BML-based command and control information interoperation model system framework construction method

Abstract

The invention provides a BML-based command and control information interoperation model system framework construction method. The method comprises the following steps: S1, grammar system construction and rule formation, wherein the grammar system construction comprises language feature analysis, grammar element extraction and description and formalized grammar analysis; s2, semantic model generation: the semantic model covers all meta-phrases of command phrases of a command information system, and the design of model content supports function implementation of a semantic analysis module in the command and control information interoperation model; s3, semantic model mapping: mapping conversion is carried out on the semantic model to an instantiated simulation model BOM of the BML in HLA simulation modeling, the semantic model can be mapped and combined into the simulation model BOM, interaction information is generated, and a simulation system is triggered to run; and S4, generation of the ontology model: forming a five-step construction method of the ontology model. The method has the characteristics of realizing automatic identification of command and control information in simulation training and improving troop training efficiency.

Description

Technical Field

[0001] The present invention relates to a method for constructing a BML-based command and control information interoperation model system framework, and in particular to the field of data interaction operation model construction. Background Art

[0002] Battle Management Language (BML): A language supported by the U.S. Department of Defense that can unambiguously command and order troops and equipment to conduct military operations, provide situational awareness, and share combat operations.

[0003] The information transmission in the current military command information system is transmitted in the form of text or short messages, and each command and control node only processes this information as a single data field or a data format of a specific protocol. These specific data formats are unrecognizable to the physical simulation system, resulting in the transmitted command information being like "free text" to the action simulation system, and cannot be directly converted into the data structure required to drive the simulation model to run.

[0004] The current technology for achieving interoperability between software can be divided into two situations. One is that operators need to manually process the data flow and conversion between software. For example, the current data interaction between the command information system and the simulation system requires a large number of professionals to convert the language format recognized by the command information and simulation systems. The transplantation performance is poor and the operation complexity is high. The second is to ensure that the structure of the data flowing between software is the same, and to achieve interoperability conversion by ensuring the unified structure of the data. Summary of the invention

[0005] The technical problem to be solved by the present invention is to provide a method for constructing a BML-based command and control information interoperability model system framework for realizing automatic recognition of command and control information in simulation training and improving the training efficiency of troops.

[0006] In order to solve the above technical problems, the technical solution adopted by the present invention is:

[0007] A method for constructing a command and control information interoperability model system framework based on BML, comprising the following steps:

[0008] S1: Construction of grammar system and formation of rules: The construction of the grammar system includes language feature analysis, extraction and description of grammatical elements and formal grammar analysis;

[0009] The formation of the grammar rules refers to designing a data structure, carrying grammar rule information, storing grammar rule analysis results, and providing grammar rule data support for the command and control information interoperability model;

[0010] S2: Semantic model generation: The main functional modules of the semantic model generation include four parts: ontology analysis, semantic matching, rule base and instantiation, which covers all meta-phrases of command phrases in the command information system. The design of the model content supports the functional implementation of the semantic analysis module in the command information interoperability model;

[0011] S3: semantic model mapping: mapping and transforming the semantic model to the instantiated simulation model BOM as BML in HLA simulation modeling, decomposing the charge information into the BML semantic model in XML format through syntax analysis, and mapping and combining the semantic model into the simulation model BOM to generate interactive information, trigger the simulation system to run, and form a mapping and transformation rule set between the semantic model and the simulation model;

[0012] S4: Ontology model generation: refers to the use of BOM technology for HLA-based virtual force simulation, forming a "five-step" construction method for the ontology model, and using Protégé as the ontology construction tool, focusing on the construction of the combat action ontology model, targeting the entity elements and task state transitions, and verifying the semantic reasoning and validity verification based on the ontology.

[0013] Furthermore, in step S1, the set architecture design of the grammatical rules includes a grammatical type name representing the type of command phrase, a grammatical sentence pattern rule representing the fixed part of the command phrase, a grammatical parameter meaning representing the meaning of each free part of the command phrase, a grammatical type number used for management, and grammatical keywords screened after specific analysis.

[0014] Furthermore, in the step S1, the formal syntax analysis adopts the IBNF formal method to structure the BML message, and the accusation information includes three parts: a header, a footer and a body.

[0015] Furthermore, in step S2, the ontology parsing module generates a data table to obtain information for different operations, including conversion, parsing and inheritance of the ontology; it includes the following steps:

[0016] S21: First, create a database connection, load the database driver class for exception handling; use the database connection parameters to create a model maker and create a model; establish a file input stream (FileInputStream) to read the ontology description file in the database; close the input stream reader, perform data conversion, store the ontology data in the database, and close the database connection;

[0017] S22: Get ontology node information, get all classes, including class name and class description type; get all object attributes, including object attribute name, definition domain and value range; get all instances, including instance name and class to which the instance belongs;

[0018] S23: The node information obtained after the ontology parsing is classified and stored in a data table for use in the operation of data in the semantic matching module.

[0019] Furthermore, in step S2, the semantic matching module mainly includes two parts of calculation: semantic similarity and semantic relevance, and its calculation includes the following steps:

[0020] S24: Calculating semantic similarity means combining the class names and instance names obtained after ontology parsing into concept pairs, and then calculating them. Before calculation, the node names should be extracted and combined into all concept pairs as much as possible. According to their value ranges, for the constructed small ontology, the number of ontology levels is set to 4, and the similarity of two identical nodes is initialized to 1.

[0021] S25: Calculate the relevance, mainly inferring new relationships based on existing, custom object attribute relationships, and calculating the shortest path length between nodes corresponding to the new relationship, and converting it into the relevance between concepts;

[0022] S26: Calculate the synthesis value, use the similarity and correlation to calculate the result, and obtain the result;

[0023] S27: Calculate the semantic matching degree. According to the specific text content, find the corresponding concept in the ontology. Use the calculated composite value to average the composite values ​​between adjacent words in the text to get the semantic matching degree. The semantic matching degree value reflects the quality of the word segmentation of the text content.

[0024] Furthermore, in step S2, the establishment of the rule base is mainly used to calculate the semantic relevance and further infer new relationships. The formation of new relationships is mainly used to reason about instances, and the establishment of rules is determined by subjective consciousness.

[0025] Furthermore, in step S3, the semantic model mapping is combined into a simulation model BOM, using attribute-driven BOM mapping or action-driven BOM mapping.

[0026] Furthermore, in step S4, the ontology model is generated by using Protégé as a tool to assist in generating the ontology and performing reasoning, and the following five-step method is used to construct the domain ontology, determine the scope of the ontology, obtain domain knowledge, define concept classes and attributes, create an ontology instance, verify the ontology and analyze.

[0027] Furthermore, in step S4, the five-step method for ontology model generation includes the following steps:

[0028] Step S41: Determine the scope of the ontology: First, it is necessary to clarify the ontology according to the research tasks and purposes, clarify the scope of the ontology, its purpose and the target user objects, and determine the content and scope of the ontology construction;

