Discrete manufacturing multi-view BOM dynamic derivation method and system based on tree-shaped net structure

Abstract

The invention discloses a discrete manufacturing multi-view BOM dynamic derivation method and system based on a tree-shaped network structure, and belongs to the technical field of intelligent manufacturing and product data management. The method comprises the following steps: constructing a tree body as a single product data source, and storing a hierarchical relationship, attribute definition and engineering semantics of a product in a tree structure; based on the tree body, dynamically matching derivation rules through a mesh mapping relation library; executing rule matching, semantic verification, structure reconstruction and dictionary verification by utilizing a dynamic view derivation engine to generate a target BOM view; semantic constraint and verification are carried out on the derivation process through a BOM data dictionary module; and realizing access control and audit based on role, scene and data sensitivity through the security and authority control module. According to the method, a new generation of xBOM dynamic derivation architecture which takes a tree form as an ontology, takes a net form as mapping, is configurable in rule and is strong in data specification is constructed; the fundamental problem of discrete manufacturing multi-view BOM management is solved, and engineering rationality and service flexibility are both achieved.

Description

Technical Field

[0001] This invention relates to the field of intelligent manufacturing and product data management technology, and more specifically to a dynamic derivation method and system for discrete manufacturing multi-view bill of materials (BOM) based on a tree-like network structure. It is applicable to the full lifecycle management of complex products in discrete manufacturing industries such as automobiles, aerospace, and high-end equipment, which are oriented towards mass customization, modular design, and flexible production. Background Technology

[0002] In discrete manufacturing, the Bill of Materials (BOM), as the core data carrier spanning product design, process planning, manufacturing, procurement, and logistics, directly determines an enterprise's collaborative efficiency and responsiveness through its multi-view (xBOM) management capabilities. Traditional BOM models generally use pure tree structures (such as single-level or multi-level BOMs) to describe product assembly relationships. While these structures clearly express hierarchical relationships, they struggle to effectively depict the network of dependencies, such as components being repeatedly borrowed or reused across multiple assembly paths. This "one item, multiple parents" scenario is particularly prevalent in modular design. Forcibly flattening or copying nodes will lead to data redundancy, version inconsistencies, and difficulties in maintaining consistency.

[0003] To overcome the limitations of tree-based representation, recent research has attempted to reconstruct the Bill of Materials (BOM) by introducing semantic networks or ontology models. These methods abstract BOM elements into nodes and relationships within a knowledge graph, achieving xBOM transformation through ontology reasoning. However, by modeling the BOM ontology as a general graph, they neglect the historical rationale and engineering universality of tree structures as a natural ontology in manufacturing. Tree structures not only conform to the top-down decomposition logic of products but also highly align with native models in industrial software such as CAD assembly trees and PLM product structure trees. Semantic modeling divorced from tree ontology can easily lead to a disconnect between the transformation results and actual engineering practices, and is difficult for manufacturing engineers to intuitively understand and maintain.

[0004] Another mainstream approach relies on predefined static mapping rules to achieve xBOM conversion. Typical practices include: developing hard-coded topology operation operators (such as node copying, deletion, and splitting) for special structures such as assemblies, split components, outsourced components, and virtual components. Although this approach can handle specific scenarios, it has significant drawbacks: (1) the rules are strongly coupled with business logic, making it difficult to adapt to dynamic scenarios such as multiple factories, multiple orders, and multiple configurations; (2) the view derivation process lacks unified data source support, and manual intervention is required to synchronize multiple views when engineering changes occur, which can easily lead to data inconsistency; (3) attribute mapping (such as process parameters and manufacturing resources) is separated from structural conversion, making it impossible to achieve collaborative dynamic derivation of structure and attributes.

[0005] In summary, existing technologies have shortcomings in both ontology modeling paradigms and dynamic derivation mechanisms: they either adhere to pure tree structures at the expense of expressive power, generalize to semantic graphs and deviate from engineering ontology, or rely on static rules and lose configuration flexibility. Especially in the context of discrete manufacturing facing challenges such as mass customization, rapid iteration, and multi-factory collaboration, there is an urgent need for a BOM management framework that can both use a tree structure as the authoritative ontology and achieve dynamic derivation of multiple views through network associations, so as to balance data standardization, structural rigor, and business flexibility. Summary of the Invention

[0006] The purpose of this invention is to provide a method and system for dynamic derivation of discrete manufacturing multi-view BOMs based on a tree-like network structure. By constructing a tree-like network fusion structure, the tree is used as the sole data source for the BOM ontology. Through embedded configuration rules, semantic relationships, and a data dictionary, on-demand, dynamic, and traceable derivation of multiple views such as EBOM, PBOM, and MBOM is achieved, thereby solving the fundamental defects of existing technologies in terms of structural expression, dynamic configuration, and consistency assurance.

[0007] To achieve the above objectives, the present invention adopts the following technical solution: In a first aspect, embodiments of the present invention provide a method for dynamic derivation of discrete manufacturing multi-view BOMs based on a tree-like network structure, comprising the following steps: Construct a tree ontology as a single product data source, and store the product's hierarchical relationship, attribute definition, and engineering semantics in a tree structure; Based on the tree ontology, derivation rules are dynamically matched through a network mapping relationship library. The network mapping relationship library includes a configuration rule sub-library and a semantic graph sub-library. The configuration rule sub-library handles regular derivation scenarios, while the semantic graph sub-library handles scenarios with missing or conflicting rules. The dynamic view derivation engine is used to perform rule matching, semantic validation, structural reconstruction, and dictionary validation to generate the target BOM view. The derivation process is semantically constrained and validated using the BOM data dictionary module. Access control and auditing based on roles, scenarios, and data sensitivity are implemented through the security and access control module.

[0008] In one embodiment, the tree ontology is formalized as a seven-tuple. Store data; in, It is a set of nodes, each with a unique ID; Let be a set of directed edges. For a collection of node attributes, To configure the validity set, A set of timestamps For data dictionary constraint identifiers, This is a pointer to a semantic relationship.

[0009] In one embodiment, each semantic relation pointer in the tree ontology is used to point to the corresponding rule or semantic path in the network mapping relation library.

