Abstract

Developments of technologies that facilitate vehicle connectivity represent a market demand. In particular, mobile device (MD) technology provides advanced user interface, customization, and upgradability characteristics that can facilitate connectivity and possibly aid in the goal of autonomous driving. This work explores the use of a MD in the control system of a conceptual electric vehicle (EV). While the use of MD for real-time control and monitoring has been reported, proper consideration has not been given to delays in data flow and their effects on system performance. The motor of a novel propulsion system for an EV was conditioned to be controlled in a wireless local area network by an ecosystem that includes a MD and an electronic board. An intended accelerator signal is predefined and sent to the motor and rotational speed values produced in the motor are sent back to the MD. Sample periods in which the communication really occurs are registered. Delays in the sample periods and produced errors in the accelerator and rotational speed signals are presented and analyzed. Maximum delays found in communications were of 0.2 s, while the maximum error produced in the accelerator signal was of 3.54%. Delays are also simulated, with a response that is similar to the behavior observed in the experiments.

1. Introduction

Transportation systems of the future will likely rely on some form of autonomous driving capabilities from vehicles [1]. Potential benefits of autonomous driving technology include the reduction or elimination of accidents, improved traffic flow, and increased energy efficiency [2, 3]. Vehicle connectivity is considered to be a key technological feature of reliable and universally autonomous driving. A “connected vehicle” is capable of communicating and interacting with other devices, vehicles, infrastructure, and remote servers [4, 5]. The recent passing of vehicle to vehicle (V2V) connectivity laws in Europe and the USA [6] is only the latest of a series of events that highlight the importance that connectivity has for the transportation industry.

Mobile devices (MD), such as smartphones and tablets, use operating systems (OS) that represent a potential enabling technology for connected vehicles. MD possess features and characteristics that may be extremely useful for such applications. For example, MD offer a wide catalogue of connectivity options, such as Wi-Fi, Bluetooth, NFC, and 4G LTE [7], provide location awareness as a key feature [8, 9], and provide built-in useful sensors like accelerometers and video cameras [1012]. Features that are inherent to MD, such as customizable and upgradable user interfaces, have become highly desirable for vehicle operation simply because people have become familiarized with them [1315].

There are many examples of the use of MD technology in automotive applications. For example, the use of smartphone OS in infotainment and navigation subsystems has been reported [16]. Also, recent products such as Android Auto and CarPlay allow a safe use of the phone features inside the car. Android Auto apps must be synchronized with installed phone apps and interact mainly with navigation and infotainment services. However, the potential of the use of MD in the vehicle environment extends beyond infotainments. Advantages of including a smartphone in the energy management systems of electric vehicle [17] and hybrid electric vehicles [18] have been presented. There are also examples of the use of smartphones in critical applications. For example, smartphones have been connected to the on-board diagnosis (OBD) network to extract information of potential risks on the road [19]. Other studies have explored the inclusion of a smartphone in a motorcycle helmet to obtain information and produce actuation with the objective of enhancing safety [20].

In spite of all their capabilities and the enthusiasm with which they have been used in transportation applications, there are important technological issues that need to be addressed before mobile devices can be introduced as a reliable enabler of connected vehicle capabilities. In particular, delays in communication and the impossibility to rigorously meet deadlines in scheduled tasks are factors that affect system performance. The studies discussed before have not addressed these issues. In particular, data processing for decision making and control of autonomous vehicles in future transportation systems will require real-time capabilities.

Current MD OS are optimized for telecommunications and energy savings but not for critical real-time tasks [21]. The use of unmodified smartphone OS to control mechatronic systems in real-time depends on the nature of the application. Common sense dictates that critical functions, such as the operation of antilock braking system in a vehicle whose faulty operation can result in serious damage, are beyond the capabilities of these systems. However, there are other possible applications in which potential damage can be prevented and for which the risks associated with the use of MD OS may be offset by their advantages. For example, applications in EVs have been reported for personal transportation [22], wheelchairs [23], and small unmanned electric vehicles [24]. Although research is currently underway to modify Android OS to produce a real-time operating system [2527], there is still an open case about which subsystems can use and exploit the advantages of current OS [28] in real-time applications, particularly those in a vehicle. Of particular interest are the effects of the delays on the system being controlled, an issue that is critical for establishing the feasibility of using a MD OS for a given purpose.

