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

Abstract

The invention relates to the field of semi-physical simulation, in particular to a multi-core simulation method and device based on a distributed semi-physical simulation system and a medium. The method comprises the steps of obtaining a plurality 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 task coupling degree; binding the semi-physical simulation objects in the same associated simulation group with the simulation core of the same lower computer to obtain a plurality of pairs of bound simulation relationships; a simulation instruction generated by the upper computer is transmitted to a scheduling core, and the scheduling core is used for obtaining a sub-simulation instruction of a simulation core in the lower computer from the simulation instruction based on the binding simulation relation and issuing the sub-simulation instruction to a corresponding target simulation core, so that the target simulation core performs simulation operation according to the sub-simulation instruction to obtain a simulation result; and a plurality of simulation results calculated by the lower computer are transmitted to the upper computer, so that the simulation instruction is updated, the continuous propulsion of the simulation process is ensured, and the practicability of the semi-physical simulation system is improved.

Description

Technical Field

[0001] This application relates to the field of hardware-in-the-loop simulation, and particularly to a multi-core simulation method, device, and medium based on a distributed hardware-in-the-loop simulation system. Background Art

[0002] With the development of modern industry and technology, the complexity of systems has been increasing continuously, posing higher requirements for testing and verification. Traditional pure digital simulation cannot fully simulate the characteristics of actual physical systems, while full physical testing is costly and risky. Against this background, hardware-in-the-loop (HiL) simulation, as a technology that combines the advantages of both, has emerged.

[0003] Hardware-in-the-loop simulation is a real-time simulation technology that tests the behavior of control systems by integrating real hardware into the simulation environment. This technology can not only provide a test environment close to the actual situation but also reduce development costs and time while ensuring safety. HiL technology is widely used in many fields such as aerospace, automotive engineering, and power electronics and has become an indispensable part of the R & D process.

[0004] For example, the invention patent application with the publication number CN110543105A discloses a general-purpose hardware-in-the-loop simulation system, which is a hardware-in-the-loop simulation system composed of a simulation management computer, a real-time simulator, an adapter box, a comprehensive control box, terminal blocks, and an Ethernet. This general-purpose hardware-in-the-loop simulation system has been applied in the design of flight control hardware-in-the-loop simulation systems, with wide adaptability, strong real-time performance, good scalability, and the ability to switch simulation signals with physical objects or physical simulation signals in real time. The real-time simulator uses a multi-core processor to assign different models or tasks to different CPUs and separates the communication interface program from the simulation model.

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

[0006] The main objective of this application is to provide a multi-core simulation method, device, and medium based on a distributed hardware-in-the-loop simulation system. To solve the above-mentioned technical problems, this application specifically adopts the following technical solutions: In the first aspect of this application, a multi-core simulation method based on a distributed hardware-in-the-loop simulation system is provided. The distributed hardware-in-the-loop simulation system includes a host computer and several slave computers, and each slave computer includes at least one scheduling core and several simulation cores. The method includes: S101. Obtain a number of hardware-in-the-loop simulation objects in the simulation task; S102. Analyze the task coupling degree among the number of hardware-in-the-loop simulation objects, and divide the number of hardware-in-the-loop simulation objects into multiple associated simulation groups according to the task coupling degree; S103. Bind each hardware-in-the-loop simulation object within the same associated simulation group to each simulation core of the same lower computer respectively to obtain a number of pairs of bound simulation relationships; S104. Transmit the simulation instructions generated by the upper computer to the scheduling core, and the scheduling core is configured to obtain a number of sub-simulation instructions corresponding to a number of simulation cores in the lower computer to which the scheduling core belongs from the simulation instructions based on the bound simulation relationships, and send the sub-simulation instructions to the corresponding target simulation cores, so that the target simulation cores perform simulation operations according to the corresponding sub-simulation instructions to obtain simulation results; S105. Transmit the number of simulation results calculated by the lower computer to the upper computer to update the simulation instructions.

[0007] In some embodiments, the indicators of the task coupling degree include at least one of: entity attribute similarity, simulation task matching degree, and entity interaction frequency.

[0008] In some embodiments, the method further includes: the upper computer and the scheduling core in the lower computer perform information interaction based on reflective memory; and / or, the scheduling core in the lower computer and a number of the simulation cores perform information interaction based on shared memory.

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

[0010] In some embodiments, the method further includes: after the scheduling core sends the sub-simulation instructions to the corresponding target simulation cores, if no update of the target simulation cores is detected for a continuous first preset duration, identify the corresponding target simulation cores as abnormal simulation cores; predict the predicted simulation results of the abnormal simulation cores based on the latest simulation results and / or historical simulation results of at least one of the target simulation cores in the lower computer, and upload the predicted simulation results to the upper computer.

[0011] 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.

[0012] In some embodiments, the method also 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.

[0013] 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 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 idle simulation cores in other lower computers; and / or, 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.

[0014] A second aspect of the present application is to provide a computer device, the device comprising: Memory for storing computer programs; 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.

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

[0016] Beneficial effects: 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 among the hardware-in-the-loop simulation objects (including entity attribute similarity, simulation task matching degree and interaction frequency), the hardware-in-the-loop simulation objects with high tightness are divided into associated simulation groups, and each associated simulation group is bound to the simulation core of the same physical lower computer for operation. Thus, the specific simulation tasks of multiple target simulation cores in each lower computer have a high degree of relevance. On the one hand, the associated simulation groups can share some data, and combined with physical proximity, the data transmission efficiency between the upper and lower computers can be effectively improved. On the other hand, it provides a feasible basis for predicting the simulation results of abnormal simulation cores inside the lower computer, ensuring the continuous progress of the simulation process and improving the practicability of the hardware-in-the-loop simulation system.

[0017] Specifically, some of the data used by the associated simulation groups can overlap, such as environmental data like terrain and wind speed, which can effectively reduce data redundancy in the information transmission between the upper and lower computers; the simulation instructions corresponding to the associated simulation groups are relatively continuous in distribution, and the scheduling center can quickly read the sub-simulation instructions corresponding to all cores; the simulation tasks corresponding to the associated simulation groups are relatively unified in 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 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.

[0018] Furthermore, a hybrid communication architecture of reflective memory and shared memory is adopted: low-latency information exchange is realized between the upper computer and the lower computer through reflective memory, and data is transmitted between the internal scheduling core and the simulation core of the lower computer using shared memory, further reducing communication latency.

