Virtual Reality Utilization in Electrical Vehicle Development

Abstract

This book chapter offers a new perspective on vehicle testing methods, by using driving simulators, which can be employed starting from early phases where components are designed, up to the real manufacturing stage. Based on these driving simulators, capable to thorough replicate real driving conditions, it can be described as a complex scenario, and the vehicle components can be dynamized with data coming from it. Therefore, with the use of a Virtual Reality (VR) environment, buildings, traffic signs, road types, and vehicles are imitated, and inspired by the real world or the imagination, but conclusive for the tested components. Moreover, for more realistic tests, a human driver can immerse into VR, controlling the virtual vehicle and leading to more reliable results. Many types of simulators are mentioned, with a focus on a specific type that is capable to test the vehicle’s propulsion system and its driver assistance systems. In the end, a case study is exposed where different configurations, software, and hardware, are tested and several results are presented.

1. Introduction

According to the latest report, published by the European Environment Agency [1], the case of premature deaths in the European Union (EU-28) for the year 2016, caused by suspended particulate matter (PM_2.5), nitrogen oxide (NO₂) and ozone (O₃), are estimated to 374,000, 68,000 and 14,000 of deaths, respectively. More nuanced, in terms of years of life lost (YLL), in the same causality order, the numbers are 3,848,000, 682,000, and 149,000 deaths. The most important sectors that contribute to the emission of air pollutants are transport, energy production and distribution, energy use in industry, industrial processes and product use, agriculture, households, institutions, and the commercial and waste industry. Relative to the year 2000, pollution mitigation is observed in all sectors, mostly in the transport sector, although both transported passenger and freight have been gradually increasing. Divided into two parts, non-road transports and road transports, both decreased the emissions of key pollutants (e.g. NO_x), but even so, this sector remains the most pollutant one.

From the road safety perspective, the number of victims due to road transport is amplified. Contributing factors in this increase are the infrastructure, the vehicles, the driving behavior, and the road exploitation. In the EU, in 2018, there was a threshold of 25,100 people who lost their lives while 135,000 were seriously injured. Compared to 2001, when the number of deaths was 54,000, there is a decrease of 55%. Considering the number of incidents in 2016 alone, of 1.35 million, supplementary measures need to be taken. Even so, the mindset, called “Vision Zero”, is to move toward zero cases by 2050 [2].

In this context, restrictive anti-pollution measures (Euro 1 to Euro 6) affecting conventional vehicles are obvious, becoming increasingly stringent in the last two decades. At the same time, in some European countries, supporting financial aid are offered for purchasing electrified automobiles. This can only lead to an accelerated transition and development of alternative propulsion systems. Categorized by the powertrain configuration, there are hybrid-electric vehicles (HEV), plug-in hybrid electric vehicles (PHEV) electric vehicles (EV), and fuel cell vehicles (FCEV). Their manufacturing involves several challenges because it is a relatively new branch of industry and the alternative is expected to be, at least, at the same level of security and comfort as conventional ones. When it comes to HEV, PHEV, and EV, the challenges are the system configuration, energy storage capacity, vehicle mass, battery charging time, charging mode, choice of electric motor, etc. [3, 4, 5, 6, 7]. In case of FCEV, hydrogen storage is a significant impediment to their widespread adoption. Another consideration when selecting an unconventional car is the availability of charging stations, which are considerably less for these types of vehicles, especially for FCEVs, due to their low popularity, as well as, still, immature technology [8].

A significant feature of vehicles that would drastically decrease the number of casualties on roads would be the presence of advanced driver-assistance systems (ADAS). They convert conventional vehicles into intelligent vehicles (IV), using communication systems and sensors. Communication between vehicles (V2V), infrastructure (V2I), and pedestrians (V2P) and usage of radio detection and ranging (RADAR), light detection and ranging (LIDAR), and cameras, all these are the key elements to success, evolving from fully dependent vehicles to autonomous ones.