[0010] In one embodiment, the configuration rule sub-library stores rule triples <context, operator, attribute mapping function>; wherein, the context includes four-dimensional combination encoding; the operators include split, merge, add, replace, and delete operators; and the attribute mapping functions include inheritance, derivation, and conversion functions.

[0011] In one embodiment, the semantic graph sub-library adopts a hierarchical architecture of description logic and graph neural networks, and calculates recommendation rules through semantic similarity. The semantic similarity formula is as follows:

[0012] in, For graph rules entities; context-graph is the derived scene graph mapping; This is a TransR-specific embedded function used for rule recommendation.

[0013] In one embodiment, the dynamic view derivation engine is based on tree ontology and mesh mapping logic, supporting incremental derivation and full derivation; incremental derivation only processes changed nodes and their downstream associated subtrees, while full derivation processes the entire BOM structure. Time complexity calculation for full derivation: , Time complexity calculation for incremental derivation: ; Space complexity calculation: It only stores view references; in, This indicates the total amount of data or the total number of entities that need to be processed when performing a full derivation. This represents the average cost of a single match or derivation operation. This indicates the amount of data that changes or is added during incremental derivation; ΔN ≤ 0.1N indicates that the underlying assumption is that incremental derivation is only effective when the amount of change is small. This indicates the size or complexity of the set of rules used to perform derived operations.

[0014] In one embodiment, the BOM data dictionary module constructs a three-level dictionary system based on national standards, industry standards, and enterprise standards, and implements triple checks on format, value range, and dependency, blocking illegal values ​​in real time and returning error codes.

[0015] In one embodiment, the security and access control module adopts a three-dimensional access control model based on roles, scenarios, and data sensitivity, and the access control decision formula is as follows:

[0016] Among them, Permit-sec (User-sec, View-sec, Attr-sec) represents a final access permission decision; User-sec represents the user security context; View-sec represents the view / scene security context; Attr-sec represents the attribute security context; RoleMatch-sec represents role matching; SceneMatch-sec represents scene matching; SensitivityMatch-sec represents sensitivity matching.

[0017] In a second aspect, embodiments of the present invention provide a dynamic derivation system for discrete manufacturing multi-view BOMs based on a tree-network structure, implementing the method described in any of the first aspects, the system comprising: The tree ontology storage module is used to store tree ontology as an authoritative data source; The network mapping relation library includes a configuration rule sub-library and a semantic graph sub-library, which are used to provide derivation logic; The dynamic view derivation engine is used to perform view derivation operations; The BOM data dictionary module is used to implement data specification verification. The security and access control module is used for managing permissions and security auditing.

[0018] As can be seen from the above technical solution, compared with the prior art, the present invention has the following technical advantages: 1. Construct a unified, authoritative, and traceable BOM ontology data source; This invention uses a tree structure as the BOM ontology, fully encompassing the hierarchical relationships, quantity dependencies, attribute definitions, and engineering semantics of a product from top-level assembly to bottom-level components, forming a single product data source. This ontology structure conforms to centuries of engineering practices in the manufacturing industry and is naturally aligned with CAD assembly trees and PLM product structure trees, ensuring the standardization, completeness, and engineering understandability of the data source, and avoiding the "information silos" and version conflicts caused by traditional multi-source BOMs.

[0019] 2. Enable dynamic, on-demand, and configurable derivation of multiple service views (xBOM); Based on a unified tree ontology, this invention uses embedded configuration rules, semantic mapping relationships, data dictionaries, and semantic graph sub-libraries to take the network structure as the logical carrier for view transformation, dynamically deriving BOM views that meet the needs of different business domains. The derivation process does not require copying or redundant storage, but is achieved through rule-driven "logical association mapping", supporting flexible trimming and reorganization in scenarios with multiple factories, multiple orders, and multiple configurations.

[0020] 3. Supports automatic synchronization and consistency assurance of engineering changes; When design changes occur, such as component replacement, structural adjustments, or attribute updates, this invention automatically triggers incremental derivation and consistency checks of downstream views based on the unique data source of the tree-structured ontology. This avoids omissions or errors caused by manual intervention, significantly improving change response efficiency and data reliability.

[0021] 4. Strengthen data standardization, compliance with standards, and security control to ensure that all attributes (such as part codes) comply with national standards and avoid ambiguity.

[0022] 5. Manage access permissions to ensure data security.

[0023] In summary, this invention not only solves the core pain points of traditional xBOM management, such as "structural distortion, rigid rules, weak consistency, and lack of standards," but also provides discrete manufacturing enterprises with a set of highly cohesive, loosely coupled, scalable, and auditable multi-view BOM dynamic derivation infrastructure through a technical path of "tree structure as ontology, network as mapping, dictionary as specification, and security as boundary." It is widely applicable to complex product manufacturing fields such as automobiles, aerospace, high-end equipment, and engineering machinery. Attached Figure Description

[0024] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0025] Figure 1 This is a flowchart of the discrete manufacturing multi-view BOM dynamic derivation method based on a tree-network structure provided in this embodiment of the invention. Figure 2 This is a diagram illustrating the collaborative architecture and data flow of the five modules of the system provided in this embodiment of the invention. Figure 3 This is a flowchart of the dynamic derivation algorithm provided in the embodiments of the present invention; Figure 4 This is the complete process from raw data input to target view output provided in this embodiment of the invention. Detailed Implementation

[0026] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0027] This invention provides a dynamic derivation method for multi-view BOMs in discrete manufacturing based on a tree-like network structure, which is mainly used for complex product lifecycle data management scenarios in discrete manufacturing that are oriented towards mass customization, modular design and flexible production.

