A state meta-model based naval battle mission simulation system

Abstract

This invention discloses a naval warfare mission simulation system based on a state meta-model. It includes a naval battlefield combat state module for generating combat action sequences from the acquired naval battlefield combat state; an event representation separation module for classifying combat action sequences using event representation methods to generate combat entity state sets; a combat behavior inference module for generating inference event sets based on the combat states in the current combat action sequence; a semantic web rule module for defining state evolution rules based on the combat entity state sets and inference event sets; and a naval battlefield simulation module for reading naval warfare rule files to achieve a formalized expression of naval battlefield missions. This system formalizes the commander's subjective decision-making knowledge, such as battlefield situation awareness, combat intentions, and combat states, into semantics. It combines formalization with domain knowledge to extract rule-based knowledge expressions from combat mission sequences, generalizing knowledge and optimizing data structures, which is highly beneficial for commanders to gain a deeper understanding of the naval battlefield situation.

Description

Technical Field

[0001] This invention relates to the field of simulation analysis, and in particular to a naval warfare mission simulation system based on a state meta-model. Background Technology

[0002] The demand for intelligence information processing is growing ever larger, and information processing is becoming increasingly difficult. With the rapid development of information technology and computing methods, military technology is also advancing rapidly. Various multi-sensor information systems and intelligence information systems designed for complex applications are emerging. Sensor systems, including radar, photoelectric, and acoustic sensors, collect real-time numerical information about targets. Intelligence information systems include text, video, images, and audio data. These systems provide more comprehensive situational information about the battlefield environment and combat entities. However, faced with the vast amounts of diverse data collected by various sensors, the numerical attributes of combat targets are beginning to exhibit high-dimensional characteristics. Furthermore, because sensors periodically transmit data in a time-series manner, the data collected is enormous in volume, complex in its relationships, and diverse in its structure. Faced with such massive amounts of time-series data, the demand for information processing is increasing. Therefore, the challenge facing combat command has shifted from information-scarce battlefield decision-making to how to accurately and efficiently analyze useful battlefield information from the large amounts of historical sample data accumulated by sensors to support effective decision-making.

[0003] Secondly, modern battlefield operations are characterized by complex logic and multidimensional battlefield space and operational domains. Modern battlefields are technologically intensive, with combat forces shifting from single-service operations to joint operations involving multiple services. Furthermore, weaponry is surrounded by advanced, knowledge-based, and innovative technologies, resulting in complex and ever-changing combat capabilities. For example, reconnaissance capabilities have expanded significantly; high-tech reconnaissance equipment can cover the entire battlefield. Similarly, attack capabilities have increased the range of various weapons and equipment, with artillery reaching 70 kilometers and tactical missiles reaching 2000 kilometers; aircraft have combat radii of up to 1800 kilometers. Faced with these multidimensional operational domains and complex operational logics, traditional methods of using domain experts to construct battlefield rules to assist commanders in decision-making are insufficient to meet the evolving needs of the battlefield. In other words, in the context of modern information warfare, commanders must process a dramatically increased amount of information during operations. They not only need to rapidly analyze and judge massive amounts of data but also weigh real-time information resources from various parties, quickly conduct simulations and assessments, and then issue battlefield decisions. This situation makes it even more difficult for traditional methods to cope with rapid battlefield changes. Summary of the Invention

[0004] This invention provides a naval warfare mission simulation system based on a state meta-model to overcome the aforementioned technical problems.

[0005] To achieve the above objectives, the technical solution of the present invention is as follows:

[0006] A naval warfare mission simulation system based on a state meta-model includes: a naval battlefield combat state module, an event representation separation module, a combat behavior inference module, a semantic web rule module, and a naval battlefield simulation module.

[0007] The maritime battlefield combat status module is used to summarize the combat actions based on the maritime battlefield situation and generate a sequence of combat actions for constructing a state meta-model.

[0008] The event representation separation module is used to classify the combat action sequence into combat action states, and generate a combat event state set based on the classified combat action states and the attributes corresponding to the combat action states.

[0009] The combat behavior simulation module is used to simulate the combat action sequence for the next moment based on the combat event states in the current combat event state set, and generate a simulated event state set.

[0010] The semantic web rules module is used to define state evolution rules based on the combat event state set and the simulated event state set, and to establish naval warfare rule files based on the state evolution rules;

[0011] The naval battlefield simulation module is used to read naval warfare rule files to simulate naval battlefield tasks.

[0012] Furthermore, the method for generating the combat action sequence used to construct the state meta-model is as follows:

[0013] Step S11: Divide the naval battlefield combat state into a composite combat state layer using the analytic hierarchy process (AHP), and the composite combat state layer includes several sub-combat state layers.

[0014] The sub-combat state layer includes a mission layer, a tactical layer, and an action layer;

[0015] Furthermore, the mission layer includes the tactical states of the tactical layer executed sequentially; the tactical layer includes the combat action states of the action layer executed sequentially; and the action layer includes action states that exist both sequentially and in parallel.

[0016] Step S12: Set up a combat ontology knowledge base for the composite combat state layer based on the knowledge data of the naval combat knowledge base; the combat ontology knowledge base includes a weapon platform knowledge base and a combat rules knowledge base;

[0017] Step S13: Define multiple classes and class hierarchies in the war ontology knowledge base, as well as class attributes and attribute constraints, based on the knowledge data in the naval warfare knowledge base.

[0018] The defined war ontology knowledge base includes multiple classes such as action class, event encoding class, time class, location class, state class, and participant class;

