Enabling EV Roaming Through Cascading WebSockets in OCPP 1.6

Battery Electric Vehicles (BEVs) are gaining popularity worldwide and are considered to be an important component of sustainable transportation systems. They have the potential to reduce carbon emissions, improve air quality, and stabilize power grids. According to the International Energy Agency (IEA), the number of electric cars has significantly increased globally, with 16.5 million on the roads in 2021, compared to 10 million in 2020. Predictions estimate that the global electric vehicle (EV) population will reach 85 million by 2025 and could reach as many as 270 million by 2030, not counting two- and three-wheeled vehicles =1]. The intention to adopt BEVs positively correlates with the availability of charging stations, which is driven by supportive norms [2]. Despite being more expensive than internal combustion engine vehicles (ICEVs), declining battery costs and other advancements are narrowing the gap between the two [3, 4]. The adoption is also influenced by socioeconomic factors [5-7] and government policies [8-13]. A study conducted in Indonesia in 2021 found that there were only 97 private and public charging stations across the country, but this number is expected to increase.

BEVs require recharging their batteries in order to operate. Recharging can be done using either AC or DC fast charging methods at private or public facilities. The infrastructure for charging electric vehicles generally refers to charge points that are connected to the electrical grid, enabling them to supply power to BEVs. Typically, the charge point is equipped with a socket outlet to transmit power to the electric vehicle. On the other hand, the electric vehicle has a vehicle inlet to receive power from the charge point. Both parties are connected using a cable that has an interface with the plug on one end and an interface with the vehicle connector on the other end, as shown in Figure 1. The terminology for these accessories is defined in the International Electrotechnical Commission (IEC) 62196 standard series.

The IEC 61851-1:2017 defines electric vehicle charging in four modes [14]. Mode 1 (slow) uses AC electricity with a maximum current of 16 A and a maximum voltage of 250 V or 480 V. Mode 2 (slow to semi-fast) uses AC electricity with a maximum current of 32 A and a maximum voltage of 250 V or 480 V. Mode 3 (semi-fast to fast) uses AC electricity with a maximum current of 250 A and a maximum voltage of 250 V or 480 V. Mode 4 (fast) uses DC electricity with a maximum current of 400 A and a maximum voltage of 600 V. It is worth noting that the electric vehicle manufacturer of Tesla uses its own standards for products sold in North America, but will adapt to IEC standards for products sold in other countries.

11-1.png

Figure 1. Accessories of an EV charging system

The IEC also defines three types of vehicle connectors for AC electric charging in IEC 62196-2:2016 [15]:

(1) Type 1, which is commonly used in North America and Japan.

(2) Type 2, which is commonly used in Germany, Spain, the United Kingdom, the Netherlands, Sweden, and China.

(3) Type 3, which is commonly used in France and Italy.

In addition, the IEC also defines the vehicle connector for DC electric charging [16], Type 4, that includes three different standardized charging systems in IEC 62196-3:2014:

(1) CHAdeMO, which is commonly used in Japan.

(2) Combined Charging System (CCS) Combo 1, which is a Type 1 with an additional connector for DC charging and is commonly used in North America.

(3) Combined Charging System (CCS) Combo 2, which is a Type 2 with an additional connector for DC charging and is commonly used in Europe.

In relation to electric vehicle charging, Afshar et al. [17] break down the electric vehicle supply equipment (EVSE) into three categories: fixed charging stations (private or public), mobile charging stations (portable, truck-mounted, or vehicle-to-vehicle power transfer), and contactless charging methods (battery swapping or wireless road charging). To access public charging stations, such as by using a contactless card or radio-frequency identification (RFID), an EV driver typically must have a contract with the corresponding charge point operator (CPO). If the driver wants to use a charge point belonging to a different CPO with whom they do not have a contract, they can still do so as long as the driver has a contract with a mobility service provider (MSP) that has an agreement with that CPO, which may also have an agreement with other CPOs. This is referred to as ‘EV roaming service system’ as specified [18]. Roaming in electric mobility (EV roaming) enables seamless access to charge points from multiple networks with just one user registration, rather than having to create multiple accounts [19]. This leads to a more efficient process for EV drivers.