[0028] Reference Figure 1 As shown, this embodiment of the invention discloses a dynamic derivation method for discrete manufacturing multi-view BOM based on a tree-like network structure, including the following steps S1~S5: S1. Construct a tree ontology as a single product data source, and store the product's hierarchical relationship, attribute definition, and engineering semantics in a tree structure; This step constructs a unified, authoritative, and traceable BOM ontology data source, using a tree structure as the BOM ontology. It fully carries the hierarchical relationships, quantity dependencies, attribute definitions, and engineering semantics of the product from top-level assembly to bottom-level components, forming a single product data source. This ontology structure conforms to centuries of engineering practices in the manufacturing industry and is naturally aligned with CAD assembly trees and PLM product structure trees, ensuring the standardization, completeness, and engineering understandability of the data source, avoiding the "information silos" and version conflicts caused by traditional multi-source BOMs. Specifically, it stores the static structure (nodes / edges / attributes) and semantic pointers throughout the product's entire lifecycle, providing a 'unique data source' for dynamic derivation and solving the redundancy problem of traditional multi-source BOMs. S2. Based on the tree-shaped ontology, the derivation rules are dynamically matched through a mesh mapping relationship library. The mesh mapping relationship library includes a configuration rule sub-library and a semantic graph sub-library. The configuration rule sub-library handles regular derivation scenarios, and the semantic graph sub-library handles scenarios with missing or conflicting rules. This realizes the transformation of static ontology into dynamic derivation logic, supporting the core requirements of multi-scenario adaptation. Based on a unified tree ontology, this step uses embedded configuration rules, semantic mapping relationships, data dictionaries, and semantic graph sub-libraries to dynamically derive BOM views that meet the needs of different business domains, including but not limited to: Design BOM (EBOM): oriented towards product structure design, synchronized with 3D CAD model; Process BOM (PBOM): oriented towards process route planning, supporting special structure mapping such as assemblies, subdivided parts, and virtual parts; Manufacturing Bill of Materials (MBOM): oriented towards shop floor production execution, it includes manufacturing semantics such as intermediate parts, sequential parts, and outsourced parts; After-sales Bill of Materials (SBOM): For after-sales repair and spare parts management; The derivation process does not require copying or redundant storage, but is achieved through rule-driven "logical association mapping", supporting flexible trimming and reorganization in scenarios with multiple factories, multiple orders, and multiple configurations.

[0029] S3. Utilize the dynamic view derivation engine to perform rule matching, semantic verification, structural reconstruction, and dictionary validation to generate the target BOM view; When design changes occur, such as component replacement, structural adjustments, or attribute updates, this invention automatically triggers incremental derivation and consistency checks of downstream views based on the unique data source of the tree ontology. Through predefined mapping rules and semantic constraints, it ensures dual synchronization of structure and attributes between EBOM→PBOM→MBOM, generating the target BOM view.

[0030] S4. Use the BOM data dictionary module to perform semantic constraints and verification on the derivation process to ensure that the data complies with national standards; This step involves deep integration with national / industry data standards, such as GB / T 24467—2009 "Hierarchical Data Dictionary for General Mechanical Parts Products". The data dictionary imposes strong constraints on the code, attributes, types, and naming of BOM elements, ensuring semantic consistency during cross-system integration.

[0031] S5. Implement access control and auditing based on roles, scenarios, and data sensitivity through the security and access control module.

[0032] By combining data ownership and access control mechanisms, role- and scenario-based permission management is implemented for the BOM ontology and derived views to prevent unauthorized access, tampering, or leakage, thus meeting the compliance requirements of discrete manufacturing enterprises for master data security.

[0033] The following is a detailed explanation of each of the above steps: 1. In step S1, the tree ontology, as a single product data source, only stores the static structure and attributes of the product throughout its entire lifecycle and does not participate in logical calculations. Its core data model is a formalized seven-tuple:

[0034] Definitions and technical details of each element: : A set of nodes, each node has a unique ID, in the format {business domain code}_{level}_{serial number}, such as ENG_02_001; the node type is divided into PHYSICAL (physical node, associated with material code) and VIRTUAL (virtual node, dictionary constraint "material code" is empty) to avoid confusion between physical and virtual nodes.

[0035] : Set of directed edges, triples middle: Parent node ID, such as ENG_01_000, engine assembly; Assembly quantity, a positive integer or variable expression, such as optional equipment. The numerical format must conform to the dictionary standard GB / T 24467::15.030.01.quantity; : Child node ID, such as ENG_02_001, cylinder block assembly; edge attributes additionally store assembly order (SEQ_eng) and tolerance fit (FIT_eng), providing basic data for process design.

[0036] : A collection of node attributes, divided into four mutually exclusive dimensions, with all attributes bound. Logo: Static attributes: Material ID (MATERIAL_ID), Specification (SPEC), Material (MATERIAL), with values ​​conforming to GB / T24467, such as material 45# matching GB / T 24467::21.060.10.material; Structure type attributes: PART_TYPE (enumeration: SELF_MADE / PURCHASED / OUTSOURCED / VIRTUAL) directly determines the downstream process, such as purchasing triggered by externally purchased parts; Version attributes: EFFECTIVE_DATE (effective date), CHANGE_ORDER (change order number), VERSION_BOM (version number), supports multiple versions running concurrently; Domain attributes: Process type (PROCESS_TYPE) and manufacturing station (WORKSTATION) provide dedicated data for specific business domains.

[0037] : Configure the validity set, using first-order logical expressions to describe the node enable conditions, such as:

[0038] When multiple conditions conflict, the resolution is based on the priority of "region > optional package > emission level" (customizable).

[0039] : A set of timestamps, including CREATE_TIME (create), RELEASE_TIME (publish), FREEZE_TIME (freeze), and EXPIRE_TIME (expire), supporting historical version backtracking (e.g., locating the BOM status of a certain batch through FREEZE_TIME).

[0040] Data dictionary constraint identifiers, format GB / T 24467::<classification code>.<attribute code>, such as: The system ensures that attributes conform to the standard value range, automatically verifies them during data entry, and blocks illegal values ​​in real time.

[0041] : A semantic relation pointer, serving as the unique association between a tree-structured ontology node and a network mapping layer. Its format is strictly defined as 'ContextKey::PredicatePath', with a length of 20-60 characters and a character set of letters, numbers, underscores, and double colons. ContextKey: Fully aligned with the context_key-rule in the configuration rule sub-library of the mesh mapping library. The generation logic is as follows: If the node PART_TYPE = "VIRTUAL" (virtual component), then ContextKey = "PBOM_FLATTEN::DELETE_VIRTUAL"; If the node CATIA_LEVEL ≥ 4 and ASSEMBLY_TYPE = "WELD" (deep weldment), then ContextKey = "PBOM_FLATTEN::MERGE_WELD_TIER4_6"; Other nodes have ContextKey = "DEFAULT::BASE_RULE"; PredicatePath: Consists of 1-3 atomic predicates via " (The reasoning path connected by the composite operator, such as...) This indicates that "the node has a process route → the process route is provided by the supplier", directly pointing to the preset inference axiom in the semantic graph sub-library; the semantic pointer is automatically injected through the "PBOM initialization tool" when the tree ontology node is created, and returns ERR_SEM_POINTER_001 when the injection error occurs, ensuring that each node can accurately locate the mapping rule.

