An integrated PLM and ERP cross-domain product data integrated management system

Abstract

The application discloses an integrated PLM and ERP cross-domain product data integrated management system, relates to the technical field of enterprise process data integration, and is used for solving the problem of inconsistent cross-system versions; the application constructs a semantic view mapping, a change event linkage, a validity period arrangement, an execution check, and a traceability control closed loop, so that design and manufacturing data semantics are aligned, change linkages are formed, and the data can be audited after being stored in a database; a unified semantic model eliminates measurement caliber, applicable technology, substitution strategy and validity period ambiguity; an event carries a version identifier and an effective condition to trigger linkage, is accurately issued according to object identification, an effective window and a disposal action, and avoids line stoppage and wrong orders; execution check uniquely solves and checks measurement consistency, substitution conflict and resource accessibility for an order material list and a process route, searches for a minimum cost path and supports writing and compensation playback, forms an audit chain, so that manual work and repeated input are reduced, mismatch and rework are reduced, and response and delivery are improved.

Description

Technical Field

[0001] This invention relates to the field of enterprise process data integration technology, and more specifically, to a cross-domain product data integrated management system that integrates PLM and ERP. Background Technology

[0002] In the field of discrete manufacturing and engineering management, the parallel application of PLM and ERP has become the mainstream: enterprises use PLM to manage engineering change requests, engineering change notifications, upper limit structure and process changes, while ERP is responsible for material master data, manufacturing and planning execution, inventory and settlement. Existing solutions mostly adopt interface integration and field mapping, and shorten the transmission time from design to manufacturing by means of master data governance and message synchronization. The technical implementation involves enterprise process modeling, resource planning and cross-system data governance, with the goal of improving delivery efficiency and consistency.

[0003] However, existing technologies have significant shortcomings: field-level synchronization ignores semantic differences, making it difficult to unify measurement standards, applicable processes, substitution strategies, and expiration dates, which can easily lead to version drift and mismatches; change-driven processes lack standardized event models and effective orchestration, resulting in unclear impact domains for engineering changes, work-in-process orders, in-transit procurement, and service spare parts, often leading to one-size-fits-all line stoppages or incorrect orders; order structure solving and executability verification are scattered, making it difficult to guarantee a unique correspondence from the engineering view to the manufacturing plan, resulting in duplicate filing and rework; cross-domain writes lack cause-effect graphs and compensation mechanisms, making it impossible to replay and audit failures, causing risks to spill over to planning and settlement; the permission model and chain of responsibility are inconsistent, cross-team collaboration is not well documented, compliance audits and quality traceability are costly, thus affecting enterprise efficiency. Summary of the Invention

[0004] To overcome the aforementioned deficiencies in the prior art, the following solution is proposed to address the issue of cross-system version inconsistency in the aforementioned background technology.

[0005] To achieve the above objectives, the present invention provides the following technical solution: A cross-domain product data integrated management system that integrates PLM and ERP includes a semantic view mapping module, a change event linkage module, an expiration date arrangement module, an execution verification module, and a traceability control module, with each module connected by signals; The semantic view mapping module is used to obtain the engineering view and change rules on the PLM side and the manufacturing view and process routing on the ERP side. Based on the cross-domain product data semantic model, it extracts the measurement caliber, applicable process, substitution strategy and expiration date elements, and establishes view mapping and consistency verification points. The change event linkage module is used to encapsulate engineering change requests, engineering change notifications, bill of materials adjustments, and process parameter changes into standard business events, and to determine whether the view mapping and consistency verification meet the linkage conditions. The expiration date arrangement module is used to identify the relationship between changes and affected execution objects when it is determined that the linkage conditions are not met or there is a conflict. Based on the relationship and preset business priorities, it generates an expiration date arrangement table containing the effective window and disposal actions. The execution verification module is used to generate a unique order bill of materials and corresponding process routes based on the upper limit structure and selection rules, combined with supply and manufacturing constraints and regional restrictions, and to verify the consistency of measurement, substitution conflicts and resource availability; The traceability control module is used to construct a cross-domain causal graph, search for the minimum cost path from the current state to the target state in the cross-domain causal graph, and compile the state transition sequence into cross-domain write instructions and compensation instructions, which are then sent to the PLM and ERP for execution.

[0006] Furthermore, the semantic view mapping module includes: Establish a semantic mapping template library for engineering views and manufacturing views; Generate a view difference matrix based on measurement caliber, applicable process, substitution strategy and shelf life; Based on the difference matrix, set consistency check points and output a list of semantic differences and correction suggestions; When the proposed correction is approved, the mapping template is updated and the updated result is used as the verification baseline for linkage.

[0007] Furthermore, the change event linkage module includes: Encapsulate cross-domain changes into standard business events that carry version identifiers, effective conditions, applicable scope, and audit identifiers; Configure idempotent keys and deduplication strategies for business events and build an event state machine. The event state machine includes states such as pending publication, published, consumed, being compensated, and replayed. After the event is published, attribute-level and structure-level differential synchronization is triggered, and if the callback verification fails, it enters the compensation branch or replay window.

[0008] Furthermore, the expiry date scheduling module includes: When consistency checks are not met or conflicts exist, analyze the relationship between changes and work-in-process orders, planned work orders, in-transit purchases, and service spare parts. Calculate the effective time window for each associated object and generate an object-window-action duration arrangement table; For objects that cannot be switched immediately, develop transition strategies such as parallel versioning, alternative postponement, or batch isolation. Before release, conduct a simulation exercise and generate an impact list and approval thresholds. After release, write the arrangement results back into the audit record.