[0029] Step S42: Obtain knowledge definition and perform knowledge reuse: List the important terms of interest in the field, define concepts, attributes and the relationships between them within the field, and then perform knowledge reuse;

[0030] Step S43: define concept classes and attributes: ontology classes are abstracted from objectively existing objects; define class attributes and relationships, and relationships have "intrinsic attributes" of the concept itself and "extrinsic attributes" of external interactions; in this step, the attribute value type and value range of the attribute must be defined;

[0031] Step S44: ontology instance creation: construct an ontology instance using a formal language or modeling tool, determine which class the instance belongs to, create an instance under the class and assign values ​​to its attributes.

[0032] Step S45: Ontology verification and analysis: Use modeling tools or ontology reasoning language to verify and analyze the constructed ontology model.

[0033] Furthermore, in step S4, the combat action ontology model is constructed by focusing on the ontology definition of entity elements and the knowledge description of action state transition, which adopts the following five-step method:

[0034] S46: Determine the scope of the entity: actions are divided into offensive, defensive, and support actions;

[0035] S47: Obtain knowledge definition: Based on the concept of action, obtain the accurate definition of the action;

[0036] S48: Define concept classes and attributes: Define various relationships between combat operations, such as inclusion, parallel, and synonymous relationships; combat operation attribute structure elements include combat operation type, command type code, order issuer, order executor, execution time, task completion time, geographical coordinates, route coordinates, methods and means;

[0037] S49: Ontology instance creation: Use Protégé software to add subclasses "offense class", "defense class", and "security class" through the Class hierarchy of Classes;

[0038] S410: Ontology verification and reasoning analysis: Use the tool to input various categories and instances, and the software automatically generates tree-like relationship diagrams, hierarchical structures and visual representations; through reasoning on the generated ontology and expert manual analysis, the relationship between various combat actions is tested to ensure the correctness of the established ontology; by defining the concepts of "attack" and "defense", the reasoning engine FaCT++ is used to perform TBox reasoning on the constructed ontology to obtain the conceptual hierarchy after reasoning.

[0039] The beneficial effects of adopting the above technical solution are:

[0040] The present invention adopts Battle Management Language (BML) as the basic theoretical basis through method research and software development, and forms an automatic interoperability specification system for command information from "free text" to formatted information by constructing a command information interoperability model, thereby realizing automatic recognition of command information in simulation training, greatly reducing the complexity of information interaction between systems, improving the interconnection and interoperability between the system command information system and the simulation system, and improving training efficiency and overall command effectiveness.

[0041] The present invention aims to design a domain ontology for combat management language understanding, propose an improved semantic matching algorithm, and realize computer automatic and intelligent understanding by instantiating combat management language content, thereby accelerating the speed and quality of combat management language processing. This study improves the ability to analyze combat management language, and uses semantic matching calculation methods to determine the optimal word segmentation results of combat management language sentences. The words in the word segmentation results are not isolated, but the entire sentence is related (the so-called semantic association), which enables the computer to understand the meaning of the sentence and automatically extract the metadata of the combat elements, thereby improving the effectiveness of combat command.

[0042] In order to solve the information interaction problem between such command information systems and action simulation systems, the present invention designs and constructs a series of specifications and driving models for command and control information interoperability in the theory of guarantee simulation systems, and invents an interoperability method and system between command information systems and action simulation systems or physical simulators, so as to realize automatic recognition of command and control information in simulation training and improve the training efficiency of troops.

[0043] The control and command information interoperability model framework system of the present invention is complete and universal, and can be used for the development of various simulation systems.

[0044] The present invention forms a complete set of interoperability modeling methods from conceptual models to simulation models, which can be used to solve the interoperability problems between other command and control systems and simulation systems.

[0045] The model of the present invention, based on the use of the HLA framework, inherits the advantage of the framework in being able to adapt to the evolving new technologies and can meet the simulation needs of complex large systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1 It is a schematic diagram of the interoperability model of the business process diagram of the system of the present invention;

[0047] Figure 2 It is a schematic diagram of the command activity syntax tree in the present invention;

[0048] Figure 3 This is a schematic diagram of the status report syntax tree in the present invention;

[0049] Figure 4 This is a schematic diagram of the voice rule set display interface in the present invention;

[0050] Figure 5 Schematic diagram of the mapping relationship between the semantic model of the present invention and BOM;

[0051] Figure 6 This is a schematic diagram of the process of constructing a domain ontology using the "five-step method" of the present invention;

[0052] Figure 7 Creating a schematic diagram for the combat action class relationship of the present invention; DETAILED DESCRIPTION

[0053] The present invention provides a method for constructing a BML-based charge information interoperability model system framework, which includes the following steps: S1: grammar system construction and rule formation: the construction of the grammar system includes language feature analysis, extraction and description of grammar elements, and formal grammar analysis;

[0054] 1) Language feature analysis means that in order to organize the elements of combat orders in a way that is closer to human thinking and accurately express the commander's intentions, the grammatical formalization method of combat orders should fully conform to the language structure characteristics of combat orders. Combat orders have the following typical characteristics: fixed format, standardized content; concise sentences, orderly organization; high grammatical accuracy; more military terms, fewer modifiers and conjunctions; suitable for network transmission. And due to the constraints of Chinese grammatical norms and format requirements, combat orders often have a large number of repeated content structures and pay more attention to semantic expression. Therefore, the grammatical formalization description method must at least meet the following points: simple expression, accurate wording, standardized structure, clear semantics; good scalability; application in social and network environments.

[0055] 2) Extraction and description of grammatical elements

[0056] A combat order usually consists of three parts: the head, the tail, and the body. The body is the main part, which contains various forms with unique structures that are different from other forms. This application is mainly for the body part. The body part is mainly composed of some common basic elements, such as action, time, space elements, etc. The most important grammatical elements can be summarized as the "5Ws" elements, namely Who, What, When, Where and Why, with the specific meanings as follows:

[0057] Who: refers to the belligerent who takes or should take action;

[0058] What: indicates the action to be taken or the action that has been taken;

[0059] When describes the time node of the action taken or the time of the action or event that has occurred;

[0060] Where: Provides the location of the combatant, the place where the action is taking place, or the place where the action or event has occurred;

[0061] Why: Describes the reason or goal for the action to be performed, or the desired end state of a planned action.

[0062] "5Ws" can be expanded according to certain rules, but Who and What are simple types, such as "destroyer" and "launch", and do not need to be expanded. The expansion rules of the other elements are as follows.

[0063] When elements are mainly divided into two categories: Start-When and End-When. They both have two extension forms: one is a combination of the start or end identifier, modifier and relative time point; the other is a combination of the start or end identifier, relative time point modifier and action. Take Start-When as an example, its extension rules are:

[0064] <start-when>::=*start* <qualifier1> <point-in-time> (1)

