Aircraft-based equipment system function logic model rapid generation method

Abstract

This invention pertains to the overall design of aircraft equipment systems, specifically a method for rapidly generating functional logic models of aircraft-based equipment systems. By analyzing target scenarios, it defines structured natural language text syntax rules for interconnected logical elements and behavioral rule atomic elements, such as the hierarchical composition of the equipment system, interaction ports, key attributes, and mode transformations. This supports the standardized structured natural language text expression of the system's functional architecture model. Combining the characteristics of aircraft design, it constructs a combined mapping relationship between natural language text descriptions and system architecture models, enabling the direct and rapid conversion of functional logic design elements and models of aircraft equipment systems for target scenarios. This supports model-based optimization of functional logic architecture design. This invention utilizes structured natural language text syntax, a hallmark of the aircraft field, to closely integrate functional logic architecture modeling with classic equipment system design conventions. It is intuitive, concise, and consistent with the characteristics and design process thinking of equipment system design.

Description

Technical Field

[0001] This invention pertains to the overall design of aircraft equipment systems and relates to a method for rapidly generating functional logic models of aircraft equipment systems. Background Technology

[0002] The applications of modern aircraft are constantly expanding, and their capabilities are becoming increasingly diverse and enhanced. Especially in recent years, with the increasing maturity of unmanned aerial vehicles (UAVs), the overall design of aircraft no longer focuses solely on the aircraft platform itself, but must consider a comprehensive equipment system comprised of the aircraft platform, ground-based command and control, maintenance and support, etc., which can be decomposed from top to bottom into multiple levels such as equipment systems, platforms, and subsystems. The design of the interconnected logic and behavioral functions at each level is becoming increasingly complex. Therefore, in the early stages of equipment system design, the ability to conduct thorough and efficient functional logic architecture design analysis and optimization based on top-level requirements will determine the correctness and agility of the system design, and further affect the quality of R&D inputs at each level of the system.

[0003] For many years, the field of aircraft design has relied on traditional document-based design methods, forming domain-specific conventions for system architecture description. These conventions typically depict the functional logic architecture of equipment systems around elements such as system hierarchy, interaction ports, key attributes, pattern transformations, behavioral rules, and behavioral decomposition. However, with the significant increase in functional performance requirements of aircraft equipment systems in recent years, the coupling relationships between their subsystems have become increasingly complex, and internal and external interconnections have surged exponentially. This has made traditional document-based design methods increasingly inadequate for meeting the requirements of functional logic architecture design and analysis for equipment systems.

[0004] The emerging model-based systems engineering (MBSE) approach has brought innovative development space to the design of functional logic architecture for equipment systems. It mainly relies on the standard system modeling language SysML as the mainstream, uses nine views, and combines a model building framework to model the functional logic architecture of the system. It can be used to carry out comprehensive functional logic architecture simulation verification, thereby improving the efficiency of functional logic design for equipment systems.

[0005] However, existing MBSE modeling methods have certain shortcomings in the application of functional logic architecture design for aircraft equipment systems. Firstly, they differ significantly from traditional design conventions: for example, when using general-purpose modeling frameworks such as MagicGrid and Harmony-SE to construct functional logic architecture models for equipment systems, it is often difficult to correspond with the system architecture description conventions specific to the aircraft field, and thus cannot accurately and intuitively reflect the design characteristics of the equipment system. Secondly, the modeling elements are complex: when constructing views based on the SysML modeling language, various characterization operations, such as depicting system interconnection ports and categories through internal block diagrams and clarifying system mode transformation logic and triggering conditions through state machine diagrams, require complex combinations of multiple elements from the modeling language. Furthermore, this often involves the correlation and coupling of modeling elements between different views, resulting in a huge workload for modeling and difficulties in ensuring consistency between different views. These shortcomings limit the agile and accurate generation of functional logic models for equipment systems and their acceptance by designers, making it difficult to promote their application in multi-disciplinary parallel collaborative functional logic analysis and optimization work.

[0006] Therefore, there is an urgent need to develop a rapid generation method for equipment system functional logic models that is based on the unique conventions of the aircraft field, simple and easy-to-understand structured natural language text, and can generate consistent multi-view content through unambiguous mapping. This method can accurately reflect the design characteristics of aircraft, improve the efficiency of designers, and effectively utilize the advantages of MBSE models in the field of simulation verification to improve the design optimization efficiency of equipment system functional logic architecture. Summary of the Invention

[0007] Purpose of the invention This invention aims to propose a method for rapidly generating equipment system functional logic models based on structured text mapping of aircraft design features, in order to improve the efficiency and quality of system functional logic architecture design and lower the threshold for applying the MBSE method in aircraft design.

[0008] Technical solution This invention aims to propose a method for rapidly generating functional logic models of aircraft equipment systems. By analyzing target scenarios, it defines structured natural language text syntax rules for interconnected logical elements and behavioral rule atomic elements, such as hierarchical composition, interaction ports, key attributes, and mode transformation of the equipment system. This supports the standardized expression of the system's functional architecture model in structured natural language text. Combining the characteristics of aircraft design, it constructs a combination mapping relationship between natural language text descriptions and system architecture models, enabling the direct and rapid conversion of functional logic design elements of aircraft equipment systems for target scenarios into models, and supporting the optimization of model-based functional logic architecture design.

[0009] Furthermore, this includes the following steps: Step (1) Describe the cross-linking logic elements of the equipment system based on structured natural language text syntax; Step (2) invokes or customizes the structured natural language text syntax that defines the atomic elements of the behavior rules, and maps them to the model in a combinatorial mapping relationship. Step (3) Based on the behavior decomposition results of the target scenario, describe the behavior functions hierarchically according to the customized structured text; Step (4) Generate the equipment system functional logic architecture model by directly mapping from structured natural language text.

[0010] Furthermore, in step (1), an analysis of the target scenario of the aircraft should be carried out first. Based on the purpose of the operation of the target scenario, and in accordance with the structured natural language text syntax, the hierarchical composition, interaction ports, key attributes, mode transformation and other cross-linking logical elements of the aircraft equipment system involved in the scenario should be clearly defined and described. The external elements of the equipment system involved in the target scenario should also be considered simultaneously.

