Process cooperation method and device across heterogeneous industrial control platforms

Abstract

The application discloses a cross-heterogeneous industrial control platform process cooperation method and device. On the source industrial control system side, the original process parameter label is mapped into a standard OPC UA node according to a unified naming specification, and a multi-layer security strategy including bidirectional certificate authentication, an encrypted channel, firewall isolation and UA protocol-aware application layer security bridging is constructed. The standardization data stream after security bridging verification is output by performing protocol-aware analysis and compliance verification on the OPC UA session message in the security channel establishment stage. On the target industrial control system side, the data stream is subscribed and time alignment processing is performed, and the joint data set is displayed on the monitoring interface in linkage. The process flow causal dependence graph is taken as a framework to divide the monitoring domain, the block-level quality index is calculated in each domain by using the multivariate function type principal component analysis calculation block, the global quality diagnosis report and the abnormal traceability path are generated through the Bayesian network probability fusion, and hierarchical early warning, work order creation and double-track archiving closed-loop processing are performed according to the diagnosis report. The application realizes the safe data sharing between the heterogeneous industrial control systems at low cost without a centralized data platform, and has the early detection and accurate traceability ability of the abnormal evolution trend form of the process parameters.

Description

Technical Field

[0001] This invention belongs to the field of industrial Internet of Things and production process monitoring technology. Specifically, it relates to a method and device for process collaboration across heterogeneous industrial control platforms based on OPC UA standardized release, protocol-aware security bridging, and topology-driven distributed quality monitoring. It can be applied to process data sharing and quality traceability between heterogeneous industrial control systems in process industries such as wood-based panel manufacturing. Background Technology

[0002] In process industries such as wood-based panel manufacturing, chemical processing, and food processing, upstream and downstream production processes are typically managed using different brands of industrial control systems (hereinafter referred to as "ICS"). For example, the glue-making workshop uses the Wonderware InTouch system, while the drying workshop uses the Siemens WinCC system. Each ICS independently maintains the process parameter tags and real-time database for its own process, forming a typical cross-platform information silo structure. Cross-ICS process data integration is a fundamental requirement for ensuring collaborative process control, improving product quality consistency, and building a full-chain quality traceability system.

[0003] Existing cross-industrial control system data integration solutions mainly fall into two categories: The first category involves deploying a centralized SCADA / MES platform to aggregate data from various industrial control systems into a unified real-time database, which is then uniformly scheduled and distributed by upper-layer applications. This type of solution has high construction costs and long implementation cycles, and any failure of the centralized platform will result in the interruption of data access for all processes. The second category involves developing point-to-point customized communication interfaces between various industrial control systems to directly exchange data using industrial communication protocols such as ModbusTCP and Profinet. This type of solution requires the separate development of interface logic for each pair of industrial control systems, lacks a unified semantic standard, and has poor system scalability.

[0004] The most relevant prior art solution to this invention is: intermediate gateway devices are deployed in the glue-making workshop and the drying workshop respectively. Each gateway converts the process parameters of the local industrial control system into a unified intermediate format and then transmits them point-to-point through the TCP / IP network in a custom message format. The target gateway parses the received message and writes the data into the corresponding tag of the local industrial control system, thereby realizing data communication between processes.

[0005] The aforementioned existing technical solutions have the following technical problems: First, the custom message format lacks semantic standardization capabilities. The process parameters of different processes differ significantly in terms of naming rules, units of measurement, and sampling frequencies. The format conversion logic of the intermediate gateway must be developed and maintained separately for each pair of processes, resulting in extremely poor system scalability. Each time a new process is added, a high cost of customized development is required. Second, the above solutions only focus on whether the data can reach the target system and lack an end-to-end automatic data quality monitoring mechanism. Quality attributes, including the integrity of transmitted data, the accuracy of timestamps, and the rationality of values, lack systematic automatic detection methods. As a result, process quality anomalies are often only discovered at the finished product inspection stage, making fault tracing difficult and unable to achieve early warning and accurate location. Summary of the Invention

[0006] To address the aforementioned shortcomings of existing technologies, this invention provides a method and apparatus for collaborative processes across heterogeneous industrial control platforms, aiming to solve the technical problems of poor data integration and scalability between heterogeneous industrial control systems and the lack of end-to-end automatic data quality monitoring and early warning.

[0007] This invention provides a method for process collaboration across heterogeneous industrial control platforms, comprising the following steps:

[0008] On the source industrial control system side, the original process parameter labels are remapped to standard OPC UA nodes according to a unified naming convention to form a standardized label set;

[0009] Based on the standardized tag set, a multi-layer security policy is constructed, which includes two-way certificate authentication, encrypted channel, firewall isolation and UA protocol-aware application layer security bridging. The UA protocol-aware application layer security bridging parses request messages and performs session compliance verification during the security channel establishment phase, and outputs a standardized data stream after security bridging verification.

[0010] On the target industrial control system side, after the application layer security bridging verification, the relevant tag subset of the standardized data stream is subscribed to, the upstream and downstream data are time-aligned, a joint dataset is obtained, and the data is displayed in a linked manner on the monitoring interface.

[0011] Based on the causal dependencies of the process flow, a process variable dependency graph is constructed and decomposed into multiple monitoring domains. Within each monitoring domain, a block-level quality index is calculated using multivariate principal component analysis. Then, a Bayesian network is used to perform probabilistic fusion of all the block-level quality indices to obtain a global quality diagnosis report and anomaly tracing path.

[0012] Based on the global quality diagnostic report, tiered early warnings are issued, alarms are pushed, and processing work orders are created. When the work order is closed, dual-track archiving is performed to update the abnormal case library and the multivariate function principal component analysis model.

[0013] Furthermore, the UA protocol-aware application layer security bridge parses request messages and performs session compliance verification during the secure channel establishment phase, outputting a standardized data stream after security bridge verification, including:

[0014] During the window period between the client sending a request to establish a secure channel and before creating a session, the security policy and certificate chain in the request to establish a secure channel are parsed and compared with the security policy template of the publishing server.

[0015] Perform whitelist verification and session policy parameter validation on the user identity token in the session creation request and session activation request, and reject session requests that do not comply with the security policy;

[0016] Configure differentiated access policies based on the security level of the tags;

[0017] Continuously monitor heartbeat messages and session identifier reuse of active sessions during session duration;

[0018] When a session anomaly is detected, session termination and forced re-authentication are triggered, and the tag data is published to the outside world in a publish-subscribe mode, outputting a standardized data stream after security bridging verification.

[0019] Furthermore, the session policy parameter verification supports configuring differentiated access policies based on the security level of the tag, including: configuring a full read policy for the reaction temperature tag, and configuring a policy that only allows specified clients to subscribe at a specified sampling frequency for the formula concentration tag.

[0020] Furthermore, a process variable dependency graph is constructed based on the causal dependencies of the process flow and decomposed into multiple monitoring domains. Within each monitoring domain, a block-level quality index is calculated using multivariate principal component analysis. Then, a Bayesian network is used to probabilistically fuse all the block-level quality indices to obtain a global quality diagnosis report and anomaly tracing paths, including:

[0021] A process variable dependency graph is constructed using key process parameters of each process as nodes and physical causal relationships between variables as edges.

[0022] Based on the structure of the process variable dependency graph, graph decomposition is performed to divide the variables into the glue-making domain, the transport domain, and the drying domain.

[0023] Deploy domain quality monitoring agents within each of the aforementioned monitoring domains to receive data snapshots of all variables in the domain at the data acquisition end, security bridging end, network transmission end, and client receiving end;

[0024] The sampling sequence of all process parameters in the domain within the time window is jointly fitted into a set of multivariate B-spline basis functions, and then projected into the basis function expansion space onto the multivariate function principal component analysis model trained under normal operating conditions of the domain.

[0025] Calculate the multivariate Hotelling statistic and the multivariate squared prediction error statistic to obtain the block-level quality index of the domain.

[0026] A Bayesian network is constructed using the causal edge directions in the graph decomposition as priors. The quality index of the parent domain is used as the input of the conditional probability of the quality index of the child domain. The fault origin domain is inferred in reverse along the causal edges to obtain the global quality diagnosis report and the anomaly tracing path.

[0027] Further, the calculation of the multivariate Hotelling statistic and the multivariate squared prediction error statistic to obtain the block-level quality index of the domain includes:

[0028] By comparing the tag arrival rate node by node, and statistically analyzing the gap duration and the number of consecutive losses, the integrity assessment results are obtained.

[0029] When the multivariate Hotelling statistic exceeds the control limit, it is determined that a systematic functional anomaly has occurred in the domain.

[0030] When the multivariate squared prediction error statistic exceeds the control limit, the parameter with the highest contribution weight is analyzed to locate the source of local morphological anomalies.

[0031] The end-to-end transmission delay and sampling interval offset between each node are measured to obtain the timeliness assessment results.

[0032] The integrity assessment results, the systematic functional anomaly determination results, and the timeliness assessment results are aggregated into the block-level quality index of the domain.

[0033] Furthermore, based on the global quality diagnostic report, tiered early warnings are issued, alarms are pushed out, and processing work orders are created, including:

[0034] When the tag interruption or loss rate exceeds the threshold, a Level 1 alarm is generated by the associated security bridging layer reporting session anomaly events;

[0035] When the end-to-end transmission delay exceeds the process tolerance limit, a secondary alarm is generated by locating the monitoring domain where the delay is located in conjunction with the abnormal tracing path.

[0036] When the multivariate squared prediction error statistic exceeds the control limit while the multivariate Hotelling statistic is normal, a level 3 alert with attention level is generated.

[0037] When the multivariate Hotling statistic exceeds the control limit, a Level 3 warning is generated.

[0038] Based on the alarm level and monitoring domain identifier, the alarm is pushed to the corresponding operating terminal and audible and visual alarm device, and a processing work order is created in the work order system, which includes the alarm type, associated monitoring domain, abnormal parameters and statistical deviation.

[0039] Furthermore, the step of performing dual-track archiving to update the exception case library and the multivariate principal component analysis model when the work order is closed includes:

[0040] Record the handling measures and recovery time when the work order is closed;

[0041] For curve segments that are confirmed as genuine process anomalies in work orders, the anomaly type and root cause are labeled and stored in the anomaly case library.

[0042] Only when there is a planned change in the process formulation or equipment and the new operating condition data is confirmed to be in a new normal state, the basis function expansion parameters and control limits of the multivariate principal component analysis model for the corresponding monitoring domain are re-estimated using the new operating condition data;

[0043] Link work order processing progress, exception cases, and model update version numbers with the quality traceability chain records.

[0044] Furthermore, the step of performing time alignment on upstream and downstream data to obtain a joint dataset and displaying it in a linked manner on the monitoring interface includes:

[0045] Create a subscription session in read-only mode on the target industrial control system side, and configure the heartbeat interval, exponential backoff reconnection strategy and maximum retention time of cached data;

[0046] The timestamps of upstream data and local data are interpolated and synchronized, their units are checked, and outliers are filtered to obtain the time-aligned joint dataset.

[0047] The joint dataset is used to display upstream process parameters and local process parameters side by side through a cross-process monitoring screen component embedded in the local human-machine interface, and supports trend curve overlay and historical backtracking.

[0048] Furthermore, the three-dimensional quality index, Bayesian tracing path, and functional anomaly detection results of each monitoring domain are persistently written into the time series database, supporting quality trend backtracking queries by monitoring domain, by parameter, and by time period, and generating quality traceability chain records.

[0049] The present invention also provides a process collaboration device across heterogeneous industrial control platforms, comprising:

[0050] The standardized release module is used to remap the original process parameter tags to standard OPC UA nodes according to a unified naming convention on the source industrial control system side, forming a standardized tag set;