[0065] <start-when>::=*start* <qualifier2><Action> (2)

[0066] Among them, start means start; Qualifier1 is a modifier, such as "no later than"; Point-in-Time represents a certain point in time; Qualifier2 represents a modifier of a relative point in time, such as "after the action Action ends"; the non-terminal symbol Action represents another action to be executed.

[0067] The Where element can be divided into two extension types: At-Where and Route-Where:

[0068] <W′here> ::= <at-where> | <route-where> (3)

[0069] <at-where>::=*at* <locin> (4)

[0070] <route-where> ：：＝( <source> <destination><Path>)

[0071] |( <source> <path> )|( <destination> <path>)|...

[0072] |(*along* <path>) (5)

[0073] <source> ::="from” <location> (6)

[0074] <destination>::="to” <location>(7)

[0075] Among them, "at", "from", "to", and "along" are grammatical terminators; Location represents location information, such as "Pier A"; Path represents a route, such as "Around Island B".

[0076] The Why element includes the need to achieve a certain action goal, attain a certain state, and obtain further purpose:

[0077] <why>::=*in-order*<Vreb>[\Task-Label\] (8)

[0078] <why>::=*in-order**cause*\EndState-Label\ (9)

[0079] <why>::=*in-order**enable*\Expanded-Purpose-Label\ (10) In-order-to is used to indicate the purpose; Verb represents the command action; Task-Label is the task reference identifier; and Expanded-Purpose-Label is the extended purpose reference identifier.

[0080] By extracting grammatical elements and formalizing their descriptions, when a certain element changes, maintenance personnel do not need to update the entire combat order template, but only need to update the changed elements, thus greatly reducing the workload of maintaining the template in the future.

[0081] 3) Formal grammar analysis

[0082] Formal method is a software development method based on mathematics, which can accurately describe the requirements and design of the system and effectively improve the quality of software. It is a development method based on strict data and has precise mathematical semantics. From a broad perspective, formal method is a system engineering method for analysis, design and implementation in the software development process; in a narrow sense, formal method is a method for software specification and verification.

[0083] The present invention is based on BNF formal grammar, combined with the technical features of the present invention and BML element content, to make targeted improvements. In the process of BML grammar formal description, the structural characteristics of combat orders must be fully considered. The combat orders such as commands and reports that interact between our military command and control system and simulation system are generally expressed in Chinese, which is constrained by Chinese grammar norms and follows the format requirements of combat orders. They have the following typical structural characteristics:

[0084] (1) There is a large amount of repeated content structure. A command may contain multiple tasks; a report may contain status information of multiple units, which requires the formal method to have a mechanism to refer to repeated content when decomposing the message.

[0085] (2) It has a large number of reference content structures. This includes two situations: referencing other elements and being referenced by other elements. A command may reference a specific task assigned to a unit; multiple combat units in the same location may reference the same address to describe their own location information.

[0086] (3) There are a large number of nested hierarchical structures. The elements in the combat order are nested between the upper and lower layers, so it is necessary to continuously iterate and go through the process of representation from abstract to concrete. For example, the plan is composed of nested elements such as tasks and personnel, and the tasks can be further subdivided into multiple smaller sub-elements.

[0087] (4) Focus on semantic expression. All combat command forms must be able to fully and clearly express the commander's intentions to avoid ambiguity in understanding between the commander and the machine.

[0088] The above characteristics are structures that must be fully considered when describing BNF. However, the standard BNF metasymbols are relatively simple. When describing issues such as repetition and reference in combat orders, the structure is often rigid and inefficient. Therefore, it is necessary to make appropriate improvements to the standard BNF so that it can meet the needs of formal description of combat orders with the above structure.

[0089] In order to make BNF more suitable for describing the language characteristics of combat commands, the standard BNF is appropriately improved by taking advantage of its open and extensible characteristics, while balancing simplicity, compatibility and effectiveness. The improved BNF is called IBNF (Improved BNF), and its metasymbols and descriptions are listed in Table 1.

[0090] Table 1 Description of the main meta-symbols of IBNF

[0091]

[0092] IBNF's improvements over standard BNF are mainly reflected in the following aspects.

[0093] (1) Define symbols that can be repeated multiple times to indicate situations where a rule needs to appear multiple times.

[0094] (2) Add reference symbols to facilitate the identification of references to other rules or being referenced to other rules.

[0095] (3) Add priority symbols to reasonably combine the order of elements in the rules.

[0096] (4) Define a description of the annotation content that can be used to explain the key elements in the rule.

[0097] Ellipses "..." may appear in IBNF expressions. They are not IBNF meta-symbols, but indicate the omission of repeated elements. In addition, meta-symbols such as "\\" and "{}" cannot be nested with other symbols.

[0098] In order to standardize the element names between the command and control system and the simulation system, the following conventions are required for the naming rules of the basic elements of IBNF.

[0099] (1) In IBNF, multiple-word elements are separated by a hyphen "-". For example, "task-time".

[0100] (2) The numeric element names in IBNF can only be non-negative integers, and no modifiers are allowed to be added to the left of the number. For example, "1223" and "0" are legal forms, while "-1" and "063" are illegal forms.

[0101] IBNF description of typical action commands

[0102] The command information system processes various forms of accusation information, including commands, reports, requests, plans, and notifications. The ultimate goal of the grammatical formalization method is to structure BML messages. Usually, the accusation information includes three parts: the header, the footer, and the body. Among them, the body is the main part of the accusation information, and the body structure of various types of accusation information will be different. This paper focuses on analyzing the language structure characteristics of the command and report body parts, and uses the IBNF method for formal description in combination with specific examples.

[0103] ① IBNF description of the command

[0104] Commands are used for statutory tasks or decisions issued by superiors to subordinates, and are an important form of BML messages. The basic rules can be described as follows:

[0105] S::={ <ob>} (11)

[0107] Among them, rule (21) belongs to the production rule set P; S is the start symbol of the grammar, which is used to indicate the beginning of the grammar; 0B belongs to the non-terminal symbol N, which is used to indicate command activities. The use of the symbol "{}" means that a command can be composed of any number of basic command expressions 0B. Non-terminal symbol 0B has further expansion rules. After analysis, the basic expression 0B can be expressed as an ordered combination of sub-elements, so OB can be expanded to:

[0108]

[0109]

[0110] Among them, the non-terminal symbol Verb represents the action to be performed, such as "attack", "defense", "ambush", etc.; the non-terminal symbol Tasker represents the name of the entity that issues the command; the non-terminal symbol Taskee represents the name of the entity that receives the command; the non-terminal symbol Affected represents the name of the entity affected by the task, and its appearance is determined by Verb; the non-terminal symbol Action represents another action to be performed; the non-terminal symbols Start-When and End-When represent time phrases, such as "start no later than a certain time point", where "start" and "no later than" are both grammatical terminals; the non-terminal symbol Where represents location phrases, such as "where", "through where", etc.; the non-terminal symbol Why represents the reason why the task is required to be executed; the non-terminal symbol Label represents a unique identifier, and other commands can reference the command by using this unique identifier. Its general form is "combat command type reference type identification number", such as "command reference identification 1"; the non-terminal symbol Mod represents additional information required to describe a specific task, such as "formation", "speed", etc.

