Multi-core simulation method, device and medium based on distributed semi-physical simulation system

Abstract

The present application relates to the field of semi-physical simulation, and in particular to a multi-core simulation method, device, and medium based on a distributed semi-physical simulation system. The method includes: obtaining a number of semi-physical simulation objects in a simulation task; dividing the semi-physical simulation objects into a plurality of associated simulation groups according to the degree of task coupling; binding the semi-physical simulation objects in the same associated simulation group with the simulation core of the same lower computer to obtain a number of pairs of binding simulation relationships; transmitting the simulation instructions generated by the upper computer to the scheduling core, which is used to obtain the sub-simulation instructions of the simulation core in the corresponding lower computer from the simulation instructions based on the binding simulation relationship and send them to the corresponding target simulation core, so that the target simulation core performs simulation operations according to the sub-simulation instructions to obtain simulation results; transmitting a number of simulation results obtained by the lower computer to the upper computer to update the simulation instructions, ensure the continuous advancement of the simulation process, and improve the practicality of the semi-physical simulation system.

Description

Technical Field

[0001] The present application relates to the field of semi-physical simulation, and in particular to a multi-core simulation method, device and medium based on a distributed semi-physical simulation system. Background Art

[0002] With the development of modern industry and technology, system complexity continues to increase, placing higher demands on testing and verification. Traditional purely digital simulations cannot fully simulate the characteristics of actual physical systems, while full physical testing is costly and risky. Against this backdrop, hardware-in-the-loop (HiL) simulation has emerged as a technology that combines the advantages of both.

[0003] Hardware-in-the-loop (HIL) is a real-time simulation technology that integrates real hardware into a simulated environment to test control system behavior. This technology not only provides a test environment that closely resembles actual conditions but also reduces development costs and time while ensuring safety. 1 HiL technology is widely used in fields such as aerospace, automotive engineering, and power electronics, becoming an integral part of the R&D process.

[0004] For example, the invention patent application with publication number CN110543105A discloses a universal semi-physical simulation system consisting of a simulation management computer, a real-time simulator, an adapter box, an integrated control box, wiring terminals, and Ethernet. This universal semi-physical simulation system has been applied in the design of flight control semi-physical simulation systems. It features wide adaptability, strong real-time performance, good scalability, and the ability to switch between simulation signals and physical or physical simulation signals in real time. The real-time simulator uses a multi-core processor, assigning different models or tasks to different CPUs, and separating the communication interface program from the simulation model.

[0005] However, in multi-core hardware-in-the-loop simulation, multiple cores need to frequently complete large amounts of data interaction work, and the communication overhead will accumulate rapidly, becoming a performance bottleneck for the entire system, thereby reducing the practicality of the hardware-in-the-loop simulation system. Summary of the Invention

[0006] The main purpose of this application is to provide a multi-core simulation method, device and medium based on a distributed semi-physical simulation system. In order to solve the above-mentioned technical problems, this application specifically adopts the following technical solutions:

[0007] A first aspect of the present application is to provide a multi-core simulation method based on a distributed hardware-in-the-loop simulation system, wherein the distributed hardware-in-the-loop simulation system includes a host computer and several slave computers, each of which includes at least one scheduling core and several simulation cores; the method includes:

[0008] S101, obtaining several semi-physical simulation objects in a simulation task;

[0009] S102, analyzing task coupling degrees between a plurality of hardware-in-the-loop simulation objects, and dividing the plurality of hardware-in-the-loop simulation objects into a plurality of associated simulation groups according to the task coupling degrees;

[0010] S103, binding each hardware-in-the-loop simulation object in the same associated simulation group to each simulation core of the same slave computer to obtain a plurality of binding simulation relationships;

[0011] S104, transmitting the simulation instruction generated by the upper computer to the scheduling core, the scheduling core being configured to obtain, from the simulation instruction, a plurality of sub-simulation instructions corresponding to a plurality of simulation cores in the lower computer to which the scheduling core belongs based on the binding simulation relationship, and issuing the sub-simulation instructions to the corresponding target simulation core, so that the target simulation core performs simulation calculations according to the corresponding sub-simulation instructions to obtain simulation results;

[0012] S105 , transmitting the plurality of simulation results obtained by the lower computer to the upper computer to update the simulation instructions.

[0013] In some embodiments, the task coupling indicator includes at least one of entity attribute similarity, simulation task matching, and entity interaction frequency.

[0014] In some embodiments, the method further includes: the upper computer and the scheduling core in the lower computer interacting with each other based on reflective memory; and / or the scheduling core in the lower computer interacting with several simulation cores based on shared memory.

[0015] In some embodiments, the method further includes: when the scheduling core detects that any of the target simulation cores uploads the simulation results to the shared memory, uploading the simulation results to the host computer based on the reflective memory; and / or, based on a preset duration, controlling the scheduling core to obtain the simulation results uploaded by at least one of the target simulation cores in the shared memory, and uploading the simulation results to the host computer based on the reflective memory.

[0016] In some embodiments, the method also includes: after the scheduling core sends the sub-simulation instruction to the corresponding target simulation core, if no update of the target simulation core is detected for a first preset period of time, the corresponding target simulation core is identified as an abnormal simulation core; based on the latest simulation results and / or historical simulation results of at least one of the target simulation cores in the lower computer, the predicted simulation results of the abnormal simulation core are predicted, and the predicted simulation results are uploaded to the upper computer.

[0017] In some embodiments, the method also includes: if no update of the abnormal simulation core is detected for a second preset time period, releasing the binding relationship between the abnormal simulation core and the semi-physical simulation object, and binding the corresponding semi-physical simulation object with other idle simulation cores; wherein, the first preset time period is less than the second preset time period.

[0018] In some embodiments, the method further includes: continuously monitoring the operating load of each of the lower computers, and when the operating load of any of the lower computers exceeds a preset load threshold, identifying the corresponding lower computer as an overloaded lower computer; changing some binding relationships in the overloaded lower computers to migrate some semi-physical simulation objects in the same associated simulation group to other lower computers.

[0019] In some embodiments, the method further includes: detecting the historical simulation step lengths of several simulation cores in the overloaded lower computer; selecting at least one overloaded simulation core whose historical simulation step length is greater than a preset simulation step length, and / or whose historical simulation step growth rate is greater than a preset growth rate, releasing the binding relationship between the overloaded simulation core and the semi-physical simulation object, and binding the corresponding semi-physical simulation object to the idle simulation cores in other lower computers; and / or,

[0020] Detect the current task coupling degree of each semi-physical simulation object in the associated simulation group corresponding to the overloaded lower computer; select at least one overloaded simulation object whose current task coupling degree is lower than a preset coupling degree threshold, unbind the corresponding overloaded simulation object from the simulation core, and bind the overloaded simulation object to the idle simulation cores in other lower computers.

[0021] A second aspect of the present application is to provide a computer device, the device comprising:

[0022] memory for storing computer programs;

[0023] A processor is used to execute the computer program and implement the steps of the multi-core simulation method based on a distributed semi-physical simulation system as provided in any embodiment of the present application when executing the computer program.

[0024] The third aspect of the present application is to provide a corresponding computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the processor performs the steps of the multi-core simulation method based on a distributed semi-physical simulation system as provided in any embodiment of the present application.

[0025] Beneficial effects:

[0026] The present application discloses a multi-core simulation method, device and medium based on a distributed semi-physical simulation system. By analyzing the task coupling degree (including entity attribute similarity, simulation task matching degree and interaction frequency) between semi-physical simulation objects, high-density semi-physical simulation objects are divided into associated simulation groups. Each associated simulation group is bound to the simulation core of the same physical lower computer for operation. As a result, the specific simulation tasks of multiple target simulation cores in each lower computer are highly correlated. On the one hand, the associated simulation groups can share part of the data, and combined with the physical proximity, the data transmission efficiency of the upper and lower computers can be effectively improved. On the other hand, it provides a feasibility basis for predicting the simulation results of abnormal simulation cores within the lower computer, ensuring the continuous advancement of the simulation process and improving the practicality of the semi-physical simulation system.

[0027] Specifically, the associated simulation groups can use overlapping data, such as environmental data such as terrain and wind speed, which can effectively reduce data redundancy in information transmission between upper and lower computers; the simulation instructions corresponding to the associated simulation groups are distributed more continuously, and the scheduling center can quickly read the sub-simulation instructions corresponding to all cores; the simulation tasks corresponding to the associated simulation groups have a more uniform pace, and the scheduling center can package and upload the simulation results of all cores at a certain time interval to reduce network congestion; at the same time, multiple semi-physical simulation objects within the associated simulation group share a high-precision clock source to ensure the strict timing correctness of interactive events.

[0028] Furthermore, a hybrid communication architecture of reflective memory and shared memory is adopted: low-latency information exchange is achieved between the upper computer and the lower computer through reflective memory, while shared memory is used to transmit data between the scheduling core and the simulation core within the lower computer, further reducing communication latency.

[0029] In addition, the initial division is dominated by task relevance, and dynamic adjustments are made in combination with the actual status of each lower computer and each simulation core during actual operation. A load monitoring and multi-level fault tolerance mechanism are also established to further improve the practicality of the semi-physical simulation system.

[0030] At the macro level, the load on lower-level machines is monitored in real time. When a high-load risk is detected on a lower-level machine, the upper-level machine can quickly migrate some of the hardware-in-the-loop simulation objects to other healthy nodes, reducing the load on the lower-level machine and preventing failure. Furthermore, for overloaded lower-level machines, more refined adjustment strategies are implemented based on factors such as the simulation core's historical simulation step size or the current task coupling level. For example, entity groups with low task coupling levels are prioritized for migration to idle nodes to achieve load optimization.

[0031] At the micro level, the simulation core computing process is monitored in real time. If the target simulation core times out and is not updated, a two-level fault tolerance mechanism is enabled: first-level fault tolerance, without the need to interact with the upper computer or other lower computers, based on the historical simulation data and / or current simulation data in the lower computer where the abnormal simulation core is located, and utilizing the high correlation between the specific simulation tasks of multiple target simulation cores in each lower computer, the simulation results of the abnormal simulation core can be quickly and accurately calculated within the lower computer; second-level fault tolerance, if the abnormality persists for more than a second preset time, the simulation core is determined to have failed, its binding relationship with the semi-physical simulation object is released, and the task is reallocated to the idle core in the same node or migrated to other healthy nodes. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following is a brief introduction to the drawings required for the embodiments or the description of the prior art. In all drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the various elements or parts are not necessarily drawn according to the actual scale. Obviously, the drawings described below are some embodiments of the present application. For those of ordinary skill in the art, other drawings can also be obtained based on these drawings without paying any creative work.

[0033] Figure 1 is a schematic block diagram of a multi-core simulation method based on a distributed hardware-in-the-loop simulation system provided in an embodiment of the present application;

[0034] Figure 2 is a schematic flow chart of a multi-core simulation method based on a distributed hardware-in-the-loop simulation system provided in an embodiment of the present application;

[0035] Figure 3 This is a schematic block diagram of binding an associated simulation group and a simulation core provided by an embodiment of the present application;

[0036] Figure 4 This is a schematic block diagram of the structure of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0037] To make the purpose, technical solutions, and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0038] Herein, suffixes such as "module," "component," or "unit" used to represent elements are only used to facilitate the description of the present application and have no specific meaning. Therefore, "module," "component," or "unit" can be used interchangeably.

[0039] As used herein, terms such as "upper," "lower," "inner," "outer," "front," "back," "one end," and "the other end" indicate positions or locations based on those shown in the accompanying drawings. These terms are intended solely to facilitate the description of this application and simplify the description. They are not intended to indicate or imply that the devices or components referred to must have, be constructed, or operate in a specific orientation. Therefore, they should not be construed as limitations on this application. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0040] As used herein, unless otherwise expressly specified or limited, the terms "installed," "provided with," "connected," etc., should be understood broadly. For example, "connected" may refer to a fixed connection, a detachable connection, or an integral connection; it may refer to a mechanical connection, a direct connection, an indirect connection through an intermediate medium, or internal communication between two components. Those skilled in the art will understand the specific meanings of the above terms in this application.

[0041] As used herein, "and / or" includes any and all combinations of one or more of the associated listed items.

[0042] Herein, "plurality" means two or more than two, ie, it includes two, three, four, five, etc.

[0043] It should be noted that, in this document, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or apparatus comprising the element.

[0044] In multi-core hardware-in-the-loop simulation, multiple cores need to frequently complete large amounts of data interaction. Especially in large-scale, highly concurrent collaborative simulation processes such as drone clusters, drones simulated in different lower computers need to frequently interact with each other across machines, causing communication delays and bandwidth waste. This leads to the rapid accumulation of communication overhead, which becomes a performance bottleneck for the entire system and reduces the practicality of the hardware-in-the-loop simulation system.

[0045] Based on this, the present application discloses a multi-core simulation method, device, and medium based on a distributed hardware-in-the-loop simulation system. By analyzing the task coupling degree (including entity attribute similarity, simulation task matching, and interaction frequency) between hardware-in-the-loop simulation objects, highly dense hardware-in-the-loop simulation objects are divided into associated simulation groups. Each associated simulation group is bound to the simulation core of the same physical slave computer for operation. Physical proximity is utilized to improve the data transmission efficiency between the slave and slave computers, further improving the practicality of the distributed hardware-in-the-loop simulation system. It should be understood that the associated simulation groups contain partially shared overlapping data, such as environmental data such as terrain and wind speed, which can effectively reduce data redundancy in information transmission between the slave and slave computers. The simulation instructions corresponding to the associated simulation groups are distributed more continuously, allowing the dispatch center to quickly read the sub-simulation instructions corresponding to all cores. The simulation tasks corresponding to the associated simulation groups are more uniform in pace, allowing the dispatch center to package and upload the simulation results of all cores at a certain time interval, reducing network congestion. At the same time, multiple hardware-in-the-loop simulation objects within the associated simulation group share a high-precision clock source to ensure the strict timing correctness of interaction events.

[0046] In some embodiments, the distributed hardware-in-the-loop simulation system includes a host computer and several slave computers, each of which includes at least one scheduling core and several simulation cores.

[0047] The host computer is the central control unit of the hardware-in-the-loop simulation system, responsible for macro-task scheduling and global coordination, such as generating simulation commands, receiving and integrating simulation results, and monitoring system operating status. The simulation commands generated by the host computer are the control signals that drive the hardware-in-the-loop simulation system. They are dynamically optimized during the simulation process based on feedback. They can be used to indicate environmental parameters such as wind speed, temperature, and terrain data, as well as real-time operational requirements, initial positions, speeds, and attitudes for all hardware-in-the-loop simulation objects.

[0048] Among them, the lower computer is a distributed physical execution node, each node contains at least one scheduling core and multiple simulation cores, which are responsible for receiving instructions from the upper computer and completing high-precision simulation solutions. The scheduling core is the control center in the lower computer responsible for task scheduling and communication. It is responsible for parsing the instructions from the upper computer, distributing sub-instructions to the bound simulation cores, etc. The number of scheduling cores can be flexibly determined according to the workload of task scheduling and communication in the lower computer; the simulation core is an independent computing unit in the lower computer that is bound to the semi-physical simulation object (such as aircraft, radar), and is used to perform real-time solutions (such as dynamic models, sensor simulation). It should be understood that the lower computer includes multiple CPU cores, and all CPU cores except the scheduling core can be simulation cores.