[0051] The security bridging module is used to construct a multi-layer security policy based on the standardized tag set, including two-way certificate authentication, encrypted channel, firewall isolation and UA protocol-aware application layer security bridging. The UA protocol-aware application layer security bridging parses request messages and performs session compliance verification during the security channel establishment phase, and outputs a standardized data stream after security bridging verification.

[0052] The subscription linkage module is used to subscribe to the relevant tag subset of the standardized data stream on the target industrial control system side after the application layer security bridging verification, to perform time alignment of upstream and downstream data, obtain a joint dataset, and display it in linkage on the monitoring interface.

[0053] The quality monitoring module is used to construct a process variable dependency graph based on the causal dependency relationship of the process flow and decompose it into multiple monitoring domains. Within each monitoring domain, the block-level quality index is calculated using multivariate principal component analysis, and all the block-level quality indices are probabilistically fused using a Bayesian network to obtain a global quality diagnosis report and anomaly tracing path.

[0054] The early warning closed-loop module is used to perform hierarchical early warning based on the global quality diagnosis report, push alarms and create processing work orders, and perform dual-track archiving to update the abnormal case library and the multivariate function principal component analysis model when the work order is closed.

[0055] Compared with the prior art, the present invention has the following advantages:

[0056] (1) This invention maps process parameter tags of different brands of industrial control systems to OPC UA nodes with standard semantics through the unified naming specification and standardized release mechanism of the OPC UA information model. It can achieve low-cost data integration between heterogeneous industrial control systems without the need to build a centralized data platform. When adding a new process, only the namespace configuration needs to be expanded. It has good scalability and significantly reduces the development and maintenance costs of cross-system data integration.

[0057] (2) The UA protocol-aware application layer security bridge proposed in this invention adds protocol semantic level session compliance verification and differentiated access control for the establishment phase of OPC UA SecureChannel, based on the traditional three-layer protection of industrial control firewall, TLS encrypted channel and X.509 two-way certificate authentication. Through OpenSecureChannel message security policy parsing, CreateSession / ActivateSession user identity token whitelist verification and session life-long monitoring, a complete defense-in-depth system is constructed, which effectively fills the gap in the existing solution in OPC UA application layer session compliance management.

[0058] (3) The present invention uses the process flow causal dependency graph as the skeleton to automatically divide the monitoring domain and uses multivariate function principal component analysis to jointly model the time series curves of multiple process parameters in the domain. It can trigger early warning when the parameter evolution trajectory deviates (such as systematic drift such as the reaction temperature continuously and slowly rising). The detection capability is significantly better than the traditional point-by-point threshold method, which can greatly advance the time of anomaly detection.

[0059] (4) This invention achieves cross-monitoring anomaly tracing through Bayesian network probability fusion, automatically distinguishes between independent faults and chain anomalies caused by causal propagation, and effectively avoids fault misjudgment when multiple alarms are issued at the same time; the dual-track archiving mechanism strictly distinguishes between real anomaly case archiving and model control limit update path, ensuring that the anomaly detection model does not generate degradation risk during continuous optimization. Attached Figure Description

[0060] Figure 1 This is a schematic diagram of the overall architecture of a cross-heterogeneous industrial control platform process collaboration system provided in an embodiment of the present invention.

[0061] Figure 2 This is a schematic diagram of the UA protocol-aware application layer security bridging session compliance verification process provided in an embodiment of the present invention.

[0062] Figure 3 This is a process variable dependency graph and a schematic diagram of monitoring domain division provided in an embodiment of the present invention.

[0063] Figure 4 This is a schematic diagram of a four-node data acquisition and multivariate principal component analysis modeling for a domain quality monitoring agent provided in an embodiment of the present invention.

[0064] Figure 5 This is a schematic diagram of the hierarchical early warning judgment logic and closed-loop processing flow provided in an embodiment of the present invention.

[0065] Figure 6 This is a schematic diagram of the linkage display process of cross-process monitoring screen components provided in an embodiment of the present invention. Detailed Implementation

[0066] The specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. The following embodiments take the cross-control system data collaboration scenario between the glue-making workshop and the drying workshop in the wood-based panel manufacturing industry as a typical application example, wherein the source control system (hereinafter referred to as "source end") is the Wonderware InTouch control system of the glue-making workshop, and the target control system (hereinafter referred to as "target end") is the Siemens WinCC control system of the drying workshop.

[0067] Example 1

[0068] This embodiment provides a method for process collaboration across heterogeneous industrial control platforms, including the following steps:

[0069] S1: On the source industrial control system side, the original process parameter labels are remapped to standard OPCUA nodes according to a unified naming convention to form a standardized label set.

[0070] In the InTouch industrial control system of the glue-making workshop, the process parameters of each reactor are stored in the InTouch real-time database as local private tags. These tags lack cross-system semantic standards and cannot be directly recognized or understood by external systems. To achieve cross-system semantic interoperability, an OPC UA publishing server is built on the source industrial control system side. Following the unified naming convention "Namespace:Workshop.Process.Parameter.Unit", the original tags are mapped one by one to standard OPC UA nodes. For example, the glue concentration tag is mapped to the node "GluePlant:ReactorA.GlueProcess.Concentration.Percent", the stirring time tag is mapped to "GluePlant:ReactorA.GlueProcess.StirTime.Second", the reaction temperature tag is mapped to "GluePlant:ReactorA.GlueProcess.Temperature.Celsius", and the glue viscosity tag is mapped to "GluePlant:ReactorA.GlueProcess.Viscosity.mPas". Through the above unified naming convention, the original process parameter tags from different brands of industrial control systems are given standardized semantic descriptions, forming a standardized tag set that can be recognized and accessed by any OPC UA compatible client.

[0071] It is worth noting that the design of the unified naming convention follows the principle of industrial semantic interoperability. The OPC UA information model constructs a node network through three elements: node class, node attribute, and reference. Each standard OPC UA node carries not only data values ​​but also semantic metadata such as engineering units, data types, ranges, and node descriptions. When building an OPC UA publishing server on the source industrial control system side, the above semantic metadata is mapped to the standard nodes along with the original tags. This allows any client conforming to the OPC UA specification to automatically understand the physical meaning, engineering units, and appropriate ranges of process parameters by browsing the node metadata, without the need for pre-built special format parsing logic. This characteristic is the fundamental difference from traditional custom message format transmission schemes. In traditional schemes, the semantics of the message format need to be maintained through documents privately agreed upon by both parties, and the format specifications need to be renegotiated every time a new access party is added. However, the standardized publishing scheme based on the OPC UA information model allows new access clients to independently parse tag semantics as long as they have the OPC UA protocol stack, enabling plug-and-play cross-system data sharing and fundamentally eliminating the expansion bottleneck of point-to-point interface development.

[0072] Specifically, when deploying the OPC UA publishing server on the source industrial control system side, a tag mapping configuration file is used to define the correspondence between the original InTouch tag names and the standard OPC UA node paths. The configuration file adopts a structured format, and each mapping record includes fields such as the source tag identifier, the target OPC UA node path (generated according to naming conventions), the node data type, engineering units, normal range upper and lower limits, and sampling period. The OPC UA publishing server reads the configuration file upon startup and dynamically registers the corresponding OPC UA node in the address space. Subsequent tag updates in the InTouch real-time database are subscribed to in real-time by the publishing server through the InTouch Suite Link interface and mapped to the Value attribute of the corresponding OPC UA node, maintaining the real-time data consistency of the standardized tag set with the data of the source industrial control system. When a new process needs to be added, only the corresponding namespace and mapping records need to be extended in the configuration file; no modification to the core logic of the publishing server is required, demonstrating excellent horizontal scalability.

[0073] S2: Based on the standardized tag set, construct a multi-layer security policy that includes two-way certificate authentication, encrypted channels, firewall isolation, and UA protocol-aware application layer security bridging. The UA protocol-aware application layer security bridging parses request messages and performs session compliance verification during the secure channel establishment phase, and outputs a standardized data stream after security bridging verification.

[0074] Based on the standardized tag set constructed in step S1, a multi-layered security strategy consisting of four protection mechanisms is built. The first layer is a two-way authentication mechanism based on X.509 certificates. Both the OPC UA publishing server and each access client must hold digital certificates issued by the factory's CA, completing two-way identity verification before communication is established to ensure the trustworthiness of both parties. The second layer is a TLS encrypted channel, providing end-to-end encryption protection for all data transmitted during the OPC UA session, preventing process parameter data from being eavesdropped on or tampered with during network transmission. The third layer is industrial firewall rule configuration, limiting source / target IP whitelists through access control lists, opening only the OPC UA standard port 4840, achieving access isolation at the network layer, and blocking connection attempts by unauthorized terminals. The fourth layer is UA protocol-aware application-layer security bridging, further implementing protocol semantic-level compliance verification during the OPC UA session establishment process on top of the first three layers of protection. Specific verification logic is shown in Example 2. These four security mechanisms work together to ultimately output a standardized data stream verified by the security bridging, which is then available for subscription by the target industrial control system.

[0075] S3: On the target industrial control system side, after the application layer security bridging verification, subscribe to the relevant tag subset of the standardized data stream, perform time alignment on the upstream and downstream data, obtain a joint dataset, and display it in a linked manner on the monitoring interface.

[0076] Deploy the OPC UA client on the WinCC industrial control system side of the drying workshop. When initiating a connection, the client must pass the application layer security bridging compliance check in step S2. After the verification is passed, the client selects a subset of tags related to the drying process (such as glue ratio concentration, reaction temperature, glue viscosity, etc.) from the standardized data stream on demand for read-only subscription. The client establishes a local memory cache, configures heartbeat intervals and disconnection reconnection parameters to ensure data continuity when the communication link is abnormal. The data preprocessing module performs interpolation synchronization and dimensional unification processing on the timestamps of the upstream glue making data and the timestamps of the local process parameters of the drying workshop, eliminates the time sequence misalignment problem caused by the difference in cross-system sampling frequencies, and forms a time-aligned joint data set. The joint data set is displayed through the cross-process monitoring screen component embedded in the WinCC HMI, and the upstream glue process parameters (glue ratio concentration, reaction temperature, etc.) and the local parameters of the drying process (hot air temperature, moisture exhaust damper opening, etc.) are presented side by side on the same screen, supporting real-time trend curve superposition and historical traceback, so as to provide operators with a cross-process linkage monitoring view. For the detailed implementation of step S3, refer to Embodiment 8.

[0077] S4: Construct a process variable dependency graph based on the causal dependency relationship of the process flow and decompose it into multiple monitoring domains, calculate the block-level quality index in each of the monitoring domains using multivariate functional principal component analysis, and perform probability fusion on all the block-level quality indices through a Bayesian network to obtain a global quality diagnosis report and an abnormality traceability path.

[0078] Based on the physical mechanism of the process flow from the glue-making workshop to the drying workshop, a process variable dependency graph is constructed, using key process parameters of each process as nodes and directed edges representing the physical causal relationships between variables. According to the topology of the dependency graph, the variables are divided into three independent monitoring domains: the glue-making domain (parameters such as glue concentration, stirring time, reaction temperature, and viscosity), the transmission domain (parameters such as OPC UA communication link status), and the drying domain (parameters such as hot air temperature, exhaust damper opening, feed rate, and discharge moisture content). An independent domain quality monitoring agent is deployed within each monitoring domain to collect data snapshots of variables at four nodes: the data acquisition end, the security bridging end, the network transmission end, and the client receiving end. Each domain agent jointly fits the sampling sequences of all process parameters within its domain within the recent time window into a multivariate B-spline basis function. This basis function expansion is then projected onto a multivariate functional principal component analysis (mfPCA) model trained under normal operating conditions for that domain. The multivariate Hotelling T² statistic and multivariate squared prediction error (SPE) statistic are calculated. Combined with the completeness and timeliness assessment results, the domain quality assessment result is output in the form of a block-level quality index (BQI). A Bayesian network is constructed using the causal edge directions of each monitoring domain as priors. The BQIs of all domains are probabilistically fused, and the fault origin domain is inferred backward along the causal edge directions to obtain a global quality diagnosis report and anomaly tracing path. Detailed implementation of step S4 is shown in Example 4.