[0042] 2. In step S2, the network mapping relation library is the core logical carrier for multi-view derivation. It is responsible for transforming the static structure of the tree ontology into dynamic, executable business views (such as PBOM and MBOM) according to the business context. It adopts a dual-channel architecture of "configuration rule sub-library (main engine)" and "semantic graph sub-library (auxiliary engine)" and follows the linkage mechanism of "rule priority, graph filling, dictionary verification, and automatic fallback". All logical outputs must pass the triple semantic verification of the BOM data dictionary module to ensure the engineering legality and business compliance of the derivation results.

[0043] (1) Configuration rule sub-library: context-driven deterministic derived main channel Functional positioning: It handles more than 80% of high-frequency, standardized derived scenarios, such as virtual component removal, outsourced component splitting by supplier, and welding component hierarchical merging. The rules are organized in the form of triples, and have engineering executability and automatic verification capabilities.

[0044] Rules are stored as triples of "context + operation + attribute mapping":

[0045] Technical details of each element: Four-dimensional combination encoding, such as "PBOM-WH01-CUSTOM-LUXURY", where the "factory code" WH01 must conform to the dictionary GB / T 24467::08.010.02.factory_code enumeration.

[0046] Structure operators include 5 core operations, each with its own formula and parameter identifier: Split operator Split 1 node into Each child node has its attributes distributed proportionally.

[0047] in: (Parent node to be split) (Number of child nodes, 2≤N≤10, conforming to dictionary constraints) (Attribute allocation ratio of the i-th child node, ∑α=1), child nodes inherit from parent nodes. and ; This represents the first child node. This represents the child node with index N_split in the sequence, where N_split is the total number of child nodes.

[0048] merge operator :Will Each node is merged into one aggregate node:

[0049] in: (Number of child nodes to be merged, ≥2) For attribute aggregation functions, such as weight ∑ and material UNION; Represents all child nodes. This represents an aggregation node. The number of edges in the aggregation node is also specified. .

[0050] Add operator Add an intermediate child node to the parent node:

[0051] in: (Target parent node) (Add new node attributes that conform to dictionary constraints), seq-add (assembly order, distinguished from other operation order parameters).

[0052] Replacement operator Virtual nodes are replaced with physical nodes:

[0053] in: (Old node to be replaced) (Target new node), inherit-flag-replace (property inheritance flag, TRUE / FALSE).

[0054] Deletion operator Remove redundant nodes from the view:

[0055] in: (Node to be deleted) and reason-delete (reason for deletion, such as "NOT_NEEDED_IN_MBOM") only apply to the view and do not affect the ontology.

[0056] : Combination of attribute mapping functions, such as: Function parameters and operators are strictly distinguished. For example, `derive(supplier)` associates parent node supplier information through a graph, and `transform(precision)` transforms according to rules, such as design precision IT7 → process precision IT6.

[0057] (2) Semantic graph sub-library: Automatic supplementary channel for missing / conflicting rules; Functional positioning: It handles scenarios with missing or conflicting rules, accounting for about 20%. It does not generate physical structures, but only provides executable logical recommendations, and requires no manual intervention throughout the process.

[0058] It adopts a hierarchical architecture of "Description Logic (DL) + Graph Neural Network (GNN)," and the formulas and parameters are all graph-specific: Example 1: Taking the TransR model, the implementation details of semantic similarity calculation are as an example; 1) Training data Data source: Bill of Materials (BOM) data of an automotive company from 2020 to 2023, containing 100,000 rules, 50,000 node attributes, and 20,000 conflict cases; Preprocessing: ① Rule encoding: Convert four-dimensional fields into 77-dimensional One-Hot vectors (ViewType=4-dimensional, FacID=20-dimensional, OrderType=3-dimensional, ConfigProf=50-dimensional); ② Attribute encoding: Discrete attribute label encoding (SELF_MADE=1), continuous attribute Min-Max normalization to [0,1]; The dataset is divided into three parts: training set (80%), validation set (10%), and test set (10%).

[0059] 2) Model parameters and training

[0060] 3) Convergence conditions and effects Convergence criteria: Validation set accuracy ≥ 92%, training set loss ≤ 0.05, validation set loss ≤ 0.1; Inference time: ≤100ms / inference, rule matching accuracy is 95% when sim_graph≥0.85.

[0061] Example 2: Taking the implementation details of dynamic rule embedding in the GraphSAGE model as an example; 1) Training data and graphs Graph: 100,000 rule entities, 20 node type entities, 526 attribute entities, 200,000 relationships (adaptation / dependency / constraint); Training data: 50,000 manually labeled "rule-graph association tags" (e.g., "EV welding rule → associated WELD node + EV attribute").

[0062] 2) Model parameters and training

[0063] 3) Convergence conditions and effects Convergence criteria: Validation set association accuracy ≥ 88%, training set loss ≤ 0.08; Results: The new rule embedding time was reduced from 24 hours to 10 minutes, and the conflict resolution accuracy rate was 95%.

[0064] In the semantic similarity calculation, taking Example 1 above as an example, the TransR model maps the rules into low-dimensional vectors, as shown in the formula:

[0065] in: For graph rules entities; context-graph is the derived scene graph mapping; This is a TransR-specific embedding function used for rule recommendation.

[0066] Dynamic rule embedding: Based on the GraphSAGE model, it learns the association between new rules and the graph, and the embedding function... It is strictly distinguished from TransR to avoid parameter reuse.

[0067] 3. In step S3, the dynamic view derivation engine, as the core of view generation, executes a four-stage closed-loop process based on tree ontology and network mapping logic: "rule matching → semantic verification → structural reconstruction → dictionary verification," supporting full / incremental derivation. All parameters contain the exclusive "-alg" suffix to prevent reuse and ensure traceability and thread safety.

