RFLP-based unified data source model change automatic identification method

Abstract

The invention discloses an RFLP-based unified data source model change automatic identification method, and belongs to the field of system engineering, and the architecture is mainly composed of two contents of establishment of an RFLP-based unified data source and model change automatic identification. An RFLP unified data source covers a demand analysis model, a functional architecture design model, a logic architecture model and a physical architecture model, different types of data source models are constructed into a unified meta-model, integrated definition and characterization are carried out, and the method comprises three contents of a meta-model definition method, meta-model mapping method research and RFLP unified data source construction technology research. Therefore, a unified model structure tree is established to serve as a unified data source of the whole model change. On the basis that a unified data source is constructed, the model is persistent into an xml file, and model changes are recognized through xml comparison. Therefore, after the model is changed, the model is uploaded to a unified data source and is automatically compared with the original model, so that the automatic identification of the model change is realized.

Description

Technical Field

[0001] The invention relates to the field of system engineering, and in particular to an automatic identification method based on RFLP unified data source model change. Background Art

[0002] With the rapid development of information technology, enterprises and organizations are facing increasing demands for data management and processing. The complexity and diversity of data are constantly increasing. How to effectively manage this data has become an important issue. In the process of enterprise informatization construction, the diversity and heterogeneity of data sources have increased the difficulty of data integration. There may be differences in data models between different systems. When these data models change, how to quickly and accurately identify these changes and synchronize these changes to a unified data source has become an important issue in data management. The RFLP (Requirements-Functional-Logical-Physical) method in MBSE modeling covers requirements analysis, functional architecture design, logical architecture design, physical architecture design, and verification processes such as Figure 1 As shown, it is a process of continuous iteration and repeated verification. Therefore, these four models are constructed into a metamodel and a unified data source is established, which will help the unified management of the model, thereby better supporting the decision-making and operation of the system. The established unified data source only realizes the management of the model, and then the automatic verification of the model is realized through the automatic identification of model changes. This process can significantly improve the efficiency of data model change management, and can also reduce errors caused by human factors, and improve the reliability and stability of the entire data management system. In existing research, only RFLP is used for related modeling, and no unified data source model is established, nor is the automatic identification and verification of model changes realized. Therefore, the present invention is of great significance to meet the development of complex systems and the automatic identification of model changes. Summary of the invention

[0003] In view of the above-mentioned deficiencies in the prior art, the present invention provides a method for automatically identifying changes in a unified data source model based on RFLP.

[0004] In order to achieve the above-mentioned object of the invention, the technical solution adopted by the present invention is:

[0005] A method for automatically identifying changes in RFLP unified data source model includes the following steps:

[0006] S1. Establish RFLP meta-model, including demand model, functional model, logical model and physical model;

[0007] S2, establish a unified model structure tree through the metamodel graph relationship in the RELP metamodel;

[0008] S3. Based on the data source in the established unified model structure tree, automatic identification is performed when changes occur in the data source model.

[0009] Furthermore, the S1 specifically includes the following steps:

[0010] S11, the RFLP-based engine system metamodel is a model that describes the engine system requirement model, function model, logic model, and physical model, and generates the engine system metamodel specification through the attribute set of the requirement model, function model, logic model, and physical model;

[0011] S12, determining the engine system metamodel mapping rule through the metamodel mapping relationship map, and establishing the mapping relationship based on the preset rule;

[0012] S13. Establish an engine system meta-model based on the mapping relationship obtained in step S12.

[0013] Furthermore, the preset rule in S12 is:

[0014] For the metamodel mapping of dependencies, the preset rules are:

[0015] a) It is not allowed to establish dependencies between the requirement metamodel and the functional metamodel, between the requirement metamodel and the logical metamodel, or between the requirement metamodel and the physical metamodel;

[0016] b) There is a dependency relationship between the functional metamodel and the logical metamodel;

[0017] For the metamodel mapping that affects relationships, the preset rules are:

[0018] a) Only the influence relationship from the physical metamodel to the requirement metamodel is allowed, and vice versa;

[0019] b) Establish mutual influence relationships between the requirement metamodel and the functional metamodel, between the functional metamodel and the logical metamodel, and between the logical metamodel and the physical metamodel.

[0020] Furthermore, the engine system metamodel in S13 is expressed as:

[0021]