[0009] Furthermore, the verification module includes: Based on the upper limit structure and selection rules, and in conjunction with supply constraints and manufacturing constraints, a unique order bill of materials and corresponding process routing are obtained. Perform executability checks on measurement consistency, substitution conflicts, and resource accessibility, and generate executability tags; When the verification fails, a rollback strategy is triggered or the process enters the manual approval path. After verification, a cross-domain write command is issued and the verification report and handling command are bound to the audit identifier.

[0010] Furthermore, the traceability control module includes: Establish a cross-domain cause-effect graph, mapping the PLM object status, ERP object status, and approval and callback processes to nodes, and establishing directed edges with linked writing, callback verification, and compensation branches; Label directed edges with cost attributes for response latency, conflict risk, and switching overhead; A heuristic search is used to find the minimum cost path from the current state to the target state; and the corresponding state transition sequence is compiled into cross-domain write instructions and compensation instructions with timestamps and idempotent keys, and the execution is monitored and the playback results are recorded.

[0011] Furthermore, the traceability control module is also used for: Map the PLM and ERP side permission policies to an access control expression based on object attributes, and record the execution subject, role, object scope, version and validity period; Generate a chain of responsibility for roles, data, and tasks, and provide node-level replay entry points and unauthorized change prompts; When rolling back or compensating, the chain of responsibility is linked to the corresponding instructions to form an end-to-end audit trail.

[0012] Furthermore, the semantic view mapping module is also used for: Perform naming convention, attribute completeness, uniqueness, and traceability checks on the materials, bill of materials, and process objects to be synchronized; When a conflict is detected, output normalization, merging, or binding correction suggestions and provide an approval interface, and write the approval conclusion and correction action back as a consistency verification baseline.

[0013] Furthermore, the change event linkage module is also used for: Generate an idempotent key and ordered sequence number for each standard business event, and configure a replay strategy with a maximum number of retries and a backoff interval. Duplicate events are deduplicated and distributed to consumers according to the principle of causal order. If the callback verification fails, enter the compensation branch or replay window, and write back the event status and audit flags after the compensation is completed.

[0014] The technical effects and advantages of the present invention, which integrates PLM and ERP into a cross-domain product data unified management system, are as follows: This invention achieves semantic alignment between design and manufacturing data, real-time change linkage, and auditable inventory management by constructing a closed-loop process encompassing semantic view mapping, change event linkage, expiration date arrangement, execution verification, and traceability control. It eliminates ambiguities in measurement standards, applicable processes, substitution strategies, and expiration date elements between PLM / ERP systems through a unified semantic model. Change events, carrying version identifiers and activation conditions, trigger linkage. Expiration date arrangement ensures precise implementation from object identifier to activation window and then to disposal action, thus avoiding line stoppages and incorrect orders. Execution verification uniquely solves and verifies the executability of order bills of materials and process routes, ensuring consistent measurement, no substitution conflicts, and resource availability. Traceability control searches for the minimum cost path based on cross-domain causal graphs and supports writing and compensation playback, forming an end-to-end audit chain. Compared to decentralized integration, this invention significantly reduces manual filing and repetitive data entry, lowers version mismatch and rework rates, improves change response speed and on-time delivery capability, and maintains stability and economy in quality traceability, compliance governance, and multi-site collaboration. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of the structure of a cross-domain product data integrated management system that integrates PLM and ERP according to the present invention. Detailed Implementation

[0016] 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.

[0017] In order to achieve the above objectives, Figure 1 A schematic diagram of the cross-domain product data integrated management system integrating PLM and ERP is given in this invention. Specifically, it includes a semantic view mapping module, a change event linkage module, an expiration date arrangement module, an execution verification module, and a traceability control module. The modules are connected by signals. The semantic view mapping module is used to obtain the engineering view and change rules on the PLM side and the manufacturing view and process routing on the ERP side. Based on the cross-domain product data semantic model, it extracts the measurement caliber, applicable process, substitution strategy and expiration date elements, and establishes view mapping and consistency verification points. The change event linkage module is used to encapsulate engineering change requests, engineering change notifications, bill of materials adjustments, and process parameter changes into standard business events, and to determine whether the view mapping and consistency verification meet the linkage conditions. The expiration date arrangement module is used to identify the relationship between changes and affected execution objects when it is determined that the linkage conditions are not met or there is a conflict. Based on the relationship and preset business priorities, it generates an expiration date arrangement table containing the effective window and disposal actions. The execution verification module is used to generate a unique order bill of materials and corresponding process routes based on the upper limit structure and selection rules, combined with supply and manufacturing constraints and regional restrictions, and to verify the consistency of measurement, substitution conflicts and resource availability; The traceability control module is used to construct a cross-domain causal graph, search for the minimum cost path from the current state to the target state in the cross-domain causal graph, and compile the state transition sequence into cross-domain write instructions and compensation instructions, which are then sent to the PLM and ERP for execution.

[0018] It includes a semantic view mapping module, a change event linkage module, an expiration date arrangement module, an execution verification module, and a traceability control module, and the modules are connected by signals. The semantic view mapping module is used to acquire engineering views and change rules from the PLM side, and manufacturing views and process routes from the ERP side. Based on the cross-domain product data semantic model, it extracts measurement caliber, applicable processes, substitution strategies, and expiration dates, and establishes view mapping and consistency verification points. The specific implementation steps include: First, the engineering view and change rules are obtained from the product lifecycle management system, and the manufacturing and planning views and process routes are obtained from the enterprise resource planning system. The set of objects in the engineering view consists of part identification, hierarchical position, quantity description, unit of measurement, applicable process prompts, alternative strategy prompts and expiration date descriptions; the change rules consist of engineering change requests, engineering change notices, measurement caliber adjustment instructions, alternative strategy effective instructions and expiration date change instructions.

