Workshop production line data centralized monitoring and traceability management method

Abstract

The present application relates to the technical field of business process management and workshop production management information processing, and particularly relates to a workshop production line data centralized monitoring and traceability management method. The method comprises the following steps: based on the blockchain traceability data and the production process configuration, a high-reliability traceability sample is constructed through field standardization, link rearrangement and frequency analysis; through image frame matching, gray feature extraction and time series analysis, a characteristic function parameter reflecting the change rule of product characteristics is generated; the time difference between the coding and the input event is compared with the characteristic parameter to generate graded early warning data; through workstation screen mapping, component binding and centralized display processing, a closed-loop monitoring operation record is formed. The present application realizes full-link data-driven monitoring from production traceability, characteristic analysis to early warning display, and improves the traceability reliability and the accuracy of abnormal early warning.

Description

Technical Field

[0001] This invention relates to the field of business process management and workshop production management information processing technology, and in particular to a method for centralized monitoring and traceability management of workshop production line data. Background Technology

[0002] In the field of business process management and workshop production management information processing technology, existing solutions for centralized monitoring and traceability management of workshop production line data typically rely on workshop monitoring systems, production execution systems, and traceability coding systems. Production batch numbers, production line workstation status, and basic traceability records are stored in multiple business databases. Product flow information is collected through product coding and barcode scanning, and then the quality inspection system updates some traceability records based on sampling results or manual input. This approach suffers from limitations such as dispersed traceability record sources, lack of structured association between production process configurations and traceability records, and difficulty in linking early warning results with a centralized on-site display interface. Existing methods often employ a collection path based on a single database or file logs, relying on manual maintenance of production process configurations and early warning rules. In scenarios where workshop production lines operate continuously and require timeline alignment of production batch number-related image frames and centralized display on on-site screens, problems such as delayed traceability record updates and untimely transmission of production line early warning information easily arise, making it difficult to ensure the stable implementation of the operational record structure for centralized monitoring and traceability management of workshop production line data. To address the common shortcomings of existing technologies for the joint processing of data and process links in the centralized monitoring and traceability management of workshop production line data based on blockchain traceability ledgers and production process configurations, and through production line early warning data structures, existing technologies generally suffer from fragmented links, inconsistent timestamp alignment, and incomplete operation record structures in various stages, including traceability record collection and cleaning, time series processing and identification of stable and key change intervals for grayscale difference data of product characteristic changes, event primary key binding and time difference calculation, and centralized display data assembly and refresh scheduling. This makes it difficult to establish a consistent process for continuous collection, alignment, judgment, display, and recording in centralized monitoring and traceability management of workshop production lines, from high-reliability target traceability record structures, product characteristic change feature function parameter structures, production line early warning data structures to the centralized monitoring and traceability management operation record structures of workshop production lines. This results in fragmented workshop production line data monitoring, delayed traceability information updates, and difficulty in tracking the operation process. Summary of the Invention

[0003] To address the aforementioned technical problems, this invention provides a method for centralized monitoring and traceability management of workshop production line data, including:

[0004] The process involves acquiring a blockchain traceability ledger and production process configuration, performing field standardization, reordering the production process time sequence, statistical analysis of process combination patterns, registration of combination codes and hash values, analysis of combination frequency, and consistency threshold screening to generate a highly reliable target traceability record structure. Specifically, the blockchain traceability ledger includes key operation events, collection time, equipment identifiers, operator identifiers, and quality inspection results, stored using an append-only, tamper-proof transaction structure. The production process configuration includes the process sequence, allowed branch paths, workstation numbers corresponding to each process, dependencies between processes, and process version numbers, stored using a combination of structured configuration files and parameter tables.

[0005] Based on a highly reliable target traceability record structure, product batch number matching, image frame time axis alignment, grayscale histogram statistics, regional grayscale feature extraction, time series processing, and stable interval and key change interval identification are performed to generate a product characteristic change feature function parameter structure.

[0006] Based on the parameter structure of the characteristic function of product characteristic changes, event primary key binding, timestamp alignment, time difference calculation, characteristic duration comparison, early warning level classification, and production line workstation binding are performed to generate production line early warning data structure;

[0007] Based on the production line early warning data structure, the system performs production line workstation screen area mapping, data field binding with screen components, centralized data assembly, interface component assembly, refresh scheduling, and display status record processing to generate a workshop production line data centralized monitoring and traceability management operation record structure.

[0008] Furthermore, the process of standardizing fields and rearranging the time sequence of production processes also includes:

[0009] Field standardization processing includes marking records with missing required fields as exceptions and writing them to the exception record buffer, correcting or removing timestamp formats, and reordering the production process in terms of time sequence.

[0010] The time sequence reordering process for the production process includes dividing the standardized traceability records into batch sets, arranging them in ascending order by timestamp field within each batch set, adjusting the order of steps with time overlap or parallel operations according to the predefined step order in the production process configuration to maintain consistency with the actual process logic, and constructing a step sequence from the quality inspection result field or equipment number field and adding a path identifier field in scenarios with process branch paths based on branch conditions.

[0011] Furthermore, the process of statistical analysis of link combination patterns, combination coding and hash value registration, combination frequency analysis and consistency threshold screening also includes:

[0012] The statistical processing of the process combination pattern includes constructing a process number sequence arranged in chronological order for each batch, and extracting ordered process segments from the process number sequence according to a preset window length and step size to count the occurrence frequency and distribution range of complete sequence combinations or partial sequence combinations.

[0013] The combined coding and hash value registration process includes concatenating the process number sequence and appending the process version number and path identifier to generate a combined code, applying an anti-collision hash algorithm to the combined code to generate a hash value and registering it in the process combined hash value list.

[0014] The frequency analysis of combinations includes calculating the number of occurrences of each combination pattern within the statistical period and the proportion of batches covered, and comparing it with the preset frequency lower limit and coverage requirements.

[0015] The consistency threshold screening process includes marking combination patterns based on the lower limit of combination frequency, the lower limit of coverage batch ratio, and the upper limit of abnormal batch conflict. Only for high consistency combinations, historical traceability records are checked to reconstruct the execution sequence.

[0016] Furthermore, the process of matching product batch numbers and aligning image frame timelines also includes:

[0017] The product batch number matching process includes reading the product batch number field from the high-reliability target traceability record structure and querying the corresponding product image frame identifier in the image metadata table to establish an association index between the traceability record and the image frame.

[0018] The image frame timeline alignment process includes unifying the traceability record timestamp field and the image frame acquisition timestamp field into an internal standard time format, grouping by product batch number and sorting by timestamp, matching the traceability records around the visual inspection station with the image frames at adjacent times to establish pairing relationships and handling cases of multiple frames or missing frames.

[0019] Furthermore, the process of gray-level histogram statistics and regional gray-level feature extraction also includes:

[0020] Gray-level histogram statistical processing includes dividing the gray-level value range of the image frame into continuous intervals according to a preset gray-level classification strategy, counting the number of pixels in each interval, and applying masking processing for noisy pixels and out-of-focus areas to generate gray-level distribution features.

[0021] The regional grayscale feature extraction process includes dividing key regions from the image frame according to a predefined region configuration, calculating the average grayscale level, grayscale distribution concentration, and local contrast for each region.

[0022] Furthermore, the process of time series processing, identification of stable intervals and key change intervals also includes:

[0023] Time series processing includes grouping by product batch number and region identifier and sorting by timestamp field to construct regional time series, resampling for scenarios with uneven sampling intervals and inserting virtual time nodes to mark missing ones, and processing duplicate or abnormal timestamp records.

[0024] The identification and processing of stable intervals and key change intervals includes constructing change rate sequences and fluctuation degree sequences from the gray-scale feature fields of the region, sliding the detection window on the time series to count the fluctuation range and continuous trend, marking the fluctuation range as a stable interval when the fluctuation range is below the stable threshold and the trend is stable, and marking the fluctuation range or frequency as a key change interval when it exceeds the change threshold.

[0025] Furthermore, the process of binding event primary keys and aligning timestamps also includes:

[0026] The event primary key binding process includes extracting the product batch number field and the coding time field from the coding event table, extracting the product batch number field and the entry time field from the entry event table, extracting the feature duration parameter field from the product characteristic change feature function parameter structure, associating the coding event and entry event with the feature parameter record with the product batch number and the single product serial number as the event primary key, and performing production line number and process version consistency verification.

[0027] The timestamp alignment process includes converting the encoding time field and the entry time field into an internally unified time format, correcting time zone deviations or format differences, and marking an anomaly when the time difference exceeds the acceptable range.

[0028] Furthermore, the process of calculating time differences and comparing characteristic durations also includes:

[0029] The time difference calculation process includes calculating the time interval between the entry time field and the coding time field for each record to generate a coding entry time difference value at the individual product level.

[0030] The feature duration comparison processing includes loading comparison rules from the feature function configuration table and generating basic early warning measurement values ​​based on the ratio and direction of the difference between the time difference and the feature duration parameter.

[0031] Furthermore, the process of classifying early warning levels and binding them to production line workstations also includes:

[0032] The warning level classification process includes reading the warning level configuration table, re-merging the warning levels according to the warning level field and the warning reason field, and adding color coding and prompting strategy fields;

[0033] The production line workstation binding process includes reading the production line workstation topology from the workshop resource management database, retrieving key workstation records based on product batch number and single product serial number, and determining the target workstation number and screen terminal number by combining the workstation binding strategy.

[0034] Furthermore, the process of refreshing the scheduling and display status records to generate the centralized monitoring and traceability management operation record structure for the workshop production line also includes:

[0035] The refresh scheduling process includes periodically reading the production line data centralized screen display configuration, triggering partial or full-screen refresh based on refresh strategy fields and data change events, and sending rendering instructions to the display control program through the screen rendering unit.