[0019] Step S14: Define combat entity classes for multiple classes in the defined war ontology knowledge base through class derivation and inheritance relationships; the combat entities include abstract entity classes, abstract platform classes, and abstract weapon platform classes;

[0020] Step S15: Define entity atomic behaviors and entity atomic states according to the combat entity class;

[0021] The entity atomic behavior is the smallest granular action completed by the combat entity, and the atomic behavior constitutes an action behavior sequence in series or in parallel on the action layer;

[0022] The entity atomic state refers to the state conditions of the combat entity itself, including the combat entity's speed, ammunition load, and duration.

[0023] Step S16: Generate a combat action sequence based on the action sequence and the state conditions of the combat entity itself.

[0024] Furthermore, the state meta-model expression is as follows:

[0025] Ei={CEi, {E1i,…….,Eii}}

[0026] In the formula: Ei represents the combat mission, CEi represents the Condition constraint for entering the combat mission Ei; {E1i, ..., Eii} represents a set of events contained under the combat mission Ei.

[0027] Furthermore, the method for generating the inference event set is as follows:

[0028] The BN inference engine unit of the combat behavior simulation module performs inference on the current combat event state from the acquired combat event state set.

[0029] The BN inference engine unit includes a pattern matcher, an agenda processor, and an execution engine processor.

[0030] The pattern matcher is used to match the combat event states in the combat event state set; and transmits the matched multiple combat event states to the agenda processor.

[0031] The agenda processor determines the priority of the naval battlefield combat rules based on the matched multiple combat event states; and transmits the multiple combat event states with determined priorities to the execution engine processor;

[0032] The execution engine processor executes the multiple combat event states in a determined priority order.

[0033] Furthermore, the semantic web rules module is used to define state evolution rules based on the combat event state set and the inferred event set, specifically as follows:

[0034] Based on semantic web technology, a semantic rule file model for the maritime battlefield is defined according to the document specification of the rule file. The document specification of the rule file includes a rule clause part, a rule set part, a rule header part, a rule attribute part, and a rule body part, and the rule body part includes the conditions and actions of the rule.

[0035] Define state evolution rules to evolve the combat action state of the combat event state set and the deduced event state of the deduced event state set;

[0036] The combat action state and the deduced event state that undergo state rule evolution are formally expressed by the triplet model to obtain the set of combat states of the naval battlefield.

[0037] The maritime battlefield semantic rule file model semantically expresses the maritime battlefield combat state set and obtains maritime battlefield mission combat rules.

[0038] The operational rules for maritime battlefield missions include operational rules for carrier-based aircraft, operational rules for surface ships, operational rules for submarines, and operational rules for formations.

[0039] Furthermore, the aforementioned surface warship combat rules include surface warship air defense combat rules, surface warship anti-submarine combat rules, and surface warship anti-ship combat rules.

[0040] Furthermore, the triplet model is

[0041] <precondition,Result,Reflection>

[0042] In the formula, precondition represents the antecedent of the state evolution rule; Result is the consequent of the state evolution rule and represents a series of combat actions to be executed after the antecedent is satisfied; reflection represents the rule mirroring, that is, the mapping relationship between the antecedent and the consequent.

[0043] Furthermore, the state evolution rule is as follows:

[0044] State evolution rules are established based on event graphs and production rules, mapping the operational action state S of the combat event state set and the deduced event state set to events in the event graph.

[0045] The operational state S is transformed into production rules based on the mapped event graph events, and state evolution rules are defined based on the production rules.

[0046] When the state evolution map f corresponds to the next event event (t+1), and the expression is:

[0047] event(t+1)=f(S(t),event(t))

[0048] Under the condition of state evolution mapping f, the corresponding production rule is:

[0049] IF event(t) THEN event(t+1)

[0050] In the formula: IF means if; event(t) means the event graph event that is currently satisfied; and event(t) is implemented by a conditional function that returns a boolean value; THEN means then; event(t+1) means setting the combat action state S(t+1) and executing the event graph event under state S(t+1).

[0051] Beneficial effects: This invention discloses a naval warfare mission simulation system based on a state meta-model. By transforming subjective decision-making knowledge such as battlefield situation cognition, combat intentions, and combat status into formal semantics that can be processed by computers, and combining formal semantics with domain knowledge, the system extracts knowledge expressions of combat mission sequences to form rules, generalizes knowledge, and optimizes data structures. This is very beneficial for commanders to gain a deeper understanding of the naval battlefield situation. Attached Figure Description

[0052] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0053] Figure 1 This is a schematic diagram of the hierarchical combat state in an embodiment of the present invention;

[0054] Figure 2 This is a schematic diagram of the state meta-model in an embodiment of the present invention;

[0055] Figure 3 This is a hierarchical structure diagram of the naval battlefield combat event ontology class in an embodiment of the present invention;

[0056] Figure 4 This is a hierarchical structure diagram of the time class of the naval battlefield combat event ontology in an embodiment of the present invention;

[0057] Figure 5 This is a class hierarchy diagram of participants in the naval battlefield combat event ontology in an embodiment of the present invention.

[0058] Figure 6 This is a class relationship diagram of the ontology model of naval battlefield combat events in an embodiment of the present invention;

[0059] Figure 7 This is a rule file model diagram of the naval battlefield combat rules in an embodiment of the present invention;

[0060] Figure 8 This is a model of an air formation interception operation mission in an embodiment of the present invention;

