2.

CONNECTING CHARGING STATIONS

TO A CENTRAL SYSTEM
 Connecting Stations to a Central System
OCPP 1.6 supports two types of protocols for communication
between a station and a central system: SOAP and WebSockets.
In practice, the de facto standard used by most systems is
WebSockets.

The Central System acts as a WebSocket server and the station

websocket acts as a WebSocket client.

1. The Central System has an URL such as
station Central System:
ws://cs.example.com/ocpp ws://cs.example.com/ocpp for the OCPP server
2. This same URL is configured to the station, which opens a new
WebSocket connection to the Central System
3. OCPP defines then what kind of JSON messages can be sent
through the WebSocket connection
Identity and Connector IDs

In OCPP terminology, a charging station always has a

STA_XX_005
unique identifier called an "Identity". An example of
an identity could be STA_XX_005.

Each connector of a station has a Connector ID,

1 2
which is a number from 1 to N.

3 4
 Connecting Stations to a Central System
When a station is powered on, it should automatically
connect to the central system in the following way::

1. Open websocket connection 1. The station checks its internal configuration for the
URL of the central system and tries to open a new
2. Send Boot Notification
WebSocket connection there.

Station Central System 2. After the connection is successfully established, the

(CS)
station sends a 'Boot Notification' message to the
central system, providing details about the station
that is now opening the connection.
 WebSocket Connection
The Central System (CS) has an URL where the OCPP
service is running, for example
ws://cs.example.com/ocpp

1. Open websocket connection

The charging station has a unique identity that is
sends as a part of the WebSocket (WS) connection URL
it opens towards the CS.
CP Central System
STA_XX_005
(CS)
For example, if s station’s identity is STA_XX_005, it
would open connection to the CS with the URL
ws://cs.example.com/ocpp/STA_XX_005
 Boot Notification Request
After the WebSocket connection has been established, the
station sends a 'Boot Notification' request message to the
central system.
1. Open websocket connection
[2, "19223201", "BootNotification", {"chargePointVendor":
2. Boot Notification (req) "VendorX", "chargePointModel": "SingleSocketCharger"} ]

Station Central System

STA_XX_005 When the station opened the WebSocket connection to the
(CS)
CS, it included its identity in the URL. In the 'Boot
Notification' message, the station provides more details,
such as the vendor and model of the station, as well as
additional information.
Structure of an OCPP message
CALL message format: As we saw in the previous example, a Boot Notification
[<MessageTypeId>, message sent by a CP has different parameters
”<UniqueId>”, “<Action>”
{<Payload>}] [2, "19223201", "BootNotification", {"chargePointVendor": "VendorX",
"chargePointModel": " V-MOD1-A"} ]
Example:
[2, "19223201", "BootNotification", First parameter 2 is a message type. Possible message types
{"chargePointVendor": "VendorX", are:
"chargePointModel": ”V-MOD1-A"} ] 2 CALL Client-to-Server
3 CALLRESULT Server-to-Client
4 CALLERROR Server-to-Client
Since our message was sent by the CP (client) to the CS
(server), the message type was 2 (CALL)
Structure of an OCPP CALL message
CALL message format: The second parameter "19223201” is a message ID that binds
[<MessageTypeId>, together CALL and CALLRESULT
”<UniqueId>”, “<Action>”
{<Payload>}] [2, "19223201", "BootNotification", {"chargePointVendor": "VendorX",
"chargePointModel": " V-MOD1-A"} ]
Example:
[2, "19223201", "BootNotification", When a station sends a message (CALL) to the Central System
{"chargePointVendor": "VendorX", with ID "19223201”, the Central System must then include this
"chargePointModel": ”V-MOD1-A"} ] same Message ID back to the CALLRESULT.

This way both the client and the server always know, which
response (CALLRESULT) is linked to which request (CALL)
Structure of an OCPP CALL message
CALL message format: The third parameter "BootNotification” tells which kind of
[<MessageTypeId>, message we are sending.
”<UniqueId>”, “<Action>”
{<Payload>}] [2, "19223201", "BootNotification", {"chargePointVendor": "VendorX",
"chargePointModel": " V-MOD1-A"} ]
Example:
[2, "19223201", "BootNotification", When the Central System receives a Boot Notification message
{"chargePointVendor": "VendorX", from a Station, it knows that this Station has now been
"chargePointModel": ”V-MOD1-A"} ] rebooted. It can then perform different actions needed by the
Central System, for example mark that the Station is now
online.
Structure of an OCPP CALL message
CALL message format: The last in the message is then the actual payload of the
[<MessageTypeId>, BootNotifcation message.
”<UniqueId>”, “<Action>” [2, "19223201", "BootNotification", {"chargePointVendor":
{<Payload>}] "VendorX", "chargePointModel": " V-MOD1-A"} ]

Example: In this example, the payload has two mandatory parameters:

[2, "19223201", "BootNotification", vendor, which tells which company has made the charging
{"chargePointVendor": "VendorX", station, and model, which tells the detailed model number of
"chargePointModel": ”V-MOD1-A"} ] this station.

The station can also send optional parameters in the message,

such as serial number, firmware version, ICCID and IMSI of a
SIM card, and energy meter serial and type.
 Boot Notification Response
When the Central System receives a Boot Notification
request from a station, it may Accept or Reject the
request. Many Central Systems, for example have a security
2. Boot Notification (req) feature where they allow only CPs with a whitelisted
identity to connect to the CS.
3. Boot Notification (resp)

[3, "19223201", {”status": ”Accepted", ”interval": 60, “currentTime”:

station
Central System “2022-12-05T12:31:14Z”} ]
STA_XX_005
(CS)

The Boot Notification response also allows the Central

System to tell the stations which time they should use and
an interval (in seconds) on how often the CP should report
heartbeats and meter values to the CS.
All Boot Notification request fields

Field Card. Description

chargePointVendor 1..1 Required. Name of the vendor who has manufactured the
charging stations. Usually a company name such as Charger Inc.
chargePointModel 1..1 Required. Model name or number of a charging station. Usually a
technical model identifier such as singe_acbox_22
chargeBoxSerialNumber 0..1 Optional. Deprecated field from previous OCPP versions
chargePointSerialNumber 0..1 Optional. Serial number of the charging station
firmwareVersion 0..1 Optional. Firmware version installed to the station
iccid 0..1 Optional. ICCID of the SIM-card in station’s modem
imsi 0..1 Optional. IMSI of the SIM-card in station’s modem
meterSerialNumber 0..1 Optional. Serial number of the energy meter of the station
meterType 0..1 Optional. Type of the energy meter of the station