Method for converting aircraft models constructed by different modeling methods

Abstract

The invention belongs to the technical field of simulation model data processing, and particularly relates to a method for converting aircraft models constructed by different modeling methods. The method comprises the following steps: S1, constructing a general meta-model for aircraft design, and determining an interaction relationship of nodes in the general meta-model; s2, establishing a business meta-model of each task domain, and forming a first conversion algorithm with the general meta-model; s3, establishing business meta-models of the functional domains, and forming a second conversion algorithm with the general meta-model; s4, establishing each physical domain service meta-model, and forming a third conversion algorithm with the general meta-model; and S5, converting different aircraft models according to the first conversion algorithm, the second conversion algorithm and the third conversion algorithm. According to the method, the cross-business-domain digital model information in the innovative research and development process of the aircraft can be quickly reused and converted, and the design consistency is ensured.

Description

Technical Field

[0001] The present application belongs to the technical field of simulation model data processing, and in particular relates to a method for converting aircraft models constructed by different modeling methods. Background Art

[0002] At present, technologies such as DODAF system modeling, SYSML system modeling and Modelica multi-physics modeling are widely used in the digital development of aircraft. In the forward design iteration process, the conversion and iteration of digital models in different fields mentioned above are involved. Most existing methods use heterogeneous software tool integration and data interface conversion to achieve this. However, due to the differences in modeling languages ​​and specifications in various fields, the efficiency of cross-business domain model information reuse and conversion is very low, and the consistency of various digital models is difficult to ensure. Summary of the invention

[0003] In order to solve the above problems, the present application provides a method for converting aircraft models constructed by different modeling methods, wherein the modeling methods include a DODAF system modeling method, a SYSML system modeling method, and a Modelica multi-physics modeling method, and the conversion method includes: Step S1, constructing a general metamodel for aircraft design, and determining the interaction relationship between nodes in the general metamodel; Step S2: Establishing business metamodels of each task domain according to the mapping relationship between each business model constructed by the DODAF system modeling method and the general metamodel, and forming a first conversion algorithm with the general metamodel; Step S3, establishing business metamodels of each functional domain according to the mapping relationship between each business model constructed by the SYSML system modeling method and the general metamodel, and forming a second conversion algorithm with the general metamodel; Step S4, establishing each physical domain business metamodel according to the mapping relationship between each business model constructed by the Modelica multi-physics modeling method and the general metamodel, and forming a third conversion algorithm with the general metamodel; Step S5: convert different aircraft models according to the first conversion algorithm, the second conversion algorithm and the third conversion algorithm.

[0004] Preferably, step S1 further comprises: Step S11, determining that the aircraft design general metamodel includes three first-level nodes: requirements, objects, and behaviors; requirements include two second-level nodes: functional requirements and non-functional requirements; objects include three second-level nodes: functional objects, logical objects, and physical objects; and behaviors include three second-level nodes: functional characteristics and physical behavior characteristics; Step S12, according to the system engineering business logic, determine the interaction relationship of each secondary node, including: there is an interaction relationship of function allocation between functional requirements and functional objects, there is an interaction relationship of function allocation between non-functional requirements and logical objects and physical objects, there is an association relationship between functional objects and functional characteristics, there is an association relationship between logical objects and functional characteristics, and there is an association relationship between physical objects and physical behavior characteristics.

[0005] Preferably, step S2 further comprises: Step S21: According to the three first-level nodes of the general metamodel, each business model constructed by the DODAF system modeling method is structurally decomposed to form three first-level nodes of capability requirements, task activities and task equipment corresponding to the three first-level nodes of the general metamodel, and construct a task domain business metamodel; Step S22: Map the task domain business metamodel to the general metamodel, and establish a first conversion algorithm between the task domain business metamodel and the general metamodel by using a set operation method.

[0006] Preferably, step S21 further comprises: The first-level node capability requirements are divided into three second-level nodes: mission objectives, operating conditions, and performance indicators; Divide the first-level node task activities into five second-level nodes: task name, task event, task rule, activity status and data flow; The first-level node task equipment is divided into three second-level nodes: equipment function, equipment interface and performance index.