[0079] S5: Based on the global quality diagnostic report, perform hierarchical early warning, push alarms and create processing work orders. When the work order is closed, perform dual-track archiving to update the abnormal case library and the multivariate function principal component analysis model.

[0080] Based on the global quality diagnostic report output in step S4, the hierarchical early warning engine classifies abnormal events into three levels: Level 1 alarms correspond to data interruption anomalies (tag interruption or loss rate exceeding the threshold), and are associated with session anomaly events reported by the security bridging layer to distinguish between network failures and security events; Level 2 alarms correspond to transmission delay anomalies (end-to-end transmission delay exceeding the process tolerance limit); Level 3 alarms correspond to function-type anomalies, further subdivided into three sub-levels: "Attention," "Warning," and "Critical," based on the combined state of T² and SPE statistics. Alarms include an anomaly tracing path and are pushed to the corresponding operation terminal interface and audible / visual alarm devices. The work order system automatically creates processing work orders containing alarm type, associated monitoring domain, anomaly parameters, and statistical deviation information. When a work order is closed, dual-track archiving is performed: The confirmed actual process anomaly curve segment is labeled with its root cause and stored in the anomaly case library; only when a planned change occurs in the process formula or equipment and the new operating condition data is confirmed by the engineer as a new normal state, the basis function expansion parameters and control limits of the corresponding monitoring domain mfPCA model are updated with the new operating condition data. The work order processing progress, anomaly cases, and model version number are synchronously linked to the quality traceability chain record. Detailed implementation of step S5 is shown in Examples 6 and 7.

[0081] Example 2

[0082] like Figure 2 As shown, this embodiment, based on embodiment 1, provides a detailed explanation of the specific implementation of step S2, which involves the UA protocol-aware application layer security bridging parsing request messages, performing session compliance verification, and outputting the standardized data stream after security bridging verification during the secure channel establishment phase. This includes the following sub-steps:

[0083] S2.1: During the window period after the client sends the request to establish a secure channel and before the request to create a session, parse the security policy and certificate chain in the request to establish a secure channel, and compare them with the security policy template of the publishing server.

[0084] The OPC UA session establishment process follows the standard sequence of OpenSecureChannel → CreateSession → ActivateSession. The security bridging layer intervenes within the window between the client sending the OpenSecureChannel request and the arrival of the CreateSession request. It performs deep parsing of the SecurityPolicy field (security policy identifier, such as Basic256Sha256) and certificate chain in the OpenSecureChannel message. The parsing results are compared item by item with the security policy template pre-configured on the publishing server. Verification includes fields such as security policy type, certificate authority compliance, certificate validity period, and certificate revocation status. Connection requests that fail the comparison are rejected during the SecureChannel establishment phase and do not proceed to the subsequent session creation process, thus isolating non-compliant connections from the system at the earliest stage of the protocol handshake.

[0085] It's important to note that in the OPC UA communication protocol specification, the OpenSecureChannel phase is the earliest handshake step for establishing a secure channel between communicating parties. During this phase, before creating a logical session, the client declares its supported security algorithm suite (such as message signature algorithms, encryption algorithms, and key lengths) through the SecurityPolicy field and attaches its X.509 application certificate with the request. The security bridging layer chooses to intervene at this stage to perform security policy comparison, rather than performing post-event verification during application layer data interaction. The technical principle behind this is to isolate non-compliant connections outside the session layer, preventing malicious clients from bypassing subsequent session layer protection and directly initiating data read / write requests through a low-security-policy-level SecureChannel, thus achieving the earliest node interception (Fail-Fast principle). Compared to the traditional approach of verifying user identity only during the ActivateSession phase, the intervention of the security bridging layer in the OpenSecureChannel phase moves security protection to the very beginning of the protocol handshake, terminating connections with non-compliant security policies before consuming any server computing resources, effectively defending against low-security-policy downgrade attacks.

[0086] Furthermore, the verification of the certificate chain is not limited to the signature verification of the certificate body, but also includes verification of the integrity of the Certificate Authority (CA) hierarchy—that is, verifying whether the client certificate was issued by a trusted root CA or intermediate CA pre-installed in the factory PKI infrastructure, preventing the use of self-signed certificates or certificates from unauthorized CAs to access the system. Certificate revocation status is verified through real-time queries using an OCSP (Online Certificate Status Protocol) server deployed within the factory, or through offline verification using a regularly updated Certificate Revocation List (CRL), ensuring that revoked client certificates are identified and rejected during the OPC UA session establishment phase, fundamentally cutting off access channels for departed personnel or decommissioned devices.

[0087] S2.2: Perform whitelist verification and session policy parameter validation on the user identity token in the session creation request and session activation request, and reject session requests that do not comply with the security policy.

[0088] The security bridging layer extracts and parses the UserIdentityToken carried in subsequent CreateSession and ActivateSession requests, performing two checks: first, whitelist verification, matching the requester's identity against the authorized client whitelist, rejecting any client identity not registered in the whitelist; second, session policy parameter verification, checking whether the subscription parameters (sampling frequency, subscription node range, etc.) in the session request comply with the access permissions granted to the client in the security policy, rejecting requests exceeding the authorized scope and recording them in the audit log. Session requests that do not comply with the security policy are filtered at this stage and do not enter the actual data access stage. Simultaneously, all rejection events are recorded with detailed rejection reasons and timestamps for security auditing purposes.

[0089] The UserIdentityToken whitelist verification is implemented based on the factory-level industrial control system's identity management database. This database uses the Subject Key Identifier (SKID) field value of the client's X.509 application certificate as the client's unique identifier, and performs precise matching against the pre-authorized client list. Employing a certificate fingerprint-based identity identification method, rather than based on IP address or client application name, effectively prevents IP address spoofing and client software impersonation attacks. Furthermore, changes to the authorization list (adding or revoking authorized clients) do not require restarting the OPC UA publishing server; they take effect in real-time through a hot-reload mechanism, supporting the execution of updated whitelist rules for new access requests without interrupting existing authorized sessions.

[0090] Regarding session policy parameter validation, the security bridging layer maintains a session policy parameter configuration table for each authorized client. Configuration items include the maximum allowed number of subscription nodes, the minimum allowed subscription interval, and the maximum allowed number of MonitoredItems. When the subscription parameters declared in the CreateSession request exceed the authorized range in the client's policy configuration table, the bridging layer will not allow the over-limit subscription to pass after degradation (i.e., without silent parameter truncation). Instead, it will directly return a BadUserAccessDenied error code and reject the session request, simultaneously recording the actual parameter values ​​and authorized limits in the rejection log. This facilitates security auditors in determining whether there is any probing behavior targeting subscription quotas.

[0091] S2.3: Configure differentiated access policies based on the security level of the tag.

[0092] The security bridging layer maintains a tag security level mapping table, assigning security levels to each OPC UA node in the standardized tag set according to the sensitivity of process data, and configuring differentiated access control policies for tags with different security levels. Through this differentiated access policy mechanism, access permissions for different clients to different tags are finely controlled during the session establishment phase, avoiding the risk of excessive data exposure caused by unified authorization. A specific configuration example of the differentiated access policy is shown in Example 3.

[0093] S2.4: Continuously monitor the heartbeat messages and session identifier reuse of active sessions during the session duration.

[0094] After a session is established, the security bridging layer continuously monitors all active sessions. This monitoring includes two dimensions: first, periodically checking the KeepAlive heartbeat messages for each active session to identify sessions that fail to respond within a timeout period or respond abnormally; second, detecting sessionId reuse to identify unexpected sessionId reuse behavior (this behavior may indicate session hijacking attacks or session leakage after an abnormal client restart). Monitoring results are recorded in real-time in the session state log, providing continuous data for the abnormal triggering in step S2.5.

[0095] The technical principle behind the SessionId reuse detection is as follows: In the OPC UA protocol specification, each session generates a globally unique SessionId by the server during the CreateSession phase. Normally, a new SessionId should be assigned each time a new session is established. If the security bridge layer detects that the SessionId carried in a newly arrived ActivateSession request overlaps with the SessionId of a currently active session, it means that the client is attempting to reuse an existing session identifier without fully executing the CreateSession handshake. This behavior could be a precursor to a session hijacking attack or an abnormal remnant after a client crash. In such cases, the security bridge layer triggers mandatory re-authentication instead of allowing session renewal, thereby cutting off the potentially hijacked session channel and requiring the legitimate client to re-initiate the complete authentication process to rebuild the session with the newly assigned SessionId, completely eliminating the risk of malicious reuse of residual sessions.

[0096] S2.5: When a session anomaly is detected, the session is terminated and forced re-authentication is triggered. The tag data is published to the outside world in a publish-subscribe mode, and a standardized data stream after security bridging verification is output.

[0097] When step S2.4 detects a session anomaly (including unexpected SessionId reuse, client certificate expiration, KeepAlive timeout, etc.), the security bridging layer immediately performs a forced session termination operation, cancels all subscriptions for the corresponding session, and returns a session termination notification to the client, requiring it to complete the entire authentication process starting from the OpenSecureChannel stage again. Renewal based on the existing SessionId is not permitted. Under normal operating conditions, the tag data that passes the above full-process compliance verification is published externally by the OPC UA publishing engine in a subscription-publish (PubSub) mode, forming a standardized data stream verified by the security bridging layer, which is then subscribed to and used by the target OPC UA client in step S3 of Example 1.

[0098] Example 3

[0099] This embodiment, based on embodiment 2, provides a detailed explanation of the specific implementation of the session policy parameter verification in step S2.3, which supports configuring differentiated access policies according to the tag security level, including the following sub-steps:

[0100] S2.3.1: Configure a full read strategy for the reaction temperature label.

[0101] For tags with low sensitivity to process data that need to be shared across multiple downstream processes (such as the reaction temperature tag "GluePlant:ReactorA.GlueProcess.Temperature.Celsius"), their security level is marked as "Public" in the tag security level mapping table of the security bridging layer. The corresponding differentiated access strategy is full read: all authorized clients that have been whitelisted can read the historical and real-time values ​​of this tag at the system's default sampling frequency, without limiting the number of subscribing clients or the range of data queries. This strategy is suitable for general process status parameters such as temperature and pressure, which are instructive for process adjustments in downstream processes and should be widely shared within the authorized scope.

[0102] From a technical perspective, the rationale for configuring a full-read strategy for reaction temperature-related process status parameters is as follows: these parameters are public sensing information necessary for process monitoring, and the operational decisions of multiple downstream processes (such as drying temperature adjustment and slab feed rate control) all rely on real-time sensing of the upstream temperature status. Imposing excessive access restrictions on these parameters would increase the monitoring costs of downstream processes. Furthermore, temperature parameters themselves do not contain confidential formula information, and the risk of public access is within an acceptable range. In addition, the full-read strategy significantly reduces the complexity of authorization management at the implementation level—it eliminates the need to maintain sampling frequency configurations for each authorized client; only client identity registration in the whitelist is required, reducing the operational burden of security policy configuration.

[0103] S2.3.2: Configure a policy for formula concentration labels that allows only specified clients to subscribe at a specified sampling frequency.

[0104] For tags involving sensitive process data such as production formulas (e.g., the formula concentration tag "GluePlant:ReactorA.GlueProcess.Concentration.Percent"), their security level is marked as "Confidential" in the tag security level mapping table of the security bridging layer. The corresponding differentiated access policy is restricted subscription: only explicitly authorized clients in the whitelist (e.g., specific client certificate identifiers of WinCC clients in the drying workshop) are allowed to subscribe at a preset specified sampling frequency (e.g., once every 5 seconds). Subscription requests exceeding the specified sampling frequency, as well as subscription requests initiated by unauthorized clients, are intercepted and rejected during the session policy verification phase of the security bridging layer, and the rejection audit log is recorded. The above differentiated access policy configuration ensures the principle of least privilege exposure for highly sensitive process data, preventing the risk of formula information leakage due to broad authorization.

