Enterprise master data governance and distribution method based on multi-system collaboration

Abstract

The invention relates to the technical field of data processing, in particular to an enterprise master data governance and distribution method based on multi-system collaboration. The method comprises the following steps: synchronously acquiring main data of multiple systems about the same entity, and associating the main data with product data and real-time equipment metadata; generating a consistency label independent of each system rule based on a product constraint condition as an objective arbitration benchmark; performing collaborative analysis on the system data processing rules according to the labels to identify conflicts; calibrating the system master data with conflicts, and generating and distributing calibrated data matched with rules of the system master data; and finally, iteratively executing collaboration and calibration based on system feedback until the similarity of each system rule reaches a set threshold, and realizing quantitative convergence. According to the method, intelligent, dynamic and consistent collaborative governance of cross-system main data is realized by introducing an objective consistency label and a quantitative closed-loop mechanism.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method for enterprise master data governance and distribution based on multi-system collaboration. Background Technology

[0002] In current enterprise IT environments such as hospitals, schools, and factories, it is common for multiple business systems to operate in parallel. These systems are often built at different times, using different technical architectures and data standards, leading to inconsistencies in data semantics, inconsistent formats, and inefficient data flow, resulting in data silos. This data inconsistency problem is particularly prominent in industrial production scenarios. For example, the status data of the same equipment (such as "high water temperature") may be interpreted differently in different systems (such as "no maintenance required" or "immediate maintenance required"), leading to contradictions in subsequent production decisions, confusion in process flows, and even product quality and safety risks.

[0003] Specifically, this manifests in several ways: When data is sequentially transferred between multiple systems, differences in built-in business rules and data processing logic among these systems can lead to the same data being processed, filtered, or discarded in different ways. This prevents downstream systems from obtaining complete and accurate data, impacting the traceability, monitoring, and optimization of the production process. Furthermore, in real-time collaborative scenarios involving parallel processing, different systems may perform calculations or judgments on the same data source based on their own rules, potentially resulting in inconsistent or even conflicting processing results, leading to contradictory actions and collaborative failures. While some existing master data management methods attempt to improve business adaptability through dynamic model expansion (e.g., the master data model expansion method based on event listening and visual configuration proposed in CN120578646B), these methods primarily address the flexibility and response speed of the model itself, lacking an effective mechanism for master data consistency governance and distribution in multi-system collaborative scenarios. Especially when multiple systems have inconsistent understandings of the business rules for the same data, even if the master data model can be dynamically expanded, semantic alignment, rule unification, and real-time synchronization of data during cross-system flow cannot be guaranteed. This results in the underutilization of enterprise data asset value and constraints on operational efficiency and decision-making quality. Summary of the Invention

[0004] To address the aforementioned technical problems, the technical solution adopted by this invention is as follows:

[0005] This invention provides a method for enterprise master data governance and distribution based on multi-system collaboration, the method comprising the following steps:

[0006] S100 synchronously retrieves master data about the same entity from multiple business systems and associates it with the corresponding product data and real-time device metadata to form a cross-system associated data set.

[0007] S200, based on the constraints defined in the product data definition, perform consistency determination on the associated data set and generate a consistency label for uniformly representing the overall state of the entity. The consistency label is independent of the data processing rules of each business system.

[0008] S300, based on the consistency label, perform collaborative analysis on the data processing rules of each business system, identify rule conflicts, and obtain collaborative analysis results.

[0009] S400, based on the results of collaborative analysis, calibrates the master data distributed to business systems with rule conflicts, and generates and distributes calibrated data that is adapted to the data processing rules of the business system.

[0010] S500, based on the feedback from the business systems on the calibrated data, iteratively execute rule coordination and data calibration until the similarity of the data processing rules of each business system for the entity is greater than the set similarity threshold.

[0011] The present invention has at least the following beneficial effects:

[0012] This invention effectively solves the problems of data silos and collaboration failures caused by inconsistencies in data semantics and processing rules between multiple systems by introducing a consistency label independent of the rules of each business system as a unified arbitration benchmark for cross-system data and setting a quantifiable similarity threshold as a collaborative convergence target. This method achieves a shift from subjective manual alignment to objective automatic collaboration, automatically identifying rule conflicts, generating calibration data, and forming a closed loop through iterative feedback. Ultimately, it drives multiple systems to achieve quantitative consistency in the data processing logic of the same entity, thereby significantly improving the consistency, accuracy, and business collaboration efficiency of master data flow across systems within an enterprise.

[0013] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

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

[0015] Figure 1 This is a flowchart illustrating an enterprise master data governance and distribution method based on multi-system collaboration, provided as an embodiment of 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] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of this invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0018] It should be noted that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe the steps as sequential processes, many of these steps can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the steps can be rearranged. A process can be terminated when its operation is complete, but it may also have additional steps not included in the figures. A process can correspond to a method, function, procedure, subroutine, subroutine, etc.

[0019] This invention provides a method for enterprise master data governance and distribution based on multi-system collaboration, such as... Figure 1 As shown, the method includes the following steps:

[0020] S100 synchronously retrieves master data about the same entity from multiple business systems and associates it with the corresponding product data and real-time device metadata to form a cross-system associated data set.

[0021] In this invention, an entity refers to a core business object that an enterprise needs to uniquely identify and share across cross-system business processes. Within the context of this invention, an entity specifically refers to physical or logical objects whose state and attributes can be described and constrained simultaneously by product data (design goals and specifications) and equipment metadata (real-time operating status). For example, in a production scenario, an entity could be a specific machine tool, an assembly line, or a batch of products being processed; in a medical scenario, it could be a medical imaging device or a patient's critical treatment path. Entities serve as the anchor point for master data governance.

[0022] Business systems refer to software systems independently deployed and running within an enterprise, undertaking specific business functions, such as Enterprise Resource Planning (ERP), Manufacturing Execution System (MES), Customer Relationship Management (CRM), and Product Lifecycle Management (PLM) systems. These systems are typically built at different times, employing heterogeneous technical architectures and data models, and holding data fragments from different perspectives and in different formats for the same entity, which is the root cause of data silos and rule conflicts. The multiple business systems described in this invention generally refer to a collection of systems within the same enterprise or group that require business collaboration.

[0023] Synchronous acquisition of master data for the same entity refers to the simultaneous extraction of identifying, descriptive, and stateful data about the same entity from various business systems. Synchronous acquisition is achieved by deploying data connectors and adapters, and acquisition methods include, but are not limited to: calling the application programming interfaces (APIs) provided by each business system; capturing changed data by reading database logs (such as MySQL Binlog); or accessing specified views in their data warehouses. To ensure data timeliness, techniques such as timed polling, message queue-based event listening, or streaming acquisition can be used.

[0024] In this invention, the master data refers to: fundamental data that is distributed across various heterogeneous business systems within an enterprise, concerning the same core business entity (i.e., the entity), and possesses high business value and is relatively stable. This data is the result of each business system modeling and maintaining the entity's key identifiers, attributes, and states from its specific functional perspective.

[0025] Due to differences in the construction goals and data models of various business systems, the master data of the same entity may be inconsistent in terms of semantic definition, data format, update granularity and timeliness, thus forming a multi-perspective, fragmented and potentially contradictory digital image of the entity in a multi-system environment.

[0026] For example, consider a "machine tool" as a physical entity:

[0027] Enterprise Resource Planning (ERP) systems maintain the attributes of assets as fixed assets (which can be called asset master data), such as asset number, acquisition date, cost center to which they belong, etc.

[0028] The Manufacturing Execution System (MES) maintains its production scheduling-related attributes (which can be called production master data), such as current work orders, plan status, and work teams.

[0029] The device Internet of Things (IoT) platform maintains real-time monitoring data from its physical sensors (which can be called device status master data), such as power on / off status, spindle speed, alarm codes, etc.

[0030] The simultaneous acquisition of master data about the same entity from multiple business systems refers to acquiring the aforementioned scattered, perspective-based core business attribute data fragments. These data fragments serve as the initial input for subsequent association, consistency determination, and rule-based collaborative processing.