Considering the aforementioned, it is necessary to involve all technical and technological resources to accelerate the development of these types of vehicles, aiming for human life quality increase. A significant resource in this regard is the driving simulator. Through such devices and virtual reality (VR) technology, it is possible to mimic real driving conditions. Such systems are used to perform tests where the driver and vehicle behavior has to be observed. Frequently, the quality assessment of different infrastructure services is done in the same manner [9]. The researchers from [10] approached driving simulators from engineering, medicine, and psychological perspectives. From a medical and psychological point of view, the emphasis is on understanding the effects of alcohol, fatigue, drugs, ADAS, infrastructure, the weather over the driver’s behavior, and also, the driver driving reactions. The engineering perspective emphasizes the development of the virtual world as real as possible so that the correspondence between the driving simulation and real driving response will remain almost unaffected. This means proper road designs, traffic signals and actors, and vehicle’s dynamics. The goal is to have a reliable tool that will help the development of electrified vehicle power trains and their safety systems.

2. Purpose of the study

Generally, the lifecycle of a vehicle follows the V-Model, starting from the feasibility study where the concept is explored, and ending up with the operational phase, when the product is used. Each hardware and software component are verified, validated, and tested (VVT) in all phases including, definition, design, implementation, integration, qualification, and production, mitigating the risk of failure [11]. In case of vehicle components testing, what concerns the power train, most of the tests are made through different speed cycles, varying from one region to another [12, 13, 14]. In Europe, there are considered two classical road cycles for testing: the urban and extra-urban cycles, entitled “Urban Driving Cycle” (UDC) and “Extra-Urban Driving Cycle” (EUDC), respectively. In the U.S.A and Japan, there are “EPA Federal Procedure” (FTP-75) and “Japan Cycle 08” (JC08). Recently, a new group of speed profiles was adopted in Europe, Japan, India, and South Korea, entitled “Worldwide harmonized Light vehicles Test Cycles” (WLTC), classified by classes where each of them is divided into speed phases. Through the power-to-mass ratio (PMR) principle, there are three vehicle classes: WLTC class 1, (PMR ≤ 22 kW/ton), WLTC class 2 (22 kW/ton <PMR ≤ 34 kW/ton), and WLTC class 3 (PMR ≥ 34 kW/ton). In what it concerns speed, there are low, medium, high, and extra-high-speed phases. Although the new driving cycles are more realistic, still, some drawbacks are present. The retired EUDC comprises several steady-state speeds, which do not represent the behavior of a real driver. The Japanese cycle contains the behavior of the real driver, but only in congested city traffic. The new WLTC uses real driving speeds, for all types of roads, with different PMR, but still, some conditions are not taken into consideration, like for example the weather conditions, road surface, traffic, pedestrians, and road profiles [15, 16, 17]. These lack lead to an idealized, unrealistic test, and to a lack of correspondence between testing and operation, which can lead to defects, hazardous situations, or sizing problems of vehicle components.

In this chapter, different, relevant, and decisive testing is approached, through driving simulator platforms, using the VR concept. The use of such an instrument in the process of testing EVs leads to a true picture of its behavior during operation. Additionally, production time and costs are substantially reduced. Specifically, different component configurations with different parameters can be tested in conditions like the real ones, starting from the designing phase, without the need to build a prototype vehicle. The such approach offers the possibility to interfere within a specific phase of design if needed. Both major components can be tested, starting from hardware as the powertrain, chassis, sensors, electrical system, and software, such as control strategies for motors, energy management strategies, and ADAS.

3. Driving simulators

The definition of a car simulator can vary from a simple computer model that simulates the dynamic behavior of an element within the vehicle to a structure with multiple degrees of freedom (DOF), with high fidelity, accurately simulating real-time behavior. Depicted in Figure 1 is a graphical representation of the most common types of car simulators, which were differentiated by the degree of flexibility/physical portability and the level of realism. Based on the simulation mode, a driving simulator can be defined as a model running offline or online.

Figure 1.

Driving simulator hierarchy [18].

3.1 The offline mode