[0019] In addition, at the initial division, task relevance is the main guiding factor, and during actual operation, dynamic adjustment is carried out in combination with the actual states of each lower computer and each simulation core, and a load monitoring and multi-level fault tolerance mechanism is constructed to further improve the practicability of the hardware-in-the-loop simulation system.

[0020] At the macroscopic level, the running load of the lower computer is monitored in real time. When a high-load risk of the lower computer is detected, the upper computer can quickly migrate some of the hardware-in-the-loop simulation objects therein to other healthy nodes to reduce the running load of the lower computer and avoid the failure of the lower computer. Moreover, for the overloaded lower computer, a more refined adjustment strategy is made according to factors such as the historical simulation step length of the simulation core or the current task coupling degree, for example, preferentially migrating the entity group with low task coupling degree to the idle node to achieve load optimization.

[0021] At the micro level, the real-time monitoring of the core operation process of the simulation is carried out. If the target simulation core fails to be updated after a timeout, a two-level fault tolerance mechanism is enabled: for the first-level fault tolerance, there is no need to interact with the upper computer or other lower computers. According to the historical simulation data and / or current simulation data in the lower computer where the abnormal simulation core is located, and by using the high correlation between the specific simulation tasks of multiple target simulation cores in each lower computer, the simulation result of the abnormal simulation core can be quickly and accurately calculated within the lower computer; for the second-level fault tolerance, if the abnormality persists for more than the second preset duration, it is determined that the simulation core fails, the binding relationship with the hardware-in-the-loop simulation object is released, and the task is re-allocated to an idle core within the same node or migrated to other healthy nodes. Brief Description of the Drawings

[0022] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. In all the drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn to scale. Obviously, the following-described drawings are some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0023] Figure 1 is a schematic block diagram of a multi-core simulation method based on a distributed hardware-in-the-loop simulation system provided by an embodiment of the present application; Figure 2 is a schematic flowchart of a multi-core simulation method based on a distributed hardware-in-the-loop simulation system provided by an embodiment of the present application; Figure 3 is a schematic block diagram of the binding of an associated simulation group and a simulation core provided by an embodiment of the present application; Figure 4 is a schematic block diagram of the structure of a computer device provided by an embodiment of the present application. Detailed Embodiments

[0024] To make the objectives, technical solutions, and advantages of the embodiments of the present application clearer, the following will clearly and completely describe the technical solutions in the embodiments of the present application with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are some, but not all, of the embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the scope of protection of the present application.

[0025] In this document, suffixes such as "module", "component", or "unit" used to represent elements are only for the convenience of explaining this application, and they have no specific meaning in themselves. Therefore, "module", "component", or "unit" can be used interchangeably.

[0026] In this document, the orientation or positional relationship indicated by terms such as "upper", "lower", "inner", "outer", "front", "rear", "one end", "the other end", etc. is based on the orientation or positional relationship shown in the drawings. It is only for the convenience of describing this application and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, so it cannot be understood as a limitation to this application. In addition, the terms "first" and "second" are only used for descriptive purposes and cannot be understood as indicating or implying relative importance.

[0027] In this document, unless otherwise clearly specified and defined, terms such as "installed", "provided with", "connected", etc. should be understood in a broad sense. For example, "connected" can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection, a direct connection, or an indirect connection through an intermediate medium, and it can be the communication inside two elements. For those of ordinary skill in the art, the specific meanings of the above terms in this application can be understood according to specific situations.

[0028] In this document, "and / or" includes any and all combinations of one or more of the listed related items.

[0029] In this document, "a plurality of" means two or more, that is, it includes two, three, four, five, etc.

[0030] It should be noted that in this document, the term "comprising", "including", or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements not only includes those elements, but also includes other elements not explicitly listed, or elements inherent to such a process, method, article, or device. Without further limitation, an element defined by the statement "comprising one..." does not exclude the existence of additional identical elements in the process, method, article, or device comprising that element.

[0031] In multi-core hardware-in-the-loop simulation, multiple cores need to frequently complete a large amount of data interaction work. Especially in large-scale and high-concurrency collaborative simulation processes such as UAV swarms, frequent cross-machine data interaction is required between UAVs that are simulated in different slave computers, resulting in communication delays and bandwidth waste, and then leading to a rapid accumulation of communication overhead, becoming the performance bottleneck of the entire system, and further reducing the practicality of the hardware-in-the-loop simulation system.

[0032] 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 among the hardware-in-the-loop simulation objects (including entity attribute similarity, simulation task matching degree and interaction frequency), the hardware-in-the-loop simulation objects with high tightness are divided into associated simulation groups, and each associated simulation group is bound to the simulation core of the same physical lower computer to run. The physical proximity is utilized to improve the data transmission efficiency between the upper and lower computers, and further improve the practicability of the distributed hardware-in-the-loop simulation system. It should be understood that there is some shared overlapping data within the associated simulation group, such as environmental data like terrain and wind speed, which can effectively reduce the data redundancy in the information transmission between the upper and lower computers; the simulation instructions corresponding to the associated simulation group are relatively continuous, and the scheduling center can quickly read the sub-simulation instructions corresponding to all cores; the simulation tasks corresponding to the associated simulation group are relatively unified in 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 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.

[0033] In some embodiments, the distributed hardware-in-the-loop simulation system includes an upper computer and several lower computers, and each of the lower computers includes at least one scheduling core and several simulation cores.

[0034] Among them, the upper 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 instructions, receiving and integrating simulation results, monitoring the system operation status, etc. The simulation instructions generated by the upper computer are control signals that drive the operation of the hardware-in-the-loop simulation system, and can be dynamically optimized based on the feedback results during the simulation process. They can be used to indicate environmental parameters such as wind speed, temperature, and terrain data, and can also be used to indicate the real-time operation requirements, initial positions, speeds, postures, etc. of all hardware-in-the-loop simulation objects.

[0035] Among them, the lower computer is a distributed physical execution node, and each node includes at least one scheduling core and multiple simulation cores, responsible for receiving the upper computer instructions and completing high-precision simulation calculations. The scheduling core is the control center within the lower computer responsible for task scheduling and communication, responsible for parsing the upper computer instructions, distributing the 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 bound to the hardware-in-the-loop simulation objects (such as aircraft, radar) in the lower computer, used to execute real-time calculations (such as dynamic models, sensor simulations). It should be understood that the lower computer includes multiple CPU cores, and other CPU cores except the scheduling core can all be simulation cores.

