Operational Rule Extraction and Construction Based on Task Scenario Analysis

Abstract

Changes in the information age have induced the necessity for a more efficient and effective self-decision-making requirement. A method of extracting and constructing naval operations decision-making rules based on scenario analysis is proposed. The template specifications of Event Condition Action (ECA) rules are defined, and a consistency detection method of ECA rules based on SWRL is proposed. The logical relationships and state transitions of the naval operational process is analyzed in detail, and the association of objects, events, and behaviors is realized. Finally, the operation of the proposed methods is illustrated through an example process, showing the method can effectively solve the problems of self-decision-making rule extraction and construction among naval battlefield decision environment, and avoid relying on artificial intelligence, which may have brought some uncertain factors.

1. Introduction

The intelligent self-decision-making of naval operations is of great significance to the research of auxiliary decision-making for naval operations. Under the conditions of information-based joint operations, the naval battlefield situation is changing rapidly, from early warning and detection, command and control, information transmission to the implementation of confrontation, and the pace of confrontation is accelerating. In view of the characteristics of high requirements for decision timeliness in operational planning, how to effectively alleviate the time faced by operational decision generation and dynamic pressure has become a technical difficulty that the operational command system urgently needs to solve. In the aspect of decision making, rule-based decision-making methods were generally utilized in earlier research on operational support. Among them, the most typical rule-based decision-making method is finite state machine (Finite State Machine, FSM). Rule-based methods were widely applied in solving decision-making problems because of the clear logic and strong interpretability. Besides, rule-based decision-making methods rarely have the ability to deal with unseen scenarios [1].

Intelligent autonomous decision-making is mainly through mathematical optimization, artificial intelligence and other methods to build a mapping from naval operational situation to operational commands. According to the different ideas of solving the mapping, there are mainly: influence diagram [2,3,4], genetic algorithm [5,6], fuzzy logic [7,8], neural network [9] and other methods. In response to different scenarios, these methods have been used to solve the problem of autonomous decision-making, and many results have been achieved [10,11,12]. However, these methods are still plagued by problems such as “dimensionality disaster”, “human subjective influence”, and “rule loopholes”. When fighters face unpredictable complex conditions, the uncertainty of decision-making increases. A large number of decision-making reasoning rules need to be extracted from data and processes with certain mutually independent attributes. Each scene of the naval surface vessel represents a series of scenarios constructed by the environment, objectives and naval surface vessel activities. The construction of the scene is the process of plot design based on the existing materials and domain knowledge based on the operational mission. For this reason, on the basis of mission scenario analysis, a method of extracting decision rules for naval surface vessel based on scenario analysis is proposed [13,14].

There are two things that must be discussed before analyzing the operational planning rules. The first is the extraction of domain terms in the operational planning field. The precise extraction of terms in the domain can assist analysts in understanding and analyzing operational planning sentences more accurately; on the other hand, it is the work of synonym extraction between terms. Synonym extraction can identify different descriptions of the same entity. Term extraction is a basic and important research direction in the field of text processing, which can be applied to many fields such as ontology construction, machine translation, semantic retrieval, and planning sentence engineering. However, terminology extraction is a complex and difficult task, and requires certain linguistic knowledge and a related field background. In this method, the data to be processed comes from a operational planning document with a strong domain. The planning sentences for word segmentation are different from the commonly used word segmentation database, and it is necessary to manually establish a term database to assist word segmentation. Therefore, it is of great significance to develop a set of automatic, efficient and highly portable term extraction and construction methods.

The research on automatic extraction of domain terminology has lasted for more than 20 years. In the 1990s, there were a number of terminology extraction systems abroad. Domestic research is concentrated in the past 10 years. The research on automatic extraction of Chinese terms also has its own particularities. The English corpus has natural advantages over the Chinese corpus. English words are separated by spaces, while in the Chinese corpus, there is no separator between words. Therefore, in the process of automatic extraction of Chinese terms, the corpus first needs to be segmented. However, it is difficult to carry out relevant research when the effect of early word segmentation is not very satisfactory. At present, the most commonly used word segmentation tools are CoreNLP [15], Jieba [16] and HanLP [17] of Stanford University, and support part-of-speech tagging. In the early work of automatic extraction of domain terms, most of them were based on linguistic knowledge. Later, with the rapid development of statistical natural language processing technology, one or more statistical strategies were gradually introduced into the term extraction system. With the use of machine learning algorithms such as Hidden Markov Model (HIMM) [18] and Conditional Random Field (CRF) [19] in the areas of part-of-speech tagging and named entity recognition, the method of combining machine learning algorithms also introduced into terminology extraction research.