[0061] Figure 9 This is a schematic diagram illustrating the decomposition of combat events into action sequences in an embodiment of the present invention;

[0062] Figure 10 This is a schematic diagram of a naval warfare mission simulation system based on a state meta-model according to the present invention. Detailed Implementation

[0063] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0064] This embodiment provides a naval warfare mission simulation system based on a state meta-model, such as... Figure 10 As shown, it includes: a maritime battlefield combat status module, an event representation separation module, a combat behavior inference module, a semantic web rules module, and a maritime battlefield simulation module;

[0065] The maritime battlefield combat status module is used to summarize the combat actions based on the maritime battlefield situation and generate a sequence of combat actions for constructing a state meta-model.

[0066] The event representation separation module is used to classify the combat action sequence into combat action states and generate a set of combat event states based on the classified combat action states and the attributes corresponding to the combat action states.

[0067] The classification of combat operation states specifically involves classifying the combat operation states in the combat operation sequence according to the combat objectives and tasks, and further dividing the multiple combat operation states included in the combat operation sequence based on the corresponding combat objectives; the combat objectives and tasks include, but are not limited to, carrier-based aircraft combat missions, surface ship combat missions, submarine combat missions, and formation combat missions.

[0068] Furthermore, the aforementioned surface warship combat missions include surface warship air defense missions, surface warship anti-submarine missions, and surface warship anti-ship missions;

[0069] The combat behavior simulation module is used to simulate the combat action sequence for the next moment based on the combat event states in the current combat event state set, and generate a simulated event state set.

[0070] The semantic web rules module is used to define state evolution rules based on the combat event state set and the simulated event state set, and to establish naval warfare rule files based on the state evolution rules;

[0071] The aforementioned naval battlefield simulation module is used to read naval warfare rule files to simulate naval battlefield missions. This invention transforms subjective decision-making knowledge, such as battlefield situation awareness, operational intentions, and operational status, into formal semantics that can be processed by computers. It then combines this formal semantics with domain knowledge, extracting operational mission sequences to form rule-based knowledge representations, generalizing knowledge, and optimizing data structures. This greatly benefits commanders' in-depth understanding of the naval battlefield situation.

[0072] In a specific embodiment, the method for generating the combat action sequence for constructing the state meta-model is as follows:

[0073] Step S11: Divide the naval battlefield combat state into a composite combat state layer using the Analytic Hierarchy Process (AHP), such as... Figure 1 As shown, the composite combat state layer includes several sub-combat state layers;

[0074] The sub-combat state layer includes a mission layer, a tactical layer, and an action layer;

[0075] Furthermore, the mission layer includes the tactical states of the tactical layer executed sequentially; the tactical layer includes the combat action states of the action layer executed sequentially; and the action layer includes action states that exist both sequentially and in parallel.

[0076] Because operational decision-making is hierarchical, and operational actions differ at different levels, the operational state of entities is used to quantitatively describe the operational process. This involves expressing the operational actions at different levels using operational states at different levels. At different operational levels, operational entities execute operational tasks (interception, identification, attack, etc.) through a series of actions. When a definite event occurs, or when the current state meets a series of conditions, the operational entity transitions from one state to another. For example, if an event changes the entity's state, thus meeting the state evolution conditions, the entity executes the state evolution rules to transition to the next operational event, corresponding to a series of entity states. If no external changes or conditions occur, the operational entity can remain in a specific state. Therefore, the state of an operational entity can be understood microscopically as a structured description of the dynamic and static attributes of maritime operational units. Due to the hierarchical nature of operational tasks, a single operational task consists of multiple composite events. Subdividing these composite events hierarchically can ultimately subdivide an operational state into multiple operational event sequences, and further subdivide them into a set of action sequences, with the basic evolutionary unit being the state. For example... Figure 2 As shown, the basic structure of the state meta-model can be represented as follows:

[0077] Ei={CEi, {E1i,…….,Eii}}

[0078] Where Ei represents the combat mission, Ci represents the Condition for entering the Ei combat mission, and only when the Condition requirements are met can the combat mission be entered for matching. {Ei…En} represents a set of events contained under the Ei combat mission. This event combat sequence is further divided into a composite event sequence and its sub-event sequences, which are in an inclusion relationship. The basic structure is as follows:

[0079] Statei = {E1i, ..., Eii}

[0080] Where Statei represents state i, and {E1i, ..., Eii} represents the set of events in that state, which are displayed externally as the corresponding dynamic and static attributes of the entity;

[0081] Step S12: Set up a combat ontology knowledge base for the composite combat state layer based on the knowledge data of the naval combat knowledge base; the combat ontology knowledge base includes a weapon platform knowledge base and a combat rules knowledge base;

[0082] The weapon platform entity knowledge base stores combat unit entity information in a hierarchical structure, including equipment entities and equipment components. The equipment entity model is organized through class derivation and inheritance relationships, primarily used to define the performance parameters and characteristics of equipment entities and components, serving as the basis for parameterized configuration. It exists in the form of header files and corresponding DLL files for the corresponding equipment entities. The equipment entities and components are managed according to a set hierarchy and organizational relationship. The hierarchical structure and system classification are controlled by XML files, defining different equipment classes based on the different equipment entities and components. Furthermore, the performance parameters and characteristics of the equipment components include weapon dimensions, weight, firing method, firing preparation time, attack range, accuracy, guidance capability, survivability, penetration capability, service life, and transport and maintenance performance.

