A method for converting aircraft models constructed by different modeling methods

Abstract

This application 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 includes: Step S1, constructing a general meta-model for aircraft design and determining the interaction relationships of each node in the general meta-model; Step S2, establishing business meta-models for each task domain and forming a first conversion algorithm with the general meta-model; Step S3, establishing business meta-models for each functional domain and forming a second conversion algorithm with the general meta-model; Step S4, establishing business meta-models for each physical domain and forming a third conversion algorithm with the general meta-model; Step S5, converting different aircraft models according to the first conversion algorithm, the second conversion algorithm, and the third conversion algorithm. This application enables the rapid reuse and transformation of digital model information across business domains in the aircraft innovation and R & D process, ensuring design consistency.

Description

Technical Field

[0001] This application 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. Background Art

[0002] Currently, technologies such as DODAF architecture modeling, SYSML system modeling, and Modelica multi-physics modeling are widely used in the digital R & D of aircraft. During the forward design iteration process, the conversion and iteration of digital models in the above different fields are involved. Most of the existing methods are implemented by integrating heterogeneous software tools and converting data interfaces. However, due to the differences in modeling languages and specifications in each field, the reuse and conversion efficiency of model information across business domains are very low, and it is difficult to ensure the consistency of various digital models. Summary of the Invention

[0003] To solve the above problems, this application provides a method for converting aircraft models constructed by different modeling methods. The modeling methods include DODAF architecture modeling method, SYSML system modeling method, and Modelica multi-physics modeling method. The conversion method includes:

[0004] Step S1: Construct a general meta-model for aircraft design and determine the interaction relationships among the nodes in the general meta-model;

[0005] Step S2: Establish business meta-models for each task domain according to the mapping relationships between the business models constructed by the DODAF architecture modeling method and the general meta-model, and form a first conversion algorithm with the general meta-model;

[0006] Step S3: Establish business meta-models for each functional domain according to the mapping relationships between the business models constructed by the SYSML system modeling method and the general meta-model, and form a second conversion algorithm with the general meta-model;

[0007] Step S4: Establish business meta-models for each physical domain according to the mapping relationships between the business models constructed by the Modelica multi-physics modeling method and the general meta-model, and form a third conversion algorithm with the general meta-model;

[0008] Step S5: Convert different aircraft models according to the first conversion algorithm, the second conversion algorithm, and the third conversion algorithm.

[0009] Preferably, step S1 further includes:

[0010] Step S11: Determine that the general meta-model for aircraft design 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. Behaviors include three second-level nodes: functional characteristics and physical behavior characteristics.

[0011] Step S12: According to the business logic of systems engineering, determine the interaction relationships among the second-level nodes, including: there is a functional allocation interaction relationship between functional requirements and functional objects; there is a functional allocation interaction relationship 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; there is an association relationship between physical objects and physical behavior characteristics.

[0012] Preferably, step S2 further includes:

[0013] Step S21: According to the three first-level nodes of the general meta-model, structurally decompose each business model constructed by the DODAF system modeling method to form three first-level nodes: capability requirements, task activities, and task equipment corresponding to the three first-level nodes of the general meta-model, and construct a task domain business meta-model.

[0014] Step S22: Map the task domain business meta-model to the general meta-model, and use the method of set operation to establish the first conversion algorithm between the task domain business meta-model and the general meta-model.

[0015] Preferably, step S21 further includes:

[0016] Divide the first-level node of capability requirements into three second-level nodes: task objectives, operating conditions, and performance indicators.

[0017] Divide the first-level node of task activities into five second-level nodes: task name, task event, task rule, activity status, and data flow.

[0018] Divide the first-level node of task equipment into three second-level nodes: equipment function, equipment interface, and performance indicators.

[0019] Preferably, step S3 further includes:

[0020] Step S31: According to the three first-level nodes of the general meta-model, structurally decompose each business model constructed by the SYSML system modeling method to form three first-level nodes: system requirements, operating activities, and design objects corresponding to the three first-level nodes of the general meta-model, and construct a functional domain business meta-model.

