A global parameter configuration method based on parallel discrete event multi-process simulation

Abstract

This invention proposes a global parameter configuration method based on parallel discrete event multi-process simulation. This method achieves bidirectional handshake interaction between the host configuration software and the simulation platform software through a Socket transmission interface, mutually verifying the initialization status and automatically restarting the corresponding software initialization process in case of initialization errors. The simulation platform software aggregates all process local parameters and reports them to the host configuration software, which then generates a unified format global parameter file. After the simulation platform software sends a distribution request, the host configuration software distributes the global parameter files sequentially according to the process number. The simulation platform software collects the file reception identifier and process parameter configuration identifier of each process for hierarchical judgment, distinguishing between file reception failure and parameter configuration abnormality, and performs targeted retries for repair. After all processes pass verification, the parallel discrete event multi-process simulation is started. This invention solves the problems of complex global parameter configuration, difficult synchronization, and cumbersome fault handling in existing parallel simulations.

Description

Technical Field

[0001] This invention belongs to the field of multi-process digital simulation, specifically involving a global parameter configuration method for multi-process simulation based on parallel discrete events. Background Technology

[0002] Discrete Event Simulation (DES) is a method for modeling systems where state changes occur at discrete points in time, triggered by events. Due to its efficiency and flexibility, DES has become the mainstream simulation technique for analyzing and optimizing complex systems such as communication networks, traffic flow, manufacturing systems, and computer architectures.

[0003] As the complexity and fidelity of simulation models continue to increase, and the demand for simulating larger-scale systems grows, traditional single-process discrete event simulation has encountered bottlenecks in terms of computational power and simulation efficiency.

[0004] Currently, most simulation platforms and applications still rely on single-process simulation. In this mode, all simulation events are placed in a global event queue and executed sequentially by a central processing unit. This method is logically simple, easy to implement and debug, but it has inherent limitations, the most significant of which are as follows: 1. Computing resources are concentrated, making it impossible to utilize the powerful computing capabilities of multi-core CPUs or distributed computing clusters; 2. Performance bottlenecks are obvious. As the model size increases, event queue management and state updates will become performance bottlenecks, resulting in excessively long simulation times. 3. Memory limitations are prominent. The entire model state resides in the memory of a single process, and the simulation scale is limited by the memory capacity of a single machine.

[0005] To address the shortcomings of single-process simulation, Parallel Discrete Event Simulation (PDES) has emerged. The core idea of ​​PDES is to decompose the simulation model into multiple logical processes (LPs). Each LP is responsible for simulating a part of the system and is distributed across different physical computing nodes or CPU cores for concurrent execution. The main purpose is to distribute computing resources, allocating the computational load across multiple processing units to fully utilize the hardware capabilities of modern multi-core / many-core processors and computing clusters; shorten process waiting time; and alleviate single-event queue congestion by concurrently processing events on different LPs, thus accelerating the simulation process.

[0006] Compared with single-process simulation, multi-process simulation exhibits the following significant advantages: High utilization of computing resources. It can evenly distribute computing tasks across multiple CPU cores or computing nodes, avoiding situations where a single core is fully loaded while other cores are idle, thus significantly improving overall computing efficiency; Large-scale simulation capabilities. By distributing model states across the memory of multiple processes, the limitations of single-machine memory are overcome, making it possible to simulate ultra-large-scale systems (such as global communication networks and mega-city transportation). Excellent speedup. For suitable simulation problems, PDES can achieve a near-linear speedup, meaning that with N processing cores, the simulation time can be reduced to nearly 1 / N, greatly improving R&D and decision-making efficiency.

[0007] At the same time, migrating simulation from a single-process to a multi-process architecture also introduces unprecedented complexity, and the main technical challenges include: (1) The global parameter configuration process is complex. In single-process simulations, all parameters can be managed centrally in a single configuration file. However, in a multi-process environment, each process may require different initialization parameters, while maintaining global consistency (such as total simulation duration and random number seed). Parameter distribution, synchronization, and verification become exceptionally complex and error-prone.