[0019] The object set in the manufacturing and planning views consists of material identifiers, assembly locations, quantity descriptions, units of measurement, process references, substitution strategies, and expiration date descriptions; the process routing consists of process sequence, pre- and post-constraints, equipment identifiers, and tooling identifiers.

[0020] The semantic view mapping module defines the following four semantic elements and their value rules in the cross-domain product data semantic model: measurement scope, applicable process, substitution strategy, and expiration date. Measurement scope indicates the unit of measurement describing the quantity and its conversion in different business processes; applicable process indicates the range of processes that the object can and cannot perform; substitution strategy indicates the primary object and candidate substitute objects, their activation conditions, and priority; and expiration date indicates the effective start condition, effective end condition, and applicable object range. All objects are bound to a source record and a timestamp.

[0021] Establish a semantic mapping template library for engineering views and manufacturing / planning views. Each semantic mapping template contains explicit mapping rule items, which describe the correspondence between engineering view fields and manufacturing / planning view fields, as well as the alignment methods for measurement caliber, applicable processes, substitution strategies, and expiration date elements.

[0022] The semantic view mapping module establishes a candidate set corresponding to an object based on the object identifier, hierarchical position, quantity description, unit of measurement, applicable process hints, alternative strategy hints, and shelf life description; When the object identifiers match, a direct correspondence is established. When the object identifiers are inconsistent, the hierarchical position, quantity description, unit of measurement, applicable process prompts and shelf life description are compared in turn. If the preset quantity fields in the above fields are consistent and there is no conflict, a one-to-one correspondence between the objects is established. If multiple candidate objects meet the corresponding conditions, they are retained as objects to be confirmed and added to the semantic difference list.

[0023] When generating the view difference matrix, the four types of semantic elements are compared item by item according to the one-to-one correspondence between engineering view objects and manufacturing and planning view objects: When the units of measurement are exactly the same and the business conversion standards are consistent, the semantic view mapping module marks the item as having consistent measurement standards; when the units of measurement are different but there are clear business conversion standards and the quantity semantics are not changed, the item is marked as having convertible measurement standards; when there are no acceptable business conversion standards, the item is marked as having conflicting measurement standards.

[0024] The determination of applicable processes, substitution strategies, and shelf-life factors is completed using the same four categories of tags: complete consistency, convertibility, conflict, and absence. The semantic view mapping module sets consistency check points on the four categories of semantic elements based on the difference matrix: Measurement consistency checkpoints are used to verify whether the quantity descriptions and units of measurement can be used directly or converted according to business standards; applicable process consistency checkpoints are used to verify whether the objects can be executed in the process routing and do not violate the pre- and post-process constraints; alternative strategy consistency checkpoints are used to verify whether the candidate alternatives and their activation conditions are consistent with the engineering perspective. Figure 1 The validity period consistency checkpoint is used to verify, item by item, whether the effective start conditions, effective end conditions, and applicable scope are consistent.

[0025] When outputting the list of semantic differences, a correction suggestion is generated for each conflict or missing item. The correction suggestion falls into one of the following three categories: normalization suggestion, merging suggestion, and binding suggestion. The normalization suggestion is used to unify the business caliber of field naming and units of measurement and adjust the value range to the specified range. The merging suggestion is used to merge two objects with the same meaning but different source records into one object and retain all traceability information. When the correction suggestion is approved, the semantic view mapping module updates the semantic mapping template and writes the update result into the consistency verification baseline.

[0026] When performing master data quality verification, the semantic view mapping module follows the order of naming convention verification, attribute completeness verification, uniqueness verification, and traceability verification. The naming convention verification process is as follows: Each object name is checked to see if it conforms to the naming convention rules, which consist of the allowed character set, the naming structure order, and the prohibited prefixes. When an object name does not conform to the naming convention rules, the semantic view mapping module outputs a normalization suggestion.

[0027] The process of attribute completeness verification is as follows: check each required attribute to see if it has a value and if the value is within the specified value range; when a required attribute is missing or the value is not within the value range, the semantic view mapping module outputs a normalization suggestion.

[0028] The process of uniqueness verification is as follows: Compare object identifiers and core attributes within the same product, version, and applicable scope. The core attributes should include at least the hierarchical position, quantity description, unit of measurement, applicable process tips, alternative strategy tips, and shelf life description. When the object is used in manufacturing or planning views, the core properties also include assembly location and process reference; The semantic view mapping module performs uniqueness checks only when all core attributes have clearly defined values ​​and the source records are complete; otherwise, it outputs normalization suggestions first. When two or more objects have completely identical combinations within the scope, the semantic view mapping module outputs a merge suggestion; when an object refers to the same thing in the engineering view and the manufacturing and planning views but has different identifiers and the core attributes have provable consistency, the semantic view mapping module outputs a binding suggestion.

[0029] The change event linkage module encapsulates engineering change requests, engineering change notifications, bill of materials adjustments, and process parameter changes into standard business events, and determines whether view mapping and consistency checks meet the linkage conditions. Specific implementation steps include: The change event linkage module receives engineering change requests and engineering change notifications from the product lifecycle management system, as well as bill of materials adjustments and process parameter changes from the product lifecycle management system or enterprise resource planning system.

[0030] The change event linkage module encapsulates the above changes into standard business events, each of which contains at least: This is used to uniquely indicate the version identifier to which this change applies, to describe the effective start and end boundaries and the effective conditions that trigger constraints, to indicate the set of objects involved and the scope of application of the object range, and to bind the audit identifier to the approval record, source record, and timestamp.