[0011] Furthermore, in step (2), the behavioral rule elements such as activities and interactions involved in the target scenario of the aircraft should be analyzed. According to the target scenario analysis requirements, the indivisible atomic elements of the behavioral rules, namely atomic behaviors, are determined. If the syntax of all types of atomic behaviors in the scenario has been defined before the analysis, the structured natural language text syntax of the atomic behaviors is directly called, and the corresponding text syntax is called to the combination mapping relationship of the model. If there are atomic behaviors in the scenario that need to be defined temporarily, the structured natural language text syntax of the atomic behaviors can be customized, and the corresponding text syntax can be established to the combination mapping relationship of the model.

[0012] Furthermore, in step (3), the target scenario should be clearly divided and described into multiple hierarchical stages from top to bottom through aircraft behavior decomposition, until it is decomposed to the atomic behaviors defined in step (2).

[0013] Furthermore, in step (4), based on the mapping relationship between structured natural language text and model, a functional logic architecture model of the aircraft equipment system containing module diagrams, internal block diagrams, state machine diagrams, activity diagrams and sequence diagrams described in SysML language should be directly generated from the aircraft equipment system description text, thereby supporting the optimization of model-based functional logic architecture design.

[0014] Further, the sub-step of analyzing the hierarchical composition of the equipment system in step (1) refers to analyzing the entities at each level inside and outside the equipment system for the target scenario. The relevant entities are collectively referred to as "components". The components inside and outside the equipment system are divided into multiple levels from top to bottom. Define a level 0 component "0 full scenario" as the top-level entity of the scenario, and the level numbers of the level 1 components below it are arranged in Arabic numeral order. The level number of a lower-level component is followed by a decimal point after the level number of its parent component, and then the Arabic numerals are added in order. The component level number is directly represented by a combination of numbers and decimal points. The hierarchical composition analysis results should be filled into the structured text "Scene Role" page according to the above structured natural language text syntax and the "component" attribute. The content of the "component" attribute line of the "Scene Role" page can be mapped to the component attribute part of the SysML module diagram. Based on the analysis and description of the hierarchical composition of the equipment system, it is necessary to further analyze the interaction ports of the internal and external components; The analysis of internal and external component interaction ports refers to the analysis of the interaction ports and categories of components at various levels inside and outside the equipment system.

[0015] The hierarchical number of an interactive port is defined as follows: add a decimal point after the serial number of its component, and then add Arabic numerals in sequence. The hierarchical number of the interactive port is prefixed with "P". The hierarchical number of the nth port of the component with hierarchical number 1 is "P1.n".

[0016] Interaction ports are categorized into three main types: information, energy, and matter, with further distinctions made for specific scenarios. Based on the flow of energy, information, and matter through these ports, port directions are defined as "in," "out," and "inout." According to the granularity of the target scenario analysis, if a component Nn interacts with an object component through its interaction port PN.nm, this interaction can be abstracted and simplified to the interaction between its parent component N and the object component. In this case, PN.nm is defined as a non-top-level port, and the parent component N has a port PN.M that acts as a proxy port for PN.nm; otherwise, PN.nm is a top-level port. The interaction port analysis results are filled into the "Scene Role" page of the structured text according to the "port" attribute, following the structured natural language text syntax described above. In the "port" row, top-level ports must clearly identify the top-level port they interface with, while non-top-level ports must clearly identify their proxy ports. The content of the "component" and "port" attribute rows on the "Scene Role" page can be mapped to generate internal block diagrams at each level of SysML. After completing the analysis of the equipment system's hierarchical composition and the interaction ports of internal and external components, further analysis of the key attributes of internal and external components is conducted. The sub-step of analyzing key attributes of internal and external components refers to clarifying and classifying the key value attributes of components at each level within and outside the equipment system. The hierarchical index of a component's value attribute is defined as follows: add a decimal point after its component number, then sequentially add Arabic numerals. The hierarchical index of the value attribute should also be prefixed with "V". For example, the hierarchical index of the nth value attribute of a component with hierarchical index 1 is "V1.n". Value attributes are divided into several categories, including string, real, and int. String value attributes have no unit, while non-string value attributes should specify their unit. An initial value should be defined for each value attribute. The results of the key attribute analysis should be filled into the structured text "Scene Role" page according to the structured natural language text syntax described above, based on the "value" attribute. The content of the "Component" and "Value" attribute rows on the "Scene Role" page can be mapped to supplement the value attribute section of the SysML module diagram. After completing the key attribute analysis of internal and external components, further analysis of the main component pattern transformation is conducted.

[0017] Furthermore, the analysis of the main component mode transformation sub-step in step (1) refers to the division of the functional modes of key components at each level inside and outside the equipment system, and the clarification of the transformation relationship between different functional modes. Components without a clear functional mode or that do not need to be divided can skip this step. The hierarchical sequence number of a component's functional mode is defined as follows: add a decimal point after its component sequence number, and then add Arabic numerals in sequence. The hierarchical sequence number of the value attribute should also be prefixed with "M". The hierarchical sequence number of the nth functional mode of the component with hierarchical sequence number 1 is "M1.n". Corresponding to the mode division, a special value attribute is defined as "mode value". Its hierarchical sequence number is the same as other value attributes except that the prefix is ​​changed to "MV". The default type of mode value is string. Functional modes are divided into three types: "initial", "intermediate", and "termination", which correspond to the modes after the initial state, the intermediate transformation, and the termination state in the SysML state machine diagram, respectively. A functional mode can choose to define the entry execution activity when entering the mode. The default activity is to assign the corresponding mode value to the name of the currently entered functional mode. The pattern segmentation results should be filled into the "Scene Role" page of the structured text according to the above-mentioned structured natural language text syntax, based on the "Pattern" and "Pattern Value" attributes. After completing the pattern segmentation, the conversion logic needs to be further refined.

[0018] If there is a transformation relationship between two functional modes of a component, the trigger signal event for the transformation from the original mode to the target mode should be clearly defined and filled in on the "Mode Transformation Trigger Event" page of the structured text. The content of the "Mode" and "Mode Value" attribute rows on the "Scene Role" page, combined with the content on the "Mode Transformation Trigger Event" page, can be mapped to generate a SysML state machine diagram. After completing the analysis of the mode transformation of the main components, step (1) ends. Further proceed to step (2) to analyze the atomic elements of the behavioral rules in the target scene.

[0019] Furthermore, step (2), the sub-step of determining the atomic elements of the behavioral rules in the target scenario, refers to determining the indivisible atomic behaviors in the target scenario, calling or customizing the structured natural language text syntax that defines the atomic behaviors, and calling or establishing the corresponding text syntax to the model's combination mapping relationship. The basic syntax describing atomic behaviors should include five basic elements: condition, role, port, behavior, and change.