[0007] Preferably, step S3 further comprises: Step S31: According to the three first-level nodes of the general metamodel, each business model constructed by the SYSML system modeling method is structurally decomposed to form three first-level nodes of system requirements, operation activities and design objects corresponding to the three first-level nodes of the general metamodel, and construct a functional domain business metamodel; Step S32: Map the functional domain business metamodel to the general metamodel, and establish a second conversion algorithm between the functional domain business metamodel and the general metamodel using a set operation method.

[0008] Preferably, step S31 further comprises: Divide the system requirements of the first-level node into four second-level nodes: requirement specifications, verification methods, verification tasks, and performance indicators; Divide the primary node operation activities into three secondary nodes: event, status and interface; The first-level node design object is divided into three second-level nodes: functional object, logical object and physical object.

[0009] Preferably, step S4 further comprises: Step S41: According to the three first-level nodes of the general metamodel, each business model constructed by the Modelica multi-physics modeling method is structurally decomposed to form three first-level nodes of system requirements, physical architecture and simulation architecture corresponding to the three first-level nodes of the general metamodel, and construct a physical domain business metamodel; Step S42: Map the physical domain business metamodel to the general metamodel, and establish a third conversion algorithm between the physical domain business metamodel and the general metamodel by using a set operation method.

[0010] Preferably, step S41 further comprises: The first-level node simulation architecture is divided into five second-level nodes: simulation interface, model parameters, simulation model, simulation conditions and simulation configuration.

[0011] This application uses a unified general metamodel and digital clue rules to standardize the description, bottom-level connection and rapid transformation of heterogeneous digital models in the aircraft R&D mission domain, functional domain and physical domain, so that the digital model information across business domains in the aircraft innovation and R&D process can be quickly reused and transformed, ensuring the consistency of the design. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 It is a flowchart of a preferred embodiment of the method of the present application for converting aircraft models constructed by different modeling methods.

[0013] Figure 2 This application Figure 1 A schematic diagram of the general metamodel relationships of the illustrated embodiment.

[0014] Figure 3 This application Figure 1 A schematic diagram of the relationship between the task domain business metamodel of the illustrated embodiment.

[0015] Figure 4 This application Figure 1 A schematic diagram of the functional domain business metamodel relationship of the illustrated embodiment.

[0016] Figure 5 This application Figure 1 A schematic diagram of the relationship between the physical domain business metamodel of the illustrated embodiment. DETAILED DESCRIPTION

[0017] In order to make the purpose, technical scheme and advantages of the implementation of this application clearer, the technical scheme in the implementation of this application will be described in more detail in combination with the drawings in the implementation of this application. In the drawings, the same or similar reference numerals throughout represent the same or similar elements or elements with the same or similar functions. The described implementation is a part of the implementation of this application, not all of the implementations. The implementation described below with reference to the drawings is exemplary and is intended to be used to explain this application, and cannot be understood as a limitation on this application. Based on the implementation in this application, all other implementations obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application. The implementation of this application is described in detail below in combination with the drawings.

[0018] The present application provides a method for converting aircraft models constructed by different modeling methods. The aircraft models constructed by different modeling methods here mainly include business models constructed by DODAF system modeling method, business models constructed by SYSML system modeling method, and business models constructed by Modelica multi-physics modeling method, such as Figure 1 As shown, the transformation method mainly includes: Step S1, constructing a general metamodel for aircraft design, and determining the interaction relationship between nodes in the general metamodel; Step S2: Establishing business metamodels of each task domain according to the mapping relationship between each business model constructed by the DODAF system modeling method and the general metamodel, and forming a first conversion algorithm with the general metamodel; Step S3, establishing business metamodels of each functional domain according to the mapping relationship between each business model constructed by the SYSML system modeling method and the general metamodel, and forming a second conversion algorithm with the general metamodel; Step S4, establishing each physical domain business metamodel according to the mapping relationship between each business model constructed by the Modelica multi-physics modeling method and the general metamodel, and forming a third conversion algorithm with the general metamodel; Step S5: convert different aircraft models according to the first conversion algorithm, the second conversion algorithm and the third conversion algorithm.