[0031] To ensure idempotent execution under conditions of duplicate submissions or network jitter, the change event linkage module generates an idempotent key and an ordered sequence number for each standard business event. The idempotent key is obtained by concatenating the event type, object identifier, version identifier, effective condition description, applicable scope summary, and source system identifier in a fixed order and encoding them in a fixed manner. The idempotent key remains unchanged throughout the event lifecycle and is used for deduplication during duplicate reception or retries. The ordered sequence number ensures that events with the same object identifier and version identifier are distributed and consumed in causal order. The ordered sequence number strictly increments within the same event stream, and during concurrent writes, a stable order is determined based on the submission order and timestamp sequence of the source system. Before publishing an event, the change event linkage module, based on the consistency checkpoints and consistency check baselines output by the semantic view mapping module, determines the linkage conditions for the objects involved in this change: when the metering consistency checkpoint, applicable process consistency checkpoint, substitution strategy consistency checkpoint, and expiration date consistency checkpoint are all in a completely consistent or convertible state without conflict or missing information, the linkage conditions are considered met; when any conflict or missing information exists, the linkage conditions are considered not met.

[0032] An event state machine is built for each standard business event to ensure cross-domain consistency and traceability. The event state machine includes five states: pending publication, published, consumed, being compensated, and replayed.

[0033] Basic verification includes at least the existence and non-repeated existence of the version identifier, whether the effective conditions have a clear start boundary or triggering constraint, whether the scope of application can be resolved to the object identifier set, whether the audit identifier has been bound to the approval record and source record, whether the idempotent key is repeated with the historical event, and whether the ordered sequence number meets the requirement of incrementing within the same event stream; only when all of the above verifications pass can the standard business event enter the pending release state.

[0034] The state transition rules are as follows: Once the event is encapsulated and passes basic verification, it enters the pending release stage; once the event is submitted to the event bus and confirmed as received, it enters the published stage; once the enterprise resource planning system completes differential synchronization and returns a callback verification result, it enters the consumed stage; once the callback verification fails or some data inconsistencies occur, it enters the compensation stage; once the compensation is completed and retries or rollbacks are completed, the event is replayed according to the idempotent key and ordered sequence number, and once the replay is complete, it enters the replayed stage.

[0035] Differential synchronization is divided into attribute-level differential synchronization and structure-level differential synchronization: Attribute-level differential synchronization is used for changes that only involve quantity descriptions, units of measurement, applicable process descriptions, alternative strategy descriptions, or expiration dates. The change event linkage module only updates the attribute fields marked as changed on the enterprise resource planning system side. Structure-level differential synchronization is used for changes that involve bill of materials levels, assembly locations, and process routing sequences. The change event linkage module only performs structural adjustments on the affected level nodes and affected process segments on the enterprise resource planning system side.

[0036] Callback verification is returned by the Enterprise Resource Planning (ERP) system after differential synchronization. Verification content includes: whether measurement consistency and applicable process consistency checks were performed according to the consistency verification baseline; whether structural or attribute updates were completed under substitution strategies and validity period constraints; and whether traceable execution records were created and bound to audit identifiers. When callback verification fails or a partial success state occurs during execution (some objects updated successfully, others failed), the change event linkage module enters either the compensation branch or the replay window based on the idempotent key and ordered sequence number in the event payload. The compensation branch is used to undo write actions that have been written to the database and require unified rollback, or to restore the state to the previous usable version. The replay window is used to resubmit unsuccessful objects without changing the already effective objects. Both compensation and replay are recorded in the event state machine and bound to audit identifiers for subsequent minimum cost path search and replay display by the traceability control module.

[0037] The deduplication and replay strategies in the event linkage module have been modified. The deduplication strategy is implemented as follows: Maintain an idempotent key storage set within the change event linkage module, and save the processed idempotent keys within the validity period of the event; When an event with the same idempotent key is received, it is directly identified as a duplicate and the processed state is returned. The replay strategy includes two parameters: maximum number of retries and backoff interval. The maximum number of retries is used to limit the maximum number of retries in the case of consecutive failures. The backoff interval is used to extend the waiting time before the next retry in the case of consecutive failures. The growth method of the backoff interval is expressed by a fixed threshold. The growth rule is defined in text in the system parameters and is configurable. The validity period of an event is determined by the event creation time and the conditions for its effectiveness. When the validity period expires and the event has not entered the consumed state, it will no longer enter the replay window. The maximum number of retries is used to limit the upper limit of repeated submissions of a single standard business event under the same idempotent key. The backoff interval is used to limit the minimum waiting time between two adjacent replays. When the number of retries reaches the upper limit, the callback verification continues to fail, or the scope of application changes, the replay window is closed and the event is marked as pending manual approval.

[0038] When an event is ultimately determined not to meet the linkage conditions, the event linkage module writes the determination and the scope of associated objects into the event payload and notifies the expiration date arrangement module to enter the expiration date arrangement of object identifier, effective window, and disposal action; when the event meets the linkage conditions and differential synchronization passes the callback verification, it is used for executability verification and the event state machine is updated to the consumed state.

[0039] The expiration date scheduling module is used to identify the relationship between changes and affected execution objects when it is determined that the linkage conditions are not met or conflicts exist. Based on the relationship and preset business priorities, it generates an expiration date scheduling table containing the effective window and handling actions. The specific implementation steps include: The preset business priority is determined based on the type of execution object, delivery commitment status, inventory risk status, and service guarantee status. When the execution object is an order in progress and is in a critical delivery batch, the business priority is higher than the planned work order. When the execution object is a service spare part and corresponds to the maintenance task of the equipment under warranty, the business priority is higher than general procurement in transit. When multiple execution objects have the same business priority, they are sorted in the order of the earlier start time of the effective window and the larger affected scope. When the change event linkage module determines that a standard business event does not meet the linkage conditions or has a conflict, the validity period orchestration module receives the event payload of the standard business event. The event payload includes at least the version identifier, the effective conditions, the scope of application, and the audit identifier, and also references the consistency verification baseline and semantic difference list output by the semantic view mapping module.

