A Framework for Communicating and Building a Digital Twin Model of the Electric Car

Abstract

The Fourth Industrial Revolution has had a huge impact on manufacturing processes and products. With rapidly growing technology, new solutions are being implemented in the field of digital representations of a physical product. This approach can provide benefits in terms of cost and testing time savings. In order to test and reflect the operation of an electric car, a digital twin model was designed. The paper collects all the information and standards necessary to transform the idea into a real and virtual model of an electric car. The significance and impact of the study on the improvement of the project are described. The research stand, correlations of components (DC and AC motors, shaft, and wheel of the electric car), and development prospects are presented in the paper. The communication method with the research stand is also presented. The digital twin should communicate in real time, which means obtaining the correct output when the input changes; the input is the AC motor current, and the output is the rotational speed of the DC motor. The relation between inputs and outputs are tested. The kinematics of the electric car are modelled in LabVIEW. The results obtained are compared with historic racing data. The track is also modeled based on satellite data, taking into account changes in terrain height, using the SG Telemetry Viewer application. The parameters of the electric car engine model are tuned based on actual data on the car’s speed and current in the electric motor. The achieved results are presented and then discussed.

1. Introduction

The automotive industry has changed significantly in the era of Industry 4.0. Many new technologies have been implemented into production processes and products [1,2]. At the same time, electric vehicles (EV) are becoming more and more popular due to the reduction in fossil fuel combustion and greenhouse gas emissions [3]. Additionally, artificial intelligence (AI) is having some impact on the automotive industry, for example in autonomous vehicles [4]. As a result, the car becomes more and more complex. It may be almost impossible to stop this trend until new regulations are developed.

Various environmental conditions affect the operation of the EV drive with more or less random damage to the engine with charged batteries. The objectives of minimizing electrical energy or maximizing crew safety are set. Problems can be solved using simulators, such as computer simulations (digital twins) where new conditions and EV configuration are implemented. The high fidelity and flexibility of simulators or computer simulations provide opportunities to reflect the unusual conditions and states of the EV. Maneuvers are practiced on developed simulators, computer simulations are carried out, and then new procedures can be passed on to drivers.

The term digital twin (DT) is used in connection with Industry 4.0. [5]. It is worth mentioning the development of DT over the years and looking forward to the future [6]. This trend can be found not only in the automotive industry [7], but also in the railway [8] and aviation [9] industries; the digital twin originated in the latter and is related to the Apollo 13 mission [10,11]. Starting from 1959, the National Aeronautics and Space Administration (NASA) required hundreds of hours of simulator training. NASA produced high-fidelity simulators with a large number of computers and many formulas. In the case of the Apollo Program, astronauts trained on 15 simulators for every aspect of the mission. The simulators provided an accurate approximation of a space flight, so various failure scenarios could be practiced.

The term DT was first used by NASA [12]. It appeared in the draft of a roadmap. Previously, a similar concept was introduced by Dr. Grieves in 2002 and was called the “Conceptual Ideal for PLM” [13]. However, it was NASA that provided the definition of DT as well as the application goals. For NASA these were as follows:

• Testing the vehicle before launch with various parameters.
• Real flight reflection, comparisons, and updates.
• Diagnostic tool for finding the causes of faults or damage.
• Investigation of new modifications not planned at the design stage.

The term digital twin first appeared in 2010, but events on Apollo 13 indicate that this was a digital twin in action. Modifications tested on simulators had a similar impact on the performance of the spacecraft. Without these options, it was much more difficult for the crew to learn how to operate the damaged ship. The main task of the DT was accomplished, namely contributing new data and knowledge. Results were obtained quickly enough to be transmitted in time if the spacecraft was at risk. The example shows that the digital twin approach resulted in positive feedback even in very demanding and stressful circumstances. Over the years, the number of publications containing the term “Digital Twin” has increased significantly. As mentioned in [14], 29 relevant papers were published in 2016, while in 2021 there were already 2997 of them. Similar results apply to DTs in the automotive industry [15].

To systemize information about digital twins, a maturity model is described. The method evaluates DT in 7 categories with 31 features, as in

Table 1. Maturity model of a digital twin.

Category	Dimensions	Comment
Context [17,18]	Reference object	What does a DT represent? A product, a manufacturing asset, a production line, a process, a factory, or a human. These objects are at different levels of abstraction.
	Tangible product life cycle phases	The phase of the product life cycle at which a DT is applied: beginning, middle or end of life.
	Application domain	A sector for implementing a DT, e.g., manufacturing, aerospace, healthcare, automotive, maritime.
	Benefits	Improving existing services, adding new value, or establishing a new service.
