A multi-model product life cycle collaborative management method based on digital clues

Abstract

To address the problems of data redundancy between derived and primary models, uncontrollable change propagation, fragmented lifecycle data, and poor data consistency and traceability among models in existing complex product management solutions, this invention proposes a multi-model product lifecycle collaborative management method based on digital clues. This invention associates scattered data for the same product object across different business systems with a unique logical identifier node, achieving effective aggregation of cross-system and cross-stage data; it generates a derived model product structure tree based on a model derivation rule-driven inheritance and differentiation mechanism, resolving data redundancy; using nodes in the product structure tree as digital clue anchors, it uniformly links data from each stage to the corresponding structural level in the product structure tree through these anchors, achieving structure-driven full lifecycle analysis; and by defining a data lineage model, it explicitly describes data generation, transformation, and dependency relationships, achieving full-link traceability and impact analysis.

Description

Technical Field

[0001] This invention relates to a method for collaborative management and control of the lifecycle of multiple product models based on digital clues. Background Technology

[0002] Complex products, such as aircraft, aero engines, and large mechanical equipment, are typically characterized by complex structural hierarchies, a large number of parts, frequent model derivations, and long lifecycles. Taking aircraft or aero engines as an example, a main model often derives into multiple improved or adapted models. Different models share many common, inheritable structures, but also exhibit localized differences in structure or configuration.

[0003] Meanwhile, complex products typically go through multiple stages in their lifecycle, including design, process planning, manufacturing, assembly and testing, quality control, and operation and maintenance. Each stage is supported by different business systems (such as PLM, ERP, MES, etc.). Because these business systems are usually built independently, their data models, coding rules, identification methods, and storage structures are different, resulting in product lifecycle data being scattered across different business systems, forming "data silos" and lacking a unified data expression and interconnection mechanism.

[0004] Currently, data management for complex products mainly takes the following approaches:

[0005] 1. Product Structure Management Solution Based on PLM System

[0006] This solution relies on a PLM system to build a Product Structure Tree (PST) and manages the bill of materials at different stages through Engineering Bill of Materials (EBOM) and Manufacturing Bill of Materials (MBOM). This method enables hierarchical representation of the product structure and supports version management and change control. However, this method has the following drawbacks: First, because the primary and derived models are typically managed using a replication structure or version branching approach, there is a lack of an explicit master-slave inheritance model, leading to data redundancy between derived and primary models. Furthermore, when the primary model changes, it is difficult to effectively and controllably synchronize the changes to all derived models. Second, because each business system is built independently with different data models and fragmented lifecycle data, there is a lack of a unified object anchor point that spans the entire lifecycle. This makes it difficult to quickly and accurately trace back to specific structural nodes when faults / quality issues occur, affecting the efficiency of problem localization and analysis.

[0007] 2. Solution based on BOM multi-view management

[0008] This solution constructs multiple view bills of materials, such as EBOM, MBOM, and PBOM, and establishes conversion rules between these view bills of materials to support collaborative work between different departments. However, this solution has the following drawbacks: First, the lack of a structural inheritance mechanism between multiple models makes it difficult to establish association and derivation mechanisms between different product models, limiting the consistency and traceability of data between models. Second, the existing solution lacks a clear record of data sources and evolution paths; data lineage is invisible or incomplete, making it impossible to accurately trace the source path of a certain indicator or result, and also making it difficult to assess the scope of impact caused by data changes. Summary of the Invention

[0009] To address the technical problems existing in current complex product management solutions, such as data redundancy between derived models and main models, uncontrollable change propagation, fragmented lifecycle data, and poor consistency and traceability of data between models, this invention proposes a multi-model product lifecycle collaborative management method based on digital clues.

[0010] The technical solution of this invention is:

[0011] A collaborative management method for the lifecycle of multiple product models based on digital clues, characterized by the following steps:

[0012] Step 1: Collect multi-source heterogeneous data from multiple product models throughout their entire lifecycle, and add data classification tags to form the original dataset;

[0013] Step 2: Perform non-destructive data cleaning on the original data, and then perform unified structure and unified semantic processing;

[0014] Step 3: Associate the data in Step 2 that point to the same product object through a unique logical identifier node to form a unified product data view;

[0015] Step 4: Construct a data lineage model;

[0016] Step 5: Construct a multi-model product structure model, including a main product structure tree and a derived model product structure tree. The main product structure tree is constructed based on the product objects in the unified product data view, according to the hierarchical relationship of products, subsystems, and components. The method for generating the derived model product structure tree is as follows: define model derivation rules; establish a change logic mapping table between the main product and the derived model products based on the model derivation rules; inherit the unchanged structural nodes and associated data in the main product structure tree, and perform structural replacement, structural addition, deletion, and / or attribute changes on the variant nodes according to the change logic mapping table to obtain the derived model product structure tree.

[0017] Step 6: Construct the bill of materials view for each business stage, and establish its node mapping relationship, attribute conversion rules and conversion trigger conditions;

[0018] Step 7: Establish and visualize the full lifecycle digital lead model, and add version and status identifiers to the associated data design baseline, manufacturing batch, and operation and maintenance stage. The full lifecycle digital lead model includes the main product digital lead and the derivative product digital lead. The main product digital lead is built based on the main product structure tree. The method for establishing the derivative product digital lead is as follows: keep the derivative product structure tree unchanged, establish independent data evolution links for the structural nodes that have changed and their associated data, and use the data evolution links corresponding to the main product for the remaining structural nodes.

[0019] Step 8: Based on the data lineage model, establish a data quality constraint monitoring mechanism for the data in the unified product data view, including consistency, integrity, and timeliness constraint monitoring;

[0020] Step 9: Based on the digital clue model, change logic mapping table, and bill of materials view, establish a product structure tree change identification and impact analysis mechanism, including change type identification, change impact scope identification, and impact analysis result generation; the impact analysis result is generated based on the change type identification result, the change impact scope identification result, and the data anomaly information monitored by the data quality constraint monitoring mechanism in Step 8.

[0021] Step 10: Based on the full lifecycle digital clue model, data quality constraint monitoring mechanism, and product structure tree change identification and impact analysis mechanism, conduct cross-stage and multi-model product collaborative management and cross-departmental collaborative support.

[0022] Steps 6 and 7 can be interchanged; step 4 can also be performed after the digital clue model is built and visualized, but before the data quality constraint monitoring mechanism is established.

[0023] Furthermore, in step 1, data classification tags are added according to data source, product model, life cycle stage, and data structure type.

[0024] Furthermore, in step 2, non-destructive data cleaning refers to the process of cleaning data without overwriting or deleting the original data, but rather generating a corresponding data version identifier for the cleaned data and establishing a relationship between the cleaned data and the original data.

[0025] Furthermore, step 3 specifically involves:

[0026] Step 3.1: Establish the product master data model;

[0027] Step 3.2: Based on the product master data model, parse and match the data processed in Step 2, and determine whether different data points to the same product object based on the matching results;

[0028] Step 3.3: For data identified as pointing to the same product object, construct a unique logical identifier node for it; the logical identifier node includes logical identifier number, product object type identifier, main model identifier and derived model identifier, cross-system mapping information and lifecycle stage identifier;

[0029] Step 3.4: Associate the scattered data pointing to the same product object with the corresponding logical identifier node to form a unified product data view.

[0030] Furthermore, the data lineage model constructed in step 4 includes lineage nodes and lineage relationships; lineage nodes are used to describe the existence of data in different lifecycle stages, different processing states, and different logical identifier nodes, including original data nodes, processed data nodes, and associated data nodes; lineage relationships are used to describe the dependency paths between lineage nodes, including source relationships, transformation relationships, association relationships, and version evolution relationships.

[0031] Furthermore, in step 5, each node in the main product structure tree corresponds to a logical identifier node and a product object uniformly identified by that logical identifier node.

[0032] Furthermore, the bill of materials (BOM) views constructed in step 6 include Engineering Bill of Materials (EBOM), Design Bill of Materials (DBOM), Process Bill of Materials (PBOM), Manufacturing Bill of Materials (MBOM), and Purchasing Bill of Materials (BBOM); node mapping relationships are used to define the correspondence between nodes in different BOM views, including one-to-one mapping, one-to-many mapping, and many-to-one mapping; attribute conversion rules are used to define the mapping and supplementary content of attribute fields during the conversion of BOM views; conversion trigger conditions are used to define the triggering method of BOM view conversion, including manual triggering and event triggering.

[0033] Furthermore, the method for constructing the digital lead model of the main product in step 7 is as follows: each node in the main product structure tree is defined as a digital lead anchor point; the digital lead anchor points are used to link the data of the main product at each stage in a lead-based manner to construct the digital lead of the main product.

[0034] The method of clue-based association is as follows:

[0035] Each digital clue anchor is assigned a unique digital clue identifier, and an identifier mapping relationship between the digital clue identifier and the logical identifier node is established to realize the association between the digital clue anchor and the data;

[0036] For the data associated with each digital lead anchor, sort and connect them according to the life cycle stage of the data generation and the data timestamp to form a data evolution link describing the product object from design to operation and maintenance under the digital lead anchor;

[0037] Based on the data processing dependencies and source relationships recorded in the data lineage model, a causal evolution link is established between data in adjacent stages, so that the data evolution link not only has temporal sequence, but also causal traceability.

[0038] Furthermore, the method for identifying the scope of change impact in step 9 is as follows: based on the change logic mapping table, identify the propagation scope of the change among multiple product models; based on the mapping relationship between bill of materials views, identify the impact of the change on each bill of materials view; based on the digital clue model, trace the upstream and downstream data dependencies of the change and identify the affected related data; the impact analysis results in step 9 include a list of affected product structure tree nodes, a list of affected derived models, a list of affected bill of materials views, processing suggestions for each affected object, and data anomaly information generated using a data quality constraint monitoring mechanism.

[0039] Furthermore, the specific process for cross-stage, multi-model product collaborative management and cross-departmental collaborative support in step 10 is as follows: When information changes occur during the product lifecycle, rule matching is first performed, that is, based on the digital clue model and the change identification and impact analysis mechanism, the change type is identified and the scope of impact and the responsible departments affected are determined; then, the task allocation stage is entered, and the processing tasks are automatically assigned to the relevant responsible departments according to the change type and scope of impact; after the relevant responsible departments complete the tasks, they provide feedback on the execution results; subsequently, anomaly judgment is performed on the execution results: if there are anomalies in the execution results, the anomaly handling stage is entered, and the relevant responsible departments correct and resubmit the execution results until the anomalies are eliminated; if there are no anomalies in the execution results, the data write-back stage is entered, and the execution results and corrected data are written back to the product structure tree and digital clue model; finally, the status update stage is entered, and the version and status identifier of the digital clue anchor points and their associated data are updated.

[0040] The beneficial effects of this invention are:

[0041] 1. This invention establishes a unified product logical identifier node, which associates scattered data for the same product object in different business systems and at different stages (design, production, assembly, testing and operation and maintenance) with the same logical identifier node. This solves the problems of fragmented lifecycle data and lack of a unified, consistent object in the prior art, and realizes effective aggregation and consistent view of cross-system and cross-stage data.

[0042] 2. To address the decoupling issue between structural and operational data, this invention establishes a data association mechanism driven by structural anchors: using nodes in the product structure tree as digital thread anchors, data from different stages (design, production, assembly, testing, and maintenance) are uniformly linked to the corresponding structural levels in the product structure tree through digital thread anchors, enabling structure-driven full lifecycle analysis. When a fault / quality problem occurs, it can quickly and accurately trace back to the specific structural node in the product structure tree, improving the efficiency of problem localization and analysis.

[0043] 3. To address the issue of untraceable lineage, this invention defines a data lineage relationship model to explicitly describe data generation, transformation, and dependency relationships, thereby achieving end-to-end traceability and impact analysis.

[0044] 4. To address the issue of model duplication redundancy, this invention establishes an inheritance and differentiation mechanism driven by model derivation rules, achieving differentiated derivation rather than overall data duplication, thereby reducing data redundancy and maintenance costs.

[0045] 5. The construction of multiple view bills of materials in this invention is based on the product structure model, and establishes automatic conversion rules and mapping relationships between bills of materials views, so that the differences between bills of materials views at different stages can be calculated and traced, providing support for the system operation of different business units.

[0046] 6. Based on the constructed digital clue model, change logic mapping table, and bill of materials view, this invention establishes a change identification and impact analysis mechanism, ensuring the controllability of change propagation.

[0047] 7. After identifying different data pointing to the same product object, the present invention also writes back the corresponding product object and the matching rule type used to the data classification label of the data. This facilitates the subsequent association of scattered data of the same product object through logical identifier nodes, and avoids the disadvantages of large data volume, inconvenient search and repeated calculation caused by separately establishing a database to store the matching and identification results. Attached Figure Description

[0048] Figure 1 This is a flowchart of the method of the present invention.

[0049] Figure 2 This is an example of the structure tree of the main product constructed in this invention, which shows the hierarchical composition relationship between the main product, subsystems (system A, system B) and components (part 1 to part 5).

[0050] Figure 3 It is based on the present invention Figure 2The example of the derived product structure tree constructed from the main product structure tree shows three types of changes in the derivation process: structural inheritance (system A - copy), structural change (system B - change, part 4 is replaced with part 4.1), and structural addition (system C - addition, including part 6).