Rule-based method mainly uses linguistic knowledge such as the word part of speech and morphological pattern of the term, which can be used to automatically extract terms from the corpus. Foreign research on automatic term extraction based on linguistic knowledge is mainly concentrated in the 1990s. The FASTER system developed by Jacquemin in 1994 first summarized the term composition rules from the known terminology database, and combined with 73 extended operating rules to extract terms from the corpus of the field of grammar medicine. The final accuracy rate was 86.7%, and the recall rate was 86.7%. 74.9%. The NODALIDA-95 launched by Linsoft in 1995 uses a structured method to organize language knowledge, with NPtool [20] as the core. It first judges the boundary of the sentence, the idioms and compound forms in the sentence, and then disambiguates it through part-of-speech analysis.

Based on statistical theory, the statistical-based method uses the statistical attributes of the distribution of terms in the corpus to identify terms. Frequently used statistical methods can be divided into two categories: one category measures the domain of words or phrases, such as word frequency (Frequency) [21,22], IF-IDF [23] value, domain relevance and domain consensus [24], etc.; another type of measurement of the unit of phrases, such as mutual information [25], Log-Likchood Ratio [26], etc. The ECA rule has a sound theoretical basis. Once a set of ECA rules required for process execution is prepared, we can take advantage of the theoretical basis. However, it is not easy to automate extracting and constructing the operational rules, thus, it is very difficult for users to manage and utilize the rules.

In this paper, aiming at the complexity of decision-making issues such as coordinated operations of naval formations or integrated defenses of the ship, combined with ECA rules, a method for extracting and constructing naval operational decision-making rules based on scenario analysis is proposed.

2. ECA Rules

An ECA model is originally used in active database systems. If an event occurs and a condition turns out to be true, then the active database executes a corresponding action. The event is a change of database contents, the condition is associated with a database query to check it, and the action corresponds to a set of statements that may trigger other changes in the database. All these are carried out automatically without any intervention from users or external applications [27].

2.1. Rule Design Principles and Requirements

There are three interpretations of the rules in “The Chinese Word Dictionary”: one is standard; the other is neat and in a certain way; and the third is a written document formulated on one or some matters. Therefore, when designing the rules of marine surface vessel operations, it should also meet the requirements of its format specification, clear purpose, flexibility and compatibility:

(1)

The state should be consistent before and after the rule is applied. When compiling the operational rules of the naval surface vessel, if there is any adjustment to the actions of the surface vessels, the status of the force should be saved in advance before the implementation of the rules. And after the implementation of the rules, it will resume the previously interrupted mission from the original status;

(2)

The format and parameters of the command action must be clear. Different from military theory, all combat instructions that require staff officers to understand and execute in actual combat must be transformed into one or more simple actions in the operational rules. Although the rules themselves can be flexible and diverse, these actions must have a limited number, clear format, and unique parameters;

(3)

The triggering conditions of the rules must be set reasonably. Naval surface vessel operations are no longer a linear structure formed by a series of operations such as crossing, search, tracking, or attack, but a network structure composed of multiple forces and multiple combat operations. The design rule trigger conditions should start from the change of the surface vessel status and find the perfect and unique representation method as possible;

(4)

The structure of the rules must be discrete and concise. The naval surface vessel operational rules are not only applied to the command-and-control system, but also applicable to the operational simulation system. Therefore, the operational rules are bound to the execution object through the dynamic parameters input by the data interface after the simulation system is running, and there is no mutual interaction between the rules;

(5)

The proper optimization and perfection of the set of operational rules must be adhered to. According to the development of military needs and the improvement of experimental experience, various rules will also be continuously expanded and improved. However, when adding simulation rules, correcting inappropriate rules, and merging duplicate or similar rules, the downward compatibility of the rule set should also be fully considered.

2.2. Event

Events in ECA rules can trigger a rule. In different applications, the classification of events is different. In order to achieve standardization, on the basis of analyzing the possible situations of general events, events are defined as two categories: (1) External events introduced from outside, or caused by external devices, entities, etc. (2) Time events that are timed or not. It is important to note that events can also be constructed by another rule.