Computing capabilities [19,20]	Trigger types (simulation capabilities)	A simulation starts on a specific event and runs continuously or once at a specific time.
	Model look-ahead perspective	Time horizon for using a DT: single specific operation or the entire period of product cooperation.
	Computing capabilities	Overall response time from a DT, processing speed. Time required from DT to be updated.
	Update frequency—input	How often a piece of new data appears: in real time or less frequently.
	Update frequency—output	Outputs from DT are immediate, real-time, or periodic due to the strategy implemented.
Model [21,22]	Creation time	A DT was designed in parallel with the product’s design or later in the product life cycle.
	Modelled characteristics	Which object behavior is modelled: geometric, kinematic, sensor, control, or system characteristics.
	Digital model types	Referring to the types of simulation models, the following are distinguished: Deterministic and stochastic models. Static and dynamic models. Discrete and continuous models.
	Model authenticity	How reliable is the digital twin representation compared to the actual product?
	Model maintenance	DT’s ability to ensure system validation and accuracy in new circumstances. Some cases require manual adaptation, while others are autonomous.
	Modularity	How the architecture of the DT system is designed and whether it integrates more modules. Unit—low complexity DT system architecture. System—several units cooperating within a modular system architecture. System of systems—a set of interconnected systems, services and modules.
Data [23,24]	Data storage	The location where data are stored depends on the size, type, and method of obtaining it: local disk, local server, cloud.
	Data scope	The scale of data acquisition. Data from a single object, external data from many resources or big data.
	Data quality	Matching system requirements. The attributes of data quality are accuracy, completeness, consistency, and uniqueness.
	Data sources	DT uses data from physical sensors and measurements but also from simulation and analysis.
	Data interpretation	DT’s capabilities to use incoming data. If a DT operates on irregular and unsorted data.
Control [25,26]	Level of cognition	DT is only for monitoring and diagnostic purposes or gives predictive forecasts based on a simulation.
	Levels of autonomy	How DT processes decisions: with user support or fully independently, autonomous.
	Learning capabilities	Determines whether a machine learning algorithm exists; supervised, semi-supervised, unsupervised, and reinforced.
Human–machine interaction (HMI) [27,28]	Types of interaction devices	Method of interacting with DT, starting with keyboard, mouse, display, and touchscreen. It may also include remote control via mobile phones or even cameras for the adaptive assistance system.
	Human interaction capabilities	In case of new challenges, DT adapts itself or the output responses are predefined.
Integration [29,30]	Digital twin interaction	Specifies whether there is only one DT or multiple DTs and describes how they collaborate.
	Hierarchy	This dimension provides information about the rank of collaborating DTs.
	Connection mode	The connection between a DT and a physical object. Digital model—there is no automated data exchange form, and it is carried out manually. Digital shadow—automated data flow from the physical object to the DT. Digital twin—automatic data exchange in both directions.
	User focus	DT can be useful for an individual user, a department, a company, or several organizations.
	Collaboration	There are DTs established for different organizations, there is data exchange between them, and they can have similar purposes or work independently.

. It helps one to assess the current stage of an application’s development and to find ways to further improve it [16].

The complexity of Industry 4.0 affects the automotive industry, especially in the simulation aspect [31]. There are many methods for simulating automotive systems, such as the following [32]:

• Model-in-the-loop (MiL)—a computer-simulated model in an environment, such as Simulink; used for capturing the most important features of the plant (hardware), identifying errors in mathematical equations, and understanding the behavior of a model under specific conditions and finding areas for improvement.
• Software-in-the-loop (SiL)—a computer-simulated model and controller model; software simulator instead of real hardware; an essential tool for identifying defects and problems; the software provides input data that is fed into the model. The model then process the input and produces output that is captured and analyzed. Outputs are compared to the expected results to determine whether the model is working correctly.
• Processor-in-the-loop (PiL) or FPGA-in-the-loop (FiL)—controller code runs on the built-in processor, testing the processor in the developed control logic and finding faults.
• Hardware-in-the-loop (HiL)—uses actual physical connections to the embedded processor, such as inputs and outputs and actuators or a communication interface; used for verifying if the controller works stably and how it responds in real time to changing signals.
• Vehicle-in-the-loop (ViL)—last step before full road testing; complete vehicle system; used for testing real-world scenarios with a virtual environment.

Differences between the simulation methods are presented in

Table 2. Characteristics of different simulation methods.

	Method	MiL	SiL	PiL/FiL	HiL	ViL	Test Drive