[0031] In this invention, the product data refers to normative data that defines the expected state and compliance benchmarks of the entity, typically derived from product lifecycle management (PLM) systems, design documents, or process documents. It predefines the target attributes, performance indicators, allowable ranges (i.e., constraints) of process parameters, and other compliance standards that the entity should possess. For example, for a "valve" as an entity, its product data might include rated pressure, temperature tolerance range, valve body material type, etc.

[0032] The real-time device metadata refers to observational data reflecting the actual state of the entity, acquired in real-time or near real-time through devices such as sensors and monitoring systems attached to the entity. It describes the entity's actual physical state (e.g., current, temperature, rotational speed) and process parameters (e.g., machining accuracy, cycle time) during operation. For example, the real-time device metadata of the valve mentioned above might include the current inlet pressure, real-time valve core opening, and valve body surface temperature.

[0033] Furthermore, the association operation in step S100 specifically involves: using the entity's unique identifier (such as device ID or product serial number) as the association key, linking, aligning, and fusing the master data (about the entity) obtained from various business systems, the product data (about the entity) obtained from the design end, and the real-time device metadata (about the entity) obtained from the sensing end. This operation aims to construct a unified set of associated data, which integrates the entity's target specifications (product data), actual operation (real-time device metadata), and multi-perspective understanding from various business systems (master data), thereby providing a complete and consistent data foundation for subsequent consistency judgment and rule collaboration.

[0034] S200, based on the constraints defined in the product data definition, perform consistency determination on the associated data set and generate a consistency label for uniformly representing the overall state of the entity. The consistency label is independent of the data processing rules of each business system.

[0035] Specifically, the consistency label is generated in the following manner:

[0036] S201, Integrate the constraints of the product data with the real-time device metadata, and compile to generate a dynamic constraint compliance rule model for the entity.

[0037] Specifically, the system integrates predefined constraints (such as performance thresholds and parameter ranges, serving as judgment benchmarks) from the product data (i.e., the entity's design specifications) with features from the real-time device metadata (i.e., real-time observation data) (such as data flow patterns and state variables, serving as judgment inputs). Through executable rule construction methods such as rule engines, state machines, or logic programming, a dynamic constraint compliance rule model for the entity is compiled and generated. This model encapsulates the logic for dynamically comparing real-time observation data with design specifications. For example, for temperature parameters, it may contain judgment logic of the following form: if the real-time temperature value exceeds the temperature threshold range defined in the product data, a temperature anomaly status indicator is triggered. By integrating all relevant constraints and data features, this model forms a unified, computable state judgment function.

[0038] S202, input the associated data set into the dynamic constraint compliance rule model to determine constraint compliance (i.e. compliance), and output a multi-dimensional state vector as the consistency label.

[0039] The associated data set obtained in step S100 is input into the dynamic constraint compliance rule model for unified judgment. The model executes its built-in logic, sequentially executing two core sub-processes:

[0040] (1) Objective benchmark determination: The real-time device metadata is compared with the constraint range defined by the product data to obtain an objective benchmark state set. This objective benchmark state set consists of a series of basic compliance judgments, such as "temperature: compliant" and "vibration: exceeding the threshold".

[0041] (2) System rule coordination assessment: For each business system, using the master data provided by the business system as input, the execution of the data processing rules of the business system is simulated to obtain a system-side state judgment; then, according to the predefined state mapping specification, the relevant states in the system-side state judgment and the objective benchmark state set are converted into standard state codes with unified semantics. Then, the converted standard system state codes and standard objective state codes are compared for logical consistency, and the logical relationship between the two is determined according to the predefined coordination rule base (such as consistency, contradiction, etc.), and a clear consistency comparison result is output. The consistency comparison result can be in the form of a Boolean value (consistent / inconsistent) or a consistency score (such as a confidence level of 0 to 1).

[0042] The predefined state mapping specification is a technical component that converts heterogeneous state descriptions into a unified encoding, typically manifested as a mapping table or rule set. Its function is to take the original, diverse state description strings or codes from various business systems as input, and convert them into a finite, predefined, standardized state encoding, such as STATE, according to predefined mapping rules.OK (Normal / Compliant), STATE WARNING (Warning / Attention), STATE ERROR (Abnormal / Fault) or STATE UNKNOWN (Unknown). This specification ensures that subsequent logical consistency comparisons are performed on a unified and unambiguous semantic basis.

[0043] The predefined coordination rule base is a formalized set of rules that can be queried and executed by the dynamic constraint compliance rule model. It encapsulates business rules for determining the logical relationships between different standardized state codes, that is, it defines which combinations of states should be considered consistent, conflicting (contradictory), or other relationships.

[0044] Each rule typically includes a condition part (IF) and a conclusion part (THEN): the condition part defines the standard state codes to be compared; the conclusion part defines the consistency comparison result to be output when the condition is met.

[0045] The rule base mainly contains the following types of decision logic:

[0046] Consistency rule: When the system-side state code is the same as the objective baseline state code or belongs to a preset equivalent group, it is determined to be logically consistent.

[0047] Contradictory (conflict) rules: When the state codes of both parties belong to a predefined mutually exclusive group (such as STATE), OK With STATE ERROR When ), it is judged as a logical contradiction.

[0048] Weak correlation or irrelevance rule: When state codes are neither explicitly consistent nor mutually exclusive, they can be judged as logically irrelevant or output with a low confidence score.

[0049] By querying and executing the corresponding rules in this rule base, standardized state code pairs can be automatically converted into explicit consistency comparison results (such as Boolean values ​​or confidence scores), thereby driving subsequent collaborative processes. The following specific example illustrates the process of system rule coordination evaluation and logical consistency comparison in step (2):

[0050] 1. Input status:

[0051] One of the states in the objective benchmark state set is determined as: "Amplitude exceeds the threshold".

[0052] The MES system status is determined as "fault".

[0053] 2. State standardization:

[0054] Based on the predefined state mapping specification, the above original state description is converted into a standardized state code:

[0055] The specification stipulates that when the original description contains keywords such as "exceeding the threshold," "abnormal," or "fault," it is mapped to the standardized state STATE. ERROR .

[0056] Therefore, both "amplitude exceeding the threshold" and "fault" are mapped to STATE. ERROR .

[0057] 3. Logical consistency comparison and output:

[0058] The standardized state codes (all STATE) are used to encode the state codes. ERROR The input is compared with the coordination rule base. The rule base defines that if the system-side state code is the same as the objective baseline state code, then the consistency relationship is satisfied.

[0059] Therefore, the consistency comparison result output in this embodiment is consistent (or expressed as a Boolean value of true, confidence level of 1.0, etc.).

[0060] Finally, the dynamic constraint compliance rule model integrates the objective baseline state set generated in step (1) with all the consistency comparison results generated in step (2), and encodes them into a unified multi-dimensional state vector, which serves as the final consistency label. The dimensions of this vector correspond to the various judgment results mentioned above, such as the "temperature parameter compliance level" representing the objective state, and the "consistency index with MES system state judgment" representing coordination.

[0061] The consistency labels generated through the above process achieve a desystematized, standardized, and quantitative representation of entity states. This eliminates the interpretative biases caused by local rules in various business systems, providing a state benchmark based on objective facts (product specifications and real-time equipment data) that can be referenced by all systems for rule conflict identification in subsequent step S300.

[0062] To ensure the accuracy and reliability of the consistency labels generated in step S200, thereby guaranteeing the effectiveness of the entire method, this method designs a multi-layered decision-making and fault-tolerance mechanism to avoid the risk of misjudgment caused by data noise, model limitations, or boundary conditions. This mechanism is based on the proactive application of the consistency judgment results and their confidence scores, specifically as follows: Confidence-driven collaborative strategy grading: The dynamic constraint compliance rule model can output consistency judgment results with accompanying confidence scores. Based on this confidence score, this method directly determines the strategy and execution intensity of subsequent collaborative analysis and data calibration: When the confidence score is higher than a first threshold (e.g., 0.9), the judgment result is considered highly reliable, and a standard, automated rule-based collaborative and data calibration process will be executed.

[0063] When the confidence level is between the first and second thresholds (e.g., 0.6-0.9), there is some uncertainty in the judgment. In this case, an early warning notification can be generated and sent during the calibration process, indicating that the calibration is based on a judgment with a moderate confidence level.