[0008] (2) Difficulty in inter-process synchronization This is the core challenge of PDES. Because each LP executes concurrently, the causal correctness of the simulation results must be guaranteed; that is, the order of event processing must conform to the logical temporal sequence (timestamp order). If LP-A sends a message with a future timestamp to LP-B, LP-B must wait for its local simulation time to advance to that time before processing the message. Designing efficient, low-overhead synchronization algorithms (such as the Conservative Approach or the Optimistic Approach) is a key focus of PDES research.

[0009] (3) Inter-process communication mechanism Multi-process simulation heavily relies on inter-process communication (IPC). The latency and bandwidth of communication directly determine the overall performance of parallel simulation. It is necessary to select appropriate communication protocols (such as MPI, gRPC, ZeroMQ, etc.) and serialization schemes, and optimize communication patterns to reduce the overhead caused by message passing.

[0010] (4) Currently only applicable to static topology Many current PDES systems and algorithms are based on a key assumption: the interaction relationships (i.e., topology) between logical processes in the simulation model are fixed and known before the simulation runs. This greatly limits their application scope. For dynamic topology systems (such as Mobile Ad Hoc Networks (MANETs), dynamic service discovery, and variable supply chains), the connection relationships between components change dynamically during the simulation process, which existing PDES frameworks often struggle to support effectively, increasing implementation complexity and runtime overhead.

[0011] In summary, parallel discrete event simulation is an inevitable trend to address the ever-increasing scale and complexity of simulations. By distributing computing resources, it promises to significantly improve simulation efficiency and overcome scale limitations. However, from theory to mature engineering practice, a series of severe challenges remain, including complex configuration, synchronization difficulties, communication overhead, and dynamic topology support. Overcoming these challenges will enable parallel discrete event simulation technology to unleash its enormous potential in a wider range of fields, becoming a key supporting technology for cutting-edge applications such as digital twins and complex system decision-making.

[0012] This patent addresses the decomposition and optimization of the global parameter configuration process in multi-process simulation of parallel discrete events. Summary of the Invention

[0013] To address the problems of complex global parameter configuration, high parameter distribution synchronization overhead, cumbersome multi-process parameter consistency verification, lack of hierarchical retry mechanism for configuration failures, and chaotic interaction logic between the host computer and simulation platform software in existing parallel discrete event multi-process simulations, this invention proposes a global parameter configuration method based on parallel discrete event multi-process simulation. The method achieves unified configuration of global parameters for multiple processes through interaction between the host configuration software and the simulation platform software. The host configuration software receives, collects, and integrates the local parameters of each process in the simulation platform software to form the global parameters for discrete event multi-process simulation, and then distributes them one by one.