[0036] Exemplarily, in a distributed real-time parallel hardware-in-the-loop simulation system, a hierarchical host-slave architecture is adopted to achieve efficient simulation. The host computer module is an ordinary computer motherboard running the Windows system, which is installed with the control software corresponding to the hardware-in-the-loop simulation. Its main functions are to configure the test state, control the experimental process, and store and process the test data. The slave computer selects a quad-core industrial computer, installs the board cards for communicating with external devices in the hardware-in-the-loop simulation, and runs the RTX real-time operating system that supports multi-core parallel computing. A set of distributed hardware-in-the-loop simulation system has multiple sets of slave computers. The slave computer mainly runs the simulation scheduling management program and real-time simulation, responds to the instructions of the host computer in real time, schedules the simulation tasks in real time according to the drive of the clock signal, and completes the simulation test.

[0037] In some embodiments, the method further includes: the host computer and the scheduling core in the slave computer perform information interaction based on reflective memory; and / or, the scheduling core in the slave computer and several of the simulation cores perform information interaction based on shared memory.

[0038] Among them, reflective memory is a real-time data sharing technology across physical nodes. By using dedicated hardware (such as reflective memory cards), a globally unified address space is constructed to achieve deterministic low-latency communication. The scheduling cores of the host computer and the slave computer interact based on reflective memory. For example, after the host computer writes the simulation instruction into the local reflective memory card, the data is automatically synchronized to the corresponding memory areas of all slave computer nodes, ensuring the real-time and consistency of instruction transmission, and is suitable for high-frequency instruction issuance and result feedback across devices. Another example is that any slave computer node can upload the simulation result of this node to the host computer through reflective memory.

[0039] Among them, shared memory is a direct memory access mechanism between multiple cores within the same physical node, and zero-copy data exchange is achieved through memory mapping. The scheduling core and the simulation cores in the slave computer interact based on shared memory, and at the same time, the timing correctness of the simulation within the group is ensured based on a unified clock source. For example, the scheduling core writes the sub-instructions into the shared memory area, and the simulation cores directly read and write the calculation results into the shared memory, avoiding the communication overhead between processes and improving the data transmission efficiency within the node.

[0040] It should be understood that the host computer and the slave computer directly exchange data through low-latency reflective memory, avoiding the network protocol overhead; within the slave computer, shared memory is used to achieve fast data interaction between the scheduling core and the simulation cores, reducing the communication delay between processes. That is to say, reflective memory supports the high-speed instruction issuance and result reporting between the host computer and the slave computer, and shared memory ensures the real-time cooperation between the cores of the slave computer. The combination of the two not only meets the low-latency requirements of cross-node communication but also realizes efficient data sharing within a single machine, reducing the overall communication load.

[0041] Please refer to Figure 1 ,Figure 1 It is a schematic block diagram of a multi-core simulation method based on a distributed hardware-in-the-loop simulation system provided by an embodiment of the present application. As Figure 1 shown, the host computer can transmit simulation instructions to the scheduling core CPU-0 in the lower computer through reflective memory. The scheduling core CPU-0 extracts the sub-simulation instructions related to this lower computer in the simulation instructions and allocates them to the corresponding simulation cores CPU-1, CPU-2, CPU-N, etc. through shared memory. These simulation cores execute specific simulation tasks for the received sub-simulation instructions and feedback the simulation results to the scheduling core CPU-0 through shared memory. The scheduling core CPU-0 then uploads these simulation results to the host computer through reflective memory. Further, each simulation core starts the simulation model and hardware device through a simulation driver, performs calculations through the simulation model, and feeds back the simulation results. The interaction between the lower computer and the hardware device can also be completed using reflective memory. Among them, the simulation model refers to a mathematical or logical model used to simulate the behavior of a 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, and is used to study the movement law of the aircraft, predict results, or optimize decisions. Specifically, it can be a Simulink model.

[0042] Next, in conjunction with the accompanying drawings, some embodiments of the present application will be described in detail. Without conflict, the following embodiments and the features in the embodiments can be combined with each other. Please refer to Figure 2 , Figure 2 It is a schematic flowchart of a multi-core simulation method based on a distributed hardware-in-the-loop simulation system provided by an embodiment of the present application. As Figure 2 shown, an embodiment of the present application provides a multi-core simulation method based on a distributed hardware-in-the-loop simulation system, which is applied to a distributed hardware-in-the-loop simulation system. The distributed hardware-in-the-loop simulation system includes a host computer and several lower computers, and each lower computer includes at least one scheduling core and several simulation cores; the method includes S101 to S105.

[0043] S101. Obtain several hardware-in-the-loop simulation objects in the simulation task.

[0044] Specifically, in the process of hardware-in-the-loop simulation, the simulation task refers to the test and verification by combining real hardware devices and virtual simulation models, including several elements such as preset hardware-in-the-loop simulation objects, environmental parameters, task objectives, time constraints, and interaction rules. Among them, the hardware-in-the-loop simulation object refers to a simulation object jointly composed of a real physical hardware device and a virtual simulation model in the hardware-in-the-loop simulation, and can interact with the simulation environment in real time.

[0045] Exemplarily, by parsing the simulation scenario configuration file input by the user, all the hardware-in-the-loop simulation objects participating in the simulation are extracted, and the class identification types (such as aircraft, radar), attributes (such as initial coordinates, communication frequency, environmental dependence), and interaction requirements with other hardware-in-the-loop simulation objects are read from the task description file. For example, in the simulation of an unmanned aerial vehicle (UAV) swarm, multiple UAVs, ground control stations, and other hardware-in-the-loop simulation objects need to be extracted, and their characteristics such as flight parameters and communication delays are marked, providing data support for subsequent analysis of the task coupling degree between hardware-in-the-loop simulation objects and division of associated simulation groups, ensuring that the physical allocation of hardware-in-the-loop simulation objects matches their logical relevance.

[0046] S102. Analyze the task coupling degree between several hardware-in-the-loop simulation objects, and divide the several hardware-in-the-loop simulation objects into multiple associated simulation groups according to the task coupling degree.