[0036] The display status recording process includes recording the screen terminal number, component instance identifier, early warning record identifier, and interface configuration version number after each refresh, as well as the interaction events of the associated operators to form a display and response chain, generating a centralized monitoring and traceability management operation record structure for workshop production line data.

[0037] The key innovations of this invention include:

[0038] (1) By acquiring the blockchain traceability ledger and production process configuration, and using continuous processing such as field standardization, production process time sequence rearrangement, process combination pattern statistics, combination coding and hash value registration, combination frequency analysis and consistency threshold screening, the scattered traceability records are organized into a highly reliable target traceability record structure, realizing the process combination mapping and reliability screening of the blockchain traceability ledger and production process configuration in the same structure.

[0039] (2) Based on the high reliability target traceability record structure, the product batch number and image frame time axis are matched and aligned. Through grayscale histogram statistics, regional grayscale feature extraction, time series organization and identification of stable intervals and key change intervals, the product image information is transformed into the product characteristic change feature function parameter structure, realizing the product characteristic change time behavior modeling with the product batch number as the main line.

[0040] (3) Based on the parameter structure of the characteristic function of product characteristic change, the event primary key binding, timestamp alignment, time difference calculation, characteristic duration comparison, early warning level classification and production line workstation binding are executed in sequence to form the production line early warning data structure. On this basis, the production line workstation screen area mapping, data field and screen component binding, centralized display data assembly, interface component assembly, refresh scheduling and display status record processing are completed to generate the workshop production line data centralized monitoring and traceability management operation record structure. A continuous display and recording link from the production line early warning data structure to the workshop production line data centralized monitoring and traceability management operation record structure is constructed.

[0041] The following are its main beneficial effects:

[0042] (1) By using a high-reliability target traceability record structure, the traceability records from the blockchain traceability ledger and the production process time sequence in the production process configuration are standardized in the same structure and the process combination mapping is performed. This enables the production batch number and production process combination related to the workshop production line to be called and reused in the same data link. Compared with the existing technology where the traceability record sources are scattered and the production process configuration is not structurally associated with the traceability record, this is conducive to carrying out workshop production line data monitoring and traceability management based on a unified high-reliability target traceability record structure in the workshop monitoring system and production execution system.

[0043] (2) By using the parameter structure of the feature function of product characteristic change, the grayscale histogram statistics and regional grayscale feature extraction results after matching product batch number and aligning image frame time axis are sorted into time series, and stable intervals and key change intervals are identified, so that product characteristic change can be solidified into parameter structure in the form of batch dimension time behavior. Compared with the existing technology that only makes judgments based on single frame image or sampling results and lacks a time behavior description that corresponds one-to-one with production batch number, it is beneficial to provide a unified and traceable product characteristic change time benchmark for subsequent time difference calculation and feature duration comparison in the continuous operation scenario of workshop production line.

[0044] (3) By combining the production line early warning data structure with the workshop production line data centralized monitoring and traceability management operation record structure, the time difference calculation and feature duration comparison results formed by the characteristic function parameter structure based on product characteristic change are combined with the early warning level classification and production line workstation binding, and the production line workstation screen area mapping and data field binding with screen components. This allows the early warning information to be synchronously recorded during the centralized display data assembly, interface component assembly and refresh scheduling process. Compared with the existing technology where the early warning results are difficult to link with the on-site centralized display interface and the operation record structure is incomplete, this is conducive to forming a continuous collection, alignment, judgment, display and recording process from the production line early warning data structure to the workshop production line data centralized monitoring and traceability management operation record structure in the application scenario of workshop production line centralized monitoring and traceability management. Attached Figure Description

[0045] Figure 1 This is a flowchart illustrating a method for centralized monitoring and traceability management of workshop production line data provided in an embodiment of this application. Detailed Implementation

[0046] Example 1: Refer to Figure 1 This is a flowchart illustrating a method for centralized monitoring and traceability management of workshop production line data provided in an embodiment of the present invention. The process may include at least steps S100-S400:

[0047] S100: Obtain the blockchain traceability ledger and production process configuration, perform field standardization, rearrange the time sequence of production links, statistically analyze link combination patterns, register combination codes and hash values, analyze combination frequency and consistency threshold screening, and generate a highly reliable target traceability record structure.

[0048] S200, based on a high-reliability target traceability record structure, performs product batch number matching, image frame time axis alignment, grayscale histogram statistics, regional grayscale feature extraction, time series processing, stable interval and key change interval identification and processing, and generates product characteristic change feature function parameter structure;

[0049] S300: Based on the parameter structure of the characteristic function of product characteristic change, perform event primary key binding, timestamp alignment, time difference calculation, characteristic duration comparison, early warning level classification and production line workstation binding processing to generate production line early warning data structure;

[0050] S400, based on the production line early warning data structure, performs production line workstation screen area mapping, data field binding with screen components, centralized display data assembly, interface component assembly, refresh scheduling and display status record processing, and generates a workshop production line data centralized monitoring and traceability management operation record structure.

[0051] Step S100 includes at least steps S110-S130:

[0052] S110. Obtain the blockchain traceability ledger and production process configuration, perform field standardization and production process time sequence rearrangement to obtain the input set for historical traceability record combination analysis.

[0053] In this embodiment, the blockchain traceability ledger is a collection of traceability data maintained by consortium blockchain ledger nodes deployed in the workshop production management network. This ledger records key operational events, collection times, equipment identifiers, operator identifiers, and quality inspection results for each production batch at each workstation, stored using an append-only, tamper-proof transaction structure. The production process configuration is process routing configuration data stored in the manufacturing execution system server. This configuration defines the process sequence, allowed branch paths, workstation numbers for each process, dependencies between processes, and process version numbers for each product model, stored using a combination of structured configuration files and parameter tables. Specifically, a traceability processing service module is deployed in the workshop production control network. This module is automatically triggered when a new block event is detected on a blockchain node or when a preset time window ends. It reads traceability transaction records within a target time period in batches through the programming interface provided by the chain node, and simultaneously reads the production process configuration corresponding to the current product model and process version from the process configuration management module. These two types of data are then linked in the same processing task, forming the initial input for this step. To achieve standardized field processing, the traceability processing service module pre-maintains a field mapping dictionary and unit conversion rules. The field mapping dictionary uniformly defines internal standard field names such as production batch number, process number, workstation number, timestamp, equipment number, operator identifier, and quality inspection result, and establishes corresponding relationships for field names and encoding methods from different source systems. The unit conversion rules are used to standardize time formats and status value encoding. During operation, the traceability processing service module parses the transaction load in the blockchain traceability ledger line by line, converting the original key-value pairs to the internal standard field set according to the field mapping dictionary. Records missing necessary fields are marked as abnormal and written to the abnormal record buffer. Records with timestamp formats that do not conform to expectations or exceed reasonable ranges are corrected or removed, and the corresponding correction rules and decision-making basis are recorded in the log submodule. After field standardization, all traceability records are converted to a unified internal structure, carrying unified production batch number, process number, and timestamp fields, and are associated with the corresponding process version number and data source identifier, facilitating subsequent combined analysis. To support auditability during version evolution, the field mapping dictionary itself is stored using version tags and effective time interval management. When processing each record, the traceability processing service module selects the matching field mapping version based on the record's creation time and appends the dictionary version number to the standardized result. Thus, even when the system is upgraded or the meaning of the fields is adjusted, the specific parsing rules used for each traceability record can still be traced.After standardizing the fields, the traceability processing module rearranges the time sequence of production steps according to the production process configuration. First, it divides the standardized traceability records into multiple batch sets based on the production batch number. Within each batch set, it sorts the records in ascending order by the timestamp field. Then, it adjusts the order of steps with overlapping times or parallel operations according to the predefined step order in the process configuration, ensuring the actual execution order matches the process logic. In scenarios with process branch paths, the traceability processing module reads the triggering branch information from the quality inspection result field, equipment number field, or process parameter field in the standardized records based on the branch conditions defined in the process configuration. It constructs a step sequence that matches the actual production path and adds a path identifier field to the rearranged records to identify the specific process route used in that batch. For detected sequence anomalies, such as missing necessary steps, duplicate records, or reversed time sequences, the traceability processing module retains the relevant records in the batch set but adds a sequence anomaly flag field and writes the anomaly type to the anomaly record buffer. The subsequent statistics module can then exclude records that do not meet the analysis requirements based on these anomaly flags. In one feasible embodiment, for a food product filling production line, the blockchain traceability ledger is maintained by a consortium blockchain node server installed in the filling line control room. The production process configuration is maintained by the process routing management module in the manufacturing execution system. The traceability processing service module is deployed on the workshop edge computing server and exchanges data with the aforementioned nodes through the production management network. When a filling batch is packaged and a completion marker is written, a reordering task is triggered. This task standardizes and reorders the records of all stages of that batch, from raw material preparation, filling, sealing, sterilization, cooling to boxing. Finally, the traceability processing service module internally represents the set of records that have undergone field standardization and production stage time-sequence reordering as a historical traceability record combination analysis input set. This historical traceability record combination analysis input set constitutes a structured dataset stored in the traceability database. It serves as the direct input for extracting the production batch number and the time-sequence sequence of stage numbers in step S120, and also serves as the original basis for constructing the subsequent high-reliability target traceability record structure, providing a unified and reliable historical traceability data foundation for subsequent modules.

[0054] S120. Extract production batch numbers and time-ordered process number sequences from the input set of historical traceability record combination analysis, perform process combination pattern statistical processing, combination coding and hash value registration processing, and generate a process combination hash value list.

