OCPP 2.0 Specification - RC1 0.97 PDF

Open Charge Point Protocol 2.
0
Interface descripti on between Charge Poi nt and Central System

Document Version 2.0.0.97
Document Status RC1
Document Release Date 26-11-2013
Page 2 (198)
OCPP 2.0

copyright Open Charge Alliance 2010, 2011, 2012, 2013
All rights reserved. This document is protected by international copyright law and
may not be reprinted, reproduced, copied or utilized in whole or in part by any
means including electronic, mechanical, or other means without the prior written
consent of the Open Charge Alliance.
Page 3 (198)
OCPP 2.0
Introduction
With the publication of OCPP 2.0 Release Candidate 1 the size and scope of the
protocol specification has expanded significantly over OCPP 1.5. The new
functionality supporting pricing, smart charging, and monitoring and control
described in Sections 4.2-4.4 and Chapters 7-9 was introduced to meet some of the
requirements that are emerging in the EV charging market. The choices of what
features to include in v2.0 we were driven fundamentally by the Change Requests
that were filed against v1.5, but also involved judgment calls on relevance, priority,
design trade-offs, overall coherence, etc.
Weve done our best to manage the challenge of incorporating new features and
functionality while keeping the specification (and implementations) trim, fit, and
focused. One principle we followed was to retain the basic functionality of OCPP
1.2/1.5 in the core of OCPP 2.0, which can be implemented independently from
the new feature sets enabling more advanced operations.
Thus if simplicity is the dominant requirement, an implementation of the OCPP 2.0
Core especially using the new Websockets transport and JSON encoding might
be all thats needed. This would be a straightforward and relatively manageable
upgrade path from OCPP 1.5 that should deliver significant improvements in
efficiency (lower network overhead and operating costs) and interoperability
(different interpretations of SOAP usage can result in incompatibility), among other
benefits.
Other implementations might include one or more of the extensions to classic
OCPP that have been defined in the 2.0 specification. For example where
regulations require employers to charge fees for workplace charging, vendors may
need to implement the Pricing feature set so EV driving employees can be informed
of the cost of energy before charging their vehicle, and perhaps choose from
different pricing options. Where a site owner or grid operator has constraints on
available power, they may require vendors to implement the smart charging
function set, perhaps in addition to pricing. And network operators or service
providers with more sophisticated operational platforms (back office systems)
should be able to take advantage of the richer and more granular monitoring and
control capabilities that OCPP 2.0 provides.
This modular approach has several further benefits, including comprehensibility,
robustness, and the ability to evolve each of the feature sets independently as
pricing, smart charging, device health, payments, reservations, vehicle-to-X, and
other areas of technical and business focus take shape over time.
In the near term the Open Charge Alliance will be exploring how to articulate this
modular perspective in various ways, for example:
Page 4 (198)
OCPP 2.0
To organize OCPP Compliancy testing and formal certification
To develop OCPP device types and profiles, e.g.
Basic+RemoteManagement+Reservations
To align OCPP device profiles with market requirements and trends
To adopt OCPP to new charging technologies, e.g. DC Fast Charging,
Inductive Charging
This work will continue as we finalize the OCPP 2.0 specification and develop
associated compliancy and certification tools and processes. Consequently, future
Release Candidates or the Final Release of OCPP 2.0 may more deeply reflect the
modular structure that has been introduced in this RC1 specification.

Page 5 (198)
OCPP 2.0
Version History
Version Date Author Description
2.0.0.97 RC1 26.11.2013 Brendan McMahon
Franc Buve
Joost van Abeelen
Marco Pas
Patrick Rademakers
Robert de Leeuw
Release Candidate 1

Page 6 (198)
OCPP 2.0
Contents
Introduction ..................................................................................................... 3
Version History .................................................................................................. 5
Contents ......................................................................................................... 6
List of Figures ................................................................................................. 13
1 Contributors .......................................................................................... 14
2 Scope ................................................................................................... 15
3 Terminology and Conventions .................................................................. 16
3.1 Conventions .................................................................................... 16
3.2 Definitions & Abbreviations ............................................................... 16
3.3 JSON, a name changer ..................................................................... 17
3.4 References ...................................................................................... 18
4 Introduction ........................................................................................... 19
4.1 General views of operation ................................................................ 19
4.2 Pricing ............................................................................................ 22
4.3 Smart Charging ............................................................................... 22
4.4 The Device Model: Monitoring, Reporting, & Configuration Management . 22
4.5 Network topology in OCPP ................................................................. 24
4.6 Local authorisation ........................................................................... 27
4.7 Off-line behaviour ............................................................................ 29
4.8 GroupID ......................................................................................... 30
4.9 Reservations ................................................................................... 31
4.10 Vendor-specific data transfer ............................................................. 31
4.11 Time zones ..................................................................................... 32
4.12 Case sensitivity ............................................................................... 32
4.13 Transaction ID generation by Charge Point .......................................... 32
5 General operations initiated by Charge Point .............................................. 34
5.1 Authorize ........................................................................................ 34
5.2 Boot Notification .............................................................................. 35
5.3 Data Transfer .................................................................................. 36
5.4 Diagnostics Status Notification ........................................................... 37
Page 7 (198)
OCPP 2.0
5.5 Firmware Status Notification ............................................................. 37
5.6 Heartbeat ....................................................................................... 38
5.7 Meter Values ................................................................................... 39
5.8 Status Notification ........................................................................... 40
5.9 Transaction Started .......................................................................... 40
5.10 Transaction Stopped......................................................................... 42
6 General operations initiated by Central System .......................................... 43
6.1 Cancel Firmware Update ................................................................... 43
6.2 Cancel Reservation........................................................................... 44
6.3 Change Availability ........................................................................... 44
6.4 Change Configuration ....................................................................... 45
6.5 Clear Cache ..................................................................................... 46
6.6 Data Transfer .................................................................................. 47
6.7 Get Configuration ............................................................................. 47
6.8 Get Diagnostics ............................................................................... 48
6.9 Get Local List Version ....................................................................... 49
6.10 Request Start Transaction ................................................................. 50
6.11 Request Stop Transaction ................................................................. 51
6.12 Reserve Now ................................................................................... 51
6.13 Reset ............................................................................................. 53
6.14 Send Local List ................................................................................ 54
6.15 Unlock Connector ............................................................................. 55
6.16 Update Firmware ............................................................................. 56
7 Pricing .................................................................................................. 58
7.1 Introduction .................................................................................... 58
7.2 Pricing operations ............................................................................ 59
7.3 Offline behaviour of pricing ............................................................... 62
8 Smart charging ...................................................................................... 63
8.1 Introduction .................................................................................... 63
8.2 Use case Local smart charging ........................................................ 66
8.3 Use case Central smart charging ..................................................... 72
8.4 Smart Charging Operations ............................................................... 76
Page 8 (198)
OCPP 2.0
9 Device Model: Monitoring, Reporting, & Configuration Management .............. 83
9.1 Introduction .................................................................................... 83
9.2 The Charge Point Device Model .......................................................... 83
9.3 Notices: Reporting Events, State, & Configuration ................................ 85
9.4 Charge Point Events ......................................................................... 86
9.5 Transaction Related Events: TransactionStopped ................................. 87
9.6 Monitoring ...................................................................................... 87
9.7 Get State Report .............................................................................. 89
9.8 Set Configuration ............................................................................. 90
9.9 Discovering Supported Charge Point Configuration ............................... 90
9.10 Minimum Device Model Support Requirements ..................................... 91
10 Messages .............................................................................................. 92
10.1 Authorize ........................................................................................ 92
10.2 BootNotification ............................................................................... 92
10.3 CancelFirmwareUpdate ..................................................................... 93
10.4 CancelReservation ........................................................................... 94
10.5 ChangeAvailability ............................................................................ 94
10.6 ChangeConfiguration ........................................................................ 95
10.7 ClearCache ...................................................................................... 97
10.8 ClearChargingProfile ......................................................................... 97
10.9 DataTransfer ................................................................................... 98
10.10 DiagnosticsStatusNotification.......................................................... 99
10.11 FirmwareStatusNotification ............................................................ 99
10.12 GetConfiguration......................................................................... 100
10.13 GetCost ..................................................................................... 101
10.14 GetDiagnostics ........................................................................... 101
10.15 GetLocalListVersion ..................................................................... 102
10.16 GetMonitoring............................................................................. 103
10.17 GetStateReport ........................................................................... 104
10.18 Heartbeat .................................................................................. 105
10.19 MeterValues ............................................................................... 106
10.20 Notifications ............................................................................... 106
Page 9 (198)
OCPP 2.0
10.21 NotifyCentralChargingNeeds ......................................................... 107
10.22 NotifyEVChargingNeeds ............................................................... 108
10.23 NotifyEVChargingSchedule ........................................................... 109
10.24 RequestStartTransaction .............................................................. 110
10.25 RequestStopTransaction .............................................................. 110
10.26 ReserveNow ............................................................................... 111
10.27 Reset ........................................................................................ 112
10.28 SendLocalList ............................................................................. 113
10.29 SetChargingProfile ...................................................................... 114
10.30 SetConfiguration ......................................................................... 115
10.31 SetMonitoring ............................................................................. 116
10.32 SetPricing .................................................................................. 117
10.33 TransactionStarted ...................................................................... 117
10.34 TransactionStopped .................................................................... 120
10.35 UnlockConnector ......................................................................... 121
10.36 UpdateFirmware ......................................................................... 122
11 Types .................................................................................................. 124
11.1 AuthorisationData .......................................................................... 124
11.2 AuthorizationStatus ........................................................................ 124
11.3 AvailabilityStatus ........................................................................... 125
11.4 AvailabilityState ............................................................................. 125
11.5 AvailabilityType ............................................................................. 125
11.6 CancelFirmwareUpdateStatus .......................................................... 126
11.7 CancelReservationStatus................................................................. 126
11.8 ChargePointModel .......................................................................... 126
11.9 ChargePointSerialNumber ............................................................... 127
11.10 ChargePointVendor ..................................................................... 127
11.11 ChargingNeeds ........................................................................... 127
11.12 ClearCacheStatus ........................................................................ 129
11.13 ChargingProfile ........................................................................... 129
11.14 ChargingProfileKindType .............................................................. 132
11.15 ChargingProfilePurposeType ......................................................... 132
Page 10 (198)
OCPP 2.0
11.16 ChargeProtocol ........................................................................... 133
11.17 ChargingSchedule ....................................................................... 133
11.18 ChargingSchedulePeriod .............................................................. 134
11.19 Component ................................................................................ 135
11.20 ComponentName ........................................................................ 137
11.21 ConfigurationStatus .................................................................... 147
11.22 ConnectorType ........................................................................... 148
11.23 Consumption .............................................................................. 150
11.24 ComponentStatesCriterion ........................................................... 150
11.25 ComponentCriterion .................................................................... 150
11.26 Cost .......................................................................................... 151
11.27 DataTransferStatus ..................................................................... 152
11.28 DiagnosticsStatus ....................................................................... 153
11.29 Evse .......................................................................................... 153
11.30 FirmwareStatus .......................................................................... 154
11.31 FirmwareErrorCode ..................................................................... 154
11.32 GenericStatus ............................................................................. 154
11.33 IdTagInfo ................................................................................... 155
11.34 IdType ....................................................................................... 155
11.35 IdToken ..................................................................................... 156
11.36 Imsi .......................................................................................... 156
11.37 KeyValue ................................................................................... 156
11.38 LocalizedText ............................................................................. 157
11.39 Location ..................................................................................... 157
11.40 Measurand ................................................................................. 157
11.41 MeterValue................................................................................. 159
11.42 MonitoringBase ........................................................................... 160
11.43 MonitoringType ........................................................................... 160
11.44 Notice ....................................................................................... 161
11.45 ReadingContext .......................................................................... 162
11.46 PhaseRotation ............................................................................ 162
11.47 PriceScheme .............................................................................. 163
Page 11 (198)
OCPP 2.0
11.48 PricingUnit ................................................................................. 164
11.49 PowerType ................................................................................. 164
11.50 RecurrencyKindType .................................................................... 165
11.51 RegistrationStatus ...................................................................... 165
11.52 ReportingStatus .......................................................................... 165
11.53 ReservationStatus ....................................................................... 166
11.54 ResetStatus ............................................................................... 166
11.55 ResetType .................................................................................. 166
11.56 RequestedEnergyTransferEnum .................................................... 167
11.57 RequestStartStopStatus ............................................................... 167
11.58 SalesTariffTable .......................................................................... 167
11.59 SupplyPhases ............................................................................. 168
11.60 StateReportBase ......................................................................... 168
11.61 Tariff ......................................................................................... 169
11.62 TariffPeriod ................................................................................ 170
11.63 TransactionData ......................................................................... 170
11.64 TransactionId ............................................................................. 171
11.65 TriggerType ............................................................................... 171
11.66 UnitOfMeasure ............................................................................ 172
11.67 UnlockStatus .............................................................................. 172
11.68 UpdateStatus ............................................................................. 173
11.69 UpdateType................................................................................ 173
11.70 ValueFormat............................................................................... 173
11.71 ValBool ...................................................................................... 174
11.72 ValDec ....................................................................................... 174
11.73 ValInt ........................................................................................ 174
11.74 ValText ...................................................................................... 174
11.75 ValNull ...................................................................................... 175
11.76 ValueType .................................................................................. 175
11.77 ValueUnion ................................................................................ 175
11.78 VariableCriteria ........................................................................... 177
11.79 VariableCriterion ......................................................................... 178
Page 12 (198)
OCPP 2.0
11.80 Variable ..................................................................................... 178
11.81 VariableName ............................................................................. 180
Appendix A: Configuration Key/Value Pairs .................................................... 192
1. General Purpose ............................................................................... 192
2. Time & Daylight Saving ..................................................................... 195
3. Under Frequency Load Shedding ......................................................... 196
4. Pricing ............................................................................................. 197
5. Display ............................................................................................ 197
6. Deprecated ...................................................................................... 198

Page 13 (198)
OCPP 2.0
List of Figures
Figure 1 OCPP Scope .................................................................................... 15
Figure 2 Charging infrastructure .................................................................... 16
Figure 3 Example of starting and stopping a transaction ................................... 20
Figure 4 Example of a firmware upgrade ......................................................... 21
Figure 5 Local Proxy ..................................................................................... 26
Figure 6 Local Controller ............................................................................... 27
Figure 7 Local list updating ............................................................................ 29
Figure 8 Sample pricing schemes ................................................................... 59
Figure 9 Set pricing at Charge Point ............................................................... 60
Figure 10 Get cost during transaction ............................................................. 61
Figure 11 Final cost at end of transaction ........................................................ 62
Figure 12 Local Smart Charging topology ........................................................ 64
Figure 13 Central Smart Charging topology ..................................................... 65
Figure 14 Use Case Local Smart Charging ....................................................... 66
Figure 15 Presetting Local Group Limits .......................................................... 67
Figure 16 Local Smart Charging (PWM) ........................................................... 68
Figure 17 Local Smart Charging (15118) ......................................................... 70
Figure 18 RFID/Plug & Charge Authorization .................................................... 71
Figure 19 Use Case Central Smart Charging .................................................... 72
Figure 20 Central Smart Charging (15118) ...................................................... 74
Figure 21 Central Smart Charging (PWM) ........................................................ 75

Page 14 (198)
OCPP 2.0
1 Contributors
The following companies & people have contributed to the OCPP protocol.
Company
(in alphabetical order)
Name
ABB Joost van Abeelen
Alliander Auke Hoekstra, Frank Geerts
CGI Franc Buve
Chargepoint Joury De Reuver, Shantanu Kothavale
E-Laad Arjan Wargers, Klaas van Zuuren
ESB Brendan McMahon
Greenlots Craig Rodine
IHomer Patrick Rademakers, Marco Pas, Dennis Laumen, Robert de Leeuw
Keba AG Erich Pawlik
The New Motion Olger Warnier
Enexis Louis Dietvorst
Page 15 (198)
OCPP 2.0
2 Scope
This document defines the protocol used between a Charge Point and Central
System.
Although the core of OCPP is about the communication between Charge Point and
Central System, in some situations the protocol is also used to pass information on
behalf of systems that are strictly speaking out of scope. OCPP can also be used to
pass information on transactions and availability between the Central System and
other systems.
The specification does not specify how to implement or which technology to use;
this will be defined in the separate OCPP Implementation Guides.

Figure 1 OCPP Scope

Page 16 (198)
OCPP 2.0
3 Terminology and Conventions
3.1 Conventions
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT,
SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this
document are to be interpreted as described in [RFC2119].
All sections and appendixes, except Scope and Terminology and
Conventions, are normative, unless they are explicitly indicated to be
informative.
3.2 Definitions & Abbreviations
This section describes the terminology that is used throughout this document.
Figure 2 Charging infrastructure

Important: we describe the charging infrastructure on a logical level for
communication purposes. We do not wish to impose a mapping onto physical
hardware. This is a manufacturers choice. For example, the EVSE might be
integrated into a Charge Point and to look as just a part of that device, but it might
just as well have its own casing and live outside of the physical entity Charge Point.

Page 17 (198)
OCPP 2.0
Central System Centralized system that manages any number of charge points
remotely.
Pool A logical group of charge points. These charge points might be
at a common location or can be grouped for any other reason.
This term is only added as reservation for future usage. In the
current specification the concept of pool is not yet used.
Charge Point A logical container for one or more EVSE units.
Charging need The amount of energy that the EV requires until a specific
point in time and the technical parameters required for
charging.
Connector A Connector is an independently operated and managed
electrical outlet on an EVSE. This corresponds to a single
physical outlet.
CSO Charge Service Operator or charge point operator. It is the
party that operates a network of charge points and has
contracts with CSPs to allow their customers to use the
charging facilities.
DSO Distribution System Operator, an entity responsible for the
distribution of electric energy to consumers. It is responsible
for the voltage stability in the distribution grid (medium and
low voltage power grid).
EV Electric Vehicle
EVSE Electrical Vehicle Supply Equipment: is the logical unit in a
Charge Point that supplies electric energy via a Connector for
recharging. An EVSE can have one or multiple Connector(s).
FTP(S) File Transport Protocol (Secure)
HTTP(S) Hypertext Transport Protocol (Secure)
ICCID Integrated Circuit Card Identifier
ISO/IEC 15118 A suite of standards for communication between EV and EVSE,
which among other things describes the exchange of charging
schedules.
IMSI International Mobile Subscriber Identity
PDU Protocol Data Unit
Smart Charging Dynamically limiting the amount of power consumed by an EV
during the charging process in order to fit within a charging
schedule set by an EVSE or Central System
SSL Secure Socket Layer
TLS Transport Layer Security
URL Uniform Resource Locator

3.3 JSON, a name changer
As of now, there are two different flavours of OCPP; we already had the SOAP
based implementations but now we also offer the possibility to use the much more
compact JSON alternative. To avoid confusion in communication on the type of
Page 18 (198)
OCPP 2.0
implementation we recommend using the distinct extensions J and S to indicate
JSON or SOAP. In generic terms this would be OCPP-J for JSON and OCPP-S for
soap. Version specific terminology would be OCPP2.0J or OCPP1.2S. If no extension
is specified for OCPP 1.2 or 1.5 then a SOAP implementation must be assumed. As
of release 2.0 this can no longer be implicit and should always be made clear. If a
system supports both the JSON and SOAP variant it is considered good practice to
label this OCPP2.0JS i.s.o. just OCPP2.0.
For OCPP-J see: [OCPP_IMP_J], for OCPP-S see: [OCPP_IMP_S]
3.4 References
[15118] IEC, ISO/IEC 15118-2 Ed. 1.0: Road vehicles
Vehicle to grid communication interface Part 2:
Technical protocol description and Open Systems
Interconnection (OSI) layer requirements, Document
Identifier: 69/216/CDV

[OCPP_IMP_J] OCPP implementation guide JSON

[OCPP_IMP_S] OCPP implementation guide SOAP

[RFC2119] Key words for use in RFCs to Indicate Requirement
Levels. S. Bradner. March
1997.http://www.ietf.org/rfc/rfc2119.txt

Page 19 (198)
OCPP 2.0
4 Introduction
This document describes a standard open protocol for communication between
charge points and a central system.
Some basic concepts are explained in the sections below in this introductory
chapter. Chapter 5 and 6 describe the general operations supported by the protocol
that were also present in OCPP 1.5. Some of them have been updated or renamed
in OCPP 2.0. Entirely new in OCPP 2.0 are the concepts of pricing, smart charging
and the device model for event and status reporting. These are briefly introduced in
this chapter. Chapter 7 describes the operations that support the display of price
and cost information on a charge point. Chapter 8 is dedicated to the topic of smart
charging and IEC/ISO 15118 support. Chapter 9 explains the new event and status
reporting mechanism based on the device model.
The exact messages and their parameters are detailed in chapter 10 and data types
are described in chapter 11.
4.1 General views of operation
This section is informative.
The following figures describe the general views of the operations between Charge
Point and Central System for two cases:
1) a Charge Point requesting authentication of a card and sending charge
transaction status,
2) Central System requesting a Charge Point to update its firmware.
The arrow labels in the following figures indicate the PDUs exchanged during the
invocations of the operations. These PDUs are defined in detail in chapter 9.

Page 20 (198)
OCPP 2.0
Figure 3 Example of starting and stopping a transaction

When a Charge Point needs to charge an electric vehicle, it needs to authenticate
the user first before the charging can be started. If the user is authorized the
Charge Point informs the Central System that it has started with charging.
When charging is done and a user wishes to unplug the electric vehicle from the
Charge Point, the Charge Point needs to verify that the user is either the one that
initiated the charging or that the user is in the same group and thus allowed to
terminate the charging. Once authorized, the Charge Point informs the Central
System that the charging has been stopped.
sd Example of starting and stopping a transaction
Charge Poi nt Central System
Charging
Authori ze.req()
Authori ze.conf()
Transacti onStarted.req()
Transacti onStarted.conf()
Authori ze.req()
Authori ze.conf()
Transacti onStopped.rec()
Transacti onStopped.conf()
Page 21 (198)
OCPP 2.0
Figure 4 Example of a firmware upgrade

When a Charge Point needs to be updated with new firmware, then the Central
System informs at which time the Charge Point can start downloading the new
firmware. Once the Charge Point has downloaded and installed the firmware, it will
notify the Central System of the status for each step. Most likely the Charge Point
needs to reboot and if so, the Charge Point will sent a boot notification containing
the new information about the installed firmware.
sd Example of a firmware upgrade
Downloading firmware...
Installing...
Reboot
UpdateFi rmware.req()
UpdateFi rmware.conf()
Fi rmwareStatusNoti fi cati on.req(Downl oaded)
Fi rmwareStatusNoti fi cati on.conf()
Fi rmwareStatusNoti fi cati on.req(Instal l ed)
BootNoti fi cati on.req()
BootNoti fi cati on.conf()
Page 22 (198)
OCPP 2.0
4.2 Pricing
OCPP 2.0 includes features to show the price for charging on a display of a charge
point and to show the accumulated cost during charging. It also provides the
possibility to show multiple price schemes and let the user select the one to be
used for the transaction.
There are potentially many different pricing models, because of differences in
business models and legislation. It is an area that is still evolving. Rather than try
and create an all-encompassing model for pricing that will last forever, the strategy
of OCPP is to start small and grow as needed. The pricing concept introduced in
chapter 7 supports only basic usage-based cost calculation on the charge point,
thus limiting the complexity of the charge point and the amount of data to be
transferred. On the other hand, complex pricing models can be supported by the
central system and cost updates can be sent to the charge point during the
transaction. Multi-language display texts can be provided to explain the pricing and
any discounts or additional costs that are calculated by the central system, but
cannot be captured in the tariff structure that is sent to the charge point.
4.3 Smart Charging
Smart charging in OCPP refers to a controlled charging process where a charge
point or a central system or both can set constraints to the amount of power that is
delivered during the course of a charge transaction. It can be used at a local level
to 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 be used on a global level to adjust the
power consumption of charge points to match the power generation capability of
the grid or the availability of renewable energy sources.
In order to control the amount of power that an EV may draw from a charge point
some form of vehicle to grid communication is necessary. OCPP has been designed
to support the ISO/IEC 15118 standard [15118] for communication between vehicle
(EV) and charge point (EVSE). However, it is anticipated that for the coming years,
the majority of EVs will only support the Mode 3 PWM signal, so care has been
taken to support smart charging with PWM as well.
4.4 The Device Model: Monitoring, Reporting, & Configuration Management
OCPP 2.0 is extended with a new Device Model that represents a standardized
logical view of the many hardware and software Components that make up a
Page 23 (198)
OCPP 2.0
typical charge point. Depending on its nature, each Component can have a number
of Variable values that are used to represent and control significant aspects of its
behaviour, its current State, and to report significant Events.
A Central System can use the fine-grained Component & Variable addressing
capability of the Device Model to:
Discover all available information about the logical structure of a charge
point, allowing Plug & Play enrolment of new charge points, and
elimination of expensive, time-consuming and error prone manual data-
entry.

Obtain detailed information on the current state of a charge point by
requesting a report on any or all Component Variables

Receive notification reports with fine-grained detail about problem and
operational events that occur at a charge point

Obtain detailed information on which events and problem values a charge
point monitors and reports, and the parameters for such reporting (e.g.
access door opened, temperature limit X exceeded)

Change the monitoring configuration, to report just the events and problem
values of interest

Change the configuration of any Component of a charge point to enable,
disable, or modify its functionality.
Overall, this enables a Central System to monitor and control a Charge Point in a
structured way, and to more easily diagnose how the charge point is doing and
what has happened, when something goes wrong.
State and Event reporting helps to improve customer experience and lower
maintenance costs by providing better, more structured and standardized (near)
real-time diagnostics.
Used effectively, it can help to improve customer service and minimize operational
costs by pushing problems up the following hierarchy:
1) prevent problems from occurring by getting fair warning;
2) facilitate customer self-help when he/she still encounters problems;
3) solve problems remotely when self-help is not enough and
4) ultimately, send service personnel on site only if other lines of defense fail.
Page 24 (198)
OCPP 2.0
4.4.1 Monitoring & Reporting Example
Suppose the air intake of the cooling system of the AC to DC convertor of a DC fast-
charger is blocked by some leaves. The convertor quickly overheats once it gets used,
especially if the connected EV draws a lot of power and the weather is hot. This makes the
convertor shut itself down occasionally. We find out something is amiss when we are called
by an angry customer. However, after a while the convertor cools down and everything
works again. The next customer charges without problems because he has a smaller
battery that draws less power and because the weather has become less sunny. We
assume that the first customer did something wrong and move on. But a week later
another angry customer calls. We send an expensive technician on site, but he finds no
problems, and thinks it is probably another case of customer error. Then the first customer
returns and experiences the problem once again. Weve spend a lot of money and made a
lot of customers unhappy.
Enter Monitoring & Reporting based on the Device Model.
While talking to the customer on the phone we can see that the convertor reports a faulty
State because of overheating. Even though this is no help to the customer yet, we can at
least give him relevant information by assuring him that it is not a problem with the EV,
cable, authentication etc.
When we investigate further we can see that the alert condition has been reported earlier,
usually shortly after charging commences. Since it is very hot on the day the customer
calls we ask the Charge Point to report its internal temperature. (We can also ask the
customer to feel the temperature.) We find the Charge Point is indeed hot. Moreover, one
EVSE is hotter than the other. Now we have a pretty clear suspicion of what is going on.
We describe the location of the inlet to the customer and ask him or her if it is obstructed.
Both we and the customer are delighted when we find a clump of dry leaves stuck in the
inlet. The customer happily removes the leaves. When we call the customer back ten
minutes later we can see the temperature in the connector has gone down. The customer
has not waited for our call and is already charging. The result: we did not dispatch a costly
staff on-site and we actually made a customer happy.