[0022] Wherein, Φ is the aero-engine design system metamodel, Θ is the engine design system metamodel, HSRS stands for high-speed rotation stability, LLD stands for long life design, ASLET stands for aviation-specific low emission, ANCT stands for aviation noise control, and R stands for reliability.

[0023] Furthermore, the S3 specifically includes the following steps:

[0024] S31, upload the engine metamodel to the unified data source and automatically parse the model at the back end to generate the corresponding metamodel, and persist it as a new version of the XML file;

[0025] S32. Compare the new version of the XML file with the original version of the XML file to automatically identify model changes.

[0026] Furthermore, the automatic identification in S32 includes the following steps:

[0027] A. Set the XML file change elements, including file elements, file sub-elements and file attributes, and determine whether there is a change based on the preset recognition conditions;

[0028] B. Set an element change threshold. If the file change element exceeds the set element change threshold, it is determined that the XML file has changed.

[0029] Furthermore, the identification conditions preset in step A include:

[0030] A1. When new elements or attributes appear in an XML file and these elements or attributes do not exist in the original XML file, they are identified as new changes;

[0031] A2. When some elements or attributes in the original XML file are missing from the XML file, it is identified as a deletion change;

[0032] A3. When the element or attribute value in the XML file changes and is inconsistent with the corresponding element or attribute value in the original XML file, it is identified as a modification.

[0033] The present invention has the following beneficial effects:

[0034] Compared with existing research, this paper proposes a unified data source model based on RFLP, which ensures data consistency and standardization and avoids conflicts and inconsistencies caused by multi-source data. By processing data in a unified format and standard, the quality and availability of data are improved, providing a solid foundation for subsequent analysis and decision-making. Combining the MBSE modeling method RFLP with a unified data source improves design efficiency. Through graphical modeling and universal modeling languages ​​(such as SysML), the RFLP model helps team members reach a consensus and avoid ambiguity and misunderstanding in communication.

[0035] The present invention studies the automatic identification of model changes, improves the efficiency of model management and maintenance, and also enhances the stability and reliability of the model. When the model changes, the model changes can be quickly detected, including parameter adjustments, structural changes, etc. Through corresponding algorithms and data analysis techniques, the automatic identification of model changes can identify the specific changes of the model, including the type, location, and range of the changes, and this process can be automated, greatly reducing the burden of manual detection, reducing the possibility of human errors, shortening the response time, and reducing costs. Therefore, the automatic identification of model changes has significant advantages in timeliness, accuracy, automation and intelligence, improving efficiency and reducing costs, and enhancing model stability and reliability. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Figure 1 Schematic diagram of the RFLP modeling method in MBSE of the present invention.

[0037] Figure 2 Schematic diagram of the RFLP metamodel definition method of the present invention.

[0038] Figure 3 Schematic diagram of the engine system metamodel integrated definition method according to an embodiment of the present invention.

[0039] Figure 4 It is a schematic diagram of XSD definition of simple meta-attribute and array meta-attribute according to an embodiment of the present invention.

[0040] Figure 5 Schematic diagram of programmatic representation of the engine metaclass according to an embodiment of the present invention.

[0041] Figure 6 Schematic diagram of a unified data source construction method according to an embodiment of the present invention. DETAILED DESCRIPTION

[0042] The specific implementation modes of the present invention are described below so that those skilled in the art can understand the present invention. However, it should be clear that the present invention is not limited to the scope of the specific implementation modes. For those of ordinary skill in the art, as long as various changes are within the spirit and scope of the present invention as defined and determined by the attached claims, these changes are obvious, and all inventions and creations utilizing the concept of the present invention are protected.

[0043] This embodiment proposes an automatic identification method based on the change of the unified demand-function-logic-physical data source model, which includes the following steps:

[0044] A method for automatically identifying changes in RFLP unified data source model includes the following steps:

[0045] S1. Establish RFLP meta-model, including demand model, functional model, logical model and physical model;

[0046] This embodiment specifically includes the following steps:

[0047] S11, the RFLP-based engine system metamodel is a model that describes the engine system requirement model, function model, logic model, and physical model, and generates the engine system metamodel specification through the attribute set of the requirement model, function model, logic model, and physical model;