This mode is represented by pure simulations, running on a computer where EV are mathematically modeled on software platforms such as Matlab, Simulink, Amesim etc., with different input parameters for each component. For example, power train testing can be made using profiles for speed, slope angle, and wind. The vehicle model varies from one quarter, if a suspension unit represents the interest, to the entire vehicle. One of the limitations of offline simulation is that it does not have an interface or graphical representation to visualize the simulations while they are being performed.

With respect to Figure 1, from the same category, scroll models are another type of vehicle simulator that may or may not run in real time. Such a model allows the rapid change of input values through variables that can be associated with the pedals and/or the steering wheel, ensuring greater control during the simulation (Figure 2) [18].

Figure 2.

Offline simulator model developed in Amesim.

3.2 The online mode

This mode refers to synchronization of a vehicle model with a real-time graphical interface, immersing the driver into a virtual reality environment. It contains at least one hardware unit, which is treated as the input for the model, manipulated by the driver, thus adding a man in the loop (MiL). Depending on the degree of complexity, the online mode covers a wide range of simulators, starting from a desktop-level simulator, to a motion simulator with multiple degrees of freedom [18].

One example of the online driving simulator was developed by the University of Jyväskylä, classified as a fixed frame simulator, which was used for a comparison study of the driver’s behavior while driving a real car versus a simulator. It comprises a platform with two doors and a dashboard. The equipment for the Hardware in the Loop (HiL) analysis was a Logitech G25 steering wheel and pedals (Figure 3) [19].

Figure 3.

Driving simulator developed by the University of Jyväskylä [19].

Another simulator with the highest realistic level, called the “National Advanced Driving Simulator” (NADS), was developed for the US National Highway Traffic Safety Administration (NHTSA), by the University of Iowa. This is a simulator with a mobile platform with multiple movements that uses a cab with a vehicle body inside, and on the interior walls is projected an image with a 360° aperture. The body is located on four actuators that provide vibrations associated with rolling on different road surfaces, while the entire cab is located on a mobile platform. The latter can provide rotational movements on the x, y, z axes, lateral and longitudinal movements. Their role is to reflect the orientation and acceleration of the car inside the VR system, similar to real operation conditions (Figure 4).

Figure 4.

Outside (up) and inside (down) images from the NADS driving simulator [10, 20].

Relevant scenarios for the traction chain can be simulated, based on real traffic conditions. In case of a traction motor, scenarios that implies different road types (e.g. urban, extra-urban, rural, motorway), with slopes, traffic, pedestrians, help in evaluating the dynamic response of the electric propulsion in all four quadrants. In cases where an overtaking is necessary, the motor is tested from the designing phase up to the real prototype, and its behavior is observed. Therefore, if needed, adjustments can be made from the early manufacturing process, leading to more suitable electrical propulsion systems.

4. Driving simulator components

The focus of this sub-chapter is the development of an (efficient) EV, not the driving experience, and therefore the structure of the simulator will refer only to a fixed frame that is reliable enough to serve our purpose. The basic structure of this simulator consists of two main elements, indissoluble, which are represented by the software component and the hardware component. The software component allows the modeling and simulation of VR world, and the vehicle dynamics. Hardware support is also required to run these tools, represented by a computing system, which may or may not be real-time. Also, when necessary, the presence of input/output ports is mandatory, helping the user to interact with the simulator (Figure 5).

Figure 5.

Driving simulator structure with a fixed frame.

4.1 The software components

4.1.1 VR modeling software

One of the adequate software platforms which will do the job for the driving simulator was made by TASS and it is called Prescan. This software tool was specially designed for the development of ADAS systems and intelligent vehicles.

The usage sequence of the software depicted in Figure 6 contains four major steps which must be followed prior to simulation evaluation. First, a relevant scenario for the interesting point is described, where the infrastructure and actors (vehicles) are modeled through Graphical User Interface (GUI), see Figure 7. The available library contains road segments, trees, traffic signs, buildings, and most important, the ‘actors’ (cars, motorcycles, and humans).

Figure 6.

Operation sequence of Prescan VR software for real-time operation [13].

Figure 7.

GUI of Prescan VR software interface [13].