2.3. Condition Template

In ECA rules, conditions are the states that must be met to trigger a rule. The expression of the condition can be simple true or false; it can also be the limited part of the condition clause in the database query language. These two condition expressions are called relationship conditions, and the template specification is defined as follows:

Definition 1.

Condition::=<Relation Condition>[AND<Relation Condition>]. Relation Condition::=<Expression><Relation Operator><Expression>. Expression::=<Variable>i<Attribute Value>. Relation Operator::=”=”|”≠”|”>|”<”.

In most scenarios, the conditions will not be simple “true” and “false”, which requires analysis of the specific situation to find out the judgment conditions for the execution of the action.

2.4. Action Template Specification

Actions in ECA rules are actions triggered when the event that triggers the rule occurs and the conditions are met. Sometimes it confuses the concept of actions. It should be emphasized here that actions are for the system and not executed by external entities. Here, the action is defined as a method call, and its template specification is defined as follows [28]:

Definition 2.

Method Calls::=<Method Names>([Parameter]).

Substitute a generated parameter into the template to execute the corresponding action. In practical applications, it is hoped to exchange information with sensors, mobile interrupts and other devices or external information sources through existing ECA rules. At the same time, the actual system needs to execute and control the generated ECA rules. Therefore, all events and conditions are the results of the feedback on external devices such as sensors or external information sources, and the action is implemented by the developer. When generating ECA rules, it is necessary to find the encapsulated events, conditions and actions in advance to meet the standardization of ECA rules.

3. Task Scenario

Task scenario analysis is to decompose the tactical task execution scenario into multiple combinable atomic tasks based on combat tasks, domain knowledge, and materials, and determine the logical structure between these atomic tasks. Among them, the experience formed in actual combat and training, the handling plan for emergencies, and the data of operational simulation can all be used as the material for scenario construction and analysis; domain knowledge is the facts and rules that military experts have been able to explain clearly and refine into rules. Rules, etc., are the basic constraints of scene construction and analysis. The parent–child relationship between tasks is formed through the decomposition mapping of high-level tasks and atomic tasks, which can be described by the task hierarchy diagram shown in Figure 1. Each complex task corresponds to a scene, and the atomic task describes more specific action details, so the execution of the atomic task is regarded as an atomic scene constructed by the scene. The composability of subtasks indicates whether a group of subtasks can be combined into a more complex task. Only subtasks that belong to the same parent task can be combined. For example, in Figure 1, the actions {AtomTask4, AtomTask5, AtomTask6} are combinable, and {AtomTask1, AtomTask5} are not combinable.

A complex task can be expressed as:

Task = {TaskGroup, TaskStucture, TaskDependency}

where: TaskGroup = {SubTask1,..., SubTaskn} represents the sub-task group obtained by task decomposition; TaskStucture represents the execution structure between sub-tasks; and TaskDependency∈{&,|} represents the dependency of the parent task on the sub-task.

The execution structure of the task group is mainly aimed at the execution relationship between the subtasks decomposed by the same parent task. Its basic structure mainly includes four types: sequence structure, concurrent structure, selection structure, and loop structure. Input and Output, respectively, represent the input and output of the task. Output, Cpre and Cpost, respectively, represent the pre-condition and post-condition of task execution. Among them, the sequence structure means that the execution of the next subtask can only be started after the execution of the previous subtask is completed. The selection structure means that the execution process of the subtasks is mutually exclusive, that is, there is one and only one subtask to be executed. Therefore, the preconditions of any two atomic tasks cannot be exactly the same, and they must be mutually exclusive. Concurrent structure refers to a group of atomic tasks that need to be executed at the same time. Therefore, the preconditions for the subtask group are exactly the same. The cyclic structure refers to a group of subtasks that need to be executed cyclically, and the order of execution of the subtasks in the cycle is fixed. In the process of task decomposition and scene design refinement, in order to further describe the dependency relationship between parent and child tasks, the relational operators ‘&’ and ‘|’ are introduced. The relational operator ’&’ connects the parent task to all subtasks, and the completion of the parent task depends on the execution of all subtasks. The relational operator ’|’ means that the realization of the parent task only needs to be satisfied by any subtask.

4. ECA Rule Extraction Process for Decision-Making Scenarios of Marine Formations