[0014] The technical solution of this invention: a global parameter configuration method based on parallel discrete event multi-process simulation, comprising the following steps: S1: The host configuration software performs initialization operations and reads its own initialization file. S2: The simulation platform software performs initialization operations and reads its own initialization file. S3: After the host configuration software completes initialization, it sends a configuration software initialization status message to the simulation platform software. The configuration software initialization status message contains a boolean type initialization status identifier, where 0 represents incomplete initialization and 1 represents complete initialization. S4: After the simulation platform software completes its own and all process initialization, it sends a platform initialization status message to the superior configuration software. S5: The host configuration software parses the platform initialization status message described in step S4, and the simulation platform software parses the configuration software initialization status message described in step S3. The host configuration software and the simulation platform software reply to each other with a confirmation message or a message to re-execute initialization based on their respective parsing results. Specifically, if the platform initialization status message parsed by the host configuration software indicates that the initialization is complete, a confirmation message is sent to the simulation platform software; if the platform initialization status indicates that the initialization is incomplete, a message indicating that the initialization needs to be continued is sent to the simulation platform software, and the simulation platform software re-executes the initialization process. If the configuration software initialization status message parsed by the simulation platform software is "completed", it replies with a confirmation message to the upper-level configuration software. If the initialization status of the upper-level configuration software is "incomplete", it sends a message to the upper-level configuration software that needs to continue initialization, and the upper-level configuration software re-executes the initialization process. S6: After receiving the confirmation message from the host configuration software, the simulation platform software reports the local parameters of each process to the host configuration software in sequence according to the program number; after the local parameters of each process have been reported, the simulation platform software sends a local parameter reporting status message to the host configuration software; the local parameter reporting status message contains a Boolean reporting completion flag, where 0 represents incomplete reporting and 1 represents complete reporting. S7: The host configuration software parses the local parameter reporting status message: If the reporting is completed (i.e., the reporting completion flag is 1), it gathers all process local parameters according to the preset standardized global parameter file template format and generates a global parameter file in a unified format, and then sends a global parameter preparation status message to the simulation platform software; if the reporting is not completed (i.e., the reporting completion flag is 0), it requests the simulation platform software to send the local parameters of the missing process, and repeats the local parameter gathering operation when the reporting is completed (i.e., the reporting completion flag changes from 0 to 1); S8: After receiving the global parameter preparation status message, the simulation platform software sends a global parameter file distribution request message to the superior configuration software. The distribution request message is of boolean type, with 0 representing that distribution will not be carried out for the time being and 1 representing that distribution is requested. S9: The host configuration software parses the request message: If the message is a request to send (i.e., the request message identifier is 1), the global parameter file is sent to each process of the simulation platform software in sequence according to the program number; if the message is not to send (i.e., the request message identifier is 0), the global parameter file sending process is paused. S10: After receiving the global parameter file, the simulation platform software collects the process preparation status messages reported by each process, including the total number of processes, whether the global parameter file was successfully received or not, and whether the process parameter configuration is complete or incomplete. The global parameter file reception identifier for each process is a Boolean type, where 0 represents that the file was not successfully received and 1 represents that the file was successfully received, indicating the integrity of the file at the transport layer. The process parameter configuration identifier is a Boolean type, where 0 represents that the parameter configuration is not complete and 1 represents that the parameter configuration is complete, indicating the correctness of the application layer parameter configuration. S11: The simulation platform software performs a judgment and processing based on the readiness status messages of all processes. (1) If the global parameter files for all processes are successfully received and the process parameters are configured (i.e., the global parameter file reception identifier and the process parameter configuration identifier are both 1), the simulation platform software sends a global parameter configuration completion message to the upper-level configuration software and starts the parallel discrete event multi-process simulation. (2) If the global parameter files for all processes are successfully received, but some process parameters are not configured (i.e., the global parameter file reception flag is 1 and some process parameter configuration flag is 0), the simulation platform software locates the process that has not been configured, corrects the corresponding process parameter configuration items for that process, and then reissues the global parameter file. Other processes that have been configured successfully are not affected until all process parameters are configured (i.e., all process parameter configuration flags are 1). (3) If the global parameter file corresponding to a process fails to be received (i.e., the global parameter file reception identifier is 0), the simulation platform software queries the program number and resends the global parameter file of the corresponding process until the global parameter files corresponding to all processes are successfully received and the process parameters are configured (i.e., the global parameter file reception identifier and the process parameter configuration identifier are both 1).

[0015] In step S1, the initialization file of the upper-level configuration software is read through the Socket transmission interface. The configuration content of the Socket transmission interface includes the local address, remote address, local port number, remote port number, and transmission protocol TCP / UDP.

[0016] In step S2, the simulation platform software's own initialization file is read via the Socket transmission interface. This file includes the total number of processes N, the number of nodes in a single process M, and the initialization structure parameters for each node. These node initialization structure parameters include frequency, bandwidth, speed, and transmit power. Based on these initialization parameters, the simulation platform software completes the initialization of all N processes and the M nodes within each process.

[0017] In step S2, the node initialization parameters are of type Struct, and the frequency, bandwidth, rate, and transmit power are all of type float.

[0018] In step S4, the platform initialization status message includes a boolean type initialization status, the total number of processes N, the number of nodes per process M, the starting IP address of each process node, and a network mask. The starting IP address of each node is the IP address of the first node of each process. The simulation platform software generates all the node IP addresses in the current process based on this starting address and the network mask. The simulation platform software automatically generates all the node IP addresses in the current process in batches based on this starting address and the network mask, without the need for manual configuration of IP addresses for each node.

[0019] In step S7, the global parameter file contains the total number of partitions of type UINT8 (totPartitionNum), the total number of nodes of type UINT16 (totNodeNum), and the UINT8 partition ID and all node information within each partition. The single node information contains the UINT16 node ID and a node parameter array, which includes the platform name (platName), device name (equipName), carrier frequency (carrierFreq), bandwidth (bandwidth), transmission rate (rate), transmit power (transPower), and node IP address.