At this level of defining the infrastructure, which can be a fictitious one or replicated from reality, vehicle dynamics (inertias, body dimensions, tires, center of gravity, etc.) must be configured. At the same step, the actor’s trajectories are defined, containing the paths and speed profiles. In car cases, the trajectory can be replaced with manual input, i.e. MiL, allowing the driving in the experiment through Human Interface Devices (HID).

The next phase is emphasized by the sensors modeling, grouped into three categories. Idealized sensors, which deal with V2I communication, using two principles, radio and infrared. There are detailed sensors such as cameras, LIDAR, RADAR, ultrasonic, and even Technology Independent Sensors (TIS). The last mentioned sensors, as the name says it, do not depend on any specific technology and are used to understand any active scanning sensor, offering the possibility to parametrize the beam, range, number of detected targets, target type, angles, energy loss, etc.

In the control stage of the operation sequence of the VR software, the mathematical behavior of the elements used within the experiments is introduced. If the previous two steps are defined in Prescan software, this stage of the study is employed in different software. Usually, a Simulink model will be sufficient to integrate the models; also, Amesim software can be considered. Within Simulink, specific input and output blocks are used to feed the VR experiment, but also to recover information about running conditions (for example, when the car is running on a hill, and the altitude is modified, the model needs to integrate such change within the mechanical model). This level of analysis is the most important since its complexity can affect the operation of the system and the accuracy of the results, but also the simulated driving experience and the reality perception.

In the last stage of the analysis, the experiment is running and the used can dive into virtual reality. This is again in Prescan, but it can be assisted by other real-time platforms for the real operation of equipment, such as electric propulsion, the energy transfer from the source etc. At this level, we are using a dSPACE platform, which is also programmed through Simulink to ease the interaction.

4.1.2 Vehicle dynamics modeling and computing platform

Several details will be given here about the third stage of the analysis. Before running the experiment, in “Engineering Workspace” represented by a different software platform as Simulink (in our case, but it can be in Amesim as well), the vehicle algorithms for sensors control and its dynamics are elaborated. The vehicle dynamic model is depicted in Figure 8, which contains the propulsion unit, shift logic, gearbox, and chassis. Based on throttle reference, motor dynamics, chassis dynamics, and the initial state of the vehicle, the next state is calculated, where state refers to position, velocity, and acceleration. Each state has two components, for translation, XYZ, while for rotation is RPY. The term RPY comes from Roll, Pitch, and Yaw angles, with rotational direction around XYZ axes.

Figure 8.

Vehicle dynamic model developed in Simulink.

4.2 Hardware components

A driving simulator which serves as a unit for EV power train research and development, is made from a frame that is support for a personal computer (PC) with one or more screens, a real-time (RT) platform, and a HID – see Figure 9.

Figure 9.

The driving simulator developed at the technical University of Cluj-Napoca.

The structure can be extended, when the real power chain is tested, with a real motor-generator configuration, a controller, a power source (battery), and an electronic load (to emulate the real electric power consumption). Moreover, in order to monitor the electric parameters, a measuring instruments cluster is interposed between the motor and controller, as between the generator and electronic load – see Figure 10.

Figure 10.

The electric traction chain used to extend the developed driving simulator developed at the technical University of Cluj-Napoca.

There are three possible hardware configurations for our simulator, considering the EV dynamics. For the first two of them, the vehicle dynamics is deployed on computational platforms and the difference is whether it is or not in real-time, while the last one uses a real electric power chain (see Figure 11 for the definition of the possible operating configurations).

Figure 11.

Studied driving simulator hardware configurations.

4.2.1 HID-PC

The simplest configuration uses a PC and an HID, whereas the latest comprises a steering wheel and foot control pedals (gaming kit), connected via USB cable. The VR and vehicle dynamics computing software runs on PC, on the programmed scenario and driver input.

4.2.2 HID-PC-RT

