Lightweight simulation resource adaptive integration method
By dividing the simulation model into algorithm and interface communication models, and combining physical resource mapping and memory mechanisms, adaptive integration of simulation resources is achieved, solving the problems of low resource utilization and insufficient scalability in traditional simulation systems, and improving simulation efficiency and system adaptability.
Patent Information
- Application Number
- CN202511651209.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-12
- Publication Date
- 2026-02-17
AI Technical Summary
Traditional simulation systems cannot adapt to the dynamically changing simulation task requirements in terms of resource allocation, resulting in low resource utilization and difficulty in improving simulation efficiency. The lack of unified standards for the encapsulation and management of model components increases the development and maintenance costs of the system. Furthermore, large-scale distributed simulations have high communication overhead, making it difficult to achieve efficient concurrent processing.
The simulation model is divided into an algorithm model and an interface communication model, and each is encapsulated as a simulation model component. Dynamic loading and unloading are achieved through a physical resource mapping table. Data interaction is carried out by combining a subscription-publish table and different memory mechanisms. Resource management and data transmission are carried out through a collaborative working mechanism of master node and slave node.
The modular design of simulation model components has been achieved, which improves resource utilization and the scalability of the simulation system, enhances the system's adaptability and simulation efficiency, reduces communication overhead, and simplifies the development and maintenance of model components.
Smart Images
Figure CN121542031A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of distributed simulation technology, and in particular to a lightweight adaptive integration method for simulation resources. Background Technology
[0002] As system complexity continues to increase, the integration of simulation resources faces numerous challenges. Traditional simulation systems typically employ fixed resource allocation methods. While this approach may meet requirements in simple scenarios, its flexibility and efficiency are clearly insufficient when facing complex and ever-changing simulation tasks. For example, in large-scale distributed simulation environments, the types and number of simulation models are constantly increasing, and frequent data interactions are required between different models. Traditional resource allocation methods cannot dynamically adjust resource allocation, resulting in low resource utilization and inefficient simulation. Furthermore, traditional simulation systems also have shortcomings in the encapsulation and management of model components, lacking a unified interface standard, making integration between different models difficult and increasing the development and maintenance costs of the system.
[0003] First, the resource allocation methods of traditional simulation systems cannot adapt to the dynamically changing simulation task requirements, resulting in low resource utilization and difficulty in improving simulation efficiency. Second, existing systems lack unified standards for the encapsulation and management of model components, making the integration and expansion between models complex and costly. Finally, existing data interaction methods suffer from high communication overhead when facing large-scale distributed simulations, making it difficult to achieve efficient concurrent processing, which seriously affects the performance and scalability of simulation systems. Summary of the Invention
[0004] Based on the above analysis, the embodiments of the present invention aim to provide a lightweight adaptive integration method for simulation resources, in order to solve the problems of low utilization of existing simulation resources and insufficient scalability and applicability of simulation systems to large-scale scenarios.
[0005] This invention discloses a lightweight adaptive integration method for simulation resources, comprising the following steps:
[0006] Obtain the simulation model description file, which includes a model type identifier, a list of input variables, and a list of output variables;
[0007] Based on the model type identifier, the simulation model is divided into an algorithm model and an interface communication model, and then encapsulated as simulation model components respectively.
[0008] Construct a physical resource mapping table, which records the correspondence between node identifiers, thread identifiers and simulation model components;
[0009] Based on the physical resource mapping table, the simulation model components are loaded into the computing nodes corresponding to the node identifiers, and the simulation model components are bound to the execution threads corresponding to the thread identifiers.
[0010] Within each execution thread, the publication and subscription of data for each variable in the input variable list and output variable list are completed based on the publish-subscribe table and the physical resource mapping table;
[0011] Based on the subscription-publishing table and physical resource mapping table, dynamic data interaction between simulation model components is performed within each simulation step to complete the adaptive integration of simulation resources;
[0012] When the simulation task termination condition is triggered, all simulation model components are unloaded in sequence and computing resources are released.
[0013] Furthermore, the components encapsulated as simulation model components include:
[0014] If the model type is identified as an algorithm model, the algorithm source code is extracted, and a first simulation model component including an init interface, a run interface, an input interface, and an output interface is generated according to the encapsulation template.
[0015] If the model type is identified as an interface communication model, the interface process description file is extracted, and a second simulation model component including an init interface, a run interface, an input interface, an output interface, and a real interface operation interface is generated based on the encapsulation template.
[0016] In the init interface, the addresses of input variables are written to InputLocalMap, and the addresses of output variables are written to OutputLocalMap.
[0017] The metadata of the first simulation model component or the second simulation model component is written into the simulation resource description file. The metadata includes the unique identifier of the model, the file name of the dynamic link library corresponding to the model component, and the number of variables.
[0018] Furthermore, the construction of the physical resource mapping table includes:
[0019] Parse the task deployment file Task.xml to obtain the board identifier and thread priority;
[0020] Using the board identifier as the node identifier, all thread identifiers within the same board are written into the physical resource mapping table;
[0021] Sort all thread identifiers according to thread priority to generate a thread scheduling order;
[0022] Based on the thread scheduling order, a mapping is established between the unique model identifier of the simulation model component and the thread identifier, and then written into the physical resource mapping table.
[0023] Furthermore, the process of publishing and subscribing to the data of each variable in the input variable list and output variable list based on the publish-subscribe table and physical resource mapping table includes:
[0024] Read the subscription-publish table, which consists of four tuples, including subscription model identifier, subscription variable identifier, publishing model identifier, and publishing variable identifier;
[0025] A publishing feature table is generated based on the physical resource mapping table. The publishing feature table records the subscription type identified by each publishing variable. The subscription type includes no subscription, local subscription, inter-thread subscription, and inter-node subscription.
[0026] The publish-subscribe table, physical resource mapping table, and publish feature table are synchronized to all compute nodes to complete the publication and subscription of data for each variable, including:
[0027] Create an OutputLocalMap and an InputLocalMap in the local memory of each execution thread to cache variable addresses;
[0028] A ThreadMap is created in the shared memory of each executing thread to cache inter-thread variable data;
[0029] A NodeMap is created in the fiber optic reflection memory of each computing node to cache variable data between nodes.
[0030] Furthermore, the dynamic data interaction between simulation model components within each simulation step, based on the publish-subscribe table and the physical resource mapping table, includes:
[0031] At the beginning of each simulation step, iterate through all output variables of the currently executing thread;
[0032] Determine the subscription type of the output variable based on the publication feature table;
[0033] If the subscription type is local subscription, then the output variable data will be copied to the corresponding address of InputLocalMap;
[0034] If the subscription type is inter-thread subscription, the output variable data will be written to a ThreadMap.
[0035] If the subscription type is inter-node subscription, the output variable data will be written to NodeMap;
[0036] Iterate through all input variables of the currently executing thread, locate the data source address according to the subscription-publish table, and determine the node identifier and thread identifier of the data source according to the physical resource mapping table;
[0037] If the data source is located in a local thread, then read the data from OutputLocalMap;
[0038] If the data source is located in another thread, then read the data from the ThreadMap;
[0039] If the data source is located on another node, then read the data from the NodeMap;
[0040] Write the read data into InputLocalMap.
[0041] Furthermore, the node includes a master node and slave nodes;
[0042] The simulation task termination conditions include reaching a preset simulation duration or receiving an external stop command; sequentially unloading all simulation model components and releasing computing resources includes:
[0043] The master node writes a stop command to the synchronization area of the fiber optic reflective memory and sends a write stop command to the slave nodes;
[0044] After receiving the write stop command sent by the master node, each slave node calls the exit interface of the corresponding simulation model component;
[0045] Unload the dynamic link libraries one by one and release the thread stacks;
[0046] Send an unloading completion status code back to the master node;
[0047] After receiving the unloading completion status codes from all slave nodes, the master node releases the global synchronization region and heartbeat region, and marks the simulation task as terminated.
[0048] Furthermore, the algorithm model is the function and algorithm implementation of the simulated object, and the number of models can be one or more.
[0049] The interface communication model is a communication protocol implementation between the simulated system and the external real system, and the number of models can be one or more.
[0050] Each algorithm model and each interface communication model are independently encapsulated as a simulation model component, and each simulation model component has a unique model identifier.
[0051] Furthermore, the dynamic link library is a .dll file on the Windows platform and a .so file on the Linux platform;
[0052] The shared memory is implemented using an inter-thread shared memory mechanism.
[0053] The fiber optic reflective memory is implemented using an inter-node reflective memory network.
[0054] Furthermore, the method also includes:
[0055] The master node updates the global frame count at the beginning of each simulation step and writes the global frame count into the synchronization area of the fiber reflection memory;
[0056] The node obtains the global frame count from the synchronization region through querying or interruption.
[0057] Each execution thread calculates its local frame count based on the global frame count and calls the run interface of the corresponding simulation model component. If the master node writes a stop instruction in the synchronization region, all slave nodes immediately terminate the simulation and enter the unloading process.
[0058] Furthermore, the method also includes performing the following steps when a new simulation model component is added:
[0059] Send the simulation resource description file of the newly added simulation model component to all compute nodes;
[0060] Each compute node parses the simulation resource description file and updates the local subscription-publishing table, physical resource mapping table, and publishing feature table;
[0061] During the simulation initialization phase, the updated mapping relationship is distributed to all computing nodes via an XML file;
[0062] The simulation task is reloaded based on the updated mapping.
[0063] Compared with the prior art, the present invention can achieve at least one of the following beneficial effects:
[0064] 1. By dividing the simulation model into an algorithm model and an interface communication model, and encapsulating them into simulation model components, a modular design of the simulation model is achieved, enabling different types of models to be developed and maintained independently. Based on the publish-subscribe table and physical resource mapping table, the publication and subscription of data for each variable in the input variable list and output variable list are completed, realizing efficient dynamic data interaction between simulation model components. By establishing caching mechanisms in local memory, shared memory between threads, and fiber optic reflection memory between nodes, the most suitable data transmission path can be selected according to the subscription type of the variable, thereby achieving efficient data transmission and concurrent processing and improving the scalability of simulation resources.
[0065] 2. By assigning a unique identifier to each model component and recording its correspondence with computing nodes and threads in the physical resource mapping table, dynamic loading and unloading of simulation model components can be achieved, thereby flexibly adjusting resource allocation according to different simulation task requirements and improving resource utilization.
[0066] 3. Through the collaborative working mechanism of the master node and slave nodes, the master node is responsible for updating the global frame count and issuing stop instructions. The slave nodes perform simulation advancement and resource unloading according to the instructions of the master node. By unloading all simulation model components and releasing computing resources in sequence when the simulation task termination condition is triggered, efficient resource recycling is achieved. In addition, when a new simulation model component is added, the system can be quickly expanded by updating the mapping relationship and reloading the simulation task, which enhances the system's adaptability.
[0067] In this invention, the above-described technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of this invention will be set forth in the following description, and some advantages may become apparent from the description or be learned by practicing the invention. The objects and other advantages of this invention can be realized and obtained from what is particularly pointed out in the description and drawings. Attached Figure Description
[0068] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts.
[0069] Figure 1 This is a schematic diagram of a lightweight simulation resource adaptive integration method according to an embodiment of the present invention;
[0070] Figure 2 This is a schematic diagram of an algorithm model interface provided in an embodiment of the present invention;
[0071] Figure 3 This is a schematic diagram of a process model interface provided in an embodiment of the present invention;
[0072] Figure 4 This is a schematic diagram illustrating dynamic data interaction between simulation model components according to an embodiment of the present invention;
[0073] Figure 5 This is a schematic diagram illustrating the principle of fiber optic reflective memory communication according to an embodiment of the present invention. Detailed Implementation
[0074] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.
[0075] A specific embodiment of the present invention discloses a lightweight simulation resource adaptive integration method, comprising the following steps:
[0076] S1. Obtain the simulation model description file, which includes a model type identifier, an input variable list, and an output variable list. The simulation model description file is a structured file that records the attributes and interface information of the simulation model. The input variable list and output variable list define the input and output data required by the simulation model. The model type identifier is used to distinguish between the algorithm model and the interface communication model.
[0077] S2. Based on the model type identifier, the simulation model is divided into an algorithm model and an interface communication model, and then encapsulated as simulation model components respectively.
[0078] Specifically, the simulation model components are encapsulated as follows:
[0079] S21. If the model type is identified as an algorithm model, extract the algorithm source code and generate a first simulation model component including an init interface, a run interface, an input interface, and an output interface based on the encapsulation template. For example... Figure 2 As shown, the algorithm model generates basic functional interfaces by extracting source code and applying standardized encapsulation templates. The algorithm model is the function and algorithm implementation of the simulated object, and the number can be one or more.
[0080] S22. If the model type is identified as an interface communication model, extract the interface flow description file and generate a second simulation model component including an init interface, a run interface, an input interface, an output interface, and a real interface operation interface based on the encapsulation template; Figure 3 As shown, the interface communication model extends the real interface through a process description file. This interface communication model is the implementation of the communication protocol between the simulated system and the external real system, and can be one or more. Each algorithm model and each interface communication model are independently encapsulated as a simulation model component, and each simulation model component has a unique model identifier.
[0081] S23. In the init interface, write the address of the input variable to InputLocalMap and the address of the output variable to OutputLocalMap.
[0082] Both the algorithm model and the interface communication model implement localized mapping of variable addresses through the init interface, where InputLocalMap is used to store the addresses of input variables and OutputLocalMap is used to store the addresses of output variables.
[0083] S24. Write the metadata of the first simulation model component or the second simulation model component into the simulation resource description file. The metadata includes the unique identifier of the model, the file name of the dynamic link library corresponding to the model component, and the number of variables.
[0084] Meta-information for both the first and second simulation model components is written to the simulation resource description file. The model's unique identifier is generated using a hash algorithm, and the dynamic link library filename automatically adapts its extension based on the operating system platform. Standardized encapsulation templates eliminate interface differences between different model types, and structured storage of meta-information enables rapid location and loading of component instances. Dynamic link libraries are .dll files on Windows and .so files on Linux.
[0085] S3. Construct a physical resource mapping table, which records the correspondence between node identifiers, thread identifiers and simulation model components.
[0086] The physical resource mapping table is a configuration table that records the mapping relationship between computing nodes, execution threads and simulation model components. Specifically, it can be a hash table or a database table. The node identifier corresponds to the physical address or logical identifier of the computing node, and the thread identifier corresponds to the thread ID assigned by the operating system or a custom scheduling identifier.
[0087] Specifically, constructing the physical resource mapping table includes:
[0088] S31. Parse the task deployment file Task.xml to obtain the board identifier and thread priority. The task deployment file Task.xml is parsed by reading the board identifier field and thread priority field from the XML file. The board identifier field corresponds to the physical hardware number of the compute node, and the thread priority field is represented by an integer value.
[0089] S32. Using the board identifier as the node identifier, write all thread identifiers within the same board into the physical resource mapping table. When writing all thread identifiers within the same board into the physical resource mapping table, a hash table data structure is used to store the correspondence between board identifiers and thread identifier sets.
[0090] S33. Sort all thread identifiers according to thread priority to generate a thread scheduling order. The thread scheduling order is generated in ascending order, with thread identifiers of lower priority values listed first and thread identifiers of higher priority values listed last. This ensures that high-priority threads obtain computing resources first and avoids low-priority threads occupying critical resources, which could hinder the task.
[0091] S34. Based on the thread scheduling order, establish a mapping between the unique model identifier of the simulation model component and the thread identifier, and write it into the physical resource mapping table. Establish a mapping between the unique model identifier of the simulation model component and the thread identifier, and allocate thread resources sequentially using a linked list structure.
[0092] S4. Based on the physical resource mapping table, load the simulation model components into the computing nodes corresponding to the node identifiers, and bind the simulation model components to the execution threads corresponding to the thread identifiers.
[0093] Based on the mapping between node identifiers and simulation model components recorded in the physical resource mapping table, the computation node to which each simulation model component should be loaded is identified, and the relevant code and data of the simulation model component are transferred to the corresponding computation node. Based on the thread identifiers recorded in the physical resource mapping table, the simulation model component is bound to the execution thread corresponding to the thread identifier, thus associating the simulation model component with a specific execution thread.
[0094] S5. Within each execution thread, the publication and subscription of data for each variable in the input variable list and output variable list are completed based on the publish-subscribe table and the physical resource mapping table.
[0095] A publish-subscribe table is a configuration table that defines the relationship between publishers and subscribers of variable data. Specifically, it is a key-value pair or relational data table. The relationship between the data source and the target is established through subscription model identifiers and publication model identifiers. The publication and subscription of each variable in the input variable list and output variable list, based on the publish-subscribe table and physical resource mapping table, includes:
[0096] S51. Read the subscription-publish table, which consists of a four-tuple, including the subscription model identifier, the subscription variable identifier, the publishing model identifier, and the publishing variable identifier;
[0097] S52. Generate a publishing feature table based on the physical resource mapping table. The publishing feature table records the subscription type of each publishing variable identifier. The subscription type includes no subscription, local subscription, inter-thread subscription, and inter-node subscription. A four-tuple is formed by the combination of subscription model identifier, subscription variable identifier, publishing model identifier, and publishing variable identifier to define the source and destination of the data flow.
[0098] S53. Synchronize the publish-subscribe table, physical resource mapping table, and publish feature table to all computing nodes to complete the publication and subscription of data for each variable, including:
[0099] S531. Create an OutputLocalMap and an InputLocalMap in the local memory of each execution thread to cache variable addresses; OutputLocalMap stores the addresses of variables published by this thread, and InputLocalMap stores the addresses of variables subscribed to by this thread.
[0100] S532. Establish a ThreadMap in the shared memory of each executing thread to cache variable data between threads; the ThreadMap can be implemented through shared memory between threads to store variable data that needs to be passed between different threads.
[0101] S533. Establish a NodeMap in the fiber optic reflective memory of each computing node to cache variable data between nodes. The NodeMap is implemented through an inter-node reflective memory network and is used to store variable data that needs to be transferred between different computing nodes.
[0102] In some embodiments, the data memory model of the local cache area (including OutputLocalMap and InputLocalMap) is consistent with that of the inter-thread data interaction module (ThreadMap) to ensure consistency in data format and access interface, facilitating unified system management and scheduling. In this design, the inter-node interaction data area (NodeMap) includes a node information area to identify the data source node and its status, supporting data routing and subscription management between multiple nodes.
[0103] The NodeMap inter-node data interaction module is implemented using a fiber optic reflective memory mechanism. When a node updates the content in NodeMap, its data is quickly synchronized to the reflective memory network through a hardware broadcast mechanism, and other nodes can obtain the latest data in real time, ensuring strong consistency and low latency transmission of data within the simulation step.
[0104] To avoid frequent operations on the fiber optic reflection memory by the simulation model, data is cached in the local cache area on a thread-by-thread basis. Within each simulation cycle, each thread first processes data interactions locally, and then updates the NodeMap with all data that needs to be transmitted across nodes at the end of the step. This mechanism significantly reduces the frequency of write operations to the fiber optic reflection memory, lowers network load, and improves the overall system performance.
[0105] S6. Based on the subscription-publishing table and physical resource mapping table, perform dynamic data interaction between simulation model components within each simulation step to complete the adaptive integration of simulation resources.
[0106] Dynamic data interaction is the process of transmitting variable data in real time according to subscription relationships within the simulation step. Local subscriptions access data directly through memory addresses, inter-thread subscriptions exchange data through shared memory, and inter-node subscriptions transmit data through fiber optic memory reflection.
[0107] like Figure 4 As shown, based on the publish-subscribe table and physical resource mapping table, the dynamic data interaction between simulation model components within each simulation step includes:
[0108] S61. At the beginning of each simulation step, iterate through all output variables of the currently executing thread.
[0109] At the start of the simulation step, the execution thread first iterates through all output variables and selects the corresponding transmission path based on the subscription type recorded in the publication feature table.
[0110] S62. Determine the subscription type of the output variable based on the publication feature table.
[0111] Specifically, if the subscription type is a local subscription, the output variable data will be copied to the corresponding address of InputLocalMap;
[0112] If the subscription type is inter-thread subscription, the output variable data will be written to a ThreadMap.
[0113] If the subscription type is inter-node subscription, the output variable data will be written to NodeMap.
[0114] Locally subscribed data is directly copied to the target component's InputLocalMap via memory address, avoiding cross-thread or cross-node communication overhead. Inter-thread subscribed data is written to a shared memory area, ThreadMap, for other threads within the same node to quickly access via memory mapping. Figure 5 As shown, data subscribed between nodes is written to the NodeMap in the fiber optic reflection memory, and multi-node synchronization is achieved through a hardware broadcast mechanism.
[0115] S63. Traverse all input variables of the currently executing thread, locate the data source address according to the subscription-publish table, and determine the node identifier and thread identifier of the data source according to the physical resource mapping table.
[0116] Specifically, if the data source is located in a local thread, data is read from OutputLocalMap;
[0117] If the data source is located in another thread, then read the data from the ThreadMap;
[0118] If the data source is located on another node, then read the data from the NodeMap;
[0119] During the input variable processing phase, the data source model identifier is queried through the subscription-publish table, and the location of the data source is determined by combining it with the physical resource mapping table. If the data source is located in the local thread, it is read directly from OutputLocalMap. If it is located in other threads, it accesses the shared memory of ThreadMap. If it is located in other nodes, it reads the reflected memory data of NodeMap.
[0120] S64. Write the read data into InputLocalMap.
[0121] After all read operations are completed, the data is written to the InputLocalMap of the current component, ensuring that the model component obtains the latest input data within the simulation step.
[0122] S7. When the simulation task termination condition is triggered, all simulation model components are unloaded sequentially and computing resources are released. Releasing computing resources is used to reclaim hardware resources when the simulation task terminates. Nodes include master nodes and slave nodes. The master node sends a stop command through the synchronization area of the memory via fiber optic reflection, ensuring that all slave nodes can synchronously receive the termination signal. During the exit interface call process, slave nodes release thread stack memory space according to the dynamic link library unloading order to avoid memory leaks.
[0123] The simulation task termination conditions include reaching a preset simulation duration or receiving an external stop command; sequentially unloading all simulation model components and releasing computing resources includes:
[0124] S71. The master node writes a stop command in the synchronization area of the fiber optic reflective memory and sends a write stop command to the slave nodes. When the master node detects that the simulation duration has exceeded the limit or an external stop command has been issued, it writes the stop command into the synchronization area and broadcasts it to all slave nodes through the reflective memory network.
[0125] S72. After receiving the write stop command sent by the master node, each slave node calls the exit interface of the corresponding simulation model component.
[0126] S73. Unload dynamic link libraries sequentially and release thread stacks; after reading synchronization region instructions from the node through polling or interrupt mechanism, immediately stop the current simulation step size advancement, and call the exit interface of the simulation model component in a preset order to release the input / output variable address mapping table.
[0127] S74. Send the unloading completion status code back to the master node; after unloading is completed, the slave node writes the status code containing the node identifier and the unloading result into the heartbeat area of the reflected memory.
[0128] S75. After receiving all unloading completion status codes from slave nodes, the master node releases the global synchronization region and heartbeat region, and marks the simulation task as terminated. The master node continues to monitor the heartbeat region until all status codes have been received, then clears the memory mapping relationship between the synchronization region and the heartbeat region, and updates the task status register to the termination flag.
[0129] Furthermore, the method also includes performing the following steps when a new simulation model component is added:
[0130] The simulation resource description file for the newly added simulation model component is sent to all compute nodes. When a new component is added to the system, its simulation resource description file is distributed to all compute nodes. The nodes parse the file to obtain the metadata of the new component and update the locally stored publish-subscribe table to include the input-output variable relationships of the new component.
[0131] Each compute node parses the simulation resource description file and updates its local subscription-publishing table, physical resource mapping table, and publishing feature table. When a new simulation model component is added, the physical resource mapping table is updated synchronously, and a mapping is established between the unique model identifier of the new component and the thread identifier to ensure that the executing threads can identify their scheduling order. The publishing feature table is updated according to the variable subscription type of the new component, and the newly added inter-thread subscription variables are recorded in the publishing feature table.
[0132] During the simulation initialization phase, the updated mapping relationships are distributed to all computing nodes via XML files. The updated mapping relationships are uniformly configured and distributed using XML file format, ensuring consistency in data interaction rules across nodes.
[0133] The simulation task is reloaded based on the updated mapping. When a new simulation task is loaded, each node loads the dynamic link library of the newly added component according to the updated mapping and binds it to the specified thread.
[0134] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware, and the program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.
[0135] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.
Claims
1. A lightweight emulation resource adaptive integration method, characterized in that, The method comprises the following steps: obtaining a simulation model description file, the simulation model description file comprising a model type identifier, an input variable list, and an output variable list; dividing the simulation model into an algorithm model and an interface communication model according to the model type identifier, and encapsulating the simulation model into simulation model components respectively; constructing a physical resource mapping table, the physical resource mapping table recording the correspondence between a node identifier, a thread identifier, and a simulation model component; loading the simulation model component to a computing node corresponding to the node identifier, and binding the simulation model component to an execution thread corresponding to the thread identifier, based on the physical resource mapping table; in each execution thread, completing the publishing and subscribing of the variable data in the input variable list and the output variable list based on a subscription-publishing table and the physical resource mapping table; in each simulation step, performing dynamic data interaction between the simulation model components according to the subscription-publishing table and the physical resource mapping table, and completing the adaptive integration of the simulation resources; when a simulation task termination condition is triggered, unloading all the simulation model components in sequence and releasing the computing resources.
2. The method of claim 1, wherein, The encapsulating into simulation model components respectively comprises: if the model type identifier is an algorithm model, extracting an algorithm source code, and generating a first simulation model component comprising an init interface, a run interface, an input interface, and an output interface according to an encapsulation template; if the model type identifier is an interface communication model, extracting an interface flow description file, and generating a second simulation model component comprising an init interface, a run interface, an input interface, an output interface, and a real interface operation interface according to an encapsulation template; writing the input variable address into InputLocalMap and the output variable address into OutputLocalMap in the init interface; writing the meta information of the first simulation model component or the second simulation model component into a simulation resource description file, the meta information comprising a model unique identifier, a dynamic link library file name corresponding to the model component, and a variable quantity.
3. The method of claim 2, wherein, The constructing of the physical resource mapping table comprises: parsing a task deployment file Task.xml to obtain a board card identifier and a thread priority; writing all thread identifiers in the same board card into the physical resource mapping table with the board card identifier as the node identifier; sorting the all thread identifiers according to the thread priority to generate a thread scheduling sequence; mapping the model unique identifier of the simulation model component and the thread identifier based on the thread scheduling sequence, and writing into the physical resource mapping table.
4. The method of claim 3, wherein, The completing of the publishing and subscribing of the variable data in the input variable list and the output variable list based on the subscription-publishing table and the physical resource mapping table comprises: reading the subscription-publishing table, the subscription-publishing table being composed of four tuples, comprising a subscription model identifier, a subscription variable identifier, a publishing model identifier, and a publishing variable identifier; generating a publishing feature table according to the physical resource mapping table, the publishing feature table recording the subscription type of each publishing variable identifier, the subscription type comprising no subscription, local subscription, inter-thread subscription, and inter-node subscription; synchronizing the subscription-publishing table, the physical resource mapping table, and the publishing feature table to all computing nodes to complete the publishing and subscribing of the variable data, comprising: An OutputLocalMap and an InputLocalMap are established in the local memory of each execution thread, used to cache variable addresses; A ThreadMap is established in the shared memory of each execution thread, used to cache inter-thread variable data; A NodeMap is established in the fiber reflection memory of each computing node, used to cache inter-node variable data.
5. The method of claim 4, wherein, The dynamic data interaction between simulation model components in each simulation step is performed according to the subscription-published table and the physical resource mapping table, and includes: At the beginning of each simulation step, all output variables of the current execution thread are traversed; The subscription type of the output variable is determined according to the published feature table; If the subscription type is local subscription, the output variable data is copied to the corresponding address of the InputLocalMap; If the subscription type is inter-thread subscription, the output variable data is written to the ThreadMap; If the subscription type is inter-node subscription, the output variable data is written to the NodeMap; All input variables of the current execution thread are traversed, the data source address is located according to the subscription-published table, and the node identifier and thread identifier where the data source is located are determined according to the physical resource mapping table; If the data source is located in the local thread, the data is read from the OutputLocalMap; If the data source is located in other threads, the data is read from the ThreadMap; If the data source is located in other nodes, the data is read from the NodeMap; The read data is written to the InputLocalMap.
6. The method of claim 5, wherein, The nodes include a master node and slave nodes; The simulation task termination condition includes reaching a preset simulation time length or receiving an external stop command; Unloading all simulation model components in turn and releasing computing resources includes: The master node writes a stop instruction in the synchronization area of the fiber reflection memory and sends the write stop instruction to the slave nodes; Each slave node calls the exit interface of the corresponding simulation model component after receiving the write stop instruction sent by the master node; Unloading dynamic link libraries in turn and releasing thread stacks; Returning the unloading completion status code to the master node; After receiving the unloading completion status code from all slave nodes, the master node releases the global synchronization area and the heartbeat area, and marks the simulation task as terminated.
7. The method of claim 1, wherein: the algorithm model is the function and algorithm implementation of the simulated object, and the number is single or multiple; the interface communication model is the communication protocol implementation of the simulated system and the external real system, and the number is single or multiple; each algorithm model and each interface communication model is independently encapsulated as a simulation model component, and each simulation model component has a unique model unique identifier.
8. The method of claim 6, wherein: the dynamic link library is a.dll file on a Windows platform and a.so file on a Linux platform; the shared memory is implemented by using an inter-thread shared memory mechanism; the fiber reflection memory is implemented by using an inter-node reflection memory network.
9. The method of claim 8, wherein, The method further includes: The master node updates the global frame count at the beginning of each simulation step, and writes the global frame count into the synchronization area of the fiber reflection memory; The slave nodes obtain the global frame count from the synchronization area through polling or interruption; Each execution thread calculates the local frame count according to the global frame count, and calls the run interface of the corresponding simulation model component. If the master node writes a stop instruction into the synchronization area, all slave nodes immediately terminate the simulation advancement and enter the unloading process.
10. The method of claim 1, wherein, The method further comprises the following steps when a new simulation model component is added: sending the simulation resource description file of the new simulation model component to all computing nodes; each computing node parses the simulation resource description file, and updates the local subscription-published table, the physical resource mapping table and the published feature table; in the simulation initialization stage, the updated mapping relationship is sent to all computing nodes through an XML file; the simulation task is reloaded based on the updated mapping relationship.