[0020] In step S10, the field for the total number of processes is of type UINT8, and its value range is 1 to 128.

[0021] The beneficial effects of this invention are: 1. Layered handshake interaction, bidirectional verification of initialization status, and early prevention of initialization anomalies: This invention designs a bidirectional status reporting and confirmation handshake mechanism between the upper-level configuration software and the simulation platform software. If initialization is incomplete on either side, a re-initialization process can be automatically triggered without manual intervention. The validity of initialization at both ends is verified before parameter distribution, avoiding parameter errors and process crashes caused by initialization failure at one end directly entering the parameter distribution process, significantly reducing the probability of failures in the pre-simulation configuration stage. Compared to the serial dependency mode in single-process simulation where initialization failure at any end leads to overall collapse, this solution advances fault detection and prevention to the configuration handshake stage, preventing the propagation of initialization anomalies to the parameter distribution process.

[0022] 2. Standardized aggregation of local parameters to generate a global file ensures global consistency of parameters across multiple processes: Existing solutions allow each process to load its local configuration independently, which can easily lead to inconsistent parameter versions and global statistical information. This invention aggregates all process local parameters through the simulation platform software and uploads them to the host configuration software. The host configuration software then centrally integrates and generates a unique standard format global parameter file. All processes share the same global configuration, eliminating differences in parameters across multiple processes at the data source level and ensuring uniformity of global constraints such as global simulation duration, random seed, and node communication parameters in parallel simulation.

[0023] 3. Layered dual-identifier verification + tiered automatic retry: Automated fault repair reduces manual intervention. Two verification dimensions—file reception identifier and parameter configuration identifier—are set up to distinguish between "file transfer failure" and "parameter parsing and configuration failure." Differentiated retry strategies are adopted for different fault types: if a file is lost, the corresponding process file is retransmitted separately; if parameter parsing errors occur, the configuration items are corrected and retransmitted, eliminating the need to retransmit the configuration for all processes, reducing the amount of duplicate data transmission and shortening fault repair time. Taking a process scale of N=128 processes as an example, the traditional full retransmission scheme requires retransmitting all 128 global parameter files and reconfiguring all processes, with the time increasing linearly with the total number of processes. This scheme only needs to retransmit the file of a single failed process, reducing the amount of duplicate data transmission by approximately 99% in a single-process failure scenario (only 1 / 128 are retransmitted), and the 127 successfully configured processes are unaffected.

[0024] 4. Reduced Overall Configuration Time: Adopting an ordered transmission scheme that distributes global parameter files sequentially based on program entry number avoids Socket link congestion and packet loss caused by multiple processes concurrently requesting files. Simultaneously, by centrally aggregating local parameters and generating a global file at once, it replaces the traditional process-by-process interaction and distributed parameter mode, significantly reducing the total time spent on cross-process configuration distribution and improving inter-process synchronization efficiency. Compared to schemes where multiple processes concurrently request the same global file, this ordered distribution mode can avoid over 80% of packet loss and retransmission events caused by concurrent TCP connections competing for bandwidth when Socket link bandwidth is limited (e.g., 100Mbps LAN), ensuring the determinism and stability of file transmission.

[0025] 5. Standardized parameter structures and message field definitions, highly versatile and easily extensible: Unified definition of node parameter floating-point structures, boolean identifiers for various interactive messages, UINT8 limit for the number of processes, and fixed field format for global parameter files, adapting to parallel simulation scenarios with 1 to 128 processes; unified configuration fields for communication socket interfaces, supporting flexible switching between TCP / UDP, adaptable to various hardware deployment environments including single-machine multi-core and distributed clusters, facilitating portability to various discrete event simulation services such as communication networks, traffic simulation, and manufacturing systems. The standardized parameter structure definition allows for migration between different simulation scenarios by simply replacing the node parameter array content without modifying the message interaction protocol and configuration process code, achieving decoupling of business logic and the configuration framework.

[0026] 6. Decoupling of communication links and clear boundaries between upper and lower level software reduce development and debugging difficulty: The configuration operation is split into two independent modules: upper-level configuration software (parameter aggregation, file generation, and distribution) and simulation platform software (process management, local parameter reporting, status verification, and simulation driving). The interaction is completed through standardized Socket messages, and the logic between modules is decoupled. During development and debugging, the functions of the upper-level configuration or simulation platform can be tested separately, making it more efficient to locate configuration process problems and reducing the overall development and maintenance cost of the parallel simulation system.