[0111] Among the grammatical symbols appearing above, Start-When, End-When, Where, Why, etc. belong to the non-terminal symbol set N, which has further extension rules; Verb, Tasker, Taskee, Affected, Action, Label, Mod, etc. belong to the non-terminal symbol set N, which is taken from the metadata in the data model; and start, end, at, from, to, along, etc. belong to the grammar terminal symbol set ∑, and no rule extension is required.

[0112] Now suppose that in a certain example, part of the command issued by the headquarters to its subordinate units is as follows: "Depart at 18:00:00 on March 16, 20XX, and move to XX°28'.0N, XX°08'.23E to prevent the enemy commandos from infiltrating."

[0113] The command is described in IBNF as follows:

[0114] *Mobile** command** subordinate units** begin** no later than** March 16, 20XX 18:00:00** XX°28'.0N, XX°08'.23E** in order to** prevent*\command reference identifier 1\ / command referenced identifier 2.

[0115] Among them, the reference identifier "command reference identifier 1" indicates that the content in "command reference identifier 1" needs to be referenced to "block" the infiltration of the object "enemy commando"; and "command referenced identifier 2" indicates that if other rules need to reference the command structure, the identifier "command referenced identifier 2" can be used.

[0116] Its syntax tree structure is as follows Figure 2 shown.

[0117] ② IBNF description of the report

[0118] Reports are used by subordinates to reflect the actual situation to their superiors and respond to their superiors' orders. The most important difference between reports and orders is that they have different understandings of the certainty of the content. For orders, the content such as action units and action attributes are certain, while for reports, these contents are usually uncertain. Therefore, it is necessary to add corresponding production rules and non-terminal symbols to reports to indicate the action unit type, equipment type, fuzziness and other important information. The formal rules of reports are described as follows.

[0119] A report consists of one or more basic report expressions RB. The basic rules can be described as follows:

[0120] S::={ <rb>} (13)

[0121] According to the different contents of the report, the report is divided into three types: task report, event report and status report. They can all be expressed as an ordered combination of their respective sub-elements. Their basic activity rules RB are shown in (14)-(16).

[0122] <RS>::=*Task-Report* <verb> <executer>

[0123] [ <affected> | <action> ] <when> <where>

[0124] <certainty> / Label / { <mod>} (14)

[0125]

[0126] Among them, basic rules (14)-(15) belong to the production rule set P; Task-Report, Event-Report and Status-Report belong to the terminal symbol set ∑, which are used to represent three types of task reports, event reports and status reports respectively; Verb, Affacted, Action, When, Where, Why, Label, Mod, Taskee, Label, etc. belong to the non-terminal symbol N, which comes from the data model and is used to represent certainty, such as "true", "may be true", "uncertain", etc.

[0127] In rule (14), the non-terminal Executer is used instead of the non-terminal Taskee, because the report sender may not know the name of the task unit. According to the information the sender has, Executer may be any of the three types: Taskee, Agent, and Theme.

[0128] <Executer>::= <taskee> (16)

[0129] <executer> ：：＝ <agent>[ / Label / ] (17)

[0130] <executer> ：：＝ <theme>[ / Label / ] (18)

[0131] If the sender of the report knows the name of the execution unit, it is expanded into Taskee according to rule (16), and Taskee is the name of the execution unit. If the sender of the report does not know the name of the unit but knows the unit type, it can be expanded into Agent according to rule (17), and then Agent can be expanded according to rule (19), including the size (Size), hostility (Hostility) and type (Unit-type) of the execution unit, such as "a squad's support force". If the sender of the report only knows the type of equipment used by the unit, it is expanded into Theme according to rule (18), and Theme can be further expanded according to rule (20), including the number of equipment (Count), hostility (Hostility) and equipment type (Equipment-type) three sub-elements, such as "three enemy equipment".

[0132] <agent> ：：＝ <size> <hostility> <unit-type> (19)

[0133] <theme> ：：＝ <count> <hostility> <equipment-type>(20)

[0134] The non-terminal symbol Verb in the event reporting rule (14) comes from the user-defined data model and is used to represent a specific type of event, such as "hurricane is coming". The non-terminal symbol Regarding in rule (15) is further expanded as follows:

[0135] <regarding> ：：＝[ <position-general>|<status-general>|]<status-material>|<status-person> (twenty one)

[0137] Rule (21) divides status reports into four different types: position status report (position-general), overall status report of the combat unit (status-general), material status report (status-material), and personnel status report (status-person).

[0138] Among the grammatical symbols appearing above, Agent, Theme, Size, Hostility, Unit-type, Count, Equipment-type, position, status-general, status-material, status-person, etc. belong to the non-terminal symbol set N, which are all taken from the metadata in the data model; while Task-Report, Event-Report, status-Report, etc. belong to the grammatical terminal symbol set ∑ and do not require rule expansion.

[0139] Now suppose that in a certain case, the subordinate sends the following position status report to the superior headquarters: "At 12:24:08 on March 17, 20XX, our unit arrived at XX°48'.13N, XX°38'.42E."

[0140] The above report is described as follows using IBNF:

[0141] *Status report** Our **position status** arrived at **XX°48'.13N,XX°38'.42E** at **12:24:08 on March 17, 20XX** Facts** Command_Reference_Identifier1*.

[0142] Its syntax tree structure is as follows Figure 3 shown.

[0143] The formation of the grammatical rules refers to designing a data structure, carrying grammatical rule information, storing grammatical rule analysis results, and providing grammatical rule data support for the command and control information interoperability model.

[0144] The command phrases of the command information system are classified by type. Each command phrase is divided into two parts: one part is a fixed sentence format, which should not be deleted or modified according to the basic specifications of the combat management language; the other part is a fixed number of specific data and instructions in the phrase. This part is the free part of the sentence format, which only standardizes its meaning type such as time, coordinates, etc., and needs to be filled in according to the actual situation in actual use.

[0145] Therefore, the grammatical rule set architecture design should include three parts: the grammatical type name representing the type of command phrase, the grammatical sentence rules representing the fixed part of the command phrase, and the grammatical parameter meaning representing the meaning of each free part of the command phrase.

[0146] In addition, there should be a grammar type number for management and a grammar keyword selected after specific analysis. The grammar type number is used to enhance the robustness of the rule set to ensure that multiple sentences corresponding to the same grammar can be added to the rule set normally. The grammar keyword is used for actual judgment and the grammar type to which the input text belongs is determined by matching the grammar keyword phrase to determine the basic meaning of the sentence.

