An industrial data integration aluminum plate batch chain processing method and system
Patent Information
- Application Number
- CN202611191247.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-08-07
- Publication Date
- 2026-10-23
AI Technical Summary
[0006]本发明的目的在于提供一种工业数据集成铝板批次链处理方法及系统,通过依据母卷可用宽度、各子卷宽度及分切位置形成连续且互不重叠的物理区间,将同一物理区间端点同时登记为子卷归属边界、分切设备侧数据库的数据分片边界和跨库同步校核边界,并根据父子映射、批次链分裂序号及子卷与物理区间的关联生成跨库同步任务键、确定局部数据分片的接收节点,继而执行全局冶炼轧制履历复制、局部数据分片定向分发以及同步校核边界内的差异核对和处理,以解决现有技术中边界口径不一致导致局部剪切数据错配、物理区间与节点路由缺少连续关联导致局部分片写入无关子卷数据库,以及跨库核对范围不统一导致虚假差异的问题
[0018]本发明通过依据母卷可用宽度、子卷宽度及分切位置形成连续且互不重叠的物理区间,并将同一物理区间端点同时登记为子卷归属边界、设备侧数据分片边界和跨库同步校核边界,使局部剪切数据归属、数据分片和跨库同步核对采用统一边界口径;通过父子映射、分裂序号及子卷与物理区间的关联生成跨库同步任务键并确定接收节点,使物理区间、局部分片与目标子卷数据库连续对应;通过复制全局冶炼轧制履历、定向分发局部分片,并在同步校核边界内执行差异核对、增量补传和冲突拦截,使各子卷完整继承母卷全局履历并仅接收对应局部分片,从而减少局部数据错配、冗余或重复写入及虚假差异,提高子卷追溯记录和跨库同步记录的一致性。
Smart Images