[0019] In order to realize the mutual conversion between these three business models, in step S1, this application analyzes and abstracts the modeling methods and languages ​​in various fields of aircraft design, establishes a general metamodel and interaction relationship of aircraft design from three dimensions: demand perspective, design perspective and behavior analysis perspective, and uses this general metamodel framework to uniformly and standardizedly describe the core objects of the aircraft development process, thereby serving as a transition model for the mutual conversion of the above three existing models. Figure 2In some optional implementations, step S1 further comprises: Step S11, determining that the aircraft design general metamodel includes three first-level nodes: requirements, objects, and behaviors; requirements include two second-level nodes: functional requirements and non-functional requirements; objects include three second-level nodes: functional objects, logical objects, and physical objects; and behaviors include three second-level nodes: functional characteristics and physical behavior characteristics; Step S12, according to the system engineering business logic, determine the interaction relationship of each secondary node, including: there is an interaction relationship of function allocation between functional requirements and functional objects, there is an interaction relationship of function allocation between non-functional requirements and logical objects and physical objects, there is an association relationship between functional objects and functional characteristics, there is an association relationship between logical objects and functional characteristics, and there is an association relationship between physical objects and physical behavior characteristics.

[0020] In this embodiment, in combination with the design logic of each business domain, three first-level nodes, namely, requirements, objects, and behaviors, are defined in the first layer, which respectively represent the design requirements that the aircraft needs to meet, the design objects of the aircraft, and the characteristics of the aircraft. According to the requirements transmission process, the requirements design implementation process, and the requirements verification process, digital clues between requirements, digital clues between requirements and objects, digital clues between requirements and behaviors, and digital clues between objects and behaviors are established, respectively representing the relationship between multi-level requirements, the relationship between requirements and design objects, the relationship between requirements and behavior verification, and the relationship between design objects and behavior verification.

[0021] Based on the design of the first-level nodes, the three first-level nodes of demand, object and behavior are subdivided. For the first-level node of demand, according to the intrinsic attributes of demand, the demand is further divided into two subcategories: functional demand and non-functional demand, which represent the demand related to the function or activity and the demand not related to the function or activity respectively. The former will form the digital clues transmitted downward through the function, that is, in Figure 2 There is a function allocation relationship with the subsequent functional objects, which will form a digital clue transmitted downward through logical objects or physical objects, that is, in Figure 2 There is a functional allocation relationship between the logical object and the physical object.

[0022] refer to Figure 2 According to the aircraft system engineering design process, the first-level node of object is further divided into three subclasses: functional object, logical object and physical object. Functional object undertakes external functional requirements. Within the first-level node of object, logical object undertakes functional objects, and physical object is the final realization of logical object. Through the gradual transformation of these three objects, the forward design evolution process of aircraft is reflected.

[0023] At the same time, according to the design evolution process, the first-level node of behavior is further divided into two subcategories: functional characteristics and physical behavior characteristics. Functional characteristics represent system characteristics related to functions, while physical behavior characteristics represent system characteristics related to physical implementation such as electromechanical and hydraulic.

[0024] Finally, according to the business logic of system engineering, the interaction relationship between each subclass metamodel is refined and established, such as Figure 2 As shown, the node-level digital clues that form the common meta-model.

[0025] Afterwards, in steps S2 to S4, a conversion algorithm is constructed between the business models constructed by the DODAF system modeling method, the SYSML system modeling method and the Modelica multi-physics modeling method and the general meta-model.

[0026] In some optional implementations, step S2 further includes: Step S21: According to the three first-level nodes of the general metamodel, each business model constructed by the DODAF system modeling method is structurally decomposed to form three first-level nodes of capability requirements, task activities and task equipment corresponding to the three first-level nodes of the general metamodel, and construct a task domain business metamodel; Step S22: Map the task domain business metamodel to the general metamodel, and establish a first conversion algorithm between the task domain business metamodel and the general metamodel by using a set operation method.

[0027] In some optional implementations, step S21 further includes: The first-level node capability requirements are divided into three second-level nodes: mission objectives, operating conditions, and performance indicators; Divide the first-level node task activities into five second-level nodes: task name, task event, task rule, activity status and data flow; The first-level node task equipment is divided into three second-level nodes: equipment function, equipment interface and performance index.

