A multi-level model-oriented bidirectional routing method, system, device and medium

Abstract

This application relates to a bidirectional routing method, system, device, and medium for multi-level models. The method includes: parsing an object description file to obtain model publication / subscription information defined in the object description file; constructing a multi-level object tree model with parent-child inheritance relationships, using the created root model as the parent model; creating an object routing table and an interaction routing table within each object tree model entity based on the relationships between the object tree models; enabling point-to-point direct memory access between objects based on the established object routing tables; coordinating collaborative behaviors among multiple objects using the interaction routing tables to complete task collaboration and state synchronization; and creating an object local blackboard for each type of object, with the subsystem copying objects from the parent system's local blackboard to complete object data inheritance and sharing. This method balances efficient point-to-point communication, flexible collaboration, and data inheritance, achieving efficient communication and collaboration across levels and subsystems.

Description

Technical Field

[0001] This application relates to the field of collaborative communication technology for multi-level simulation models, and in particular to a bidirectional routing method, system, device, and medium for multi-level models. Background Technology

[0002] With the continuous development of modern simulation systems, distributed computing, and complex system modeling, the construction and data interaction of multi-level object systems have become key challenges. These systems often contain a large number of hierarchical model entities, which require frequent state synchronization, instruction passing, and collaborative computation.

[0003] Currently, common system architectures often employ centralized data buses and hierarchical message forwarding mechanisms. While centralized architectures are simple in structure, the bus can easily become a performance bottleneck as the number of entities increases, and it is difficult to adapt to hierarchical entity organization. Traditional hierarchical forwarding mechanisms, although conforming to entity tree structures, often require data interaction to be passed through intermediate nodes layer by layer, resulting in high latency, poor real-time performance, and difficulty in supporting direct and efficient collaboration across layers and subsystems. Furthermore, the sharing and inheritance of object data typically rely on global replication or frequent remote access, increasing network overhead and the risk of data inconsistency.

[0004] Existing technologies lack a comprehensive data interaction solution that can simultaneously address hierarchical entity management, efficient point-to-point communication, flexible collaboration, and data inheritance. Therefore, there is an urgent need for a data method for multi-level object systems that supports bidirectional routing and efficient memory access to improve the overall system performance, real-time capabilities, and scalability. Summary of the Invention

[0005] Therefore, it is necessary to provide a bidirectional routing method, system, device, and medium for multi-level models that can improve the efficiency, flexibility, and scalability of collaborative communication in multi-level simulation systems, addressing the aforementioned technical problems.

[0006] A bidirectional routing method for a multi-level model, the method comprising:

[0007] Parse the scenario file to obtain the list of entities defined in the scenario file.

[0008] Based on the path to the object description file in the concept file, parse the object description file and obtain the model publication and subscription information defined in the object description file.

[0009] Using the created root model as the parent model, construct a multi-level object tree model with parent-child inheritance relationships.

[0010] Based on the relationships between the object tree models, an object routing table and an interaction routing table are created within each object tree model entity.

[0011] Based on the established object routing table, point-to-point direct memory access between objects is enabled.

[0012] By leveraging interactive routing tables, collaborative behaviors among multiple objects can be coordinated to achieve task collaboration and state synchronization.

[0013] After creating a local blackboard for each type of object, the subsystem copies the object from the parent system's local blackboard, thus completing the inheritance and sharing of object data.

[0014] A bidirectional routing system for a multi-level model, the system comprising:

[0015] The scenario file parsing module is used to parse scenario files and obtain the entity list information defined in the scenario files.

[0016] The subscription information acquisition module is used to parse the object description file based on the path in the concept file and obtain the model publication and subscription information defined in the object description file.

[0017] The model building module is used to construct a multi-level object tree model with parent-child inheritance relationships, using the created root model as the parent model.

[0018] The routing table building module is used to create an object routing table and an interaction routing table within each object tree model entity based on the relationships between the object tree models.

[0019] The access module is used to enable point-to-point direct memory access between objects based on the established object routing table.

[0020] The collaborative communication module is used to coordinate collaborative behaviors among multiple objects by using an interactive routing table to complete task collaboration and state synchronization.

[0021] The data sharing module is used to create a local blackboard for each type of object, and then the subsystem copies the object from the local blackboard of the parent system to complete the inheritance and sharing of object data.

[0022] A computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program performing the following steps:

[0023] Parse the scenario file to obtain the list of entities defined in the scenario file.

[0024] Based on the path to the object description file in the concept file, parse the object description file and obtain the model publication and subscription information defined in the object description file.

[0025] Using the created root model as the parent model, construct a multi-level object tree model with parent-child inheritance relationships.

[0026] Based on the relationships between the object tree models, an object routing table and an interaction routing table are created within each object tree model entity.

[0027] Based on the established object routing table, point-to-point direct memory access between objects is enabled.

[0028] By leveraging interactive routing tables, collaborative behaviors among multiple objects can be coordinated to achieve task collaboration and state synchronization.

[0029] After creating a local blackboard for each type of object, the subsystem copies the object from the parent system's local blackboard, thus completing the inheritance and sharing of object data.

[0030] A computer-readable storage medium having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0031] Parse the scenario file to obtain the list of entities defined in the scenario file.

[0032] Based on the path to the object description file in the concept file, parse the object description file and obtain the model publication and subscription information defined in the object description file.

[0033] Using the created root model as the parent model, construct a multi-level object tree model with parent-child inheritance relationships.

[0034] Based on the relationships between the object tree models, an object routing table and an interaction routing table are created within each object tree model entity.

[0035] Based on the established object routing table, point-to-point direct memory access between objects is enabled.