[0064] When the confidence level falls below the second threshold (e.g., 0.6), the current data is deemed insufficient to support reliable automated decision-making. In this case, low-risk calibrations such as format conversion will be temporarily suspended or only performed, and the manual review process will be triggered first to avoid automated erroneous operations under low confidence levels.

[0065] Continuous monitoring and closed-loop optimization of model performance: The dynamic characteristics of the dynamic constraint compliance rule model are partly reflected in its self-optimization capability based on performance feedback. This invention continuously tracks the correlation between the confidence level of the model output and subsequent manual arbitration results or business verification results. If it is found that the model consistently outputs a confidence level higher than a first threshold in a specific scenario, but the results are frequently overturned, it indicates that the model may have defects in that scenario. This signal will automatically trigger targeted retraining of the model or rule base updates, forming a closed loop from application feedback to model optimization, ensuring that the model can continuously improve over time and adapt to new business scenarios and data characteristics.

[0066] The direct impact of input anomalies on confidence: When constructing the associated dataset, if missing metadata of key real-time devices is detected, or if the values ​​significantly exceed the physically possible range (outliers), not only will the anomaly be recorded, but it will also be treated as a key factor, directly lowering the overall confidence of this consistency determination. This ensures that when the quality of the input data is questionable, the model's output will naturally tend to be conservative, guiding the process towards a more cautious manual or semi-automatic processing branch.

[0067] By transforming confidence scoring from passive output information into a proactive core variable for process control and risk management, this method endows the generation and application of consistency labels with inherent flexibility and fault tolerance. This design effectively avoids the risk of systematic misjudgment that may be caused by the absolute output of the model, and effectively improves the practicality and reliability of the entire method in complex environments.

[0068] S300, based on the consistency label, perform collaborative analysis on the data processing rules of each business system, identify rule conflicts, and obtain collaborative analysis results.

[0069] S300 specifically includes the following sub-steps:

[0070] S310, the multi-dimensional standardized state represented by the consistency label is logically mapped and compared with the rules in the data processing rule base of each business system, and the first analysis result is output to identify the candidate conflicting rules.

[0071] In this invention, the multi-dimensional standardized state represented by the consistency label refers to the set of entity state decisions generated by the dynamic constraint compliance rule model, encapsulated in a multi-dimensional state vector, and standardized and encoded. For example, a consistency label may contain states in the following dimensions: temperature state is STATE. ERROR The vibration state is STATE OK The consistency with the ERP system is "completely consistent" (value 1.0), while the consistency with the MES system is "completely conflicting" (value 0.0).

[0072] The mapping in this step refers to establishing the correspondence between each state dimension (such as "temperature state") in the consistency label and the relevant data processing rules (such as the rules involving temperature judgment in each business system).

[0073] The comparative analysis aims to identify potential logical contradictions between the logical conditions or expected outputs defined by the rule and the corresponding objective state standards represented by the consistency label, thereby identifying conflict risks. If a conflict risk is identified through comparative analysis, the rule is designated as a candidate conflict rule.

[0074] In this invention, "potential" may specifically refer to the following technical meanings:

[0075] This identifies potential conflicts in logical structure by formally comparing rule logic with state standards without dynamically simulating execution using actual data. The judgment is based on the following: if a rule is executed according to its definition, its output logic may contradict the objective state standard. For example, a rule defines "abnormal when temperature is greater than threshold A (e.g., 100)," while the objective standard for consistency labels is "temperature compliance threshold is threshold B (e.g., 105)." Then, when the temperature is between threshold A and threshold B, the rule will output an abnormality, while the objective standard determines compliance, thus constituting a potential logical contradiction. This rule is identified as a candidate conflict rule.

[0076] Based on the above analysis, this step outputs a rule-state association set, which labels the rules with conflict risk, i.e., candidate conflict rules, and their associated specific state dimensions, providing targets for subsequent conflict verification.

[0077] S320, based on the associated dataset as a unified input, simulate the execution of the candidate conflict rules identified in the first analysis result; compare the simulated output of each candidate conflict rule with the corresponding state in the consistency label; if the comparison result is logically contradictory, then confirm the candidate conflict rule as the target conflict rule, and output the second analysis result containing all target conflict rules.

[0078] This step follows the initial analysis results output by S310, performing dynamic simulation and final determination on the identified candidate conflict rules to generate a precise conflict list. The specific process is as follows:

[0079] Input and Target Determination: The associated dataset formed by S100 serves as the unified factual input for the simulation. Simultaneously, the first analysis result (rule-state association set) output by S310 is used as the target input. This rule-state association set clearly indicates which rules and which state dimensions of the consistency label have a risk of logical contradiction, thereby focusing the validation scope of S320 on these high-risk targets and improving analysis efficiency.

[0080] Rule simulation execution: Using a rule engine or logic simulator, each candidate conflict rule is loaded and run sequentially. The simulation takes the associated dataset as the rule input and simulates the execution environment and logic of the rule in its native business system, thereby obtaining the simulated output that the rule will produce under the current data state (e.g., a status judgment or a business action instruction).

[0081] Output standardization and state comparison: The simulated outputs of each rule obtained in the previous step are converted into standardized state codes according to the same set of state mapping specifications defined in S200. Subsequently, this code is compared with the corresponding pre-associated objective state in the consistency label (i.e., the specific state dimension mapped in S310).

[0082] Logical contradiction determination and conflict confirmation: Based on a predefined coordination rule base, the above comparison results are judged. If the standardized state output by the rule simulation is determined to be logically contradictory to the corresponding objective state in the consistency label (e.g., "STATE" and "CONTAIN TABLE"), then the result is considered logically contradictory. OK "and "STATE ERROR If the condition is met, then the rule is confirmed to have a genuine and reproducible rule conflict. This determination is recorded as a confirmed target candidate rule.

[0083] Generate a second analysis result: Integrate all target candidate rules verified and confirmed through the above process to form a second analysis result. This second result is a structured conflict determination result set, and each record includes at least: conflict rule ID, the business system to which it belongs, the conflict state dimension, the rule simulation output, the state corresponding to the consistency label, and the basis for determining it to be contradictory.

[0084] S330, Based on the first analysis result and the second analysis result, the collaborative analysis result is generated.

[0085] In this invention, the collaborative analysis result is a structured data object that provides a complete description and solution guidance for confirmed rule conflicts, and it includes at least the following elements:

[0086] Conflict Rule List: Lists all data processing rules that are logically contradictory as confirmed by step S320, and identifies the business system to which they belong.

[0087] Conflict Description: For each conflict, describe its specific type, such as "opposite state judgments", "inconsistent threshold standards" or "mutually exclusive logical conditions", and specify the entity state dimension involved (such as temperature, operating status).

[0088] Criteria for conflict determination: Record the key evidence that triggers the conflict determination, including the specific objective state (standard state code or value) from the consistency label and the simulated output of the corresponding rule.

[0089] Calibration benchmark recommendations: Based on the preset collaboration priority strategy, a suggested resolution benchmark is specified for each conflict, that is, whether the objective state represented by the consistency label should be used as the benchmark or the original rule logic of the specific business system should be used as the benchmark, so as to provide a decision basis for subsequent data calibration steps.

[0090] S400, based on the results of collaborative analysis, calibrates the master data distributed to business systems with rule conflicts, and generates and distributes calibrated data that is adapted to the data processing rules of the business system.

[0091] Furthermore, the S400 specifically includes:

[0092] S410, based on the preset collaboration priority strategy, determine whether the consistency label or the data processing rules of the specific business system should be used as the calibration benchmark.

[0093] The preset collaboration priority strategy determines the authoritative benchmark for calibration by quantitatively evaluating the degree of consensus between the consistency label and existing business system rules, thereby achieving a balance between automation and reliability. Specifically, it is configured as follows:

[0094] (1) Calculate the overall consensus between the consistency label and the data processing rules of each business system.

[0095] After identifying rule conflicts in step S300, calibration is not performed immediately. Instead, an overall consensus index is first calculated. This index quantifies the overall consistency between the consistency label and the data processing rules of all relevant business systems. Its calculation method can be as follows:

[0096] Mean method: Calculate the similarity between the consistency label and the data processing rules of each business system, such as the Jaccard similarity coefficient or cosine similarity, and then take the arithmetic mean of all similarities.

