0% found this document useful (0 votes)
28 views26 pages

Using OCPP With CHAdeMO

Uploaded by

Hans HP
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
28 views26 pages

Using OCPP With CHAdeMO

Uploaded by

Hans HP
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 26

Using OCPP with CHAdeMO

v1.0, 2020-12-03
Relevant for:
• OCPP version: 1.6 and 2.0.1.
• CHAdeMO version: 1.1 and 2.0.1

Copyright © 2020 Open Charge Alliance & CHAdeMO Association. All rights reserved.

Copyright and Restrictions on Circulation and Use

This document (set) is protected by copyright held by the Open Charge Alliance & CHAdeMO Association. This document is made
available under the *Creative Commons Attribution-NoDerivatives 4.0 International Public License* (https://creativecommons.org/
licenses/by-nd/4.0/legalcode).

Version History

VERSION DATE AUTHOR DESCRIPTION

1.0 2020-12-03 Franc Buve First release.


OCA
Milan Jansen
OCA

© Open Charge Alliance & CHAdeMO Association 2020 1/25 Using OCPP with CHAdeMO
1. Executive Summary
A CHAdeMO charging station "speaks" CHAdeMO to the electric vehicle and OCPP to the charging station management system.
How do they relate to each other? This white paper has been written by Open Charge Alliance together with the CHAdeMO
Association to show how these protocols work together to charge a vehicle. It provides a translation table for the terminology used
in both protocols and a set of diagrams that show the exchange of messages between electric vehicle and charging station on the
one hand and charging station and management system on the other hand. It also explains how information from CHAdeMO about
the DC charging session in progress can be made available to a charging station management system via the OCPP 2.x device
model functionality.

2. Introduction
OCPP is a standard communication protocol between a charging station and a charging station management system and it is
independent of the type of connection between the charging station and the electric vehicle. CHAdeMO is a standard for the
connection between a charging station and an electric vehicle for DC fast charging.

As such, these two standards do not overlap. It is the charging station that needs to be able to translate information between these
two protocols. For example, when the electric vehicle provides its current state of charge via CHAdeMO to the charging station,
then the charging station will translate this to OCPP and pass this on to the charging station management system. Similarly, when
the management system sends an OCPP message to the charging station to reduce the charging power (e.g. in a smart charging
scenario), then the charging station will translate this to CHAdeMO parameters that are communicated to the electric vehicle.

In a joint working group, the CHAdeMO Association and Open Charge Alliance sat together to create a translation table, for the
terminology used in both standards, and to create detailed sequence diagrams that show the interaction between OCPP and
CHAdeMO. In addition, they documented how the wealth of information that CHAdeMO provides about the DC charging that is in
progress, can be made available to the charging system management system via the OCPP device model.

The information provided in this white paper is useful for both charging station manufacturers and charging station operators. If
you are developing a charging station with CHAdeMO, then the translation table and sequence diagrams will accelerate your
development. If you have already developed such a charging station, then reading the chapter about publishing CHAdeMO data in
the OCPP device model in OCPP 2.x will show you how to make everything you know from the DC charging session available to the
management system. As a charging station operator you can use this data to show information about state of charge and
remaining charging time on the charger display (if it does not already do so) or perhaps in the smartphone app that was used to
start the session. This information can also be used to tailor your smart charging schedule to the vehicle that is being charged.

2.1. Reading Guide


The white paper continues with an OCPP - CHAdeMO translation table in chapter OCPP - CHAdeMO Translation Table. This is
useful if you are familiar with the OCPP protocol specification and need to implement a charging station that supports CHAdeMO or
vice versa.

Chapter OCPP and CHAdeMO Sequence Diagrams shows the sequence of messages that occur during starting and stopping of a
transaction, on the CHAdeMO side of a charging station as well as on the OCPP side.

Chapter Showing CHAdeMO Data in OCPP Device Model shows how the OCPP device model can be used to make everything the
charging station knows about the electric vehicle that is connected, available to the charging system management system. It is
entirely up to the manufacturer of the charging station to decide what information is to be published in this way, because everything
that is needed by the back-office to manage a charging session is already provided in the relevant OCPP messages. The
information that is published about the connected vehicle can, however, be very useful for informational or diagnostic purposes. It
might even be used to optimize your smart charging algorithm, for example by making use of values like "Total capacity of traction
battery" and "Estimated charging time", that are provided by CHAdeMO.

© Open Charge Alliance & CHAdeMO Association 2020 2/25 Using OCPP with CHAdeMO
3. OCPP - CHAdeMO Translation Table
3.1. Definitions

OCPP includes additional concepts that have no equivalents in CHAdeMO, either because they relate to the link between the charging station and the charging station
management system, because they relate to local HMI interactions that do not affect the EV charging interface directly, or because they’re specifically related to EV charging
NOTE
interface protocols other than CHAdeMO.
Such concepts are not covered in this document — refer to the relevant OCPP specifications for details on these areas.

CHAdeMO includes additional concepts that have no equivalents in OCPP, either because they relate to low level details of the electrical interface between the charging station
NOTE and the electric vehicle, or because they relate to concepts that are not covered by OCPP 1.6 and 2.0.1 (such as V2G and V2H support).
Such concepts are not covered in this document — refer to the relevant CHAdeMO specifications for details on these areas.

OCPP 1.6 EDITION 2 OCPP 2.0.1 PART 2 - SPECIFICATION CHADEMO 1.1 CHADEMO 2.0.1
SECTION 2. TERMINOLOGY AND CONVENTIONS SECTION 2. CONVENTIONS, TERMINOLOGY AND SECTION 3. TERMS AND DEFINITION SECTION 3. TERMS AND DEFINITION
ABBREVIATIONS

Definition Description Definition Description Definition Description Definition Description

Charge Point The Charge Point is the physical Charging Station The Charging Station is the Quick charger/Charger Quick charger/Charger
system where an electric vehicle physical system where EVs can be
can be charged. A Charge Point charged. A Charging Station has
has one or more connectors. one or more EVSEs.

Central System Charge Point Management System: CSMS Charging Station Management N/a N/a
the central system that manages System. The system that manages
Charge Points and has the Charging Stations and has the
information for authorizing users information for authorizing Users
for using its Charge Points. for using its Charging Stations.

EV Electrical Vehicle, this can be BEV EV Electric Vehicle, distributed energy Electric A vehicle using an electric motor as Electric A vehicle using an electric motor as
(battery EV) or PHEV (plug-in hybrid resource with a remote battery and vehicle/Vehicle a powertrain. vehicle/Vehicle a powertrain.
EV) socket.

Connector The term “Connector”, refers to an Connector The term Connector, refers to an Charging connector A connecting apparatus equipped Charging connector A connecting apparatus equipped
independently operated and independently operated and to charging cable that complies to charging cable that complies
managed electrical outlet on a managed electrical outlet on a with IEC62196-3 Standard Sheets with IEC62196-3 Standard Sheets
Charge Point. This usually Charging Station. In other words, Configuration AA Configuration AA
corresponds to a single physical this corresponds to a single
connector, but in some cases a physical Connector. In some cases
single outlet may have multiple an EVSE may have multiple
physical socket types and/or physical socket types and/or
tethered cable/connector tethered cable/Connector
arrangements to facilitate different arrangements(i.e. Connectors) to
vehicle types. facilitate different vehicle types.

© Open Charge Alliance & CHAdeMO Association 2020 3/25 Using OCPP with CHAdeMO
OCPP 1.6 EDITION 2 OCPP 2.0.1 PART 2 - SPECIFICATION CHADEMO 1.1 CHADEMO 2.0.1
SECTION 2. TERMINOLOGY AND CONVENTIONS SECTION 2. CONVENTIONS, TERMINOLOGY AND SECTION 3. TERMS AND DEFINITION SECTION 3. TERMS AND DEFINITION
ABBREVIATIONS

Charging cable Charging cable Cable assembly equipped with a, by Charging cable An electrical cable comprising Charging cable An electrical cable comprising of
the EV accepted, plug, intended to power wires and signal wires for power wires and signal wires for
be used for the connection charging a vehicle charging a vehicle (6)
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.

N/a EVSE An EVSE is considered as an N/a N/a


independently operated and
managed part of the Charging
Station that can deliver energy to
one EV at a time.

N/a N/a Control circuit Circuit for charger control and Control circuit Circuit for charger control and
supplying power (DC12V) to vehicle supplying power (DC12V) to vehicle

N/a N/a Traction battery A battery used for traction mounted Traction battery A battery used for traction mounted
on an electric vehicle. on an electric vehicle.

Connector lock Connector lock Latch A component which prevents the Latch A component which prevents the
release of charging connector from release of charging connector from
vehicle inlet vehicle inlet

N/a N/a Latch holding A function for immobilizing the Latch holding A function for immobilizing the
latch by electrical signal latch by electrical signal

EV Driver EV Driver The Driver of an EV who wants to User User