[0083] The combat rule knowledge base stores standardized combat rules for operational decision-making, assisting inference-based decision-making. The combat rule knowledge base includes a combat model library and a real-time database. The combat model library stores classic combat model templates in the operational domain to assist the inference engine in decision support. The real-time database stores dynamic and static data of real-time combat simulations or perceived combat entities. Regarding the construction of the combat model library, behavioral rules are constructed, using a hierarchical decomposition mechanism to break down and refine combat states, conditions, and events. This includes specific atomic actions required for events and the evolution of event states after conditions are met. The entity model state sets and the transition conditions between states are also analyzed. The formal description of state evolution rules provides knowledge support for the hybrid inference engine.

[0084] Step S13: Define multiple classes and class hierarchies in the war ontology knowledge base, as well as class attributes and attribute constraints, based on the knowledge data in the naval warfare knowledge base.

[0085] Based on a tree-like hierarchical model, a corresponding class hierarchy is defined from the knowledge data in the aforementioned naval warfare knowledge base, clarifying the relationships between various terms, including subclass relationships and parallel relationships. The class hierarchy definition can employ any of the following three methods: top-down, which involves first defining a top-level parent class and then progressively refining subclasses; bottom-up, which involves abstracting the parent class by defining various lower-level classes; or a hybrid approach, which involves first defining relatively obvious hierarchies and then expanding upwards and downwards.

[0086] Since defining classes alone is insufficient to describe a domain, attributes are needed. Within this domain, attribute definitions typically derive from class characteristics, such as essential class features, constituent elements, external features, and relationships between individuals. The value of an attribute refers to its value range, which can be a built-in type, such as String, Number, Enumerated, or Boolean in Protégé, or a class type. Specifically, after determining the categories and hierarchical relationships of the naval battlefield combat information ontology, the attributes of the classes need to be described. A class can have its own unique attributes, as well as relational attributes with other classes. That is, the attributes of classes in the naval battlefield combat information ontology are divided into two types: object attributes and numeric attributes.

[0087] The properties that describe the relationship between two classes are called object properties. In Protégé, object properties are defined and described using owl:ObjectPropery, rdfs:domains describes the domain of the property, and rdfs:Ranges describes the range of the property.

[0088] For the classes of the naval battlefield combat information ontology, the main attribute relationships between the classes designed in this application are: Precede, Follow, HasAction, HasState, HasPlace, HasCode, etc. The main attributes are shown in Table 1.

[0089] Table 1. Main Object Attributes of Naval Battlefield Combat Information Ontology

[0090] 1 HasPlace (the location where it happened) combat events Place 2 HasAction (the action that is owned) combat events action 3 HasState(possessing state) combat events state 4 HasCode (the identifier it possesses) combat events Event coding 5 HasTime (possesses time attributes) combat events time 6 Follow state action 7 Precede (before) state action 8 HasActor (the participant who owns the talent) combat events Participants 9 HasSponsor (the initiator that owns the service) Participants Initiator 10 HasPatient (the one who possesses) Participants bearer 11 HasDuratin (duration) time Duration 12 HasTimeZone (time zone of occurrence) time Time zone 13 HasStartPoint(starting time point) time Start time point

[0091] The data attributes describe a specific characteristic of a single class. That is, attributes can be used to describe the relationship between instances or between instances and numerical values. For example, restricting instances with specific values ​​or data formats is called a data attribute. Generally, if the instance content corresponding to a category is text, the corresponding numeric type is string; if the instance content corresponding to a category is numeric or data, the numeric type must be restricted to integer or float; if the instance content corresponding to a category is date or time, it must correspond to time. Based on the category characteristics, the data attributes corresponding to this application are shown in Table 2:

[0092] Table 2. Main Data Attributes of the Naval Battlefield Combat Information Ontology

[0093]

[0094]

[0095] To ensure the completeness of the naval battlefield event ontology model, attribute constraints need to be applied to the event ontology information. Two constraint attributes, `has` and `is a`, are defined in the naval battlefield combat event. The constraint attribute `has` is actually an extended attribute representing "ownership". For example, if `Event` is a naval battlefield combat event class, a constraint attribute `hasAtTime` needs to be defined, meaning the combat event must occur at a certain time. The constraint attribute `is a` is used to define lower-level classes; that is, if two classes have an `is a` attribute, then one class is the parent class and the other is the child class. The definition of these attributes and attribute constraints is based on existing technology and will not be elaborated further here.

[0096] like Figure 3 As shown, the defined war ontology knowledge base includes multiple classes such as action class, event encoding class, time class, location class, state class, and participant class;

[0097] The Location class includes a subclass of spatial location of naval battlefield events; for example, Location describes the spatial attributes of naval battlefield events, is a spatial description of naval battlefield events, and describes the location where naval battlefield events occur.

[0098] like Figure 4 As shown, the time class includes a subclass for the start time of an event, a subclass for the time zone of an event, and a subclass for the duration of an event. Time describes the temporal attributes of a naval battlefield event. The time class consists of three subclasses: the start time, the time zone, and the duration. The specific hierarchical structure is as follows: the start time is composed of year, month, day, hour, minute, and second; the time zone describes the time zone of the location where the naval battlefield event occurs; and the duration describes the total time the naval battlefield event lasts from start to finish.

[0099] The action class includes the sequence of actions of entities in a naval battlefield event within a certain time period; specifically, the action describes the behavior of entities in a naval battlefield event within a certain time period. The action has a certain continuity in time, and preferably, the action can also be refined into a sequence in terms of granularity.