[0055] In this embodiment, the input set for historical traceability record combination analysis has already undergone field standardization and time order rearrangement in S110. Therefore, each record in this input set carries information such as production batch number field, process number field, timestamp field, process version number field, and path identifier field. The traceability combination analysis module runs on the same server or a logically adjacent microservice instance as the traceability processing service module. When an update to the historical traceability record combination analysis input set is detected or at the end of a preset statistical period, a process combination analysis task is automatically initiated. Specifically, the traceability combination analysis module first groups the historical traceability record combination analysis input set according to the production batch number, and constructs a time-ordered sequence of process numbers for each batch. Each process number is mapped from the process code or workstation code defined in the process configuration. The process number sequence fully reflects the execution order from the first process to the last process. In scenarios with branch paths, the process number sequence also contains path identifier information to distinguish different branch patterns. During the construction of the process number sequence, the traceability combination analysis module processes abnormal records based on the sequence anomaly flag field. For cases of missing necessary steps, duplicate records, or reversed sequence, various implementation methods can be adopted. For example, it can infer the completion based on the minimum necessary step set in the process configuration, or mark the batch as an abnormal batch requiring manual review and exclude it from subsequent high-reliability combination calculations, without affecting the core logic of this invention. After completing the construction of the process number sequence, the traceability combination analysis module performs process combination pattern statistical processing on the process number sequence of each batch. The so-called process combination pattern refers to the ordered step segments extracted from the process number sequence according to a certain window length and step size. It can be a complete sequence combination covering the entire process, or a local sequence combination of fixed or variable length. In the process combination pattern statistical processing, the traceability combination analysis module selects whether to perform statistics on the complete process number sequences of all batches, or to use a sliding window method to perform statistics on local step segment combinations, according to the pre-configured combination strategy, and records the number of times each combination occurs within the statistical period, the production line range of its distribution, and the corresponding process version number. In a preferred embodiment, the system employs a parallel statistical approach of complete sequence combination and partial sequence combination in the food filling production line. The complete sequence combination mode is used to analyze the execution of typical standard process paths, while the partial sequence combination mode is used to capture the connection relationship between several key processes.To facilitate rapid comparison and de-identification processing, the source tracing and combination analysis module performs combination coding and hash value registration for each combination mode. The combination coding is a structured code formed by concatenating the sequence of process numbers according to a preset separation rule and adding the process version number, path identifier, and statistical window information. The hash value is a fixed-length digest value obtained by applying a one-way hash algorithm to the combination code. In this embodiment, the hash algorithm can be a collision-resistant hash algorithm commonly used in industrial control systems, but the specific implementation of the algorithm is not limited. In the combination coding and hash value registration process, the source tracing and combination analysis module first generates the combination code text or binary structure, then calls the hash calculation unit to generate the corresponding hash value. The combination code, hash value, occurrence count, the set of production batch numbers involved, and the corresponding process version number are registered together in the combination mode index table, and the hash value is used as the unique reference key for this combination mode in subsequent analysis. This combination mode index table is organized in the database as a list of process combination hash values. Each row or record in the list of process combination hash values ​​contains a hash value field, a combination code field, a statistical period field, an occurrence count field, a batch number set digest field, and a process version number field. To meet the needs of long-term system evolution and auditability, the list of combination hash values ​​also includes version identifiers and execution times for the combination statistics tasks. The analysis module can track the statistical changes of a specific combination pattern over different periods based on the version identifier during subsequent operation. In a specific embodiment, after the filling production line completes all shifts of production for the day, the system triggers a combination statistics task daily, performing combination encoding and hash registration on the sequence of process numbers for all production batches that day. A typical standard combination for the filling production line might manifest as a fixed pattern from pretreatment, filling, capping, sterilization, cooling to boxing; this pattern will be encoded and registered as a combination record with high frequency of occurrence. Simultaneously, during cross-day statistics, the system can select a statistical period spanning multiple days to compare the combination frequencies of all historical data, providing a richer statistical basis for the subsequent screening of high-reliability target traceability record structures. After the above processing, the list of link combination hash values ​​is used as the output field of step S120. It serves as the direct input for the combination frequency analysis and link combination consistency threshold screening in step S130, and also as the source of traceability statistics for subsequent cross-main steps. When necessary, it can be called by the visualization components in S300 and S400 to help display the distribution of typical process paths and abnormal paths in the workshop.

[0056] S130. Perform combination frequency analysis and combination consistency threshold screening on the list of combination hash values ​​of links to generate a high-reliability target traceability record structure.

[0057] In this embodiment, the process combination hash value list already contains fields such as hash value, combination code, statistical period, occurrence frequency, and associated batch number set for each combination pattern. The construction of the high-reliability target traceability record structure is based on this list, performing combination frequency analysis and consistency threshold screening, and backtracking the original records in the historical traceability record combination analysis input set to form a traceability record set with stable process characteristics. Specifically, the high-reliability screening module is deployed in the same application cluster as the traceability combination analysis module. It is automatically triggered when an update to the process combination hash value list is detected or at the end of a preset statistical period, and performs a traversal analysis of the current version of the process combination hash value list. In the combination frequency analysis process, the high-reliability screening module first calculates or reads the occurrence frequency and batch coverage ratio of each combination pattern in the current statistical period based on the length of the statistical period, the production rhythm of the target production line, and the number of product batches. Without introducing formulas, this can be understood as comparing the occurrence frequency with preset frequency lower limits, coverage requirements, and historical statistical data to determine whether the combination pattern belongs to a conventional process path or a typical path. In one implementation, the high-reliability screening module sets different frequency thresholds for different types of combinations in food filling production lines. For example, for complete combinations covering the entire process, it requires that they appear in most statistical periods and cover most production batches. For partial combinations, a slightly lower frequency standard can be used to distinguish between critical paths and auxiliary paths. In another implementation, the high-reliability screening module can also introduce a combination stability index, using the fluctuation of the occurrence of the same combination in multiple statistical periods as a reference to determine whether a combination is a long-term stable path or a path generated by short-term temporary adjustments. After completing the combination frequency analysis, the high-reliability screening module judges each combination pattern according to a preset consistency threshold rule. This consistency threshold rule defines a lower limit for combination frequency, a lower limit for the proportion of covered batches, and an upper limit for conflict records in abnormal batches. For example, it requires that the number of occurrences of a combination pattern in a statistical period is not less than a certain minimum, the coverage rate of the production batches involved reaches a preset proportion, and the number of occurrences of the combination pattern in batches marked as having abnormal order or missing fields does not exceed a certain number. Combination patterns that meet the above multiple conditions are marked as high-consistency combinations, while other combination patterns are marked as low-consistency combinations or combinations to be observed. If the high consistency condition is not met, the high reliability screening module will not construct the corresponding high reliability target traceability record, but will only retain its statistical information in the combination pattern index table for subsequent analysis. For patterns determined to be high consistency combinations, the high reliability screening module will backtrack the historical traceability record combination analysis input set based on the batch number set summary recorded in the link combination hash value list, filter out all traceability records belonging to the combination pattern, and reconstruct the link execution sequence corresponding to each batch based on the link sequence information in the combination code.During the backtracking process, the high-reliability screening module also simultaneously reads the process version number and path identifier fields related to the batch from the historical traceability record combination analysis input set, and appends them to the corresponding traceability record to identify the process version and process path of the high-reliability combination. In a specific embodiment, for the standard path combination with the highest proportion in the food filling production line, the high-reliability screening module will repeatedly identify it as a high-consistency combination in a multi-day statistical period, and automatically backtrack all traceability records that match this path, constructing them as part of the high-reliability target traceability record structure. This structure includes not only the timestamp and step number of each step, but also the corresponding equipment number, operator identifier, and quality inspection result fields, thus forming a set of reference samples that are relatively stable in terms of time and process logic. In terms of structure, the high-reliability target traceability record structure is constructed as a hierarchical data structure. The upper layer is a highly consistent combined index layer, recording combined hash values, combined codes, process version numbers, and statistical information. The lower layer is a batch record layer, aggregating all traceability records corresponding to a combination by production batch number. Each record contains standardized fields and anomaly marker fields, and a combined identifier field is attached to the record for quick retrieval in subsequent modules. The high-reliability target traceability record structure, as the output field of this step, is written to a dedicated data table in the traceability database. Simultaneously, it is provided to the product characteristic image analysis input set construction module in S210 via a data interface. That is, when constructing the product characteristic image analysis input set, batches and processes belonging to the high-reliability target traceability record structure are preferentially selected, enabling the subsequent product characteristic change detection and feature function establishment module to perform analysis based on samples with stable process execution. Regarding cross-step integration, the high-reliability target traceability record structure can also provide a reference for early warning value calculation in S300. For example, when comparative analysis of abnormal batches is required, standard path samples can be retrieved from the high-reliability target traceability record structure and compared with the traceability trajectory of the current abnormal batch. The comparison results are then displayed on the production line dataset screen and in the early warning management interface of S400. In summary, the output field of this step is the high-reliability target traceability record structure. This field is explicitly declared as one of the inputs of S210 within the system, thus forming a continuous data link from the list of link combination hash values ​​to high-reliability traceability samples, and then to multimodal analysis and early warning display during system operation.

[0058] In summary, the technical effects of this step are as follows: By introducing combination frequency analysis and combination consistency threshold screening on the basis of the combination hash value list, this step transforms the historical traceability data, which was originally mixed with normal and abnormal records, into a structured, highly reliable target traceability record structure. This allows the subsequent product characteristic change modeling and early warning mechanism construction to be based on stable process samples, and retains complete statistical and version information during the system evolution process, which facilitates the auditing and tracking of the traceability process.

[0059] Step S200 includes at least steps S210-S230:

[0060] S210. Obtain a high-reliability target traceability record structure, perform product batch number matching processing and image frame time axis alignment processing to obtain the product characteristic image analysis input set.