[0047] Among them, the task coupling degree refers to the degree of tightness of the association between hardware-in-the-loop simulation objects. Exemplarily, the indicators of the task coupling degree include at least one of entity attribute similarity, simulation task matching degree, and entity interaction frequency. Among them, the entity attribute similarity refers to the degree of consistency of the static characteristics between hardware-in-the-loop simulation objects, including physical parameters (such as equipment model, sensor type, range, endurance), simulation model parameters (such as control period, accuracy requirement), communication protocol, etc. The simulation task matching degree refers to the collaborative dependence relationship of the dynamic behaviors between hardware-in-the-loop simulation objects, such as task objective collaboration (such as UAV swarm collaborating to execute a rescue task), synchronization requirement (such as UAV swarm synchronously turning), data flow direction (such as the output of a sensor being the input of a controller). The entity interaction frequency refers to the number of interaction events between hardware-in-the-loop simulation objects per unit time. For example, the periodic communication interval and event-driven interaction frequency between multiple hardware-in-the-loop simulation objects.

[0048] In some embodiments, the indicators of the task coupling degree may further include the time synchronization accuracy requirement. For example, some hardware-in-the-loop simulation objects need to strictly align timestamps, and such hardware-in-the-loop simulation objects need to be grouped into the same associated simulation group to utilize the unified clock source within the group.

[0049] Specifically, the indicators of the task coupling degree can be flexibly selected according to the specific hardware-in-the-loop simulation scenario. Exemplarily, the indicators of the task coupling degree are set with priorities. For example, if the coupling degree of a certain hardware-in-the-loop simulation object with multiple associated simulation groups is close, and the entity interaction frequency is the highest-priority task coupling degree indicator, the corresponding hardware-in-the-loop simulation object is preferentially included in the group with the highest entity interaction frequency; for another example, when the attribute similarities of multiple hardware-in-the-loop simulation objects are all relatively high, only the task matching degree and entity interaction frequency need to be considered; for another example, the comprehensive task coupling degree can also be determined according to indicators such as attribute similarity, task matching degree, and entity interaction frequency.

[0050] In some embodiments, the task coupling degree between semi-physical simulation objects is quantified through a preset algorithm. The preset algorithm can be a preset clustering algorithm or a pre-trained coupling degree prediction model. For example, in the simulation of an unmanned aerial vehicle (UAV) formation, multiple UAVs need to communicate frequently to share data such as attitude and speed, and the environments they are in are also highly similar. Their entity attribute similarity, simulation task matching degree, and entity interaction frequency are all high. Therefore, they are determined to be high-coupling semi-physical simulation objects. Subsequently, through the clustering algorithm, the semi-physical simulation objects with a higher task coupling degree are divided into an associated simulation group.

[0051] 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 a task coupling degree higher than the coupling degree threshold are grouped into the same associated simulation group. For example, in the simulation of a UAV formation, the UAVs that need to cooperate in real-time for path planning within the same formation are grouped into an associated simulation group due to their high interaction frequency and strong task dependence; while the UAVs that independently perform reconnaissance tasks and only need to report data periodically may form separate groups. Among them, the resource constraints can be the number of lower-level machines, the number of simulation cores in the lower-level machines, the computing power of the simulation cores, etc., so as to match the computing requirements or the number of semi-physical simulation objects in each associated simulation group with the computing power and the number of simulation cores of the lower-level machines, and the computing resources of the simulation cores need to be taken into account.

[0052] Exemplarily, if the total computing requirement of the semi-physical simulation objects in an associated simulation group exceeds the computing power of a single lower-level machine, or the total number of the semi-physical simulation objects in an associated simulation group exceeds the number of simulation cores of a single lower-level machine, the associated simulation group is further split to balance the load, so that the semi-physical simulation objects in each associated simulation group are bound to multiple simulation cores of the same lower-level machine. For example, in the simulation of a UAV formation, the number of multiple UAVs in the same formation is higher than the number of simulation cores of a single lower-level machine. At this time, 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 division, so that the associated simulation group takes into account the computing resources of the simulation cores.

[0053] It should be understood that the associated simulation group is a logical set composed of high-task-coupling semi-physical simulation objects. By physically deploying them in close proximity, the cross-node communication overhead is reduced. At the same time, it is ensured that the semi-physical simulation objects within the group share environmental data (such as a unified terrain model, wind speed parameters) to reduce redundant transmission, and the simulation cores bound to the same lower-level machine share a high-precision clock source to ensure strict timing synchronization of interaction events, thereby optimizing the performance of the entire simulation system.

[0054] S103. Bind each hardware-in-the-loop simulation object within the same associated simulation group to each simulation core of the same lower-level computer respectively, to obtain several pairs of bound simulation relationships.

[0055] Among them, the bound simulation relationship is a fixed mapping relationship established between the hardware-in-the-loop simulation object and the simulation core, ensuring that each hardware-in-the-loop simulation object performs simulation operations on a specific simulation core, forming a one-to-one task execution unit.

[0056] Specifically, establish a one-to-one matching relationship between each hardware-in-the-loop simulation object within a certain associated simulation group and a specific simulation core of the same lower-level computer, ensuring that all hardware-in-the-loop simulation objects within the group are physically bound to different simulation cores of the same lower-level computer for operation.

[0057] Please refer to Figure 3 , Figure 3 which is a schematic block diagram of the binding of an associated simulation group and a simulation core provided by an embodiment of the present application; as Figure 3 shown, the lower-level computer is a quad-core industrial computer. An associated simulation group includes two drones A and B flying in coordination and a ground control station E. These three hardware-in-the-loop simulation objects are respectively assigned to three simulation cores of this quad-core industrial computer, such as Figure 3 CPU-1, CPU-2, CPU-N in

[0058] In some embodiments, the method further includes: before performing step S102, reserving a standby lower-level computer or a standby simulation core, so that when performing step S102, the standby lower-level computer or the standby simulation core does not participate in the statistics of the number of simulation cores, and when performing step S103, the standby lower-level computer or the standby simulation core is not bound to the hardware-in-the-loop simulation object; or, after performing step S103, statistically analyzing the core redundancy situation of each lower-level computer, and selecting a standby lower-level computer or a standby simulation core; when it is monitored that a simulation core fails or is overloaded, automatically switch to the standby lower-level computer or the standby simulation core to maintain task continuity.

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

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

[0061] It should be noted that in the initialization stage, the scheduling core writes the bound simulation relationship into the shared memory and loads the corresponding simulation model, environmental parameters, and interactive interface configuration (such as input / output memory addresses, etc.) for each simulation core to execute the corresponding hardware-in-the-loop simulation task.

[0062] S105. Transmit several simulation results obtained by the lower computer calculation to the upper computer to update the simulation instruction.