See Chapter 9 Device Model: Monitoring, Reporting, & Configuration Management
for further details of the Device Model.
4.5 Network topology in OCPP
In OCPP each charge point communicates directly with the Central System. OCPP
has no knowledge of the topology of the charge point network. However, this does
not mean that it is not possible to create groups of charge points for local
communication or control purposes.
Page 25 (198)
OCPP 2.0
4.5.1 Local proxy
In some situations it is desirable to route all communications for a group of charge
points through a single network node (modem, router ). A typical example is the
situation where a number of a charge points are located in an underground parking
garage with little of no access to the mobile network. In order to provide access to
mobile data the charge points are linked to a central data communications unit over
a LAN. This central unit connects to the mobile network and acts as a proxy
between Central System and charge points. Such a unit is called a local proxy in
OCPP. A local proxy acts as a message router. The local proxy will replace the
internal IP address in the From field of messages originating from a charge point
by its own external IP address, such that the Central System will send the response
message back to the local proxy. When receiving a message from the Central
System, the local proxy will examine the ChargeBoxIdentity field in the message
and use that to forward the message to the appropriate charge point. Neither the
Central System nor the charge points are aware of the topology of the network. For
the charge points in the group the local proxy is the Central System. Similarly, for
the Central System the local proxy is the charge point.
The following diagrams illustrate this configuration.

Page 26 (198)
OCPP 2.0
Figure 5 Local Proxy

4.5.2 Local controller
Whereas a local proxy does little more than route OCPP messages, a local controller
can send messages to its charge points, independently of the Central System. A
typical usage for this is the local smart charging case described below, where a
local controller can impose charge limits on its charge points. In order for a local
controller to be addressed by the Central System, it needs to have a
ChargeBoxIdentity. From the point of view from OCPP, the local controller will just
be a charge point (without any connectors). The Central System will possess the
logic to deal with the local controller in order to support, for example, local smart
charging. It is up to the implementation of the Central System, whether the group
deployment Local Proxy
Local group
devi ce
CP01
devi ce
CP02
devi ce
CP03
Central System
IP 81.205.99.50 IP 192.168.2.1
IP 192.168.2.2
IP 192.168.2.3
Local Proxy
Local proxy is
a SOAP router.
IP 192.168.4
l an
l an
l an
mobi l e data
sd Sample communication flow local proxy
l ocal network
Central System Local Proxy
Charge Point CP01
IP 81.205.99.50 IP 192.168.2.1
IP 192.168.2.2 IP 81.205.99.0
1: OCPP.req(from 192.168.2.2, CP01) 1.1: OCPP.req(from 81.205.99.50, CP01)
1.2: OCPP.conf(to 81.205.99.50, CP01) 1.3: OCPP.conf(to192.168.2.2, CP01)
Page 27 (198)
OCPP 2.0
topology is manually configured or deduced from the network based on IP
addresses and information in BootNotifications.
The following diagrams illustrate this configuration. The first diagram shows the
topology. The second diagram shows the Central System sending a message (1) to
the local controller, the local controller sending another message (2) to the charge
point and the charge point sending a message (3) to the Central System, which is
passed through the local controller.
Figure 6 Local Controller

4.6 Local authorisation
deployment Local Controller
Local group
devi ce
CP01
devi ce
CP02
devi ce
CP03
Local Controller
CP00
Central System
IP 81.205.99.50
IP 192.168.2.2
IP 192.168.2.3
IP 192.168.4
IP 192.168.2.1
Local Controller
has its own
ChargeBoxIdentity
sd Sample communication flow local controller
l ocal network
Central System Charge Point CP01 Local Controller
CP00
IP 192.168.2.1 IP 81.205.99.50
IP 192.168.2.2 IP 81.205.99.0
1: OCPP.req(to 81.205.99.50, CP00)
1.1: OCPP.conf(from 81.205.99.50, CP00)
2: OCPP.req(to 192.168.2.2, CP01)
2.1: OCPP.conf(from 192.168.2.2, CP01)
3: OCPP.req(from 192.168.2.2, CP01) 3.1: OCPP.req(from 81.205.99.50, CP01)
3.2: OCPP.conf(to 81.205.99.50, CP01) 3.3: OCPP.conf(to 192.168.2.2, CP01)
Page 28 (198)
OCPP 2.0
There are two separate concepts for local authorisation: Caching and local lists.
Both mechanisms can be enabled or disabled separately.
Caching is the mechanism where the Charge Point builds up a cache list of
previously allowed idTags, with their expiration date. This is done for the sole
purpose of quicker response times for the EV driver. This list cannot be remotely
managed, only cleared through a ClearCache.req.
The local list is managed by the Central System, updating the list with full or
differential updates. This list can be cleared remotely by sending an empty local list.
An update of the local list doesn't implicitly clear the local cache. A Central System
might do this explicitly though.
On one hand a freshly sent local list should contain the most recent idTag
information from the Central System. However, over time, and by lack of updates
of the local list, the cache can contain more recent information than the local list. If
an idTag occurs both in the cache and the local list, the Charge Point should use the
most recent information.
Because the local list is managed remotely the Charge Point should not alter this
information directly with cache updates, since the cache could be cleared.
The local white list of OCPP version 1.2 that serves to cache previously authorized
id-tags has been extended to support the concept of a local authorisation list that
can be synchronized with the Central System. The local authorisation list is still
updated with the results of authorisation, start and stop requests, but in addition to
that it can be synchronised with the Central System to contain the authorisation
status of all tag-ids or a selection of tag-ids. If synchronisation is not used, the local
authorisation list will exhibit the same behaviour as the former local white list.
In order to support the above-mentioned off-line behaviour the Charge Point may
implement a local authorisation list that can cache authorized id-tags and can be
synchronised with the Central System. In response to an authorisation, start or
stop transaction request Central System will return group-id, expiry-date and an
authorisation status that Charge Point uses to update its local authorisation list.
This is the caching mechanism.
Additionally, the Central System can synchronise this list by either (1) sending a
complete list of id-tags to replace the local authorisation list or (2) by sending a list
of changes (add, update, delete) to apply to the local authorisation list. The new
operations to support this are Get Local List Version and Send Local List.
Page 29 (198)
OCPP 2.0
Figure 7 Local list updating

4.7 Off-line behaviour
This section is normative.
Data communication between Charge Point and Central System will in most cases
be done by means of wireless communication (e.g. GPRS, UMTS). In the event of
unavailability of the communications or even of the Central System, the Charge
Point is designed to operate stand-alone. In that situation a Charge Point MAY
authorise identifiers using its local authorisation list, which exists of a cache of
sd Example of a full update
SendLocal Li st.req(234, Authori sati onData, Ful l )
SendLocal Li st.req(Accepted)
sd Example of a differential update
GetLocal Li stVersi on.req()
GetLocal Li stVersi on.conf(234)
SendLocal Li st.req(239, Authori sati onData, Di fferenti al )
SendLocal Li st.req(Accepted)
Page 30 (198)
OCPP 2.0
previously accepted identifiers and/or a centrally managed local list of identifiers
that are allowed access.
When offline the Charge Point MUST queue any messages that need to be sent to
the Central System and transmit these messages in chronological order as soon as
the connection to the Central System is restored. In such cases the Central System
will not be aware that these are queued messages (other than by inference given
that the various timestamps are significantly in the past) it will process these
messages as any other.
In the event that a Charge Point has restored the connection with the Central
System and is busy sending all messages in the queue, the sending of new
transaction-related messages SHALL wait until the queue has been emptied. This is
to ensure that transaction-related messages SHALL always be sent in chronological
order. Transaction-related messages are those messages that contain a transaction
id in the request or response message.
It is therefore allowed to send, for example, an Authorize request or a Notifications
request before the offline queue has been emptied, such that customers are not
kept waiting and urgent notifications are not delayed.
4.8 GroupID
Note: In previous versions of OCPP, this concept was known as Parent id tag. As
the simple IdToken element previously in OCPP is now a complex type that can
contain identifiers other than RFID card UIDs in a well-defined way, the
parentIdTag name was no longer accurate or useful, and has been changed to
better reflect its purpose, to avoid possible implementation errors, and to reflect
best implementation practice.
Central System has the ability to treat a set of identity tokens as a group, thereby
allowing any one token in the group to start a transaction and the same or another
token in the same group to stop the transaction. This is convenient for families or
businesses with multiple drivers using one or more shared electric vehicles on a
single recharging contract account.
Tokens are grouped by specifying a common group identifier in the optional
GroupId element. Two ID-Tokens are considered to be in the same group if their
GroupIds match.
Note that the value of the GroupID is never itself used as a TokenID for group
membership checking purposes, even if it has the form of a ID-Token.
Page 31 (198)
OCPP 2.0
In OCPP 2.0, a token group identifier can be any of the supported variant data-
types of the idToken data-type, such as a common shared account number (e.g.
with an IdType of Central1).
In previous OCPP versions, the GroupId was named parentIdTag, and was of the
same (untyped string) datatype as IdToken, and so usually held an actual RFID tag
UID.
However, in practice, the use of an actual Token-ID of one of the tokens in a group
is not convenient, since the (arbitrarily chosen) Token-ID for the GroupID role
might subsequently be lost, stolen, or faulty, but would still need to be maintained
in the Central System for as long as the Group exists.
4.9 Reservations
Reservation of a charge point is possible using the Reserve Now operation. This
operation reserves the charge point until a certain expiry time for a specific id-tag.
A group id-tag may be included in the reservation to support group reservations. It
is possible to reserve a specific EVSE on a charge point or to reserve any connector
on a charge point. A reservation is released when the reserved id-tag is used on the
reserved connector (when specified) or on any connector (when unspecified) or
when the expiry time is reached or when the reservation is explicitly cancelled.
4.10 Vendor-specific data transfer
The mechanism of vendor-specific data transfer allows for the exchange of data or
messages not standardized in OCPP. As such, it offers a framework within OCPP for
experimental functionality that may find its way into future OCPP versions.
Experimenting can be done without creating new (possibly incompatible) OCPP
dialects. Secondly, it offers a possibility to implement additional functionality
agreed upon between specific Central System and Charge Point vendors.
The operation Vendor Specific Data can be initiated either by the Central System or
by the Charge Point.
IMPORTANT: Use this with extreme caution and only for optional functionality,
because it will impact your compatibility with other systems that do not make use
of this option. We recommend mentioning the usage explicitly in your
documentation and/or communication. Please consider submitting a change request
before turning to this option to add functionality.
Page 32 (198)
OCPP 2.0
4.11 Time zones
To improve interoperability between Central Systems and Charge Points all time
values SHOULD be exchanged as UTC, with the time zone designator Z, as
specified by ISO 8601.
For the purpose of displaying local time on a charge points display the following
configuration keys are provided:
TimeZoneOffset
StartDst
EndDst
4.12 Case sensitivity
All strings in messages and enumerations are case sensitive, unless explicitly stated
otherwise. String elements that are case insensitive will be of type CiString.
4.13 Transaction ID generation by Charge Point
In previous versions of OCPP, transaction identifiers were always determined by the
Central System. This identifier is returned to the Charge Point as part of the
TransactionStarted.conf PDU, as shown below.

As of OCPP 2.0 the Charge Point MAY generate a transaction identifier. This
identifier is sent to the Central System as part of the TransactionStarted.req
message, in the optional element transaction identifier. If used, the Charge Point
SHALL generate a unique transaction id for every transaction on the Charge Point.
sd Start Transaction with central tx-id
Central System Charge Poi nt
Transacti onStarted.req(evse, i d-tag)
Transacti onStarted.conf(status, central tx-i d)
Page 33 (198)
OCPP 2.0
Since the transaction identifier MUST be unique within the charge point network,
the Charge Point SHOULD either use a universally unique identifier (UUID) for this
or provide another method to create a unique identifier, e.g. by prefixing a locally
created transaction id with the unique identity of the Charge Point and the charge
point operator to prevent duplicates.
The transaction id SHALL be of type TransactionIdString to contain the string
representation of the locally generated unique identifier.
The Central System SHALL use this transaction identifier for the transaction and
SHALL use this value for the mandatory transactionId element of
TransactionStarted.conf PDU, as shown below:

sd Start Transaction with local tx-id
Transacti onStarted.req(evse, i d-tag, cp tx-i d)
Transacti onStarted.conf(status, cp tx-i d)
Page 34 (198)
OCPP 2.0
5 General operations initiated by Charge Point
5.1 Authorize

Before the owner of an electric vehicle can start or stop charging, the Charge Point
needs to be able to authorize the operation. Only after authorisation will the Charge
Point unlock the connector.
Note: If the identifier for stopping the transaction is identical to the identifier with
which the transaction was started, then the Charge Point SHALL stop the
transaction without authorising the identifier centrally or in the local list.
A Charge Point MAY cache previously authorized identifiers in the local authorisation
list and MAY use these to authorize a user. If the identifier is not present in the
local authorisation list, then the Charge Point SHALL send a Authorize.req PDU to
the Central System for requesting authorisation. If the identifier is present in the
local authorisation list, then the Charge Point MAY omit the sending of an
authorisation request to the Central System and use the authorisation value of the
local authorisation list instead.
Upon receipt of an Authorize.req PDU, the Central System SHALL respond with an
Authorize.conf PDU. This response PDU SHALL indicate, whether or not the id-tag is
accepted by the Central System. The response PDU MUST include an authorisation
status value indicating acceptance or a reason for rejection and MAY include a
group-id-tag.
sd Authorize
authori zati on.req()
authori zati on.conf()
Page 35 (198)
OCPP 2.0
5.2 Boot Notification

After start-up a Charge Point sends a notification to the Central System with
information about its configuration (e.g. version, vendor, etc.). The Central System
will only accept Charge Points that are registered with the Central System.
The Charge Point SHALL send a BootNotification.req PDU each time it (re-)boots.
Upon receipt of a BootNotification.req PDU, the Central System SHALL respond with
a BootNotification.conf. The response PDU SHALL indicate whether the Central
System accepts the Charge Point. When the Central System is willing to accept the
Charge Point, then the response PDU SHALL contain the Central Systems current
time and heartbeat interval.
Upon receipt of a BootNotification.conf PDU, the Charge Point SHALL keep sending
a BootNotification.req PDU when the Central System doesnt accept it. The Charge
Point SHOULD use an acceptable interval for resending a BootNotification.req PDU,
to avoid flooding the Central System.
The Charge Point SHALL NOT send any other request other than
BootNotification.req until the Central System accepts the Charge Point.
sd Boot Notification
BootNoti fi cati on.req()
BootNoti fi cati on.conf()
Page 36 (198)
OCPP 2.0
5.3 Data Transfer

If a Charge Point needs to send information to the Central System for a function not
supported by OCPP, it SHALL use the DataTransfer.req PDU.
The vendorId in the request SHOULD be known to the Central System and uniquely
identify the vendor-specific implementation. The VendorId SHOULD be a value from
the reversed DNS namespace, where the top tiers of the name, when reversed,
should correspond to the publicly registered primary DNS name of the Vendor
organisation.
Optionally, the messageId in the request PDU MAY be used to indicate a specific
message or implementation.
The length of data in both the request and response PDU is undefined and should
be agreed upon by all parties involved.
If the recipient of the request has no implementation for the specific vendorId it
SHALL return a status UnknownVendor and the data element SHALL not be
present. In case of a messageId mismatch (if used) the recipient SHALL return
status UnknownMessageId. In all other cases the usage of status Accepted or
Rejected and the data element is part of the vendor-specific agreement between
the parties involved.
sd Data Transfer
DataTransfer.req()
DataTransfer.conf()
Page 37 (198)
OCPP 2.0
5.4 Diagnostics Status Notification

Charge Point sends a notification to inform the Central System when a diagnostics
upload has finished. The Charge Point SHALL send a
DiagnosticsStatusNotifcation.req PDU to inform the Central System that the upload
of diagnostics has finished successfully or failed.
Upon receipt of a DiagnosticsStatusNotifcation.req PDU, the Central System SHALL
respond with a DiagnosticsStatusNotifcation.conf.
5.5 Firmware Status Notification

A Charge Point sends notifications to inform the Central System about the progress
of the firmware update. The Charge Point SHALL send a
sd Diagnostics Status Notification
Di agnosti csStatusNoti fi cati on.req()
Di agnosti csStatusNoti fi cati on.conf()
sd Firmware Status Notification
Fi rmwareStatusNoti fi cati on.req()
Page 38 (198)
OCPP 2.0
FirmwareStatusNotifcation.req PDU for informing the Central System about the
progress of the installation of a firmware update.
Upon receipt of a FirmwareStatusNotifcation.req PDU, the Central System SHALL
respond with a FirmwareStatusNotification.conf.
5.6 Heartbeat

To let the Central System know that a Charge Point is still connected, a Charge
Point sends a heartbeat after a configurable time interval.
The Charge Point SHALL send a Heartbeat.req PDU for ensuring that the Central
System knows that a Charge Point is still alive.
Upon receipt of a Heartbeat.req PDU, the Central System SHALL respond with a
Heartbeat.conf. The response PDU SHALL contain the current time of the Central
System, which could be used by the Charge Point to synchronize its internal clock.
The Charge Point MAY skip sending a Heartbeat.req PDU when another PDU has
been sent to the Central System within the configured heartbeat interval. This
implies that a Central System SHOULD assume availability of a Charge Point
whenever a PDU has been received, the same way as it would have, when it
received a Heartbeat.req PDU.
Note: The reader should check the implementation guides on implementation
specific details for the Heartbeat implementation.
sd Heartbeat
Heartbeat.req()
Heartbeat.conf()
Page 39 (198)
OCPP 2.0
5.7 Meter Values

A Charge Point MAY sample the electricity meter or other sensor/transducer
hardware to provide extra information about its meter values. In that case the
Charge Point SHALL use a MeterValues.req PDU to upload meter values.
If meter values are related to a transaction, e.g. to indicate charging progress
during a transaction, then the transaction id SHALL be included in the
MeterValues.req. A Charge Point SHALL NOT send any MeterValues.req PDUs with a
transaction id after the related transaction has stopped.
If meter values need to be sent to the Central System for billing purposes, then the
TransactionData element of the TransactionStopped.req PDU SHALL be used for
that purpose.
A MeterValues.req contains one or more values elements, of type MeterValue (see
below), each representing a set of one or more data values taken at a particular
point in time.
Each values element contains a timestamp and a set of one or more individual
value elements, all captured at the same point in time. Each value element
contains a single value datum. The nature of each value is determined by the
optional measurand, context, location, unit, and format attributes.
The optional measurand attribute specifies the type of value being
measured/reported.
The optional context attribute specifies the reason/event triggering the reading.
sd Meter Values
MeterVal ues.req()
MeterVal ues.conf()
Page 40 (198)
OCPP 2.0
The optional location attribute specifies where the measurement is taken (e.g.
Inlet, connector).
The EXPERIMENTAL optional format attribute specifies whether the data is
represented in the normal (default) form as a simple numeric value (Raw), or as
SignedData, an opaque digitally signed binary data block, represented as hex
data. This experimental attribute may be deprecated and subsequently removed in
later versions, when a more mature solution alternative is provided.
To retain backward compatibility, the default values of all of the optional attributes
on a value element are such that a value without any attributes will be
interpreted, as heretofore, as a register reading of active import energy in Wh
(Watt-hour) units.
Upon receipt of a MeterValues.req PDU, the Central System SHALL respond with a
MeterValues.conf.
The MeterValues.req PDU is a transaction-related message. In an offline situation
the Charge Point SHALL queue messages that need to be sent to the Central
System and SHALL transmit transaction-related messages in chronological order as
soon as the connection to the Central System is restored.
5.8 Status Notification
This has been replaced by State & Event Reporting.
5.9 Transaction Started

sd Transaction Started
Transacti onStarted.req()
Transacti onStarted.conf()
Page 41 (198)
OCPP 2.0
The Charge Point SHALL send a TransactionStarted.req PDU to the Central System
to inform it about the start of a charging transaction. If this transaction ends a
reservation (see Reserve Now operation), then the TransactionStarted.req MUST
contain the reservationId.
The Central System MUST verify validity of the transaction for its own purposes,
because the identifier might have been authorized locally by the Charge Point using
an out-of-date white list. The identifier, for instance, may have been blocked since
it was added to the local white list.
Upon receipt of a TransactionStarted.req PDU, the Central System SHALL respond
with a TransactionStarted.conf PDU. This response PDU MUST include a transaction
id and an authorisation status value.
Upon receipt of a TransactionStarted.conf PDU with an authorisation status value
other than Accepted and if the transaction matching the transaction identifier is
still in progress, the charge point MUST stop the transaction immediately and send
the appropriate request as specified in Transaction Stopped.
Note: If the transaction to which the TransactionStarted.conf PDU refers, occurred
in the past while the Charge Point was offline, then there will be no active
transaction matching transaction-id and there is no need to stop the transaction,
because it has already stopped.
If Charge Point has implemented a local authorisation list, then upon receipt of a
TransactionStarted.conf PDU the Charge Point SHALL update the local list entry with
the IdTagInfo value from the response. An authorisation status value of
ConcurrentTx SHALL be replaced by Accepted in the local authorisation list.
In an offline situation the Charge Point SHALL queue messages that need to be sent
to the Central System and SHALL transmit transaction-related messages in
chronological order as soon as the connection to the Central System is restored.

Page 42 (198)
OCPP 2.0
5.10 Transaction Stopped

The Charge Point SHALL send a TransactionStopped.req PDU when a transaction is
stopped. A transaction MUST be stopped explicitly by the Charge Point.
Upon receipt of a TransactionStopped.req PDU, the Central System SHALL respond
with a TransactionStopped.conf PDU. The Central System SHALL always stop the
transaction.
A TransactionStopped.req PDU MAY contain an optional TransactionData element
to provide more detail about transaction usage. The optional TransactionData
element is a container for any number of values (MeterValue datatype) sub-
elements, using the same data structure as the values elements of the
MeterValues.req PDU (See 10.19)
If Charge Point has implemented a local authorisation list, then upon receipt of a
TransactionStopped.conf PDU the Charge Point SHALL update the local list entry
with the IdTagInfo value from the response. An authorisation status value of
ConcurrentTx SHALL be replaced by Accepted in the local authorisation list.
The id-tag in the request PDU MAY be omitted when the Charge Point itself needs to
stop the transaction, for instance, when the Charge Point is requested to reset.
In an offline situation the Charge Point SHALL queue messages that need to be sent
to the Central System and SHALL transmit transaction-related messages in
chronological order as soon as the connection to the Central System is restored.

sd Transaction Stopped
Transacti onStopped.req()
Transacti onStopped.conf()
Page 43 (198)
OCPP 2.0
6 General operations initiated by Central System
6.1 Cancel Firmware Update

If a firmware update request (FirmwareUpdate.req PDU) has been previously sent
to a Charge Point and has not been fully processed, the Central System can request
a Charge Point to cancel a firmware update.
Upon receipt of a CancelFirmwareUpdate.req PDU, the Charge Point SHALL respond
with a CancelFirmwareUpdate.conf PDU. The response PDU SHALL indicate whether
the charge point was able to cancel the firmware update.
Cancel firmware update is not meant for roll-back to previously installed firmware.
Therefore, the Charge Point cannot and SHALL not cancel a firmware update which
has already been installed. Roll-back of firmware to a previous version can only be
achieved by another firmware update.
It is not possible to distinguish between the situation where a firmware update has
already been installed or where a firmware update request was not sent. In both
cases there is no firmware update request pending in the Charge Point.
The Central System can verify the firmware version by using the Device Model.

sd CancelFirmwareUpdate
Cancel Fi rmwareUpdate.req()
Cancel Fi rmwareUpdate.conf()
Page 44 (198)
OCPP 2.0
6.2 Cancel Reservation

To cancel a reservation the Central System SHALL send a CancelReservation.req
PDU to the Charge Point.
If the Charge Point has a reservation matching the reservationId in the request
PDU, it SHALL return status Accepted. Otherwise it SHALL return Rejected.
6.3 Change Availability

sd Cancel Reservation
Cancel Reservati on.req()
Cancel Reservati on.conf()
sd Change Availability
ChangeAvai l abi l i ty.req()
ChangeAvai l abi l i ty.conf()
Page 45 (198)
OCPP 2.0
Central System can request a Charge Point to change its availability. A Charge Point
is considered available (operative) when it is charging or ready for charging. A
Charge Point is considered unavailable when it does not allow any charging. The
Central System SHALL send a ChangeAvailability.req PDU for requesting a Charge
Point to change its availability. The Central System can change the availability to
available or unavailable.
Upon receipt of a ChangeAvailability.req PDU, the Charge Point SHALL respond with
a ChangeAvailability.conf PDU. The response PDU SHALL indicate whether the
Charge Point is able to change to the requested availability or not. When a
transaction is in progress Charge Point SHALL respond with availability status
'Scheduled' to indicate that it is scheduled to occur after the transaction has
finished.
In the event that Central System requests Charge Point to change to a status it is
already in, Charge Point SHALL respond with availability status Accepted.
6.4 Change Configuration

Central System can request a Charge Point to change configuration parameters. To
achieve this, Central System SHALL send a ChangeConfiguration.req. This request
contains a key-value pair, where "key" is the name of the configuration setting to
change and "value" contains the new setting for the configuration setting.
Upon receipt of a ChangeConfiguration.req Charge Point SHALL reply with a
ChangeConfiguration.conf indicating whether it was able to executed the change.
Content of "key" and "value" is not prescribed. If "key" does not correspond to a
configuration setting supported by Charge Point, it SHALL reply with a status
sd Change Configuration
ChangeConfi gurati on.req()
ChangeConfi gurati on.conf()
Page 46 (198)
OCPP 2.0
NotSupported. Otherwise it SHALL indicate success or failure with status Accepted
or Rejected respectively.
6.5 Clear Cache

Central System can request a Charge Point to clear its cache. For instance a Charge
Point may cache previously authorized cards.
The Central System SHALL send a ClearCache.req PDU for clearing the Charge
Points cache list. Charge Point SHALL clear the local cache, but it SHALL NOT clear
the local list, because that is managed by the SendLocalList message.
Upon receipt of a ClearCache.req PDU, the Charge Point SHALL respond with a
ClearCache.conf PDU. The response PDU SHALL indicate whether the Charge Point
was able to clear its cache.

sd Clear Cache
Cl earCache.req()
Cl earCache.conf()
Page 47 (198)
OCPP 2.0
6.6 Data Transfer

If the Central System needs to send information to a Charge Point for a function not
supported by OCPP, it SHALL use the DataTransfer.req PDU.
Behaviour of this operation is identical to the Data Transfer operation initiated by
the Charge Point. See 5.3 Data Transfer for details.
6.7 Get Configuration

sd Data Transfer
DataTransfer.req()
DataTransfer.conf()
sd Get Configuration
GetConfi gurati on.req()
GetConfi gurati on.conf()
Page 48 (198)
OCPP 2.0
To retrieve the value of configuration settings, the Central System SHALL send a
GetConfiguration.req PDU to the Charge Point.
If the list of keys in the request PDU is empty or missing (it is optional), the Charge
Point SHALL return a list of all configuration settings in GetConfiguration.conf.
Otherwise Charge Point SHALL return a list of recognized keys and their
corresponding values and read-only state. Unrecognized keys will be placed in the
response PDU as part of the optional unknown key list element of
GetConfiguration.conf.
6.8 Get Diagnostics

