Aero-engine narrow sense EBOM structure design method based on fault hardware

Abstract

The application belongs to the field of aero-engine design, and is a narrow EBOM structure design method for aero-engines based on fault hardware. By setting a narrow EBOM structure, the EBOM is set to a three-layer structure of object-unit body-fault hardware, and then fault hardware definition is performed, all fault information of hardware is traversed, fault hardware meeting the fault hardware definition is found out, and the fault hardware is connected with the corresponding unit body. The data in the fault hardware is minimized and split. Finally, all fault components contained in any fault hardware are identified synchronously, and the data information accompanying all the found fault components is synchronously migrated into the corresponding fault hardware. The number of hardware that needs to be controlled can be greatly reduced, the control efficiency is improved, and the control quality is guaranteed. With specific fault hardware as the core, the history information of each fault hardware can be effectively tracked through the bottom-up building method, which is beneficial to the formation of cross-use information between each part.

Description

Technical Field

[0001] This application belongs to the field of aero-engine design, and specifically relates to a narrow EBOM structure design method for aero-engines based on faulty hardware. Background Technology

[0002] An Engineering Bill of Material (EBOM) is a list of materials that includes the structure and composition of various components according to design requirements, reflecting the product's attributes and the design relationships between parts. In information systems, it is a computer-readable product structure data file and serves as the initial data source for subsequent production and manufacturing.

[0003] The broad definition of an aero-engine EBOM encompasses all its subordinate components, totaling tens of thousands of components, with hierarchical levels reaching over 10 layers, posing a significant challenge to the information management of aero-engines. A complete, broadly defined aero-engine EBOM includes, for example, [examples of EBOMs would follow here]. Figure 1 As shown, this EBOM is for demonstration purposes only, and therefore the complete EBOM has been greatly simplified.

[0004] Especially for aero engines in the early stages of feasibility studies, they often have multiple schemes, configurations, and rounds of technical development. The material selection and structural forms of each component are quite different, and there are also cases of overlapping components. The workload of constructing a complete aero engine EBOM and maintaining it in real time is enormous, requiring a lot of manpower and resources.

[0005] Currently, the following drawbacks exist:

[0006] 1) The number of components managed by a complete aero-engine EBOM is extremely large, reaching tens of thousands. This results in a significant time consumption in the establishment and maintenance of the information system, as well as the creation and updating of the attribute information of the relevant components. Furthermore, the management is not convenient and is prone to errors due to the large number of hardware components.

[0007] 2) The engine assembly relationship is complex. There are still many levels of components below the unit level, up to 10 or more. Building and expanding according to the complete EBOM is not conducive to the display of component information, nor is it conducive to in-depth data mining in the later stage.

[0008] 3) Engines in the early stages of scheme demonstration often have multiple schemes, configurations, and rounds of technical characteristics. Hardware cross-use is very frequent. The same hardware may be installed in different engines at different times. As a top-down management method, it is difficult to identify the complete history information of a certain cross-used hardware.

[0009] Therefore, how to manage and maintain EBOM more efficiently is a problem that needs to be solved. Summary of the Invention

[0010] The purpose of this application is to provide a narrow EBOM structure design method for aero-engines based on faulty hardware, so as to solve the problem of difficult EBOM management and maintenance in the prior art.

[0011] The technical solution of this application is: a narrow EBOM structure design method for aero-engines based on faulty hardware, comprising:

[0012] The EBOM structure is divided into a three-layer structure: object-unit-fault hardware;

[0013] Define the faulty hardware, traverse the fault information of all hardware, find the faulty hardware that matches the faulty hardware definition, and connect the faulty hardware to the corresponding unit body.

[0014] The data within the faulty hardware is broken down into the smallest units, and all the smallest units are entered into the corresponding faulty hardware.

[0015] Simultaneously identify all faulty components contained in any faulty hardware, and synchronously migrate the data information associated with all the identified faulty components to the corresponding faulty hardware.

[0016] Preferably, the method for connecting the faulty hardware to the corresponding unit is as follows:

[0017] All components under any unit are set to parallel status. After the faulty hardware is found, the basic information of the faulty hardware is matched with the basic information of different units. When it is determined that two or more faulty hardware belong to different assemblies but belong to the same unit, the faulty hardware belonging to different assemblies is associated with the same unit according to the basic information.