Aspect
Software simulated model		✓	✓	✓	✓
Control simulator			✓
Embedded processor				✓	✓	✓	✓
I/O, communication					✓	✓	✓
Real conditions							✓

. Depending on current characteristics, progress, and requirements of the project, some of these methods can be used. Each method has a specific approach and provides unique feedback. The MiL method is virtual while ViL is real and provides the best accuracy but is also expensive. ViL simulation should be used for complex systems, such as the advanced driver assistance system (ADAS), which is crucial to safety. In the case of less complicated car systems, such as wipers or smart keys, more virtual methods are used, such as MiL, SiL, or HiL [33,34].

Examples of digital twins for electric cars are presented in

Table 3. Digital twin examples in an EV world.

Topic	Description
Battery digital twin [35]	Based on available measurements from the LIB module, a DT framework was proposed in which various algorithms estimate the battery charge state. The digital twin of the battery is compared to the real-world module.
Health monitoring and prognosis of electric vehicle motor [36]	Data, such as speed, time, housing, and winding temperature, are collected to train an artificial neural network (ANN). The electric motor is modelled in Simulink and connected to the ANN. The engine health can be monitored with real engine data stored in the cloud.
eGolf battery digital twin [37]	Data from the car is sent to the cloud via the 4G mobile network. The DT of the battery estimates the state of charge and health condition. Battery status can be diagnosed by the end-user while driving.
Car twin [38]	Automotive systems, such as the anti-lock braking system, immobilization control module, power control module, power steering control module, and others, are modelled in Simulink. Input signals are collected from the car via the controller area network, comparing car simulation results with real-world data collect while driving a car.

. The solutions offer rapid testing and prototyping, reducing time and costs. Data from DT support decision-making. The capabilities of DT technology are advanced and are continuing to develop. On the other hand, the fidelity of the virtual model is crucial. Integrating data from multiple sources can be complex, and reflecting real-world scenarios can be challenging. Running simulations in real time may require significant computing power. The DT approach is not standardized.

In addition to the dimension of the Fourth Industrial Revolution, i.e., integration, communication, and interaction standards, there is an advanced combination of virtual and real tools and tests that improve the efficiency of electric cars. A study [39] shows that the well-to-wheel (WTW) efficiency of diesel ICEV ranges from 25–37%. However, in the case of an EV powered by renewable energy, the overall efficiency ranges from 40–70%. An overview of areas where the energy efficiency of EVs can be improved is discussed in [40]. Tests include various methods, such as the following:

• Regenerative braking—a simulation test proved that the regenerative braking logic saved approximately 30% of energy consumption compared to a vehicle without recuperation [41].
• Battery efficiency—different speed profiles were tested on a chassis dynamometer with VW e-Up. The question concerned the impact of speed on energy consumption and battery performance [42].
• Energy management system—data from vehicles were sent to the cloud via 4G LTE network. Real-time vehicle performance was consistent with the cloud computing status. Based on these calculations, an ID-VIL simulation was performed to evaluate possible decisions to minimize costs and battery life loss [43].
• Hybrid energy storage system—modelling and simulation of the battery–supercapacitors system for the e-Golf. Studies have shown that the system can reduce energy consumption by 2.95% per 100 km [44].

Other aspects of Industry 4.0 are big data processing and cloud computing. Models for integrating sensor data with CPS, with the need to periodically query the controlled sensor network and process the received data in real time, are elaborated. Car data can be extracted using on-board diagnostic parameter IDs (OBD-II PIDs). Data are sent to the cloud to feed the digital twins. The authors in [37] point to the limited data quality and maximum sampling frequency of 9 Hz. However, the authors of [38] point out the lack of security requirements in CAN standards. Processing data and sharing results in real time is a challenge for DT implementation.

Analyses based on historical data must be synchronized with the electric car’s operating conditions in real time to enhance the capabilities of the physical and virtual worlds. The list of supported parameters is defined by a vehicle manufacturer. For EVs, additional services may be available to measure voltage, current, state of charge, and maximum battery temperature. The performance of EVs is tested in various conditions. In [45], the EV performance is tested in Bogotá at an altitude of 2600 m above the sea level, and in [46] the effect of different ambient temperatures on driving behavior is investigated.

Goals and Approaches

The regular approach to collecting data starts with a race or a training ring. It is then possible to observe the operation of the vehicle, but this is no longer effective in terms of cost, time, and effort, especially in a constantly changing motor sport with new car regulations or a new competition venue. Currently, the DT approach can address all these drawbacks [47], while EVs can be tested indoors. In this paper, the main task for the digital twin is to simulate racing conditions.

