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

Abstract

With the electrification and connectivity of vehicles in transportation, traditional vehicles with single drivetrains are being replaced by pure electric or hybrid electric vehicles (HEVs). This evolution has given rise to diverse electromechanical coupling drivetrains. There is a pressing need to update simulation software to assess the economic performance of vehicles in various environments, and promote sustainable development and energy conservation. This paper presents a unified framework for the construction and automated operation of large-scale automated vehicle simulations with multiple drivetrain types, facilitating synchronous information exchange among vehicles. Central to the framework is the development of a plug-and-play vehicle model based on a modular component design, facilitating the rapid assembly of vehicles with varied drivetrain configurations and standardizing simulation file management. Additionally, a standardized simulation process construction is established to accommodate the automated operation of simulations. Furthermore, a data scheduling method among vehicles is introduced to achieve multi-vehicle interconnection simulation. Finally, the effectiveness of the framework is demonstrated through a case study involving queue-following control for HEVs. This framework aims to provide a comprehensive solution for quickly establishing automated simulation environments for multi-vehicle interaction, enhancing model reusability and scalability.

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.

3. System Framework Design

In this study, we propose a framework for a multiple vehicle interaction simulation system, as shown in Figure 2, involving two primary functions. Firstly, it requires the flexible construction of vehicle configurations. To facilitate the diversification of vehicle configurations, all vehicle models are assembled from various components based on a modular design approach. For instance, a pure electric vehicle model consists of modules such as a battery, motor, and wheel. All modules are model-based and built using Simulink, falling into three categories: electrical, hydraulic, and mechanical. These modules are interconnected according to their properties to create a variety of vehicle models. Each vehicle is equipped with signal input and output modules to facilitate the transmission of signals, with the signal bus organized on a per-vehicle basis and aggregated to interact with the external environment. To realize these functions, a modeling environment and a customized interactive simulation environment are necessary, along with data scheduling from external applications to manage the input and output data of the large-scale vehicle simulation system.

To avoid duplicating module parameters and signal names across multiple vehicles, each vehicle model operates within a separate MATLAB/Simulink 2022 session, with simulation parameters initialized in the MATLAB workspace using M scripts. The scheduling of the input and output signals for all vehicle models is essential. The data scheduler, implemented in C language and based on shared memory technology within the Visual Studio (VS) environment, collects the output signals from each vehicle model in multiple MATLAB session environments, interacting with external software, and inputting the signals to each vehicle model. When the simulation ends and starts, Simulink’s start callback function and end callback function are utilized to set the shared memory flag. The necessary points in the frame construction process are summarized as follows:

(1)

The internal signal connection of the model. MATLAB scripts are used to control the automated wiring and splicing of the modules by using the same names of the input signals and output signals of other modules as the principle of interconnection.

(2)

The extraction of module parameters. The component comprises the parameter scripts and Simulink models, where the parameter scripts can provide the Simulink models with the required parameters. The parameter scripts, essentially text files, are accessed using regular expressions to identify agreed assignment expressions. Strings positioned to the left and right of the equals sign are designated as the names of the output and input parameters, respectively. Model parameters are essentially strings and can be retrieved via the get parameters command provided by MATLAB. These parameters can then be filtered based on specific parameter naming conventions.

(3)

The model input and output signal records. Using a specific naming approach to the vehicle needs to interact with the external input and output signal interface naming, and based on this through the script to identify and statistics, and then the signal name and serial number written to the XML file, for the subsequent generation and configuration of signaling interfaces between the vehicle modules.

(4)

Shared memory signaling interface module generation, including the Simulink model and VS data scheduling interaction interface. For the Simulink model, the shared memory function provided by the Windows system is used to write the C file and compile the Mex file, and then the level-2 S function is used as the data interaction module to read and write the signals. The Simulink automated modeling approach is used, and scripts are used to control each input and output interface in Simulink to connect with the interaction module, and to automate the configuration of the corresponding signal interface name and shared memory address. For VS data scheduling, the XML file is parsed and shared memory addresses are assigned to each signal, similar to Simulink, and the shared memory functions provided by Windows are used to associate the input and output data mappings together.

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. Component interface properties.

Component	Interface Number	Input Signal Physical Characteristics	Output Signal Physical Characteristics	Interface Effort Signal Direction
Gearbox, clutch, final drive, mechanical accessories, torque coupling	1	Torque	Rotational speed	Input
	2	Rotational speed	Torque	Output
Transfer	1	Torque	Rotational speed	Input
	2, 3	Rotational speed	Torque	Output
Planetary	1, 2, 3	Torque	Rotational speed	Input
	4	Rotational speed	Torque	Output
Electrical accessories, power converter	1	Voltage	Current	Input
	2	Current	Voltage	Output