[0048] like Figure 2 As shown. Among them, the RFLP metamodel is a model that describes the complex system requirement model, functional model, logical model and physical model. By combing the attribute sets that describe these models, extracting common attributes, abstracting them into common parent classes, and using the inheritance, polymorphism and other ideas of object-oriented programming, a metamodel specification is proposed that can encapsulate the requirement model, functional model, logical model and physical model into a specific metamodel (such as: engine system metamodel). The metamodel specification uses metaclasses and metaattributes to provide unified encapsulation of different models. Metaattributes are descriptions of individual characteristics of the original model. Metaclasses are sets of metaattributes organized in a hierarchical form using inheritance ideas, such as Figure 3 shown.

[0049] Attribute induction and meta-attribute definition. Attribute induction refers to summarizing the model into the required attribute set, functional attribute set, logical attribute set and physical attribute set of each model according to the four dimensions of demand, function, logic and physics. In the induction process, according to the object-oriented inheritance concept, the common attributes of multiple parts are classified into the attribute set of the parent part. For example, the power system includes the design and development of key subsystems such as the engine, transmission system, and control system. For the design and development of the engine, its required attributes include power, torque, fuel efficiency, emission standards, etc., functional attributes include intake, compression, combustion, etc., logical attributes include the interaction relationship and timing control of each sub-function, and physical attributes include material mode, processing technology, etc. The above attributes are all applicable to the engine system, so they can be classified as the attributes of the engine system. For special models of engine systems, such as the "F-1" engine, it is only necessary to list their unique attributes, such as sea level thrust, sea level specific impulse, etc.

[0050] Meta-attribute definition is to describe the meta-class from multiple aspects based on the attribute set summarized above. According to the different types of meta-attribute values, meta-attributes can be divided into simple meta-attributes and array meta-attributes (such as Figure 4Defined by XSD). The value of a simple meta-attribute is a common primitive data type in programming languages, such as text, numeric value, numeric array (matrix), etc. The value of an array meta-attribute is a meta-attribute array. Taking the engine requirement meta-class as an example, its meta-attributes include combat technical indicators and six requirements. The six requirements are an array meta-attribute, and its values ​​include reliability, maintainability, supportability, testability, safety, and environmental adaptability. The design purpose of the array meta-attribute is to effectively classify and manage the meta-attributes. Array meta-attributes support deep nesting. For example, the reliability meta-attribute mentioned above may also be an array meta-attribute, and its possible values ​​include: reliability, failure probability, average life, etc. When actually defining meta-attributes, it is not necessary to list all reliability evaluation indicators, but to select appropriate reliability indicators as meta-attributes in combination with the actual design process of the system.

[0051] Metaclass design and interface design. Metaclass is a collection description and abstract representation of various demand models, functional models, logical models, and physical models generated in the actual system design process based on the above meta-attribute definitions. It can be represented mathematically using the representation method of sets in mathematics, or programmatically using the representation method of classes in object-oriented programming languages. The following formula gives a simplified mathematical representation of the engine design model metaclass.

[0052]

[0053] Where ECO represents energy conversion and output, TE represents thermal efficiency, D represents durability, R represents reliability, LE represents low emissions, and FDA represents fault diagnosis and alarm. Formula 2 gives a simplified mathematical representation of the aero-engine design model metaclass.

[0054]

[0055] Where HSRS stands for high-speed rotation stability, LLD stands for long-life design, ASLET stands for aviation-specific low emission technology, and ANCT stands for aviation noise control technology.

[0056] It can be seen from the above that the attribute inheritance in the object-oriented metaclass design can be realized according to the set union operation. By adding conditional constraints in the formula, the polymorphism in the object-oriented metaclass design can be realized, that is, different subclasses instantiate the abstract attributes in the abstract parent class differently. Therefore, when it is necessary to read and write the reliability attributes of a specific engine, you only need to use the unified interface of the abstract parent class to access different metamodel objects.

[0057] Figure 5A simple example of programmatic representation of metaclasses is given. As shown in the figure, the engine metaclass (Engine) is an abstract representation of the system design process and implements three interfaces: HumanReadable, Serializable, and Verifiable. The HumanReadable interface describes how to convert the metamodel into human-readable information and provides methods such as describeInGB and describeInAGMA, which respectively represent formatting the metamodel according to the national standard and the national military standard and describing the metamodel according to the American AGMA standard. The Serializable interface describes how to serialize the metamodel into a text string or a binary byte stream, and how to restore the metamodel instance from a text string, a binary byte stream, or a file. The function of the Serializable interface is to enable the metamodel to be persistently stored to avoid information loss. The Verifiable interface describes how to verify the metamodel, including integrity verification and correctness verification. Metamodel verification is an important connotation of the metamodel specification. Only a metamodel with complete semantic information can ensure the correctness of information transmission during data transmission. Therefore, the metamodel specification requires that the creator of the metamodel must provide complete metamodel information when using the metamodel specification to encapsulate the metamodel. For large meta-models that require multiple users to jointly improve information, they are split into appropriate granularity so that the small meta-models after the split are independent of each other and together constitute the original large meta-model through meta-class aggregation.