Different plans need to be conceived according to the occurrence of the scene, and different actions and the results of the actions must be evaluated according to these plans. According to the goals to be completed and the actual situation that may occur, list all the plans in the scene, and draw the processing process according to the execution steps of the plan. A task scene is composed of multiple atomic scenes, and each atomic scene implements a specific atomic task through the execution of the behavior of task participants. By traversing the sub-task groups and atomic tasks of each level of the task, a complete task scene can be constructed to fully reflect the details of task execution. According to the composability of atomic tasks, the process of extracting decision-making rules for naval formations only needs to decompose complex tasks hierarchically into a series of atomic tasks, conceive the execution scenarios of atomic tasks with reference to existing materials and domain knowledge, analyze the events that may be generated by the system, evaluate the execution conditions and possible results of different behaviors, and finally realize the system’s event, condition, and behavior association mapping.

Therefore, the steps for extracting and constructing naval operational decision-making rules based on task scenario analysis are as follows:

Step 1: Task analysis. According to the operational tasks to be completed by the naval surface vessel system, combined with the scene design materials and domain knowledge constraints, the task is decomposed and classified, all possible situations are listed, complex tasks are decomposed into atomic tasks, and the execution sequence structure between these atomic tasks is determined by dependency relationships.

Step 2: Situation analysis. According to the actual situation that may occur, list the possible states of the system during the execution of each atomic task and the actions that may be executed in each state. The execution of each action will bring the system to a new specific state, as shown in Figure 2.

Step 3: Trigger event analysis. Comprehensive task analysis and scene analysis extract the corresponding events and trigger conditions. An event refers to a time-space state change or attribute change of a certain military significance that occurs in the system, target, and environment under certain conditions. The triggering event is the “switch” that activates the corresponding rules. The processing process of the integrated scenario analysis diagram and scenario plan is described as follows:

(a)

The state in the scene analysis diagram is transformed into an event (represented by a rectangle) or a condition (represented by a diamond) of the ECA rules, which needs to be artificially distinguished according to the actual situation.

(b)

Transform the conditions in the process into the conditions of the ECA rules.

(c)

The actions that should be performed in the scene analysis graph are transformed into the actions of the ECA rules (represented by hexagons).

Step 4: State transition condition analysis. The event in the rule is actually a change of the situation, and the condition is a purposeful judgment on the past, present, and future scenarios to determine whether the action in the rule is executed. The “purpose” here includes the current state in the scenario analysis, the state to be achieved, and the constraints provided by domain knowledge. The conditions of judgment can be either the quantified values of the systems, goals, and environmental attributes that make up the scenario, or the qualitative complex relationships of events.

Step 5: Rule expression. According to the grammatical structure of the defined ECA rules, the corresponding rules can be obtained by substituting the trigger events, conditions, and actions obtained in each state into the grammatical structure of the rules. The essence of rule extraction is to express the state transition process in the form of rules, as shown in Figure 3. Illustrated as follows: S₁ is the initial state of Scenario₁, and A₁ occurs the Scenario₁ to S₂, which means the S₁ transfer to S₂ by A₁.

According to the conditions in the action template specification, the action template specification, and the grammatical structure of the ECA rules, the process information obtained is finally mapped to the corresponding rules.

5. Consistency Detection of ECA Rules

5.1. Condition Template

In actual applications, in order to avoid redundancy of rules and ensure the accuracy of rule execution, it is necessary to check the consistency of the extracted ECA rules to obtain a complete ECA rule.

Regulation 1.

Given action a and action b, exclusive (a, b) means that action a and action b are mutually exclusive, that is, action a and action b cannot occur at the same time.

Exclusive (a, b) means that action a is compatible with action b, that is, action a and action b can occur at the same time without affecting each other.

Regulation 2.

For event (or condition) c and event d, preceding (c, d) indicates that event c is the predecessor of event d, that is, the occurrence of event c will lead to the occurrence of event d.

Consistency check: Let E, C and A correspond to the set of events, conditions and actions, respectively, Rule 1:{On e₁ If c₁ Do a₁}, Rule 2:{On e₂ If c₂ Do a₂}, and ∃e₁,e₂∈E, ∃c₁,c₂∈C, ∃a₁,a₂∈A.

