IoT Applications and Services for Connected and Autonomous Electric Vehicles

Abstract

Automotive/transportation sector is undergoing a phenomenal course of rapid, multifaceted change. This transformation is enabled by similar factors that are driving advancements in the Internet of Things including increased computing resources and ubiquitous connectivity. In near future, Connected and Autonomous Electric Vehicle (CAEV) will evolve in ways that will have a major impact on transportation infrastructure, automotive industries, as well as vehicle ownership. As the number of connected vehicles continues to grow, the conventional Vehicle Ad hoc Networks are now evolving as the Internet of Vehicle (IoV). The IoV may be referred as a platform that enables the exchange of information between the vehicle and its surroundings through various communication media. In case of Connected and Autonomous Vehicle (CAV), it may be referred to Internet of CAV. This paper presents the implementation of CAEV toward an automated driving, and testbeds of CAEV use cases including automated charging management services and CAEV taxi services. The preliminary analysis shows that the effectual implementation of the CAEV use cases.

1 Introduction

Current trend of automotive industry is green, energy-saving, and intelligent to overcome global environmental crisis and energy challenges as well as to improve quality of life of the people.

Automotive/transportation sector is undergoing a phenomenal course of rapid, multifaceted change. This transformation is enabled by similar factors that are driving advancements in the Internet of Things (IoT) including increased computing resources and ubiquitous connectivity.

Hence, the IoT technology has a significant impact on the automotive industry. It is enabling various innovations such as automated driving, smart fleet management, and intelligent transportation infrastructure.

Autonomous vehicle (AV) technologies have been progressing at a very rapid pace over the past decade. In recent years, Connected and Autonomous Vehicle (CAV) as well as Connected and Autonomous Electric Vehicle (CAEV) technologies are considered as highly appealing automotive technologies.

Many companies are heavily investing in CAVs and adopting different approaches to bring the major changes in the automotive industry. Major players are traditional Original Equipment Manufacturer (OEM) including Ford, Mercedes-Benz that are already in the automotive business and disruptive players (i.e., Waymo, Uber) that have no significant background in the automotive industry.

Currently, some OEMs including Tesla and BMW already offer partially autonomous vehicles with self-driving features such as autopilot and self-parking. In near future, CAEVs will evolve in ways that will have a major impact on transportation infrastructure, automotive industries, as well as vehicle ownership.

As the number of connected vehicles continues to grow, the conventional Vehicle Ad hoc Networks (VANETs) are now evolving as the Internet of Vehicle (IoV) [1,2,3,4,5]. The IoV may be referred as a platform that enables the exchange of information between the vehicle and its surroundings through various communication media. In case of CAV, it may be referred to Internet of CAV (IoCAV).

CAEV technology is an active area of research and possesses numerous challenging applications. Though CAEV technology shows great promises and has substantial benefits, there are several impediments along the way of its deployment [6].

For instance, in automated charging services, CAEV shall have automated reservation and charging functionalities and might be able to charge without human aid using its built-in software, sensors, actuators, etc. However, a wireless charging station (WCS) should be able to offer automated charging capabilities by providing a charging service to the CAEV, which include WCS reservation and wireless charging process.

This paper presents the implementation of CAEV toward an automated driving, and testbeds of CAEV use cases including automated charging management services and CAEV taxi services. Such CAEV applications and services have the potential to benefit consumers, enterprises, and the public sector. The preliminary analysis shows that the effectual implementation of the CAEV use cases including CAEV charging management system and CAEV taxi service.

To the extent of our knowledge, this is the first work that shows CAEV testbed implementations with real-world scenario for wireless charging as well as CAV taxi service.

The remainder of this paper is organized as follows. Section 2 describes Connected and Autonomous Electric Vehicles, while Sect. 3 highlights IoT Technology and CAEV. In Sect. 4, CAEV use cases and services including CAEV charging management system, CAEV taxi service, implementation aspects, and preliminary analysis are discussed. Finally, Sect. 5 provides conclusion.

2 Connected and Autonomous Electric Vehicles

Connected and Autonomous Electric Vehicles (CAEVs) are complex automotive systems, combining connected vehicles (CV), autonomous vehicle (AV), and electric vehicle (EV).