[0058] The metaclass design adopts inheritance, such as Figure 5 As shown in the figure, the crankshaft metaclass (CrankShaft), cylinder metaclass (Cylinder) and cooling system metaclass (CoolingSystem) are all inherited from the engine metaclass (Engine). The inherited metaclass automatically obtains all the properties and methods of the parent class, and the subclass can have its own unique meta-properties and methods. For example, the cylinder metaclass has getClinderNumber and setClinderNumber methods, which represent getting and setting the number of cylinders respectively; the crankshaft metaclass has getCrankShaftLength and setCrankShaftLength methods, which represent getting and setting the length of the crankshaft section; the cooling system metaclass has getCoolingSystemType and setCoolingSystemType methods, which represent getting and setting the cooling system type (air cooling, water cooling, etc.).

[0059] S12, determining the engine system metamodel mapping rule through the metamodel mapping relationship map, and establishing the mapping relationship based on the preset rule;

[0060] Metamodel mapping rule definition: Metamodel mapping rules refer to the potential constraints that must be followed when creating a mapping relationship between two metamodels. It defines some basic issues that must be considered when establishing metamodel mapping, such as whether the mapping relationship between metamodels needs to point to specific meta attributes, what types of mapping relationships between metamodels are there, what built-in rules and constraints are there for different mapping types, and whether metamodel mapping needs to meet special conditional constraints.

[0061] Mapping relationships are established; mapping relationships describe the relationship between meta-models, between meta-attributes, or between meta-models and meta-attributes. By sorting out the various potential relationships between requirements, functions, logic and physical models in the system design process, mapping relationships are defined as three types: composition relationship, dependency relationship and influence relationship. Composition relationship is mainly used to describe the inclusion and inclusion relationship between design meta-models. For example, the engine cooling system is composed of water pump, radiator, fan, thermostat, coolant, etc., which can adjust the temperature of the engine to prevent overheating and damage. The assembly relationship between design meta-models is represented by the dependency relationship between meta-attributes. Dependency relationship is mainly used to describe the necessary relationship between meta-models or meta-attributes, such as formula constraints, matching constraints, etc. Dependency relationship is bidirectional, that is, the dependent party and the dependent party are mutually dependent. For example, the movement of the engine crank-connecting rod mechanism requires the cooperation of the valve mechanism to complete, and the cooling system and lubrication system need to provide necessary cooling and lubrication for the crank-connecting rod mechanism and the valve mechanism. Influence relationship is used to describe the unidirectional relationship between meta-models or meta-attributes. For example, if the engine cooling system fails, it will affect the heat dissipation of the lubrication system, causing the oil temperature to be too high, thereby accelerating the aging and deterioration of the oil.

[0062] RFLP metamodel mapping is the modeling of complex relationships between requirements, functions, logic, and physical metamodels. All metamodel mapping relationships converge into an intricate metamodel relationship map. Metamodel mapping methods include mapping rule definition, mapping relationship modeling, and mapping relationship management. Mapping rules are constraints on mapping relationships between metamodels, including mapping granularity control, mapping relationship definition, mapping range setting, and other contents. Mapping relationship modeling is to establish mapping relationships between metamodels in a visual form based on the above mapping rules, which is specifically manifested as the connection between two metamodels. Depending on the mapping relationship, the connection is manifested in different styles. Mapping relationship management provides functions such as classification, filtering, updating, and calibration of established mapping relationships.

[0063] S13. Establish an engine system meta-model based on the mapping relationship obtained in step S12.

[0064] The generation of metamodel is the process of instantiating metaclasses into metamodels by using factory pattern and abstract factory pattern. The abstract factory pattern provides an interface for creating a series of related or interdependent objects without specifying their specific classes. In the context of metamodel generation, if the system needs to create multiple metamodels of different types and there are dependencies between these metamodels, the abstract factory pattern can be used to create a set of interdependent metamodel instances.