[0105] The technical basis for the specified sampling frequency limit is that by limiting the subscription sampling frequency, it can prevent malicious or faulty clients from subscribing at extremely high frequencies, which could lead to unreasonable CPU and bandwidth loads on the OPC UA server (i.e., subscription rate flooding attacks). Taking a sampling frequency of once every 5 seconds as an example: for formula concentration parameters, the process-level adjustment response cycle is usually on the order of minutes. A sampling frequency of once every 5 seconds is sufficient to meet the real-time monitoring needs of downstream processes. High-frequency subscriptions exceeding this frequency have no value for process operation and will only increase server load and the exposure of sensitive data. In addition, the restricted subscription policy takes effect during the session policy parameter verification phase, without relying on the client's voluntary compliance. It enforces the principle of least privilege at the system level, ensuring that access to formula data is controllable and auditable.

[0106] Example 4

[0107] like Figure 3 As shown, this embodiment, based on embodiment 1, provides a detailed explanation of the specific implementation of step S4: constructing a process variable dependency graph based on the causal dependency relationship of the process flow and decomposing it into multiple monitoring domains; calculating the block-level quality index using multivariate principal component analysis; and obtaining a global quality diagnosis report and anomaly tracing path through Bayesian network probabilistic fusion. The implementation includes the following sub-steps:

[0108] S4.1: Construct the process variable dependency graph using the key process parameters of each process as nodes and the physical causal relationships between variables as edges.

[0109] Taking the glue preparation and drying process of engineered wood panels as an example, the key process parameters of each process are defined as nodes in the process variable dependency graph: Glue preparation side nodes include glue concentration, stirring time, reaction temperature, and glue viscosity; drying side nodes include hot air temperature, exhaust damper opening, feeding speed, and discharge moisture content; transmission side nodes include link quality parameters such as data packet delay, packet loss rate, and session status of the OPC UA communication link. Directed causal edges are determined based on the process physical mechanism: reaction temperature → glue viscosity (increased reaction temperature accelerates the cross-linking reaction, resulting in decreased viscosity); glue viscosity → drying hot air temperature setpoint (higher viscosity means higher solid content, requiring an appropriate increase in hot air temperature to ensure drying effect); glue concentration → discharge moisture content (higher concentration increases moisture absorption by the board, increasing the risk of high discharge moisture content). All these nodes and directed edges together constitute a complete process variable dependency directed graph, providing a structural foundation for subsequent monitoring domain partitioning.

[0110] Furthermore, the process variable dependency graph adopts a directed acyclic graph (DAG) structure instead of an undirected correlation graph. The technical significance of this is that the directional information of the directed causal edges is the core prior information for Bayesian source tracing inference in subsequent step S4.6—only when the causal direction is known can the fault origin domain be located by inferring the reverse direction along the causal chain through conditional probability. Undirected correlation graphs can only express statistical correlations between parameters and cannot provide information on the causal propagation direction, thus failing to support fault tracing based on causal paths. In the process flow, the determination of the causal direction is based on the process physical mechanism rather than statistical correlation: for example, the causal effect of reaction temperature on glue viscosity is achieved through a thermodynamic reaction kinetic mechanism (increased reaction temperature leads to a faster crosslinking reaction rate, and viscosity decreases accordingly). This causal direction is supported by a physical mechanism and is unrelated to whether temperature and viscosity are strongly correlated in historical data. Graph models built solely based on statistical correlations cannot distinguish between true causal effects and common-cause effects, and will produce erroneous tracing conclusions when multiple parameters are synchronously abnormal. In contrast, directed causal graphs based on physical mechanisms can ensure that the tracing inference results are process-interpretable, enabling operators to formulate targeted response measures accordingly.

[0111] S4.2: Based on the structure of the process variable dependency graph, perform graph decomposition to divide the variables into the glue-making domain, the transport domain, and the drying domain.

[0112] Based on the physical affiliation of nodes in the dependency graph and the cross-domain characteristics of causal edges, a graph decomposition method is used to divide all variable nodes into three monitoring domains: the glue-making domain, which includes all glue-making process parameter nodes (glue concentration, stirring time, reaction temperature, glue viscosity); the transmission domain, which includes OPC UA communication link status parameter nodes (data packet latency, packet loss rate, session state); and the drying domain, which includes all drying process parameter nodes (hot air temperature, exhaust damper opening, feed rate, discharge moisture content). The monitoring context is transmitted between domains through cross-domain causal edges—causal edges from the glue-making domain to the transmission domain express the logical path of glue-making parameter changes transmitted to the drying side via the data link, while causal edges from the transmission domain to the drying domain express the impact of communication link quality anomalies on the reliability of drying side data. The three monitoring domains and their inter-domain causal edges together constitute the skeleton of a topology-driven distributed monitoring framework.

[0113] S4.3: Deploy a domain quality monitoring agent within each of the aforementioned monitoring domains to receive data snapshots of all variables in the domain at the data acquisition end, security bridging end, network transmission end, and client receiving end.

[0114] Deploy an independently running domain quality monitoring agent process in each of the adhesive preparation, transmission, and drying domains. Each agent collects a data snapshot of all variables within its domain at the following four data nodes: Data Acquisition End (real-time database read point of the industrial control system, recording the original value and timestamp of the tag when it is written at the source); Security Bridging End (OPC UA security bridging layer output point, recording the data value and timestamp published after bridging verification); Network Transmission End (mirror port data point of the industrial switch, recording the intermediate state of OPC UA data packets on the network transmission link); Client Receiving End (OPCUA client receive buffer of the target industrial control system, recording the final data value and receive timestamp of the subscribed data). The full data snapshots at these four nodes provide a multi-dimensional, end-to-end data foundation for subsequent triple quality assessments of completeness, accuracy, and timeliness.

[0115] S4.4: Jointly fit the sampling sequence of all process parameters in the domain within the time window into a set of multivariate B-spline basis functions, and project them into the basis function expansion space onto the multivariate function principal component analysis model trained under normal operating conditions in the domain.

[0116] Multivariate functional modeling is performed using the monitoring domain as the unit. For p process parameters within the monitoring domain, discrete sampling sequences of each parameter within the most recent time window (e.g., the past 30 minutes) are taken. Cubic B-spline basis functions are used to fit each parameter sequence to a continuous function curve, resulting in multivariate functional observations composed of p process parameter function curves. These multivariate functional observations are projected onto a multivariate functional principal component analysis (mfPCA) model pre-trained on historical normal operating data for this domain. The score vectors of each principal component are extracted to prepare for subsequent statistical calculations. The training process of the mfPCA model uses historical normal operating data confirmed by process engineers during the initial stage of system commissioning. Principal component function bases of each order are obtained by estimating the eigenvalues ​​of the multivariate functional sample covariance operator, and the number of principal components to be retained is determined based on the cumulative variance contribution rate.

[0117] Specifically, the construction process of the multivariate B-spline basis function is as follows: For the j-th process parameter (j=1,2,...,p) within the monitoring domain, N discrete sampling points collected within the most recent time window are used to form an observation sequence. A third-order B-spline basis function (ensuring the first and second order of the curve is continuously differentiable) and a preset number of uniformly distributed internal nodes are selected. Under the criterion of minimizing the squared residual plus the smoothing penalty term, the B-spline expansion coefficient vector of each parameter sequence is estimated by least squares fitting. The selection of the number of internal nodes follows the principle of "sufficiently expressing the dynamic characteristics of the parameter but avoiding overfitting noise": for parameters with a sampling period of one minute, 8 to 12 internal nodes are usually set within a 30-minute time window, which can fully fit the trend change and mid-frequency fluctuation of the process parameter within this time scale, while smoothing high-frequency sampling noise. After B-spline expansion, each process parameter is represented as a continuous function curve. The p parameter curves together constitute a multivariate function observation value of the current moment in the monitoring domain. This observation value can be regarded as a point in a p-dimensional function space.

[0118] In the basis function expansion space, the process of projecting the multivariate functional observations onto the multivariate functional principal component analysis model is essentially a projection decomposition under the eigenfunction basis of the p-dimensional function covariance operator. The training process of the mfPCA model is as follows: using at least 30 consecutive days of normal operating data during the initial stage of system commissioning (covering typical factory production shifts, seasonal temperature differences, and other variable operating conditions) as training samples, the same B-spline expansion is performed on the parameter sampling sequence for each historical time window to obtain a multivariate functional sample set under historical normal operating conditions. The multivariate functional covariance operator is calculated on this sample set and eigenvalue decomposition is performed (corresponding to singular value decomposition of the covariance matrix under the finite-dimensional approximation). The first m-order principal component function basis, arranged in descending order of variance contribution rate (usually selecting the number of principal components required for a cumulative variance contribution rate of 85% to 95%), is extracted to obtain the basis function set and corresponding eigenvalue vector of the mfPCA model. Each principal component function basis describes the main pattern of joint change of p process parameters under normal operating conditions: the first principal component usually corresponds to the slow drift pattern of the overall level of all parameters, and the higher-order principal components correspond to the change pattern of the relative relationship between parameters. The projection distribution of the training samples in the principal component subspace and residual subspace of the mfPCA model is used to estimate the T² control limit and SPE control limit to complete the model training.

[0119] It should be understood that the technical advantage of using functional principal component analysis instead of traditional multivariate principal component analysis is that traditional multivariate PCA uses the instantaneous value vectors at each discrete sampling time as the modeling object, which cannot capture the morphological characteristics of the evolution of process parameters over time (such as monotonic trends, periodic bending, rate of change, etc.), and can only detect static distribution shifts; while functional PCA treats the entire time series curve as a whole observation object, using the morphological feature space of the curve (spanned by the coefficient vectors of the B-spline basis functions) as the modeling space, so that the T² and SPE statistics can simultaneously sense the abnormal signals in two dimensions: the absolute value shift of the parameter and the morphological shift of the parameter curve. Thus, it can trigger an early warning at the early stage when the parameter evolution trend begins to deviate from the normal trajectory, without waiting for the parameter value to cross a single point threshold.

[0120] S4.5: Calculate the multivariate Hotelling statistic and the multivariate squared prediction error statistic to obtain the block-level quality index of the domain.

[0121] Based on the principal component score vector obtained from projection in step S4.4, the multivariate Hotelling T² statistic is calculated: within the principal component subspace retained by mfPCA, the T² statistic reflects the Mahalanobis distance of the current multivariate functional observation relative to the center of normal operating conditions, and is used to detect whether there is a systematic shift in the overall functional curve shape of the monitoring domain. Simultaneously, the multivariate squared prediction error (SPE) statistic is calculated: the sum of the squares of the differences between the reconstructed value of the current observation in the mfPCA model and the actual observation value. The SPE statistic reflects the magnitude of the residual component where the current observation exceeds the mfPCA's ability to describe normal operating conditions, and can further trace the contribution weight of each parameter within the domain to the total residual, used to locate local morphological anomalies. The T² statistic and SPE statistic, combined with the quantitative results of integrity assessment and timeliness assessment, are summarized into the block-level quality index (BQI) of the domain. The BQI is output outward in the form of a structured numerical vector. Detailed evaluation dimensions of the BQI are described in Example 5.

[0122] S4.6: Construct a Bayesian network using the causal edge directions in the graph decomposition as priors, take the parent domain quality index as input to the conditional probability of the child domain quality index, infer the fault origin domain in reverse along the causal edges, and obtain the global quality diagnosis report and anomaly tracing path.

