OCPP 1.6 Implementation Overview
OCPP 1.6 Implementation Overview
OCPP 1.6 Implementation Overview
OCPP 1.6
Implementation Overview
2 0 2 3- 0 8 - 0 1 1/2 0
O C PP 1 .6
Notice
This document contains information about one or more ABB products and may include a description
of or a reference to one or more standards that may be generally relevant to the ABB products. The
presence of any such description of a standard or reference to a standard is not a representation
that all of the ABB products referenced in this document support all of the features of the described
or referenced standard. In order to determine the specific features supported by a particular ABB
product, the reader should consult the product specifications for the particular ABB product.
ABB may have one or more patents or pending patent applications protecting the intellectual pro-
perty in the ABB products described in this document.
The information in this document is subject to change without notice and should not be construed
as a commitment by ABB. ABB assumes no responsibility for any errors that may appear in this
document.
In no event shall ABB be liable for direct, indirect, special, incidental or consequential damages of any
nature or kind arising from the use of this document, nor shall ABB be liable for incidental or conse-
quential damages arising from use of any software or hardware described in this document.
This document is originally written in English. Other language versions are a translation of the origi-
nal document and ABB cannot be held liable for errors in the translation.
This document and parts thereof must not be reproduced or copied without written permission
from ABB, and the contents there of must not be imparted to a third party nor used for any unautho-
rized purpose.
Copyrights
All rights to copyrights, registered trademarks, and trademarks reside with their respective owners.
Copyright © 2023 ABB.
All rights reserved.
2 0 2 3- 0 8 - 0 1 2 /2 0
O C PP 1 .6
Table of Contents
Table of Contents..........................................................................................................................................3
Revisions....................................................................................................................................................... 4
Overview ........................................................................................................................................................5
Security ....................................................................................................................................................... 20
Encryption ............................................................................................................................................................ 20
Authentication ..................................................................................................................................................... 20
2 0 2 3- 0 8 - 0 1 3/2 0
O C PP 1 .6
Revisions
Revision Description Date Author
A First issue. 12 February 2019 Mikhail Kireev
1.2 Added description for new messages and addi- 06 January 2020 Mikhail Kireev
tional Measurands. The first part of the docu-
ment is restructured.
1.3 • Added TriggerMessage in “Supported 15 February 2021 Mikhail Kireev
functionality”,
• Added chapter “Smart Charging custom
configuration key DiscardTxProfileWhen-
ConnectionLoss”,
• Added chapter “Reference to payment ses-
sion for payment terminal authorized ses-
sion in idTag of StartTransaction”,
• Added part “ABB implementation choices
for some of OCPP 1.6 unspecified areas”,
• Added part “Known issues”.
1.4 • Some typos and small mistakes cor- 30 July 2023 Evangelos
rected, Kontosis
• Updated Firmware Management profile
information in “Supported functionality”,
• Updated AC socket information in “Me-
terValues”,
• Updated chapter “Free Vend Mode”,
• Added chapter “Reference to Vehicle ID
for autocharge authorized session in cus-
tom DataTransfer message”,
• Updated chapter “StopTransaction in
case of power supply failure”,
• Added chapter “StartTransaction and
StopTransaction timestamps”,
• Added chapter “Date and Time format”,
• Updated list of Supported / Not Sup-
ported keys and added new ABB custom
keys in “Configuration keys” part,
• Added Value Range information for keys
of Type ‘int’ in “Configuration keys” part.
2 0 2 3- 0 8 - 0 1 4/2 0
O C PP 1 .6
Overview
This document describes the OCPP 1.6 functionality supported by ABB DC chargers according to the
OCPP protocol specification and ABB specific extensions of OCPP 1.6.
On its DC chargers, ABB implemented the OCPP 1.6-J version, that uses JSON over WebSockets. An
ABB DC charger connects to an OCPP Server directly and, in parallel, it also connects to the ABB
AbilityTM Platform. This setup enables efficient remote support and offerings simultaneously with
OCPP. ABB names this concept Dual Uplink.
2 0 2 3- 0 8 - 0 1 5/2 0
O C PP 1 .6
Supported Functionality
The implementation is following the OCPP 1.6 specification of Open Charge Alliance. According to
the OCPP 1.6 specification all of the features and associated messages are grouped into Feature
Profiles.
The Table below shows the mapping between the various OCPP 1.6 Feature Profiles and the software
versions of the ABB DC Fast Charging products in which these profiles are supported:
Profile Core Firmware* Local Auth Reservation Smart Remote
Management List Charging Trigger
Model Management
Terra T53 4.0.0.x 4.0.0.x* 4.0.0.x To be 4.3.x 4.5.x
and T54 supported** (partially)
Terra High Any Any version* Any version To be 1.2.x 1.5.x
Power T175 version supported** (partially)
Terra HVC 1.2.x Not supported N/A N/A 1.2.x 1.5.x
(Connector (partially)
and
OppCharge)
DC Wallbox Any Any version* Any version To be Any 1.5.x
version supported** version (partially)
Terra Any Any version* Any version To be Any 1.7.0
94/124/184 version supported** version (partially)
* Messages for the Firmware Management profile are implemented. However, the update of the
charger firmware via OCPP is currently disabled due to security concerns and potential SLA violation.
In the standard ABB firmware update process, the operator is informed in advance about firmware
updates, including release notes. That gives the operator the possibility to influence the process and
ask questions about the possible impact. ABB rolls out the new firmware in a controlled way and
ensures successful completion of the firmware update process through a separate dedicated
connection. In this way, the firmware updates can be more effectively controlled compared to using
only OCPP. Furthermore, they are executed effortlessly for the operator.
** The reservation profile is not yet implemented in the current software version for the chargers.
ABB intends to provide this functionality in the future software versions. Updating to these versions
will be possible remotely, without service personnel visiting the charger.
The following table lists the messages which are supported per OCPP 1.6 Feature Profile.
Note that the charger can produce WebSocket messages with a maximum size of 128KB.
2 0 2 3- 0 8 - 0 1 6 /2 0
O C PP 1 .6
2 0 2 3- 0 8 - 0 1 7/2 0
O C PP 1 .6
*Available from Software versions 1.2.x for Terra HP and HVC and from 4.3.x for Terra 53/4.
MeterValues
As mentioned above, the following Measurands are supported:
1. Current.Import,
2. Energy.Active.Import.Register,
3. Power.Active.Import,
4. SoC,
5. Voltage,
6. Current.Offered,
7. Power.Offered,
8. Temperature.
‘Energy.Active.Import.Register’ and ‘SoC’ are enabled by default. Other values could be enabled
through the ChangeConfiguration command for the keys MeterValuesAlignedData,
MeterValuesSampledData, StopTxnAlignedData, and StopTxnSampledData. See Configuration Keys
chapter for the description of these keys.
Note: For an AC cable or a socket of T53 and T54 chargers only the ‘Energy.Active.Import.Register’
Measurand is currently supported.
Voltage
In the OCPP 1.6 protocol specification [1], Chapter 7.31, the Voltage value of a Measurand is specified
as an “Instantaneous AC RMS supply voltage”. In ABB DC Fast charging, the Voltage field contains the
instantaneous voltage measured on DC contactors of the plug during charging.
2 0 2 3- 0 8 - 0 1 8 /2 0
O C PP 1 .6
To enable Current.Offered and Power.Offered, either the Smart Charing profile should be activated
or (if Smart Charging is not used) the power management component should be activated in the
charger configuration by ABB Service.
The Current.Offered and Power.Offered values represent the actual maximum current and power, re-
spectively, that could be given to the connected vehicle based on the maximum capabilities of the
vehicle provided during the charging session setup. These Measurands do not always represent the
charger's maximum capabilities without considering the context of the connected vehicle.
For example, on a 350kW High-Power charger, if during a session setup the vehicle communicates
that it could charge up to a maximum of 100kW, the charger will allocate only 100kW, with 10-15% of
extra power, and will communicate this number through Power.Offered. Accordingly, the Power.Of-
fered will not contain the 350kW power value.
Note: An additional 10-15% of power is attributed to the usage of AC input current from the grid for
power and current management. Therefore, some margin is added during the calculation of DC val-
ues.
Temperature
The temperature measurand is available for connectorId=0 only. To enable the sending of
temperature measurements, the “Temperature” value should be added to the key
MeterValuesAlignedData.
The temperature is measured inside one or several enclosures of the charging system. Therefore, in
the case of multiple enclosure topology e.g., a charge post + power cabinet(s), several temperature
measurands are provided, one per enclosure.
Depending on the number of enclosures, one or more temperature values are placed in a comma-
separated list inside Measurands. Below is an example of a JSON structure containing two
temperature measurements for a Heavy Vehicle Charger which consists of a depot box and a power
cabinet. The power cabinet temperature is 33.8°C and depot box temperature is 18.6°C:
"MeterValues": {
"connectorId": 0,
"meterValue": [{
"sampledValue": [{
"unit": "Celsius",
"context": "Sample.Clock",
"measurand": "Temperature",
"location": "Body",
"value": "33.8,18.6"
}],
"timestamp": "2019-12-19T14:20:00.155Z"
}]
}
Sampling Moments
Samples are taken at different moments in time, depending on the value of the interval configura-
tion, but always only during an ongoing charging session, as specified in Section 3.16 [1].
2 0 2 3- 0 8 - 0 1 9 /2 0
O C PP 1 .6
To enable this mode, the Central System should send the ChangeConfiguration message for the
FreevendEnabled key with the TRUE value (the default value for this key is FALSE). For specification
of this configuration key please see Chapter ABB Custom Configuration Keys.
When the Free Vend mode is enabled and charging is started locally, the StartTransaction message
will contain an idTag as configured by the custom configuration key FreevendIdTag. However, if
Autocharge is enabled via the Charger Management System and the vehicle communicates its
Vehicle ID to the charger, the idTag parameter will contain this Vehicle ID as value instead.
When the Free Vend mode is enabled and charging is started remotely via a RemoteStartTransaction
message, the StartTransaction message will contain the idTag referenced in the received
RemoteStartTransaction message.
Note: The central system should be configured to accept the StartTransaction message with the id-
Tag configured for the Free Vend mode. If this idTag is not known by the Central System, and the
Central System rejects StartTransaction for this idTag, charging will be stopped with the Reason =
DeAuthorized, unless the configuration key StopTransactionOnInvalidId is set to FALSE.
2 0 2 3- 0 8 - 0 1 10 /2 0
O C PP 1 .6
The key is Boolean, when it is set to TRUE and the connection to the Central System is lost (the Web-
Socket connection is dropped), the txProfile, if such profile exists for the ongoing charging session,
will be deleted immediately and all the limits applied by it will be not considered.
When the key is set to FALSE, the behavior aligns with the OCPP specification: the txProfile will be
active until the end of the ongoing charging session even if the connection to the Central System is
lost.
This is implemented by putting a reference to the payment transaction into the field idTag of the
StartTransaction request message preceded by a configurable prefix (e.g., “PAY:”, “PT:”).
The default value of the prefix is an empty String.
The numbers that are communicated in the idTag of an OCPP StartTransaction message per type of
supported payment terminals are the following:
The DataTransfer message is sent by the charger as soon as the StartTransaction confirmation mes-
sage has been received. The structure of the message is shown below:
"DataTransfer" {
"data": "{
\"VehicleID\":<Vehicle Id>,
\"transactionID\":<Transaction Id>
}",
"messageId": "VehicleID",
"vendorId": "com.abb.evci/vid/v1"
}
In case no Vehicle ID is received by the charger, the DataTransfer message is sent with the “Vehi-
cleID” parameter value set to empty String (i.e., “”).
2 0 2 3- 0 8 - 0 1 11 /2 0
O C PP 1 .6
Sending the above described DataTransfer message can be enabled by setting the value of the con-
figuration key SendVehicleID to TRUE.
ABB agrees that it makes sense to at least properly finalize the charging session and at least send
the StopTransaction message. Therefore, ABB has implemented this functionality in the power loss
scenario right after the Charging Station has recovered and booted.
The exact sequence of messages sent by the Charging Station after it has booted is the following:
1. BootNotification request,
2. StatusNotification requests,
"StopTransaction": {
"reason": "PowerLoss",
"idTag": <ID Tag>,
"transactionId": <Transaction Id>,
"meterStop": <Meter Stop Value>,
"timestamp": <Timestamp>
}
Note: There is a slight time difference between the exact moment of when the event happens and
the timestamp mentioned in the OCPP message due to communication latency among the software
layers within the charger.
2 0 2 3- 0 8 - 0 1 1 2 /2 0
O C PP 1 .6
ABB chargers accept only the extended format of date and time data according to the ISO 8601
standard. This practically means that separators have to be used in the provided data (i.e., 2019-10-
11T11:23:58+00:00) otherwise the relevant message is rejected by the charger.
Known Issues
RebootRequired status in ChangeConfiguration.conf
According to Chapter 5.3 “Change configuration” [1], “If the change was applied successfully, but a
reboot is needed to make it effective, the Charge Point SHALL respond with status 'RebootRe-
quired.”
This type of response is not implemented in the software of ABB DC chargers. The only response im-
plemented is “Accepted” or “Rejected”.
However, the only parameter change that requires a reboot of the charging station is WebSocket-
PingInterval. All the other parameters do not require a reboot and are applied immediately.
Section 3.16.4 of the OCPP specifications, that was added in the last edition says “If the comma sep-
arated list contains one or more Measurands that are not supported by this Charge Point, the Charge
Point SHALL respond with: ChangeConfiguration.conf with: status = Rejected”.
ABB based its implementation on an earlier version of the OCPP document where certain aspects
were not explicitly specified. ABB chose to have the charger parse CSL (Charging Station Language)
with the best effort and applied the recognized Measurands. As a result, ultimately, any string will be
accepted.
The same principle applies to every key of CSL type supported in the ABB implementation.
ABB agrees that specification 3.16.4 is clearer, but at the same time, it is stricter. Unfortunately,
OCPP has no means to provide information to the Central System regarding why exactly the configu-
ration change was rejected. ABB plans to address this and align it with version 3.16.4 in future soft-
ware versions.
2 0 2 3- 0 8 - 0 1 13 /2 0
Configuration Keys
Core profile
AllowOfflineTxForUnknownId optional When offline, a Charge Point may allow auto- Boolean RW FALSE N/A
matic authorization of any "unknown" identi-
fiers that cannot be explicitly authorized by
Local Authorization List or Authorization
Cache entries. Identifiers with status other
than "Accepted" (Invalid, Blocked, Expired)
must be rejected.
AuthorizationCacheEnabled optional A Charge Point may implement an Authoriza- Boolean RW TRUE N/A
tion Cache that autonomously maintains a
record of previously presented identifiers
that have been successfully authorized by
the Central System.
AuthorizeRemoteTxRequests required Whether a remote request to start a transac- Boolean R FALSE N/A
tion in the form of a RemoteStartTransac-
tion.req message should be authorized be-
forehand like a local action to start a
transaction.
ClockAlignedDataInterval required Size (in seconds) of the clock-aligned data int RW 0 0 - 3600
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) indi-
cates that every day should be broken into
96 15-minute intervals.
2 0 2 3- 0 8 - 0 1 14 /2 0
O C PP 1 .6
2 0 2 3- 0 8 - 0 1 15 /2 0
O C PP 1 .6
2 0 2 3- 0 8 - 0 1 16 /2 0
O C PP 1 .6
TransactionMessageAttempts required How often the Charge Point should try to int RW 10 0 - 30
submit a transaction-related message when
the Central System fails to process it.
TransactionMessageRetryInterval required How long the Charge Point should wait be- int RW 60 60 - 600
fore resubmitting a transactionrelated mes-
sage that the Central System failed to pro-
cess.
WebSocketPingInterval optional Only relevant for websocket implementa- int RW 30 0 - 3600
tions. 0 disables client side websocket
Ping/Pong. In this case there is either no
ping/pong or the server initiates the ping
and client responds with Pong. Positive val-
ues are interpreted as number of seconds
between pings. Negative values are not al-
lowed. ChangeConfiguration is expected to
return a REJECTED result.
Local Authorization List Management
LocalAuthListEnabled required Whether the Local Authorization List is ena- Boolean RW TRUE N/A
bled.
LocalAuthListMaxLength required Maximum number of identifications that can int R 10000 5 - 1000000
be stored in the Local Authorization List.
SendLocalListMaxLength required Maximum number of identifications that can int R 1000 5 - 1000000
be sent in a single SendLocalList.req.
ChargeProfileMaxStackLevel required Max StackLevel of a Charging. The number int R 10 Any value
defined also indicates the max allowed num-
ber of installed charging schedules per
Charging Purposes.
ChargingScheduleAllowedCharg- required A list of supported quantities for use in a CSL R Current, Power N/A
ingRateUnit ChargingSchedule. Allowed values: 'Current'
and 'Power'.
ChargingScheduleMaxPeriods required Maximum number of periods that may be int R 24 Any value
defined per ChargingSchedule.
MaxChargingProfilesInstalled required Maximum number of Charging profiles in- int R 10 Any value
stalled at a time.
2 0 2 3- 0 8 - 0 1 17 /2 0
O C PP 1 .6
Core profile
BlinkRepeat optional Number of times to blink Charge Point lighting when signalling. int
ConnectorPhaseRotationMaxLength optional Maximum number of items in a ConnectorPhaseRotation Configuration Key. int
LightIntensity optional Percentage of maximum intensity at which to illuminate Charge Point lighting. int
MaxEnergyOnInvalidId optional Maximum energy in Wh delivered when an identifier is invalidated by the Central System int
after start of a transaction.
StopTxnAlignedDataMaxLength optional Maximum number of items in a StopTxnAlignedData Configuration Key. int
StopTransactionOnEVSideDisconnect required When set to true, the Charge Point shall administratively stop the transaction when the Boolean
cable is unplugged from the EV.
NOTE: this parameter is not being used, Transaction will always stop on EV disconnect or
even before.
UnlockConnectorOnEVSideDisconnect required When set to true, the Charge Point shall unlock the cable on Charge Point side when the Boolean
cable is unplugged at the EV.
2 0 2 3- 0 8 - 0 1 18 / 2 0
O C PP 1 .6
2 0 2 3- 0 8 - 0 1 19/2 0
Security
Encryption
In addition to network level security ABB OCPP 1.6 implementation supports OCPP-J over TLS
security. TLS 1.2 is supported. It is up to Central System operator to decide if TLS with Websocket
(WSS) is used or not. No additional configuration changes are required to enable it. For more
information on encryption with OCPP 1.6-J please see chapter “6.2.1 Encryption” of [2].
Authentication
ABB OCPP 1.6 implementation supports basic HTTP authentication. Username equals charge point
ID and password/authorization keys can optionally be set during installation.
Reference Documentation
[1] Open Charge Point Protocol 1.6
[2] Open Charge Point Protocol JSON 1.6, OCPP 1.6-J Specification
2 0 2 3- 0 8 - 0 1 2 0 /2 0