Additional to the previous configuration, there is an RT platform, for more complex vehicle models, where RT computing power is needed. The vehicle dynamic model of the power train is deployed on the RT platform, while the PC is used for chassis dynamics and VR. Here, the HID signals are divided, the path reference is sent toward the PC, while the speed reference is toward the RT platform. The resulting speed of the vehicle is sent to PC, based on reference, power train dynamics, and road angle.

4.2.3 HID-PC-RT-PT

The last configuration implies the presence of a real power train, consisting of two electric machines (one operating in the motor regime, while the second one in the generator regime), an electronic controller to control the electric motor, a power source (a battery) and an electric load (which recovers the electric power generated by the second electrical machine, based on a profile correlated with the running conditions which are imposing the total resistant force applied to the motor’s shaft). The motor is controlled by the electronic controller, supplied from the battery, with the reference speed signal provided by HID. The energy produced by the generator could be injected back into the battery, supercapacitors, or into the grid. The motor speed is measured and sent to PC (within Simulink), and as a result, the vehicle moves into VR accordingly (within Prescan).

5. Driving simulator modeling

As mentioned above, several steps must be followed prior to the experiment launch, represented by the sequence:

5.1 Scenario designing

The world within the VR can be modeled by a fictitious scenario, elaborated on basis of testing interest points, or/and from reality, thus replication of the real world. A good basis for the real world can be exported from Open Street Map, as.OSM file. This type o file contains data in form of points, connections, and street name properties (tags). Thus, the infrastructure is rebuilt in 2D, with no elevation option. Built from segments, if the altitude of each end of the segment is known, conversion into 3D is made possible. The altitude information can be obtained through Google Maps, in the Terrain section. Next, importing a base layer for road, which is exported from Google Maps as a Print Screen, helps with graphics improvement. Due to lack of information in exported. OSM file regarding the buildings and traffic signs, replication can be achieved through the software library.

The real and replicated maps used in the VR experiment are depicted in Figure 12.

Figure 12.

Real Google (up) and replicated (down) maps drawn in Prescan VR infrastructure.

The map must be populated with actors, represented by vehicles and humans, each of them having their own law of motion. After placing the vehicles, their dynamics are parametrized accordingly, starting from inertias, wheel radius, center of gravity, body dimensions, suspension stiffness and damping rate, ending with tire stiffness. Subsequently, vehicle and infrastructure sensors will be added and parametrized, depending on the sensor type. There are some generalities for all the sensors as position, orientation, and range, but also particularities, for example, a camera resolution and its focal length or the capture frequency for an ultrasonic sensor. In the end, for the actors which are not manipulated by HID, the trajectories are assigned to them. A sample of the employed parametrization of the aforementioned characteristics is shown in Figure 13.

Figure 13.

Vehicle dynamics in PreScan software.

5.2 Dynamics designing

The elaboration of the control algorithms to model the dynamics and component structures of the vehicle takes place in Simulink, see Figure 14. Keeping interest in testing an electric vehicle, it was necessary to replace the default engine model, employed in Prescan, with an electric motor. The synchronous motor with permanent magnets was used (actually, an inverted structure, with the outer rotor, also called as an in-wheel motor). A considerable benefit of choosing this structure is the lack of mechanical transmission, which means that reduced mechanical losses are generated by the propulsion system.

Figure 14.

EV dynamic model.

The comparison between Figures 8 and 14 emphasize the propulsion replacing, moreover, removal of the mechanical transmission blocks and gear shift logic had a place.

The motor was modeled in the rotor synchronous rotating frame (dq frame), and it was vector controlled, [21, 22]. The model of the concerned machine, a permanent magnet synchronous motor (PMSM) with surface-mounted magnets, contains the voltage equations (function of the fluxes or the currents), the torque balance dynamic equation, and the electromagnetic torque.

$$\begin{array}{l}{U}_d=R\cdot I_d+L_d\frac{{\mathit{dI}}_d}{\mathit{dt}}-{\omega }_r\cdot L_q\cdot I_q\\ U_q=R\cdot I_q+L_q\frac{{\mathit{dI}}_q}{\mathit{dt}}+{\omega }_r\cdot L_d\cdot I_d+{\mathrm{\Psi }}_{\mathit{md}}\cdot {\omega }_r\end{array}$$E1