A connected vehicle (CV) is a vehicle with technology that enables it to communicate with nearby vehicles, infrastructure, as well as objects, but may not be automated nor electrically operated. While, an autonomous vehicle (AV) is a vehicle that is, in the broadest sense, capable of driving itself without human intervention. And electric vehicle (EV) is a vehicle that powers up and operates with energy stored in the battery.

Typically, CAEV is a vehicle that is not only capable of sensing its environment and navigating with little or no human input and communicating with other entities but also is operated by the electric power. The CAEV may collect various sensors data through intra-vehicle communication system and feed the data to in-vehicle applications. Similarly, the CAEV may communicate with roadside unit (RSU), cloud infrastructure, and other CAEVs, to perform some computing tasks collaboratively.

Basically, the CAEV is composed of five major components.

• Perception system which is responsible for sensing the environment to understand its surroundings. The CAEV may sense its environment using various sensing devices including Radar, LiDAR (Light Detection and Ranging), image sensors, and 3D camera, etc.

• Localization and mapping system that enable the vehicle to know its current location. The most commonly used technique is Global Navigation Satellite System (GNSS) that provides geo-spatial positioning with global or regional coverage.

• Driving policy refers to the decision making capability of a CAEV under various situations, such as negotiating at roundabouts, giving way to vehicles and pedestrians, and overtaking vehicles.

• Communication system: As CAVs shall be connected to the surrounding environment such as vehicles with Vehicle to Vehicle connectivity (V2V), to the infrastructure with Vehicle to Infrastructure (V2I) and to anything else such as the Internet: Vehicle to Anything (V2X), through wireless communications links.

• Storage Battery System: This system includes charger and battery packs in the vehicle. Basically, state of charge (SoC) level determines the amount of charge stored in the battery.

2.1 Classification of Vehicle Automation

Society of Automotive Engineers (SAE) released SAE International Standard J3016 that sets out taxonomy and standard to define different levels of autonomy. SAE updated its classification in 2016 as SAE J3016-201609.

Basically, vehicle automation has been categorized into various levels of AV technology ranging from Level 0, corresponding to no automation, to Level 5, corresponding to full automation. For instance, automated driver-assistance systems such as adaptive cruise control correspond to lower automation levels, while fully automated driverless vehicles correspond to higher automation levels.

The SAE defined levels of vehicle automation is depicted as follows.

Level 0—No Automation: In this level, the human driver is responsible for all the driving tasks including control of the car as well as monitoring the road and environment around the car.

Level 1—Driver Assistance: In this level, the human driver is assisted with either steering or acceleration/deceleration by the driver-assistance system but not both. For instance, adaptive cruise control.

Level 2—Partial Automation: In this level, the driver-assistance system takes care of both acceleration/ deceleration and steering control of the car, while the human driver monitors the road and environment around the car. It includes more advanced levels of driver assistance and requires continuous supervision of the driver.

Level 3—Conditional Automation: In this level, the automated driving system undertakes all aspects of the dynamic driving task with the expectation that the human driver will respond appropriately to a request to intervene. Thus, it requires partial supervision of the driver.

Level 4—High Automation: In this level, the automated driving system undertakes all aspects of the dynamic driving task, even if a human driver does not respond appropriately to a request to intervene. This level is basically unsupervised.

Level 5—Full Automation: In this level, the automated driving system undertakes all aspects of the dynamic driving tasks in all roadway and environmental conditions. This level does not require driver at all.

Figure 1 shows SAE defined level of vehicle automation.

Fig. 1

SAE defined level of vehicle automation

2.2 Advantages of CAEVs

CAEVs offer many potential advantages in terms of sustainable development for environment friendly urban mobility, which are as follows.

• Improved safety: it may eliminate many of the accidents caused by human error, estimated at about 90% of all accidents.

• Greater mobility: it may provide services to those who cannot drive, including elderly, disabled, and children.

• Reduced parking needs: passengers may be dropped off at their destinations without needing a nearby parking space.

• Relaxed drivers: drivers may rest, work, or entertain themselves during a trip.

• Increased car sharing: it may significantly reduce the need for individually owned cars.