[0020] Based on the five basic elements of atomic behavior mentioned above, the structured text syntax of atomic behavior can be customized or invoked according to the specific behavior content.

[0021] The atomic behavior categories that can be directly invoked include, but are not limited to, "signal atom" behavior, "signal value atom" behavior, "pattern signal atom" behavior, and "pattern value atom" behavior. Customization can also be performed based on specific atomic behavior description requirements. After analyzing the atomic elements of the behavior rules in the target scenario, further invocation or establishment of a syntax-to-model-view combination mapping relationship can be performed.

[0022] The sub-step of calling or establishing the combined mapping relationship between syntax and model view in step (2) refers to forming a mapping relationship to each view of the SysML model based on the multi-type atomic behavior structured text syntax that needs to be called or customized according to the target scenario. The atomic behavior model view generated by the structured text mapping is expressed based on the activity diagram. The port, value attribute, and trigger mode transformation content used involve the cross-linking with the module diagram, state machine diagram, and internal block diagram. Its text mapping relationship should also be constructed in this step. After completing the combined mapping relationship between calling or establishing syntax and model view, step (2) ends, and the process proceeds to step (3) to carry out the internal and external behavior decomposition of the equipment system under the target scenario.

[0023] Further, step (3) involves decomposing the internal and external behaviors of the equipment system within the target scenario, and dividing and describing multiple hierarchical sub-steps. This means that through behavior decomposition, the target scenario is clearly divided and described into multiple hierarchical stages from top to bottom, down to atomic behaviors. The top-level behavior stage of the scenario that does not need to be further aggregated is called the Level 1 stage, which can be hierarchically divided down to atomic behaviors. Each level of stage that can be further decomposed can also be regarded as a collective behavior, which is named "reference" behavior in the "behavior category" column, and only needs to describe the two basic elements of "condition-role" to distinguish it from other indivisible atomic behaviors. The hierarchical sequence number of the Level 1 stage is arranged in Arabic numeral order. The hierarchical sequence number of a lower-level stage is added after the hierarchical sequence number of its parent stage, and then the Arabic numerals are added in sequence. The results of the internal and external behavior decomposition should be filled into the "Activity and Interaction Definition" page of the structured text according to the above structured natural language text syntax and the "reference" behavior category. After completing the internal and external behavior decomposition of the equipment system within the target scenario, the atomic behavior sub-steps under the target scenario are further described.

[0024] Step (3) describes the atomic behavior sub-step in the target scenario. This refers to refining the description of each atomic behavior category in the "Activity and Interaction Definition" page based on the structured natural language text syntax of the atomic behavior already defined in step (2). After completing the description of the atomic behavior in the target scenario, step (3) ends, and the process proceeds to step (4), which involves directly mapping the text to generate the views of the equipment system functional logic architecture model.

[0025] Furthermore, step (4) of directly mapping from text to generate the views of the functional logic architecture model of the equipment system refers to the process of completing the content of the three pages of "Scene Roles", "Mode Conversion Trigger Events" and "Activity and Interaction Definitions" according to the structured natural language text syntax, and then using the text-model mapping relationship described in step (2) or customized to directly and finally map to generate the functional logic architecture model of the aircraft equipment system, which includes module diagrams, internal block diagrams, state machine diagrams, activity diagrams and sequence diagrams.

[0026] Furthermore, the entity in step 1 specifically refers to: the equipment system or its subordinate system, including hardware or software systems.

[0027] Furthermore, the main components in step 1 are specifically those whose behavior or function is of great significance to the equipment system in achieving its phased objectives in the target scenario.

[0028] Furthermore, in the transformation logic of step 1, among the modes that can be triggered for transformation filled in on the "Mode Transformation Trigger Event" page, there is a conditional transformation event by default. That is, when the mode value attribute changes from the original mode to the target mode, mode transformation can also be triggered. The above logic does not need to be filled in the structured text.

[0029] Furthermore, the five basic elements in step 2 are as follows: "Condition" refers to the logical order in which the current atomic behavior follows the preceding behavior, or the subsequent behavior follows the current atomic behavior, including three categories: no special conditions, parallel start, and conditional start; "Role" is divided into primary role and secondary role, and should be called from the "Component" row of the "Scene Component" page; "Port" must specify the port and category used when the primary and secondary roles interact, and should be called from the "Port" row under the corresponding component on the "Scene Component" page; "Behavior" refers to the main content of the current atomic behavior clearly described in natural language. If the atomic behavior involves the transmission of specific signals, it should be called from the "Including Sequence Name" column of the "Mode Conversion Trigger Event" page; "Change" refers to the change in the mode or related value attribute of the secondary role triggered after the current atomic behavior occurs. The mode before and after the change of the secondary role, as well as the value attribute that caused the change, should be called from the "Mode" and "Value" rows of the "Scene Component" page.

[0030] Furthermore, the specific stage in a certain step refers to a set of system behaviors with phased objectives and time spans, formed by dividing the entire life cycle or a part of the usage process of the equipment system or its subordinate systems. From the researcher's perspective, the top-level stage of the entire life cycle of the equipment system, which does not need further aggregation, is called a Level 1 stage; the bottom-level stage, which does not need further subdivision, is called an atomic behavior.

[0031] The beneficial effects of this application are as follows: This invention is based on the structured natural language text syntax that is characteristic of the aircraft field, which closely connects the functional logic architecture modeling with the classic design conventions of equipment systems, making it intuitive, concise and in line with the characteristics of equipment system design and design process thinking. By establishing a structured text-model mapping, the complex elements and operations of existing modeling languages ​​are simplified, significantly reducing the workload of functional logic modeling of equipment systems, effectively ensuring the consistency of different views, and ensuring the completeness and coherence of key design information.

[0032] By constructing an equipment system cross-linking logic analysis framework that includes hierarchical composition, interaction ports, key attributes, and pattern transformation analysis, as well as a behavioral function analysis framework that includes hierarchical decomposition of internal and external behaviors of the equipment system and customization of atomic behaviors, it is convenient to carry out top-down multi-disciplinary collaborative functional logic decomposition and bottom-up complex system model integration and aggregation, which can significantly improve the efficiency of functional logic integration verification of complex mega-systems.