[0051] Figure 4 It is a collaborative management flowchart that shows the complete closed-loop process from information change triggering to rule matching, task allocation, execution feedback, anomaly judgment and handling, data write-back and status update. Detailed Implementation

[0052] The present invention will be further described below with reference to the accompanying drawings.

[0053] Reference Figure 1 The present invention proposes a multi-model product lifecycle collaborative management method based on digital clues, which includes the following steps:

[0054] Step 1: Collect and store multi-source heterogeneous data in a unified manner to form a raw data set covering the entire life cycle of multiple product models.

[0055] Specifically:

[0056] Data acquisition methods based on application programming interface calls, data file exchange, or messaging mechanisms are used to collect lifecycle data related to multiple product models from relevant business systems during the product design, process planning, manufacturing, assembly and testing, quality control, and operation and maintenance phases.

[0057] The types of data collected include:

[0058] Structured data, including but not limited to product structure data, material codes, process parameters, and quality inspection data;

[0059] Semi-structured data, including but not limited to product design configuration data, product process configuration data, and process description data stored in formats such as XML and JSON;

[0060] Unstructured data, including but not limited to design documents, technical specifications, test reports, product images, product videos, and product operation records.

[0061] For the collected multi-source heterogeneous data, data classification tags are added to each data entry according to data source, product model, lifecycle stage, and data structure type (for example, the data classification tag for a quality inspection data entry is: {Data source: Quality Management System (QMS); Product model: Model M; Lifecycle stage: Quality control stage; Data structure type: Structured data}). These tags are then stored together with the multi-source heterogeneous data in the data storage system, forming a raw data set covering the entire lifecycle of multiple product models. Through the data classification tags in this step, centralized data management and unified indexing can be achieved without disrupting the original data structure and semantics, providing a traceable data foundation for subsequent multi-model product structure tree modeling and digital clue construction.

[0062] Step 2, data processing.

[0063] To ensure that the collected multi-source heterogeneous data has a consistent structure and semantics, so as to facilitate subsequent association and modeling, this step processes the original data.

[0064] Step 2.1, Data Cleaning: Non-destructive data cleaning is performed on the original data in the dataset formed in Step 1. This includes format normalization, identification and handling of missing and outlier values. During data cleaning, the original data is not overwritten or deleted. Instead, corresponding data version identifiers are generated for the cleaned data, and a relationship is established between the cleaned data and the original data to support data backtracking and version tracking.

[0065] The method for establishing the relationship between the data before and after cleaning in this step is as follows: the original data is identified as raw_data_id, and the cleaned data is identified as clean_data_id. The source data clean_data_id is recorded as originating from the original data raw_data_id through the "source data identifier field". When a piece of original data is processed by different cleaning rules, multiple cleaned versions can be generated, and the mapping relationship between them and the original data can be recorded respectively to support data backtracking and version tracking.

[0066] For example, given original data identified as raw_data_id = R001, after cleaning using the first cleaning rule, the data is identified as clean_data_id = C001. A data version identifier, version_id = V1, is generated and assigned to the cleaned data. Simultaneously, the source data identifier field, source_data_id = R001, is recorded in the cleaned data. The cleaned data clean_data_id = C001 is associated with the original data raw_data_id = R001 through the source data identifier field source_data_id = R001. After cleaning using the second cleaning rule, the data is identified as clean_data_id = C002, and a data version identifier, version_id = V2, is generated and assigned to the cleaned data. The source data identifier field, source_data_id = R001, is recorded in the cleaned data. The cleaned data clean_data_id = C002 is associated with the original data raw_data_id = R001 through the source data identifier field source_data_id = R001.

[0067] Step 2.2, Data Transformation and Integration: The original data and cleaned data are transformed into a structured representation based on a unified field system. The same semantic field in different business systems is mapped to a unified standard field, forming a lifecycle data set with consistent expression structure and unified semantics, which can be used for subsequent multi-model product structure tree modeling and digital clue construction.

[0068] For example, process data in XML or JSON format is converted into a structured data representation with a unified field system; part_number and material_code are mapped to component identifiers, and product_id is mapped to product instance identifiers. Each piece of data after processing has a unified field structure and semantic expression, providing standardized data input for cross-system product object identification and data association in the subsequent step 3.

[0069] Step 3: For the data processed in Step 2, logical identifier nodes are used to associate data pointing to the same product object, forming a unified product data view around the same product object.

[0070] To break down data silos and organize data scattered across different business systems around the same product object, this step establishes a unified product data view. This requires first establishing a product master data model as a unified data organization and identification framework. Then, based on the product master data model, the product objects to which the scattered data points are identified, and a unique logical identifier node is constructed for each product object. Finally, all relevant data is associated with this logical identifier node to form a unified product data view.

[0071] Step 3.1: Establish the product master data model;

[0072] A product master data model is predefined as a unified data organization and identification framework. The product master data model is used to uniformly describe / define product objects in different business systems and provides a matching basis for subsequent cross-business system product object identification.

[0073] The product master data model uses a structured approach to predefine the following core data dimensions:

[0074] Product type (category dimension): Define the product type to which the data belongs, such as complete machine, module, or component;

[0075] Model code (identification dimension): A unique identifier assigned to each specific product model;

[0076] Component hierarchy (relationship dimension): describes which components make up the product and the parent-child hierarchical relationship between the components, such as engine → high-pressure compressor → turbine → blade;

[0077] Configuration Relationships (Rule Dimension): Defines the common structure and differential configuration rules between the primary model and derived models;

[0078] Unique identifier across business systems (mapping dimension): Establish the correspondence between identifiers of the same product entity in different business systems, such as the correspondence between part numbers in PLM and material codes in MES.

[0079] Step 3.2: Identify data that points to the same product object;

[0080] Based on the product master data model, the product identification information (including model code, part number, material code, serial number and equipment number) in the data processed in step 2 (these data cover different business systems) is uniformly parsed and matched to determine whether different data points to the same product object; when the matching determines that different data points to the same product object, the corresponding product object and the matching rule type used are written back to the data classification label of the data.

[0081] The method for determining whether different data points to the same product object is as follows: when multiple different data meet the predefined product identifier matching rules or structural association rules, they are determined to point to the same product object.

[0082] Predefined product identifier matching rules include: exact matching rules for unique identifiers (e.g., identical serial numbers), matching rules for multiple fields (e.g., identical product model, part number, batch number, etc.), and fuzzy matching rules (e.g., standardized matching ignoring case, hyphens, and spaces).

[0083] Predefined structural association rules infer based on the product structure hierarchy. For example, if component X in system A is assembled under module Y, and component X' in system B is also assembled under the same module Y, and the confidence of X and X' reaches a preset threshold, then X and X' can be determined to be the same product object.

