A task-level combat simulation modeling method

Abstract

A novel task level combat simulation modeling method and framework, the method comprising the following steps: (1) determining the granularity of the task level simulation model under the support of the combat level; (2) establishing a model driven task level simulation model framework; (3) establishing a parallel distributed integrated simulation architecture based on shared objects. The framework comprises objects, the objects comprising entities, components, combatants, combat units, battlefield space scenes, communication networks and environment objects, and the entities comprising combat platforms, weapon entities, decoy entities and facility entities. The present application strictly separates the combat simulation modeling and simulation running two activities, and through a clear modeling and simulation semantic layer interface specification makes the model independent of the simulation platform, and the simulation platform can automatically support parallel, distributed, real-time and other running modes.

Description

Technical Field

[0001] This invention relates to the field of military simulation modeling technology, specifically to a novel mission-level combat simulation modeling method and framework. Background Technology

[0002] Combat simulation is generally divided into four levels from bottom to top, based on the scale of the simulation and the granularity of the model: engineering level, engagement level, mission level, and campaign level. The higher the level, the larger the scale of the participating entities and the coarser the model granularity; the lower the level, the smaller the simulation scale and the finer the model granularity. Lower-level simulations provide basic data support for upper-level simulations, while upper-level simulations provide constraints and guidance for lower-level simulations. Mission-level combat simulations generally focus on evaluating the completion of combat missions, supporting the assessment of the operational effectiveness of equipment systems under joint operational conditions. Mission-level combat simulations are generally conducted based on the results of engagement-level combat simulations. Currently, a great deal of work has been done in the construction and application research of mission-level combat simulation systems. However, this work has the following three limitations in terms of simulation modeling methods: (1) Lack of clear distinction between mission-level and engagement-level: Although there is a general consensus on the support and guidance relationship between engagement-level and mission-level systems, it is not easy to establish a specific support and guidance relationship in practice. The main reason is that the combat simulation systems at the engagement-level and mission-level are basically not standardized. The relevant systems did not (or did not have time) to consider the support and constraint relationship with other systems at the design stage, and the functional positioning and data interfaces between actual systems do not match. Therefore, many engagement-level simulation systems can support a certain scale of mission-level systems in a certain field, while many mission-level simulation systems need to simulate more granular combat processes and physical behaviors. As a result, not only is the construction of simulation model resources repeated, but the model granularity of each simulation system is not uniform. When facing further application requirements, there is a problem of difficulty in coordinating different model granularities, and the expansion and evolution of simulation systems face great difficulties.

[0003] (2) Lack of composable mission-level simulation model framework: A composable simulation model framework is key to the healthy expansion and evolution of mission-level combat simulation systems and the rapid response to user simulation application needs. Most current mission-level combat simulation systems are built on general military simulation platforms (such as FLAMES, AFSIM, VR-Force, XSIM, etc.). These platforms are generally maintained by military simulation companies. In order to support the universality of simulation platforms in simulation applications at different levels, these platforms only provide basic military simulation modeling specifications and exemplary simulation model component libraries, without composable simulation model frameworks for a specific level. When building a mission-level combat simulation system based on these platforms, it is generally necessary to redesign the relevant mission-level simulation model framework. In practice, scalable mission-level simulation model frameworks that can fully consider various needs are rare. The simulation application development modes that can be supported are mostly based on the development and integration of individual mission-level combat simulation applications. It is difficult to build a generalized composable simulation model framework for the entire mission-level combat simulation needs, and it is difficult to support the construction of mission-level combat simulation model libraries and the rapid composable development of simulation applications.

[0004] (3) Deep coupling between combat simulation model and simulation operation: Modeling is the expression of system business knowledge, and simulation is the execution and solution of the model. Depending on the application scenario and experimental requirements, simulation execution can adopt different operation modes such as centralized operation, parallel operation, distributed operation, and real-time operation. Ideally, this operation mode should be transparent to simulation modeling. That is to say, when modelers write models, they should not need to consider the simulation operation mode, but let the simulation support platform automatically realize it. Due to the lack of reasonable abstract design, current mission-level combat simulation systems are basically unable to achieve this. Most of them are based on a distributed architecture, and even when running on a single machine, they still use inter-process communication. This not only makes modeling more complex and labor-intensive, but also results in low simulation execution efficiency, difficulty in ensuring simulation repeatability, and inconvenience for large-scale simulation experiments. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to overcome the shortcomings of the above-mentioned background technology and provide a new mission-level combat simulation modeling method and framework. The invention designs a mission-level combined simulation model framework supported by the engagement level, strictly separates the two major activities of combat simulation modeling and simulation operation, and makes the model independent of the simulation platform through a clear modeling and simulation semantic layer interface specification. The simulation platform can automatically support parallel, distributed, real-time and other operation modes.

[0006] The technical solution adopted by this invention to solve its technical problem is a novel mission-level combat simulation modeling method, comprising the following steps: (1) Determine the granularity of the mission-level simulation model under engagement-level support; (2) Establish a model-driven task-level simulation model framework; (3) Establish a parallel distributed integrated simulation architecture based on shared objects.