[0049] For example, in a distributed real-time parallel semi-physical simulation system, a layered upper and lower computer architecture is used to achieve efficient simulation. The upper computer module is an ordinary computer motherboard running the Windows system. It is installed with the control software corresponding to the semi-physical simulation. Its main functions are to configure the test state, control the experimental process, and store and process the test data. The lower computer uses a quad-core industrial computer, installs the board used for communicating with external devices in the semi-physical simulation, and runs the RTX real-time operating system that supports multi-core parallel solving. A distributed semi-physical simulation system has multiple sets of lower computers. The lower computer mainly runs the simulation scheduling management program and real-time simulation, responds to the instructions of the upper computer in real time, and schedules the simulation tasks in real time according to the drive of the clock signal to complete the simulation test.

[0050] In some embodiments, the method further includes: the upper computer and the scheduling core in the lower computer interacting with each other based on reflective memory; and / or the scheduling core in the lower computer interacting with several simulation cores based on shared memory.

[0051] Reflective memory is a real-time data sharing technology across physical nodes. It uses dedicated hardware (such as reflective memory cards) to build a globally unified address space, enabling deterministic, low-latency communication. The scheduling core between the host and slave nodes is based on reflective memory interaction. For example, after the host writes simulation instructions to the local reflective memory card, the data is automatically synchronized to the corresponding memory area of ​​all slave nodes, ensuring real-time and consistent instruction transmission. This technology is suitable for high-frequency instruction issuance and result transmission across devices. For another example, any slave node can upload its simulation results to the host through reflective memory.

[0052] Shared memory is a direct memory access mechanism between multiple cores within the same physical node, enabling zero-copy data exchange through memory mapping. The scheduling core and simulation core in the lower computer interact via shared memory, while a unified clock source ensures timing correctness for simulations within the group. For example, the scheduling core writes sub-instructions to the shared memory area, and the simulation core directly reads and writes the solution results to the shared memory, eliminating inter-process communication overhead and improving data transfer efficiency within the node.

[0053] It should be understood that the upper and lower computers exchange data directly via low-latency reflective memory, avoiding network protocol overhead. Shared memory is used within the lower computer to enable fast data exchange between the scheduling core and the simulation core, reducing inter-process communication latency. In other words, reflective memory supports high-speed instruction issuance and result reporting between the upper and lower computers, while shared memory ensures real-time collaboration between the lower computer cores. The combination of these two not only meets the low-latency requirements of cross-node communication, but also enables efficient data sharing within a single computer, reducing the overall communication load.

[0054] Please refer to Figure 1 , Figure 1 is a schematic block diagram of a multi-core simulation method based on a distributed hardware-in-the-loop simulation system provided in an embodiment of the present application, such as Figure 1 As shown, the host computer can transmit the simulation instructions to the scheduling core CPU-0 in the lower computer through the reflective memory. The scheduling core CPU-0 extracts the sub-simulation instructions related to the lower computer in the simulation instructions and distributes them to the corresponding simulation cores CPU-1, CPU-2, CPU-N, etc. through the shared memory. These simulation cores execute the sub-simulation instructions they receive and feed back the simulation results to the scheduling core CPU-0 through the shared memory. The scheduling core CPU-0 then uploads these simulation results to the host computer through the reflective memory. Furthermore, each simulation core starts the simulation model and hardware device through the simulation driver, solves the simulation model and sends back the simulation results. The interaction between the lower computer and the hardware device can also be completed using the reflective memory. Among them, the simulation model refers to a mathematical or logical model used to simulate the behavior of the system. For example, in aircraft simulation, the simulation model is a technical tool that uses mathematical formulas and computer means to simulate the movement of a real aircraft. It is used to study the movement laws of the aircraft, predict results or optimize decisions. Specifically, it can be a Simulink model.

[0055] The following describes some embodiments of the present application in detail with reference to the accompanying drawings. In the absence of conflict, the following embodiments and features of the embodiments can be combined with each other. Figure 2 , Figure 2 This is a schematic flow chart of a multi-core simulation method based on a distributed hardware-in-the-loop simulation system provided in an embodiment of the present application. Figure 2As shown, an embodiment of the present application provides a multi-core simulation method based on a distributed semi-physical simulation system, which is applied to a distributed semi-physical simulation system. The distributed semi-physical simulation system includes an upper computer and several lower computers, each of the lower computers includes at least one scheduling core and several simulation cores; the method includes S101 to S105.

[0056] S101: Acquire several hardware-in-the-loop simulation objects in a simulation task.

[0057] Specifically, in hardware-in-the-loop simulation, a simulation task refers to testing and verification performed by combining real hardware devices with virtual simulation models. It includes pre-defined elements such as hardware-in-the-loop simulation objects, environmental parameters, task objectives, time constraints, and interaction rules. Hardware-in-the-loop simulation objects refer to simulation objects in hardware-in-the-loop simulation that are composed of real physical hardware devices and virtual simulation models and are capable of real-time interaction with the simulation environment.

[0058] For example, by parsing the simulation scenario configuration file input by the user, all hardware-in-the-loop simulation objects participating in the simulation are extracted, and the class identifier (e.g., aircraft, radar), attributes (e.g., initial coordinates, communication frequency, environmental dependencies), and interaction requirements with other hardware-in-the-loop simulation objects of the hardware-in-the-loop simulation objects are read from the task description file. For example, in a drone swarm simulation, it is necessary to extract multiple hardware-in-the-loop simulation objects such as drones and ground control stations, and annotate their flight parameters, communication delays, and other characteristics. This provides data support for subsequent analysis of the task coupling between hardware-in-the-loop simulation objects and the division of related simulation groups, ensuring that the physical allocation of hardware-in-the-loop simulation objects matches the logical associations.

[0059] S102: Analyze the task coupling degrees between a plurality of hardware-in-the-loop simulation objects, and divide the plurality of hardware-in-the-loop simulation objects into a plurality of associated simulation groups according to the task coupling degrees.

[0060] Task coupling refers to the closeness of the association between hardware-in-the-loop simulation objects. Exemplarily, indicators of task coupling include at least one of entity attribute similarity, simulation task matching, and entity interaction frequency. Entity attribute similarity refers to the consistency of static characteristics between hardware-in-the-loop simulation objects, including physical parameters (such as device model, sensor type, range, and endurance), simulation model parameters (such as control cycle and accuracy requirements), and communication protocols. Simulation task matching refers to the collaborative dependencies between dynamic behaviors of hardware-in-the-loop simulation objects, such as task objective coordination (such as a swarm of drones coordinating to perform a rescue mission), synchronization requirements (such as a swarm of drones steering synchronously), and data flow direction (such as sensor output serving as controller input). Entity interaction frequency refers to the number of interaction events between hardware-in-the-loop simulation objects per unit time, including, for example, the periodic communication interval between multiple hardware-in-the-loop simulation objects and the frequency of event-driven interactions.

[0061] In some embodiments, the task coupling index may also include time synchronization accuracy requirements. For example, some semi-physical simulation objects need to strictly align timestamps. Such semi-physical simulation objects need to be included in the same associated simulation group to utilize a unified clock source within the group.