With the ultimate goal of facilitating vehicle connectivity, this work explores the use of an Android based control ecosystem (ABCe) to manage critical functions within the propulsion system of an experimental, task-oriented electric vehicle of modular design that is currently under development, called EvTEC. This work presents the basic architecture of the ABCe, a modular controller that incorporates a MD with unmodified Android OS that communicates with an embedded system. Special attention is paid to the measurement of the delays occurring in the control system. For this reason, the ABCe is evaluated through the measurement of the signal delays and their effect on performance of the propulsion system of the vehicle. The effects of the delays on the electric motor acceleration signal are quantified, from which the implications of the use of the MDOS are discussed.

The paper is arranged as follows. Details of the vehicle and propulsion system are provided in Section 2. Section 3 describes the Android based control ecosystem and the experimental setup. Section 4 presents the results of the experiments. Section 5 provides a discussion and remarks obtained, while Section 6 presents a simulation of the delays and a comparison with experimental results. Future work and conclusions of this study are shown in Sections 7 and 8, respectively.

2. The Electric Powertrain of EvTEC

The modular controller presented in this paper was developed to manage the powertrain of EvTEC, an electric vehicle that is currently under development. The goal of the EvTEC project is to design and build a utilitarian electric vehicle whose design is characterized by modularity, energy efficiency, and connectivity. The basic concept is shown in Figure 1. At the current stage, a prototype vehicle is under construction to serve as a test bed for the development of technology that will be required to achieve the intended design characteristics. The open architecture Android based controller is an example of such technological developments. The propulsion system of this vehicle is composed of a LiFeMnPO4 battery pack with a 4.2 kWh storage capacity and a powertrain composed of two electric motors connected to a gear train.

As mentioned before, energy efficiency in an electric vehicle can be improved by optimizing energy management inside the vehicle according to the foresighted driving conditions or as a byproduct of reduced vehicle weight, which in turn is a consequence of improved safety capabilities [2, 3]. The design goals for the ABCe are thus to provide connectivity with the user and the infrastructure and to manage power flow within the system in such a way that energy use is optimized.

Details of the powertrain architecture are shown in Figure 2. The shaft of the motor/generator A (M/G A) is connected to one of the lateral gears on differential 1 (D1). The shaft of the motor/generator B (M/G B) is connected to the other lateral gear on D1. The rotation of the lateral gears in D1 move the planetary gears inside D1 and the carrier. The carrier of D1 is meshed with a gear reduction (R). R is meshed with the carrier of differential 2 (D2) which is connected to the shaft of the wheels and provides traction. Lock 1 (L1) and lock 2 (L2) can fix the shaft of M/G A and M/G B, respectively.

In operation, the control will coordinate the motors response to obtain the highest combined efficiency according to the torque and speed requirement of the powertrain. The idea being to make the best use of the energy stored in the battery pack to extend the driving range of the vehicle.

The ABCe is used to control and manage the electric powertrain, as illustrated in Figure 3.

As a key element of the control system, the MD is a useful input/output user interface(UI), which enables the connection of the powertrain to the external world. The MD OS makes for a modular controller in that it is portable, customizable, and upgradable. This work uses these characteristics to develop an app that can be used to control the powertrain from a tablet or a phone.

3. The Android Based Control Ecosystem (ABCe)

The primary goal of the ABCe is to control the vehicle’s forward movement. To enable this, the system was designed to include an electronic board that can communicate with a MD using Bluetooth, USB cable, or wireless local area network (WLAN) connection. The particular connection through WLAN enables a drive over wireless (DoW) application, which eliminates the need for physical cable and provides superior transfer rates in comparison with a Bluetooth connection. This idea is in tune with the modular and customizable concept because it enables the control of the vehicle from anywhere, inside or outside of the passenger compartment.

The core of the electronic board used in this research is a P8X32A microcontroller. This microcontroller is made up of 8 independent cores of 32 bits each that share clock and I/O resources. The electronic board has 16 general use I/O digital channels and 8 analog input channels.

Figure 4 shows a schematic of the connections of the electronic board. The board controls the flow of accelerator signals (D I/O 0 and D I/O 4), regenerative braking signals (D I/O 1 and D I/O 5), and the signals to reverse the rotational speed (D I/O 2 and D I/O 6) of the motors. The electronic board also receives the signals from sensors and can measure the speed of the motors (D I/O 3 and D I/O 7), the current and voltage drawn from the battery (AI 0 and AI 1), the accelerator pedal signal (AI 6), and the braking pedal signal (AI 7).