[0068] in, 1) The full derivation algorithm is as follows: Input parsing: Validate parameters, such as view type, factory code, etc., and output the normalized context Context-alg. Return error codes for invalid parameters, such as ERR_VALID_002. Body traversal: DFS + configured pruning, traversing the root node. Generate a set of temporary nodes With path-alg, the time complexity is... ; Rule matching: Encode context_key-alg, match rule sub-libraries, call graph sub-libraries to verify consistency, and output. ; Structure Restructuring: Executing struct_op to generate ,application Mapping properties; Consistency verification: Four types of dedicated verification methods: Circular references: adjacency matrix Exponentiation, Then a conflict is determined; Orphaned nodes: Check Does it exist in ; Unit conflict: Conversion factor (e.g., kg→g, k=1000) formula: ; Configuration Conflict: Resolution Inspection and The contradiction.

[0069] 2) Incremental Derivation: Detects changed nodes based on a dual verification of 'node attribute hash value + version number'. The detection is triggered by the real-time change monitoring mechanism of the tree-structured ontology storage module (responding within 100ms after the change), locating the downstream related subtree of the changed node. By only processing the changed parts, efficiency is significantly improved; Parallel computing: Dynamic thread pool CorePoolSize-alg, Task-alg split by level, 120,000 nodes generated on an 8-core CPU take ≤90s; Caching mechanism: LRU policy caching The cache hit rate is ≥95%, and the response time is ≤0.5s.

[0070] Complexity Analysis Time complexity: Fully derived , Incremental Derivation ; Space complexity: It only stores view references, reducing storage by 90% compared to traditional full storage.

[0071] Configuration rules and semantic layer integration design: Dual-channel reasoning mechanism: Main channel: Rule-driven, process Context-alg → rule matching → structure reconstruction → output, response time ≤ 1s (10,000 nodes); Auxiliary channel: When rules are missing or conflicting, the graph recommends similar rules or resolves conflicts through sim-graph. After a commercial vehicle company applied this, the processing time for special scenarios decreased from 30 minutes to 5 minutes.

[0072] Rule and graph co-validation When there is a property conflict (e.g., EBOM material = "steel" → PBOM = "aluminum"), the procedure is as follows: The map traces the causes of the conflict (such as "new energy weight reduction requirements"). DL axioms verify the compatibility of "aluminum material + aluminum heat treatment" ( ); We recommend using "material derivation rules," which are executed after dictionary validation and have a conflict resolution accuracy of 98.5%.

[0073] 4. In step S4, the BOM data dictionary module constructs a three-level dictionary system of "country-industry-enterprise" to provide semantic constraints and legality gates for the entire system and ensure data consistency across modules.

[0074] (1) Dictionary structure and parameter binding

[0075] Attribute binding format: Each attribute field is annotated with U_dict = "GB / T 24467::<Classification Code>.<Attribute Code>", such as: "MATERIAL": { "value": "45#", "U_dict": "GB / T 24467::21.060.10.material" } (2) Triple verification mechanism and execution logic Format validation Method: Regular expression matching; Example: MATERIAL_ID must match ^[AZ]{2}[0-9]{8}$; Failure: Returns ERR_FORMAT_001; Value range validation; Method: Enumeration set / Numerical range judgment; Example: split_ratio must satisfy 0 < α ≤ 1 and ∑α = 1; Failure: Returns ERR_VALUE_002; Dependency checking; Method: Logical rule engine (based on Drools or self-developed rule DSL); Example rules: when part.PART_TYPE == "SELF_MADE" then part.supplier_code must be null Failure: Returns ERR_DEPENDENCY_003; Verification timing: Verification during body write; Rule matching validation; Final verification before outputting derived results.

[0076] (3) Interaction logic (semantic hub) Provide attribute constraints (U_dict) for the tree ontology; Provide semantic premises for configuration rules; Provide a namespace for the semantic graph (entity / relation names are derived from dictionary encoding); Provides a final legality gate for derived engines.

[0077] (4) The linkage between the BOM data dictionary module and the core architecture; Step S4, as the "semantic constraint hub" of the core architecture of "dynamic derivation", is embedded in the entire derivation process, and its linkage logic with other layers is as follows: Tree-structured ontology construction phase: Each attribute of an ontology node is bound to a unique U_dict identifier (format: GB / T24467::<classification code>.<attribute code>, such as material being bound to "GB / T 24467::21.060.10.material"). If the attribute value is invalid (such as material = "non-standard steel"), node creation is blocked to ensure the compliance of the basic data of the core architecture. Mesh mapping rule configuration phase: Verify the validity of parameters in the configuration rule sub-library. FacID must conform to the GB / T 24467::08.010.02.factory_code enumeration (such as WH01 / WH02); The N_split of P_split must satisfy 2≤N≤10 (GB / T 24467::15.030.02.split_num); illegal parameters are marked "RULE_ILLEGAL=true" to prevent the rule from taking effect and ensure that the logical configuration of the core architecture is compliant; Dynamic derivation output phase: Perform "triple validation" on the V_view-alg nodes generated by the derivation engine: Format validation: MATERIAL_ID must match the regular expression ^[AZ]{2}[0-9]{8}$; Range verification: split_ratio must satisfy 0 < α ≤ 1 and ∑α = 1; Dependency verification: When PART_TYPE="SELF_MADE" (self-made parts), supplier_code must be null; if verification fails, return ERR_FORMAT_001 / ERR_VALUE_002 / ERR_DEPENDENCY_003, interrupt the derivation process, and ensure that the output of the core architecture is compliant; This step can build a three-level standard system based on GB / T 24467, providing semantic constraints for the first three layers, ensuring the compliance of derived results, and resolving the 'semantic ambiguity' problem.