[0097] Weighted consensus method: Assign a weight to each business system (based on data authority, system importance, etc.) and calculate the weighted similarity sum between the consistency label and the rules of each system.

[0098] Voting method: Set a basic similarity threshold, and count how many system rules support the consistent label judgment results (similarity above the threshold). The support rate is the overall consensus.

[0099] (2) If the overall consensus is higher than the preset consensus threshold, the consensus label is selected as the calibration benchmark; if the overall consensus is lower than the preset consensus threshold, the data processing rules of the specific business system designated as the authoritative source are selected as the calibration benchmark.

[0100] System administrators or policy engines predefine one or more consensus thresholds. These thresholds serve as quantitative boundaries for determining whether a consensus label has gained sufficient widespread acceptance. Based on the calculated overall consensus level, the policy executes the following decisions:

[0101] If the overall consensus level is higher than the preset consensus threshold, this indicates that the determination of the consistency label has received implicit support from most system rules or is highly compatible with mainstream rule logic, and its credibility as an objective arbitration benchmark is high. Therefore, the strategy selects the consistency label as the benchmark for this calibration.

[0102] If the overall consensus level is lower than the preset consensus threshold, it indicates that the determination of the consistency label differs significantly from most existing rules, its credibility is questionable, and directly using it as a benchmark may be risky. In this case, the strategy will activate an alternative plan, selecting the data processing rules of a specific business system that has been pre-designated as the authoritative source as the calibration benchmark. This authoritative source can be the system primarily responsible for the data domain or a core system that is recognized in business operations.

[0103] S420, based on the selected calibration benchmark, performs logical mapping or semantic alignment processing on the original master data to generate calibrated data that is compatible with the data processing rules of the target business system.

[0104] In this invention, the logical mapping and semantic alignment processing are two core technical operations for implementing calibration, as detailed below:

[0105] 1. Logical mapping

[0106] Logical mapping is used to transform the business rules, status determination logic, or calculation relationships carried by the original master data to conform to the logical framework defined by the calibration benchmark. This operation is performed through a pre-built rule engine: the original data and the selected calibration benchmark rules are taken as input, and the rule engine derives and outputs new data fields and values ​​that conform to the target logic.

[0107] Example of state logic transition: When the source system determines that the equipment "needs maintenance" based on "continuous running time > 100 hours", while the calibration benchmark determines "normal operation" based on "real-time vibration value < threshold and normal oil temperature", the logic mapping operation will convert and reconstruct the original input from "continuous running time" to the judgment logic based on "vibration value and oil temperature" according to the logic of the calibration benchmark, and output the state conclusion of "normal operation" and the corresponding basis.

[0108] Example of computational relationship mapping: When the source system calculates "output rate" as (qualified products / total input), while the target system defines it as (qualified products / actual operating hours), the logical mapping operation will re-execute the calculation to generate an indicator value that conforms to the rules defined by the target system.

[0109] 2. Semantic alignment processing

[0110] Semantic alignment is used to resolve inconsistencies in concepts, terminology, coding, or units between different business systems, ensuring the accurate transmission of data meaning. This semantic alignment process relies on an enterprise-standard terminology library, data dictionary, or ontology. By querying these knowledge bases, it automatically completes term lookup, code conversion, or unit conversion, and optionally adds explanatory semantic annotations to the data.

[0111] Terminology / encoding mapping example: When system A uses the "Customer Level" field (values ​​1, 2, 3) and system B uses the "VIP Identifier" field (values ​​"Yes" and "No"), semantic alignment processing will complete the conversion between fields and values ​​during data distribution based on predefined mapping relationships (such as "1" mapping to "Yes", and "2" and "3" mapping to "No").

[0112] Example of unit and format consistency: For pressure data, convert the unit from "MPa" to "psi"; for date data, convert the format from "YYYYMMDD" to "YYYY-MM-DD".

[0113] When a consistency label is selected as the calibration benchmark, the processing focuses on logically mapping and aligning the raw data with the objective constraints and real-time status defined in the product data. Typical operations include status redefinition and alarm level adjustment.

[0114] When the data processing rules of a specific authoritative system are selected as the calibration benchmark, the processing focuses on resolving semantic and logical heterogeneity between systems. Typical operations include terminology conversion, encoding mapping, and business rule interpretation, so that the data fully conforms to the internal processing logic of that authoritative system.

[0115] Taking the priority determination of "equipment maintenance work orders" as an example:

[0116] Raw data: from the sensor, showing "spindle vibration value exceeds the standard".

[0117] Rule conflict: The MES system rule is determined to be "urgent, requiring immediate shutdown"; the ERP system rule is determined to be "early warning, maintenance can be scheduled"; while the consistency label, based on the equipment health model and process constraints, is determined to be "high warning, inspection recommended within 2 hours".

[0118] Strategy execution:

[0119] Calculate the overall consensus among the three judgments mentioned above (MES emergency, ERP warning, and tag high warning). Assume that the calculated consensus between the tag and the MES and ERP rules is low (e.g., 0.4), below the preset threshold (e.g., 0.7).

[0120] Due to insufficient consensus, the strategy does not adopt the consistency label as a benchmark. Instead, it designates the "MES system" (as the authoritative source for production execution) as the calibration benchmark based on pre-defined rules.

[0121] Perform calibration: The original vibration data and all relevant context information are logically reconstructed and semantically aligned according to the data format and field requirements required by the "emergency stop" logic of the MES system, generating a standard "emergency stop work order" data, which is then distributed to the maintenance system and ERP system for synchronization.

[0122] By introducing a decision-making mechanism based on overall consensus and a preset consensus threshold, this method endows the collaborative prioritization strategy with self-checking and fault tolerance capabilities. It no longer unconditionally trusts any single source (including consistency labels), but instead verifies the credibility of the benchmark by seeking consensus and safely reverts to preset authoritative system rules when consensus is insufficient. This significantly improves the robustness and reliability of cross-system collaboration in complex and uncertain environments.

[0123] After generating the calibrated data, this method distributes it to the corresponding business systems through a pre-configured data interface or message middleware. The distribution process ensures that the data packets contain necessary metadata (such as data version, calibration basis, and validity period) so that the receiving system can verify, process, and trace the data.

[0124] Through the configurable and selectable calibration operations described above, this method can ensure the semantic consistency and business logic compatibility of cross-system data while respecting the local rules of each system, thus achieving accurate and controllable collaborative data distribution.

[0125] S500, based on the feedback from the business systems on the calibrated data, iteratively execute rule coordination and data calibration until the similarity of the data processing rules of each business system for the entity is greater than the set similarity threshold.

[0126] This step constitutes the closed-loop control of the method, which drives iteration through feedback and uses quantized similarity as a verifiable convergence criterion. It may include the following sub-steps:

[0127] S510, Feedback Information Collection

[0128] After receiving and applying the calibrated data, the subsequent data processing actions or business events generated by the business system (such as whether the expected work order was generated based on the new data, or whether the alarm was correctly cleared) constitute an implicit or explicit feedback signal. Feedback information is collected by monitoring the API response status of these business systems, data processing records in the operation logs, or dedicated confirmation messages to determine whether the calibrated data was successfully accepted and triggered the expected business logic.

[0129] S520, Driving and Execution of Iterative Processes

[0130] The collected feedback information will be used to evaluate the effectiveness of the previous calibration operation. If the feedback indicates that the conflict persists (e.g., the target system modifies or rejects the calibrated data again according to its original rules), or the calculated rule similarity still does not reach the set similarity threshold, a new round of rule co-analysis (S300) and data calibration (S400) will be automatically triggered.

[0131] In the new iteration cycle, historical calibration records, the specific content of this feedback, and possibly updated real-time device metadata will be comprehensively analyzed to dynamically fine-tune the calibration strategy (such as the collaborative priority strategy) or the selected calibration benchmark, and generate new post-calibration data for distribution. S530, Convergence Determination and Threshold Management

[0132] The termination condition for the iteration process is that the quantitative similarity of the data processing rules of the entity by all relevant business systems is continuously greater than a preset similarity threshold.