[0147] The content of the rule set is divided into five categories: grammar type number, grammar type name, grammar keyword, grammar sentence pattern rules, and grammar parameter meaning. The grammar type name is the command phrase type name in the integrated information system command platform; the grammar keyword is the characteristic keyword extracted from the command phrase. Some phrases cannot be distinguished from other command phrases using one keyword, so multiple keywords are used to distinguish them; the grammar sentence pattern rules are the fixed sentence pattern part of the command phrase. This part is the phrase skeleton part that cannot be modified in the command information system, and the part where custom text can be added uses the "$" symbol for wildcarding; the meaning of the grammar parameter is to give each "$" part in the sentence pattern rule a meaningful name, and each name corresponds to a "$" part in the sentence pattern rule, separated by a semicolon.

[0148] S2: Semantic model generation: The semantic model module includes designing data structures, carrying semantic model information, building semantic model sets, storing semantic analysis results, and providing semantic model data support for the command and control information interoperability model. The interoperability model system includes a display page for semantic information. Since semantic information has more information than grammatical information, the page is displayed in a paging manner. It supports keyword fuzzy queries, and operators can quickly jump to the corresponding page through the page button at the bottom of the page.

[0149] The semantic model module covers all "meta-phrases" of the command phrases (commands, requests, reports, firepower) of the command information system, and the generated main functional modules have four parts: ontology parsing, semantic matching, rule base and instantiation.

[0150] In step S2, the ontology parsing module generates a data table to obtain information for different operations, including conversion, parsing and inheritance of the inference engine of the ontology; it includes the following steps:

[0151] S21: First, create a database connection, load the database driver class for exception handling; use the database connection parameters to create a model maker and create a model; establish a file input stream (FileInputStream) to read the ontology description file in the database; close the input stream reader, perform data conversion, store the ontology data in the database, and close the database connection;

[0152] S22: Get ontology node information, get all classes, including class name and class description type; get all object attributes, including object attribute name, definition domain and value range; get all instances, including instance name and class to which the instance belongs;

[0153] S23: The node information obtained after the ontology parsing is classified and stored in a data table for use in the operation of data in the semantic matching module.

[0154] The design of the model content supports the functional realization of the semantic analysis module in the command and control information interoperability model. The present invention designs a domain ontology for the understanding of combat management language, proposes an improved semantic matching algorithm, and realizes computer automatic and intelligent understanding by instantiating the combat management language content, which speeds up the speed and quality of combat management language processing, improves the analysis ability of combat management language, and uses the semantic matching calculation method to judge the optimal word segmentation result of a single sentence of the combat management language. The words in the word segmentation result are not isolated, but the whole single sentence is related (the so-called semantic association), which enables the computer to understand the meaning of the sentence and automatically extract the metadata of the combat elements, thereby improving the combat command effectiveness.

[0155] In step S2, the semantic matching module mainly includes two parts of calculation: semantic similarity and semantic relevance, and its calculation includes the following steps:

[0156] S24: Calculating semantic similarity means combining the class names and instance names obtained after ontology parsing into concept pairs, and then calculating them. Before calculation, the node names should be extracted and combined into all concept pairs as much as possible. According to their value ranges, for the constructed small ontology, the number of ontology levels is set to 4, and the similarity of two identical nodes is initialized to 1.

[0157] S25: Calculate the relevance, mainly inferring new relationships based on existing, custom object attribute relationships, and calculating the shortest path length between nodes corresponding to the new relationship, and converting it into the relevance between concepts;

[0158] S26: Calculate the synthesis value, use the similarity and correlation to calculate the result, and obtain the result;

[0159] S27: Calculate the semantic matching degree. According to the specific text content, find the corresponding concept in the ontology. Use the calculated composite value to average the composite values ​​between adjacent words in the text to get the semantic matching degree. The semantic matching degree value reflects the quality of the word segmentation of the text content.

[0160] When other factors are the same, whether from the perspective of human subjective experience or the perspective of corresponding formula derivation, the changing relationship between factors and similarity and correlation is consistent. For example, the smaller the semantic distance of the node, the greater the similarity value; the greater the node depth, the smaller the level difference, the greater the similarity; the greater the semantic overlap, the greater the similarity. The correlation calculation is obtained by removing the relationship between classes and subclasses and performing relational reasoning on the object attributes defined by the ontology creator.

[0161] In step S2, the establishment of the rule base is mainly used to calculate the semantic relevance and further infer new relationships. The formation of new relationships is mainly used to reason about instances. The establishment of rules is determined by subjective consciousness. As long as it is reasonable, it can be set as a rule for reasoning. It is a process of continuous updating and improvement, so the rules can be customized according to actual needs.

[0162] The content of the rule set is divided into three parts: meta-phrase, meta-phrase meaning, and priority weight. The meta-phrase is both the meta-phrase itself and the key name in the rule set that cannot be repeated or empty; the meta-phrase meaning is the meaning contained in the meta-phrase, which is extracted and provided to the model for display; the priority weight is the weight calculated by calculating the number of words in the meta-phrase, which is provided to the matching algorithm for sorting.

[0163] The semantic rule data structure is shown in Table 2, and the speech rule set display interface is shown in Figure 4 shown.

[0164] Table 2 SenmanticRule: semantic rule set table

[0165]

[0166] S3: semantic model mapping: mapping and transforming the semantic model to the instantiated simulation model BOM as BML in HLA simulation modeling, decomposing the charge information into the BML semantic model in XML format through syntax analysis, and mapping and combining the semantic model into the simulation model BOM to generate interactive information, trigger the simulation system to run, and form a mapping and transformation rule set between the semantic model and the simulation model;

[0167] Semantic model mapping means that the interoperability model obtains the charge information, performs BOM processing on the charge information, and then extracts the command information to drive the simulation system. Here, it is necessary to map the BML semantic model to the BOM simulation model, declare the input and output of the model, define the model solution method, and complete the conversion function from free language to computer language.

[0168] The semantic model mapping is combined into a simulation model BOM, using attribute-driven BOM mapping or action-driven BOM mapping. The attribute-driven BOM mapping is to use the semantic model as the attribute of the BOM model to drive the simulation operation, that is, the semantic model is mapped as the attribute of the BOM model, and the semantic value corresponding to the semantic model changes when the information content changes, driving the BOM model attribute value to be modified, and triggering the simulation system operation through the RTI publication reservation mechanism.

[0169] Action-driven BOM mapping is an action-driven simulation model in which the semantic model serves as the interaction mode of the BOM model. That is, the command information content can be decomposed into an entity semantic model and a behavioral semantic model. The decomposed behavioral semantic models, such as maneuvering and shooting, are used as actions to drive the interaction mode of the BOM model. Such actions trigger the movement of the BOM state machine, thereby promoting the operation of the simulation system.