[0036] By leveraging interactive routing tables, collaborative behaviors among multiple objects can be coordinated to achieve task collaboration and state synchronization.

[0037] After creating a local blackboard for each type of object, the subsystem copies the object from the parent system's local blackboard, thus completing the inheritance and sharing of object data.

[0038] The aforementioned bidirectional routing method, system, device, and medium for multi-level models first construct a multi-level object tree with clear parent-child relationships by parsing scenario files, inheriting the advantages of hierarchical management in terms of clear structure and logical isolation. Its key innovation lies in not relying on this tree structure for layer-by-layer forwarding of communication, but instead creating an independent "object routing table" and "interaction routing table" for each model entity. These two routing tables are established through a one-time bidirectional recursive propagation, accurately recording the direct communication relationships between models across any level. This enables point-to-point direct access for data storage (via the object routing table) and behavioral collaboration (via the interaction routing table) between objects, thus solving the real-time bottleneck. Simultaneously, the independent existence of the "interaction routing table" allows for flexible configuration and efficient execution of task collaboration and state synchronization logic, meeting the needs of complex collaborative scenarios. In terms of data inheritance, a "local blackboard" replication mechanism is adopted. Subsystems only need to copy the object data they subscribe to from the parent system's blackboard, realizing on-demand, efficient data sharing and inheritance. This avoids the overhead of global copying and ensures fast, localized access to data within the subsystem, significantly improving memory access efficiency. In summary, this approach not only maintains the hierarchical architecture of the system for easier management and expansion but also achieves direct, efficient communication and collaboration across levels and subsystems through built-in bidirectional routing capabilities, ultimately resulting in significant improvements in overall performance, real-time response, and system scalability. Attached Figure Description

[0039] Figure 1 This is a flowchart illustrating a bidirectional routing method for a multi-level model in one embodiment;

[0040] Figure 2 This is a flowchart illustrating a bidirectional routing process for a multi-level model in one embodiment.

[0041] Figure 3 This is a logical structure diagram of a hierarchical object system and various modules of bidirectional routing in one embodiment;

[0042] Figure 4 This is a flowchart illustrating the workflow of a scenario file and object description file parsing module in one embodiment.

[0043] Figure 5 A flowchart illustrating the workflow of a multi-level model creation module in one embodiment;

[0044] Figure 6 A flowchart illustrating the workflow of the routing relationship creation module in one embodiment;

[0045] Figure 7 This is a flowchart of the efficient memory access module based on object routing tables in one embodiment;

[0046] Figure 8 This is a flowchart of the efficient memory access module based on the interactive routing table in one embodiment;

[0047] Figure 9 This is a flowchart of the local blackboard copy construction module in one embodiment;

[0048] Figure 10 This is a block diagram of a bidirectional routing system for a multi-level model in one embodiment;

[0049] Figure 11 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0051] In one embodiment, such as Figure 1 As shown, a bidirectional routing method for a multi-level model is provided, including the following steps:

[0052] Step 102: Parse the scenario file and obtain the entity list information defined in the scenario file.

[0053] Step 104: Based on the path of the object description file in the concept file, parse the object description file and obtain the model publication and subscription information defined in the object description file.

[0054] Specifically, based on the path of the object description file in the scenario file and parsing the publish / subscribe attributes between models, the system iterates through the set of published objects in the object description file and stores the published objects in the model's published information set; it iterates through the set of subscribed objects in the object description file and stores the subscribed objects in the model's subscribed information set; it iterates through the set of published interaction information in the object description file and stores the published interaction information in the model's published interaction information set; and it iterates through the set of subscribed interaction information in the object description file and stores the subscribed interaction information in the model's subscribed interaction information set.

[0055] Step 106: Using the created root model as the parent model, construct a multi-level object tree model with parent-child inheritance relationships.

[0056] Specifically, the model creation function is called to create the root model, and the model entity list information obtained from the concept file is traversed to create model entities in sequence with the root model as the only parent model.

[0057] Furthermore, a parent-child hierarchical relationship is established, subsystems are dynamically created and configured, and a multi-level model system is generated. If the created models are not in the same group (logical subsystem), the model parameters are processed in batches through the model creation list, and the creation of the routing table is delayed. If the created models belong to the same group (logical subsystem), the corresponding model pointers are generated through the model generation function, and the routing table is created immediately, allowing models in the same group to directly share blackboard data.

[0058] Furthermore, iterate through all models under the root model, sequentially obtaining the system entities corresponding to each model. It then iterates through the set of objects in the system that need to be subscribed to from the parent system, propagating upwards. If the current system has subscribed to the object and a parent system exists, the parent system's recursive function is recursively called. Propagating downwards, iterates through all subsystems. If a subsystem has published the object to its parent system, the subsystem's recursive function is recursively called. This generates the initial object routes for the system entities.

[0059] Furthermore, the entities traversed during the recursive process are recorded, and the routing relationships are recorded in the routing table of each system, updating the object routing table of the relevant models. The system traverses the set of interactions that need to be subscribed to from the parent system, propagating upwards. If the current system has subscribed to the interaction and a parent system exists, the parent system's recursive function is recursively called. The process then propagates downwards, traversing all subsystems. If a subsystem has published the object to the parent system, the subsystem's recursive function is recursively called to generate the initial interaction routes for the system entities.

[0060] Furthermore, the entities traversed during the recursive process are recorded, and the routing relationships are recorded in the interaction routing table of each system, updating the interaction routing table of the relevant models.

[0061] Step 108: Based on the relationships between the object tree models, create an object routing table and an interaction routing table within each object tree model entity.