Figure CN122964176A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of distributed database data processing technology, specifically to a method and system for batch chain processing of integrated industrial data on aluminum plates. Background Technology
[0002] After aluminum sheet master coils are slit into multiple sub-coils, the overall history of smelting, rolling, and quality needs to be inherited by each sub-coil, while local shearing data such as shearing force, blade gap, width coordinates, and acquisition time need to be assigned to the corresponding sub-coil according to the actual slit range. The above data is usually distributed across the batch chain master database, the slit equipment side database, and multiple sub-coil databases, involving cross-database replication, distribution, and synchronization processing.
[0003] Existing technologies typically establish a parent-child relationship using a parent volume identifier and a child volume identifier, copy the parent volume history to the child volume record, and segment and write local data based on the child volume number, preset fragmentation rules, or device-side location records. After the data transmission is completed, the records in different databases are checked using version numbers, timestamps, or synchronization status, and missing, late, or duplicate records are retransmitted, updated, or intercepted.
[0004] However, in existing processes, subvolume ownership boundaries, device-side data fragmentation boundaries, and cross-database synchronization verification ranges are often formed separately, and there is a lack of continuous association between physical intervals, task keys, and receiving nodes. After the parent volume is split along the width direction, inconsistent boundary diameters can easily cause locally cut data to be assigned to the wrong subvolume. Furthermore, the general distribution relationship may cause some fragments to be written to unrelated subvolume databases, resulting in false differences for the same record in different databases and affecting the consistency of subvolume traceability records.
[0005] The information disclosed in this background section is intended only to enhance the understanding of the overall background of the invention and should not be construed as an admission or in any way implying that the information constitutes prior art known to those skilled in the art. Summary of the Invention
[0006] The purpose of this invention is to provide an industrial data integration aluminum plate batch chain processing method and system. This method involves forming continuous and non-overlapping physical intervals based on the available width of the parent roll, the width of each sub-roll, and the cutting position. The endpoints of the same physical interval are simultaneously registered as the sub-roll ownership boundary, the data fragmentation boundary of the cutting equipment's database, and the cross-database synchronization verification boundary. Based on the parent-child mapping, batch chain split sequence number, and the association between the sub-roll and the physical interval, a cross-database synchronization task key is generated, and the receiving node for the local data fragment is determined. Subsequently, global smelting and rolling history replication, targeted distribution of local data fragments, and difference verification and processing within the synchronization verification boundary are performed. This addresses the problems in existing technologies, such as inconsistent boundary standards leading to local cut data mismatch, lack of continuous association between physical intervals and node routes resulting in local fragments being written to unrelated sub-roll databases, and inconsistent cross-database verification scope leading to false differences.
[0007] The technical solution of this invention is as follows: On one hand, this invention provides an industrial data integration aluminum plate batch chain processing method, including: acquiring the master roll identifier, global smelting and rolling history, and local shearing data and acquisition time identifier collected by the slitting unit along the width coordinate; establishing a master roll history entry record and determining the master roll version in the batch chain master database; sorting the local shearing data according to the width coordinate; generating continuous and non-overlapping physical intervals corresponding to each sub-roll by combining the available width of the master roll, the width of each sub-roll, and the slitting position; simultaneously registering the endpoints of the same physical interval as the sub-roll ownership boundary, the data fragmentation boundary of the slitting equipment side database, and the cross-database synchronization verification boundary; and extracting the local shearing data according to the data fragmentation boundary to form local data fragments; when a topological split occurs in the batch chain, acquiring the sub-roll identifier, global smelting and rolling history, and local data processing method for industrial data integration aluminum plate batch chain processing method; when a topological split occurs in the batch chain, acquiring the local data fragmentation data. The system establishes a parent-child mapping between the parent volume identifier and the child volume identifier, based on the volume identifier and batch chain split sequence number. According to the parent-child mapping, the batch chain split sequence number, and the association between the child volume identifier and the physical region, a cross-database synchronization task key is generated, shared by the batch chain master database, the splitting device side database, and the child volume database. The receiving node for each local data fragment is determined. The global smelting and rolling history is copied to each child volume database, and the local data fragments are distributed according to the receiving node corresponding to the cross-database synchronization task key. Within the cross-database synchronization verification boundary, the synchronization records of the three types of databases are checked based on the parent volume version, batch chain split sequence number, and acquisition time identifier. Incremental retransmission or conflict interception is performed on discrepancies. When the verification is consistent, the corresponding child volume data is submitted, forming a child volume traceability record.
[0008] Furthermore, the acquisition of global smelting and rolling history and local shearing data includes: reading smelting records, rolling records and quality records corresponding to the master coil identifier; organizing the global smelting and rolling history according to the record version and formation time and determining the master coil version; reading shearing force, blade gap, width coordinate and acquisition time; binding data from the same acquisition location with the master coil identifier to form the local shearing data.
[0009] Furthermore, the generation of physical intervals and local data fragments includes: determining the interval endpoints sequentially according to the coordinate order of the available width of the parent volume, based on the width of each sub-volume and the cutting position; verifying the continuity relationship of adjacent interval endpoints and the coverage relationship of all physical intervals to the available width of the parent volume; and when the verification is consistent, extracting the local cut data according to the width range defined by each physical interval to form local data fragments corresponding one-to-one with the sub-volumes.
[0010] Furthermore, the registration data sharding boundary and synchronous verification boundary include: comparing the interval endpoints in the sharding device-side database with the width intervals of the corresponding subvolumes in the batch chain master database across databases; when the boundaries are inconsistent, correcting the interval endpoints according to the sharding position, and synchronously updating the corrected interval endpoints as the subvolume ownership boundary, data sharding boundary, and cross-database synchronous verification boundary; and continuing to constrain local cut data truncation, subvolume ownership determination, and synchronous record verification with the updated same boundary.
[0011] Furthermore, the generation of cross-database synchronization task keys includes: responding to batch chain topology split events, generating cross-database synchronization task keys for each sub-volume based on parent-child mapping and batch chain split sequence number; establishing synchronization entries carrying the same cross-database synchronization task key in the batch chain master database, the split device side database, and the corresponding sub-volume database, so that the parent volume version, sub-volume identifier, physical range, and local data fragments are associated along the cross-database synchronization task key.
[0012] Furthermore, the verification of synchronization records includes: using the cross-database synchronization task key as the verification index, querying the batch chain master database, the split device side database, and the sub-volume database respectively within the scope defined by the synchronization verification boundary to form a master database record set, a device database record set, and a sub-volume database record set; comparing the cross-database synchronization task key, parent volume version, batch chain split sequence number, data shard boundary, and acquisition time identifier in each record set to determine the difference records and their respective physical intervals.
[0013] Furthermore, the incremental retransmission or conflict interception includes: identifying records that exist in the main database record set or device database record set but not in the corresponding sub-volume database record set as missing records; identifying records that arrive after a preset synchronization time window as late records; and identifying records with the same cross-database synchronization task key, physical range, width coordinate, and acquisition time identifier as duplicate records; generating incremental retransmission tasks limited to the corresponding physical range for missing records and late records that still do not exist in the corresponding sub-volume database record set; and performing write interception on duplicate records.
[0014] Furthermore, determining the receiving node for the local data fragment includes: querying the subvolume node table based on the cross-database synchronization task key, associating the subvolume identifier, corresponding physical range, and local data fragment with the corresponding subvolume database; when distributing the local data fragment, determining the receiving node according to the association relationship, and writing the local data fragment to the corresponding subvolume database.
[0015] Furthermore, after performing incremental retransmission or conflict interception, the process further includes: for the sub-volume data that has completed history copying, fragment distribution, and difference processing, verifying the parent volume version, batch chain split sequence number, data fragment boundary, data source, and cross-database synchronization task key; if the verification is consistent, submitting the corresponding sub-volume data and writing the synchronization completion status to the above three types of databases; if the verification is inconsistent, locating the affected local data fragments and receiving nodes, performing at least one of re-truncation, incremental retransmission, and targeted update, and verifying again.
[0016] On the other hand, the present invention also provides an industrial data integration aluminum plate batch chain processing system, including a batch chain master database, a slitting equipment side database, multiple sub-volume databases, a data acquisition module, a fragment generation module, a synchronization task module, a replication and distribution module, and a consistency processing module; the data acquisition module is used to acquire the parent roll identifier, the global smelting and rolling history, and the local shearing data and acquisition time identifier collected along the width coordinate, establish a parent roll history entry record in the batch chain master database, and determine the parent roll version; the fragment generation module is used to sort the local shearing data according to the width coordinate, generate continuous and non-overlapping physical intervals according to the available width of the parent roll, the width of each sub-volume, and the slitting position, and simultaneously register the endpoints of the same physical interval as the sub-volume ownership boundary, data fragment boundary, and synchronization verification boundary, and form local data fragments corresponding to each sub-volume; the synchronization task... The module is used to obtain the sub-volume identifier and batch chain split sequence number when a topology split occurs in the batch chain, establish a parent-child mapping between the parent volume identifier and the sub-volume identifier, generate a cross-database synchronization task key shared by the three types of databases based on the parent-child mapping, the batch chain split sequence number, and the association between the sub-volume identifier and the physical interval, and determine the receiving node of the local data fragment; the replication and distribution module is used to replicate the global smelting and rolling history to each sub-volume database, and distribute the local data fragments in a targeted manner according to the receiving node corresponding to the cross-database synchronization task key; the consistency processing module is used to check the synchronization records of the three types of databases based on the parent volume version, batch chain split sequence number, and acquisition time identifier within the scope limited by the synchronization verification boundary, perform incremental retransmission or conflict interception on the difference records, and submit the sub-volume data composed of the global smelting and rolling history and the corresponding local data fragments when the verification is consistent.
[0017] The beneficial effects of this invention are as follows:
[0018] This invention forms continuous and non-overlapping physical intervals based on the available width of the parent volume, the width of the child volume, and the splitting position. The endpoints of the same physical interval are simultaneously registered as the child volume ownership boundary, the device-side data fragmentation boundary, and the cross-database synchronization verification boundary, ensuring a unified boundary standard for local cut data ownership, data fragmentation, and cross-database synchronization verification. Cross-database synchronization task keys are generated and receiving nodes are determined through parent-child mapping, splitting sequence numbers, and the association between child volumes and physical intervals, ensuring continuous correspondence between physical intervals, local fragments, and the target child volume database. By replicating the global smelting and rolling history, distributing local fragments, and performing difference verification, incremental retransmission, and conflict interception within the synchronization verification boundary, each child volume fully inherits the parent volume's global history and only receives the corresponding local fragments. This reduces local data mismatches, redundancy, duplicate writes, and false differences, improving the consistency of child volume traceability records and cross-database synchronization records. Attached Figure Description
[0019] Figure 1 This is a schematic diagram of the overall process of the industrial data integration aluminum plate batch chain processing method provided in one embodiment of the present invention; Figure 2 This is a schematic diagram illustrating the correspondence between physical regions, local data, and triple boundaries provided in one embodiment of the present invention; Figure 3 This is a schematic diagram of batch chain topology splitting, cross-database synchronization task keys, receiving nodes, and differential replication and distribution relationships provided in one embodiment of the present invention; Figure 4 This is a schematic diagram of the process for verifying and processing differences of three types of database records within the synchronous verification boundary provided in one embodiment of the present invention; Figure 5 This is a schematic diagram of the timing of the master volume version, batch chain splitting event, acquisition time, fragment distribution and synchronization completion status write-back provided in one embodiment of the present invention. Detailed Implementation
[0020] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only for explaining the invention and are not intended to limit the invention; that is, the described embodiments are merely some embodiments of the invention, and not all embodiments. The components of the embodiments of the invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.
[0021] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.
[0022] It should be noted that relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0023] As mentioned earlier, after the master roll is split into multiple sub-rolls along its width, the global smelting and rolling history and local shearing data are stored in the batch chain master database, the splitting equipment side database, and the sub-roll database, respectively. When the sub-roll ownership boundary, the equipment side data fragmentation boundary, and the cross-database synchronous verification range are formed separately, and there is a lack of continuous association between the physical interval and the task key and the receiving node, local shearing data is prone to being assigned to the wrong sub-roll or written to the irrelevant sub-roll database, and may form false differences due to inconsistencies in the cross-database verification range.
[0024] To address this, the present invention provides an industrial data integration aluminum plate batch chain processing method and system. It uses physical intervals formed along the width of the parent roll to uniformly define the sub-roll affiliation, equipment-side data fragmentation, and cross-database synchronous verification. Based on parent-child mapping, batch chain split sequence number, and association between sub-rolls and physical intervals, it generates cross-database synchronous task keys, determines receiving nodes, and completes global smelting and rolling history replication, local data fragmentation and targeted distribution, and difference verification and processing within the synchronous verification boundary.
[0025] Example 1:
[0026] See Figure 1 This embodiment provides an industrial data integration aluminum plate batch chain processing method, applied to data replication, targeted distribution, and synchronization processing between the batch chain master database, the slicing device-side database, and multiple sub-volume databases. The execution entity of this method can be a data processing device capable of accessing the above three types of databases. The method mainly includes the following steps:
[0027] S100: Obtain the master roll identifier, global smelting and rolling history, and local shearing data and collection time identifier collected by the slitting unit along the width coordinate. Establish a master roll history entry record in the batch chain master database and determine the master roll version.
[0028] S200. Sort the local cut data according to the width coordinate, and generate continuous and non-overlapping physical intervals corresponding to each sub-volume by combining the available width of the parent volume, the width of each sub-volume, and the cutting position. Simultaneously register the endpoints of the same physical interval as the sub-volume ownership boundary, the data fragmentation boundary of the database on the cutting device side, and the cross-database synchronization verification boundary. Cut the local cut data according to the data fragmentation boundary to form local data fragments.
[0029] S300. When a topology split occurs in the batch chain, obtain the sub-volume identifier and the batch chain split sequence number, establish a parent-child mapping between the parent volume identifier and the sub-volume identifier, and generate a cross-database synchronization task key shared by the batch chain master database, the splitting device side database, and the sub-volume database according to the parent-child mapping, the batch chain split sequence number, the sub-volume identifier, and the physical interval, and determine the receiving node for the local data fragment.
[0030] S400. Copy the global smelting and rolling history to each sub-volume database, and distribute the local data fragments according to the receiving node corresponding to the cross-database synchronization task key. Within the scope of the cross-database synchronization verification boundary, check the synchronization records of the three types of databases according to the parent volume version, batch chain split sequence number and collection time identifier. Perform incremental retransmission or conflict interception on the difference records. When the verification is consistent, submit the corresponding sub-volume data to form a sub-volume traceability record.
[0031] Based on the above steps, this invention enables the local shearing data attribution, equipment-side data fragmentation, and cross-database synchronous verification to adopt the same physical boundary, so that the batch chain topology, physical interval, local data fragmentation and receiving node form a continuous correspondence, and the global smelting and rolling history and local data fragmentation enter the sub-volume database according to their respective data scope, thereby reducing false differences caused by local data mismatch, redundant writing to irrelevant sub-volume databases, rewriting of duplicate records, and inconsistencies in cross-database verification scope.
[0032] Example 2:
[0033] Based on the above embodiments, in order to provide a clearer and more complete explanation of the technical solutions, the present invention also provides a second embodiment. The industrial data integration aluminum plate batch chain processing method can also be executed by the data processing device.
[0034] In this second embodiment, step S100 may further include:
[0035] S110. Read the smelting record, rolling record and quality record corresponding to the master roll identifier, organize the global smelting and rolling history according to the record version and formation time and determine the master roll version;
[0036] S120. Read the shearing force, blade gap, width coordinates and acquisition time, and bind the data at the same acquisition location with the master roll identifier to form the local shearing data.
[0037] For example, steps S110 to S120 may further include the following steps: First, the data acquisition module reads smelting records, rolling records, and quality records from the batch chain master database using the parent roll identifier (e.g., M001) as the query condition. Each record carries a record version and formation time. The data acquisition module organizes the global smelting and rolling history according to the record version and formation time, and determines the parent roll version (e.g., V12) associated with the parent roll history entry record. When the record version, formation time, or parent roll identifier is missing, the corresponding record retains its original data source and enters a pending state.
[0038] Secondly, the data acquisition module reads shearing force, blade gap, width coordinates, and acquisition time from the database on the slitting equipment side. The shearing force is derived from the acquisition field on the slitting equipment side (e.g., 18.0 kN), the blade gap is derived from the equipment setting or acquisition field (e.g., 0.10 mm), the width coordinates are derived from the acquisition record formed along the width direction of the master roll (e.g., 120 mm), and the acquisition time identifier is derived from the record on the same equipment side (e.g., 10:00:05). The data acquisition module binds the above data with the master roll identifier to form local shearing data, using the acquisition location as the corresponding condition.
[0039] In a non-limiting example, the batch chain master database reads the smelting records, rolling records, and quality records associated with the master roll for M001. The record set includes a V11 record with a formation time of 09:40:00 and a V12 record with a formation time of 09:55:00. After organizing the data by version and formation time, the data acquisition module determines V12 as the current master roll version and establishes a master roll history entry record containing M001, V12, and references from the three types of history records.
[0040] Then, the database on the slitting device side retrieves three local shearing records. The first record has a width coordinate of 120mm, a shearing force of 18.0kN, a blade gap of 0.10mm, and a collection time of 10:00:05. The corresponding data for the second record are 720mm, 17.6kN, 0.12mm, and 10:00:08. The corresponding data for the third record are 1320mm, 18.2kN, 0.11mm, and 10:00:11. The data acquisition module binds the three records to M001 according to the collection location and forms an ordered set of local shearing data according to the width coordinate.
[0041] Finally, when another equipment-side record only contains shearing force and blade clearance but lacks width coordinates, this record retains its equipment-side origin and enters the unbound record set, not participating in the current local data fragmentation. Thus, step S100 outputs the V12 global smelting and rolling history of M001, three valid local shearing records, and the status of the unbound record, and sends the valid records to step S200.
[0042] See Figure 2 In this second embodiment, step S200 may include the following steps:
[0043] S210. Determine the endpoints of the intervals sequentially according to the coordinate order of the available width of the parent volume and the width and cutting position of each sub-volume.
[0044] S220. Verify the continuity of the endpoints of adjacent intervals and the coverage of all physical intervals to the available width of the parent volume;
[0045] S230. When the data is verified to be consistent, the local cut data is extracted according to the width range defined by each physical interval to form local data fragments that correspond one-to-one with the sub-volume.
[0046] S240. Perform a cross-database comparison between the interval endpoints in the splitting device-side database and the width intervals of the corresponding sub-volumes in the batch chain master database.
[0047] S250. When the boundaries are inconsistent, correct the interval endpoints according to the splitting position, and synchronously update the corrected interval endpoints as the subvolume ownership boundary, data shard boundary and cross-database synchronous verification boundary.
[0048] S260. Continue to constrain local cut data truncation, subvolume ownership determination, and synchronization record verification using the updated same boundary.
[0049] For example, steps S210 to S260 may further include the following steps: First, the slicing generation module reads the available width of the parent volume, the width of each sub-volume, the slicing position, and the sub-volume identifier, and sorts the local shearing data according to the width coordinates. The available width of the parent volume comes from at least one of the slicing task record and the process record in the batch chain master database (e.g., 1500mm), the width of each sub-volume comes from the sub-volume specification record (e.g., 500mm, 600mm, and 400mm), and the slicing position comes from at least one of the slicing task record and the slicing position record in the slicing equipment side database (e.g., 0mm, 500mm, 1100mm, and 1500mm).
[0050] To ensure that the width of each subvolume directly corresponds to the endpoints of the interval, let the first... The physical interval endpoints corresponding to each subvolume are The left and right endpoints are respectively and The width of the sub-volume is . and Derived from the segmentation position record, Derived from the sub-volume specification record, the units for the above endpoints and widths are all in millimeters, and their relationship is expressed by the following formula:
[0051]
[0052] In the formula, Indicates the first Each subvolume corresponds to a physical interval endpoint pair. This indicates that the width of the defined interval at this endpoint is the same as the width of the corresponding subvolume. This indicates that adjacent physical intervals are consecutively connected at the current recording precision. The parentheses in the formula only represent endpoint pairs and do not limit the opening or closing of physical intervals. The output of this formula is used for continuous coverage relationship verification and local data trimming.
[0053] Secondly, after determining the endpoint pairs of each physical interval, the continuous coverage relationship of the available width of the parent volume for adjacent interval endpoints and all physical interval pairs is checked according to the following formula:
[0054]
[0055] In the formula, For continuous coverage residuals, the unit is millimeters. This represents the deviation between the starting endpoint of the first physical interval and the starting side of the available width of the parent volume. This indicates the deviation between the endpoint of the last physical interval and the end of the available width of the parent volume. This represents the deviation between the common endpoints of adjacent physical intervals. At that time, each physical interval is continuous, non-overlapping, and covers the available width of the parent volume. At this time, the fragment generation module does not output valid local data fragments, but instead enters the interval endpoint cross-database comparison.
[0056] Then, after verifying the consistency of the continuous coverage relationship, the fragmentation generation module treats the endpoints of each physical interval as the same boundary object, and registers them as the subvolume ownership boundary, the data fragmentation boundary of the database on the splitting device side, and the cross-database synchronization verification boundary. It then filters the local cut records whose width coordinates fall within the corresponding physical interval according to the data fragmentation boundary, forming a one-to-one correspondence between the subvolume identifier, the physical interval, and the local data fragment. When there is no valid local cut record within a certain physical interval, the corresponding local data fragment remains in a pending state and is not submitted as a synchronization completion status.
[0057] When the endpoints of the interval in the splitting device's database are inconsistent with the width intervals of the corresponding sub-volumes in the batch chain master database, an endpoint-by-endpoint comparison is performed within the same sub-volume identifier and the same batch chain splitting context. Let the first... The record values of each endpoint in the subvolume ownership boundary, device-side data fragmentation boundary, and synchronization verification boundary are respectively... , and .in, Derived from the ownership records of subvolumes and physical regions. Data fragment boundary records originating from the database on the slicing device side. The synchronization check boundary records originate from the cross-database synchronization items, and all three are in millimeters. The consistency relationship of the three boundaries is checked according to the following formula:
[0058]
[0059] In the formula, EB,i is the triple boundary consistency residual of the i-th endpoint, in millimeters. When EB,i=0, the three types of boundary records point to the same physical endpoint; when... When the split position record is used to determine the correction endpoint, the same corrected endpoint is synchronously updated as the subvolume ownership boundary, data fragment boundary, and synchronization verification boundary. After the update, the local cut data extraction, subvolume ownership determination, and synchronization record verification are re-executed, and the local data fragments and verification status formed before the correction are marked as invalid. When the split position record cannot be read, the affected subvolume task remains in an unconfirmed state and the endpoint is not automatically inferred based on adjacent intervals.
[0060] In a non-limiting example, the available width of the parent volume M001 is 1500mm, and the widths of the sub-volumes C01, C02, and C03 are 500mm, 600mm, and 400mm, respectively, with cutting positions of 0mm, 500mm, 1100mm, and 1500mm, respectively. This forms three physical intervals with endpoint pairs of (0mm, 500mm), (500mm, 1100mm), and (1100mm, 1500mm), respectively. The right endpoint minus the left endpoint of each endpoint pair equals the width of the corresponding sub-volume, and adjacent endpoints are continuous. Substituting these endpoints into the continuous coverage residual formula, the first endpoint deviation, the last endpoint deviation, and the adjacent endpoint deviation are all 0, the continuous coverage residual is 0, and the three physical intervals are continuous, non-overlapping, and cover the available width of the parent volume.
[0061] After the locally cut data is sorted according to the width coordinate, the record at 120mm falls into the physical interval corresponding to C01, the record at 720mm falls into the physical interval corresponding to C02, and the record at 1320mm falls into the physical interval corresponding to C03. The fragment generation module registers the endpoints of the three physical intervals as the subvolume ownership boundary, data fragment boundary, and synchronization verification boundary, respectively, and forms local data fragments C01, C02, and C03.
[0062] Finally, if the database on the sharding device side records the common endpoint of C02 and C03 as 1098mm, while the subvolume ownership boundary and synchronization verification boundary are both recorded as 1100mm, then based on the aforementioned triple boundary consistency residual relationship, the triple boundary consistency residual of this common endpoint is determined to be 4mm. The sharding generation module uses the sharding position recorded as 1100mm to determine the correction endpoint, and synchronously updates this common endpoint as the subvolume ownership boundary, data sharding boundary, and synchronization verification boundary. After the update, the triple boundary consistency residual is 0. The module re-extracts the locally cut data of C02 and C03, redetermines the subvolume ownership and synchronization verification range, and the sharding and verification status formed before the correction are no longer submitted.
[0063] See Figure 3 In this second embodiment, step S300 may include the following steps:
[0064] S310, Respond to batch chain topology split events and generate cross-database synchronization task keys for each subvolume based on parent-child mapping and batch chain split sequence number;
[0065] S320. Establish a synchronization item carrying the same cross-database synchronization task key in the batch chain master database, the slicing device side database and the corresponding sub-volume database, so that the parent volume version, sub-volume identifier, physical range and local data fragment are associated along the cross-database synchronization task key.
[0066] S330. Query the sub-volume node table based on the cross-database synchronization task key, and associate the sub-volume identifier, corresponding physical range, and local data fragment with the corresponding sub-volume database.
[0067] S340. When distributing local data fragments, the receiving node is determined according to the aforementioned association, and the local data fragments are written to the corresponding sub-volume database.
[0068] For example, steps S310 to S340 may further include the following steps: First, after a topology split occurs in the batch chain, the synchronization task module obtains the parent volume identifier, each child volume identifier, and the batch chain split sequence number, and establishes a parent-child mapping between the parent volume identifier and each child volume identifier. The batch chain split sequence number is derived from the current topology split event (e.g., 01, 02, and 03) and is used to distinguish the child volume tasks formed from the same parent volume. For each child volume, the synchronization task module writes the parent-child mapping, the batch chain split sequence number, and the association between the child volume identifier and the physical interval into the task context, and generates a cross-database synchronization task key shared by three types of databases (e.g., TK-A, TK-B, and TK-C).
[0069] Secondly, the batch chain master database, the sharding device-side database, and the corresponding sub-volume database each establish a synchronization entry carrying the same cross-database synchronization task key, enabling the parent volume version, sub-volume identifier, physical range, and local data fragments to be queried along the same cross-database synchronization task key. The synchronization task module then queries the sub-volume node table using the cross-database synchronization task key to verify whether the sub-volume identifier, physical range, and local data fragment associated with the task key all point to the same sub-volume database, and determines the receiving node (e.g., Node-A, Node-B, and Node-C).
[0070] In a non-limiting example, a topology split event occurs on M001, resulting in C01, C02, and C03 from the parent volume. The batch chain split numbers for the three child volumes are 01, 02, and 03, respectively. The synchronization task module establishes parent-child mappings for M001-C01, M001-C02, and M001-C03, and writes the physical ranges, local data fragment references, and parent volume version V12 corresponding to C01, C02, and C03 into three independent task contexts.
[0071] Then, for the C02 task context, the synchronization task module generates a cross-database synchronization task key TK-B based on the M001-C02 parent-child mapping, split sequence number 02, and the association between C02 and the physical intervals with endpoints of 500mm and 1100mm respectively. The batch chain master database, the split device-side database, and the C02 sub-volume database each establish synchronization entries carrying TK-B, and each synchronization entry is jointly associated with V12, C02, the aforementioned physical intervals, and the C02 local data fragment references. C01 and C03 form TK-A and TK-C respectively according to the same relationship.
[0072] Finally, the synchronization task module queries the subvolume node table using TK-B to find that C02, the aforementioned physical range, and the C02 local data fragment all point to Node-B, and identifies Node-B as the receiving node. If the query result lacks a Node-B record, the C02 task retains its TK-B, original physical range, and original fragment references unchanged and enters the pending distribution state. After the node table is completed, it queries and verifies the association relationships again. The matching task key, synchronization item, and receiving node are used as input for step S400.
[0073] In this second embodiment, step S400 may include the following steps:
[0074] S410. Copy the global smelting and rolling history to each sub-volume database;
[0075] S420. Distribute the local data fragments according to the receiving node corresponding to the cross-database synchronization task key;
[0076] See Figure 4 After completing the global smelting and rolling history replication and the local data fragmentation and targeted distribution, the synchronous verification and difference processing in step S400 may include the following steps:
[0077] S430. Using the cross-database synchronization task key as the verification index, within the scope of the synchronization verification boundary, query the batch chain master database, the split device side database and the sub-volume database respectively to form the master database record set, the device database record set and the sub-volume database record set.
[0078] S440. Compare the cross-database synchronization task key, parent volume version, batch chain split sequence number, data fragment boundary and acquisition time identifier in each record set to determine the difference records and their respective physical intervals.
[0079] S450. Records that exist in the main database record set or device database record set but not in the corresponding sub-volume database record set are identified as missing records. Records that arrive after the preset synchronization time window are identified as late records. Records with the same cross-database synchronization task key, physical range, width coordinate and acquisition time identifier are identified as duplicate records.
[0080] S460: Generate incremental retransmission tasks limited to the physical range for missing records and late records that do not yet exist in the corresponding sub-volume record set; and perform write interception for duplicate records.
[0081] S470. For sub-volume data that has completed history copying, fragment distribution and difference processing, verify the parent volume version, batch chain split sequence number, data fragment boundary, data source and cross-database synchronization task key.
[0082] S480. When the data is verified to be consistent, submit the corresponding sub-volume data and write the synchronization completion status to the above three types of databases.
[0083] S490. If discrepancies are found, locate the affected local data fragments and receiving nodes, perform at least one of the following: re-capture, incremental retransmission, and targeted update, and then verify again.
[0084] See Figure 5 During the processes of establishing the master volume version, forming local cut records, splitting the batch chain topology, establishing task keys, copying the global history, distributing local fragments, synchronous verification, incremental retransmission, and writing back the synchronous completion status, each database and functional module interacts in chronological order. When any database status write-back fails, only the synchronous completion status is rewritten, and the global history or local data fragments are not copied repeatedly.
[0085] For example, steps S410 to S490 may further include the following steps: First, the copying and distribution module reads the master roll version and global smelting and rolling history generated in step S100, and establishes global history copying tasks for each sub-roll generated from the current master roll. The global smelting and rolling history contains the overall record of the master roll's smelting, rolling, and quality stages, without being clipped according to the physical range of each sub-roll, and is associated with the corresponding sub-roll identifier and cross-database synchronization task key.
[0086] Secondly, for partially cut data, the copy and distribution module reads the local data fragments formed in step S200 and the receiving nodes determined in step S300, and performs targeted writing according to the correspondence between subvolume identifiers, physical ranges, local data fragments, and receiving nodes. Local data fragments are only written to their corresponding subvolume databases, not to other subvolume databases. Each copy result and targeted writing result forms a synchronization record to be verified along the original cross-database synchronization task key.
[0087] In a non-limiting example, the replication and distribution module reads the V12 global smelting and rolling history of M001 and the three task contexts TK-A, TK-B, and TK-C. For C01, C02, and C03, the module creates global history replication tasks respectively, writing the same V12 smelting record, rolling record, and quality record into the three sub-volume databases, and recording the corresponding sub-volume identifier, cross-database synchronization task key, and global history data source in each replication result.
[0088] For locally cut data, records with a width coordinate of 120mm are written to Node-A only according to TK-A, records with a width coordinate of 720mm are written to Node-B only according to TK-B, and records with a width coordinate of 1320mm are written to Node-C only according to TK-C. Each write result records the cross-database synchronization task key, subvolume identifier, physical interval endpoint, local data fragment reference, receiving node, and pending verification status, and serves as input for the three types of record sets.
[0089] When Node-B is temporarily unavailable, the V12 global history replication result of C02 remains in a written state, and the local data fragments of C02 remain in a pending distribution state, without being written to Node-A or Node-C. After Node-B recovers, the replication and distribution module completes the targeted writing according to the original TK-B, original physical range, and original node mapping. As a result, a V12 global history copy and a local data fragment belonging only to the C02 physical range are formed in the C02 subvolume database, and the two enter synchronization verification along TK-B.
[0090] Then, after the replication and distribution module completes the write operation, the consistency processing module locates the same subvolume task using the cross-database synchronization task key and limits the query range using the synchronization verification boundary, forming the master database record set, device database record set, and subvolume database record set respectively. The verification fields include the cross-database synchronization task key, parent volume version, batch chain split sequence number, data shard boundary, and acquisition time identifier.
[0091] Let the set of verification fields be set. Including cross-database synchronization of task keys Master Volume Version Batch chain split sequence number Data partition boundaries and collection time identifier . , and These represent the batch chain master database, the sharding device-side database, and the sub-volume database, respectively. In the... In a task context, the fields The record values from the three types of databases are used as the main database value, device database value, and subvolume database value for comparison, respectively. Derived from step S300, Derived from step S100, Originating from a batch chain topology split event, Derived from the data fragment boundaries registered or corrected in step S200, Data collected from the slitting equipment. The number of difference fields for each task context is determined by the following formula:
[0092]
[0093] In the formula, For the first The number of difference fields in each task context is dimensionless. The indicator function takes 1 if the corresponding fields in the three database types are not all equal, and 0 if they are equal. At that time, the five verification fields of the corresponding records are consistent. At that time, a list of difference fields is generated, and the difference records are associated with their respective physical ranges. If a record exists in the main database record set or the device database record set but not in the sub-volume database record set, it is preferentially determined as a missing record based on its existence.
[0094] The preset synchronization time window is derived from at least one of the following: historical synchronization delay statistics, system configuration, and design limits (e.g., 30 seconds). The arrival time is the actual record between the database write time and the message reception time. When the interval between the acquisition time and the arrival time of a record exceeds the preset synchronization time window, the record is identified as a late record. When the cross-database synchronization task key, physical range, width coordinate, and acquisition time identifier are all the same, the corresponding record is identified as a duplicate record. Incremental retransmission tasks are generated for missing records and late records that are still not present in the corresponding sub-volume database record set. These incremental retransmission tasks retain the original cross-database synchronization task key, the physical range to which they belong, and the receiving node, and only retransmit the target record within that physical range. Late records that have already arrived at the corresponding sub-volume database retain their late status and enter the final verification process; no additional incremental retransmission tasks are generated for them. Duplicate records are subject to write interception, and the interception status and the original record reference are retained.
[0095] After completing the corresponding processing in incremental retransmission and write interception, the consistency processing module performs a final check on the history replication results, fragment distribution results, and difference processing results. The data source field is used to distinguish between the batch chain master database source of the global smelting and rolling history and the fragmentation device-side database source of the locally cut data. When the parent volume version, batch chain split sequence number, data fragment boundary, data source, and cross-database synchronization task key are consistent, the corresponding sub-volume data is submitted, and the synchronization completion status is written to the three types of databases along the original cross-database synchronization task key. The submission of the corresponding sub-volume data confirms that the data that has completed history replication and local fragment targeted writing and has been verified to be consistent has entered the valid submission state. The global smelting and rolling history is not copied again, nor is the local data fragment written repeatedly. When the verification is inconsistent, the return position is determined according to the physical interval to which the difference record belongs, the local data fragment, and the receiving node. Boundary difference return step S200 re-truncates, and missing records and late records that are still not present in the corresponding sub-volume database record set are returned for incremental retransmission. The node write difference is performed according to the original node mapping to perform targeted update. After completion, the three types of record sets are formed again and verified. If a consistent result still cannot be reached after re-extraction, incremental re-transmission, or targeted update, the affected task will enter a state awaiting manual verification, while other unaffected sub-volume tasks will retain their original processing results.
[0096] Finally, for task C01 corresponding to TK-A, a main database record set, a device database record set, and a sub-volume database record set are formed within the synchronous verification range with endpoints of 0mm and 500mm respectively. All three record sets record V12, split sequence number 01, identical data fragment boundaries, and identical acquisition time identifiers. Substituting each field into the three-database record difference counting formula yields a difference field count of 0. For task C02 corresponding to TK-B, if a locally cut record with a width coordinate of 720mm and an acquisition time identifier of 10:00:08 exists in the device database, but this record does not exist in the sub-volume database, then this record is identified as a missing record.
[0097] If the arrival time of the record is 10:00:50, and the interval from acquisition to arrival is 42 seconds, which exceeds the preset synchronization time window of 30 seconds, then it is also identified as a late record. Since the record does not yet exist in the corresponding sub-volume library record set, an incremental retransmission task is generated, which is limited to physical intervals with endpoints of 500mm and 1100mm and points to Node-B.
[0098] If a record that arrives again has the same TK-B, the same physical range, the same width coordinate of 720mm, and the same acquisition time identifier of 10:00:08, it will be identified as a duplicate record and write interception will be performed, and it will not be written to the C02 subvolume database again.
[0099] After the retransmission and interception are completed, if TK-B, V12, split sequence number 02, data fragment boundary, data source, and acquisition time identifier are consistent, then the C02 subvolume data is submitted and the synchronization completion status is written to the three types of databases. If, upon re-verification, the common endpoint of C02 and C03 is still found to be 1098mm, then the local data fragments corresponding to C02 and C03, as well as Node-B and Node-C, are located, and the process returns to step S200 to update the same boundary according to the split position of 1100mm, re-truncate the local data fragments, and verify them again.
[0100] Furthermore, in this second embodiment, if the parent volume identifier, width coordinates, acquisition time, or necessary history records are missing, the corresponding records retain their original data source and enter a pending or unbound state. If a local record cannot establish a correspondence with the parent volume, sub-volume, or physical interval, it is not assigned to an adjacent interval or other sub-volume. After the fields are completed and the correspondence is reconfirmed, the process re-enters step S100 or step S200.
[0101] When endpoints are reversed, endpoints exceed the available width of the parent volume, adjacent endpoints are discontinuous, physical intervals overlap, or all physical intervals do not cover the available width of the parent volume, the fragmentation generation module will not output valid local data fragments and will perform cross-database comparison and boundary correction according to steps S240 to S260. When the boundaries are inconsistent and the split position is unreadable, the affected sub-volume task will remain in a pending confirmation state. When there are no valid local records in a certain physical interval, the corresponding fragment is marked as incomplete, allowing the already formed global history copy results to be retained, but not written to the synchronization completion status.
[0102] When a cross-database synchronization task key conflicts in the current split event, or when parent-child mapping, batch chain split sequence number, or association between a subvolume and physical range is missing, or when there is no matching record in the subvolume node table, the corresponding synchronization item commit and partial fragment distribution are blocked. If any query of any of the three types of record sets fails or the record set is incomplete, a consistent commit is not performed. If the physical range to which a difference record belongs cannot be determined, the record is isolated along with the original task context, and the retransmission scope is not expanded. If the receiving node is unreachable, the target subvolume database is unwritable, or incremental retransmission fails, the original cross-database synchronization task key, original physical range, and original node mapping are maintained, and processing is restarted from the most recent valid step after the fault is recovered.
[0103] When the final subvolume data has been committed but the synchronization completion status write fails, the committed business data result and the status write failure flag are retained. After recovery, only the synchronization completion status is rewritten, and the global smelting and rolling history or local data fragments are not copied repeatedly. When the fault status has not been recovered, the affected tasks remain in the pending manual verification status, while other unaffected subvolume tasks continue to retain their respective processing results.
[0104] For example, if the device library records the common endpoint of C02 and C03 as 1098mm and the slicing position is temporarily unreadable, the local data fragments corresponding to C02 and C03 will remain in a pending confirmation state, and neither the 1098mm nor 1100mm record will be used for further submission. After the slicing position is restored to 1100mm, the endpoint comparison, triple boundary synchronization update, and local data fragment truncation will be re-executed.
[0105] If, after node record recovery, it is found that TK-B is associated with both C02 and C03 in the same split event, the synchronization task module will not select either node to continue distribution, but will instead maintain both task contexts pending repair. After the parent-child mapping and the association between the subvolume and the physical region are repaired, it will be reconfirmed that TK-B is only associated with C02 and Node-B will be found. The local data fragmentation of C02 will then begin targeted writing.
[0106] If the C02 data has been verified and submitted, but the synchronization completion status write to the batch chain master database fails, the submitted C02 business data result is retained. After the status write is restored, the original submission record is queried using TK-B and the synchronization completion status is rewritten. The V12 global smelting and rolling history is not copied again, nor is the C02 local data fragment written repeatedly.
[0107] Example 3:
[0108] Based on the same inventive concept, the present invention also provides an industrial data integration aluminum plate batch chain processing system, which is used to perform the methods described in any of the above embodiments.
[0109] like Figures 1 to 5 As shown, the system includes a batch chain master database, a sharding device-side database, multiple sub-volume databases, a data acquisition module, a shard generation module, a synchronization task module, a replication and distribution module, and a consistency processing module.
[0110] The data acquisition module is used to acquire the master roll identifier, global smelting and rolling history, and local shearing data and acquisition time identifier collected along the width coordinate. It also establishes a master roll history entry record in the batch chain master database and determines the master roll version.
[0111] The sharding generation module is used to sort the locally cut data according to the width coordinate, generate continuous and non-overlapping physical intervals based on the available width of the parent volume, the width of each sub-volume, and the sharding position, and register the endpoints of the same physical interval as the sub-volume ownership boundary, data sharding boundary, and synchronization verification boundary, and form local data shards corresponding to each sub-volume.
[0112] The synchronization task module is used to obtain the sub-volume identifier and batch chain split sequence number when a topology split occurs in the batch chain, establish a parent-child mapping between the parent volume identifier and the sub-volume identifier, generate a cross-database synchronization task key shared by the above three types of databases based on the parent-child mapping, the batch chain split sequence number and the association between the sub-volume identifier and the physical interval, and determine the receiving node of the local data shard.
[0113] The copy and distribution module is used to copy the global smelting and rolling history to each sub-volume database, and to distribute local data fragments in a targeted manner according to the receiving node corresponding to the cross-database synchronization task key.
[0114] The consistency processing module is used to verify the synchronization records of the above three types of databases within the scope of the synchronization verification boundary, based on the parent volume version, batch chain split sequence number and collection time identifier, perform incremental retransmission or conflict interception for the difference records, and submit the sub-volume data composed of the global smelting and rolling history and the corresponding local data fragments when the verification is consistent.
[0115] The batch chain master database stores the parent volume history entry record, parent volume version, parent-child mapping, cross-database synchronization task key, and synchronization status. The slicing equipment-side database stores local cut data, width coordinates, acquisition time identifiers, equipment-side interval endpoints, and synchronization items. Each sub-volume database receives the global smelting and rolling history, corresponding local data fragments, and synchronization completion status. Each module calls the above records through the database read / write interface. The synchronization task module writes synchronization items carrying the cross-database synchronization task key, the replication and distribution module writes data according to the receiving node, and the consistency processing module queries the record set according to the cross-database synchronization task key and synchronization check boundary and writes back the status.
[0116] The data acquisition module accesses the batch chain master database and the slicing device side database after the master volume access event occurs, outputting the master volume version, global smelting and rolling history, and local shearing data. The shard generation module reads the available width of the master volume, the width of each sub-volume, and the slicing position, outputting the physical range, triple boundary reference, and local data shards. The synchronization task module is triggered by the batch chain topology split event, receiving the sub-volume identifier, physical range, and local data shard reference, and outputting the cross-database synchronization task key and receiving node. The replication and distribution modules form a global history replication stream and a local data shard targeted distribution stream, respectively. The consistency processing module forms three types of record sets according to the cross-database synchronization task key and synchronization verification boundary, outputting the difference record, retransmission result, interception status, final verification status, and synchronization completion status.
[0117] For example, after receiving the M001 access event, the data acquisition module retrieves the V12 global smelting and rolling history from the batch chain master database and three local shearing records with width coordinates of 120mm, 720mm, and 1320mm from the slitting equipment side database. The data acquisition module combines M001, V12, the global history, and the three local records into a versioned input and sends it to the fragment generation module.
[0118] The fragment generation module generates three physical intervals and their triple boundary references based on the available width of the 1500mm master volume, the widths of the three child volumes (500mm, 600mm, and 400mm), and the four slicing positions (0mm, 500mm, 1100mm, and 1500mm). The module then extracts the three local records into local data fragments C01, C02, and C03, respectively, and sends the child volume identifier, physical interval, and fragment reference to the synchronization task module.
[0119] The synchronization task module establishes a parent-child mapping between M001 and the three sub-volumes, forming three cross-database synchronization task keys: TK-A, TK-B, and TK-C. It then determines Node-A, Node-B, and Node-C through the sub-volume node table. The replication and distribution module writes the V12 global history to the three sub-volume databases, and simultaneously directs the three local data shards to their respective nodes.
[0120] The consistency processing module uses TK-A, TK-B, and TK-C as verification indexes to query records in the three types of databases within their respective synchronization verification boundaries. For missing records and late records that are not yet present in the corresponding sub-volume database record set, it generates incremental retransmission tasks within a limited range, and performs write interception on duplicate records. After verification, it commits the corresponding sub-volume data and writes the synchronization completion status to the three types of databases. Thus, each module transmits data and status along the same physical interval, the same cross-database synchronization task key, and the corresponding receiving node, without forming a second processing route separate from the main method chain.
[0121] The above description is merely a preferred embodiment of the technical solution of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.
Claims
1. A batch chain processing method for integrated industrial data aluminum plates, characterized in that, include: Obtain the master roll identifier, global smelting and rolling history, and local shearing data and collection time identifier collected by the slitting unit along the width coordinate. Establish a master roll history entry record in the batch chain master database and determine the master roll version. The local cut data is sorted according to the width coordinate. Combined with the available width of the parent volume, the width of each sub-volume, and the cutting position, continuous and non-overlapping physical intervals are generated for each sub-volume. The endpoints of the same physical interval are simultaneously registered as the sub-volume ownership boundary, the data fragmentation boundary of the database on the cutting device side, and the cross-database synchronization verification boundary. The local cut data is then extracted according to the data fragmentation boundary to form local data fragments. When a topology split occurs in the batch chain, the sub-volume identifier and the batch chain split sequence number are obtained, a parent-child mapping between the parent volume identifier and the sub-volume identifier is established, and based on the parent-child mapping, the batch chain split sequence number, the sub-volume identifier and the association relationship with the physical interval, a cross-database synchronization task key shared by the batch chain master database, the splitting device side database and the sub-volume database is generated, and the receiving node of the local data fragment is determined. The global smelting and rolling history is copied to each sub-volume database, and the local data fragments are distributed to the receiving nodes corresponding to the cross-database synchronization task keys. Within the scope of the cross-database synchronization verification boundary, the synchronization records of the three types of databases are checked according to the parent volume version, batch chain split sequence number and collection time identifier. Incremental retransmission or conflict interception is performed on the difference records. When the verification is consistent, the corresponding sub-volume data is submitted to form a sub-volume traceability record.
2. The method according to claim 1, characterized in that, The acquisition of global smelting and rolling history and local shearing data includes: Read the smelting record, rolling record, and quality record corresponding to the master roll identifier, organize the global smelting and rolling history according to the record version and formation time, and determine the master roll version; Read the shearing force, blade gap, width coordinates, and acquisition time, and bind the data from the same acquisition location with the master volume identifier to form the local shearing data.
3. The method according to claim 1, characterized in that, The generation of physical regions and local data fragments includes: Based on the coordinate order of the available width of the parent volume, the endpoints of the intervals are determined sequentially according to the width of each sub-volume and the cutting position. Verify the continuity of the endpoints of adjacent intervals and the coverage of all physical intervals to the available width of the parent volume; Upon verification, the local cut data is extracted according to the width range defined by each physical interval to form local data fragments that correspond one-to-one with the sub-volume.
4. The method according to claim 3, characterized in that, The registered data fragmentation boundaries and synchronous verification boundaries include: Perform a cross-database comparison between the interval endpoints in the slicing device-side database and the width intervals of the corresponding sub-volumes in the batch chain master database; When the boundaries are inconsistent, the interval endpoints are corrected according to the split position, and the corrected interval endpoints are synchronously updated as the subvolume ownership boundary, data shard boundary and cross-database synchronous verification boundary; Continue to constrain local cut data truncation, subvolume ownership determination, and synchronization record verification using the updated same boundary.
5. The method according to claim 1, characterized in that, The generation of cross-database synchronization task keys includes: In response to batch chain topology split events, generate cross-database synchronization task keys for each subvolume based on the parent-child mapping and the batch chain split sequence number. Establish synchronization entries carrying the same cross-database synchronization task key in the batch chain master database, the sharding device side database, and the corresponding sub-volume database, so that the parent volume version, sub-volume identifier, physical range, and local data fragments are associated along the cross-database synchronization task key.
6. The method according to claim 1, characterized in that, The verification of synchronization records includes: Using the cross-database synchronization task key as the verification index, within the scope of the synchronization verification boundary, the batch chain master database, the split device side database, and the sub-volume database are queried respectively to form the master database record set, the device database record set, and the sub-volume database record set; By comparing the cross-database synchronization task key, parent volume version, batch chain split sequence number, data fragment boundary, and acquisition time identifier in each record set, the difference records and their respective physical intervals are determined.
7. The method according to claim 6, characterized in that, The execution of incremental retransmission or conflict interception includes: Records that exist in the main database record set or device database record set but not in the corresponding sub-volume database record set are identified as missing records; records that arrive after the preset synchronization time window are identified as late records; and records with the same cross-database synchronization task key, physical range, width coordinates, and acquisition time identifier are identified as duplicate records. For missing records and late records that do not yet exist in the corresponding sub-volume record set, generate incremental retransmission tasks limited to the physical range to which they belong, and perform write interception on duplicate records.
8. The method according to claim 5, characterized in that, The process of determining the receiving node for local data fragments includes: Query the subvolume node table based on the cross-database synchronization task key, and associate the subvolume identifier, corresponding physical range, and local data fragments with the corresponding subvolume database; When distributing local data fragments, the receiving node is determined according to the aforementioned relationship, and the local data fragments are written to the corresponding sub-volume database.
9. The method according to claim 7, characterized in that, After performing incremental retransmission or conflict interception, the process also includes: For sub-volume data that has completed history copying, sharding distribution and difference processing, verify the parent volume version, batch chain split sequence number, data shard boundary, data source and cross-database synchronization task key; When the data matches, submit the corresponding subvolume data and write the synchronization completion status to the three types of databases mentioned above. If discrepancies are found, locate the affected local data fragments and receiving nodes, perform at least one of the following: re-capture, incremental retransmission, and targeted update, and then verify again.
10. An industrial data integration aluminum plate batch chain processing system, characterized in that, It includes a batch chain master database, a sharding device-side database, multiple sub-volume databases, a data acquisition module, a shard generation module, a synchronization task module, a replication and distribution module, and a consistency processing module; The data acquisition module is used to acquire the master roll identifier, global smelting and rolling history, and local shearing data and acquisition time identifier collected along the width coordinate. It also establishes a master roll history entry record in the batch chain master database and determines the master roll version. The sharding generation module is used to sort the locally cut data according to the width coordinate, generate continuous and non-overlapping physical intervals based on the available width of the parent volume, the width of each sub-volume, and the sharding position, and register the endpoints of the same physical interval as the sub-volume ownership boundary, data sharding boundary, and synchronization verification boundary, and form local data shards corresponding to each sub-volume. The synchronization task module is used to obtain the sub-volume identifier and batch chain split sequence number when a topology split occurs in the batch chain, establish a parent-child mapping between the parent volume identifier and the sub-volume identifier, generate a cross-database synchronization task key shared by the above three types of databases based on the parent-child mapping, the batch chain split sequence number and the association between the sub-volume identifier and the physical interval, and determine the receiving node of the local data shard. The copy and distribution module is used to copy the global smelting and rolling history to each sub-volume database, and to distribute local data fragments in a targeted manner according to the receiving node corresponding to the cross-database synchronization task key. The consistency processing module is used to verify the synchronization records of the above three types of databases within the scope of the synchronization verification boundary, based on the parent volume version, batch chain split sequence number and collection time identifier, perform incremental retransmission or conflict interception for the difference records, and submit the sub-volume data composed of the global smelting and rolling history and the corresponding local data fragments when the verification is consistent.