• Increased road capacity: through fleet platooning, more predictable traffic flow, and reduced congestion may be achieved

• Fewer ${\mathrm {CO_2}}$ emissions and pollutants: using the electric power to operate, it may reduce GHG emissions as well as air pollution; minimize environmental impact; improve quality of life in urban area.

• Less fuel costs: Fossil fuel will not be consumed to run CAEV, so fuel consumption is significantly reduced.

3 IoT Technology and CAEV

Automotive industry is one of the appealing sectors for the Internet of Things (IoT). By using smart embedded devices, the IoT can resolve several existing issues such as automotive safety, fuel consumption efficiency, and transportation-related infrastructure challenges.

The IoT enables information exchange between the CAEV, its surroundings, and the smart city. Using onboard IoT devices, data from ECU (electronic control unit) such as speed, temperature, location data, and other sensor data can be obtained for the vehicle, whereas with IoT devices, environmental and traffic information can be provided to the vehicle.

The IoT enables situation awareness services such as sharing and processing image and video information; detecting critical situations and alerting CAEV; enabling object detection on the road and obstacle avoidance; furnishing information on accident ahead; provisioning road conditions (i.e., slippery, icy). Thus, IoT-enabled driving allows the vehicle to identify traffic signs, markers, and signals and respond automatically.

The IoT applications and services may apply to many sectors where IoT-embedded devices performing tasks to replace human beings. In case of automotive sector, the IoT enables new numerous applications and services combining IoT technology and autonomous driving such as platooning, automated parking, Mobility-as-a-service (MAAS).

In recent years, many government agencies, research institutes, and major private companies are actively involved in the development of the IoV technology including IoCAV [7, 8].

IoCAV technology may be visualized as two vertical stacks—IoT stack and autonomous driving stack [7]. In Fig 2, the overview of IoT and Autonomous stacks for the IoCAV platform is depicted.

Fig. 2

Overview of IoT and Autonomous stacks for the IoCAV platform [7]

The vehicle uses own intelligent sensors to collect raw data from the vehicle to diagnose and analyze the data, record the driving information, and resolve the tasks. It also exchanges data with other entities in the vicinity such as roadside units (RSUs), vehicles, traffic lights.

IoT platform acts as a collection center for large amounts of data from various connected IoT devices. Using IoT provides supplementary source of data for the vehicle and enables efficient and robust IoCAV applications and services.

The IoCAV creates an integrated platform for supporting numerous services such as intelligent traffic management, intelligent vehicle control, dynamic information services.

The IoCAV may be composed of three fundamental components [7]: Vehicle IoT integration; IoT platforms and architecture; and Communication network. Figure 3, illustrates a high-level diagram of the IoCAV platform.

Fig. 3

High-level diagram of the IoCAV platform

Vehicle IoT integration enables using IoT devices, in-vehicle sensors for various functions such as local dynamic mapping (LDM), and provisioning autonomous driving functions, and data fusion functionality as well as includes vehicle IoT-enabled platform and communication modules.

IoT platforms and architecture may include various IoT-enabled CAEV services such as platooning, car sharing, CAEV taxi, automated parking, automated charging.

Communication network is a network layer that allows the exchange of information among vehicles, RSUs, pedestrians, sensors and actuators, and cloud infrastructure using communication protocols and standards such as WiFi, BLE (Bluetooth Low Energy), 3G/4G, LTE (Long-Term Evolution), 5G, ITS-G5/ IEEE 802.11p.

4 CAEV Use Cases and Services

Sensing capabilities, advance decision making abilities, cutting-edge computing resources, and emerging wireless networks have facilitated the deployment of IoCAV to yield various CAEV services and applications [9].

Some of the CAEV use cases and services that are designed and implemented in the SecCharge platform are discussed as follows.

4.1 CAEV Charging Management System

CAEV charging service may include various actors such charging station operator, network provider, the utilities in the IoT platform [10, 11].

The CAEV charging management system based on the SecCharge platform is presented. It consists of following key components: SecCharge CAEV server, Wireless charging station operators (WCSOs), and Energy service providers (ESPs) [12]. Figure 4 depicts a high-level diagram of CAEV Charging management system based on the SecCharge platform.