[0078] 5. In step S5, the security and access control module is embedded in the entire derivation process to achieve field-level desensitization and auditing, ensuring the security of core data; As the 'security protection layer' of the 'dynamic derivation' core architecture, it is embedded in the four key derivation nodes, and the linkage logic is as follows: Derivative request initiation phase (entry point security): Verify whether user permissions conform to the 3D model: RBAC: Verifies whether a user role (such as ProcessEngineer) has the "derive_view" operation permission; ABAC: Verify whether the user's factory (e.g., WH01) and the requested order type (e.g., CUSTOM) match the scenario policy ("WH01 process engineer can only access CUSTOM order BOM"). DAC: Verifies whether the user is in the ACL list of the target BOM node (e.g., the "ENG_02_001" node can only be modified by the design manager); if any verification fails, the request is rejected to ensure the security of the access point of the core architecture; Rule matching phase (logical security): For sensitive rules (such as the P_split rule involving cost splitting), visibility is controlled according to user data sensitivity permissions. CONFIDENTIAL level users: View the complete rules (including cost parameters); INTERNAL level users: Desensitize cost parameters (e.g., 1200.50 → 1***.**); avoid leakage of logical configuration of core architecture; Structure Restructuring Phase (Intermediate Data Security): For sensitive attributes (supplier_code, Cost) involved in the derivation process, field-level desensitization is performed in real time (according to the sensitivity level of the dictionary module). After desensitization, the attributes are only temporarily stored in memory and are not persisted to disk, ensuring the security of intermediate data in the core architecture. Results Output Phase (Traceability and Security): Generate full-link audit logs (including User-sec, Action-sec, Target-sec, Data-sec, and Decision-sec), bind the logs to the VERSION_bom of the derived view, and retain them for ≥3 years to ensure the traceability of core architecture operations.

[0079] Three-dimensional permission model, permission decision formula:

[0080] Where: RoleMatch-sec represents role matching; SceneMatch-sec represents scene matching; SensitivityMatch-sec represents sensitivity matching, all of which contain the suffix "sec"; Security audit: Logs include User-sec / Time-sec / Content-change-sec, are stored for ≥3 years, and have field-level anonymization (e.g., cost "1200.50→1***.**").

[0081] Data backup and disaster recovery Local backup: incremental (hourly) + full (daily), encrypted with AES-256; Off-site disaster recovery: RPO ≤ 1 hour, RTO ≤ 4 hours, automatic verification after recovery. .

[0082] Based on the same inventive concept, this invention also provides a dynamic derivation system for discrete manufacturing multi-view BOMs based on a tree-like network structure, implementing the dynamic derivation method for discrete manufacturing multi-view BOMs based on a tree-like network structure as described in the above embodiments. The system includes: The tree ontology storage module is used to store tree ontology as an authoritative data source; The network mapping relation library includes a configuration rule sub-library and a semantic graph sub-library, which are used to provide derivation logic; The dynamic view derivation engine is used to perform view derivation operations; The BOM data dictionary module is used to implement data specification verification. The security and access control module is used for managing permissions and security auditing.

[0083] Figure 2 This diagram illustrates the collaborative architecture and data flow of the five modules of the system. Its core purpose is to intuitively disclose the module composition, functional boundaries, and data interaction relationships of the "Tree-like Network Structure BOM Dynamic Derivation System" of this invention. It solves the technical problems of "structure and logic coupling and lack of semantic specifications" in traditional BOM systems and is a key view for understanding the overall operation mechanism of the system.

[0084] Among them, the tree-structured ontology storage module serves as the sole authoritative data source, storing the entire product lifecycle structure in the form of a seven-tuple, and its output serves as the starting point for derived logic. Where “VEACTUR” is the tree ontology seven-tuple defined above. The element is abbreviated and labeled "Structure and Semantic Anchor Point" below the module, which clarifies its function as a single product data source - it only stores static structural data of the product (such as parent-child assembly relationships and part attributes), does not participate in logical calculations, and provides a data foundation for the entire system.

[0085] The network mapping relation library is divided into primary and secondary channels: Configuration rules sub-library: marked with "structural operators" Attribute mapping function "Rules are bound to the premise" corresponds to the main engine that handles 80% of the common derived scenarios. Rule triggering depends on the semantic constraints of the BOM data dictionary. Semantic Graph Sub-library: Annotated with "description logic axioms", it is an auxiliary engine that handles 20% of rule-missing / conflicting scenarios, and provides rule recommendation and conflict resolution support through ontology reasoning.

[0086] The BOM data dictionary module interacts bidirectionally with all modules: labeled "BOM Data Dictionary Module," it includes the identifiers "GB / T 24467 / 17645 and other standards, bidirectional verification, attribute validity gate." This module constructs a three-level dictionary system based on national / industry standards, connecting to a tree-structured ontology and a network mapping relational library via bidirectional arrows. It achieves standardized control over the entire process of "attribute constraint binding, rule semantic premise verification, and derived result validity audit," providing U_dict constraint identifiers for the ontology, attribute semantic premises for rules, and a final verification gate for the engine. Dynamic Derivation Engine: Without a separate module box, it is implicitly defined by the link "B Rules and Graph Output → Derived BOM View" as the core of the process execution. It receives the structural data of the tree ontology and the rule / graph results of the network mapping library, and outputs a multi-view BOM. Security and Access Control Module: Labeled as "Data Security Assurance", connected to the "Database", it implements field-level anonymization and end-to-end auditing based on the "RBAC+ABAC+DAC" three-dimensional model to ensure data security and compliance.

[0087] The data flow diagram uses solid arrows to mark the core data flow: tree ontology → network mapping relation library (provides structural data) → dynamic derivation engine (executes derivation) → data security assurance (security control) → database; and uses bidirectional arrows to mark the constraint flow: bidirectional verification between the BOM data dictionary module and the tree ontology and network mapping relation library to ensure cross-module data semantic consistency.

[0088] Figure 3 This is a linear process diagram, primarily used to clearly disclose the execution steps, decision branches, and exception handling logic of the dynamic derivation engine, solving the technical problems of traditional static rule BOMs such as "poor adaptability to multiple scenarios and low efficiency of full derivation".

[0089] Rule matching phase: Matching preset rules based on the input context; Semantic verification phase: The Tableau algorithm is called to detect rule conflicts (such as "split + merge" mutual exclusion), and graph assistance is triggered when a conflict occurs; The process starts from "Start" and proceeds sequentially as follows: "Input Context_alg → Rule Configuration → Query Configuration Rule Sub-library → Match Structure Operators and Attribute Mapping Functions". Here, "Context_alg" is the standardized derived context defined earlier. This stage only completes rule location and does not involve complex calculations, ensuring the accuracy of the process initiation.

