Or: what actually happens when you charge your electric vehicle at a public charging station?

I personally (and happily) don’t own a car, let alone an electric one. Nonetheless, I have ended up working in the e-mobility space. Given my personal lack of practical experience, I was initially a bit confused about how charging an electric vehicle works. Apparently it involved RFID cards, but sometimes also mobile phone apps? Also, the term ‘roaming’ was floating around. I had heard of roaming in the context of mobile phones, but I didn’t know how it applied to electric vehicles (EVs). On top of this, I soon encountered a heap of confusing acronyms and abbreviations, such as CPO, EMSP, CPMS, OCPP and OCPI. I didn’t find a comprehensive overview of the involved actors and the process, so I decided to write one myself. Note that this blog post can only cover specific scenarios, as the involved protocols cover a large number of use cases. I will focus on the configurations and processes I’ve found to be most common. I am also going to gloss over many details of the involved protocols.

Before we go into the details, we need to clarify a number of terms. Picture yourself as an EV driver. You likely have one or more contracts with so called e-mobility service providers (EMSP). These are companies that provide you with a contract to charge your EV. They usually have a mobile app and/or hand you an RFID token that you can use to charge your EV at public charging stations. For this blog post, let us assume that you have a contract with a single EMSP.

When you want to charge your EV, you drive your car to a public charging station. These are operated by charging point operators (CPO). CPOs are responsible for the hardware and the software that runs the charging station. They use a system called a charge point management system (CPMS) to operate the charging stations. This system both communicates with the charging stations and with the EMSPs.

Some words on roaming #

As you might have inferred, you don’t actually have a contract with the CPO of the charging station you are using. Instead, you have a contract with your EMSP. This is where the term roaming comes into play. Roaming basically describes the constellation that a contract with a single EMSP usually allows you to charge your EV at a large number of various CPO’s stations, without having to sign a contract with each of them. This is similar to how you can use your mobile phone in many different countries without having to sign a contract with each mobile network operator.

Before you roll up to the charging station, your EMSP and the CPO of the charging station need to have agreed on a contract. This contract may have drastically different conditions to those you agreed to with your EMSP. For example, the CPO may charge a different price for the kWh you consume, or they may charge a fee for using the charging station. This is fully opaque to you as the EV driver. There are various ways (and protocols) to implement roaming. I am going to focus on the broadly used OCPI (Open Charge Point Interface) protocol, where applicable.

Overview #

The following diagram shows the actors involved in a charging session:

The three actors are the EV driver (you), the EMSP and the CPO. The EV driver operates the EV, the EMSP operates an EMSP backend system and the CPO operates the charge point management system (CPMS). The EV driver has a contract with the EMSP, and the EMSP has a roaming contract with the CPO.

The CPMS communicates with the charging station using the OCPP (Open Charge Point Protocol). The CPMS and the EMSP communicate using the OCPI (Open Charge Point Interface) protocol.

The protocols: OCPI and OCPP #

OCPI is a protocol that is used to communicate between the EMSP backend and the CPMS. It is implemented as a REST API and uses JSON messages to exchange information. The protocol is used to exchange information about charging stations, charging sessions, tariffs, and other information. The protocol is modular and extensible.

The OCPP protocol is used to communicate between the charging station and the CPMS. It is a protocol either running on top of WebSockets or HTTP. It is used to send messages between the charging station and the CPMS. These messages are used to control and configure the charging station, start and stop charging sessions, and exchange status updates and meter values. The protocol is quite flexible and allows for a wide range of use cases, which also makes it somewhat complicated. This is especially true of the current version family of the protocol, OCPP 2.x. In the rest of this blog post, I will focus on the OCPP 1.6 version, as it is still the most widely adopted version (and simpler, as well).

Especially OCPP (but also some parts of OCPI) is designed around asynchronous communication. The reason for this is that the charging stations are mostly connected to the CPMS via mobile networks, which can be unreliable. This is especially important, as the stations are sometimes located in areas of poor network connectivity (such as parking garages).

Scenario 1: Charging with an RFID token #

In this scenario, you want to use an RFID token to charge your EV. This is the most common scenario, and it is usually the most reliable one, as a driver. The process is as follows:

Let us begin with step (3), as this is where you as a driver come into play. We’ll get back to steps (1) and (2) later.

• You arrive at the charging station and plug in your EV (3). The charging station detects this, but since charging has not been authorized yet, it does not start charging your EV.
• You hold your RFID token in front of the RFID reader of the charging station (4).
• The charging station reads the token and sends a request for authorization to the CPMS. This is usually done using another protocol called OCPP (Open Charge Point Protocol). Specifically, the charging station sends a Authorize.req OCPP message to the CPMS, containing the ID of the RFID token (5).