Fig. 4

High-level diagram of CAEV charging management system based on the SecCharge platform

ESPs are autonomous entities producing and distributing energy to the consumers. These consumers may be private (i.e., homeowners) or public (i.e., charging stations operators). Whereas, WCSOs are fundamentally accountable for operation and maintenance of wireless charging stations (WCSs). Typically, WCSOs may manage multiple WCSs at various charging sites/locations. A particular EV charging network may have several WCSOs.

A SecCharge CAEV system, which is a central component of the system architecture, acts as a Smart Management Center (SMC) for EV charging. It is designed for facilitating charging services to the CAEVs by providing effectual coordination with various WCSOs in EV charging networks.

On the one hand, SecCharge server may provide charging-related services to CAEVs including finding WCS location, assigning reservation and managing CAEV information, and financial transactions. On the other hand, SecCharge server is responsible for interacting with WCSOs for efficient smart charging. The SecCharge CAEV system may establish agreements with different WCSOs in the EV network such that CAEVs can charge in the entire EV charging infrastructure.

Consequently, the SecCharge CAEV system is based on a centralized server that smartly manages charging-related activities. In case of scheduling and reservation services, the system maintains reservation allocation information including occupied and available time slots, so that CAEVs may reserve the WCSs operated by different WCSOs.

An automated reservation mechanism for charging CAEVs has been described. By deploying an automated reservation mechanism, the CAEVs can reserve recharging schedule ahead of time, so such a strategy can not only minimize waiting time but also alleviate congestion at the charging stations (i.e., recharging congestion).

Automated reservation allocation scheme is a strategic constituent of the charging strategies. The automated charging module gets information from the sensing unit to determine the state of charge (SoC) of the CAEV. A threshold SoC for a CAEV ($SoC_{\mathrm {th}}$), say $30\%$, is an initial desired SoC level for recharging a particular CAEV. A critical SoC ($SoC_{\mathrm {cr}}$) is bare minimum SoC level in the CAEV. It should be noted that $SoC_{\mathrm {th}}$ must be greater than $SoC_{\mathrm {cr}}$.

Thus, as soon as current SoC reaches $SoC_{\mathrm {th}}$, it will send an alert and triggers Reservation Request (Reserve$\_$Req).

In automated reservation allocation scheme, the CAEV sends Reserve$\_$Req, which has 3-tuple {$SoC_{\mathrm {th}}$, $Loc_{\mathrm {cur}}$, Dest}, to the SecCharge CAEV system, indicating that the CAEV needs recharging. Figure 5 depicts message flows for CAEV Charging.

Fig. 5

Message Flows for CAEV Charging

Upon receiving Reserve$\_$Req, the SecCharge CAEV server shall deploy an algorithm for determining appropriate SoC level and reserving time slots with an appropriate charging station. Figure 6 depicts an algorithm flow for the automated reservation.

Fig. 6

Flow for Automated Reservation Algorithm

Target SoC level for recharging is given by:

$$\begin{aligned} SoC_{\mathrm {tar}} = \alpha \big ( SoC_{\mathrm {max}} - SoC_{\mathrm {cur}} \big ) \end{aligned}$$

(1)

where $\alpha$ is a coefficient for recharging, such that $\alpha \in \{0,1 \}$.

Determination of $\alpha$ depends on various factors such as distance to be travelled, a location of a WSC (i.e., downtown or suburb), and time of day (peak hour or wee hour). As SecCharge CAEV server is responsible for determining $\alpha$, in turn, $SoC_{\mathrm {tar}}$ for each CAEV, a slot allocation in WSC will be optimal.

Required charging time $t_{\mathrm {char}}$ is computed as:

$$\begin{aligned} t_{\mathrm {char}} = SoC_{\mathrm {tar}} \times \frac{Q }{CR_{x} \times \mu } \end{aligned}$$

(2)

where Q is CAEV’s battery capacity (kWh); $CR_{x}$ is charge rate; $\mu$ is CAEV charging efficiency, typically, $\mu$ = 0.9.

While computing $t_{\mathrm {char}}$, $CR_{x}$ should be considered with lower value of either the vehicle’s acceptance rate or the WSC power output rate.