charge the EV at a Charging
Station.

State of charge (SoC) State of charge of charging vehicle State of charge (SoC) State of charge of charging vehicle State of charge (SoC) Charged rate of traction battery State of charge (SoC) Charged rate of traction battery
in percentage in percentage calculated by vehicle that is only calculated by vehicle that is only
used for display on charger State of used for display on charger State of
charge (SOC) of traction battery charge (SOC) of traction battery
shall be set in % unit. shall be set in % unit.

Control Pilot signal Signal used by a Charge Point to Control Pilot signal A signal used by a Charging Station Control signal Signals used for establishing Control signal Signals used for establishing
inform EV of maximum Charging to inform an EV of a maximum charging sequence between charging sequence between a
power or current limit, as defined current limit, as defined by charger and vehicle (except for charger and a vehicle (except for
by [IEC61851-1]. IEC61851-1. CAN communication). CAN communication).

Contactor An electrically controlled switching


device, typically used by Charging
Stations to switch charging power
on/off.

Transaction start point Transaction starts at the point that TxStartPoint Defines when the Charging Station Charging start trigger User triggers the charging process Charging start trigger User triggers the charging by plug
all conditions for charging are met, starts a new transaction. The by plug the cable, or swipe a card the cable, or swipe a card or presse
for instance, EV is connected to sequence diagrams are using the or presse the charging start button the charging start button etc.
Charge Point and user has been configuration EVConnected. etc.
authorized.

Transaction stop point Transaction ends at the point TxStopPoint Defines when the Charging Station Charger detects stop user indicates termination of Charger detects stop user indicates termination of
where one of the preconditions for ends a transaction. The sequence instruction by user charging, ・Stop button is pressed instruction by user charging, ・Stop button is pressed
charging irrevocably becomes diagrams are using the ・Termination signal from ・Termination signal from
false, for instance when a user configuration EVConnected. communication functions or communication functions or
swipes to stop the transaction and authentication card (e.g. RFID) authentication card (e.g. RFID)
the stop is authorized.

© Open Charge Alliance & CHAdeMO Association 2020 4/25 Using OCPP with CHAdeMO
OCPP 1.6 EDITION 2 OCPP 2.0.1 PART 2 - SPECIFICATION CHADEMO 1.1 CHADEMO 2.0.1
SECTION 2. TERMINOLOGY AND CONVENTIONS SECTION 2. CONVENTIONS, TERMINOLOGY AND SECTION 3. TERMS AND DEFINITION SECTION 3. TERMS AND DEFINITION
ABBREVIATIONS

N/a N/a EV contactor A switching device dedicated for EV contactor A switching device dedicated for
quick charging installed on the quick charging installed on the
power lines of vehicle near vehicle power lines of the vehicle near
inlet vehicle inlet

Cable Plugged in In this document this can mean the Connector Proximity Both charger and vehicle shall have
following: - Cable fixed on Charging detection a means to confirm that they are
Station side, cable plugged in to EV connected with each other. The
- Cable plugged into the Charging charger shall detect the status of
Station and EV - Wireless Charger connector mating and use it as a
detects an EV* trigger to start charging

Charging Profile Generic charging profile, used for Charging Profile Generic charging profile, used for
different types of Profiles. Contains different types of Profiles. Contains
information about the Profile and information about the Profile and
holds the Charging Schedule. In holds the ChargingSchedule.
future versions of OCPP it might
hold more than 1 Charging
Schedule.

Charging Schedule Part of a charging profile. Defines a Charging Schedule Part of a charging profile. Defines a
block of charging Power or Current block of charging Power or Current
limits. Can contain a start time and limits. Can contain a start time and
length. length.

Composite Charging The charging schedule as Composite Charging "The charging schedule as
Schedule calculated by the Charge Point. It is Schedule calculated by the Charging Station.
the result of the calculation of all It is the result of the calculation of
active schedules and possible local all active schedules and possible
limits present in the Charge Point. local limits present in the Charging
Local Limits might be taken into Station. Local Limits might be
account. taken into account.

Energy Management A device that manages the local


System 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.

Energy Offer Period Energy Offer Period starts when the Energy Offer Period Time during which a charging
EVSE is ready and willing to supply station is ready and willing to offer
energy. energy to an EV.

Energy Transfer Time during which an EV chooses Energy Transfer Time during which an EV chooses
Period to take offered energy, or return it. Period to take offered energy, or return it.
Multiple Energy Transfer Periods
are possible during a Transaction.

© Open Charge Alliance & CHAdeMO Association 2020 5/25 Using OCPP with CHAdeMO
OCPP 1.6 EDITION 2 OCPP 2.0.1 PART 2 - SPECIFICATION CHADEMO 1.1 CHADEMO 2.0.1
SECTION 2. TERMINOLOGY AND CONVENTIONS SECTION 2. CONVENTIONS, TERMINOLOGY AND SECTION 3. TERMS AND DEFINITION SECTION 3. TERMS AND DEFINITION
ABBREVIATIONS

Local Controller Optional device in a smart charging Local Controller A logical entity between a CSMS
infrastructure. Located on the and one or more charging stations
premises with a number of Charge that has the ability to control
Points connected to it. Sits charging of a group of charging
between the Charge Points and stations based on the input from
Central System. Understands and the CSMS, and can send messages
speaks OCPP messages. Controls to its charging stations,
the Power or Current in other independently of the CSMS.
Charge Point by using OCPP smart
charging messages. Can be a
Charge Point itself.

Offline There is no communication


possible between the charging
station and CSMS. For an OCPP-J
connection this means the
WebSocket connection is not open.

Charging Session A Charging Session is started when Session A Session in OCPP is a general
first interaction with user or EV term that refers to the charging
occurs. This can be a card swipe, process of an EV, that might
remote start of transaction, include a Transaction.
connection of cable and/or EV,
parking bay occupancy detector,
etc.

Transaction The part of the charging process Transaction A transaction in OCPP is a part of Charging control Generic Charging process based on Charging control flow Generic Charging process based on
that starts when all relevant the complete process of charging sequence CHAdeMO communication CHAdeMO communication
preconditions (e.g. authorization, an EV that starts and stops based protocol, including charging start protocol, including charging start
plug inserted) are met, and ends at on configurable parameters. These process, communicaiton sequence, process, communicaiton sequence,
the moment when the Charge Point configurable parameters refer to charging parameter exchange, error charging parameter exchange, error
irrevocably leaves this state. moments in the charging process, handling and charging termination handling and charging termination
such as the EV being connected or process process
the EV driver being authorized.

External Control An external system that may


System impose charging limits/constraints
on the charging station or CSMS,
for example a DSO or EMS.

Energy Offer During a transaction, there may be


SuspendPeriod periods the EnergyOffer to EV is
suspended by the EVSE, for
instance due to Smart Charging or
local balancing.

Vehicle inlet Mating point of charging connector Vehicle inlet Mating point of charging connector
at vehicle side which is in at vehicle side that complies with
compliance with IEC62196-3 IEC62196-3 Standard Sheets
Standard Sheets Configuration AA Configuration AA

Input circuit Charging circuit from the power Input circuit Charging circuit from the power
receiving terminal connected to a receiving terminal connected to a
power supply such as AC mains to power supply such as AC mains to
the primary side of the isolation the isolation device which secures
device which secures isolation isolation between a charger and a
between charger and vehicle vehicle

© Open Charge Alliance & CHAdeMO Association 2020 6/25 Using OCPP with CHAdeMO
OCPP 1.6 EDITION 2 OCPP 2.0.1 PART 2 - SPECIFICATION CHADEMO 1.1 CHADEMO 2.0.1
SECTION 2. TERMINOLOGY AND CONVENTIONS SECTION 2. CONVENTIONS, TERMINOLOGY AND SECTION 3. TERMS AND DEFINITION SECTION 3. TERMS AND DEFINITION
ABBREVIATIONS

Output circuit Charging circuit from on the Output circuit Charging circuit from the
secondary side of the isolation secondary side of the isolation
device which secures the isolation transformer which secures the
between charger and vehicle to the isolation between the primary
tip of charging connector circuit of a charger and a vehicle to
the tip of charging connector

Main circuit Circuit which includes the input Main circuit Circuit which includes the input
circuit and the output circuit circuit and the output circuit

Maximum current The maximum value of current


which can be output under the
standard operating condition (the
current specified by the charger
manufacturer)

CAN communication Communication means used to CAN communication Communication means used to
exchange data between charger exchange data between the
and vehicle for charging control. charger and vehicle for charging
control

Data area CAN parameter defined by byte and Data area CAN parameter defined by byte and
bit of each ID as data format of bit of each ID as data format of
CAN communication. It does not CAN communication. It does not
include area which is not defined include the area which is not
by the specification (value defined by the specification (value
exceeding specified maximum exceeding specified maximum
value and value other than the fixed value and value other than the fixed
value). value)