Conclusion 1. If e₁ = e₂, c₁⊂c₂, and a₁ = a₂, it is easy to get that either Rule1 or Rule2 is inaccurate. Then, if the occurrence of c₁ can fully trigger the action, it means that c₂ is redundant, and it can be further concluded that Rule2 is redundant. On the contrary, if c₂ is necessary, then c1 cannot be used as a condition to trigger an action. At this time, Rule1 is wrong.

Conclusion 2: When satisfied:

(1)

preceding (e₁, e₂) (or e₁ = e₂), c₁ = c₂.

(2)

preceding (c₁, e₂) (or c₁ = e₂), and the condition c₂ is established.

It can be seen that Rule 1 will be triggered at the same time Rule 2 will be triggered. If exclusive (a₁, a₂), then at least one of the rules Rule 1 and Rule 2 is wrong; if exclusive (a₁, a₂) (or a₁ = a₂), then Rule 1 and Rule 2 are compatible with each other. At this time, you need Integrate rules Rule 1 and Rule 2.

5.2. Consistency Detection of ECA Rules Based on SWRL

After extracting and constructing naval operational decision-making rules based on mission scenario analysis, it needs to be verified to ensure the consistency between the conceptual domains of the operational decision-making rule set and the elements within the conceptual domain due to complexity. SWRL is a language that uses semantic forms to present rules. The concept of its rule part is derived from RuleML and combined with OWL ontology to finally get this language. Use SWRL (Semantic Web Rule Language, Semantic Web Rule Language) rules to verify the operational decision-making rule set for a certain mission scenario. It is necessary to ensure the correctness of combat operations and the consistency of combat operations with other conceptual domains.

First of all, according to the services provided and the actual situation that may occur, the scenario plans of all services should be listed, and the logical model of each service should be described by ECA rules, and the ECA rules should be stored in the rule library; at the same time, in accordance with the provided services and ECA, the actions performed in the rules use certain ontology modeling tools such as protégé to define the contents of the top-level ontology, domain ontology, task ontology, and application ontology, and analyze and describe the classes and attributes of the ontology based on actual needs. Then, check the key factor action (Action), respectively, check the relationship between combat actions and actions, combat actions and resources (Resource), combat actions and combat strength (Strength), combat actions and combat objectives (Objection), Through the time (Time) description and space (Space) description to express the time and space description of each factor, and the time and space relationship between the factors, and to achieve the verification of the time and space relationship.

⮚

Combat operations–actions mainly check the dependence and constraints of actions. The current action can only be carried out when its prerequisite actions are completed. The action–action check mainly realizes the pre-set check of each action in the joint combat plan. Whether the time of action is consistent with the sequence of actions.

⮚

Combat operations–resources check whether the resource allocation in the plan meets the resource type and quantity required by the current action. First, check the resource type’s constraints on the action, and then check the usable time of the reused resource and the resource of the consumable resource. Whether the quantity meets the needs of the action.

⮚

Between combat action and force, it mainly realizes the verification of the constraints of the type and quantity of combat force on the action, which is similar to the verification of combat action-resources. First, verify whether the type of force meets the action, and then verify the satisfaction of the number of troops.

⮚

The content of the verification between combat operations and targets is that combat operations must include more than one target and combat targets must be executed by more than one action.

Conflicts exist in any service system. There are many types of conflicts between services, and their manifestations are also different. The possible conflicts caused by the occurrence of two services include: purpose conflict, effect conflict, resource conflict, and redundant service; the time period of occurrence may be inclusive, overlapping, or sequential. In terms of performance, conflicts may appear in one system state (for example, when two conflicting services occur when the time period intersects), they may also appear in the comparison of several states, or when the results differ from expectations. Generally speaking, conflicts between rules mainly refer to that in certain states, multiple rules in a rule set may be triggered at the same time. If there are conflicts between multiple actions triggered by these rules, these rules conflict with each other. The action in the rule corresponds to a behavior in the service, and the action conflict refers to the resource conflict (used by the service) and effect conflict (affecting the service) in the service behavior. Therefore, in the conflict of operational rules, conflict detection refers to judging conflicting service behaviors and then detecting conflicting rules.

