Multi-factory production master data distribution method based on message bus
By adopting a message bus-based multi-factory production master data distribution method, the problems of data structure adaptability, ambiguous ownership, and inflexible distribution are solved, realizing real-time and reliable distribution of production master data and meeting the accuracy and real-time requirements of multi-factory production processes.
Patent Information
- Application Number
- CN202610092245.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-01-23
- Publication Date
- 2026-05-19
AI Technical Summary
Existing technologies for managing master data in multi-factory production suffer from poor data structure adaptability, ambiguous data ownership, and insufficient distribution flexibility and fault tolerance, making it difficult to meet the real-time and accuracy requirements of the production process.
A message bus-based multi-factory production master data distribution method is adopted. Through flexible modeling, data access, and dynamic distribution architecture, the production master data model can be customized, and the data of multiple factories can be accurately isolated and defined. Combined with incremental real-time distribution and fault-tolerant retransmission mechanism, the real-time performance and reliability of the data are ensured.
It enables dynamic adaptation of production master data structures across different industries, clarifies the ownership of data factories, ensures real-time synchronization and integrity of data, reduces system development and maintenance costs, minimizes the risk of data misuse, and meets the real-time requirements of production scenarios.
Smart Images

Figure CN122069130A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the fields of Internet of Things, Industrial Internet and smart factory technology, specifically a method for distributing production master data across multiple factories based on a message bus. Background Technology
[0002] Against the backdrop of accelerated digital transformation in the manufacturing industry, manufacturing enterprises face two core challenges: First, the shortening of product lifecycles and the increase in customization demands have led to a significant increase in the complexity of the production process, which greatly increases the reliance on the real-time and accuracy of production master data (such as material data and factory-material association data); Second, the expansion of enterprise capacity is driving the transformation of factory layout from "single-factory centralized" to "group multi-factory distributed", and the management scope of production master data has extended from a single factory to a multi-factory cluster across regions and business lines.
[0003] Current mainstream multi-factory production master data synchronization solutions in the industry generally adopt a "custom development + fixed architecture" model, which has the following key technical defects: 1. Poor data structure adaptability: The production master data has different structures for different industries (such as automobile manufacturing, electronic components, and mechanical equipment). The data model and synchronization logic need to be adjusted through secondary development. It cannot dynamically adapt to industry characteristics, resulting in long system development cycles, high maintenance costs, and difficulty in responding to the rapid iteration needs of enterprise business. 2. Ambiguous data ownership definition: The existing solution does not clearly define the "factory ownership" dimension of production master data, but only identifies data attributes through basic fields. It does not establish a strong correlation between data and factories, which can easily lead to data being mixed up between multiple factories (such as material data of factory A being mistakenly used in the production plan of factory B), causing problems such as production scheduling chaos and material management errors. 3. Insufficient distribution flexibility and fault tolerance: Most solutions only support timed synchronization of full data, which cannot meet the real-time requirements for data changes in production scenarios (such as the need for immediate synchronization of material specification updates to downstream production systems), and also lack a mechanism for retransmission after data loss, posing a risk of data synchronization interruption.
[0004] Therefore, there is an urgent need for a multi-factory production master data distribution method that can dynamically adapt to different industry data structures, clearly define the data factory ownership, and achieve accurate, real-time, and reliable distribution to address the shortcomings of existing technologies. Summary of the Invention
[0005] (a) Technical problems to be solved To address the shortcomings of existing technologies, this invention provides a method for distributing production master data across multiple factories based on a message bus. By constructing a three-layer technical architecture of "flexible modeling - data access - dynamic distribution," it enables custom configuration of the production master data model, precise isolation and attribution of data across multiple factories, and incremental real-time distribution and fault-tolerant retransmission based on a message bus. This solves the technical pain points of existing solutions in terms of adaptability, accuracy, real-time performance, and reliability.
[0006] (II) Technical Solution To achieve the above objectives, the present invention provides the following technical solution: a method for distributing production master data across multiple factories based on a message bus, comprising the following steps: Step 1: Flexible modeling of production master data, supporting users to visually define the field structure of the production master data model and configure the relationships between models; Step 2: Production master data access and update, realizing data entry, modification and deletion through interface integration or manual maintenance; Step 3: Configure the distribution object, defining the target application identifier, distribution data structure, and data filtering conditions; Step 4: Implement incremental real-time distribution and proactive publishing based on the message bus to ensure data real-time performance and integrity; Step 5: Data distribution verification and feedback. After subscribing to the application, the system verifies the data and provides feedback. The system then redistributes the data based on the feedback.
[0007] Preferably, in step one, the field structure includes field name, data type, and whether it is required. The data type includes character, integer, reference type, and character array type. The character array type is used to identify the factory cluster to which the data belongs.
[0008] Preferably, in step one, the relationship between the models is established through reference type fields, the display rules of the reference fields are configured, and only the key fields of the source model are displayed when maintaining the target model data.
[0009] Preferably, in step three, the data filtering conditions are configured differently for different data types: the character array type supports overlapping matching and IN conditions; the character / integer field supports equal to, not equal to, contain, and IN conditions.
[0010] Preferably, in step four, the incremental real-time distribution automatically detects and pushes matching data when data changes; the proactive publishing supports manually triggering the publishing of historical data and automatically re-uploading lost data.
[0011] Preferably, in step four, the message bus uses Kafka or RabbitMQ, the distributed messages are encapsulated in JSON format, and the distribution delay is controlled within 100 milliseconds.
[0012] Preferably, in step five, when the subscription application verification fails, the system redistributes the application according to a preset number of retries (1-5 times), with the retry interval increasing sequentially.
[0013] (III) Beneficial Effects This invention provides a method for distributing production master data across multiple factories based on a message bus, which has the following advantages: 1. This invention, through a flexible modeling mechanism, can adapt to the production master data structure of different industries without customized development, reducing system development and maintenance costs and responding to the rapid iteration needs of enterprise business; and by introducing a "domain" character array field, the ownership of data factories is clearly defined, and combined with precise filtering rules, data isolation and accurate distribution across multiple factories are achieved, avoiding data misuse.
[0014] 2. This invention features an incremental real-time distribution mode based on a message bus, ensuring data changes are synchronized within seconds to meet the real-time requirements of production scenarios. The proactive publishing and automatic retransmission mechanisms guarantee the integrity of data distribution, resolving data loss issues. Furthermore, it supports customizable data structures and filtering condition combinations for distribution, reducing redundant data transmission, adapting to the interface requirements of different subscription applications, and lowering the difficulty of cross-system integration. The entire distribution process is recorded with distribution logs and verification feedback, enabling full traceability of the data distribution process and facilitating troubleshooting and system optimization. Attached Figure Description
[0015] Figure 1 This is a schematic diagram of the "material" model field structure of the present invention; Figure 2 This is a schematic diagram of example data for the "material" model and the "plant-material" model of the present invention; Figure 3 This is a schematic diagram of example data for the "material" model and the "plant-material" model of the present invention.
[0016] Among them, 101 represents the "material" model structure; 102-106 are the fields in the "Material" model and their corresponding data types; 107 is the "factory-material" model, used to record independent attribute information within a factory; 108-113 are the fields in the "Plant-Material" model and their corresponding data types; 114 is the reference data configuration information for the material code field in the "Plant-Material" model, used to associate it with the "Material" model; 115 is used to display material data in a list format when maintaining material data in the "Plant-Material" model; 116 indicates that the material code field of the "Plant-Material" model is associated with the "Material" model; 117 links the material code field of the "Plant-Material" model with the material code field of the "Material" model; When maintaining material data in the "Plant-Material" model, 118 only displays the material code, material name, and material specification fields in the list.
[0017] 201 represents the fields and sample data for the "Material" model; 202-203 are example material data; 204 contains field and example data for the "Plant-Material" model; 205-207 are sample factory-material data.
[0018] 301 contains field and sample data for the "Plant-Material" model; 302-304 are example data for "Plant-Materials"; 305 is the distribution target for "Plant-Materials"; 306 refers to the published data structure and fields to be published defined in the "Factory-Material" distribution object; 307 refers to the filter criteria defined in the "Plant-Material" distribution object; 308 is the data structure to be published corresponding to the distribution object defined in 306; 309 represents the "Plant-Materials" data required for the data to be released; 310 represents the "material" data required in the data to be released; 311 defines a filtering condition for 307, such as "belonging to domain && A factory", which means that the character array field value of the belonging to domain contains "A factory". 312 represents the fields defined for filtering conditions, such as the domain field; 31 represents the judgment condition corresponding to the filter condition field, such as "&&" which indicates an overlap condition (there are common elements in the data and the value); 314 represents the field value corresponding to the filter condition, such as "Factory A"; 315 refers to the published data packets corresponding to the distribution objects defined in 306; 316 to 317 are the matching results corresponding to filter condition 307. Detailed Implementation
[0019] 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. Example 1:
[0020] This invention provides a method for distributing production master data across multiple factories based on a message bus, comprising the following steps: Step 1: Flexible Modeling of Production Master Data 1.1) Customizable Model Structure: Supports users to visually define the field structure of the production master data model, including field names, data types, and whether they are required; the data types include character, integer, reference, and character array types, where the character array type is used to identify the factory cluster to which the data belongs; (1) An exemplary “material model” can define the following fields: material code (character type, unique identifier), material name (character type), material specification (character type), financial category (character type), whether it is batch management (integer type, 1 indicates yes, 0 indicates no); (2) An exemplary “plant-material model” can define the following fields: belonging domain (character array, identifying the plant to which the data belongs, such as [“Plant A”, “Plant B”]), plant code (character type, unique identifier of the plant), and material code (reference type).
[0021] 1.2) Model Association Configuration: Set the fields of the target model to "reference type" to establish an association with the source model; configure the display rules of the referenced fields so that only the key fields of the source model are displayed when maintaining the target model data; For example, the "Material Code" field of the "Plant-Material Model" is configured to reference the "Material Code" field of the "Material Model". When maintaining the "Plant-Material" data, only the "Material Code", "Material Name", and "Material Specification" fields are displayed.
[0022] Step 2: Production Master Data Access and Update Two data access methods are provided, supporting data entry, modification, and deletion operations: 2.1) Interface Integration and Access: Provides standardized RESTful API interfaces to interface with enterprise ERP, MES and other business systems to achieve automatic synchronization and updating of production master data; 2.2) Manual maintenance access: Provides a visual data maintenance interface, supporting users to manually enter new data, modify existing data, or delete invalid data, adapting to temporary data adjustment and small-batch data maintenance scenarios.
[0023] Step 3: Configure the dispatch object Based on the subscription application requirements, the core parameters of the distribution object are defined, including the target application identifier, distribution data structure, and data filtering conditions: 3.1) Target application identifier: Clearly define the data recipient, such as "Factory A MES system" or "Group supply chain management system"; 3.2) Distribution data structure: Customize the combination of fields to be published, including only the fields required by the subscribing application; For example, configure the distribution structure for the MES system of factory A as follows: Domain + Factory Code + Material Code + Financial Category + Material Name + Material Specification; 3.3) Data filtering conditions: Configure differentiated filtering rules for fields of different data types: Character array type (e.g., "belonging field"): supports overlapping matching (belonging field contains the target factory) and IN (belonging field specifies multiple factories) conditions; Character / integer fields (such as "financial category" or "whether batch management"): support equal to, not equal to, contain, and IN conditions.
[0024] Step 4: Dynamic Dispatch Based on Message Bus Based on a message bus, two modes are implemented: incremental real-time distribution and proactive publishing, ensuring the real-time performance and integrity of data distribution. 4.1) Incremental Real-time Distribution: When production master data is added, modified, or deleted, the system automatically detects the data change and determines whether the changed data matches the filtering conditions of the distribution object. If it matches, it is encapsulated into a message according to the preset distribution structure and pushed to the target application in real time through the message bus. 4.) Active publishing operation: Supports users to manually trigger the republishing of historical data; the system periodically verifies the distribution records, and if data loss is detected (such as message bus transmission interruption), it automatically triggers the retransmission mechanism; 4.3) Message transmission: The message is encapsulated and distributed in JSON format, which includes data identifier, domain, factory code, associated fields and business field information to ensure that the subscribing application can directly parse and use it.
[0025] Step 5: Data Distribution Verification and Feedback After receiving the distribution message, the subscribing application verifies the integrity and format correctness of the data. If the verification passes, it returns "received successfully" feedback; if the verification fails, it returns "received failed" and the reason for the error. The system will re-trigger data distribution based on the feedback result until the distribution is successful or the preset number of retries (default 3 times) is reached. Example 2:
[0026] Based on Example 1: Furthermore, in step 1, the visual modeling supports drag-and-drop operations, allowing users to configure the model structure by dragging and dropping field components without writing code.
[0027] Furthermore, in step three, the data filtering conditions support combined configuration, and multiple conditions are associated through "AND / OR" logic to meet the filtering needs of complex scenarios.
[0028] Furthermore, in step four, the message bus adopts Kafka or RabbitMQ, which supports high-concurrency data transmission and controls the distribution latency to within 100 milliseconds.
[0029] Furthermore, in step four, the system records the distribution log for each piece of data, including information such as distribution time, target application, distribution status, and message content, and supports log querying and tracing.
[0030] Furthermore, in step five, the preset number of retries can be customized by the user, ranging from 1 to 5 times, with the retry interval increasing sequentially (default intervals of 1 second, 3 seconds, and 5 seconds). Example 3:
[0031] The core of this invention lies in constructing a three-layer technical architecture of "flexible modeling - data access - dynamic distribution," which realizes full lifecycle management of multi-factory production master data based on a message bus. The specific implementation process is as follows: (a) Flexible modeling of production master data 1. Customizable Model Structure: Users can visually define the field structure of the production master data model (including field names, data types, and whether fields are required) according to the actual business needs of the project. For example... Figure 1 Taking typical "material model" and "plant-material model" as examples: (1) The fields that can be defined in the “Material Model” include: Material Code (character type, unique identifier), Material Name (character type), Material Specification (character type), Financial Category (character type), and Whether it is batch managed (integer type, 1 indicates yes, 0 indicates no); (2) The “Factory-Material Model” is used to record the association attributes between factories and materials. The fields that can be defined include: the domain (character array, which identifies the factory to which the data belongs, such as [“Factory A”, “Factory B”]), the factory code (character type, a unique identifier of the factory), and the material code (reference type, associated with the “Material Code” field of the “Material Model”).
[0032] 2. Model Inter-Model Association Configuration: Supports setting field types to "Reference Type" to establish cross-model associations. For example, the "Material Code" field of the "Plant-Material Model" can be configured to reference the "Material Code" field of the "Material Model," enabling linked queries between the two models (such as automatically retrieving material name, specifications, and other information through Plant-Material data association). Simultaneously, the "Display Rules" for referenced fields can be configured. For instance, when maintaining "Plant-Material" data, only key fields such as "Material Code," "Material Name," and "Material Specification" can be displayed, simplifying the operation process.
[0033] (ii) Access and update of production master data It supports two data access methods to meet data maintenance needs in different scenarios: 1. Interface Integration and Access: Provides standardized API interfaces (such as RESTful API) that can be connected with existing business systems such as enterprise ERP and MES to achieve automatic synchronization and updating of production master data (such as real-time synchronization to the master data model of this invention after material changes in the ERP system). 2. Manual maintenance access: Provides a visual data maintenance interface, supporting users to manually enter new data, modify existing data, or delete invalid data, suitable for temporary data adjustments and small-batch data maintenance scenarios.
[0034] by Figure 2 For example, the data accessed by the "Material Model" includes: material code "001" corresponding to material name "Material A", specification "3*5mm", financial category "finished product", and whether it is batch management "1"; the data accessed by the "Factory-Material Model" includes: domain "Factory A", factory code "1001", and material code "001", realizing the association and binding between Factory A and "Material A".
[0035] (iii) Dynamic distribution based on message bus Driven by "application subscription needs," precise data distribution is achieved through configuring distribution rules and based on the message bus. The specific steps are as follows: 1. Distribution Object Configuration: Users define the core parameters of the distribution object according to the needs of the subscribed application (such as a factory production execution system or a group supply chain management system): (1) Target application identifier: Clearly identify the data recipient (e.g., "Factory A MES system" or "Group CRM system"); (2) Distribution data structure: Customize the combination of fields to be published. For example, configure the distribution structure of the MES system of Factory A as "Domain + Factory Code + Material Code + Financial Category + Material Name + Material Specification", which only contains the fields required by the application and reduces data transmission redundancy; (3) Data filtering conditions: Configure flexible filtering rules for fields of different data types, for example: 3.1) Character array type (e.g., "belonging domain"): Supports conditions such as "overlapping match" (e.g., "belonging domain contains factory A") and "IN" (e.g., "belonging domain is factory A or factory B"); 3.2) Character / integer fields (such as "financial category" and "whether it is batch managed"): support conditions such as "equal to", "not equal to", and "include" (such as "financial category = finished product", "whether it is batch managed = 1", "financial category IN (finished product, semi-finished product)").
[0036] 2. Data Distribution and Execution: Two distribution modes are implemented based on the message bus, balancing real-time performance and fault tolerance: (1) Incremental real-time distribution: When the production master data is added, modified or deleted, the system automatically detects the data change and determines whether the changed data matches the filtering conditions of the distribution object; if it matches, the data is encapsulated into a message according to the preset distribution structure and pushed to the target application in real time through the message bus; (2) Active publishing operation: Supports users to manually trigger data publishing (such as manually selecting historical data to republish after system failure recovery). At the same time, the system periodically verifies the distribution records. If data loss is detected (such as message bus transmission interruption causing non-delivery), the automatic retransmission mechanism is triggered to ensure data integrity.
[0037] by Figure 3 For example, configure the distribution object for the MES system of factory A: the filter condition is "the domain contains factory A", and the distribution structure is "domain + factory code + material code + financial category + material name + material specification". When the data of "Factory A-1001-001" in "Factory-Material Model" changes, the system automatically matches the filter condition, associates it with the data of "Material A-3*5mm" in "Material Model", generates a message and pushes it to the MES system of factory A to achieve accurate data synchronization.
[0038] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.
Claims
1. A method for distributing production master data across multiple factories based on a message bus, characterized in that: Includes the following steps: Step 1: Flexible modeling of production master data, supporting users to visually define the field structure of the production master data model and configure the relationships between models; Step 2: Production master data access and update, realizing data entry, modification and deletion through interface integration or manual maintenance; Step 3: Configure the distribution object, defining the target application identifier, distribution data structure, and data filtering conditions; Step 4: Implement incremental real-time distribution and proactive publishing based on the message bus to ensure data real-time performance and integrity; Step 5: Data distribution verification and feedback. After subscribing to the application, the system verifies the data and provides feedback. The system then redistributes the data based on the feedback.
2. The method for distributing production master data across multiple factories based on a message bus according to claim 1, characterized in that: In step one, the field structure includes field name, data type, and whether it is required. The data type includes character, integer, reference type, and character array type. The character array type is used to identify the factory cluster to which the data belongs.
3. The method for distributing production master data across multiple factories based on a message bus according to claim 2, characterized in that: In step one, the relationships between the models are established through reference type fields, the display rules of the reference fields are configured, and only the key fields of the source model are displayed when maintaining the target model data.
4. The method for distributing production master data across multiple factories based on a message bus according to claim 3, characterized in that: In step three, the data filtering conditions are configured differently for different data types: the character array type supports overlapping matching and IN conditions; the character / integer field supports equal to, not equal to, contain, and IN conditions.
5. The method for distributing production master data across multiple factories based on a message bus according to claim 1, characterized in that: In step four, the incremental real-time distribution automatically detects and pushes matching data when data changes; the proactive publishing supports manually triggering the publishing of historical data and automatically re-uploading lost data.
6. The method for distributing production master data across multiple factories based on a message bus according to claim 5, characterized in that: In step four, the message bus uses Kafka or RabbitMQ, the distributed messages are encapsulated in JSON format, and the distribution delay is controlled within 100 milliseconds.
7. The method for distributing production master data across multiple factories based on a message bus according to claim 1, characterized in that: In step five, when the subscription application verification fails, the system redistributes the application according to the preset number of retries (1-5 times), with the retry interval increasing sequentially.