[0170] The key point of semantic model mapping is to map and transform the semantic model to the instantiation simulation model BOM as BML in HLA simulation modeling. The command information system decomposes the command information into BML semantic models in XML format through syntax analysis. These semantic models can be mapped and combined into simulation model BOM through the above two methods to generate interactive information and trigger the operation of the simulation system, such as Figure 5 As shown, on this basis, the present invention compares and analyzes the implementation methods of these two methods, so as to form a mapping transformation rule set between the semantic model and the simulation model.

[0171] S4: Ontology model generation: refers to the use of BOM technology for HLA-based virtual force simulation, forming a "five-step" ontology model construction method, and using Protégé as an ontology construction tool, focusing on the construction of combat action ontology models, targeting entity elements and task state transitions, and verifying ontology-based semantic reasoning and validity verification.

[0172] In step S4, the ontology model is generated by using Protégé as a tool to assist in generating the ontology and performing reasoning, and the following five steps are used to construct the domain ontology, determine the scope of the ontology, obtain domain knowledge, define concept classes and attributes, create an ontology instance, verify the ontology and analyze.

[0173] like Figure 6 As shown, in step S4, the five-step method for ontology model generation includes the following steps:

[0174] Step S41: Determine the scope of the ontology: First, it is necessary to clarify the ontology according to the research tasks and purposes, clarify the scope of the ontology, its purpose and the target user objects, and determine the content and scope of the ontology construction;

[0175] Step S42: Obtain knowledge definition and perform knowledge reuse: List the important terms of interest in the field, define concepts, attributes and the relationships between them within the field, and then perform knowledge reuse;

[0176] Step S43: define concept classes and attributes: ontology classes are abstracted from objectively existing objects;

[0177] Define the attributes and relationships of the class. The relationship has the "intrinsic attributes" of the concept itself and the "extrinsic attributes" of external interaction. In these steps, the attribute value type and value range of the attribute should be defined;

[0178] Step S44: ontology instance creation: construct an ontology instance using a formal language or modeling tool, determine which class the instance belongs to, create an instance under the class and assign values ​​to its attributes.

[0179] Step S45: Ontology verification and analysis: Use modeling tools or ontology reasoning language to verify and analyze the constructed ontology model.

[0180] Action is the core element of the task space and the most basic element abstracted from the task process. In step S4, the combat action ontology model is constructed by focusing on the ontology definition of entity elements and the knowledge description of action state transition, which adopts the following five-step method:

[0181] S46: Determine the scope of the entity: Actions are divided into offensive, defensive, and support actions; offensive is "active attack on the enemy", the main feature of which is that the entity moves toward the enemy or conducts fire strikes. Offensive actions are further classified into many categories, such as attack, maneuver, etc. Defense refers to "fighting against the enemy's attack", which is divided into active defense, passive defense, etc.

[0182] S47: Obtain knowledge definition: Based on the concept of action, obtain the accurate definition of the action; for example, there are many description concepts about maneuvering actions in the offensive category, such as troop mobility is subdivided into action styles such as encirclement, follow-up, alternating advance, pursuit, infiltration, interspersed, and transfer. Define related concepts, such as follow-up is the action of following the front troops or personnel behind or to the side and rear, keeping a certain distance as required; detour, a combat action to go around the enemy's flank or rear. Due to limited space, I will not give examples of concept definitions one by one here.

[0183] S48: Define concept classes and attributes: Define various relationships between combat operations, such as inclusion, parallel, and synonymous relationships; combat operation attribute structure elements include combat operation type, command type code, order issuer, order executor, execution time, task completion time, geographical coordinates, route coordinates, methods and approaches.

[0184] For example, penetration and detour are included in the maneuver category and belong to the sub-concepts of maneuver category actions, which is an inclusion relationship; penetration and detour are different forms of maneuver and belong to parallel; strong attack and strong attack are synonymous, strong attack is to concentrate superior forces to forcibly attack the defending enemy, and strong attack is the action of forcibly attacking, the two have a synonymous relationship. The relationships between concepts are interrelated to form complex relationships. For example, pursuit is a sub-concept of the maneuver category of combat actions, and it is also a sub-concept of the attack category.

[0185] S49: Creation of ontology instance: Using Protégé software, add subclasses "offense class", "defense class", and "guarantee class" through the Class hierarchy of Classes; offense class, defense class, and guarantee class are the first-generation subclasses of combat operations, and the three are in a parallel brother relationship. The attack class, maneuver class, and reconnaissance class under the offense class are the second-generation subclasses of combat operations. Under the attack class are the third-generation subclasses of combat operations, including pursuit, encirclement, encirclement, attack, and raid, which are in a parallel relationship. Under the raid action, there are subclasses of ambush, sneak attack, quick attack, surprise attack, sabotage, rush, and harassment.

[0186] There are several subcategories under the maneuver category, including pursuit, encirclement, alternating advance, detour, follow-up, encirclement, etc. Among them, pursuit, encirclement, and encirclement are also offensive in nature, and infiltration is reconnaissance in nature. Therefore, pursuit, encirclement, and encirclement are also subcategories of the attack category, and infiltration is also a subcategory of reconnaissance. There are five different forms of subcategories of pursuit actions under pursuit, namely fire pursuit, tracking pursuit, vertical pursuit, force pursuit, and parallel pursuit. These five actions, like their parent category pursuit, also belong to both the maneuver category and the attack category.

[0187] S410: Ontology verification and reasoning analysis: Use the tool to input various types and examples, and the software automatically generates tree-like relationship diagrams, hierarchical structures and visual representations; through reasoning on the generated ontology and expert manual analysis, the relationship between various combat actions is tested to ensure the correctness of the established ontology; by defining "offense"

[0188] As well as concepts such as "defense", the constructed ontology is subjected to TBox reasoning using the reasoning engine FaCT++, and the concept hierarchy after reasoning can be obtained.

[0189] Through analysis, the result of ontology reasoning is completely in line with expectations. By taking similar actions, various combat tasks can be defined, including specific tasks and abstract tasks, and the relationship and hierarchy between these tasks can be reasoned.

[0190] System business process description:

[0191] The present invention realizes the interoperability between the command information system and the support simulation system by constructing an interoperability model based on BML and using the HLA platform. Figure 1 As shown: it can process two data types: command information generated by the command information system and command code generated by the support simulation system. The operations of the two models are inverse to each other.

[0192] The command information generated by the command information system is imported into the command and control information interoperability model through the model input interface. The grammatical analysis module processes the command information according to the grammatical rules and converts the "free text" into the basic module of the data model in the semantic model set, namely, the "meta-word". Combined with the interpretation of the meta-word in the semantic model set, the semantic analysis module maps the "meta-word" into the semantic model. According to the mapping relationship of the semantic model, the BOM processing module maps the generated semantic model into the BOM model. The FOM processing module encapsulates the BOM to form a FOM interaction model that conforms to the HLA specification, and integrates the subscription and publication functions in the federation to issue instructions to the support simulation system.