[0062] Specifically, the task coupling degree indicator can be flexibly selected according to the specific semi-physical simulation scenario. For example, the task coupling degree indicator is set with a priority. For example, if the coupling degree of a semi-physical simulation object is close to that of multiple associated simulation groups, and the entity interaction frequency is the task coupling degree indicator with the highest priority, then the corresponding semi-physical simulation object will be preferentially included in the group with the highest entity interaction frequency. For another example, when the attribute similarity of multiple semi-physical simulation objects is high, only the task matching degree and the entity interaction frequency need to be considered. For another example, the comprehensive task coupling degree can also be determined based on the indicator dimensions such as attribute similarity, task matching degree and entity interaction frequency.

[0063] In some embodiments, the task coupling between hardware-in-the-loop simulation objects is quantified using a preset algorithm, where the preset algorithm can be a pre-set clustering algorithm or a pre-trained coupling prediction model. For example, in a drone formation simulation, multiple drones require high-frequency communication to share data such as attitude and speed, and their environments are also highly similar. Their entity attribute similarity, simulation task matching, and entity interaction frequency are all high, so they are determined to be highly coupled hardware-in-the-loop simulation objects. Subsequently, the clustering algorithm is used to group hardware-in-the-loop simulation objects with high task coupling into an associated simulation group.

[0064] In some embodiments, the coupling degree threshold can be flexibly set according to the resource constraints in the actual application scenario, and the semi-physical simulation objects with task coupling degrees higher than the coupling degree threshold can be classified into the same associated simulation group. For example, in the UAV formation simulation, the UAVs in the same formation that require real-time collaborative path planning are divided into an associated simulation group due to their high interaction frequency and strong task dependence; while UAVs that independently perform reconnaissance missions and only need to report data periodically may be grouped separately. Among them, the resource constraints can be the number of lower computers, the number of simulation cores in the lower computers, the computing power of the simulation cores, etc., so as to match the computing requirements or number of semi-physical simulation objects in each associated simulation group with the computing power and number of simulation cores of the lower computers, and the computing resources of the simulation cores must be taken into account.

[0065] For example, if the total computing requirements of the semi-physical simulation objects of a certain associated simulation group exceed the computing power of a single slave computer, or the total number of semi-physical simulation objects of a certain associated simulation group exceeds the number of simulation cores of a single slave computer, the associated simulation group is further split to balance the load so that the semi-physical simulation objects within each associated simulation group are bound to multiple simulation cores of the same slave computer. For example, in a UAV formation simulation, if the number of multiple UAVs in the same formation exceeds the number of simulation cores of a single slave computer, the multiple UAVs in the same formation can be further divided according to their positional relationships, or the relevant parameters of the clustering algorithm can be adjusted to perform more refined clustering divisions so that the associated simulation groups can take into account the computing resources of the simulation cores.

[0066] It should be understood that the associated simulation group is a logical collection of semi-physical simulation objects with high task coupling. It reduces cross-node communication overhead through physical proximity deployment, while ensuring that the semi-physical simulation objects in the group share environmental data (such as unified terrain models and wind speed parameters) to reduce redundant transmission, and the simulation cores bound to the same lower computer share a high-precision clock source to ensure strict timing synchronization of interactive events, thereby optimizing the performance of the entire simulation system.

[0067] S103 , binding each hardware-in-the-loop simulation object in the same associated simulation group with each simulation core of the same lower computer to obtain a plurality of binding simulation relationships.

[0068] Among them, the binding simulation relationship is a fixed mapping relationship established between the semi-physical simulation object and the simulation core, which ensures that each semi-physical simulation object performs simulation calculations on a specific simulation core, forming a one-to-one task execution unit.

[0069] Specifically, a one-to-one matching relationship is established between each semi-physical simulation object in a certain associated simulation group and a specific simulation core of the same lower computer, ensuring that all semi-physical simulation objects in the group are physically bound to different simulation cores of the same lower computer for operation.

[0070] See also Figure 3 , Figure 3 This is a schematic block diagram of an associated simulation group and a simulation core binding provided by an embodiment of the present application; Figure 3 As shown in the figure, the lower computer is a quad-core industrial computer. A certain associated simulation group includes two coordinated flying drones A and B and a ground control station E. These three semi-physical simulation objects are respectively assigned to the three simulation cores of this quad-core industrial computer, as shown in the figure. Figure 3 Among them, CPU-1, CPU-2, CPU-N, in addition, core CPU-0 can be used as the scheduling core.

[0071] In some embodiments, the method further includes: reserving a spare lower machine or a spare simulation core before executing step S102, so that when executing step S102, the spare lower machine or the spare simulation core does not participate in the statistics of the number of simulation cores, and when executing step S103, the spare lower machine or the spare simulation core is not bound to the semi-physical simulation object; or, after executing step S103, counting the core redundancy of each lower machine, and selecting a spare lower machine or a spare simulation core; when a simulation core failure or overload is detected, automatically switching to the spare lower machine or the spare simulation core to maintain task continuity.

[0072] S104. The simulation instruction generated by the upper computer is transmitted to the scheduling core. The scheduling core is used to obtain several sub-simulation instructions corresponding to several simulation cores in the lower computer to which the scheduling core belongs from the simulation instruction based on the binding simulation relationship, and send the sub-simulation instructions to the corresponding target simulation core, so that the target simulation core performs simulation operations according to the corresponding sub-simulation instructions to obtain simulation results.

[0073] Specifically, the sub-simulation instruction is a local simulation task split from the simulation instruction by the scheduling core according to the binding simulation relationship, such as the exclusive instruction of UAV A. The scheduling core then sends the sub-simulation instruction to the corresponding target simulation core according to the binding simulation relationship. These target simulation cores will perform specific local simulation tasks according to the sub-simulation instruction, such as attitude control or path planning of UAV A, and then output the corresponding simulation results, such as the current position, speed or status information of UAV A.

[0074] It should be noted that during the initialization phase, the scheduling core writes the bound simulation relationship into the shared memory and loads the corresponding simulation model, environment parameters and interactive interface configuration (such as input / output memory address, etc.) for each simulation core to execute the corresponding semi-physical simulation task.

[0075] S105 , transmitting the plurality of simulation results obtained by the lower computer to the upper computer to update the simulation instructions.

[0076] Specifically, the scheduling core of the lower computer transmits the simulation results (such as drone positions, sensor data, and environmental conditions) calculated by all simulation cores within the associated simulation group to the upper computer. The upper computer integrates and analyzes the simulation results of multiple nodes in real time from a global perspective, dynamically generating new simulation instructions. This leverages the real-time feedback from the lower computers and the global decision-making capabilities of the upper computer to ensure continuous optimization of simulation tasks within dynamic real-time simulations.

[0077] It should be understood that simulation instructions are dynamically updated based on real-time simulation results to advance the simulation task and improve the accuracy and practicality of the final simulation results. For example, in a drone rescue simulation, the initial simulation instruction is "go straight for 500 meters", but the simulation result may feedback that the infrared sensor is interfered with by thick smoke. The host computer can update the simulation instruction to "slow down to 2m / s and drive to the right front." For another example, the initial simulation instruction is to detect the environment in situ, and the simulation result feedback indicates that the environment at the current location has been detected. The host computer can update the simulation instruction to "go straight for 50 meters and continue to detect the environment." This process forms a closed-loop control to ensure that the simulation task is continuously optimized based on dynamic feedback.

[0078] In some embodiments, after hardware-in-the-loop simulation objects within an associated simulation group are bound to the same slave computer, shared memory can be used to achieve low-latency communication between simulation cores, avoiding the bandwidth consumption of cross-node reflective memory. For example, if drone A and ground control station E need to frequently exchange flight status data, after binding them to the same slave computer, they can directly transmit data through shared memory, rather than through cross-machine communication using reflective memory.

