Next Article in Journal
Semantic Segmentation of 3D Point Clouds in Outdoor Environments Based on Local Dual-Enhancement
Next Article in Special Issue
GNSS and LiDAR Integrated Navigation Method in Orchards with Intermittent GNSS Dropout
Previous Article in Journal
Photocatalytic Oxidization Based on TiO2/Au Nanocomposite Film for the Pretreatment of Total Phosphorus (TP)
Previous Article in Special Issue
STEAM: Spatial Trajectory Enhanced Attention Mechanism for Abnormal UAV Trajectory Detection
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:

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

Department of Engineering Processes Automation and Integrated Manufacturing Systems, Silesian University of Technology, Konarskiego 18A, 44-100 Gliwice, Poland
Author to whom correspondence should be addressed.
Appl. Sci. 2024, 14(5), 1776;
Submission received: 25 January 2024 / Revised: 15 February 2024 / Accepted: 16 February 2024 / Published: 22 February 2024


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. 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. 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. 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.
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:
M = c T I N i n v e r t e r s e t p o i n t ,
c T T o r q u e   c o n s t a n t = M n / I q n = 5   N m / 2.37 A , I N _ i n v e r t e r N o m i n a l   o u t p u t   c u r r e n t   o f   t h e   i n v e r t e r = 2.4   A , s e t p o i n t % I N i n v e r t e r
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 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). 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 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:
  • 16AAhex—transaction identifier, value assigned by the client;
  • 0000—protocol identifier must be zero;
  • 000Bhex = 11dec—number of consecutive double words;
  • FFhex—the server identifier means that the DFE11B is the end station;
  • 10hex = 16dec—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;
  • 0032hex = 50dec—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 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.
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.

Author Contributions

Conceptualization, A.B., I.P. and T.B.; methodology, A.B. and T.B.; software, A.B. and T.B.; validation, A.B., I.P. and T.B.; formal analysis, A.B. and T.B.; investigation, A.B. and T.B.; resources, A.B. and T.B.; data curation, A.B., I.P. and T.B.; writing—original draft preparation, T.B.; writing—review and editing, I.P.; visualization, A.B. and T.B.; supervision, A.B. and I.P.; project administration, A.B.; funding acquisition, I.P. All authors have read and agreed to the published version of the manuscript.


This research received no external funding.

Institutional Review Board Statement

Not applicable.

Informed Consent Statement

Not applicable.

Data Availability Statement

The raw data supporting the conclusions of this article will be made available by the authors on request.

Conflicts of Interest