$$\frac{d{\mathrm{\Omega }}_r}{\mathit{dt}}=\frac{1}{J_r}\cdot \left(T_e-B\cdot {\mathrm{\Omega }}_r-T_r\right)$$E2

$$T_e=p\cdot \left[\left(L_d-L_q\right)\cdot I_d\cdot I_q+{\mathrm{\Psi }}_{\mathit{md}}\cdot I_q\right]$$E3

where R phase stator resistance, L_d, L_q are the inductances in the direct and quadrature axis, p is the number of pair of poles, ω_r, Ω_r are the electric and mechanical speed, respectively, J is the inertia of the mobile part of the PMSM, B is the air friction coefficient, Ψ_md is the direct axis component of the main flux of the permanent magnet (the one in the q axis is neglected), and T_e, T_r are the electromagnetic and resistive torque components, respectively.

In the dq coordinates frame, the supply of the PMSM is assured via an equivalent chopper which can offer two possible voltage values, ±U/2, (U being the dc bus voltage), which means that the voltage reference vectors, u_d, u_q, are:

$$\left[\begin{array}{l}{u}_d\\ u_q\end{array}\right]=\frac{U}{2}\cdot \left[\begin{array}{l}{u}_d^{\ast }\\ u_q^{\ast }\end{array}\right],$$E4

The control logic relies on PI controllers which will offer the quadrature current reference function of the speed error, the direct and quadrature axis reference voltages function of similar currents error, while the reference direct current is imposed to zero for maximizing the torque.

The Simulink diagram of the motor is depicted in Figure 15.

Figure 15.

PMSM model with a vector control technique.

The mechanical model of the traction system, which integrates the operation down or up on the hills, is presented next.

Resistant torque applied to the motor shaft resulted from the vehicle resistant forces, namely climbing force (F_h), aerodynamic drag force (F_d), wind resistive force (F_w) and rolling force (F_r), [23, 24].

$$F_m=F_{\mathit{acc}}+F_h+F_d+F_w+F_r$$E5

where F_m is the motor force deduced from its torque and wheel radius and F_acc is the acceleration force.

The climbing force depends on the angle of incline θ, imported from VR, and uses the expression:

$$F_h=M_{\mathit{tot}}·g·\mathit{sin}\left(\theta \right)$$E6

where M_tot is vehicle mass (kg) and g is the gravitational acceleration (m/s²).

The drag force depends very much on vehicle aerodynamics, considering its frontal area (A_f), air density ($\mathit{\vartheta }$), aerodynamic coefficient (k_d) empirically determined for each body shape, and the vehicles speed (v), expressed as:

$$F_d=A_{\mathit{fr}}·\vartheta ·v^2·k_d$$E7

In what concerns the resistance force due to wind, the wind relative coefficient (k_rv), the drag force, the vehicle’s speed, and wind speed (v_w) are part of the equation:

$$F_w=\left(\left(0.98·{\left(\frac{v_w}{v}\right)}^2+0.63·\left(\frac{v_w}{v}\right)\right)·k_{\mathit{rw}}-0.4·\left(\frac{v_w}{v}\right)\right)·F_d$$E8

The last resistant force, rolling resistance, is proportional to the road’s surface coefficient (k_r) and angle:

$$F_r=k_r·M_{\mathit{tot}}·g·cos\left(\theta \right)$$E9

5.3 Communication designing

Depending on the hardware set-up, in some cases, the link between the hardware components must be configured. In the first case (a) where is only one connection, between HID and PC, usually via USB cable, there is no need to configure it due to drivers supplied by the HID manufacturer. Nevertheless, for case b there are two new links involved, between the RT platform and HID, and between the RT platform and PC, respectively. First of them, where the speed and break reference are sent toward the RT platform, ordinarily the signal type is analog, coming from a potentiometer, which could be connected to analog inputs of the RT platform. The other one, between the RT platform and PC, where information from VR traffic is sent to the RT platform and speed response back to VR, could be done using CAN, Ethernet, and even Serial communication. In the end, in case of c, compared to the previous case, an additional connection is defined between the RT platform and power train (PT). Again, this could be facilitated through CAN, Ethernet, Analog Signal, depending on the available hardware features.