[0007] Furthermore, in step (1), the method for determining the granularity of the mission-level simulation model under engagement-level support is as follows: (1-1) Clarify the functional positioning of engagement level and mission level: engagement level simulation answers the question of the combat effectiveness of weapons and equipment, and provides the mission level with basic combat effectiveness data of equipment, including detection range, identification probability, deception probability, kill probability, jamming range, hit accuracy and damage radius under different conditions, expressed in the form of a decision table; mission level simulation examines the combat effectiveness of equipment system in carrying out joint combat missions, and studies and analyzes the capability shortcomings of equipment system in the face of various combat mission requirements; (1-2) Determine the model interaction framework based on the information flow of combat nodes: When the model is abstracted, the information flow between each combat node is preserved, and the internal structure and behavior of each combat node are simplified with the support of the engagement level. The information interaction between different components within the same entity and the interaction between the entity and the combat environment are carried out by direct interface calls; the information flow between different entities of the same combatant is completed through network communication; the interaction between entities of different combatants is modeled in three categories: perception, damage, and interference. (1-3) Determine the spatiotemporal characteristic model granularity of various weapons and equipment based on the reference step size: clearly define the simulation reference step size of the mission level as 1 second, and abstract all activities within 1 second; for activities longer than 1 second, retain the spatiotemporal characteristics of the entity to support the establishment of combat relationships at the coordination, electronic reaction, and communication system layers; abstract and simplify the links that do not affect the establishment of relationships, such as dynamic simulation that does not affect fine granularity, flight process of unguided munitions that is not affected by communication and electronic reaction, and local support process within combat units.

[0008] Furthermore, in step (2), the method for establishing a model-driven task-level simulation model framework is as follows: (2-1) To meet the needs of various task-level simulation applications, abstract the model framework and build a task-level simulation model framework; (2-2) Decompose the various equipment entities and their combat behaviors that the model framework needs to support into components, and clarify the static interface and dynamic interaction mechanism of each component. (2-3) Based on the class diagram of the Unified Modeling Language, the composition structure of the model framework and the interface relationship of the model framework are described in a standardized manner, and the framework code is automatically generated.

[0009] Furthermore, in step (2-1), the constructed task-level simulation model framework includes objects, which include entities, components, combat parties, combat units, battlefield space scenarios, communication networks, and environmental objects. The entities include combat platforms, weapon entities, decoy entities, and facility entities. The communication network and environmental objects are respectively connected to the battlefield space scenario. The combat units are connected to the combat platforms. The combat platforms are respectively connected to the combat parties, weapon entities, and decoy entities. The weapon entities, decoy entities, and facility entities are respectively connected to the combat parties. The combat parties are connected to the battlefield space scenario. The object is an abstract class used to describe various elements in the battlefield space. It has a name and a unique identifier, and has a state. It is the basic unit of simulation scheduling and can define and schedule its own discrete events. It can access various simulation services provided by the simulation platform through the simulation service interface and can access various model services provided by the battlefield space scene through the model service interface. The entities are objects in the battlefield space that have independent spatiotemporal characteristics and are capable of independent maneuvering; they are divided into four categories: combat platforms, weapon entities, decoy entities, and facility entities. The components are functional objects that cannot be moved independently; they are mounted on different types of entities and function as functional components of those entities. The combat platform is a combat entity that can move independently in the battlefield space and exhibit rational and autonomous combat behavior under the control of commanders and soldiers. The combat platform can carry different types of components such as sensors, communication equipment, and weapon systems, providing spatial locations for these components and using these components to jointly simulate various functions and behaviors of the combat platform. The weapon entity is an entity capable of independent maneuvering and attacking a target entity to cause damage to the target entity; the weapon entity is initially mounted on a combat platform, launched under the command of the combat platform, and detaches from the combat platform to maneuver independently. The combat unit is used to describe the command post at each level, aggregate lower-level combat units or combat platforms, and command and control them. The combat parties represent the aspects involved in the operation, and different combat parties are in a hostile, neutral, or allied relationship; all combat units, combat platforms, and weapon entities are managed by the combat parties. The decoy entity is an entity that uses deception to cover the combat entity. It is launched from the combat platform, located around the combat entity being covered, and can move independently or be towed on the launching entity. For a period of time, it has similar maneuvering behavior and target characteristics to the combat entity being covered, creating confusion for the enemy's sensors to track and identify it, causing the enemy's weapons to attack the wrong target. The decoy effect of the decoy entity is reflected by the decoy probability, which is given by the engagement-level simulation test. The battlefield facilities mentioned are those deployed by a combatant and that can affect the combat behavior of both sides; battlefield facilities can be targeted and destroyed by the enemy; battlefield facilities influence the combat behavior of combat entities through environmental services. The battlefield space scene is responsible for managing and scheduling various objects and environmental objects belonging to different combat parties within the battlefield space, and providing various model services for each object model to access. The communication network is an abstract description of various communication networks for sharing information between combat entities. It is responsible for managing communication equipment nodes and their topological relationships, reflecting channel communication capabilities, and simulating the message transmission process. The communication network is managed by the battlefield space scenario. The environmental objects are those established in the scenario that will affect the combat behavior of the entities, including geographical location, combat area, and weather cloud formations; the state of the environmental objects themselves may change, and the environmental objects are managed by the battlefield space scenario and provided to the simulation model through environmental services.

[0010] Furthermore, in step (2-2), based on the model framework, the interfaces between components form a hierarchical interface system.

