Transcription
OCPP 1.XRFC ISO/IEC 15118v0.5 DRAFT, 2016-09-15
Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22. Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35. 15118 use cases relevant for OCPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46. ISO 15118 Certificate structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57. Use cases from 15118 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78. Use cases and related messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88.1. A2 - Begin of charging process with concurrent IEC 61851‑1 and High Level Communication . . . . . . . . . . . . . . . . . . . . . . . . . . 98.2. C1 - Certificate Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108.3. C1 - Certificate installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118.4. D4 - Authorization at EVSE using external credentials performed with help of SA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128.5. E1 - AC charging with load leveling based on High Level Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138.6. E2 - Optimized charging with scheduling to secondary actor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158.7. E3 - Optimized charging with scheduling at EV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178.8. F1 - Charging Loop with metering information exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198.9. F2 - Charging loop with interrupt from the SECC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208.10. F3 - Charging loop with interrupt from the EVCC or user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228.11. H1 - End of charging process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239. Trust Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2410. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2510.1. 15118 Messages and Elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2510.2. Elements without a 1511 message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3010.3. New OCPP messages to be defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3110.4. Current OCPP 2.0 15118 messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3110.5. TransactionStopped.req . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3211. DataType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3411.1. ExampleEnum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3411.2. ExampleClass. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3412. Configuration Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3412.1. NewKeyName. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3413. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3513.1. Local Smart Charging (15118) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3513.2. Central Smart Charging (15118) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Copyright 2010 – 2016 Open Charge Alliance. All rights reserved.This document is made available under the *Creative Commons AttributionNoDerivatives 4.0 International Public d/4.0/legalcode).Version 16-07-180.32016-07-070.22016-04-060.12016-03-18 Open Charge Alliance. 2016AuthorJonel Timbergen,Klaas van Zuuren ElaadNL StephanCater, ChristianLewandowskiRWEJonel Timbergen,Klaas van ZuurenElaadNLJonel Timbergen,Robert de LeeuwElaadNLJonel TimbergenElaadNLJonel TimbergenElaadNLJonel TimbergenElaadNL1/37DescriptionAdded new sequence diagrams:E1, E2, E3, F2Added mapping of use cases,messages and elements.Minor fixesAdded messages and newsequence diagramAdded additional use cases fromthe 15118 specification.Added the first use casesbelonging to this 15118 RFC.RFC ISO/IEC 15118
1. IntroductionThe ISO/IEC JWG 15118 for the Vehicle-to-Grid Communication Interface (V2G CI) was founded in 2009 with means to the need ofa complementary international standard to IEC 61851-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 EVsand charging infrastructures. The standard is currently under development and will ultimately provide means for variousauthentication schemes (e.g. plug charge vs. external identification means, like RFID cards), automatic handling of chargingservices as well as (proprietary) value added services, charge scheduling and advance planning, etc. It is structured accord- ing tothe OSI-model of ISO/IEC 7498-1. The 15118 standard is of interest to the Open Charge Alliance, as it provides the ex- change ofcharging schedules and enables to control the amount of power that an EV may draw from a Charge Point, in which some form ofvehicle to grid communication is necessary. Especially the second part, which specifies the messages to be exchanged betweenthe communication partners (Application Layer), the associated data and data types (Presentation Layer) via TCPIIP basedTransport and Network Layer, is important to acknowledge in this Request for Change (RFC). Here, the authorization for charging isprovided in a certificate within the EVSE, handled by the certificate handling process in use case elements ”C”, eliminating the roleof the Charge Point and its RFID reader.For illustration purposes: the figure below shows a complete sequence with authorization and scheduling:Figure 1. Sequence with Authorization and Scheduling2. GoalTo enhance the current OCPP specification in order facilitate the 15118 functionalities regarding vehicle to grid communication,providing additional charging schedules, authorization certificates and plug and charge functionalities. It is important to align thesetwo standards, as vehicle to grid communication will play a increasing prominent role in both the landscape of EVs and the smartgrid. Open Charge Alliance. 20162/37RFC ISO/IEC 15118
This 15118 OCPP RFC has been designed to meet a number of alignment objectives: .To allow to the communication between anEV (BEV or a PHEV) and an EVSE .To allow the support of certificate handling at the EVSE, i.e. plug and charge3. ScopeOCPP 2.0 allows Central Systems and Charge Points that both support the Smart Charging Profile to cooperate to provide smartcharging of EVs. Smart charging in OCPP refers to a controlled charging process where a Charge Point or a Central System or bothcan set constraints to the amount of power that is delivered during the course of a charge transaction. It can be used at a local levelto limit the total amount of power that may be used by a group of Charge Points, for example in a parking garage. It can also beused on a global level to adjust the power consumption of Charge Points to match the power generation capability of the grid or theavailability of renewable energy sources. In order to control the amount of power that an EV may draw from a Charge Point someform of vehicle to grid communication is necessary. OCPP has been designed to support the ISO/IEC 15118 standard [15118] forcommunication between vehicle (EV) and Charge Point (EVSE). However, it is anticipated that for the coming years, the majority ofEVs will only support the control pilot PWM signal [61851], so care has been taken to support smart charging with this as well.The RFC will consist of the following elements:1. Introductory section2. Use case documentation3. Sequence diagrams4. Additional requirements5. Messages6. Data types and configuration keys (TODO)7. Additional schema’s (TODO)8. Test scripts (TODO)9. Reference implementation (TODO)4. AbbreviationsTable 1. ILANMOOEMPLCPnCPUPWMRCDSDRSECCVASV2GBattery Management System DCH Demand Clearing HouseElectronic Control UnitElectric Energy MeterExternal Identification MeansE-Mobility Operator Clearing HouseElectricity ProviderEVEV Communication Controller EVSE EV Supply EquipmentFleet OperatorGatewayHome Area NetworkHigh Level CommunicationHuman Machine InterfaceLocal Area NetworkMeter OperatorOriginal Equipment ManufacturerPower Line CommunicationPlug and ChargePaying UnitPulse Width ModulationResidual Current DeviceService Detail RecordSupply Equipment Communication Controller EV Driver Vehicle UserValue-Added ServicesVehicle to Grid Open Charge Alliance. 20163/37RFC ISO/IEC 15118
5. 15118 use cases relevant for OCPPThe bold indicated use case component are identified as of influence of the OCPP communication.Table 2. 15118 use cases relevant for 2H1Use case element name / groupingBegin of charging process with forced High Level CommunicationBegin of charging process with concurrent IEC 61851‑1 and High Level CommunicationEVCC/SECC communication setupCertificate updateCertificate installationAuthorization using Contract Certificates performed at the EVSEAuthorization using Contract Certificates performed with help of SAAuthorization at EVSE using external credentials performed at the EVSEAuthorization at EVSE using external credentials performed with help of SAAC charging with load leveling based on High Level CommunicationOptimized charging with scheduling to secondary actorOptimized charging with scheduling at EVDC charging with load leveling based on High Level CommunicationResume to Authorized Charge ScheduleCharging loopCharging loop with metering information exchangeCharging loop with interrupt from the SECCCharging loop with interrupt from the EVCC or userReactive power compensationVehicle to grid supportValue added servicesCharging detailsEnd of charging process Open Charge Alliance. 20164/37RFC ISO/IEC 15118
6. ISO 15118 Certificate structureCharging according to ISO 15118 requires several certificates as shown in the figure below. The certificate on the EVSE (marked inred) needs to be updated every 6 weeks. There is a mechanism needed in OCPP to transfer the certificate and the private key. TheEVSE needs to check the validity of the contract certificate. To perform this check the certificate chain of the Mobility Operator(MO) must be installed on the EVSE. OCPP must support to maintain this certificate chain.Contract Certificates as XML signature credentials Contract Certificate is bound to a EMAID and used in XML signature to authorizethe vehicle for charging. The Contract Certificate can be verified even if the SECC is offline. The contract binding is handled asfollows:Figure 2. Overview of applied XML based signaturesPlug and charge Identification mode where the customer just has to plug their vehicle into the EVSE and all aspects of charging areautomatically taken care of with no further intervention from the driver.Figure 3. Overview of the resulting certificate structureThe datatype which is used to send a Charging Schedule to the EV is called SAScheduleTuple (Secondary Actor Schedule Tuple). Open Charge Alliance. 20165/37RFC ISO/IEC 15118
This data type consist of a Pmax Schedule and a SalesTariff. The SalesTariff must be signed and could be optionally encryptedwith the private key of the Mobility Operator Sub-CA. The data structure of OCPP should be aligned to the 15118 data structure inthis point. Open Charge Alliance. 20166/37RFC ISO/IEC 15118
7. Use cases from 15118Neither EV nor EVSE have any High Level Communication device, basic signalling applies. The charging process is separated intoeight functional groups to allow the classification of the elementary use cases (see Figure 2). For each functional group, severalelementary use cases are possible. Each use case should be a combination of elementary use cases (see Annex C). All possibleelementary use cases are mentioned in the document: ISO 15118-1:2013(E).a) Start of the charging process: initiation of the process between vehicle and EVSE after the physical plug-in of the vehicle. It setsthe basis for the on-going charging process e.g. availability of PWM, High Level Communication etc.;b) Communication setup: establishes the association and relevant connection between EVCC and SECC;c) Certificate Handling: everything related to certificates;d) Identification and Authorization: methods for identification and authorization;e) Target setting and charging scheduling: information needed from the EV as well as from SECC and the secondary actor to startthe charging process and charging;f) Charging controlling and re-scheduling: elements during the charging process; g) Value-added services: elements not needed forpure charging of EVs; h) End-of-charging process: Triggers for signalling the end of the charging process.Variations of use case implementations exist, depending on the EVSE, the EV or the business case used for the charging process.Figure 2 provides an overview of all use case elements grouped by function. Examples are listed in Annex C.NOTEThe groups do not specify the order in which the use case elements will be implemented, or which elements arerequired or optional. Open Charge Alliance. 20167/37RFC ISO/IEC 15118
8. Use cases and related messagesThe below table provides insight in the relation of identification modes and use case elements, following Annex A (15118-2:2014).Table 3. Relation of Identification Modes and Use Case ElementsNo.B1C1C2D2D4E1E2E3E4F3H1Use case element name / groupingEVCC/SECC communication upReq/ResCertificate eq/ResCertificateupdateReq/ResCertificate ation using Contract Certificates performed with ServicePaymentSelectionReq/Reshelp of zation at EVSE using external credentialsServiceDiscoveryReq/Resperformed with help of esAC charging with load leveling based on High owerDeliveryReq/ResChargingStatusReq/ResOptimized charging with scheduling to secondary eq/ResChargingStatusReq/ResOptimized charging with scheduling at ResDC charging with load leveling based on High ing loop with interrupt from the EVCC or userSessionStopReq/ResEnd of charging processSessionStopReq/Res Open Charge Alliance. 20168/37RFC ISO/IEC 15118
8.1. A2 - Begin of charging process with concurrent IEC 61851‑1 andHigh Level CommunicationTable 4. A2 - Begin of charging process with concurrent IEC 61851‑1 and High Level CommunicationNo.1234TypeUse case elementnameUse case element IDObjectivesDescriptionDescriptionStart of AC charging process with concurrent IEC 61851-1 and High Level Communication).A2Establish High Level Communication concurrently with IEC 61851-1 mode 3 charging.This use case covers the initial basic signalling (IEC 61851–1) from the EVSE and high-levelcommunication working concurrently and mode 3 charging.NOTE: Charging spot operator may offer a fall-back solution if High Level Communication fails byenabling charging according to IEC 61851–1.The actors involved are:- Primary actors: EV, EVSE, EVCC, SECC.5Prerequisites6Requirements7End conditionsScenario description:- Connect the cable between the EV and EVSE.- EVSE sets a valid duty cycle in the range of 10-96% (this indicates that High LevelCommunication is not required).- EV interprets the PWM duty cycle which is in the range 9 - 97 %.- EVCC and SECC establish the physical and data link layers connection (The detailed sequence isdefined in ISO 15118-3).- Communication set-up (use case function group B) is able to start.- The EV shall be connected physically to the EVSE.- The EV and EVSE require basic signalling.- The EV and EVSE shall have a higher level communication device in accordance with ISO 151182 and ISO 15118-3.- Successful set up of High Level Communication at the data link layer- Timing for the initialization process shall be according to ISO 15118-3.Triggers:- For EVSE: EV is connected properly to the EVSE- For EV: Plug present shall be according IEC 61851-1.Success end conditions: *- Successful set-up of High Level Communication at the data link layer.Failure end conditions:- No establishment of High Level Communication at the data link layer.- Failure of PWM signal- No correct association of SECC and EVCC or timeout in the binding process occurs. Open Charge Alliance. 20169/37RFC ISO/IEC 15118
8.2. C1 - Certificate UpdateTable 5. C1 - Certificate Scenario description5678Alternative scenario’sPrerequisitesPost conditionsSequence diagramRequirements Open Charge Alliance. 2016DescriptionCertificate UpdateC1Replace the valid or expired certificate in the EV with a new and valid certificate from thesecondary actor.This use case covers the update of a valid certificate in the EV. Therefore, the EVCC is initiating acertificate update process using the established High Level Communi- cation with the SECC toretrieve a new certificate from the issuing secondary actor. NOTE 1 There may be alternativecommunication paths to do a certificate update. However, these are outside the scope of thisstandard. NOTE 2 Whether an expired certificate is subject to be updated depends on thebusiness decision of SA NOTE 3 If there is no permission from the SA to update the certificate,Use Case Element C2 might apply. The certificate update process from SECC to secondary actorand back is outside the scope of this standard.— Primary actors: EVCC, SECC. — Secondary actors: EMOCH, FO, E-Mobility OperatorThe actors involved are: Scenario description: — EVCC requests a certificate update by SECC,providing information about the secondary actor who has issued the certificate. — SECC enablesa communication link to the secondary actor or provide the cer- tificates to be updated as a localcopy. — SECC requests a certificate update for EVCC from secondary actor containing EVCCspecific information. — Issuing entity provides a new certificate to the requesting SECC. — SECCforwards the new certificate to EVCC.(list of alternative use scenario’s, should be other use cases)(Preconditions for this use case)(Post conditions after this use case is finished successfully)EVCC shall support the certificate update process. SECC shall support the certificate updateprocess. Trigger: — EVCC / SECC detects that the certificate of the EV has — Limited remaininglifetime.10/37RFC ISO/IEC 15118
8.3. C1 - Certificate installationTable 6. C1 - Certificate ActorsScenario description5Alternative scenario’sPrerequisites6Post conditions7Sequence diagram89Error HandlingRemarks Open Charge Alliance. 2016DescriptionCertificate Installation(ID of this use case (same as chapter name: UC.01?)Installation of a new certificate from the secondary actor in the EV.This use case covers the installation of a certificate (Contract Certificate) into the EV if no suchcertificate is available yet / it has expired / is invalid. Therefore, the EVCC is initiating a certificateinstallation process using the established High Level Communication with the SECC to retrieve acertificate from the issuing secondary actor. The EV is identified by using a certificate (OEMProvisioning Certificate) that was installed by the OEM earlier (e.g. at EV production).NOTE There may be alternative communication paths for doing a certificate installation. However,these are outside the scope of this standard. The certificate installation / transfer process fromSECC to the secondary actor and back is outside the scope of this standard. The correspondingcontract may be identified by the secondary actor, for instance, via the certificate ID of theBootstrap Certificate. This ID is transferred from the customer to the secondary actor at contractcreation. (First, the OEM has to transfer this ID to the customer e.g. at EV delivery). — SECCrequests a certificate installation for EVCC from the secondary actor found containing EVCCspecific information (OEM Provisioning Certificate). — Issuing entity shall provide a certificate andthe corresponding private key to the requesting SECC. At least the private key has to be encryptedusing the old EVCC OEM Provisioning Certificate. — SECC shall forward the new certificate andthe corresponding (encrypted) private key to EVCC. (Description of this use case)The actors involved are:— Primary actors: EVCC, SECC.— Secondary actors: EMOCH, FO, E-Mobility OperatorScenario description: — EVCC requests a certificate installation by SECC.— For this purpose, the SECC has to identify the secondary actor which has a contract with theowner of the EV. Therefore, it has to send the OEM Provisioning Certificate (or its ID) to — theclearing house / all known clearing houses.— the preferred secondary actor / all known secondary actors.(list of alternative use scenario’s, should be other use cases)— Communication set-up according to use case element B1 shall be established successfully.— No Contract Certificate resp. no valid Contract Certificate is available in the EV.— A Bootstrap Certificate created by the OEM is available in the EV.— Online connection between SECC and secondary actor shall be possible or certificates to beupdated shall be available on SECC.Success end conditions:— Valid certificate (Contract Certificate) from secondary actor shall be stored in the EVCC.— The Bootstrap Certificate (created by the OEM) is still available in the EV. Failure endconditions:— Certificate update failed due to communication issue.— Certificate update failed due to rejection by the secondary actor.— Certificate update failed because no secondary actor with a matching con- tract can be found.(What is the expected behaviour when something goes wrong?)(Add additional remarks here.)11/37RFC ISO/IEC 15118
8.4. D4 - Authorization at EVSE using external credentials performedwith help of SATable 7. D4 - Authorization at EVSE using external credentials performed with help of SANo.123TypeUse case elementnameUse case element IDObjectives4DescriptionDescriptionAuthorization at EVSE using external credentials performed with help of SA.D4Authorization at EVSE with credentials, which are external to the vehicle, with help of a secondaryactor.This use case covers the process of how identification should be validated by a secondary actor.EV Driver identifies himself/herself at the EVSE by using one of the identification methodsoffered.NOTE: Depending on the identification type, the EVSE operator may not have the possibility toauthenticate the IDs and therefore might not authorize the service.The actors involved are:- Primary actors: USER, EVSE, SECC, HMI.- Secondary actors: EMOCH, E-Mobility Operator.5Prerequisites6Requirements7End conditionsScenario description:- SECC forwards the IDs (EVSE ID and contract ID) to the secondary actor for validation.- The secondary actor replies with an agreement or non-agreement.- Service Starts after successful verification of the IDs.- Communication set-up according to use case element B1 shall be established successfully.- Online connection between SECC and secondary actors is required.- EV Driver shall activate the authorization within a specific time after connect- ing the EV to theEVSE or the EVSE shall have an HMI to authorize the restart of the identification process.- EV Driver shall use the identification method at EVSE (e.g. HMI).- The SECC shall send the identification to the secondary actor for validation.Trigger:— Authorization shall be made at the EVSE and activated by the USER.Success end conditions:- Authorization process is successful, a session ID is defined and the required service (charging orvalue-added) starts.Failure end conditions:- Authorization process fails.- The identification performed by the EV Driver at the EVSE is not validated by the secondaryactor.- The required service does not start.- EV Driver might be informed about the reason for failure (i.e. contract has expired, contract hasbeen blocked, stolen car or contract, procedure to be restarted, identification server not available).Figure 4. Sequence Diagram: Authorization at EVSE using external credentials performed with help of SA. Open Charge Alliance. 201612/37RFC ISO/IEC 15118
8.5. E1 - AC charging with load leveling based on High LevelCommunicationTable 8. E1 - AC charging with load leveling based on High Level CommunicationNo.123TypeUse case elementnameUse case element IDObjectives4DescriptionDescriptionAC charging with load leveling based on High Level Communication.E1This use case covers only charging within local charging infrastructures. Dynamic adjustment ofthe maximum AC current to be drawn by the EV within the limits of the local installation.The SECC and EVCC exchange information about the AC current limits using High LevelCommunication. The SECC communicates the maximum power that can be drawn from theoutlet, in order to protect the EVSE, to the EVCC.EXAMPLE: Simple load leveling can be in a car park or at home, where not all AC power outletscan deliver full AC current and, therefore, need to dynamically adjust the maximum AC currentthat the EV can draw.56PrerequisitesCombined scenariodescription7Requirements8End conditionsThe actors involved are:— Primary actors: USER, EVSE, SECC.— If authorization according use case elements D is applied, it shall be established successfully.151181. The EVCCC sends ChargeParameterDiscoveryReq to the SECC.OCPP2. The SECC sends NotifyEVChargingNeeds PDU to the Central System.3. The Central System sends a NotifyCentralChargingNeeds to the SECC.4. The SECC responds with ChargeParameterDiscoveryRes to the EVCC.5. THE EVCC sends a PowerDelivery PDU to the SECC marks the point in time when the EVSEprovides voltage to its output power outlet and the EV can start to recharge its battery.OCPP6.* Optionally the SECC sends a NotifyEVChargingShedule PDU to the Central System.7. The contactor is
pure charging of EVs; h) End-of-charging process: Triggers for signalling the end of the charging process. Variations of use case implementations exist, depending on the EVSE, the EV or the business case used for the charging process. Figure 2 provides an overview of all use case elements grouped by function. Examples are listed in Annex C. NOTE