[0100] The state class includes a current naval battlefield event subclass and other naval battlefield event subclasses associated with the current naval battlefield event subclass. A state describes the sequence of actions of an entity in a naval battlefield event at a given moment. States are instantaneous in time, primarily representing an entity's determination of whether a certain action has occurred at a specific instant. A state typically follows an action, confirming whether the desired outcome of that action was successful, and then a new action will follow this state.

[0101] like Figures 5 to 6As shown, the participant classes include subclasses for fixed-wing aircraft, ground bases, rotary-wing aircraft, underwater vessels, and surface vessels. Specifically, participants describe entities involved in naval warfare. These entities are divided into two categories: initiators of events and receivers of events. The hierarchical structure of initiators and receivers is shown in the diagram. Both participants and receivers are composed of four categories: fixed-wing aircraft, ground bases, rotary-wing aircraft, underwater vessels, and surface vessels. Fixed-wing aircraft are further divided into reconnaissance aircraft, fighter jets, unmanned reconnaissance aircraft, and aerial refueling aircraft. Rotary-wing aircraft are divided into reconnaissance helicopters and attack helicopters. Currently, underwater vessels only include the submarine category. Surface vessels are divided into six categories: patrol boats, frigates, aircraft carriers, supply ships, light cruisers, and destroyers. Ground bases are divided into ten categories: storage centers, armories, power plants, command posts, airports, weather stations, maritime radar stations, logistics warehouses, power plants, and radar stations.

[0102] The event coding class includes a numbered subclass for each maritime battlefield combat event; the event code describes the number of the maritime battlefield combat event, and is a unique number that identifies the maritime battlefield combat event. It is unique and can uniquely identify each maritime battlefield combat event.

[0103] Step S14: Define combat entity classes for multiple classes in the defined war ontology knowledge base through class derivation and inheritance relationships; the combat entities include abstract entity classes, abstract platform classes, and abstract weapon platform classes;

[0104] The state meta-model is organized through class derivation and inheritance. It defines the characteristics and performance parameters of combat entities on different platforms. Important classes include: Abstract Entity Class: the root class of all combat entities and equipment, which defines the general attributes and some management attributes of the entity; Abstract Platform Class: the common parent class of all concrete entity categories, which mainly defines the physical, motion, detectability, and detection performance parameters of the entity; and Abstract Weapon Platform Class: the common parent class of various weapon platforms, mainly used to maintain the static parameters of the relevant weapon platforms.

[0105] Step S15: Define entity atomic behaviors and entity atomic states according to the combat entity class;

[0106] The entity atomic behavior is the smallest granular action completed by the combat entity, and the atomic behavior constitutes an action behavior sequence in series or in parallel at the action layer; the atomic behavior is indivisible, and the atomic behavior constitutes an action behavior sequence in series or in parallel at the action layer, which is reflected as the tactical action state at the top.

[0107] The entity atomic state refers to the state conditions of the combat entity itself, including the combat entity's speed, ammunition load, and duration.

[0108] Step S16: Generate a combat action sequence based on the action sequence and the state conditions of the combat entity itself. The maneuvering behaviors representing the action state in the combat action sequence are the smallest granularity atomic behaviors employed. Maneuvering behaviors are indivisible, and the superposition of basic maneuvering behaviors can form corresponding tactical methods at the tactical level. Because different combat platforms have different capabilities, different types of platforms have different series of state parameters. For example, the maneuverability of surface ships differs from that of aircraft, therefore the state content differs for each type of combat platform.

[0109] In a specific embodiment, the method for generating the inference event set is as follows:

[0110] The BN inference engine unit of the combat behavior simulation module performs inference on the current combat event state from the acquired combat event state set. The BN inference engine unit includes a pattern matcher, an agenda processor, and an execution engine processor. The pattern matcher is used to match the combat event states in the combat event state set and transmits the matched combat event states to the agenda processor. The agenda processor determines the priority of the naval battlefield combat rules based on the matched combat event states and transmits the prioritized combat event states to the execution engine processor. The execution engine processor executes the multiple combat event states sequentially based on the determined priority.

[0111] The combat behavior simulation module uses time, space, events, and targets to jointly determine the evolution of the combat state; and generates a set of simulation events based on the execution of combat tasks in a time sequence; if the event of executing the combat task is a sudden event, the sudden event data is processed first and the current time drive is paused; if the execution of the event of executing the combat task will trigger a logical branch, the event state transition direction is determined according to the priority of the preset event allocation.

[0112] In a specific embodiment, the semantic web rules module is used to define state evolution rules based on the combat event state set and the simulated event set, specifically as follows:

[0113] Based on semantic web technology, a semantic rule file model for the maritime battlefield is defined according to the document specification of the rule file; such as... Figure 7 As shown, the document specification of the rule file includes a specification section, a rule set section, a rule header section, a rule attribute section, and a rule body section, and the rule body section includes the conditions and actions of the rule;

[0114] The Semantic Web is a W3C-defined standard extension to the web, defining common data formats and exchange protocols. It allows information to be shared and reused across application, company, and community boundaries. Semantic Web rules allow rules and logic to be expressed within the Semantic Web. These rules are expressed through antecedent (entity) and consequent (header) implications, meaning that if the condition defined in the antecedent is met, the condition defined in the consequent must also be met; that is, if the antecedent is satisfied, the consequent result can be true. In general, production rules are relatively simple and clear, making them supported by almost all rule engines, such as Drools, Jess, and ILOG JRule. Furthermore, it allows for the convenient representation of real-world clinical pathway rules as "IF condition THEN result".