[0040] First, the relationship between changes and affected execution objects is identified: using the object identifier in the applicable scope as the primary key, execution objects directly or indirectly related to the object identifier are retrieved in the Enterprise Resource Planning (ERP) system. These execution objects are limited to four categories: work-in-process orders, planned work orders, in-transit purchases, and service spare parts. The expiration date orchestration module compares the object identifier with the bill of materials (BOM) level and the process reference in the process routing: when the BOM node of a work-in-process order or planned work order matches the object identifier in the event payload, or when the process parameter pointed to by the process reference in a work-in-process order or planned work order matches the process parameter change in the event payload, the work-in-process order or planned work order is determined to be an affected execution object; when the material identifier or substitution strategy trigger condition in the purchase details of an in-transit purchase matches the object identifier or substitution strategy description in the event payload, the in-transit purchase is determined to be an affected execution object; when the material identifier or expiration date element in the service spare parts list matches the object identifier or expiration date element in the event payload, the service spare parts are determined to be an affected execution object.

[0041] The above matching is based on the view mapping established by the semantic view mapping module to ensure the semantic alignment of measurement scope, applicable process, substitution strategy and expiration date elements. After the relationship identification is completed, the expiration date arrangement module forms a set of affected execution objects. Each item in the set is bound to its object identifier, source record, current execution stage and timestamp, and uniformly marked with an audit identifier.

[0042] The effective window is calculated for each of the affected execution objects and the appropriate action is determined. The effective window is the time interval during which the changes corresponding to the version identifier take effect on the execution object without disrupting the continuity of execution. The calculation of the effective window is based on textual rules rather than formulas: For work-in-progress orders, the expiration date arrangement module reads the current process, next process, batch boundary, and planned completion time of the work-in-progress order; when the effective conditions allow immediate switching and switching in the current process will not cause conflicts in measurement standards, applicable processes, or alternative strategies, the start time of the effective window is determined as the time between the completion of the current process and the start of the next process; when immediate switching would cause a conflict, the start time of the effective window is determined as the next batch boundary that will not cause a conflict; for planned work orders, the start time of the effective window is determined as the planned start time of the planned work order or the preparation time before the planned start time, depending on the status of the effective conditions and the consistency check point; for purchases in transit, the start time of the effective window is determined as the expected warehousing completion time after arrival or the replacement effective time allowed by the alternative strategy, whichever is later; for service spare parts, the start time of the effective window is determined as the next replaceable time point of the service spare part in the service list.

[0043] The termination condition of the effective window is determined by the effective condition and the validity period. When the effective condition specifies a clear end point of the effective period, that point in time shall prevail. When the effective condition is until it is replaced by the next version, the start point of the next version's effective period shall be the termination condition.

[0044] The handling actions are limited to three categories, consistent with the aforementioned definitions: parallel versioning, alternative postponement, and batch isolation. Parallel versioning is used to maintain both the old and new versions within the same object scope, applicable to situations where different batches in work-in-progress cross change boundaries. Alternative postponement is used to temporarily suspend the new alternative strategy in in-transit procurement or service spare parts until the effective window arrives. Batch isolation is used to physically or logically isolate production batches before and after the effective window to ensure a clear traceability chain. The expiration date scheduling module checks the measurement consistency checkpoint first, then the applicable process consistency checkpoint, then the alternative strategy consistency checkpoint, and finally the expiration date consistency checkpoint. For each affected execution object, it selects a handling action that ensures execution continuity and meets the effective conditions. When no handling action can achieve a conflict-free switch at the current time, the expiration date scheduling module postpones the start time of the effective window to the next batch boundary or the start time of the next planned work order, and re-evaluates the handling actions accordingly until the conditions are met or the manual approval path is entered.

[0045] The above results are organized into an expiration schedule table for objects, windows, and actions. The expiration schedule table should include at least the following fields: object identifier, version identifier, start time of effective window, end condition of effective window, action, status of referenced consistency checkpoint, approval status, rollback strategy reference, source record, and audit identifier.

[0046] It should be noted that the approval status includes at least pending approval, approved, and rejected approval; the rollback strategy reference is used to indicate the rollback method when subsequent execution verification fails or the traceability control module triggers a compensation instruction. The rollback method includes at least restoring the previous available version, maintaining the original action unchanged, and extending the effective window; when the approval status is rejected approval, the validity period arrangement module continues to execute the original version and writes the rejection reason into the record corresponding to the audit identifier.

[0047] The rules for generating the expiry date schedule are as follows: For each affected execution object, the corresponding version identifier and effective conditions are written. The start and end points of the effective window are determined according to the aforementioned calculation method. Based on the action selection result, the parallel version, alternative postponement, or batch isolation are filled in. The consistency check point status (measurement consistency check point, applicable process consistency check point, alternative strategy consistency check point, and expiration date consistency check point) used to support the decision are recorded item by item. After the expiration date arrangement table is generated, the expiration date arrangement module provides it as a structured output to the execution verification module for the executability verification of the order bill of materials and process routing. At the same time, the expiration date arrangement module binds the expiration date arrangement table with the audit identifier for the traceability control module to reference when constructing the cross-domain cause-effect graph and searching for the minimum cost path. If the feedback verification fails, the effective window of the corresponding affected execution object is extended or the action is adjusted according to the specific reason for the failure. The adjusted record is written back to the expiration date arrangement table with the same field format.