[0021] Step S32: Map the functional domain business meta-model to the general meta-model, and use the method of set operation to establish the second conversion algorithm between the functional domain business meta-model and the general meta-model.

[0022] Preferably, step S31 further includes:

[0023] Dividing the system requirements of the first-level node into four second-level nodes: requirement specifications, verification methods, verification tasks, and performance indicators;

[0024] Dividing the operation activities of the first-level node into three second-level nodes: events, states, and interfaces;

[0025] Dividing the design objects of the first-level node into three second-level nodes: functional objects, logical objects, and physical objects.

[0026] Preferably, step S4 further includes:

[0027] Step S41: Structurally decompose each business model constructed by the Modelica multi-physics modeling method according to the three first-level nodes of the general meta-model, forming three first-level nodes corresponding to the three first-level nodes of the general meta-model: system requirements, physical architecture, and simulation architecture, and constructing a business meta-model for the physical domain;

[0028] Step S42: Map the business meta-model of the physical domain to the general meta-model, and establish a third conversion algorithm between the business meta-model of the physical domain and the general meta-model by using the method of set operation.

[0029] Preferably, step S41 further includes:

[0030] Dividing the first-level node simulation architecture into five second-level nodes: simulation interfaces, model parameters, simulation models, simulation conditions, and simulation configurations.

[0031] This application uses a unified general meta-model and digital thread rules to standardize the description, underlying connection, and rapid transformation of heterogeneous digital models in the aircraft R & D task domain, functional domain, and physical domain, enabling the rapid reuse and transformation of digital model information across business domains in the aircraft innovation R & D process, and ensuring design consistency. Brief Description of the Drawings

[0032] Figure 1 is a flowchart of a preferred embodiment of the method for converting aircraft models constructed by different modeling methods in this application.

[0033] Figure 2 is this application Figure 1 Schematic diagram of the relationship of the general meta-model of the illustrated embodiment.

[0034] Figure 3 is this application Figure 1 Schematic diagram of the relationship of the business meta-model of the task domain of the illustrated embodiment.

[0035] Figure 4This is the present application Figure 1 Schematic diagram of the relationship of the functional domain business element model in the illustrated embodiment

[0036] Figure 5 This is the present application Figure 1 Schematic diagram of the relationship of the physical domain business element model in the illustrated embodiment Detailed implementation manners

[0037] To make the purpose, technical solutions, and advantages of the implementation of the present application clearer, the technical solutions in the implementation manners of the present application will be described in more detail below with reference to the accompanying drawings in the implementation manners of the present application. In the accompanying drawings, the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The described implementation manners are some but not all of the implementation manners of the present application. The implementation manners described below with reference to the accompanying drawings are exemplary and are intended to explain the present application and should not be construed as limiting the present application. All other implementation manners obtained by those of ordinary skill in the art based on the implementation manners in the present application without creative efforts fall within the scope of protection of the present application. The implementation manners of the present application will be described in detail below with reference to the accompanying drawings

[0038] The present application provides a method for converting aircraft models constructed by different modeling methods. The aircraft models constructed by different modeling methods mainly include business models constructed by the DODAF architecture modeling method, business models constructed by the SYSML system modeling method, and business models constructed by the Modelica multi-physics modeling method, as Figure 1 shown. The conversion method mainly includes

[0039] Step S1: Construct a general aircraft design element model and determine the interaction relationships of each node in the general element model

[0040] Step S2: Establish each task domain business element model according to the mapping relationship between each business model constructed by the DODAF architecture modeling method and the general element model, and form a first conversion algorithm with the general element model

[0041] Step S3: Establish each functional domain business element model according to the mapping relationship between each business model constructed by the SYSML system modeling method and the general element model, and form a second conversion algorithm with the general element model

[0042] Step S4: Establish each physical domain business element model according to the mapping relationship between each business model constructed by the Modelica multi-physics modeling method and the general element model, and form a third conversion algorithm with the general element model