[0028] The node relationships of the task domain business metamodel formed in the above embodiment are as follows: Figure 3 shown.

[0029] First, as shown in formula (1), the task domain business metamodel is decomposed and represented using the general metamodel: (1) In the formula, Represents the capability requirement model, Represents the task activity scenario model, represents the mission equipment architecture model, Represents the black box functional characteristic model, Represents a white-box physical behavior characteristic model; Represents a set of functional requirements, Represents a set of non-functional requirements, represents a set of demand relations, Represents a set of relationships between requirements and functional objects, Represents requirements and a set of logical object relationships; Represents a collection of black box function objects, Represents a set of functional object relationships, Represents a set of relationships between functional objects and logical objects. Represents a set of relationships between functional objects and functional characteristics; Represents a collection of logical objects, Represents a set of relationships between logical objects and functional objects. Represents a set of relationships between logical objects. Represents a set of relationships between logical objects and functional characteristics; represents the set of black box functional activities, Represents a collection of black box timing diagram objects, Represents a collection of black-box state machine objects; represents the set of black box functional activities, Represents a collection of white-box timing diagram objects, Represents a collection of white-box state machine objects. For behavioral models generated in both black-box and white-box processes, the superscript X represents the model generated by black-box analysis, and the superscript Y represents the model generated by white-box analysis.

[0030] According to formula (2), the task capability requirement model is obtained based on the task activity scenario model analysis: (2) In the formula, Represents the mapping from functional objects to functional requirements, Represents the mapping from behavioral objects to non-functional requirements, Represents the mapping from the relationship between functions to the relationship between requirements, Represents the mapping from the relationship between function and behavior to the relationship between requirements and function, Represents the mapping from the relationship between functions and logical objects to the relationship between requirements and logical objects.

[0031] According to formula (3), the task equipment architecture model is obtained based on the task activity scenario model analysis: (3) In the formula, Represents the mapping from functional objects to logical objects, Represents the mapping from the upper-level system mission activities to the lower-level aircraft top-level functions, Represents the mapping from the upper-level system task behavior to the lower-level aircraft equipment behavior. Represents the mapping from the relationship between task activities to the relationship between architecture equipment nodes, Represents the mapping from the relationship between mission activities and mission scenarios to the relationship between mission equipment and mission scenarios.

[0032] In some optional implementations, step S3 further includes: Step S31: According to the three first-level nodes of the general metamodel, each business model constructed by the SYSML system modeling method is structurally decomposed to form three first-level nodes of system requirements, operation activities and design objects corresponding to the three first-level nodes of the general metamodel, and construct a functional domain business metamodel; Step S32: Map the functional domain business metamodel to the general metamodel, and establish a second conversion algorithm between the functional domain business metamodel and the general metamodel using a set operation method.

[0033] In some optional implementations, step S31 further includes: Divide the system requirements of the first-level node into four second-level nodes: requirement specifications, verification methods, verification tasks, and performance indicators; Divide the primary node operation activities into three secondary nodes: event, status and interface; The first-level node design object is divided into three second-level nodes: functional object, logical object and physical object.

[0034] The relationship between the nodes of the functional domain business metamodel formed in the above embodiment is as follows: Figure 4 shown.

[0035] According to formula (4), the functional domain business metamodel is decomposed and represented by the general metamodel: (4) In the formula, Represents the demand model of the product level, Represents the use case model, Represents the activity diagram model, Represents a sequence diagram model, Represents the state machine model, Represents the behavioral model, represents the functional architecture model, Represents the logical architecture model, is a collection of function objects, is a collection of functional activities. is a collection of timing diagram objects. A collection of state machine objects.