With the list of nearby WSCs, the SecCharge CAEV server shall compute travel time ($t_{\mathrm {tra}}$) to each WCS as well as waiting time ($t_{\mathrm {wa}}$). The waiting time ($t_{\mathrm {wa}}$) is the time between the arrival time ($t_{\mathrm {arr}}$) of the CAEV to the WSC and the time that the CAEV starts to receive charging service.

Then, the SecCharge CAEV server shall determine the WSC with the least $t_{\mathrm {tra}}$ and $t_{\mathrm {wa}}$ and check if the required time slots are available in the given WCS.

If the required time slots are not available, then the SecCharge CAEV server shall choose the next WSC with lower $t_{\mathrm {tra}}$ and $t_{\mathrm {wa}}$.

After allocating the time slots in the given WSC, the SecCharge CAEV server shall generate Reservation ticket, which has reservation information. At least, the reservation information for the CAEV shall have Reservation start time($t^{\mathrm {r}}_{\mathrm {s}}$), Reservation finish time ($t^{\mathrm {r}}_{\mathrm {f}}$), and information on WSC location.

Reservation finish time and reservation duration can be computed as follows.

$$\begin{aligned} t^{\mathrm {r}}_{\mathrm {f}}= & {} t^{\mathrm {r}}_{\mathrm {s}} + \eta \times \delta \end{aligned}$$

(3)

$$\begin{aligned} \tau ^{\mathrm {r}}= & {} t^{\mathrm {r}}_{\mathrm {f}} - t^{\mathrm {r}}_{\mathrm {s}} \end{aligned}$$

(4)

After successful pre-authorization payment with help of the Payment gateway, the status changes to ‘payment pre-authorized.’ Upon successful generation of the reservation ticket, the SecCharge CAEV server shall send a confirmation for automated reservation (Reserve$\_$Confirm) to the CAEV. In the meantime, the SecCharge CAEV server shall also send the automated reservation details (Reserve$\_$Now) with $\tau ^{\mathrm {r}}$ in order to reserve time slot(s) at the given WCS.

Upon receiving Reserve$\_$Confirm, the CAEV can obtain a desired route to re-route via the given WCS.

4.2 CAEV Taxi Service

One of appealing use cases would be CAEV taxi service. The objective is to provide ride-hailing using CAEVs [13, 14]. It can be observed that a fleet of moving CAEVs around the urban city might drastically change land usage, for instance, reducing the parking area required in the urban environment.

The SecCharge AEV taxi service platform is discussed in this subsection. Figure 7 shows a high-level diagram for CAEV taxi service based on the SecCharge platform.

Fig. 7

High-level diagram for CAEV Taxi service based on the SecCharge platform

A SecCharge AEV taxi center is the main component of the CAEV taxi service that may get the client requests and use relevant data from the IoT platform to provide appropriate information on pickup/ drop-off to the relevant AEV taxi.

A client shall send a AEV taxi service request using a mobile application to the SecCharge AEV taxi center that operates within a certain geographical region. The taxi service request shall include at least a pickup location, a drop-off location.

Upon receiving the taxi service request from the client, the AEV taxi center shall collect relevant information such as traffic condition, road infrastructure condition using IoT platform to compute an appropriate route from the pickup location to drop-off location as well as calculate trip fares for two AEV taxi categories that include small AEV and large AEV.

Then, the taxi service center allows the client to select the AEV Taxi either large or small along with corresponding fare. With the user selection, the taxi service center shall choose the most appropriate AEV to serve the given client.

During AEV taxi selection, the system shall check the SoC level of AEV taxi for reachability analysis.

In order to conduct the reachability analysis, the system requires to determine the estimated SoC level at the drop-off location ($SoC_{\mathrm {fin}}$); for the sake of simplicity, it can be computed as follows:

$$\begin{aligned} SoC_{\mathrm {fin}} = SoC_{\mathrm {cur}} - \frac{ \{ \delta _{\mathrm {pd}} + \delta _{\mathrm {cp}} \} \times \zeta }{Q} \end{aligned}$$

(5)