[0033] By customizing the structured natural language text grammar of atomic behaviors and establishing the corresponding text grammar to model composition mapping relationship, professional designers can focus on the functional logic architecture design itself, significantly reduce the modeling work in the design process, and improve the standardization and accuracy of model construction.

[0034] Step (2), the sub-step of determining the atomic elements of the behavioral rules in the target scenario, refers to determining the indivisible atomic behaviors in the target scenario, calling or customizing the structured natural language text syntax that defines the atomic behaviors, and calling or establishing the corresponding text syntax to the model's combination mapping relationship. The basic syntax describing atomic behaviors should include five basic elements: condition, role, port, behavior, and change.

[0035] In summary, compared with other model-based functional logic architecture design methods, the method of this invention is more in line with aircraft design habits, significantly improves modeling efficiency and quality, and has better applicability.

[0036] The method of this invention is applicable to the engineering development and functional logic verification of complex aircraft equipment systems, and can support parallel work by multiple departments and disciplines, significantly improving the design efficiency of aircraft equipment systems.

[0037] The structured text and mapping model of the equipment system functional logic architecture generated by this invention has the characteristics of being clear, complete and consistent. After batch generation, it can effectively build an labeled dataset, which can further support the fine-tuning generation of large language models of equipment system functional logic vertical domain. Attached Figure Description

[0038] Figure 1 Method flowchart; Figure 2 A diagram illustrating the structured natural language text syntax for the scene / role page; Figure 3 Mapping generation module diagram; Figure 4 Mapping generates an internal block diagram illustration (full scene); Figure 5 Mapping to generate an internal block diagram (equipment system); Figure 6 A diagram illustrating the structured natural language text syntax of the mode transition trigger event page; Figure 7 A schematic diagram of the mapping-generated state machine; Figure 8 Schematic diagram of sequence diagram generation by mapping (Level 1); Figure 9 Schematic diagram of sequence diagram generation (level 2); Figure 10 A schematic diagram of the interaction activities between the atoms in the mapping-generated signal; Figure 11 Schematic diagram of the interaction activities between the signal atoms in the mapping generation mode; Figure 12 Schematic diagram of the interaction activities between the signal atoms in the mapping generation mode; Figure 13 Schematic diagram of sequence graph generation by mapping (level 2). Detailed Implementation

[0039] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions in the embodiments of this invention will be described in more detail below. In the examples, the same or similar reference numerals denote the same or similar components or elements having the same or similar functions throughout. The described embodiments are some, but not all, of the embodiments of this invention. The embodiments described below with reference to reference are exemplary and intended to explain this invention, and should not be construed as limiting the invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention. The embodiments of this invention will be described in detail below.

[0040] Figure 1The sub-step (1) of analyzing the hierarchical composition of the equipment system refers to analyzing the entities at each level inside and outside the equipment system for the target scene. These entities are collectively referred to as "components" in this method. Components inside and outside the equipment system can usually be divided into multiple levels from top to bottom. In this method, a level 0 component "0 Full Scene" is defined as the top-level entity of the scene, and the level 1 components below it are numbered sequentially using Arabic numerals. A decimal point is added after the level number of a lower-level component, and then Arabic numerals are added sequentially. Component level numbers are directly represented by a combination of numbers and decimal points without a prefix. The results of the hierarchical composition analysis should be filled into the structured text "Scene Role" page according to the "component" attribute, following the structured natural language text syntax described above. Figure 2 As shown. The content of the "Component" attribute row on the "Scene Roles" page can be mapped to generate a SysML module diagram (component attribute section), such as... Figure 3 As shown.

[0041] Figure 1 The sub-step of analyzing the interaction ports of internal and external components in step (1) refers to analyzing the interaction ports and categories of components at various levels inside and outside the equipment system. In this method, the hierarchical number of an interaction port is defined as follows: add a decimal point after the serial number of its component, and then add Arabic numerals in sequence. The hierarchical number of the interaction port should also be prefixed with "P". For example, the hierarchical number of the nth port of the component with hierarchical number 1 is "P1.n". Interaction ports can be divided into three types: information, energy, and matter, and their sub-categories can be clearly defined for specific scenarios. Based on the entry and exit of energy, information, and matter flow through the port, the port direction can be defined as three types: "in", "out", and "inout". According to the analysis granularity of the target scenario, if a component Nn interacts with an object component through its interaction port PN.nm, it can be abstracted and simplified to the interaction between its parent component N and the object component. Then, PN.nm is defined as a non-top-level port, and the parent component N has a port PN.M that is a proxy port of PN.nm; otherwise, PN.nm is a top-level port. The results of the interaction port analysis should be entered into the "Scene Role" page of the structured text according to the "Port" attribute, following the structured natural language text syntax described above. Figure 2 As shown. In the "Port" row, the top-level port needs to specify the top-level port it interfaces with, while non-top-level ports need to specify their proxy ports. The content of the "Components" and "Ports" attribute rows on the "Scene Roles" page can be mapped to generate internal block diagrams of various SysML levels, such as... Figure 4 , Figure 5 As shown.

[0042] Figure 1The sub-step (1) of analyzing the key attributes of internal and external components refers to clarifying and classifying the key value attributes of components at each level inside and outside the equipment system. In this method, the hierarchical number of the value attribute of a component is defined as follows: add a decimal point after the component number to which it belongs, and then add Arabic numerals in sequence. The hierarchical number of the value attribute should also be prefixed with "V", such as the hierarchical number of the nth value attribute of the component with hierarchical number 1 is "V1.n". Value attributes can be divided into several categories, such as string, real, and int. Among them, string value attributes have no unit (represented by "status"), and non-string value attributes should also specify their unit. The initial value of a value attribute should also be defined. The results of the key attribute analysis should be filled into the structured text "Scene Role" page according to the above structured natural language text syntax, according to the "value" attribute, such as Figure 2 As shown. The content of the "Component" and "Value" attribute rows on the "Scene Roles" page can be mapped to supplement the value attribute section of the SysML module diagram, such as... Figure 3 As shown.