[0027] 7. Supports large-scale parallel simulation and breaks through the bottleneck of single-machine memory and configuration efficiency: This solution is adapted to multi-process distributed architecture, with parameters stored in the memory of each process, and is not limited by the memory capacity of a single machine; the layered verification combined with the targeted retry mechanism can still stably complete the global parameter configuration at the scale of hundreds of processes, and support the implementation of parallel discrete event simulation of complex systems such as ultra-large-scale communication networks and military training. Attached Figure Description

[0028] Figure 1 This is a schematic diagram of the process of this invention; Figure 2 This is a block diagram of the modules of the present invention. Detailed Implementation

[0029] In this embodiment, the total number of processes N=2 and the number of nodes per process M=3 are set. The complete configuration process of this invention is executed as follows: 1. The host configuration software completes software initialization. The host configuration software reads its own initialization file, completes the configuration of the Socket transmission interface, selects TCP as the communication protocol, sets the local address to 192.168.1.91, and configures the local port number to 8080. This Socket interface is used to establish a data interaction channel with the simulation platform software.

[0030] 2. The simulation platform software completes software initialization and initializes each process according to the software initialization requirements. The simulation platform software reads the local initialization file and obtains the total number of processes N=2 and the number of single process nodes M=3. At the same time, it completes its own Socket interface configuration, with the transmission protocol being TCP, the local address being 192.168.1.88, the remote address pointing to the upper configuration software address 192.168.1.91, and the remote port number matching the upper configuration software port 8080.

[0031] The simulation platform software then starts processes 1 and 2, loading initialization parameters in Struct format onto the three nodes within each process one by one. The parameters, including frequency, bandwidth, speed, and transmit power, are all of type float. Parameters of node 1 under process 1: node ID is 1, frequency is 750MHz, bandwidth is 500kHz, data rate is 1000kbps, and transmit power is 38dBm; Parameters of node 2 under process 1: node ID is 2, frequency is 750MHz, bandwidth is 500kHz, data rate is 1000kbps, and transmit power is 38dBm; Parameters of node 3 under process 1: node ID is 3, frequency is 750MHz, bandwidth is 500kHz, data rate is 1000kbps, and transmit power is 38dBm. Parameters of node 1 under process 2: node ID is 4, frequency is 750MHz, bandwidth is 500kHz, data rate is 1000kbps, and transmit power is 38dBm; Parameters of node 2 under process 2: node ID is 5, frequency is 750MHz, bandwidth is 500kHz, data rate is 1000kbps, and transmit power is 38dBm; Parameters of node 3 under process 2: node ID is 6, frequency is 750MHz, bandwidth is 500kHz, data rate is 1000kbps, and transmit power is 38dBm.

[0032] 3. After completing initialization, the host configuration software sends an initialization status message to the simulation platform software. After the host configuration software has completed its initialization, it sends a boolean initialization status message to the simulation platform software via TCPSocket. The message identifier is 1, which indicates that the host configuration software initialization has been completed.

[0033] 4. After completing initialization of itself and all processes, the simulation platform software sends a platform initialization status message to the host configuration software. This message contains five items: a Boolean initialization status flag (indicating platform initialization is complete), the total number of processes, the number of nodes per process, the starting IP address of each process node (10.0.0.1), and the network mask (255.255.255.0). The simulation platform software automatically generates the complete IP addresses of all nodes within each process based on the starting IP address and the network mask. The specific generation rule is as follows: for process k (k=1,2,...,N), the IP address of its m-th node (m=1,2,...,M) is calculated using the formula: IP... k,m =IPstart k +(m-1), where IPstart k Let be the starting address of the node IP for process k. After determining the subnet range by performing a bitwise AND operation between the starting address and the network mask, node IP addresses are sequentially allocated within the subnet.

[0034] 5. After receiving the platform initialization status message, the host configuration software parses it. If the initialization status of the simulation platform software is "completed", the host configuration software replies with a confirmation message.

[0035] 6. After receiving the initialization status message from the host configuration software, the simulation platform software parses it. If the host configuration software's initialization status is "completed," it replies with a confirmation message to the simulation platform software.