[0018] Preferably, the method for finding any faulty hardware is as follows: set up a search function related to basic information, input two or more or all of the information items under the basic information, and then search until the corresponding faulty hardware is found.

[0019] Preferably, the data information of the faulty hardware includes basic information, unit information, out-of-tolerance information, rework information, material substitution information, assembly problems, trial run problems, and fault detection problems.

[0020] Preferably, when a component is determined to be faulty hardware, it is searched separately according to eight different categories of data information and stored in the corresponding data information category. Furthermore, the out-of-tolerance information and material substitution information of each faulty hardware are only stored as the final processing result.

[0021] Preferably, when updating data, if it is determined that a faulty hardware has been added to the corresponding unit, a new data storage unit is added to the corresponding faulty hardware based on the basic information of the faulty hardware, and the fault information of the newly added faulty hardware is sent to the corresponding data storage unit.

[0022] Preferably, when updating faulty hardware, different update versions are recorded and different storage units are created for each update, and different update versions can be associated with different parties.

[0023] This application presents a narrow EBOM structure design method for aero-engines based on faulty hardware. By setting a narrow EBOM structure, the EBOM is set into a three-layer structure of object-unit-faulty hardware. Then, the faulty hardware is defined, the fault information of all hardware is traversed, the faulty hardware that meets the faulty hardware definition is found, and the faulty hardware is connected to the corresponding unit.

[0024] The system minimizes and breaks down the data within faulty hardware into the smallest units, recording all these units into the corresponding faulty hardware. Finally, it synchronously identifies all faulty components within any faulty hardware and migrates the associated data information of all identified faulty components to the corresponding faulty hardware. This significantly reduces the number of hardware units requiring management, improves management efficiency, and ensures management quality. Using specific faulty hardware as the core and employing a bottom-up approach, it effectively tracks the history of each faulty hardware unit, facilitating the creation of cross-functional information between different units. Attached Figure Description

[0025] To more clearly illustrate the technical solutions provided in this application, the accompanying drawings will be briefly described below. Obviously, the drawings described below are merely some embodiments of this application.

[0026] Figure 1 This is a schematic diagram of the EBOM structure in the background technology;

[0027] Figure 2 This is a schematic diagram of the overall process of this application;

[0028] Figure 3 This is a schematic diagram of the narrow definition of EBOM in this application;

[0029] Figure 4 This is a schematic diagram of the data information involved in the faulty hardware of this application;

[0030] Figure 5 This is a schematic diagram illustrating the principle of serial component association in this application. Detailed Implementation

[0031] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be described in more detail below with reference to the accompanying drawings.

[0032] A narrow EBOM structure design method for aero-engines based on faulty hardware, such as Figure 2 As shown, it includes the following steps:

[0033] Step S100: Divide the EBOM structure into a three-layer structure: object-unit-fault hardware;

[0034] The unit is the top level of an EBOM and remains basically unchanged. The failure of any component under the unit will result in a faulty hardware.

[0035] Set all components under any unit cell to a parallel state, such as Figure 3 This demonstrates a narrow EBOM (Engine Engineering Machine Object Model) for aero-engines based on faulty hardware. It focuses on the faulty hardware and obscures the assembly relationships below the unit level. In this example, the first-level unit level includes components such as the "fan" and "high-pressure compressor." The faulty hardware corresponding to the high-pressure compressor includes the front casing, the extension casing, and the first-stage rotor.

[0036] According to the complete EBOM requirements, the front casing and the first-stage rotor belong to different assemblies. To facilitate management and ensure a simple hierarchy, both are integrated into the high-pressure compressor. Similarly, the upper and lower levels of the original EBOM, such as the front casing and its assembly, are also placed under the same high-pressure compressor. This significantly reduces the number of control levels, promotes information flattening, and facilitates data transmission. Furthermore, by only controlling faulty hardware in the aero-engine, the number of hardware components requiring control can be greatly reduced.

[0037] The method for further connecting faulty hardware with the corresponding unit body is as follows: after identifying the faulty hardware, the basic information of the faulty hardware is matched with the basic information of different unit bodies. When it is determined that two or more faulty hardwares belong to different assemblies but belong to the same unit body, the faulty hardwares belonging to different assemblies are associated with the same unit body according to the basic information.