[0133] The set similarity threshold is a configurable parameter whose value is positively correlated with the business criticality of the data entity. For example, for core equipment data that directly affects production safety or product quality, the threshold can be set to 0.95 or higher; for general business data, the threshold can be set between 0.80 and 0.90. This achieves a balance between governance rigor and execution efficiency.

[0134] When iterative calculations confirm that the rule similarity of all systems is stable above a threshold, it is determined that the multi-rule collaboration for that entity has reached convergence. The system records the final rule set and data mapping relationship as a collaboration snapshot and then enters steady-state monitoring mode.

[0135] In this invention, the similarity of the data processing rules of each business system for the entity is quantified by calculating the similarity between the output results of each business system's rules and the benchmark rules on the same test dataset. The specific calculation method is as follows:

[0136] (1) Process the same test dataset according to the benchmark rules and the data processing rules currently in effect for each business system to obtain the corresponding benchmark output result set and the output result set of each business system.

[0137] First, to ensure a fair and comprehensive evaluation, a unified test dataset will be maintained. This dataset is a representative sample set of the entity's master data, designed to cover various typical and edge business scenarios to ensure effective activation of different rule-based processing logic. The test dataset can be derived from anonymized sampling of historical production data or specifically generated based on the data model and business logic.

[0138] Then, perform the following core operations to collect the rule output results:

[0139] Benchmark Result Generation: The test dataset is processed according to the rules used as a comparison benchmark to obtain the benchmark output. This benchmark can be the decision logic implicit behind the consistency label, or a recognized set of standard rules.

[0140] System Result Generation: Based on the data processing rules currently in effect for each business system, the same test dataset is processed to obtain the corresponding output results for each system.

[0141] The output results from each of the above processes are collected to form a corresponding baseline output result set and the output result sets of each business system. The output results can be in the form of classification labels (such as "normal / abnormal"), numerical values, or operation instruction codes.

[0142] (2) By calculating the Jaccard similarity coefficient or cosine similarity between the output result set of each business system and the benchmark output result set, the quantitative similarity value of the data processing rules of each business system is obtained.

[0143] The Jaccard similarity coefficient is applicable when the rule output is a discrete set of categories or labels. The Jaccard similarity coefficient is calculated as the number of elements in the intersection of two output sets divided by the number of elements in their union. The coefficient ranges from 0 to 1; a higher value indicates greater consistency in the judgments of the two rules on the test data. Cosine similarity is more suitable when the rule output is a numerical vector (such as a series of scores or weights). Cosine similarity is calculated by treating the two output sets as vectors and calculating the cosine of the angle between them in their inner product space. The closer the value is to 1, the more similar the numerical patterns and trends of the two rule outputs.

[0144] Furthermore, during the iteration of S500, if the similarity of a business system still cannot reach the set similarity threshold after multiple calibrations of the data processing rules of a certain business system, an external arbitration instruction is received through the manual arbitration interface; the external arbitration instruction is used as a new rule benchmark, and at least one of the following operations is performed accordingly: (a) correcting the generation logic of the consistency label; (b) adjusting the collaboration priority strategy.

[0145] The manual arbitration interface is a standardized human-computer interaction module. During the S500 iteration process, the similarity trend of rules in each business system is continuously monitored after each calibration. If it is detected that the similarity value of a rule for a specific business system does not show a convergence trend after a preset number of calibration iterations (e.g., 3 times), or remains below the set similarity threshold, it is determined that the automatic collaboration mechanism has reached its effectiveness limit in resolving the conflict. At this time, an arbitration task is automatically pushed to the management platform. This task presents the entity data to be arbitrated, details of the conflicting rules, previous calibration records, and the current similarity status in the form of a structured form or a visual interface. Arbitrators (such as domain experts or system administrators) analyze the root cause of the conflict through this interface and input the final ruling and business rules. This interface ensures that the decisions of external experts can be accurately captured in the form of structured data (such as new judgment conditions, mapping relationships, or strategy parameters).

[0146] The received external arbitration instructions are structured rule descriptions that have undergone interface standardization. The input instructions can be processed by a rule parser, converting them into rule objects or logical expressions that the computer can understand and execute. For example, the natural language description "When parameter X is greater than A and event Y occurs, it should be determined as state Z" can be parsed into a corresponding logical decision tree. The parsed rule object is marked as a "new rule benchmark" with high priority. This benchmark will be given higher authority than existing automatically generated rules (consistency labels) or ordinary system rules in subsequent related processing.

[0147] Furthermore, based on the established new benchmark, perform at least one of the following update operations to achieve closed-loop learning:

[0148] (a) Correcting the generation logic of consistency labels: The consistency labels are generated by a dynamic constraint compliance rule model. The new rule benchmark and its corresponding original data (associated dataset) are added to the model's training dataset as a high-quality training sample pair. By triggering the model's incremental learning or retraining process, the model can internalize the business logic reflected in this manual arbitration, thereby automatically generating more accurate and business-realistic consistency labels when encountering similar scenarios in the future. For example, if arbitration corrects a misjudgment of a certain type of device status, the model will adjust its internal weights or rules, and future judgments on such statuses will be closer to the arbitration result.

[0149] (b) Adjusting the Collaboration Priority Strategy: The collaboration priority strategy consists of a series of configuration parameters and judgment logic. Based on the business principles reflected in the new rule benchmark (such as clarifying the ultimate authority system for a certain type of data domain), the strategy is dynamically adjusted. Specific operations may include: updating the authority weights of relevant business systems in the strategy; modifying the decision logic for selecting the benchmark under specific conflict types; or adding specific processing rules for entities or conflict patterns related to the new benchmark. This allows subsequent automated collaboration to directly apply the knowledge accumulated through manual arbitration, avoiding repeated triggering of arbitration.

[0150] Through the above mechanism, an evolution from purely automated collaboration to human-machine collaboration has been achieved. It ensures the method's ultimate solution capability when facing complex, novel, or boundary cases, and transforms artificial intelligence into automated capabilities that can be continuously reused by the system, significantly improving the adaptability, robustness, and long-term effectiveness of the entire master data governance system.

[0151] Furthermore, the S500 also includes the following steps:

[0152] S10 records the differences and feedback results of each rule collaboration and data calibration, forming a collaborative knowledge graph.

[0153] After each S300 (Collaborative Analysis) and S400 (Data Calibration) run, the following core elements are automatically recorded to form a collaborative case study:

[0154] Entity characteristics: Key attributes of the entity (such as equipment type, product model).

[0155] Conflict context: The original data characteristics that trigger the rule conflict, the business systems involved, and their specific rules.

[0156] Difference content: The specific logical differences between the rule outputs and consistency labels of each business system (such as different judgment conditions and inconsistent thresholds).

[0157] Calibration operations: The calibration benchmark adopted (conformity label or specific system rules) and the specific calibration operations (detailed parameters and transformation rules for logical mapping and semantic alignment).

[0158] Feedback results: The acceptance status of the calibrated data by the business system (e.g., successful application, secondary modification, rejection), and the change in rule similarity value recalculated after calibration.

[0159] Using graph database technology, the aforementioned collaborative cases are constructed into a collaborative knowledge graph. In this graph, nodes represent entities, business systems, data processing rules, consistency tags, calibration operations, and other objects. Edges represent relationships between nodes, such as "entity-involved-system," "rule-existence-conflict," "conflict-resolved through calibration operation," and "calibration operation-generated-feedback result." Weights can be attached to edges to indicate the frequency or validity of the relationship.

[0160] S11, when dealing with similar entities or similar conflicts again, retrieve and apply matching empirical decision-making patterns from the collaborative knowledge graph to guide subsequent collaborative and calibration operations.

[0161] S11 specifically includes the following sub-steps:

[0162] (1) Scene matching and retrieval: When processing a collaborative task again (for a new entity or a new conflict), the feature vector of the task (including entity features, conflict patterns, etc.) is first extracted. Then, similarity retrieval is performed in the collaborative knowledge graph:

[0163] Calculate the feature similarity between the features of the new task and the features of historical case nodes in the graph (algorithms such as cosine similarity can be used).

[0164] Retrieve one or more historical collaborative cases with the most similar features as similar historical cases.