[0061] In this embodiment, the workshop production line data centralized monitoring and traceability management system has already constructed a high-reliability target traceability record structure through the preceding step S130. This structure is stored in the traceability data storage node and maintained by the high-reliability traceability sample management module. The high-reliability target traceability record structure records fields such as product batch number, process number, timestamp, process version, production line number, workstation number, equipment number, quality inspection result, and path identifier. Specifically, when the characteristic analysis scheduling module detects that a new round of product characteristic analysis task has been triggered, it reads the high-reliability target traceability record structure from the high-reliability traceability sample management module. The triggering conditions can be reaching a preset statistical period, receiving a manual command from the workshop production management system, or detecting an abnormal alarm in a certain batch of products. The feature analysis scheduling module first filters out high-reliability traceability records belonging to the target production line and target process version based on the production line number field and process version field, and then filters out batches that fail quality inspection based on the quality inspection result field, thereby obtaining a data subset suitable for constructing the product feature image analysis input set. This data subset still maintains the field layout of the high-reliability target traceability record structure.

[0062] When establishing the relationship between the high-reliability target traceability record structure and product image data, the system deploys a product image acquisition subsystem at the visual inspection station in the workshop. This subsystem consists of industrial cameras installed at key locations on the production line, lighting control units, trigger sensors, a product image storage server, and an acquisition gateway that communicates with the Manufacturing Execution System (MES). When each product passes through the visual inspection station, the trigger sensor sends an acquisition trigger signal to the industrial camera. The industrial camera acquires product image frames under pre-configured exposure parameters and writes a timestamp field, a station number field, a production line number field, and a product batch number field issued by the MES into the acquisition results. The product image storage server stores these image frames in an image archive and synchronizes the image metadata to the production management database through the acquisition gateway, establishing a clear mapping relationship between the product image frames and the production line number, station number, and product batch number fields in the traceability record. After obtaining the high-reliability target traceability record structure, the feature analysis and scheduling module queries the corresponding product image frame identifier in the image metadata table based on the product batch number field, constructs an association index between traceability record entries and image frames, and establishes a bidirectional reference relationship between the high-reliability target traceability record structure and the image archive.

[0063] After completing the product batch number matching process, the product image frame timeline and the traceability record timeline need to be aligned. Specifically, the timeline alignment submodule reads the timestamp field of each step in the high-reliability target traceability record structure, and simultaneously reads the acquisition timestamp field in the product image frame metadata. Based on the workshop's unified time source configuration, it determines the time base and accuracy level used by the two types of timestamp fields. If there are time zone deviations or format differences, they are unified to the internal standard time format through time conversion rules. Subsequently, the timeline alignment submodule groups the traceability records and image frame records according to the product batch number field, sorts them within each group according to the timestamp field, and then matches the traceability records occurring around the visual inspection station with the image frames at adjacent times according to the workstation number field and the step number field, constructing a pairwise relationship of "traceability step event - image frame". When multiple images correspond to the same event, the timeline alignment submodule selects a representative frame according to a preset strategy. For example, it selects the image frame whose timestamp field is closest to the timestamp field of the process step, or the image frame with the highest quality assessment score. When there are missing image frames, the timeline alignment submodule will mark the missing frame in the matching result and put the record into the abnormal matching record table. The subsequent statistics module will decide whether to remove the sample as needed.

[0064] In one feasible embodiment, two industrial cameras are deployed on a food packaging production line. One camera captures overall images of the product's appearance, while the other captures images of key local areas. The product batch number field is read from the outer packaging barcode by a barcode scanner and injected into the image metadata. The feature analysis scheduling module periodically extracts stable batch records from a high-reliability target traceability record structure over the past few days. Through joint queries with the image metadata and image archive, it constructs a set of image frames corresponding to each batch, and attaches a process number field, a timestamp field, a workstation number field, and a path identifier field to each image frame, thereby logically forming a product feature image analysis input set. The product characteristic image analysis input set consists of a product batch number field, an image frame identifier field, a standardized timestamp field, a process number field, a process version field, a production line number field, and an optional quality inspection result field. It is registered by the characteristic analysis scheduling module as a structured dataset with the field name "product characteristic image analysis input set", stored in the image analysis database, and provided to the grayscale histogram statistical processing and regional grayscale feature extraction processing modules in the subsequent step S220 through the data access interface, realizing the automatic flow from the high-reliability target traceability record structure to the image analysis input.

[0065] S220. Extract product image frames and corresponding batch numbers from the product characteristic image analysis input set, perform grayscale histogram statistical processing and regional grayscale feature extraction processing, and generate grayscale difference data of product characteristic changes.

[0066] In this embodiment, the product characteristic image analysis input set is output from the aforementioned step S210 and stored in the image analysis database. Its field set includes at least a product batch number field, an image frame identifier field, a timestamp field, a process number field, and a process version field. After receiving the task instruction from the characteristic analysis scheduling module, the image feature extraction module reads the records to be processed in batches from the product characteristic image analysis input set. For each record, it uses the image frame identifier field to retrieve the corresponding product image frame from the image archive, forming a batch-level image frame set. The image frame data is stored using a uniform resolution and grayscale encoding method to support subsequent grayscale histogram statistical processing and regional grayscale feature extraction processing. For different product categories, the image feature extraction module can select the corresponding image preprocessing strategy based on the process version field. For example, background subtraction is performed first for transparently packaged products, and enhancement filtering is performed first for products with obvious surface textures, thereby concentrating the subsequent grayscale statistical results on pixel areas related to product characteristics.

[0067] In grayscale histogram statistical processing, the image feature extraction module divides the grayscale value range into several continuous intervals for each product image frame according to a preset grayscale grading strategy. It then counts the number of pixels in each interval and records this as the grayscale distribution feature of the image frame. The grayscale grading strategy is stored as a configurable parameter in the feature extraction configuration table and can be dynamically adjusted according to the characteristics of the production line. For example, it can enhance the resolution of low grayscale areas in dark-field imaging scenes and enhance the resolution of high grayscale areas for highly reflective packaging materials. During the statistical process, the image feature extraction module performs masking processing on noisy pixels and out-of-focus areas. The criteria for determining noisy pixels can be derived from edge strength, local contrast, or the output of an external noise detection model, while the criteria for determining out-of-focus areas can be derived from texture sharpness evaluation results. Through this noise processing, the system only includes pixels of acceptable quality when calculating the grayscale histogram, avoiding interference from irrelevant factors in the evaluation of product characteristic changes. The grayscale histogram statistical results are organized frame by frame and saved together with the product batch number field and timestamp field as intermediate grayscale statistical results. Internally, the image feature extraction module still treats these as extended fields of the product characteristic image analysis input set.

[0068] In the regional grayscale feature extraction process, the image feature extraction module divides several regions from the product image frame according to a predefined region configuration. Each region corresponds to a key part of the product, such as the bottle opening area, sealing area, label area, or liquid surface area. Region configuration is completed by engineers during the system deployment phase using visualization tools. Region boundaries are described using coordinate ranges in the configuration table, and multiple versions can be maintained based on the process version field and production line number field. During processing, the image feature extraction module calculates various grayscale-related statistical indicators for each region, such as average grayscale level, grayscale distribution concentration, local contrast, and uniformity of bright and dark distribution. These indicators can be obtained by combining the grayscale histogram and local neighborhood statistical results within the region; however, the specific calculation expressions are not described in this manual, only the implementation process. For food products, regional grayscale features are correlated with changes in bacterial count, color, or turbidity. Therefore, the regional grayscale feature extraction module can also read reference data from online quality inspection equipment, labeling the regional grayscale features corresponding to the time period in the reference data to provide labeled samples for subsequent time series processing and feature function construction.

[0069] In one embodiment, for a beverage bottling line, the image feature extraction module, based on the product batch number field recorded in the product characteristic image analysis input, reads complete batch product image frames in batches from the image archive. The system is configured with four regions, corresponding to the main view area of ​​the bottle, the bottle neck sealing area, the label area, and the bottom area, respectively. Each region has an independent grayscale grading strategy and filtering parameters. After grayscale histogram statistical processing, the system generates a set of grayscale histogram data and regional statistical indicators for each image frame. When grouping feature results, the image feature extraction module stores the batch number field, timestamp field, process number field, and corresponding regional grayscale features of each image frame together in the product characteristic change grayscale difference data set. The core field set in the product characteristic change grayscale difference data includes the batch number field, timestamp field, process version field, region identifier field, and region grayscale feature field. The region grayscale feature field records several statistical indicators within the region, used to describe the brightness and darkness changes of product characteristics over time. This set is registered in the system as structured data output with the field name "product characteristic change grayscale difference data". It is directly used as input for time series processing and stable interval and key change interval identification processing in subsequent step S230. At the same time, it can also be used as an auxiliary visualization data source in the production line dataset centralized screen display and early warning management module, allowing operators to view the grayscale change trend in the graphical interface.

[0070] S230. Perform time series processing on the grayscale difference data of product characteristic changes, identify and process stable intervals and key change intervals, and generate the parameter structure of the characteristic function of product characteristic changes.

[0071] In this embodiment, the grayscale difference data of product characteristic changes is output in step S220 and stored in the feature analysis database. Each record contains at least a product batch number field, a timestamp field, a region identifier field, a process version field, and a region grayscale feature field. After receiving the task instruction from the feature analysis scheduling module, the feature function construction module reads the grayscale difference data of product characteristic changes corresponding to a certain batch or a set of batches into memory, groups it according to the product batch number field, and then constructs a region-level time series within each batch according to the region identifier field. In the time series processing, the feature function construction module first sorts according to the timestamp field to construct a sequence table of regional grayscale features changing over time. For scenarios with uneven sampling intervals, the feature function construction module resamples according to a preset sampling rhythm. When it finds that the interval between adjacent timestamps exceeds a set threshold, a virtual time node is inserted, and a missing marker is set for this node to identify sampling gaps in subsequent processing stages. For records with duplicate timestamps or abnormal timestamp order, the feature function construction module detects outliers in the timestamp sequence, triggers an abnormal data processing branch, merges duplicate records, and places records with obviously erroneous timestamps into the abnormal buffer, but retains the original record number for easy subsequent auditing.