The authors declare no conflict of interest.


  1. Achouch, M.; Dimitrova, M.; Ziane, K.; Sattarpanah Karganroudi, S.; Dhouib, R.; Ibrahim, H.; Adda, M. On Predictive Maintenance in Industry 4.0: Overview, Models, and Challenges. Appl. Sci. 2022, 12, 8081. [Google Scholar] [CrossRef]
  2. Teplická, K.; Khouri, S.; Mudarri, T.; Freňáková, M. Improving the Quality of Automotive Components through the Effective Management of Complaints in Industry 4.0. Appl. Sci. 2023, 13, 8402. [Google Scholar] [CrossRef]
  3. Sanguesa, J.A.; Torres-Sanz, V.; Garrido, P.; Martinez, F.J.; Marquez-Barja, J.M. A Review on Electric Vehicles: Technologies and Challenges. Smart Cities 2021, 4, 372–404. [Google Scholar] [CrossRef]
  4. Khanum, A.; Lee, C.-Y.; Yang, C.-S. Deep-Learning-Based Network for Lane Following in Autonomous Vehicles. Electronics 2022, 11, 3084. [Google Scholar] [CrossRef]
  5. Barton, M.; Budjac, R.; Tanuska, P.; Gaspar, G.; Schreiber, P. Identification Overview of Industry 4.0 Essential Attributes and Resource-Limited Embedded Artificial-Intelligence-of-Things Devices for Small and Medium-Sized Enterprises. Appl. Sci. 2022, 12, 5672. [Google Scholar] [CrossRef]
  6. Digital Twin Industry Worth $110.1 Billion by 2028. Available online: (accessed on 11 August 2023).
  7. Ali, W.A.; Fanti, M.P.; Roccotelli, M.; Ranieri, L. A Review of Digital Twin Technology for Electric and Autonomous Vehicles. Appl. Sci. 2023, 13, 5871. [Google Scholar] [CrossRef]
  8. Kampczyk, A.; Dybeł, K. The Fundamental Approach of the Digital Twin Application in Railway Turnouts with Innovative Monitoring of Weather Conditions. Sensors 2021, 21, 5757. [Google Scholar] [CrossRef]
  9. Souanef, T.; Al-Rubaye, S.; Tsourdos, A.; Ayo, S.; Panagiotakopoulos, D. Digital Twin Development for the Airspace of the Future. Drones 2023, 7, 484. [Google Scholar] [CrossRef]
  10. Tomayko, J.E. Making New Reality: Computers in Simulations and Image Processing. In Computers in Spaceflight: The NASA Experience; Wichita State University: Wichita, KS, USA, 1988; pp. 278–281, Computers in the Apollo Mission Simulators. Available online: (accessed on 4 November 2023).
  11. Apollo 13: The First Digital Twin by Stephen Ferguson. Available online: (accessed on 4 November 2023).
  12. Shafto, M.; Conroy, M.; Doyle, R.; Glaessgen, E.; Kemp, C.; LeMoigne, J.; Wang, L. Draft modeling, simulation, information technology & processing roadmap. Technol. Area 2010, 11, 1–32. Available online: (accessed on 4 November 2023).
  13. Singh, M.; Fuenmayor, E.; Hinchy, E.P.; Qiao, Y.; Murray, N.; Devine, D. Digital Twin: Origin to Future. Appl. Syst. Innov. 2021, 4, 36. [Google Scholar] [CrossRef]
  14. Kukushkin, K.; Ryabov, Y.; Borovkov, A. Digital Twins: A Systematic Literature Review Based on Data Analysis and Topic Modeling. Data 2022, 7, 173. [Google Scholar] [CrossRef]
  15. Rjabtšikov, V.; Rassõlkin, A.; Kudelina, K.; Kallaste, A.; Vaimann, T. Review of Electric Vehicle Testing Procedures for Digital Twin Development: A Comprehensive Analysis. Energies 2023, 16, 6952. [Google Scholar] [CrossRef]
  16. Uhlenkamp, J.-F.; Hauge, J.B.; Broda, E.; Lütjen, M.; Freitag, M.; Thoben, K.-D. Digital Twins: A Maturity Model for Their Classification and Evaluation. IEEE Access 2022, 10, 69605–69635. [Google Scholar] [CrossRef]
  17. Attaran, M.; Celik, B.G. Digital Twin: Benefits, use cases, challenges, and opportunities. Decis. Anal. J. 2023, 6, 100165. [Google Scholar] [CrossRef]
  18. Botín-Sanabria, D.M.; Mihaita, A.-S.; Peimbert-García, R.E.; Ramírez-Moreno, M.A.; Ramírez-Mendoza, R.A.; Lozoya-Santos, J.d.J. Digital Twin Technology Challenges and Applications: A Comprehensive Review. Remote Sens. 2022, 14, 1335. [Google Scholar] [CrossRef]
  19. Hofmann, W.; Branding, F. Implementation of an IoT- and Cloud-based Digital Twin for Real-Time Decision Support in Port Operations. IFAC-PapersOnLine 2019, 52, 2104–2109. [Google Scholar] [CrossRef]
  20. Lehner, D.; Pfeiffer, J.; Tinsel, E.F.; Strljic, M.M.; Sint, S.; Vierhauser, M.; Wortmann, A.; Wimmer, M. Digital Twin Platforms: Requirements, Capabilities, and Future Prospects. IEEE Softw. 2022, 39, 53–61. [Google Scholar] [CrossRef]
  21. Boyes, H.; Watson, T. Digital twins: An analysis framework and open issues. Comput. Ind. 2022, 143, 103763. [Google Scholar] [CrossRef]
  22. Ganguli, R.; Adhikari, S. The digital twin of discrete dynamic systems: Initial approaches and future challenges. Appl. Math. Model. 2020, 77 Pt. 2, 1110–1128. [Google Scholar] [CrossRef]
  23. Wu, H.; Ji, P.; Ma, H.; Xing, L. A Comprehensive Review of Digital Twin from the Perspective of Total Process: Data, Models, Networks and Applications. Sensors 2023, 23, 8306. [Google Scholar] [CrossRef]
  24. Yi, H. Improving cloud storage and privacy security for digital twin based medical records. J. Cloud Comp. 2023, 12, 151. [Google Scholar] [CrossRef]
  25. Feldt, J.; Kourouklis, T.; Kontny, H.; Wagenitz, A. Digital twin: Revealing potentials of real-time autonomous decisions at a manufacturing company. CIRP 2020, 88, 185–190. [Google Scholar] [CrossRef]
  26. Eirinakis, P.; Lounis, S.; Plitsos, S.; Arampatzis, G.; Kalaboukas, K.; Kenda, K.; Lu, J.; Rožanec, J.M.; Stojanovic, N. Cognitive Digital Twins for Resilience in Production: A Conceptual Framework. Information 2022, 13, 33. [Google Scholar] [CrossRef]
  27. Mo, D.-H.; Tien, C.-L.; Yeh, Y.-L.; Guo, Y.-R.; Lin, C.-S.; Chen, C.-C.; Chang, C.-M. Design of Digital-Twin Human-Machine Interface Sensor with Intelligent Finger Gesture Recognition. Sensors 2023, 23, 3509. [Google Scholar] [CrossRef]
  28. Ma, X.; Tao, F.; Zhang, M.; Wang, T.; Zuo, Y. Digital twin enhanced human-machine interaction in product lifecycle. CIRP 2019, 83, 789–793. [Google Scholar] [CrossRef]
  29. Kritzinger, W.; Karner, M.; Traar, G.; Henjes, J.; Sihn, W. Digital Twin in manufacturing: A categorical literature review and classification. IFAC-PapersOnLine 2018, 51, 1016–1022. [Google Scholar] [CrossRef]
  30. Sahal, R.; Alsamhi, S.H.; Brown, K.N.; O’Shea, D.; McCarthy, C.; Guizani, M. Blockchain-Empowered Digital Twins Collaboration: Smart Transportation Use Case. Machines 2021, 9, 193. [Google Scholar] [CrossRef]
  31. Ibrahim, M.; Rjabtšikov, V.; Gilbert, R. Overview of Digital Twin Platforms for EV Applications. Sensors 2023, 23, 1414. [Google Scholar] [CrossRef] [PubMed]
  32. Park, C.; Chung, S.; Lee, H. Vehicle-in-the-Loop in Global Coordinates for Advanced Driver Assistance System. Appl. Sci. 2020, 10, 2645. [Google Scholar] [CrossRef]
  33. Vignati, M.; Debattisti, N.; Bacci, M.L.; Tarsitano, D. A Software-in-the-Loop Simulation of Vehicle Control Unit Algorithms for a Driverless Railway Vehicle. Appl. Sci. 2021, 11, 6730. [Google Scholar] [CrossRef]
  34. Mihalič, F.; Truntič, M.; Hren, A. Hardware-in-the-Loop Simulations: A Historical Overview of Engineering Challenges. Electronics 2022, 11, 2462. [Google Scholar] [CrossRef]
  35. Issa, R.; Badr, M.M.; Shalash, O.; Othman, A.A.; Hamdan, E.; Hamad, M.S.; Abdel-Khalik, A.S.; Ahmed, S.; Imam, S.M. A Data-Driven Digital Twin of Electric Vehicle Li-Ion Battery State-of-Charge Estimation Enabled by Driving Behavior Application Programming Interfaces. Batteries 2023, 9, 521. [Google Scholar] [CrossRef]
  36. Venkatesan, S.; Manickavasagam, K.; Tengenkai, N.; Vijayalakshmi, N. Health Monitoring and Prognosis of Electric Vehicle Motor using intelligent-Digital Twin. IET Electr. Power Appl. 2019, 13, 1328–1335. [Google Scholar] [CrossRef]
  37. Merkle, L.; Pöthig, M.; Schmid, F. Estimate e-Golf Battery State Using Diagnostic Data and a Digital Twin. Batteries 2021, 7, 15. [Google Scholar] [CrossRef]
  38. Popa, L.; Berdich, A.; Groza, B. CarTwin—Development of a Digital Twin for a Real-World In-Vehicle CAN Network. Appl. Sci. 2023, 13, 445. [Google Scholar] [CrossRef]
  39. Albatayneh, A.; Assaf, M.N.; Alterman, D.; Jaradat, M. Comparison of the Overall Energy Efficiency for Internal Combustion Engine Vehicles and Electric Vehicles. Environ. Clim. Technol. 2020, 24, 669–680. [Google Scholar] [CrossRef]
  40. Martyushev, N.V.; Malozyomov, B.V.; Khalikov, I.H.; Kukartsev, V.A.; Kukartsev, V.V.; Tynchenko, V.S.; Tynchenko, Y.A.; Qi, M. Review of Methods for Improving the Energy Efficiency of Electrified Ground Transport by Optimizing Battery Consumption. Energies 2023, 16, 729. [Google Scholar] [CrossRef]
  41. Sandrini, G.; Chindamo, D.; Gadola, M. Regenerative Braking Logic That Maximizes Energy Recovery Ensuring the Vehicle Stability. Energies 2022, 15, 5846. [Google Scholar] [CrossRef]
  42. Konzept, A.; Reick, B.; Kaufmann, A.; Hermanutz, R.; Stetter, R. Battery Electric Vehicle Efficiency Test for Various Velocities. Vehicles 2022, 4, 60–73. [Google Scholar] [CrossRef]
  43. Zhang, Y.; Liu, H.; Zhang, Z.; Luo, Y.; Guo, Q.; Liao, S. Cloud computing-based real-time global optimization of battery aging and energy consumption for plug-in hybrid electric vehicles. J. Power Sources 2020, 479, 229069. [Google Scholar] [CrossRef]
  44. Almutairi, A.; Albagami, N.; Almesned, S.; Alrumayh, O.; Malik, H. Electric Vehicle Load Estimation at Home and Workplace in Saudi Arabia for Grid Planners and Policy Makers. Sustainability 2023, 15, 15878. [Google Scholar] [CrossRef]
  45. Restrepo, J.; Rosero, J.; Tellez, S. Performance Testing of Electric Vehicles on operating conditions in Bogotá DC, Colombia. In Proceedings of the 2014 IEEE PES Transmission & Distribution Conference and Exposition-Latin America (PES T&D-LA), Medellin, Colombia, 10–13 September 2014; IEEE: Medellin, Colombia, 2014; pp. 1–8. [Google Scholar]
  46. Zhao, Z.; Li, L.; Ou, Y.; Wang, Y.; Wang, S.; Yu, J.; Feng, R. A Comparative Study on the Energy Flow of Electric Vehicle Batteries among Different Environmental Temperatures. Energies 2023, 16, 5253. [Google Scholar] [CrossRef]
  47. Jones, D.; Snider, C.; Nassehi, A.; Yon, J.; Hicks, B. Characterising the Digital Twin: A systematic literature review. CIRP J. Manuf. Sci. Technol. 2020, 29 Pt A, 36–52. [Google Scholar] [CrossRef]
  48. Nowak, M.; Baier, M. Implementation of object-oriented programming in study of electrical race car. IOP Conf. Ser. Mater. Sci. Eng. 2016, 145, 042028. [Google Scholar] [CrossRef]
  49. Nowak, M.; Baier, A. Object-oriented application for electric car’s drive. In Selected Engineering Problems; Institute of Engineering Processes Automation and Integrated Manufacturing Systems: Gliwice, Poland, 2015; pp. 57–62. Available online: (accessed on 11 August 2023).
  50. Instruction Manual and Data Sheet Torque Sensor Series 2000. Available online: (accessed on 11 August 2023).
  51. GreenPower Motor Datasheet. Available online: (accessed on 11 August 2023).
  52. SEW Eurodrive. Parameter and Operating State Indicators. Available online: (accessed on 23 July 2023).
  53. SEW Eurodrive. Fieldbus Interface DFE11B Ethernet. Available online: (accessed on 23 July 2023).
  54. SEW Eurodrive. Communication and Fieldbus Unit Profile. Available online: (accessed on 23 July 2023).
  55. SEW Eurodrive. MOVIDRIVE® MDX60B/61B. Available online: (accessed on 23 July 2023).
  56. Figueroa-Lorenzo, S.; Añorga, J.; Arrizabalaga, S. A Role-Based Access Control Model in Modbus SCADA Systems. A Centralized Model Approach. Sensors 2019, 19, 4455. [Google Scholar] [CrossRef]
  57. Mejías, A.; Herrera, R.S.; Márquez, M.A.; Calderón, A.J.; González, I.; Andújar, J.M. Easy Handling of Sensors and Actuators over TCP/IP Networks by Open Source Hardware/Software. Sensors 2017, 17, 94. [Google Scholar] [CrossRef]
  58. Modbus Organization. Modbus Application Protocol Specification. Available online: (accessed on 11 August 2023).
  59. National Instruments. Modbus Master Plasmionique Inc. Available online: (accessed on 23 July 2023).
  60. Niknejad, P.; Agarwal, T.; Barzegaran, M.R. Utilizing Sequential Action Control Method in GaN-Based High-Speed Drive for BLDC Motor. Machines 2017, 5, 28. [Google Scholar] [CrossRef]
  61. Estrada, L.; Vázquez, N.; Vaquero, J.; de Castro, Á.; Arau, J. Real-Time Hardware in the Loop Simulation Methodology for Power Converters Using LabVIEW FPGA. Energies 2020, 13, 373. [Google Scholar] [CrossRef]
  62. Stević, Z.; Andjelković, Z.; Antić, D. A New PC and LabVIEW Package Based System for Electrochemical Investigations. Sensors 2008, 8, 1819–1831. [Google Scholar] [CrossRef] [PubMed]
  63. Stalica, A.; Błachuta, M.; Baier, A.; Zur, P.; Kołodziej, A.; Konopka, P.; Komander, M. Telemetric System for Silesian Greenpower’s Vehicle. IOP Conf. Ser. Mater. Sci. Eng. 2019, 564, 012119. Available online: (accessed on 23 July 2023). [CrossRef]
  64. Baier, A.; Komander, M.; Nowak, A.; Konopka, P.; Kołodziej, A.; Żur, P. Designing and verifying the concept of Silesian Greenpower electric bolide structure. In Proceedings of the Innovative Manufacturing Engineering and Energy (IManEE 2019), Pitesti, Romania, 22–24 May 2019; pp. 1–7. [Google Scholar] [CrossRef]
  65. Żur, P.; Baier, A.; Kołodziej, A. Influence of selected parameters of the motor controller on the current characteristics of the DC brush motor used in the Silesian Greenpower’s Vehicle. In Proceedings of the 4th International Conference on Mechanical, Manufacturing, Modeling and Mechatronics IC4M 2019, in Conjunction with 4th International Conference on Design Engineering and Science, ICDES 2019, Nice, France, 22–24 February 2019. [Google Scholar] [CrossRef]
  66. Grabowski, Ł.; Baier, A.; Buchacz, A.; Majzner, M.; Sobek, M. Application of CAD/CAE class systems to aerodynamic analysis of electric race cars. In Proceedings of the Modern Technologies in Industrial Engineering (ModTech2015), Mamaia, Romania, 17–20 June 2015. [Google Scholar] [CrossRef]