[0011] Furthermore, in steps (2-3), state diagrams are used to standardize the modal behavior of model components, class diagrams in the Unified Modeling Language are used to describe the interaction relationships between model framework objects, and activity diagrams are used to graphically describe the interface behavior of model components, which correspond one-to-one with the code, thereby realizing the model-driven description of the model framework.

[0012] Furthermore, in step (3), the method for establishing a parallel distributed integrated simulation architecture based on shared objects is as follows: (3-1) Determine the automatic distribution mechanism for models based on shared objects; (3-2) Determine the simulation clock synchronization mechanism under distributed operation mode; (3-3) Determine the parallel scheduling execution algorithm for the entity-based model engine.

[0013] Furthermore, in step (3-1), the implementation of the automatic distribution mechanism of shared objects is based on three modules: battlefield space object database, battlefield space object manager, and battlefield space interaction manager; the battlefield space object database is responsible for managing the real state data of all objects in the battlefield space scene that need to be shared among entities at the previous simulation moment; the battlefield space object database serves as the complete set of battlefield space object databases for the simulation engine to query real information, and is also used for distributed sharing among computing nodes. The Battlefield Space Object Manager serves as a bridge between the Battlefield Space Scene and the Battlefield Space Object Database. Its main functions include: 1) managing lists of various local and remote objects within the Battlefield Space, acting as both a query interface for object status information from the previous simulation moment and a unified interface for updating the status of all objects after the current simulation moment is completed; 2) acting as a coordinator for interactions between objects: for local object interactions, it directly calls back its interaction function interface; for remote object interactions, it immediately sends the interaction to the node where the remote object is located through the Battlefield Space Object Manager. The Battlefield Space Interaction Manager is only enabled in distributed simulation mode. It supports local objects sending interaction messages to objects located on remote nodes. The Battlefield Space Object Manager calls the Manager as needed and receives interactions sent to the local node from the distributed middleware. The Manager then forwards the interactions to the objects to which they belong for processing.

[0014] Furthermore, in step (3-2), two synchronization points are set for each simulation advancement. The first synchronization point is the global unified time synchronization of the simulation engine. The simulation thread of each node begins to traverse the entities on its own node to advance the clock. If the advancement involves interaction with objects located on remote nodes, the relevant interaction is immediately sent through the battlefield space object manager. The callback thread of each node is responsible for receiving the interaction sent to itself and handing it over to the relevant object for processing, thereby modifying the state of the local object. The second synchronization point is to ensure that each node has completed the traversal and remote interaction reception and processing, and then enters the object state synchronization stage, synchronizing all local modifications in the battlefield space object manager to the battlefield space object managers of other nodes. Clock synchronization is achieved through synchronization between battlefield space scene instances, and is handled by the battlefield space scene on the master node. When the battlefield space scene on the slave node finishes executing the current step, it reports the completion of the current step to the master node through a remote procedure call. After collecting the reports from all nodes, the master node completes synchronization and sends a unified time synchronization interaction to each node, and each node begins to advance the current step.

[0015] Furthermore, in step (3-3), the model engine schedules on an entity-by-entity basis, using a combination of fixed baseline step size advancement and discrete event advancement. Within each step size, it first traverses all communication networks to receive messages; then it traverses all environmental objects to calculate states; then it traverses all entities; then it achieves object state synchronization, synchronizing the object states to the battlefield space object database, and synchronizing with other nodes in distributed mode; finally, it advances the simulation clock.

[0016] A novel mission-level combat simulation modeling framework includes objects, which include entities, components, combat parties, combat units, battlefield space scenarios, communication networks, and environmental objects. The entities include combat platforms, weapon entities, decoy entities, and facility entities. The communication network and environmental objects are respectively connected to the battlefield space scenario. The combat units are connected to the combat platforms. The combat platforms are respectively connected to the combat parties, weapon entities, and decoy entities. The weapon entities, decoy entities, and facility entities are respectively connected to the combat parties. The combat parties are connected to the battlefield space scenario. The object is an abstract class used to describe various elements in the battlefield space. It has a name and a unique identifier, and has a state. It is the basic unit of simulation scheduling and can define and schedule its own discrete events. It can access various simulation services provided by the simulation platform through the simulation service interface and can access various model services provided by the battlefield space scene through the model service interface. The entity is an object in the battlefield space with independent spatiotemporal characteristics, capable of independent maneuvering; The components are functional objects that cannot be moved independently; they are mounted on different types of entities and function as functional components of those entities. The combat platform is a combat entity that can move independently in the battlefield space and exhibit rational and autonomous combat behavior under the control of commanders and soldiers. The combat platform can carry different types of components such as sensors, communication equipment, and weapon systems, providing spatial locations for these components and using these components to jointly simulate various functions and behaviors of the combat platform. The weapon entity is an entity capable of independent maneuvering and attacking a target entity to cause damage to the target entity; the weapon entity is initially mounted on a combat platform, launched under the command of the combat platform, and detaches from the combat platform to maneuver independently. The combat unit is used to describe the command post at each level, aggregate lower-level combat units or combat platforms, and command and control them. The combat parties represent the aspects involved in the operation, and different combat parties are in a hostile, neutral, or allied relationship; all combat units, combat platforms, and weapon entities are managed by the combat parties. The decoy entity is an entity that uses deception to cover the combat entity. It is launched from the combat platform, located around the combat entity being covered, and can move independently or be towed on the launching entity. For a period of time, it has similar maneuvering behavior and target characteristics to the combat entity being covered, creating confusion for the enemy's sensors to track and identify it, causing the enemy's weapons to attack the wrong target. The decoy effect of the decoy entity is reflected by the decoy probability, which is given by the engagement-level simulation test. The battlefield facilities mentioned are those deployed by a combatant and that can affect the combat behavior of both sides; battlefield facilities can be targeted and destroyed by the enemy; battlefield facilities influence the combat behavior of combat entities through environmental services. The battlefield space scene is responsible for managing and scheduling various objects and environmental objects belonging to different combat parties within the battlefield space, and providing various model services for each object model to access. The communication network is an abstract description of various communication networks for sharing information between combat entities. It is responsible for managing communication equipment nodes and their topological relationships, reflecting channel communication capabilities, and simulating the message transmission process. The communication network is managed by the battlefield space scenario. The environmental objects are those established in the scenario that will affect the combat behavior of the entities, including geographical location, combat area, and weather cloud formations; the state of the environmental objects themselves may change, and the environmental objects are managed by the battlefield space scenario and provided to the simulation model through environmental services.