The aim of the paper is to find a solution to test the efficiency of an electric car. A new solution is needed to reduce the time it takes to test strategies or to improve the car before competing. The electric car from the research project has been participating in competitions for many years. The current state of research led to the creation of a research station where some of the work is carried out [48,49]. To bridge the gap between theory and practice, integration and communication standards are presented, as well as virtual and real tools and tests to improve the performance of the electric car. This approach is closest to [43] because the DT uses X-in-the-loop simulations. At the same time, they are at different levels of DT maturity. It all depends on the application requirements. An overview of the proposed system is presented in Figure 1.

The rest of the paper is organized as follows: Section 2 provides an overview of the research stand, inverter communication, and strategies for simulating racing conditions. Section 3 contains the data collected during testing. Section 4 summarizes the obtained results. Finally, Section 5 presents conclusions and aims the future work.

2. Digital Twin Components and Communication

The research schedule is divided into parts. Firstly, the research station is presented. In the research station, some components are dedicated to VIL simulation, and others are digital twin components. Secondly, the connection mode between the elements is presented and communication is tested. Finally, the simulation program is implemented to compare the results obtained for the virtual car on the research station with the racing car on the racing track.

In the research case, an inertial dynamometer is used to build the digital twin of the electric car. The research stand consists of the following:

• PC and router;
• SEW Eurodrive MDX61B drive inverter with a DFE11B extension card;
• Three-phase SEW DRE80M4 AC motor with ES7S incremental encoder;
• DC motor;
• Shaft with the mass wheel and the built-in torque sensor;
• Car wheel;
• Drive system (belts).

The research station replicates the electric car as closely as possible. The clutch connecting the engine to the wheel is the same as in the electric car. When the DC motor is running, the car’s wheel shaft rotates, like a shaft. That situation describes the car driving on a flat track in a straight line. In order to change the load, the AC motor is used, which is also coupled to the shaft, but from the other side. Changing the torque on the shaft using the AC motor makes it possible to generate conditions similar to those on a real track i.e., turns, weather conditions, or hills. The motor torque is controlled by the drive inverter. All speeds on the research stand are known thanks to the encoder mounted on the AC motor and calculations of the ratio between the parts. The built-in torque sensor is an NCTE2200-75 [50]. The torque sensor range is 75 NM, with an accuracy of less than 1%. This does not apply to the research stand when the rated torque of the DC motor is 1.15 Nm [51]. This is the limitation of the case study.

In the research stand, the elements, such as the DC motor, battery, car wheel, and drive systems, constitute the vehicle system, the same as that installed in the racing car. This is the actual installation (hardware). The other group, consisting of the PC, router, inverter, and AC motor, is used to reflect real conditions. The ViL simulation, i.e., a physical system in the virtual state, can be performed on the research stand.

Building a virtual environment starts with parametrizing the drive inverter. They can be changed in the program MOVITOOLS MotionStudio provided by SEW. The modified parameters [52] are presented in

Table 4. The list of modified parameters.

Parameter	Name	Value
P100	Setpoint source	Fieldbus
P101	Control signal source
P700	Operating mode 1	CFC and torque control
P870	Setpoint description PO1	Control word 1
P871	Setpoint description PO2	Current
P872	Setpoint description PO3	No function
P873	Actual value description PI1	Status word 1
P874	Actual value description PI2	Speed
P875	Actual value description PI3	Output current
P876	PO data enable	ON

.

Parameters P100 and P101 have the fieldbus value. The drive inverter expects the control word and setpoints to come from this communication interface. Other options for setpoint source are SBus (system bus) and RS485. The drive inverter can also be controlled with binary inputs. For the application’s purposes, the fieldbus was chosen, which is a powerful and universal interface. The fieldbus is a group of protocols used in industry. Commonly used fieldbus variants include the AS-I Interface, Profibus, Profinet, EtherCAT, Modbus, ControlNet, etc. They work in an industrial network and have an advantage over the serial communication commonly used so far. For example, RS-232 only allows two devices to be connected for communication, whereas, thanks to the fieldbus, many devices from different manufacturers can operate simultaneously on one control platform. Thanks to this solution, the amount of cabling is reduced, costs are lower, and communication is faster and more reliable.

Different protocols require specific option cards; for example, the DFP21B is needed for Profibus, the DFE32B is needed for Profinet, and the DFE24B is needed for EtherCAT. The DFE11B expansion card allows one to connect the Ethernet fieldbus, namely Modbus/TCP. The drive inverter is connected to the router via an Ethernet cable [53,54]. Both the inverter and the PC operate on the same network. Each of them has a unique IP address. Swapping input and output words is possible using parameter P876.