[0084] Step 3.3: Construct corresponding logical identifier nodes for data pointing to the same product object;

[0085] For the scattered data identified in step 3.2 as pointing to the same product object (such as the same model of engine or the same component instance), a unique logical identifier node is constructed for it; the logical identifier node is a data aggregation entity used to uniformly identify and associate all relevant data of the same product object scattered in different business systems; the logical identifier node does not replace the physical storage of the original data, but serves as the unique data anchor point of the product object in the unified data view subsequently formed.

[0086] The constructed logical identifier node includes at least:

[0087] ① Logical identifier number, used to uniquely identify product objects within the business system;

[0088] ② Product object type identifier, used to indicate the complete machine, system, subsystem or component corresponding to the logical identifier node;

[0089] ③ The main model identifier and the derived model identifier are used to represent the model hierarchy of the product object;

[0090] ④ Cross-system mapping information, used to record the original identifier, source system identifier and mapping relationship of the product object in different business systems;

[0091] ⑤ Lifecycle stage identifier, used to indicate the lifecycle stage at which product object data is generated.

[0092] Logical identifier nodes can be generated through hash mapping, rule encoding, or unique identifier generation mechanisms to ensure the unique representation of data pointing to the same product object in different business systems within the product master data model.

[0093] Logical identifier nodes are stored as nodes in the subsequently formed unified product data view. Different logical identifier nodes describe the relationships between product objects through association relationships, including assembly relationships, configuration relationships, and version relationships.

[0094] Step 3.4: Associate scattered data pointing to the same object across business systems with the corresponding logical identifier nodes to form a unified product data view;

[0095] For data identified as pointing to the same product object, a logical identifier node is constructed for it as a unified data identity identifier that is independent of the specific business system. All relevant data of the same product object from different business systems and different life cycle stages are associated with the corresponding logical identifier node, thereby forming a unified product data view around the same product object.

[0096] After processing in steps 3.1 to 3.4, each identified and associated product object (hereinafter referred to as "unified identified product object") has a unique logical identifier node, and through this logical identifier node, it is associated with full lifecycle data from various business systems, providing basic data units for building the product structure tree in the subsequent step 5.

[0097] Step 4: Construct a data lineage model;

[0098] To achieve a clear record of data sources, evolution paths, and dependencies, and to provide a traceability basis for subsequent data quality monitoring and change impact analysis, this step constructs a data lineage model covering the entire process of data collection, processing, identification, and association.

[0099] Specifically, this data kinship model includes two basic data elements: kinship nodes and kinship relationships, among which:

[0100] Lineage nodes are used to describe the existence of data at different lifecycle stages, different processing states, and different logical identifier nodes, and include at least the following types:

[0101] ① Raw data nodes are used to represent the raw data collected from various business systems;

[0102] ②Process data nodes, used to represent the cleaned, transformed, or integrated data versions;

[0103] ③ Associated data nodes, used to represent data that has been associated with logical identifier nodes;

[0104] Bloodline relationships are used to describe dependency paths between bloodline nodes, and at least include:

[0105] ① Source relationship, used to indicate which original data node the processed data node originates from;

[0106] ② Transformation relationships are used to indicate the evolution path of data under different processing rules or algorithms;

[0107] ③ Association relationship, used to indicate the mapping relationship between data and corresponding logical identifier nodes or product objects;

[0108] ④ Version evolution relationship, used to indicate the inheritance or replacement relationship between different data versions.

[0109] This step can also be performed after the digital clue model has been built and visualized, but before the data quality constraint monitoring mechanism has been established.

[0110] Step 5: Construct a multi-model product structure model.

[0111] After completing the construction of the unified product data view and data lineage model, this step further constructs a multi-model product structure model to establish an inheritance and differentiation management mechanism between the main product and derived model products.

[0112] Step 5.1: Construct the main product structure tree and solidify the design baseline of the main products;

[0113] Step 5.1.1: Based on the product objects with unified identification in the unified product data view formed in Step 3.4, construct the main product structure tree (PST) according to the hierarchical composition relationship between products, subsystems and components. Each node in the main product structure tree corresponds to a logical identification node and the main model product object uniformly identified by the logical identification node. Thus, each node in the product structure tree has the ability to associate data across business systems through its associated logical identification node.

[0114] Reference Figure 2 Taking a certain product as an example, the main product structure tree starts from the top-level main product node and expands downwards level by level into subsystem nodes and component nodes. For example... Figure 2 As shown, the main product includes two subsystem nodes: System A and System B. System A includes three component nodes: Part 1, Part 2, and Part 3; System B includes two component nodes: Part 4 and Part 5. Each of these nodes corresponds to a uniformly identified product object, and is associated with the full lifecycle data of that product object in each business system through a logical identifier node.

[0115] Step 5.1.2 solidifies the product structure tree of the main product in its predetermined design state, along with its associated design data, configuration data, and constraint rules, into a design baseline. This design baseline serves as the basis for subsequent model derivation and structural inheritance. The main product refers to the benchmark product within the product series that forms the basis for the development of subsequent derived models. The design baseline includes a complete component hierarchy, attribute definitions, and configuration relationships. Derived models are improved / adapted models derived from the design baseline of the main product through partial replacement, modification, addition, or deletion of structural or configuration components. For example, in the field of aero-engines, the CFM56-5B engine can be considered the main product, while CFM56-5B1 and CFM56-5B2 are derived models of the CFM56-5B engine.

[0116] Step 5.2: Generate the derived model product structure tree;

[0117] Step 5.2.1, define the model derivation rules;

[0118] For each derived product model relative to the main product's variant nodes (once the main product and derived product model are designed, the variant nodes can be obtained from the design schemes of each product model), define its model derivation rules. Multiple model derivation rules can be defined for the same variant node.

[0119] Model number derivation rules include:

[0120] ①Structural replacement rules: Define which replacement component or substructure is used at this node for a certain derivative product model;

[0121] ② Structural addition and deletion rules: Define which child nodes are added or deleted at this node for a certain derived product model;

[0122] ③ Attribute change rules: Define which attribute values ​​of a certain derived product change at this node;

[0123] ④ Applicability rules: Define which derivative models the variant node applies to and which derivative models it does not apply to.

[0124] Step 5.2.2: Establish a change logic mapping table between the main product and derived model products;

[0125] Based on the model derivation rules defined in step 5.2.1, a change logic mapping table between the main product and derived model products is established. This mapping table clarifies the change logic of nodes in the structure trees of each derived model product when a node in the main product structure tree changes.

[0126] Step 5.2.3: Based on the main product structure tree and the change logic mapping table, generate the derived model product structure tree;

[0127] Based on the main product structure tree, the unchanged structural nodes and their associated data are inherited to generate the basic skeleton of the derived product structure tree.