[0115] Preferably, in practice, the instantiation of the state meta-model proceeds from top to bottom. Domain experts provide the relevant combat tasks based on the battlefield situation. Then, military experts summarize the combat actions under these tasks, generating a sequence of combat actions. Finally, based on the sequence of combat actions and event representation methods, the corresponding actions and their associated attributes are separated and combined into a combat entity state. A detailed explanation of the specific instantiation process is provided below:

[0116] like Figure 8 The image shows an air formation performing a defensive combat mission. In this mission model, "air formation defense" is a macro-level combat event within the combat mission. This combat event is composed of multiple other composite events. In this model, a combat event is subdivided into multiple composite event sequences: attacking with air-to-air missiles, returning to base, and changing azimuth and speed.

[0117] Each combat event can also be subdivided into a sequence of actions. During the execution of a combat mission, the air formation will change its position and speed multiple times. Therefore, this combat event can be broken down as follows: Figure 9 As shown, combat operations can be further decomposed into more granular atomic behaviors and states. Atomic states are described by the attributes and parameters of the combat entity itself. The maneuvering behavior that represents the action state at the action level is an atomic behavior, so the maneuvering behavior cannot be further divided and is the state element in the model. The generation of maneuvering behavior is to continuously change the current atomic state, that is, to continuously change some attribute parameters of the current entity. In this specific example, it is to change the speed and orientation of the aircraft. This is a complete combat mission decomposition process.

[0118] Define state evolution rules to evolve the combat action state of the combat event state set and the deduced event state of the deduced event state set;

[0119] The combat action state and the deduced event state that undergo state rule evolution are formally expressed by the triplet model to obtain the set of combat states of the naval battlefield.

[0120] The maritime battlefield semantic rule file model semantically expresses the maritime battlefield combat state set and obtains maritime battlefield mission combat rules.

[0121] The operational rules for maritime battlefield missions include operational rules for carrier-based aircraft, operational rules for surface ships, operational rules for submarines, and operational rules for formations.

[0122] Furthermore, the aforementioned surface warship combat rules include surface warship air defense combat rules, surface warship anti-submarine combat rules, and surface warship anti-ship combat rules.

[0123] In a specific embodiment, the triplet model is as follows:

[0124] <precondition,Result,Reflection>

[0125] In the formula, precondition represents the antecedent of the state evolution rule; Result is the consequent of the state evolution rule and represents a series of combat actions to be executed after the antecedent is satisfied; reflection represents the rule mirroring, that is, the mapping relationship between the antecedent and the consequent.

[0126] In a specific embodiment, the state evolution rule is as follows:

[0127] State evolution rules are established based on event graphs and production rules, mapping the operational action state S of the combat event state set and the deduced event state set to events in the event graph.

[0128] The operational state S is transformed into production rules based on the mapped event graph events, and state evolution rules are defined based on the production rules.

[0129] When the state evolution map f corresponds to the next event event (t+1), and the expression is:

[0130] event(t+1)=f(S(t),event(t))

[0131] Under the condition of state evolution mapping f, the corresponding production rule is:

[0132] IF event(t) THEN event(t+1)

[0133] In the formula: IF means if; event(t) means the event graph event that is currently satisfied; and event(t) is implemented by a conditional function that returns a boolean value; THEN means then; event(t+1) means setting the combat action state S(t+1) and executing the event graph event under state S(t+1).

[0134] Traditionally, rules are represented using production rules like IF condition THEN event. However, relying solely on this condition-event production rule approach has significant limitations: it cannot provide a behavioral driving mechanism for mission planning, meaning it cannot drive the mission planning of combat units through production rules, nor can it enable the transformation between different basic mission processes of combat units; it also cannot extend the behavioral reasoning process of combat units, easily leading to confusion in behavioral reasoning. Since production rules only provide the entry conditions for behavioral reasoning and the behavior to be executed when those conditions are met, without limiting the scope of application, when the same condition is used in different stages of the same tactical process, requiring different behavioral decisions based on the condition judgment, the reasoning based on production rules cannot determine which operational stage the rule applies to, causing confusion in behavioral reasoning. Therefore, a method combining event graphs and production rules is used to address this issue. Combat behavior is mapped to events in the event graph, and the concept of event graphs is used to model the state of combat behavior. In the current state, the evolution of the event state can also be considered a special action. At this point, the problem is transformed back into a problem that can be solved using production rules, thus overcoming the shortcomings of traditional production rules.

[0135] The extended knowledge of the semantic rules is as follows: The rule description methods defined by different rule engine development groups and manufacturers generally differ, mainly falling into three categories: Java-like language descriptions, Lisp and its extended languages, and XML-based languages. Java-like language descriptions: Well-known rule engines like Drools and ILOG JRules support Java script-style rules. Due to their close similarity to Java language syntax and semantics, Java-like language descriptions have the following advantages:

[0136] We can take advantage of the benefits of object-oriented and declarative programming.

[0137] Integration and interaction with Java systems are simple, data and function interactions are relatively convenient, and classes defined in the Java system can be reused.

[0138] The syntax and semantics are simple, making it easy to design, write, and read.

[0139] The execution process is relatively clear.

[0140] The drawback of using Java-like descriptions is that they cannot directly support data and function interactions when interacting and interfacing with rule engines in non-Java environments, requiring corresponding conversions.