[0017] Compared with the prior art, the advantages of the present invention are as follows: (1) The mission-level combat simulation modeling method provided by the present invention clarifies the distinction and support relationship between mission level and engagement level, establishes the overall model granularity of mission-level combat simulation, and lays the foundation for building a sustainable mission-level combat simulation system.

[0018] (2) The mission-level combat simulation modeling method provided by the present invention comprehensively considers the application requirements for the evaluation of the combat effectiveness of various equipment systems under joint operations conditions, and adopts component-based modeling technology to build a generalized and scalable mission-level combined simulation modeling framework, which can realize the rapid combined construction of various mission-level combat simulation applications and support the construction of a unified mission-level combat simulation reusable model library.

[0019] (3) The mission-level combat simulation modeling method provided by the present invention comprehensively utilizes graphical and driven modeling technologies such as UML class diagrams, state diagrams, sequence diagrams, and activity diagrams to support the model-driven construction of mission-level combat simulation models, thereby improving the maintainability of simulation models and the evolvability of mission-level combat simulation systems.

[0020] (4) The mission-level combat simulation modeling method provided by the present invention is based on distributed shared object technology, supports complete decoupling of modeling and simulation, realizes that the simulation operation mode is completely transparent to the simulation model, automatically supports various operation modes such as parallel, distributed and real-time, and truly realizes one-time modeling and on-demand operation, so that modelers can focus only on modeling work. Attached Figure Description

[0021] Figure 1 This is the structure of the task-level simulation model framework provided in the embodiments of the present invention.

[0022] Figure 2 This is the component model framework provided in the embodiments of the present invention.

[0023] Figure 3 This is the combat platform model framework provided in the embodiments of the present invention.

[0024] Figure 4 This is the equipment model interface layer provided in the embodiments of the present invention.

[0025] Figure 5 This is the model service interface provided in the embodiments of the present invention.

[0026] Figure 6 This is the simulation service interface provided in the embodiments of the present invention.

[0027] Figure 7 This is the distributed sharing overall architecture provided in the embodiments of the present invention.

[0028] Figure 8 This is the state synchronization mechanism between distributed nodes provided in the embodiments of the present invention. Detailed Implementation

[0029] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0030] The method in this embodiment includes the following steps: (1) Determine the granularity of the mission-level simulation model under engagement-level support; First, the functional positioning of engagement-level and mission-level simulations must be clearly defined. Engagement-level simulations primarily address the operational effectiveness of weapons and equipment, providing mission-level simulations with basic operational effectiveness data, including detection range, identification probability, deception probability, kill probability, jamming range, hit accuracy, and damage radius under different conditions, generally represented in the form of decision tables. Mission-level simulations primarily examine the operational effectiveness of equipment systems in carrying out joint operational missions, and based on this, analyze the capability shortcomings of equipment systems in facing various operational mission requirements. Each mission-level simulation model is designed with clearly defined engagement-level effectiveness data or data tables, ensuring that the relevant engagement-level simulation system can support it, allowing direct lookup of tables based on relevant engagement situation conditions during use.

[0031] Secondly, the model interaction framework is determined based on the information flow of combat nodes. Mission-level modeling focuses on system-wide operational effectiveness; therefore, the information flow between the various nodes constituting the system is crucial to its effectiveness. The model abstraction must preserve the information flow between combat nodes to support the impact of command and control architecture, force coordination, electromagnetic environment effects, and network communication transmission on mission operational effectiveness. The internal structure and behavior of each combat node are simplified as much as possible with engagement-level support. Information interaction between different components within the same entity and between the entity and the operational environment are achieved through direct interface calls; information flow between different entities of the same combatant is mainly accomplished through network communication; and interactions between entities of different combatants are modeled in three categories: perception, damage, and jamming.

[0032] Third, the granularity of the spatiotemporal characteristic models for various weapons and equipment is determined based on a baseline step size. One reason why previous mission-level simulations and engagement-level simulations did not differentiate between levels is that some modelers in certain equipment domains were reluctant to simplify their self-developed equipment models, resulting in generally finer-grained models. This method, in its design, first explicitly sets the baseline step size for mission-level simulations to 1 second. All activities within 1 second are abstracted, such as radar scanning, weapon guidance, trajectory encounters, and artillery flight, and are placed in engagement-level combat simulations, directly providing simulation results to the mission level without affecting the effectiveness of mission-level modeling. For activities longer than 1 second, the principle is to retain the spatiotemporal characteristics of the entities, focusing on supporting the establishment of system-level combat relationships such as coordination, electronic warfare, and communication. Any aspects that do not affect the establishment of these relationships (such as fine-grained dynamic simulations, unguided munitions flight processes without the influence of communication and electronic warfare, and local support processes within combat units) are abstracted and simplified.