[0079] For example, in a detection mission, the host computer first generates a global simulation instruction, such as "UAV A flies 50 meters west, UAV B flies 20 meters east, and UAV C returns to base." It then sends this simulation instruction to the scheduling cores of all lower computers via reflective memory. After receiving the instruction, the scheduling core (such as CPU-0) quickly locates the hardware-in-the-loop simulation object for which this lower computer is responsible based on the preset binding simulation relationship, such as UAV A bound to CPU-1 and UAV B bound to CPU-2. It then extracts the corresponding sub-simulation instructions from the global instruction. The scheduling core then sends the sub-simulation instruction "UAV A flies 50 meters west" to CPU-1 and the sub-simulation instruction "UAV B flies 20 meters east" to CPU-2.

[0080] Upon receiving a sub-simulation instruction, each simulation core immediately initiates the simulation operation. During the operation, the simulation core can directly access real-time data from other cores in the group using shared memory (for example, Drone A can read the real-time position of Drone B), ensuring the accuracy of the collaborative task. For example, CPU-1 calculates the new attitude, speed, and path based on Drone A's flight model, while CPU-2 simultaneously processes the obstacle avoidance logic for Drone B. After the operation is complete, each simulation core writes the simulation results to the shared memory in real time. The scheduling core then retrieves the simulation results through shared memory and uploads them to the host computer using reflective memory.

[0081] In some embodiments, the method further includes: when the scheduling core detects that any of the target simulation cores uploads the simulation results to the shared memory, uploading the simulation results to the host computer based on the reflective memory; and / or, based on a preset duration, controlling the scheduling core to obtain the simulation results uploaded by at least one target simulation core in the shared memory, and uploading the simulation results to the host computer.

[0082] For example, immediate response upload of simulation results: when the scheduling core detects that any simulation core has written simulation results to shared memory, it immediately triggers the data upload process. This is suitable for critical data that requires a fast response. For example, a simulation core uses a 1ms simulation step size and uploads simulation results to the scheduling core every 1ms. The scheduling core immediately triggers the data upload process.

[0083] For example, for periodic uploading of simulation results, the scheduling core scans the shared memory periodically (i.e., the preset duration), collects the simulation results uploaded by all simulation cores within the period, and reduces the transmission overhead of high-frequency small data packets. For example, in the UAV formation simulation, the scheduling core packages the collected data such as the position and speed of each UAV every 5ms, and uploads it to the host computer through the reflective memory to ensure the synchronous update of the global state. Among them, the preset duration is the pre-set periodic data synchronization time interval in the semi-physical simulation system, which is used to balance real-time performance and network load. Its specific value can be aligned with the minimum time step of the simulation task, or dynamically configured according to the mission criticality and real-time requirements, such as setting a shorter period for high real-time control tasks, which is not limited here.

[0084] It should be understood that the two different upload triggering mechanisms can be used in combination. For critical HIL simulation objects, immediate response upload can be used to ensure immediate feedback of key data. For common HIL simulation objects, periodic upload can be used to ensure stable transmission of regular data and continuity of the overall simulation process. This hybrid mechanism avoids the high-frequency communication of purely event-driven communication while addressing the latency issues of periodic polling, balancing real-time performance with communication load.

[0085] In some embodiments, the method also includes: after the scheduling core sends the sub-simulation instruction to the corresponding target simulation core, if no update of the target simulation core is detected for a first preset period of time, the corresponding target simulation core is identified as an abnormal simulation core; based on the latest simulation results and / or historical simulation results of at least one of the target simulation cores in the lower computer, the predicted simulation results of the abnormal simulation core are predicted, and the predicted simulation results are uploaded to the upper computer.

[0086] Specifically, the first preset duration is the time threshold for the scheduling core to determine that the simulation core is abnormal, or it can be the validity period limit of the latest simulation results and / or historical simulation results, for example, 10 simulation steps. After the scheduling core sends the sub-simulation instruction to the target simulation core, the scheduling core does not detect the status update of the target simulation core within this time period, such as no data is written to the shared memory or the heartbeat signal is lost, then the abnormality detection mechanism is triggered.

[0087] Obtain the target simulation cores for simulation settlements that are being performed or have been performed within the first preset time period, and then obtain the latest simulation results and / or historical simulation results of these target simulation cores, which may include the latest simulation results and / or historical simulation results of the abnormal simulation core, as well as the latest simulation results and / or historical simulation results of other normal target simulation cores in the same associated simulation group (i.e., the same lower computer), to provide a sufficient and reliable data basis for subsequent predictions. Among them, the latest simulation result refers to the data output normally by the abnormal simulation core for the last time, such as the position, speed, aircraft attitude angle, and engine speed last uploaded by UAV A, and its timestamp must be within the first preset time period; correspondingly, the historical simulation result refers to the data output from the abnormal simulation core in multiple cycles before the failure, such as the position coordinates and flight trajectory of the past 10 simulation steps.

[0088] Furthermore, temporary replacement values ​​are calculated based on the latest simulation results and / or historical simulation results of these target simulation cores through preset prediction algorithms (such as linear interpolation and Kalman filtering) as the predicted simulation results for the next moment, and uploaded to the host computer to maintain the continuity of the global simulation process, avoid global simulation interruption due to single point failure, and at the same time gain response time for subsequent possible simulation core migration.

[0089] For example, in a drone formation simulation, if the simulation core of aircraft D fails to update its attitude data for 50ms after the scheduling core issues a control instruction, which exceeds the first preset time length, the scheduling core reads the latest simulation results of other normal cores in the same lower computer from the shared memory, such as the position of wingman F, wind speed sensor data, and the historical position trajectory of aircraft D. Since the aircraft maintain relative formation, the current position of aircraft D can be predicted and estimated to generate a predicted simulation result.

[0090] It should be understood that by analyzing the task coupling between semi-physical simulation objects, the highly tightly coupled semi-physical simulation objects are divided into associated simulation groups. Each associated simulation group is bound to the simulation core of the same physical lower computer. Therefore, the specific simulation tasks of multiple target simulation cores in each lower computer are highly correlated, which provides a feasibility basis for predicting the simulation results of abnormal simulation cores, and quickly and accurately infers the simulation results of abnormal simulation cores internally to ensure the continuous advancement of the simulation process.

[0091] In some embodiments, the semi-physical simulation object corresponding to the abnormal simulation core is marked as an abnormal semi-physical simulation object and synchronized to the host computer. The host computer determines the priority or influence coefficient of the specific simulation task performed by the abnormal semi-physical simulation object based on the entire simulation task and the current simulation process. When the priority is greater than the preset priority or the influence coefficient is greater than the preset coefficient, other normal semi-physical simulation objects are replaced to perform the corresponding specific simulation task.

[0092] In other words, predicted simulation results and abnormal conditions (i.e., abnormal hardware-in-the-loop simulation objects that cannot be simulated normally) are uploaded to the host computer via reflective memory, maintaining the continuity of the global simulation process and triggering the host computer to decide whether to change simulation instructions. For example, in a drone rescue simulation, if drone B's simulation core experiences an anomaly and is predicted to be unable to continue searching, and drone B's search mission is the highest priority or will highly impact subsequent mission scheduling, the host computer can dynamically adjust instructions, instructing drone A to expand its search area to cover drone B's search range, ensuring overall mission progress, while tolerating local failures and minimizing the impact on the global simulation.

[0093] In some embodiments, the method also includes: if no update of the abnormal simulation core is detected for a second preset time period, releasing the binding relationship between the abnormal simulation core and the semi-physical simulation object, and binding the corresponding semi-physical simulation object with other idle simulation cores; wherein, the first preset time period is less than the second preset time period.

