Design of a Modularization-Based Automation Performance Simulation Framework for Multi-Vehicle Interaction System

By inergency On Mar 28, 2024

[ad_1]

1. Introduction

Under the background of growing market demands and stringent fuel consumption regulations, pure electric or hybrid electric vehicles (HEVs) have emerged as a vital solution to the dual challenges of energy scarcity and environmental pollution, by virtue of their easy access to electricity, clean, and low pollution benefits [1]. HEVs signify a developmental shift within the vehicle industry, with various configurations already in use on the roads. With the infrastructure construction of the Internet of Vehicles (IoV) and cloud computing [2], effective co-simulation of multiple vehicles is an important way to mine the big data of the IoV [3].

Large-scale vehicle simulation technology, leveraging traffic and vehicle simulation software, facilitates the acceleration of edge computing applications and reduces the costs associated with vehicle–road collaboration. The traffic environment plays a critical role in influencing energy consumption and drivability [4]. Under the background of the trend of electrification and networking in the automotive industry, the collaborative optimization design of traffic flow composed of various configurations of HEVs and traditional vehicles has put forward new requirements for the design of performance simulation environments. To achieve large-scale vehicle performance co-simulation, two primary objectives must be addressed as follows: firstly, the rapid and straightforward construction of vehicle models with various configurations, including the automatic initialization of model parameters, control of the running process, and postprocessing of results. HEVs involve many configurations and sub-component models, each constructed with its own unique specifications. Utilizing plug-and-play model construction technology and simulation file management methods [5], such as those proposed by Autonomie software 2019, AVL Cruise 2020, etc., enhances the reusability of simulation model files. By introducing modularity, a vehicle is divided into multiple modules, each containing different parameters and models. Those modules are combined with each other and their relationships analyzed to complete the modeling of a single vehicle, forming an automated framework for single vehicle performance simulation. Secondly, establishing an interaction channel between multiple vehicles to enable signal interaction while ensuring synchronization is crucial. This involves recording the input and output signals required by each vehicle to construct a communication matrix and establishing a signal scheduler for dynamic signal allocation between vehicles. Based on the above two aspects, the multiple vehicle performance simulation under the mixed traffic environment with various vehicle combinations is completed. The original contributions of this paper can be summarized as follows: (i) the simulated working principle of the drag-and-drop coupled mechanical system is described, (ii) the process of an automated performance simulation is designed, (iii) a method for the effective management of simulation system scripts and model files is proposed, and (iv) an efficient multiple vehicle control system model architecture and development framework is presented.

The structure of this paper is outlined as follows: Section 2 outlines the existing literature review and identifies the gaps in software tools for vehicle performance calculation. Section 3 delves into the architecture and design methodology of the comprehensive simulation environment. Section 4 elucidates the methodology for constructing vehicle models and detailing the simulation processes for individual vehicles, providing a foundation for the development of simulation models. Section 5 expands this discussion to the joint simulation methods for multiple vehicles, showcasing the application of these methods through practical use cases in Section 6. Finally, the conclusions and future perspectives are presented in Section 7.

2. Literature Review