[0048] The execution verification module is used to generate a unique order bill of materials and corresponding process routes based on the upper limit structure and selection rules, combined with supply and manufacturing constraints and regional restrictions. It also verifies metering consistency, substitution conflicts, and resource availability. Specific implementation steps include: It receives the upper limit structure and selection rules from the product lifecycle management system, the supply constraints and manufacturing constraints from the enterprise resource planning system, and the regional restrictions from the compliance library; it also references the consistency verification baseline and consistency verification points output by the semantic view mapping module, and the validity period arrangement table composed of object identifiers, effective windows and disposal actions output by the validity period arrangement module.

[0049] Supply constraints include at least the available quantity, estimated delivery time, alternative supply relationships, and inventory freeze status; manufacturing constraints include at least the process routing template, equipment identification, tooling identification, personnel qualifications, process sequence, and pre- and post-constraints; regional restrictions include at least the list of prohibited objects, the list of permitted objects, and the effective regional scope. The execution verification module will only perform a unique solution after a clear association has been established between the above constraint information and the object identification, effective window, and applicable scope of the order.

[0050] Each order is uniquely solved according to the decision order: First, based on the selection rules, a set of candidate objects that meet the functional and configuration constraints is selected from the upper limit structure. Then, regional restrictions are applied to remove candidate objects that are not allowed to enter the specified region. Next, based on the supply constraints, determine whether the candidate object is available for supply within the effective window. If a candidate object is not available for supply within the effective window, then the candidate object is excluded. Next, the candidate object is checked for manufacturability on the established process routing template according to manufacturing constraints. If it is not manufacturable, the next candidate object in the alternative strategy is tried. If there are multiple candidate objects in the same position, the coverage of the effective window, the scope of changes to the existing process routing, and the batch isolation cost caused by the disposal action are compared in turn. The candidate object that can fully cover the effective window and has the least change to the process routing is selected first. When a unique result still cannot be determined, the verification module is executed to mark the position as pending approval and the specific reasons for the inability to determine the result are written into the verification report.

[0051] After all locations are selected, the execution verification module organizes the selected objects and their quantity descriptions, units of measurement, alternative strategy references, and expiration dates into a unique order bill of materials. At the same time, based on the process sequence and capability matching relationship required by the selected objects, the execution verification module selects the pre- and post-process constraints and alternative work centers in conjunction with manufacturing constraints, and generates the process route corresponding to the order bill of materials.

[0052] The feasibility of the unique order bill of materials and its corresponding process route is checked. The process of checking the consistency of measurement is as follows: the quantity description and unit of measurement in the order bill of materials are compared with the measurement caliber in the consistency check baseline. If the units of measurement are the same and the business conversion caliber is consistent, it is determined that the measurement is consistent. If the units of measurement are different but there is a clear business conversion caliber and it will not change the semantics of the quantity, it is determined that the measurement is convertible and the business conversion caliber used when placing the goods into inventory is recorded. If there is no acceptable business conversion caliber, it is determined that there is a measurement conflict and the reason is written into the check report.

[0053] The process of alternative conflict verification is as follows: Check each alternative strategy reference to see if it introduces mutually exclusive objects in the same position. Check each alternative activation condition and validity period element to see if they are consistent with the validity period arrangement table. If there is inconsistency caused by mutual exclusion or overlapping activation conditions, it is judged as an alternative conflict and written into the verification report.

[0054] The process of resource accessibility verification is as follows: For each process step in the process route, check whether there are equipment and tooling identifiers that meet the capability requirements within the effective window, and check whether the required personnel qualifications are available within the effective window. If any of these are unavailable, the process is determined to be resource unreachable. When there is an alternative work center, the execution verification module selects an alternative work center based on manufacturing constraints without changing the pre- and post-process constraints. If the alternative work center still cannot meet the resource reachability requirements, the verification is determined to have failed and the reason for unreachability is recorded in the verification report.

[0055] Based on the above three types of verification conclusions, an executability label is generated for the order: when the measurement is consistent, there is no substitution conflict, and all process resources are available, it is marked as executable; when the measurement is convertible, there is no substitution conflict, and all process resources are available, it is marked as conditionally executable, along with the business conversion caliber to be used; when there is a measurement conflict, substitution conflict, or any process resource is unavailable, it is marked as unexecutable, and the verification report provides a detailed explanation of the reasons for failure and the corresponding object identifier.

[0056] When the executability tag is executable or conditionally executable, the execution verification module outputs the unique order bill of materials, corresponding process route, executability tag, and complete verification report together. After binding with the audit identifier, it is handed over to the traceability control module to build a cross-domain cause-effect graph and referenced when compiling cross-domain writing instructions and compensation instructions in the future. When the executability tag is not executable, the execution verification module returns the verification report to the expiration date scheduling module and the change event linkage module. The expiration date scheduling module extends or adjusts the effective window and disposal action according to the reasons for failure in the verification report. The change event linkage module enters the compensation branch or the replay window according to the event state machine, and triggers the execution verification module again for verification and re-examination after approval.

[0057] The traceability control module is used to construct a cross-domain cause-effect graph, search for the minimum cost path from the current state to the target state in the graph, and compile the state transition sequence into cross-domain write and compensation instructions, which are then sent to the PLM and ERP for execution. Specific implementation steps include: It receives standard business events, which include version identifier, effective conditions, scope of application, audit identifier, idempotent key and ordered sequence number, and references the current state of the event state machine; it receives an expiration date arrangement table consisting of object identifier, effective window and disposal action from the expiration date arrangement module; it receives a unique order bill of materials, corresponding process route, executability tag and verification report from the execution verification module; and it references the consistency verification baseline and consistency verification point output by the semantic view mapping module.