[0062] Specifically, the system creates an object routing table by iterating through all objects to be created in the model's creation list and adding newly created objects to the subscriber's local blackboard sequentially. It also deletes objects from the model's deletion list by iterating through the model's deletion list and deleting them sequentially from the subscriber's local blackboard sequentially. Finally, it updates the object routing table by iterating through all objects to be updated in the model's update list and updating them sequentially from the subscriber's local blackboard sequentially. Through relevant functions, users can perform creation, deletion, and update operations on objects on their local blackboard and access the objects directly through the local interface.

[0063] Furthermore, by sending model function calls to create, delete, and update corresponding function execution callbacks, objects are sent to the relevant subscribed models.

[0064] Step 110: Based on the established object routing table, implement point-to-point direct memory access between objects.

[0065] Specifically, it iterates through all target model sets under the interaction object. It checks the subscription status of all models, and based on the previously created interaction routing table, calls the relevant functions to check if they have subscribed to this interaction. If they have, it calls the interaction sending function to send the interaction to the model.

[0066] Further, interactive events are generated and sent, and the engine information of the sender and receiver is obtained. The engine relationship is determined; if they are from the same engine, a priority queue is used; otherwise, they are entered into a cross-engine cache queue. The engine scheduler retrieves the interactive event from the planned event pair queue and executes the callback function. Through the callback function, subscribers can directly access the interaction via their local interface. When an entity is deleted later, its ID is directly removed from the model's interactive subscriber routing table.

[0067] Step 112: Using the interactive routing table, coordinate the collaborative behavior among multiple objects to complete task collaboration and state synchronization.

[0068] Specifically, first, an object-specific blackboard is created for each object type, and a map container is allocated for each object type, with the object ID as the key and the shared pointer to the object as the value. Then, the routing between the parent system and the current system is established based on the created object routing table.

[0069] Further, iterate through all object IDs stored in the parent system's local blackboard to form a list of IDs to be processed. Query the current system's subscription set to determine if the currently iterated object ID exists in that set. If the object ID to be stored is in the parent system's subscription set, copy the object's subscription data from the parent system's local blackboard. Insert the shared pointer of the object to be copied into the current system's local blackboard, return to the object description file parsing step, and process the next object ID until all IDs have been traversed.

[0070] Step 114: After creating a local blackboard for each type of object, the subsystem copies the object from the parent system's local blackboard, completing the inheritance and sharing of object data.

[0071] In the aforementioned bidirectional routing method for multi-level models, a multi-level object tree with clear parent-child relationships is first constructed by parsing the scenario file, inheriting the advantages of hierarchical management in terms of clear structure and logical isolation. Its key innovation lies in not relying on this tree structure for layer-by-layer forwarding of communication, but instead creating an independent "object routing table" and "interaction routing table" for each model entity. These two routing tables are established through a one-time bidirectional recursive propagation, accurately recording the direct communication relationships between models across any level. This enables point-to-point direct access for data storage (via the object routing table) and behavioral collaboration (via the interaction routing table) between objects, thus solving the real-time bottleneck. Simultaneously, the independent existence of the "interaction routing table" allows for flexible configuration and efficient execution of task collaboration and state synchronization logic, meeting the needs of complex collaborative scenarios. Regarding data inheritance, a "local blackboard" replication mechanism is adopted. Subsystems only need to copy their subscribed object data from the parent system's blackboard, achieving on-demand, efficient data sharing and inheritance. This avoids the overhead of global copying and ensures fast local access to data within the subsystem, significantly improving storage efficiency. In summary, this approach not only maintains the hierarchical architecture of the system for easier management and expansion, but also enables direct and efficient communication and collaboration across layers and subsystems through built-in bidirectional routing capabilities, ultimately resulting in significant improvements in overall performance, real-time response, and system scalability.

[0072] In one embodiment, all models under the root model are traversed to obtain the system entities corresponding to each model. For object routing, bidirectional propagation is performed to establish routing relationships. Specifically, upward propagation is performed: if the current system subscribes to the current object and a parent system exists, the forwarding function of the parent system is recursively called. Downward propagation is performed: all subsystems are traversed; if the current subsystem publishes the current object to the parent system, the forwarding function of the current subsystem is recursively called. The traversed system entities are recorded, and the established routing relationships are recorded in the object routing table of each system. For interaction routing, bidirectional propagation is performed to establish routing relationships. Specifically, upward propagation is performed: if the current system subscribes to the current interaction and a parent system exists, the forwarding function of the parent system is recursively called. Downward propagation is performed: all subsystems are traversed; if the current subsystem publishes the current interaction to the parent system, the forwarding function of the current subsystem is recursively called. The traversed system entities are recorded, and the established routing relationships are recorded in the interaction routing table of each system.

[0073] In one embodiment, after establishing the route between the parent system and the current system, all object identifiers stored in the parent system's local blackboard are traversed to form a list to be processed. The object subscription set of the current system is queried to determine whether the currently traversed object identifier exists in the object subscription set. If it exists, the data of the current object is copied from the parent system's local blackboard to the current system's local blackboard.

[0074] In one embodiment, when there are objects to be created, deleted, or updated, the corresponding model creation list, model deletion list, or model update list are traversed according to the object operation type.

[0075] Based on each object in the created list, the object routing table is traversed to determine the model identifiers of all subscribed objects. A corresponding object event is generated for each subscribed model, and depending on whether the sender and receiver belong to the same engine, the object event is inserted into either the priority event queue or the cached event queue. The engine scheduler retrieves the event from the event queue and executes the callback, enabling the subscribed model to perform object creation, deletion, or update operations on the parent system's local blackboard, achieving point-to-point direct memory access between objects.