There are four major existing EV roaming protocols [20-22], namely the Open Clearing House Protocol (OCHP), the Open InterCharge Protocol (OICP), the eMobility Inter-operation Protocol (eMIP), and the Open Charge Point Interface (OCPI). These protocols allow seamless data exchange between CPOs and MSPs during roaming transactions, and enable the transfer of essential data, such as authentication data, remote start/stop control of the charge point, details about the charge point and charging session, and billing. In addition, these protocols rely on HTTP [23-27] and, to some degree, comply with the six criteria for open standards as formulated by the Committee on Technical Barriers to Trade of the World Trade Organization (WTO TBT), which are nowadays considered as the universal reference [28-30]. These criteria are openness, impartiality and consensus, effectiveness and relevance, coherence, and deve-loping country interests. A comprehensive explanation of how these major EV roaming protocols manage tasks such as user registration, start a charging session, stop a charging session, and billing can be found in the study [31].

On the other hand, the CPO internal system typically relies on the Open Charge Point Protocol (OCPP). This protocol has become a widely accepted standard and has been integrated into many charge point products today [32] for communication between charge points and their central management system using HTTP or WebSocket [33], where WebSocket is a full-duplex communication protocol [34]. Therefore, based on the fact that OCPP is available in many charge point products, this study aims to enhance the functionality of OCPP and explore its feasibility in supporting EV roaming between CPOs with its existing functions. This study could contribute as valuable examples that expand technology options and encourage more researchers to participate in the development of EV roaming protocols that are most suitable for their respective countries. The recent version of the protocol is OCPP 2.0.1 [35], but this paper only applies to OCPP 1.6. Thus, the term 'OCPP' without a specified version in this paper always means OCPP 1.6.

The remainder of this paper is organized as follows. Section 2 briefly reviews the OCPP and the four major EV roaming protocols: OCHP, OICP, e-MIP, and OCPI. Section 3 presents simulation models development, actual products utilization, and describes scenarios for the experiment. Section 4 presents the experiment results of the proposed system, and Section 5 discusses the results and relevant topics. Section 6 concludes this paper.

3.1 Simulation models development

Actors and roles involved in the experiment to simulate the proposed EV roaming system are defined as follows:

● The National Access Point (NAP) facilitates EV roaming in the proposed system. The NAP acts like a roaming hub and is assigned the role of both the WebSocket client and the WebSocket server.

● The Central System (CS) manages charge points and connects to the National Access Point to provide EV roaming services for EV drivers. This allows them to communicate and exchange data with other CSs. The CS is assigned the role of both the WebSocket client and the WebSocket server.

● The Charge Point (CP) delivers energy to an EV and allows it to recharge its battery. The CP is assigned the role of the WebSocket client.

Three simulation models for the experiment, which includes the National Access Point Model, the Central System Model, and the Charge Point Model, have been developed using Java, each representing an actor in the proposed EV roaming system. The development sequence as shown in Figure 4 was followed to ensure reliability. In addition, an open-source central system platform called SteVe [36], as shown in Figure 5, which was developed at RWTH Aachen University, was utilized as the benchmark for creating the models. SteVe supports OCPP up to version 1.6 and is distributed under the General Public License (GPL).

11-4.png

Figure 4. Simulation models development sequence

11-5.png

Figure 5. SteVe user interface

Figure 4 illustrates that once it is confirmed that SteVe can exchange data with the actual charge point product, it could be used as a reference for creating the Charge Point Model. The same method applies when creating both the Central System Model, which uses the fully functional Charge Point Model as a reference, and the National Access Point Model, which uses the fully functional Central System Model as a reference. It is important to note that both the Central System and the Charge Point are entities operated by the CPO, where, in best practice, the Central System is also responsible for managing users.

3.2 Simulation models interconnection

The three simulation models were designed to be connected to each other as shown in Figure 6. This connection technique, commonly found in distributed systems, enables seamless data exchange between the models. When a client sends a message to a WebSocket server, that server can forward the message to another server using another WebSocket connection, and so on, until the message reaches its appropriate destination. This will allow the models to work together effectively and efficiently, facilitating simulation of EV roaming activities.

Cascading the WebSocket connection is a technique used to pass WebSocket messages from one connection to another. It shares similarities with the cascading replication described by Red Hat, where a server acts both as a consumer and a supplier [37]. In both cases, the aim is to ensure that data is efficiently and reliably distributed across multiple connections, thereby improving the performance and reliability of the system. In the context of WebSocket connections, cascading can be useful in scenarios where a large number of clients need to receive real-time transactions in a system.

11-6.png