[0058] Based on this, the traceability control module constructs a cross-domain cause-effect graph. The specific process is as follows: Define the object status of the product lifecycle management system, the object status of the enterprise resource planning system, the approval process, and the callback verification process as nodes; define the linkage write, callback verification, and compensation branch as directed edges. Each directed edge is labeled with a cost attribute, which consists of three items: response latency, conflict risk, and switching overhead.

[0059] Response latency, conflict risk, and switching overhead are all described using three levels: high, medium, and low. When historical execution monitoring records show that similar objects can be written in one go within the current effective window without waiting for batch boundaries, the response latency is set to low. When it is necessary to wait for the start time of the next batch boundary or the next planned work order, the response latency is set to the higher value. When all consistency checkpoints pass, the conflict risk is set to low; when there is a convertible state, the conflict risk is set to medium; and when there is a failed state, the conflict risk is set to high. When the action does not change the existing process routing and inventory handling method, the switching overhead is set to low; when replacement, suspension or batch isolation is required, the switching overhead is set to medium; and when parallel versions or restoration of the previous available version are required, the switching overhead is set to high.

[0060] The response latency value is assessed based on historical execution monitoring records and the textual rules of the current system load: if the target object can obtain a stable response before the start time of the effective window, the response latency is assessed as low; if it needs to wait until the next batch boundary or the start time of the next planned work order, the response latency is assessed as high. The conflict risk value is assessed based on the textual rules of the consistency checkpoint and the check report: when the measurement consistency checkpoint, applicable process consistency checkpoint, substitution strategy consistency checkpoint, and expiration date consistency checkpoint are all in a passed state, the conflict risk is assessed as low; when there is a convertible state but special activation conditions for applying business conversion calibers or substitution strategies need to be applied when placing the item into inventory, the conflict risk is assessed as medium; when there is a failed state, the conflict risk is assessed as high. The switching overhead value is assessed based on the handling action and its impact on the order bill of materials and the corresponding process routing: parallel versions usually correspond to high switching overhead, substitution postponement usually corresponds to medium switching overhead, and the switching overhead of batch isolation depends on the batch boundary and the workload of inventory processing and is assessed according to the textual rules.

[0061] The traceability control module determines the current state and the target state based on this. The current state is the current status of the object as indicated by the event state machine, and the target state is the state after being written to the database, which is jointly indicated by the version identifier, the effective conditions, the scope of application, and the executable label. This provides a definite start and end point for searching the minimum cost path in the cross-domain causal graph.

[0062] Heuristic search is performed in the cross-domain causal graph. The heuristic search first generates a set of candidate paths reachable from the current state. At each step of expansion, the candidate path with the smaller cumulative cost is selected for expansion. The cumulative cost is compared in the following order: conflict risk first, then switching cost, and finally response delay. When the previous item is equal, the next item is compared. When a candidate path reaches the target state for the first time, the path is recorded as the path with the minimum cost. The operations corresponding to the directed edges on the minimum cost path are sequentialized to form a state transition sequence, and compiled into cross-domain write instructions and compensation instructions according to the following method: For each state transition, one or more cross-domain write instructions are generated. The write instructions include the target system identifier, object identifier, version identifier, effective window, disposal action, operation type, timestamp, idempotent key and ordered sequence number. For state transitions with rollback requirements or partial success risks, corresponding compensation instructions are generated simultaneously. These instructions include the target system identifier, object identifier, the version identifier to be revoked or the previous available version to be restored, an effective window adjustment description, a timestamp, an idempotent key, and an ordered sequence number. The traceability control module sorts the instruction sequence by ordered sequence number and effective window to ensure that the execution order and effective time of cross-domain write instructions and compensation instructions match across multiple objects. Subsequently, the instruction sequence is distributed to the product lifecycle management system and enterprise resource planning system for execution, and the execution monitoring and callback verification results are recorded in the event state machine.

[0063] If the callback verification shows that all objects have been completed and stored in the database according to the action within the effective window, the traceability control module marks the minimum cost path as a closed path and binds it to the audit identifier for playback; if the callback verification shows that any object has not been completed according to the action or there are convertible meters but not stored in the database according to the business conversion caliber, the traceability control module will retry the distribution of the incomplete part according to the idempotent key and the ordered sequence number, and trigger a compensation instruction when necessary.

[0064] When a partial success state occurs (some objects succeed, some fail), the traceability control module processes the data according to a textually defined compensation priority: first, writes that cause irreversible impacts on inventory or planning in the Enterprise Resource Planning (ERP) system are revoked; then, writes that cause version chain inconsistencies in the Product Lifecycle Management (PLM) system are revoked; finally, the system restores to the previous usable version and marks the path as being in a compensation-in-progress state. After compensation is completed, the traceability control module replays unsuccessful writes based on idempotent keys and ordered sequence numbers until the callback verification passes or the maximum number of retries of the replay strategy is reached. All execution monitoring records, callback verification records, compensation records, and replay records are bound with audit identifiers and stored as replay records in a searchable track by the traceability control module for subsequent node-by-node replay by object identifier, version identifier, and effective window.

[0065] The traceability control module feeds back the cost attributes and execution results of the closed path and compensation path to the change event linkage module for updating the event state machine; it feeds back the actual object identifier, effective window and disposal action to the expiration date arrangement module for updating the expiration date arrangement table; when a failure caused by semantic inconsistency is found during execution, the traceability control module feeds back the relevant records and verification report fragments to the semantic view mapping module for updating the consistency verification baseline and semantic mapping template.