[0038] Step S200: Define the faulty hardware, traverse the fault information of all hardware, find the faulty hardware that matches the faulty hardware definition, and connect the faulty hardware to the corresponding unit body.

[0039] The data information for faulty hardware includes eight categories: basic information, unit information, out-of-tolerance information, rework information, material replacement information, assembly issues, trial run issues, and troubleshooting issues. Each category contains multiple sets of information items; for example, basic information includes drawing number, version, and other information items.

[0040] Faulty hardware typically refers to hardware involved in deviations from tolerances, material substitutions, rework, assembly, testing, and troubleshooting processes. Faulty hardware can be a part or an assembly. Deviations from tolerances, material substitutions, and rework emphasize the result, while assembly, testing, and troubleshooting emphasize the process. Specific data information related to faulty hardware includes... Figure 4 As shown.

[0041] Basic information is the hardware's identity data, a unique characteristic used to identify the hardware. Unit information describes the hardware's history, indicating which engine it was installed in at different times.

[0042] Figure 4 Information on intermediate processing, material substitution, assembly, trial runs, and troubleshooting can also be expanded downwards as needed to gradually broaden the scope of content requiring control.

[0043] In other words, when defining a fault, a standard threshold range is set for each information item under the six classification items, excluding basic information and unit information. Data for any information item that exceeds the standard threshold range is determined to be a faulty component, thus forming a faulty hardware.

[0044] Step S300: The data in the faulty hardware is divided into the smallest units according to the principle of indivisibility, and all the smallest units are entered into the corresponding faulty hardware.

[0045] When performing the minimum breakdown, for example, if one piece of hardware contains multiple out-of-tolerance information, it is defined as multiple information. The version information item under the basic information has multiple versions, and each version is stored as a separate information. Multiple parts together have one out-of-tolerance list, which is also defined as multiple information. The assembly time, platform time, and test run time in the history information are all broken down to the smallest unit and entered separately.

[0046] This allows for more flexible data retrieval when using data, preventing different content within the same message from needing to be stored in different locations, and also makes data replacement and modification more convenient when updating data.

[0047] During data processing, it is determined whether there are any faulty components. If not, no data migration is performed. If there are faulty components, according to the principle of associated faulty components, all faulty components contained in any faulty hardware are identified synchronously, and the data information associated with all the identified faulty components is synchronously migrated to the corresponding faulty hardware.

[0048] Component migration is not part of the information entry process; rather, it involves adjusting hardware information according to the system's history, falling under the data processing category. For example, if component 1 was used for two years in system 1 and three years in system 2, then searching for component 1's data requires separate searches in both systems. Component migration objects may be parts, components, or units. Component migration requires synchronously identifying all faulty components within it and migrating all associated data. For instance, when migration of a high-guide vane internal support component, it's necessary to synchronously identify all guide vane-related faults, including out-of-tolerance and material loss, etc. Specific associated hardware and information are required, such as... Figure 5 As shown.

[0049] When a component is determined to be faulty hardware, it is searched separately according to the eight different categories of data information. The search scope covers any information contained in the engine to ensure the comprehensiveness of the data. Then, it is stored in the corresponding information item according to the principle of indivisibility. Furthermore, the out-of-tolerance information and replacement information of each faulty hardware are processed according to the result-oriented principle, that is, only the final processing result is stored to ensure the quality of data storage, ensure the independence of each information item, and ensure that the information items do not overlap with each other to facilitate retrieval.

[0050] Furthermore, the method for locating any faulty hardware is as follows: Set up a search function related to the basic information, input two or more, or all, of the information items under the basic information, and then search until the corresponding faulty hardware is found. Since different faulty hardware may be within the same drawing number, search errors are prone to occur. Therefore, using information such as drawing number, version, and batch number for cross-checking ensures a unique identification of the faulty hardware, preventing errors. Especially for hardware with specific assembly positions and sequences, it is advisable to try synchronizing its assembly information to the hardware itself.

[0051] When updating data, if a faulty hardware is detected in the corresponding unit, a new data storage unit is added for the faulty hardware based on its basic information. The fault information of the newly added faulty hardware is sent to the corresponding data storage unit, thereby enabling continuous data expansion. Each data information module has the ability to expand data information, and the hardware information can be continuously supplemented and improved along with its application process.