[0076] In one embodiment, when a current interaction occurs, the set of all target models under the object in the current interaction is traversed. For each model in the target model set, the interaction routing table is queried to determine whether the current model has subscribed to the current interaction. If subscribed, an interaction event is generated for the current model, and depending on whether the interacting parties belong to the same engine, the event is inserted into a priority event queue or a cached event queue, respectively. The engine scheduler retrieves the interaction event from the event queue and executes a callback. Subscribed models access and process the current interaction through a local interface to coordinate the collaborative behavior between multiple objects, completing task collaboration and state synchronization.

[0077] In one embodiment, based on the path of the object description file in the scenario file, the object description file is parsed, the models in the object description file are traversed, and model information is initialized. The set of publishing objects in the object description file is traversed, and the publishing objects are stored in the publishing information set of the corresponding model. The set of subscribed objects in the object description file is traversed, and the subscribed objects are stored in the subscription information set of the corresponding model. The set of publishing interactions in the object description file is traversed, and the publishing interactions are stored in the publishing interaction set of the corresponding model. The set of subscription interactions in the object description file is traversed, and the subscription interactions are stored in the subscription interaction set of the corresponding model. The publishing information set, the subscription information set, the publishing interaction set, and the subscription interaction set are integrated to obtain the model publishing / subscription information defined in the object description file.

[0078] In one embodiment, the created root model is used as the parent model and registered with the model manager. A parent-child hierarchy is established, and subsystems are recursively added and configured under the parent model. It is determined whether the newly created model belongs to the same logical group as the parent model. If they belong to the same group, a routing table is created immediately, and models within the group directly share blackboard data; if they do not belong to the same group, the parameters of the newly created model are added to the batch processing list, the creation of the routing table is delayed, and the parent system is synchronized through the corresponding subsystem synchronization function.

[0079] In one embodiment, such as Figure 2 As shown, a flow chart for bidirectional routing in a multi-level model is provided, with the specific steps as follows:

[0080] 1) Initialize the model list based on the model information in the entity list of the scenario file, and then parse the publish / subscribe attributes between models according to the object description file;

[0081] 2) Using the root model as the sole parent model, construct a multi-level object tree model with a clear parent-child inheritance relationship;

[0082] 3) Based on the relationships between the models, create an object routing table and an interaction routing table within each model entity;

[0083] 4) Based on the established object routing table, point-to-point direct memory access between objects is enabled, avoiding multi-level forwarding and improving communication efficiency and real-time performance;

[0084] 5) With the help of the interactive routing table, the system can coordinate the collaborative behavior between objects to achieve efficient task collaboration and state synchronization;

[0085] 6) After the route is created, the subsystem will copy the object from the parent system's local blackboard, thereby realizing the inheritance and sharing of object data and achieving efficient memory access.

[0086] It is worth noting that, such as Figure 3 As shown, a hierarchical object system and a logical structure between various modules of bidirectional routing are provided, and the corresponding program modules include:

[0087] The scenario file and object description file parsing module: First, based on the object description file path specified in the scenario file, it parses the object description file to obtain the list of model entities and their published attributes; then, it iterates through the model information in all model trees under the root model, checking if a model with the same name exists in the model information list modelInfoTable, and if so, skips that model; it then iterates through the collection of published objects in the description file. <pubobeject>Store the published objects in the model's published information collection; iterate through the collection of subscribed objects in the description file. <subobeject>Store the subscribed objects in the model's subscription information set; iterate through the set of interaction information published in the description file. <pubinter>The published interaction information is stored in the model's published interaction information set; the subscribed interaction information sets in the description file are traversed. <subinter>The subscribed interaction information is stored in the model's subscription interaction information set.

[0088] The multi-level model creation module uses the root model (RootModel) as the sole entry point and recursively creates all child objects, forming an object tree with a clear parent-child inheritance relationship. For example, SoldierMan and PlaneJ-20 are its child objects, and two tank models, Tank99a and Tank100a, are further created under the soldier model SoldierMan. The generated models are registered and added to the model manager to handle object and interaction callbacks. Parent-child hierarchical relationships are established, subsystems are dynamically created and configured, and a multi-level model system is generated. If the created models are not in the same group (logical subsystem), model parameters are processed in batches through the model creation list m_createCommitList, the creation of the routing table is delayed, and finally the system synchronization function SystemManager::sync() is called for system synchronization. If the created models belong to the same group (logical subsystem), the corresponding model pointers are generated through the model generation function generateModel, and the routing table is created immediately. Models in the same group directly share blackboard data.

[0089] The route creation module first iterates through all models under the root model RootModel, obtaining the corresponding system entity _system for each model. It then iterates through the set of objects in the system that need to be subscribed to by the parent system, m_objectSubToParent, and performs bidirectional propagation: upward propagation—if the current system has subscribed to the object (subObject in interSubToParent) and a parent system exists, the parent system's recursive function forwardObject is called recursively; downward propagation—it iterates through all subsystems, and if a subsystem has published the object to its parent system (subObject in m_objectPubToParent), the subsystem's recursive function forwardObject is called recursively. The module records the entities traversed during the recursion and records the routing relationships in the routing table of each system, then updates the object routing table m_objectRoutingTable for the relevant models. The system iterates through the set of interactions that need to be subscribed to by the parent system, `m_interSubToParent`, and performs bidirectional propagation: Upward propagation: if the current system has subscribed to the interaction (`subObject` is in `interSubToParent`) and a parent system exists, the parent system's recursive function `forwardObject` is called recursively; Downward propagation: traverses all subsystems, and if a subsystem has published the object to the parent system (`subObject` is in `m_objectPubToParent`), the subsystem's recursive function `forwardObject` is called recursively. The system records the entities traversed during the recursion and records the routing relationships in the interaction routing table of each system, then updates the interaction routing table `m_interRoutingTable` of the relevant models.