[0165] (2) Extraction and application of empirical decision-making patterns: From the retrieved similar historical cases, empirical decision-making patterns that have been verified to be effective in those cases are extracted. These empirical decision-making patterns are not simply copies of historical operations, but rather abstract, reusable strategies, mainly including:

[0166] Recommended calibration benchmarks: In similar conflict contexts, calibration benchmarks that have been successfully adopted in historical cases (e.g., "90% of similar cases use the consistency label as a benchmark").

[0167] Calibration operation template: The most effective calibration operation sequence and parameters for this type of conflict (e.g., "first perform unit conversion, then add semantic annotations").

[0168] Anticipated risk warning: Failure feedback from past cases and methods to avoid them.

[0169] (3) Guiding subsequent operations: The extracted experience-based decision-making patterns are pushed to the S300 (collaborative analysis) and S400 (data calibration) stages. For example:

[0170] In S300, potential rule conflict types and historical solutions are indicated.

[0171] In S400, it is recommended to use calibration benchmarks and operation templates with high historical success rates and good feedback, thereby reducing trial and error iterations and directly guiding and accelerating the collaborative process.

[0172] Taking the "wind turbine bearing temperature warning" conflict as an example:

[0173] Spectrum Record (S10): During the initial processing, the recorded entity was "Centrifugal Fan A," and the conflict arose from the rule differences between the MES (threshold: >75℃ alarm) and the SCADA system (threshold: >80℃ alarm). The calibration benchmark adopted a consistency label (based on the equipment manual: >78℃ warning), and the operation was "Logic Reconstruction: Re-determine the original temperature value as 'warning' according to the manual's logic." The feedback result was that both systems accepted it, and the similarity improved to 0.95.

[0174] Application of Experience (S11): When dealing with similar temperature conflicts in "Centrifugal Fan B", a spectral search revealed a high degree of similarity to the "Fan A" case. The extracted empirical decision-making pattern was: "For temperature conflicts in similar fans, it is recommended to use a consistency label (equipment manual) as a benchmark for logical reconstruction calibration." This pattern was recommended to the calibration module, potentially skipping some analysis iterations and directly applying effective strategies to quickly achieve synergy.

[0175] Through S10 and S11, this method achieves continuous self-optimization of the collaborative governance process. It transforms problem-solving experience from a one-time consumable into an accumulative, searchable, and reusable organizational knowledge asset, enabling it to become increasingly intelligent and efficient when facing recurring or similar challenges. This significantly improves the automation level and overall effectiveness of large-scale, long-cycle master data collaborative governance.

[0176] Furthermore, the S500 also includes:

[0177] S20, Based on the historical records in the collaborative knowledge graph, train the conflict prediction model.

[0178] This step aims to build a predictive model based on historical collaborative experience in order to anticipate potential rule conflicts.

[0179] The training data for the conflict prediction model comes from historical collaboration cases recorded in the collaborative knowledge graph. Each case serves as a training sample, containing the following elements: input features (entity attribute data, original data triggering the conflict), process features (rule identifiers of the involved business systems, consistency labels), and outcome features (the actual output of each business system, the calibration rules adopted, and their final feedback effects). The training objective of this model is to learn the complex mapping relationship between input features, process features, and outcome features. Through this training, the model can predict (i.e., deduce) the possible output results of each business system rule based on new input data and corresponding consistency labels.

[0180] Considering the inherent complex relationships within the training data (especially the graph structure), the conflict prediction model can be implemented using algorithms that effectively utilize structured knowledge, such as:

[0181] Graph Neural Network Models: These models take the overall or subgraph structure of a collaborative knowledge graph as input and directly perform inference and prediction by learning the vectorized representations of nodes (such as rules and entities) and edges (such as conflict relationships and calibration operations) in the graph.

[0182] Feature-engineered machine learning models extract predefined features (such as conflict pattern statistics, rule co-occurrence strength, historical calibration success rate, etc.) from historical cases and knowledge graphs, and use these features as input to train traditional machine learning models such as gradient boosting decision trees for prediction.

[0183] S21, when new data is obtained, the new data and the consistency label are input into the conflict prediction model; the conflict prediction model, based on the collaborative knowledge graph, derives the output results that the data processing rules of each business system will produce under the input of the new data.

[0184] This step uses a trained model for forward prediction, aiming to proactively identify rule conflicts that may be triggered when new data flows in.

[0185] When new data about an entity is acquired, instead of waiting for the data to flow through various business systems and actually cause conflicts, the prediction mechanism is immediately activated. The system proactively inputs the new data along with the current consistency label for that entity into the conflict prediction model.

[0186] The conflict prediction model performs a virtual simulation based on historical conflict patterns and rule behaviors learned from a collaborative knowledge graph during the training phase. This simulation essentially mimics the data processing rules of various relevant business systems, deriving (i.e., predicting) the possible outputs of these rules given only this new data as input. This process outputs a set of predicted outputs for each system, forming a snapshot of the potential future system state, revealing potential rule divergences that might occur without intervention.

[0187] S22, the derived output result is logically compared with the consistency label. If there is a logical discrepancy, the historical calibration rule that matches the logical discrepancy is called from the collaborative knowledge graph as the recommended calibration rule.

[0188] This step compares the model's predictions with objective benchmarks and proactively prepares validated solutions for identified potential conflicts. The predicted outputs of each business system derived from the conflict prediction model are logically compared with the state represented by the consistency label, which serves as the objective benchmark. This comparison aims to identify logically contradictory risks, i.e., to determine whether the predictive behavior of any business system will conflict with the objective standard.

[0189] Once a logical contradiction is identified (e.g., a system is predicted to be "abnormally shut down," while the consistency label shows "operating normally"), the collaborative knowledge graph is immediately searched for historical cases that have successfully resolved the same or highly similar logical paradoxes. From these matching cases, validated historical calibration rules are extracted (e.g., "reconstruct the shutdown state into a conditional operating state based on real-time performance parameters").

[0190] Subsequently, the best-matching historical calibration rules are encapsulated into a recommended calibration rule. This recommended rule is not executed immediately, but rather serves as an early warning and contingency plan, pushed to the management interface in advance, or provided as a key input to subsequent collaboration and calibration (S300 / S400) processes, thereby realizing the transformation from passive response to proactive intervention.

[0191] Implementation example: Taking "reactor pressure monitoring" in a production scenario as an example, this illustrates the proactive prediction and contingency plan recommendation mechanism.

[0192] When the sensor collects new data on the "reactor pressure value P", step S21 is executed: the new data P and the current consistency label (determined to be "optimizable within the safe range") generated based on the safety model are input into the conflict prediction model.

[0193] The model is based on learning from the collaborative knowledge graph to deduce the possible outputs of each system: the data processing rules of the MES system may output "warning and suggestion to slow down" because the P value is close to its preset threshold; the rules of the ERP system may output "maintain the current state" because the current production plan requires it.

[0194] Subsequently, the logical comparison in step S22 is performed: the above predicted output is compared with the consistency label ("optimizable within a safe range"). It is determined that the "early warning and slowdown" of MES and the "maintain status" of ERP are logically contradictory to the objective judgment of "optimizable", indicating that there is a potential risk of rule conflict.

[0195] Based on this determination, we immediately retrieved successful historical cases of resolving similar "efficiency and safety metric conflicts" from the collaborative knowledge graph and extracted the verified and effective historical calibration rules. For example, we extracted a rule: "Add semantic annotations to the pressure data, indicating that 'the current pressure is still X% below the safety limit,' and suggest 'optimizing process parameters instead of forcibly reducing the speed.'"

[0196] The extracted rules are encapsulated into a recommended calibration rule and used as an early warning plan, which is then pushed to the operator console in advance or injected into subsequent collaborative processes. This allows for the anticipation of conflicts and the preparation of solutions before stress data formally triggers actual business actions in the MES or ERP systems.

[0197] By integrating steps S20 to S22, this method achieves a fundamental improvement in the collaborative governance model, evolving from passive, responsive collaboration to proactive, predictive collaboration. This is specifically reflected in the following three technical effects:

[0198] Achieving proactive risk identification and early warning: Through real-time analysis of new data and consistency labels using conflict prediction models, potential rule conflicts can be identified before the data formally triggers internal rules in various business systems and causes actual business consequences. This allows governance actions to be taken before the impact occurs, transforming post-event remediation into pre-event intervention.