[0090] Dictionary verification stage: Triple verification (format, value range, dependency) is implemented through standards such as GB / T 24467, and illegal input is intercepted in real time.

[0091] The code is labeled "Semantic Consistency Verification → Tableau Algorithm Detection → Rule Conflict?". If there is a conflict / missing rule, the code queries the configuration rule library. If there is no conflict, the code restructures.

[0092] Dictionary validation: Marked with "Format / Value Range / Dependency Triple Validation", it has two branches: "Validation Passes" outputs "Target View BOM_target", "Validation Failes" "Interrupts the Process and Returns an Error Code", ensuring that the output data conforms to the standard; the process finally ends with "End", forming a closed-loop traceable logic, which is convenient for operation log recording and problem backtracking.

[0093] Book Figure 3 By using a design of "dynamic rule configuration + incremental branching", this diagram breaks through the limitations of traditional solutions and achieves dynamic adaptation for multiple factories and multiple order scenarios through "rule configuration + confirmation".

[0094] Figure 4 This invention fully demonstrates the entire process from raw data input to target view output: 1. Data Input and Context Definition User-uploaded x-BOM data table: Users upload a structured data table (such as Excel) through the front-end interface. This table contains fields such as part number, parent node, quantity, and attributes. This table can be EBOM, PBOM, or other views. The system does not require its structure to be perfect and allows for redundancy or missing data.

[0095] Input context: The user also inputs context parameters for the derived target, such as View_Type = PBOM and Factory = WH01. These parameters are used for subsequent rule matching and access control.

[0096] Tree structure management: The system performs "tree structure management" on the uploaded data tables, including: ID standardization: Assign a unique ID to each node to ensure global uniqueness; Hierarchical verification: Checks whether the parent-child relationship forms a valid tree structure (no circular references, no isolated nodes); Virtual component tagging: Identify and tag virtual components for subsequent processing; Attribute binding standard: Bind each attribute (such as "material" or "process type") to national standards such as GB / T 24467 to ensure semantic consistency.

[0097] Stored in the tree-structured ontology storage module: The processed data is stored in the tree-structured ontology storage module in the form of a "seven-tuple BOM_core", which serves as the sole data source for all subsequent operations.

[0098] 2. Rule Configuration and Semantic Validation Querying the configuration rule sub-library: The system queries the "Configuration Rule Sub-library" for preset rules based on context parameters (such as View_Type=PBOM, Factory=WH01). Rules are represented by triples.<context_key, struct_op, attr_func> Formal storage, where: struct_op is a structure operator; attr_func is the attribute mapping function.

[0099] Matching structure operators and attribute mapping functions: The system matches the queried rules with the current context to determine the specific operation to be performed.

[0100] Semantic consistency verification: The "Tableau algorithm" is invoked to verify the semantic consistency of the matched rules, checking for conflicts or omissions. If a conflict or omission is detected, the process proceeds to the "Confirm" branch; otherwise, it proceeds directly to the "Structure Restructuring" stage.

[0101] 3. Structural Restructuring and Derivation Structural Restructuring: The system executes the matched operators to generate a new set of nodes. For example, if the rule is P_split, a node will be split into multiple child nodes, inheriting some of their attributes.

[0102] Is it a change only in attributes / quantities? The system determines whether this change only involves modifications to attributes or quantities, and does not involve changes to the structural topology. If so, it executes "incremental derivation"; otherwise, it executes "full derivation".

[0103] Incremental derivation: only processes the changed node and its downstream subtree, greatly improving efficiency; Full Derivation: Processes the entire BOM, suitable for scenarios where the structural topology changes.

[0104] Dictionary validation: Performs triple validation on derived results: format, range, and dependencies. Format validation: Verify whether the attribute value conforms to a regular expression (such as the material ID format); Value range validation: Verify whether the attribute value is within the enumeration set or numerical range (e.g., "Process Type" must be one of "Machining / Sheet Metal / Assembly"). Dependency validation: Verify whether the logical relationship between attributes is reasonable (e.g., when "self-made part flag = TRUE", "supplier code" must be empty).

[0105] 5. Results Output and Error Handling Validation passed: If all validations pass, the target view BOM_target is output and stored in the "Result Storage" submodule under the Security and Access Control module.

[0106] Verification failure: If any verification fails, the process is interrupted, an error code is returned, and the error information is stored in the "Error Information Storage" submodule under the security and access control module for subsequent analysis and repair. The log is retained for ≥3 years.

[0107] During the "semantic consistency verification" phase, if a conflict or missing element is detected, the system will pause and prompt the user for "manual confirmation." If the user confirms, the system will continue; if the user refuses, the process will be interrupted and the error will be logged.

[0108] Case Implementation: A new energy vehicle company's WH01 factory added a "CUSTOM-EV" order type (which requires deriving a PBOM including battery assembly breakdown), triggering a dual-engine collaborative process, the specific implementation of which is as follows: Main engine (configuration rule sub-library) matching: Input context: ViewType=PBOM, FacID=WH01, OrderType=CUSTOM, ConfigProf=EV; Encoding context_key-alg="PBOM-WH01-CUSTOM-EV", querying the configuration rule sub-library, no exact match rule was found because this order type is newly added; After three fuzzy rollbacks (omitting ConfigProf → omitting OrderType → retaining ViewType), there were still no matching rules. The main engine output "FLAG_RULE_MISSING=true", triggering the auxiliary engine.