Simulation of vehicle energy consumption and dynamic performance is widely embraced by vehicle research institutions for the development and analysis of new transmission systems [6]. Typically, a module-based design approach is employed to integrate components into a system via signal connections [7]. However, the interdependence of signals and parameters among components necessitates a unified standard for automated operation when dealing with large-scale interactions between vehicles of various configurations. This field of energy consumption and performance simulation for different vehicle configurations is well established, with numerous commercial and open-source software options available [8], such as MATLAB 2022, AVL Cruise 2020, AMESim 2020, ADVISOR 2002, Autonomie 2019, etc. AVL Cruise is a commercial vehicle simulation software that can analyze a variety of vehicle drivetrains. Graphical modeling, achieved by dragging and dropping vehicle components and connecting them, is the core feature, enabling the assembly of a complete vehicle model. A parameter matching study was carried out by J. W. Ma [9], who used AVL Cruise to design the motor, power battery, and final drive to meet the target performance. H. T. Arat [10] built multiple powertrain vehicles with AVL Cruise, to compare and analyze features of the vehicles in terms of performance and emission results. Autonomie is an open-source software developed at Argonne National Laboratory, and the Simulink-based simulation environment can capture the detailed mechanism of the model. J. Yao et al. [11] improved the simulation process efficiency of vehicle fuel economy with a novel large-scale learning and prediction process based on Autonomie. Micro-level traffic simulators are designed to simulate interactions between vehicles to evaluate mobility ecosystems, such as VISSIM 5.20 [12] and SUMO 4.24 [13]. Many projects evaluate the algorithm performance of autonomous driving, vehicle–road collaboration, and vehicle-to-everything communication in complex interactive scenarios by constructing virtual traffic environments [14]. T. Tettamanti et al. [15] used MATLAB and VISSIM to calculate mathematical problems and simulate the traffic environment online, respectively, and established an integrated simulation control environment based on the VISSIM COM interface to solve signal control problems. W. M. Griggs et al. [16] embedded a real vehicle into SUMO to realize the hardware-in-the-loop of the vehicle in a large-scale intelligent transportation system, and thus allowed drivers to obtain real-time traffic feedback. The design of multi-vehicle simulation architecture is generally oriented to the motion safety and information interaction between vehicles under various complex virtual environment conditions. M. A. Meyer et al. [17] proposed a closed-loop platoon simulation environment with intelligent transportation system, and implemented a large-scale vehicle simulation for cooperative adaptive cruise control. M. Guériau et al. [18] devised a virtual environment to validate and test the platoon control method that achieves a direct match between the perception and control of real and virtual vehicles. When multiple vehicles are simulated in a distributed manner, it is key to ensure the synchronization of data interaction and the simulation of real hardware characteristics. Z. Zhang et al. [19] presented a time-triggered automotive cyber-physical systems design framework with co-simulation between the software, network/platform, and physical components. E. Eyisi et al. [20] designed an integrated modeling and simulation tool for evaluating networked control systems. Based on the existing simulation tools, the test platform for vehicle energy consumption and multi-vehicle interaction is widely used. The multi-vehicle simulation environment considering vehicle dynamics is mainly used to study the intelligent sensing and advanced assisted driving functions of vehicles [21]. To study the functional performance of connected vehicles in a wide range of traffic scenarios and road conditions, the software PreScan 5.0 was developed to form a comprehensive environment for designing and evaluating a multi-vehicle simulation system [22]. C. S. Wang et al. [23] used PreScan software to construct a simulation environment by importing real road sections and tested the vehicle cooperative driving sense system. However, the current vehicle energy consumption calculation is only for single-vehicle simulation tests under a specific driving cycle, and there are few multi-vehicle performance collaborative optimization platforms for hybrid vehicle configurations.

While current vehicle performance analysis software is widely used, it primarily focuses on simulating specific vehicle configurations under fixed driving cycles [24]. However, there is a notable absence of multi-vehicle simulation environments that incorporate co-simulation for investigating intelligent sensing and advanced assisted driving functions, especially concerning hybrid electric vehicles (HEVs) with diverse configurations. In contrast, traffic simulation software serves as a multiple vehicle interaction environment, to facilitate the development of collaborative algorithms, such as energy consumption and traffic efficiency optimization. Nevertheless, existing micro-traffic simulation software treats vehicles as mass blocks with fixed lengths [25], neglecting the dynamic characteristics of real vehicles and failing to refine the transmission systems of individual vehicles.

Currently, technologies such as vehicle-to-vehicle wireless communication are in the process of practical implementation [26]. Consideration of the specific configuration of each vehicle and the communication and interaction between different vehicles could significantly impact the development of new hybrid vehicles and enhance performance by leveraging operating condition information, as shown in Figure 1. Addressing the limitations of the current research, this paper proposes a large-scale vehicle performance automation simulation framework based on a modular design.