The electronic board can be connected to the MD to WLAN, Bluetooth, or USB through the specialized transmitter and receiver pins (Tx and Rx in Figure 4). In this case, WLAN connection is used with an additional adapter, a RN XV Wi-Fly module. The MD used in this work is a first generation Nexus Tablet running Android 4.4.

The next section presents the details of the signal conditioning implemented for the control of the motor accelerator signal and the motor rotational speed sensing, as well as the details of the communication between the MD and the electronic board. Effects of the generated delays in communication over the speed of one of the motors already connected to the gear box are also discussed.

3.1. Control of the Accelerator Signal

In this control, the MD generates a command for the accelerator, which can be either produced by the user by an autonomous driving algorithm or received remotely by the connectivity options that are free. The command for the accelerator is transmitted to the electronic board at a programmed writing rate. The command for the accelerator is received by the electronic board Rx pin, at the programmed writing rate ± delays, which occur with a random nature. The command for the accelerator is translated into a pulse width modulated (PWM) signal which is conditioned to produce the accelerator signal: a voltage from 0 to 5 V that is received by the electric motor controller. The circuit schematic showing the implementation of the signal conditioning is presented in Figure 5.

3.2. Sensing of the Electric Motor Speed

The rotational speed of the electric motor is sensed by attaching a magnet to the electric motor shaft. A Hall Effect sensor is located in the near zone. When the sensor detects the magnetic field of the magnet, it acts like a switch, producing digital pulses. Figure 6 shows the implementation of the sensor and the schematic of the circuit to measure the rotational speed. The electronic board translates the signal received from the sensor to a rotational speed. The information of the rotational speed is transmitted through the Tx pin to the MD at a programmed Tx rate. The MD reads this information at the Tx rate  ±  delays, which are inherent to the MD in the control and monitoring system.

3.3. Experimental Setup

Delay data was obtained from direct measurements of the electric motor performance. The electric motor controller transmits the energy stored in the battery pack to the electric motor. The motor controller receives the acceleration signal from the electronic board as explained before. Figure 7 shows the experimental setup.

The RN XV Wi-Fly module in the electronic board is working as the host of the WLAN connection. Communication is performed under IEEE 802.11 g standard, working in the 2.4 GHz band. The baud rate was set at 11520. The operation range is 38 m. For tests purposes, authentication and encryption were left open.

4. Measurement Results

An accelerator signal is generated in the MD () as function of time in seconds (). The function is of the type , a sine function where the amplitude is , the period is , is the phase shift, and is the vertical shift. In this particular case, a sine function as shown in (1) was implemented. Consider

The electronic board receives the acceleration signal filtered by a floor function , as shown in (2). Conisder

Finally, the acceleration signal translated to a PWM percentage is given by (3). Consider

Experiments were performed at two different sample rates. In the first set of experiments (Test 1), a writing rate of 20 ms was programmed in Android to send the command for the accelerator signal. In return, a Tx rate of 25 ms was scheduled in the electronic board to send the rotational speed of the electric motor to the MD. In a second set of experiments (Test 2), the sample rates for writing in Android and the Tx in the electronic board were scheduled at 10 ms both. Each test was run 3 times. The mobile OS can schedule operations; however, it cannot guarantee the rigorous accomplishment of deadlines. The delays incurred in the sending and receiving periods for each sample are calculated using the equations shown in Table 1.

Figure 8 shows a typical plot of the delays in the sampling period for the experiments run here. The plot of Figure 8 corresponds to the writing loop delays () in the MD for the run 1 of the Test 1.

The magnitude and variation of the delays are represented graphically in boxplots as shown in Figures 9(a) and 9(b), where data from the sampling loops for Test 1 and Test 2 are shown. The left whisker represents the 2-percentile mark while the right whisker represents the 98-percentile mark. The left and right extremes of the box represent the 25- and 75-percentile marks, respectively. The bar inside the box represents the median. The star represents the mean and the circles represent outliers. There were 1500 samples in each run, so the boxplots, which shows data of the three runs, contain 4500 samples each. The boxplots reveal that, in average, the delays are close to zero; however the distribution, mainly of the reading and receiving loops, presents large spreads.

The delays introduced by the communication with the MD have an effect in the transmitted data. For example, the effect of the delays in the accelerator signal is displayed in Figure 10. The plots show the accelerator signal generated in the MD as a thin line and the accelerator signal received by the electronic board in markers. The three runs of the tests are displayed. Percentage of errors ( and ) between the ideal accelerator signal ( and ) with respect to the real values sent and received ( and ) are calculated with (4) where is the time in which sample happened. Table 2 summarizes the maximum, minimum, and average percentage of error obtained in each run. Consider