where $\delta _{\mathrm {pd}}$ and $\delta _{\mathrm {cp}}$ represent travel distances from pickup to drop-off locations and from current to pickup locations, respectively; $\zeta$ represents the power consumption per kilometer (kWh/km); Q represents the battery’s rated capacity (kWh).

Figure 8 depicts a flowchart of the taxi dispatching mechanism. After computation of $SoC_{\mathrm {fin}}$, the system shall check if $SoC_{\mathrm {fin}}$ is greater than the lower limit of SoC level ($SoC_{\mathrm {lo}}$). If it is true, then the system shall send pickup location ($L_{\mathrm {pu}}$) and estimated pickup time ($t_{\mathrm {pu}}$) to that particular AEV taxi. Otherwise, the system shall apply charging scheme for choosing relevant WSC for that AEV taxi.

Fig. 8

Flowchart of the taxi dispatching mechanism

An one-time password (OTP)-based access code is send through email or SMS (short message service) such that the client has to use it in order to unlock the AEV taxi.

4.3 Implementation Aspects

SecCharge CAEV platform is based on modular architecture such that each CAEV use case may be run independently. Current implementation of SecCharge CAEV platform has two modules—CAEV charging management and CAEV taxi services.

SecCharge CAEV system utilizes combination of client-server, web-based and mobile architecture. The technical specifications of the SecCharge CAEV system are discussed as follows.

The SecCharge application is built on Model View Controller (MVC) architecture. MVC architecture divides application into three parts which are interconnected and have loose coupling. Loose coupling among these three components allows code reuse and easy code modification. The MVC architecture is implemented using the Spring framework which is generally referred as Spring MVC.

Oracle Express edition has been used as the database for application due to its high performance speed and multiple databases support.

Hibernate is an ORM (object-relational mapping) API which abstracts the SQL (structured query language) from developers. This allows developers to focus primarily on developing business logic thus speeding up the software development.

Apache Tomcat provides a light weight web container to host SecCharge application. Primarily, Tomcat was used because it supports Java and is compatible with Spring MVC and consumes less memory.

And Eclipse is deployed as a fundamental integrated development environment (IDE) for web application development, while Android Studio is used as IDE for Android platform development.

Being open-source operating system and Linux distribution based on Debian, Ubuntu is considered as underlying operating system in the SecCharge system.

Representational State Transfer (REST) is an architectural style that specifies constraints to induce desirable properties like performance, scalability, and modifiability. These desirable properties make a web service work best on the web. RESTful web services are the web services which implements REST architecture. In SecCharge system, web services are implemented using REST API provided by Spring framework. All HTTP/HTTPS calls in the application are performed over RESTful web services. And being lightweight data-interchange format, JavaScript Object Notation (JSON) is used.

As Open Charge Point Protocol (OCPP) is an application protocol for communication between wireless charging stations and a central management system, the OCPP is considered as communication protocols between WCSs and the SecCharge CAEV server in our implementation. Being an open protocol, the OCPP would allow WCSs and central systems from different vendors to easily communicate with each other.

For the testbed deployment, the SecCharge CAEV wireless charging platform deploys WCS emulator and miniature prototype of CAEV, which is shown in Fig. 9.

Fig. 9

SecCharge CAEV wireless charging platform Testbed

The miniature prototype of CAEV is built on RC (remote control) car using Raspberry Pi 3 along with a wide-angle camera, ultrasonic sensors and ${\mathrm {I^2C}}$-bus Pulse-width modulation (PWM) controller, namely PCA9685. The CAEV prototype has three different modes – manual; auto steering; and autopilot. In manual mode, the vehicle can be operated with any external device such as smart phone or joy stick as in RC car. In auto steering mode, the vehicle will be partially automated such that only throttle (i.e., forward or backward) needs to provided, the vehicle shall take care of the angle (i.e., left or right). And in autopilot mode, the vehicle shall perform automated driving such that it shall take care of both throttle and angle. In order to achieve an automated driving capability, the CAEV prototype uses various software libraries including OpenCV and machine learning tools such as tensorflow and keras.

The WCS emulator is built on Raspberry Pi 3 and ultrasonic sensor. So during the wireless charging process, the WCS shall verify the authenticity of the respective CAEV to be charged.