[0063] Specifically, the scheduling core of the lower computer transmits the simulation results (such as UAV position, sensor data, environmental status) calculated by all simulation cores in the associated simulation group to the upper computer. The upper computer integrally analyzes the simulation results of multiple nodes in real time from a global perspective and dynamically generates new simulation instructions, thereby ensuring the continuous optimization of the simulation task in dynamic real-time simulation by using the real-time feedback of the lower computer and the global decision-making ability of the upper computer.

[0064] It should be understood that the simulation instruction is dynamically updated based on the real-time simulation result to promote the progress of the simulation task and improve the accuracy and practicality of the final simulation result. For example, in the UAV rescue simulation, the initial simulation instruction is "go straight for 500 meters", but the simulation result may feedback that the infrared sensor is interfered by thick smoke. The upper computer can update the simulation instruction to "reduce the speed to 2m / s and drive in the right front direction". Another example is that the initial simulation instruction is to detect the environment in place, and the simulation result feedback shows that the environment at the current position has been detected. The upper computer can update the simulation instruction to "go straight for 50 meters to continue detecting the environment". This process forms a closed-loop control to ensure the continuous optimization of the simulation task according to the dynamic feedback.

[0065] In some embodiments, after the hardware-in-the-loop simulation objects in the associated simulation group are bound to the same lower computer, low-latency communication between simulation cores can also be achieved by using the shared memory, avoiding the bandwidth occupation of cross-node reflective memory. For example, UAV A and ground control station E need to interact with high-frequency flight state data. After being bound to the same lower computer, they can directly transmit through the shared memory instead of communicating across machines through reflective memory.

[0066] Exemplarily, in a detection task, the host computer first generates global simulation instructions, such as "UAV A flies 50 meters westward, UAV B flies 20 meters eastward, and UAV C returns to the base", and sends the simulation instructions to the scheduling cores of all slave computers through reflective memory. After receiving the instructions, the scheduling core (such as CPU-0) quickly locates the hardware-in-the-loop simulation object responsible for this slave computer based on the preset bound simulation relationship. For example, UAV A bound to CPU-1 and UAV B bound to CPU-2, and extracts the corresponding sub-simulation instructions from the global instructions. The scheduling core sends the sub-simulation instruction of "UAV A flies 50 meters westward" to CPU-1; and sends the sub-simulation instruction of "UAV B flies 20 meters eastward" to CPU-2.

[0067] After each simulation core receives the sub-simulation instruction, it immediately starts the simulation operation. During the operation, the simulation core can directly read the real-time data of other cores in the group through shared memory (for example, UAV A can read the real-time position of UAV B) to ensure the accuracy of the collaborative task. For example, CPU-1 calculates the new attitude, speed, and path according to the flight model of UAV A, and CPU-2 synchronously processes the obstacle avoidance logic of UAV B. After the operation is completed, each simulation core writes the simulation result into the shared memory in real time. The scheduling core then obtains the simulation result through the shared memory and uploads it to the host computer in a package through reflective memory.

[0068] In some embodiments, the method further includes: when the scheduling core monitors that any one 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, controlling the scheduling core to obtain the simulation results uploaded by at least one target simulation core in the shared memory based on a preset duration, and uploading the simulation results to the host computer.

[0069] Exemplarily, for immediate response upload of simulation results, that is, when the scheduling core monitors that any simulation core writes the simulation result into the shared memory, it immediately triggers the data upload process, which is applicable to critical data that requires quick response. For example, the simulation core uses 1 ms as the simulation step, and uploads the simulation result to the scheduling core every 1 ms, and the scheduling core immediately triggers the data upload process.

[0070] Exemplarily, for the periodic upload of simulation results, that is, the scheduling core scans the shared memory at a period (i.e., a preset duration) to collect the simulation results uploaded by all simulation cores during this period, reducing the transmission overhead of high-frequency small data packets. For example, in the simulation of an unmanned aerial vehicle formation, the scheduling core packs the data such as the positions and speeds of each unmanned aerial vehicle collected every 5 ms and uploads them to the host computer through reflective memory to ensure the synchronous update of the global state. Among them, the preset duration is the periodic data synchronization time interval preset in the hardware-in-the-loop 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 requirements of task criticality and real-time performance. For example, a shorter period is set for high-real-time control tasks, which is not limited here.

[0071] It should be understood that the two different upload trigger mechanisms can be used in combination. For critical hardware-in-the-loop simulation objects, immediate response upload can be adopted to ensure the instant feedback of critical data. For ordinary hardware-in-the-loop simulation objects, periodic upload can be adopted to ensure the stable transmission of regular data and the continuity of the overall simulation process. This combined mechanism not only avoids high-frequency communication driven by pure events but also solves the delay problem of periodic polling, balancing real-time performance and communication load.

[0072] In some embodiments, the method further includes: after the scheduling core issues the sub-simulation instruction to the corresponding target simulation core, if the update of the target simulation core is not detected for a continuous first preset duration, the corresponding target simulation core is identified as an 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, the predicted simulation result of the abnormal simulation core is predicted, and the predicted simulation result is uploaded to the host computer.

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

[0074] Obtain the target simulation cores of the simulation settlement that is being or has been conducted 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.

[0075] 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 gain response time for subsequent possible simulation core migration.

[0076] For example, in a UAV formation simulation, if the simulation core of aircraft D fails to update its attitude data for 50 ms after the scheduling core issues a control command, which exceeds the first preset duration, 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 a relative formation, the current position of aircraft D can be predicted and inferred to generate a predicted simulation result.

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

[0078] 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.

[0079] That is to say, the predicted simulation results and abnormal conditions (i.e. abnormal semi-physical simulation objects that cannot be simulated normally) are uploaded to the host computer through reflective memory to maintain the continuity of the global simulation process, and at the same time can trigger the host computer to decide whether to change the simulation instructions. For example, in the UAV rescue simulation, if the simulation core of UAV B is abnormal and it is predicted that it cannot continue searching, and at this time the search task of UAV B is the highest priority task or will highly affect the subsequent task arrangement, the host computer can dynamically adjust the instructions and instruct UAV A to expand the search area to cover the search range of UAV B, ensuring the overall advancement of the task, while tolerating local failures and minimizing the impact on the global simulation.

[0080] 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.

[0081] The second preset duration is the time threshold for the scheduling core to determine that the abnormal simulation core needs to be forced to migrate, such as 50 simulation steps. If the abnormality lasts for more than this duration and is not recovered, the rebinding of the semi-physical simulation object is triggered. Correspondingly, the idle simulation core refers to the allocable computing unit that is not currently bound to the semi-physical simulation object.