• The CPMS checks if the token is valid (6).

  You might wonder how the CPMS recognizes the RFID token. There are multiple ways, but most commonly it works like this: once an EMP and a CPO have agreed on a contract, the EMSP sends a list of all their RFID tokens to the CPO (1). The CPO then stores this list in their CPMS. This list is updated regularly, so that the CPO always has the latest list of tokens. This is done using the OCPI protocol. In other words: in our scenario, your EMSP has already informed the CPO about your RFID token. When the CPMS receives the Authorize.req message, it checks if the token is in the list. If it is, the CPMS now knows which EMSP the token belongs to, and can check if the token is valid.

• The CPMS responds with an Authorize.conf OCPP message back to the charging station (7). This message tells the charging station whether the token is valid or not.
• If the token is valid, the charging station may now begin charging your EV. It indicates this by sending a StartTransaction.req OCPP message to the CPMS (8). This message again contains the ID of the RFID token.

• The CPMS now generates a unique transaction ID that identifies the charging session (9).

  As per the OCPP standard, the CPMS now again checks if the token is valid.

• The CPMS responds with a StartTransaction.conf OCPP message back to the charging station (10). This message contains a unique transaction ID that identifies the charging session.
• The charging station starts charging your EV and sends a MeterValues.req OCPP message to the CPMS (11). This message contains the current power consumption of the charging station. It continues to send MeterValues.req messages at regular intervals, so that the CPMS can keep track of the power consumption. Each such message is acknowledged by the CPMS with a MeterValues.conf OCPP message (12). These meter values may also be relayed to the EMSP backend using OCPI, but I’m omitting this here for clarity.

There now are various ways the charging session can end. You might end it by unplugging your EV, you might end it at the station by presenting your token, or there might even be a technical fault! Let us assume that you choose to end the session by unplugging your EV (13).

Note that unplugging your EV might not actually stop the session, as this is dependent on the configuration of the charging station. More specifically the ´StopTransactionOnEVSideDisconnect´ OCPP configuration key. It’s complicated!

Once the charging station detects that the EV has been disconnected, it sends a StopTransaction.req OCPP message to the CPMS (14). This message contains the transaction ID that was assigned to the charging session in step 9. Usually, it also contains the final power consumption of the charging session. The CPMS now responds with a StopTransaction.conf OCPP message (15). Your EV is charged, and you’re on your way!

But we’re not quite done yet! The CPMS now has to inform your EMSP about the charging session. This again happens using the OCPI protocol. The CPMS sends a charge detail record (CDR) message to your EMSP (16). This message contains all the information about the charging session, including the transaction ID, the start and end time of the session, the power consumption and the price. This price has been calculated based on the tariff that was agreed upon between your EMSP and the CPO. The details of this tariff have already been exchanged between the EMSP and the CPMS in step (1).

Your EMSP can now process the CDR and send you an invoice (17).

Scenario 2: Charging with a mobile app #

In this scenario, you have a contract with your EMSP and you are using a mobile app to charge your EV. This is usually a little more error-prone than RFID tokens. However, it is also more convenient, as you do not have to carry around a card. Hence it is becoming more common. The brittleness of this scenario comes down to the fact that you need more communication between systems than in the RFID scenario. In the previously described RFID scenario, the charging station only needed to communicate with the CPMS when you plugged in your EV. Since the EMSP and CPO had already exchanged the list of RFID tokens beforehand, the CPMS was able to check if the token is valid. In the mobile app scenario, it’s a little different:

Again, we start with the step (3), where you as a driver come into play. We’ll get to steps (1) and (2) later.

• You arrive at the charging station and plug in your EV (3). The charging station detects this, but since charging has not been authorized yet, it does not start charging your EV.

• You open your mobile app, select the station and request to start charging (4). The app sends a request to the EMSP backend.

  You either select the station by scanning a QR code or by selecting it from a list or map of nearby stations. You might ask yourself: where does the app know which stations exist? This is where we get back to step (2). The CPMS has already sent a list of all charging stations which belong to the CPO to the EMSP backend. This is done using the OCPI protocol. The list is continuously updated, so that the EMSP always has the latest list of stations, including their location and current status.

• The EMSP backend sends a Command(START_SESSION) OCPI message to the CPMS (5). This message contains the ID of the charging station and an authorization token.

  In contrast to the previous scenario, this token has not been handed to the CPMS beforehand. The CPO may only store this particular token for the duration of the charging session.