[0072] After completing the time series processing, the feature function construction module enters the stable interval and critical change interval identification stage. In this stage, for each regional time series, the module constructs a change rate sequence and a fluctuation degree sequence for the regional grayscale feature fields. Although specific algorithms are used internally for calculation, this manual only describes the overall processing logic. Based on preset stability judgment rules, the module slides a detection window across the time series, statistically analyzing the fluctuation range, continuous trend, and fluctuation frequency of the regional grayscale feature fields within the window. When the fluctuation range within the window is below the stability threshold and the continuous trend meets the stability condition, the corresponding time period is marked as a stable interval. When the grayscale feature fields within the detection window show a significant upward or downward trend, or when the fluctuation range and fluctuation frequency both exceed the change threshold, the corresponding time period is marked as a critical change interval. The stability threshold and change threshold, among other judgment parameters, are stored in the feature function configuration table. Different parameters can be set for different product categories and different regions. During actual operation, the feature function construction module dynamically reads the corresponding configuration based on the process version field and the region identifier field. When there are missing nodes in the grayscale feature sequence, the module considers missing markers when determining the stable interval and the critical change interval. When the missing ratio exceeds the specified range, the time period is not marked as a stable interval or a critical change interval, but enters the state to be supplemented, and is processed by the subsequent data supplementation or re-collection process.

[0073] In one embodiment, for the bottle-sealing area of ​​a beverage filling production line, the feature function construction module identifies stable and critical change intervals in the grayscale feature time series of the bottle-sealing area for each batch. In normal production batches, the bottle-sealing area shows significant grayscale changes before and after the sterilization process, while the grayscale changes are relatively gradual between filling and labeling. The feature function construction module continuously processes historical batch data using stable and change threshold rules to statistically determine the typical locations and durations of stable and critical change intervals in different batches. Based on this, the feature function construction module generates a set of parameters describing the product characteristic change process for each regional time series. This parameter set includes fields such as the start and end times of the stable interval, the start and end times of the critical change interval, the critical change magnitude level, and the change duration level. It also retains the process version field, production line number field, and region identifier field to describe the temporal behavior characteristics of the product characteristics under these production conditions. The above parameter set is organized according to the product batch number field and the region identifier field, forming the parameter structure of the product characteristic change feature function. The product characteristic change feature function parameter structure, serving as an internal system field name, refers to all parameters describing the time-varying patterns of product characteristics. It is stored in a structured format in the feature analysis database and provided to the real-time coding and input time difference calculation input set construction module in subsequent step S310 via a data access interface. When constructing the real-time coding and input time difference calculation input set, S310 reads feature duration-related parameters corresponding to the target batch or product type from the product characteristic change feature function parameter structure. These parameters are then correlated with the time difference between the real-time coding event and the input event to assess the deviation between the current batch production process and its historical stable state. Simultaneously, the product characteristic change feature function parameter structure can also serve as a configuration source for the production line data centralized screen display and early warning management module, providing the visualization interface with characteristic change curve references and early warning threshold references, thereby connecting image analysis results and early warning display logic across main steps. In summary, the technical effects of this step are as follows: By performing time series processing on grayscale difference data of product characteristic changes and identifying stable and key change intervals, this step constructs a structured parameter structure for product characteristic change feature functions. This clearly encodes the relationship between product characteristics and the production timeline and provides a directly callable parameter basis for subsequent real-time coding, early warning calculation of input time difference, and centralized display. Compared with relying solely on real-time image judgment, this provides a more stable and reusable characteristic time scale in production management scenarios.

[0074] Step S300 includes at least steps S310-S330:

[0075] S310. Obtain the parameter structure of the product characteristic change feature function, perform event primary key binding and timestamp alignment processing, and obtain the input set for real-time code input time difference calculation.

[0076] In this embodiment, the product characteristic change feature function parameter structure is output from the preceding step S230 and stored in the feature analysis database. This structure records at least the product batch number field, process version field, production line number field, key change interval start and end time parameters, stable interval start and end time parameters, feature duration parameters, and region identifier field, etc., to describe the typical characteristic change process of different product batches under existing production conditions. The workshop production line data centralized monitoring and traceability management system deploys a real-time event acquisition subsystem at the information system level. The real-time event acquisition subsystem includes a barcode scanning terminal, a coding controller, a data entry terminal, a manufacturing execution system server, and an event message middleware. The barcode scanning terminal reads the coding information on the outer packaging of the product when the product enters the coding station. The coding controller generates a coding event when the coding inkjet or labeling action is completed. The data entry terminal automatically enters product-related information by quality inspectors or equipment. The manufacturing execution system server is responsible for receiving the above events and writing them into the production event database. The event message middleware encapsulates the coding event and the data entry event into a unified format event message stream. The real-time event processing module runs on the edge computing node in the workshop or the data center server. It is automatically triggered when a new coded event or entry event is detected in the event message middleware. It reads the product characteristic change feature function parameter structure corresponding to the current production day or the current statistical cycle from the feature analysis database, and reads the coded event table and the entry event table from the production event database. The three types of data together constitute the input source of this step.

[0077] Specifically, the event primary key binding process is executed by the primary key binding unit in the real-time event processing module. This unit first extracts the product batch number field, single product serial number field, coding time field, coding station number field, production line number field, and process version field from the coding event table, and extracts the product batch number field, single product serial number field, entry time field, entry terminal number field, and entry operator identifier field from the entry event table. Then, it extracts the product batch number field, production line number field, process version field, and feature duration parameter field from the product characteristic change feature function parameter structure. The primary key binding unit uses the product batch number field and the single-item product serial number field as the event primary key according to pre-defined primary key rules. It associates the coding event and the entry event with the corresponding feature parameter records, performing consistency checks on the production line number field and the process version field during the association process. When multiple coding events or multiple entry events are found under the same primary key, the primary key binding unit selects the event closest to the feature parameter statistical time range as the valid event according to the rules, records the remaining events in the abnormal event buffer table, and adds an abnormal type flag. The abnormal event buffer table is synchronously written to the log database for subsequent auditing. After completing the matching of all event records, the primary key binding unit generates a unified event primary key record unit for each successfully matched primary key record. This record unit aggregates the product batch number field, the single-item product serial number field, the coding time field, the entry time field, the feature duration parameter field, the production line number field, and the process version field, providing a foundation for the next step of timestamp alignment.

[0078] In the timestamp alignment process, the time alignment unit in the real-time event processing module performs a unified format conversion on the coding time field and the entry time field of the aforementioned event primary key record unit. The time alignment unit pre-obtains the workshop's unified time source configuration and historical time synchronization records from the system's time management module, identifies the time base and time precision used by different event sources, converts the original time values ​​into an internal unified time format, and corrects events with time zone markings or daylight saving time adjustment records. When it is found that the coding time field of a record is later than the entry time field, or the time difference between the two exceeds the maximum acceptable range of the system, the time alignment unit fills the record with an exception flag field and writes the record to the time exception buffer, while retaining the original timestamp value for subsequent manual verification. While ensuring the uniformity and integrity of the timestamp fields, the time alignment unit, based on the feature duration parameter in the product characteristic change feature function parameter structure, adds a feature duration parameter value related to the characteristics of that batch to each event primary key record unit, establishing an internal association between "coding time—entry time—feature duration parameter," providing complete contextual information for subsequent time difference calculation and feature duration comparison.

[0079] In one feasible embodiment, in the beverage bottling workshop, the coding event originates from the inkjet printer controller installed at the end of the packaging line. The programmable logic controller (PLC) collects the coding completion signal and sends an event message via an event message middleware, which includes a production batch number field, a single-item product serial number field, and a coding time field. The data entry event is triggered by the data entry terminal in the quality inspection area. When quality inspectors complete the sampling data entry and submit the record, the system generates an entry event message containing a product batch number field, a single-item product serial number field, and an entry time field. After detecting that the characteristic function parameter structure of the corresponding batch of product characteristics has been generated by S230 and entered into the feature analysis database, the real-time event processing module initiates a primary key binding and timestamp alignment task, integrating the three data sources into a unified event primary key record set. Finally, the real-time event processing module serializes the integrated results, organizes each event primary key record unit into structured data, and declares the field name of this data set as "real-time code input time difference calculation input set". This data structure is the output product of step S310 and is directly used by the time difference calculation processing and feature duration comparison processing modules in subsequent step S320. At the same time, it serves as a bridge connecting product characteristic analysis and early warning calculation at the system cross-main step level.

[0080] S320. Extract the product batch number, coding time field, and entry time field from the real-time coding entry time difference calculation input set, perform time difference calculation processing and feature duration comparison processing, and generate a product-level early warning value list.

[0081] In this embodiment, the real-time coding entry time difference calculation input set is output by step S310 and stored in the early warning calculation database. The early warning value calculation module reads this input set when it receives a task instruction from the early warning task scheduler. The task triggering condition can be after the production line completes all entry operations for a certain batch of products, when the system reaches a preset statistical cycle time, or when the operator manually triggers the early warning assessment through the workshop management interface. The early warning value calculation module parses each record in the real-time coding entry time difference calculation input set, extracting the product batch number field, single product serial number field, coding time field, entry time field, characteristic duration parameter field, production line number field, and process version field, and internally constructs a temporary data structure for time difference calculation. The time difference calculation processing is performed by the time difference calculation unit in the early warning value calculation module. This unit relies on a unified time format to calculate the time interval between the entry time field and the coding time field for each record, generating the coding entry time difference value for the product, and recording the time difference value in the time difference field. The time difference calculation unit supports multiple calculation granularities, such as calculating the time difference at the level of a single product, the median time difference of a batch, or the maximum time difference of a batch. In the core solution of this invention, the time difference field at the level of a single product is a required field, used to generate product-level early warning values, while the batch-level time difference index is an optional extension, used in subsequent statistical analysis scenarios.