Central System can request a Charge Point for diagnostic information.The Central
System SHALL send a GetDiagnostics.req PDU for getting diagnostic information of
a Charge Point with a location where the Charge Point MUST upload its diagnostic
data to and optionally a begin and end time for the requested diagnostic
information.
Upon receipt of a GetDiagnostics.req PDU, and if diagnostics information is available
then Charge Point SHALL respond with a GetDiagnostics.conf PDU stating the name
of the file containing the diagnostic information that will be uploaded. Charge Point
SHALL upload a single file, optionally compressed. Format of the diagnostics file is
not prescribed. If no diagnostics file is available, then GetDiagnostics.conf SHALL
not contain a file name.
sd Get Diagnostics
GetDi agnosti cs.req()
GetDi agnosti cs.conf()
Page 49 (198)
OCPP 2.0
6.9 Get Local List Version

In order to support synchronisation of the local authorisation list, Central System
can request a Charge Point for the version number of the local authorisation list.
The Central System SHALL send a GetLocalListVersion.req PDU to request this
value.
Upon receipt of a GetLocalListVersion.req PDU, the Charge Point SHALL respond
with a GetLocalListVersion.conf PDU containing the version number of its local
authorisation list. By convention, a version number of 0 (zero) is used to indicate
that the local authorisation list is empty, and a version number of -1 is used to
indicate that the Charge Point does not support local authorisation lists.
sd Get Local List Version
GetLocal Li stVersi on.req()
GetLocal Li stVersi on.conf()
Page 50 (198)
OCPP 2.0
6.10 Request Start Transaction

Central System can request a Charge Point to start a transaction by sending a
RequestStartTransaction.req. Upon receipt Charge Point SHALL reply with
RequestStartTransaction.conf and a status indicating whether it is able to start a
transaction or not.
The RequestStartTransaction.req SHALL contain an identifier (IdTag), which Charge
Point SHALL use, if it is able to start a transaction, to send a TransactionStarted.req
to Central System. The transaction is started in the same way as described in Start
Transaction. The RequestStartTransaction.req MAY contain an Evse id if the
transaction is to be started on a specific connector.
Note: In effect the RequestStartTransaction.req remotely presents an IdTag to the
Charge Point.
sd RequestStartTransaction
RequestStartTransacti on.req()
RequestStartTransacti on.conf()
Page 51 (198)
OCPP 2.0
6.11 Request Stop Transaction

Central System can request a Charge Point to stop a transaction by sending a
RequestStopTransaction.req to Charge Point with the identifier of the transaction.
Charge Point SHALL reply with RequestStopTransaction.conf to indicate whether it
is indeed able to stop the transaction. The process of stopping a transaction SHALL
be as described in Transaction Stopped.
6.12 Reserve Now

sd RequestStartTransaction
RequestStartTransacti on.req()
RequestStartTransacti on.conf()
sd Reserve Now
ReserveNow.req()
ReserveNow.conf()
Page 52 (198)
OCPP 2.0
Central System can issue a Reserve Now command to a Charge Point to reserve a
EVSE for use by a specific id-tag. This can be a specific EVSE or any EVSE on the
Charge Point.
To request a reservation the Central System SHALL send a ReserveNow.req PDU to
a Charge Point. The Central System MAY specify a specific connector to be
reserved. Upon receipt of a ReserveNow.req PDU, the Charge Point SHALL respond
with a ReserveNow.conf PDU.
If the reservationId in the request matches a reservation in the Charge Point, then
the Charge Point SHALL replace that reservation with the new reservation in the
request and SHALL return the status value Accepted.
If the reservationId does not match any reservation in the Charge Point, then the
Charge Point SHALL return the status value Accepted if it succeeds in reserving a
connector. The Charge Point SHALL return Occupied if the Charge Point or the
specified connector are occupied. The Charge Point SHALL also return Occupied
when the Charge Point or connector has been reserved for the same or another id-
tag. The Charge Point SHALL return Faulted if the Charge Point or the connector is
in the Faulted state. The Charge Point SHALL return Unavailable if the Charge
Point or connector are in the Unavailable state. The Charge Point SHALL return
Rejected if it is configured not to accept reservations.
If the Charge Point accepts the reservation request, then it SHALL refuse charging
for all incoming id-tags on the reserved connector, except when the incoming id-tag
or the group id-tag match the id-tag or group id-tag of the reservation. If the
connectorId in the reservation request is 0, then the Charge Point SHALL NOT
reserve a specific connector, but SHALL make sure that at any time during the
validity of the reservation, one connector remains available for the reserved id-tag.
If the group id-tag in the reservation has a value (it is optional), then in order to
determine the group id-tag that is associated with an incoming id-tag, the Charge
Point MAY look it up in its local cache. If it is not found in the local cache, then the
Charge Point SHALL send an Authorize.req for the incoming id-tag to the Central
System. The Authorize.conf response contains the group-id.
A reservation will be terminated on the Charge Point when either (1) a transaction
is started for the reserved id-tag or group id-tag and on the reserved connector or
any connector when the reserved connectorId is 0, or (2) when the time specified in
expiryDate is reached, or (3) when the Charge Point or connector are set to Faulted
or Unavailable.
If a transaction for the reserved id-tag is started, then Charge Point SHALL send the
reservationId in the TransactionStarted.req PDU (see Start Transaction) to notify
the Central System that the reservation is terminated.
Page 53 (198)
OCPP 2.0
When a reservation expires, the Charge Point SHALL terminate the reservation and
make the connector available. Charge Point MAY send a status notification to notify
the Central System that the reserved connector is now available. This is not
obligatory, because the Central System knows when reservations are due to expire.
6.13 Reset

Central System SHALL send a Reset.req PDU for requesting a Charge Point to reset
itself. The Central System can request a hard or a soft reset. Upon receipt of a
Reset.req PDU, the Charge Point SHALL respond with a Reset.conf PDU. The
response PDU SHALL indicate whether the Charge Point is willing to reset itself.
Soft Reset = Application Reset
Hard Reset = System Reset
At receipt of a soft reset, Charge Point SHALL return to its basic idle state. If any
transaction is in progress it SHALL immediately be terminated normally, as in Stop
Transaction. The Charge Point SHALL NOT perform a reboot unless it is unable to
return to its idle state without doing so.
At receipt of a hard reset Charge Point SHALL immediately attempt to terminate
any transaction in progress normally as in Transaction Stopped and then perform a
reboot.
sd Reset
Reset.req()
Reset.conf()
Page 54 (198)
OCPP 2.0
6.14 Send Local List

Central System can send a local authorisation list that a Charge Point can use for
authorisation of id-tags. The list can be either a full list to replace the current list in
the Charge Point or it can be a differential list with updates to be applied to the
current list in the Charge Point.
The Central System SHALL send a SendLocalList.req PDU to send the list to a
Charge Point. The SendLocalList.req PDU SHALL contain the type of update (full or
differential) and the version number that the Charge Point MUST associate with the
local authorisation list after it has been updated.
Upon receipt of an SendLocalList.req PDU, the Charge Point SHALL respond with a
SendLocalList.conf PDU. The response PDU SHALL indicate whether the Charge
Point has accepted the update of the local authorisation list. If the status is Failed
or VersionMismatch and the updateType was Differential, then Central System
SHOULD retry sending the full local authorisation list with updateType Full.
Both the SendLocalList.re q and SendLocalList.conf PDUs have an optional element
hash , that MAY be used to verify proper receipt of the list by Charge Point and
Central System. The computation method of the hash value is not defined in this
version of the specification, but may become subject to standardisation in the
future. The presence of this hash element is not intended to require or encourage
users of this OCPP version to implement any vendor or deployment specific hashing
scheme, other than those who may be participating in pilot implementations of a
proposed standardized canonical data hashing algorithm for possible inclusion in a
future version release of OCPP.
sd Send Local List
SendLocal Li st.req()
SendLocal Li st.conf()
Page 55 (198)
OCPP 2.0
6.15 Unlock Connector

Central System can unlock a connector of a Charge Point. The Central System
SHALL send an UnlockConnector.req PDU for requesting a Charge Point to unlock
one of its connector.
Upon receipt of an UnlockConnector.req PDU, the Charge Point SHALL respond with
a UnlockConnector.conf PDU. The response PDU SHALL indicate whether the Charge
Point was able to unlock its connector.
If there was a transaction in progress on the specific connector, then Charge Point
SHALL immediately finish the transaction as described in Transaction Stopped.
sd Unlock Connector
Unl ockConnector.req()
Unl ockConnector.conf()
Page 56 (198)
OCPP 2.0
6.16 Update Firmware

Central System can notify a Charge Point that it needs to update its firmware. The
Central System SHALL send an UpdateFirmware.req PDU to inform the Charge Point
about the availability of new firmware. The PDU SHALL contain a date and time
after which the Charge Point is allowed to retrieve the new firmware and the
location from which the firmware can be downloaded. Optionally the
UpdateFirmware.req PDU MAY contain an install-date indicating the date/time that
the Charge Point should install its firmware. This enables a 2 phased installation:
retrieve firmware on specified date/time or after
install firmware on specified date/time or after
Depending on the implementation of the Charge Point, retrieval and installation of
new firmware may be disruptive to an on-going transaction. The Charge Point is
allowed to postpone the actual retrieval and installation to a point in time where it
can do so without interrupting a transaction in progress.
If the install / retrieve date/time are in the past, the Charge Point shall perform the
firmware update immediately.
Upon receipt of an UpdateFirmware.req PDU, the Charge Point SHALL respond with
a UpdateFirmware.conf PDU. The Charge Point SHOULD start retrieving the
firmware as soon as possible after retrieve-date. If an install-date is specified, then
the Charge Point SHOULD perform the installation of the new firmware as soon as
possible after the date and time of install-date, else the installation SHOULD be
performed as soon as possible after retrieving it.
sd Update Firmware
UpdateFi rmware.req()
UpdateFi rmware.conf()
Page 57 (198)
OCPP 2.0
If an earlier firmware update request is present in the Charge Point, waiting for
retrieval or installation, then Charge Point SHALL replace this request by the new
request. A firmware update MAY be cancelled as described in Cancel Firmware
Update.
Page 58 (198)
OCPP 2.0
7 Pricing
7.1 Introduction
From a user perspective three stages related to price information need be
supported:
A. Before charging: Pricing information upfront of a charge session
B. During charging: Cost information during a charge session
C. After charging: Total cost information after a charge session

These three stages can be found in all day-to-day consumer related payment
transactions.
To explain the concept, the example of a gas station is the closest related:
A. Providing the cost for a unit (x euro per litre).
B. Providing the costs while fuelling (y litre, x euro per litre) (running costs = y
litre * x euro)
C. Providing the costs after a charge session
The applicable stages depend on the pricing concept the operator is using and on
national or local legislation. OCPP supports the information exchange for the three
mentioned situations.
The pricing concept of OCPP is designed to be light-weight on the Charge Point and
still provide flexible pricing options. Cost calculation is performed on the Central
System, so that the Charge Point is not burdened by complicated pricing issues, like
discounts and peak/off-peak hours.
The Central System provides pricing information to a Charge Point as one or more
price schemes that may contain multiple tariffs, for example a price per unit for
charging and price for parking. Multi-language display texts can be provided to
Page 59 (198)
OCPP 2.0
explain the pricing and any discounts or additional costs that cannot be captured in
the simple tariff structure of a price scheme.
Real-time consumption costs can be calculated on the Charge Point for display
purposes, if desired, but the actual costs will be calculated during the transaction
on the Central System. The Charge Point can periodically request the Central
System to provide the current actual costs, so that it does not have to calculate the
cost itself. In case of variable rates or peak/off-peak hours requesting intermediate
cost values from the Central System is the only option, because the Charge Point
cannot calculate it from the information in the price scheme.
When multiple price schemes are offered, there should be a facility for the user to
select one. This selection will be communicated back to the Central System as a
parameter in the TransactionStarted message.
As an example, Figure 8 shows a configuration with two pricing schemes with
different energy prices, but sharing a common parking fee.
Figure 8 Sample pricing schemes

The Charge Point may store price schemes locally to make sure they are available
in an offline situation
7.2 Pricing operations
obj ect Sample pricing schemes
Regular charging :PriceScheme
tags
di spl ayText = Regul ar ful l power chargi ng at max 11 kW
i ncl udi ng parki ng fee
pri ceSchemeId = 1
Energy tariff :Tariff
tags
currency = EUR
di spl ayText = Energy pri ce
pri ceNet = 0.22
pri ci ngUni t = kWhToEV
tari ffId = 1
Parking tariff :Tariff
tags
currency = EUR
di spl ayText = Parki ng fee
pri ceNet = 2.00
pri ci ngUni t = OccupancyHours
tari ffId = 10
Smart charging :PriceScheme
tags
di spl ayText = Chargi ng for a l ower pri ce wi th a vari abl e
amount of power dependi ng on avai l abi l i ty i n the network,
i ncl udi ng parki ng fee
pri ceSchemeId = 2
Energy tariff :Tariff
tags
currency = EUR
di spl ayText = Energy pri ce at vari abl e power
pri ceNet = 0.10
pri ci ngUni t = kWhToEV
tari ffId = 2
Page 60 (198)
OCPP 2.0
7.2.1 Set pricing at charge point

Figure 9 Set pricing at Charge Point

To set pricing information at a Charge Point the Central System SHALL send the
SetPricing.req message. If the business concept requires that price schemes are
specific to the user, then the price schemes applicable to the user MAY be provided
by the Central System as part of the Authorize.conf response message. In that case
the user-specific price schemes SHALL overrule the existing price schemes in the
Charge Point.
The price schemes set a tariff per connector and multiple tariffs are supported so
that a user can select a desired tariff.
If pricing schemes have been sent to a Charge Point, then the default price scheme
(in case of one scheme) or the selected price scheme (in case of multiple schemes)
SHALL be communicated back to the Central System as a value of the field
sd Set Pricing
User
alt User-specific pricing
[Usi ng user-speci fi c pri ce schemes]
[Usi ng generi c pri ce schemes]
Generic price schemes can be set in advance.
These can be stored for offline use.
SetPri ci ng(pri ceSchemes)
SetPri ci ng.conf()
present i d-tag()
Authori ze.req(i d-tag)
Authori ze.conf(OK, pri ceSchemes)
Authori ze.conf(OK)
di spl ay pri ci ng()
Page 61 (198)
OCPP 2.0
priceSchemeId as part of the TransactionStarted.req message. If the
TransactionStarted.req message contains a priceSchemeId, then the Central
System SHALL perform real-time cost calculation during the transaction. Otherwise,
the Central System MAY perform real-time cost calculation, but not necessarily,
because the Central System in that case SHOULD NOT to provide the actual cost in
response to GetCost.req messages, and it SHOULD NOT return final costs in the
TransactionStopped.conf message.
7.2.2 Get cost during transaction
Figure 10 Get cost during transaction

A Charge Point MAY calculate the cost of a running transaction locally, using the
unit price information in the price scheme. Alternatively, a Charge Point MAY
request the current cost from the Central System. To do so a Charge Point SHALL
send a GetCost.req PDU to the Central System.
If the TransactionStarted.req PDU contained a priceSchemeId, then the Central
System SHALL respond with a GetCost.conf PDU containing the actual consumption
in units and the actual cost in money. Otherwise, the Central System SHALL return
an empty GetCost.conf message to denote that no intermediate cost value is
available.
This information MUST NOT be used for invoicing as they are intermediate values.
The final cost is communicated in the TransactionStopped.conf PDU.

sd Cost calculation on CS
User
A transaction is in progress...
GetCost.req(tx-i d)
cal cul ate cost()
GetCost.conf(CostVal ue)
di spl ay i ntermedi ate cost()
Page 62 (198)
OCPP 2.0
7.2.3 Final cost at end of transaction

Figure 11 Final cost at end of transaction

If the TransactionStarted.req PDU contained a priceSchemeId , then after the
charge transaction the Central System SHALL calculate the total cost and return
this information as part of the TransactionStopped.conf PDU to the Charge Point,
which can use it to display the total transaction cost.
7.3 Offline behaviour of pricing
If the Charge Point is offline at the start of a transaction it can only display pricing
schemes that have been stored locally in the Charge Point. Because it is unknown
how long a Charge Point may be offline, the pricing scheme information has an
expiry date to prevent the use of pricing schemes that are no longer valid.
User-specific pricing schemes that might be returned in response to an
authorization request are not available either.
When offline, the Charge Point cannot request intermediate cost values from the
Central System.
sd Cost calculation on CS at end
User
A transaction is in
stopped...
When transaction has ended, final cost is
returned in TransactionStopped.conf.
Transacti onStopped.req(tx-i d)
cal cul ate fi nal cost()
Transacti onStopped.conf(OK, fi nal Cost)
di spl ay fi nal cost()
Page 63 (198)
OCPP 2.0
8 Smart charging
8.1 Introduction
There may be many different uses for smart charging. Two typical kinds of smart
charging, which are referred to as local and central smart charging, will be used
here to illustrate the behaviour of smart charging.
Key to local smart charging is, that the charging schedules are controlled locally
and do not involve the Central System. The use case for local smart charging is
about limiting the amount of power that can be used by a group of charge points,
to a certain maximum. A typical use would be a number of charge points in a
parking garage where the rating of the connection to the grid is less than the sum
the ratings of the charge points. Another application might be that the local
controller receives information about the availability of power from a DSO or a local
smart grid node.
In the case of central smart charging the constraints to the charging schedule are
determined by the Central System. The Central System uses these schedules to
stay within limits imposed by any external system.

Page 64 (198)
OCPP 2.0
8.1.1 Local smart charging
Figure 12 Local Smart Charging topology

Local smart charging assumes the existence of a local controller to control a group
of charge points. The local controller is a logical component. It may be implemented
either as a separate physical component or as part of a master charge point
controlling a number of other charge points.
In the case of local smart charging the local controller imposes charging limits to a
charge point. These limits may be changed dynamically during the charging process
in order to keep the power consumption of the group of charge points within the
group limits. The group limits may be preconfigured in the local controller or may
have been configured by the Central System.

deployment Local SC
devi ce
CP01
devi ce
CP02
devi ce
CP03
Local Controller
CP00
Central System
Local Controller limits
power usage of total
group to pre-configured
maximum capacity.
EV
EV 2
Local group
OCPP OCPP
i so/i ec 15118
fl ow
chargi ng profi l e
chargi ng needs & chargi ng profi l e
mode 3
fl ow
Max
capaci ty
profi l e
Page 65 (198)
OCPP 2.0
8.1.2 Central smart charging
Figure 13 Central Smart Charging topology

Central smart charging assumes that charge limits are controlled by the Central
System. The Central System receives a capacity forecast from the grid operator
(DSO) or another source in one form or another and calculates charging schedules
for some or all charging transactions, details of which are out of scope of this
specification.

deployment Central SC
devi ce
CP13
devi ce
CP11
devi ce
CP10
Central System
EV
EV 2
CS receives a capacity
forecast from an external
party (e.g. DSO).
OCPP
mode 3
fl ow
chargi ng profi l e
chargi ng need & chargi ng profi l e
i so/i ec 15118
fl ow
Page 66 (198)
OCPP 2.0
8.2 Use case Local smart charging
Figure 14 Use Case Local Smart Charging

In the use case for local smart charging, the Local Controller sets charging limits for
charge points in the local group. In the simplest case these can be fixed maximum
values. In a more advanced case these limits can be adjusted depending on the
number of active transactions. The Local Controller may have a fixed power budget
that it has to distribute among the charge points in the group or it may receive
charging limits from the Central System.
The following diagram illustrates the sequence of message to preset charging limits
for a local group. These limits can either be preconfigured in the local controller in
one way or another, or they can be set by the Central System. The Central System
sets the limits for the local controller and the local controller contains the logic to
distribute this capacity among the connected EVSEs by adjusting their limits as
needed.

uc Local Smart Charging
User
EV
Local Smart Charging
EVSE :EVSE
CSO Central System :
CentralSystem
Set EVSE charging
limits
Set group charging
limits
Local Controller :
LocalController
Charging limits may be
changed by local
controller while charging.
Optional, because the
charging limits can also
simply be a maximum
power setting that is pre-
configured in the local
controller.
extend
control s
owns
Page 67 (198)
OCPP 2.0
Figure 15 Presetting Local Group Limits

The next diagrams describe the sequence of messages for a typical case of local
smart charging. For simplicitys sake, this case only involves one EVSE. The first
diagram (Figure 16 ) describes smart charging using mode 3 PWM communication
with the EV. The second (Figure 17) diagram describes smart charging using the
more advanced ISO/IEC 15118 communication with the EV. Details of the
messages can be found in sections 8.4 and 9.
Explanation of Figure 16: The letters A and B in the following text refer to
locations in the diagram.
A: After authorization the EVSE will set a maximum current to use via the PWM
signal. This limit is based on a (default) charging profile that the EVSE had
previously received from the Local Controller. The EV starts charging and a
TransactionStarted is sent to the Central System.
B: While charging is in progress the EVSE will continuously adapt the maximum
current according to the charging profile.
Optionally, at any point in time the Local Controller may send a new charging
profile to the EVSE that shall be used as a limit schedule for the EV.

sd Presetting local group limits
EVSE CSO Central System Local Control l er
Limits for local
controller's group may
be preconfigured in
controller or set
dynamically by CSO.
Local controller assigns
limits to EVSE
opt Set local group limits
[Li mi ts dynami cal l y assi gned by CSO]
SetChargi ngProfi l e.req(0, groupl i mi t, absol ute, from, to)
SetChargi ngProfi l e.conf(OK)
SetChargi ngProfi l e.req(0, l i mi t, absol ute, from, to)
Page 68 (198)
OCPP 2.0
Figure 16 Local Smart Charging (PWM)

Explanation of Figure 17: The letters A and B in the following text refer to
locations in the diagram.
A: The EV sends its local charging needs immediately after authorization. This is
reported to the Central System with TransactionStarted. Central System
responds with a charging profile that the EV shall use as a limit schedule. If
TransactionStarted.conf contains csChargingNeeds, then the limit schedule is
based upon charging needs that the EV owner has provided to the Central
sd Local Smart Charging (PWM)
EV EVSE CSO Central System User Local Control l er
opt Change of limits by controller
Controller decides to
change the charging
profile.
loop Charge according to charging profile
[for each i nterval peri od i n chargi ng profi l e]
EVSE implements
charging profile by
sending mode 3 PWM
signals whenever
maximum current needs
changing.
ref
RFID/Plug & Charge Authorization
ref
A
B
PWM set max current(l i mi t)
swi tch power on()
start chargi ng()
Transacti onStarted.req(i d-tag)
Transacti onStarted.conf(OK)
get l i mi t from chargi ng
profi l e() :l i mi t
PWM set max
current(l i mi t)
SetChargi ngProfi l e.req(connector, l i mi t)
Transacti onStopped.req(i d-tag)
Transacti onStopped.conf(OK)
swi tch power off()
end chargi ng()
Page 69 (198)
OCPP 2.0
System. This way, for example, the EV owner can instruct the EVSE to provide
no more than 4 kWh, even though the EV might be able to charge a lot more.
B: The EV calculates a detailed charging schedule and sends it to the EVSE. The
EVSE will communicate the actual charging schedule back to the Local
Controller as an evChargingProfile.
C: Optionally, at any point in time the Local Controller may send a new charging
profile to the EVSE that shall be used as a limit schedule for the EV. In that
case these limits are sent to the EV and the process returns to the top of the
loop 'Charging', causing it to recalculate a charging schedule.
The loop 'Charging' terminates when the entire charging schedule has been
executed. If cabin preconditioning is required after charging has finished, then
the process will jump back to the top of the loop 'Transaction' to calculate a
schedule needed for cabin preconditioning.

Page 70 (198)
OCPP 2.0
Figure 17 Local Smart Charging (15118)

sd Local Smart Charging (15118)
EV EVSE CSO Central System Local Control l er
ref
loop Transaction
[unti l transacti on i s fi ni shed]
loop Charging
[unti l chargi ng i s fi ni shed]
User terminating and
disconnecting.
Process may be repeated as result
of cabin preheating after charging.
EV is charging according
to schedule...
ref
opt Renegotiation by local controller
A
B
C
l ocal chargi ng needs ()
Transacti onStarted.req(i d-tag, evChargi ngNeeds)
Transacti onStarted.conf(OK, chargi ngProfi l e, csChargi ngNeeds)
send chargi ng l i mi ts()
cal cul ate chargi ng schedul e()
send and execute charge
schedul e(Chargi ngSchedul e)
Noti fyEVChargi ngSchedul e.req(Chargi ngSchedul e)
Noti fyEVChargi ngSchedul e.conf(OK)
fi ni shed chargi ng schedul e()
Page 71 (198)
OCPP 2.0
The reference block RFID/Plug & Charge Authorization is shown in more detail
below. Authorisation in this sequence diagram assumes it is based on RFID cards or
Plug & Charge authorisation, but other authorisation methods can be used as well,
as long as it uses a unique id-tag to pass along in the start transaction message.
Figure 18 RFID/Plug & Charge Authorization

sd RFID/Plug & Charge Authorization
User EVSE EV CSO Central System
opt RFID swipe
alt Authorization
[ID i n l ocal l i st]
[ID not i n l ocal l i st]
opt Plug & Charge
After Plug and Charge
identification the system
will have to decide which
ID is to be used for the
transaction: RFID,
contract-id or vehicle-id.
alt Authorization
[ID i n l ocal l i st]
[ID not i n l ocal l i st]
RFID swi pe(i d-tag)
authori ze from l ocal l i st(i d-tag) :OK
Authori ze.conf(OK)
connect cabl e()
sessi on set-up(contract-i d,
vehi cl e-i d)
authori ze from l ocal l i st(contract-i d) :OK
Authori ze.req(contract-i d, vehi cl e)
Authori ze.conf(OK)
sessi on setup confi rmati on()
Page 72 (198)
OCPP 2.0
8.3 Use case Central smart charging
Figure 19 Use Case Central Smart Charging

In the use case Central smart charging the Central System imposes charging limits
on EVSEs. At the start of a charging session the EV communicates its charging
needs to the Central System via the EVSE using the ISO/IEC 15118 protocol. The
Central System responds with charging limits that are to be applied to the session.
The EV will calculate a charging profile that fits within these limits and send it back
to inform the Central System of the profile it will use for charging. During the
session the Central System can trigger a renegotiation to establish new charging
limits.
After the EV has finished charging and when it is still connected to the EVSE, the EV
may issue a new charging profile, for example when it needs energy to preheat the
cabin.
Clarification of the diagram Figure 20:
A: The EV sends local charging needs immediately after authorization. This is
reported to the Central System with TransactionStarted. Central System
responds with a charging profile that the EV shall use a limit schedule. If
TransactionStarted.conf contains csChargingNeeds, then the limit schedule is
based upon charging needs that the EV owner has provided to the Central
System. This way the EV owner can instruct the EVSE to provide no more than
4 kWh, even though the EV might be able to charge a lot more.
uc Central Smart Charging
CSO Central System :
CentralSystem
EV
EVSE :EVSE
User
Exchange EV
charging needs
Exchange charging
limits
Smart Charging
i ncl ude
i ncl ude
control s
owns
Page 73 (198)
OCPP 2.0
B: The EV calculates a detail charging schedule and sends it to the EVSE. The
EVSE will communicate the actual charging schedule back to Central System as
an evChargingProfile.
C: Optionally, at any point in time the Central System may send a new charging
profile to the EVSE that shall be used as a limit schedule for the EV. In that
case these limits are sent to the EV and the process returns to the top of the
loop 'Charging', causing it to recalculate a charging schedule.
The loop 'Charging' is broken when the entire charging schedule has been
executed. If cabin preconditioning is required after charging has finished, then
the process will jump back to the top of the loop 'Transaction' to calculate a
schedule needed for cabin preconditioning.
Central smart charging can also be done with mode 3 PWM EVs or EVSEs, albeit
with some limitations, because an EV cannot communicate its charging needs over
PWM. In analogy to the local smart charging use case, in paragraph 8.2, an EVSE
can execute a charging schedule by varying the PWM signal. This is illustrated in
Figure 21:
A: After authorization the EVSE will set a maximum current to use via the PWM
signal. This limit is based on a (default) charging profile that the EVSE had
previously received from the Central System. The EV starts charging and a
TransactionStarted is sent to the Central System.
B: While charging is in progress the EVSE will continuously adapt the maximum
current according to the charging profile.
Optionally, at any point in time the Central System may send a new charging
profile to the EVSE that shall be used as a limit schedule for the EV.