[0036] Through the behavioral perspective analysis, according to formula (5), the behavioral model is obtained based on the functional model analysis: (5) In the formula, It represents the top-level function set assigned from the upper-level system. Indicates the mapping of the top-level functions of this level to the activity diagram model of this level. Indicates the mapping of the top-level functions of this level to the sequence diagram model of this level. Indicates the mapping of the top-level functions of this level to the state machine model of this level; The above mapping process reveals the process of decomposing activities, analyzing internal and external interaction relationships, and analyzing internal state transitions of the top-level functional objects at this level through the scenario-based behavior model analysis method. Through the demand perspective analysis, as shown in formula (6), the demand model is obtained based on the behavior model analysis: (6) In the formula, Represents the mapping of the activity diagram model at this level to the functional requirements, Represents the mapping of the sequence diagram model at this level to non-functional requirements, Represents the mapping of the state machine model at this level to functional requirements and non-functional requirements; Based on equations (4), (5) and (6), further analysis is performed to obtain the mapping from the behavior model to the demand model and the mapping from the behavior model to the functional model as shown in equation (7): (7) In the formula, Indicates the behavior model of this level To the demand model The mapping of Indicates the behavior model of this level Functional Architecture Model 's mapping.

[0037] Through the above analysis of behavior perspective and object perspective, we can get: (8) In the formula, Represents the mapping from functional objects to logical objects, Represents a mapping from logical objects to derived requirements resulting from logical design decisions, Represents the mapping from the relationship between functional objects to the relationship between logical objects, Represents the mapping from relationships between logical objects to relationships between derived requirements generated from the logical objects.

[0038] In some optional implementations, step S4 further includes: Step S41: According to the three first-level nodes of the general metamodel, each business model constructed by the Modelica multi-physics modeling method is structurally decomposed to form three first-level nodes of system requirements, physical architecture and simulation architecture corresponding to the three first-level nodes of the general metamodel, and construct a physical domain business metamodel; Step S42: Map the physical domain business metamodel to the general metamodel, and establish a third conversion algorithm between the physical domain business metamodel and the general metamodel by using a set operation method.

[0039] In some optional implementations, step S41 further includes: The first-level node simulation architecture is divided into five second-level nodes: simulation interface, model parameters, simulation model, simulation conditions and simulation configuration.

[0040] The relationship between the nodes of the physical domain business meta-model formed in the above embodiment is as follows: Figure 5 shown.

[0041] According to formula (9), the physical domain business metamodel is decomposed and represented by the general metamodel: (9) In the formula, Represents the physical architecture model, Represents the physical characteristics model of various fields such as electromechanical and hydraulic, represents a multi-domain joint simulation model, express A subset of the simulation configuration will be established later. is the physical object model, is the set of relations between physical objects, is a set of relationships between physical objects and logical objects. is the set of relationships between physical objects and functional objects, is the set of relationships between physical objects and requirements, is the set of relationships between physical objects and functional characteristics, The physical property model.

[0042] Through the analysis from the demand perspective and the behavior perspective, we can get the design transformation process from logical objects to physical objects as shown in formula (10): (10) In the formula, Represents the mapping from logical objects to physical objects, Represents the mapping from physical objects to physical properties, Represents the mapping from the relationship between logical objects to the relationship between physical objects, Represents the mapping from physical objects to derived requirements resulting from physical design decisions.

[0043] By analyzing equations (9) and (10), we can obtain the mapping from the logical model to the physical model, from the physical model to the derived requirement model, and from the physical architecture to the joint simulation architecture: (11) In the formula, Represents the logical architecture model To the physical architecture model The mapping of Represents the physical architecture model Derived requirements from physical architecture The mapping of Represents the physical architecture model To co-simulate the physical property model , thereby realizing the design process from logical architecture to physical architecture and multi-domain physical property models.

[0044] Finally, in step S5, according to the conversion requirements, the business models constructed by different modeling methods are first converted into a common metamodel, and then the common metamodel is converted into the required business model.

[0045] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions that can be easily thought of by a person skilled in the art within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be based on the protection scope of the claims.

Claims