Figure 6. Cascading the WebSocket connection

3.3 Actual products utilization in the experiment

In addition to the simulation models, this study also utilizes actual charge point products in the experiment, including one charge point developed in-house and one manufactured by the industry. The in-house developed charge point has a maximum charging power of 22 kW and is equipped with Type 1 (J1772) connector, while the industry-manufactured charge point has a maximum charging power of 50 kW and is equipped with two connectors, CHAdeMO and CCS Combo 2. The objective of using these actual products is to ensure that the proposed EV roaming system can be implemented in real-world scenarios. Figures 7(a) and (b) show the visual representations of the two charge point products.

Furthermore, in order to simulate EV roaming using actual charge point products, this study utilizes an electric vehicle as shown in Figure 8. The car supports both Type 1 (J1772) and CHAdeMO connectors.

11-7a.png

11-7b.png

Figure 7. Charge point products used in the experiment

11-8.jpg

Figure 8. EV used in the experiment

3.4 Scenarios and evaluation

The experiment will be conducted based on five scenarios mentioned below. Qualitative evaluation determines whether the scenarios can be successfully simulated, while quantitative evaluation measures the time required for user authorization processes using both the completed simulation models and the actual products. In this study, the user authorization process is defined as the duration between the request message and the corresponding response message, which is used to authorize a user for using the charge point. Furthermore, it was decided to conduct the experiment during high traffic load conditions of a network where normal subscriber expectations would not be met, but for which a reduced level of performance should still be achieved to prevent excessive repeat calling and spread of network congestion, as described in the study [38].

The high traffic load conditions are chosen for the following reasons:

● Realistic testing: High traffic load conditions create a more realistic testing environment. If a system is intended to be used in a high traffic scenario, it is important to test it under such conditions to ensure that it can perform optimally in the intended use case. The objective is to ensure that EV roaming between CPOs remains available even during periods of high traffic load, such as peak hours.

● Performance evaluation: Conducting an experiment under high traffic load conditions is useful in order to evaluate the performance of the system under stress. This approach can help to identify any potential weaknesses that may not be seen under normal conditions. For instance, the network connection between CPOs remains stable, and user authorization is within the acceptable time limit.

● Optimization: High traffic load conditions can create an opportunity to improve system performance by identifying specific areas for optimization. For instance, new methods for user authorization that are more effective and efficient can be well-measured and introduced.

● Risk mitigation: Conducting experiments under high traffic load conditions can help to mitigate the risk of system failure and improve reliability by identifying potential issues in high load conditions that can be addressed to reduce the risk of system failure. In this case, the decision whether to increase the scalability of EV roaming networks can be obtained based on the endurance under high traffic load conditions.

The following are the five scenarios used for the experiment. Each scenario is coupled with its respective flow chart, which depicts user authorization to grant access to the Charge Point based on a valid user token, up to the provision of the CDR.

3.4.1 Scenario one

“An EV driver, D, registered with CPO 1, C₁, and received a valid user token, T, for accessing Charge Points operated by C₁, which then shares T with the National Access Point, N. Currently, D needs to access a Charge Point operated by C₂ using T, where C₂ has a ‘whitelist’ of valid user tokens from N. Thus, D can be granted access to the Charge Point.”

Figure 9 shows the decision whether or not to grant access to the Charge Point for scenario one.

3.4.2 Scenario two

“An EV driver, D, registered with CPO 1, C₁, and received a valid user token, T, for accessing Charge Points operated by C₁. Currently, D needs to access a Charge Point operated by CPO 2, C₂, using T. Both C₁ and C₂ have shared their 'whitelist' of registered user tokens with the National Access Point, N, for authenticating EV drivers who require Charge Points from CPOs they are not yet registered with. D can be granted access to the Charge Point operated by C₂ through authentication by N. After D finishes using the Charge Point, C₂ will send the payment details to N, which then shares them with C₁.”

Figure 10 shows the decision whether or not to grant access to the Charge Point for scenario two.

3.4.3 Scenario three

“An EV driver, D, registered with CPO 1, C₁, and received a valid user token, T, for accessing Charge Points operated by C₁. Currently, D needs to access a Charge Point operated by CPO 2, C₂, using T. Both C₁ and C₂ have shared their endpoint with the National Access Point, N, enabling other parties to authorize EV drivers who require access to their Charge Points. D can be granted access to the Charge Point operated by C₂ based on the following processes: 1) N provides the endpoint of C₁ to C₂, and 2) C₂ requests authentication of D from C₁. After D finishes using the Charge Point, C₂ will send billing information to C₁.”