[0094] The second preset duration is the time threshold at which the scheduling core determines that an abnormal simulation core requires forced migration, for example, 50 simulation steps. If the abnormality persists beyond this duration and is not resolved, the rebinding of the hardware-in-the-loop simulation object is triggered. Correspondingly, an idle simulation core refers to an allocable computing unit that is not currently bound to a hardware-in-the-loop simulation object.

[0095] Specifically, when the scheduling core determines that a simulation core is abnormal, it first maintains the simulation process through the prediction results. If the abnormality lasts for more than a second preset time, the migration mechanism is triggered. The scheduling core first unbinds the abnormal simulation core from the semi-physical simulation object, selects an idle simulation core in this lower computer or other lower computers, such as calling a reserved spare simulation core, and synchronously loads the model parameters, environmental data and historical status of the original semi-physical simulation object to the new core simulation core to ensure simulation continuity. For example, in the UAV formation simulation, after the simulation task of UAV A is migrated to the idle simulation core for execution, it immediately continues to solve based on the pre-fault position and formation instructions to avoid cluster formation disorder.

[0096] It should be understood that at the micro level, the simulation core's computational progress is monitored in real time. If the target simulation core times out and fails to update, a two-level fault tolerance mechanism is activated: Level 1 fault tolerance, which eliminates the need for interaction with the host or other slave computers, leverages the historical and / or current simulation data within the slave computer where the abnormal simulation core resides and the high correlation between the specific simulation tasks of multiple target simulation cores within each slave computer. This provides a feasible basis for predicting the simulation results of the abnormal simulation core, allowing the simulation results of the abnormal simulation core to be quickly and accurately calculated within the slave computer, ensuring the continued progress of the simulation process. Level 2 fault tolerance, if the abnormality persists for more than a second preset duration, determines that the simulation core has failed, releases its binding to the hardware-in-the-loop simulation object, and reassigns the task to an idle core within the same node or migrates it to another healthy node. Thus, through hierarchical processing (prediction first, migration second), a balance is achieved between real-time performance and reliability. Short-term abnormalities rely on predictions from the associated data within the slave computer to maintain simulation continuity, while long-term faults ensure task recovery through dynamic resource adjustment, achieving fault isolation and rapid recovery, thereby ensuring the robustness of the system's long-term operation.

[0097] In some embodiments, the method further includes: continuously monitoring the operating load of each of the lower computers, and when the operating load of any of the lower computers exceeds a preset load threshold, identifying the corresponding lower computer as an overloaded lower computer; changing some binding relationships in the overloaded lower computers to migrate some semi-physical simulation objects in the same associated simulation group to other lower computers.

[0098] The runtime load is a metric used by the lower computer during real-time operation, including real-time parameters such as CPU utilization, memory usage, and task execution latency. It is used to assess whether its current processing capacity is approaching its limits. Correspondingly, the preset load threshold is a safety upper limit set based on the hardware performance of the lower computer. For example, a CPU utilization rate exceeding 85% or a memory usage exceeding 90% for three consecutive cycles triggers the load balancing mechanism.

[0099] Specifically, the system periodically collects load data from each slave machine. When a slave machine is detected to have exceeded a preset load threshold, it is marked as overloaded. Some hardware-in-the-loop simulation entities are unbound from their original simulation cores, and their task configurations are migrated to idle simulation cores on other slave machines, such as reserved backup machines. For example, if a slave machine is overloaded due to running simulations for five drones simultaneously, one of the drones can be migrated to an idle simulation core on another slave machine.

[0100] It should be understood that since the simulation tasks of the semi-physical simulation objects in the associated simulation group are highly coupled, the specific simulation tasks of multiple semi-physical simulation objects in a certain stage may need to be high-density and high-computation. At this time, multiple target simulation cores in the lower computer may require greater computing power, which in turn leads to an increase in or overload of the operating load of the lower computer at this stage. If a lower computer is overloaded due to the addition of high-density tasks, some semi-physical simulation objects can be migrated to other nodes for simulation and solution by dynamically adjusting the binding relationship, thereby dispersing the overload risk to other lower computers and avoiding simulation interruption of the overloaded lower computer.

[0101] In some embodiments, the method also includes: detecting the historical simulation step lengths of several simulation cores in the overloaded lower computer; selecting at least one overloaded simulation core whose historical simulation step length is greater than a preset simulation step length, and / or whose historical simulation step length growth rate is greater than a preset growth rate, releasing the binding relationship between the overloaded simulation core and the semi-physical simulation object, and binding the corresponding semi-physical simulation object to the idle simulation cores in other lower computers.

[0102] The historical simulation step size is the computational time required for the simulation core to execute a single simulation cycle. It is used to measure its computational efficiency and reflect the core's real-time processing capabilities. Correspondingly, the preset simulation step size is the upper limit of the standard solution time required by the simulation task and is used to determine the potential or existing cumulative delay of the simulation core.

[0103] The historical simulation step size growth rate represents the trend of step size changes over multiple consecutive cycles. For example, the simulation step size increased from 0.9ms to 20ms over the last 10 cycles, a growth rate of approximately 2122.22%. Correspondingly, the preset growth rate represents the maximum incremental threshold, which is used to determine potential or existing performance degradation of the simulation core.

[0104] Specifically, when a slave machine is detected as overloaded, the historical simulation step lengths of its simulation cores are analyzed. If a core's historical simulation step length exceeds a preset simulation step length, or its historical simulation step growth rate exceeds a preset growth rate, it is marked as an overloaded simulation core, and the corresponding semi-physical simulation object is re-bound to the idle simulation cores of other slave machines. Thus, based on simulation core performance indicators, cores with high load or trending overload are prioritized for migration, avoiding ineffective migrations caused by blind migrations and optimizing overall resource utilization.

[0105] In some embodiments, the current task coupling degree of each semi-physical simulation object in the associated simulation group corresponding to the overloaded lower computer is detected; at least one overloaded simulation object whose current task coupling degree is lower than a preset coupling degree threshold is selected, the corresponding overloaded simulation object is unbound from the simulation core, and the overloaded simulation object is bound to the idle simulation cores in other lower computers.

[0106] Specifically, the current task coupling degree is the strength of the association between a hardware-in-the-loop (HIL) object and other HIL objects within its associated simulation group, calculated in real time during the simulation process. This degree can be updated based on the latest interaction data, such as the average interaction frequency, attribute similarity, and task dependencies over the last 10 preset periods. This is used to determine the feasibility of migrating a HIL object. Correspondingly, the preset coupling threshold is a pre-set loose coupling criterion used to identify HIL objects with weaker associations with other HIL objects within the group and therefore suitable for priority migration.

[0107] In some embodiments, the current task coupling degree of each semi-physical simulation object in the associated simulation group corresponding to the overloaded lower computer is detected; when the task coupling degree of each semi-physical simulation object is higher than a preset coupling degree threshold, the hardware accelerator corresponding to the lower computer is enabled.

[0108] Specifically, a hardware accelerator is a dedicated computing module integrated into the lower computer, capable of providing higher computational efficiency and real-time performance than a general-purpose CPU for specific simulation tasks. For more information on these modules, please refer to related technologies and are not limited here. When it is detected that the current task coupling of all hardware-in-the-loop simulation objects within the associated simulation group of an overloaded lower computer exceeds a preset coupling threshold, the strong associations between these hardware-in-the-loop simulation objects will result in a high migration cost or increased communication resources after migration. In this strongly coupled scenario, hardware-level acceleration is used to avoid simulation interruptions and complement the migration strategy.