[0066] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, in the form of a computer program product.

[0067] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0068] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

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

[0070] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A cross-domain product data integrated management system combining PLM and ERP, characterized in that: It includes a semantic view mapping module, a change event linkage module, an expiration date arrangement module, an execution verification module, and a traceability control module, and the modules are connected by signals. The semantic view mapping module is used to obtain the engineering view and change rules on the PLM side and the manufacturing view and process routing on the ERP side. Based on the cross-domain product data semantic model, it extracts the measurement caliber, applicable process, substitution strategy and expiration date elements, and establishes view mapping and consistency verification points. The change event linkage module is used to encapsulate engineering change requests, engineering change notifications, bill of materials adjustments, and process parameter changes into standard business events, and to determine whether the view mapping and consistency verification meet the linkage conditions. The expiration date arrangement module is used to identify the relationship between changes and affected execution objects when it is determined that the linkage conditions are not met or there is a conflict. Based on the relationship and preset business priorities, it generates an expiration date arrangement table containing the effective window and disposal actions. The execution verification module is used to generate a unique order bill of materials and corresponding process routes based on the upper limit structure and selection rules, combined with supply and manufacturing constraints and regional restrictions, and to verify the consistency of measurement, substitution conflicts and resource availability; The traceability control module is used to construct a cross-domain causal graph, search for the minimum cost path from the current state to the target state in the cross-domain causal graph, and compile the state transition sequence into cross-domain write instructions and compensation instructions, which are then sent to the PLM and ERP for execution.

2. The integrated cross-domain product data management system combining PLM and ERP as described in claim 1, characterized in that: The semantic view mapping module includes: Establish a semantic mapping template library for engineering views and manufacturing views; Generate a view difference matrix based on measurement caliber, applicable process, substitution strategy and shelf life; Based on the difference matrix, set consistency check points and output a list of semantic differences and correction suggestions; When the proposed correction is approved, the mapping template is updated and the updated result is used as the verification baseline for linkage.

3. The integrated cross-domain product data management system combining PLM and ERP as described in claim 1, characterized in that: The change event linkage module includes: Encapsulate cross-domain changes into standard business events that carry version identifiers, effective conditions, applicable scope, and audit identifiers; Configure idempotent keys and deduplication strategies for business events and build an event state machine. The event state machine includes states such as pending publication, published, consumed, being compensated, and replayed. After the event is published, attribute-level and structure-level differential synchronization is triggered, and if the callback verification fails, it enters the compensation branch or replay window.

4. The integrated cross-domain product data management system combining PLM and ERP as described in claim 1, characterized in that: The expiry date scheduling module includes: When consistency checks are not met or conflicts exist, analyze the relationship between changes and work-in-process orders, planned work orders, in-transit purchases, and service spare parts. Calculate the effective time window for each associated object and generate an object-window-action duration arrangement table; For objects that cannot be switched immediately, develop transition strategies such as parallel versioning, alternative postponement, or batch isolation. Before release, conduct a simulation exercise and generate an impact list and approval thresholds. After release, write the arrangement results back into the audit record.

5. The integrated cross-domain product data management system combining PLM and ERP as described in claim 1, characterized in that: The verification module includes: Based on the upper limit structure and selection rules, and in conjunction with supply constraints and manufacturing constraints, a unique order bill of materials and corresponding process routing are obtained. Perform executability checks on measurement consistency, substitution conflicts, and resource accessibility, and generate executability tags; When the verification fails, a rollback strategy is triggered or the process enters the manual approval path. After verification, a cross-domain write command is issued and the verification report and handling command are bound to the audit identifier.

6. The integrated cross-domain product data management system combining PLM and ERP as described in claim 1, characterized in that: The traceability control module includes: Establish a cross-domain cause-effect graph, mapping the PLM object status, ERP object status, and approval and callback processes to nodes, and establishing directed edges with linked writing, callback verification, and compensation branches; Label directed edges with cost attributes for response latency, conflict risk, and switching overhead; A heuristic search is used to obtain the minimum cost path from the current state to the target state; and the corresponding state transition sequence is compiled into cross-domain write instructions and compensation instructions with timestamps and idempotent keys, and the execution is monitored and the playback results are recorded.

7. The integrated cross-domain product data management system combining PLM and ERP as described in claim 6, characterized in that: The traceability control module is also used for: Map the PLM and ERP side permission policies to an access control expression based on object attributes, and record the execution subject, role, object scope, version and validity period; Generate a chain of responsibility for roles, data, and tasks, and provide node-level replay entry points and unauthorized change prompts; When rolling back or compensating, the chain of responsibility is linked to the corresponding instructions to form an end-to-end audit trail.

8. The integrated cross-domain product data management system combining PLM and ERP as described in claim 2, characterized in that: The semantic view mapping module is also used for: Perform naming convention, attribute completeness, uniqueness, and traceability checks on the materials, bill of materials, and process objects to be synchronized; When a conflict is detected, output normalization, merging, or binding correction suggestions and provide an approval interface, and write the approval conclusion and correction action back as a consistency verification baseline.

9. The integrated cross-domain product data management system combining PLM and ERP as described in claim 3, characterized in that: The change event linkage module is also used for: Generate an idempotent key and ordered sequence number for each standard business event, and configure a replay strategy with a maximum number of retries and a backoff interval. Duplicate events are deduplicated and distributed to consumers according to the principle of causal order. If the callback verification fails, enter the compensation branch or replay window, and write back the event status and audit flags after the compensation is completed.

Images