Figure 11 shows the decision whether or not to grant access to the Charge Point for scenario three.

3.4.4 Scenario four

“An EV driver, D, registered with CPO 1, C₁, and received a valid user token, T, for accessing Charge Points operated by C₁. Currently, D needs to access a Charge Point operated by CPO 2, C₂, using T. Both C₁ and C₂ have shared their endpoint with the National Access Point, N, enabling N to redirect any authentication request to the corresponding CPOs. D can be granted access to the Charge Point operated by C₂ based on the following processes: 1) N redirects the authentication of D to C₁, and 2) C₁ sends the authentication result of D to N, which then forwards it to C₂. After D finishes using the Charge Point, C₂ will send an invoice to N, which then shares it with C₁.”

Figure 12 shows the decision whether or not to grant access to the Charge Point for scenario four.

3.4.5 Scenario five

“An EV driver, D, registered with CPO 1, C₁, and received a valid user token, T, to access Charge Points operated by C₁. Currently, D needs to access a Charge Point operated by CPO 2, C₂, using T. However, only C₁ is connected to the National Access Point, N, to enable EV roaming for EV drivers, while C₂ does not have an agreement with and is not yet connected to N. Therefore, D cannot be granted access to the requested Charge Point operated by C₂.”

Figure 9 also shows the decision to not grant access to the Charge Point for scenario five.

The provided scenarios for the conducted experiment in this study outline potential business models for the proposed EV roaming system, which can be described as follows:

●Scenario one, which demonstrates asynchronous data exchange, is the fastest user authorization in the experiment. This scheme requires CPOs to share their authorized user data with the NAP, which then shares the ‘whitelist’ of valid user tokens with all CPOs. This allows for local user authentication for EV roaming. However, as mentioned earlier, the drawback of this approach is that the system may not always have the latest information regarding a user's eligibility during the EV roaming process. Sharing valid user tokens with the roaming hub, which can then be shared with the CPO, is also provided by OCHP, eMIP, and OCPI. In this case, it is important to note that security and privacy issues must be taken into account and that the user agrees to the sharing of their data.

● Scenario two, which also demonstrates asynchronous data exchange, requires CPOs to connect to the NAP for user authentication. This scheme also requires CPOs to share their authorized user data with the NAP for authentication purposes. This scenario significantly demands more user authorization time than scenario one, and similarly, the system might not be updated with the latest user eligibility information during the EV roaming process. In this case, the NAP does not share the valid user tokens with the CPO, and user authentication is done by the NAP. Thus, the responsibility for data security is in the hands of the NAP solely, and also the CPO where the user was initially registered.

●Scenario three, which demonstrates synchronous data exchange, doubles the time required for user authorization in comparison with scenario two. This scenario requires CPOs to share their endpoint for the user authentication service with the NAP, which then shares it with the requesting CPO. This CPO needs to connect to the corresponding CPO using the provided endpoint for user authentication purposes. In scenario three, the NAP's task is completed after sending the endpoint to the requesting CPO. This approach can be considered new and for experimental only, as it was not found in OCHP, OICP, eMIP, and OCPI. There are no issues with data security and privacy concerns in this approach. However, the requesting CPO must find the relevant CPO to request for user authentication.

●Scenario four provides a user authorization time that is approximately the same as in scenario three. Moreover, this scenario also demonstrates synchronous data exchange, which reflects real-time user authentication. However, in scenario four, user authentication is performed by the CPO that owns the user data, whereas the NAP serves as a roaming hub for authentication. This is similar to those in OCHP, OICP, eMIP, and OCPI.

● Scenario five demonstrates that if a CPO is currently not supporting EV roaming (i.e., does not have a contract with the NAP), then the users belonging to other CPOs might not be granted access to charge points belonging to that CPO.

The effectiveness of the proposed EV roaming system starts with the establishment of connections between all components within the system. In this context, the connection between the WebSocket clients and the WebSocket servers are established from the CP to the CS up to the NAP. This arrangement creates a virtual channel for bidirectional data exchange that enables seamless communication for EV roaming or other purposes. It is clear from this paper that the proposed EV roaming system does not yet include any MSP, as in other existing EV roaming protocols discussed in this paper. However, this does not mean there is no room for the MSP in the proposed system, as this paper is intended to present the simplest architectural solution. In fact, the role of an MSP can be taken over by the CPO, such as for handling user registration, contract, and payment. In the case where an actual MSP exists, the business model could be similar as those described in OCHP, OICP, eMIP, and OCPI, with the NAP becoming a roaming hub that has an agreement with the MSP.