[0052] When updating faulty hardware, in accordance with the process flow principle, different update versions are recorded and different storage units are created for each update, and different update versions can be associated with different parties.

[0053] A single piece of hardware may involve multiple fault scenarios, and a single fault scenario may also contain various data information. Therefore, the data entry and maintenance should be completed by multiple parties according to their job responsibilities. By having multiple parties complete the data maintenance through a workflow, the workload for any single party can be avoided being excessive. When performing data maintenance, different parties should log in to the same EBOM using their respective accounts.

[0054] This application establishes a narrow EBOM structure, defining it as a three-layer structure of object-unit-faulty hardware. Faulty hardware is then defined, and fault information for all hardware is traversed to identify those matching the definition. This faulty hardware is then connected to its corresponding unit. The data within the faulty hardware is then minimized and broken down into the smallest units, which are then entered into the corresponding faulty hardware. Finally, all faulty components within any faulty hardware are synchronously identified, and the associated data information of all identified faulty components is synchronously migrated to the corresponding faulty hardware. This significantly reduces the number of hardware devices requiring management, improves management efficiency, and ensures management quality. Using specific faulty hardware as the core and employing a bottom-up approach, the historical information of each faulty hardware device can be effectively tracked, facilitating the formation of cross-functional information between different units.

[0055] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for designing the narrow EBOM structure of an aero-engine based on faulty hardware, characterized in that, include: The EBOM structure is divided into a three-layer structure: object-unit-fault hardware; Define the faulty hardware, traverse the fault information of all hardware, find the faulty hardware that matches the faulty hardware definition, and connect the faulty hardware to the corresponding unit body. The data within the faulty hardware is broken down into the smallest units, and all the smallest units are entered into the corresponding faulty hardware. Simultaneously identify all faulty components contained in any faulty hardware, and synchronously migrate the data information associated with all the identified faulty components to the corresponding faulty hardware. The data information of the faulty hardware includes basic information, unit information, out-of-tolerance information, rework information, substitute material information, assembly problems, test run problems, and troubleshooting problems. When any component is determined to be faulty hardware, it is searched separately according to the different information items of the eight different categories of data information. The search scope covers any information contained in the engine. Then, it is stored in the corresponding information item according to the principle of indivisibility. The out-of-tolerance information and substitute material information of each faulty hardware are processed according to the result-oriented principle. When performing the minimum breakdown, if a piece of hardware contains multiple out-of-tolerance information, it is defined as multiple information. The version information item under the basic information has multiple versions, and each version is stored as a separate information. Multiple parts together have one out-of-tolerance list, which is also defined as multiple information. The assembly time, platform time, and test run time in the history information are all broken down to the smallest unit and entered separately.

2. The narrow EBOM structure design method for aero-engines based on faulty hardware as described in claim 1, characterized in that, The method for connecting the faulty hardware to the corresponding unit is as follows: All components under any unit are set to parallel status. After the faulty hardware is found, the basic information of the faulty hardware is matched with the basic information of different units. When it is determined that two or more faulty hardware belong to different assemblies but belong to the same unit, the faulty hardware belonging to different assemblies is associated with the same unit according to the basic information.

3. The narrow EBOM structure design method for aero-engines based on faulty hardware as described in claim 1, characterized in that, The method for finding any faulty hardware is as follows: set up the search function related to basic information, enter two or more or all of the information items under basic information, and then search until the corresponding faulty hardware is found.

4. The narrow EBOM structure design method for aero-engines based on faulty hardware as described in claim 1, characterized in that: When a component is determined to be faulty hardware, it is searched separately according to the different information items of the eight different categories of data information and stored in the corresponding information item. Moreover, the out-of-tolerance information and material substitution information of each faulty hardware only store the final processing result.

5. The narrow EBOM structure design method for aero-engines based on faulty hardware as described in claim 1, characterized in that: When updating data, if it is determined that a faulty piece of hardware has been added to the corresponding unit, a new data storage unit is added for the faulty hardware based on its basic information, and the fault information of the newly added faulty hardware is sent to the corresponding data storage unit.

6. The narrow EBOM structure design method for aero-engines based on faulty hardware as described in claim 5, characterized in that: When updating faulty hardware, different update versions are recorded and different storage units are created for each update, and different update versions can be associated with different parties.

Images