ocpp icon indicating copy to clipboard operation
ocpp copied to clipboard

Update Get15118EVCertificateResponse.json

Open HugoJP1 opened this issue 3 years ago • 6 comments

At Switch, we have been running into an issue in 2.0.1 where certificates for the EV included in Get15118EVCertificateResponse are greater than 5600 (around 5800). This is because certificates have a lot of information embedded in them which can have variable length. We know that we haven't been the only company to encounter this issue, because it has been the focus of an OCA Technology Working Group meeting in early March. The provisional conclusion at that time was to increase the limit to 7500. This hasn't been formalised in a document yet, although I know that a follow up conversation is planned (see OCA notes from that meeting below)

Proposing to set to 7500 for now and then update once we get the full decision from the OCA.

  • exiResponse field length limitation Long discussion on how to address this. There were some concerns that a charging station won't any longer be able to handle the message. The main problem is that we don't know how big the message will get because OCPP is only forwarding the messages and not defining them. Same problem for the -20 task group, because in the ISO15118-20 more and bigger certificates are allowed. Results: OCA will update the PnC 1.6 Whitepaper. The maximum length in the JSON schema will be dropped for the Get15118EvCertificate.conf message and the exiResponse field. The charging station shall report its maximum supported length of the field via a configuration variable. Additionally, there will be a recommendation regarding a reasonable length for the field (7500 chars). There will be a follow-up discussion on how to tackle this issue in OCPP 2.0.1. Franc created a JIRA Ticket for this https://openchargealliance.atlassian.net/browse/OCPP16M-67

HugoJP1 avatar Sep 05 '22 16:09 HugoJP1

SonarCloud Quality Gate failed.    Quality Gate failed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
5.7% 5.7% Duplication

sonarqubecloud[bot] avatar Sep 05 '22 16:09 sonarqubecloud[bot]

@OrangeTux does that sound reasonable for you? also not sure why sonar cloud is complaining as it was one line change

tropxy avatar Sep 05 '22 16:09 tropxy

to add to the explanation on the top, Hubject onboarding document with the title "Requirements for EVSEs" says this:

3.2. Deviation from OCPP Message Get15118EVCertificate The value of the FIELD NAME exiRequest/Response in the OCPP Message Get15118EVCertificate is limited to 5600 characters. This limitation is too low. The EVSE shall accept strings for exiRequest/Response being a maximum of 7500 characters long but must accept exiRequest/Response being 6100 characters long.

I cant provide the full copy of the document, unfortunately, but I hope that is enough

tropxy avatar Sep 06 '22 09:09 tropxy

I'm not sure how to handle this situation, to be fair.

The OCPP 2.0.1 spec defines the limit as 5600 characters. I think this library should follow implement the specification. When the OCA makes changes to an existing spec, they should release the changes as part of a new version. For example as version 2.0.2.

I'm fine with adding preliminary support for this new version. Are you aware if the OCA is planning to release these changes under a new version, @tropxy ?

OrangeTux avatar Sep 08 '22 09:09 OrangeTux

@OrangeTux this is the current plan (from the draft errata of OCPP 2.0.1 due to be released officially soon): image

HugoJP1 avatar Oct 14 '22 12:10 HugoJP1

@OrangeTux this is the current plan (from the draft errata of OCPP 2.0.1 due to be released officially soon): image

@OrangeTux given this, I think we shall include this PR into the base code, what do you say?

tropxy avatar Oct 14 '22 12:10 tropxy