[0090] The object routing efficient memory access module: It creates an object routing table, iterates through all objects to be created in the model creation list `m_createCommitList`, and adds newly created objects to the subscriber's local blackboard sequentially by iterating through the routing table established in step 3). It deletes objects in the object routing table, iterates through all objects to be deleted in the model deletion list `m_deleteCommitList`, and deletes objects to be deleted sequentially by iterating through the routing table established in step 3). It updates the object routing table, iterates through all objects to be updated in the model update list `m_updateCommitList`, and updates objects to be updated sequentially by iterating through the routing table established in step 3). It creates callback functions, calls the corresponding callback functions for creation, deletion, and update in the `sendObjectToModel` function to execute the callbacks, and sends the objects to the relevant subscribed models. On the subscriber's local blackboard, operations such as creation, deletion, and update can be performed on the objects, and the objects can be accessed directly through the local interface.

[0091] The efficient memory access module for interactive routing works as follows: First, it iterates through the set of all target models (modelVec) under the interactive object; it checks the subscription status of all models, and based on the previously created interactive routing table, calls the PubAndSubManager::isExistInBitTable() function to check whether the model has subscribed to this interaction. If it has, it calls the interaction sending function sendInterToModel to send the interaction to the model; it generates and sends interactive events, and obtains the engine information of the sender and receiver; it determines the engine relationship, and if they are in the same engine, it uses a priority queue; otherwise, it enters the cross-engine cache queue; the engine scheduler retrieves the interactive event from the scheduled event pair queue m_scheduleEventQueue, and subscribers can directly access the interaction through the local interface via the callback function; when an entity is deleted later, it is directly deleted by recursively checking the interactive routing table of all entities.

[0092] The local blackboard copy construction module first establishes the route between the parent system and the current system; it then iterates through all object IDs stored in the parent system's local blackboard to form a list of IDs to be processed, queries the current system's subscription set m_objectSubToParent, and determines whether the currently iterated object ID exists in the set; if it exists, it copies the object's subscription data from the parent system's local blackboard; it repeats the above process until all objects have been processed.

[0093] In one embodiment, such as Figure 4 As shown, a workflow for a scenario file and object description file parsing module is provided, with the following specific steps:

[0094] Step 401. Program begins;

[0095] Step 402. Parse the specified scenario and object description file;

[0096] Step 403. Check if the parsing was successful. If not, output a failure log and return false; if yes, proceed to step 404.

[0097] Step 404. The program parses and obtains the root model information;

[0098] Step 405. Determine if the root model exists. If not, output a failure log and return false; if yes, proceed to step 408.

[0099] Step 406. Output the failure log;

[0100] Step 407. Return false;

[0101] Step 408. Traverse all models under the model, specifically traversing the models in the model information list modelInfoTable; Step 409. Obtain the corresponding model name;

[0102] Step 410. Determine if the corresponding model exists. If not, proceed to step 425; if yes, execute step 411.

[0103] Step 411. Initialize model information modelInfo, and execute steps 412-415 in parallel;

[0104] Step 412. Traverse the pubObeject collection of publication objects in the description file and store the publication objects into the model's publication information collection pubObeject;

[0105] Step 413. Traverse the sub-subject collection of subscription objects in the description file and store the subscription objects into the model's subscription information collection sub-subject;

[0106] Step 414. Traverse the published interaction information set pubInter in the description file and store the published interaction information into the model's published interaction information set pubInter;

[0107] Step 415. Traverse the subscribed interaction information set subInter in the description file and store the subscribed interaction information into the model's subscribed interaction information set subInter;

[0108] Step 416. Determine whether the object name objectName is in the model's pubObjectSet based on the traversal result of step 412. If not, proceed to step 425. If yes, proceed to step 420 and insert it into pubObjectSet.

[0109] Step 417. Determine whether the object name objectName of the traversal result in step 413 is in the model's subObejectSet. If not, proceed to step 425. If yes, proceed to step 421 and insert it into subObejectSet.

[0110] Step 418. Determine whether the object name interName is in the model's pubInterSet based on the traversal result of step 414. If not, proceed to step 425. If yes, proceed to step 422 and insert it into pubInterSet.

[0111] Step 419. Determine whether the object name interName is in the model's subInterSet based on the traversal result of step 415. If not, proceed to step 425; if yes, proceed to step 423 and insert it into subInterSet.

[0112] Step 424. Insert the execution results of steps 420-423 into the model information list modelInfoTable;

[0113] Step 425. Determine whether all models have been traversed. If not, jump to step 409. If yes, execute step 426.

[0114] Step 426, this module's process ends. In one embodiment, such as... Figure 5 As shown, a workflow for a multi-level model creation module is provided, with the following specific steps:

[0115] Step 501. Program begins;

[0116] Step 502. Create the root model RootModel and create model entities with it as the unique parent model;

[0117] Step 503. Register the model to the model manager;

[0118] Step 504. Establish a parent-child hierarchical relationship and add corresponding subsystems under the parent model;

[0119] Step 505. Determine whether the established models belong to the same group. If yes, call the model generation function generateModel to generate model pointers and execute steps 509-511; otherwise, jump to steps 506-508.

[0120] Step 506. Call the model generation function generateModel to generate a model pointer;

[0121] Step 507. Delay the creation of the routing table;

[0122] Step 508. Use the model creation list m_createCommitList to batch process model data;

[0123] Step 509. Call the model generation function generateModel to generate a model pointer;

[0124] Step 510. Create the routing table immediately;