SWRL is a language that uses semantic forms to present rules. The concept of its rule part is derived from RuleML and combined with OWL ontology to finally get this language. In RuleML, the result of reasoning is represented by hand, and the basic form of the reasoning premise will be retained in SWRL and represented by body. Therefore, SWRL can be regarded as a combination of rules and ontology. Through the combination of the two, the relations and vocabulary described in the ontology can be directly used when writing the rules, because in SWRL, the relations between these categories no longer need other methods and rule descriptions, and the ontology can be directly used. To describe. The main idea of SWRL is to expand the OWL interpretation, and it can map variables to the domain. Only when the antecedent and subsequent parts of this mapping are met at the same time, a rule is established. According to the way the SWRL expresses the rules, the following grammatical format is defined:

Definition 3.

Predicatel (?Variablel)^Predicate2 (?Variable,?Variable3)→Predicate3 (?Variable4,?Variable5).

Among them, the implication is represented by the arrow symbol “→”, which logically associates the premise and the conclusion, that is, the premise before the arrow and the conclusion after the arrow; the predicate uses “∧” for conjunctive connection; variables start with a question mark (?).

There are two aspects to service conflict discovery and detection. On the one hand, it is the discovery and detection of conflicting service behaviors, which are mainly resolved through semantic analysis, such as the context-aware conflict framework, which uses the method of constructing contextual conflict management middleware to detect and resolve conflicts. On the other hand, it is to discover conflicting service logic. Most of these methods assume that the service is known, and predefine conflicting service behaviors. On this basis, discover the service logic that will cause conflicts, such as that based on conflicts. The time for detection and resolution, the conflicts in the pervasive computing environment are divided into static conflicts and dynamic conflicts, and a method of adding post-conditions to ECA to detect conflicts is proposed.

According to the above prerequisites, this project uses SWRL to construct meta-rules for resource consumption and resource state transition. The required predicates are as

Table 1. List of air and sea coordinated assaults on the sea.

Event Name	Remark
Rule (?r)	r is a rule
FamilyService (?fs)	fs is a subclass of the FamilyService class
Property (?p)	p is an object attribute (operation on resources)
Resource (?res)	res is a subclass of Resource
hasService (?r, ?Is)	Rule r has service fs
hasProperty (?fs, ?p)	Service fs has object attribute p
hasConstraint (?p, ?res)	Object attribute p has attribute constraints res
resConsumption (?fs, ?res)	Service fs consumes resources res
Changestate (?res, ?s)	The status of resource res becomes s

.

(Firstly, construct meta-rules for resource consumption.If the execution of the service in the rule needs to consume a certain resource, it can be transformed into the following meta-rule:

metaR-1:

Rule (?r)∧FamilyService (?fs)^hasService (?r, ?fs)^Property (?p)^hasProperty (?fs, ?p)^Resource (?res)^hasResource (?p, ?res)→resConsumption(?fs, ?res)

Afterwards, construct meta-rules for resource state transition.Suppose the resource has three states: on, off, and occupied, that is, the values of the variable s in the above table changeState (?res, ?s) are on, off, and busy, respectively. After the ECA rule is executed, the condition for the resource state to change is:

➀

If the Action (action or service) part of an ECA rule has object attribute turn-on, then after this rule is executed, the resource status will become on;

➁

If the Action (action or service) part of an ECA rule has an object attribute turn-off, then after this rule is executed, the resource status will become off;

➂

If the Action (action or service) part of an ECA rule has object attribute occupation, then after this rule is executed, the resource status will become busy.

According to the above natural language description, it is transformed into a meta-rule, as shown below:

➀

metaR-2:

Rule (?r)^FamilyService (?fs)^hasService (?r,?fS)^Property (tum-on)^hasProperty (?fs,tum-on)^Resource (?res)^hasResource (tum-on, ?res)→changeState (?res, on)

➁

metaR-3:

Rule (?r)^FamilyService (?fs)^hasService (?r, 7fs)^Property (turn-off)^hasProperty (?fs, turnoff)^Resource (?res)”hasResource (tum-off, ?res)→changeState(?res, off)

➂

metaR-4:

Rule (?r)^FamilyService (?fs)^hasService (?r, ?fs)^Property (occupy)^hasProperty (?fs,occupy)^Resource (?res)^hasResource (occupy, ?res)→changeState (?res, busy)

Another definition is as follows:

Definition 4.

If ∃resl|sl (changeState (?res, ?s)), ∃res2|s2 (changeState (?res, ?s)), and resl = res2, s1 ≠ s2, then changeState (resl, s1) = changeState (res2, s2) (or changeState (res2, s2) = changeState (resl, s1)).

Based on the above meta-rules, to determine and detect ECA rule conflicts according to the conflict detection algorithm, first define the following:

Definition 5.

FPR (service-property-resource collection) = {(fs, p, res)|fs is a subclass of FamilyService, p is an object property, res is a subclass of Resource}.

Definition 6.

SC (Resource Conflict Set) = {(Fsl, Fs2, Res)|Fsl and Fs2 resource conflict, and occupy resource Res at the same time}.

Definition 7.

EC (effect conflict set) = {(Fsl, Fs2) l Fsl and Fs2 effect conflict}.

The specific detection algorithm is as follows:

Definition 8.

RC (Rule Conflict Set) = {(Evt, Fs, conEvt, conFs, type)|Evt is the action (the Action of the ECA rule) is the triggering event (ECA rule) of the ECA rule of sci.Fs1 (or eci.Fs1) Event), Fs is the corresponding sci.Fs1 (or eci.Fs1), conEVt is the triggering event of the ECA rule whose action is sci.Fs2 (or eci.Fs2), and conFs is the corresponding sci.Fs2 (or eci.Fs2)), type is SC (or EC); i = 1,2...}.