Payment details in an EV roaming protocol typically relies on CDRs. After the end of a charging session, a CDR is sent by the local CPO to the EV driver's home CPO, which then calculates the cost of the charging session based on the tariffs agreed upon with the local CPO. The EV driver is then charged by the home CPO for the charging session, and the home CPO pays the local CPO for the service. This method is useful for those who frequently use public charging stations and prefer only their home CPO for billing and payment. On the other hand, ad-hoc payments (pay directly using credit cards, mobile payment apps, etc.) are useful for those who do not frequently use public charging stations and do not want to commit to a subscription plan. Both CDR and ad-hoc payment have their pros and cons. CDR provides a more convenient and efficient payment process for EV drivers, as they only need to deal with their home CPO for billing and payment. Ad-hoc payment, in contrast, provides more flexibility and can be more convenient for EV drivers who do not want to be restricted to a particular CPO. However, ad-hoc payment can also be more expensive, as CPOs may charge higher fees to cover the cost of processing ad-hoc payments.

The CDR can contain data about start and stop meter values, and hence can be considered a source of energy consumption data. This data is important for various stakeholders, including the local government, as they may want to develop a predictive machine learning model to forecast energy consumption for the next day based on data from previous days for optimizing energy distribution, increasing energy efficiency, and reducing energy costs. Furthermore, such a model could potentially lead to dynamic pricing, which can benefit both energy consumers and suppliers. Consumers could save money by using energy during off-peak demand, while suppliers could manage their energy resources more efficiently, reduce peak demand, and ensure a stable supply of energy. Studies [39-41] provide information on the study that explores predictive models for energy consumption based on machine learning.

Calculating payments based on the CDR can be as follows:

$B=(E C \times B R)+T X$              (1)

where,

B  = billing price

EC  = stop meter - start meter

BR = base electricity rate

TX  = government tax

The NAP is the central element of the proposed EV roaming system, without which EV roaming cannot be carried out. In non-continental countries, such as Indonesia, where electric mobility in transportation occurs only within the country, an appointed government institution can participate as the NAP. Whereas in other countries where electric mobility in cross-border transportation is frequent, another business model may be preferred. Furthermore, it is important for regulations to be established that ensure cooperation between different charging networks and guarantee fair and transparent pricing for EV drivers. This will help to promote the growth of the EV market and increase adoption of electric mobility.

User authentication to authorize EV drivers who want to use a charge point can be achieved in several ways, including the plain verification and approaches that involve security. Plain verification could include methods such as checking the user’s identifier, whereas security approaches might involve N-factor authentication, or encryption to protect the user’s information and prevent unauthorized access.

Aydin [42] proposes an authentication and billing scheme for EV charging that includes mutual authentication based on a MAC calculated from random numbers and the encrypted user’s identifier using the AES algorithm. ElGhanam et al. [43] propose a fast, secure, and lightweight authentication and billing scheme using symmetric and asymmetric cryptography for dynamic wireless charging of EVs in an Internet of Electric Vehicles (IoEV) that integrates EVs into the Internet of Things (IoT) ecosystem. From all available sources, a comprehensive reference that discusses the authentication and billing scheme using OCPP can be found in the study [44].

The traffic load of the communication network could affect the performance of an EV charging session, with higher traffic loads increasing the chance of collisions and requiring more connection attempts for the session to complete. To guarantee quality of service (QoS) and quality of experience (QoE), it is important to classify the traffic on the communication channel between all entities involved in the session: the Charge Point, the Central System, and the National Access Point. In the study [45], traffic classification and prediction of network traffic load are discussed for a software-defined network with high prediction accuracy. The traffic load of the communication network also increases with the number of EVs in vicinity with the charge points. The populations of EVs in the residential, business, and working area, along with the corresponding load comparison of charge points under different forecast methods and the number of queuing vehicles, finish queuing time, and idle time are discussed in the study [46].

The authors would like to thank Wahyu Cesar and Firson Satriasta for their contribution in the development of the work.