[0082] 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 the second preset time, the migration mechanism is triggered. The scheduling core first releases the binding relationship between the abnormal simulation core and 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.

[0083] It should be understood that at the micro level, the real-time monitoring of the simulation core operation process is carried out. If the target simulation core fails to update after a timeout, a two-level fault tolerance mechanism is enabled: the first-level fault tolerance does not require interaction 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 using the high correlation between the specific simulation tasks of multiple target simulation cores in each lower computer, a feasible basis is provided for predicting the simulation results of the abnormal simulation core. The simulation results of the abnormal simulation core can be quickly and accurately calculated within the lower computer to ensure the continuous progress of the simulation process; for the second-level fault tolerance, if the abnormality persists for more than the second preset duration, it is determined that the simulation core fails, the binding relationship between it and the semi-physical simulation object is released, and the task is reallocated to the idle core within the same node or migrated to other healthy nodes. Thus, by hierarchical processing (prediction first and then migration), the balance between real-time performance and reliability is achieved. Short-term abnormalities rely on the internal associated data of the lower computer for prediction to maintain simulation continuity, while long-term faults ensure task recovery through dynamic resource adjustment, realizing fault isolation and rapid recovery, and ensuring the robustness of the long-term operation of the system.

[0084] 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 one of the lower computers exceeds a preset load threshold, identifying the corresponding lower computer as an overloaded lower computer; changing some of the binding relationships in the overloaded lower computer to migrate some of the semi-physical simulation objects in the same associated simulation group to other lower computers.

[0085] Among them, the operating load is a resource occupancy index during the real-time operation of the lower computer, including real-time parameters such as CPU usage rate, memory occupancy, and task execution delay, and is used to evaluate whether its current processing capacity is close to the limit. Correspondingly, the preset load threshold is a safety upper limit value preset according to the hardware performance of the lower computer. For example, the CPU usage rate > 85% or the memory occupancy > 90% for three consecutive cycles is used to trigger the load balancing mechanism.

[0086] Specifically, the operating load data of each lower computer is periodically collected. When it is detected that a lower computer exceeds the preset load threshold, it is marked as an overloaded lower computer, the binding relationship between some semi-physical simulation entities and the original simulation core is released, and its task configuration is migrated to the idle simulation core of other lower computers, such as a reserved standby lower computer. For example, if a lower computer is overloaded due to simultaneously simulating 5 unmanned aerial vehicles, 1 unmanned aerial vehicle can be migrated to the idle simulation core of another lower computer.

[0087] It should be understood that due to the high coupling of the simulation tasks of the hardware-in-the-loop simulation objects in the associated simulation group, it may be that the specific simulation tasks of multiple hardware-in-the-loop simulation objects in a certain stage need to be of high density and high computational volume. At this time, it may lead to the need for a large amount of computing power for multiple target simulation cores in the lower computer, and then lead to an increase or overload of the operating load of the lower computer in this stage. If a lower computer is overloaded due to newly added high-density tasks, by dynamically adjusting the binding relationship, some hardware-in-the-loop simulation objects can be migrated to other nodes for simulation calculation, and the overload risk can be dispersed to other lower computers to avoid the simulation interruption of the overloaded lower computer.

[0088] In some embodiments, the method further includes: detecting the historical simulation step lengths of several of the 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 hardware-in-the-loop simulation object, and binding the corresponding hardware-in-the-loop simulation object to an idle simulation core in another lower computer.

[0089] Among them, the historical simulation step length is the computing time required for a simulation core to execute a single simulation cycle, which is used to measure its computing efficiency and reflect the real-time processing ability of the core. Correspondingly, the preset simulation step length is the upper limit of the standard solution time required for the simulation task, which is used to determine the potential or existing cumulative delay of the simulation core.

[0090] Among them, the historical simulation step length growth rate is the change trend of the step length in multiple consecutive cycles. For example, if the last 10 simulation step lengths increase from 0.9ms to 20ms, the growth rate is about 2122.22%. Correspondingly, the preset growth rate is the preset maximum increasing threshold, which is used to determine the potential or existing performance degradation of the simulation core.

[0091] Specifically, when it is detected that a certain lower computer is overloaded, analyze the historical simulation step lengths of its respective simulation cores. If the historical simulation step length of a certain core exceeds the preset simulation step length, or its historical simulation step length growth rate exceeds the preset growth rate, it is marked as an overloaded simulation core, and the corresponding hardware-in-the-loop simulation object is re-bound to an idle simulation core in another lower computer. Thus, through the performance indicators of the simulation core, the cores with high load or trend-based overload are preferentially migrated, avoiding ineffective migration caused by blind migration and optimizing the overall resource utilization rate at the same time.

[0092] In some embodiments, detect the current task coupling degree of each hardware-in-the-loop 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 the preset coupling degree threshold, release the binding relationship between the corresponding overloaded simulation object and the simulation core, and bind the overloaded simulation object to an idle simulation core in another lower computer.

[0093] Specifically, the current task coupling degree is the association strength between the hardware-in-the-loop simulation object that is calculated in real time during the simulation process and other hardware-in-the-loop simulation objects within the associated simulation group to which it belongs. It can be updated based on the latest interaction data, such as the average interaction frequency, attribute similarity, and task dependency relationship within the most recent 10 preset cycles, and is used to judge the feasibility of migrating the hardware-in-the-loop simulation object. Correspondingly, the preset coupling degree threshold is a preset loose coupling determination criterion, which is used to identify the hardware-in-the-loop simulation objects that are weakly associated with other hardware-in-the-loop simulation objects within the group and can be preferentially migrated.

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

[0095] Specifically, the hardware accelerator is a dedicated computing module integrated in the lower computer, which can provide higher computing efficiency and real-time performance for specific simulation tasks compared to a general-purpose CPU. For the specific module, reference can be made to related technologies and will not be limited here. When it is detected that the current task coupling degree of all hardware-in-the-loop simulation objects within the associated simulation group of the overloaded lower computer is higher than the preset coupling degree threshold, at this time, strong association splitting and migration of the hardware-in-the-loop simulation objects will incur a large migration cost, or it will lead to an increase in communication resources after migration. In a strongly coupled scenario, hardware-level acceleration is used to avoid simulation interruption, forming a complement to the migration strategy.