[0199] It provides intelligent, forward-looking decision support: not only predicting conflicts, but also automatically matching and recommending historically validated calibration rules from the collaborative knowledge graph. This provides ready-to-use and reliable contingency plans for handling impending conflicts, greatly shortening the decision-making and execution cycle from conflict occurrence to finding and implementing the optimal solution, and significantly improving collaborative efficiency.

[0200] A continuously self-optimizing reinforcement loop is formed: the model's prediction results are compared with the actual collaborative situations that subsequently occur, and the differences directly constitute feedback on the model's accuracy. This feedback data is used for continuous iterative optimization of the model, thus forming a reinforcement loop of "prediction → verification → learning → re-prediction". This allows the predictive capabilities and collaborative intelligence of this invention to continuously evolve over time and with the accumulation of cases, possessing significant adaptive and self-learning capabilities.

[0201] Furthermore, the method also includes a real-time maintenance step for the consistency label:

[0202] S610, continuously monitor the data stream of the real-time device metadata.

[0203] This step establishes a continuously running data stream monitoring service. This service interfaces with an IoT platform or device data bus to continuously acquire real-time device metadata streams generated by the entity (such as a specific device) via subscription or pull. These data streams typically include time-series sensor readings, device events, and alarm signals. The monitoring service has buffering and preprocessing capabilities, enabling it to handle high-frequency data and filter noise.

[0204] S620, when the key state parameters of the entity exceed the constraint boundaries defined by the product data, the recalculation and dynamic update of the consistency label are triggered.

[0205] The constraints defined in product data are clearly defined in the early stages of an entity's (product's) lifecycle by its technical specifications or process documents and stored in a structured form, for example:

[0206] Threshold boundary: The upper limit, lower limit or target range of a certain parameter (e.g., "motor winding temperature ≤ 155℃").

[0207] State combination boundary: a composite condition in which multiple parameters must be satisfied simultaneously (e.g., "pressure > 1MPa and flow rate = 0" is considered a dangerous state).

[0208] Rate of change boundary: The maximum allowable change of a parameter per unit time (e.g., "temperature rise rate ≤ 10℃ / minute").

[0209] The real-time monitoring service compares the arriving real-time device metadata with these predefined constraint boundaries in real time. When it is identified that any one or more key status parameters (defined by the business and usually related to security, quality, or core performance) continuously or momentarily exceed (i.e., exceed the upper limit, fall below the lower limit, or violate composite conditions) their corresponding constraint boundaries, it is determined that the entity's status has deviated from its preset compliance ideal range.

[0210] Once an out-of-bounds event is confirmed, the event will act as a high-priority trigger signal, automatically interrupting or suspending the steady-state service of the tag and immediately triggering a recalculation of the consistent tag.

[0211] Triggering context: When the recalculation process is triggered, the current real-time device metadata snapshot, the details of the triggered out-of-bounds event, and the associated product data constraints will be captured as new inputs.

[0212] Recalculation Process: The recalculation process logically reuses step S200, but its input is the latest real-time state. Based on the latest associated data set (consisting of master data, product data, and real-time data from multiple business systems at the time of the boundary violation), a consistency check is performed again to generate a new consistency label reflecting the current boundary violation state. For example, the new label may be updated from "Normal Operation" to "Over-Temperature Warning" or "Efficiency Deviation".

[0213] Dynamic updates: Newly generated consistency labels will dynamically and seamlessly replace old label versions in memory or cache, and update the version number. All subsequent co-analysis, prediction, or calibration operations that depend on this consistency label will be performed immediately based on this new label, ensuring the timeliness of the co-aligned baseline.

[0214] This real-time maintenance step brings a key technical enhancement to the entire approach:

[0215] Ensure the real-time and accuracy of tags: This transforms consistent tags from periodic snapshots into a real-time state view, closely following every critical change in the physical state of the entity, preventing collaborative decision-making errors caused by outdated tags.

[0216] Achieve proactive state management: Instead of passively handling cross-system conflicts caused by state changes, proactively sense state transitions and update collaborative benchmarks in advance before large-scale conflicts occur, thereby transforming passive response into proactive guidance.

[0217] Enhancing overall adaptability and robustness: This method enables the master data governance system to adapt to normal fluctuations and abnormal changes in equipment status during the production process, ensuring the continuous effectiveness and reliability of collaborative logic in a dynamic industrial environment.

[0218] Furthermore, the entity is an entity with an internal topological structure.

[0219] The entity scope that the method described in this invention can effectively manage includes not only single, discrete business objects, but also a class of composite entities with inherently close business relationships, i.e., entities with internal topological structures. In terms of data structure, such entities are represented as a network of multiple nodes connected by specific relationships. Each node represents a sub-entity or component, and the relationships define the business or physical dependency logic between them.

[0220] Typical example:

[0221] An automated production line can have nodes such as individual processing equipment, robotic arms, conveyor belts, and inspection stations; relationships include material flow relationships (the output of equipment A is the input of equipment B) and timing dependencies (station C must start after station D is completed).

[0222] A complete set of equipment: such as a reactor system, the nodes include the reactor body, feed pump, temperature controller, and pressure valve; the relationships include physical connection (pipeline connection) and control linkage (temperature controller adjusts reactor temperature).

[0223] A supply chain path includes nodes such as suppliers, warehouses, transportation units, and production lines; and relationships such as ownership transfer relationships and spatiotemporal sequence relationships.

[0224] When performing master data governance on such entities, each business system may only focus on its local nodes. However, in the collaborative analysis of step S300 of this invention, rule conflicts involving the association logic between multiple nodes can be identified.

[0225] Specifically, in S300, if the identified rule conflict involves the association logic between multiple nodes in the topology, an association calibration operation is performed: calibrated data corresponding to all relevant nodes is generated synchronously. The association calibration operation ensures that the generated calibrated data meets the consistency constraints of the association logic.

[0226] In entities with internal topologies, association logic refers to business rules that transcend individual node attributes and are used to maintain the integrity and coordination of the topology. It manifests as intrinsic relationships such as temporal dependencies, physical connections, or energy / material flow relationships between sub-entities (nodes), describing the inherent relationships of mutual constraints and collaborative operation between nodes. Typical manifestations of association logic include:

[0227] System-level constraints: such as "the overall production line cycle time (production rate) is determined by the processing capacity of the slowest piece of equipment".

[0228] Cross-parameter coupling constraints: such as "the system pressure and internal temperature of the reactor must be maintained within the coupling range defined by the process safety regulations".

[0229] Example of conflicting relevance rules:

[0230] The characteristic of this type of conflict is that local optimization rules targeting a single node can disrupt overall coordination through associative logic. For example, in a production line topology:

[0231] The MES system may determine that upstream equipment D should accelerate its operation to ensure material supply based on the real-time full-load status of downstream equipment E.

[0232] At the same time, the ERP system may require equipment D to reduce its speed to save energy based on overall energy consumption indicators.

[0233] Both rules appear to apply only to node D, but their execution results directly impact the input stability of node E and even the production balance and energy efficiency of the entire production line through the material flow relationships between nodes. This contradiction arising from local decision-making ignoring topological relationships constitutes a rule conflict involving relational logic.

[0234] Correlated calibration operations adhere to two core principles: synchronicity and correlation consistency, ensuring that calibration of local conflicts within the topology does not disrupt overall coordination. The execution process is as follows:

[0235] Conflict impact domain analysis: First, based on the internal topology of the entity, analyze all relevant nodes directly affected by the conflict rules and indirectly affected through the relationship, and determine the complete scope of this calibration.

[0236] Synchronous generation of candidate data schemes: Based on the above analysis, the calibration operation is no longer limited to the direct target node of the conflict, but instead generates a set of candidate data schemes to be verified synchronously for all relevant nodes. For example, for the aforementioned production line conflict, calibration data proposals need to be generated synchronously for the direct conflict point (equipment D) and related affected points (equipment E).