Page 74 (198)
OCPP 2.0
Figure 20 Central Smart Charging (15118)

sd Central Smart Charging (15118)
EV EVSE CSO Central System
ref
loop Transaction
[unti l transacti on i s fi ni shed]
loop Charging
[unti l chargi ng i s fi ni shed]
opt Renegotiation by central system
User terminating and disconnecting.
Process may be repeated as result of
cabin preheating after charging.
EV is charging according
to schedule...
ref
A
B
C
l ocal chargi ng needs ()
Transacti onStarted.req(i d-tag, evChargi ngNeeds)
Transacti onStarted.conf(OK, csChargi ngProfi l e,
csChargi ngNeeds)
cal cul ate chargi ng schedul e()
send and execute charge
schedul e(Chargi ngSchedul e)
Noti fyEVChargi ngSchedul e.req(evChargi ngSchedul e)
SetChargi ngProfi l e.req(connector, l i mi ts)
fi ni shed chargi ng schedul e()
Page 75 (198)
OCPP 2.0
Figure 21 Central Smart Charging (PWM)

sd Central Smart Charging (PWM)
EV EVSE CSO Central System User
opt Change of limits by controller
Central System decides
to change the charging
profile.
loop Charge according to charging profile
[for each i nterval peri od i n chargi ng profi l e]
EVSE implements
charging profile by
sending mode 3 PWM
signals whenever
maximum current needs
changing.
ref
ref
A
B
PWM set max current(l i mi t)
swi tch power on()
start chargi ng()
Transacti onStarted.req(i d-tag)
Transacti onStarted.conf(OK,
csChargi ngProfi l e, csChargi ngNeeds)
get l i mi t from chargi ng
profi l e() :l i mi t
PWM set max
current(l i mi t)
swi tch power off()
end chargi ng()
Page 76 (198)
OCPP 2.0
8.4 Smart Charging Operations
8.4.1 Charging profiles
8.4.1.1 Charging profile purposes
A charging profile consists of a charging schedule, which is basically a list of time
intervals and maximum power, and some values to specify the time period and
recurrence of the schedule. Optionally, the profile can provide tariff information, for
example to differentiate between peak and off-peak hours. (See 11.13)
There are four different types of charging profiles, depending on their purpose:
ChargePointMaxProfile
In local smart charging scenarios, the Charge Point has one or more local charging
profiles that limit the power to be shared by all EVSEs of the Charge Point. The
Central System SHALL configure such a profile with ChargingProfilePurpose set to
ChargePointMaxProfile.
ChargePointExternalConstraints
The local power schedule available at the charge point might incorporate local
constraints that are not known to the Central System. Such local constraints SHALL
be represented by charging profiles with ChargingProfilePurpose set to
ChargePointExternalConstraints.
TxDefaultProfile
Default schedules for new transactions MAY be used to impose charging policies on
all transactions. An example could be a policy that prevents charging during the
day. For schedules of this purpose, ChargingProfilePurpose SHALL be set to
TxDefaultProfile.
TxProfile
If a transaction-specific profile with purpose TxProfile is present, it SHALL overrule
the default charging profile with purpose TxDefaultProfile for the duration of the
current transaction only. If there is no transaction active on the EVSE specified in a
charging profile of type TxProfile, then the Charge Point SHALL discard it and return
an error status in SetChargingProfile.conf.
The final schedule constraints that apply to a transaction are determined by
merging the profiles with purposes ChargePointMaxProfile and
ChargePointExternalConstraints with the profile TxProfile or the TxDefaultProfile in
case no profile of purpose TxProfile is provided.
Page 77 (198)
OCPP 2.0
8.4.1.2 Stacking charging profiles
It is allowed to stack charging profiles of the same charging profile purpose in order
to describe complex calendars. For example, one can define a charging profile of
purpose TxDefaultProfile with a duration and recurrence of one week that allows full
power charging on weekdays from 23:00h to 06:00h and from 00:00h to 24:00h in
weekends and reduced power charging at other times. On top of that, one can
define other TxDefaultProfiles that define exceptions to this rule, for example for
holidays.
Precedence of charging profiles is determined by the value of their stackLevel
parameter. At any point in time the prevailing charging profile SHALL be the
charging profile with the highest stackLevel among the profiles that are valid at that
point in time, as determined by their validFrom and validTo parameters.
8.4.1.3 Combining charging profile purposes
The actual schedule that the Charge Point will offer to the EV, in case of ISO/IEC
15118 charging, or that will guide the PWM level in other cases, is a combination of
the prevailing charging profiles of the different purposes.
This actual schedule is calculated by taking the minimum value for each time
interval. Note that time intervals do not have to be of fixed length, nor do they
have to be the same for every charging profile purpose. This means that a resulting
actual schedule may contain intervals of different lengths.
At any point in time the available power in the actual schedule, which is the result
of merging the schedules of charging profiles ChargePointMaxProfile,
ChargePointExternalConstraints and TxDefaultProfile (or TxProfile), SHALL be less
than or equal to lowest value of available power in any of merged schedules.
Page 78 (198)
OCPP 2.0
8.4.2 Set Charging Profile

A Central System can send a charging profile to a Charge Point in the following
situations:
1. At the start of a transaction to set the charging profile for the transaction;
2. During a transaction as a separate message to change the active profile for
the transaction;
3. Outside of the context of a transaction as a separate message to set a
default charging profile for an EVSE or a local controller.
These situations are described below.
8.4.2.1 Setting a charging profile at start of transaction
If the Central Systems receives a TransactionStarted.req with a ChargingNeeds
parameter, then this means that the Charge Point expects to receive a charging
profile. In that case Central System SHALL respond with a TransactionStarted.conf
PDU with a ChargingProfile parameter with chargingProfilePurpose TxProfile and
optionally a parameter for the centrally specified charging needs. If
TransactionStarted.conf contains a parameter csChargingNeeds, then the charging
profile is based upon charging needs that the EV owner has provided to the Central
System. This way the EV owner can, for example, instruct the EVSE to provide no
more than 4 kWh, even though the EV might be able to charge a lot more.
If the Central System receives a TransactionStarted.req without a ChargingNeeds
parameter, then this means that the Charge Point is not expecting a charging
sd Set Charging Profile
alt
[at start of transacti on]
[otherwi se]
StartTransacti on.req(i d-tag, evChargi ngNeeds)
StartTransacti on.conf(status, tx-i d, chargi ngProfi l e, csChargi ngNeeds)
SetChargi ngProfi l e.req(evse, profi l e, absol ute, from, to, tx)
SetChargi ngProfi l e.conf(status)
Page 79 (198)
OCPP 2.0
profile, because it is either using a (previously loaded) default charging profile or
not using any charging profile at all. The Central System SHALL respond with a
TransactionStarted.conf without charging profile and charging needs parameters.
8.4.2.2 Setting a charging profile during a transaction
The Central System MAY send a charging profile to a Charge Point to update the
charging profile for that transaction. The Central System SHALL use the
SetChargingProfile.req PDU for that purpose. If a charging profile with the same
chargingProfileId exists on the Charge Point, then the new charging profile SHALL
replace the existing charging profile, otherwise it SHALL be added. The Charge
Point SHALL then re-evaluate its collection of charge profiles to determine which
charging profile will become active. In order to ensure that the updated charging
profile applies only to the current transaction, the chargingProfilePurpose of
ChargingProfile MUST be set to TxProfile. (See: 8.4.1.1.)
8.4.2.3 Setting a charging profile outside of a transaction
The Central System MAY send charging profiles to a Charge Point that are to be
used as default charging profiles. The Central System SHALL use the
SetChargingProfile.req PDU for that purpose. Such charging profiles MAY be sent at
any time. If a charging profile with the same chargingProfileId exists on the Charge
Point, then the new charging profile SHALL replace the existing charging profile,
otherwise it SHALL be added. The Charge Point SHALL then re-evaluate its
collection of charge profiles to determine which charging profile will become active.
8.4.3 Clear Charging Profile

If the Central System wishes to clear some or all of the charging profiles that were
previously sent the Charge Point, it SHALL use the ClearChargingProfile.req PDU.
sd Clear Charging Profile
Cl earChargi ngProfi l e.req(i d, connector, purpose, stackLevel )
Cl earChargi ngProfi l e.conf(OK)
Page 80 (198)
OCPP 2.0
The Charge Point SHALL respond with a ClearChargingProfile.conf PDU specifying
whether it was able to process the request.
8.4.4 Notify EV or Central Charging Needs

Normally the charge point supplies the EV ChargingNeeds in the TransactionStarted
message. However, it can be sent separately. The Charge Point SHALL use the
NotifyEVChargingNeeds.req for this. It may also be used during the transaction
when the current schedule is no longer sufficient to meet the charging needs of the
EV.
The Central System SHALL respond with a NotifyEVChargingNeeds.conf PDU with
one to three charging profiles of purpose TxProfile that the Charge Point SHALL
offer to the EV. As an optional element the NotifyEvChargingNeeds.conf PDU MAY
contain charging needs that were specified for this EV at the Central System (e.g.
on a web page or by smart phone app). The central charging needs SHALL overrule
the EV charging needs.
sd Notify EV Charging Needs
Noti fyEVChargi ngNeeds.req(evChargi ngNeeds)
Noti fyEVChargi ngNeeds.conf(OK, chargi ngProfi l e, central Chargi ngNeeds)
Page 81 (198)
OCPP 2.0

A similar message is available for the central system to send updated charging
needs to the charge point, e.g. when the user has changed charging needs on the
Central System. The Central System SHALL send a NotifyCentralChargingNeeds.req
to the Charge Point to inform it of change charging needs. Optionally, the Central
System MAY provide a new charging profile to match the changed needs.
The Charge Point SHALL respond with a NotifyCentralChargingNeeds.conf PDU.
8.4.5 Notify EV Charging Schedule

If ISO/IEC 15118 charging is used, the charging profile will be calculated by the
electric vehicle and passed on to the Charge Point. The Charge Point SHALL use the
NotifyEVChargingSchedule.req PDU to communicate this to the Central System.
The Central System SHALL respond with a NotifyEVChargingSchedule.conf PDU to
confirm whether it was able to process the message correctly.
sd Notify Central Charging Needs
Noti fyCentral Chargi ngNeeds.req(csChargi ngNeeds, chargi ngProfi l e)
Noti fyCentral Chargi ngNeeds.conf(OK)
sd Notify EV Charging Schedule
Noti fyEVChargi ngSchedul e.req(chargi ngSchedul e)
Page 82 (198)
OCPP 2.0
8.4.6 Offline behaviour of smart charging
If a Charge Point goes offline after having received a transaction-specific charging
profile with purpose TxProfile, then it SHALL continue to use this profile for the
duration of the transaction.
If a Charge Point goes offline before a transaction is started or before a transaction-
specific charging profile with purpose TxProfile was received, then it SHALL use the
charging profiles that are available. Zero or more of the following charging profile
purposes MAY have been previously received from the Central System:
ChargePointMaxProfile
ChargePointExternalConstraints
TxDefaultProfile
See section 8.4.1 for a description on how to combine charging profiles with
different purposes.
If a Charge Point goes offline, without having any charging profiles, then it SHALL
execute a transaction as if no constraints apply.

Page 83 (198)
OCPP 2.0
9 Device Model: Monitoring, Reporting, & Configuration Management
9.1 Introduction
OCPP 2.0 is extended with a detailed Device Model to facilitate comprehensive
monitoring, reporting, & configuration management.
Note: See chapter 4.4 for an overview introduction to the Device Model.
9.2 The Charge Point Device Model
The Device Model is a standardized logical description of a Charge Point. It allows
for unambiguous description of the state, configuration, and monitoring settings of
the Charge Point, and the precise reporting of significant charge point events.
9.2.1 Components
Logical Components constitute the primary entities of the Device Model, and
represent both typical real-world sub-components (controller, RFID reader, energy
meter, etc.), and virtual logical/software components, with standardized component
names (e.g. TokenReader, FiscalMetering, Firmware, SelfTest,
EVConnection).
Manufacturers MUST use the standard device model Components (as identified by
values of the components name attribute from the enumeration ComponentName)
in order to facilitate automated handling and validation of messages containing
Device Model data.
Where none of the OCPP pre-defined component names apply, manufacturers MUST
use the reserved Component name OtherComponent and specify a custom
descriptive name in the optional OtherName attribute.
We distinguish three levels where components may be found in the build-up of a
Charge Point:
Charge Point
EVSE(s)
Connector(s)
A component can occur on different levels, and more than once. An example of this
is metering: Metering could occur on any of these level. There might be EVSE-
specific meters for transactional purposes, but additionally there might also be a
meter on the Charge Point level monitoring the total consumption of the Charge
Point.
Page 84 (198)
OCPP 2.0
Manufacturers are free to place their components on a level that reflects their build-
up. There is no mandatory relation between any given level and a (sub) set of
components. The standard components are enumerated and described under the
type ComponentName
The following table populated with arbitrary components illustrates the concept in
the context of State and Event reporting.
Charge Point
TokenReader
RadioLink
OverCurrentBreaker
PanicButton
ShockSensor
TiltSensor
Controller
Ventilator
EVSE
StartButton
StopButton
Mode3Controller
ISO15118Controller
BayOccupancyDetector
ACDCConverter
Ventilator
Connector
ConnectorType
ConnectorProtection
PlugRetentionLock

As stated this hierarchy can be used flexibly:
Charge Points can have multiple EVSEs with multiple Connectors.
Components can occur on multiple levels and multiple times per level.

Indexing is used when multiple components with the same name exist on the same
level. The numbering SHALL start at 1; the value 0 (zero), where applicable, implies
all indexed elements. A missing index implies the first index (1).
9.2.2 Variables
OCPP uses standardized Variables to report on the state of a component.
Examples are Boolean variables like Active, analogue variables like Temperature
and enumerations like ConnectorType.
Names, data types, enumerations and descriptions can be found in the
VariableName type of the Variable element. This table is normative, but to avoid
Page 85 (198)
OCPP 2.0
complexity, when implementing OCPP over SOAP, only the names are enforced in
the WSDL.
Unique, or not yet standardized Variables of a Component can be reported using
the reserved variable name OtherVariable and can be given a unique descriptive
name using the optional attribute OtherName. Such variables can be made part of
the standard enumeration in a future version of the specification.
Where multiple instances of a Variable exist within a single Component, they SHALL
be distinguished by successive values of the index attribute. Index numbering
SHALL start at 1, the value 0 (zero) implies all elements in the index (where
applicable). A missing index attribute implies the first index.
Variables are usually scalars (single data items), but may be vectors, and so have
multiple Values (e.g. voltage on multiple AC phases). Multiple (vector) values may
exist for each index of a variable.
For the purpose of setting and reporting configuration, Variable Values include
another partial dimension: ValueType. This allows the representation and
exchange of separate values for (current) Value, and configurable Setting value,
Minimum value, and Maximum value.
To allow formal validation of message content, the actual value of each Variable
Value is represented within a sub-element that has a datatype appropriate to the
nature of the Variable (Boolean, integer, decimal, text string, or specific
enumeration).
9.3 Notices: Reporting Events, State, & Configuration
Using the Device Model of OCPP 2.0, Charge Points can report information ranging
from very static state (e.g. Component presence, model numbers, etc.), through
configuration settings, through regular operational state (e.g. plug inserted,
charging in progress), through data monitoring (e.g. supply voltage variations), and
on to transient and/or urgent event situations.
A sample of the classes of reportable information is shown in the table below.
State
Info
Event
Info
Information Class Examples
Y Static State Component Make/Model/Serial-Number
Y Semi-Static State Component Presence, manually configured availability
Y Configured State Remotely configured settings
Y Monitoring Settings Alerting: set to report Voltage above X Volts as Critical
Y Y Operational Event State Contactor Closed, EVSE Charging, parking bay occupied
Y Y Periodic Data Sampling Hourly report of input supply Voltage(s)
Page 86 (198)
OCPP 2.0
Y Y Delta (Change) Monitoring Temperature, Supply Voltage(s)
Y Alert Reporting Humidity > X, Current > X
Y Critical Values Reporting Temperature > X, Current >X
Y Problem/Fault Events RFID reader Fault, Shock detector activated

All of the above monitoring, state & event reporting, & configuration management
information is communicated from the Charge Point to the Central System using a
common Notice structure.
Notice* [id] [cause] [trigger] at
Component* name [otherName] [EVSE] [connector] [index]
Variable* name [otherName] [index] [techcode] [techinfo]
Value* [unit][valueType][TechCode][TechInfo]
TypedValue [unit] value

Monitoring [monitoring-attributes]

Component* name [otherName] [EVSE] [connector] [index]