[0096] It should be understood that according to the task coupling degree of the hardware-in-the-loop simulation objects within the associated simulation group (such as preferentially migrating the low-coupling hardware-in-the-loop simulation objects) or the historical simulation step length (such as migrating the hardware-in-the-loop simulation object with the longest migration calculation time), the hardware-in-the-loop simulation objects to be preferentially migrated are determined, and at the same time, the hardware accelerator is combined to minimize the migration cost to ensure the reliability and real-time performance of the hardware-in-the-loop simulation. For example, in the simulation of an unmanned aerial vehicle cluster, the low-coupling radar module responsible for environmental perception in the overloaded node is migrated to the idle node, while the high-coupling flight control core still runs locally, which not only relieves the load pressure but also maintains the core collaboration efficiency.

[0097] In some embodiments, the operating load of each slave computer is continuously monitored. When the operating load of any one of the slave computers exceeds a preset load threshold, the scheduling core of each slave computer continuously collects the status of its own resources (such as CPU / memory occupancy rate, simulation core queue depth), and periodically reports it to the master computer. Based on historical data (such as the computational amount of the simulation tasks that each slave computer needs to execute in history) and current task characteristics (such as the complexity of the current simulation task), the master computer predicts the future load trend of each slave computer. If the future load trend exceeds the preset load threshold, the corresponding slave computer is identified as an overloaded slave computer; part of the binding relationship in the overloaded slave computer is changed to migrate some of the hardware-in-the-loop simulation objects in the same associated simulation group to other slave computers.

[0098] In some embodiments, if the tightness of an associated simulation group decreases due to task evolution (such as the drone formation in the battlefield splitting up to perform reconnaissance), the master computer can actively split the group and reallocate it to balance the load.

[0099] It should be understood that in the embodiments of the present application, by analyzing task coupling degree indicators such as entity attribute similarity, simulation task matching degree, and interaction frequency, highly associated hardware-in-the-loop simulation objects are divided into associated simulation groups and bound to the simulation cores of the same slave computer. Physical proximity is used to reduce cross-node communication, and at the same time, environmental data (such as terrain, wind speed) is shared to reduce redundant transmission. Secondly, an efficient data transmission mechanism is established between the master computer and the slave computer and inside the slave computer. Reflective memory is used to achieve low-latency communication between the master computer and the scheduling core, and the interaction between the scheduling core and the simulation core inside the slave computer is optimized through shared memory, significantly reducing communication overhead. In addition, a dynamic load balancing and fault tolerance mechanism is provided to achieve elastic resource allocation, avoid simulation interruption easily caused by overload or core failure, and continuously monitor the load of the slave computer. When overload is detected, hardware-in-the-loop simulation objects are selected for migration according to the historical step length of the simulation core or the current task coupling degree (such as preferentially migrating low-coupling tasks or enabling hardware acceleration), and a two-level fault tolerance mechanism is constructed: the first level predicts the abnormal core results through historical / current data to maintain the simulation process, and the second level directly migrates the task to other cores or slave computers to ensure system continuity. These improvements effectively solve the deficiencies of hardware-in-the-loop simulation in communication efficiency, load balancing, and fault tolerance, and improve the practicality and reliability of the simulation system.

[0100] In some embodiments, in the hardware-in-the-loop simulation system, the design framework control terminal (such as the scheduling core) serves as the middle layer. Through the framework control terminal, the simulation models in the subordinate simulation cores are uniformly managed. 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 terminal. The simulation framework is only used to forward instructions to start / stop the models. All model event management and step information writing are completed by the framework control terminal, thereby achieving the decoupling of the framework and the models in the lower computer and realizing the parallel simulation function of multiple simulation nodes. That is to say, the framework management terminal is at least used for: receiving multi-node simulation events and target information (i.e., simulation instructions) from the control software; parsing the multi-node simulation events and target information, and selecting the simulation models corresponding to the simulation cores for distribution; after starting the corresponding simulation model, sending the target simulation information (i.e., sub-simulation instructions) once every 1 ms cycle; receiving the simulation feedback (i.e., simulation results) of the model once every 1 ms cycle; pushing the simulation feedback of the model to the simulation control software; the interactions between the framework management terminal and the outside are all in real-time with high frame rate; managing all simulation tasks on the same simulation machine (i.e., the lower computer), and controlling their start, running, end and other states; managing all step data on the same simulation machine.

[0101] As Figure 1 shown, the simulation task is designed with modular cutting. CPU-0 is the framework control terminal (i.e., the scheduling core), and CPU-1, CPU-2, CPU-N are the real-time simulation operation terminals (i.e., the simulation cores) that obtain instruction data from the task module for real-time simulation. Thus, the real-time simulation framework in the lower computer (i.e., at least one scheduling core and several simulation cores) adopts the "control terminal task scheduling, operation terminal periodic execution" mechanism to achieve the function of "multi-task, parallel processing", and reduce the coupling degree of the software structure and the control process. Moreover, due to the characteristics of the reflected memory hardware device driver, at the same time, only one process in the real-time simulation framework is supported to use the reflected memory communication. The unified task reception and result feedback by the scheduling center can effectively adapt to this characteristic and avoid communication conflicts.

[0102] The real-time simulation framework adopts a working mode with the minimum control period. For example, multi-core simulation tasks achieve task scheduling and data exchange through the RTX response service once every 1 ms. Every 1 ms, the task scheduling instruction (i.e., the sub-simulation task instruction) is issued by the task scheduling of the framework control end, and the real-time simulation operation end polls the task scheduling instruction once every 1 ms and makes a response. The reading and sending of inter-core communication data in the simulation are strictly carried out in the order of first judging the interrupt status and then accessing the memory, and closely cooperate to complete the multi-task processing process. The main functions of the framework control end in real-time parallel simulation include the monitoring of the simulation test process, the task scheduling of each core, the response and processing of interrupts, the coordination of inter-core communication, the allocation of shared resources, the handling of simulation test failures, the acquisition and processing of data, etc. Among them, RTX is a general real-time extension system based on the Windows operating system.

[0103] In some embodiments, the real-time parallel simulation task scheduling adopts scheduling driven by the RTX clock signal. The RTX clock signal is generated by the RTX software system. The RTX system has the function of dynamic priority allocation. The task switching time is less than 5.2 us, and the interrupt response is less than 5 us. It is a real-time simulation operating system. The interrupt service program under the RTX system notifies the occurrence of event simulation in the shortest time, and places other high-frequency calculations and data interactions through the communication mechanism between interrupts and tasks in the triggered simulation task itself, which can not only avoid various limitations in writing interrupt service programs, but also further reduce the interrupt latency.