[0036] 7. After receiving the confirmation message from the host configuration software, the simulation platform software sends the process local parameters to the host configuration software in the order of process 1 and process 2, according to the program number.

[0037] 8. After the simulation platform software has sent all the local parameters of all processes, it sends a local parameter reporting status message to the upper-level configuration software. The message is of Boolean type and the value is 1, which means that the local parameter reporting process of all processes has been completed.

[0038] 9. After receiving the local parameter reporting status message, the host configuration software parses it. If the local parameter reporting status is "completed," it aggregates the local parameters reported by each process according to a fixed file format to form a global parameter file and sends a global parameter preparation status message to the simulation platform software. The global parameter preparation status message is marked as 1, indicating to the simulation platform software that the global parameter file is ready. The global parameter file format is shown in Table 1.

[0039] Table 1 Global Parameter File Note: Recommended data types for each field are totPartitionNum (UINT8), totNodeNum (UINT16), Partition ID (UINT8), Node ID (UINT16), platName (STRING), equipName (STRING), carrierFreq (FLOAT), bandwidth (FLOAT), rate (FLOAT), transPower (FLOAT), and Node IP address (STRING). 10. After receiving the global parameter preparation status, the simulation platform software parses it. If the global parameter preparation status is "completed," it sends a global parameter file distribution request to the upper-level configuration software. The request type is Boolean, with a flag of 1, indicating that the simulation platform software is requesting the distribution of the global parameter file.

[0040] 11. After receiving the request to send the global parameter file, the host configuration software parses the request item and sets the status to "request to send". The host configuration software then sends the global parameter file to each process in sequence according to the process number.

[0041] The host configuration software parses and sends the request identifier as 1, and starts the global parameter file sending process. In the order of process 1 and process 2, the complete global parameter file is transferred to the corresponding process of the simulation platform software.

[0042] 12. The simulation platform software collects the process preparation status messages reported by each process. If all processes have successfully received the global parameter file and completed parameter configuration, the simulation platform software sends a global parameter configuration completion message to the superior configuration software and starts the simulation.

[0043] After receiving the global parameter file, each process reports its process readiness status to the simulation platform software. The first field of the message is the total number of processes of type UINT8, which is 2 in this embodiment. Then, it reports two sets of Boolean identifiers for processes 1 and 2 respectively: process 1's global parameter file reception identifier is 1, and its process parameter configuration identifier is 1; process 2's global parameter file reception identifier is 1, and its process parameter configuration identifier is 1. The simulation platform software iterates through all process identifiers, confirms that all processes have completed global parameter file reception and process parameter configuration, sends a global parameter configuration completion message to the upper-level configuration software, and begins the parallel discrete event multi-process simulation.

[0044] Comparative Example: To illustrate the technical advantages of the hierarchical verification and graded retry mechanism of this invention, a comparative scheme without this mechanism is presented. Assuming the same settings of total process count N=2 and number of nodes per process M=3, during the global parameter file distribution process, process 2 fails to receive the file due to a momentary network interruption (file reception identifier = 0). In the traditional full retransmission scheme, the current configuration process of all processes needs to be terminated, and both processes need to re-receive the global parameter file and reconfigure, adding more than double the amount of repeated data transmission and configuration waiting time. However, with the graded retry mechanism of this invention, the simulation platform software only detects that the file reception identifier of process number 2 is 0, and retransmits the global parameter file to process 2 separately. Process 1 is completely unaffected and can directly enter the ready waiting state. In a large-scale simulation scenario with N=128, this difference can result in a configuration time difference of tens of times—traditional full retransmission requires retransmitting 128 files, while this invention only requires retransmitting 1 file, demonstrating the significant engineering advantages of hierarchical verification combined with a targeted retry mechanism in large-scale parallel simulation.

Claims