Furthermore, since the exiting operating system in Raspberry Pi 3 does not support Google Map services, a smartphone shall be being attached to the CAEV. And Android mobile app has been developed in order to utilize the Google Map services as well as communicate with the Back-end server. When the SOC reaches 30%, the mobile app shall generate a reservation request and send it to the SecCharge Back-end server. After accomplishing the automated reservation as mentioned in Sect. 4.2, the back-end server shall send the reservation response that includes the location of the wireless charging station (WCS). The mobile app shall then re-route the path to destination location ‘B’ from the current location ‘A’ through the WCS ‘C’, which is depicted in Fig. 10.

Fig. 10

Route to the destination B from current location A via wireless charging station C

4.4 Preliminary Analysis

For the use case of AEV charging management, one of the main requirements would be the selection of appropriate targeted SoC level. In order to provide efficient allocation of the time slots at the wireless charging stations, precise computation of $SoC_{\mathrm {tar}}$ is essential, which mainly relies upon $\alpha$.

Since technical details for full-fledged CAEVs (i.e., Level 4 and 5) are not available till the date, we have determined to utilize the technical specifications of the existing Battery Electric Vehicles (BEVs) such as Tesla Model S and BMW i3 for the testbed implementation. Table 1 shows the technical specifications of above-mentioned BEVs.

Table 1 Technical Specifications of BEVs

It should be noted that Environmental Protection Agency (EPA) has specified a total range (EPA rating) covered by a BEV with full charge.

It is assumed that charging outputs with power levels of 7.3 kWh and 11 kWh are used for charging process of the selected BEVs.

Determining proper targeted SoC level might be challenging since on the one hand, CAEVs do not need to recharge more frequently, but on the other hand, CAEVs do not have to spend lot of time at the charging stations.

Figure 11 shows the charging time with respect to various $SoC_{\mathrm {tar}}$. With increasing $SoC_{\mathrm {tar}}$, the required charging time increases significantly. In order to provide efficient time slot allocation, $SoC_{\mathrm {tar}}$ needs to be computed precisely.

Fig. 11

Charging time with respect to various targeted SoC levels

For the use case of AEV taxi services, a ratio $\Phi = \frac{N}{R}$ is defined, where a number of available AEV taxis are N and a number of rider’s trip requests are R.

In case, if current SoC levels of AEVs are insignificant, then they may fail to qualify reachability analysis, thus those AEVs may be eliminated during taxi dispatching process. That means, the waiting time for the rider ($t_{\mathrm {wa}}$), which can be stated as the time difference between the rider request time and the pickup time, may increase.

We have considered two scenarios. In the scenario A, it is assumed that AEV taxis have maintained $SoC_{\mathrm {cur}}$ such that they can serve any trips requested by the riders. Whereas, in the scenario B, it is assumed that about half of the AEV taxis have $SoC_{\mathrm {cur}}$ lower than $40\%$. Thus, they would not be able to serve all the rider trip requests with their $SoC_{\mathrm {cur}}$. Using above taxi dispatching strategy, we have computed the average waiting time $t_{\mathrm {wa}}$ with respect to $\Phi$ for both scenarios.

Fig. 12

Avg waiting time with respect to $\Phi$ for two scenarios

Figure 12 shows average waiting time with respect to $\Phi$ for scenarios A and B. In both case, the trend is linear and decreases along with increase in $\Phi$. When the ratio $\Phi$ is high, the rider waiting time is low. It can be seen that if there are more AEV taxis than riders and then there are many offers, then the probability to find a ride quickly becomes high. However, the waiting time in the scenario B is higher than in comparison with the scenario A.

5 Conclusion

As the number of connected vehicles continues to grow, the conventional Vehicle Ad hoc Networks (VANETs) are now evolving as the Internet of Vehicle (IoV). The IoV may be referred as a platform that enables the exchange of information between the vehicle and its surroundings through various communication media. In case of CAV, it can be referred to Internet of CAV (IoCAV). This paper presents a number of use cases describing the implementation of CAEV toward an automated driving. We have successfully deployed the testbed of SecCharge CAEV platform having two modules—CAEV charging management and CAEV taxi services. The preliminary analysis shows that the effectual deployment of CAEV charging management system and CAEV taxi service.