[0043] Figure 1 The analysis of the main component mode transformation sub-step in step (1) refers to the division of the functional modes of key components at various levels inside and outside the equipment system, and the clarification of the transformation relationship between different functional modes. Components without a clear functional mode or that do not need to be divided can skip this step. In this method, the hierarchical sequence number of a component's functional mode is defined as follows: add a decimal point after its component sequence number, and then add Arabic numerals in sequence. The hierarchical sequence number of the value attribute should also be prefixed with "M". For example, the hierarchical sequence number of the nth functional mode of the component with hierarchical sequence number 1 is "M1.n". Corresponding to the mode division, a special value attribute is defined as "mode value". Its hierarchical sequence number is the same as other value attributes except that the prefix is ​​changed to "MV". The default type of mode value is string. Functional modes can be divided into three types: "initial", "intermediate", and "termination", which correspond to the modes after the initial state, the intermediate transformation, and the termination state in the SysML state machine diagram, respectively. A functional mode can also choose to define the entry execution activity when entering the mode. This activity defaults to assigning the corresponding mode value to the name of the currently entered functional mode. The pattern segmentation results should be entered into the "Scene Roles" page of the structured text according to the above-mentioned structured natural language text syntax, based on the "Pattern" and "Pattern Value" attributes. Figure 2 As shown.

[0044] After completing the pattern division, the conversion logic needs further refinement. In this method, if there is a conversion relationship between two functional patterns of a component, the trigger signal event for the conversion from the original pattern to the target pattern should be clearly defined and filled in on the "Pattern Conversion Trigger Event" page of the structured text. It should be noted that between the patterns that can trigger conversion filled in on the "Pattern Conversion Trigger Event" page, a conditional conversion event is implicitly present. That is, when the pattern value attribute changes from the original pattern to the target pattern, the pattern conversion can also be triggered. The above logic does not need to be filled in on the structured text. The content of the "Pattern" and "Pattern Value" attribute rows on the "Scene Role" page, combined with the content on the "Pattern Conversion Trigger Event" page, can be mapped to generate a SysML state machine diagram, such as... Figure 7 As shown.

[0045] Figure 1 The sub-step (2) of determining the atomic elements of the behavior rules in the target scenario refers to determining the indivisible atomic behaviors in the target scenario, calling or customizing the structured natural language text syntax that defines the atomic behaviors, and calling or establishing the corresponding text syntax to the model's combination mapping relationship. In this method, the basic syntax describing atomic behaviors should include five basic contents: condition, role, port, behavior, and change. "Condition" refers to the logical order relationship in which the current atomic behavior inherits the previous behavior or the subsequent behavior continues the current atomic behavior. It includes three categories: no special conditions (executed in a separate order), parallel start (executed in the same sequence as other behaviors), and condition start (executed according to the content situation determined by the conditions). "Role" is divided into primary role (i.e., the sender of signals and behaviors) and secondary role (i.e., the receiver of signals and behaviors), which should be called from the "Components" row of the "Scene Components" page. "Port" "It is necessary to clearly define the ports and categories used when the main and secondary roles interact, which should be called from the "Ports" row under the corresponding component on the "Scene Components" page; "Behavior" refers to the main content of the current atomic behavior clearly described in natural language. If the atomic behavior involves the transmission of specific signals, it should be called from the "Including Sequence Name" column on the "Mode Conversion Trigger Event" page; "Change" refers to the change in the mode or related value attribute of the secondary role triggered after the current atomic behavior occurs. The mode before and after the change of the secondary role, as well as the value attribute that caused the change, should be called from the "Mode" and "Value" rows on the "Scene Components" page."

[0046] Based on the five basic elements of atomic behavior described above, the structured text syntax of atomic behaviors can be customized or invoked according to the specific behavior content. The atomic behavior categories that can be directly invoked in this method include, but are not limited to, "signal atom" behavior (simply describing signal transmission without depicting secondary role pattern or value transformation), "signal value atom" behavior (signal triggers secondary role value attribute transformation), "pattern signal atom" behavior (secondary role pattern transformation triggered by a specific signal), and "pattern value atom" behavior (secondary role pattern transformation triggered by a change in pattern value attribute), etc. When using this method, it is also possible to perform customized extensions based on specific atomic behavior description requirements.

[0047] Figure 1 The sub-step of calling or establishing the combination mapping relationship between the syntax and the model view in step (2) refers to the multi-type atomic behavior structured text syntax that needs to be called or customized according to the target scenario, forming a mapping relationship to each view of the SysML model. Figure 8 , Figure 9 , Figure 10 Examples of mapping relationships from structured text to SysML model views for "signal atom" behavior, "pattern signal atom" behavior, and "signal value atom" behavior are presented respectively. The atomic behavior model view generated by the structured text mapping is expressed based on an activity diagram. The port, value attribute, trigger mode transformation, and other content used involve the cross-linking with the module diagram, state machine diagram, and internal block diagram. The text mapping relationship should also be constructed in this step.

[0048] Figure 1 The middle step (3) involves decomposing the internal and external behaviors of the equipment system within the target scenario, and dividing and describing multiple hierarchical stages. This refers to clearly dividing and describing the target scenario into multiple hierarchical stages (behaviors) from top to bottom, down to atomic behaviors, through behavior decomposition. For example... Figure 11 As shown, in this method, the top-level behavior stage of the scene that does not require further aggregation is called a Level 1 stage (behavior), which can be hierarchically divided into atomic behaviors. Each level of stage that can be further decomposed can also be considered a collective behavior, named "Reference" behavior in the "Behavior Category" column, and only needs to characterize the two basic elements of "Condition-Role" to distinguish it from other indivisible atomic behaviors. The hierarchical sequence number of the Level 1 stage (behavior) is arranged in Arabic numeral order. The hierarchical sequence number of a lower-level stage (behavior) is appended with a decimal point after the hierarchical sequence number of its parent stage (behavior), and then arranged in order with Arabic numerals. The results of internal and external behavior decomposition should be filled into the "Activity and Interaction Definition" page of the structured text according to the above-mentioned structured natural language text syntax, categorized as "Reference" behavior.

[0049] Figure 1The sub-step describing atomic behavior in the target scenario in step (3) refers to the description of each atomic behavior category in the "Activity and Interaction Definition" page, based on the atomic behavior structured natural language text syntax defined in step (2).

[0050] like Figure 12 , Figure 13 As shown, step 3, "Activity and Interaction Definition," allows the content of the page to be mapped to generate SysML sequence diagrams at various levels. The atomic behaviors within the sequence diagrams can be linked to... Figure 8 , Figure 9 , Figure 10 A schematic diagram of atomic behavior.