[0193] The report information generated by the support simulation system sends the federation metadata to the FOM processing module through the subscription and publication function modules in the federation; the FOM processing module splits the report information into BOM models; based on the model mapping relationship, the BOM processing module generates semantics; then generates "meta-phrases" based on the semantic model set, and finally the syntax analysis module combines multiple "meta-phrases" to generate instruction information that conforms to the BML specification, that is, natural language.

[0194] The command and control information interoperability model framework system of the present invention is complete and universal, and can be used in the development of various simulation systems. It forms a complete set of interoperability model modeling methods from conceptual models to simulation models, which can be used to solve the interoperability problems between other command and control systems and simulation systems. Based on the use of the HLA framework, the model inherits the advantage of the framework that it can adapt to the evolving new technologies and can meet the simulation needs of complex large systems.

[0195] Ontology-based semantic reasoning and verification examples

[0196] The ontology language supports semantic definition and also has semantic logical reasoning capabilities. The present invention uses the OWL generated by Protégé and the underlying XML to verify the correctness and validity. Figure 7 The experiment is shown as an example.

[0197] 1) Build a team ontology model

[0198] Assume that the classes, instances and connections of a squad ontology model form a complex network concept structure. For example, a platoon is composed of three tanks and one combat vehicle, and must perform three combat tasks: advance, deploy into a front triangle formation, and assault the blue side infantry.

[0199] In order to quantitatively describe the formation of the squad, taking this platoon as an example, common formations include front triangle formation, rear triangle formation, etc.

[0200] 2) Experimental design of ontology semantic reasoning

[0201] When verifying ontology semantic reasoning, we took maneuvering as an example for experiment. The case setting is that a row of our physical action simulation system (physical action simulation system) received a maneuver order from the superior (command seat of the command information system): "At T, we will move from the starting point to the W position in a marching formation, deploy into a front triangle battle formation, and then assault the enemy infantry force 2,000 meters in front of the W position, with the support force being the right infantry row (physical action simulation system)."

[0202] Obviously, to correctly execute the mobile combat order, the squad's physical action simulation system must "understand" the following things: first, in terms of sequence, it needs to execute the following sequence of actions, namely "march--deploy--assault"; second, it needs to know that it is equipped with (and only has) 3 tanks; third, it needs to understand the meaning of the front triangle formation and how to change from the marching formation to the front triangle formation; finally, in terms of support relations, the first row of infantry is the right-hand support unit of the unit.

[0203] 3) Reasoning and verification of task sequence

[0204] First, set the execution unit and combat mission, define the random attribute as "execution unit", set the execution unit of a combat mission as the tank platoon; by adding this object attribute, describe the combat mission for the tank platoon, and add three tasks: "expand into a front triangle formation; advance to the W position; assault the "blue infantry". Secondly, define the object attribute "predecessor task" definition to describe the predecessor task of a combat mission undertaken by the tank platoon, and the object attribute has a transitive relationship. Then, describe the sequence between combat missions, that is, advance to the W position first, then expand into a front triangle formation; first expand into a front triangle formation, and then launch an assault on the blue infantry support point. Then, run the ontology reasoning and conclude that advancing to the W position is also a predecessor task to launch an assault on the blue infantry. The sequence between combat missions shows that the setting result of the predecessor task is completely in line with expectations.

[0205] 4) Reasoning and verification of equipment allocation

[0206] First, define the object attribute "equipment allocation" to describe the equipment allocated to a combat unit. Assume that a tank platoon can only be allocated with tanks. Create an instance of the tank platoon "Tank Platoon 1", create 3 instances of tanks and an instance of infantry fighting vehicles, and allocate 3 tanks and 1 combat vehicle to the instance "Tank Platoon 1", which is the equipment allocation relationship of "Tank Platoon 1". Define the relationship between tanks and infantry fighting vehicles as mutually exclusive in advance. In this way, when running reasoning, the inconsistency in the ontology model can be detected, and the user can also know the reason for the inconsistency in the ontology model.

[0207] 5) Reasoning and verification of battle formations

[0208] Define two formation instances, "Battle Formation 1" and "Battle Formation 2". Run inference to find that instances "Battle Formation 1" and "Battle Formation 2" belong to the front triangle formation and the rear triangle formation respectively.

[0209] By running the inference query, we can also get the result that the instances "battle formation 1" and "battle formation 2" belong to the front triangle formation and the rear triangle formation respectively. It can be seen that the results are consistent.

[0210] 6) Reasoning and verification of neighbor relationships

[0211] Define the object attribute "Friends" to describe the support relationship between two units. This object attribute has a symmetric relationship. Describe the friendship relationship between the tank platoon and the infantry platoon. Run the inference and find that the left neighbor of the infantry platoon is the tank platoon.

[0212] When the Infantry Platoon 1 receives the interaction from the Tank Platoon 1, since the two platoons have the same shared concept of the attribute "friends" and combat units, the Infantry Platoon 2 is the friend of the Infantry Platoon 1. Based on its attributes, the Tank Platoon 1 can infer that the Infantry Platoon 2 is also the friend of the Tank Platoon 1. The Infantry Platoon 1 passes the semantics contained in it to the Tank Platoon 1 through the ontology.

[0213] In summary, semantic interoperability needs to be based on a clear description of information semantics and a common understanding of information. Ontology is an effective method to solve semantic interoperability. Based on ontology, semantic interoperability of command and control information, system and entity action simulation system requires the establishment of combat action ontology. Although some research has been conducted at home and abroad, there is no unified combat domain ontology construction method, and there is no mature combat domain ontology available. Based on the research on ontology model construction method, a "five-step method" for constructing ontology is proposed, namely, determining scope, acquiring knowledge, defining concept classes and attributes, creating ontology and verifying ontology. The "five-step method" is used to establish combat action ontology. Taking a typical squad ontology as an example, reasoning experiments are conducted on the task order, equipment allocation, combat formation, and friendly relations in the squad to verify the correctness and rationality of semantic reasoning based on ontology.

[0214] The above description of the disclosed embodiments enables one skilled in the art to implement or use the present invention. Various modifications to these embodiments will be apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but rather to the widest scope consistent with the principles and novel features disclosed herein. < / regarding> < / hostility> < / count> < / theme> < / unit-type> < / hostility> < / size> < / agent> < / theme> < / executer> < / agent> < / executer> < / taskee> < / mod> < / certainty> < / where> < / when> < / action> < / affected> < / executer> < / verb> < / rb> < / ob> < / why> < / why> < / why> < / location> < / destination> < / location> < / path> < / path> < / destination> < / path> < / destination> < / route-where> < / locin> < / route-where> < / at-where> < / point-in-time> < / qualifier1>

Claims