[0082] After completing the time difference calculation, the early warning value calculation module enters the feature duration comparison processing stage. This process is performed by the feature comparison unit, which reads values ​​from the time difference field and the feature duration parameter field, and determines the degree of deviation of the time difference relative to the feature duration parameter according to a preset comparison strategy. The feature duration parameter originates from the product characteristic change feature function parameter structure and reflects the reference time required for a product batch to move from a critical change range to a stable range under normal production conditions. The feature comparison unit first loads the corresponding comparison rules from the feature function configuration table based on the process version field and the region identifier field. These rules define the segmentation relationship between the time difference and the feature duration parameter, as well as the corresponding early warning interval division logic. In actual calculations, the feature comparison unit categorizes the time difference records for each product based on the ratio, direction, and magnitude of the difference between the time difference and the feature duration parameter, generating a basic early warning metric. Internally, the basic early warning metric can be represented as a hierarchical marker or ordered level. The early warning value calculation module combines this basic early warning metric with the product batch number field and the individual product serial number field to form a product-level early warning assessment record.

[0083] In one embodiment, the beverage filling production line configures a characteristic duration parameter for the packaging process of refrigerated beverages. This parameter reflects the time range from the completion of filling and sealing to the completion of the critical cooling process and the attainment of a stable product temperature. When reading the real-time coding entry time difference calculation input set, the early warning value calculation module calculates the time difference between the entry time field and the coding time field for each product in the same batch and compares it with the corresponding characteristic duration parameter. When the time difference is significantly shorter than the characteristic duration parameter, the characteristic comparison unit classifies the product into a high-risk category; when the time difference fluctuates around the characteristic duration parameter, it is classified into a normal category; and when the time difference is significantly longer than the characteristic duration parameter, it is classified into another risk category. To improve the auditability and configuration management capabilities during system evolution, the characteristic comparison unit records the version number of the comparison rule, the effective time of the comparison rule, and related configuration parameters when generating the early warning metric. This metadata information is written into the early warning evaluation record, allowing for retrospective analysis of the specific rule version and configuration status when analyzing the basis for early warning decisions.

[0084] During the early warning value generation phase, the early warning value calculation module generates a comprehensive early warning value for each product based on the basic early warning metric. This comprehensive early warning value is a specific representation of the product-level early warning value. The module can design different comprehensive early warning value formats according to workshop management strategies, such as a simple hierarchical marking method, a comprehensive scoring method including multiple dimensions, or a structured record method with explanatory labels. In the core solution of this invention, the comprehensive early warning value includes at least two parts: an early warning level field and an early warning reason field. The early warning level field indicates the severity of the early warning for the product, and the early warning reason field summarizes the direction and approximate magnitude of the deviation between the time difference and the characteristic duration parameter, facilitating the subsequent display module to present concise explanatory information on the interface. After generating the comprehensive early warning value for all products, the early warning value calculation module compiles the product batch number field, single product serial number field, production line number field, early warning level field, and early warning reason field into a set of product-level early warning value records, and registers this set as structured data output with the field name "Product-level Early Warning Value List". The product-level early warning value list is stored in the early warning result database and is directly used as input for early warning level classification and production line workstation binding in step S330. It also serves as a cross-main step data source for the production line data centralized screen display and early warning management module in S400 to access when displaying early warning details.

[0085] S330. Perform warning level classification and production line workstation binding on the product-level warning value list to generate the production line warning data structure.

[0086] In this embodiment, the product-level early warning value list is output in step S320 and stored in the early warning result database. The early warning distribution module is activated when a new round of product-level early warning value list is generated or when the workshop management system issues a refresh request. It parses each record in the product-level early warning value list and forms structured early warning data for the workshop operation layer through early warning level classification and production line workstation binding. The early warning level classification is performed by the early warning level classification unit. This unit first reads the early warning level configuration table, which is maintained by workshop managers through a configuration interface. It defines parameters such as the level name, level order, corresponding early warning range, color code, and sound and light prompt strategy for different early warning levels, and sets independently adjustable configuration items for different production lines, product types, or process versions. For each record in the product-level early warning value list, the early warning level classification unit reads the early warning level field and the early warning reason field, re-merges the early warning levels according to the mapping relationship in the early warning level configuration table, and fine-tunes the early warning level according to the deviation direction and magnitude described in the early warning reason field when necessary. For example, a middle level is used for records near the boundary, and a higher level is used for records with obvious deviation. After merging, the warning level classification unit adds a final warning level identifier field to each record, and also constructs a user-friendly color coding field and a prompt strategy field to provide input for subsequent screen display configuration.

[0087] In the production line workstation binding process, the workstation binding unit in the early warning distribution module maps product-level early warning records with assigned final early warning levels to specific production line workstations and screen display areas. The workstation binding unit first reads the production line and workstation topology information from the workshop resource management database. This information records the workstation number, workstation type, upstream and downstream workstation relationships, screen terminal number, screen terminal location, and workstation binding strategy for each production line. The workstation binding strategy defines the spatial attribution rules for different types of early warnings, such as whether a product-level early warning is assigned to the upstream workstation where the problem occurred, the current storage workstation where the product is stored, or the quality inspection workstation responsible for the product. Based on the production line number field and the single-item product serial number field in the product-level early warning value list, the workstation binding unit retrieves the most recently visited key workstation record for the product from traceability data or real-time event data. It then determines the current workstation or the most relevant workstation for the product using the workstation number field, and finally, combines this with the workstation binding strategy to determine the target workstation for displaying the early warning information. In some implementations, to cover cross-process impacts, the workstation binding unit can also bind multiple workstation identification fields to the same warning record, such as simultaneously marking the corresponding production workstation and quality inspection workstation, so that the warning information can be displayed synchronously on multiple screen terminals.

[0088] In one embodiment, each production line in the beverage bottling workshop is equipped with three types of screen terminals, installed in the bottling station area, cooling station area, and quality inspection area, respectively. The corresponding station binding strategy is as follows: warnings related to deviations in characteristic duration parameters are assigned to the screen terminals in the cooling station area and quality inspection area. The bottling station area only displays the current output and equipment status, and does not display this type of warning. When processing the product-level warning value list, the station binding unit locates the corresponding production line topology based on the production line number field, and then infers whether the product has entered the cooling end stage or the quality inspection stage based on the single product serial number field, product batch number field, and station trajectory in the traceability record. The final warning level identifier field and warning reason field are then bound to the screen terminal number field in the cooling station area and the quality inspection area. The station binding unit also generates a prompt strategy field for each warning record based on the audio-visual prompt strategy in the warning level configuration table, and writes it into the terminal control queue in combination with the screen terminal number field, providing the necessary input for the subsequent production line station screen area mapping processing and data field binding with screen components in S410.

[0089] In this invention, the production line early warning data structure serves as the core data structure output by the early warning distribution module. After completing the early warning level classification and production line workstation binding processing, the early warning distribution module organizes each product-level early warning record into a structured record set containing fields such as product batch number, single product serial number, production line number, target workstation number, screen terminal number, final early warning level identifier, color code, prompt strategy, and early warning reason. This set is then registered as an output field named "Production Line Early Warning Data Structure." The production line early warning data structure is stored in the early warning distribution database and exposed to the production line workstation screen area mapping processing module and data field and screen component binding processing module in subsequent steps S410 via an interface service. This forms a crucial bridge across main steps, from feature analysis and early warning calculation to centralized display and archive of operation records. At the version management level, the system adds a configuration version number and generation time field to the production line early warning data structure, enabling the system to reconstruct the decision-making logic at the time of reviewing early warning behavior based on the early warning level configuration and workstation binding strategy in effect at that time. In summary, the production line early warning data structure output in this step is not only directly usable by the S410, but also referenced in the workshop management statistical analysis module. It is used to statistically analyze the early warning distribution across different workstations, shifts, and product types, thus closing the monitoring and traceability management link of this invention from a management perspective. The technical effects of this step can be summarized as follows: By introducing early warning level classification and production line workstation binding processing on top of the product-level early warning value list, this step constructs a production line early warning data structure oriented towards specific workstations and screen terminals. This transforms the early warning results from an abstract numerical list into control data with spatial orientation and display strategies, providing early warning inputs refined to the workstation and terminal levels for centralized monitoring and traceability management. It also provides a unified and reliable data foundation for subsequent centralized display and operation record archiving.

[0090] Step S400 includes at least steps S410-S430:

[0091] S410. Obtain the production line early warning data structure, perform production line workstation screen area mapping processing, data field binding processing with screen components, and obtain the screen display configuration input set.

[0092] In this embodiment, the production line early warning data structure is output from the preceding step S330 and stored in the early warning distribution database. The production line early warning data structure records at least the following fields: product batch number, single-piece product serial number, production line number, target workstation number, screen terminal number, final early warning level identifier, color code, prompt strategy, and early warning reason. The workshop production line data centralized monitoring and traceability management system includes a screen mapping management module and an interface component binding module, both running on the application server within the workshop information management network. The screen mapping management module periodically queries the early warning distribution database to check for a new version of the production line early warning data structure, or receives an event notification after the early warning distribution module writes a new version. Upon detecting new version data, this step is automatically triggered, using the latest version of the production line early warning data structure as input. Meanwhile, the screen mapping management module reads the production line workstation topology, screen terminal asset list, and screen physical installation location information from the workshop resource management database. The production line workstation topology records the workstation number, workstation type, upstream and downstream relationships, and the production line number to which it belongs. The screen terminal asset list records the screen terminal number, screen size, resolution, and the workstation area to which it belongs. The screen physical installation location information records the coordinates of the workshop area where the screen is located and its visible range.