6. Case study

In this section, the results obtained from several co-simulations will be presented. In all cases, the virtual vehicle was driven for one lap over the circuit shown in the map from Figure 12. Three software configuration variants and one HiL configuration are presented. These configurations were: Prescan-Simulink, Prescan-Simulink-Amesim, Prescan-Simulink-dSpace, and Prescan-Simulink-dSpace-PT. For cases where the motor has been simulated, the parameters are equivalent to the ones from the actual motor. Additionally, a V2I communication was tested through an RF sensor mounted on a traffic sign. Its purpose was to limit the speed of the vehicle when it was getting close to the first intersection.

The parameters of the electrical power train used in the simulation, and for the control of the real motor, when a specific battery voltage was used, are given in Table 1.

PMSM parameters
Rated power	3 [kW]	Permanent magnet flux	0.0518 [Wb]
Speed	420 [rpm]	Motor inertia	0.2214 [kg∙m^2]
Rated torque	68 [Nm]	Mechanical friction coefficient	0.01
Pole pairs	28	Stator resistance	0.04 [Ω]
Supply voltage	48 [V]	d-axis inductance	0.4 [mH]
Rated current	63 [A]	q-axis inductance	0.4 [mH]

Table 1.

Real and simulated motor parameters.

6.1 Prescan-Simulink co-simulation

Here we had a co-simulation that lasted for approximately 160 seconds, with results depicted in Figure 16. The speed reference provided by the throttle pedal, scaled in the motor-rated speed (0–44 rad/s) is observed, which is thoroughly followed by the motor, except for the moments of acceleration and deceleration, when, as expected, the error occurs due to vehicle inertia.

Figure 16.

Motor speed reference (red) and its response (blue).

In the 20th second of the simulation, the V2I communication intervenes, which caps the speed at 30 km/h. The graph with the representation of the throttle pedal highlights this aspect, see Figure 16, where in yellow there is the resultant reference speed resulted by the speed limit algorithm. The antagonistic interaction of these two values is obvious, having as an operational period the time interval in which the vehicle is within the range of the RF sensor and the speed surpasses the set limit.

A correlation between the component of the current on q axis (red) and the electromagnetic torque developed by the motor (blue) is observed in Figure 17; there is direct proportionality relation between them. For the acceleration and deceleration phases, the electromagnetic torque differs from the resistant one, which emphasizes the inertia presence. Of course, at the same time the current amplitude of the three-phase increases during these periods. Although the constructive parameters of the motor power is 3 kW, this is exceeded in the moments of acceleration/deceleration, due to the threshold set higher than the nominal one in order to obtain better dynamic performances. This is allowed only if it is mentioned in the motor specifications and can be done for short periods of time.

Figure 17.

Motor parameters evolution during simulation: Dq axes currents, three-phase currents, torque, and mechanical power.

6.2 Prescan-Simulink-Amesim co-simulation

In the case of this simulation (with the results depicted in Figures 18 and 19), traversing the perimeter of the campus took approximately 168 seconds. The control strategy modeled in Amesim differs from the one in Simulink: here, the torque control strategy is approached.

Figure 18.

Motor parameters evolution during: Torque and axis currents.

Figure 19.

Motor parameters evolution during simulation: Currents, speed, and mechanical power.

It should be mentioned that the flux weakening control strategy is also employed, the sub-model of the torque regulator being built to provide both references of the current, meaning the d, q components. The reference maintains the same source of origin as in the previous case, except that the scaling was done with torque values from 0 to 68 Nm, the maximum value of the rated torque of the machine. The reference torque is followed by the machine and due to a different control strategy, which limits the torque to a rated value, its value is less than half compared to previous results (Simulink). A reason for this change could be the different driving behavior of the driver.