[0109] It should be understood that the priority for migration of HIL objects is determined based on the task coupling degree of HIL objects within the associated simulation group (e.g., low-coupling HIL objects are prioritized for migration) or the historical simulation step length (e.g., migrating HIL objects with the longest computational time). Simultaneously, hardware accelerators are used to minimize migration costs, ensuring the reliability and real-time performance of HIL simulation. For example, in a drone swarm simulation, the low-coupling radar module responsible for environmental perception in an overloaded node is migrated to an idle node, while the highly coupled flight control core remains running locally, alleviating load pressure while maintaining core coordination efficiency.

[0110] In some embodiments, the operating load of each of the lower machines is continuously monitored. When the operating load of any of the lower machines exceeds a preset load threshold, the scheduling core of each lower machine continuously collects the local resource status (such as CPU / memory occupancy, simulation core queue depth) and periodically reports it to the upper machine. The upper machine predicts the future load trend of each lower machine based on historical data (such as the computational amount of simulation tasks that each lower machine needs to perform in history) and current task characteristics (such as the complexity of the current simulation task). If the future load trend exceeds the preset load threshold, the corresponding lower machine is identified as an overloaded lower machine; some binding relationships in the overloaded lower machine are changed, and some binding relationships in the overloaded lower machine are changed to migrate some semi-physical simulation objects in the same associated simulation group to other lower machines.

[0111] In some embodiments, if the density of the associated simulation group decreases due to mission evolution (such as a formation of drones performing reconnaissance separately on the battlefield), the host computer can actively split the group and redistribute it to balance the load.

[0112] It should be understood that in the embodiments of the present application, by analyzing task coupling indicators such as entity attribute similarity, simulation task matching, and interaction frequency, highly correlated semi-physical simulation objects are divided into correlated simulation groups and bound to the simulation core of the same slave computer. Physical proximity is used to reduce cross-node communication, while sharing environmental data (such as terrain and wind speed) reduces redundant transmission. Secondly, an efficient data transmission mechanism is established between the host computer and the slave computer, and within the slave computer. Reflective memory is used to achieve low-latency communication between the host computer and the scheduling core, and shared memory is used to optimize the interaction between the scheduling core and the simulation core in the slave computer, significantly reducing communication overhead. In addition, a dynamic load balancing and fault tolerance mechanism is provided to achieve flexible resource allocation, avoid simulation interruptions caused by overload or core failure, monitor the slave computer load in real time, and when overload is detected, select and migrate semi-physical simulation objects based on the historical step size of the simulation core or the current task coupling (such as prioritizing the migration of low-coupling tasks or enabling hardware acceleration). A two-level fault tolerance mechanism is constructed: the first level predicts abnormal core results through historical / current data to maintain the simulation process, and the second level directly migrates tasks to other cores or slave computers to ensure system continuity. These improvements effectively address the shortcomings of hardware-in-the-loop simulation in communication efficiency, load balancing, and fault tolerance, and enhance the practicality and reliability of the simulation system.

[0113] In some embodiments, in a semi-physical simulation system, a framework control end (such as a scheduling core) is designed as an intermediate layer, and the simulation models in the subordinate simulation cores are uniformly managed through the framework control end. At the same time, all information interactions between the control software in the upper computer and the simulation models in the lower computer are managed and message distributed by the framework control end. The simulation framework is only used to forward instructions to start / stop the model, and all model event management and step information writing are completed by the framework control end, thereby realizing the decoupling of the framework and model in the lower computer and realizing the parallel simulation function of multiple simulation nodes. That is to say, the framework management end has at least the functions of: receiving multi-node simulation events and target information (i.e., simulation instructions) of the management and control software; parsing multi-node simulation events and target information, and selecting the simulation model of the corresponding simulation core to send; after starting the corresponding simulation model, sending the target simulation information (i.e., sub-simulation instructions) once every 1ms period; receiving the simulation feedback of the model (i.e., simulation results) once every 1ms period; pushing the simulation feedback of the model to the simulation management and control software; the interaction between the framework management end and the outside world is real-time and high frame rate; managing all simulation tasks on the same simulation machine (i.e., the lower machine), and controlling their start, run, end and other states; and managing all step data on the same simulation machine.

[0114] like Figure 1As shown, the simulation task is modularly segmented. CPU-0 is the framework's control end (i.e., the scheduling core), while CPU-1, CPU-2, and CPU-N are the real-time simulation computation ends (i.e., simulation cores) that retrieve instruction data from the task modules and perform real-time simulation. Consequently, the real-time simulation framework in the lower computer (i.e., at least one scheduling core and several simulation cores) utilizes a "control end task scheduling, computation end periodic execution" mechanism to achieve "multitasking and parallel processing" capabilities, reducing the coupling between software structure and control flow. Furthermore, due to the characteristics of reflective memory hardware device drivers, only one process in the real-time simulation framework can use reflective memory communication at a time. The dispatch center's unified task reception and result feedback effectively adapts to this characteristic and avoids communication conflicts.

[0115] The real-time simulation framework operates in a minimal control cycle. For example, multi-core simulation tasks are scheduled and exchanged via the 1ms RTX response service. Every 1ms, the framework control end issues task scheduling instructions (i.e., sub-simulation task instructions), and the real-time simulation operation end polls and responds to these instructions every 1ms. Inter-core communication data reading and transmission strictly follows the interrupt status check followed by memory access, ensuring close coordination to complete multi-tasking. The main functions of the framework control end in real-time parallel simulation include monitoring the simulation test process, scheduling tasks for each core, responding to and handling interrupts, coordinating inter-core communication, allocating shared resources, handling simulation test failures, and collecting and processing data. RTX is a general-purpose real-time extension system based on the Windows operating system.

[0116] In some embodiments, real-time parallel simulation task scheduling is driven by the RTX clock signal, generated by the RTX software system. The RTX system features dynamic priority allocation, task switching times of less than 5.2µs, and interrupt response times of less than 5µs, making it a real-time simulation operating system. The RTX system's interrupt service routine (ISR) notifies simulation events of their occurrence in the shortest possible time, while other high-frequency computations and data interactions are handled within the triggered simulation task itself via an interrupt-task communication mechanism. This avoids the limitations of ISR programming and further reduces interrupt latency.

[0117] After a simulation task is activated, the simulation core first updates the simulation results from the previous cycle to the shared memory cache. When the framework management detects an update to the simulation structure of a simulation core on the same slave computer, it transmits the data to the master computer via reflective memory and activates the real-time step-by-step solution tasks for the simulation model on other simulation cores. Driven by external event commands, the framework management and control end periodically activates model tasks, updates simulation results, and sends them to the master computer until the simulation experiment concludes.

[0118] In some embodiments, the inter-task communication model of a hardware-in-the-loop simulation system primarily includes shared memory, semaphores, and reflective memory. The advantages of using shared memory for inter-task communication include the fastest access speed, the ability to specify the size of the data area, and the flexibility to configure the data area structure as needed. Reflective memory is used for interaction with the host computer and external devices. The reflective memory network utilizes high-speed fiber-optic hardware data sharing technology, ensuring strict transmission determinism and predictability. It also features simple data communication protocols, fast data transmission, strong real-time performance, and good platform versatility.

[0119] In some embodiments, static estimation or testing is used before program execution to determine the computational load, communication overhead, and logical relationships between tasks. This allows for initial analysis of the task coupling between several hardware-in-the-loop simulation objects. Furthermore, based on the inter-task correlations, the simulation resource requirements for each task can be determined in advance, preventing uncontrolled computational resource overhead and improving simulation efficiency.

[0120] See also Figure 4 , Figure 4 1 is a schematic block diagram of a computer device provided in an embodiment of the present application. The computer device may be a terminal device or a server.