[0093] Specifically, the production line workstation screen area mapping process is executed by the mapping rule engine unit in the screen mapping management module. The mapping rule engine unit pre-loads a workstation screen area mapping rule table, which is maintained by workshop managers using configuration tools. The rules include the relationship between warning levels and screen area priorities, the relationship between target workstation types and screen area types, single-screen multi-area allocation strategies, and cross-screen allocation strategies. The mapping rule engine unit first locates the target production line in the production line workstation topology based on the production line number field. Then, it establishes a set of workstations to be mapped based on the target workstation number field and the workstation number fields recorded in the topology. Simultaneously, it locates a set of candidate screens in the screen terminal asset list based on the screen terminal number field. Subsequently, within the same production line, the mapping rule engine unit incorporates the set of workstations to be mapped and the set of candidate screens into the rule calculation process. For each warning record, it selects an appropriate screen area type based on the warning level identifier field and the warning reason field. For example, high-level warnings are mapped to the main viewing area, medium-level warnings are mapped to the sidebar area, and low-level warnings are mapped to the summary area. When a screen terminal needs to display multiple warning records, the mapping rule engine unit dynamically generates a screen area identifier field based on the screen size and the number of preset areas, dividing the screen into several logical areas. Each area corresponds to a screen area identifier field and the number of warning records it can accommodate.

[0094] After completing the screen area division, the mapping rule engine unit, for each record in the production line early warning data structure, finds the corresponding workstation in the set of workstations to be mapped based on the target workstation number field. Then, it matches the specific screen terminal number field and screen area identifier field based on the early warning level identifier field and workstation type, adding screen area mapping information to the matching result. For early warning records that fail to match a suitable screen area, the mapping rule engine unit writes the record to the screen mapping exception table, along with an exception reason code. The exception table is viewed and handled by system maintenance personnel. After the above mapping calculation, each valid record in the production line early warning data structure is appended with a screen area identifier field and a screen terminal number field, thereby logically establishing a one-to-one or one-to-many relationship between the target workstation and the screen area.

[0095] The binding of data fields to screen components is performed by the component binding unit in the interface component binding module. The component binding unit pre-loads a set of screen component templates from the interface component template library. These templates include alert list components, workstation status panel components, batch details pop-up components, SOP step prompt components, and overall production line overview components. Each component template defines a component type, a set of bindable fields, a set of supported interactive events, and a set of visual style parameters. Based on the screen area identifier field and alert level identifier field output by the mapping rule engine unit, the component binding unit selects a matching component template. For example, the main view area uses a workstation status panel component or an alert list component, while the sidebar area uses an SOP step prompt component. The component binding unit constructs a component binding record for each screen area instance, filling in the screen terminal number field, screen area identifier field, component type field, and binding field mapping relationship. The binding field mapping relationship explicitly indicates which display position and data slot in the component instance the product batch number field, single-item product serial number field, alert level identifier field, color code field, and alert reason field in the production line alert data structure are bound to. The component binding unit also reads the refresh cycle parameters related to the warning display from the system configuration and writes them into the component binding record as the component instance refresh strategy field, so that the subsequent refresh scheduling module can use them in step S430.

[0096] In one embodiment, a beverage workshop installs a large screen at the end of each production line. The central area displays the current warning status of each workstation, the right-hand area displays a list of warning details, and the bottom area displays SOP (Standard Operating Procedure) prompts related to the warnings. The screen mapping management module identifies the workstation range covered by the screen based on the production line workstation topology, mapping the production line warning data structure records associated with that range to the central and right-hand areas. The interface component binding module binds the central area to a workstation status panel component, the right-hand area to a warning list component, and the bottom area to an SOP prompt component, specifying the data source field for each component instance in the component binding record. Finally, the screen mapping management module and the interface component binding module jointly construct a set of screen display configuration input records. The system organizes these records into a structured data set, with fields including at least the screen terminal number, screen area identifier, component type, binding field mapping relationship, refresh strategy, and product batch number and warning level identifier fields inherited from the production line warning data structure. Internally, the system names this data set the "Screen Display Configuration Input Set" and writes it into the interface configuration database. The screen displays the configuration input set as the output field of step S410, which is directly called by the centralized display data assembly and interface component assembly module in the subsequent step S420, thereby realizing the transition of the production line early warning data structure output by S330 to the centralized display module at the main step level.

[0097] S420: Extract screen layout parameters, warning level fields and SOP operation step templates from the screen display configuration input set, perform centralized display data assembly processing and interface component assembly processing, and generate production line data centralized screen display configuration.

[0098] In this embodiment, the screen display configuration input set is output in step S410 and stored in the interface configuration database. This database contains fields such as screen terminal number, screen area identifier, component type, binding field mapping relationship, refresh strategy, and product batch number and warning level identifier related to the warning. The centralized display configuration management module initiates this step when it detects the generation of a new version of the screen display configuration input set or when the workshop management system issues an interface refresh configuration update command. The centralized display configuration management module first extracts the set of screen terminal numbers that need to participate in this round of configuration calculation from the screen display configuration input set. Then, it loads the screen layout parameters of the corresponding screen terminal from the screen layout parameter library, which records screen resolution, screen physical size, available area rectangle division scheme, default component arrangement order, and default font size. Simultaneously, the centralized display configuration management module reads the SOP operation step template related to the corresponding production line from the SOP template management module. The SOP operation step template describes the operation step number, step text content, responsible role, and step order for each type of abnormality or warning level.

[0099] The centralized data assembly process is performed by the data assembly unit within the centralized display configuration management module. For each screen terminal, the data assembly unit constructs a list of screen regions based on the screen region identifier field recorded in the screen display configuration input. Then, according to the region rectangle division scheme in the screen layout parameters, it assigns a specific pixel range and display order to each screen region. Subsequently, the data assembly unit determines the component semantics of each region instance based on the component type field (e.g., workstation status panel, warning list, or SOP step area), and establishes a field mapping relationship between the component instance and the production line warning data structure by combining the binding field mapping relationship field. For the warning list component, the data assembly unit filters records from the production line warning data structure according to the warning level identifier field and the product batch number field. Based on the binding field mapping relationship field, it fills the warning level identifier field, warning reason field, and product batch number field into the column definition of the warning list component. Simultaneously, it adds a corresponding foreground or background color marker to each warning record based on the color coding field. For the workstation status panel component, the data assembly unit reads the latest workstation operating status indicators from the traceability database or production line status monitoring database through the target workstation number field and the production line number field, combines the workstation status indicators and the warning level identifier field into a workstation status structure, and fills it into the data area of ​​the workstation status panel component according to the workstation arrangement order defined in the screen layout parameters.

[0100] During the centralized data assembly process, the data assembly unit also needs to associate SOP operation step templates with warning records. The data assembly unit reads the set of operation steps set for different warning levels and warning reasons from the SOP operation step templates, and then matches the specific SOP operation step template entries on the warning record corresponding to the screen display configuration input set based on the warning level identifier field and the warning reason field. The matching results are then organized into an SOP prompt data structure. For the SOP step prompt component below, the data assembly unit fills the step number field, step text field, and responsible role field from the SOP prompt data structure into the component data buffer, so that whenever a warning record appears on the screen, the corresponding SOP step prompt component can display the matching operation suggestion. During this process, the data assembly unit also records the SOP template version number field and the SOP template effective time field, writing them into the screen component configuration. This allows the SOP version used at the time to be restored when reviewing the operation records later.

[0101] The interface component assembly process is executed by the component assembly unit in the centralized display configuration management module. For each screen terminal, the component assembly unit constructs a complete centralized screen display configuration structure for production line data based on the area layout, component type, and component data generated by the data assembly unit. The component assembly unit generates a component instance description for each screen area instance, including component identifier, component type, coordinates and dimensions, data source identifier, field binding list, and interaction strategy fields. The interaction strategy field defines how the component responds to operator clicks, scrolling, filtering, etc. For example, when a row in the warning list component is selected, a batch details pop-up window is triggered; when a workstation in the workstation status panel component is selected, the user scrolls to the corresponding warning record; when a step in the SOP step prompt component is selected, an action is registered and executed on the operator terminal. The component assembly unit also combines the refresh strategy field and the warning level configuration table to set the refresh frequency and refresh trigger event for each component instance. For example, components associated with high-level warnings use a shorter refresh cycle, while components associated with low-level warnings use a longer refresh cycle, reducing the consumption of network and screen resources.

[0102] In one embodiment, the end-of-line screens in the beverage workshop adopt a three-row, three-column layout. The first row displays the overall status of the production line, the second row displays the workstation status panel components, and the third row displays the warning list components on the left and the SOP step prompt components on the right. The centralized display configuration management module loads the three-row, three-column layout scheme from the screen layout parameter library and assigns a layout position to each area instance according to the screen area identifier field in the screen display configuration input set. The component assembly unit generates a component instance description for each area instance, mapping the data structure generated by the production line warning data structure and the SOP operation step template to the component data source, ultimately forming a structured production line data centralized screen display configuration set. This set is registered internally by the system as a data structure with the field name "production line data centralized screen display configuration" and stored in the interface configuration database, providing a configuration basis for the refresh scheduling processing and display status record processing in subsequent step S430. At the same time, the production line data centralized screen display configuration is also associated with the current version number and effective time period through the configuration management module, enabling the system to retain the old version configuration and mark the corresponding version in the running record when upgrading the interface layout scheme in the future.

[0103] S430: Refresh and schedule the configuration of the centralized screen display of production line data and the data structure of production line early warning data, and process the display status record to generate the operation record structure of centralized monitoring and traceability management of workshop production line data.

[0104] In this embodiment, the centralized screen display configuration of the production line data is output in step S420, and the production line early warning data structure is output in step S330. These two are stored in the interface configuration database and the early warning distribution database, respectively. The centralized display execution module and the operation record management module run on the business server in the workshop information management network, performing real-time control of the screen display and recording the display status. The refresh scheduling process is executed by the refresh scheduling unit in the centralized display execution module. This unit periodically reads the centralized screen display configuration of the production line data, obtains the component instance set and corresponding refresh strategy field for each screen terminal, and subscribes to data change events in the early warning result database. When a new version of the production line early warning data structure is written or the status of an existing early warning record is updated, the refresh scheduling unit determines whether to trigger a partial refresh or a full-screen refresh based on the refresh strategy field.