[0051] Figure 1 Step (4): Directly map from text to generate the views of the functional logic architecture model of the equipment system. This means that after completing the content of the three pages of "Scene Roles", "Mode Transition Trigger Events" and "Activity and Interaction Definitions" according to the structured natural language text syntax described above, the text-model mapping relationship described above or customized is used to directly map and finally generate the functional logic architecture model of the aircraft equipment system, which includes module diagrams, internal block diagrams, state machine diagrams, activity diagrams and sequence diagrams.

[0052] The following description, in conjunction with specific embodiments, provides further details.

[0053] In this embodiment, we will analyze and construct a functional logic architecture model of an equipment system consisting of a drone and a ground station, targeting a scenario in which a manned-drone drone will cooperate to perform a certain task.

[0054] pass Figure 1 Step (1) analyzes the hierarchical composition of the equipment system. Based on structured text analysis, it describes the hierarchical relationship between the level 1 components "1 Equipment System" and "2 Manned Aircraft," and the level 2 sub-components of "1 Equipment System," "1.1 Unmanned Aerial Vehicle" and "1.2 Ground Station." The analysis results are then presented in... Figure 2 Fill in the information in the "Component" attribute row on the "Scene Role" page.

[0055] pass Figure 1The sub-step of the internal and external component interaction port in step (1) first describes the port interaction between the level 2 sub-components "1.1 UAV" and "1.2 Ground Station" of "1 Equipment System" based on structured text analysis. This interaction occurs through the ports "P1.1.1 UAV-Ground Station Communication Interface (UAV)" and "P1.2.1 UAV-Ground Station Communication Interface (Ground Station)". Secondly, the analysis describes the port interaction between "1.1 UAV" and "2 Manned Aircraft" through the ports "P1.1.2 UAV-Manned Aircraft Communication Interface (UAV)" and "P2.1 UAV-Manned Aircraft Communication Interface (Manned Aircraft)". In this case, "P1.1.2 UAV-Manned Aircraft Communication Interface (UAV)" is proxied at the "1 Equipment System" level by "P1.1 UAV-Manned Aircraft Communication Interface Proxy (Equipment System)". The above analysis results are presented in... Figure 2 Fill in the information in the "Port" attribute row on the "Scene Role" page.

[0056] pass Figure 1 Step (1) describes the main component pattern transformation sub-step, and describes key value attributes such as "V1.1.1 UAV" based on structured text analysis, and displays the analysis results in Figure 2 Fill in the information in the "Value" attribute row on the "Scene Role" page.

[0057] pass Figure 1 Step (1) describes the key attributes of internal and external components. First, based on structured text analysis, it describes the functional modes of "1 Equipment System" such as "M1.1 Mode 1" and "1.1 UAV" such as "M1.1.1 Mode 1.1", and characterizes mode values ​​such as "MV1.1 Equipment System Mode" and "MV1.1.1 UAV Mode". The above analysis results are presented in... Figure 2 Fill in the "Mode" and "Mode Value" attribute rows on the "Scene Role" page.

[0058] Secondly, the analysis describes the signal-triggered transformation relationships between the various modes of "1 Equipment System" and "1.1 UAV" that have a transformation relationship. For example, after being triggered by "trig1.1 signal 1", the mode of "1 Equipment System" changes from "M1.1 Mode 1" to "M1.4 Mode 4". The above analysis results are in Figure 6 Please fill in the information on the "Mode Conversion Trigger Event" page.

[0059] pass Figure 1 Step (2) Determine the atomic elements of the behavior rules in the target scenario. Based on the granularity requirements of the target scenario analysis, the atomic behaviors that cannot be further divided when carrying out the description are clarified, including “signal atom” behavior, “pattern signal atom” behavior, “signal value atom” behavior and multiple types, and the structured natural language text syntax of the relevant types of atomic behaviors is called.

[0060] pass Figure 1 Step (2) calls or establishes a sub-step for the combination mapping relationship between syntax and model view. This sub-step calls the structured text mapping relationship between the above atomic behaviors and the model view based on the activity graph. The mapping relationship diagram of the "signal atom" behavior, "pattern signal atom" behavior, and "signal value atom" behavior is shown below. Figure 8 , Figure 9 , Figure 10 As shown.

[0061] pass Figure 1 Step (3) Decompose the internal and external behaviors of the equipment system in the target scenario, divide and describe multiple levels of sub-steps, and according to the structured text syntax, decompose the target scenario into three level 1 stages: "1. UAV goes to the designated location", "2. Manned aircraft and UAV cooperate to perform the task", and "3. Task completed". Fill in the "Reference" category row of the "Activity and Interaction Definition" page of the analysis results.

[0062] pass Figure 1 Step (3) describes the atomic behavior sub-steps in the target scenario and calls... Figure 1 In step (2), the text syntax of the atomic behavior to be called is determined, and the three level 1 stages are further decomposed into multiple atomic behaviors such as "1.1 The ground station sends instructions to the UAV to go to the designated location". The categories of "signal atom", "pattern signal atom", and "signal value atom" on the "Activity and Interaction Definition" page of the analysis results are filled in. The conditional logic of behaviors such as "2.2 The UAV goes forward to perform task A" is also described according to the syntax.

[0063] pass Figure 1 Step (4) involves directly mapping the text to generate the various views of the equipment system functional logic architecture model. Based on the three pages of content—"Scene Roles," "Mode Transition Trigger Events," and "Activity and Interaction Definitions"—completed according to structured natural language text syntax, the final target scene equipment system functional logic architecture model, including module diagrams, internal block diagrams, state machine diagrams, activity diagrams, and sequence diagrams, can be directly mapped and generated. Figure 3 The full-scene module diagram shown Figure 4 The diagram shown represents the internal block diagram of the Level 1 system cross-linking in the entire scenario. Figure 5 The diagram shown represents the internal block diagram of the interconnection of the Level 2 system under the "1 Equipment System". Figure 7 A state machine diagram represented by (taking "1 Equipment System" as an example). Figure 12 The sequence diagram shown represents the first stage. Figure 13 Sequence diagrams representing the second stage, Figures 8-10 Activity diagrams, represented by the 'atom', characterize the behavior of atoms.