4. Single-Vehicle Platform Design

For the comprehensive simulation analysis of various vehicle configurations, ranging from different models to the parameters of each component, the processing program needs to accommodate all potential simulation requirements, which can be summarized as a variety of vehicle models and simulation processes in general. Since signal connections and parameter calculations between components are related to their interdependencies, it is crucial to execute necessary tasks to ensure the proper operation of the simulation system and identify potential configuration errors, such as scripts running sequences and signal connection relationships. A single-vehicle performance simulation involves system construction to meet the diverse requirements of essential functions to maintain the system operation, as shown in Figure 3.

4.1. Simulation Construction

The diversification of vehicle models primarily encompasses the following aspects: the vehicle model library (including passenger cars, commercial vehicles, special vehicles, etc.), the types of components and their connection configurations following specific rules, and the configurable parameters of each component. A single-vehicle model design architecture comprises module files, information extraction tools, and module connection rules, as illustrated in Figure 4. In the general simulation process, the initialization file provides all the parameters required by the model. Subsequently, the model undergoes execution, and the results produced by the model are subjected to postprocessing. Each component serves as a module and consists of four types of files: initialization scripts, preprocessing scripts, component models, and postprocessing scripts. The initialization script is solely dedicated to initializing the parameters essential for the corresponding model. It directly assigns values to parameters that do not necessitate further processing. It does not involve referencing parameters from other initialization or preprocessing files, nor does it engage in mutual calculations between parameters. Parameters that users can directly configure via the UI are included in this script, such as the engine fuel consumption map and the car body mass in the car body model. When the model entails parameters obtained from the initialization or preprocessing script of other components, or when parameters require mutual calculation to derive new parameters, these assignment statements referring to other component parameters or mutual calculations must be housed in the preprocessing script. For instance, the engine fuel consumption map may be further calculated to derive the optimal working curve of the engine, while the total mass of the vehicle is obtained by aggregating the masses of all individual components. After the simulation of the model, the postprocessing script can leverage all the parameters and model output signals. Based on these data, the postprocessing script generates the calculation results.

With the aid of information extraction tools, key information from the parameter scripts can be recognized and extracted based on the characters’ positions around the equals sign. This includes identifying the input parameters (IPs), output parameters (OPs), input signals (ISs), and output signals (OSs). Input parameters (IPs) are those necessary for script or model execution, found on the right side of equations within assignment statements or within the configuration boxes of models. Output parameters (OPs) represent new parameters generated after script execution, located on the left side of assignment statements. Input signals (ISs) are provided by other component models, while output signals (OSs) are the outputs generated by the component during operation.

Furthermore, based on the interdependence of the input and output variables between parameter scripts, we can perform automated operation sorting and parameter integrity testing. In addition, based on the input and output properties of the module files, with the help of the module’s connection tool, we can achieve interconnection between modules. Through the operation of various module files, three major functions are ultimately achieved, including a simulation feasibility check, module scripts run order, and model automatic construction.

4.2. Component Connection Relationship

The entire simulation model is divided into four parts: the driver, the environment, vehicle control system, and vehicle powertrain system, as illustrated in Figure 5. In the Simulink modeling software, due to the presence of numerous input and output signals in each component, to facilitate the signal wiring between modules and automatic program splicing of modules, multiple signals in the module are bundled in the form of a bus. Multiple signals are collected in the bus and can be extracted directly from the bus where needed. Each part corresponds to its own signal bus, namely the driver bus, environment bus, controller bus, and powertrain bus. These four buses are combined into a global bus, which facilitates the transfer of signals between various controllers, plants, driver, and environment. The controller buses consist of different components or vehicle controller buses, such as MCU, TCU, HCU, etc. Similarly, the plant buses comprise various plant buses, such as gearbox bus, wheel bus, etc.

