Operational Rule Extraction and Construction Based on Task Scenario Analysis

: Changes in the information age have induced the necessity for a more efﬁcient 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 speciﬁcations of Event Condition Action (ECA) rules are deﬁned, 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 battleﬁeld decision environment, and avoid relying on artiﬁcial intelligence, which may have brought some uncertain factors.


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 partof-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.

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].

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.

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.

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.

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]: 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.

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. 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.
Task scenario analysis Figure 1. The hierarchical structure and corresponding relationship of tasks and scenarios.
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.

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 A complex task can be expressed as: 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.

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.
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: 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 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: 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 1 is the initial state of Scenario 1 , and A 1 occurs the Scenario 1 to S 2 , which means the S 1 transfer to S 2 by A 1 .
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: S1 is the initial state of Scenario1, and A1 occurs the Scenario1 to S2, which means the S1 transfer to S2 by A1.  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.

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 e1 If c1 Do a1}, Rule 2:{On e2 If c2 Do a2}, and ∃e1,e2∈E, ∃c1,c2∈C, ∃a1,a2∈A. Conclusion 1. If e1 = e2, c1⊂c2, and a1 = a2, it is easy to get that either Rule1 or Rule2 is inaccurate. Then, if the occurrence of c1 can fully trigger the action, it means that c2 is redundant, and it can be further concluded that Rule2 is redundant. On the contrary, if c2 is necessary, then c1 cannot be used as a condition to trigger an action. At this time, Rule1 is wrong.
(2) preceding (c1, e2) (or c1 = e2), and the condition c2 is established. 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.

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 1 If c 1 Do a 1 }, Rule 2:{On e 2 If c 2 Do a 2 }, and ∃e 1 ,e 2 ∈ E, ∃c 1 ,c 2 ∈ C, ∃a 1 ,a 2 ∈ A. Conclusion 1. If e 1 = e 2 , c 1 ⊂c 2 , and a 1 = a 2 , it is easy to get that either Rule1 or Rule2 is inaccurate. Then, if the occurrence of c 1 can fully trigger the action, it means that c 2 is redundant, and it can be further concluded that Rule2 is redundant. On the contrary, if c 2 is necessary, then c1 cannot be used as a condition to trigger an action. At this time, Rule1 is wrong.
It can be seen that Rule 1 will be triggered at the same time Rule 2 will be triggered. If exclusive (a 1 , a 2 ), then at least one of the rules Rule 1 and Rule 2 is wrong; if exclusive (a 1 , a 2 ) (or a 1 = a 2 ), then Rule 1 and Rule 2 are compatible with each other. At this time, you need Integrate rules Rule 1 and Rule 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: 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. 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.
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 Family-Service, p is an object property, res is a subclass of Resource}.  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.

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).
In order to verify the feasibility of the technology, take the naval surface vessel airsea 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.
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. (2) Scene analysis.

AWACS
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). 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 (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). Table 2. List of air and sea jointed anti-sea assaults in naval battlefield.

Event
Event Name Remark e 1 Takeoff order received The plane received a takeoff order e 2 Reach height The plane reaches the specified altitude e 3 Arriving in the airspace Plane arrives in designated airspace e 4 Assembled The aircraft is assembled e 5 Forward 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).  (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.

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 decisionmaking 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.