Energization A state in which the output voltage Energization A period from before the start of
is possible, including insulation test the insulation test by the charger to
of charger and welding detection of the output voltage exceeding 10V
vehicle or the output current is is applied after the charging current
possible, and/or when a voltage of is terminated including the welding
more than 10V is applied to the detection
output circuit.

Power failure A state in which the input voltage Power failure A state in which the input voltage
falls below the specified input falls below the specified input
voltage range. voltage range

Y capacitor Capacitor which is installed


between P and GND, N and GND of
the charger and the vehicle,
typically as noise filtering
component.

© Open Charge Alliance & CHAdeMO Association 2020 7/25 Using OCPP with CHAdeMO
3.2. Charger States
OCPP 1.6 EDITION 2 OCPP 2.0.1 PART 2 - SPECIFICATION CHADEMO 1.1 CHADEMO 2.0.1
SECTION 4.9. STATUS NOTIFICATION SECTION 3.16. CHARGINGSTATEENUMTYPE & 2.6.4.1. APPENDED TABLE3.2.3 DEFINITION OF STATE OF APPENDED TABLE 3.3.3 DEFINITION OF STATE OF
TXSTARTSTOPPOINT VALUES CHARGER CHARGER

State Description State Description State Description State Description

Available (Connector) When a Connector becomes Idle Idle status is referred as the state State A / Standby Unconnected with vehicle State A / Standby Disconnected with vehicle
available for a new user (Operative) 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.

Preparing When a Connector becomes no EVConnected There is a connection between EV State B / Standby Connected with vehicle State B / Standby Connected with vehicle
longer available for a new user but and EVSE, in case the protocol
there is no ongoing Transaction used between EV and the charging
(yet). Typically a Connector is in station can detect a connection,
preparing state when a user the protocol needs to detect this
presents a tag, inserts a cable or a for the state to become active. The
vehicle occupies the parking bay connection can either be wired or
(Operative)" wireless.