[0125] Step 511. Models within the same group directly share blackboard data;

[0126] Step 512. This module's process ends.

[0127] In one embodiment, such as Figure 6 As shown, a workflow for a routing relationship creation module is provided, with the following specific steps:

[0128] Step 601. First, traverse all models under the root model RootModel and obtain the system entity _system corresponding to each model in turn;

[0129] Step 602. Establish object routes;

[0130] Step 603. Propagate upwards;

[0131] Step 604. Determine if the current system has subscribed to the object and it exists in the parent system. If so, proceed to step 605.

[0132] Step 605. Call the parent system's recursive function forwardObject;

[0133] Step 606. Propagate downwards;

[0134] Step 607. Traverse all subsystems and determine whether the subsystem has published the object to the parent system. If so, proceed to step 608.

[0135] Step 608. Call the subsystem's recursive function forwardObject;

[0136] Step 609. Record the entities that have been traversed: Calculate the results of steps 605 and 608, and use the set container _forwardObjectVisited to record the entities that have been traversed;

[0137] Step 610. Update object routes: Call the object route update function updateObjectRouting to update the object routes;

[0138] Proceed to step 611 to establish an interactive route;

[0139] Step 612. Propagate upwards;

[0140] Step 613. Determine if the current system has subscribed to the interaction and it exists in the parent system. If yes, proceed to step 614; otherwise, proceed to step 618.

[0141] Step 614. Recursively call the parent system's forwardObject function;

[0142] Step 615. Propagate downwards;

[0143] Step 616. Traverse all subsystems and determine whether the subsystem has published the interaction to the parent system. If yes, proceed to step 617; otherwise, proceed to step 618.

[0144] Step 617. Recursively call the subsystem's forwardObject function;

[0145] Step 618. Record the entities that have been traversed: Calculate the results of steps 614 and 617, and use the set container _forwardObjectVisited to record the entities that have been traversed;

[0146] Step 619. Update Interactive Routes: Call the interactive route update function updateInterRouting to update the interactive routes;

[0147] Step 620. Route establishment complete: Object routes and interaction routes have been established.

[0148] Step 621. This module's process ends.

[0149] In one embodiment, such as Figure 7 As shown, a workflow for an efficient memory access module based on an object routing table is provided, with the following specific steps:

[0150] Step 701. Module flow begins;

[0151] Steps 702, 704, and 706 are executed in parallel.

[0152] Step 702. Create an object routing table;

[0153] Step 703. Iterate through all objects to be created in the model creation list m_createCommitList, and insert the objects to be created into the local blackboard;

[0154] Step 704. Delete the object routing table;

[0155] Step 705. Iterate through all objects to be deleted in the model deletion list m_deleteCommitList, and insert the objects to be deleted into the local blackboard;

[0156] Step 706. Update the object routing table;

[0157] Step 707. Iterate through all objects to be updated in the model update list m_updateCommitList, and insert the objects to be updated into the local blackboard;

[0158] Step 708. Traverse the object routing table: Traverse the object routing table created in the route creation module;

[0159] Step 709. Execute the object callback for each ModelID that subscribes to the object;

[0160] Step 710. Create a callback function, obtain the subscriber system object, and insert the object into the local blackboard;

[0161] Step 711. Call the function sendObjectToModel to send the object to the relevant subscribed model;

[0162] Step 712. Generate and send object events, and obtain sender and receiver engine information;

[0163] Step 713. Determine if the objects are from the same engine: if yes, proceed to step 714; if no, proceed to step 715.

[0164] Step 714. Insert into priority queue: Insert the object information into the priority event queue m_scheduleEventQueue;

[0165] Step 715. Insert into the cached event queue: Insert the object information into the cached event queue m_cacheEventQueue;

[0166] Step 716. Retrieve the event from the engine scheduler;

[0167] Step 717. Execute the object callback function;

[0168] Step 718. The subscriber's local blackboard can perform operations such as creating, deleting, and updating objects;

[0169] Step 719. This module's process ends.

[0170] In one embodiment, such as Figure 8 As shown, a workflow for an efficient memory access module based on an interactive routing table is provided, with the following specific steps:

[0171] Step 801. The process of this model begins;

[0172] Step 802. Traverse all target models (modelVec) under the interaction object;

[0173] Step 803. Check if the model has subscribed to this interaction: Check the subscription status of all models. Based on the previously created interaction routing table, call the PubAndSubManager::isExistInBitTable() function to check if the model has subscribed to this interaction. If it has subscribed to the interaction, proceed to step 804.

[0174] Step 804. Call sendInterToModel to send the interaction to the relevant subscribed model;

[0175] Step 805. Generate and send interactive events, and obtain sender and receiver engine information;

[0176] Step 806. Determine if the interaction is between objects from the same engine; if yes, proceed to step 807; if no, proceed to step 808.

[0177] Step 807. Insert into priority queue: Insert the interaction information into the priority event queue m_scheduleEventQueue;

[0178] Step 808. Insert into the cached event queue: Insert the interaction information into the cached event queue m_cacheEventQueue;

[0179] Step 809. Retrieve the event from the engine scheduler;

[0180] Step 810. Execute the interaction callback function;

[0181] Step 811. Subscribers access the object directly through the local interface;

[0182] Step 812. Determine whether all models have been traversed. If yes, proceed to step 813; otherwise, jump to step 803.

[0183] Step 813. This module's process ends.

[0184] In one embodiment, such as Figure 9 As shown, a workflow for a local blackboard copy building module is provided, with the following specific steps:

[0185] Step 901. This module's process begins;

[0186] Step 902. Create a local blackboard: First, create a local blackboard for each type of object, and assign a map container to each type of object, with the object ID as the key and the shared pointer to the object as the value;