The rule conflict set marks the triggering event of the ECA rule that may cause conflict (Event in the ECA rule). When the rule is executed, when one of the events is triggered and the corresponding conditions are met, the triggering event of the conflicting rule is detected in real time Whether it happens, once the conflict triggering event occurs, you need to take corresponding solutions.

6. Verification Example

In order to verify the feasibility of the technology, take the naval surface vessel air–sea coordinated assault operation as an example, and conduct rule extraction according to the ECA-driven decision-making mechanism. In response to unexpected situations that may occur in a certain sea area, against the enemy’s naval fleet, the use of aviation, surface ships, submarines and shore guidance forces to implement multi-wave contract attacks against the enemy with the support of shore-based electronic warfare forces. The command post has direct command of its troops. The shore-based command post and various combat platforms jointly complete various combat phase tasks such as comprehensive situation analysis, determination of strike determination, formulation of combat plans, adjustment of combat plans, and execution of combat plans.

The process of extracting and constructing operational rules is as follows:

(1)

Task analysis.

Based on the analysis of the initial situation of the battlefield, the task is decomposed, and the air and sea coordinated assault mission is decomposed (as shown in Figure 3).

Decompose task dependencies. Based on the “task decomposition diagram”, further analyze the sub-task execution structure and dependencies of the air–sea jointed anti-sea assault mission, and draw a “task execution structure diagram” (as shown in Figure 4).

(2)

Scene analysis.

Based on task analysis, combined with domain knowledge, analyze and list various possible states, events, actions, and new states after the actions during combat operations, and obtain “air–sea jointed anti-sea assault scenario analysis diagram”, as shown in Figure 5.

(3)

Trigger event analysis.

Based on the “scene analysis graph, analyze and sort out the events that trigger new actions, and “air–sea jointed anti-sea assault event list” is proposed (shown in

Table 2. List of air and sea jointed anti-sea assaults in naval battlefield.

Event	Event Name	Remark
e1	Takeoff order received	The plane received a takeoff order
e2	Reach height	The plane reaches the specified altitude
e3	Arriving in the airspace	Plane arrives in designated airspace
e4	Assembled	The aircraft is assembled
e5	Forward order received	The aircraft received a forward order
ej6	Fighter arrives in patrol airspace	The plane arrives at the designated patrol airspace
ej7	Receipt of interception order	Fighter received intercept order
e8	Received return order	Received return order
ey4	Aerial threat found	Early warning detection of aerial threats
ey5	Discover and identify the target of the attack	The early warning aircraft found and identified the target of the attack
ey6	mission completed	The attack target reaches the specified damage level, and the attack mission is completed
eg6	Attack aircraft arrives in standby airspace	The attack aircraft arrives in the designated standby airspace
eg7	Attack order received	The attack aircraft received the command to attack the sea
es1	Receipt of sailing order	Warship received an order to sail
es2	Arrived in the standby area	Warship arrives in the standby area
es3	Attack order received	Warship receives an order to attack the sea

).

(1)

State transition condition analysis.