[0033] (2) Establish a model-driven task-level simulation model framework; First, a modeling approach centered on a model framework is adopted. The model framework is abstracted to meet the needs of various mission-level simulation applications, building a generalized mission-level simulation model framework. The basic modeling concepts of the established mission-level simulation model framework include 12 elements: objects, entities, components, combatants, combat platforms, combat units, weapon entities, decoy entities, facility entities, battlefield space scenarios, communication networks, and environmental objects. Objects include entities, components, combatants, combat units, battlefield space scenarios, communication networks, and environmental objects. Entities include combat platforms, weapon entities, decoy entities, and facility entities. Communication networks and environmental objects are connected to the battlefield space scenario, combat units are connected to combat platforms, combat platforms are connected to combatants, weapon entities, and decoy entities, weapon entities, decoy entities, and facility entities are connected to combatants, and combatants are connected to the battlefield space scenario. Detailed descriptions are shown in the table below.

[0034] 1 object SimObject An abstract class describing various elements in the battlefield space, possessing a name and unique identifier, and having a state. It is the basic unit of simulation scheduling, capable of defining and scheduling its own discrete events. It can access various simulation services provided by the simulation platform through the simulation service interface; and it can access various model services provided by the battlefield space scene through the model service interface. 2 entity SimEntity Objects with independent spatiotemporal characteristics in the battlefield space are capable of independent maneuvering; they are divided into four main categories: combat platforms, weapon entities, decoy entities, and facility entities. 3 Components SimComponent Functional objects that cannot operate independently are generally mounted on different types of entities and function as functional components of those entities. 4 combat platform SimPlatform A combat entity capable of independent maneuvering in the battlefield and exhibiting rational and autonomous combat behavior under the control of commanders and soldiers. A combat platform can carry various types of components such as sensors, communication equipment, and weapon systems, providing spatial locations for these components and enabling them to jointly simulate the various functions and behaviors of the combat platform. 5 Weapon Entity SimWeapon An entity capable of independent maneuvering and attacking a target to cause damage. The weapon is initially mounted on a combat platform, launched under the platform's command, and then detaches from the platform to maneuver independently. 6 combat unit SimUnit It is a special type of combat platform that has the functions of a platform to combine relevant components. The combat unit is mainly used to describe the command posts at various levels, to aggregate lower-level combat units or combat platforms and to command and control them. 7 combat side SimSide This refers to the parties involved in the combat, and the different combatants have different relationships, such as hostile, neutral, or allied. All combat units, combat platforms, and weapon entities are managed by the combatant. 8 Deceiving entities SimDecoy A decoy entity, launched from a combat platform, serves as a cover for a critical combat unit. It typically resides near the target unit and can maneuver independently or be towed by the launching entity. For a period, it exhibits similar maneuvering behavior and target characteristics to the target unit, confusing enemy sensors and causing enemy weapons to attack the wrong target. The decoy effect is primarily demonstrated by the decoy probability, which is determined through engagement-level simulation experiments. 9 battlefield facilities SimFacility Battlefield facilities deployed by one combatant can influence the combat behavior of both sides. These facilities can be targeted and destroyed by the enemy. They are not equipped with offensive or defensive capabilities, nor do they deliver weapons or decoys. The battlefield facilities influence the combat behavior of combat entities through environmental services. These environmental services encapsulate the effects of the natural, electromagnetic, and artificial environments on the behavior of objects in the battlefield space as global computational services, provided to the simulation model. 10 Battlefield Space Scene SimBSS It is responsible for managing and scheduling various objects belonging to different combat parties within the battlefield space, as well as global objects such as environmental objects, and providing various model services for each object model to access. Under distributed simulation conditions, the battlefield space scene only manages combat entities running on local nodes. The simulation calculations of the combat party models themselves are uniformly placed on the master computing node. On the slave computing nodes, the combat party models themselves do not perform calculations, but only schedule the entities they manage. 11 Communication Network SimComNet This is an abstract description of various communication networks for sharing information between combat entities. It is responsible for managing communication equipment nodes and their topological relationships, demonstrating channel communication capabilities, and simulating message transmission processes. The communication network is managed by the battlefield space scenario. 12 Environment Object SimEnvObject The scenario establishes environmental objects that will influence the actual combat behavior of the entities, including geographical location, combat area, and weather cloud formations. The state of the environmental objects themselves may change, such as the position and speed of cloud formations, and wind direction and weather in the combat area. Environmental objects are managed by the battlefield space scenario and provided to the simulation model through environmental services. The "object" is a common abstraction of all the remaining 11 concepts; the "entity" is a common abstraction of combat platforms, weapon entities, facility entities, and decoy entities; and the "combat unit" is a special type of combat platform. Components can be mounted on various entities and can be further subdivided into eight categories: reconnaissance and perception, platform mobility, weapon systems, information countermeasures, information processing, communication equipment, integrated support, and combat behavior. Each category is further subdivided into different component subclasses, down to the component class that can be instantiated and deployed. The top-level structure of the mission-level simulation model framework is as follows: Figure 1 As shown, the component model types are further subdivided as follows: Figure 2 As shown, the components include platform mobility, sensors, information processing, combat behavior, communication equipment, weapon systems, information warfare, and integrated support.