The input signal set of each component interface must match the physical characteristics of the output signal set of the interface of another component to be connected in sequence. The properties of the component interface are shown in Table 1, while the rules governing component connections are shown in Figure 6.

To streamline user connectivity and minimize unnecessary errors, a restriction is imposed wherein an interface can only be connected to one other interface at a time. Simultaneous connections of two or more interfaces, even if they adhere to connection rules, are not permitted. Additionally, interfaces within the same module cannot be interconnected, even if they satisfy the basic connection criteria. Given scenarios where one component needs to connect to multiple components simultaneously, such as the battery module requiring connections to both the motor and the power converter, auxiliary modeling components are introduced, as shown in Table 2.

The controller, driver, and environment components do not require physical connections. Consequently, their inputs originate from the global bus, while their outputs are directed to the corresponding signal output buses. Apart from these two buses, different plant inputs and outputs need to be interconnected to establish various configurations. Given that different powertrain configurations entail distinct plant and connection relationships, the connection relationship between plants is represented by effort and flow signals. It is important to note that the number of effort and flow signals for each plant vary according to the plant type, corresponding to the number of interfaces in the table and the type of input and output signals for each interface. Furthermore, with the aid of the auxiliary modeling modules outlined in the table, the effort signals (or flow signals) of the same attribute can be superimposed or distributed.

The connection relationship configuration of the components and the corresponding models’ connection relationship are shown in Figure 7. In Figure 7a, the configuration connection relationship between the gearbox and final drive is represented. Referring to Table 1, both the gearbox and final drive have two interfaces, and the input–output relationship is shown in Figure 7b. Following the connection relationship between components, interface 2 of the gearbox can be connected to interface 1 of the final drive.

The dashed connection on the component configuration (Figure 7a) represents two connections on the corresponding model (Figure 7b). For the gearbox, the connections are the gearbox output torque (gearbox effort out) and gearbox flow in. For the final drive, the connections are the final drive input torque (final drive effort in) and final drive output speed (final drive flow out). It is important to note that the gearbox flow in is equivalent to the final drive output speed, while the gearbox output torque is equivalent to the final drive input torque.

For each model, aside from the input effort and flow, there may be a requirement for input signals from other external models. Similarly, besides the output effort and flow, the model’s output signals need to be disseminated to other models. Taking the final drive model as an example in Figure 8, the necessary signals are selected from the global bus via the signal selection subsystem, while all the final drive output signals are gathered onto the final drive bus by the signal collection subsystem.

4.3. Simulation Feasibility Checking

Different models have their own running files, including initialization, preprocessing, result postprocessing, etc. These files are interdependent during execution, necessitating a specific sequence for processing. To ensure the correct execution of the file sequence and verify any missing parameters or signals, distinct names are defined for various files, as outlined in Table 3.

In accordance with the order of operations, the inspection of possible unreasonable situations encompasses script and model parameter integrity checking, signal integrity checking, and configuration checking.

After obtaining the script set that requires IPs again, compare the number of scripts in the current set with the number of scripts in step d. If the script set is empty or the length is not equal, return to step d and repeat the process. However, if the script set is not empty and its length remains the same, it is determined that the scripts in the current script set lack IPs and cannot run correctly. Each script in the script set is then individually analyzed to retrieve its required IPs, which are then communicated to the users.

2.

Model parameter integrity checking

Catalog OPs provided by all initialization and preprocessing scripts and save all OPs in the OPs collector.
For each model, catalog its required IPs and determine the difference between the IPs of each model and the OPs collector. If the difference set is empty, it indicates that the parameters required by the model can be fully provided by the scripts. Otherwise, it signifies that some parameters required by the model are missing.
Gather the parameters and corresponding models from the non-empty difference set and output them to the user for inspection.

3.

Model signal integrity checking