[0141] Lisp and its extended languages: Lisp is a computer programming language with a long history, characterized by its unique bracketed Polish notation. Created in 1958, it is the second oldest widely used high-level programming language. Lisp has undergone significant changes over its long development and includes numerous variants, the most prominent being Common Lisp and Scheme. Initially created as a practical mathematical notation, Lisp was primarily influenced by Church's lambda calculus. Lisp quickly became a popular language in the field of artificial intelligence. As an older programming language, Lisp embodies many ideas from computer science, including tree data structures, automatic memory management, dynamic typing, conditional statements, high-priority functions, and recursion.

[0142] Based on the syntax and semantics of the Lisp language, expert systems or rule engines such as CLIPS, JESS, and JLisa have extended their own rule description languages.

[0143] XML-based description languages: XML is a markup language that is relatively easy for both humans and machines to understand. XML was designed with simplicity, generality, and ease of use in mind, and can easily represent data of arbitrary structure. It is widely used in Web services and the Internet. Rule ML (Rule Markup Language) is an XML-based markup language that can be used to express both forward (bottom-up) and backward (top-down) reasoning rules. Designed by the Rule Markup Initiative, it serves as an XML-based Web language for representing rules. It is an authoritative open language used by individuals, companies, and academic groups, and can be used as an exchange standard in rule engine systems.

[0144] SWRL (Semantic Web Rule Language), a subset of Rule ML, combined with Web Ontology Language (OWL), is used to express rules and logic in the Web semantic network. All rules are described using OWL. By combining Horn logic and OWL, SWRL provides powerful reasoning capabilities.

[0145] There has never been a unified approach to describing rules using rule languages. Different rule engines define rule files differently. Generally speaking, rule languages ​​can be divided into two main categories: structured and makeup-based. A standard rule file typically consists of the following parts:

[0146] package: Defines the package name of the rules file. This package name only distinguishes files logically and does not represent the actual physical path of the file, but functions and variables defined under the same package name can be called directly.

[0147] import: declares the class name to be imported. It can import not only externally defined variables, but also some public static methods.

[0148] `global`: Sets global variables within a rule. Commonly used for providing services and returning data. Unlike `fact`, the engine is unaware of whether global variables have changed. Therefore, `global` variables must be set before inserting `fact`.

[0149] Function: Defines the functions within the rules, encapsulating the business operations within the rules. Generally, functions in a rule engine should be concise and easy to understand, and not overly complex. Otherwise, it will undoubtedly increase the difficulty of code maintainability. Complex code processing should be handled by Java classes. If the rule engine needs to call complex code logic, it only needs to pass the encapsulated Java class as a global variable to the rule engine.

[0150] `query` is a method provided by Drools to search for facts in the current working memory based on certain conditions.

[0151] rule: Defines a rule. A rule consists of three parts: attribute part, condition part, and result part. A rule begins with "rule" and ends with "end".

[0152] Generally speaking, the structure of a rule is as follows:

[0153] rule "name"

[0154] attributes

[0155] when

[0156] LHS

[0157] then

[0158] RHS

[0159] End

[0160] rule: Specifies the name of the rule, which must exist. The name should be unique and can be executed multiple times.

[0161] The attributes section contains 13 attributes, which can be declared individually to control rule execution. For example, `salience` sets the rule's priority; a higher value indicates higher priority. The default value is 0. The `no-loop` attribute prevents already executed rules from being re-activated when the `fact` object is modified.

[0162] The conditional part, abbreviated as LHS (Left Hand Side), defines the conditions for the current rule and lies between `when` and `then`. An LHS can contain zero or more conditions. If no conditions are specified, it defaults to `eval(true)`, meaning it always returns true.

[0163] The Result Section (RHS) is located between `then` and `end` and handles the business logic following the fulfillment of conditions. You can directly write Java code or use variable names defined in the condition section.

[0164] end: Indicates the end of the rule and must exist.

[0165] This invention expresses the semantic war dynamics model implied by the commander's decision-making knowledge in a formalized and data-driven form, abstracts a maritime combat state meta-model, and the command information system designed using the maritime combat state meta-model can effectively adapt to the following four aspects:

[0166] First, regarding mission changes. If the battlefield situation changes and commanders issue new operational orders, the operational mission of the command information system will change, affecting the sequence of operational mission execution and ultimately requiring modifications to the entire operational plan.

[0167] Second, regarding changes in the status of combat units. The status of a combat unit includes external status and internal status. External status refers to changes in the battlefield environment in which the combat unit is located, while internal status refers to changes in the status of the combat unit itself, such as changes in the amount of resources it carries or damage to its communication modules.

[0168] Third, in terms of multi-service coordination. In a networked battlefield environment, multiple services need to coordinate their operations to complete combat missions. Therefore, when formulating operational plans, the command information system needs to assign responsibility for tasks to specific operational units and clarify the cooperation methods between operational units.