[0035] Combat platform model framework such as Figure 3 As shown, the combat platform includes platform mobility, sensors, seeker head, weapon systems, communication equipment, integrated support, information warfare, information processing, and combat behavior. The simulation model framework involves various modeling elements such as equipment models, combat models, model services, and simulation services.

[0036] Secondly, a component-based modeling technique is adopted for model framework design. The various equipment entities and their combat behaviors that the model framework needs to support are decomposed into components. Specifically, the various modeling elements involved in the model framework, such as equipment models, combat models, model services, and simulation services, are decomposed into components, clarifying the static interfaces and dynamic interaction mechanisms of each type of component. Based on the above model framework, the interfaces between components form a hierarchical interface system, see... Figures 4-6 .

[0037] Third, a model-driven approach is adopted for describing the model framework. The composition and interface relationships of the model framework are standardized and described using class diagrams based on the Unified Modeling Language (UML) (see...). Figures 1-6 It automatically generates framework code, simplifying the development of the model framework and maintaining its graphical representation, which facilitates ongoing maintenance and modification. Furthermore, it uses state diagrams to standardize the modal behavior of model components, unified modeling language class diagrams to describe the interaction relationships between model framework objects, and activity diagrams to graphically describe the interface behavior of model components, ensuring a one-to-one correspondence between the diagrams and the code. This achieves model-driven description of the model framework, facilitating its maintenance.

[0038] (3) Establish a parallel distributed integrated simulation architecture based on shared objects; (3-1) Determine the automatic distribution mechanism for models based on shared objects; Shared objects are a buffered, distributed object programming technique that maintains the local state of all relevant objects on each computing node. This decouples objects, allowing users to interact directly without worrying about whether the object is local or remote. State synchronization and interaction are handled in the background, greatly simplifying modeling. Furthermore, computational tasks are decomposed at the operational platform level, ensuring local interaction between components within the platform and eliminating concerns about component-level model distribution. Object state sharing primarily occurs between entities of different adversaries; interactions between entities within the same operational party are modeled using communication methods and transmission based on communication equipment and networks.

[0039] The automatic distribution mechanism for shared objects is based on three modules: the Battlefield Space Object Database, the Battlefield Space Object Manager, and the Battlefield Space Interaction Manager. The Battlefield Space Object Database (BSODatabase) manages the real-world state data of all objects within the battlefield space scenario that need to be shared among entities at the previous simulation moment (in distributed operation mode, it also includes data of objects computed remotely). The Battlefield Space Object Database serves as the complete set of the Battlefield Space Object Database for the simulation engine to query real-world information, and is also used for distributed sharing among computing nodes. The Battlefield Space Object Manager (BSOManager) acts as a bridge between the battlefield space scenario and the Battlefield Space Object Database. Its main functions include: 1) Managing lists of various local and remote objects within the battlefield space, serving as both a query interface for object state information at the previous simulation moment and a unified interface for updating the state of all objects after the current simulation is completed. 2) Acting as a coordinator for object interactions: for local object interactions, it directly calls back its interaction function interface; for remote object interactions, it immediately sends the interaction to the node where the remote object resides through the Battlefield Space Object Manager. The Battlefield Space Interaction Manager (BSIManager) is only enabled in distributed simulation mode. It supports sending interaction messages from local objects to objects located on remote nodes. The Battlefield Space Object Manager is invoked as needed and receives interactions from the distributed middleware sent to the local node, then forwards them to the object to which the interaction belongs for processing. The overall architecture of the automatic model distribution mechanism based on shared objects is as follows: Figure 7 As shown. Distributed middleware is the underlying software used when a mission-level combat simulation system runs in distributed mode, supporting interactive communication between simulation system instances distributed across multiple computing nodes.

[0040] (3-2) Determine the simulation clock synchronization mechanism under distributed operation mode; Simulation clock synchronization mechanisms among distributed computing nodes of multiple mission-level combat simulation systems, such as Figure 8 As shown in the diagram, each simulation progression has two synchronization points. The first synchronization point is a global time synchronization by the simulation engine. Simulation threads on each node begin traversing the entities on their local node to advance the clock. If interaction with objects on remote nodes is involved during this process, the interaction is immediately sent through the Battlefield Space Object Manager. Each node's callback thread receives the interactions sent to it and forwards them to the relevant objects for processing, thereby modifying the state of the local objects. The second synchronization point ensures that all nodes have completed traversal and remote interaction reception and processing, then enters the object state synchronization phase, synchronizing all local modifications in the Battlefield Space Object Manager to the Battlefield Space Object Managers of other nodes.

[0041] Clock synchronization is achieved through synchronization between battlefield space scene instances, and is handled by the battlefield space scene on the master node. When a battlefield space scene on a slave node completes its current step, it reports the completion of the current step to the master node via a remote procedure call. After collecting reports from all nodes, the master node completes synchronization, sends a unified time synchronization message to each node, and each node begins advancing its current step.