Figure 1. The block diagram for the system.
Figure 1. The block diagram for the system.
Applsci 14 01776 g001
Figure 2. (a) The block diagram in LabView. Presentation of the FC16 recording function; (b) the part of the front panel. Presentation of the communication panel.
Figure 2. (a) The block diagram in LabView. Presentation of the FC16 recording function; (b) the part of the front panel. Presentation of the communication panel.
Applsci 14 01776 g002
Figure 3. (a) Dependence of the control quantity and the rotational speed. (b) Enlarged rotation graph with setpoint 20 applied.
Figure 3. (a) Dependence of the control quantity and the rotational speed. (b) Enlarged rotation graph with setpoint 20 applied.
Applsci 14 01776 g003
Figure 4. Dependences of the control quantity and the rotational speed.
Figure 4. Dependences of the control quantity and the rotational speed.
Applsci 14 01776 g004
Figure 5. The rotational speed of the DC motors during the first lap from simulation and race data.
Figure 5. The rotational speed of the DC motors during the first lap from simulation and race data.
Applsci 14 01776 g005
Figure 6. (a) DC motor’s rotational speed during lap 5 from simulation and race data; (b) dependence of the control quantity and the DC motor rotational speed during the fifth lap.
Figure 6. (a) DC motor’s rotational speed during lap 5 from simulation and race data; (b) dependence of the control quantity and the DC motor rotational speed during the fifth lap.
Applsci 14 01776 g006
Figure 7. (a) CAD model of the racing car; (b) the reproduced car in terms of structure; (c) the motor parameters; (d) data from the telemetry module on the modeled trip.
Figure 7. (a) CAD model of the racing car; (b) the reproduced car in terms of structure; (c) the motor parameters; (d) data from the telemetry module on the modeled trip.
Applsci 14 01776 g007
Figure 8. Wind parameters.
Figure 8. Wind parameters.
Applsci 14 01776 g008
Figure 9. (a) Car motion trajectory based on data from the telemetry system; (b) simulation of the car trajectory on the Dunsfold track.
Figure 9. (a) Car motion trajectory based on data from the telemetry system; (b) simulation of the car trajectory on the Dunsfold track.
Applsci 14 01776 g009
Figure 10. Comparison of the travel trajectories on the Dunsfold track: blue line—telemetry GPS track; green line—theoretical track.
Figure 10. Comparison of the travel trajectories on the Dunsfold track: blue line—telemetry GPS track; green line—theoretical track.
Applsci 14 01776 g010
Table 1. Maturity model of a digital twin.
Table 1. Maturity model of a digital twin.
Reference objectWhat 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 phasesThe phase of the product life cycle at which a DT is applied: beginning, middle or end of life.
Application domainA sector for implementing a DT, e.g., manufacturing, aerospace, healthcare, automotive, maritime.
BenefitsImproving existing services, adding new value, or establishing a new service.
Computing capabilities
Trigger types (simulation capabilities)A simulation starts on a specific event and runs continuously or once at a specific time.
Model look-ahead perspectiveTime 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—inputHow often a piece of new data appears: in real time or less frequently.
Update frequency—outputOutputs from DT are immediate, real-time, or periodic due to the strategy implemented.
Creation timeA DT was designed in parallel with the product’s design or later in the product life cycle.
Modelled characteristicsWhich object behavior is modelled: geometric, kinematic, sensor, control, or system characteristics.
Digital model typesReferring 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 maintenanceDT’s ability to ensure system validation and accuracy in new circumstances. Some cases require manual adaptation, while others are autonomous.
ModularityHow 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 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 qualityMatching 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 interpretationDT’s capabilities to use incoming data. If a DT operates on irregular and unsorted data.
Level of cognition DT is only for monitoring and diagnostic purposes or gives predictive forecasts based on a simulation.
Levels of autonomyHow DT processes decisions: with user support or fully independently, autonomous.
Learning capabilitiesDetermines whether a machine learning algorithm exists; supervised, semi-supervised, unsupervised, and reinforced.
Human–machine interaction (HMI)
Types of interaction devicesMethod 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 capabilitiesIn case of new challenges, DT adapts itself or the output responses are predefined.
Digital twin interactionSpecifies whether there is only one DT or multiple DTs and describes how they collaborate.
HierarchyThis dimension provides information about the rank of collaborating DTs.
Connection modeThe 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 focusDT can be useful for an individual user, a department, a company, or several organizations.
CollaborationThere are DTs established for different organizations, there is data exchange between them, and they can have similar purposes or work independently.
Table 2. Characteristics of different simulation methods.
Table 2. Characteristics of different simulation methods.
MethodMiLSiLPiL/FiLHiLViLTest Drive
Software simulated model
Control simulator
Embedded processor
I/O, communication
Real conditions
Table 3. Digital twin examples in an EV world.
Table 3. Digital twin examples in an EV world.
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.
Table 4. The list of modified parameters.
Table 4. The list of modified parameters.
P100Setpoint sourceFieldbus
P101Control signal source
P700Operating mode 1CFC and torque control
P870Setpoint description PO1Control word 1
P871Setpoint description PO2Current
P872Setpoint description PO3No function
P873Actual value description PI1Status word 1
P874Actual value description PI2Speed
P875Actual value description PI3Output current
P876PO data enableON
Table 5. The control word description.
Table 5. The control word description.
0Fixed definitionController inhibit “1”/Enable “0”
1Enable “1”/Rapid stop “0”
2Enable “1”/Stop “0”
3Hold control
4Integrator switchover
5Parameter set switch-over
8Direction of rotation for motor potentiometer0 = CW direction of rotation
1 = CCW direction of rotation
Motor potentiometer acceleration
Motor potentiometer deceleration
10 9
0 0 = no change
0 1 = up
1 0 = down
1 1 = no change
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)
13Fixed setpoint switchover0 = 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
ReservedSet reserved bits to 0
Table 6. Modbus TCP frame format. The entire frame is called an ADU (application data unit).
Table 6. Modbus TCP frame format. The entire frame is called an ADU (application data unit).
0–1Transaction IDMBAP—Modbus
Application header
2–3Protocol ID
4–5Length field
6Client ID
7Function codePDU—protocol data unit
8–n 1Data
1 A maximum of ten words can be exchanged at a time.
Table 7. Register mapping.
Table 7. Register mapping.
OffsetMeaning for Read OperationMeaning for Write OperationRemarks
0hex–3hexReservedReservedNo access
4hex–DhexProcess input data
(actual values)
Process output data (setpoints)Max. 10 words for MDX61B
Access via FC3, FC16, FC23
Table 8. Six track segments of appropriate length.
Table 8. Six track segments of appropriate length.
Segment No.Length [m]Setpoint Value
Table 9. The SWOT analysis of the system.
Table 9. The SWOT analysis of the system.
StrengthsData-driven model uses real-world data
Research station consists of the same parts as the racing car
Various scenarios can be simulated
WeaknessDepends on data quality
Lack of physical understanding of the data
Manual method for implementing input data
OpportunitiesThe entire system can be expanded
Indoor testing reduces time and costs
ThreatsComplexity of data integration
Requires appropriate validation
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Share and Cite

MDPI and ACS Style

Bednarz, T.; Baier, A.; Paprocka, I. A Framework for Communicating and Building a Digital Twin Model of the Electric Car. Appl. Sci. 2024, 14, 1776.

AMA Style

Bednarz T, Baier A, Paprocka I. A Framework for Communicating and Building a Digital Twin Model of the Electric Car. Applied Sciences. 2024; 14(5):1776.

Chicago/Turabian Style

Bednarz, Tomasz, Andrzej Baier, and Iwona Paprocka. 2024. "A Framework for Communicating and Building a Digital Twin Model of the Electric Car" Applied Sciences 14, no. 5: 1776.

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Metrics

Back to TopTop