The maximum angular speed of the motor exceeds the rated value, the reason being the strategy of flux weakening, possibly due to the value of the resistant torque, lower than the machine’s rated one. The maximum linear speed of the vehicle in this cycle was approximately 18 m/s (64 km/h), with 5 m/s (18 km/h) more than in the previous case.

6.3 Prescan-Simulink-dSpace co-simulation

The results presented in this sub-section (see Figure 20) are dealing with a real-time system, based on dSpace platform (a MicroLabBox unit was used), in which the model from Simulink was deployed. The simulation time was about 230 seconds, so a less aggressive driving style was adopted. With the reduction of acceleration/deceleration, the value of dynamic torque was also reduced – an aspect visible in the torque plot.

Figure 20.

Motor parameters evolution during simulation: Speed, torque, and currents.

From the representations of the three-phase currents and iq component, there is a decrease in amplitude, compared to the first results; this reconfirms a relaxed driving style. As in the case of the first presented results, the component element of the id current is zero, thus the flux weakening strategy remains absent.

6.4 Prescan-Simulink-dSpace-PT

In the last analyzed case, the exposed results are real (see Figure 21), measured in the virtual intermediate circuit and at the motor terminals, by means of transducers. The driving cycle lasted approximately 178 seconds, during which a moderate driving style was adopted.

Figure 21.

Motor parameters evolution during HiL simulation: Speed, voltage, currents.

An attempt was made to replicate a driving profile similar to that in the previous simulations so that the obtained results could be comparable. Therefore, between the simulation results with the model employed on the RT platform and the real motor, at rated speed, it can be observed the approximate equal level for the amplitude of the stator currents. Additionally, the voltage and current flow from the battery were measured, where the presence of measurement errors is observed.

7. Conclusions

The need for vehicles with reduced or zero pollution potential, such as hybrid (HV), purely electric (EV), and fuel-cell (FCV) vehicles, pushes toward the evolution of their testing and validation, which implies that their progress follows an accelerated trend. In order to maintain this trend, a different approach for testing propulsion systems has been proposed here, by using driving simulators. This chapter focuses on the development of a car simulator that uses the virtual reality (VR) concept, with an online simulation model, being ranked at a realistic level of a fixed platform simulator.

The specialized software, embedded in the project, is represented by Prescan, Matlab/Simulink, and Amesim software packages, which are used for: modeling/simulating the VR (Prescan), modeling the vehicle dynamics (Amesim and Simulink), and its control (Simulink). The hardware components are also present, by using a personal computer (PC), a real-time (RT) platform (based on a dSpace board, i.e. a MicroLabBox unit), the graphical interface (special video-card and screens), and the human interface device (HID), meaning the steering wheel and pedals used by a “driver”. The replication of the perimeter of the Technical University of Cluj-Napoca campus, inside the VR environment, was used as the test circuit, for different co-simulation configurations. A permanent magnet synchronous motor (PMSM) topology was tested on this circuit, both in the form of a mathematical model and a real motor. In both cases, the results are quite similar. In the simulated models, both control strategies, with speed and torque reference, were implemented and simulated and the expected results have been obtained. A simple vehicle control algorithm was also successfully tested.

The challenge of finding the right solution for the propulsion unit it is not an easy task, due to the vast number of mechanical and electrical constraints. The required performances of the electrical motor are dictated by the application, thus for an EV/HEV the most important mechanical performances are torque, speed, vibrations, and acoustic behavior because they affect the vehicle dynamics and the passengers’ comfort. From the electrical point of view, the supply voltage, current, frequency, and efficiency are a few of the focus points, when the optimum operation is desired. The specific values for the mentioned parameters were emerged from the EV desired characteristics.

In conclusion, the results presented on the car simulator for testing the propulsion of electric vehicles, support and validate its use for the implementation, testing, and development of new hardware and software subsystems that are part of the electric propulsion system.

Acknowledgments

This work was supported by a grant of the Romanian Ministry of Research and Innovation, CCCDI - UEFISCDI, project number PN-III-P1-1.2-PCCDI-2017-0776/No. 36 PCCDI /15.03.2018, within PNCDI III.