[0064] Furthermore, unless otherwise defined, the technical or scientific terms used in this application description shall have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms "upper," "lower," "left," "right," "center," "vertical," "horizontal," "inner," and "outer," etc., used in this application description to indicate relative direction or positional relationship are used only to indicate relative orientation or positional relationship, and do not imply that the device or component must have a specific orientation, or be constructed and operated in a specific orientation. When the absolute position of the described object changes, its relative positional relationship may also change accordingly, and therefore should not be construed as a limitation on this application. The terms "first," "second," "third," and similar terms used in this application description are used only for descriptive purposes to distinguish different components, and should not be construed as indicating or implying relative importance. The terms "a," "one," or "the," etc., used in this application description should not be construed as an absolute limitation on quantity, but should be construed as indicating the existence of at least one. The terms "including," "comprising," etc., used in this application description mean that the element or object preceding the word covers the element or object listed after the word and its equivalents, without excluding other elements or objects.

[0065] Furthermore, it should be noted that, unless otherwise explicitly specified and limited, terms such as “installation,” “connection,” and “linkage” used in the description of this application should be interpreted broadly. For example, a connection can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium; or it can be a connection within two components. Those skilled in the art can understand its specific meaning in this application according to the specific circumstances.

[0066] The above description is merely a specific embodiment of the present invention and is not intended to limit the present invention. Within the spirit and principles of the present invention, any person skilled in the art may use the above-disclosed technical content to make changes or modifications to equivalent embodiments and apply them to other fields. However, any simple modifications, equivalent changes and modifications made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention, as well as any modifications, equivalent substitutions, improvements, etc., should be included within the protection scope of the present invention.

Claims

1. A method for rapidly generating functional logic models of aircraft-based equipment systems, characterized in that, By analyzing the target scenario, we define structured natural language text syntax rules for the hierarchical composition of the equipment system, interaction ports, key attributes, mode transformation and cross-linking logical elements, and behavioral rule atomic elements, supporting the standardized structured natural language text expression of the system functional architecture model. Combining the characteristics of aircraft design, we construct a combination mapping relationship between natural language text description and system architecture model, realizing the direct and rapid conversion of the functional logic design elements of the aircraft equipment system for the target scenario with the model, and supporting the optimization of model-based functional logic architecture design.

2. The method as described in claim 1, characterized in that, Includes the following steps: Step (1) Describe the cross-linking logic elements of the equipment system based on structured natural language text syntax; Step (2) invokes or customizes the structured natural language text syntax that defines the atomic elements of the behavior rules, and maps them to the model in a combinatorial mapping relationship. Step (3) Based on the behavior decomposition results of the target scenario, describe the behavior functions hierarchically according to the customized structured text; Step (4) Generate the equipment system functional logic architecture model by directly mapping from structured natural language text.

3. The method as described in claim 2, characterized in that, in, Step (1) requires first analyzing the target scenario of the aircraft. Based on the operational purpose of the target scenario, and in accordance with the structured natural language text syntax, the hierarchical composition, interaction ports, key attributes, and mode transformation and cross-linking logic elements of the aircraft equipment system involved in the scenario should be clearly defined and described. External elements of the equipment system involved in the target scenario should also be considered simultaneously.

4. The method as described in claim 2, characterized in that, In step (2), the activity and interaction behavior rule elements involved in the target scenario of the aircraft should be analyzed; according to the target scenario analysis requirements, the indivisible behavior rule atomic elements, i.e. atomic behaviors, should be determined. If the syntax of all atomic behavior types in the scenario has been defined before the analysis, the structured natural language text syntax of the atomic behavior should be directly called, and the corresponding text syntax should be called to the combination mapping relationship of the model. If there are atomic behaviors that need to be defined temporarily in the scenario, the structured natural language text syntax of the atomic behaviors can be customized, and the corresponding text syntax can be used to establish a combination mapping relationship with the model.

5. The method as described in claim 2, characterized in that, In step (3), the target scenario should be clearly divided and described into multiple hierarchical stages from top to bottom through aircraft behavior decomposition, until it is decomposed to the atomic behavior defined in step (2).

6. The method as described in claim 2, characterized in that, In step (4), based on the mapping relationship between structured natural language text and model, a functional logic architecture model of the aircraft equipment system containing module diagrams, internal block diagrams, state machine diagrams, activity diagrams and sequence diagrams described in SysML language should be directly generated from the aircraft equipment system description text, thereby supporting the optimization of model-based functional logic architecture design.