[0169] Fourth, in terms of functional service orientation. The functions of combat units are service-oriented, enabling the command information system to locate the task execution unit to a specific functional service of the combat unit when making decisions. Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit it; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A naval warfare mission simulation system based on a state meta-model, characterized in that, include: The modules include: naval battlefield combat status module, event representation separation module, combat behavior simulation module, semantic web rules module, and naval battlefield simulation module. The maritime battlefield combat status module is used to summarize the combat actions based on the maritime battlefield situation and generate a sequence of combat actions for constructing a state meta-model. The method for generating the combat action sequence used to construct the state meta-model is as follows: Step S11: Divide the naval battlefield combat state into a composite combat state layer using the analytic hierarchy process (AHP), and the composite combat state layer includes several sub-combat state layers. The sub-combat state layer includes a mission layer, a tactical layer, and an action layer; Furthermore, the mission layer includes the tactical states of the tactical layer executed sequentially; the tactical layer includes the combat action states of the action layer executed sequentially; and the action layer includes action states that exist both sequentially and in parallel. Step S12: Set up a combat ontology knowledge base for the composite combat state layer based on the knowledge data of the naval combat knowledge base; the combat ontology knowledge base includes a weapon platform knowledge base and a combat rules knowledge base; Step S13: Define multiple classes and class hierarchies in the war ontology knowledge base, as well as class attributes and attribute constraints, based on the knowledge data in the naval warfare knowledge base. The defined war ontology knowledge base includes multiple classes such as action class, event encoding class, time class, location class, state class, and participant class; Step S14: Define combat entity classes for multiple classes in the defined war ontology knowledge base through class derivation and inheritance relationships; the combat entities include abstract entity classes, abstract platform classes, and abstract weapon platform classes; Step S15: Define entity atomic behaviors and entity atomic states according to the combat entity class; The entity atomic behavior is the smallest granular action completed by the combat entity, and the atomic behavior constitutes an action behavior sequence in series or in parallel on the action layer; The entity atomic state refers to the state conditions of the combat entity itself, including the combat entity's speed, ammunition load, and duration. Step S16: Generate a combat action sequence based on the action sequence and the state conditions of the combat entity itself; The event representation separation module is used to classify the combat action sequence into combat action states, and generate a combat event state set based on the classified combat action states and the attributes corresponding to the combat action states. The combat behavior simulation module is used to simulate the combat action sequence for the next moment based on the combat event states in the current combat event state set, and generate a simulated event state set. The semantic web rules module is used to define state evolution rules based on the combat event state set and the simulated event state set, and to establish naval warfare rule files based on the state evolution rules; The naval battlefield simulation module is used to read naval warfare rule files to simulate naval battlefield tasks.

2. The naval combat mission simulation system based on a state meta-model according to claim 1, characterized in that, The state meta-model expression is as follows: Ei={CEi, {E1i,…….,Eii}} In the formula: Ei represents the combat mission, CEi represents the Condition constraint for entering the combat mission Ei; {E1i, ..., Eii} represents a set of events contained under the combat mission Ei.

3. The naval combat mission simulation system based on a state meta-model according to claim 1, characterized in that, The method for generating the inference event state set is as follows: The BN inference engine unit of the combat behavior simulation module performs inference on the current combat event state from the acquired combat event state set. The BN inference engine unit includes a pattern matcher, an agenda processor, and an execution engine processor. The pattern matcher is used to match the combat event states in the combat event state set; and transmits the matched multiple combat event states to the agenda processor. The agenda processor determines the priority of naval battlefield combat rules based on the matched multiple combat event states. And transmit the status of multiple combat events with determined priorities to the execution engine processor; The execution engine processor executes the multiple combat event states in a determined priority order.

4. A naval combat mission simulation system based on a state meta-model according to claim 1, characterized in that, The semantic web rules module is used to define state evolution rules based on the combat event state set and the simulated event state set, specifically: Based on semantic web technology, a semantic rule file model for the maritime battlefield is defined according to the document specification of the rule file. The document specification of the rule file includes a rule clause part, a rule set part, a rule header part, a rule attribute part, and a rule body part, and the rule body part includes the conditions and actions of the rule. Define state evolution rules to evolve the combat action state of the combat event state set and the deduced event state of the deduced event state set; Furthermore, the operational action state and the inferred event state that undergo state rule evolution are formally expressed through the triplet model to obtain the set of operational states in the naval battlefield. The maritime battlefield semantic rule file model semantically expresses the maritime battlefield combat state set and obtains maritime battlefield mission combat rules. The operational rules for maritime battlefield missions include operational rules for carrier-based aircraft, operational rules for surface ships, operational rules for submarines, and operational rules for formations. Furthermore, the aforementioned surface warship combat rules include surface warship air defense combat rules, surface warship anti-submarine combat rules, and surface warship anti-ship combat rules.

5. A naval combat mission simulation system based on a state meta-model according to claim 4, characterized in that, The triplet model is <precondition, Result, Reflection> In the formula, precondition represents the antecedent of the state evolution rule; Result is the consequent of the state evolution rule and represents a series of combat actions to be executed after the antecedent is satisfied; reflection represents the rule mirroring, that is, the mapping relationship between the antecedent and the consequent.

6. A naval combat mission simulation system based on a state meta-model according to claim 4, characterized in that, The state evolution rule is as follows: State evolution rules are established based on event graphs and production rules, and the combat action state S of the combat event state set and the deduced event state set is mapped to the event of the event graph. The operational state S is transformed into production rules based on the mapped event graph events, and state evolution rules are defined based on the production rules. When the state evolution map f corresponds to the next event event (t+1), and the expression is: event(t+1) = f (S(t),event(t)) Under the condition of state evolution mapping f, the corresponding production rule is: IF event(t) THEN event(t+1) In the formula: IF means if; event(t) means the event graph event that is currently satisfied; and event(t) is implemented by a conditional function that returns a boolean value; THEN means then; event(t+1) means setting the combat action state S(t+1) and executing the event graph event under state S(t+1).

Images