As explained in the OCPP 2.0.1 Foundations article the structure OCPP follows is one where the Charging Station Management System (CSMS) is the server and the Charging Station (CS) is the client. One CSMS can host many CS’s but a CS may only connect to one CSMS at a time. Charger onboarding refers to the process by which the CS registers itself to a CSMS and establishes a long lived websocket connection.
There are 3 stages to a charger onboarding which will be explained in this article: websocket connection, required OCPP onboarding, and optional OCPP onboarding.
This article will cover these three steps at a high level, for a more in depth explanation of the websocket handling refer to the OCPP-2.0.1_part4_ocpp-j-specification.pdf specification document.
For details on the OCPP onboarding requirements refer to the provisioning use cases in the OCPP-2.0.1_part2_specification.pdf document.
The WebSocket protocol is described in RFC 6455 and is essentially a long-lived connection between a client and server. This is distinct from HTTP which works on a request and response model.
In the EV charger context the CSMS is the server, it has a URL which is open to connection requests. The CS is the client and it must know the CSMS URL that it wants to connect to, this URL is a very important variable and will be different for each CSMS.
The URL format is something like ws://csms-name.com/cs001
ws:// indicates this is a websocket URLcsms-name.com is the domain name of the CSMScs001 is the charging station ID. It’s an OCPP requirement that this be included in the URLBefore any of the following sequences can take place successfully the charging station will need to be onboarded to the CSMS. This is so that the CSMS can recognise the CS when it attempts to connect and ensure that only authorized chargers are connecting.
Charger onboarding on the CSMS side is typically done just using an API POST endpoint which adds a record to the chargers table, this table is then referred to when a charger attempts to connect. Depending on the security profile there will be different requirements for the charger onboarding, for example profile 0 just needs the charger ID, profile 1 also needs a password, and profile 3 also needs a charger certificate.
The following section outlines the HTTP requests required for establishing a websocket connection on each of the 4 security profiles. For more detail on these security profiles refer to the article on Security.
The following outlines the steps required to establish a non secure websocket connection without a password (security profile 0)
CS → HTTP GET → CSMS
To create a websocket connection the CS starts with an HTTP request which is called a websocket handshake request. This essentially tells the CSMS which protocols it supports and asks for an upgrade to a websocket connection.
CS ← HTTP 404 Not Found / 101 Switching Protocols ← CSMS
The CSMS then checks the charging station ID in the request against its own list of authorized chargers and if it’s not in the list it can immediately send a 404 Not Found response and proceed no further.
If it does recognise the charger but does not support the OCPP protocols listed in Sec-WebSocket-Protocol it can respond with a 200 but an empty Sec-WebSocket-Protocol header and proceed no further
If it does recognise the charger and supports one or more of the protocols it can accept the request and indicate the protocol to be used with a Switching Protocols response:
Security profile 2 requires a server side certificate which is used by the CSMS to securely authenticate itself to the CS. The extra steps at the start here here are those required to establish transport layer security or TLS. Once that is established the usual flow of HTTP requests and responses is completed.
CS → Client Hello → CSMS
CS ← Server Hello / Server Certificate / Server Hello Done ← CSMS
CS → Client Key Exchange / Change Cipher Spec / Finished → CSMS
CS ← ChangeCipherSpec / Finished - CSMS
CS → HTTP GET → CSMS
CS ← HTTP 401 Authorization Required ← CSMS
CS → HTTP GET Basic Auth Username/Password → CSMS
CS ← HTTP/200 ← CSMS
Security profile 3 is mutual TLS or MTLS and requires both the CSMS and the CS to authenticate themselves with certificates. It is by far the most secure of the profiles and is recommended where possible, especially in production or sensitive deployments.
It should be noted in this case that the CS certificate must be derived from the CSMS root. This means it’s unlikely that a first boot of a charger will ever use profile 3 as it would not be able to know the CSMS root certificate details beforehand in order to generate its own certificate. It’s more likely to connect on profile 2 and upgrade to profile 3 using the mechanisms described in the Security article. The steps below would then be for a subsequent boot sequence.
In this case there is no need for a charger password as this is replaced by the certificate, the number of steps is therefor actually less.
CS → Client Hello → CSMS
CS ← Server Hello / Server Certificate / Certificate Server Request / Server Hello Done ← CSMS
CS → Client Certificate / Client Key Exchange / Certificate Verify / Change Cipher Spec / Finished → CSMS
CS ← ChangeCipherSpec / Finished - CSMS
This can all be implemented relatively simply using a WebSocket package, for example the websockets python package or the websocket rust crate.
Websockets do not natively relate requests to responses, however this is a very important aspect of how OCPP operates so there is an additional small standard which OCPP applies to make sure that all requests have a linked response and that these are sent in order. Every request is of type CALL, every call must be responded to with either a CALLRESULT or a CALLERROR.
The details of this standard are outlined in the RPC framework section of the OCPP-2.0.1_part4_ocpp-j-specification.pdf document.
Once a WebSocket connection is established there is a defined message sequence between the CS and CSMS in order for the CS to be properly registered to the CSMS with the right information.
Self explanatory message from the CS which gives some key information about the station and the state it is in. The required fields are the booting reason, the station vendor, and model
The CSMS responds to this essentially with a status, which could be accepted, pending or rejected.
Optionally, the CSMS may choose to respond to the BootNotification with pending and not accept it until it gets some more information about the charger. This additional information is very useful for the charge point operator using the CSMS so it’s recommended to follow this pattern.
CS → BootNotification → CSMS
CS ← Pending ← CSMS
CS ← GetBaseReport ← CSMS
CS → NotifyReport → CSMS
The NotifyReport (triggered by the CSMS sending a GetBaseReport) is what the CS uses to send information about its device model an important OCPP 2.0.1 concept which is explained fully in the Device Model article
Efficient websocket handling is a very important feature of a scalable CSMS. Depending on the type of CSMS the number of chargers connected over websockets can far outweigh the number of frontend or API users. A dropped connection to a charger should be avoided at all times so the websocket server should be as robust and scalable as possible, any updates to the server should involve a blue-green deployment to retain connectivity.