Wheel	1	Torque	Rotational speed	Input
	2	Vehicle speed	Force	Output
Vehicle body	1	Force	Vehicle speed	Input

, 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. Auxiliary modeling components interface.

Component	Interface Number	Input Signal Physical Characteristics	Output Signal Physical Characteristics	Interface Attributes
Moment superposition	1	Torque	Rotational speed	Input
	2	Rotational speed	Torque	Output
Force superposition	1	Force	Vehicle speed	Input
	2	Vehicle speed	Force	Output
Voltage distribution	1	Voltage	Current	Input
	2	Current	Voltage	Output

.

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. File attributes that need to be described.

Types	Attributes
Initialization script	OP
Preprocessing script	IP, OP
Postprocessing script	IP, OP, IS, OS
Model	IP, IS, OS

.

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.

• Preprocessing script parameter integrity check
  • Catalog the OPs of all initialization files.
  • Distinguish between preprocessing scripts that require input parameters (IPs) and those that do not require IPs and catalog the OPs of preprocessing scripts that do not require IPs.
  • Collect all the cataloged OPs and save them in an OPs collector.
  • Obtain the script sets that require IPs and determine the number of scripts in each set, then proceed with the following process as depicted in Figure 9.

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. Calculation requirements and performance index.

Performance Index	Calculation Type	Configuration
Economy	Distance-based cycle	Driving range, SOC balance correction, cold start, number of repeated cycles, curb weight added, …
	Map-based cycle
	Time-based cycle
	Steady state (constant speed)
Acceleration	Acceleration time between speed	Whether to enable performance mode, shift time optimization, …
	Acceleration distance between time
	Acceleration speed difference between time
Gradeability	Maximum gradeability	Maximum number of iterations, tolerance value, curb weight added, …
Drivability	Drive away	Simulation termination condition setting, curb weight added, …
	Acceleration
	Tip in
	Tip out
	Deceleration
Other performance	…	…

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. Calculation mode.

Calculation Mode	Description
Change parameters	Multi-parameter study combination collection, such as sensitivity analysis
Replace the initialization script	Modify parameters in batches by script
Replace model	Replace models with different modeling techniques, such as empirical models and theoretical formula models
Batch processing	Simultaneous calculation of multiple vehicles

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.

5. Multiple Vehicles Platform

After constructing individual vehicles, they are connected in series through a data interface on a multiple vehicle construction platform. Given that each vehicle model, data scheduler, and traffic software operate as independent simulation systems, variations in the simulation time, step size, solver, etc., may occur. This necessitates the design of data synchronization and event notification mechanisms. Moreover, the data scheduler requires access to the start and end times of each vehicle model. The architecture of the multiple vehicle platform design is illustrated in Figure 12. To enable the efficient exchange of interaction information among vehicles, data are recorded in an interaction information XML file, specifying the input and output signals required for each vehicle. Facilitating this information exchange requires the implementation of three key functional modules. Firstly, the data synchronization scheduling control module manages the timing and coordination of the data exchange, ensuring synchronization across different simulation systems. Secondly, the shared memory address allocation module allocates memory addresses for shared data storage, enabling effective communication between vehicles. Lastly, the shared memory interface module generation component generates interfaces for accessing shared memory, facilitating seamless reading, and writing of data during simulation. Together, these modules support the smooth interaction and information exchange among vehicles within the simulation environment.

5.1. Data Synchronization Scheduling Control

During simulation, each vehicle model’s start and end are marked using Simulink’s callback functions, setting shared memory flags. Additionally, providing feedback prompts throughout the simulation, including progress details, messages, and changes in input and output signals, is crucial.

In the joint simulation setup, ensuring data synchronization, task scheduling, and timing control between Simulink and VS programs is paramount. At simulation initiation, Simulink writes a shared memory startup flag, with the VS program commencing its simulation routine upon flag reading. The simulation concludes upon reading the end flag. Throughout the simulation, Simulink serves as both writer and reader, necessitating a wait for the VS program’s write and read status, as depicted in Figure 13. If VS has not read or written the latest data, Simulink enters a wait state to prevent redundant operations. Similarly, VS waits for Simulink to write or read, ensuring complete timing synchronization. To control the data interaction as per temporal logic, read and write wait flags coordinate the data exchange. This includes writing data, setting task labels, and reading data. When identifiers are invalid, Simulink waits for the VS program to set the identifier, entering sleep mode if necessary. Implementing this control prevents Simulink from looping too rapidly, preventing freezing.