1. A method for constructing a BML-based command and control information interoperability model system framework, characterized in that: It includes the following steps: S1: Construction of grammar system and formation of rules: The construction of the grammar system includes language feature analysis, extraction and description of grammatical elements and formal grammar analysis; The formation of the grammar rules refers to designing a data structure, carrying grammar rule information, storing grammar rule analysis results, and providing grammar rule data support for the command and control information interoperability model; S2: Semantic model generation: The main functional modules of the semantic model generation include four parts: ontology analysis, semantic matching, rule base and instantiation, which covers all meta-phrases of command phrases in the command information system. The design of the model content supports the functional implementation of the semantic analysis module in the command information interoperability model; S3: Semantic model mapping: Mapping and transforming the semantic model to the instantiated simulation model BOM as BML in HLA simulation modeling, decomposing the charge information into the BML semantic model in XML format through syntax analysis, and mapping and combining the semantic model into the simulation model BOM to generate interactive information, trigger the simulation system to run, and form a mapping and transformation rule set between the semantic model and the simulation model; S4: Ontology model generation: refers to the use of BOM technology for HLA-based virtual force simulation, forming a "five-step" ontology model construction method, and using Protégé as an ontology construction tool, focusing on the construction of combat action ontology models, targeting entity elements and task state transitions, and verifying ontology-based semantic reasoning and validity verification.

2. The method for constructing a BML-based charge and control information interoperability model system framework according to claim 1, characterized in that: In step S1, the set architecture design of the grammatical rules includes a grammatical type name representing the type of command phrase, a grammatical sentence pattern rule representing the fixed part of the command phrase, a grammatical parameter meaning representing the meaning of each free part of the command phrase, a grammatical type number used for management, and grammatical keywords screened after specific analysis.

3. The method for constructing a BML-based charge and control information interoperability model system framework according to claim 1, characterized in that: In the step S1, the formal syntax analysis adopts the IBNF formal method to structure the BML message, and the accusation information includes three parts: the header, the tail and the body.

4. The method for constructing a BML-based charge and control information interoperability model system framework according to claim 1, characterized in that: In the step S2, the ontology parsing module generates a data table to obtain information for different operations, including conversion, parsing and inheritance of the inference engine of the ontology; It includes the following steps: S21: First, create a database connection and load the database driver class for exception handling; Create a model maker using the database link parameters and create a model; create a file input stream (FileInputStream) to read the ontology description file in the database; close the input stream reader, perform data conversion, store the ontology data in the database, and close the database connection; S22: Get ontology node information, get all classes, including class name and class description type; get all object attributes, including object attribute name, definition domain and value range; get all instances, including instance name and class to which the instance belongs; S23: The node information obtained after the ontology parsing is classified and stored in a data table for use in the operation of data in the semantic matching module.

5. The method for constructing a BML-based charge and control information interoperability model system framework according to claim 1, characterized in that: In step S2, the semantic matching module mainly includes two parts of calculation: semantic similarity and semantic relevance, and its calculation includes the following steps: S24: Calculating semantic similarity means combining the class names and instance names obtained after ontology parsing into concept pairs, and then calculating them. Before calculation, the node names should be extracted and combined into all concept pairs as much as possible. According to their value ranges, for the constructed small ontology, the number of ontology levels is set to 4, and the similarity of two identical nodes is initialized to 1. S25: Calculate the relevance, mainly inferring new relationships based on existing, custom object attribute relationships, and calculating the shortest path length between nodes corresponding to the new relationship, and converting it into the relevance between concepts; S26: Calculate the synthesis value, use the similarity and correlation to calculate the result, and obtain the result; S27: Calculate the semantic matching degree. According to the specific text content, find the corresponding concept in the ontology. Use the calculated composite value to average the composite values ​​between adjacent words in the text to get the semantic matching degree. The semantic matching degree value reflects the quality of the word segmentation of the text content.

6. The method for constructing a BML-based charge and control information interoperability model system framework according to claim 1, characterized in that: In step S2, the establishment of the rule base is mainly used to calculate the semantic relevance and further infer new relationships. The formation of new relationships is mainly used to reason about instances, and the establishment of rules is determined by subjective consciousness.

7. The method for constructing a BML-based charge and control information interoperability model system framework according to claim 1, characterized in that: In the step S3, the semantic models are mapped and combined into a simulation model BOM, using attribute-driven BOM mapping or action-driven BOM mapping.

8. The method for constructing a BML-based charge and control information interoperability model system framework according to claim 1, characterized in that: In step S4, the ontology model is generated by using Protégé as a tool to assist in generating the ontology and performing reasoning, and the following five steps are used to construct the domain ontology, determine the scope of the ontology, obtain domain knowledge, define concept classes and attributes, create an ontology instance, verify the ontology and analyze.

9. The method for constructing a BML-based charge and control information interoperability model system framework according to claim 8, characterized in that: In step S4, the five-step method for ontology model generation includes the following steps: Step S41: Determine the scope of the ontology: First, it is necessary to clarify the ontology according to the research tasks and purposes, clarify the scope of the ontology, its purpose and the target user objects, and determine the content and scope of the ontology construction; Step S42: Obtain knowledge definition and perform knowledge reuse: List the important terms of interest in the field, define concepts, attributes and the relationships between them within the field, and then perform knowledge reuse; Step S43: define concept classes and attributes: ontology classes are abstracted from objectively existing objects; define class attributes and relationships, and relationships have "intrinsic attributes" of the concept itself and "extrinsic attributes" of external interactions; in these steps, the attribute value type and value range of the attribute must be defined; Step S44: ontology instance creation: construct an ontology instance using a formal language or modeling tool, determine which class the instance belongs to, create an instance under the class and assign values ​​to its attributes.

10. Step S45: Ontology verification and analysis: Use modeling tools or ontology reasoning language to verify and analyze the constructed ontology model.

11. The method for constructing a BML-based charge and control information interoperability model system framework according to claim 8, characterized in that: In step S4, the combat action ontology model is constructed by focusing on the ontology definition of entity elements and the knowledge description of action state transition, which adopts the following five-step method: S46: Determine the scope of the entity: actions are divided into offensive, defensive, and support actions; S47: Obtain knowledge definition: Based on the concept of action, obtain the accurate definition of the action; S48: Define concept classes and attributes: Define various relationships between combat operations, such as inclusion, parallel, and synonymous relationships; combat operation attribute structure elements include combat operation type, command type code, order issuer, order executor, execution time, task completion time, geographical coordinates, route coordinates, methods and means; S49: Ontology instance creation: Using Protégé software, add subclasses "offense class", "defense class", and "security class" through the Class hierarchy of Classes; S410: Ontology verification and reasoning analysis: Use the tool to input various categories and instances, and the software automatically generates tree-like relationship diagrams, hierarchical structures and visual representations; through reasoning on the generated ontology and expert manual analysis, the relationship between various combat actions is verified to ensure the correctness of the established ontology; by defining the concepts of "attack" and "defense", the reasoning engine FaCT++ is used to perform TBox reasoning on the constructed ontology to obtain the conceptual hierarchy after reasoning.

Images