[0105] Specifically, the refresh scheduling unit maintains refresh queues divided by screen terminal number and component instance identifier. Each queue item records the target component instance, the bound data source identifier, and the most recent refresh timestamp field. The refresh scheduling unit periodically traverses the refresh queues, determining whether a refresh is needed based on the component instance's refresh strategy field and the difference between the current time and the last refresh time. When an update to a warning record in the warning result database is detected, the refresh scheduling unit locates the associated component instance based on the data source identifier field, marks the corresponding queue item as an event-triggered refresh, and prioritizes refreshing that component instance in the next scheduling cycle. The refresh action is executed by the screen rendering unit. Based on the component instance description in the centralized screen display configuration of the production line dataset, the screen rendering unit reads the latest data from the production line warning data structure and associated data sources, converts it into rendering instructions, and sends them to the display control program of the corresponding screen terminal via the workshop network, thereby displaying the latest warning information and SOP prompts on the screen.

[0106] The display status recording process is executed by the display record unit within the operation record management module. After each refresh action, the display record unit retrieves the screen terminal number field, component instance identifier field, refresh timestamp field, and the set of warning record identifiers read from the production line warning data structure from the refresh scheduling unit, and combines this information into a display event record. The display record unit also appends the current production line data centralized screen display configuration version number field to the display event record, recording the version status of the interface layout and component binding relationships. If an operator performs operations such as confirmation, blocking, or annotation on a warning record through a screen terminal or auxiliary operation terminal, the display record unit reads the interaction event identifier field, operator identifier field, and interaction timestamp field from the interaction event queue, associating the interaction behavior with this display event record, thus forming a traceable display and response chain. The display record unit stores all display event records in a structured manner. The recorded content includes fields such as product batch number, single product serial number, production line number, workstation number, screen terminal number, component instance identifier, warning level identifier, display timestamp, interface configuration version number, and interaction action summary.

[0107] In one embodiment, a lightweight display control program runs on each screen terminal in the beverage workshop. This program periodically receives rendering instructions and data snapshots from the centralized display execution module and completes the graphics rendering locally. The centralized display execution module controls the frequency of rendering instruction transmission through a refresh scheduling unit, using a shorter refresh cycle for components related to high-level warnings and a longer refresh cycle for components related to low-level warnings. When a high-level warning record for a certain batch of products is added to the warning result database, the refresh scheduling unit immediately marks the component instance associated with that batch as needing a refresh and generates a rendering instruction in the next scheduling cycle, driving the screen terminal to quickly display the warning information. The display recording unit synchronously records the product batch number field, warning level identifier field, and interface configuration version number field involved in this refresh. If the on-duty personnel click on the warning record on the screen and register that they have completed a certain operation in the corresponding SOP step through the operation terminal, the interaction event will be attached to the display event record, forming a complete "display-response" event chain.

[0108] In this invention, the workshop production line data centralized monitoring and traceability management operation record structure serves as the output field for this step, constructed by the operation record management module based on the display record unit. This structure summarizes and hierarchically manages the aforementioned display event records. The top layer is an operation record index layer divided by time slice and production line number; the middle layer is a display behavior layer divided by screen terminal number and component instance identifier; and the bottom layer is an early warning display trajectory layer divided by product batch number and single product serial number. The operation record management module writes the operation record structure into the mirror table of the operation record database and the traceability database, enabling the structure to be used by the workshop management statistics module to analyze long-term early warning distribution, and also as auxiliary input in the next round of historical traceability record combination analysis. Specifically, in the subsequent step S110, when the system reads the historical traceability record combination analysis input set from the traceability database, it can simultaneously read the workshop production line data centralized monitoring and traceability management operation record structure entries related to these batches, incorporating display behavior and early warning response behavior into the traceability analysis perspective, thereby closing the complete link from production behavior, characteristic changes, early warning calculation to display behavior. The workshop production line data centralized monitoring and traceability management operation record structure output in this step is therefore used both as an output field of step S430 for long-term archiving and as an auxiliary input field of step S110 for cross-batch analysis.

[0109] In summary, the technical effects of this step are as follows: By introducing refresh scheduling and display status recording processing on the basis of the centralized screen display configuration and production line early warning data structure of the production line data, this step constructs a structured workshop production line data centralized monitoring and traceability management operation record structure. It transforms screen display behavior and operator response behavior into data objects that can be stored and traced back for a long time, forming a traceable closed-loop data link between the centralized display module and the preceding traceability analysis module and early warning calculation module. In the field of production management, it constructs a set of display operation archives associated with interface configuration version and early warning strategy.

Claims

1. A method for centralized monitoring and traceability management of workshop production line data, characterized in that, include: The blockchain traceability ledger and production process configuration are obtained, and field standardization and production process time sequence rearrangement are performed. For the rearranged traceability records, a process number sequence is constructed according to the production batch. The process number sequence is subjected to process combination mode statistical processing. Based on the preset consistency threshold including the lower limit of combination frequency, the lower limit of the coverage batch ratio, and the upper limit of abnormal batch conflict, high consistency combinations are selected. Historical traceability records are checked back to aggregate and form a high reliability target traceability record structure. Based on a high-reliability target traceability record structure, product batch number matching and image frame timeline alignment are performed to obtain a product characteristic image analysis input set. Product image frames are extracted from the input set, and regions corresponding to key parts of the product are divided from the image frames according to a preset region configuration. Gray-level histogram statistics and region gray-level feature extraction are performed on the divided regions to generate gray-level difference data of product characteristic changes. The gray-level difference data is grouped by product batch and region identifier to construct a region-level gray-level feature time series. A detection window is slid across the time series to statistically analyze the fluctuation range and trend of gray-level features within the window. Intervals with fluctuations below a stable threshold are marked as stable intervals, and intervals with fluctuations exceeding a change threshold are marked as critical change intervals. Based on the identified stable intervals and critical change intervals, a product characteristic change feature function parameter structure is generated. Based on the feature function parameter structure of product characteristic changes, event primary key binding is performed to associate the coding event and the input event with the corresponding feature parameters; The time difference between the coding time and the input time is calculated, and the comparison rules are loaded from the feature function configuration table according to the ratio and direction of the time difference with the feature duration parameter to generate a basic early warning metric value. The basic early warning metric value is divided into early warning levels, and the divided early warning levels are bound with the target workstation number and the screen terminal number according to the production line workstation topology structure read from the workshop resource management database and the preset workstation binding strategy to generate a production line early warning data structure containing the final early warning level identifier field, the target workstation number field and the screen terminal number field. Based on the production line early warning data structure, according to the screen terminal asset list and screen physical installation location information read from the workshop resource management database, the screen area mapping of the production line workstation is processed, and according to the component templates loaded from the interface component template library, the early warning level, product batch and SOP operation step template read from the SOP template management module are bound to the corresponding components on the screen to generate the screen display configuration. According to the refresh strategy field in the screen display configuration, the screen refresh is triggered periodically or based on data change events, and rendering instructions are sent to the display control program through the screen rendering unit. After each refresh, the screen terminal number, component instance identifier, warning record identifier, and interface configuration version number are recorded, and the operator's interaction events are associated to generate a workshop production line data centralized monitoring and traceability management operation record structure. This structure includes an operation record index layer divided by time slice and production line number, a display behavior layer divided by screen terminal number and component instance identifier, and a warning display trajectory layer divided by product batch number and single product serial number. The workshop production line data centralized monitoring and traceability management operation record structure is used as an auxiliary input in subsequent historical traceability record combination analysis and is associated with the corresponding historical traceability records so that the display behavior and warning response behavior related to these batches can be read synchronously during traceability analysis.

2. The method according to claim 1, characterized in that, The process of performing field standardization and time sequence rearrangement in the production process includes: Field standardization processing includes marking records with missing required fields as exceptions and writing them to the exception record buffer, correcting or removing timestamp formats, and reordering the production process in terms of time sequence. The production process time sequence rearrangement process includes dividing the standardized traceability records into batch sets, arranging them in ascending order by the timestamp field within each batch set, adjusting the order of steps with time overlap or parallel operations according to the predefined step order in the production process configuration to maintain consistency with the actual process logic, and constructing a step sequence from the quality inspection result field or equipment number field according to the branch conditions and adding a path identifier field in the case of process branch paths.

3. The method according to claim 1, characterized in that, The blockchain traceability ledger and production process configuration include: The blockchain traceability ledger includes key operation events, collection time, equipment identification, operator identification, and quality inspection results, and is stored using an append-only, tamper-proof transaction structure. The production process configuration includes the process sequence, allowed branch paths, workstation numbers corresponding to each process, dependencies between processes, and process version numbers, and is stored using a combination of structured configuration files and parameter tables.

4. The method according to claim 1, characterized in that, The process of constructing the regional grayscale feature time series includes: The time series processing includes grouping by product batch number and region identifier, sorting by timestamp field to construct regional time series, resampling for scenarios with uneven sampling intervals and inserting virtual time nodes to mark missing data, and processing duplicate or abnormal timestamp records. The stable interval and key change interval identification processing includes constructing change rate sequence and fluctuation degree sequence based on regional grayscale feature fields, sliding detection window on the time series to count fluctuation range and continuous trend, marking stable intervals when the fluctuation range is below the stability threshold and the trend is stable, and marking key change intervals when the fluctuation range or frequency exceeds the change threshold.

5. The method according to claim 1, characterized in that, The process of binding event primary keys includes: The event primary key binding process includes extracting the product batch number and coding time fields from the coding event table, extracting the product batch number and entry time fields from the entry event table, extracting the feature duration parameter field from the product characteristic change feature function parameter structure, associating the coding event and entry event with the feature parameter record using the product batch number and single product serial number as the event primary key, and performing production line number and process version consistency verification. The timestamp alignment process includes converting the coding time field and entry time field into an internal unified time format, correcting time zone deviations or format differences, and marking an anomaly when the time difference exceeds the acceptable range.

Images