Based on the scene analysis graph and event table, the trigger conditions for triggering the state transition were analyzed and sorted out, and the “air–sea coordinated assault state transition table” was obtained (as shown in

Table 3. Changes in the state of air and sea jointed anti-sea assaults in naval battlefield.

State Transfer	Event	Transfer Condition	Execution Action	Etraction Rule
Sj0→Sj1	e1	cj1: Fighter received takeoff order	a1: take off	Rj1
Sj1→Sj2	e2	cj2: The fighter plane reaches the predetermined height	a2: flight	Rj2
Sj2→Sj3	e3	cj3: Fighter arrives in the assembly airspace	a3: Assemble	Rj3
Sj3→Sj4	e4	cj4: Fighter assembly is complete	a4: The report is assembled	Rj4
Sj4→Sj5	e5	cj5: Fighter receives forward order	a2: flight	Rj5
Sj5→Sj6	ej5	cj6: Fighter arrives in patrol airspace	aj6: patrol	Rj6
Sj6→Sj6	ej6	cj7: Fighter received intercept order	aj7: Air intercept	Rj7
Sj6→S8	e8	cj8: Fighter received a return order	a8: Return home	Rj8
Sy0→Sy1	e1	cy1: AWACS received takeoff order	a1: take off	Ry1
Sy1→Sy2	e2	cy2: AWACS reached a predetermined height	a2: flight	Ry2
Sy2→Sy3	e3	cy3: AWACS arrives at the scheduled airspace	ay3: Reconnaissance search	Ry3
Sy3→Sy3	ey4	cy4: An early warning aircraft detects an air threat^The fighter plane arrives in the patrolled airspace	ay4: Guide fighter interception	Ry4
Sy3→Sy3	ey5	cy5: The early warning aircraft finds and recognizes the attack target^The attack aircraft arrives in the attack airspace^Warship arrives in the standby area	ay5: Guide attack aircraft and surface ships to attack the sea	Ry5
Sy3→S8	ey6	cy6: All assault targets have reached the level of damage	a8: Return home	Ry8
Sg0→Sg1	e1	cg1: Attack aircraft received takeoff order	a1: take off	Rg1
Sg1→Sg2	e2	cg2: The attack aircraft reaches the specified altitude	a2: flight	Rg2
Sg2→Sg3	e3	cg3: The attack aircraft arrives in the assembly airspace	a3: Assemble	Rg3
Sg3→Sg4	e4	cg4: Attack aircraft assembled	a4: The report is assembled	Rg4
Sg4→Sg5	e5	cg5: The attacker received the forward order	a2: flight	Rg5
Sg5→Sg6	eg6	cg6: Attack aircraft arrives in standby airspace	ag6: Air standby	Rg6
Sg6→Sg6	eg7	cg7: Attacking aircraft received an attack command	ag7: Attack aircraft to sea attack	Rg7
Sg6→S8	e8	cj8: Attack aircraft received a return order	a8: Return home	Rg8
Ss0→Ss1	es1	cs1: Warship received an order to sail	as1: Surface ships set sail	Rs1
Ss1→Ss2	es2	cs2: Warship arrives in the standby area	as2: Surface ship standby	Rs2
Ss2→Ss2	es3	cs3: Warship receives an attack order	as3: Surface ship to sea attack	Rs3
Ss2→S8	e7	cs4: Surface ship receives order to return	a8: Return home	Rs4

).

(2)

Rule expression.

According to the grammatical structure of ECA rules, each change in the state of air and sea jointed anti-sea assaults in the state transition table is mapped to a corresponding rule.

7. Conclusions

In this work, the design of a rule-based extraction and construction architecture has been proposed with the aim to help commanders in defining their decision rules. Decision-making is the central task of command. Improving the timeliness and accuracy of operational decision-making in naval formations is an important method to improve combat command capabilities [29]. In view of the high requirements of current operational planning on decision timeliness, the situation analysis and plan formulation in the decision-making process should be assigned to the intelligent autonomous decision-making model to minimize the workload of the commander’s decision-making. Improve the efficiency and rationalization of operational decision-making, and realize the rapid formulation and optimization of decision-making plans to adapt to the sensitivity requirements of wartime decision-making on time, data, and changing battlefield environments. However, the naval surface vessel jointed operational decision-making is a complex issue. Different operational missions and different jointed operational platforms have different operational rules. How to effectively obtain, organize, and describe operational rules requires a lot of experimentation and continuous improvement. It also needs to further research on the perception and learning behaviors of naval operational decision rules based on task scenario analysis.