[0123] Using the causal edge direction of the process variable dependency graph in step S4.2 as the prior, a three-node Bayesian network is constructed: glue-making domain → transmission domain → drying domain. In this Bayesian network, the BQI of the parent domain (upstream domain) serves as the conditional input to the conditional probability distribution of the BQI of the child domain (downstream domain). The posterior probability of each domain being the origin of the anomaly is calculated through Bayesian inference. For example, when the drying domain BQI detects an mfPCA T² anomaly, if the glue-making domain BQI also shows a unidirectional shift, then the glue-making domain is inferred to be the origin of the fault, and the anomaly in the drying domain is a causal propagation effect, based on conditional probability calculation. If the glue-making domain BQI is normal, then the drying domain is inferred to be an independent origin of the fault, thus avoiding unnecessary troubleshooting by maintenance personnel on the drying side. The Bayesian inference results are output in the form of anomaly tracing paths, which, together with the BQI of each domain, constitute a global quality diagnosis report for use by the hierarchical early warning engine in step S5.

[0124] Specifically, the construction method of the Bayesian network conditional probability table (CPT) is as follows: The block-level quality index (BQI) of each monitoring domain is discretized into three state intervals: "normal," "slightly abnormal," and "severely abnormal" (the interval boundaries are determined by dividing the historical BQI distribution using quantiles). The causal edge direction in the process variable dependency graph is used as the prior, with the glue-making domain as the root node (no parent node), the transmission domain taking the glue-making domain as its parent node, and the drying domain taking both the transmission and glue-making domains as parent nodes. The conditional probability distribution of each node is initialized in the following way: In the early stages of system operation, the prior conditional probability table is manually set using existing process knowledge and historical fault cases (such as maintenance logs and production accident records); after the system accumulates a certain amount of historical operating data, the CPT parameters are updated using the Expectation-Maximization (EM) algorithm in a Bayesian manner, so that the probability model gradually converges to the actual fault propagation law, improving the accuracy of source tracing inference.

[0125] During online fault tracing and inference, the BQI state observations of each monitoring domain in the current calculation period are input into a Bayesian network. Precise posterior inference is performed using either the variable elimination algorithm or the junction tree algorithm to calculate the posterior probability that each domain is the fault origin domain under the joint observation of the current BQI states of all domains. Domains with posterior probabilities exceeding a preset confidence threshold (e.g., 0.7) are marked as high-confidence fault origin domains and appended to the anomaly tracing path output in the form of probability values ​​and confidence intervals for reference by the hierarchical early warning engine in step S5 and by operators. This probabilistic tracing method has the advantage over rule-based deterministic tracing methods in that when multiple monitoring domains simultaneously exhibit anomalies, Bayesian inference can synthesize observational evidence from all domains to provide the most probable fault origin hypothesis and its confidence level, rather than arbitrarily pointing to a single domain. This allows operators to make more rational troubleshooting decisions under uncertain conditions.

[0126] Example 5

[0127] like Figure 4 As shown, this embodiment, based on embodiment 4, provides a detailed explanation of the specific implementation of step S4.5, which involves calculating the multivariate Hotelling statistic and the multivariate squared prediction error statistic to obtain the domain block-level quality index. This includes the following sub-steps:

[0128] S4.5.1: Compare the tag arrival rate node by node, collect the statistical gap duration and the number of consecutive losses, and obtain the integrity assessment results.

[0129] The domain quality monitoring agent performs node-by-node statistics on the data arrival status of each process parameter tag within the domain at four acquisition nodes (data acquisition end, security bridging end, network transmission end, and client receiving end): calculating the tag arrival rate (the ratio of the actual number of data packets arriving to the theoretically expected number of data packets) for each node; identifying and counting the duration of consecutive data gaps (the length of the time interval during which no valid data is received consecutively); and counting the number of consecutive data loss instances (the number of consecutively missing sampling points at the sampling period granularity). The three statistical results are combined to form the integrity assessment result, which is written into the BQI vector of the current domain as an integrity component.

[0130] S4.5.2: When the multivariate Hotelling statistic exceeds the control limit, it is determined that a systematic functional anomaly has occurred in the domain.

[0131] The multivariate Hotelling T² statistic value within the current time window, calculated according to step S4.4 of Example 4, is compared with the T² control limit estimated using the F-distribution or Bootstrap method on historical data under normal operating conditions. When the T² statistic exceeds the control limit, it is determined that the joint function curve shape of multiple process parameters within the monitoring domain has undergone a systematic overall shift relative to the normal operating condition reference model, i.e., a domain-level systematic function anomaly. Taking the glue-making process of engineered wood panels as an example: when the joint shape of the curves of parameters such as reaction temperature and glue viscosity in the glue-making domain shows a continuous and slow drift trend (e.g., the reaction temperature systematically increases at a rate of approximately 0.3°C per hour), the T² statistic will exceed the control limit before the parameter value reaches the upper limit of a single-point threshold (e.g., 180°C)—for example, when the temperature is still at 175°C. This enables early detection of abnormal systematic evolution trends, significantly advancing the anomaly detection time compared to traditional point-by-point threshold alarms.

[0132] The estimation method for the T² control limit is as follows: After the mfPCA model training is completed, the projection score vectors of all normal operating condition training samples in the mfPCA principal component subset space are substituted into the Hotelling T² statistic calculation formula to obtain the historical distribution of the training set T² statistic. The control limit can be estimated by two methods: Method 1 is the parametric estimation method. Under the assumption that the principal component score vectors follow a multivariate normal distribution, the T² statistic theoretically follows an F distribution. The control limit is determined based on the quantiles of the F distribution (usually the quantile corresponding to the 99% confidence level). Method 2 is the nonparametric bootstrap method. By resampling the training samples with replacement (it is recommended that the number of bootstrap iterations be no less than 1000), the empirical quantile distribution of the T² statistic is estimated, and the 99th quantile is taken as the control limit. This method has stronger robustness to non-normal principal component scores and is suitable for scenarios where the process parameter distribution deviates significantly from normality. In practical deployments, if the training sample size is sufficient (it is recommended to have no less than 300 time window samples), the Bootstrap method should be used first to estimate the control limits in order to reduce the dependence on distribution assumptions and improve the accuracy of control limit estimation.

[0133] S4.5.3: When the multivariate squared prediction error statistic exceeds the control limit, analyze the parameter with the highest contribution weight to locate the source of local morphological anomalies.

[0134] When the SPE statistic exceeds the SPE control limit estimated by kernel density estimation or χ² distribution method, the contribution weight of each process parameter to the total SPE is further calculated. The contribution weight is defined as the proportion of the square of the residual component of each parameter in the total sum of squared residuals. The contribution weights are sorted from high to low. Parameters with contribution weights exceeding a preset proportion threshold are marked as sources of local morphological anomalies. Their parameter identifiers, contribution weight values, and SPE exceedance magnitudes are written into the function accuracy component of BQI, providing parameter-level local location results for the graded alarm in step S5.

[0135] The calculation of the contribution weights of each process parameter to the SPE statistic is based on residual decomposition: the SPE statistic is defined as the squared L² norm of the projection of the current multivariate functional observation into the residual subspace of the mfPCA model. This residual vector is decomposed according to the process parameter dimension. The ratio of the residual component of the j-th process parameter to the squared L² norm of the total residual is the SPE contribution weight w_j of that parameter (where the sum of the contribution weights of all parameters equals 1). When the SPE statistic exceeds the control limit, parameters are sorted from high to low according to their contribution weight w_j. Parameters whose contribution weight exceeds the uniform baseline value (i.e., 1 / p, where p is the number of parameters in the domain) by more than 1.5 times are typically marked as candidates for local morphological anomalies. This threshold selection is empirically effective in distinguishing between true local morphological anomalies and normal parameter noise fluctuations. Taking a typical scenario in the glue-making process of engineered wood panels as an example: if the contribution weight of the glue concentration parameter is significantly higher than other parameters when the SPE exceeds the limit, the stability of the raw material supply system should be investigated first; if the contribution weight of the reaction temperature is the highest, the working status of the cooling system should be investigated. Parameter-level localization achieved by ranking by contribution weights allows maintenance personnel to focus directly on the most likely source of the anomaly without having to check all process parameters one by one, significantly shortening the fault location time.

[0136] S4.5.4: Measure the end-to-end transmission delay and sampling interval offset between each node to obtain the timeliness assessment results.

[0137] The domain quality monitoring agent measures the transmission delay of process parameters between adjacent acquisition nodes within the domain: it calculates the delay of each transmission segment (data acquisition end → security bridge end, security bridge end → network transmission end, network transmission end → client receiving end) based on the difference in timestamps of data packets at each node, and summarizes them into a total end-to-end transmission delay value; simultaneously, it measures the sampling interval offset (the difference between the actual sampling interval and the configured sampling period) when each node receives data, identifying sampling timing instability issues caused by network jitter or system load fluctuations. The end-to-end transmission delay value and the sampling interval offset value are combined to form a timeliness assessment result, and the timeliness component is written into the BQI vector of the current domain.

[0138] S4.5.5: Aggregate the integrity assessment results, the systematic functional anomaly determination results, and the timeliness assessment results into the block-level quality index of the domain.

[0139] The integrity assessment results (tag arrival rate, gap duration, number of consecutive losses) obtained in step S4.5.1, the function accuracy assessment results (ratio of T² statistic to control limit, ratio of SPE statistic to control limit, ranking of outlier parameter contribution weights) obtained in steps S4.5.2 and S4.5.3, and the timeliness assessment results (end-to-end transmission delay, sampling interval offset) obtained in step S4.5.4 are aggregated according to a predefined BQI structure format to form the block-level quality index (BQI) for the current assessment period of the monitoring domain. The BQI is written to the quality monitoring buffer of each domain in real time with timestamp as the key, for reading and use by the Bayesian aggregation engine in step S4.6 of Example 4.

[0140] Example 6

[0141] like Figure 5 As shown, this embodiment, based on embodiment 1, provides a detailed explanation of the specific implementation of step S5, which involves hierarchical early warning, alarm push, and creation of processing work orders based on the global quality diagnostic report. This includes the following sub-steps:

[0142] S5.1: When the tag interruption or loss rate exceeds the threshold, a Level 1 alarm is generated based on the session anomaly event reported by the associated security bridging layer.

[0143] The tiered early warning engine continuously monitors the integrity assessment components in each monitoring domain's BQI. When a tag is completely interrupted (continuous missing duration exceeds a set threshold, such as continuous missing for more than 30 seconds) or the tag loss rate exceeds a set threshold (such as packet loss rate exceeding 5% within a 5-minute window), a Level 1 alarm is triggered. When a Level 1 alarm is generated, it is synchronously associated with the session event logs of the security bridging layer, performing correlation analysis between integrity anomalies and session layer events: if it is associated with a session anomaly event recorded by the security bridging layer (such as TLS handshake failure due to certificate expiration, or forced session termination due to unexpected SessionId reuse), the alarm type is marked as "data interruption caused by a security event"; if there are no anomaly event records in the security bridging layer, the alarm type is marked as "data interruption caused by a network failure." This automatically distinguishes between network failures and security events at the alarm stage, providing operations personnel with precise directions for fault handling.

[0144] It should be noted that the threshold for determining complete label interruption (e.g., continuous absence exceeding 30 seconds) and the threshold for label loss rate (e.g., a loss rate exceeding 5% within a 5-minute window) should be calibrated according to the specific process response time requirements: for parameters requiring high real-time monitoring, such as reaction temperature on the adhesive side, the interruption threshold can be appropriately shortened (e.g., 15 seconds); for quality parameters with relatively slow responses, such as moisture content of the output material on the drying side, the threshold can be appropriately relaxed (e.g., 60 seconds). The threshold parameters are stored in the system configuration file and can be set separately by monitoring domain and parameter label. They can be flexibly adjusted without modifying the core logic code to adapt to the differentiated requirements for data timeliness in different process scenarios.