[0042] (3-3) Determine the parallel scheduling and execution algorithm for the entity-based model engine; Sharing objects effectively decouples interactions between different entities. In other words, at any given moment in the simulation, each entity's access to the state of other entities is based on a cache from the previous moment. This allows for entity-level parallel computation on the same computing node, fully utilizing the multi-core computing power of high-performance computers to accelerate simulation execution.

[0043] The model engine schedules on an entity-by-entity basis, employing a combination of fixed-base-step progression and discrete-event progression. The basic scheduling flow is as follows: Within each step, first, all communication networks are traversed for message reception; second, all environmental objects are traversed for state calculation; third, all entities are traversed. Since the calculation of all entities is based on the state of other objects at the previous moment, the causal relationships between entities are decoupled. This step can use a multi-core parallel computing mechanism to accelerate simulation execution; fourth, object state synchronization is achieved by synchronizing the object states to the battlefield space object database, and in distributed mode, synchronization with other nodes is also required; fifth, the simulation clock is advanced. Each Foreach step can be decomposed and executed in parallel on multiple cores.

[0044]

[0045]

[0046] Those skilled in the art can make various modifications and variations to this invention. If such modifications and variations are within the scope of the claims of this invention and their equivalents, then such modifications and variations are also within the protection scope of this invention.

[0047] The contents not described in detail in the specification are prior art known to those skilled in the art.

Claims

1. A mission-level combat simulation modeling method, characterized in that, Includes the following steps: (1) Determine the granularity of the mission-level simulation model under engagement-level support; (2) Establish a model-driven task-level simulation model framework; (3) Establish a parallel distributed integrated simulation architecture based on shared objects; In step (3), the method for establishing a parallel distributed integrated simulation architecture based on shared objects is as follows: (3-1) Determine the automatic distribution mechanism for models based on shared objects; (3-2) Determine the simulation clock synchronization mechanism under distributed operation mode; (3-3) Determine the parallel scheduling and execution algorithm for the entity-based model engine; In step (3-1), the implementation of the automatic distribution mechanism of shared objects is based on three modules: battlefield space object database, battlefield space object manager, and battlefield space interaction manager; the battlefield space object database is responsible for managing the real state data of all objects in the battlefield space scene that need to be shared among entities at the previous simulation moment; The battlefield space object database serves two purposes: firstly, it provides a complete set of battlefield space objects for the simulation engine to query real information; secondly, it is used for distributed sharing among various computing nodes. The Battlefield Space Object Manager serves as a bridge between the Battlefield Space Scene and the Battlefield Space Object Database. Its main functions include: 1) managing lists of various local and remote objects within the Battlefield Space, acting as both a query interface for object status information from the previous simulation moment and a unified interface for updating the status of all objects after the current simulation moment is completed; 2) acting as a coordinator for interactions between objects: for local object interactions, it directly calls back its interaction function interface; for remote object interactions, it immediately sends the interaction to the node where the remote object is located through the Battlefield Space Object Manager. The Battlefield Space Interaction Manager is only enabled in distributed simulation mode. It supports local objects sending interaction messages to objects located on remote nodes. The Battlefield Space Object Manager calls the interaction as needed and receives interactions sent to the local node from the distributed middleware. The interaction is then transferred to the object to which the interaction belongs for processing by the Battlefield Space Object Manager. In step (3-2), two synchronization points are set for each simulation advance. The first synchronization point is the global unified time synchronization of the simulation engine. The simulation thread of each node begins to traverse the entities on its own node to advance the clock. If the advancement involves interaction with objects located on remote nodes, the relevant interaction is immediately sent through the battlefield space object manager. The callback thread of each node is responsible for receiving the interaction sent to itself and handing it over to the relevant object for processing, thereby modifying the state of the local object. The second synchronization point is to ensure that each node has completed the traversal and remote interaction reception and processing, and then enters the object state synchronization stage, synchronizing all local modifications in the battlefield space object manager to the battlefield space object managers of other nodes. Clock synchronization is achieved through synchronization between battlefield space scene instances, and is handled by the battlefield space scene on the master node. When the battlefield space scene on the slave node finishes executing the current step, it reports the completion of the current step to the master node through a remote procedure call. After collecting the reports from all nodes, the master node completes synchronization and sends a unified time synchronization interaction to each node, and each node begins to advance the current step.

2. The mission-level combat simulation modeling method as described in claim 1, characterized in that: In step (1), the method for determining the granularity of the mission-level simulation model under engagement-level support is as follows: (1-1) Clarify the functional positioning of engagement level and mission level: engagement level simulation answers the question of the combat effectiveness of weapons and equipment, and provides the mission level with basic combat effectiveness data of equipment, including detection range, identification probability, deception probability, kill probability, jamming range, hit accuracy and damage radius under different conditions, expressed in the form of a decision table; mission level simulation examines the combat effectiveness of equipment system in carrying out joint combat missions, and studies and analyzes the capability shortcomings of equipment system in the face of various combat mission requirements; (1-2) Determine the model interaction framework based on the information flow of combat nodes: When the model is abstracted, the information flow between each combat node is preserved, and the internal structure and behavior of each combat node are simplified with the support of the engagement level. The information interaction between different components within the same entity and the interaction between the entity and the combat environment are carried out by direct interface calls; the information flow between different entities of the same combat party is completed through network communication. The interactions between different combatant entities are modeled into three categories: perception, damage, and interference. (1-3) Determine the spatiotemporal characteristic model granularity of various weapons and equipment based on the reference step size: clearly define the simulation reference step size of the mission level as 1 second, and abstract all activities within 1 second; for activities longer than 1 second, retain the spatiotemporal characteristics of the entity to support the establishment of combat relationships at the coordination, electronic reaction, and communication system layers; abstract and simplify the links that do not affect the establishment of relationships, such as dynamic simulation that does not affect fine granularity, flight process of unguided munitions that is not affected by communication and electronic reaction, and local support process within combat units.