The effects of the delays on the speed of the motors can be appreciated in Figure 11. In Figure 11(a), the results for speed for the 3 runs of Test 1 are presented. In Figure 11(b), the results for speed for the 3 runs of Test 2 are presented. The speed transmitted by the electronic board is displayed like a thin line, while the speed read by the MD is presented in markers. The internal algorithm in the electronic board for the measurement of speed cannot yet effectively distinguish speeds below 2 revolutions per second. As a consequence, it takes some time to register the speed of zero. However, the data presented is still valid for the differences between what is sent and received between the electronic board and the MD. It is also accurate for speeds above 2 revolutions per second.

5. Discussion

The generation of a control signal in the MD is an important function for the purpose of controlling the electric motor of the vehicle powertrain. The purpose of the choice of a sine function introduced in (1) is not to reproduce a realistic accelerator signal function but to have control of what is sent to the electronic board. More work is needed to conclude whether the generation of the accelerator signal with the MD is the best choice, when, alternatively, an intended speed profile can be sent and, after that, control the necessary accelerator signal to produce that speed directly in the real-time embedded system of the electronic board.

The objective of Test 1 and Test 2, which differ in the communication sample rate, is to find a difference in the generation of delays in dependence of the scheduled sample rate, which was already found for the MD in [29]. Figure 9 not only expands that information for the electronic board but also illustrates the magnitude and number of outliers (data outside 2 and 98 percentiles). It was found that, indeed, the spread in the delays is different for each test, being larger for Test 1. Test 2 is performed with a sample rate of 0.01 s, which is the sample rate at which standard Controller Area Network (CAN) systems manage information in automotive applications [30]. While the median and mean in the delays measured are close to zero, the outliers above 98 percentiles show big delays. For Test 1 and Test 2, four and two values, respectively, of the sample period delays were between 0.15 and 0.2 s. Those are relatively big delays compared to the delays presented in the scheduled transmitting loop in the electronic board, which are almost zero. The electronic board, which is a real time embedded system, can schedule tasks with very good compliance with deadlines. For the current EvTEC propulsion system design, at its maximum speed of 40 km/h, a 0.2 s span represents about 2.2 m. Studies have shown that driver reaction times lie within 1.2 sec on average, and the NHTSA uses 1.5 sec as a standard for calculations [31]. In the worst case, signal delays may contribute significantly to the reaction time of the driver. A suitable safety strategy would have to be devised to attenuate the effects of such a delay.

The errors between the information that is sent and received (accelerator signal and speed) between the electronic board and the MD are small in all runs. The writing loops in the MD present lower errors than the receiving loop in the electronic board. This can be explained by the fact that while the writing loop is running, the data to be sent are stored in a buffer still inside the Android OS, which introduces variability in the receiving loop of the electronic board. The absolute maximum percentage of error found in the data was 3.54%, which corresponds to the difference between the ideal accelerator signal and the signal received in the electronic board. For the rotational speed, the errors can be appreciated in the plots (Figure 11). The rotational speed read follows closely the rotational speed transmitted in each run; the largest variations are observed between runs.

For the purpose of energy management, the control and monitoring system was able to pick up behavior from which power consumption data can be extracted. For example, Figure 11 clearly shows that the rotational speed data sent from the electronic board and the rotational speed data received in the MD have some variations. In fact, a pattern that indicates some type of transitory behavior between consecutive runs can be observed within the trials. Each acceleration cycle shown in the figure is produced by electric pulses ordered by the controller. In this particular case, all electric pulses were measured to be identical. Hence, these changes could be attributed to physical mechanisms taking place inside the power module, such as variations in oil viscosity caused by temperature fluctuations or the inertial effects of the moving masses of oil. Further work and instrumentation is necessary to find those factors and measure and control them or to adjust operating conditions to make better use of available energy (stored in the batteries).

The Android application is installed in an unmodified version of the OS, which means that processes that have a negative effect on predictability, like the garbage collector (GC), are still there. GC is responsible for memory management and periodically frees memory occupied by objects no longer used in the program [25, 27, 28]. The tests presented here are conducted in the presence of the actions of the GC.

6. Simulation of the MD OS Delays