Catalog the OSs of all models and save them in a signal collector.
For each model, catalog the ISs and determine the difference between the ISs of each model and the OSs collector. If the difference set is empty, it indicates that the signals required by the model can be fully provided by other models. Otherwise, it signifies that some signals required by the model are missing.
Gather the signals and corresponding models from the non-empty difference set and output them to the user for inspection.

4.

Postprocessing script parameter and signal integrity checking

Catalog the OPs provided by all initialization and preprocessing scripts, as well as the OSs provided by all models, and save them in a collector.
Utilize a method similar to the preprocessing script parameter integrity check to examine the integrity of postprocessing script parameters and signals. Note that postprocessing scripts can both require and provide parameters and signals simultaneously.

5.: Unreasonable configuration checking

The vehicle simulation model must align with the test process. For instance, distance-based operating conditions should be used with specific drivers. Additionally, the State of Charge (SOC) balance of the driving cycle must match the usage of hybrid electric vehicles.

Beyond the verifications discussed, additional checks include scrutinizing whether different models erroneously utilize identical names for Oss and detecting any instances of OPs being redundantly defined across scripts. Given the infrequency and straightforward nature of these issues, an extensive discussion is deemed unnecessary. Moreover, it is crucial to delineate the signal connection relationships between each model and its respective components, with a particular emphasis on accurately identifying the originating component model of the input signal.

4.4. Simulation Process Construction

The vehicle simulation test process encompasses various aspects such as dynamic performance, economy, driving range, and drivability performance. Additionally, it involves joint simulation and parameter sensitivity analysis across different test processes. Table 1 lists different types of computing configurations and performance indexes. Table 4 provides users with the ability to compute various combined performances, such as calculating both the acceleration time of 100 km and the maximum climbing degree simultaneously. Table 5 lists the different calculation modes, and each calculation mode in Table 2 can be flexibly combined with the calculation types in Table 1. Given the multitude of combinations, it is impractical to delineate the corresponding execution process for each combination.

To meet the diverse testing needs across different processes and enhance function reusability, each performance index solution is treated as a running process, while different calculation modes are considered modifications of various processes. Each simulation process is segmented into multiple process steps, such as system initialization, model execution, result saving, and outputting calculated performance indices. These process steps are then flexibly combined to form a process, and each process can be modified or combined flexibly to achieve complex processes.

For instance, consider the parameter sensitivity analysis of environmental temperature changes on the driving range of a pure electric vehicle under specific driving cycles, as depicted in Figure 10. The four major parts separated by dotted lines represent distinct processes: the parameter sensitivity analysis process, time-based cycle process, driving range calculation process, and simulation termination condition-setting process. It is important to note that these four processes are independent of each other. The functionality of the parameter sensitivity analysis process relies entirely on the nested entry calls it makes. For example, the parameter change analysis process calls the time-based cycle process to conduct vehicle economy simulation at different temperatures. Similarly, the parameter change analysis process can also focus on assessing the impact of altering the vehicle’s total mass on factors like the maximum gradeability or acceleration time.

The primary function of the time-based cycle process is to calculate the economics of a specific vehicle configuration under a time-based cycle. When no process is nested within the time-based cycle process, there are no other nested programs to execute the model simulation steps. Consequently, the model simulation step in the time-based cycle process will run directly. However, the additional functionalities of the time-based cycle process or other economic simulation processes depend on whether there is process nesting. For instance, in Figure 11, the driving range simulation process is nested, enabling the calculation of the driving range for pure electric vehicles. This process can also be combined with others to meet various simulation requirements. For example, it can be combined with the State of Charge (SOC) correction process for SOC balance correction in hybrid vehicles or with the cold start process of traditional vehicles to account for economic fuel consumption penalties.

6. Case Study and Discussion