1. A global parameter configuration method based on parallel discrete event multi-process simulation, characterized in that, Includes the following steps: S1: The host configuration software performs initialization operations and reads its own initialization file. S2: The simulation platform software performs initialization operations and reads its own initialization file. S3: After the host configuration software completes its initialization, it sends a configuration software initialization status message to the simulation platform software. S4: After the simulation platform software completes its own and all process initialization, it sends a platform initialization status message to the superior configuration software. S5: The host configuration software parses the platform initialization status message described in step S4, and the simulation platform software parses the configuration software initialization status message described in step S3. The host configuration software and the simulation platform software reply to each other with a confirmation message or a message to re-execute initialization based on their respective parsing results. S6: After receiving the confirmation message from the host configuration software, the simulation platform software reports the local parameters of each process to the host configuration software in sequence according to the program number; after the local parameters of each process have been reported, the simulation platform software sends a local parameter reporting status message to the host configuration software. S7: The host configuration software parses the local parameter reporting status message: If the reporting is completed, it gathers all process local parameters and generates a global parameter file in a unified format according to the preset standardized global parameter file template format, and then sends a global parameter preparation status message to the simulation platform software; if the reporting is not completed, it requests the simulation platform software to send the local parameters of the missing process, and repeats the local parameter gathering operation when the reporting is completed. S8: After receiving the global parameter preparation status message, the simulation platform software sends a global parameter file distribution request message to the superior configuration software. S9: The host configuration software parses and sends request messages: If the message is a request to send, the global parameter file is sent to each process of the simulation platform in sequence according to the program number; If the message indicates that it will not be sent immediately, then the global parameter file sending process will be paused. S10: After receiving the global parameter file, the simulation platform software collects the process preparation status messages reported by each process, including the total number of processes, whether the global parameter file was successfully received or not, and whether the process parameter configuration is complete or not. S11: The simulation platform software performs a judgment and processing based on the readiness status messages of all processes. (1) If the global parameter files corresponding to all processes are successfully received and the process parameters are configured, the simulation platform software sends a global parameter configuration completion message to the upper-level configuration software and starts the parallel discrete event multi-process simulation. (2) If the global parameter files for all processes are successfully received, but some process parameters are not configured, the simulation platform software locates the processes that are not configured, corrects the corresponding process parameter configuration items for the process, and then reissues the global parameter file for the process until all process parameters are configured. (3) If the global parameter file corresponding to a process fails to be received, the simulation platform software queries the process number and resends the global parameter file to the corresponding process until the global parameter files corresponding to all processes are successfully received and the process parameters are configured.

2. The global parameter configuration method based on parallel discrete event multi-process simulation according to claim 1, characterized in that, In step S1, the initialization file of the upper-level configuration software is read through the Socket transmission interface. The configuration content of the Socket transmission interface includes the local address, remote address, local port number, remote port number, and transmission protocol TCP / UDP.

3. The global parameter configuration method based on parallel discrete event multi-process simulation according to claim 1, characterized in that, In step S2, the simulation platform software's own initialization file is read through the Socket transmission interface, including the total number of processes N, the number of nodes in a single process M, and the initialization structure parameters of each node. The node initialization structure parameters include frequency, bandwidth, speed, and transmit power.

4. The global parameter configuration method based on parallel discrete event multi-process simulation according to claim 3, characterized in that, In step S2, the node initialization parameters are of type Struct, and the frequency, bandwidth, rate, and transmit power are all of type float.

5. The global parameter configuration method based on parallel discrete event multi-process simulation according to claim 1, characterized in that, In step S4, the platform initialization status message includes a boolean type initialization status, the total number of processes N, the number of nodes per process M, the starting IP address of each process node, and the network mask. The starting IP address of each node is the IP address of the first node of each process. The simulation platform software automatically generates all node IP addresses in the current process in batches based on this starting address and the network mask, without the need for manual configuration of IP addresses for each node.

6. The global parameter configuration method based on parallel discrete event multi-process simulation according to claim 1, characterized in that, In step S7, the global parameter file contains the total number of partitions of type UINT8 (totPartitionNum), the total number of nodes of type UINT16 (totNodeNum), and the UINT8 partition ID and all node information within each partition. The single node information contains the UINT16 node ID and a node parameter array, which includes the platform name (platName), device name (equipName), carrier frequency (carrierFreq), bandwidth (bandwidth), transmission rate (rate), transmit power (transPower), and node IP address.

7. The global parameter configuration method based on parallel discrete event multi-process simulation according to claim 1, characterized in that, In step S10, the field for the total number of processes is of type UINT8, and its value range is 1 to 128.

Images