[0237] Apply and verify association logic constraints: After generating candidate data schemes, these schemes are rigorously verified under the association logic defined in the topology structure. Specifically, predefined association rule models (such as material balance equations and timing constraint models) are invoked to verify whether the candidate scheme satisfies the consistency constraints among all nodes. In this invention, consistency constraints refer to a set of business rules and conditions derived from the association logic of the entities, which must be satisfied simultaneously. They stipulate the logical consistency, numerical balance, or timing coordination that must be maintained between the states, attributes, or operations of different nodes (sub-entities) within the topology structure, and are rigid rules that ensure the overall functional integrity of the system. Typical examples of consistency constraints:

[0238] Numerical balance constraints: For example, on a production line, it is required that "the total output of all upstream nodes must equal the total input of all downstream nodes." If a candidate data scheme increases the output rate of a certain piece of equipment, the receiving capacity data of the relevant downstream equipment must be adjusted synchronously to satisfy this material balance.

[0239] State mutual exclusion constraints: For example, in a reaction system, it is stipulated that "when the safety valve (node ​​A) is in the 'open' state, the main feed pump (node ​​B) must not be in the 'full speed' state". Candidate data schemes must simultaneously satisfy this type of state mutual exclusion condition.

[0240] Timing dependency constraints: For example, in an assembly process, it is required that "the 'complete' event of node C (painting) must precede the 'start' event of node D (drying)". The time data involved in candidate solutions must satisfy this sequence. Based on the above verification results, perform deterministic operations:

[0241] Verification passed: If the candidate data scheme satisfies all associated constraints, the candidate data scheme is submitted as an atomic transaction and distributed to the relevant business systems.

[0242] Verification Failure and Backtracking: If a candidate data scheme violates any associated constraint (e.g., acceleration on device D will cause a buffer overflow on device E), the calibration process will automatically backtrack. The calibration baseline or coordination strategy can be adjusted based on feedback, candidate data schemes can be regenerated and verified again until a globally feasible solution that satisfies all associated logical constraints is found.

[0243] In summary, the enterprise master data governance and distribution method based on multi-system collaboration provided by this invention has the following technical effects:

[0244] 1. It solves the root cause of data semantic inconsistency with rules: By creating consistent labels based on product and real-time data that are independent of each system, it provides an objective and unified semantic benchmark and arbitration basis for multi-system data, fundamentally solving data conflicts caused by different understandings between systems.

[0245] 2. An automated and quantifiable collaborative closed loop has been achieved: the collaborative goal has been clarified from the vague goal of reaching consensus to a calculable rule similarity greater than a set threshold, and the system is automatically calibrated through an iterative feedback mechanism, forming a measurable, controllable, and convergent automated governance closed loop, which significantly reduces human intervention.

[0246] 3. Enhanced intelligence and foresight in collaboration: By constructing a collaborative knowledge graph and conflict prediction model, it can learn and reuse historical experience, proactively predict potential conflicts, and pre-recommend solutions, realizing a paradigm shift from passive response to proactive prediction, which greatly improves collaborative efficiency and decision-making intelligence.

[0247] 4. Enhanced system robustness and self-optimization capabilities: Mechanisms such as manual arbitration interface, real-time update of consistency labels, and correlation calibration are designed to handle complex scenarios, adapt to dynamic changes, and continuously learn and optimize from human feedback and actual results, ensuring the long-term effectiveness and adaptability of the governance system in complex industrial environments.

[0248] 5. Ensures global consistency of complex related entities: For entities with internal topological structures such as production lines and equipment groups, an associated calibration operation is proposed to ensure that adjustments to local data meet global business logic constraints and avoid the problem of disrupting overall coordination due to local optimization.

[0249] This invention also provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being configured to perform the method described in this invention.

[0250] This invention also provides a computer-readable storage medium storing computer-executable instructions for performing the methods described in this invention.

[0251] It should be understood that the various forms of processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this invention can be achieved, and this is not limited herein.

[0252] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for enterprise master data governance and distribution based on multi-system collaboration, characterized in that, The method includes the following steps: S100 synchronously obtains master data about the same entity from multiple business systems and associates it with the product data and real-time device metadata corresponding to that entity to form a cross-system associated data set; S200, based on the constraints defined in the product data definition, perform consistency determination on the associated data set and generate a consistency label for uniformly representing the overall state of the entity. The consistency label is independent of the data processing rules of each business system. S300, based on the consistency label, perform collaborative analysis on the data processing rules of each business system, identify rule conflicts, and obtain collaborative analysis results; S400, based on the results of collaborative analysis, calibrates the master data distributed to business systems with rule conflicts, and generates and distributes calibrated data that is adapted to the data processing rules of the business system. S500, based on the feedback from the business systems on the calibrated data, iteratively execute rule coordination and data calibration until the similarity of the data processing rules of each business system for the entity is greater than the set similarity threshold.

2. The method according to claim 1, characterized in that, In S200, the consistency label is generated in the following manner: By integrating the constraints of the product data with the real-time device metadata, a dynamic constraint compliance rule model for the entity is compiled and generated. The associated data set is input into the dynamic constraint compliance rule model for constraint compliance determination, and a multi-dimensional state vector is output as the consistency label.

3. The method according to claim 1 or 2, characterized in that, The S300 specifically includes: The multi-dimensional standardized state represented by the consistency label is logically mapped and compared with the rules in the data processing rule base of each business system, and the first analysis result is output to identify the candidate conflicting rules. Based on the associated dataset as a unified input, the candidate conflict rules identified in the first analysis result are simulated and executed; the simulated output of each candidate conflict rule is compared with the corresponding state in the consistency label. If the comparison result is logically contradictory, the candidate conflict rule is confirmed as the target conflict rule, and a second analysis result containing all target conflict rules is output. The collaborative analysis results are generated based on the first analysis result and the second analysis result.

4. The method according to claim 3, characterized in that, The S400 specifically includes: Based on the preset collaboration priority strategy, the consistency label or the data processing rules of a specific business system are used as the calibration benchmark. Based on the selected calibration benchmark, the original master data is logically mapped or semantically aligned to generate calibrated data that is compatible with the data processing rules of the target business system.

5. The method according to claim 1, characterized in that, In S500, the similarity of the data processing rules is calculated in the following way: Based on the baseline rules and the data processing rules currently in effect for each business system, the same test dataset is processed to obtain the corresponding baseline output result set and the output result set for each business system. The quantitative similarity value of the data processing rules of each business system is obtained by calculating the Jaccard similarity coefficient or cosine similarity between the output result set of each business system and the benchmark output result set.

6. The method according to claim 1, characterized in that, The S500 also includes: Record the differences and feedback results of each rule collaboration and data calibration to form a collaborative knowledge graph; When dealing with similar entities or conflicts again, matching empirical decision-making patterns are retrieved from the collaborative knowledge graph and applied to guide subsequent collaborative and calibration operations.

7. The method according to claim 6, characterized in that, The S500 also includes: A conflict prediction model is trained based on the historical records in the collaborative knowledge graph. When new data is acquired, the new data and the consistency label are input into the conflict prediction model; the conflict prediction model, based on the collaborative knowledge graph, derives the output results that the data processing rules of each business system will produce under the input of the new data. The derived output is logically compared with the consistency label. If there is a logical discrepancy, the historical calibration rule that matches the logical discrepancy is retrieved from the collaborative knowledge graph and used as the recommended calibration rule.

8. The method according to claim 1, characterized in that, During the iteration of S500, if the similarity of a business system still cannot reach the set similarity threshold after multiple calibrations of the data processing rules of a certain business system, an external arbitration instruction will be received through the manual arbitration interface. The external arbitration instruction shall be used as the new rule benchmark, and at least one of the following operations shall be performed accordingly: (a) Modify the generation logic of the consistency tag; (b) Adjust the aforementioned collaboration priority strategy.

9. The method according to claim 1 or 2, characterized in that, It also includes a real-time maintenance step for the consistency tags: Continuously monitor the data stream of the real-time device metadata; When the entity's key state parameters exceed the constraint boundaries defined by the product data, a recalculation and dynamic update of the consistency label is triggered.

10. The method according to claim 1, characterized in that, The entity is an entity with an internal topology structure; in S300, if the identified rule conflict involves the association logic between multiple nodes in the topology structure, then an association calibration operation is performed: calibrated data corresponding to all relevant nodes is generated synchronously; wherein, the association calibration operation ensures that the generated calibrated data meets the consistency constraints of the association logic.

Images