3. The mission-level combat simulation modeling method as described in claim 1, characterized in that: In step (2), the method for establishing a model-driven task-level simulation model framework is as follows: (2-1) To meet the needs of various task-level simulation applications, abstract the model framework and build a task-level simulation model framework; (2-2) Decompose the various equipment entities and their combat behaviors that the model framework needs to support into components, and clarify the static interface and dynamic interaction mechanism of each component. (2-3) Based on the class diagram of the Unified Modeling Language, the composition structure of the model framework and the interface relationship of the model framework are described in a standardized manner, and the framework code is automatically generated.

4. The mission-level combat simulation modeling method as described in claim 1, characterized in that: In step (2-1), the constructed mission-level simulation model framework includes objects, which include entities, components, combat parties, combat units, battlefield space scenarios, communication networks, and environmental objects. The entities include combat platforms, weapon entities, decoy entities, and facility entities. The communication network and environmental objects are respectively connected to the battlefield space scenario. The combat units are connected to the combat platforms. The combat platforms are respectively connected to the combat parties, weapon entities, and decoy entities. The weapon entities, decoy entities, and facility entities are respectively connected to the combat parties. The combat parties are connected to the battlefield space scenario. The object is an abstract class used to describe various elements in the battlefield space. It has a name and a unique identifier, and has a state. It is the basic unit of simulation scheduling and can define and schedule its own discrete events. It can access various simulation services provided by the simulation platform through the simulation service interface. It can access various model services provided by the battlefield space scene through the model service interface; The entities are objects in the battlefield space that have independent spatiotemporal characteristics and are capable of independent maneuvering; they are divided into four categories: combat platforms, weapon entities, decoy entities, and facility entities. The components are functional objects that cannot be moved independently; they are mounted on different types of entities and function as functional components of those entities. The combat platform is a combat entity that can move independently in the battlefield space and exhibit rational and autonomous combat behavior under the control of commanders and soldiers. The combat platform can carry different types of components such as sensors, communication equipment, and weapon systems, providing spatial locations for these components and using these components to jointly simulate various functions and behaviors of the combat platform. The weapon entity is an entity capable of independent maneuvering and attacking a target entity to cause damage to the target entity; the weapon entity is initially mounted on a combat platform, launched under the command of the combat platform, and detaches from the combat platform to maneuver independently. The combat unit is used to describe the command post at each level, aggregate lower-level combat units or combat platforms, and command and control them. The combat parties represent the aspects involved in the operation, and different combat parties are in a hostile, neutral, or allied relationship; all combat units, combat platforms, and weapon entities are managed by the combat parties. The decoy entity is an entity that uses deception to cover the combat entity. It is launched from the combat platform, located around the combat entity being covered, and can move independently or be towed on the launching entity. For a period of time, it has similar maneuvering behavior and target characteristics to the combat entity being covered, creating confusion for the enemy's sensors to track and identify it, causing the enemy's weapons to attack the wrong target. The decoy effect of the decoy entity is reflected by the decoy probability, which is given by the engagement-level simulation test. The facility entity is a battlefield facility deployed by a combatant that can affect the combat behavior of both sides; the facility entity can be targeted and destroyed as a battlefield target of the enemy; the facility entity affects the combat behavior of combat entities through environmental services. The battlefield space scene is responsible for managing and scheduling various objects and environmental objects belonging to different combat parties within the battlefield space, and providing various model services for each object model to access. The communication network is an abstract description of various communication networks for sharing information between combat entities. It is responsible for managing communication equipment nodes and their topological relationships, reflecting channel communication capabilities, and simulating the message transmission process. The communication network is managed by the battlefield space scenario; The environmental objects are those established in the scenario that will affect the combat behavior of the entities, including geographical location, combat area, and weather cloud formations; the state of the environmental objects themselves may change, and the environmental objects are managed by the battlefield space scenario and provided to the simulation model through environmental services.

5. The mission-level combat simulation modeling method as described in claim 1, characterized in that: In step (2-2), based on the model framework, the interfaces between components form a hierarchical interface system.

6. The mission-level combat simulation modeling method as described in claim 1, characterized in that: In steps (2-3), state diagrams are used to standardize the modal behavior of model components, class diagrams in Unified Modeling Language are used to describe the interaction relationships between model framework objects, and activity diagrams are used to graphically describe the interface behavior of model components, which correspond one-to-one with the code, thereby realizing the model-driven description of the model framework.

7. The mission-level combat simulation modeling method as described in claim 1, characterized in that: In step (3-3), the model engine schedules on an entity-by-entity basis, using a combination of fixed baseline step size advancement and discrete event advancement. Within each step size, it first traverses all communication networks to receive messages; then it traverses all environmental objects to calculate their states; then it traverses all entities; then it synchronizes the object states to the battlefield space object database, synchronizing with other nodes in distributed mode; and finally, it advances the simulation clock.

Images