[0109] The auxiliary engine (semantic graph sub-library) intervenes: Step 1: Construct a query subgraph G_query: with "PBOM-WH01-CUSTOM-EV" as the core, it associates 12 entities and 18 relationships, including "EV model → battery assembly → supplier A / B → WH01 factory workstation"; Step 2: TransR Model Retrieval: Encode G_query into a 128-dimensional vector, calculate the cosine similarity with 100,000 rule vectors in the graph sub-database, and return the Top-3 candidate rules with sim_graph≥0.85 (Rule 1: PBOM-WH02-CUSTOM-EV, sim=0.92; Rule 2: PBOM-WH01-CUSTOM-HEV, sim=0.88; Rule 3: PBOM-WH03-CUSTOM-EV, sim=0.86). Step 3: DL Ontology Verification: Call the Tableau algorithm of the OWL 2 DL ontology to verify the compatibility of candidate rules with the axioms "EV models → battery packs must be split by supplier" and "WH01 factory workstation is only compatible with supplier A". Rule 2 was disqualified because it included "welding technology specific to HEV models" (which conflicts with EV models); Rule 3 was rejected because "Supplier B is not a good match for workstation WH01"; Rule 1 (PBOM-WH02-CUSTOM-EV) passes verification after modifying "FacID=WH02→WH01"; Dual-engine collaborative execution: The main engine receives rule 1 (modified) recommended by the auxiliary engine and executes the P_split operator: splits the "Battery Assembly" node (ID: BAT_01_000) into 2 child nodes (BAT_01_000_S1 / BAT_01_000_S2), allocates cost / weight according to alpha_split=[0.6,0.4], and associates the child nodes with suppliers A and B respectively; The auxiliary engine synchronously updates the graph: the "PBOM-WH01-CUSTOM-EV" rule is embedded into the existing graph, and the GraphSAGE model is used to learn its association with "WH01 workstation" and "EV attribute", and the relationship weights are updated. The WH01 factory has added a "Battery Torque Rule for EV Models" (requiring a torque of 120NM), and the following procedures will be followed: Rule input: Manually enter the rule content (context_key-rule="PBOM-WH01-CUSTOM-EV-TORQUE", struct_op="P_add"); GraphSAGE embedding: Input: New rule + entities for "EV attribute", "torque process node", and "WH01 station" in the diagram; Execution: The model learns the association between the new rules and the aforementioned entities, generating a 128-dimensional embedding vector; Output: Updated graph relationships (New rule → EV attribute, weight = 0.92; New rule → WH01 workstation, weight = 0.88); Verification: The DL ontology axiom "EV vehicle torque ≤ 150NM" was successfully verified. Application: When generating subsequent EV orders of the same type, this rule can be directly matched without manual intervention.

[0110] This case study achieves three major breakthroughs in enterprise core BOM management scenarios through an innovative architecture that "guarantees data uniqueness through tree-structured ontology, enables logical flexibility through mesh mapping, and drives efficient processing through a dynamic engine": First, it eliminates multi-version redundancy by using a unique data source, reducing data maintenance costs; second, it utilizes automated rules and incremental processing; and third, it employs semantic validation and rule reuse.

[0111] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for dynamic derivation of discrete manufacturing multi-view BOM based on a tree-like network structure, characterized in that, Includes the following steps: Construct a tree ontology as a single product data source, and store the product's hierarchical relationship, attribute definition, and engineering semantics in a tree structure; Based on the tree ontology, derivation rules are dynamically matched through a network mapping relationship library. The network mapping relationship library includes a configuration rule sub-library and a semantic graph sub-library. The configuration rule sub-library handles regular derivation scenarios, while the semantic graph sub-library handles scenarios with missing or conflicting rules. The dynamic view derivation engine is used to perform rule matching, semantic validation, structural reconstruction, and dictionary validation to generate the target BOM view. The derivation process is semantically constrained and validated using the BOM data dictionary module. Access control and auditing based on roles, scenarios, and data sensitivity are implemented through the security and access control module.

2. The method as described in claim 1, characterized in that, The tree ontology is formalized into a seven-tuple. Store data; in, It is a set of nodes, each with a unique ID; Let be a set of directed edges. For a collection of node attributes, To configure the validity set, A set of timestamps For data dictionary constraint identifiers, This is a pointer to a semantic relationship.

3. The method as described in claim 2, characterized in that, Each semantic relation pointer in the tree ontology is used to point to the corresponding rule or semantic path in the network mapping relation library.

4. The method as described in claim 1, characterized in that, The configuration rule sub-library stores rule triples <context, operator, attribute mapping function>; wherein, the context includes four-dimensional combination encoding; the operators include split, merge, add, replace and delete operators; and the attribute mapping functions include inheritance, derivation and conversion functions.

5. The method as described in claim 1, characterized in that, The semantic graph sub-library adopts a hierarchical architecture of description logic and graph neural networks, and calculates recommendation rules through semantic similarity. The semantic similarity formula is as follows: in, For graph rules entities; context-graph is the derived scene graph mapping; This is a TransR-specific embedded function used for rule recommendation.

6. The method as described in claim 1, characterized in that, The dynamic view derivation engine is based on tree ontology and mesh mapping logic, and supports incremental derivation. Incremental derivation only processes the changed node and its downstream associated subtree, while full derivation processes the entire BOM structure. Time complexity calculation for full derivation: , Time complexity calculation for incremental derivation: ; Space complexity calculation: Only store view references; in, This indicates the total amount of data or the total number of entities that need to be processed when performing a full derivation. This represents the average cost of a single match or derivation operation. This indicates the amount of data that changes or is added during incremental derivation; ΔN ≤ 0.1N indicates that the underlying assumption is that incremental derivation is only effective when the amount of change is small. This indicates the size or complexity of the set of rules used to perform derived operations.

7. The method as described in claim 1, characterized in that, The BOM data dictionary module is built on a three-level dictionary system based on national standards, industry standards and enterprise standards. It implements triple checks on format, value range and dependency, and blocks illegal values ​​in real time and returns error codes.

8. The method as described in claim 1, characterized in that, The security and access control module adopts a three-dimensional access control model based on roles, scenarios, and data sensitivity. The access control decision formula is as follows: Among them, Permit-sec (User-sec, View-sec, Attr-sec) represents a final access permission decision; User-sec represents the user security context; View-sec represents the view / scene security context; Attr-sec represents the attribute security context; RoleMatch-sec represents role matching; SceneMatch-sec represents scene matching; SensitivityMatch-sec represents sensitivity matching.

9. A dynamic derivation system for discrete manufacturing multi-view BOM based on a tree-network structure, characterized in that, The system for implementing the method as described in any one of claims 1-8 comprises: The tree ontology storage module is used to store tree ontology as an authoritative data source; The network mapping relation library includes a configuration rule sub-library and a semantic graph sub-library, which are used to provide derivation logic; The dynamic view derivation engine is used to perform view derivation operations; The BOM data dictionary module is used to implement data specification verification. The security and access control module is used for managing permissions and security auditing.

Images