[0187] Step 903. Establish object routes: Based on the established object routing table, complete the route establishment between the parent system and the current system;

[0188] Step 904. Traverse the list of all object IDs in the parent system's local blackboard: Traverse all object IDs stored in the parent system's local blackboard to form a list of IDs to be processed;

[0189] Step 905. Determine if the current object ID is in m_objectSubToParent: Query the current system's subscription collection m_objectSubToParent, and determine if the currently traversed object ID exists in the collection. If it does, proceed to step 906; otherwise, jump to step 904.

[0190] Step 906. Copy the object's subscription data from the parent system's local blackboard;

[0191] Step 907. Insert the copied object into the local blackboard of the current system;

[0192] Step 908. This module's process ends.

[0193] It should be understood that, although Figures 1-2 , Figures 4-9 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figures 1-2 , Figures 4-9 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0194] In one embodiment, such as Figure 10 As shown, a bidirectional routing system for a multi-level model is provided, including: a scenario file parsing module 1002, a subscription information acquisition module 1004, a model construction module 1006, a routing table construction module 1008, an access module 1010, a cooperative communication module 1012, and a data sharing module 1014, wherein:

[0195] The scenario file parsing module 1002 is used to parse the scenario file and obtain the entity list information defined in the scenario file.

[0196] The subscription information acquisition module 1004 is used to parse the object description file according to the path of the object description file in the concept file, and obtain the model publication and subscription information defined in the object description file.

[0197] Model building module 1006 is used to build a multi-level object tree model with parent-child inheritance relationship, using the created root model as the parent model.

[0198] The routing table building module 1008 is used to create an object routing table and an interaction routing table within each object tree model entity based on the relationships between the object tree models.

[0199] Access module 1010 is used to enable point-to-point direct memory access between objects based on the established object routing table.

[0200] The collaborative communication module 1012 is used to coordinate collaborative behaviors among multiple objects by means of an interactive routing table, so as to complete task collaboration and state synchronization.

[0201] The data sharing module 1014 is used to create a local blackboard for each type of object, and then the subsystem copies the object from the local blackboard of the parent system to complete the inheritance and sharing of object data.

[0202] Specific limitations regarding a bidirectional routing system for a multi-level model can be found in the limitations of a bidirectional routing method for a multi-level model described above, and will not be repeated here. Each module in the aforementioned bidirectional routing system for a multi-level model can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0203] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 11 As shown, the computer device includes a processor, memory, network interface, display screen, and input system connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements a bidirectional routing method oriented towards a multi-level model. The display screen can be an LCD screen or an e-ink display screen. The input system can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the computer device casing, or an external keyboard, touchpad, or mouse.

[0204] Those skilled in the art will understand that Figure 3 , Figures 10-11 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0205] In one embodiment, a computer device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to perform the following steps:

[0206] Parse the scenario file to obtain the list of entities defined in the scenario file.

[0207] Based on the path to the object description file in the concept file, parse the object description file and obtain the model publication and subscription information defined in the object description file.

[0208] Using the created root model as the parent model, construct a multi-level object tree model with parent-child inheritance relationships.

[0209] Based on the relationships between the object tree models, an object routing table and an interaction routing table are created within each object tree model entity.

[0210] Based on the established object routing table, point-to-point direct memory access between objects is enabled.

[0211] By leveraging interactive routing tables, collaborative behaviors among multiple objects can be coordinated to achieve task collaboration and state synchronization.

[0212] After creating a local blackboard for each type of object, the subsystem copies the object from the parent system's local blackboard, thus completing the inheritance and sharing of object data.

[0213] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0214] Parse the scenario file to obtain the list of entities defined in the scenario file.

[0215] Based on the path to the object description file in the concept file, parse the object description file and obtain the model publication and subscription information defined in the object description file.

[0216] Using the created root model as the parent model, construct a multi-level object tree model with parent-child inheritance relationships.

[0217] Based on the relationships between the object tree models, an object routing table and an interaction routing table are created within each object tree model entity.

[0218] Based on the established object routing table, point-to-point direct memory access between objects is enabled.

[0219] By leveraging interactive routing tables, collaborative behaviors among multiple objects can be coordinated to achieve task collaboration and state synchronization.

[0220] After creating a local blackboard for each type of object, the subsystem copies the object from the parent system's local blackboard, thus completing the inheritance and sharing of object data.

[0221] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), Synchlink, DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.

[0222] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0223] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.< / subinter> < / pubinter> < / subobeject> < / pubobeject>

Claims

1. A bi-directional routing method for a multi-level model, characterized by, The method includes: Parse the scenario file to obtain the entity list information defined in the scenario file; Based on the path of the object description file in the scenario file, parse the object description file and obtain the model publication and subscription information defined in the object description file; Using the created root model as the parent model, construct a multi-level object tree model with parent-child inheritance relationships; Based on the relationships between the various object tree models, an object routing table and an interaction routing table are created within each object tree model entity. Traverse all models under the root model to obtain the system entity corresponding to each model; For object routing, bidirectional propagation is performed to establish routing relationships. The specific steps are as follows: perform upward propagation. If the current system has subscribed to the current object and there is a parent system, then the forwarding function of the parent system is recursively called. Perform downward propagation, traversing all subsystems. If the current subsystem publishes the current object to the parent system, then recursively call the forwarding function of the current subsystem. Record the system entities that have been traversed, and record the established routing relationships in the object routing table of each system; For interactive routes, bidirectional propagation is performed to establish routing relationships. The specific steps are as follows: perform upward propagation. If the current system has subscribed to the current interaction and a parent system exists, the forwarding function of the parent system is recursively called. Perform downward propagation, traversing all subsystems. If the current subsystem publishes the current interaction to the parent system, then recursively call the forwarding function of the current subsystem. Record the system entities that have been traversed, and record the established routing relationships in the interaction routing table of each system; Based on the established object routing table, point-to-point direct memory access between objects is achieved; The interactive routing table is used to coordinate the collaborative behaviors of multiple objects, thereby completing task collaboration and state synchronization. After creating a local blackboard for each type of object, the subsystem copies the object from the parent system's local blackboard, thus completing the inheritance and sharing of object data.