1. A method for converting aircraft models constructed by different modeling methods, wherein the modeling methods include DODAF system modeling method, SYSML system modeling method and Modelica multi-physics modeling method, characterized in that: The conversion method comprises: Step S1, constructing a general metamodel for aircraft design, and determining the interaction relationship between nodes in the general metamodel; Step S2: Establishing business metamodels of each task domain according to the mapping relationship between each business model constructed by the DODAF system modeling method and the general metamodel, and forming a first conversion algorithm with the general metamodel; Step S3, establishing business metamodels of each functional domain according to the mapping relationship between each business model constructed by the SYSML system modeling method and the general metamodel, and forming a second conversion algorithm with the general metamodel; Step S4, establishing each physical domain business metamodel according to the mapping relationship between each business model constructed by the Modelica multi-physics modeling method and the general metamodel, and forming a third conversion algorithm with the general metamodel; Step S5: convert different aircraft models according to the first conversion algorithm, the second conversion algorithm and the third conversion algorithm.

2. The method for converting aircraft models constructed by different modeling methods according to claim 1, characterized in that: Step S1 further comprises: Step S11, determining that the aircraft design general metamodel includes three first-level nodes: requirements, objects, and behaviors; requirements include two second-level nodes: functional requirements and non-functional requirements; objects include three second-level nodes: functional objects, logical objects, and physical objects; and behaviors include three second-level nodes: functional characteristics and physical behavior characteristics; Step S12, according to the system engineering business logic, determine the interaction relationship of each secondary node, including: there is an interaction relationship of function allocation between functional requirements and functional objects, there is an interaction relationship of function allocation between non-functional requirements and logical objects and physical objects, there is an association relationship between functional objects and functional characteristics, there is an association relationship between logical objects and functional characteristics, and there is an association relationship between physical objects and physical behavior characteristics.

3. The method for converting aircraft models constructed by different modeling methods according to claim 2, characterized in that: Step S2 further comprises: Step S21: According to the three first-level nodes of the general metamodel, each business model constructed by the DODAF system modeling method is structurally decomposed to form three first-level nodes of capability requirements, task activities and task equipment corresponding to the three first-level nodes of the general metamodel, and construct a task domain business metamodel; Step S22: Map the task domain business metamodel to the general metamodel, and establish a first conversion algorithm between the task domain business metamodel and the general metamodel by using a set operation method.

4. The method for converting aircraft models constructed by different modeling methods according to claim 3, characterized in that: Step S21 further includes: The first-level node capability requirements are divided into three second-level nodes: mission objectives, operating conditions, and performance indicators; Divide the first-level node task activities into five second-level nodes: task name, task event, task rule, activity status and data flow; The first-level node task equipment is divided into three second-level nodes: equipment function, equipment interface and performance index.

5. The method for converting aircraft models constructed by different modeling methods according to claim 1, characterized in that: Step S3 further comprises: Step S31: According to the three first-level nodes of the general metamodel, each business model constructed by the SYSML system modeling method is structurally decomposed to form three first-level nodes of system requirements, operation activities and design objects corresponding to the three first-level nodes of the general metamodel, and construct a functional domain business metamodel; Step S32: Map the functional domain business metamodel to the general metamodel, and establish a second conversion algorithm between the functional domain business metamodel and the general metamodel by using a set operation method.

6. The method for converting aircraft models constructed by different modeling methods according to claim 5, characterized in that: Step S31 further includes: Divide the system requirements of the first-level node into four second-level nodes: requirement specifications, verification methods, verification tasks, and performance indicators; Divide the first-level node operation activities into three second-level nodes: event, status and interface; The first-level node design object is divided into three second-level nodes: functional object, logical object and physical object.

7. The method for converting aircraft models constructed by different modeling methods according to claim 1, characterized in that: Step S4 further comprises: Step S41: According to the three first-level nodes of the general metamodel, each business model constructed by the Modelica multi-physics modeling method is structurally decomposed to form three first-level nodes of system requirements, physical architecture and simulation architecture corresponding to the three first-level nodes of the general metamodel, and construct a physical domain business metamodel; Step S42: Map the physical domain business metamodel to the general metamodel, and establish a third conversion algorithm between the physical domain business metamodel and the general metamodel by using a set operation method.

8. The method for converting aircraft models constructed by different modeling methods according to claim 7, characterized in that: Step S41 further includes: The first-level node simulation architecture is divided into five second-level nodes: simulation interface, model parameters, simulation model, simulation conditions and simulation configuration.

Images