Items marked * may occur multiple times.
9.4 Charge Point Events
A Charge Point may send a set of Notices in a standalone Notifications.req
message PDU.
By convention, a Notifications.req with zero (0) Notice elements represents an
assertion by the charge point that there are no (further) Notices to report.
Where information relating to a single logical trigger event comes from multiple
components, then a Notice may contain multiple Component elements.
However, when multiple logically independent events happen (nearly)
simultaneously, each should be represented in a separate Notice.
A Charge Point SHOULD send information about asynchronously occurring events
to the Central System as soon as possible, after each event occurs and is detected
by the Charge Point controller, but only if the relevant Variables associated with the
Component where the event occurs are configured to monitor and report such
events.
For example, a common logical event is a transition of the Problem state variable
of a component. This may represent the occurrence of a fault on a sub-component
Page 87 (198)
OCPP 2.0
(e.g. RFID Reader), or the detection of a critical out-of-range value from some
monitored sensor (e.g. Temperature).
9.5 Transaction Related Events: TransactionStopped
When a charging session ends, the resulting TransactionStopped message can
contain a Notifications element that can report relevant events that occurred
during the charging session.
Typically, this will include the reason for the ending of the charging session in the
final Notice element, with a trigger attribute value of Completion. In addition, it
may contain other time ordered & time-stamped event and/or state notices relating
to the transaction, such as starting conditions (e.g. local/remote authorization
events, starting EV State of Charge (SOC)), charging suspension events, final SOC
state, etc.
9.6 Monitoring
Monitoring is the collective term for any of the mechanisms that a charge point
may use to become aware that a significant change or condition is occurring that
must be reported to the Central System, if enabled by configuration to do so.
In practice, Monitoring activity in the charge point may be triggered in the
controller by hardware interrupts, polling of input sensors, or by a controller
receiving an error value from an intelligent component (e.g. RFID reader module)
or sub-controller.
There are three primary triggering mechanisms for monitoring:
9.6.1 Alerting: Alert & Critical Monitoring
The detection that a monitored Components Variables value has exceeded a
reporting threshold. Alerting is primarily intended to apply to Variables that have
the characteristics of a continuous analogue quantity, such as Voltage,
Temperature, etc.
There are two grades of seriousness of alerting, Alert and Critical, and two
possible directions of movement away from the normal range (Upper and Lower),
so there are four alerting thresholds that can be configured.
9.6.2 Delta Value Change Monitoring
The detection that a Variables present Value has changed (up or down) by more
than the configured delta threshold from the last reported delta monitoring value.
Delta monitoring is useful when it is desired to gather data over time about changes
in the value(s) of a Variable that has a wide range of acceptable values. The
(absolute) change in value of a Variable that will trigger a Delta reporting Notice is
specified using the Component Variables delta attribute.
Page 88 (198)
OCPP 2.0
A typical use of delta monitoring, especially when troubleshooting, would be to
capture progressive changes in charge point supply voltage or device temperature.
9.6.3 Boolean State Monitoring
Delta monitoring with an integer delta value of 1 (one) can be specified for a
Boolean variable that only has values of 1 and 0 (true and false). This can be
applied to important Component Variables such as Problem and Active to enable
the reporting of every change in such variables (e.g. Component entering/leaving a
problem/fault state; Component active/inactive.
9.6.4 Periodic Monitoring
In some cases it is desirable to capture the value(s) of particular Variables at
regular intervals, irrespective of whether they have changed (significantly) or not.
Periodic monitoring allows the reporting of the value(s) of specific Variables at fixed
intervals.
The sampling interval (in seconds) is specified using the Component Variables
periodic attribute. When the clockaligned attribute is true, periodic sampling is
clock-aligned to trigger at midnight and each successive periodic interval from
midnight.
9.6.5 Base Monitoring Configurations
It is desirable to avoid charge point network operators having to specify Monitoring
configuration from scratch, for every make and model of charge point.
A Charge Points designers are best placed to know what variable values and states
can be measured inside the charge point, and to decide on an initial default set of
events/states that can and should be monitored in normal operation.
This is the FactoryDefault monitoring configuration, for normal operational use.
Other standard starting configurations are None, Minimum, and All.
These values can be specified as MonitoringBase when the SetMonitoring
message is used, to simplify the configuration process.
9.6.6 Set Monitoring
A Central System can use the SetMonitoring message to configure the Monitoring
in effect at a Charge Point.
SetMonitoring defines health monitoring criteria for component variables,
effectively specifying when event Notices will be sent by the charge point. For
example: Charge Point shall send an event notice whenever the value of Variable
VVVV of Component CCCC reaches the critical upper threshold XXX.
Page 89 (198)
OCPP 2.0
For each specified Component Variable, the Monitoring control attributes
(alertUpper, criticalUpper, alertLower, criticalLower, delta, periodic, and
clockaligned) can be specified to control how and when the Variables state or
state change events are reported.
9.6.7 Get Monitoring
A Central System can request a Charge Point to report its current Monitoring
configuration using the GetMonitoring message. The charge point replies to the
Central System with a GenericStatus to indicate whether the request is Accepted,
Rejected, or Not-Supported.
The main information reply to a GetMonitoring is sent asynchronously by the charge
point, using a Notice (inside a Notifications message PDU) with a trigger
attribute value of MonitoringRequested.
The Monitoring setting of each reported Component Variable are reported in the
element of type Monitoring.
9.7 Get State Report
The Central System may use this command to request information on the current
values of Component Variables (i.e. charge point State) and/or the Monitoring
criteria in effect on the Variables of the charge point and its sub-Components.
This would typically occur immediately after a successful BootNotification for a
charge point that is being newly enrolled, or has been out of contact for an
extended period of time, or after the Central System has lost its confidence in its
previously held version of the charge points State (e.g. after an extended outage
or system failure of the Central System).
To avoid excessive data traffic, selection criteria, based on specific Components,
and/or Variables, and/or current Component state/status can be specified in the
request.
When the Inventory ReportBase option is specified, the charge point MUST (if
supported) report all the standard (and model specific) Variables that are defined
for its design configuration, including all per evse, per connector and multi-
instance Values of Variables.
A Central System MAY request a Charge Point to report its current State using the
GetStateReport command message. It can be used for the ad hoc diagnosis of
specific problems or to let the Charge Point describe itself so it can be automatically
entered into the Central System.
Page 90 (198)
OCPP 2.0
The set of Components and their Variables to be reported can be explicitly
specified, or can be dynamically selected by the charge point to match specified
state-based selection criteria (e.g. Components in a Problem state) using
ComponentStatesCriteria. The Charge Point replies to the Central System with a
GenericStatus to indicate whether the request is Accepted, Rejected, or Not-
Supported.
Since a request for a large amount of information may require the Charge Point
controller to poll many sub-controllers and sub-component devices, some of which
may have slow response times, the main information reply to a GetStateReport is
sent asynchronously by the Charge Point, after all data has been gathered, using a
Notice (inside a Notifications message PDU) with a trigger attribute value of
StateRequested.
9.8 Set Configuration
A Central System may request a Charge Point to change its current configuration
state using the SetConfiguration command message.
This can be used, for example, to adjust common configuration parameters (e.g.
Heartbeat Interval), to disable specific faulty sub-components (e.g. Connector 2 of
EVSE 2), and/or to enable/disable particular functionality (e.g. Local Pricing, under-
frequency charging suspension).
Each SetConfiguration can contain one or more component elements, each of
which contains one or more Variable(s), each of which can have one or more
value(s) set. Setting Values can be optionally qualified as Set, Min, or Max
using the ValueType attribute.
A Central System can use the configuration settings enumeration mechanism
described below to discover which facets of a charge point are externally
controllable via configuration parameters.
Note: This mechanism replaces the ChangeConfiguration key-value based
mechanism of previous OCPP versions, which is now DEPRECATED.
9.9 Discovering Supported Charge Point Configuration
By using the Settable criterion of the optional variableCriteria element of a
GetStateReport message, a Central System can request a State report containing
an exhaustive enumeration of all configurable options on a Charge Point.
In response, the Charge Point MUST send a Notice containing the value, set, (and
min and max, where supported) values of every configurable Variable, for every
configurable Component.
Page 91 (198)
OCPP 2.0
These values must be repeated for all evse, connector, and index instances of
each Component/Variable.
9.10 Minimum Device Model Support Requirements
Since Charge Points can vary in complexity and build-up, not all components are
present in all Charge Points. It is therefore neither useful nor necessary to require
manufacturers to report on all possible components.
In addition, depending on the sophistication of a charge points design, it may have
the ability to report on (and/or control) few or many of its internal components
using the Device Model.
However, there is a minimum set of logical Components and associated Variables
that MUST always be represented in the model, including:
AvailabilityState Variable for the ChargePoint component overall and for
each independently controllable EVSE and Connector component.

The Boolean variable Problem, and/or a more specific Variable value is
required for each Component that is present in the charge point and had a
specific ChargePointErrorCode in OCPP 1.5.

For example: if an RFID (token) reader component is present then the
TokenReader component, with a Problem Boolean variable MUST be
supported, to provide the equivalent of the ReaderFailure
ChargePointErrorCode in OCPP 1.5.
The above minimum Device Model support requirements provide a minimal
replacement for the equivalent (limited) functionality of the obsolete and removed
StatusNotification message that was used in previous versions of OCPP.
However, to enable effective Plug and Play usability, a network operator may
require that charge points can report at least the presence, availability, and type of
all significant components, even those that may be incapable of reporting their
condition or being controlled.
TODO: TO BE FINALIZED

Page 92 (198)
OCPP 2.0
10 Messages
10.1 Authorize
Authorize.req
This contains the field definition of the Authorize.req PDU sent by the Charge Point
to the Central System.
Field Name Field Type Card. Description
idTag IdToken

1..1 Mandatory. This contains the
identifier that needs to be
authorized.
Authorize.conf
This contains the field definition of the Authorize.conf PDU sent by the Central
System to the Charge Point as response to a Authorize.req PDU.
idTagInfo IdTagInfo

1..1 Mandatory. This contains
information about
authorisation status, expiry
and group id.
priceScheme PriceScheme 0..* Optional. List of price schemes
applicable to this user. If
absent, then the default pricing
at the charge point is used, as
set by a SetPricing message.

10.2 BootNotification
BootNotification.req
This contains the field definition of the BootNotification.req PDU sent by the Charge
Point to the Central System.
chargePointModel ChargePointModel 1..1 Mandatory. This contains a
value that identifies the model
of the ChargePoint.
Page 93 (198)
OCPP 2.0
chargePointVendor ChargePointVendor 1..1 Mandatory. This contains a
value that identifies the
vendor of the ChargePoint.
chargePointSerialN
umber
ChargePointSerial
Number
0..1 Optional. This SHOULD
contain the unique hardware
serial number of the Charge
Point.
imsi Imsi

0..1 Optional. This contains the
IMSI of the modem's SIM
card, if present.

The IMSI provided could be
used to send a reset SMS if
needed.
BootNotification.conf
This contains the field definition of the BootNotification.conf PDU sent by the
Central System to the Charge Point as response to a BootNotification.req PDU.
currentTime dateTime

Central System's current
time.
heartbeatInterval integer

interval in seconds of the
heartbeats.
status RegistrationStatus

whether the Charge-Box has
been registered within the
System Central.
10.3 CancelFirmwareUpdate
CancelFirmwareUpdate.req
This contains the field definition of the CancelFirmwareUpdate.req PDU sent by
Central System to Charge Point.
No fields are defined.
Page 94 (198)
OCPP 2.0
CancelFirmwareUpdate.conf
This contains the field definition of the CancelFirmwareUpdate.conf PDU sent by the
Charge Point to the Central System in response to a CancelFirmwareUpdate.req
PDU.
Field
Name
Field Type Card. Description
status CancelFirmwareUpdateStatus 1..1 Mandatory. This contains the
status of the firmware
cancelation.
10.4 CancelReservation
CancelReservation.req
This contains the field definition of the CancelReservation.req PDU sent by the
Central System to the Charge Point.
reservationId integer

1..1 Mandatory. Id of the
reservation to cancel.

CancelReservation.conf
This contains the field definition of the CancelReservation.conf PDU sent by the
Charge Point to the Central System as response to a CancelReservation.req PDU.
status CancelReservation
Status

1..1 Mandatory. This indicates the
success or failure of the
cancelling of a reservation by
Central System.

10.5 ChangeAvailability
ChangeAvailability.req
This contains the field definition of the ChangeAvailability.req PDU sent by the
Page 95 (198)
OCPP 2.0
evse Evse 1..1 Mandatory. This contains an
evse.id number (>=0)
identifying an EVSE for which
availability needs to change.
evse.id = 0 (zero) is used if the
availability of the charge point
as a whole needs to change.
evse.connectorType is
irrelevant in this message and
can be ignored.
type AvailabilityType

type of availability change
that the Charge Point should
perform.

ChangeAvailability.conf
This contains the field definition of the ChangeAvailability.conf PDU return by
Charge Point to Central System.
status AvailabilityStatus

1..1 Mandatory.This indicates
whether the Charge Point can
perform the availability
change.

10.6 ChangeConfiguration
Note: ChangeConfiguration is DEPRECATED in OCPP 2.0, and is expected to be removed in a future
version.

Implementers SHOULD use the new SetConfiguration message of OCPP 2.0, which supports more
fine-grained configuration, is consistent with the Device Model, and allows multiple configuration
changes to be made in a single message.

Every ChangeConfiguration key value is now treated as a shorthand alias for the normative
equivalent Component.Variable based configuration value used in SetConfiguration. (See Appendix
A: )

Page 96 (198)
OCPP 2.0
ChangeConfiguration.req
This contains the field definition of the ChangeConfiguration.req PDU sent by
Central System to Charge Point. It is RECOMMENDED that the content and meaning
of the 'key' and 'value' attributes is agreed upon between Charge Point and Central
System.

The possible options for the 'key' and 'value' attributes are described in a separate
document. (Appendix A: Configuration Key/Value Pairs)
ChangeConfiguration.conf
This contains the field definition of the ChangeConfiguration.conf PDU returned from
status Configuration
Status

1..1 Mandatory. Returns whether
configuration change has
been accepted.

key string[50] 1..1 Mandatory. The name of the
configuration setting to
change.
See: Appendix A: for
standard configuration key
names and associated
values
value string[500]

1..1 Mandatory. The new value
as string for the setting.
See: Appendix A: for
standard configuration key
names and associated
values
Page 97 (198)
OCPP 2.0
10.7 ClearCache
ClearCache.req
This contains the field definition of the ClearCache.req PDU sent by the Central
System to the Charge Point.
ClearCache.conf
This contains the field definition of the ClearCache.conf PDU sent by the Charge
Point to the Charge Point as response to a ClearCache.req PDU.
status ClearCacheStatus

the local authorisation list has
been cleared or not.

10.8 ClearChargingProfile
ClearChargingProfile.req
The Central System uses this message to clear (remove) either a specific charging
profile (denoted by id) or a selection of charging profiles that match with the values
of the evse, chargingProfilePurpose and stackLevel fields.
id integer 0..1 Optional. The ID of the
charging profile to clear.
evse Evse 0..1 Optional. Specifies the EVSE
and connector for which to
clear charging profiles. An
evse.id of zero (0) specifies the
charging profile for the overall
charge point. Absence of this
parameter means the clearing
applies to all charging profiles
that match the other criteria in
the request.
chargingProfile
Purpose
ChargingProfile
Purpose
0..1 Optional. Specifies to purpose
of the charging profiles that will
be cleared, if they meet the
Page 98 (198)
OCPP 2.0
other criteria in the request.
stackLevel integer 0..1 Optional. Specifies the
stackLevel for which charging
profiles will be cleared, if they
meet the other criteria in the
request.
ClearChargingProfile.conf
status Status 1..1 Mandatory. Returns Accepted if
the Charge Point has found a
charging profile matching the
criteria and was able to clear it.
Returns Rejected otherwise.
10.9 DataTransfer
DataTransfer.req
This contains the field definition of the DataTransfer.req PDU sent either by the
Central System to the Charge Point or vice versa.
vendorId string[255]

1..1 Mandatory. This identifies the
Vendor specific
implementation
messageId string[50] 0..1 Optional. Additional
identification field
data Text
Length undefined
0..1 Optional. Data without
specified length or format.
DataTransfer.conf
This contains the field definition of the DataTransfer.conf PDU sent by the Charge
Point to the Central System or vice versa as response to a DataTransfer.req PDU.
status DataTransferStatus 1..1 Mandatory. This indicates the
success or failure of the data
Page 99 (198)
OCPP 2.0
transfer.
data Text
Length undefined
0..1 Optional. Data in response to
request.

10.10 DiagnosticsStatusNotification
DiagnosticsStatusNotification.req
This contains the field definition of the DiagnosticsStatusNotification.req PDU sent
by the Charge Point to the Central System.
status DiagnosticsStatus

status of the diagnostics
upload.
DiagnosticsStatusNotification.conf
This contains the field definition of the DiagnosticsStatusNotification.conf PDU sent
by the Central System to the Charge Point as response to a
DiagnosticsStatusNotification.req PDU.
10.11 FirmwareStatusNotification
FirmwareStatusNotification.req
This contains the field definition of the FirmwareStatus.req PDU sent by the Charge
status FirmwareStatus

progress status of the
firmware installation.
errorCode This contains the
error code
reported by the
Charge Point.
progress status of the
firmware installation.
Page 100 (198)
OCPP 2.0
FirmwareStatusNotification.conf
This contains the field definition of the FirmwareStatus.conf PDU sent by the Central
System to the Charge Point as response to a FirmwareStatus.req PDU.
10.12 GetConfiguration
Note: GetConfiguration is DEPRECATED in OCPP 2.0, and is expected to be
removed in a future version. Implementers SHOULD use the Device Model based
mechanism to discover all supported configurable parameters of a charge point, as
described in Section: 9.9.

Every ChangeConfiguration key value is now treated as a shorthand alias for the
normative equivalent Component.Variable based configuration value used in
SetConfiguration (as described in 10.30).

The correspondence mapping from key to Component.Variable is documented in
Appendix A: The standardized values and meanings for possible options for the
'key' and 'value' attributes are described in Appendix A: .
GetConfiguration.req
This contains the field definition of the GetConfiguration.req PDU sent by the
key string[50]

0..* Optional. List of keys for
which the configuration value
is requested.
GetConfiguration.conf
This contains the field definition of the GetConfiguration.conf PDU sent by Charge
Point to the Central System in response to a GetConfiguration.req.
configurationKey KeyValue

0..* Mandatory. List of requested
or known keys
unknownKey string[50] 0..* Optional. Requested keys that
are unknown

Page 101 (198)
OCPP 2.0
10.13 GetCost
GetCost.req
The CP requests the Central System to provide the costs based on the actual
consumption.
transactionId TransactionId 1..1 Mandatory. The transaction for
which the current cost is
requested.
LocalConsumption Consumption 1..* Mandatory. Locally measured
cumulative consumption for
each tariff in the price scheme.
GetCost.conf
The result of the calculation of the actual cost. It will be empty when no real-time
cost calculation is performed on the Central System, for example when a
priceSchemeId has not been communicated in TransactionStarted.req.
actualCost Cost 0..1 Optional. Calculated actual cost

10.14 GetDiagnostics
GetDiagnostics.req
This contains the field definition of the GetDiagnostics.req PDU sent by the Central
location anyURI

location (directory) where the
diagnostics file shall be
uploaded to.
retries integer

0..1 Optional.This specifies how
many times Charge Point
must try to upload the
diagnostics before giving up.
If this field is not present, it is
left to Charge Point to decide
Page 102 (198)
OCPP 2.0
how many times it wants to
retry.
retryInterval integer

0..1 Optional. The interval in
seconds after which a retry
may be attempted. If this
field is not present, it is left to
Charge Point to decide how
long to wait between
attempts.
startTime dateTime

date and time of the oldest
logging information to include
in the diagnostics.
stopTime dateTime

date and time of the latest
logging information to include
in the diagnostics.
GetDiagnostics.conf
This contains the field definition of the GetDiagnostics.conf PDU sent by the Charge
Point to the Central System as response to a GetDiagnostics.req PDU.
fileName string[255]

name of the file with
diagnostic information that
will be uploaded. This
attribute is not present when
no diagnostic information is
available.
10.15 GetLocalListVersion
GetLocalListVersion.req
This contains the field definition of the GetLocalListVersion.req PDU sent by the
Page 103 (198)
OCPP 2.0
GetLocalListVersion.conf
This contains the field definition of the GetLocalListVersion.conf PDU sent by the
Charge Point to Central System in response to a GetLocalList.req PDU.
listVersion integer

current version number of the
local authorisation list in the
Charge Point.

10.16 GetMonitoring
This message requests that the charge point send a Notice describing all Monitoring
currently in effect, including both hardwired and configurable monitoring of
continuous/analogue variables, and reported transitions of logical state Variables
such as Active and Problem.
GetMonitoring.req
Component
StatesCriterion
Component
StatesCriterion
0..1 Optional. If specified,
Monitoring criteria only apply
to Components that, at the
time (in the future), match at
least one of the given
Component overall States.
component Component 0..1 Optional. A filter for limiting
the response based on
Component. Wildcards can be
used as follows:
- If name is *, events for
all components will be
reported.
- If EVSE is not specified,
events for all EVSEs will be
reported.
- If Connector is not
specified, events for all
Connectors will be
Page 104 (198)
OCPP 2.0
reported.
variableCriteria VariableCriteria 0..1 Optional. A filter for limiting
Variables as specified in the
FilterVariable type.

GetMonitoring.conf
This is the reply of the Charge Point after receiving a GetMonitoring.req.
status ReportingStatus 1..1 Mandatory. Indicates whether
the report request was
Accepted, Rejected, or Not
Supported

10.17 GetStateReport
GetStateReport.req
This contains the field definition of the GetStateReport.req PDU sent by the Central
reportBase StateReportBase 0..1 Optional. Specifies one of the
common preset reporting
sets: Currently Boot or
Inventory
used as follows:
all components will
potentially be reported.
Page 105 (198)
OCPP 2.0
reported.
Connectors will be
reported.
variableCriteria VariableCriteria 0..1 Optional. A filter for limiting

GetStateReport.conf
This is the reply of the Charge Point after receiving a StateReport.req.
status ReportingStatus 1..1 Mandatory. Indicates whether
the report request was
Accepted, Rejected, or Not
Supported

10.18 Heartbeat
Heartbeat.req
This contains the field definition of the Heartbeat.req PDU sent by the Charge Point
to the Central System.
Heartbeat.conf
This contains the field definition of the Heartbeat.conf PDU sent by the Central
System to the Charge Point as response to a Heartbeat.req PDU.
currentTime dateTime

current time of the Central
System.

Page 106 (198)
OCPP 2.0
10.19 MeterValues
MeterValues.req
This contains the field definition of the MeterValues.req PDU sent by the Charge
identifying an EVSE.
evse.id = 0 (zero) is used to
designate the main power
meter.
can be ignored.
transactionId TransactionId 0..1 Optional. The transaction to
which these meter samples
are related.
values MeterValue 0..* Optional. The sampled meter
values with timestamps.
MeterValues.conf
This contains the field definition of the MeterValues.conf PDU sent by the Central
System to the Charge Point as response to a MeterValues.req PDU.

10.20 Notifications
Notifications.req
This contains a set of Notice.req PDUs, which may individually contain State reports
or Event notifications, sent by the Charge Point to the Central System.
If zero notice elements are included, this is an explicit indication of currently
nothing further to report
Page 107 (198)
OCPP 2.0
notice Notice 0..* Zero or more Notice type
elements.

Notifications.conf
This contains the field definition of the Notifications.conf PDU sent by the Central
System to the Charge Point as response to a BootNotification.req PDU.
10.21 NotifyCentralChargingNeeds
NotifyCentralChargingNeeds.req
evse Evse 1..1 Mandatory. Defines the EVSE
and connector to which the
electric vehicle requesting
energy is connected. evse.id
may not be 0.
csChargingNeeds ChargingNeeds 1..1 Mandatory. The characteristics
of the required energy delivery
as specified by the Central
System.
csChargingProfile ChargingProfile 0..3 Optional. Profile with maximum
power the electric vehicle can
use over time, based on
csChargingNeeds.
The charging profiles SHALL
have a charging profile purpose
of TxProfile.
The current version of
ISO15118-2 limits the number
of limit schedules offered to an
EV to 3 [15118, V2G2-295].
NotifyCentralChargingNeeds.conf
status Status 1..1 Mandatory. Returns whether
the Charge Point has been able
Page 108 (198)
OCPP 2.0
to process the message
successfully. It does not imply
acceptance or adherence to the
charging profile by the EV.
10.22 NotifyEVChargingNeeds
NotifyEVChargingNeeds.req
evse Evse 1..1 Mandatory. Defines the EVSE
and connector to which the
electric vehicle requesting
energy is connected. evse.id
may not be 0.
evChargingNeeds ChargingNeeds 1..1 Mandatory. The characteristics
of the energy delivery required
by the electric vehicle.
NotifyEVChargingNeeds.conf
the Central System has been
able to process the message
that the evChargingNeeds can
be met with the current
charging profile.
csChargingProfile ChargingProfile 0..3 Optional. Charging profiles with
maximum power the electric
vehicle can use over time. The
charging profiles SHALL have a
charging profile purpose of
TxProfile.
The current version of
ISO15118-2 limits the number
of limit schedules offered to an
EV to 3 [15118, V2G2-295].
csChargingNeeds ChargingNeeds 0..1 Optional. Charging needs
collected at the central system
Page 109 (198)
OCPP 2.0
(e.g. using a smart phone
application or values from the
database at the central
system). If the charge point
communicates charging needs,
they will be processed at the
central system and
incorporated into the charging
needs element sent with the
reply.
10.23 NotifyEVChargingSchedule
NotifyEVChargingSchedule.req
The Charge Point uses this message to communicate the charging schedule as
calculated by the EV to the Central System. This is only applicable in case of
ISO/IEC 15118 charging.
evse Evse 1..1 Mandatory. The charging
schedule contained in this
notification applies to an EVSE
and connector. evse.id must be
> 0.
timeBase DateTime 1..1 Mandatory. Periods contained
in the charging profile are
relative to this point in time.
chargingSchedule ChargingSchedule 1..1 Mandatory. Planned energy
consumption of the EV over
time. Always relative to
timeBase.
NotifyEVChargingSchedule.conf
the Central System has been
able to process the message
any approval of the charging
schedule.
Page 110 (198)
OCPP 2.0
10.24 RequestStartTransaction
Note: in OCPP 1.5 and earlier this PDU was known as RemoteStartTransaction.
RequestStartTransaction.req
This contains the field definitions of the RequestStartTransaction.req PDU sent to
Charge Point by Central System.
evse Evse 0..1 Optional. This contains an
evse.id number (>0)
identifying an EVSE for to
start the transaction.
can be ignored.
When a request start
transaction is received all
connectorTypes of a specific
EVSE should be capable of
starting the transaction.
idTag IdToken

1..1 Mandatory. The identifier that
Charge Point must use to
start a transaction.
RequestStartTransaction.conf
This contains the field definitions of the RequestStartTransaction.conf PDU sent
from Charge Point to Central System.
status RequestStartStopS
tatus

1..1 Mandatory. Status indicating
whether Charge Point accepts
the request to start a
transaction.
10.25 RequestStopTransaction
Note: in OCPP 1.5 and earlier this PDU was known as RemoteStopTransaction.
Page 111 (198)
OCPP 2.0
RequestStopTransaction.req
This contains the field definitions of the RequestStopTransaction.req PDU sent to
Charge Point by Central System.
transactionId TransactionId

1..1 Mandatory. The identifier of
the transaction which Charge
Point is requested to stop.
RequestStopTransaction.conf
This contains the field definitions of the RequestStopTransaction.conf PDU sent from
status RequestStartStopS
tatus

1..1 Mandatory. Status indicating
whether Charge Point accepts
the request to stop a
transaction.

10.26 ReserveNow
ReserveNow.req
This contains the field definition of the ReserveNow.req PDU sent by the Central
reservation needs to be done.
evse.id = 0 (zero) is used to
indicate that the reservation is
not for a specific connector.
can be ignored. When a
reserve now is received all
connectors for a specific EVSE
Page 112 (198)
OCPP 2.0
should be reserved.
expiryDate dateTime

date and time when the
reservation ends.
idTag IdToken

1..1 Mandatory. The identifier for
which the Charge Point has to
reserve a connector.
groupIdTag IdToken 0..1 Optional. The group id-tag.
reservationId integer 1..1 Mandatory. Unique id for this
reservation.

If any sub connector types are provided then these should be ignored. When a
reserve now is received all sub connectors for a specific connector should be
reserved.
ReserveNow.conf
This contains the field definition of the ReserveNow.conf PDU sent by the Charge
Point to the Central System in response to a ReserveNow.req PDU.
status ReservationStatus

1..1 Mandatory. This indicates the
success or failure of the
reservation.

10.27 Reset
Reset.req
This contains the field definition of the Reset.req PDU sent by the Central System to
the Charge Point.
type ResetType

type of reset that the Charge
Point should perform.
Page 113 (198)
OCPP 2.0
Reset.conf
This contains the field definition of the Reset.conf PDU sent by the Charge Point to
the Central System as response to a Reset.req PDU.
status ResetStatus

1..1 Mandatory. This indicates
whether the Charge Point can
perform the reset.
10.28 SendLocalList
SendLocalList.req
This contains the field definition of the SendLocalList.req PDU sent by the Central
hash string[64] 0..1 Optional. A hash value
calculated over the content of
the localAuthorisationList
elements. It can be used by
Charge Point to verify correct
receipt of the list.
listVersion integer 1..1 Mandatory. In case of a full
update this is the version
number of the full list. In case
of a differential update it is
the version number of the list
after the update has been
applied.
localAuthorisation
List
AuthorisationData 0..* Optional. In case of a full
update this contains the list of
values that form the new local
authorisation list. In case of a
differential update it contains
the changes to be applied to
the local authorisation list in
the Charge Point.
updateType UpdateType 1..1 Mandatory. This contains the
type of update (full or
Page 114 (198)
OCPP 2.0
differential) of this request.
SendLocalList.conf
This contains the field definition of the SendLocalList.conf PDU sent by the Charge
Point to the Central System as response to a SendLocalList.req PDU.
hash string[64] 0..1 Optional. A hash value
calculated over the content of
the new local authorisation
list in the Charge Point. It can
be used by Central System to
verify that the update has
correctly been applied by the
Charge Point.
status UpdateStatus

whether the Charge Point has
successfully received and
applied the update of the local
authorisation list.
10.29 SetChargingProfile
SetChargingProfile.req
The Central System uses this message to send charging profiles to a Charge Point.
Multiple charging profiles with possibly different charging profile purposes and/or
stack levels can be sent at once (see: 11.13).
evse Evse 1..1 Mandatory. The EVSE and
connector to which the
charging profile applies. If
evse.id = 0, the message
contains an overall limit for the
charge point.
csChargingProfiles ChargingProfile 1..* Mandatory. The charging
profiles to be set at the Charge
Point.
Page 115 (198)
OCPP 2.0
SetChargingProfile.conf
the Charge Point has been able
to process the message
acceptance or adherence to the
charging profile by the EV.
10.30 SetConfiguration
SetConfiguration.req
This contains the field definition of the SetConfiguration.req PDU sent by Central
System to Charge Point.
The standardized configurable Component Variable settings are documented in
Appendix A: .
component Component 1..* Mandatory. One or more
component elements.
Each named component can
contain one or more
Variable elements
Each Variable element can
contain settings for one or
more configuration values
(setValue, minValue,
maxValue) as attributes.
Component elements can
be qualified and/or
wildcarded with evse,
connector, and index
attributes.
Variable elements can be
qualified and/or wildcarded
with the index attribute.
Page 116 (198)
OCPP 2.0

SetConfiguration.conf
This contains the field definition of the SetConfiguration.conf PDU returned from
status GenericStatus

configuration change has
been accepted.
10.31 SetMonitoring
This message specifies the Monitoring criteria that define when the Charge Point
produces a Notifications report. In it, an operator could specify things like: the
Charge Point shall send an event notice as soon as a Variable reaches the critical
state.
SetMonitoring.req
ComponentStates
Criterion
Component
StatesCriterion
0..1 Optional. If specified,
Monitoring criteria only apply
to Components that, at the
time (in the future), match at
least one of the given
Component overall States.
used as follows:
all components will be
reported.
reported.
Connectors will be
Page 117 (198)
OCPP 2.0
reported.
filterVariable FilterVariable 0..1 Optional. A filter for limiting

SetMonitoring.conf
status GenericStatus

Monitoring change has been
accepted.

10.32 SetPricing
SetPricing.req
This message allows a Central System to provide the EVSE with the price schemes
per connector to display. This message is used when prices are the same for all
users. User-specific tariffs, e.g. price schemes determined by their e-mobility
provider, are returned in the Authorization confirmation message.
priceScheme PriceScheme 1..* Mandatory. A list of one or
more price schemes.
SetPricing.conf
This is an empty return message to confirm that pricing has been updated. Pricing
can always be set and will be applicable for the next charge session. If a new
pricing is set during an active charge session the active charge session will use the
existing pricing.
10.33 TransactionStarted
Note: in OCPP 1.5 and earlier this PDU was known as StartTransaction.
TransactionStarted.req
This section contains the field definition of the TransactionStarted.req PDU sent by
the Charge Point to the Central System.
Page 118 (198)
OCPP 2.0
evse Evse

1..1 Mandatory. This identifies
which EVSE (evse.id number
(>0)) is used.
Optionally the used connector
evse.connectorType can be
provided but this is not
mandatory.
evChargingNeeds ChargingNeeds 0..1 Optional. Charging needs
collected at the charge point
(e.g. using ISO15118
communication, a user
interface at the charge point or
another facility). Charging
needs might not be fully
available.
idTag IdToken

identifier for which a
transaction has to be started.
contractId IdToken 0..1 Optional. An IdToken of type
EVCOID identifying the contract
owner responsible for payment
when this differs from the idTag
that is used for authorisation.
meterStart integer

1..1 Mandatory.This contains the
meter value in Wh for the
connector at start of the
transaction.
reservationId integer 0..1 Optional. This contains the id
of the reservation that
terminates as a result of this
transaction.
priceSchemeId integer 0..1 Optional. Id of price scheme to
apply to this transaction. If
absent, then real-time pricing
is not used and no cost will be
displayed during and after
transaction.
Page 119 (198)
OCPP 2.0
timestamp dateTime

date and time on which the
transaction is started.

0..1 Optional. If present, this
transaction id, generated by
the Charge Point, shall be
used by the Central System.

If any sub connector types are provided then these should be ignored. When a start
transaction is received these relate to the connector.
TransactionStarted.conf
This contains the field definition of the TransactionStarted.conf PDU sent by the
Central System to the Charge Point as response to a TransactionStarted.req PDU.
idTagInfo IdTagInfo

information about
and group id.
contractIdInfo IdTagInfo

0..1 Optional. This contains
information authorisation
status of the contractId if that
was present in the
TransactionStarted.req.

transaction id supplied by the
Central System.
csChargingNeeds ChargingNeeds 0..1 Optional. Charging needs
collected at the central
system (e.g. using a smart
phone application or values
from the database at the
central system). If the charge
point communicates charging
needs, they will be processed
at the central system and
incorporated into the charging
Page 120 (198)
OCPP 2.0
needs element sent with the
reply.
csChargingProfile ChargingProfile 0..3 Optional. Profile with
maximum power the electric
vehicle can use over time.
The charging profiles SHALL
have a charging profile
purpose of TxProfile.
10.34 TransactionStopped
Note: in OCPP 1.5 and earlier this PDU was known as StopTransaction.
TransactionStopped.req
This contains the field definition of the TransactionStopped.req PDU sent by the
Charge Point to the Central System.
idTag IdToken

identifier which requested to
stop the charging. It is
optional because a charge
point may terminate charging
without the presence of an id-
tag, e.g. in case of a reset.
You should only provide the
idTag if it is actually used to
terminate the transaction.
meterStop integer

meter value in Wh for the
connector at end of the
transaction.
timestamp dateTime

transaction is stopped.
notifications Notification 0..1 Optional. Can be used to
report information about
significant events occurring
Page 121 (198)
OCPP 2.0
during the charging session
(including the final/proximate
reason for session
termination), and/or the
values of relevant Variables at
session end (e.g. vehicle SOC,
tethered cable holstered,
charging bay vacated)

transaction-id as received by
the TransactionStarted.conf.
transactionData TransactionData 0..* Optional. This contains
transaction usage details
relevant for billing purposes.
timeSpentCharging integer 0..1 Optional. This contains the
total time spent charging in
seconds.
TransactionStopped.conf
This contains the field definition of the TransactionStopped.conf PDU sent by the
Central System to the Charge Point as response to a TransactionStopped.req PDU.
idTagInfo IdTagInfo

0..1 Optional. This contains
information about
and group id. It is optional,
because a transaction may
have been stopped without an
identifier.
totalCost Cost 0..1 Optional. Total cost of the
transaction.

10.35 UnlockConnector
UnlockConnector.req
This contains the field definition of the UnlockConnector.req PDU sent by the
Page 122 (198)
OCPP 2.0
evse.id number (>0)
to unlock the connector.
When evse.connectorType is
provided then this connector
should be unlocked.
If no evse.connectorType is
provided, all connectors
attached to a specific EVSE
should be unlocked.
UnlockConnector.conf
This contains the field definition of the UnlockConnector.conf PDU sent by the
Charge Point to the Central System as response to an UnlockConnector.req PDU.
status UnlockStatus

whether the Charge Point has
unlocked the connector.

10.36 UpdateFirmware
UpdateFirmware.req
This contains the field definition of the UpdateFirmware.req PDU sent by the Central
location anyURI

1..1 Mandatory. This contains a
string containing a URI
pointing to a location from
which to retrieve the
firmware.
Page 123 (198)
OCPP 2.0
retries integer

0..1 Optional. This specifies how
many times Charge Point
must try to download the
firmware before giving up. If
this field is not present, it is
left to Charge Point to decide
how many times it wants to
retry.
retrieveDate dateTime

date and time after which the
Charge Point must retrieve
the (new) firmware.
installDate dateTime 0..1 Optional. This contains the
Charge Point may decide to
start the installation of the
retrieved firmware.
retryInterval integer

0..1 Optional. The interval in
seconds after which a retry
may be attempted. If this
field is not present, it is left to
Charge Point to decide how
long to wait between
attempts.
UpdateFirmware.conf
This contains the field definition of the UpdateFirmware.conf PDU sent by the
Charge Point to the Central System as response to a UpdateFirmware.req PDU.

Page 124 (198)
OCPP 2.0
11 Types
11.1 AuthorisationData
Class
Elements that constitute an entry of a local authorisation list update.
idTag IdToken 1..1 Mandatory. The identifier to which this
authorisation applies.
idTagInfo IdTagInfo

0..1 Optional. This contains information about
authorisation status, expiry and group id.
If this element is present, then this entry
SHALL be added or updated in the local
authorisation list. If this element is
absent, than the entry for this idtag in the
local authorisation list SHALL be deleted.

11.2 AuthorizationStatus
Enumeration
Status as response to an Authorize.req.
Value Description
Accepted Identifier is allowed for charging.
Blocked Identifier has been blocked. Not allowed for charging.
Expired Identifier has expired. Not allowed for charging.
Invalid Identifier is unknown. Not allowed for charging.
ConcurrentTx Identifier is already involved in another transaction and
multiple transactions are not allowed. (The value of
ConcurrentTx can only be returned in response to a
TransactionStarted.req message. It is not relevant for a
TransactionStopped.req and during Authorize the Central
System might not know, whether the authorization is for
Page 125 (198)
OCPP 2.0
starting or stopping.)
11.3 AvailabilityStatus
Enumeration
Status returned in response to ChangeAvailability.req.
Value Description
Accepted Request has been accepted and will be executed.
Rejected Request has not been accepted and will not be executed.
Scheduled Request has been accepted and will be executed when
transaction(s) in progress have finished.
11.4 AvailabilityState
Enumeration
Allowed values (states) of the AvailablilyState Variable.
Value Description
Unknown Unknown; e.g. not yet determined
Available Available for use, as none of the other states are
applicable.
This is the default, and non-active state.
Inoperative Commanded "out of service"
Reserved Not Available because of specific or aggregate
reservation in effect
Occupied In Use: Physically or logically connected
This is an Active state
Faulted Unable to operate due to a fault condition.
11.5 AvailabilityType
Enumeration
Page 126 (198)
OCPP 2.0
Requested availability change in ChangeAvailability.req.
Value Description
Inoperative Charge point is not available for charging.
Operative Charge point is available for charging.
11.6 CancelFirmwareUpdateStatus
Enumeration
Status in CancelFirmwareUpdate.conf
Value Description
Accepted This specifies that a planned firmware update was pending
and it has been cancelled.
Rejected This specifies that there was no firmware update request
pending in the Charge Point, either because the firmware
update has already been installed or because it had never
been sent.

11.7 CancelReservationStatus
Enumeration
Status in CancelReservation.conf.
Value Description
Accepted Reservation for the identifier has been cancelled.
Rejected Reservation could not be cancelled, because there is no
reservation active for the identifier.
11.8 ChargePointModel
Class
String for holding a charge point model value in BootNotification.req. It is a case
insensitive string.
Field Name Field Type Description
Page 127 (198)
OCPP 2.0
ChargePoint
Model
CiString[20]
11.9 ChargePointSerialNumber
Class
String for holding serial number value in BootNotification.req. It is a case
insensitive string.
ChargePoint
SerialNumb
er
CiString[25]
11.10 ChargePointVendor
Class
String for holding a charge point vendor value in BootNotification.req. It is a case
insensitive string.
ChargePoint
Vendor
CiString[20]
11.11 ChargingNeeds
Class

class ChargingNeeds
ChargingNeeds
- requestedEnergyTransfer :RequestedEnergyTransferType
- energyAmount :fl oat [0..1]
- numberOfPhases :i nt [0..1]
- evMi nCurrent :fl oat [0..1]
- evMaxCurrent :fl oat [0..1]
- evMaxPower :fl oat [0..1]
- nomi nal Vol tage :fl oat [0..1]
- startOfChargi ng :DateTi me [0..1]
- departureTi me :DateTi me [0..1]
- condi ti oni ngPeri od :i nt [0..1]
- stateOfCharge :fl oat [0..1]
- energyCapaci ty :fl oat [0..1]
enumerati on
RequestedEnergyTransferType
Ac
DcIso
DcChademo
Page 128 (198)
OCPP 2.0
requestedEnergyTra
nsfer
RequestedEnergyTr
anferType
1..1 Mandatory. Type of energy
transfer requested by the
electric vehicle.
energyAmount integer 0..1 Optional. Amount for energy
requested (in Watth). This
inludes energy required for
preconditioning.
numberOfPhases integer 0..1 Optional. Number of phases
(between 1 and 3). Mandatory
for AC charging.
evMinCurrent float 0..1 Optional. Minimum current
supported by the electric
vehicle (per phase).
evMaxCurrent float 0..1 Optional. Maximum current
vehicle (per phase). Includes
cable capacity.
evMaxPower float 0..1 Optional. Maximum power
vehicle. Mandatory for DC
charging.
nominalVoltage float 0..1 Voltage to be used for
calculations. Always between 1
phase and neutral.
startOfCharging DateTime 0..1 Optional. Earliest point in time
when the EV plans to charge.
departureTime DateTime 0..1 Optional. Estimated departure
time of the electric vehicle.
conditioningPeriod integer 0..1 Optional. Time in minutes
before departureTime, in which
the EV requires energy for air-
conditioning or heating.
stateOfCharge float 0..1 Optional. Energy available in
the battery (in percent of the
Page 129 (198)
OCPP 2.0
battery capacity)
energyCapacity float 0..1 Optional. Capacity of the
battery (in KWh)
11.12 ClearCacheStatus
Enumeration
Response to ClearCache.req.
Value Description
Accepted Command has been executed.
Rejected Command has not been executed.
11.13 ChargingProfile
Class
A ChargingProfile consists of a ChargingSchedule, describing the amount of power
that can be delivered per time interval, and optionally one or more
SalesTariffTables. The EV will construct a charging schedule that fits within a
ChargingProfile offered by the Charge Point. The EV may use the information in the
SalesTariffTable to construct a most economical charging schedule based on the
price level information per tariff period. Note, that tariff periods do not have to be
synchronised with charging schedule periods.
Page 130 (198)
OCPP 2.0

chargingProfileId integer 1..1 Mandatory. Unique identifier for
this profile.
primary boolean 0..1 Optional. Indicates whether the
limit schedule is the primary
limit schedule or an alternative
limit schedule that can be used
during negotiation according to
ISO15118. A
SetChargingProfile.req message
contains exactly one primary
limit schedule. If the charge
point is working with local
smart charging, the algorithm
to merge limit schedules for the
overall energy consumption has
to ensure that there is only one
primary schedule applicable to
class ChargingProfile
ChargingProfile
- chargi ngProfi l eID :i nt
- pri mary :bool ean [0..1]
- stackLevel :i nt
- chargi ngProfi l ePurpose :Chargi ngProfi l ePurposeType
- chargi ngProfi l eKi nd :Chargi ngProfi l eKi ndType
- recurrencyKi nd :RecurrencyKi ndType [0..1]
- val i dFrom :DateTi me [0..1]
- val i dTo :DateTi me [0..1]
ChargingSchedule
- chargi ngSchedul eId :i nt
- durati on :i nt [0..1]
- startSchedul e :DateTi me [0..1]
SalesTariffTable
- sal esTari ffId :i nt
- tari ffDescri pti on :stri ng [0..1]
- maxEPri ceLevel :i nt
TariffPeriod
- startPeri od :i nt
- peri odDescri pti on :stri ng [0..1]
- ePri ceLevel :i nt
ChargingSchedulePeriod
- startPeri od :i nt
- maxPower :i nt
- numberPhases :i nt [0..1]
Enumerati on
ChargingProfilePurposeType
ChargePoi ntSchedul e
ChargePoi ntSchedul eConstrai nts
EvDefaul tSchedul e
EvSchedul eConstrai nts
EvSchedul e
Enumerati on
ChargingProfileKindType
Absol ute
Rel ati ve
Recurri ng
Enumerati on
RecurrencyKindType
Dai l y
Weekl y
1..*
1
1..*
1
0..*
1
1
1
Page 131 (198)
OCPP 2.0
a schedule negotiation
according to ISO15118. If an
EV charges controlled by PWM
(mode 3) or doesnt support
multiple sales tariff tables when
charging with ISO15118, the
primary limit schedule shall be
used.

Note: The term alternative
limit schedule is used for limit
schedules with primary = false.
MAY be empty if the Charge
Point doesnt support ISO/IEC
15118 or doesnt support
alternative schedules.
stackLevel integer
>=0
1..1 Mandatory. Value determining
level in hierarchy stack of
profiles. Higher values have
precedence over lower values.
Lowest level is 0.
chargingProfilePurp
ose
ChargingProfilePurp
oseType
1..1 Mandatory. Defines the purpose
of the schedule transferred by
this message.
chargingProfileKind ChargingProfileKind
Type
1..1 Mandatory. Indicates the kind
of schedule.

recurrencyKind RecurrencyKindTyp
e
0..1 Optional. Indicates the start
point of a recurrence.
validFrom DateTime 0..1 Optional. Point in time at which
the profile starts to be valid. If
absent, the profile is valid as
soon as it is received by the
charge point. Not to be used
when ChargingProfilePurpose is
TxProfile.
validTo DateTime 0..1 Optional. Point in time at which
the profile stops to be valid. If
Page 132 (198)
OCPP 2.0
absent, the profile is valid until
it is replaced by another profile.
Not to be used when
ChargingProfilePurpose is
TxProfile.
chargingSchedule ChargingSchedule 1..1 Mandatory. Contains limits for
the available power over time.
salesTariff SalesTariffTable 0..1 Optional. Contains indications
of the relative value of energy
over time (for example price or
percentage of green energy).
Mandatory for an alternative
limit schedule.
11.14 ChargingProfileKindType
Enumeration
Value Description
Absolute Schedule periods are relative to a fixed point in time defined
in the schedule.
Relative Schedule periods are relative to a situation-specific start
point (such as the start of a session) that is determined by
the charge point.
Recurring The schedule restarts periodically at the first schedule
period.
11.15 ChargingProfilePurposeType
Enumeration
Value Description
ChargePointMaxPr
ofile
Configuration for the maximum power available at a
Charge Point. Only valid for a Charge Point. Therefore
evse.Id MUST be 0 in the SetChargingProfile.req
message.
ChargePointExtern
alConstraints
Additional constraints that will be incorporated into a local
power schedule. Only valid for a Charge Point. Therefore
evse.Id MUST be 0 in the SetChargingProfile.req
message.
Page 133 (198)
OCPP 2.0
TxDefaultProfile Default profile to be used for new transactions. In the
SetChargingProfile.req message evse.Id MAY be 0, in
which case the profile applies to all EVSEs of the Charge
Point.
TxProfile Profile with constraints to be imposed by the Charge Point
on the current transaction. A profile with this purpose
SHALL cease to be valid when the transaction terminates.
In the SetChargingProfile.req message evse.Id MUST NOT
be 0.
11.16 ChargeProtocol
Enumeration
Allowed values of the ChargeProtocol Variable
Value Description
Mode3 IEC61851 Mode 3 protocol (DC & PWM signalling via
Control Pilot wire)
CHAdeMO CHAdeMO protocol
ISO15118 ISO15118 V2G protocol (wired or wireless) as used
with CCS
Uncontrolled No charging power management applies (e.g. Schuko
socket)

11.17 ChargingSchedule
Class
chargingScheduleId integer 1..1 Mandatory. Unique identifier for
a charging schedule.
duration integer 0..1 Optional. Duration of the
charging schedule in seconds.
If the duration is left empty,
the last period will continue
Page 134 (198)
OCPP 2.0
indefinitely or until end of the
transaction in case
startSchedule is absent.
startSchedule DateTime 0..1 Optional. Starting point of an
absolute schedule. If absent
the schedule will be relative to
start of charging.
chargingSchedulePe
riod
ChargingScheduleP
eriod
1..* Mandatory. List of
ChargingSchedulePeriod
elements defining maximum
power usage over time.
11.18 ChargingSchedulePeriod
Class
startPeriod integer 1..1 Mandatory. Start of the period,
in seconds from the start of
schedule. The value of
StartPeriod simultaneously
defines the stop time of the
previous period.
maxPower integer 1..1 Mandatory. Maximum power in
Watt that may be delivered
during the schedule period.
numberPhases integer 0..1 Optional. The number of
phases that can be used for
charging. If a number of
phases is needed,
NumberPhase=3 will be
assumed unless another
number is given. For calculation
purposes, the PWM duty cycle
shall be
PMax/(NumberPhases*Nominal
Voltage), where
NominalVoltage is between one
phase and neutral.
Page 135 (198)
OCPP 2.0
11.19 Component
Class
Contains information about a component in the device model.
Attribute:
name
Component
Name
1..1 Mandatory. The name of the
component in the device
model.
Use OtherComponent if the
relevant component is not in
the standard enumeration.
attribute:
otherName
string 0..1 Optional. The second (non-
standardized) name of the
component. Especially
relevant if name is
OtherComponent.
attribute:
evse
integer 0..1 Optional. The index of the
EVSE in which the component
is located. If not specified, it
indicates that the component
is NOT part of an EVSE: i.e. it
exists at the overall charge
point level.
When using Component as a
filter (e.g. in the
GetStateReport.req message),
specifying no EVSE means
every EVSE.
attribute:
connector
Connector in which the
component is located. If not
specified, it indicates that the
component is NOT part of a
Connector: i.e. it exists at
EVSE level, or above.
Page 136 (198)
OCPP 2.0
filter (e.g. in the
specifying no Connector
means every Connector.
attribute:
index
component. E.g. if we talk
about the third fan of the
second EVSE, the value of
index would be 3 and that of
EVSE would be 2.
If not specified, the value is
assumed to be 1, meaning the
first component within the
Charge Point, EVSE or
Connector (depending on the
value of EVSE and Connector).
filter (e.g. in the
specifying no Index means all
values.
variable 1..* Mandatory. One or more
VariableType.

Page 137 (198)
OCPP 2.0

11.20 ComponentName
Enumeration
The list of possible values of the ComponentName of the Component type. If the
relevant name is not in the enumeration the value OtherComponent MUST be used
and a non-standardized descriptive name SHOULD be specified as the value of
optional OtherName attribute.
Value Description
AccessSensor Reports when an access door/panel is open. This may be a
simple switch, or may also involve circuitry or code that
allows the Sensor to be disarmed in advance from
generating an alert when a service visit is expected.
AcDcConverter An AC to DC Power Converter is a complex electromagnetic
& power electronics component that usually simulates a
variable current DC current source to force energy directly
into the EV battery stack(s), under tight control of the EV's
battery management system. Some DC charge points have
monolithic power converters (e.g. single 50kW converter),
while others may use a "modular" approach, with the total
DC output current being the sum of the outputs from
multiple semi-independent modules (e.g. 5 x 10kW).
Due to their complexity, Power Converters normally contain
multiple sub-systems, and have their own sub-controller,
and temperature monitoring and cooling.
Common Variables: Present: (per module); Available:
Available for use; Enabled: (not commanded Out of
Service); Problem: some problem/fault exists; Tripped: A
problem requiring intervention has occurred.; Overload:
Excessive current/power consumption; DC Voltage; DC
Current; Power; Temperature; FanSpeed.
AreaVentilation Fans (or equivalent devices) used to ensure that EVs that
require ventilation during charging, as signaled by IEC
61851 State D (+3V) (e.g. non-sealed lead-acid) are not
charge in a closed space.
Common Variables: Active: running; Problem: fault: e.g. fan
stalled/slow; FanSpeed: measured or inferred fan RPM
Page 138 (198)
OCPP 2.0
Value Description
BayOccupancySensor Charge points (and standalon EVSE units) can use sensors
(optical, ground loop, ultrasonic, etc.) to detect whether the
associated parking/charging bay is physically vacant, or is
occupied by a vehicle or other obstruction. This information
can be used make (and report) an EVSE as Unavailable
Common Variables: Present: OccupancySensor hardware
exists; Available: OccupancySensor is wired up/in; Enabled:
Sensor is detecting occupancy; Active: BayOccupied;
Percent: percentage obstruction (for analogue sensors).
BeaconLighting The Beacon Lighting component, if present, helps EV drivers
to locate nearby charging places, and/or to determine
charging availablity state, usually by colour variation.
The lighting level may be adjustable based on ambient light
levels to maintain daytime visiblity without providing
nuisance light at night.
Common Variables: Present, Available, Enabled; Active: On;
Problem: Beacon lighting fault; Percent: Lighting Level;
Power: Lighting Wattage; Colour: Displayed colour
CableBreakaway
Sensor
A sensor that detects when a charging cable (captive or
removable) has been forcibly pulled from the charge point.
Although all series production EVs contain interlock circuitry
to prevent the vehicle from being driven away while
"plugged in", this could still happen due to an EV interlock
failure, a non-standard EV, impact by another vehicle, or
other reasons.
Common Variables: Active: Breakaway detected
CHAdeMOController A CHAdeMO Controller component communicates with an EV
using the wired CANbus protocol to exchange information an
control charging using the CHAdeMO protocol.
Common Variables: Present & Available; Active: EV
connected; Problem: controller fault
ChargePoint The entire Charge Point as a logical entity.
Common Variables: Present: Always; Available: not faulted;
Enabled: Available for use (not commanded Out of Service);
Problem: some problem/fault exists; Tripped: A problem
requiring intervention has occurred.; Overload: Excessive
Page 139 (198)
OCPP 2.0
Value Description
current/power consumption; SupplyPhases:;
PhaseRotation:; AC Voltage; AC Current; Power;
VoltageImbalance; CurrentImbalance; Manufacturer; Model;
ECVariant; SerialNumber; OperatingTimes
ChargingStatus
Indicator
The Charging Status Indicator, when present, provides
visible feedback to the user about the connection and
charging status of an EVSE/Connector. This is commonly in
the form of multi-colored lighting.
Common Variables: Present, Available, Enabled; Active: On
(displaying); Colour: Displayed colour
Clock The Clock component represents a real time clock
component. Clocks usually (but not always) maintain
accurate time during power outages.
Common Variables: Present, Available; Active: running;
Fallback: running on backup power; Fallback.max: battery
backed; Problem: fault;
Connector A connector denotes a means to connect an EV to a charge
point with either a socket, an attached cable & inline
connector, or an inductive coil.
An EVSE can support multiple connectors, but only a single
connector may be "connected" and used to communicate
and/or deliver power at any one time.
Common Variables: Present; Available: Available for use
(not commanded Out of Service); Problem: some
problem/fault exists; Tripped: A problem requiring
intervention has occurred.; Overload: Excessive
current/power consumption; SupplyPhases:;
PhaseRotation:; AC Voltage; AC Current; DC Voltage; DC
Current; Power; VoltageImbalance; CurrentImbalance
ConnectorProtection Many charge point designs have Connectors that have an
external protective mechanism to prevent contact with
conductors that may become "live" under other failure
modes. Such protection mechanisms are mandatory in some
jurisdictions, and can take the form of an external shutter or
sliding "door" that is locked/unlocked electrically (solenoid)
or mechanically (motor). For attached cable designs, a
connector holster lock mechanism may perform a similar
Page 140 (198)
OCPP 2.0
Value Description
function.
Common Variables: Active: Unlocked; Problem: UnlockFailed
Controller An embedded logic controller, usually at the ChargePoint
and/or EVSE level.
Common Variables: Present & Available; Active: running;
Problem: controller fault
ControlMetering Charge Points (and the subsidiary EVSEs) commonly use
discrete electrical/electronic circuitry to monitor the
electrical behaviour of charging EVs in near real time (e.g.
to check for excessive current draw). This logical component
is often separate from a (certified) Fiscal Meter, because the
latter cannot provide overload signals or interrupts
sufficiently quickly.
Common Variables: Power; ACCurrent; DCCurrent;
DCVoltage
CoolingSystem Fans (or equivalent devices) used to provide cooling airflow,
typically to a Charge Point overall, or to specific EVSEs.
Problem: fault: e.g. fan stalled/slow; FanSpeed: measured
or inferred fan RPM
Display The Display component, if present, provides information and
feedback to the user.
Common Variables: Present & Available; Problem: Display
fault; WidthInChars; HeightInChars; DataText: Display
Contents
ELVSupply The ELV Supply component represents the low voltage
power supply (typically 12V DC) that provides operating
power for controllers and other components.
It may have a backup capability to continue to power critical
components during short power outages.
Common Variables: Fallback: Running on backup energy;
StateOfCharge: backup battery; Time: (estimated)
operating time on backup energy
EmergencyStop Many high-power/DC charge points contain a highly visible
Page 141 (198)
OCPP 2.0
Value Description
Sensor "Emergency Stop" button, that should be pressed by the
user or other nearby persons if serious faulty behaviour is
observed (e.g. smoke/flames from EV or charge point).
Common "Emergency Stop" button designs are usually
mechanically latching when pushed, and require to be
manually reset. They are often behind a "push to break"
transparent cover, to discourage improper use.
Common Variables: Active: Currently Pressed; Tripped:
Pressed & not reset
EVChargingSession A logical EV re-charging session between an EVSE and an
EV.
Common Variables: Active: Ongoing; Complete: Ended
normally ; (e.g. smart charging schedule completed);
Tripped: Terminated abnormally; Problem: Session fault;
(e.g. bad Mode3 signalling); StateOfCharge: EV SOC %
EVConnection The logical (physical or inductive+wireless) connection from
an EVSE to an EV.
Common Variables: Operated; Active (Connected); Problem:
Connection fault (e.g. bad Mode3 signalling)
EVRetentionLock Many EV charging connectors have a locking mechanism,
both to prevent the connector from being removed when
high currents are flowing, and/or as an anti-theft/vandalism
measure.
Common Variables: Present & Available; Active: (Locked);
Problem
EVSE

The EVSE is a logical/virtual component that represents the
entire chain of components responsible for transporting
energy from the grid to the electric vehicle or vice versa. A
charge point can have multiple EVSEs, that may be able to
communicate with and charge multiple EVs simultaneously.
Common Variables: Present: Always, except for local
controllers; Available: Available for use (not commanded
Out of Service); Problem: some problem/fault exists;
Tripped: A problem requiring intervention has occurred.;
Overload: Excessive current/power consumption;
SupplyPhases:; PhaseRotation:; AC Voltage; AC Current; DC
Voltage; DC Current; Power; VoltageImbalance;
Page 142 (198)
OCPP 2.0
Value Description
CurrentImbalance
ExternalTemperature
Sensor
An external temperature sensor reports ambient air
temperature, and may be used (possibly in conjunction with
humidity sensor(s)) to control Ventilators and Fans.
Common Variables: Present & Available; Problem: sensor
fault; Temperature: ambient temperature
Firmware The Firmware component represents the software installed
the controller (ChargePoint or EVSE level).
Common Variables: VersionNumber; VersionDate
FiscalMetering A (usually certified) Fiscal Meter provides energy transfer
readings that are the basis for billing. In simple cases,
energy readings may be taken only at start and end of a
charging session, but when complex Time-of-Use tariffs are
in effect, intermediate readings must be acquired during
charging sessions.
Common Variables: EnergyToEV; EnergyRegisterToEV
GroundIsolation
Tester
Some Charge Points (especially DC) may include an
Isolation Tester as part of their own self test mechanisms,
to confirm the isolation of floating circuitry when no Evs are
connected (especially during startup self-test).
Common Variables: Problem: Isolation fault; Impedance:
Isolation resistance
Heater Heaters are sometimes present in charge points, usually to
ensure reliable operation in cold environments.
Common Variables: Present & Available; Active: heater on;
Problem: heater fault; Power: instantaneous heater power
level
HumiditySensor A humidity sensor reports relative air humidity, and may be
used (possibly in conjunction with temperature sensor(s)) to
control Ventilators and Fans.
fault; Humidity: RH(%)
InternalTemperature An internal temperature sensor reports the air temperature
within an enclosure (ChargePoint or spoke EVSE), and may
Page 143 (198)
OCPP 2.0
Value Description
Sensor be used (possibly in conjunction with humidity sensor(s)) to
control Ventilators and Fans.
fault; Temperature: enclosure temperature
ISO15118Controller An ISO 15118 Controller component communicates (wired
or wirelessly) with an EV to exchange information and
control charging using the ISO 15118 protocol.
LightSensor LightSensor reports ambient light levels.
This may be used by the charge point to regulate the on/off
or brightness state of integral or external environmental
lighting: e.g. charge point beacon/availability lighting, or
ambient courtesy lighting for users, based on the
environmental light conditions.
fault; Light: light level (Lux)
LocalPowerController The Local Power Controller component represents any
locally implemented capability to manage/constrain power
consumption from the distribution network for safety or
other reasons.
Such control will normally preempt and constrict or suspend
the ongoing charging of EVs, irrespective of any smart
charging plan.
Constraint may be completely autonomous (e.g. based on
incoming power supply frequency alone) or may be
influenced by local power availability communication
mechanisms, such as PLC or ZigBee signaling from a local
distribution transformer substation.
Common Variables: Present & Available; Active: Constraint
in Effect; Problem: power controller fault; Power: Maximum
Available Power; Frequency: Constraint On[1] & Off[2]
Mode3Controller A Mode 3 Controller component provides and senses the low
voltage DC and PWM signalling between an EVSE and EV
over a control pilot line.
Page 144 (198)
OCPP 2.0
Value Description
OtherComponent Special Component to represent devices, etc. that do not
correspond to any standardized component.
Multiple (different) non-standardized devices, etc. can be
represented as successive indexed OtherComponents.
Each (indexed) OtherComponent SHOULD provide a suitable
descriptive value for the component's "Name" variable.
Common Variables: OtherVariable

OutOfServiceInput An OutOfServiceInput, when present, can allow the host site
operator to control the actual times of operation of the
charge point.
Activation of this input causes the charge point to make
(and report) itself unavailable for charging.
Common Variables: Present: Out of Service Input exists;
Available: Out of Service Input enabled; Active: Out of
Service Signalled
OverCurrentBreaker Over-Current Breaker(s) protect equipment (and life) by
disconnecting the electrical supply when the current drawn
(on any phase) exceeds the rated value to a substantial
degree. Over-current breakers are not normally used to
interrupt cases where an EV exceeds the signalled maximum
current by a moderate amount.
Common Variables: Tripped: Breaker opened; Operated:
RCD opened and auto-reclosed
OverCurrentBreaker
Recloser
Over-Current Breakers may have a motorized recloser
mechanism that may be configured to perform re-arm
retries after a trip (up to some specified number), or may be
set for remotely controlled re-arming on command.
Common Variables: Active: Reclosing; Problem: Fault;
Retries: Auto retry count
PlugRetentionLock Many socket type connectors have locking mechanisms to
retain an inserted plug, both to prevent on-load
Page 145 (198)
OCPP 2.0
Value Description
disconnection, and to prevent theft of charging cables. The
locking mechanism may be solenoid or motor operated, and
usually has self monitoring and retry mechanisms.
Common Variables: Active: Locked; Problem: FockingFailed;
Retries: Retries on last operation
PowerContactor Each EVSE channel (and/or possibly each Connector) must
have a main Power Contactor that switches on and off the
power to the EV after all authorization and safety
requirements have been met. Power Contactors are distinct
from safety/protection breakers, because they are designed
to make/break the maximum load current(s) on a regular
basis.
Because of their high switching power and regular
operation, they are more likely to fail than other
electromechanical components, and one common failure
mode ("welded contacts") is potentially dangerous as it can
leave sockets energized when they should be safe. For this
reason Power Contactors often have so-called "mirror
contacts", that allow the detection of the "stuck closed"
state.
Common Variables: Active: Contactor Closed (Power on);
Problem: Close/Open failed
ProfileExecutor The Profile Executor logical component is responsible for the
execution of a smart charging profile (schedule). For
ISO15118 capable EVs, this function is performed by the
vehicle itself. Otherwise the function is performed by EVSE.
Common Variables: Present & Available; Active: Profile in
progress; Complete: smart charging completed; Problem:
profile execution fault
RadioLink A Radio Link component provides a communications link
from a Charge Point to a Central System. It commonly uses
data modes of mobile telephony infrastructure, such as
GPRS.
High resilience implementations may include provision for
fallback arrangements, such as multiple SIMs, and can be
reported as multiple RadioLink components.
Page 146 (198)
OCPP 2.0
Value Description
connected; Problem: Communications module or link fault;
IMSI; ICCID; IPAddress; SignalStrength
RCD A Residual Current Device (US: ground fault breaker)
protects human life and/or downstream equipment by
quickly detecting abnormal curent flows (usually indicative
in earth faults) in the charge point, cable, or EV during
charging.
Common Variables: Tripped: RCD opened; Operated: RCD
opened and auto-reclosed
RCDRecloser RCD devices sometimes have a motorized recloser
mechanism that may be configured to perform re-arm
retries after a trip (up to some specified number), or may be
set for remotely controlled re-arming on command.
Common Variables: Active: Reclosing; Problem: Fault;
Retries: Auto retry count
SelfTest SelfTest is a virtual component, representing self test
mechanisms of the equipment (hardware and/or software).
Complete: self-test ended normally; Problem: self-test fault
SessionCoster SessionCoster is a virtual component, representing the
ability of the charge point/EVSE to perform local charging
session costing calculations (and usually display)
ShockSensor Measures impact forces/accelerations experienced (e.g. by
ChargePoint or spoke EVSE), indicative of possible damage.
Common Variables: acceleration value(s)
StartButton Some charge points (especially high power DC) may include
an explicit "Start" button (either a physical button or a
virtual button on a graphical user interface display) that
must be pressed by the user to commence charging.
Common Variables: Present & Available; Operated: Button
has been pressed; Active: Button is in the pressed state
StopButton Some charge points (especially high power DC) may include
an explicit "Stop" button (either a physical button or a
virtual button on a graphical user interface display) that can
or must be pressed by the user to terminate the charging
Page 147 (198)
OCPP 2.0
Value Description
session.
Common Variables: Present & Available; Operated: Button
has been pressed; Active: Button is in the pressed state
TiltSensor Measures Tilt angle from normal reference position
(normally 90 degree vertical), in degrees.
Common Variables: Angle value(s)
TokenReader Charge points (and individual EVSEs) may have an
authorization token reader component, commonly an
industry standard RFID reader.
Common Variables: Present & Available; Operated: token
data read event; Problem: token reader fault; TokenInfo:
Token data
UpstreamProtectionT
rigger
Charge points or physically separate (spoke) EVSEs may
include circuitry designed to trigger the disconnection of
power to the component by an upstream protection device
after a severe problem has been detected (usually impact
shock and/or tilt (usually an upstream RCD, by creating a
deliberate controlled earth fault).
Common Variables: Present & Available; Operated; Problem
WiredLink A Wired Link component represents a fixed infrastructure
communications link from a Charge Point to a Central
System.
It commonly uses shared networking infrastructure
(including the public internet), and protocols such as
Ethernet, xDSL, etc.
High resilience implementations may include provision for
fallback arrangements, such as multiple routing paths.
connected; Problem: Communications module or link fault; ;
IPAddress

11.21 ConfigurationStatus
Enumeration
Page 148 (198)
OCPP 2.0
Status in ChangeConfiguration.conf.
Value Description
Accepted Configuration key supported and setting has been
changed.
Rejected Configuration key supported, but setting could not be
changed.
NotSupported Configuration key is not supported.
11.22 ConnectorType
Enumeration
Allowed values of the ConnectorType Variable.
Note: This enumeration does not attempt to include every possible power connector
type worldwide as an individual type, but to specifically define those that are known
to be in use (or likely to be in use) in the charge points using the OCPP protocol.
In particular, many of the very large number of domestic electrical sockets designs
in use in many countries are excluded, unless there is evidence that they are or are
likely to be approved for use on charge points in some jurisdictions (e.g. as
secondary connectors for charging light EVs such as electric scooters). These light
connector types can be represented with the enumeration value
Other1PhMax16A.
All 3 phase connector types not explicitly enumerated should be represented as
Other3Ph.
Value Description
cType1 IEC62196-2 Type 1 connector (captive cabled)
a.k.a. J1772
cType2 IEC62196-2 Type 2 connector (captive cabled)
a.k.a. Mennekes socket
sType2 IEC62196-2 Type 2 socket
Page 149 (198)
OCPP 2.0
a.k.a. Mennekes connector
sType3 IEC62196-2 Type 2 socket
a.k.a. Scame
cCCS1 Combined Charging System 1 (captive cabled)
a.k.a. Combo 1
cCCS2 Combined Charging System 2 (captive cabled)
a.k.a. Combo 2
cG105 JARI G105-1993 (captive cabled)
a.k.a. CHAdeMO
Tesla Tesla Connector (captive cabled)
CEE-7-7 CEE 7/7 16A socket. May represent 7/4 & 7/5
a.k.a Schuko
sBS1361 UK domestic socket
a.k.a. 13Amp
s309-3P-16A 16A 3 phase IEC60309 socket
wInductive Wireless inductively coupled connection (generic)
wResonant Wireless resonant coupled connection (generic)
Other1PhMax16A Other single phase (domestic) sockets (16A max)
CEE7/17, AS3112, NEMA 5-15, NEMA 5-20, JISC8303,
TIS166, SI 32, CPCS-CCC, SEV1011, etc.
Other3Ph Other 3 phase sockets
NEMA14-30, NEMA14-50
Page 150 (198)
OCPP 2.0
11.23 Consumption
Class
This class holds the cumulative consumption costs in units.
tariffId integer 1..1 Mandatory. Identifier referring
to the tariff to which this
consumption applies.
tariffUnits float 1..1 Mandatory. Actual consumption
of the charge session in units,
like hours or kWh. In case of a
flat fee, totalUnits will be 1.

11.24 ComponentStatesCriterion
This class contains a collection of one or more ComponentCriterion elements,
that are logically ORed to determine inclusion of Components whose component
state matches any of the criteria.
matchComponentStat
e
ComponentCrite
rion
1..* One or more component
criterion states

11.25 ComponentCriterion
Enumeration
This enumeration specifies values (or combinations of values) of the common
component state boolean variables (Present,Available,Active,Fallback,Problem) and
the presence of active Monitoring on any of the components Variables as
qualification criteria for selection.
Where multiple ComponentCriterion values are used in combination, the result is
the logical OR of the individual criteria.
Value Description
Present Component is Present (but not necessarily
Available/Enabled)
Page 151 (198)
OCPP 2.0
Available Component is Available (but not necessarily remotely
Enabled)
Enabled Component is Enabled (Remotely or hard wired)
Active Component is in Active state (implies Present and
Available)
Problem Component is in Problem state (implies Present and
Available)
Fallback Component is in Fallback state (e.g. backup mode)
(implies Present and Available)
AnyAlertVariables Report all Variables and Components where the report
attribute of the Value is Alert AND where the report
attribute is Alert or Critical. (Critical implies Alert but is
more severe.)
AnyCriticalVariables Report all Variables and Components where the report
attribute of the Value is Critical.
AnyDeltaVariables Report all Variables and Components that have a Delta
value defined in their MonitoringCriteria
AnyPeriodicVariables Report all Variables and Components that have a
Periodicity interval defined in their MonitoringCriteria.

11.26 Cost
Class
Page 152 (198)
OCPP 2.0

The total amount to pay, as calculated by the Central System, is included in order
to support display, payment or printing of receipts at the Charge Point.
priceSchemeId integer 1..1 Mandatory. Identifier referring
to the price scheme used to
calculate the cost.
consumption Consumption 1..* Mandatory. Total consumption
in units.
currency ISO 4217 Code 1..1 Mandatory. Currency in which
totalCost is expressed.
totalNetCost double 1..1 Mandatory. Total cost of the
charge session including tax.
totalGrossCost double 0..1 Optional. Total cost of the
charge session excluding tax.

11.27 DataTransferStatus
Enumeration
Status in DataTransfer.conf.
Value Description
class Cost
Consumption
- tari ffId :i nt
- consumpti on :doubl e
Cost
- pri ceSchemeId :i nt
- currency :ISO4217
- totaNetCost :doubl e
- total GrossCost :doubl e
1..*
1
Page 153 (198)
OCPP 2.0
Accepted Message has been accepted and the contained request
is accepted.
Rejected Message has been accepted but the contained request
is rejected.
UnknownMessageId Message could not be interpreted due to unknown
messageId string.
UnknownVendorId Message could not be interpreted due to unknown
vendorId string.

11.28 DiagnosticsStatus
Enumeration
Status in DiagnosticsStatusNotification.req.
Value Description
Uploaded Diagnostics information has been uploaded.
UploadFailed Uploading of diagnostics failed.
11.29 Evse
Class
Evse as described in:
ChangeAvailibity.req
MeterValues.req
RequestStartTransaction.req
ReserveNow.req
TransactionStarted.req
UnlockConnector.req
id integer
id >= 0
1..1 Mandatory. The id of the Evse.
Id '0' (zero) is used to target
the entire charge point as a
whole
Page 154 (198)
OCPP 2.0
connectorType ConnectorType 0..1 Optional. Specific connector
type on a EVSE.

11.30 FirmwareStatus
Enumeration
Status of a firmware download as reported in FirmwareStatusNotification.req.
Value Description
Downloaded New firmware has been downloaded by charge point.
DownloadFailed Charge point failed to download firmware.
InstallationFailed Installation of new firmware has failed.
Installed New firmware has successfully been installed in charge
point.
Cancelled The firmware update has been cancelled.
CancelFailed The firmware update failed to be cancelled.
11.31 FirmwareErrorCode
Enumeration
Firmware errorcode reported in FirmwareStatusNotification.req.
Value Description
NoError No error to report.
OtherError Other type of error.
Timeout A timeout has occurred.
VerificationFailed The verification of the firmware file failed.

11.32 GenericStatus
Enumeration
A generic status which is used in:
Page 155 (198)
OCPP 2.0
Value Description
Accepted Indicating an Accepted value
Rejected Indicating an Rejected value
NotSupported Indicating an NotSupported value

11.33 IdTagInfo
Class
Contains status information about an identifier. It is returned in Authorisation, Start
Transaction and Stop Transaction responses.
expiryDate dateTime Optional. This contains the date at which
id-tag should be removed from the Local
List.
groupIdTag IdToken Optional. This contains the group-identifier.
status AuthorizationStatu
s
Mandatory. This contains whether the id-
tag has been accepted or not by the Central
System.
11.34 IdType
Enumeration
Value Description
Central1 A centrally generated id (e.g. in case of remote
activation by SMS). No format defined.
Central2 Another type of centrally generated id (e.g. in case of
remote activation by operator). No format defined.
EVCCID ID of an electric vehicle as specified in ISO15118
EVCOID EV contract id definition as defined in DIN 91286.
ISO7812 ISO/IEC 7812 identification card format that is used
for credit cards, debit cards, etc.
Page 156 (198)
OCPP 2.0
ISO14443 ISO 14443 UID of RFID card. It is a string of 4 or 7
bytes in hexadecimal representation.
ISO14443Reversed A UID format having the bytes in (non-standard)
reversed order.
Local1 A locally generated id (e.g. internal id created by the
Charge Point). No format defined.
Local2 Another type of locally generated id. No format
defined.
PhoneNumber A telephone number, with leading '+' if in standard
international form

11.35 IdToken
Class
Contains the identifier to use for authorisation. It is a case insensitive string. By
default if no idType is specified, an RFID UID is assumed.
Name Field Type Card. Description
id string[50] 1..1 Mandatory. Id is case insensitive.
idType IdType 0..1 Optional. Type of id. If absent type
ISO14443 (RFID) is assumed.

11.36 Imsi
Type
String for holding IMSI value, like in BootNotification.req. It is a case insensitive
string.
Imsi string[20] String is case insensitive.
11.37 KeyValue
Class
Page 157 (198)
OCPP 2.0
Contains information about a specific configuration key. It is returned in
GetConfiguration.conf.
key string[50] 1..1 Mandatory.
readonly Boolean 1..1 Mandatory. False if the value can be set
with the ChangeConfiguration message.
value string[500] 0..1 Optional. If key is known but not set, this
attribute may be absent.
11.38 LocalizedText
Class
language string[2] 1..1 Mandatory. ISO 639-1 language code.
text string[200] 1..1 Mandatory.

11.39 Location
Enumeration
Allowable values of the optional "location" attribute of a value element in
MeterValue.
Value Description
Inlet Measurement at network (grid) inlet connection
Outlet Measurement at an EVSE connection outlet
(Connector). Default value
Body Measurement inside body of charge point (e.g.
Temperature)

11.40 Measurand
Enumeration
Page 158 (198)
OCPP 2.0
Allowable values of the optional "measurand" attribute of a Value element, as used
in MeterValue. Default value of "measurand" attribute of Value is always
"Energy.Active.Import.Register"
Value Description
Energy.Active.Export.Register Energy exported by EV (Wh or kWh)
Energy.Active.Import.Register Energy imported by EV (Wh or kWh)
Energy.Reactive.Export.Register Reactive energy exported by EV (varh or
kvarh)
Energy.Reactive.Import.Register Reactive energy imported by EV (varh or
kvarh)
Energy.Active.Export.Interval Energy exported by EV (Wh or kWh)
Energy.Active.Import.Interval Energy imported by EV (Wh or kWh)
Energy.Reactive.Export.Interval Reactive energy exported by EV. (varh or
kvarh)
Energy.Reactive.Import.Interval Reactive energy imported by EV. (varh or
kvarh)
Power.Active.Export Instantaneous active power exported by
EV. (W or kW)
Power.Active.Import Instantaneous active power imported by
EV. (W or kW)
Power.Reactive.Export Instantaneous reactive power exported
by EV. (var or kvar)
Power.Reactive.Import Instantaneous reactive power imported
by EV. (var or kvar)
Current.Export Instantaneous current flow from EV
Current.Import Instantaneous current flow to EV
Voltage AC RMS supply voltage
Temperature Temperature reading inside charge point.
Page 159 (198)
OCPP 2.0
11.41 MeterValue
Class
Collection of meter values in MeterValues.req. Each value can optionally be
accompanied by one or more attributes.
timestamp dateTime 1..1 Mandaroy. Timestamp for
measured value(s).
value string 1..* Mandatory. Values for one or
more measurands. Value as a
Raw (decimal) number or
SignedData. Field Type is
string to allow for digitally
signed data readings. Decimal
numeric values are also
acceptable to allow fractional
values for measurands such
as Temperature and Current.
attribute:
context
ReadingContext 0..1 Optional. Type of detail value:
start, end or sample. Default
= Sample.Periodic
attribute:
format
ValueFormat 0..1 Optional. Raw or signed data.
Default = Raw
attribute:
measurand
Measurand 0..1 Optional. Type of
measurement. Default =
Energy.Active.Iimport.Registe
r
attribute:
location
Location 0..1 Optional. Location of
measurement.
Default=Outlet
attribute:
unit
UnitOfMeasure 0..1 Optional. Unit of the value.
Default = Wh if the (default)
measurand is an Energy
type.
Page 160 (198)
OCPP 2.0
11.42 MonitoringBase
Enumeration
Standard monitoring configurations for SetMonitoring
Value Description
None No monitoring base: only explicitly specified items are
monitored & reported
Minimal Only monitor & report critical states and fault events
that impact the safety or usability of the charge point
FactoryDefault Standard monitoring for normal operational use
All Monitor & report everything that can be reported
11.43 MonitoringType

attribute:
id
integer 0..1 Optional. An id that can be
used to refer to the specific
event.
attribute:
alertUpper
Decimal 0..1 Optional. Upper alerting level
threshold
attribute:
alertLower
Decimal 0..1 Optional. Upper alerting level
threshold
attribute:
criticalUpper
Decimal 0..1 Optional. Upper critical level
threshold
attribute:
criticalLower
Decimal 0..1 Optional. Upper critical level
threshold
attribute:
delta
Decimal 0..1 Optional. Minimum absolute
variable value change (from
previously reported) to trigger
further report.
Monitoring and reporting of
changes in the boolean (1/0)
state variables of any Component
Page 161 (198)
OCPP 2.0
(e.g. Active, Problem) can be
achieved by setting delta=1
attribute:
periodic
Integer 0..1 Optional. Time interval, in
seconds, between periodic
reports ov Variable value.
attribute:
clockaligned
boolean 0..1 Optional. When true, periodic
sampling is clock-aligned to
trigger at midnight and each
successive periodic interval
from midnight

11.44 Notice
Class
A Notice can contain information about the values of component variables,
describing an event, data sampling (based on time or value change), or response to
an explicit state data request by the Central System.
See diagram in section 8.3 for a visual representation of a Notice and its sub-
elements.
attribute:
id
integer 0..1 Optional. An id that can be
used to refer to the specific
event.
attribute:
cause
string 0..1 Optional. Cause of the event.
(In future versions of OCPP,
this attribute can be used to
connect events into logical
chains. E.g.: event charge
restriction caused by event
overheating caused by
fanspeed low.)
attribute:
trigger
TriggerType 1..1 Mandatory. Indicates why the
event message was triggered.
attribute: dateTime 1..1 Mandatory. Timestamp for the
Page 162 (198)
OCPP 2.0
at event.
component component 1..* Mandatory. The component
(or possibly components) in
which the event originated as
specified in the sub-type
Component type.

11.45 ReadingContext
Enumeration
Values of the context attribute of MeterValue.
Value Description
Interruption.Begin Value taken at start of interruption.
Interruption.End Value taken when resuming after interruption.
Sample.Clock Value taken at clock aligned interval.
Sample.Periodic Value taken as periodic sample relative to start time of
transaction.
Transaction.Begin Value taken at end of transaction.
Transaction.End Value taken at start of transaction.
11.46 PhaseRotation
Enumeration
Allowed values of the PhaseRotation Variable
Relative phase wiring for 3-phase supplies.
For Charge Points, the 3-phase wiring relative relative to other charge points on the
same 3-phase supply (or to the upstream feed reference).
For EVSEs or Connectors, the 3-phase wiring relative relative to the incoming
charge point power supply.

Page 163 (198)
OCPP 2.0
Value Description
RST Standard Reference phasing
STR Standard 120 degree rotation
TRS Standard 240 degree rotation
RTS Reversed Reference phasing
TSR Reversed 120 degree rotation
SRT Reversed 240 degree rotation

11.47 PriceScheme
Class

priceSchemeId integer 1..1 Mandatory. Unique identifier of
the price scheme.
displayText LocalizedText 0..* Optional. Description in
multiple languages of this price
class Pricing
PriceScheme
- pri ceSchemeId :i nt
- di spl ayText :Local i zedText [0..*]
- connector :ConnectorType
- expi ryDate :DateTi me
Tariff
- tari ffId :i nt
- di spl ayText :Local i zedText [0..*]
- currency :ISO4217
- pri ci ngUni t :Pri ci ngUni t
- pri ceNet :doubl e
- pri ceGross :doubl e
- taxPct :doubl e
- condi ti on :stri ng
Enumerati on
PricingUnit
Sessi on
kWhToEV
OccupancyHours
Chargi ngHours
Idl eHours
LocalizedText
- l anguage :ISO639-1
- text :stri ng
1..*
1
Page 164 (198)
OCPP 2.0
scheme for display on Charge
Point.
connector ConnectorType 0..1 Optional. The type of connector
to which this price scheme
applies. If absent, the scheme
applies to all connectors.
expiryDate DateTime 0..1 Optional. The point in time at
which this scheme ceases to be
valid. Use this to prevent the
use of an expired price scheme
when the Charge Point is offline
for a long period of time.
tariff Tariff 1..* Mandatory. One or more tariffs
that make up the price scheme.
11.48 PricingUnit
Enumeration
Value Description
Session Single unit per transaction. Use for flat fee rate or
access fee.
kWhToEV Energy transfer to EV.
OccupancyHours Total time in hours spent connected to the Charge
Point. Use to charge for connection time instead of
energy usage or use to charge for parking on top of
energy usage.
IdleHours Time in hours connected to the Charge Point, but not
charging.
ChargingHours Time in hours connected to the Charge Point while
charging.

11.49 PowerType
Enumeration
Allowed values of the PowerType Variable
Page 165 (198)
OCPP 2.0
Value Description
AC Alternating Current (single or 3-phase)
DC Direct Current
ACDC AC and/or DC
11.50 RecurrencyKindType
Enumeration
Value Description
Daily Daily: The schedule restarts at the beginning of the next
day.
Weekly The schedule restarts at the beginning of the next week
(defined as Monday morning)
11.51 RegistrationStatus
Enumeration
Result of registration in response to BootNotification.req.
Value Description
Accepted Charge point is accepted by Central System.
Rejected Charge point is not accepted by Central System. This
happens when the charge point id is not known by
Central System.
11.52 ReportingStatus
Enumeration
Status in GetStateReport.conf and SetMonitoring.conf.
Value Description
Accepted Request is understood and supported, and will be
produced
NotSupported Request is understood but not supported.
Page 166 (198)
OCPP 2.0
Rejected Request is not understood.

11.53 ReservationStatus
Enumeration
Status in ReserveNow.conf.
Value Description
Accepted Reservation has been made.
Faulted Reservation has not been made, because connectors
or specified connector are in a faulted state.
Occupied Reservation has not been made. All connectors or the
specified connector are occupied.
Rejected Reservation has not been made. Charge Point is not
configured to accept reservations.
Unavailable Reservation has not been made, because connectors
or specified connector are in an unavailable state.

11.54 ResetStatus
Enumeration
Result of Reset.req.
Value Description
Accepted Command will be executed.
Rejected Command will not be executed.
11.55 ResetType
Enumeration
Type of reset requested by Reset.req.
Value Description
Page 167 (198)
OCPP 2.0
Hard Full reboot of Charge Point software.
Soft Return to initial status, gracefully terminating any
transactions in progress.
11.56 RequestedEnergyTransferEnum
Enumeration
Value Description
Ac
AC charging
DcIso
DC charging ISO
DcChademo
DC charging Chademo
11.57 RequestStartStopStatus
Enumeration
The result of a RequestStartTransaction.req or RequestStopTransaction.req request.
Value Description
11.58 SalesTariffTable
Class
Used for smart charging operations.
salesTariffId integer 1..1 Mandatory. Identifier used to
identify one sales tariff.
tariffDescription string(32) 0..1 Optional. A human readable
short description (for
visualization and reporting).
maxEPriceLevel integer 1..1 Mandatory. Defines the
maximum number of distinct
price levels across all provided
Page 168 (198)
OCPP 2.0
sales tariff tables (e.g. on-
peak, mid-peak, off-peak).
tariffPeriods TariffPeriod 1..* Mandatory. List of TariffPeriod
elements.
11.59 SupplyPhases
Enumeration
Allowed values of the SupplyPhases Variable
Number of alternating current phases connected/available
Value Description
0 DC
1 Single Phase
3 Three Phase
G105 JARI G105-1993 (CHAdeMO)
11.60 StateReportBase
Enumeration
Standard reporting configurations for GetStateReport
Value Description
None No standard report base: only explicitly specified data
is returned.
Boot Report:
AvailabilityState of each EVSE
AvailabilityState of Charge Point overall
All Components in Problem State
All Component.Variables in Critical or Alert status
Page 169 (198)
OCPP 2.0
Inventory Enumerate:
All present/installed Components (including multi-
occurrence)
All Variables defined for each component (including
multi-occurrence variables)
All values for each component variable
11.61 Tariff
Class
Used in price schemes to contain a description and price for a PricingUnit.
tariffId integer 1..1 Mandatory. Unique identifier of
the tariff.
displayText LocalizedText 0..* Optional. Description in
multiple languages for
displaying on the Charge Point.
pricingUnit PricingUnit 1..1 Mandatory. The unit to which
the price applies.
currency ISO 4217 Code 1..1 Mandatory. Currency of price in
the tariff.
priceNet double 0..1 Optional. The price for one unit
including tax. It may be
omitted if variable prices are
used and cost calculation can
only be done on the Central
System.
priceGross double 0..1 Optional. The price for one unit
excluding tax. Calculated as
100 * priceNet / (100 +
taxPct).
taxPct double 0..1 Optional. Percentage of value-
added tax.
Page 170 (198)
OCPP 2.0
condition string[500] 0..1 Optional. The conditions under
which this tariff is applicable.
The format is not specified and
left to the implementer. It is
intended to be standardized in
a next release of OCPP.

11.62 TariffPeriod
Class
Used for smart charging operations to define the relative price level of a period.
startPeriod integer 1..1 Mandatory. Start of the period,
in seconds from the start of
schedule. The value of
StartPeriod simultaneously
defines the stop time of the
previous period.
periodDescription string(32) 0..1 Optional. A human readable
short description (for
visualization and reporting).
ePriceLevel integer 1..1 Mandatory. Defines the price
level of this period. 0 if
comparison of price levels shall
not be used (e.g. because
payment is handled by external
means).
11.63 TransactionData
Class
Details of transaction usage in TransactionStopped.req.
values MeterValue 0..1 Optional. Meter values
related to a transaction.

Note: In 1.5 the cardinality
Page 171 (198)
OCPP 2.0
was mistakenly 0..*
11.64 TransactionId
Union
A transaction id can either be an integer or a string. The integer TransactionId is
backwards compatible with previous versions of OCPP and is convenient when
transaction ids are generated by the Central System.
The string version of a transaction id is big enough to hold a universally unique
identifier (UUID) or other forms of unique identifiers. TransactionIdString MUST be
used when using locally generated transaction ids and MAY be used for centrally
generated transaction ids.
In all messages in chapter 9 that contain a field TransactionId, the field
TransactionIdString MAY be used instead.
TransactionId integer Numeric transaction id.
TransactionIdString string[50] String representation of a
transaction id.

11.65 TriggerType
Enumeration
Reason category for creation of Notice
Value Description
Alerting Monitored variable has passed an Alert or Critical
threshold
Delta Delta Monitored Variable value has changed by more
than specified amount
Periodic Periodic Monitored Variable has been sampled for
reporting at the specified interval
Completion Activity has completed (e.g. charging session ended)
StateRequested State data explicitly requested (by GetStateReport
Page 172 (198)
OCPP 2.0
command)
MonitoringRequested Monitoring criteria explicitly requested (by
GetMonitoringCriteria command)
11.66 UnitOfMeasure
Enumeration
Allowable values of the optional "unit" attribute of a Value element, as used in
MeterValues.req and TransactionStopped.req messages. Default value of "unit"
attribute of Value is always "Wh".
Value Description
Wh Watt-hours (energy). Default.
kWh kiloWatt-hours (energy).
varh Var-hours (reactive energy).
kvarh kilovar-hours (reactive energy).
W Watts (power).
kW kilowatts (power).
var Vars (reactive power).
kvar kilovars (reactive power).
Amp Amperes (current).
Volt Voltage (r.m.s. AC).
Celsius Degrees (temperature).
11.67 UnlockStatus
Enumeration
Status in response to UnlockConnector.req.
Value Description
Page 173 (198)
OCPP 2.0
11.68 UpdateStatus
Enumeration
Type of update for a SendLocalList.req.
Value Description
Accepted Local authorisation list successfully updated.
Failed Failed to update the local authorisation list.
HashError The hash value computed over the received values
does not match provided hash value.
NotSupported Update of local authorisation list is not supported by
Charge Point.
VersionMismatch Version number in the request for a differential
update is less or equal then version number of current
list.

11.69 UpdateType
Enumeration
Type of update for a SendLocalList.req.
Value Description
Differential Indicates that the current local authorisation list must
be updated with the values in this message.
Full Indicates that the current local authorisation list must
be replaced by the values in this message.

11.70 ValueFormat
Enumeration
Format that specifies how the value element in MeterValue is to be interpreted.
Page 174 (198)
OCPP 2.0
Value Description
Raw Data is to be interpreted as integer/decimal numeric
data.
SignedData Data is represented as a signed binary data block,
encoded as hex data.
11.71 ValBool
Type
General purpose boolean class for Variable value reporting
valBool boolean True or false; 1 or 0
11.72 ValDec
Type
General purpose decimal number for Variable value reporting
valDec decimal Any valid decimal value
11.73 ValInt
Type
General purpose integer number class for Variable value reporting
valInt integer Any valid integer value
11.74 ValText
Type
General purpose text string class for Variable value reporting
Page 175 (198)
OCPP 2.0
valText String[1000] String of maximum length 1000 characters
11.75 ValNull
Type
General purpose content-free classs for reporting unavailable Variable data values
valNull String[0] String of maximum 0 characters
11.76 ValueType
Enumeration
Specifies configuration settings types for Value elements of device model Variables.
Value Description
Value Actual Variable Value.
Value is the implicit default for Variable data transfers
from Charge Point to Central System.
Set Explicitly set value (may subsequently change).
Set is the implicit default for configuration setting
Variable Values sent from Central Systems to Charge
Points.
MinSet Minimum value configured for variable
MaxSet Maximum value configured for variable
MinLimit Minimum limit value for variable (e.g. design limit)
MaxLimit Maximum limit value for variable (e.g. design limit)
11.77 ValueUnion
Union
The ValueUnion union is used to contain a reported value of a Variable, using
alternate sub-elements, based on the intrinsic datatype (boolean, integer, decimal,
text, or specific enumeration) of the Variable. A Variable can have multiple values.
Page 176 (198)
OCPP 2.0
For example because multiple phases are reported on or when reporting voltage,
current and power.
Note 1: Items with cardinality marked ! are mutually exclusive (union)
Note 2: The absence of any available data for a variable value can be signaled by
use of the empty valNull sub-element of ValueUnion.

attribute:
unit
0..1 Optional. Default units are
specified in the variableName
type. If the default unit is
used, the attribute is optional.
attribute:
valueType
ValueType 0..1 Optional. Used to specify
setting (default), or range
minimum, or maximum for
values
attribute:
techcode
string 0..1 Optional. Contains the ID used
by the manufacturer to
describe a state of the
Variable. Technical codes are
commonly hardware or
software status/fault codes.
Interpretation of Technical
Code data is usually specific to
the manufacturer/model of
the component.
attribute:
techinfo
string 0..1 Optional. Can contain helpful
information included by the
manufacturer on the current
state, or last event, of a
component. It is commonly
contextual technical data
associated with an event/fault
and is usually specific to the
manufacturer/model of the
component.
Page 177 (198)
OCPP 2.0
availabilityState AvailabilityState 0..1 ! Enumeration for reporting the
AvailabilityState Variable
chargeProtocol ChargeProtocol 0..1 ! Enumeration for reporting the
ChargeProtocol Variable
powerType PowerType 0..1 ! Enumeration for reporting the
PowerType Variable
connectorType ConnectorType 0..1 ! Enumeration for reporting the
ConnectorType Variable
phaseRotation PhaseRotation 0..1 ! Enumeration for reporting the
PhaseRotation Variable
supplyPhases SupplyPhases 0..1 ! Enumeration for reporting the
SupplyPhases Variable
valBool ValBool 0..1 ! Boolean datatype for reporting
boolean Variable values
valInt ValInt 0..1 ! Integer datatype for reporting
integer Variable values
valDec ValDec 0..1 ! Decimal datatype for reporting
decimal Variable values
valText Val 0..1 ! Decimal datatype for reporting
decimal Variable values
valNull ValNull 0..1 ! Explicit Null datatype for
reporting unavailable Variable
values

11.78 VariableCriteria
This class contains a collection of one or more VariableCriterion elements, that
are logically ORed to determine selection/inclusion of Variables.
matchVariable VariableCriterion 1..* One or more component
criterion states
Page 178 (198)
OCPP 2.0
11.79 VariableCriterion
Enumeration
This enumeration specifies attributes (primarily Monitoring) of the Variables as
qualification criteria for selection.
Where multiple VaribaleCriterion values are used in combination, the result is the
logical OR of the individual criteria.
Value Description
Alerting Include Variable if any Alert or Critical monitoring is
in effect on it
Delta Include Variable if Delta monitoring is in effect on it
Periodic Include Variable if Periodic monitoring is in effect on
it
Settable Include (all) Variable Values (value,set,min,max),if
configurable (settable) by Central System.
By requesting a State report with this Variable criterion
(across all or specific Components), a Central System
can receive an exhaustive enumeration of all
configurable options on a Charge Point.
11.80 Variable
Every component should contain at least one instantiation of this type.
attribute:
name
variableName 1..1 The name of the Variable as
described in the VariableName
type.
attribute:
index
integer The index is optional. If no
index is specified the variable
is the only variable of its kind
for the related component.
attribute:
unit
0..1 Optional. Default units are
specified in the variableName
type. If the default unit is
Page 179 (198)
OCPP 2.0
used, the attribute is optional.
value ValueType 0..* Optional. This union sub-
element carries the value of a
variable, based on its data
type, as specified in the
variableValue type.
variableCriteria VariableCriteria 0..* Optional. This sub-element
carries variable specific
selection criteria.
Only applicable to use of
Variable within Component
within getStateReport.
monitoring MonitoringType 0..* Optional. Carries the current
monitoring criteria for the
Component Variable
Page 180 (198)
OCPP 2.0
11.81 VariableName
This type lists the VariableNames and corresponding datatypes and enumerations and gives descriptions and
examples to clarify.

Name Values Description Examples
Booleans. The default is false/0.
Present 1 (true) Component is present/physically
installed, but not necessarily
Available/Enabled. The
"absence" (Present=false) is
never reported.
All.
This Variable is only used during
self-enumeration reports from the
charge point.
Available 0 (false)
1 (true)
The Component is Present and
locally configured for use (e.g.
reset, fuse replaced, not
Tripped), but is not necessarily
(remotely) Enabled.
ChargePoint, EVSE or Connector:
Not Faulted AvailabilityState
AcDcConverter: Functional
(Single-shot) ShockSensor:
Capable of generating a Shock
event.
Enabled 0 (false)
1 (true)
The Component is Present,
Available, and Enabled for
operation. For Available
components that cannot be
selectively (remotely) enabled /
disabled, this value is always
true.
ChargePoint, EVSE or Connector:
In normal operation (not Faulted or
Inoperative AvailabilityStates)
BayOccupancySensor: Actively
sensing (occupancy event reporting
depends on Monitoring status of
Active state)
Tripped 0 (false) Single-shot device requires
explicit intervention to re-
OverCurrentBreaker: tripped.
RCD: tripped. EVChargingSession:
Page 181 (198)
OCPP 2.0
1 (true) prime/activate to normal. terminated abnormally
Fallback 0 (false)
1 (true)
Component is operating in a
fallback, or backup mode.
In an inventory report, a Value of
1 for the MAxLimit ValueType
indicates that the component can
enter a fallback state (i.e. a
fallback mode is present).
Only Components that are
Present can be in the Fallback
state
ELVSupply: on battery power.
Controller: on backup firmware
image. RadioLink: using backup
provider/SIM.
Operated 1 (true) The Component operated in an
instantaneous, transient, or
immediately self-resetting
pattern. Used only in event
reports, where it is always true.
TokenReader: detected an RFID
card. StopButton: pressed.
RCDRecloser: re-closed.
ShockSensor: significant
acceleration value detected
Complete 1 (true) Component's operation cycle has
completed. Used only in event
reports, where it is always true.
EVChargingSession: ended
normally. Controller: self-test
sequence completed
Active 0 (false)
1 (true)
Component is in its non-resting /
active state: E.g: On, Engaged,
Locked.
Only components that are
Present, Available, and
Enabled- can be in the Active
ConnectorProtection: shutter open.
PlugRetentionLock: locking pin
engaged. Power contactor: relay
closed. AcDcConverter: unit "on".
EmergencyStopSensor: button
depressed. AccessDetector: door
open
Page 182 (198)
OCPP 2.0
state.
changes in the Active boolean
state of any Component can be
achieved by enabling monitoring
with a delta=1
EVChargingSession: ongoing
Problem 0 (false)
1 (true)
Component itself is in a
"Problem" condition.
This is distinct from a problem at
the parent level. E.g. if the plug is
not locket the connector can still
function.
Only components that are
Present can be in the Problem
state.
changes in the Problem boolean
state of any Component can be
achieved by enabling monitoring
with a delta=1
Fiscal Meter: cannot be read
Ventilator: fan slow/stalled.
RadioLink: communications module
cannot connect.
Overload 0 (false)
1 (true)
Component is in Overload state. EVSE, Connector or Session taking
higher current than allowed.
Enumerations
ChargeProtocol Valid values of the
ChargeProtocol data
The Charging Control Protocol
applicable to the Charge Point,
EVSE, or Connector. NOTE:
Connector: Charging Protocol
supported by Connector. EVSE:
Charging Protocol currently in
Page 183 (198)
OCPP 2.0
type orthogonal to ConnectorType.
Examples:
operation.
ConnectorType Valid values of the
ConnectorType
Specific type of connector,
including sub-variant information.
NOTE: Distinct and orthogonal to
Charging Protocol, Power Type,
Phases.
Connector: type of Connector

EVSE: ConnectorType currently in
use.

PowerType Valid values of the
PowerType data type
The type of power available from
Charge Point, EVSE, or Connector
Connector: Power types available:
e.g. ACorDC (CCS Connector)
AvailabilityState Valid values of the
AvailabilityState data
type.
Replicates the ChargePointStatus
values reported by the
StatusNotification in OCPP 1.5.
If a component is unavailable its
parent can still be available. E.g.
if a Charge Point has 2 EVSEs
and 1 is unavailable the Charge
Point is available. If part of the
EVSEs is reserved and part is
occupied the ChargePoint is
reported reserved.
Connector. Inoperative: Connector
has been commanded into
Inoperative state. Occupied:
connector is connected ("plugged
in").
SupplyPhases {Null}
0
1
3
Number of alternating current
phases connected/available. 1 or
3 for AC, 0 means DC (no
alternating phases). Null value
indicates that the number of
phases (e.g. in use) is unknown.

Page 184 (198)
OCPP 2.0
PhaseRotation RST
STR
TRS
The relative phase wiring of
EVSE's and/or Connectors with
respect to the incoming Charge
Point Supply.

Integers
WidthInChars {Null}: Unknown
0: No Display
1-N: Display width in
characters
Currently used only to describe a
display size.
Display: 16-40 typically
Height
InChars
{Null}: Unknown
0: No Display
1-N: Display height in
characters
Currently used only to describe a
display size.
Display: 1-20 typically
Retries {Null}: Unknown
0: No Retries
1-N: up to N retries
For self-monitoring electro-
mechanical equipment, the
Retries count is the number of
retries (excluding the original
attempt) in the last successful, or
attempted, cycle of operation
RCDRecloser: Number of times
retried on last re-close. E.g.
indicative for actuators starting to
fail.
Decimals (with default units)
ACVoltage RMS AC Voltage (in volts):
1 value: single phase to neutral
2 values: phase - neutral &
neutral earth
3 values: 3 x phase to neutral
4 values: 3 x phase to neutral +
ChargePoint: Input Voltage
Page 185 (198)
OCPP 2.0
neutral-earth
ACCurrent RMS AC Current (in amperes):
1 value: single phase current
3 values: 3 x phase current
4 values: 3 x phase current +
neutral current
ChargePoint: Total Current (all
EVSE's + ancillaries)
EVSE: "Billable" current to EV:
includes losses (AC->DC) and
ancillaries (e.g. fans)
DCVoltage Instantaneous DC Voltage (volts) EVSE: DC output voltage
DCCurrent Instantaneous DC Current (in
amperes)
EVSE: output current
Power Instantaneous (real) Power
(measured/calculated, including
power factor for AC) (in kW)
ChargePoint: total power
consumption (all EVSE's +
ancillaries). EVSE: "Billable" power
to EV: includes losses (AC->DC)
and ancillaries (e.g. fans)
EnergyToEV Total energy transferred to EV
during (ongoing or terminated)
charging session (in wH by
default)
ChargePoint: total energy
consumed (all EVSE's + ancillaries)
EVSE: "Billable" energy to EV:
includes losses (AC->DC) and "per
EVSE" ancillaries (e.g. fans)
EnergyFromEV Total energy transferred from EV
during (ongoing or terminated)
charging session (in wH by
default)
ChargePoint: total energy exported
(all EVSE's - ancillaries)
EVSE: "Billable" exported energy to
grid: excludes losses (DC->AC)
and per EVSE ancillaries (e.g. fans)
EnergyRegisterToEV Cumulative import kWh display
value from an (certified) fiscal
EVSE: "Billable" energy to EV:
includes losses (AC->DC) and "per
Page 186 (198)
OCPP 2.0
energy meter (in wH by default) EVSE" ancillaries (e.g. fans)
VoltageImbalance Percentage voltage imbalance in
three phase supply
ChargePoint: Imbalance
percentage of incoming supply
voltages
CurrentImbalance Percentage current imbalance in
three phase supply

Frequency Frequency of AC power or signal
(usually grid frequency)

ConnectedTime Time EV is connected to a charge
point in a single (physical/logical)
session (in seconds)
EVSE: EV connected time
ChargingTime Total time that EV is taking
(significant) energy from an EVSE
(in seconds). Short pauses in
charging (e.g. battery pre-
conditioning, post-conditioning)
are included.
EVSE: EV charging time.
PostChargingTime Total time since EV has taken
energy from EVSE. (in seconds)
This may, for example, be used as
the basis for a "parking time" fee.
Temperature Temperature(s) of component (in
Celsius, by default). Components
may have multiple indexed
sensors.
AcDcPowerConverter: Temperature
sensor(s) on IGBT heatsink
Humidity The relative humidity in %. Note:
Not absolute humidity or specific
ChargePoint: Internal ambient air
Page 187 (198)
OCPP 2.0
humidity relative humidity
Light The ambient light level. The value
is in Lux.

Regulate the on/off or brightness
state of integral or external
environmental lighting.
Force Newtons or g Reports (impact) force/
acceleration values (estimates) in
one or more directions, in units of
Newtons (default) or g.
By definition the order is X
(rightwards), Y (forwards) and Z
(upwards).
Conveys how hard a ChargePoint
was hit by a car and may explain
malfunctions.
Angle Tilt angle from vertical. First
angle is rightwards and second
angle forwards.
Conveys how far the Charge Point
is tilted after an accident and can
be used to disable a chargepoint
for safety reasons.
FanSpeed Fan Speed in RPM. A fan speed of
0 represents stopped/stalled.
{Null} means unknown.
As ubiquitous but delicate moving
components fans are a frequent
source of problems.
Impedance GroundIsolationTester:
Isolation Impedance
Impedance in Ohm: Either real
(resistive) impedance (single
value), or a complex impedance
(at nominal mains frequency)
with resistive and reactive
(inductive/capacitative) parts, as
two values.
GroundIsolationTester: Isolation
Impedance
Page 188 (198)
OCPP 2.0
Time Time Time, in ISO 8601 datetime
format. Time zone optional.
Clock:
Time[1]: Current Time
Value example:
2013-09-27T20:12:34+01:00
TimeOffset Offset in hours Time Offset with respect to
Coordinated Universal Time (aka
UTC or Greenwich Mean Time) in
the form of an ISO 8601 time
(zone) offset suffix, including the
mandatory "+" or "-" prefix
Clock:TimeOffset represents the
configured operating timezone of a
charge point
Timeout seconds
Timeout for Component operation (in
seconds)
EVConnection:Maximum wait time
for user to connect
Interval Seconds Repeat interval for component
operation (in seconds)
Controller: Heartbeat Interval
SignalStrength Mobile Radio data signal strength,
in dbmW (typically -140 to -50)
or ASU (typically 0-31 or 99 for
unknown).
RadioLink: Signal strength as
reported by mobile data module.
StateOfCharge State of Charge Percentage value,
as reported by EV
EVChargingSession: EV State of
Charge
ELVSupply: rechargeable backup
battery SOC
Percent {Null}: unavailable
0-100: Percentage of
Can be used by miscellaneous
analogue input sensors and/or
BayOccupancySensor: Strength of
"occupied" signal, BeaconLighting:
Page 189 (198)
OCPP 2.0
maximum output controllers. Relative lighting inetnsity
Text strings. Unavailable is represented by {Null}.
Colour Colour values, expressed as
standard 24 bit hexadecimal RGB
values. E.g. 000000: Black,
FF0000: Red, 00FF00: Green,
0000FF: Blue, FFFF00:Yellow,
FFFFFF: White
Beacon Lighting: Displayed Colour
ChargingStatusIndicator: Displayed
Colour
TokenInfo A typed authorization Id structure
State An arbitrary "state name"
identifier string to allow controller
components to report their
current internal state
Controller: Main charge point
controller state
Controller[EVSE=2]: State of 2nd
EVSE sub-controller
DataText General purpose micellaneous
data from a Component, in text
form

OtherVariable Container for variables that are
not (yet) listed in this
variableName type. They MAY be
accompanied by an otherName
attribute to Variable that enables
giving a unique name to an
otherVariable.

OperatingTimes iCal RRULE text Recurring operating times in
iCalendar RRULE format.
ChargePoint: operating times
Page 190 (198)
OCPP 2.0
Manufacturer Component Manufacturer name
Model Manufacturer's Model
code/number of Component,
including suffixes etc. to identify
functional, regional or linquistic
variation.

ECVariant EC Variant code Production series variants
reflecting internal design changes
or sub-component substitutions
not affecting external
functionality.

SerialNumber Serial Number Serial number of Component
VersionNumber Version Number Version Number of
software/firmware

VersionDate DateTime Issue date or datetime of
software/firmware

ICCID
ICCID (Integrated Circuit Card
IDentifier) of mobile data SIM
card.

IMSI
IMSI (International Mobile
Subscriber Identity) number of
mobile data SIM card
AcDcConverter: diagnostic data
RadioLink: connection failure error
message
Page 191 (198)
OCPP 2.0
IPAddress
Assigned IP address of
communications link of a specific
component.
RadioLink: 192.168.23.45
WiredLink: 2001:db8:0000:0:1::1
Page 192 (198)
OCPP 2.0
Appendix A: Configuration Key/Value Pairs
This appendix describes the standardized Charge Point configuration options that
are defined for the key value of ChangeConfiguration in OCPP 2.0.
Note: ChangeConfiguration is DEPRECATED in OCPP 2.0, and is expected to be
removed in a future version.

Implementers SHOULD use the new SetConfiguration message of OCPP 2.0, which
supports more fine-grained configuration, is consistent with the Device Model, and
allows multiple configuration changes to be made in a single message.

Every ChangeConfiguration key value is now treated as a shorthand alias for the
normative equivalent Component.Variable based configuration value used in
SetConfiguration.

The correspondence mapping from key to Component.Variable is documented in
the table below, for each key value.
The options are grouped based on their purpose to optionally explain the expected
behaviour when used.
For options that are not described and thus are Charge Point manufacturer specific
it is recommended to use a default naming convention for the options.
Recommendation is to use an option prefix with a naming scheme:
<manufacturer_company_name>_<option name>
Example:
A manufacturer named ACME needs a specific Charge Point option called
rebootWhenIdle it is advised to call this option acme_rebootWhenIdle
In this case it is clear that this option is manufacturer specific and thus immediately
recognizable.
1. General Purpose
Key-Name Format Units Key-Value
ChargeBoxSerialNu
mber
The serial number of the Charge Point
inside the Charge Point..
[case insensitive, size <= 25
characters]
Page 193 (198)
OCPP 2.0
FirmwareVersion String Firmware version of the Charge Point.
characters]
ResetRetries int times Number of times to retry an unsuccessful
reset of the charge point.
BlinkRepeat int times Number of times to blink charge point
lighting when signalling
HeartBeatInterval
Controller
.Interval
int

seconds Interval of inactivity (no OCPP exchanges)
with central system after which the
charge point should send a Heartbeat.req
PDU
ConnectionTimeOut
EVConnection
.Timeout
int

seconds Interval (from successful authorization)
until incipient charging session is
automatically cancelled due to failure of
EV user to (correctly) insert the charging
cable connector(s) into the appropriate
socket(s).
ResetRetries
Controller
.Retries
int times Number of times to retry an unsuccessful
reset of the charge point.
BlinkRepeat
ChargingStatus
Indicator
.Count
int times Number of times to blink charge point
lighting when signalling
Iccd String The ICCID of the modem's SIM card.
characters]
LightIntensity
BeaconLighting
.Percent
int % Percentage of maximum intensity at
which to illuminate Charge Point lighting
MeterSerialNumber String The serial number of the main power
meter.
Page 194 (198)
OCPP 2.0
characters]
MeterType String The type of the main power meter of
the Charge Point.
characters]
ClockAlignedDataInter
val
FiscalMetering
.Interval
int seconds Size (in seconds) of the clock-aligned
data interval. This is the size (in seconds)
of the set of evenly spaced aggregation
intervals per day, starting at 00:00:00
(midnight). For example, a value of 900
(15 minutes) indicates that every day
should be broken into 96 15-minute
intervals.
When clock aligned data is being
transmitted, the interval in question is
identified by the start time and (optional)
duration interval value, represented
according to the ISO8601 standard. All
"per-period" data (e.g. energy readings)
should be accumulated (for "flow" type
measurands such as energy), or averaged
(for other values) across the whole
interval (or partial interval, at the
beginning or end of a charging session),
and transmitted (if so enabled) at the end
of each interval, bearing the interval start
time timestamp.
A value of "0" (numeric zero), by
convention, is to be interpreted to mean
that no clock-aligned data should be
transmitted.
MeterType String The type of the main power meter of
the Charge Point.
characters]
MeterValuesSampledD
ata
CSL
1
Sampled measurands to be included in a
MeterValues.req PDU, every

1
CSL: Comma Separated List

Page 195 (198)
OCPP 2.0
ControlMetering
.DataText[1]
MeterValueSampleInterval seconds.
Default: Energy.Active.Import.Register
MeterValuesAlignedDat
a
FiscalMetering
.DataText[1]
CSL Clock-aligned measurand(s) to be
included in a MeterValues.req PDU, every
ClockAlignedDataInterval seconds.
MeterValueSampleInte
rval
ControlMetering
.Interval
int seconds Interval between sampling of metering
(or other) data, intended to be
transmitted by "MeterValues" PDUs. For
charging session data (ConnectorID<>0),
samples are acquired and transmitted
periodically at this interval from the start
of the charging transaction.
A value of "0" (numeric zero), by
convention, is to be interpreted to mean
that no sampled data should be
transmitted.
StopTxnSampledData
ControlMetering
.DataText[2]
CSL Sampled measurands to be included in
the TransactionData element of
TransactionStopped.req PDU, every
MeterValueSampleInterval seconds from
the start of the charging session.
StopTxnAlignedData
FiscalMetering
.DataText[2]
CSL Clock-aligned periodic measurand(s) to
be included in the TransactionData
element of TransactionStopped.req
MeterValues.req PDU for every
ClockAlignedDataInterval of the charging
session.

2. Time & Daylight Saving
For the purpose of displaying local time on a charge points display the following
configuration keys are provided:
TimeZoneOffset
StartDst
EndDst
Note: OCPP does not prescribe the use of a specific time zone for time values.
However, it is strongly recommended to use UTC for all time values to improve
interoperability between Central Systems and Charge Boxes.
Page 196 (198)
OCPP 2.0
TimeZoneOffset
Clock
.TimeOffset
ISO 8601
offset
Hours
and
minutes
Time zone offset as specified by ISO
8601: Z, or +/-hh:mm, or +/-hhmm, or
+/-hh (Z means UTC (zero offset))
A charge point can calculate the correct
time based on the UTC time + Time Zone
Offset. The UTC time is exchanged via
BootNotification.conf and HeartBeat.conf.
See also StartDst / EndDst.
StartDst
Clock
.Time[2]
dateTime Date
and time
On a certain moment in time the Day
Light Saving Time goes into effect which
means that +1 hour needs to be added to
the UTC time + Time Zone Offset. The
time that the Day Light Saving Time goes
into effect is not consistent across
countries/timezones and also varies each
year.
The charge point can calculate the exact
user time using UTC time + Time Zone
Offset and determine if the charge point
time is within the bounds of StartDst /
EndDst and add +1 hour to the result.
EndDst
Clock
.Time[3]
dateTime Date
and time
UTC dateTime of the end of the daylight
saving time. When EndDst is provided,
the StartDst is mandatory.

3. Under Frequency Load Shedding
UflsEnabled
LocalPowerCont
roller
.Available[1]
boolean true/fals
e
Indicates if the Charge Box is using UFLS
UflsFreqLow
LocalPowerCont
roller
.Frequency[1]
float Hz Low frequency limit at which to start
under-frequency load shedding.
Page 197 (198)
OCPP 2.0
UflsFreqHigh
LocalPowerCont
roller
.Frequency[2]
float Hz High frequency limit at which to stop
under-frequency load shedding
UflsTime
LocalPowerCont
roller
.Time[1]
int seconds Number of seconds that frequency must
be under UflsFreqLow or above
UflsFreqHigh before starting c.q. stopping
under-frequency load shedding.

4. Pricing
CalculateCost
SessionCoster
.Active[1]
boolean true/fals
e
Parameter for the CP to know if the CP or
the Central System will calculate the
actual cost during the charge session.
CalculateCostLocally
SessionCoster
.Active[2]
boolean true/fals
e
Parameter for the CP to request the
Central System during a charge session
to calculate and receive the actual cost.
SmartChargingPricingU
sed
SessionCoster
.Active[3]
.
boolean true/fals
e
Parameter for the CP know if the CP
needs to use the pricing concept related
to smart charging.
GetCostInterval
SessionCoster
.Interval
int seconds Parameter for the CP to request the
Central System during a charge session
to calculate and receive the actual cost.

5. Display
A Charge Point may have a physical display attached to it, the following
configuration keys are used to exchange information about display capabilities.
NbrOfDisplayLines
Display
int The total number of lines that can be
displayed.
Page 198 (198)
OCPP 2.0
.HeightInChars
NbrOfCharsPerLine
Display
.WidthInChars
int The total numbers of characters per line
that can be displayed.

6. Deprecated
The following configuration keys have been maintained for compatibility, but will
become deprecated in the next release:
ProximityLockRetries Int times
ProximityContactRetrie
s
Int times
ChargePointId String N/A

OCPP 2.0 Specification - RC1 0.97 PDF

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

OCPP 2.0 Specification - RC1 0.97 PDF

Caricato da

Copyright:

Formati disponibili

Open Charge Point Protocol 2.

Potrebbero piacerti anche