For the operating mode, parameter P700 is set to CFC (current flux control), where the motor current is controlled [55]. Due to the choice of this control technique, control must also be current-based (P871). The control value also appears as a setpoint value. Then, the output torque on the motor shaft can be calculated from the following formula:

$$\mathrm{M}={\mathrm{c}}_{\mathrm{T}}\cdot {\mathrm{I}}_{\mathrm{N}\mathrm{i}\mathrm{n}\mathrm{v}\mathrm{e}\mathrm{r}\mathrm{t}\mathrm{e}\mathrm{r}}\cdot \mathrm{s}\mathrm{e}\mathrm{t}\mathrm{p}\mathrm{o}\mathrm{i}\mathrm{n}\mathrm{t},$$

(1)

$$\begin{array}{cc}& c_T-\mathrm{T}\mathrm{o}\mathrm{r}\mathrm{q}\mathrm{u}\mathrm{e} \mathrm{c}\mathrm{o}\mathrm{n}\mathrm{s}\mathrm{t}\mathrm{a}\mathrm{n}\mathrm{t}=M_n/I_{q_n}=5 \mathrm{N}\mathrm{m}/2.37\mathrm{A},\hfill \\ & I_{N\_inverter}-\mathrm{N}\mathrm{o}\mathrm{m}\mathrm{i}\mathrm{n}\mathrm{a}\mathrm{l} \mathrm{o}\mathrm{u}\mathrm{t}\mathrm{p}\mathrm{u}\mathrm{t} \mathrm{c}\mathrm{u}\mathrm{r}\mathrm{r}\mathrm{e}\mathrm{n}\mathrm{t} \mathrm{o}\mathrm{f} \mathrm{t}\mathrm{h}\mathrm{e} \mathrm{i}\mathrm{n}\mathrm{v}\mathrm{e}\mathrm{r}\mathrm{t}\mathrm{e}\mathrm{r}=2.4 \mathrm{A},\hfill \\ & setpoint-\mathrm{\%}{I}_{N_{inverter}}\hfill \end{array}$$

A control word (P870) is required to control the AC motor. The control word can be viewed as a software security feature. When the word has a valid value, the inverter interprets it as being ready for operation. The description of a single bit of the control word is presented in

Table 5. The control word description.

Bit	Functionality	Assignment
0	Fixed definition	Controller inhibit “1”/Enable “0”
1		Enable “1”/Rapid stop “0”
2		Enable “1”/Stop “0”
3		Hold control
4		Integrator switchover
5		Parameter set switch-over
6		Reset
7		Reserved
8	Direction of rotation for motor potentiometer	0 = CW direction of rotation 1 = CCW direction of rotation
9 10	Motor potentiometer acceleration Motor potentiometer deceleration	10 9 0 0 = no change 0 1 = up 1 0 = down 1 1 = no change
11 12	Selection of the internal fixed setpoints n11–n13 or n21–n23	12 11 0 0 = Speed setpoint via process output data word 2 0 1 = Internal setpoint n11 n(21) 1 0 = Internal setpoint n12 n(22) 1 1 = Internal setpoint n13 n(23)
13	Fixed setpoint switchover	0 = Fixed setpoint of the active parameter set selected by bit 11/12 1 = Fixed setpoint of another set of parameters selected by bit 11/12
14 15	Reserved	Set reserved bits to 0

.

The remaining parameters are the status word (P873), actual speed (P874), and actual output current (P875). The status word contains information about the inverter if the output stage is enabled or an error has occurred. The actual speed is read from the encoder. The gear ratio on the research stand is known, so that the actual speed of the DC motor and wheel can be calculated.

To implement a digital twin for the presented model, the following requirements should be met:

• Establish communication.
• Build a simulation program.

2.1. Establishing Communication

Communication is based on the Modbus TCP/IP protocol. The protocol is used for industrial purposes, such as SCADA systems [56,57]. The Modbus is a type of client–server architecture [58]. The PC is the client device that initiates communication and sends requests. The inverter is a server device that processes received requests and sends responses. Data are exchanged between them via a Modbus TCP/IP frame (

Table 6. Modbus TCP frame format. The entire frame is called an ADU (application data unit).

Byte	Name	Notes
0–1	Transaction ID	MBAP—Modbus Application header
2–3	Protocol ID
4–5	Length field
6	Client ID
7	Function code	PDU—protocol data unit
8–n 1	Data

¹ A maximum of ten words can be exchanged at a time.

). Thanks to the frame, the necessary functionality is ensured, and the parameters go directly to the appropriate registers in the inverter.