To ensure effective interaction with Simulink, the VS program employs a similar read and write logic, enabling access to data and facilitating VS interaction data, as depicted in Figure 14. Initially, the VS program verifies the model’s running status, exiting if the model is not active. Based on task scheduling signals transmitted by Simulink, the VS program schedules tasks with varying cycles. This ensures that tasks are executed in a coordinated manner, aligning with the simulation progress. Furthermore, read and write wait flags coordinate the task progress between Simulink and the VS program, ensuring the synchronization of the simulation timing. By adhering to these wait flags, both programs can interact seamlessly, facilitating efficient joint simulation.

5.2. Shared Memory Address Allocation and Interface Module Generation

To enhance the versatility of the data scheduler and accommodate varying numbers of vehicles and signals per vehicle, Simulink’s input and output interfaces are dynamically obtained and recorded in XML files through an M script. Efficient data transmission is facilitated by specifying the input and output directions, names, and associated variables in XML. These files streamline the creation of interactive interface modules for Simulink using automated modeling tools, as depicted in Figure 15. Given the real-time nature of the signal output during Simulink simulation and the imperative to swiftly transfer semaphore data to the control center, shared memory data transfer is employed. A C language parsing program parses XML files from each vehicle model, allocating shared memory spaces and addresses for signal exchange. Additionally, process control monitors shared memory flags to manage the foreground input control during each step of execution.

The structured overview in

Table 6. Vehicle communication matrix.

Vehicle ID	Interactive Signal Set	Shared Memory Address	Synchronization Flags	Data Exchange Addresses
Vehicle 1	Signal Set 1	Memory Address 1	Sync Flag 1	Data Address 1
Vehicle 2	Signal Set 2	Memory Address 2	Sync Flag 2	Data Address 2
Vehicle 3	Signal Set 3	Memory Address 3	Sync Flag 3	Data Address 3
...	...	...	...	...

presents the essential communication parameters for each vehicle within the network. This includes vehicle IDs, descriptions of interactive signal sets, shared memory addresses for data exchange, synchronization flags for timing coordination, and data exchange addresses within the shared memory. This comprehensive matrix forms the basis for a synchronized multi-vehicle communication scheduling method, facilitating seamless interaction via the coordinated utilization of shared memory, synchronization flags, and data exchange addresses.

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 \underset{u}{\min }J={\displaystyle {\int }_k^{k+N_p}[w_1{f}_{tq}(u(t))+w_2{f}_{time}(x(t))+w_3{f}_{com}(x(t))]}dt\\ s.t.\{\begin{array}{l}d(t)\le d_{pre}(t)-g_{\min \_safe}\\ v_{\min \_i}\le v(t)\le v_{\max \_i}\\ T_{\min \_tq}\le T_{tq}(t)\le T_{\max \_tq}\\ T_{\min \_b}\le T_{tq}(t)\le T_{\max \_b}\end{array}\end{array}$$

(1)

where $J$ is the total cost function, and $f_{tq}$, $f_{time}$, and $f_{com}$ 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. $dt$ 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_{pre}$ and $g_{\min \_safe}$ 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_{tq}$ is the driving torque. $T_{\max \_tq}$ and $T_{\min \_tq}$ 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. Simulation results of vehicle speed planning system.

	Krauss	MPC	Optimize Proportion
Travel time (s)	1710	1712	−0.2%
Number of stops (times)	15	6	65.2%
Maximum acceleration (m/s2)	1.26	0.98	12.5%
Minimum acceleration (m/s2)	−1.65	−1.93	25.4%
Energy required at wheel (kJ)	19,505.40	14,972.90	23.2%
Electricity consumption per 100 km (kWh/100 km)	9.47	8.80	9.5%
Fuel consumption per 100 km (L/100 km)	6.73	5.53	16.8%

.

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.

7. Conclusions and Future Work

This study introduces a comprehensive framework for large-scale vehicle performance simulation, to facilitate multi-vehicle collaborative control strategies design across multi-vehicle systems with diverse configurations. The modularization-based framework facilitates the rapid and efficient assembly of various electric vehicle configurations, automating the initialization and postprocessing of scripts by analyzing signals and parameter dependencies among vehicle models and data files. A communication matrix table is constructed based on the interactive signal set for each vehicle, enabling the development of a multi-vehicle communication scheduling method that ensures synchronous interaction among vehicles through shared memory, synchronization flags, and data exchange addresses. The framework supports automatic verification and simulation file management, allowing for the modular expansion of component models, parameter scripts, and the simulation process. Consequently, a scalable and customizable architecture for multiple vehicle automation performance simulation is achieved. This framework empowers the assessment of vehicle performance simulations for both individual vehicles and vehicle fleets within a simulated traffic environment, facilitating the collaborative optimization of control algorithms. However, current simulation test environments face limitations due to their non-real-time nature and dependency on a single hardware platform. Future work will focus on the development of a real driver-in-the-loop, multi-vehicle, distributed real-time operating environment to simulate a mixed traffic scenario, involving multiple drivers across diverse vehicle models.