Based on the proposed multi-vehicle interactive simulation platform, an economical speed planning algorithm based on net-connected information is validated. The algorithm process is depicted in Figure 16. Initially, leveraging the vehicle’s GPS-derived position, driving path, and signalized phase data retrieved from the cloud, the desired time intervals at each intersection are computed under speed constraints and signal phase limitations in a forward direction. Subsequently, appropriate time intervals are selected as reference points to ensure optimal passage efficiency. Backward recursion, based on the signal phase and speed constraints, is employed to determine the reference time interval for all signalized intersections. This reference time interval is then translated into reference speeds. Integrating this information with the position and speed data of the lead vehicle retrieved from the cloud, alongside the vehicle’s own speed information, an objective function is formulated within the Model Predictive Control (MPC) framework. This function considers vehicle economy, comfort, and reference speed.

Subsequently, under constraints such as road speed limits, safety distances, and vehicle dynamics, the optimization problem is reformulated into a nonlinear planning problem using the multi-targeting method. Economic speed is then determined through the solution of this problem. Finally, the economic speed trajectory, travel path, and vehicle position obtained from the solution are transmitted to the lower-level energy management system for implementation.

The optimal problem in the prediction time domain is defined as follows:

$\begin{array}{l} \arg \min_{u} J = \int_{k}^{k + N_{p}} [w_{1} f_{t q} (u (t)) + w_{2} f_{t i m e} (x (t)) + w_{3} f_{c o m} (x (t))] d t \\ s . t . {\begin{cases} d (t) \leq d_{p r e} (t) - g_{\min_s a f e} \\ v_{\min_i} \leq v (t) \leq v_{\max_i} \\ T_{\min_t q} \leq T_{t q} (t) \leq T_{\max_t q} \\ T_{\min_b} \leq T_{t q} (t) \leq T_{\max_b} \end{cases} \end{array}$

(1)

where $J$ is the total cost function, and $f_{t q}$ , $f_{t i m e}$ , and $f_{c o m}$ are the cost functions of the driving force, comfort, and reference speed, respectively. $w_{1}$ , $w_{2}$ , and $w_{3}$ are the weight coefficients corresponding to the three cost functions, respectively. $d t$ is the time step. $k$ is the current moment. $N_{p}$ is the step size in the predicted time domain. $d$ is the safe distance $d_{p r e}$ and $g_{\min_s a f e}$ are the pre-set safety distances and minimum safety distances, respectively. $v$ is the vehicle speed. $v_{\max_i}$ and $v_{\min_i}$ are the maximum and minimum vehicle speeds, respectively. $T_{t q}$ is the driving torque. $T_{\max_t q}$ and $T_{\min_t q}$ are the maximum and minimum driving torques, respectively. $T_{\max_b}$ and $T_{\min_b}$ are the maximum and minimum braking torques, respectively.

As the software primarily serves automation modeling, vehicle interface configuration, interface transmission, and interaction interface description, the emphasis in documentation tends to lean towards architecture and modeling methodologies. The focal point of this paper lies in delineating the design of a multi-vehicle communication software architecture, with vehicle algorithms taking a subsidiary role. Consequently, detailed discussions on vehicle control algorithms and related content are deemed unsuitable. However, for a clearer exposition of the algorithms utilized, additional references can be consulted for further elucidation [27].

In a distributed simulation setup, a PC serves as the master running servers and orchestrates the execution of vehicle models in MATLAB/Simulink. Two types of vehicles are configured: a pure electric vehicle (EV) and a plug-in hybrid with continuously electronically variable transmission (ECVT).

Firstly, for each vehicle, in accordance with the single-vehicle platform design outlined in Section 4.1, it is imperative to ascertain the components utilized in the vehicle, including but not limited to the engine, motor, and battery. Subsequently, a modular approach is adopted to select each component model, initialization script, and postprocessing script, such as the engine fuel consumption map and battery capacity. These components are then interconnected mechanically or electrically based on the vehicle configuration, adhering to the connection rules delineated in Section 4.2. In Section 4.3, a comprehensive summary of all scripts and models involved in the entirety of the vehicle is presented, followed by a meticulous verification of their rationality and effectiveness. Leveraging automated program splicing techniques, a comprehensive vehicle simulation model encompassing the model parameters is meticulously assembled within the MATLAB environment. This marks the attainment of a standalone simulation project capable of computing the vehicle performance metrics.

Subsequently, to facilitate multi-vehicle interaction, the multi-vehicle data transfer methodology outlined in Section 5.1 is employed to define the input and output interfaces for each vehicle, enabling communication with the surrounding environment. This entails sharing the speed and driving position data to formulate a communication matrix. Following this, the data transfer implementation methodology detailed in Section 5.2 is applied, wherein the communication matrix is documented in the address allocation file. This file is then inputted into the scheduler, streamlining communication and information exchange among vehicles. Finally, the simulation architecture of the entire vehicle performance simulation platform with multi-vehicle interaction is completed. The simulation architecture is depicted in Figure 17.

The SUMO 5.16 model comprises a road network file (net.xml) and a demand file (rou.xml). The road network file encompasses road modeling and signal light settings, while the demand file establishes vehicle and traffic flow models. Road network file editing methods include XML language editing, SUMO’s Netedit software for drawing, and Netconvert for road network identification and conversion [28]. Each method has its advantages and disadvantages, so this study integrates all three methods for modeling. Initially, Netconvert is used to read the OpenStreetMap road network of the target scene and convert it into .net.XML format. Then, Netedit simplifies the process by removing irrelevant road network elements and setting parameters such as signal light phases and speed limits. Finally, the road network file is further edited and enhanced using XML language [29].

The M language interface program utilizes Traci library functions to facilitate information interaction between SUMO and MATLAB [30]. The program first executes the Traci library function import command and initializes the Traci port based on the SUMO port. This enables access to the vehicle ID, speed, location, and other Traci library functions. Additionally, the program utilizes Traci library functions to set the vehicle speed, enabling feedback from the MATLAB model to the SUMO simulation scene.

In exploring the energy-saving control strategy of plug-in hybrid logistics vehicles, the optimization effect varies under different signal light phase settings, signal light intersection distances, or vehicle speed conditions. The speed planning algorithm, based on the Krauss car-following model [31], is simulated and verified. The resulting trajectories and speeds of both the Krauss and Model Predictive Control (MPC) following vehicles [32] are illustrated in Figure 18 and Figure 19, respectively. Notably, the plug-in hybrid ECVT demonstrates the ability to navigate each signal intersection effectively while also achieving a superior tracking performance relative to the pure electric vehicle (EV).

The simulation results of the economic speed planning system based on the networked information and the speed planning system based on the Krauss following model are compared and analyzed. The results are shown in Table 7.

From the results presented in Table 7, it is evident that compared to the Krauss following vehicle, the MPC-optimized vehicle experiences an increase in travel time. However, this is offset by the optimized comfort and economy of the vehicle. By leveraging signal light phase information along the vehicle’s driving path, the reference time at each intersection is reasonably planned, thereby reducing the number of vehicle stops and minimizing the acceleration and deceleration conditions.

In summary, both the EV and CEVT vehicles successfully complete the initialization script running, model construction, and information sharing between vehicles. They achieve collaborative following control seamlessly. The entire process operates as an automated scheduling process, facilitating mutual collaboration and communication among each vehicle. Utilizing the simulation technology platform proposed in this paper, in conjunction with the modular design principle and a flexible calculation method, enables the rapid construction of new energy vehicles featuring various hybrid drivetrains. During the early stages of product development, high-volume automated simulations facilitate powertrain matching and performance analysis, obviating the need for a manual configuration setup, parameter adjustments, and scenario replacements. This approach effectively eliminates time wastage, thereby swiftly reducing the costs associated with new product development, shortening development cycles, and enhancing overall work efficiency. By addressing the challenges of low modeling efficiency and the intricate integration of multiple models encountered in current simulation practices, this platform offers efficient technical support for the design and development of automotive simulation systems.

[ad_2]