The following FC operations (function codes) are available for the inverter device:

• FC3—read holding registers.
• FC16—write multiple registers.
• FC23—read/write multiple registers.

Using these functions, the AC motor can be started or stopped with the correct control word sent by the PC, or the actual values of the AC motor, such as speed, position, and current, can be read. Next,

Table 7. Register mapping.

Offset	Meaning for Read Operation	Meaning for Write Operation	Remarks
0hex–3hex	Reserved	Reserved	No access
4hex–Dhex	Process input data (actual values)	Process output data (setpoints)	Max. 10 words for MDX61B Access via FC3, FC16, FC23

presents the Modbus register mapping. This is how data are saved when exchanging process data words. The first available offset starts at reference number 4.

The library supporting communication in LabVIEW software is Modbus Master from Plasmionique Inc. (Varennes, QC, Canada) [59]. LabVIEW uses the graphical environment presented in Figure 2a for programming. The code is similar to an electric diagram. More complex functions are presented in the form of blocks that organize and simplify the program structure.

LabVIEW is a software that contains all the tools needed to perform simulations [60,61]. At the same time, the software is user-friendly and ensures quick implementation. The user interface consists of two windows: a block diagram and a front panel [62].

Figure 2b presents example Modbus frames. Frames are coded in the hexadecimal system. The last frame TX means transmitted data and RX means received data. The meanings of double words in the frame are as follows:

• 16AA_hex—transaction identifier, value assigned by the client;
• 0000—protocol identifier must be zero;
• 000B_hex = 11_dec—number of consecutive double words;
• FF_hex—the server identifier means that the DFE11B is the end station;
• 10_hex = 16_dec—function code, FC16 is the operation record;
• 0004—address of the first register;
• 0002—number of required registers;
• 04—number of double words remaining;
• 0006hex = 0110bin—setting the value of control word 1, bit 1, and bit 2 to 1 causes the inverter to enter the read-ready state;
• 0032_hex = 50_dec—current controlled value, set value.

All data included in the manufacturers’ instructions and collected in Table 4, Table 5, Table 6 and Table 7 are implemented in LabView. They are essential to avoid problems and errors during startup. The communication between the inverter and the PC via the Modbus protocol has been completed.

2.2. Building a Simulation Algorithm

After establishing communication, the impact of the control value on the wheel rotational speed is examined. For this purpose, different values of the current setpoint are tested (Figure 3a). At higher setpoint, the rotational speed decreases, while the negative setpoints accelerate the DC motor. The rotational speed vibrates, as shown in Figure 3b. The reason for this is that the drive inverter adjusts the AC motor current to achieve the set torque. At the same time, the rotational speed of the AC motor also changes. Moreover, the speed value stabilizes with a delay resulting from the existing moment of inertia. For setpoint 20, the final rotational speed is approximately 1760 rpm and is reached after 50 s.

Based on historical data collected during races using telemetry sensors installed in cars [63], the Dunsfold racetrack is divided into segments. A view of the Dunsfold track is presented in Figure 4. The required range of rotational speed can be activated. According to historical data, the DC motor rotates at a speed from 1670 to 1815 rpm. The third column of

Table 8. Six track segments of appropriate length.

Segment No.	Length [m]	Setpoint Value
1	445	45
2	165	10
3	308	−25
4	83	10
5	181	20
6	191	30

contains setpoint proposals that are overestimated, referring to the results from Figure 3a. In addition to the DC rotational speed, lap time, race time, lap number, and DC motor current are collected at 1-second intervals during races.

The LabVIEW algorithm also calculates actual track position, lap and race times, lap number, rotational speed of the DC motor, and virtual car speed. The program runs in a loop and the simulation values are updated and saved every second. The time interval for collecting data from the racing car and the virtual simulation car is equal and can be compared. The principle of operation of the program is based on the calculated position of the virtual car. Each time the virtual car travels a distance from one segment to another, a specific setpoint value from the AC motor is applied. Once the virtual car has completed the entire lap distance, the lap time is set to zero and a new lap is started. The procedure is then repeated in a loop. The simulation data are stored in a text file. All simulation parameters can be updated online from the front panel, without changes in the flowchart.

3. Results

Two experiments were carried out:

• First lap simulation—no additional torque from the AC motor.
• Further lap simulation with specified setpoints.

3.1. Simulation of Lap 1