[0145] S5.2: When the end-to-end transmission delay exceeds the process tolerance limit, a secondary alarm is generated by locating the monitoring domain where the delay is located in conjunction with the abnormal tracing path.

[0146] The hierarchical early warning engine continuously monitors the timeliness assessment components in the BQI of each monitoring domain. When the end-to-end transmission delay of any monitoring domain exceeds the tolerance limit set according to the process response time requirements, a secondary alarm is triggered. When the secondary alarm is generated, it combines the anomaly tracing path output in step S4.6 of embodiment 4 to locate which monitoring domain and which transmission segment the transmission delay mainly occurs in (e.g., "Transmission domain: Security bridge end → Network transmission end segment delay exceeds limit"). The monitoring domain identifier and the corresponding transmission segment information are attached to the alarm content to help network operation and maintenance personnel quickly locate the source of the delay and avoid inefficient segment-by-segment troubleshooting across the entire link.

[0147] S5.3: When the multivariate squared prediction error statistic exceeds the control limit while the multivariate Hotelling statistic is normal, a level 3 alert of the attention level is generated.

[0148] When the SPE statistic in the BQI of any monitoring domain exceeds the control limit while the T² statistic remains within the control limit, it is determined to be a local morphological anomaly: the overall functional evolution trend of the monitoring domain is still within the normal reference range, but the curve shape of individual process parameters within the domain shows local deviations. This situation triggers the "Attention" sub-level alarm in the three-level alarm system. The alarm content includes the identifier of the abnormal parameter with the highest contribution weight and the extent to which the SPE statistic exceeds the control limit, prompting the operator to pay attention to the abnormal change of this parameter for subsequent trend tracking, without the need for immediate emergency intervention.

[0149] S5.4: When the multivariate Hotelling statistic exceeds the control limit, a Level 3 warning is generated.

[0150] When the T² statistic in the BQI of any monitoring domain exceeds the control limit, regardless of whether the SPE statistic also exceeds the limit, it is determined to be a systemic functional anomaly for the entire domain. When only T² exceeds the control limit, a "Warning" sub-level alarm is triggered, indicating a systemic overall deviation trend in the multi-parameter joint functional curve shape within the monitoring domain; the operator should promptly check the relevant procedures. When both T² and SPE significantly exceed the control limits, a "Severe" sub-level alarm is triggered, indicating a global composite anomaly in the monitoring domain, requiring immediate activation of emergency response procedures. This refined classification of alarm sub-levels allows operators to prioritize based on the severity of the anomaly and allocate response resources accordingly.

[0151] It is worth noting that the triggering conditions for the "Critical" sub-level (both T² and SPE significantly exceed the control limits) and the "Warning" sub-level (only T² exceeds the control limits) in the three-level alarm system are fundamentally different in terms of the semantics of the monitoring domain state: "Warning" indicates that the overall evolution trend of the monitoring domain has deviated, but the degree of deviation is still within the description range of the mfPCA residual model, that is, the abnormal pattern is similar to the normal deviation pattern seen in the past; "Critical" indicates that the abnormal pattern has exceeded the historical experience range of the mfPCA model, and both the trend level (T² exceeding the limit) and the residual level (SPE exceeding the limit) are abnormal at the same time, which usually means that a new type of composite anomaly has occurred that has never appeared in history, and emergency response procedures need to be initiated immediately. This judgment logic enables operators to accurately identify the highest priority events with limited resources, avoid operators ignoring alarm information due to frequent low-level alarms (i.e., the phenomenon of "alarm fatigue"), and improve the overall alarm response efficiency.

[0152] S5.5: Based on the alarm level and monitoring domain identifier, push the alarm to the corresponding operation terminal and audible and visual alarm device, and create a processing work order in the work order system that includes alarm type, associated monitoring domain, abnormal parameters and statistical deviation.

[0153] Based on the alarm level (Level 1 / Level 2 / Level 3 - Attention / Level 3 - Warning / Level 3 - Critical) and the monitoring domain identifier (Glue-making domain / Transfer domain / Drying domain), the alarm content is pushed to the corresponding responsible position's operation terminal interface (WinCC HMI alarm screen) and physical audible and visual alarm devices. The "Critical" sub-level alarm simultaneously triggers the highest priority audible and visual alarm. Simultaneously, a processing work order is automatically created in the work order management system. The work order content includes: alarm type and alarm level, associated monitoring domain identifier, list of abnormal parameter identifiers, deviation values ​​of each statistical quantity relative to the control limits, Bayesian source path inference results, and alarm generation timestamp, providing structured fault handling guidance for maintenance personnel or process engineers, reducing fault location time.

[0154] Example 7

[0155] This embodiment, based on embodiment 1, provides a detailed explanation of the specific implementation of step S5, which involves performing dual-track archiving to update the exception case library and the multivariate function-type principal component analysis model when the work order is closed. The steps include:

[0156] Step A: Record the handling measures and recovery time when the work order is closed.

[0157] The closed-loop tracking module continuously monitors the status flow of each processed work order in the work order management system. When the work order status changes to "closed," the system automatically triggers the work order closure hook, extracting and structuredly storing the following information from the work order record: the operator or engineer identifier, a description of the specific handling measures (a combination of free text and standardized handling codes), a fault recovery timestamp, and the fault duration (the time difference from the alarm occurrence time to the work order closure time). This information serves as the basic metadata for subsequent dual-track archiving and is stored in association with the alarm event record and anomaly curve segment corresponding to the work order.

[0158] Step B: For curve segments in work orders that are confirmed as genuine process anomalies, label the anomaly type and root cause, and then store them in the anomaly case library.

[0159] When closing a work order, the processing personnel must confirm and determine the nature of the anomaly. For work orders confirmed as genuine process anomalies (not false alarms), the system automatically extracts time-series curve segments of process parameters for each associated monitoring domain within the alarm occurrence period from the quality traceability chain records. The anomaly type entered in the work order (such as "systematic drift in reaction temperature," "sudden change in glue concentration," etc.) and root cause analysis conclusions (such as "insufficient cooling water flow," "raw material batch change," etc.) are used as structured annotation information and stored together with the Bayesian source path inference results and the time-series change curve of the T² / SPE statistic in the anomaly case library. The anomaly case library supports multi-dimensional searching by anomaly type, associated parameters, monitoring domain, time period, etc., and provides a similar anomaly curve pattern matching function. When similar parameter curves appear in subsequent production processes, the system can automatically match historical cases and recommend handling solutions to assist operators in responding quickly.

[0160] Regarding the use of the abnormal case library, the similar abnormal curve pattern matching function is implemented based on the following technology: The process parameter time-series curve segment of each abnormal case in the case library is also expanded into a function-type representation using B-splines, and the corresponding principal component score vector is extracted as the case feature vector. When a new SPE (Short-Terminal Physical Exceedance) event occurs, the principal component score vector of the process parameter curve segment in the current time window is also extracted. The nearest neighbor case is retrieved in the case library feature vector space using cosine similarity or Mahalanobis distance, and the historical case with the highest similarity and its corresponding handling plan are returned. This method uses the mfPCA basis function expansion space as a unified metric space for case comparison, enabling quantitative comparison of abnormal curve shapes under different production periods and process states in a unified coordinate system, improving the accuracy of similar case matching. As the case library continues to accumulate, the coverage and accuracy of the recommended solutions will continue to improve.

[0161] Step C: Only when there is a planned change in the process formulation or equipment and the new operating condition data is confirmed to be in a new normal state, re-estimate the basis function expansion parameters and control limits of the multivariate principal component analysis model for the corresponding monitoring domain using the new operating condition data.

[0162] The update of the control limits of the mfPCA model is subject to a strict gating mechanism, allowing updates only when both of the following conditions are met simultaneously: First, the change must be a planned change (such as introducing a new adhesive type, changing the model of drying equipment, upgrading the process formulation, etc.), and the change event must have been pre-registered in the production management system; second, the new operating condition data after the change must be manually confirmed by a process engineer with the appropriate permissions to be a new normal operating state, rather than a persistent anomaly or transitional state. Once both conditions are met, the system re-estimates the joint covariance operator eigenvalue parameters, principal component basis functions, score vector distribution parameters, and T² / SPE control limits of the corresponding monitoring domain mfPCA model using continuous normal operating data under the new condition (it is recommended to collect at least 7 days of steady-state operating data). The system then completes the model update and records the new model version number and update timestamp. This strict gating mechanism ensures that the anomaly detection model does not experience control limit degradation due to abnormal operating condition data being mistakenly included in training as normal data, thus guaranteeing that the model does not experience missed detections during continuous optimization.

[0163] The technical principle behind the mfPCA model update is as follows: Under normal production conditions, the evolution trajectory of process parameters is constrained by factors such as process formulation, equipment characteristics, and environmental conditions, presenting a relatively stable normal operating condition probability distribution in the parameter space. When a planned upgrade of the process formulation or a planned replacement of key equipment occurs, the new operating conditions cause a systematic shift in the normal evolution trajectory of process parameters. The principal component basis functions and control limits of the original mfPCA model are no longer applicable to describing the new normal operating condition distribution. If the model is not updated, the system will continuously generate false alarms for the normal parameter curve shape under the new operating conditions, seriously affecting the reliability of alarms. Conversely, if the model control limits are arbitrarily updated after each process disturbance, the actual process drift anomalies may be incorrectly included in the normal range through model "adaptation," leading to a degradation in detection sensitivity (i.e., control limit degradation problem). The strict gating logic in the dual-track archiving mechanism is designed to solve the above dilemma: by strictly separating planned change data from unplanned abnormal data in the data flow, it allows the system to update in a timely manner after legal operating condition changes to maintain detection accuracy, while ensuring that the model does not degrade due to the infiltration of abnormal data, thus achieving the technical goal of "continuous optimization without degradation" of the anomaly detection model.

[0164] Step D: Associate the work order processing progress, exception cases, and model update version number with the quality traceability chain records.

[0165] The entire lifecycle processing record of the work order (timestamps and operator information for each stage of creation, processing, and closure), the case number stored in the exception case database for step B, and the MFPCA model update version number triggered by step C are all uniformly linked and written into the quality traceability chain record in the time-series database, with the alarm event ID as the primary key to establish a related index. The quality traceability chain record supports traceability queries by product batch, production period, or related process, forming a complete and auditable closed-loop record from alarm triggering → work order processing → dual-track archiving, providing a structured data evidence chain for factory quality management system audits and continuous process improvement analysis.

[0166] Example 8

[0167] like Figure 6 As shown, this embodiment, based on embodiment 1, provides a detailed explanation of the specific implementation of step S3, which involves time alignment of upstream and downstream data, obtaining a joint dataset, and displaying it in a linked manner on the monitoring interface. This includes the following sub-steps:

[0168] S3.1: Create a subscription session in read-only mode on the target industrial control system side, and configure the heartbeat interval, exponential backoff reconnection strategy and maximum retention time of cached data.