[0043] Step S5. Convert different aircraft models according to the first conversion algorithm, the second conversion algorithm, and the third conversion algorithm.

[0044] To achieve the mutual conversion between these three service models, in step S1 of this application, by analyzing and abstracting the modeling methods and languages in various fields of aircraft design, a general aircraft design meta-model and interaction relationships are established from three dimensions: the requirements perspective, the design perspective, and the behavior analysis perspective. The core objects in the aircraft R & D process are uniformly and standardizedly described using this general meta-model framework, so as to serve as a transition model for the mutual conversion of the above three existing models. Refer to Figure 2 In some optional implementation manners, step S1 further includes:

[0045] Step S11. Determine that the general aircraft design meta-model 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. Behaviors include three second-level nodes: functional characteristics and physical behavior characteristics;

[0046] Step S12. According to the business logic of systems engineering, determine the interaction relationships of each second-level node, including: there is a functional allocation interaction relationship between functional requirements and functional objects; there is a functional allocation interaction relationship 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; there is an association relationship between physical objects and physical behavior characteristics.

[0047] In this embodiment, in combination with the design logics of each business domain, three first-level nodes of requirements, objects, and behaviors are defined at 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 requirement transfer process, the requirement design implementation process, and the requirement verification process, digital threads of requirements and requirements, requirements and objects, requirements and behaviors, and objects and behaviors are respectively established, which respectively represent the inheritance relationship of 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.

[0048] Based on the design of the first-layer nodes, the three first-level nodes of requirements, objects, and behaviors are further subdivided. For the first-level node of requirements, according to the internal attributes of requirements, requirements are further divided into two subcategories: functional requirements and non-functional requirements, which respectively represent requirements related to functions or activities, and requirements not related to functions or activities. The former will form a downward digital thread through functions, that is, there is a functional allocation relationship with subsequent functional objects in Figure 2 ; the latter will form a downward digital thread through logical objects or physical objects, that is, in Figure 2There is a functional allocation relationship with logical objects and physical objects.

[0049] Reference 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. The functional object undertakes external functional requirements. Inside the first-level node of "object", the logical object undertakes the functional object, and the physical object is the ultimate realization of the logical object. Through the gradual transformation of these three objects, the forward design evolution process of the aircraft is reflected.

[0050] At the same time, according to the design evolution process, the first-level node of "behavior" is further divided into two subclasses: functional characteristics and physical behavior characteristics. Among them, functional characteristics represent system characteristics related to functions, and physical behavior characteristics represent system characteristics related to physical implementations such as mechanical, electrical, and hydraulic.

[0051] Finally, according to the business logic of systems engineering, the interaction relationships between the meta-models of each subclass are refined and established, such as Figure 2 shown, to form a digital thread at the node level of the general meta-model.

[0052] After that, in steps S2 - S4, conversion algorithms 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 are constructed in sequence.

[0053] In some alternative embodiments, step S2 further includes:

[0054] Step S21: According to the three first-level nodes of the general meta-model, the business models constructed by the DODAF system modeling method are 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 meta-model, and a task domain business meta-model is constructed;

[0055] Step S22: Map the task domain business meta-model to the general meta-model, and use the method of set operation to establish the first conversion algorithm between the task domain business meta-model and the general meta-model.

[0056] In some alternative embodiments, step S21 further includes:

[0057] The first-level node of capability requirements is divided into three second-level nodes: task objectives, operating conditions, and performance indicators;

[0058] The first-level node of task activities is divided into five second-level nodes: task name, task event, task rule, activity status, and data flow;

[0059] The first-level node of task equipment is divided into three second-level nodes: equipment function, equipment interface, and performance indicators.

[0060] The relationships of the nodes of the task domain business meta-model formed by the above embodiments are as Figure 3 shown.

[0061] First, as shown in Equation (1), the task domain business meta-model is decomposed and characterized using the general meta-model:

[0062] (1)