The first lap is the most specific. The electric car starts from zero speed and accelerates for most of the lap time. In this case, no additional load is added to the engine. It represents a straight track when in fact it is not. The difference between the first lap times is 12 s (Figure 5). The difference is due to the reduced speed halfway through the lap, probably due to a braking maneuver. The start on the real track is faster. The final rotational speed of the DC motors is similar in both graphs. This should be a good predictor for validating the ViL simulation, provided that both final velocities are consistent.

3.2. Simulation of Lap 5

Starting from the second lap, the simulation program uses the setpoint values to reflect the car kinematics on the racetrack. Lap number 5 is selected from the historical data to compare the lap time and rotational speed with the simulation results. For a regular lap, the difference in lap time is 4 s (Figure 6a). At some point in the simulation, the rotational speed is lower than the racing speed. In the second half of the simulation, the rotational speed is higher than expected. The suggested setting values may not be optimal. The dependence of the control quantity on the rotational speed is presented in Figure 6b.

4. Discussion

The solution integrates physical components with the virtual environment via the Modbus protocol. Data exchange at the research station is bidirectional. The integration provides a new service reflecting the kinematics from the historic race. As a result, car performance can be simulated indoors. The research stand offers great opportunities to create a digital twin of an electric car. With the research stand, the VIL simulator, the operation of batteries and DC motors can be subjected to simulated real conditions. The results obtained during the simulation even exceed the normal performance of the electric car. Research simulations were performed for one racetrack, but simulation of others is also possible. The program provides all options for this case.

As expected, the simulation results differ from historical racing data. There are several reasons for this discrepancy, as follows:

• Random events and incidents occurring during real races are not taken into account.
• Varying the load on the AC motor does not provide a constant output value.
• The overall condition of the battery and DC motor may affect the final results.
• No additional load is added on the first lap.
• Because the setpoints cause subsequent laps to take too long, the motor speed increases and there is no time to reduce it. To obtain more appropriate time laps, the track should be divided into more segments, even if the speed does not change much during the time lap.

Analysis of the information collected in Table 1 clearly classified the implemented solution as a digital model. There is no automated form of data exchange between the racing car and digital object. The SWOT analysis, taking into account the strengths, weaknesses, opportunities, and threats of the presented hybrid solution, is presented in

Table 9. The SWOT analysis of the system.

	Description
Strengths	Data-driven model uses real-world data Research station consists of the same parts as the racing car Various scenarios can be simulated
Weakness	Depends on data quality Lack of physical understanding of the data Manual method for implementing input data
Opportunities	The entire system can be expanded Indoor testing reduces time and costs
Threats	Complexity of data integration Requires appropriate validation

.

To overcome weaknesses and threats, the digital twin concept involves building models of the car on various tracks, e.g., a track known from the Top Gear program, Dunsfold. Building the DT involves the following activities:

• Analysis of telemetry data in order to select tested journeys.
• Creating a CAD model of the car (Figure 7a). Based on the physical parameters, the car is mapped in terms of structure, arrangement of elements in the vehicle, determination of the masses of individual components, determination of technical parameters of the drive, adjustment of chassis parameters, and determination of aerodynamic resistance based on analyses of air flow through the car body (Figure 7b) [64,65]. The body model is omitted and replaced by the impact of aerodynamic drag forces [66]. The model is tuned by modifying the parameters of the car engine (Figure 7c) and adjusting them in such a way that the engine current and the car speed match the data of the telemetry application (Figure 7d).

• Building a CAD model of the track on which the car run. The track is modeled based on satellite data, taking into account changes in terrain height. The first step is to make a sketch of the track contour based on satellite photos from a top view, as in Figure 4. Points are added at altitudes corresponding to the altitude [m.a.s.l.] of the corresponding track points based on Google Earth satellite data. In order for the car to move along the desired track, the points of contact between the vehicle and the ground must be determined. For this purpose, the 3D Contact function is used. Four contacts are assigned (each corresponding to each of the vehicle’s wheels) with the same physical values.
• Creating a simulation in the Siemens NX Motion Simulation module, taking into account the forces acting on the car in the real environment. Atmospheric conditions were modeled. According to the diagram from the Weather Underground website, the wind blows from west to east at a speed of 2 [mph], which after conversion gives a value of 0.89408 [m/s] (Figure 8).

• Reflection of the car’s passage in a virtual environment based on data from the telemetry application. Data obtained from the telemetry system allow for plotting the actual trajectory of the car (Figure 9a). After running a simulation that mirrored part of the Dunsfold track, the car goes around the corner on the same trajectory as the real car in the race. Once this result is achieved, the model is considered tuned and ready for testing (Figure 9b)