2. The method of claim 1, wherein, After creating a local blackboard for each type of object, the subsystem copies the object from the parent system's local blackboard, completing the inheritance and sharing of object data, including: After establishing the route between the parent system and the current system, all object identifiers stored in the local blackboard of the parent system are traversed to form a list to be processed. Query the object subscription set of the current system, and determine whether the identifier of the currently traversed object exists in the object subscription set. If it exists, copy the data of the current object from the local blackboard of the parent system to the local blackboard of the current system.

3. The method according to any one of claims 1 to 2, characterized in that, Based on the established object routing table, point-to-point direct memory access between objects is implemented, including: When there are objects to be created, deleted, or updated, the corresponding model creation list, model deletion list, or model update list are traversed according to the object operation type. Based on each object in the created list, traverse the object routing table to determine the model identifiers of all those subscribing to the current object; Generate a corresponding object event for each subscription model, and insert the object event into the priority event queue or the cached event queue respectively, depending on whether the sender and receiver belong to the same engine. The engine scheduler retrieves events from the event queue and executes callbacks, enabling the subscription model to perform object creation, deletion, or update operations on the local blackboard of the parent system, thus achieving point-to-point direct memory access between objects.

4. The method of claim 3, wherein, The interactive routing table is used to coordinate collaborative behaviors among multiple objects, enabling task collaboration and state synchronization, including: When the current interaction occurs, iterate through all target model sets under the object in the current interaction; For each model in the target model set, query the interaction routing table to determine whether the current model has subscribed to the current interaction. If it has, generate an interaction event for the current model and insert the event into the priority event queue or the cached event queue according to whether the two parties in the interaction belong to the same engine. The engine scheduler retrieves interactive events from the event queue and executes callbacks. The subscription model accesses and processes the current interaction through a local interface to coordinate collaborative behaviors among multiple objects and complete task collaboration and state synchronization.

5. The method of claim 4, wherein, Based on the path to the object description file in the scenario file, parse the object description file to obtain the model publication / subscription information defined in the object description file, including: Based on the path of the object description file in the scenario file, parse the object description file, traverse the models in the object description file, and initialize the model information; Traverse the collection of published objects in the object description file and store the published objects into the publication information collection of the corresponding model; Iterate through the set of subscription objects in the object description file and store the subscription objects into the subscription information set of the corresponding model; Iterate through the set of publishing interactions in the object description file and store the publishing interactions into the set of publishing interactions of the corresponding model; Iterate through the subscription interaction set in the object description file and store the subscription interaction to the subscription interaction set of the corresponding model; By integrating the published information set, the subscription information set, the published interaction set, and the subscription interaction set, the model published / subscribed information defined in the object description file is obtained.

6. The method of claim 5, wherein, Using the created root model as the parent model, construct a multi-level object tree model with parent-child inheritance relationships, including: Use the created root model as the parent model and register it with the model manager; Establish a parent-child hierarchical relationship, and recursively add and configure subsystems under the parent model; Determine whether the newly created model belongs to the same logical group as the parent model. If they belong to the same group, create a routing table immediately, and models within the group directly share blackboard data. If they do not belong to the same group, add the parameters of the newly created model to the batch processing list, delay the creation of the routing table, and complete the parent system synchronization through the corresponding subsystem synchronization function.

7. A bi-directional routing system oriented to a multi-level model, characterized by, The system includes: The scenario file parsing module is used to parse the scenario file and obtain the entity list information defined in the scenario file; The subscription information acquisition module is used to parse the object description file according to the path of the object description file in the scenario file, and obtain the model publication and subscription information defined in the object description file; The model building module is used to construct a multi-level object tree model with parent-child inheritance relationships, using the created root model as the parent model. The routing table construction module is used to create an object routing table and an interaction routing table within each object tree model entity based on the relationships between the object tree models; traverse all models under the root model to obtain the system entities corresponding to each model; for object routing, perform bidirectional propagation to establish routing relationships, specifically: perform upward propagation, if the current system subscribes to the current object and a parent system exists, then recursively call the forwarding function of the parent system; perform downward propagation, traverse all subsystems, if the current subsystem publishes the current object to the parent system, then recursively call the forwarding function of the current subsystem; record the traversed system entities and record the established routing relationships in the object routing table of each system; for interaction routing, perform bidirectional propagation to establish routing relationships, specifically: perform upward propagation, if the current system subscribes to the current interaction and a parent system exists, then recursively call the forwarding function of the parent system; perform downward propagation, traverse all subsystems, if the current subsystem publishes the current interaction to the parent system, then recursively call the forwarding function of the current subsystem; record the traversed system entities and record the established routing relationships in the interaction routing table of each system. The access module is used to enable point-to-point direct memory access between objects based on the established object routing table. The collaborative communication module is used to coordinate collaborative behaviors among multiple objects by means of the interactive routing table, so as to complete task collaboration and state synchronization. The data sharing module is used to create a local blackboard for each type of object, and then the subsystem copies the object from the local blackboard of the parent system to complete the inheritance and sharing of object data.

8. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer readable storage medium having stored thereon a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images