[0169] An OPC UA client is deployed on the WinCC industrial control system side in the drying workshop. After passing the full-process compliance verification of the security bridging layer in Example 2, a CreateSession request is initiated to the OPC UA publishing server in read-only mode. At the protocol level, it is explicitly stated that the client only has subscription permissions and no write permissions, thus isolating the risk of write operations on the process parameters of the source industrial control system from the perspective of session permissions. After the session is established, the client is configured with the following reliability parameters: heartbeat interval (KeepAlive period, such as sending a heartbeat message every 10 seconds to maintain session activity, with a timeout threshold of 30 seconds); exponential backoff reconnection strategy (initial reconnection waiting time is 5 seconds, and the waiting time increases by a power of 2 after each reconnection failure, with a maximum waiting time limit of 300 seconds to prevent a connection storm caused by a large number of clients reconnecting simultaneously when the network is interrupted); maximum retention time of cached data (the maximum time that the client's local memory buffer stores accumulated data during the disconnection, such as 120 seconds, and historical data exceeding the retention time is automatically discarded according to the first-in-first-out principle) to ensure that critical process parameter data is not lost when the communication link is interrupted.

[0170] The technical significance of the exponential backoff reconnection strategy lies in the following: In manufacturing environments, after a brief interruption of the industrial control network (such as a switch restart or fiber optic cable jitter), a large number of client devices often attempt to reconnect almost simultaneously. If all clients initiate reconnection requests at the same time, the OPC UA server will be subjected to a concentrated connection storm the moment the network recovers, potentially causing server overload and prolonging the overall recovery time. The exponential backoff strategy, by introducing a randomized, incremental waiting time for each client, distributes the concentrated reconnection requests along the timeline, avoiding a reconnection storm. Simultaneously, setting a maximum waiting time limit (e.g., 300 seconds) ensures that even after multiple reconnection failures, the client can eventually complete the reconnection within an acceptable timeframe, preventing it from becoming permanently offline due to indefinitely increasing waiting times. This balances the needs for both system stability and rapid recovery after a failure.

[0171] S3.2: Interpolate and synchronize the timestamps of the upstream data and the local data, perform dimensional verification and outlier filtering to obtain the time-aligned joint dataset.

[0172] The data acquisition cycles of the source control system (InTouch) and the target control system (WinCC) may differ (e.g., the sampling cycle on the adhesive preparation side is 1 second, and the sampling cycle on the drying side is 2 seconds), and there may be slight deviations in the clocks of the two systems. The data preprocessing module performs the following processing on the upstream adhesive preparation process parameters and local drying process parameters received from the subscription: timestamp interpolation synchronization, using linear interpolation or piecewise cubic spline interpolation to resample the upstream data to a time reference grid consistent with the drying side, eliminating timing misalignment caused by sampling cycle differences; dimensional verification, comparing the dimensional attributes of each OPC UA node in the standardized label set to verify whether the physical units of the received data are consistent with expectations, recording warnings and filtering out data with inconsistent dimensions; outlier filtering, using static boundary checks based on historical quantile ranges and dynamic jump detection based on first-order difference Z-scores to mark and remove values ​​that exceed reasonable physical ranges or experience sudden jumps. After the above processing, a joint dataset with timestamp alignment, unified dimensions, and filtered outliers is obtained.

[0173] Regarding timestamp interpolation synchronization, the selection criteria for the linear interpolation and piecewise cubic spline interpolation methods are as follows: Linear interpolation has low computational complexity and is suitable for scenarios with small differences in sampling periods (such as the difference between 1 second on the glue-making side and 2 seconds on the drying side) and relatively gentle parameter changes; piecewise cubic spline interpolation can provide smoother interpolation results that are closer to the actual physical process when there are significant bending changes in parameters (such as the nonlinear change in glue viscosity during the stirring stage), but its computational complexity is slightly higher. The system supports configuring interpolation methods according to parameter type, using linear interpolation for slowly changing process state quantities (such as reaction temperature) and cubic spline interpolation for process parameters with obvious dynamic characteristics (such as glue viscosity) to achieve a balance between computational efficiency and interpolation accuracy.

[0174] The static boundary check based on historical quantile range statistically analyzes the [0.5%, 99.5%] quantile range of each parameter in historical data under normal operating conditions, marking data values ​​exceeding this range as suspected physical boundary anomalies. The dynamic jump detection based on first-order difference Z-score calculates the Z-score of the difference value sequence between adjacent sampling points, marking data points with an absolute first-order difference exceeding three times the standard deviation of the mean as suspected abrupt changes. The two detection methods are complementary: the static boundary check can capture over-range output caused by sensor malfunctions, while the dynamic jump detection can capture sudden steps in the sensor signal (such as zeroing or saturation after a sensor disconnection). Data points marked as anomalous are removed before participating in time alignment to prevent single-point outliers from affecting the reliability of adjacent normal data points through interpolation, thus ensuring the overall quality of the joint dataset.

[0175] S3.3: The joint dataset is presented side by side with the upstream process parameters and the local process parameters through the cross-process monitoring screen component embedded in the local human-machine interface, and trend curve overlay and historical backtracking are supported.

[0176] A cross-process monitoring component is embedded in the WinCC HMI of the drying workshop. This component reads real-time and historical data from the local federated dataset buffer via the OPC DA / OPC UA standard interface for screen rendering. The monitoring screen layout presents the upstream glue preparation process parameters (displaying real-time values ​​and recent historical trend curves of parameters such as glue concentration, reaction temperature, and glue viscosity) and the local drying process parameters (displaying parameters such as hot air temperature, exhaust damper opening, feed rate, and discharge moisture content) side by side on the same screen. The component supports trend curve overlay functionality, for example, overlaying the upstream glue concentration trend curve onto the local hot air temperature trend axis to intuitively present the coordinated changes of upstream and downstream related parameters. The component also supports historical backtracking functionality, allowing operators to select any historical time period to replay and export the combined historical trajectory of upstream and downstream process parameters. The aforementioned cross-process linkage monitoring interface allows drying workshop operators to monitor the status of upstream adhesive preparation processes in real time without switching to other systems. For example, when the adhesive concentration is abnormally high, the operator can directly sense and adjust the drying hot air temperature in advance on the WinCC interface in the drying workshop to avoid over-drying.

[0177] Example 9

[0178] This embodiment adds the following steps after step S4.6, based on embodiment 4:

[0179] The three-dimensional quality index, Bayesian source tracing path, and functional anomaly detection results of each monitoring domain are persistently written into the time series database, supporting quality trend backtracking queries by monitoring domain, by parameter, and by time period, and generating quality traceability chain records.

[0180] After the BQI calculations for each monitoring domain and the Bayesian aggregation source inference are completed, the following data will be persistently written to a time-series database (such as InfluxDB or TimescaleDB) in time-series format: three-dimensional quality indices for each domain of the adhesive preparation, transport, and drying domains (integrity component – ​​including label arrival rate, missing duration, and number of consecutive losses; function accuracy component – ​​including T² statistic value and its ratio to control limits, SPE statistic value and its ratio to control limits, and SPE contribution weight of each parameter; timeliness component – ​​including end-to-end transmission delay and sampling interval offset); Bayesian aggregation source inference results (posterior probability values ​​and inference confidence for each domain as the fault origin domain); and detailed results of function-type anomaly detection (B-spline basis function expansion coefficients, principal component score vectors, and mfPCA model residual curves for each process parameter within the current time window). The time-series database establishes a multi-dimensional combined index for the above data, based on monitoring domain identifiers, process parameter tags, and time periods. It supports the following typical query scenarios: querying the historical evolution trend of the three-dimensional quality index for a specific monitoring domain within a specified time period; querying the change in the SPE contribution weight of a specific process parameter (such as reaction temperature) over time to trace the timing of parameter performance degradation; and querying the overall quality status of the same batch during its production process by product batch association. All persistent records, linked by alarm event ID and batch number, form a quality traceability chain record that runs through the entire process of data acquisition, quality assessment, anomaly alarms, and work order processing, together with the work order processing records and dual-track archiving results in step D of Example 7. This provides a complete data evidence chain for factory quality management system audits and continuous process improvement.

[0181] Regarding the indexing strategy design for time-series databases, the specific implementation of the multi-dimensional composite index includes: using the monitoring domain identifier (adhesive manufacturing domain / transfer domain / drying domain) as the partition key and the timestamp as the sort key; storing time-series data within the monitoring domain in physical contiguous order to ensure sequential I / O efficiency when querying by domain and time period; using process parameter tags as secondary indexes to support single-parameter historical performance queries across time periods; and using alarm event IDs and product batch numbers as foreign keys to support event-related queries for traceability scenarios. This multi-dimensional index design ensures that even with a large volume of records, typical quality trend queries (such as "querying the historical evolution of T² statistics in the adhesive manufacturing domain over the past 7 days") can still be completed within seconds, meeting the dual needs of real-time monitoring and historical analysis on the production site.

[0182] The complete data structure of the quality traceability chain records uses the alarm event ID as the primary key, associating the following data objects: original alarm event records (alarm type, alarm level, trigger time, associated monitoring domain, list of abnormal parameters, T² / SPE statistic deviation); Bayesian source inference results (posterior probability of each domain as the fault origin domain, inference confidence, and anomaly propagation path chain); the entire lifecycle record of processing work orders (timestamps and operator identifiers for each stage of work order creation, processing, and closure); a dual-track archiving result index (case number in the anomaly case library, or mfPCA model update version number); and product batch number (obtained through the production management system, linking quality events with the final quality report of the corresponding batch of products). This structured traceability chain design enables factory quality engineers to quickly locate all quality events occurring during the production process using the product batch number when facing product quality issues. Combined with the process parameter curves and handling records at the time, a complete chain of quality certification documents is formed, meeting the audit requirements of the quality management system.

[0183] Example 10

[0184] like Figure 1 As shown, this embodiment provides a cross-heterogeneous industrial control platform process collaboration device, including:

[0185] The standardized publishing module is used on the source industrial control system side to remap the original process parameter tags to standard OPC UA nodes according to a unified naming convention, forming a standardized tag set. Using the unified naming convention of "Workshop.Process.Parameter.Unit", the standardized publishing module maps the original process parameter tags (such as glue concentration, stirring time, reaction temperature, glue viscosity, etc.) in the local database of industrial control systems such as InTouch in the glue-making workshop one by one to nodes with standard OPC UA information model semantics, forming a standardized tag set that can be recognized and accessed by any OPC UA client. The OPC UA publishing server submodule is responsible for external publishing and node management.

[0186] The security bridging module is used to construct a multi-layer security policy based on the standardized tag set, including two-way certificate authentication, encrypted channels, firewall isolation, and UA protocol-aware application layer security bridging. The UA protocol-aware application layer security bridging parses request messages and performs session compliance verification during the secure channel establishment phase, and outputs a standardized data stream after security bridging verification. The security bridging module implements a four-layer protection mechanism: the first layer, the X.509 certificate two-way authentication submodule, is responsible for verifying the identity of both communicating parties using the certificate chain; the second layer, the TLS end-to-end encrypted channel submodule, is responsible for encrypting OPC UA session data throughout the process; the third layer, the industrial firewall configuration submodule, is responsible for IP whitelist management and dedicated opening of OPC UA port 4840; the fourth layer, the UA protocol-aware application layer security bridging submodule, parses security policy fields and certificate chains during the OpenSecureChannel phase, verifies the UserIdentityToken whitelist and session policy parameters during the CreateSession and ActivateSession phases, continuously monitors KeepAlive messages and SessionId reuse during session duration, triggers forced session termination and forced re-authentication when an anomaly is detected, and supports configuring differentiated access control policies such as full read or restricted subscription for different clients based on the tag security level.

[0187] The subscription linkage module is used on the target industrial control system side to subscribe to the relevant tag subset of the standardized data stream after the application layer security bridging verification, to perform time alignment of upstream and downstream data, obtain a joint dataset, and display it in a linked manner on the monitoring interface. The subscription linkage module includes an OPC UA read-only client submodule (establishing a subscription session in read-only mode on the WinCC side of the drying workshop, configuring reliability parameters such as heartbeat interval, exponential backoff reconnection strategy, and local buffer cache retention time), a data preprocessing submodule (performing interpolation synchronization, dimensional verification, and outlier filtering on the timestamps of upstream and local data to complete cross-process data time alignment), and a cross-process monitoring screen component submodule (embedding WinCC HMI to display upstream glue-making process parameters and local drying process parameters side by side in the same screen, supporting real-time trend curve overlay and historical backtracking query).

[0188] The quality monitoring module is used to construct a process variable dependency graph based on the causal dependency relationship of the process flow and decompose it into multiple monitoring domains. Within each monitoring domain, a block-level quality index is calculated using multivariate principal component analysis. Then, a Bayesian network is used to perform probabilistic fusion of all the block-level quality indices to obtain a global quality diagnosis report and anomaly tracing path. The quality monitoring module includes a process variable dependency graph construction submodule (constructing a dependency graph with key process parameters of each process as nodes and physical causal relationships as directed edges, and dividing variables into three monitoring domains: glue-making domain, transmission domain, and drying domain through graph decomposition), a domain quality monitoring agent submodule (deployed independently in each monitoring domain, collecting data snapshots of all variables in the domain at four nodes: data acquisition end, security bridging end, network transmission end, and client receiving end, performing integrity assessment, joint modeling with multivariate B-spline basis functions, and performing function accuracy assessment and timeliness assessment using mfPCA T² / SPE statistics, and aggregating and outputting the block-level quality index BQI), and a Bayesian aggregation engine submodule (constructing a Bayesian network with the causal edge directions of the monitoring domain as priors, performing probabilistic fusion of BQI in each domain to infer the fault origin domain, and outputting a global quality diagnosis report and anomaly tracing path).

[0189] The early warning closed-loop module is used to perform hierarchical early warning based on the global quality diagnosis report, push alarms and create processing work orders, and perform dual-track archiving to update the abnormal case library and the multivariate function principal component analysis model when the work order is closed. The early warning closed-loop module includes a hierarchical early warning engine submodule (which classifies abnormal events into three levels based on the BQI three-dimensional assessment results: Level 1 data interruption alarm, Level 2 transmission delay alarm, and Level 3 function-type morphological abnormality alarm, and further subdivides them into three sub-levels: "Attention", "Warning", and "Critical" according to the T² / SPE combination state), an alarm push and work order creation submodule (which pushes alarms to the corresponding operation terminal interface and audible and visual alarm devices according to the alarm level and monitoring domain identifier, and automatically creates structured processing work orders containing alarm type, associated monitoring domain, abnormal parameters, and statistical deviation), and a dual-track archiving submodule (which performs archiving along two independent paths when a work order is closed: one path marks the actual abnormal curve confirmed by the work order and stores it in the abnormal case library for diagnostic knowledge accumulation; the other path only triggers the update of the basis function expansion parameters and control limits of the corresponding monitoring domain mfPCA model after a planned process change and the new operating condition is confirmed by the engineer, and writes the work order progress, case number, and model version number into the quality traceability chain record to form a complete closed loop).

[0190] Furthermore, the data flow between the modules is as follows: The standardized tag set and OPC UA node data stream output by the standardized publishing module first enter the security bridging module for session compliance verification. After successful verification, the standardized data stream is simultaneously consumed by two downstream modules—the subscription linkage module consumes real-time process parameter data for HMI linkage display, and the quality monitoring module consumes real-time process parameter data and session event logs from the security bridging end for quality assessment calculation. The global quality diagnostic report and anomaly tracing path output by the quality monitoring module flow to the early warning closed-loop module, triggering the hierarchical alarm judgment and work order creation process; the dual-track archiving results (anomaly case library update and mfPCA model version update) output by the early warning closed-loop module are fed back to the quality monitoring module, ensuring that the mfPCA model is updated in a timely manner under planned change scenarios to maintain detection accuracy. Data flows between the above modules are transmitted asynchronously through internal message queues (such as memory message queues in the producer-consumer pattern), avoiding the impact of the computational load of the quality monitoring module on the real-time session processing performance of the security bridging module, ensuring the low-latency response capability of the overall system, and realizing the decoupled parallel operation of the four functional domains of data acquisition, security protection, quality monitoring and early warning closed loop.

Claims

1. A method for process collaboration across heterogeneous industrial control platforms, characterized in that, include: On the source industrial control system side, the original process parameter labels are remapped to standard OPC UA nodes according to a unified naming convention to form a standardized label set; Based on the standardized tag set, a multi-layer security policy is constructed, which includes two-way certificate authentication, encrypted channel, firewall isolation and UA protocol-aware application layer security bridging. The UA protocol-aware application layer security bridging parses request messages and performs session compliance verification during the security channel establishment phase, and outputs a standardized data stream after security bridging verification. On the target industrial control system side, after the application layer security bridging verification, the relevant tag subset of the standardized data stream is subscribed to, the upstream and downstream data are time-aligned, a joint dataset is obtained, and the data is displayed in a linked manner on the monitoring interface. Based on the causal dependencies of the process flow, a process variable dependency graph is constructed and decomposed into multiple monitoring domains. Within each monitoring domain, a block-level quality index is calculated using multivariate principal component analysis. Then, a Bayesian network is used to perform probabilistic fusion of all the block-level quality indices to obtain a global quality diagnosis report and anomaly tracing path. Based on the global quality diagnostic report, tiered early warnings are issued, alarms are pushed, and processing work orders are created. When the work order is closed, dual-track archiving is performed to update the abnormal case library and the multivariate function principal component analysis model.

2. The method according to claim 1, characterized in that, The UA protocol-aware application layer security bridging parses request messages and performs session compliance verification during the security channel establishment phase, outputting a standardized data stream after security bridging verification, including: During the window period between the client sending a request to establish a secure channel and before creating a session, the security policy and certificate chain in the request to establish a secure channel are parsed and compared with the security policy template of the publishing server. Perform whitelist verification and session policy parameter validation on the user identity token in the session creation request and session activation request, and reject session requests that do not comply with the security policy; Configure differentiated access policies based on the security level of the tags; Continuously monitor heartbeat messages and session identifier reuse of active sessions during session duration; When a session anomaly is detected, session termination and forced re-authentication are triggered, and the tag data is published to the outside world in a publish-subscribe mode, outputting a standardized data stream after security bridging verification.

3. The method according to claim 2, characterized in that, The session policy parameter verification supports configuring differentiated access policies based on the security level of the tag, including: configuring a full read policy for the reaction temperature tag, and configuring a policy that only allows specified clients to subscribe at a specified sampling frequency for the formula concentration tag.

4. The method according to claim 1, characterized in that, Based on the causal dependencies in the process flow, a process variable dependency graph is constructed and decomposed into multiple monitoring domains. Within each monitoring domain, a block-level quality index is calculated using multivariate principal component analysis. Then, a Bayesian network is used to probabilistically fuse all the block-level quality indices to obtain a global quality diagnosis report and anomaly tracing paths, including: A process variable dependency graph is constructed using key process parameters of each process as nodes and physical causal relationships between variables as edges. Based on the structure of the process variable dependency graph, graph decomposition is performed to divide the variables into the glue-making domain, the transport domain, and the drying domain. Deploy domain quality monitoring agents within each of the aforementioned monitoring domains to receive data snapshots of all variables in the domain at the data acquisition end, security bridging end, network transmission end, and client receiving end; The sampling sequence of all process parameters in the domain within the time window is jointly fitted into a set of multivariate B-spline basis functions, and then projected into the basis function expansion space onto the multivariate function principal component analysis model trained under normal operating conditions of the domain. Calculate the multivariate Hotelling statistic and the multivariate squared prediction error statistic to obtain the block-level quality index of the domain. A Bayesian network is constructed using the causal edge directions in the graph decomposition as priors. The quality index of the parent domain is used as the input of the conditional probability of the quality index of the child domain. The fault origin domain is inferred in reverse along the causal edges to obtain the global quality diagnosis report and the anomaly tracing path.

5. The method according to claim 4, characterized in that, The calculation of the multivariate Hotelling statistic and the multivariate squared prediction error statistic to obtain the block-level quality index of the domain includes: By comparing the tag arrival rate node by node, and statistically analyzing the gap duration and the number of consecutive losses, the integrity assessment results are obtained. When the multivariate Hotelling statistic exceeds the control limit, it is determined that a systematic functional anomaly has occurred in the domain. When the multivariate squared prediction error statistic exceeds the control limit, the parameter with the highest contribution weight is analyzed to locate the source of local morphological anomalies. The end-to-end transmission delay and sampling interval offset between each node are measured to obtain the timeliness assessment results. The integrity assessment results, the systematic functional anomaly determination results, and the timeliness assessment results are aggregated into the block-level quality index of the domain.

6. The method according to claim 1, characterized in that, Based on the global quality diagnostic report, tiered early warnings are issued, alerts are pushed out, and processing work orders are created, including: When the tag interruption or loss rate exceeds the threshold, a Level 1 alarm is generated by the associated security bridging layer reporting session anomaly events; When the end-to-end transmission delay exceeds the process tolerance limit, a secondary alarm is generated by locating the monitoring domain where the delay is located in conjunction with the abnormal tracing path. When the multivariate squared prediction error statistic exceeds the control limit while the multivariate Hotelling statistic is within the normal range, a level 3 alert with attention level is generated. When the multivariate Hotling statistic exceeds the control limit, a Level 3 warning is generated. Based on the alarm level and monitoring domain identifier, the alarm is pushed to the corresponding operating terminal and audible and visual alarm device, and a processing work order is created in the work order system, which includes the alarm type, associated monitoring domain, abnormal parameters and statistical deviation.

7. The method according to claim 1, characterized in that, The step of performing dual-track archiving to update the exception case library and the multivariate function-type principal component analysis model when the work order is closed includes: Record the handling measures and recovery time when the work order is closed; For curve segments that are confirmed as genuine process anomalies in work orders, the anomaly type and root cause are labeled and stored in the anomaly case library. Only when there is a planned change in the process formulation or equipment and the new operating condition data is confirmed to be in a new normal state, the basis function expansion parameters and control limits of the multivariate principal component analysis model for the corresponding monitoring domain are re-estimated using the new operating condition data; Link work order processing progress, exception cases, and model update version numbers with the quality traceability chain records.

8. The method according to claim 1, characterized in that, The process of aligning upstream and downstream data by time to obtain a joint dataset and displaying it in a linked manner on the monitoring interface includes: Create a subscription session in read-only mode on the target industrial control system side, and configure the heartbeat interval, exponential backoff reconnection strategy and maximum retention time of cached data; The timestamps of upstream data and local data are interpolated and synchronized, their units are checked, and outliers are filtered to obtain the time-aligned joint dataset. The joint dataset is used to display upstream process parameters and local process parameters side by side through a cross-process monitoring screen component embedded in the local human-machine interface, and supports trend curve overlay and historical backtracking.

9. The method according to claim 4, characterized in that, The three-dimensional quality index, Bayesian source tracing path, and functional anomaly detection results of each monitoring domain are persistently written into the time series database, supporting quality trend backtracking queries by monitoring domain, by parameter, and by time period, and generating quality traceability chain records.

10. A process collaboration device across heterogeneous industrial control platforms, characterized in that, include: The standardized release module is used to remap the original process parameter tags to standard OPC UA nodes according to a unified naming convention on the source industrial control system side, forming a standardized tag set; The security bridging module is used to construct a multi-layer security policy based on the standardized tag set, including two-way certificate authentication, encrypted channel, firewall isolation and UA protocol-aware application layer security bridging. The UA protocol-aware application layer security bridging parses request messages and performs session compliance verification during the security channel establishment phase, and outputs a standardized data stream after security bridging verification. The subscription linkage module is used to subscribe to the relevant tag subset of the standardized data stream on the target industrial control system side after the application layer security bridging verification, to perform time alignment of upstream and downstream data, obtain a joint dataset, and display it in linkage on the monitoring interface. The quality monitoring module is used to construct a process variable dependency graph based on the causal dependency relationship of the process flow and decompose it into multiple monitoring domains. Within each monitoring domain, the block-level quality index is calculated using multivariate principal component analysis, and all the block-level quality indices are probabilistically fused using a Bayesian network to obtain a global quality diagnosis report and anomaly tracing path. The early warning closed-loop module is used to perform hierarchical early warning based on the global quality diagnosis report, push alarms and create processing work orders, and perform dual-track archiving to update the abnormal case library and the multivariate function principal component analysis model when the work order is closed.

Images