[0065] S2, establish a unified model structure tree through the metamodel graph relationship in the RELP metamodel;

[0066] In this embodiment, for the engine system, metamodel mapping rules are defined, and mapping relationships are defined as three types: composition relationship, dependency relationship, and influence relationship. For example, the engine system is composed of multiple subsystems, including fuel system, cooling system, lubrication system, ignition system, intake system, exhaust system, control system, etc.; the fuel system relies on the supply of fuel and the precise control of the injector to ensure that the fuel is sprayed into the cylinder in the correct amount and time, and the operation of the cooling system relies on the circulation of the water pump and the heat dissipation capacity of the radiator to keep the engine working within a suitable temperature range; the fuel supply and the cooling system temperature adjustment will affect the functions of each subsystem, thereby affecting the satisfaction of the entire engine system requirements. And the definition of built-in rules, such as not allowing the requirement metamodel to establish a dependency relationship with the physical metamodel; the definition of special rules, prohibiting a certain metamodel or meta-attribute from establishing a mapping relationship with a specific metamodel or meta-attribute, etc.

[0067] S3. Based on the data source in the established unified model structure tree, automatic identification is performed when changes occur in the data source model.

[0068] Establishment and persistence of unified data source: According to the above metamodel description, a unified data source is established for the engine system and persisted as an XML file.

[0069] This embodiment specifically includes the following steps:

[0070] S31: Upload the model to the unified data source through the upload interface. The backend automatically parses the model, generates the corresponding metamodel, and persists it as a new version of the XML file.

[0071] Design of built-in rules. Built-in rules refer to predefined metamodel mapping rules. For different metamodel mapping types, the corresponding built-in rules are different. For metamodel mapping of dependencies, the built-in rules are:

[0072] a) It is not allowed to establish dependencies between the requirement metamodel and the functional metamodel, between the requirement metamodel and the logical metamodel, or between the requirement metamodel and the physical metamodel.

[0073] b) There is a dependency between the functional metamodel and the logical metamodel.

[0074] The built-in rules for metamodel mappings that affect relationships are as follows:

[0075] a) Only the influence relationship from the physical metamodel to the requirement metamodel is allowed, and vice versa;

[0076] b) The requirement metamodel and the functional metamodel, the functional metamodel and the logical metamodel, and the logical metamodel and the physical metamodel can all establish mutual influence relationships.

[0077] For the metamodel mapping of composition relations, the built-in rules are as follows:

[0078] a) The establishment of composition relationships must conform to the actual composition situation.

[0079] Unified data source construction and persistence; such as Figure 6 As shown, the engine system requirement-function-logic-physical metamodel definition method and the metamodel mapping method are used as the method support for building a unified data source. The demand-driven engine system design simulation process is used as the model and data support to build a unified data source for the engine system based on the requirement-function-logic-physical metamodel. The four models are described by metamodel, the mapping relationship is established, the metamodel relationship is analyzed, and finally a unified model structure tree is generated, and the entire data source model is persistently represented.

[0080] S32: Compare the new version of the XML file with the previous version of the XML file, automatically identify changes in the model (the change threshold set here is to prompt for any changes), and perform corresponding visual displays for different situations. If the model change is a new addition, it will be updated after meeting the requirements. If it is a modification, a comparison will be performed, the affected part will be displayed, and the changes will be merged. If it is a deletion, the corresponding structure will be deleted and the associated relationship will be deleted.

[0081] The data source model changes (addition, deletion, modification), and automatic identification is achieved. The specific solution is: when the model changes (addition, deletion, modification), it is uploaded to the unified data source. The data source performs corresponding comparison and analysis through the persistent XML file to achieve automatic identification of model changes, find the change and modification location, and visualize it.

[0082] The quantitative criteria for the identification process are as follows:

[0083] a) The structure of the XML file after the change should remain consistent, including the root element, sub-elements, attributes, etc.

[0084] b) Matching elements and attributes: During the comparison process, determine whether changes have occurred by comparing element names, attribute names, and attribute values.

[0085] c) Design change thresholds, such as the number of element changes, the number of attribute changes, or the number of attribute changes exceeding a certain range, as the basis for change identification.

[0086] The identification conditions are as follows:

[0087] d) New addition condition: When new elements or attributes appear in the XML file and these elements or attributes do not exist in the original XML file, they are identified as new changes.

[0088] e) Deletion condition: When some elements or attributes in the original XML file are missing from the XML file, it is identified as a deletion change.

[0089] f) Modification condition: When the element or attribute value in the XML file changes and is inconsistent with the corresponding element or attribute value in the original XML file, it is identified as a modification.

[0090] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0091] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0092] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process in the computer or other programmable device. Figure 1 A process or multiple processes and / or boxes Figure 1The steps for the functions specified in one or more boxes.

[0093] The present invention uses specific embodiments to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea. At the same time, for those skilled in the art, according to the idea of ​​the present invention, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present invention.

[0094] Those skilled in the art will appreciate that the embodiments described herein are intended to help readers understand the principles of the present invention, and should be understood that the protection scope of the present invention is not limited to such specific statements and embodiments. Those skilled in the art can make various other specific variations and combinations that do not deviate from the essence of the present invention based on the technical revelations disclosed by the present invention, and these variations and combinations are still within the protection scope of the present invention.

Claims

1. A method for automatically identifying changes in RFLP unified data source model, characterized in that: The steps include: S1. Establish RFLP meta-model, including demand model, functional model, logical model and physical model; S2, establish a unified model structure tree through the metamodel graph relationship in the RELP metamodel; S3. Based on the data source in the established unified model structure tree, automatic identification is performed when changes occur in the data source model.

2. The method for automatically identifying changes in RFLP unified data source model according to claim 1, characterized in that: The S1 specifically includes the following steps: S11, the RFLP-based engine system metamodel is a model that describes the engine system requirement model, function model, logic model, and physical model, and generates the engine system metamodel specification through the attribute set of the requirement model, function model, logic model, and physical model; S12, determining the engine system metamodel mapping rule through the metamodel mapping relationship map, and establishing the mapping relationship based on the preset rule; S13. Establish an engine system meta-model based on the mapping relationship obtained in step S12.

3. The method for automatically identifying changes in RFLP unified data source model according to claim 2, characterized in that: The preset rule in S12 is: For the metamodel mapping of dependencies, the preset rules are: a) It is not allowed to establish dependencies between the requirement metamodel and the functional metamodel, between the requirement metamodel and the logical metamodel, or between the requirement metamodel and the physical metamodel; b) There is a dependency relationship between the functional metamodel and the logical metamodel; For the metamodel mapping that affects relationships, the preset rules are: a) Only the influence relationship from the physical metamodel to the requirement metamodel is allowed, and vice versa; b) Establish mutual influence relationships between the requirement metamodel and the functional metamodel, between the functional metamodel and the logical metamodel, and between the logical metamodel and the physical metamodel.

4. The method for automatically identifying changes in RFLP unified data source model according to claim 2, characterized in that: The engine system metamodel in S13 is expressed as: Wherein, Φ is the aero-engine design system metamodel, Θ is the engine design system metamodel, HSRS stands for high-speed rotation stability, LLD stands for long life design, ASLET stands for aviation-specific low emission, ANCT stands for aviation noise control, and R stands for reliability.

5. The method for automatically identifying changes in RFLP unified data source model according to claim 2, characterized in that: The S3 specifically includes the following steps: S31, upload the engine metamodel to the unified data source and automatically parse the model at the back end to generate the corresponding metamodel, and persist it as a new version of the XML file; S32. Compare the new version of the XML file with the original version of the XML file to automatically identify model changes.

6. The method for automatically identifying changes in RFLP unified data source model according to claim 5, characterized in that: The automatic identification in S32 includes the following steps: A. Set the XML file change elements, including file elements, file sub-elements and file attributes, and determine whether there is a change based on the preset recognition conditions; B. Set an element change threshold. If the file change element exceeds the set element change threshold, it is determined that the XML file has changed.

7. The method for automatically identifying changes in RFLP unified data source model according to claim 6, characterized in that: The identification conditions preset in step A include: A1. When new elements or attributes appear in an XML file and these elements or attributes do not exist in the original XML file, they are identified as new changes; A2. When some elements or attributes in the original XML file are missing from the XML file, it is identified as a deletion change; A3. When the element or attribute value in the XML file changes and is inconsistent with the corresponding element or attribute value in the original XML file, it is identified as a modification.

Images