[0063] In the formula, represents the ability requirement model, represents the task activity scenario model, represents the task equipment architecture model, represents the black box functional characteristic model, represents the white box physical behavior characteristic model; represents the set of functional requirements, represents the set of non-functional requirements, represents the set of requirement relationships, represents the set of relationships between requirements and functional objects, represents the set of relationships between requirements and logical objects; represents the set of black box functional objects, represents the set of relationships between functional objects, represents the set of relationships between functional objects and logical objects, represents the set of relationships between functional objects and functional characteristics; represents the set of logical objects, represents the set of relationships between logical objects and functional objects, represents the set of relationships between logical objects, represents the set of relationships between logical objects and functional characteristics; represents the set of black box functional activities, represents the set of black box sequence diagram objects, represents the set of black box state machine objects; represents the set of black box functional activities, represents the set of white box sequence diagram objects, represents the set of white box state machine objects; For the behavior models generated in both the black box process and the white box process, the superscript X represents the model generated by black box analysis, and Y represents the model generated by white box analysis.

[0064] According to Equation (2), the task ability requirement model is obtained by analyzing the task activity scenario model:

[0065] (2)

[0066] 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 relationships between functions to the relationships between requirements, Represents the mapping from the relationships between functions and behaviors to the relationships between requirements and functions, Represents the mapping from the relationships between functions and logical objects to the relationships between requirements and logical objects.

[0067] As shown in Equation (3), the task equipment architecture model is obtained through the analysis of the task activity scenario model:

[0068] (3)

[0069] In the formula, Represents the mapping from functional objects to logical objects, Represents the mapping from upper-level system tasks and activities to lower-level aircraft top-level functions, Represents the mapping from upper-level system task behaviors to lower-level aircraft equipment behaviors, Represents the mapping from the relationships between task activities to the relationships between system architecture equipment nodes, Represents the mapping from the relationships between task activities and task scenarios to the relationships between task equipment and task scenarios.

[0070] In some alternative embodiments, step S3 further includes:

[0071] Step S31: Structurally decompose each business model constructed by the SYSML system modeling method according to the three first-level nodes of the general meta-model, to form three first-level nodes of system requirements, operation activities, and design objects corresponding to the three first-level nodes of the general meta-model, and construct a business meta-model for the functional domain;

[0072] Step S32: Map the business meta-model of the functional domain to the general meta-model, and establish a second conversion algorithm between the business meta-model of the functional domain and the general meta-model by using the method of set operation.

[0073] In some alternative embodiments, step S31 further includes:

[0074] Divide the first-level node system requirements into four second-level nodes: requirement specifications, verification methods, verification tasks, and performance indicators;

[0075] Divide the first-level node operation activities into three second-level nodes: events, states, and interfaces;

[0076] Divide the first-level node design objects into three second-level nodes: functional objects, logical objects, and physical objects.

[0077] The relationships between the nodes of the functional domain business element model formed by the above embodiments are as follows Figure 4 as shown.

[0078] According to Equation (4) shown below, the functional domain business element model is decomposed and characterized using the general element model:

[0079] (4)

[0080] wherein, represents the requirements model of this product level, represents the use case model, represents the activity diagram model, represents the sequence diagram model, represents the state machine model, represents the behavior model, represents the functional architecture model, represents the logical architecture model, is the set of functional objects, is the set of functional activities, is the set of objects in the timing diagram, is the set of state machine objects.

[0081] Through the analysis from the behavior perspective, according to Equation (5) shown below, the behavior model is obtained based on the functional model analysis:

[0082] (5)

[0083] wherein, represents the set of functions at the top level of this level allocated from the upper-level system, represents the mapping from the top-level function of this level to the activity diagram model of this level, represents the mapping from the top-level function of this level to the sequence diagram model of this level, represents the mapping from the top-level function of this level to the state machine model of this level;

[0084] The above mapping process reveals the process of activity decomposition, internal and external interaction relationship analysis, and internal state transition analysis of the top-level function objects of this level through the scenario-based behavior model analysis method. Through the analysis from the requirements perspective, according to Equation (6) shown below, the requirements model is obtained based on the behavior model analysis:

[0085] (6)

[0086] wherein, represents the mapping from the activity diagram model of this level to the functional requirements, represents the mapping from the sequence diagram model of this level to the non-functional requirements, represents the mapping from the state machine model of this level to the functional requirements and non-functional requirements;

[0087] Based on equations (4), (5), and (6), as shown in equation (7), the mappings from the behavior model to the requirement model and from the behavior model to the function model are further analyzed as follows:

[0088] (7)

[0089] wherein, represents the mapping from the behavior model at this level to the requirement model , represents the mapping from the behavior model at this level to the functional architecture model .

[0090] Through the above analysis from the behavior perspective and the object perspective, it can be obtained that:

[0091] (8)

[0092] wherein, represents the mapping from the functional object to the logical object, represents the mapping from the logical object to the derived requirements generated due to logical design decisions, represents the mapping from the relationships between functional objects to the relationships between logical objects, represents the mapping from the relationships between logical objects to the relationships between the derived requirements generated by logical objects.

[0093] In some alternative embodiments, step S4 further includes:

[0094] Step S41: Structurally decompose each business model constructed by the Modelica multi-physics modeling method according to the three first-level nodes of the general meta-model, to form three first-level nodes of system requirements, physical architecture, and simulation architecture corresponding to the three first-level nodes of the general meta-model, and construct a business meta-model for the physical domain;

[0095] Step S42: Map the business meta-model for the physical domain to the general meta-model, and establish a third conversion algorithm between the business meta-model for the physical domain and the general meta-model by using the method of set operation.

[0096] In some alternative embodiments, step S41 further includes:

[0097] Divide the first-level node of the simulation architecture into five second-level nodes: simulation interface, model parameters, simulation model, simulation conditions, and simulation configuration.

[0098] The relationships between the nodes of the business meta-model for the physical domain formed by the above embodiments are as Figure 5 shown.

[0099] As shown in Equation (9), the physical domain service meta-model is decomposed and characterized by the general meta-model:

[0100] (9)

[0101] In the formula, represents the physical architecture model, represents the physical property models in various fields such as mechanical, electrical, and hydraulic, represents the multi-domain co-simulation model, represents a subset of is the physical object model, is the set of relationships between physical objects, is the 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, is the physical property model.

[0102] Through the analysis from the perspective of requirements and behavior, it can be obtained that the transformation process from the logical object to the physical object design is as shown in Equation (10):

[0103] (10)

[0104] In the formula, represents the mapping from the logical object to the physical object, represents the mapping from the physical object to the physical property, represents the mapping from the relationships between logical objects to the relationships between physical objects, represents the mapping from the physical object to the derived requirements generated by physical design decisions.

[0105] By comprehensively analyzing Equations (9) and (10), the mappings between the logical model and the physical model, between the physical model and the derived requirements model, and between the physical architecture and the co-simulation architecture are obtained:

[0106] (11)

[0107] In the formula, represents the mapping from the logical architecture model to the physical architecture model , represents the mapping from the physical architecture model to the physical architecture derived requirements , Indicates the mapping from the physical architecture model to the co-simulation physical property model so as to realize the design process from the logical architecture to the physical architecture and the multi-domain physical property model.

[0108] Finally, in step S5, according to the conversion requirements, each business model constructed by different modeling methods is first converted into a general meta-model, and then the general meta-model is converted into the required business model.

[0109] As described above, it is only the specific implementation manner 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 those skilled in the art within the technical scope disclosed in the present application should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to 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, converting different aircraft models according to the first conversion algorithm, the second conversion algorithm and the third conversion algorithm; Wherein, 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.

2. The method for converting aircraft models constructed by different modeling methods according to claim 1, 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.

3. The method for converting aircraft models constructed by different modeling methods according to claim 2, 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.

4. 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 using a set operation method.

5. The method for converting aircraft models constructed by different modeling methods according to claim 4, 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 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.

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

7. The method for converting aircraft models constructed by different modeling methods according to claim 6, 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