[0121] For example, the above method can be implemented in the form of a computer program. Figure 4 Runs on the computer equipment shown.

[0122] like Figure 4 As shown, the computer device includes a processor, a memory, and a network interface connected via a system bus, wherein the memory may include a non-volatile storage medium and an internal memory.

[0123] The non-volatile storage medium can store an operating system and a computer program. The computer program includes program instructions, which, when executed, can enable the processor to execute any multi-core simulation method based on a distributed hardware-in-the-loop simulation system.

[0124] The processor is used to provide computing and control capabilities and support the operation of the entire computer equipment.

[0125] The internal memory provides an environment for the operation of the computer program in the non-volatile storage medium. When the computer program is executed by the processor, the processor can execute any multi-core simulation method based on the distributed semi-physical simulation system.

[0126] This network interface is used for network communication, such as sending assigned tasks.

[0127] It should be understood that the processor may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0128] In one embodiment, the method is applied to a distributed hardware-in-the-loop simulation system, wherein the distributed hardware-in-the-loop simulation system includes a host computer and several slave computers, each of which includes at least one scheduling core and several simulation cores; the processor is configured to run a computer program stored in a memory to implement the following steps:

[0129] S101, obtaining several semi-physical simulation objects in a simulation task;

[0130] S102, analyzing task coupling degrees between a plurality of hardware-in-the-loop simulation objects, and dividing the plurality of hardware-in-the-loop simulation objects into a plurality of associated simulation groups according to the task coupling degrees;

[0131] S103, binding each hardware-in-the-loop simulation object in the same associated simulation group to each simulation core of the same slave computer to obtain a plurality of binding simulation relationships;

[0132] S104, transmitting the simulation instruction generated by the upper computer to the scheduling core, the scheduling core being configured to obtain, from the simulation instruction, a plurality of sub-simulation instructions corresponding to a plurality of simulation cores in the lower computer to which the scheduling core belongs based on the binding simulation relationship, and issuing the sub-simulation instructions to the corresponding target simulation core, so that the target simulation core performs simulation calculations according to the corresponding sub-simulation instructions to obtain simulation results;

[0133] S105 , transmitting the plurality of simulation results obtained by the lower computer to the upper computer to update the simulation instructions.

[0134] Exemplarily, the processor is used to run a computer program stored in the memory, and is also used to implement the steps of the multi-core simulation method based on a distributed semi-physical simulation system provided in any embodiment of the present application, which will not be repeated here.

[0135] A computer-readable storage medium is also provided in an embodiment of the present application, wherein the computer-readable storage medium stores a computer program, wherein the computer program includes program instructions, and the processor executes the program instructions to implement any step of the multi-core simulation method based on a distributed semi-physical simulation system provided in the embodiment of the present application.

[0136] The computer-readable storage medium may be an internal storage unit of the computer device described in the aforementioned embodiment, such as a hard disk or memory of the computer device. The computer-readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, a SmartMedia Card (SMC), a Secure Digital (SD) card, a flash memory card, etc., equipped on the computer device.

[0137] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present application, and such modifications or substitutions should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A multi-core simulation method based on a distributed hardware-in-the-loop simulation system, characterized in that: The distributed hardware-in-the-loop simulation system includes a host computer and several slave computers, each of which includes at least one scheduling core and several simulation cores; the method includes: S101, obtaining several semi-physical simulation objects in a simulation task; S102, analyzing task coupling degrees between a plurality of hardware-in-the-loop simulation objects, and dividing the plurality of hardware-in-the-loop simulation objects into a plurality of associated simulation groups according to the task coupling degrees; S103, binding each hardware-in-the-loop simulation object in the same associated simulation group to each simulation core of the same slave computer to obtain a plurality of binding simulation relationships; S104, transmitting the simulation instruction generated by the upper computer to the scheduling core, the scheduling core being configured to obtain, from the simulation instruction, a plurality of sub-simulation instructions corresponding to a plurality of simulation cores in the lower computer to which the scheduling core belongs based on the binding simulation relationship, and issuing the sub-simulation instructions to the corresponding target simulation core, so that the target simulation core performs simulation calculations according to the corresponding sub-simulation instructions to obtain simulation results; S105, transmitting the plurality of simulation results obtained by the lower computer to the upper computer to update the simulation instruction; The method further includes: after the scheduling core sends the sub-simulation instruction to the corresponding target simulation core, if no update of the target simulation core is detected for a first preset time period, identifying the corresponding target simulation core as an abnormal simulation core; predicting a predicted simulation result of the abnormal simulation core based on the latest simulation result and / or historical simulation result of at least one of the target simulation cores in the lower computer, and uploading the predicted simulation result to the upper computer; If no update of the abnormal simulation core is detected for a second preset time period, the binding relationship between the abnormal simulation core and the semi-physical simulation object is released, and the corresponding semi-physical simulation object is bound to other idle simulation cores; wherein the first preset time period is less than the second preset time period.

2. The multi-core simulation method based on a distributed hardware-in-the-loop simulation system according to claim 1, characterized in that: The task coupling index includes at least one of entity attribute similarity, simulation task matching, and entity interaction frequency.

3. The multi-core simulation method based on a distributed hardware-in-the-loop simulation system according to claim 1, characterized in that: The method further includes: the upper computer and the scheduling core in the lower computer performing information interaction based on reflective memory; and / or the scheduling core in the lower computer performing information interaction with a plurality of the simulation cores based on shared memory.

4. The multi-core simulation method based on a distributed hardware-in-the-loop simulation system according to claim 3, characterized in that: The method further comprises: When the scheduling core detects that any of the target simulation cores uploads the simulation result to the shared memory, uploading the simulation result to the host computer based on the reflective memory; and / or, Based on a preset duration, the scheduling core is controlled to obtain a simulation result uploaded by at least one target simulation core in a shared memory, and the simulation result is uploaded to the host computer based on the reflective memory.

5. The multi-core simulation method based on a distributed hardware-in-the-loop simulation system according to claim 1, characterized in that: The method further comprises: Continuously monitoring the operating load of each of the slave computers, and when the operating load of any of the slave computers exceeds a preset load threshold, identifying the corresponding slave computer as an overloaded slave computer; Part of the binding relationship in the overloaded lower computer is changed to migrate part of the semi-physical simulation objects in the same associated simulation group to other lower computers.

6. The multi-core simulation method based on a distributed hardware-in-the-loop simulation system according to claim 5, characterized in that: The method further comprises: Detecting historical simulation steps of a plurality of the simulation cores in the overloaded slave computer; Selecting at least one overloaded simulation core whose historical simulation step length is greater than a preset simulation step length and / or whose historical simulation step growth rate is greater than a preset growth rate, releasing the binding relationship between the overloaded simulation core and the semi-physical simulation object, and binding the corresponding semi-physical simulation object to an idle simulation core in another slave computer; and / or, Detecting the current task coupling degree of each hardware-in-the-loop simulation object in the associated simulation group corresponding to the overloaded slave computer; At least one overloaded simulation object whose current task coupling degree is lower than a preset coupling degree threshold is selected, the corresponding overloaded simulation object is unbound from the simulation core, and the overloaded simulation object is bound to an idle simulation core in another lower computer.

7. A computer device, characterized in that: The device comprises: memory for storing computer programs; A processor, configured to execute the computer program and implement the multi-core simulation method based on a distributed hardware-in-the-loop simulation system according to any one of claims 1 to 6 when executing the computer program.

8. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which, when executed by a processor, enables the processor to implement the multi-core simulation method based on a distributed hardware-in-the-loop simulation system according to any one of claims 1 to 6.

Images