Clearly, the delays produced by MD OS affect the response of the system. Models for these delays can help the designer predict the performance of a proposed control. To reproduce the effects of the delays in the proposed system with a simulation, an approach based on probability density functions is now introduced. The delays measured experimentally in Section 4 can be simulated using a mixture of skewed Gaussian distributions. The proposed probability density function is presented in (5) to (7), where is the mixture weight, represents the location, represents the scale, and represents the shape factor. Consider

The parameters of the distributions that provide a best fit for the experimental data are provided in Table 3. Random delays and can then be generated using . Figure 12 compares histograms of simulated and experimental delays obtained for the cycles of the MD and the electronic board.

The simulated delays can be plugged into equations (*) and (**) in Table 1 to predict the time at which each sampling cycle starts in the MD () and the electronic board (). Equation (8) is obtained in this manner. Consider

The accelerator signals sent by the MD are calculated using (9), where is the processing time between the start of the sampling cycle (when the ideal acceleration is computed) and the moment in which is calculated and sent. Figure 13 illustrates measured experimentally and simulated with a uniform distribution with values between 1.4 ms and 3.5 ms. Consider

The values of are transferred to the electronic board . The errors ( and ) are calculated according to (4). Figure 14 shows the obtained errors and their comparison with experimental results.

As can be seen, the simulated results follow a pattern similar to that of the experimental data. Clearly, a limitation of the approach presented here for the simulation of the delays is that outliers cannot be represented properly. For example, in this test, the 2.57% of the most extreme values of the delays in the MD were not shown in the simulation. For the case of the electronic board, 0.8% of the most extreme values of the delays were not simulated. Nevertheless, most of the delays in the sampling cycles can be effectively covered by this approach. To prepare a full simulation of the effects of the delays on the speed measured in the powertrain, it is necessary to include the mathematical models of the operation of the electric motors and the mechanical resistance created by the powertrain, which is beyond the scope of this paper.

7. Future Work

Future work includes a redundant system to handle the communication and enables the implementation of a fault tolerant control system. This would imply that the performance of the mechanical system will not be affected by the delays introduced by the communication with the MD. Other aspects to explore are the integration of the ABCe with a CAN bus and the possibility of complying with international communication standards. Finally, effects of electric and magnetic fields in the proposed control system must be further studied and evaluated. WLAN is susceptible to interferences from other networks working at the 2.4 GHz band [32], depending on factors such as the location inside the car. For that reason, an evaluation of possible interference sources given the distance between the WLAN host and the MD (which is expected to be short most of the time) must be addressed.

8. Conclusions

This work presented the basic architecture of an Android OS based controller used to control a critical system of the EvTEC concept. In particular, control of the accelerator signal was used. To achieve this, one of the electric motors that compose the propulsion system was conditioned and instrumented to interact with the Android based control ecosystem (ABCe). The integration of the MD is intended to provide the propulsion system of EVTEC with a modular and customizable controller that potentially can facilitate connectivity and driving autonomy.

Two stages were identified in the communication process between the electronic board and the MD: when the MD generates and writes commands to be received in the electronic board and when the electronic board transmits information to be read in the MD. Sample rates were programmed for these two stages.

Experiments were performed in which an intended acceleration signal was established and programmed in the MD to be sent to the electronic board. The electronic board transformed the received accelerator signal into a PWM signal to control the accelerator of the electric motor. Rotational speed of the shaft was measured and the information was transmitted back to the MD. During two tests, composed of three runs each, the sample periods in which the communication was produced between the MD and the electronic board were registered.

On average, the sample rates are accomplished as scheduled; however, maximum delays in communication occasioned by the introduction of the MD in the system can be as big as 0.2 s. The maximum absolute percentage of error in the accelerator signal caused by the delays in the scheduled rates, compared with the intended accelerator signal, was found to be only 3.54%.

A simulation for the delays in the sampling cycles is presented. A mixture of Gaussian distributions was fitted to the experimental data and was used to reproduce randomly the delays. With the simulated delays in the writing and Rx cycles, the errors in the transmission of the accelerator signal were simulated.

This work demonstrated that introducing a MD in the control and monitoring of physical systems will introduce delays in communications that must be taken into account in each application. While in this work the accelerator signal was generated and sent by the MD as a demonstration of capabilities and limitations, the MD can have numerous different uses in the context of connectivity, autonomous driving, and control of propulsion system, like speed limit detection, energy management, auxiliary in safety subsystems, or networks for cooperation between vehicles and infrastructure elements.

Conflict of Interests

The authors declare that there is no conflict of interests regarding the publication of this paper.