[0104] After the simulation task is activated, the simulation core first updates the simulation results of the previous cycle to the shared memory cache. When the framework management end detects that the simulation structure of the simulation core of the same lower computer has been updated, it transmits the data to the upper computer through the reflective memory and activates the real-time step-by-step solution task of the simulation model on other simulation cores. Driven by the external event instruction, the framework control end periodically activates the model task, updates and sends the simulation results to the upper computer until the simulation test ends.

[0105] In some embodiments, the inter-task communication model of the hardware-in-the-loop simulation system mainly includes: shared memory, semaphore and reflective memory. The advantage of using shared memory for inter-simulation task communication is the fastest access speed, the size of the data area can be specified, and the structure of the data area can be freely set according to needs. Using reflective memory as the interaction with the upper computer and external devices, the reflective memory network adopts high-speed fiber optic hardware data sharing technology, which has strict transmission certainty and predictability, and also has the characteristics of simple data communication protocol, fast data transmission, strong real-time performance, and good platform versatility.

[0106] In some embodiments, before the program execution, the computational workload, communication overhead, and the logical relationships between tasks are obtained through static estimation or testing methods, and then the task coupling degree among several hardware-in-the-loop simulation objects is initialized and analyzed. Further, according to the relevance between simulation tasks, the simulation resource requirements for each task can be confirmed in advance, which can avoid uncontrollable subsequent computational resource overhead and improve the simulation efficiency.

[0107] Please refer to Figure 4 , Figure 4 which is a schematic block diagram of a computer device provided by an embodiment of the present application. The computer device can be a terminal device or a server.

[0108] Exemplarily, the above method can be implemented in the form of a computer program, and the computer program can run on a computer device as shown in Figure 4 .

[0109] As shown in Figure 4 , the computer device includes a processor, a memory, and a network interface connected through a system bus. Among them, the memory can include a non-volatile storage medium and an internal memory.

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

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

[0112] 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 be enabled to execute any multi-core simulation method based on a distributed hardware-in-the-loop simulation system.

[0113] The network interface is used for network communication, such as sending assigned tasks, etc.

[0114] It should be understood that the processor can be a Central Processing Unit (CPU), and the processor can also be other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc.

[0115] Among them, in one embodiment, it is applied to a distributed hardware-in-the-loop simulation system. The distributed hardware-in-the-loop simulation system includes a host computer and several slave computers. Each slave computer includes at least one scheduling core and several simulation cores. The processor is used to run a computer program stored in a memory to implement the following steps: S101. Obtain several hardware-in-the-loop simulation objects in the simulation task; S102. Analyze the task coupling degree among the several hardware-in-the-loop simulation objects, and divide the several hardware-in-the-loop simulation objects into multiple associated simulation groups according to the task coupling degree; S103. Bind each hardware-in-the-loop simulation object within the same associated simulation group to each simulation core of the same slave computer respectively to obtain several pairs of bound simulation relationships; S104. Transmit the simulation instruction generated by the host computer to the scheduling core. The scheduling core is used to obtain several sub-simulation instructions corresponding to several simulation cores in the slave computer to which the scheduling core belongs from the simulation instruction based on the bound simulation relationship, and send the sub-simulation instructions to the corresponding target simulation cores, so that the target simulation cores perform simulation operations according to the corresponding sub-simulation instructions to obtain simulation results; S105. Transmit several simulation results calculated by the slave computer to the host computer to update the simulation instruction.

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

[0117] In an embodiment of the present application, there is also provided a computer-readable storage medium storing a computer program, where the computer program includes program instructions, and the processor executes the program instructions to implement the steps of any one of the multi-core simulation methods based on a distributed semi-physical simulation system provided in the embodiments of the present application.

[0118] Among them, the computer-readable storage medium may be an internal storage unit of the computer device described in the foregoing embodiments, such as the 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 Card, etc. equipped on the computer device.

[0119] The above is only the specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art within the technical scope disclosed by the present application can easily think of various equivalent modifications or substitutions, and these modifications or substitutions should be covered within the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope 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 semi-physical 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 a number of semi-physical simulation objects in a simulation task; S102, analyzing the task coupling degree between a plurality of semi-physical simulation objects, and dividing the plurality of semi-physical simulation objects into a plurality of associated simulation groups according to the task coupling degree; S103, binding each semi-physical 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; S104, transmitting the simulation instruction generated by the upper computer to the scheduling core, the scheduling core is used to obtain a number of sub-simulation instructions corresponding to a number of 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 calculation according to the corresponding sub-simulation instructions to obtain a simulation result; S105, transmitting a plurality of simulation results obtained by solving the lower computer to the upper computer to update the simulation instruction.

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 semi-physical simulation system according to claim 1, wherein The method further includes: the upper computer and the scheduling core in the lower computer perform information interaction based on reflective memory; and / or the scheduling core in the lower computer performs information interaction with a plurality of the simulation cores based on shared memory.

4. The multi-core simulation method based on a distributed semi-physical simulation system according to claim 3, wherein The method further comprises: When the scheduling core detects that any of the target simulation cores uploads the simulation result to the shared memory, the scheduling core uploads 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 of the target simulation cores in the 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 or 4, characterized in that The method further comprises: 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, the corresponding target simulation core is identified as an 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, the predicted simulation result of the abnormal simulation core is predicted, and the predicted simulation result is uploaded to the upper computer.

6. The multi-core simulation method based on a distributed hardware-in-the-loop simulation system according to claim 5, wherein The method further comprises: 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.

7. The multi-core simulation method based on a distributed semi-physical simulation system according to claim 1, characterized in that The method further comprises: 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; Some binding relationships in the overloaded lower computer are changed to migrate some semi-physical simulation objects in the same associated simulation group to other lower computers.

8. The multi-core simulation method based on a distributed semi-physical simulation system according to claim 7, characterized in that The method further comprises: Detecting the historical simulation steps of a plurality of the simulation cores in the overloaded lower computer; Select at least one overload 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, release the binding relationship between the overload simulation core and the semi-physical simulation object, and bind the corresponding semi-physical simulation object to the idle simulation cores in other lower computers; and / or, Detecting the current task coupling degree of each semi-physical 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 idle simulation cores in other lower computers.

9. 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 semi-physical simulation system as claimed in any one of claims 1 to 8 when executing the computer program.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the processor implements the multi-core simulation method based on a distributed semi-physical simulation system according to any one of claims 1 to 8.

Images