7. The method as described in claim 2, characterized in that, Step (1) analyzes the hierarchical composition of the equipment system. The sub-step refers to analyzing the entities that make up each level of the equipment system, both inside and outside the target scenario. The relevant entities are collectively referred to as "components". The components inside and outside the equipment system are divided into multiple levels from top to bottom. A level 0 component "0 full scenario" is defined as the top-level entity of the scenario, and the level numbers of the level 1 components below it are arranged in Arabic numeral order. A lower-level component's hierarchical number is assigned a decimal point after its parent component's hierarchical number, followed by sequentially added Arabic numerals. Component hierarchical numbers are directly represented by a combination of numbers and decimal points. The hierarchical composition analysis results should be filled into the structured text "Scene Role" page according to the above-mentioned structured natural language text syntax, based on the "component" attribute. The content of the "component" attribute row on the "Scene Role" page can be mapped to generate the component attribute section of the SysML module diagram. Based on the analysis and description of the equipment system's hierarchical composition, further analysis of the interaction ports between internal and external components is required. The analysis of internal and external component interaction ports refers to the analysis of the interaction ports and categories of components at various levels inside and outside the equipment system. The hierarchical number of an interactive port is defined as follows: add a decimal point after the serial number of its component, and then add Arabic numerals in sequence. The hierarchical number of the interactive port is prefixed with "P". The hierarchical number of the nth port of the component with hierarchical number 1 is "P1.n". Interaction ports are categorized into three main types: information, energy, and matter, with further distinctions made for specific scenarios. Based on the flow of energy, information, and matter through these ports, port directions are defined as "in," "out," and "inout." According to the granularity of the target scenario analysis, if a component Nn interacts with an object component through its interaction port PN.nm, this interaction can be abstracted and simplified to the interaction between its parent component N and the object component. In this case, PN.nm is defined as a non-top-level port, and the parent component N has a port PN.M that acts as a proxy port for PN.nm; otherwise, PN.nm is the top-level port. The interaction port analysis results are filled into the "Scene Role" page of the structured text according to the "port" attribute, following the structured natural language text syntax described above. In the "port" row, top-level ports must clearly identify the top-level port they interface with, while non-top-level ports must clearly identify their proxy ports. The content of the "Component" and "Port" attribute rows on the "Scene Role" page can be mapped to generate internal block diagrams at each level of SysML. After completing the analysis of the equipment system's hierarchical composition and the interaction ports of internal and external components, the key attributes of the internal and external components are analyzed. The sub-step of analyzing key attributes of internal and external components refers to clarifying and classifying the key value attributes of components at each level within and outside the equipment system. The hierarchical number of a component's value attribute is defined as follows: add a decimal point after its component number, then add Arabic numerals in sequence. The hierarchical number of the value attribute should also be prefixed with "V". The hierarchical number of the nth value attribute of the component with hierarchical number 1 is "V1.n". Value attributes are divided into several categories, including string, real, and int. Among them, string value attributes have no unit, while the unit of non-string value attributes should be specified. An attribute should have an initial value defined. The key attribute analysis results should be filled into the structured text "Scene Role" page according to the above structured natural language text syntax, according to the "value" attribute. The content of the "component" and "value" attribute rows on the "Scene Role" page can be mapped to supplement the value attribute part of the SysML module diagram. After completing the key attribute analysis of internal and external components, further analyze the pattern transformation of the main components. Step (1) analysis of the main component mode transformation sub-step refers to dividing the functional modes of key components at each level inside and outside the equipment system and clarifying the transformation relationship between different functional modes; this step can be skipped for components without a clear functional mode or that do not need to be divided. The hierarchical sequence number of a component's functional mode is defined as follows: add a decimal point after its component number, then add Arabic numerals in sequence. The hierarchical sequence number of value attributes should also be prefixed with "M". The hierarchical sequence number of the nth functional mode of the component with hierarchical sequence number 1 is "M1.n". Corresponding to the mode division, a special value attribute is defined as "mode value". Its hierarchical sequence number is the same as other value attributes except that the prefix is ​​changed to "MV". The default type of mode value is string. Functional modes are divided into three types: "initial", "intermediate", and "terminating", which correspond to the modes after the initial state, the intermediate transition, and the termination state in the SysML state machine diagram, respectively. A certain functional mode can optionally define the entry execution activity when entering the mode. The default activity is to assign the corresponding mode value to the name of the currently entered functional mode. The mode division result should be filled into the structured text "Scene Role" page according to the above structured natural language text syntax, according to the "mode" and "mode value" attributes. After completing the mode division, the conversion logic needs to be further improved. If there is a conversion relationship between two functional modes of a component, the trigger signal event for the conversion from the original mode to the target mode should be clearly defined and filled in on the "Mode Conversion Trigger Event" page of the structured text. The content of the "Mode" and "Mode Value" attribute rows on the "Scene Role" page can be combined with the content of the "Mode Conversion Trigger Event" page to generate a SysML state machine diagram; after completing the mode conversion of the main components, step (1) ends; and then proceed to step (2) to analyze the atomic elements of the behavior rules in the target scene.

8. The method as described in claim 2, characterized in that, Step (2) is the sub-step of determining the atomic elements of the behavior rules in the target scenario. It refers to determining the indivisible atomic behaviors in the target scenario, calling or customizing the structured natural language text syntax that defines the atomic behaviors, and calling or establishing the corresponding text syntax to the model's combination mapping relationship. The basic syntax for describing atomic behavior should include five basic elements: condition, role, port, behavior, and change. Based on the five basic elements of atomic behavior mentioned above, the structured text syntax of atomic behavior can be customized or invoked according to the specific behavior content. The atomic behavior categories that can be directly called include, but are not limited to, "signal atom" behavior, "signal value atom" behavior, "pattern signal atom" behavior, and "pattern value atom" behavior; customized extensions can also be made based on specific atomic behavior description requirements; after completing the analysis of the atomic elements of the behavior rules in the target scenario, the syntax to model view combination mapping relationship can be further called or established; Step (2) is the sub-step of calling or establishing a combination mapping relationship between the syntax and the model view. It refers to the multi-type atomic behavior structured text syntax that needs to be called or customized according to the target scene, forming a mapping relationship to each view of the SysML model. The atomic behavior model view generated by the structured text mapping is expressed based on the activity diagram. The port, value attribute, and trigger mode transformation content used involve the cross-linking with the module diagram, state machine diagram, and internal block diagram. The text mapping relationship should also be constructed in this step. After completing the call or establishing the combination mapping relationship between the syntax and the model view, step (2) ends and the next step (3) is to carry out the internal and external behavior decomposition of the equipment system under the target scenario.

9. The method as described in claim 2, characterized in that, Step (3) involves decomposing the internal and external behaviors of the equipment system in the target scenario and describing multiple hierarchical sub-steps. This means that through behavior decomposition, the target scenario is clearly divided and described into multiple hierarchical stages from top to bottom, down to atomic behaviors. The top-level behavior stage of the scenario that does not need to be further aggregated is called the Level 1 stage, which can be hierarchically divided down to atomic behaviors. Each level of stage that can be further decomposed can also be regarded as a collective behavior, which is named "reference" behavior in the "behavior category" column. It only needs to describe the two basic elements of "condition-role" to distinguish it from other indivisible atomic behaviors. The hierarchical sequence number of the Level 1 stage is arranged in Arabic numeral order. The hierarchical sequence number of a certain lower-level stage is added after the hierarchical sequence number of its parent stage, and then the Arabic numerals are added in order. The internal and external behavior decomposition results should be filled into the "Activity and Interaction Definition" page of the structured text according to the above structured natural language text syntax and the "reference" behavior category. After completing the internal and external behavior decomposition of the equipment system in the target scenario, the atomic behavior sub-steps in the target scenario are further described. Step (3) describes the atomic behavior sub-step under the target scenario. It refers to the description of each atomic behavior category in the "Activity and Interaction Definition" page based on the atomic behavior structured natural language text syntax defined in step (2). After completing the description of the atomic behavior under the target scenario, step (3) ends and the process proceeds to step (4) to generate each view of the equipment system functional logic architecture model by directly mapping from the text.

10. The method as described in claim 2, characterized in that, Step (4) involves directly mapping from text to generate the functional logic architecture model of the equipment system. This means that after completing the content of the three pages of "Scene Roles", "Mode Transition Trigger Events" and "Activity and Interaction Definitions" according to the structured natural language text syntax, the text-model mapping relationship in step (2) or the custom text is used to directly and finally map to generate the functional logic architecture model of the aircraft equipment system, which includes module diagrams, internal block diagrams, state machine diagrams, activity diagrams and sequence diagrams.

Images