SuspendedEVSE/Susp SuspendedEVSE: PowerPathClosed/Sus PowerPathClosed: All State C From [Switch(d1) = ON] to [opto- State C From [Switch(d1) = ON] to [opto-
endedEV When the EV is connected to the pendedEV/Suspended preconditions are met, power can coupler (j) = ON and "vehicle coupler (j) = ON and ‘vehicle
EVSE but the EVSE is not offering EVSE flow. In case of a wired charger, the charging enabled (H'102.5.0)"= 1] charging enabled (H'102.5.0)’= 1]
energy to the EV, e.g. due to a cable is properly connected, driver
smart charging restriction, local is authorized, etc. This does not
supply power constraints, or as the mean that the EV is read to charge
result of StartTransaction.conf it’s battery, it might, for example, be
indicating that charging is not to warm. SuspendedEVSE: When
allowed etc. (Operative) the EV is connected to the EVSE
SuspendedEV: When the EV is but the EVSE is not offering energy
connected to the EVSE and the to the EV, e.g. due to a smart
EVSE is offering energy but the EV charging restriction, local supply
is not taking any energy. power constraints, or when
(Operative)" charging has stopped because of
the authorization status in the
response to a
transactionEventRequest indicating
that charging is not allowed etc.
SuspendedEV: When the EV is
connected to the EVSE and the
EVSE is offering energy but the EV
is not taking any energy."

State D "From [opto-coupler (j) = ON and State D "From [opto-coupler (j) = ON and
""vehicle charging ‘vehicle charging
enabled""(H'102.5.0) = 1] to enabled’(H'102.5.0) = 1] to [‘charger
[“charger status (H'109.5.0)” = 1 status (H'109.5.0)’ = 1 and
and “charging stop control ‘charging stop control (H'109.5.5)’
(H'109.5.5)” = 0] = 0]

Charging "When the contactor of a Charging/EnergyTrans The contactor of the Connector is State E From [“charger status (H'109.5.0)” State E From [‘charger status (H'109.5.0)’ =
Connector closes, allowing the fer closed and energy is flowing to = 1 and “charging stop control 1 and ‘charging stop control
vehicle to charge (Operative)" between EVSE and EV. (H'109.5.5)” = 0] via [charging] to (H'109.5.5)’ = 0] via [charging] to
[transmission / reception of stop [transmission / reception of stop
instruction]" instruction]

© Open Charge Alliance & CHAdeMO Association 2020 8/25 Using OCPP with CHAdeMO
OCPP 1.6 EDITION 2 OCPP 2.0.1 PART 2 - SPECIFICATION CHADEMO 1.1 CHADEMO 2.0.1
SECTION 4.9. STATUS NOTIFICATION SECTION 3.16. CHARGINGSTATEENUMTYPE & 2.6.4.1. APPENDED TABLE3.2.3 DEFINITION OF STATE OF APPENDED TABLE 3.3.3 DEFINITION OF STATE OF
TXSTARTSTOPPOINT VALUES CHARGER CHARGER

StopAuthorized/Deaut StopAuthorized: An EV Driver has State F From [transmission / reception of State F From [transmission / reception of
horized/RemoteStop been authorized to stop charging. stop instruction] to [ current in the stop instruction] to [ current in the
For example: By swiping an RFID output circuit is less than or equal output circuit is less than or equal
card. Deauthorized: The to 5A and “charger status to 5A and ‘charger status
transaction was stopped because (H'109.5.0)” = 0] (H'109.5.0)’ = 0]
of the authorization status in the
response to a
transactionEventRequest.
RemoteStop: A
RequestStopTransactionRequest
has been sent.

Finishing When a Transaction has stopped at EVConnected There is a connection between EV State G From [ current in the output circuit State G From [ current in the output circuit
a Connector, but the Connector is and EVSE, in case the protocol is less than or equal to 5A and is less than or equal to 5A and
not yet available for a new user, used between EV and the charging “charger status (H'109.5.0)” = 0] to ‘charger status (H'109.5.0)’ = 0] to
e.g. the cable has not been station can detect a connection, [“vehicle status (H'102.5.3)” = 1] [‘vehicle status (H'102.5.3)’ = 1]
removed or the vehicle has not left the protocol needs to detect this
the parking bay (Operative) for the state to become active. The
connection can either be wired or
wireless.

State H From [“vehicle status (H'102.5.3)” = State H From [‘vehicle status (H'102.5.3)’ =
1] to [voltage in the output circuit is 1] to [voltage in the output circuit is
less than or equal to 10V and less than or equal to 10V and
“energizing state (H'109.5.2)” = 0] ‘energizing state (H'109.5.2)’ = 0]

State I From [voltage in the output circuit State I From [voltage in the output circuit
is less than or equal to 10V and is less than or equal to 10V and
“energizing state (H'109.5.2)” = 0] ‘energizing state (H'109.5.2)’ = 0] to
to [End of CAN data transmission] [End of CAN data transmission]

SuspendedEVSE/Susp SuspendedEVSE: When the EV is SuspendedEVSE/Susp SuspendedEVSE: When the EV is


endedEV connected to the EVSE but the endedEV connected to the EVSE but the
EVSE is not offering energy to the EVSE is not offering energy to the
EV, e.g. due to a smart charging EV, e.g. due to a smart charging
restriction, local supply power restriction, local supply power
constraints, or as the result of constraints, or when charging has
StartTransaction.conf indicating stopped because of the
that charging is not allowed etc. authorization status in the
(Operative) SuspendedEV: When response to a
the EV is connected to the EVSE transactionEventRequest indicating
and the EVSE is offering energy but that charging is not allowed etc.
the EV is not taking any energy. SuspendedEV: When the EV is
(Operative)" connected to the EVSE and the
EVSE is offering energy but the EV
is not taking any energy.

Faulted When a Charge Point or connector Faulted When a Connector (or the EVSE or Charger Charging system error: Charger Charging system error:
has reported an error and is not the entire charging station it error/Charging system Error flag indicating vehicle error or error/Charging system Error flag indicating a vehicle error
available for energy delivery . belongs to) has reported an error error error or a charger error detected by
charger error detected by charger
(Inoperative). and is not available for energy
Charger error: vehicle
delivery. (Inoperative).
Error flag indicating charger’s error Charger error:
detected by charger Error flag indicating charger’s error
detected by charger"

© Open Charge Alliance & CHAdeMO Association 2020 9/25 Using OCPP with CHAdeMO
4. OCPP and CHAdeMO Sequence Diagrams
The clearest way to show the relationship between OCPP and CHAdeMO message is to graphically show in chronological order
which message are exchanged between EV and charging station and charging station and charging station management system.
These so-called sequence diagrams show messages that are sent as lines with arrows from one party to another. When lines are
encapsulated this can mean one of two things. It is either optional or conditional. An optional message sequence is indicated by
'opt' and a conditional message sequence is indicated by 'alt', which is followed by the condition that describes when the message
sequence will occur. Note, that the time flow from top to bottom of the diagram is not to scale, i.e. the vertical spacing between
messages does not say anything about the timing between them — it only describes the order in which they are sent.

This chapter holds sequence diagrams for the most common scenarios:

1. Starting a charging session


2. Stopping of a session by charging station
3. Abnormal termination of a session by charging station
4. Stopping of a session by EV
5. Abnormal termination of a session by EV
6. Dynamic control

Since the messages for OCPP 1.6 differ from OCPP 2.0.1 we have added dedicated sequence diagrams for OCPP 1.6 after the
OCPP 2.0.1 diagrams.

If it is necessary to take legacy vehicles supporting only CHAdeMO version older than 1.1 into account, then the
following can be done: When the Charging Station receives a signal from the cable proximity detection at the start
of the charging session, then it can also use the cable proximity detection to verify when the EV leaves. In case
NOTE the CAN communications starts before a cable proximity detection signal is received, then the Charging Station
knows it should also not expect a cable proximity detection signal after the CAN communications ends. For the
Charging Station to be able to verify when the EV leaves a vendor-specific method could be used. An example
would be detecting that the cable is removed from/placed back into the holster.

© Open Charge Alliance & CHAdeMO Association 2020 10/25 Using OCPP with CHAdeMO
4.1. Sequence Diagrams for OCPP 2.0.1 and CHAdeMO
This section contains all sequence diagrams related to OCPP 2.0.1 in correspondence with CHAdeMO 1.1 and 2.0.1.

There is almost no difference between the message flows of CHAdeMO 1.1 and 2.0.1. Therefore no separate
NOTE
sequence diagrams were needed. Differences between the versions are marked by notes.

4.1.1. Start charging session


The sequence diagram below describes OCPP 2.0.1 and CHAdeMO message flows between the systems, when starting a charging
session.

EV Charging Station CSMS


EV Driver

State A (No vehicle connection)


plugin cable

plugin cable (If not fixed)

StatusNotificationRequest(status = Occupied, ...)

StatusNotificationResponse()

State B (Vehicle connection)


TransactionEventRequest(eventType = Started, triggerReason = CablePluggedIn,
chargingState = EVConnected, transactionId = AB1234, timestamp,
evse.id = 1, evse.connectorId = 1, ...)

TransactionEventResponse(...)

Authorize start

AuthorizeRequest(idToken(id = 1234))

AuthorizeResponse(idTokenInfo.status = Accepted, ...)

TransactionEventRequest(eventType = Updated, transactionId = AB1234,


triggerReason = Authorized, idToken.id = 1234, ...)

TransactionEventResponse(idTokenInfo.status = Accepted, ...)

"Charge sequence signal 1 = ON"

Start T-time 8.0s

State C (Information exchange before charging)

C-time <= 4.0s / T-time 6.0s

Vehicle CAN data( H'100: Minimum charge current, Minimum battery voltage, Maximum battery voltage, Charged rate constant value
H'101 = Maximum charging time, Estimated charging time, Total capacity of traction battery
H'102.(0/1/2/6) = CHAdeMO protocol number, Target battery voltage, State of charge)

C-time <= 0.5s / T-time 2.5s

Charger CAN data( H'108: Welding detection, Available output voltage, Available output current, Threshold voltage
H'109: CHAdeMO protocol number, Present output voltage, Present charging current, Remaining charging time)

opt
TransactionEventRequest(eventType = Updated, transactionId = AB1234,
timestamp, chargingState = SuspendedEV, triggerReason = ChargingStateChanged, ...)

TransactionEventResponse(...)

"Vehicle start charge permission" signal

C-time From (f)=ON <= 6.0s AND within 1.0s from Switch(k)=ON

End T-time 8.0s

Vehicle CAN data( H'102.5.0: Vehicle charging enabled = 1)

State D (Connector lock and insulation test)


opt
TransactionEventRequest(eventType = Updated, transactionId = AB1234,
timestamp, chargingState = SuspendedEVSE, triggerReason = ChargingStateChanged, ...)

TransactionEventResponse(...)

alt [if cable not permanently attached]


lock connector

C-time <= 20.0s / T-time 22.0s

"Charge sequence signal 2 = ON"

EV contactor = CLOSE

C-time <= 2.0s / T-time 4.0s

Vehicle CAN data( H'102.5.3: Vehicle status = 0)

Wait for 1.0s

start energy offer

State E (Charging)

C-time From (e) = ON <= 2.0s / T-time 4.0s

Vehicle CAN data( H'102.3: Charging current request > 0A,


H'102.6: State of Charge)

TransactionEventRequest(eventType = Updated, transactionId = AB1234,


timestamp, chargingState = Charging, triggerReason = ChargingStateChanged, meterValues, ...)

TransactionEventResponse(...)

C-time <= 0.5s / T-time 2.5s

Charger CAN data( H'109.5.0: Charger status = 1,


H'109.5.5: Charging stop control = 0

Figure 1. Sequence diagram: Start charging session

© Open Charge Alliance & CHAdeMO Association 2020 11/25 Using OCPP with CHAdeMO
4.1.2. Stop by Charging Station
The sequence diagram below describes OCPP 2.0.1 and CHAdeMO message flows between the systems, when the charging
station initiates a stop of the charging session.

EV Charging Station CSMS


EV Driver

State E (Charging)
Authorize stop

TransactionEventRequest(eventType = Updated, transactionId = AB1234,


triggerReason = StopAuthorized, idToken.id = 1234, ...)

TransactionEventResponse(idTokenInfo.status = Accepted, ...)

Charger CAN data( H'109.5.5: Charging stop control = 1)

Start C-time 2.0s (v1.1)

Start T-time 4.0s

State F (Termination of charging)


Stop energy offer

alt [Output current <= 5A]

C-time <= 2.5s / T-time 3.0s (v2.0.1)

Charger CAN data( H'109.5.0: Charger status = 0)

T-time From (Switch k) = OFF <= 2.5s (v1.1)

opt
TransactionEventRequest(eventType = Updated, transactionId = AB1234,
timestamp, chargingState = SuspendedEVSE, triggerReason = ChargingStateChanged, ...)

TransactionEventResponse(...)

C-time <= 0.5s (v2.0.1)

Start C-time 2.0s (v1.1)

End T-time 4.0s

"Vehicle stop charge permission" signal (Switch k) = OFF

State G (EV contactor welding detection)


Open contactor

C-time <= 4.0s / T-time 10.0s

Vehicle CAN data( H'102.5.3: Vehicle status = 1)

State H (Output voltage check)

C-time <= 0.5s / T-time 2.5s

"Charge sequence signal 2 = OFF"

Wait for 0.5s

C-time From (Switch d2) = OFF <= 1.0s / T-time 3.0s

"Charge sequence signal 1 = OFF"

Drop output voltage

alt [output voltage <= 10V]

C-time <= 2.0s / T-time 4.0s

Charger CAN data( H'109.5.2: Energizing state = 0)

Unlock connector (If not fixed)

State I (Termination of CAN communication)

C-time <= 0.5s / T-time 2.5s

End of Vehicle CAN data(H'100, H'101, H'102)

C-time <= 0.5s

End of Charger CAN data(H'108, H'109)

State B (Vehicle connection)


TransactionEventRequest(eventType = Updated, transactionId = AB1234,
triggerReason = ChargingStateChanged, chargingState = EVConnected, ...)

TransactionEventResponse(...)

Unplug cable (If not fixed)

Unplug cable

State A (No vehicle connection)


StatusNotificationRequest(status = Available)

StatusNotificationResponse()

TransactionEventRequest(eventType = Ended, transactionId = AB1234,


triggerReason = EVCommunicationLost, chargingState = Idle, stoppedReason = Local, ...)

TransactionEventResponse(...)

Figure 2. Sequence diagram: Stop by Charging Station

© Open Charge Alliance & CHAdeMO Association 2020 12/25 Using OCPP with CHAdeMO
4.1.3. Stop by Charging Station (abnormal)
The sequence diagram below describes OCPP 2.0.1 and CHAdeMO message flows between the systems, when the charging
station initiates an abnormal stop of the charging session.

An abnormal stop by a charging station can occur for example in case of; Ground fault, overcurrent fault, power
NOTE
loss, power quality, emergency stop, etc.

In case of a power failure, it might not be possible to send the OCPP messages at that time. In this case the
NOTE
TransactionEventRequest messages must be queued as described at the OCPP specification.

In case an error occurs prior to charging, the Charging Station will not necessarily send a
TransactionEventRequest with eventType = Ended. When using OCPP 2.0.1, this depends on the configured
NOTE TxStartPoint. As mentioned before, the sequence diagram examples shown use the EVConnected value for both
the TxStartPoint and TxStopPoint. This means that as long as the EV and EVSE are still connected, the Charging
Station will not send a TransactionEventRequest with eventType = Ended.

EV Charging Station CSMS


EV Driver

State E (Charging)
alt
Charger CAN data( H'109.5.1: Charger error = 1)

Charger CAN data( H'109.5.4: Charging system error = 1,


H'109.5.5: Charging stop control = 1,
H'108.0.0: Welding detection Identifier = 0 (v2.0.1))

State F (Termination of charging)


Stop energy offer

alt [Output current <= 5A]

T-time 2.5s

Charger CAN data( H'109.5.0: Charger status = 0)

TransactionEventRequest(eventType = Updated, transactionId = AB1234,


triggerReason = AbnormalCondition, chargingState = SuspendedEVSE, ...)

TransactionEventResponse(...)

Start T-time 2.5s

State H (Output voltage check)

C-time <= 0.5s

"Charge sequence signal 1 = OFF"

C-time <= 0.5s

Open contactor

Vehicle CAN data( H'102.5.3: Vehicle status = 1)

C-time From (Switch d2) = OFF <= 1.0s / T-time 3.0s

End T-time 2.5s

"Charge sequence signal 2 = OFF"

Drop output voltage

alt [output voltage <= 10V]

C-time <= 2.0s / T-time 4.0s

Charger CAN data( H'109.5.2: Energizing state = 0)

Unlock connector (If not fixed)

State I (Termination of CAN communication)

C-time <= 0.5s / T-time 2.5s

End of Vehicle CAN data(H'100, H'101, H'102)

C-time <= 0.5s

End of Charger CAN data(H'108, H'109)

State B (Vehicle connection)


Unplug cable (If not fixed)

Unplug cable

State A (No vehicle connection)


StatusNotificationRequest(status = Available)

StatusNotificationResponse()

TransactionEventRequest(eventType = Ended, transactionId = AB1234,


triggerReason = EVCommunicationLost, chargingState = Idle, StoppedReason = <See note>, ...)

Possible values for stoppedReason:


EmergencyStop,
GroundFault,
OvercurrentFault,
PowerLoss,
PowerQuality,
other

TransactionEventResponse(...)

Figure 3. Sequence diagram: Stop by Charging Station (abnormal)

© Open Charge Alliance & CHAdeMO Association 2020 13/25 Using OCPP with CHAdeMO
4.1.4. Stop by EV
The sequence diagram below describes OCPP 2.0.1 and CHAdeMO message flows between the systems, when the EV initiates a
stop of the charging session.

EV Charging Station CSMS


EV Driver

State E (Charging)
alt [EV disables charging]
Vehicle CAN data( H'102.5.0: Vehicle charging enabled = 0,
H'102.3: Charging current request = 0)
[Position of a shift lever other than in ‘parking’]
Vehicle CAN data( H'102.5.1: Vehicle shift position = 1,
H'102.3: Charging current request = 0)

C-time <= 0.5s / T-time 2.5s

TransactionEventRequest(eventType = Updated, transactionId = AB1234,


triggerReason = ChargingStateChanged, chargingState = SuspendedEV, ...)

TransactionEventResponse(...)

Charger CAN data( H'109.5.5: Charging stop control = 1)

Start C-time 2.0s (v1.1)

Start T-time 4.0s

State F (Termination of charging)


Stop energy offer

alt [Output current <= 5A]

C-time <= 2.5s / T-time 3.0s (v2.0.1)

Charger CAN data( H'109.5.0: Charger status = 0)

T-time From (Switch k) = OFF <= 2.5s (v1.1)

C-time <= 0.5s (v2.0.1)

Start C-time 2.0s (v1.1)

End T-time 4.0s

"Vehicle stop charge permission" signal (Switch k) = OFF

State G (EV contactor welding detection)


Open contactor

C-time <= 4.0s / T-time 10.0s

Vehicle CAN data( H'102.5.3: Vehicle status = 1)

State H (Output voltage check)

C-time <= 0.5s / T-time 2.5s

"Charge sequence signal 2 = OFF"

Wait for 0.5s

C-time From (Switch d2) = OFF <= 1.0s / T-time 3.0s

"Charge sequence signal 1 = OFF"

Drop output voltage

alt [output voltage <= 10V]

C-time <= 2.0s / T-time 4.0s

Charger CAN data( H'109.5.2: Energizing state = 0)

State I (Termination of CAN communication)

C-time <= 0.5s / T-time 2.5s

End of Vehicle CAN data(H'100, H'101, H'102)

C-time <= 0.5s

End of Charger CAN data(H'108, H'109)

State B (Vehicle connection)


Authorize stop/unlock connector (If not fixed)

TransactionEventRequest(eventType = Updated, transactionId = AB1234,


triggerReason = StopAuthorized, idToken.id = 1234, ...)

TransactionEventResponse(idTokenInfo.status = Accepted, ...)

Unlock connector (If not fixed)

TransactionEventRequest(eventType = Updated, transactionId = AB1234,


triggerReason = ChargingStateChanged, chargingState = EVConnected, ...)

TransactionEventResponse(...)

Unplug cable (If not fixed)

Unplug cable

State A (No vehicle connection)


StatusNotificationRequest(status = Available)

StatusNotificationResponse()

TransactionEventRequest(eventType = Ended, transactionId = AB1234,


triggerReason = EVCommunicationLost, chargingState = Idle, stoppedReason = StoppedByEV OR SOCLimitReached, ...)

TransactionEventResponse(...)

Figure 4. Sequence diagram: Stop by EV

© Open Charge Alliance & CHAdeMO Association 2020 14/25 Using OCPP with CHAdeMO
4.1.5. Stop by EV (abnormal)
The sequence diagram below describes OCPP 2.0.1 and CHAdeMO message flows between the systems, when the EV initiates an
abnormal stop of the charging session.

An abnormal stop by a EV can occur for example in case of; Battery overvoltage, battery undervoltage, battery
NOTE
current deviation, high battery temperature, battery voltage deviation, etc.

EV Charging Station CSMS


EV Driver

State E (Charging)
alt
Vehicle CAN data( H'102.4.X: Fault flag = 1)

A H'102.4 fault flag:


0 = Battery overvoltage,
1 = Battery undervoltage,
2 = Battery current deviation error,
3 = High battery temperature,
4 = Battery voltage deviation error

Vehicle CAN data( H'102.5.2: Charging system error = 1)

Vehicle CAN data( H'102.3: Charging current request = 0)

C-time <= 0.5s / T-time 2.5s

TransactionEventRequest(eventType = Updated, transactionId = AB1234,


triggerReason = AbnormalCondition, chargingState = SuspendedEV, ...)

TransactionEventResponse(...)

Charger CAN data( H'109.5.5: Charging stop control = 1)

State F (Termination of charging)


Stop energy offer

alt [Output current <= 5A]

T-time 2.5s

Charger CAN data( H'109.5.0: Charger status = 0)

State G (EV contactor welding detection)


Open contactor

C-time <= 4.0s / T-time 10.0s

Vehicle CAN data( H'102.5.3: Vehicle status = 1)

State H (Output voltage check)

C-time <= 0.5s / T-time 2.5s

"Charge sequence signal 2 = OFF"

Wait for 0.5s

C-time From (Switch d2) = OFF <= 1.0s / T-time 3.0s

"Charge sequence signal 1 = OFF"

Drop output voltage

alt [output voltage <= 10V]

C-time <= 2.0s / T-time 4.0s

Charger CAN data( H'109.5.2: Energizing state = 0)

State I (Termination of CAN communication)

C-time <= 0.5s / T-time 2.5s

End of Vehicle CAN data(H'100, H'101, H'102)

C-time <= 0.5s

End of Charger CAN data(H'108, H'109)

State B (Vehicle connection)


Authorize stop/unlock connector (If not fixed)

TransactionEventRequest(eventType = Updated, transactionId = AB1234,


triggerReason = StopAuthorized, idToken.id = 1234, ...)

TransactionEventResponse(idTokenInfo.status = Accepted, ...)

Unlock connector (If not fixed)

TransactionEventRequest(eventType = Updated, transactionId = AB1234,


triggerReason = ChargingStateChanged, chargingState = EVConnected, ...)

TransactionEventResponse(...)

Unplug cable (If not fixed)

Unplug cable

State A (No vehicle connection)


StatusNotificationRequest(status = Available)

StatusNotificationResponse()

TransactionEventRequest(eventType = Ended, transactionId = AB1234,


triggerReason = EVCommunicationLost, chargingState = Idle, stoppedReason = StoppedByEV, ...)

TransactionEventResponse(...)

Figure 5. Sequence diagram: Stop by EV (abnormal)

© Open Charge Alliance & CHAdeMO Association 2020 15/25 Using OCPP with CHAdeMO
4.1.6. Dynamic control
The sequence diagram below describes OCPP 2.0.1 and CHAdeMO message flows between the systems, when the CSMS provides
a charging profile to the charging station, to request a charging current change.

EV Charging Station CSMS


EV Driver

State C (Information exchange before charging)

C-time <= 4.0s / T-time 6.0s

Vehicle CAN data( H'100: Minimum charge current, Minimum battery voltage, Maximum battery voltage, Charged rate constant value
H'101: Maximum charging time, Estimated charging time, Total capacity of traction battery
H'102.(0/1/2/6): CHAdeMO protocol number, Target battery voltage, State of charge
Extended function:
H'110.0.0: Dynamic control = 1)

C-time <= 0.5s / T-time 2.5s

Charger CAN data( H'108: Welding detection, Available output voltage, Available output current, Threshold voltage
H'109: CHAdeMO protocol number, Present output voltage, Present charging current, Remaining charging time
Extended function:
H'118.0.0: Dynamic control = 1)

opt
TransactionEventRequest(eventType = Updated, transactionId = AB1234,
timestamp, chargingState = SuspendedEV, triggerReason = ChargingStateChanged, ...)

TransactionEventResponse(...)

"Vehicle start charge permission" signal

C-time From (f)=ON <= 6.0s AND within 1.0s from Switch(k)=ON

End T-time 8.0s

Vehicle CAN data( H'102.5.0: Vehicle charging enabled = 1)

State D (Connector lock and insulation test)


opt
TransactionEventRequest(eventType = Updated, transactionId = AB1234,
timestamp, chargingState = SuspendedEVSE, triggerReason = ChargingStateChanged, ...)

TransactionEventResponse(...)

alt [if cable not permanently attached]


lock connector

C-time <= 20.0s / T-time 22.0s

"Charge sequence signal 2 = ON"

EV contactor = CLOSE

C-time <= 2.0s / T-time 4.0s

Vehicle CAN data( H'102.5.3: Vehicle status = 0)

Wait for 1.0s

start energy offer

State E (Charging)

C-time From (e) = ON <= 2.0s / T-time 4.0s

Vehicle CAN data( H'102.3: Charging current request > 0A,


H'102.6: State of Charge)

TransactionEventRequest(eventType = Updated, transactionId = AB1234,


timestamp, chargingState = Charging, triggerReason = ChargingStateChanged, meterValues, ...)

TransactionEventResponse(...)

C-time <= 0.5s / T-time 2.5s

Charger CAN data( H'109.5.0: Charger status = 1,


H'109.5.5: Charging stop control = 0

SetChargingProfileRequest(chargingProfile)

SetChargingProfileResponse(status = Accepted)

Charger CAN data( H'108.3: Available output current)

Vehicle CAN data( H'102.3: Charging current request)

TransactionEventRequest(eventType = Updated, transactionId = AB1234,


timestamp, triggerReason = ChargingRateChanged, meterValues, ...)

TransactionEventResponse(...)

Charger CAN data( H'108.6.0: Permission to reset the maximum charging time = 1)

C-time <= 6s

Vehicle CAN data( H'101.1, H'101.2: Maximum charging time)

10s after H’118.6.0

Charger CAN data( H'109.6, H'109.7: Remaining charging time)

Figure 6. Sequence diagram: Dynamic control

© Open Charge Alliance & CHAdeMO Association 2020 16/25 Using OCPP with CHAdeMO
4.2. Sequence Diagrams for OCPP 1.6 and CHAdeMO
This section contains all sequence diagrams related to OCPP 1.6 in correspondence with CHAdeMO 1.1 and 2.0.1.

There is almost no difference between the message flows of CHAdeMO 1.1 and 2.0.1. Therefore no separate
NOTE
sequence diagrams were needed. Differences between the versions are marked by notes.

4.2.1. Start charging session


The sequence diagram below describes OCPP 1.6 and CHAdeMO message flows between the systems, when starting a charging
session.

EV Charging Station CSMS


EV Driver

State A (No vehicle connection)


plugin cable

plugin cable (If not fixed)

StatusNotification.req(status = Preparing, ...)

StatusNotification.conf()

State B (Vehicle connection)


Authorize start

Authorize.req(idTag = 1234)

Authorize.conf(idTagInfo.status = Accepted, ...)

"Charge sequence signal 1 = ON"

Start T-time 8.0s

State C (Information exchange before charging)

C-time <= 4.0s / T-time 6.0s

Vehicle CAN data( H'100: Minimum charge current, Minimum battery voltage, Maximum battery voltage, Charged rate constant value
H'101 = Maximum charging time, Estimated charging time, Total capacity of traction battery
H'102.(0/1/2/6) = CHAdeMO protocol number, Target battery voltage, State of charge)

C-time <= 0.5s / T-time 2.5s

Charger CAN data( H'108: Welding detection, Available output voltage, Available output current, Threshold voltage
H'109: CHAdeMO protocol number, Present output voltage, Present charging current, Remaining charging time)

opt
StatusNotification.req(status = SuspendedEV, ...)

StatusNotification.conf()

"Vehicle start charge permission" signal

C-time From (f)=ON <= 6.0s AND within 1.0s from Switch(k)=ON

End T-time 8.0s

Vehicle CAN data( H'102.5.0: Vehicle charging enabled = 1)

State D (Connector lock and insulation test)


opt
StatusNotification.req(status = SuspendedEVSE, ...)

StatusNotification.conf()

alt [if cable not permanently attached]


lock connector

C-time <= 20.0s / T-time 22.0s

"Charge sequence signal 2 = ON"

EV contactor = CLOSE

C-time <= 2.0s / T-time 4.0s

Vehicle CAN data( H'102.5.3: Vehicle status = 0)

Wait for 1.0s

start energy offer

State E (Charging)

C-time From (e) = ON <= 2.0s / T-time 4.0s

Vehicle CAN data( H'102.3: Charging current request > 0A,


H'102.6: State of Charge)

StatusNotification.req(status = Charging, ...)

StatusNotification.conf()

StartTransaction.req(idTag = 1234, connectorId = 1, timestamp, ...)

StartTransaction.conf(transactionId = AB1234, ...)

C-time <= 0.5s / T-time 2.5s

Charger CAN data( H'109.5.0: Charger status = 1,


H'109.5.5: Charging stop control = 0

Figure 7. Sequence diagram: Start charging session

© Open Charge Alliance & CHAdeMO Association 2020 17/25 Using OCPP with CHAdeMO
4.2.2. Stop by Charging Station
The sequence diagram below describes OCPP 1.6 and CHAdeMO message flows between the systems, when the charging station
initiates a stop of the charging session.

EV Charging Station CSMS


EV Driver

State E (Charging)
Authorize stop

Charger CAN data( H'109.5.5: Charging stop control = 1)

Start C-time 2.0s (v1.1)

Start T-time 4.0s

State F (Termination of charging)


Stop energy offer

alt [Output current <= 5A]

C-time <= 2.5s / T-time 3.0s (v2.0.1)

Charger CAN data( H'109.5.0: Charger status = 0)

T-time From (Switch k) = OFF <= 2.5s (v1.1)

opt
StatusNotification.req(status = SuspendedEVSE, ...)

StatusNotification.conf()

C-time <= 0.5s (v2.0.1)

Start C-time 2.0s (v1.1)

End T-time 4.0s

"Vehicle stop charge permission" signal (Switch k) = OFF

State G (EV contactor welding detection)


Open contactor

C-time <= 4.0s / T-time 10.0s

Vehicle CAN data( H'102.5.3: Vehicle status = 1)

State H (Output voltage check)

C-time <= 0.5s / T-time 2.5s

"Charge sequence signal 2 = OFF"

Wait for 0.5s

C-time From (Switch d2) = OFF <= 1.0s / T-time 3.0s

"Charge sequence signal 1 = OFF"

Drop output voltage

alt [output voltage <= 10V]

C-time <= 2.0s / T-time 4.0s

Charger CAN data( H'109.5.2: Energizing state = 0)

StopTransaction.req(transactionId = AB1234, idTag = 1234, reason = Local, timestamp, ...)

StopTransaction.conf(...)

StatusNotification.req(status = Finishing, ...)

StatusNotification.conf()

Unlock connector (If not fixed)

State I (Termination of CAN communication)

C-time <= 0.5s / T-time 2.5s

End of Vehicle CAN data(H'100, H'101, H'102)

C-time <= 0.5s

End of Charger CAN data(H'108, H'109)

State B (Vehicle connection)


Unplug cable (If not fixed)

Unplug cable

State A (No vehicle connection)


StatusNotification.req(status = Available, ...)

StatusNotification.conf()

Figure 8. Sequence diagram: Stop by Charging Station

© Open Charge Alliance & CHAdeMO Association 2020 18/25 Using OCPP with CHAdeMO
4.2.3. Stop by Charging Station (abnormal)
The sequence diagram below describes OCPP 1.6 and CHAdeMO message flows between the systems, when the charging station
initiates an abnormal stop of the charging session.

An abnormal stop by a charging station can occur for example in case of; Ground fault, overcurrent fault, power
NOTE
loss, power quality, emergency stop, etc.

In case of a power failure, it might not be possible to send the OCPP messages at that time. In this case the
NOTE
transaction-related OCPP messages must be queued as described at the OCPP specification.

In case an error occurs prior to charging, the Charging Station will only send a StopTransaction.req if it already
NOTE sent/queued a StartTransaction.req. The chance of this happening is low, because when using OCPP 1.6, the
transaction will always start during state E.

EV Charging Station CSMS


EV Driver

State E (Charging)
alt
Charger CAN data( H'109.5.1: Charger error = 1)

Charger CAN data( H'109.5.4: Charging system error = 1,


H'109.5.5: Charging stop control = 1,
H'108.0.0: Welding detection Identifier = 0 (v2.0.1))

State F (Termination of charging)


Stop energy offer

alt [Output current <= 5A]

T-time 2.5s

Charger CAN data( H'109.5.0: Charger status = 0)

StatusNotification.req(status = Faulted, errorCode = <See note>, ...)

Possible errorCodes that may cause the suspension of a transaction:


GroundFailure,
HighTemperature,
InternalError,
OverCurrentFailure
OverVoltage,
UnderVoltage,
OtherError

StatusNotification.conf()

Start T-time 2.5s

State H (Output voltage check)

C-time <= 0.5s

"Charge sequence signal 1 = OFF"

C-time <= 0.5s

Open contactor

Vehicle CAN data( H'102.5.3: Vehicle status = 1)

C-time From (Switch d2) = OFF <= 1.0s / T-time 3.0s

End T-time 2.5s

"Charge sequence signal 2 = OFF"

Drop output voltage

alt [output voltage <= 10V]

C-time <= 2.0s / T-time 4.0s

Charger CAN data( H'109.5.2: Energizing state = 0)

StopTransaction.req(transactionId = AB1234, idTag = 1234, reason = <See note>, timestamp, ...)

Possible values for reason:


PowerLoss,
EmergencyStop,
Other

StopTransaction.conf(...)

StatusNotification.req(status = Finishing, ...)

StatusNotification.conf()

Unlock connector (If not fixed)

State I (Termination of CAN communication)

C-time <= 0.5s / T-time 2.5s

End of Vehicle CAN data(H'100, H'101, H'102)

C-time <= 0.5s

End of Charger CAN data(H'108, H'109)

State B (Vehicle connection)


Unplug cable (If not fixed)

Unplug cable

State A (No vehicle connection)


StatusNotification.req(status = Available, ...)

StatusNotification.conf()

Figure 9. Sequence diagram: Stop by Charging Station (abnormal)

© Open Charge Alliance & CHAdeMO Association 2020 19/25 Using OCPP with CHAdeMO
4.2.4. Stop by EV
The sequence diagram below describes OCPP 1.6 and CHAdeMO message flows between the systems, when the EV initiates a
stop of the charging session.

EV Charging Station CSMS


EV Driver

State E (Charging)
alt [EV disables charging]
Vehicle CAN data( H'102.5.0: Vehicle charging enabled = 0,
H'102.3: Charging current request = 0)
[Position of a shift lever other than in ‘parking’]
Vehicle CAN data( H'102.5.1: Vehicle shift position = 1,
H'102.3: Charging current request = 0)

C-time <= 0.5s / T-time 2.5s

StatusNotification.req(status = SuspendedEV, ...)

StatusNotification.conf()

Charger CAN data( H'109.5.5: Charging stop control = 1)

Start C-time 2.0s (v1.1)

Start T-time 4.0s

State F (Termination of charging)


Stop energy offer

alt [Output current <= 5A]

C-time <= 2.5s / T-time 3.0s (v2.0.1)

Charger CAN data( H'109.5.0: Charger status = 0)

T-time From (Switch k) = OFF <= 2.5s (v1.1)

C-time <= 0.5s (v2.0.1)

Start C-time 2.0s (v1.1)

End T-time 4.0s

"Vehicle stop charge permission" signal (Switch k) = OFF

State G (EV contactor welding detection)


Open contactor

C-time <= 4.0s / T-time 10.0s

Vehicle CAN data( H'102.5.3: Vehicle status = 1)

State H (Output voltage check)

C-time <= 0.5s / T-time 2.5s

"Charge sequence signal 2 = OFF"

Wait for 0.5s

C-time From (Switch d2) = OFF <= 1.0s / T-time 3.0s

"Charge sequence signal 1 = OFF"

Drop output voltage

alt [output voltage <= 10V]

C-time <= 2.0s / T-time 4.0s

Charger CAN data( H'109.5.2: Energizing state = 0)

StopTransaction.req(transactionId = AB1234, idTag = 1234, timestamp, ...)

StopTransaction.conf(...)

StatusNotification.req(status = Finishing, ...)

StatusNotification.conf()

State I (Termination of CAN communication)

C-time <= 0.5s / T-time 2.5s

End of Vehicle CAN data(H'100, H'101, H'102)

C-time <= 0.5s

End of Charger CAN data(H'108, H'109)

State B (Vehicle connection)


Authorize stop/unlock connector (If not fixed)

Unlock connector (If not fixed)

Unplug cable (If not fixed)

Unplug cable

State A (No vehicle connection)


StatusNotification.req(status = Available, ...)

StatusNotification.conf()

Figure 10. Sequence diagram: Stop by EV

© Open Charge Alliance & CHAdeMO Association 2020 20/25 Using OCPP with CHAdeMO
4.2.5. Stop by EV (abnormal)
The sequence diagram below describes OCPP 1.6 and CHAdeMO message flows between the systems, when the EV initiates an
abnormal stop of the charging session.

An abnormal stop by a EV can occur for example in case of; Battery overvoltage, battery undervoltage, battery
NOTE
current deviation, high battery temperature, battery voltage deviation, etc.

EV Charging Station CSMS


EV Driver

State E (Charging)
alt
Vehicle CAN data( H'102.4.X: Fault flag = 1)

A H'102.4 fault flag:


0 = Battery overvoltage,
1 = Battery undervoltage,
2 = Battery current deviation error,
3 = High battery temperature,
4 = Battery voltage deviation error

Vehicle CAN data( H'102.5.2: Charging system error = 1)

Vehicle CAN data( H'102.3: Charging current request = 0)

C-time <= 0.5s / T-time 2.5s

StatusNotification.req(status = SuspendedEV / Faulted, ...)

StatusNotification.conf()

Charger CAN data( H'109.5.5: Charging stop control = 1)

State F (Termination of charging)


Stop energy offer

alt [Output current <= 5A]

T-time 2.5s

Charger CAN data( H'109.5.0: Charger status = 0)

State G (EV contactor welding detection)


Open contactor

C-time <= 4.0s / T-time 10.0s

Vehicle CAN data( H'102.5.3: Vehicle status = 1)

State H (Output voltage check)

C-time <= 0.5s / T-time 2.5s

"Charge sequence signal 2 = OFF"

Wait for 0.5s

C-time From (Switch d2) = OFF <= 1.0s / T-time 3.0s

"Charge sequence signal 1 = OFF"

Drop output voltage

alt [output voltage <= 10V]

C-time <= 2.0s / T-time 4.0s

Charger CAN data( H'109.5.2: Energizing state = 0)

StopTransaction.req(transactionId = AB1234, idTag = 1234, timestamp, ...)

StopTransaction.conf(...)

StatusNotification.req(status = Finishing, ...)

StatusNotification.conf()

State I (Termination of CAN communication)

C-time <= 0.5s / T-time 2.5s

End of Vehicle CAN data(H'100, H'101, H'102)

C-time <= 0.5s

End of Charger CAN data(H'108, H'109)

State B (Vehicle connection)


Authorize stop/unlock connector (If not fixed)

Unlock connector (If not fixed)

Unplug cable (If not fixed)

Unplug cable

State A (No vehicle connection)


StatusNotification.req(status = Available, ...)

StatusNotification.conf()

Figure 11. Sequence diagram: Stop by EV (abnormal)

© Open Charge Alliance & CHAdeMO Association 2020 21/25 Using OCPP with CHAdeMO
4.2.6. Dynamic control
The sequence diagram below describes OCPP 1.6 and CHAdeMO message flows between the systems, when the CSMS provides a
charging profile to the charging station, to request a charging current change.

EV Charging Station CSMS


EV Driver

State C (Information exchange before charging)

C-time <= 4.0s / T-time 6.0s

Vehicle CAN data( H'100: Minimum charge current, Minimum battery voltage, Maximum battery voltage, Charged rate constant value
H'101: Maximum charging time, Estimated charging time, Total capacity of traction battery
H'102.(0/1/2/6): CHAdeMO protocol number, Target battery voltage, State of charge
Extended function:
H'110.0.0: Dynamic control = 1)

C-time <= 0.5s / T-time 2.5s

Charger CAN data( H'108: Welding detection, Available output voltage, Available output current, Threshold voltage
H'109: CHAdeMO protocol number, Present output voltage, Present charging current, Remaining charging time
Extended function:
H'118.0.0: Dynamic control = 1)

opt
StatusNotification.req(status = SuspendedEV, ...)

StatusNotification.conf()

"Vehicle start charge permission" signal

C-time From (f)=ON <= 6.0s AND within 1.0s from Switch(k)=ON

End T-time 8.0s

Vehicle CAN data( H'102.5.0: Vehicle charging enabled = 1)

State D (Connector lock and insulation test)


opt
StatusNotification.req(status = SuspendedEVSE, ...)

StatusNotification.conf()

alt [if cable not permanently attached]


lock connector

C-time <= 20.0s / T-time 22.0s

"Charge sequence signal 2 = ON"

EV contactor = CLOSE

C-time <= 2.0s / T-time 4.0s

Vehicle CAN data( H'102.5.3: Vehicle status = 0)

Wait for 1.0s

start energy offer

State E (Charging)

C-time From (e) = ON <= 2.0s / T-time 4.0s

Vehicle CAN data( H'102.3: Charging current request > 0A,


H'102.6: State of Charge)

StatusNotification.req(status = Charging, ...)

StatusNotification.conf()

StartTransaction.req(idTag = 1234, connectorId = 1, timestamp, ...)

StartTransaction.conf(transactionId = AB1234, ...)

C-time <= 0.5s / T-time 2.5s

Charger CAN data( H'109.5.0: Charger status = 1,


H'109.5.5: Charging stop control = 0

SetChargingProfileRequest(chargingProfile)

SetChargingProfileResponse(status = Accepted)

Charger CAN data( H'108.3: Available output current)

Vehicle CAN data( H'102.3: Charging current request)

opt
StatusNotification.req(status = Charging, info = <Info regarding changed charging current>, ...)

StatusNotification.conf()

Charger CAN data( H'108.6.0: Permission to reset the maximum charging time = 1)

C-time <= 6s

Vehicle CAN data( H'101.1, H'101.2: Maximum charging time)

10s after H’118.6.0

Charger CAN data( H'109.6, H'109.7: Remaining charging time)

Figure 12. Sequence diagram: Dynamic control

© Open Charge Alliance & CHAdeMO Association 2020 22/25 Using OCPP with CHAdeMO
5. Showing CHAdeMO Data in OCPP Device Model
5.1. Quick Introduction to OCPP Device Model
OCPP has a feature that is available as of release 2.x, called the Device Model, through which a charging station can publish a list of
components which consist of associated variables with their values. The charging station management system can query these
variables and can install monitors to be notified whenever these values exceed a certain threshold or change more than a certain
amount. Most variables will be read-only, but some variables are writable, which means that the charging station management
system can change their value.

Figure 13. Device Model structure

A component can be part of the charging station as a whole, or it can be associated with a specific EVSE or connector. There are
components that are real physical components, such as an AcDcConverter (representing the AC-DC converter in a DC charging
station) and components that represent logical (software) components. These are called "controllers" in the device model. One
such example is the controller for OCPP communication of a charging station, which is named OCPPCommCtrlr. Typical variables
for an AcDcConverter are: DCCurrent, DCVoltage, Power and Temperature, which are operational values reported by the converter.
For an OCPPCommCtrlr there will be variables like: HeartbeatInterval, OfflineThreshold and ActiveNetworkProfile, which are basically
configuration parameters that can be set by the charging station management system to influence OCPP behaviour.

5.2. CHAdeMO Data in Device Model


If we want to represent data from the CHAdeMO controller in the device model, then the obvious choice is to introduce a
component CHAdeMOCtrlr. Whereas only one OCPPCommCtrlr exists for the whole charging station, a dedicated CHAdeMOCtrlr is
needed for every CHAdeMO connector in the station.

Some of the information reported by CHAdeMO is really CHAdeMO-specific, but lot of the data is generic charging data, such as
power, current, voltage and state of charge. Such data might also be reported by other charging protocols, like ISO 15118. It
therefore makes sense to extract all generic charging data about the connected vehicle into a generic component. We propose to
call this component: ConnectedEV.

5.2.1. What Can CHAdeMO Data Be Used For?


The following sections in this white paper describe the data that is coming from CHAdeMO and can be represented in OCPP. This
does not mean that every charging station will provide this information; that is up to the manufacturer. The information in existing
OCPP messages is sufficient to manage a charging session. It is not required to disclose this data in order to support charging or
smart charging.

Then why would a charging station management system be interested in these values? The information provided as part of
CHAdeMOCtrlr or ConnectedEV may be of interest for a couple or reasons:

1. For diagnostic purposes, e.g. to record the reason why the EV aborted charging;
2. For testing purposes, e.g. to check whether the EV really follows the supplied charging schedule;
3. For smart charging purposes, e.g. by using the information about battery capacity, the lowest acceptable current for
charging or the remaining charging time, a smart charging schedule can be tailored to match the vehicle. For instance, when
CSMS knows the value of the current below which the vehicle will stop charging (DCCurrent.minset), it can use this to set

© Open Charge Alliance & CHAdeMO Association 2020 23/25 Using OCPP with CHAdeMO
the value of minChargingRate in an OCPP Charging Profile.

The text below is part of a proposal to formally include ConnectedEV as a standardized component of the device
NOTE
model. It is awaiting approval of the OCPP Technical Working Group of the Open Charge Alliance.

5.3. CHAdeMOCtrlr Component


The following variables that are reported for a CHAdeMO connection, are considered to be CHAdeMO-specific and are published as
part of the CHAdeMOCtrlr component.

VARIABLE UNIT CORRESPONDING CHADEMO VALUE

CHAdeMOProtocolNumber integer CHAdeMO protocol number (H'102.0)

VehicleStatus boolean Vehicle status (H'102.5.3)

DynamicControl boolean Vehicle compatible with dynamic control (H'110.0.0)

5.4. ConnectedEV Component


Generic charging data is reported via the ConnectedEV component. It is not really a component of the charging station itself, but
represents the electrical vehicle that is connected to a connector of the charging station.

5.4.1. Power and Current Values


The power and current values provided by CHAdeMO can be used by a charging station management system for diagnostic
purposes or, for example, to verify that the charging station is correctly following limits that are given in a charging schedule.

VARIABLE UNIT CORRESPONDING CHADEMO VALUE

DCCurrent.minSet A Minimum charge current (H'100.0)

DCCurrent.target A Charging current request (H'102.3)

DCVoltage.minSet V Minimum battery voltage (H'100.2,3)

DCVoltage.maxSet V Maximum battery voltage (H'100.4,5)

DCVoltage.target V Target battery voltage (H'102.1,2)

5.4.2. Energy and State of Charge Values


The charging station management system can use the energy and state of charge values to provide information about the progress
of charging to a user via a smartphone app or the data can be used to optimize a smart charging algorithm.

VARIABLE UNIT CORRESPONDING CHADEMO VALUE

EnergyImport.maxSet Wh Total capacity of traction battery * 100 (H'101.5,6)

RemainingTimeFull.maxSet s Maximum charging time * 60 (H'101.2)

RemainingTimeFull.actual s Estimated charging time * 60 (H'101.3)

StateOfCharge.maxSet % Charged rate reference constant (H'100.6)

StateOfCharge.actual % State of charge (H'102.6)

5.4.3. Status Values


The charging state indicates error situations, that may cause charging to be suspended or stopped. This information is useful for
the charging station management system for diagnostic purposes.

VARIABLE UNIT CORRESPONDING CHADEMO VALUE

ChargingState.actual one or more of:

BatteryOvervoltage Battery overvoltage (H'102.4.0)

BatteryUndervoltage Battery undervoltage (H'102.4.1)

ChargingCurrentDeviation Battery current deviation (H'102.4.2)

BatteryTemperature High battery temperature (H'102.4.3)

VoltageDeviation Battery voltage deviation (H'102.4.4)

© Open Charge Alliance & CHAdeMO Association 2020 24/25 Using OCPP with CHAdeMO
VARIABLE UNIT CORRESPONDING CHADEMO VALUE

ChargingSystemError Charging system error (H'102.5.2)

VehicleShiftPosition Vehicle shift position (H'102.5.1)

VehicleChargingEnabled Vehicle charging enabled (H'102.5.0)

5.5. Implementation Feedback Welcome


When implementers of both OCPP and CHAdeMO want to explore disclosing information about the charging parameters of the EV
to the CSMS, they can do so using sections B2.2 "Configuring a Charging Station" and N2.2 "Configure Monitoring" from OCPP 2.0.1
"Part 2 - Specification" and the above-mentioned component and variable descriptions.

We encourage giving feedback on this new approach by joining the Open Charge Alliance and participating in the Open Charge
Alliance Technical Working Group.

© Open Charge Alliance & CHAdeMO Association 2020 25/25 Using OCPP with CHAdeMO

You might also like