• Optimization of the car’s driving path in the selected corner. The next stage is to route the digital twin along a new route. The goal is to obtain higher travel speeds at a simi-lar current level, i.e., approximately 20A. The test run and the comparison of the movement trajectories are presented in Figure 10. The green line shows the theoretical trajectory, while the blue line reflects the trajectory obtained from the GPS position of the telemetry module.

After analysis of the track, differences were noticed between the driving resulting from the vehicle’s trajectory and the theoretically determined track optimized due to the criterion of minimizing the centrifugal force. For the Chicago Corner curve, the length of the track resulting from telemetry was 76,000 mm, and the track after optimization was 82,000 mm.

The speed of the car while turning at Chicago Corner was also compared. The entry speed was 55 km/h for measurements from the telemetry module and the twin at Chicago Corner. The speed at the exit of the corner was 54 km/h in the case of the telemetry and 57.8 km/h in the case of the twin.

The average current was 27A when driving through Chicago Corner in the case of measurements from the telemetry module. The average current was 23A in the case of the twin moving along the optimized trajectory.

After carrying out the simulation process, it was shown that it is possible to negotiate the bend more economically and at a higher speed. The electric car moving along the designated trajectory showed a greater increase in speed after passing the turn. This translates directly into lower energy losses when traversing the analyzed track. Optimization is necessary to negotiate the same turn on different driving lines, one real and the other theoretically determined, and with the same drive parameters and after taking into account the forces acting on the car. To understand best practices for turning more economically and at higher speeds, it is important to analyze the relationship between historical and real-time data about the car and the environment.

5. Conclusions and Future Work

The paper presents the DT concept of the electric car with ViL simulation for more economical turning and at higher speeds. Connecting the ViL simulation with the digital model is a novel approach. The research station uses physical parts, while the kinematics of the vehicle is modelled with the software. Using physical parts instead of modeled components is beneficial because it increases the model accuracy. The actual status of the application development allows for static and deterministic simulation in which past electric car races can be carried out. Components of the research station are the same as used in the case of the EV. Kinematics of the vehicle in a specific time period are modelled using historical data.

Further research requires validation. It means more measurements and further data integration. To obtain better results, the research stand includes the telemetry system installed in the electric car. With the current data on the DC motor, the proposed control values may differ. To improve the final simulation performance, a torque sensor with a smaller range should be installed. Then, the measured torque value can be compared with the calculated one. More data are better for comparison results with the DC motor data sheet and historic and actual telemetry data. Using only the AC motor encoder for measuring the rotational speed is not sufficient to verify the correctness of the solution.

To complete the model, validation of kinematics is required to measure the DC motor current on the research station. The impact of set values on the DC current is possible to test. Finally, both the rotational speed and the current values of the DC motor need to be compared with the historic data collected by the telemetry system during the race. The simulation results should obtain similar values for the time lap, rotational speed and current of the DC motor. The main challenge for the validation process will be to compare the simulation results between different racing tracks and find out whether there is a common pattern for this process. The biggest limitation of the validation is the quality and the quantity of historical data about a specific event and car. The digital twin approximates various events, but never reflects real-world scenarios one-to-one.

Future steps include a machine learning algorithm for computing setpoint values of the AC motor for different previous races. After validation, optimization of battery use or DC motor operation in changing weather conditions will be tested. A very important step is to automate the flow of data from the EV to the research station in order to build a digital shadow. It will simplify the commissioning procedure on the research stand. A later step is to automate the flow of data from the research station to the race car. Such a system as DT will guarantee two-way data exchange in real time during a racing event. Additional cloud computing and optimization results from the research station will impact the physical object. It is the most complex and demanding concept, while offering the best results.

Converting the digital model into a digital twin will require a more advanced system in both the race car and the research station. Data from the race car must be send to cloud via 4G/5G network. The biggest challenge now is delivering results on time. The results generated should have an impact on the racing event. The system integration further will complicate the application. Building a scalable solution for different vehicles moving in parallel will need more digital twin platforms. In relation to the automotive industry, it is also important to find a safe way to obtain data without leaking them. Of course, future work must not affect the safety of the end user.

The digital twin model presented in the article was verified for light electric cars driving in energy shortage conditions. These conditions have been precisely formulated by the Greenpower Education Trust. The Greenpower Education Trust is a UK based charity with an outstanding track record in kickstarting careers in engineering. We help unlock potential and spark enthusiasm for science, technology, engineering, and math (STEM) through the excitement of motorsport. We believe that the created digital twin model can be applied to larger electric vehicles after scaling the model and modernizing the distribution of the car’s masses.