• The CPMS sends a RemoteStartTransaction.req OCPP message to the charging station (6). This message contains the authorization token.
• The charging station responds with a RemoteStartTransaction.conf OCPP message (7). This message indicates whether the request was accepted or not. Since our charging station is ready to work, it accepts the request.
• The CPMS forwards the result of the request to the EMSP backend using a CommandResult(ACCEPTED) OCPI message (8). The EMSP may then use this information to display this to the user in the mobile app.
• Depending on its configuration, the station may now try to authorize the token. It does this by sending an Authorize.req OCPP message to the CPMS (9). This message contains the ID token.
• The CPMS checks if the token is valid (10). In this case, the token is always considered valid, as it was provided by the EMSP backend.
• The CPMS responds with an Authorize.conf OCPP message back to the charging station (11).
• Since the token has been authorized, the charging station may now begin charging your EV. It indicates this by sending a StartTransaction.req OCPP message to the CPMS (12). This message again contains the authorization token.
• The CPMS now generates a unique transaction ID that identifies the charging session (13).
• The CPMS responds with a StartTransaction.conf OCPP message back to the charging station (14). This message contains the transaction ID.
• Since the charging session has started, the CPMS sends a Session OCPI message to the EMSP backend (15). This message contains the transaction ID and the charging station ID. The EMSP backend stores this information.
• While the charging session continues, the charging station continually communicates the current power consumption to the CPMS using MeterValues.req OCPP messages (16). The CPMS acknowledges these messages with MeterValues.conf OCPP messages (17). These meter values may also be relayed to the EMSP backend using OCPI, but I’m omitting this here for clarity.

Once you are done charging, you now decide to stop the session using the mobile app. The resulting process is similar to the one we just described:

• You open your mobile app and request to stop charging (18). The app sends a request to the EMSP backend.
• The EMSP backend sends a Command(STOP_SESSION) OCPI message to the CPMS (19). This message contains the transaction ID, which the EMSP backend had previously stored.
• The CPMS sends a RemoteStopTransaction.req OCPP message to the charging station (20). This message contains the transaction ID.
• The charging station responds with a RemoteStopTransaction.conf OCPP message (21). This message indicates whether the request was accepted or not. Since our charging station is happy so far, and is able to terminate the session, it accepts the request.
• The CPMS forwards the result of the request to the EMSP backend using a CommandResult(ACCEPTED) OCPI message (22). The EMSP may then use this information to display this to the user in the mobile app.
• The charging station now stops charging your EV and sends a StopTransaction.req OCPP message to the CPMS (23). This message contains the transaction ID and the final power consumption.
• The CPMS acknowledges this with a StopTransaction.conf OCPP message (24).
• You unplug your EV (25) and drive off.
• The CPMS now has to inform your EMSP about the charging session. This again is done by sending a CDR over the OCPI protocol (26).
• Finally, your EMSP will process the CDR and send you an invoice (27).

You can see that the app-based scenario is more involved and requires more communication, especially between the EMSP and the CPMS.

Conclusion #

In this blog post, I have described the basic process of charging an EV at a public charging station. I have focused on two basic scenarios, and only followed the happy path. I also omitted some messaging scenarios. For example, the station status (EV connected, charging, available…) is continually updated both via OCPP and OCPI. Also, OCPI allows for a number of different communication topologies between CPO and EMSP. I have only demonstrated the most basic one here.

There are many opportunities for something to go wrong in the process, as you might imagine. I also did not cover other scenarios, such as charging with a credit card, paying via SMS message, or Plug-And-Charge (which is a new standard that allows you to charge your EV without any manual authorization steps). The world of e-mobility is a complex one, and I have only scratched the surface. I hope this blog post has given you a rough overview of the involved actors and the process. Really going into the details would require a lot more time and space than I have here :D

Further reading #

Luckly, the underlying protocols are well documented. The standards are freely available and quite easy to read. I highly recommend reading them if you want to learn more about the details of the protocols. Here are some links to the relevant documentation:

• OCPI documentation
• OCPP documentation.

Note that there are also other roaming protocols, such as the confusingly named OICP (Open InterCharge Protocol) (which is specific to a single, proprietary roaming platform) and OCHP (Open Clearing House Protocol) (which seems to be defunct?).

I also didn’t go into the different charging standards and physical connector types, as well as into how the EV actually communicates with the charging station. If you are interested in this, I recommend Wikipedia as a starting point.

Photo credit: @chuttersnap