[0128] For variant nodes in the main product structure tree, perform structural replacement, addition, deletion and / or attribute changes according to the change logic mapping table to generate differentiated branches of the derived model product structure tree.

[0129] By attaching the differentiated branches to the corresponding positions in the basic skeleton, a derived model product structure tree is obtained.

[0130] Through the above process, a multi-model product structure model is formed, consisting of the main product structure tree and all derived model product structure trees, providing a structural foundation for the subsequent construction of the bill of materials view in step 6 and the change impact analysis in step 9.

[0131] For example, refer to Figure 3 ,by Figure 2 Based on the main product shown, the derived product structure tree is generated through a change logic mapping table. The differences between it and the main product structure tree are reflected in the following three types of changes:

[0132] ①Structural inheritance (copying): such as Figure 3 As shown, system A is marked as "copy", indicating that the subsystem and its subordinate parts 1, 2 and 3 completely follow the structure of the main product in the derived model without any changes, and the corresponding logical identifier nodes and associated data are directly inherited from the main product.

[0133] ②Structural changes (replacements): such as Figure 3 As shown, system B is marked "Change," indicating that a partial structural change has occurred in this subsystem within the derived model. Specifically, part 4 in the main product is replaced with part 4.1 (corresponding to the structural replacement rule in the model derivation rules), while part 5 remains unchanged. Part 4.1, as a component unique to the derived model, requires the establishment of an independent logical identifier node and association with its own lifecycle data.

[0134] ③ New structural additions: such as Figure 3 As shown, system C is marked "new", indicating that this subsystem and its subordinate part 6 are newly added structures in the derived model (corresponding to the structure addition and deletion rules in the model derivation rules), and do not exist in the main product structure tree. System C and part 6 need to establish independent logical identifier nodes.

[0135] contrast Figure 2 and Figure 3It can be seen that the derived product structure tree is not a complete copy of the main product structure tree. Instead, it inherits the common structure and only establishes differentiated branches for the changed and added parts, thereby realizing the inheritance and differentiated management of multi-model product data and reducing data redundancy.

[0136] Step 6: Construct the bill of materials view for each business stage and establish its mapping relationship and conversion rules.

[0137] Based on the multi-model product structure model, in order to support collaborative work among different business departments, this step constructs the bill of materials view for each business stage and establishes the mapping relationship and conversion rules between the bill of materials views.

[0138] Specifically, based on the multi-model product structure model, corresponding bill of materials (XBOM) views are built for different business stages, including but not limited to engineering bill of materials (EBOM), design bill of materials (DBOM), process bill of materials (PBOM), manufacturing bill of materials (MBOM) and procurement bill of materials (BBOM).

[0139] To support data conversion and synchronization between different bill of materials views, the following mapping relationships and conversion rules are established:

[0140] ① Node mapping relationship: Define the node correspondence in different bill of materials views, including one-to-one mapping (e.g., part A in EBOM corresponds to part A in MBOM), one-to-many mapping (e.g., a component in EBOM is split into multiple manufacturing units in MBOM), and many-to-one mapping (e.g., multiple design parts in EBOM are merged into one process unit in PBOM).

[0141] ② Attribute conversion rules: Define the mapping and supplementary content of attribute fields during the conversion of the bill of materials view. For example, when converting from EBOM to MBOM, manufacturing attributes such as manufacturing process route, processing steps and time quota need to be supplemented.

[0142] ③ Conversion Trigger Conditions: Define the triggering method for bill of materials view conversion, including manual triggering (the business personnel initiate the bill of materials view conversion request) and event triggering (when the upstream bill of materials view changes, the downstream bill of materials view is automatically updated).

[0143] The aforementioned mapping relationships and transformation rules will be used in the change impact analysis mechanism in step 9 to identify affected bill of materials (BOM) views and assess the scope of change propagation. Simultaneously, during the BOM view transformation process, the data lineage model constructed in step 4 records the source relationships and transformation paths of the BOM view transformation, making the differences between various BOM views traceable and auditable, and ensuring the consistency and traceability of each BOM view across multiple product models.

[0144] Step 7: Build a full lifecycle digital lead model based on the product structure tree.

[0145] Step 7.1 Construct digital leads for the main product;

[0146] Step 7.1.1: Define each node (including product nodes, subsystem nodes, and component nodes) in the main product structure tree constructed in Step 5 as a digital thread anchor point.

[0147] Step 7.1.2: Use digital lead anchors to link the data of the main product at each stage in a lead-based manner to construct digital leads for the main product;

[0148] The clue-based association is carried out in the following order:

[0149] ① Assign a unique digital clue identifier to each digital clue anchor point, establish an identifier mapping relationship between digital clue identifiers and logical identifier nodes, and realize the association between digital clue anchor points and data;

[0150] ② For the data associated with each digital thread anchor point, sort and connect them according to the life cycle stage of data generation (design → manufacturing → assembly → testing → operation and maintenance) and data timestamp, forming a data evolution link describing the product object from design to operation and maintenance under the digital thread anchor point;

[0151] ③ After sorting and concatenation, based on the bloodline relationship in the data bloodline relationship model constructed in step 4, a causal evolution link is established between data in adjacent stages, so that the data evolution link not only has temporal sequence, but also causal traceability.

[0152] Ultimately, all digital lead anchors in the main product structure tree, their respective data evolution links, and the product structure hierarchy relationships between digital lead anchors together constitute the main product digital lead.

[0153] Step 7.2: By inheriting and differentiating the digital clues of the main product, the digital clues of the derived model product are obtained;

[0154] Based on the derived model product structure tree constructed in step 5, a digital clue inheritance and differentiation mechanism is adopted to inherit and differentiate the digital clues of the main product, thereby obtaining the digital clues of the derived model product.

[0155] The aforementioned digital clue inheritance and differentiation mechanism works as follows: without altering the derived product structure tree in step 5, only the structural nodes that have changed in the derived product structure tree and their associated data are established with independent data evolution links; nodes that have not changed retain the data evolution links corresponding to the main product. Through this digital clue inheritance and differentiation mechanism, differentiated construction of digital clues for derived products is achieved, avoiding data redundancy.

[0156] Step 7.3: Add version and status identifiers to the data design baseline, manufacturing batch and operation and maintenance phase associated with the digital clue to support the update of the digital clue and the traceability of the version;

[0157] Step 7.4, Visualize the digital cue model;

[0158] This step is based on the digital clue model to build a digital clue visualization interface to support the full lifecycle traceability and analysis of multiple product models. It is used to display and interactively access product structure nodes and their related data in multiple dimensions, so that users can understand and utilize digital clues.

[0159] The visualization interface is constructed in the following ways:

[0160] ① Graphical rendering of product structure tree: The product structure tree is displayed graphically in the form of a tree diagram or hierarchical diagram, supporting the expansion, collapse and positioning of nodes;

[0161] ② Timeline rendering of data evolution chain: Display the data evolution chain under a single digital clue anchor point in the form of a timeline, with the horizontal axis representing the life cycle stage or timestamp, and the vertical axis representing data attributes or status;

[0162] ③ Annotation and rendering of changes and anomalies: Visually distinguish nodes that have changed or are abnormal by using color coding, icon annotation, or highlighting.

[0163] ④ Rendering the relationship graph of the data chain: Based on the data lineage model, the dependencies and evolution paths between data are displayed in a directed graph format. The visualization interface should have at least the following functions:

[0164] ① Evolutionary tracing function based on the time dimension:

[0165] It supports displaying the historical data evolution process of any product model, structural node, or component in the design, production, assembly, testing, and operation and maintenance stages in a timeline format;

[0166] It supports comparison and viewing at different points in time or between different versions to identify changes in structure, attributes, and process data.

[0167] ② Hierarchical navigation functionality based on structural dimensions:

[0168] It supports using the product structure tree as the navigation entry point to expand and locate the whole machine, system, subsystem and component nodes step by step;

[0169] When any structural node in the product structure tree is selected, the digital clue data associated with that structural node is displayed, including design data, process data, quality data, test data, and operation and maintenance data.

[0170] ③ Change log and difference highlighting function:

[0171] Visually identify nodes where changes occur in product structure, attributes, or configuration;

[0172] It supports displaying the differences in data before and after the change, the time of the change, and the source of the change, to assist in change analysis and auditing.

[0173] ④ Affects the display of links and relationships:

[0174] Based on the digital clue model and change logic mapping table, it supports displaying the scope of impact caused by a change in a structural node or data in the product structure tree, including the affected downstream structural nodes, bill of materials view and derived models.

[0175] Present the dependencies and propagation paths between data in the form of links or relationship diagrams.

[0176] ⑤ Status and anomaly information visualization function:

[0177] Supports displaying the data status and anomaly indicators for each node in a digital clue;

[0178] When there are data anomalies or unprocessed changes, the corresponding nodes are prompted or marked to assist in subsequent collaborative processing and problem localization.

[0179] The order of steps 6 and 7 above can be interchanged.

[0180] Step 8: Establish a data quality constraint monitoring mechanism based on logical identifier nodes and lineage relationship models.

[0181] A data quality constraint monitoring mechanism is established for the data linked through logical identifier nodes in the unified product data view constructed in step 3. This mechanism includes consistency constraint monitoring, integrity constraint monitoring, and timeliness constraint monitoring. The monitoring process relies on the data lineage model constructed in step 4 to trace the root causes and locate anomalies in data that violates constraints. When a violation of data quality constraints is detected, data anomaly information associated with the corresponding lineage node and logical identifier node is generated for subsequent data change analysis, problem localization, and data repair.

[0182] in:

[0183] Consistency constraint monitoring is used to check whether data remains consistent and consistent across different business systems, stages, and product data views. For example, if a part is labeled as "Inconel 718" in the design phase PLM, but the actual material usage record for the part is "Inconel 718Plus" in the manufacturing phase MES, data anomaly information associated with the corresponding lineage node and logical identifier node of the part will be generated, and an alarm will be issued to indicate that there is a discrepancy in the part labeling.

[0184] Integrity constraint monitoring is used to verify the integrity of the business chain, such as whether data from critical stages or key nodes is missing. For example, if a part has completed manufacturing and entered the assembly stage, but its quality inspection data is missing and not associated with the corresponding logical identifier node, it indicates a violation of integrity constraints. This generates data anomaly information associated with the part's corresponding lineage node and logical identifier node, and issues an alarm indicating missing data in the quality inspection process.

[0185] Timeliness constraint monitoring is used to check whether data is updated in a timely manner and has not expired. If a design change has occurred, but the manufacturing BOM view in MES still uses the old version, it indicates a violation of the timeliness constraint. Data anomaly information associated with the lineage node and logical identifier node corresponding to the design change will be generated, and an alarm will be issued to indicate that the data has not been updated synchronously with the design change.

[0186] Step 9: Establish a mechanism for identifying and analyzing changes in the product structure tree.

[0187] When the structure tree, bill of materials view, or associated lifecycle data of the main product or any derived product changes, in order to assess the scope of the change and guide subsequent design and business collaboration decisions, this step, based on the digital clue model built in step 7, the change logic mapping table established in step 5.2.2, and the bill of materials view established in step 6, identifies the scope of the change and the affected related objects, and generates corresponding impact analysis results.

[0188] Step 9.1, Change type identification;

[0189] First, identify the type of change, which includes at least the following types:

[0190] ① Design Change: A structural node or attribute in the product structure tree changes. For example, the material of the turbine blades in the main product changes from Inconel 718 to Inconel 718Plus;

[0191] ② Process Change: The manufacturing process or processing method changes. For example, if the processing method of a part changes from traditional casting to additive manufacturing, the PBOM and MBOM need to be updated simultaneously.

[0192] ③ Supplier / Material Changes: The source of supply for components or the specifications of materials change. For example, if the supplier of a standard part is changed and the new supplier has a different material code, the material code of the corresponding node in the Bill of Materials (BBOM) needs to be updated, and the node mapping relationship between the BBOM and other bill of materials views such as EBOM and MBOM needs to be updated simultaneously.

[0193] ④ Changes driven by quality issues: Structural or process adjustments due to batch quality defects or test failures. For example, if a batch of parts fails fatigue testing, it may be necessary to go back to the design stage and modify the wall thickness parameters.

[0194] ⑤ Changes driven by operation and maintenance feedback: Design improvements resulting from field operation data feedback. For example, a certain component frequently experiences excessive wear during operation, requiring design improvements or adjustments to the maintenance cycle;

[0195] ⑥ Regulatory / Standard Changes: Adaptive modifications resulting from updates to industry standards or regulations. For example, a new airworthiness standard requires a component to meet higher fatigue life standards, necessitating re-verification or design modifications.

[0196] Step 9.2, Identify the scope of impact of the change;

[0197] Based on the change logic mapping table established in step 5.2.2, the mapping relationship between the bill of materials views established in step 6, and the digital clue model constructed in step 4, the scope of impact of the change is comprehensively identified.

[0198] Specifically:

[0199] Based on the change logic mapping table, identify the scope of change propagation across multiple product models:

[0200] When a node in the main product's structure tree changes, the system checks if any derived models inherit the structure of that changed node. If so, and the node is not marked as a variant node in the derived model's structure tree (i.e., the node uses the main product's structure in the derived model), the change is propagated to the corresponding derived model's structure tree. If the node is marked as a variant node in a derived model's structure tree (i.e., the derived model uses a replacement structure), the changed node in the main product's structure tree is marked as "requires manual evaluation." For example, if the turbine blade material of the main product CFM56-5B changes, and the derived model CFM56-5B1 uses the same blade (not a variant node), the change propagates automatically. However, if the derived model CFM56-5B2 has replaced the blade with an improved version (a variant node), a manual assessment is required to determine whether to synchronize the change.

[0201] Simultaneously, based on the mapping relationship between the bill of materials (BOM) views, the impact of changes on each BOM view is identified. For example, if a design change causes a change in the attribute of a node in the EBOM, the mapping relationship between EBOM and MBOM can be used to identify that the corresponding manufacturing unit in the MBOM needs to have its process route updated synchronously.

[0202] Furthermore, based on the digital cue model, the upstream and downstream data dependencies of changes can be traced to identify affected related data. For example, if the design parameters of a part change, the digital cue model can be used to trace downstream to identify that process parameters, manufacturing batch data, and quality inspection data that depend on the design parameters may all be affected and need to be evaluated or updated synchronously.

[0203] Step 9.3: Generate the impact analysis results;

[0204] Based on the identification results of steps 9.1 and 9.2 above, the impact analysis results are generated, including at least: a list of affected product structure tree nodes, a list of affected derived models, a list of affected bill of materials views, and handling suggestions for each affected object (such as automatic synchronization / manual evaluation required / cascading propagation / unaffected).

[0205] When conducting change impact analysis, the data quality constraint monitoring mechanism established in step 8 also needs to be used to monitor the generated data anomaly information. If anomaly information exists, the anomaly node is marked as pending and displayed in the impact analysis results to assist in design decisions and business collaboration.

[0206] Step 10: Based on the full lifecycle digital clue model, change identification and impact analysis mechanism, and data quality constraint monitoring mechanism, conduct cross-stage and multi-model product collaborative management and cross-departmental collaborative support.

[0207] Based on the full lifecycle digital clue model constructed in step 7, the full lifecycle data of digital clue anchors and their associated product objects are used to achieve collaborative management and control between the design, production, assembly, testing and operation and maintenance stages, as well as between the main product and derived model products.

[0208] Reference Figure 4 The execution process for collaborative management and control is as follows:

[0209] When information changes occur during the product lifecycle (such as design changes, process changes, quality issue feedback, etc.), the process first enters the rule matching stage. Based on the digital clue model and the change identification and impact analysis mechanism established in step 9, the change type is identified, and the scope of impact and the responsible departments affected are determined. Then, the task allocation stage begins, where processing tasks are automatically assigned to relevant responsible departments such as design, process, production, quality, or operations and maintenance, according to the change type and scope of impact. After completing the task, the relevant departments provide feedback on the execution results. Subsequently, the execution results are judged for anomalies: if the execution results are abnormal (such as inconsistent data, incomplete processing, or correlation with the data anomaly information detected and prompted by the data quality constraint monitoring mechanism established in step 8), the anomaly handling stage begins, where the relevant responsible departments correct the errors and resubmit the execution results until the anomaly is eliminated. If the execution results are not abnormal, the data write-back stage begins, where the execution results and corrected data are written back to the product structure tree and digital clue model. Finally, the status update stage begins, where the version and status identifier of the digital clue anchor points and their associated data are updated, thus completing a complete collaborative control closed-loop process.

[0210] Specifically, collaborative management and control includes the following three dimensions:

[0211] ① Cross-stage collaborative management and control:

[0212] Since the data associated with each digital clue anchor point in the digital clue model established in this invention has been sorted and linked according to its life cycle stage, and a causal evolution link has been established between the data of adjacent stages, and the change identification and impact analysis mechanism established in step 9 is based on the digital clue model, when the product attributes, structure or process data of any stage changes, the digital clue anchor points, related data and responsible departments in the upstream and downstream stages of that stage can be identified based on the digital clue model and the change identification and impact analysis mechanism in step 9. In this way, corresponding collaborative processing task instructions can be generated and sent to the relevant responsible departments to achieve cross-stage collaborative management and control.

[0213] During the collaboration process, collaborative operations and change information are recorded in real time and attached to the corresponding digital clue anchor points in the digital clue model, forming a control trajectory that can be traced back to history, tracked for responsibility, and audited for data.

[0214] ② Multi-model collaborative management and control:

[0215] For derivative product models, the change logic mapping table established in step 5.2.2 and the digital clue inheritance and differentiation mechanism described in step 7.2 are used to automatically transfer changes from the main product to the derivative product models. The derivative product models only generate new data evolution links at the change points, while the rest use the digital clues of the main product, ensuring the consistency of structure and data and the controllability of differences among multiple product models.

[0216] ③ Cross-departmental collaborative support:

[0217] The digital lead model is integrated with the business systems of various departments to establish cross-departmental collaboration rules. When changes occur in the design, process, production, quality, or operations departments, the task is automatically assigned to the relevant departments based on the change type and impact scope identified by the product structure tree change identification and impact analysis mechanism in step 9. After the collaborative processing is completed, the results and corrected data are written back to the product structure tree and digital lead model, thereby achieving a closed loop of cross-departmental collaborative management.

[0218] During collaborative management, if the digital clue anchor point is associated with data anomaly information detected by the data quality constraint monitoring mechanism established in step 8, the data anomaly information will be pushed to the relevant responsible departments through the message notification interface connected to each business system. Anomaly handling or confirmation will be performed before triggering change transmission or data update to ensure data consistency and security of multi-model collaboration.

[0219] During the collaborative management process, when the product structure or attributes change, the impact analysis results generated by the product structure tree change identification and impact analysis mechanism in step 9 are used to determine the affected digital clue anchors. A new clue version is formed for the affected digital clue anchors and their associated data, and the traceability of historical versions is maintained, providing a foundation for subsequent cross-stage collaborative management.

Claims

1. A method for collaborative management and control of the lifecycle of multiple product models based on digital cues, characterized in that, Including the following steps: Step 1: Collect multi-source heterogeneous data from multiple product models throughout their entire lifecycle, and add data classification tags to form the original dataset; Step 2: Perform non-destructive data cleaning on the original data, and then perform unified structure and unified semantic processing; Step 3: Associate the data in Step 2 that point to the same product object through a unique logical identifier node to form a unified product data view; Step 4: Construct a data lineage model; Step 5: Construct a multi-model product structure model, including a main product structure tree and a derived model product structure tree. The main product structure tree is constructed based on the product objects in the unified product data view, according to the hierarchical relationship of products, subsystems, and components. The method for generating the derived model product structure tree is as follows: define model derivation rules; establish a change logic mapping table between the main product and the derived model products based on the model derivation rules; inherit the unchanged structural nodes and associated data in the main product structure tree, and perform structural replacement, structural addition, deletion, and / or attribute changes on the variant nodes according to the change logic mapping table to obtain the derived model product structure tree. Step 6: Construct the bill of materials view for each business stage, and establish its node mapping relationship, attribute conversion rules and conversion trigger conditions; Step 7: Establish and visualize the full lifecycle digital lead model, and add version and status identifiers to the associated data design baseline, manufacturing batch, and operation and maintenance stage. The full lifecycle digital lead model includes the main product digital lead and the derivative product digital lead. The main product digital lead is built based on the main product structure tree. The method for establishing the derivative product digital lead is as follows: keep the derivative product structure tree unchanged, establish independent data evolution links for the structural nodes that have changed and their associated data, and use the data evolution links corresponding to the main product for the remaining structural nodes. Step 8: Based on the data lineage model, establish a data quality constraint monitoring mechanism for the data in the unified product data view, including consistency, integrity, and timeliness constraint monitoring; Step 9: Based on the digital clue model, change logic mapping table, and bill of materials view, establish a product structure tree change identification and impact analysis mechanism, including change type identification, change impact scope identification, and impact analysis result generation; The impact analysis results are generated based on the change type identification results, the change impact scope identification results, and the data anomaly information monitored by the data quality constraint monitoring mechanism in step 8. Step 10: Based on the full lifecycle digital clue model, data quality constraint monitoring mechanism, and product structure tree change identification and impact analysis mechanism, conduct cross-stage and multi-model product collaborative management and cross-departmental collaborative support. Steps 6 and 7 can be interchanged; step 4 can also be performed after the digital clue model is built and visualized, but before the data quality constraint monitoring mechanism is established.

2. The multi-model product lifecycle collaborative management method based on digital clues according to claim 1, characterized in that, In step 1, add data category tags according to data source, product model, life cycle stage, and data structure type.

3. The multi-model product lifecycle collaborative management method based on digital clues according to claim 1, characterized in that, In step 2, non-destructive data cleaning refers to the process of cleaning data without overwriting or deleting the original data. Instead, it generates a corresponding data version identifier for the cleaned data and establishes a relationship between the cleaned data and the original data.

4. The multi-model product lifecycle collaborative management method based on digital clues according to claim 1, characterized in that, Step 3 specifically involves: Step 3.1: Establish the product master data model; Step 3.2: Based on the product master data model, parse and match the data processed in Step 2, and determine whether different data points to the same product object based on the matching results; Step 3.3: For data identified as pointing to the same product object, construct a unique logical identifier node for it; the logical identifier node includes logical identifier number, product object type identifier, main model identifier and derived model identifier, cross-system mapping information and lifecycle stage identifier; Step 3.4: Associate the scattered data pointing to the same product object with the corresponding logical identifier node to form a unified product data view.

5. The multi-model product lifecycle collaborative management method based on digital clues according to claim 1, characterized in that, The data lineage model constructed in step 4 includes lineage nodes and lineage relationships. Lineage nodes are used to describe the existence of data in different lifecycle stages, different processing states, and different logical identifier nodes, including original data nodes, processed data nodes, and associated data nodes. Lineage relationships are used to describe the dependency paths between lineage nodes, including source relationships, transformation relationships, association relationships, and version evolution relationships.

6. The multi-model product lifecycle collaborative management method based on digital clues according to claim 1, characterized in that, In step 5, each node in the main product structure tree corresponds to a logical identifier node and a product object that is uniformly identified by that logical identifier node.

7. The multi-model product lifecycle collaborative management method based on digital clues according to claim 1, characterized in that, The bill of materials (BOM) views constructed in step 6 include Engineering Bill of Materials (EBOM), Design Bill of Materials (DBOM), Process Bill of Materials (PBOM), Manufacturing Bill of Materials (MBOM), and Purchasing Bill of Materials (BBOM); the node mapping relationship is used to define the correspondence between nodes in different BOM views, including one-to-one mapping, one-to-many mapping, and many-to-one mapping; Attribute conversion rules are used to define the mapping and supplementary content of attribute fields during the conversion of the bill of materials view; conversion trigger conditions are used to define the triggering method of the bill of materials view conversion, including manual triggering and event triggering.

8. The multi-model product lifecycle collaborative management method based on digital clues according to claim 1, characterized in that, The method for constructing the digital lead model for the main product in step 7 is as follows: define each node in the main product structure tree as a digital lead anchor point; use the digital lead anchor points to link the data of each stage of the main product in a lead-based manner to construct the digital lead of the main product. The method of clue-based association is as follows: Each digital clue anchor is assigned a unique digital clue identifier, and an identifier mapping relationship between the digital clue identifier and the logical identifier node is established to realize the association between the digital clue anchor and the data; For the data associated with each digital lead anchor, sort and connect them according to the life cycle stage of the data generation and the data timestamp to form a data evolution link describing the product object from design to operation and maintenance under the digital lead anchor; Based on the data processing dependencies and source relationships recorded in the data lineage model, a causal evolution link is established between data in adjacent stages, so that the data evolution link not only has temporal sequence, but also causal traceability.

9. The multi-model product lifecycle collaborative management method based on digital clues according to claim 1, characterized in that, The method for identifying the scope of impact of changes in step 9 is as follows: based on the change logic mapping table, identify the scope of the change's propagation among multiple product models; based on the mapping relationship between bill of materials views, identify the impact of the change on each bill of materials view; Based on the digital clue model, the upstream and downstream data dependencies of the changes are traced, and the affected related data is identified. The impact analysis results in step 9 include a list of affected product structure tree nodes, a list of affected derived models, a list of affected bill of materials views, processing suggestions for each affected object, and data anomaly information generated using the data quality constraint monitoring mechanism.

10. The multi-model product lifecycle collaborative management method based on digital clues according to claim 1, characterized in that, The specific process for cross-stage, multi-model product collaborative management and cross-departmental collaborative support in step 10 is as follows: When information changes occur during the product lifecycle, rule matching is first performed, that is, based on the digital clue model and the change identification and impact analysis mechanism, the change type is identified and the scope of impact and the responsible departments affected are determined; then, the task allocation stage is entered, and the processing tasks are automatically assigned to the relevant responsible departments according to the change type and scope of impact; after the relevant responsible departments complete the tasks, they provide feedback on the execution results; subsequently, the execution results are judged for anomalies: if there are anomalies in the execution results, the anomaly handling stage is entered, and the relevant responsible departments correct and resubmit the execution results until the anomalies are eliminated; If the execution result is normal, the data write-back process will begin, and the execution result and corrected data will be written back to the product structure tree and digital lead model. Finally, the status update stage is entered, where the version and status identifier of the digital clue anchor and its associated data are updated.

Images