An industrial process-oriented abnormality automatic recovery and event-driven linkage method

Abstract

The present disclosure provides an industrial process-oriented abnormality automatic recovery and event-driven linkage method, comprising: classifying and recording abnormality occurred in an industrial process, scanning unprocessed abnormality records in a preset period, the abnormality at least including one of device offline, device failure, no available device, call failure and production line alarm; for each abnormality record scanned, querying the current state of the corresponding device according to the abnormality type, and judging whether it meets the preset recovery condition corresponding to the abnormality type; in response to meeting the preset recovery condition, generating a recovery instruction based on the abnormality record, finding an execution instance waiting for the abnormality and sending an abnormality recovery signal; in response to listening to the abnormality recovery signal, executing the execution instance. The present disclosure automatically completes abnormality recovery by including each abnormality in life cycle management, associates abnormality recovery and process continuation with event signals, and realizes abnormality traceability and recovery automation.

Description

Technical Field

[0001] This disclosure relates to the field of industrial anomaly management and equipment linkage control, and more specifically to an automatic anomaly recovery and event-driven linkage method for industrial processes. Background Technology

[0002] In industrial production line control systems, anomaly handling and equipment linkage are crucial for ensuring system reliability. Existing solutions suffer from scattered anomaly information, lack of lifecycle management, reliance on manual intervention for process waiting, and a lack of linkage logic and read / write verification closed loops. This results in anomaly information being scattered in logs, making it difficult to perform structured queries and statistics, and hindering automatic recovery. It relies on maintenance personnel to monitor anomalies and manually recover, leading to slow response times and high costs. Summary of the Invention

[0003] In view of the above problems, this disclosure provides an automatic recovery and event-driven linkage method for industrial processes to improve recoverability and equipment coordination consistency in abnormal scenarios.

[0004] This disclosure provides a method for automatic anomaly recovery and event-driven linkage in industrial processes, comprising: classifying and recording anomalies occurring in the industrial process; scanning unprocessed anomaly records at a preset cycle, wherein the anomalies include at least one of the following: equipment offline, equipment failure, no available equipment, call failure, and production line alarm; for each scanned anomaly record, querying the current status of the corresponding equipment according to its anomaly type, and determining whether it meets the preset recovery conditions corresponding to that anomaly type; in response to meeting the preset recovery conditions, generating a recovery instruction based on the anomaly record, finding the execution instance waiting due to the anomaly and sending an anomaly recovery signal; and in response to listening to the anomaly recovery signal, executing the execution instance.

[0005] According to embodiments of this disclosure, the current status of the corresponding device is queried based on its anomaly type to determine whether it meets the preset recovery conditions corresponding to the anomaly type. This includes: in response to an anomaly type of device offline or device failure, determining whether to recover based on the working status signal of the corresponding device; in response to an anomaly type of no available device, determining whether to recover based on the availability of the same type of device; in response to an anomaly type of call failure, directly determining that the preset recovery conditions are met; and in response to an anomaly of production line alarm, determining whether to recover based on the production line status checklist and manual judgment. The production line status checklist is used to store the signal items corresponding to the production line.

[0006] According to embodiments of this disclosure, the process of determining whether a production line alarm has been resolved based on a production line status checklist and manual assessment includes: periodically reading the status value corresponding to each inspection item one by one according to a predefined production line status checklist; comparing each read status value with the predefined normal status of that inspection item; and determining that the production line alarm has been resolved once all comparison results for all inspection items are normal and manual confirmation is received. The production line status checklist includes at least the following inspection items: emergency stop status, safety protection status, equipment status, energy supply status, sensor status, and communication network status.

[0007] According to embodiments of this disclosure, generating a recovery instruction based on an anomaly record, finding an execution instance waiting due to the anomaly, and sending an anomaly recovery signal includes: parsing a suspended task identifier from the anomaly record; in response to the absence of an associated anomaly record for the task identifier, setting a recovery flag variable associated with the task identifier to true; and sending an anomaly recovery signal to the execution instance associated with the task identifier.

[0008] According to embodiments of this disclosure, in response to detecting an abnormal recovery signal, an execution instance is executed, including: reading the value of the target node as the target value; invoking a method of the target device to write control parameters based on the target value; reading back the value of the verification node as the verification value, and comparing the verification value with the target value; and executing the execution instance when the comparison result is consistent.

[0009] According to embodiments of this disclosure, the verification value is compared with the target value, and then the process further includes: if the verification value is inconsistent with the target value, a warning log is recorded and the current linkage verification is terminated without blocking the main process of initiating linkage control.

[0010] According to embodiments of this disclosure, a method for invoking a target device to write control parameters based on a target value includes: continuously writing multiple control parameters to the target device; in response to a successful write, polling and reading the target device's reception confirmation flag until the reading is successful or the maximum number of retries is reached; and in response to receiving a successful read confirmation flag, writing a reset flag to the target device to complete the handshake.

[0011] The second aspect of this disclosure provides an automatic anomaly recovery and event-driven linkage system for industrial processes, which can be used to implement the aforementioned automatic anomaly recovery and event-driven linkage method for industrial processes. The system includes: an anomaly recording module, used to classify and record anomalies occurring in the industrial process, and scan unprocessed anomaly records at a preset period, wherein the anomalies include at least one of equipment offline, equipment failure, no available equipment, call failure, and production line alarm; an anomaly recovery module, used to query the current status of the corresponding equipment for each scanned anomaly record based on its anomaly type, and determine whether it meets the preset recovery conditions corresponding to that anomaly type; a task recovery module, used to generate a recovery instruction based on the anomaly record in response to meeting the preset recovery conditions, locate the execution instance waiting due to the anomaly, and send an anomaly recovery signal; and an event-driven module, used to execute the execution instance in response to detecting the anomaly recovery signal.

[0012] A third aspect of this disclosure provides an electronic device comprising: one or more processors; and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to perform the above-described automatic recovery and event-driven linkage method for industrial processes.

[0013] A fourth aspect of this disclosure also provides a computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, cause the processor to perform the aforementioned automatic exception recovery and event-driven linkage method for industrial processes.

[0014] The automatic anomaly recovery and event-driven linkage method for industrial processes provided in this disclosure classifies and records anomalies, performs periodic scans, determines recovery conditions based on type, and automatically recovers the process. After recovery, an event-driven event wakes up suspended instances. Since the entire process requires no manual intervention, it at least partially solves the technical problems of manual recovery and the inability of suspended processes to automatically resume, achieving the technical effect of automatically recovering anomalies and restarting processes to improve production efficiency. Attached Figure Description

[0015] Figure 1 A flowchart illustrating an automatic anomaly recovery and event-driven linkage method for industrial processes according to an embodiment of the present disclosure is shown schematically.

[0016] Figure 2 This schematic diagram illustrates a structural block diagram of an automatic anomaly recovery and event-driven linkage system for industrial processes according to an embodiment of the present disclosure;

[0017] Figure 3 A block diagram of an electronic device suitable for implementing an automatic recovery from anomalies and an event-driven linkage method for industrial processes, according to an embodiment of the present disclosure, is shown schematically. Detailed Implementation

[0018] The embodiments of the present disclosure will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the disclosure. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of the present disclosure for ease of explanation. However, it will be apparent that one or more embodiments may be practiced without these specific details. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts of the present disclosure.

[0019] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. Terms such as include, comprise, etc., as used herein indicate the presence of the described features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0020] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0021] When using expressions such as at least one of A, B, and C, the expression should generally be interpreted in accordance with the meaning commonly understood by those skilled in the art (e.g., a system having at least one of A, B, and C should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B, and C, etc.).

[0022] In industrial production line control systems, anomaly handling and equipment coordination are crucial for ensuring system reliability. Existing solutions have the following shortcomings:

[0023] (1) Scattered abnormal information: Abnormal information such as equipment failure, communication failure, and platform error is scattered in log files, different tables in the database, and memory cache, lacking a unified abnormal classification and persistence mechanism. It is difficult to trace the cause, count the frequency, and analyze the trend after an abnormality occurs.

[0024] (2) Lack of lifecycle management: After an anomaly is recorded, there is a lack of status management (such as unresolved / resolved / confirmed), making it impossible to distinguish between anomalies that are being processed and those that have been resolved but have not yet been restored. After an anomaly is resolved (such as equipment repair), manual judgment and manual restoration of the process are required, resulting in low automation.

[0025] (3) Process waiting relies on manual intervention: When equipment malfunctions or is busy, the process enters a waiting state. Existing solutions mostly rely on manual monitoring and manual triggering of recovery (such as clicking the retry button). The lack of an automatic mechanism to detect, resolve and restore the process leads to long waiting times and high labor costs.

[0026] (4) Scattered linkage logic: The linkage between equipment (such as notifying the cutting machine to start after the loading machine arrives) is mostly hard-coded in the business code, lacking a unified event-driven framework. Modifying the linkage logic requires modifying the code, making maintenance difficult.

[0027] (5) Lack of read / write verification closed loop: In the linkage control, after writing parameters, the verification of whether they have taken effect is not read back, which may lead to the hidden danger that the writing is successful but the effect is not actually taken. There is no retry mechanism, and the system will give up after a single failure.

[0028] (6) Decoupling of exceptions and linkages: Exception handling and linkage control are implemented independently. After the exception is recovered, the linkage is not triggered to be re-executed, or the linkage fails and the exception is not recorded. The two lack coordination.

[0029] Figure 1 A flowchart illustrating an automatic anomaly recovery and event-driven linkage method for industrial processes according to an embodiment of this disclosure is shown, such as... Figure 1 As shown, embodiments of this disclosure provide an automatic recovery and event-driven linkage method for industrial processes, comprising: classifying and recording anomalies occurring in the industrial process; scanning unprocessed anomaly records at a preset cycle, wherein the anomalies include at least one of equipment offline, equipment failure, no available equipment, call failure, and production line alarm; for each scanned anomaly record, querying the current status of the corresponding equipment according to its anomaly type, and determining whether it meets the preset recovery conditions corresponding to the anomaly type; in response to meeting the preset recovery conditions, generating a recovery instruction based on the anomaly record, finding the execution instance waiting due to the anomaly, and sending an anomaly recovery signal; and in response to listening to the anomaly recovery signal, executing the execution instance.

[0030] Specifically, when the robot controller in the automotive welding production line reports that the equipment is offline, the system records the anomaly and suspends the automotive body welding execution instance. When the unprocessed record is detected, the system checks whether the robot communication signal has been restored. If it responds, a recovery command is generated and an anomaly recovery signal is sent to the welding instance. The monitoring module triggers the instance to continue the welding process without manual intervention to restart the process.

[0031] It should be noted that users can also check the anomaly recovery status in advance by selecting the anomaly record. A manual operation switch is provided: it supports pausing / resuming by process ID or locating instances by task ID; after pausing, signal processing and scheduling are blocked, only status subscription and anomaly entry are retained; suitable for manual intervention scenarios such as maintenance, tool change, and anomaly inventory.

[0032] Furthermore, priorities are set for each production line. For the highest priority production line, in response to the generation of an exception record and the exception type being device offline or device failure, an event subscription is set to subscribe to the working status signal of the corresponding device to determine whether to recover. In response to the exception type being call failure, an exception recovery signal is sent directly to improve the processing efficiency of high-priority production line failures.

[0033] Through the embodiments of this disclosure, equipment anomalies, platform anomalies, and production line alarms are classified and persisted. Unresolved anomalies are detected by a scheduled task and the current status of the equipment (Online status, Standby status) is queried. When the recovery conditions are met, the anomaly status is set to Resolved and the waiting process (the execution instance of waitingForDevice=true) is resumed by sending a deviceAvailable signal. At the same time, manual handling paths (ETRY to retry device calls, SKIP to skip the current task, ACK to confirm that the anomaly has been resolved) and automatic recovery are supported in parallel.

[0034] Based on the above embodiments, the step of querying the current status of the corresponding device according to its anomaly type and determining whether it meets the preset recovery conditions corresponding to the anomaly type includes: in response to the anomaly type being device offline or device failure, determining whether to restore based on the working status signal of the corresponding device; in response to the anomaly type being no available device, determining whether to restore based on the availability of the same type of device; in response to the anomaly type being call failure, directly determining that the preset recovery conditions are met; in response to the anomaly being a production line alarm, determining whether to restore based on the production line status check table and manual judgment, wherein the production line status check table is used to store the signal items corresponding to the production line.

[0035] In this embodiment, the corresponding exception management module is configured to classify and persist exceptions. The exceptions include at least DEVICE_OFFLINE, DEVICE_FAULT, NO_AVAILABLE_DEVICE, CALL_FAILED, and LINE_ALARM. An alarm code ALM_{equipmentCode}_{timestamp} is generated and recorded in the alarm record table, which includes the device ID, task ID, process instance ID, exception type, and alarm status UNCONFIRMED (unprocessed) / PROCESSED (processed).

[0036] It should be noted that DEVICE_OFFLINE indicates that the device is offline (onlineStatus=OFFLINE), DEVICE_FAULT indicates that the device is faulty (workStatus=FAULT); NO_AVAILABLE_DEVICE indicates that there are no available devices (the query result is empty or all devices are offline / faulty); CALL_FAILED indicates that the command was not issued (the method call returned a failure); LINE_ALARM indicates a production line alarm (such as safety light curtain triggering or emergency stop being pressed).

[0037] The specific information recorded in the anomaly log includes: alarm_cod (alarm code), equipment_id (device ID), task_detail_id (task detail ID, string format), process_id (process instance ID), alarm_type (alarm type, such as system alarm / device alarm), alarm_level (NORMAL / SERIOUS / URGENT), alarm_message (anomaly type description and error information), alarm_time (alarm time), alarm_status (alarm status, such as UNCONFIRMED (unconfirmed / PROCESSED (processed)), recovery_time (recovery time), solution (solution description), remark (remarks), and is_auto_recovered (whether automatic recovery is enabled).

[0038] The anomaly logging process includes: generating an alarm code in the format ALM_{equipmentCode}_{timestamp}; constructing an alarm log object, setting the device ID, task ID, process instance ID, anomaly type, alarm message, alarm time, etc.; inserting the record into the database and saving it; sending a WebSocket notification to push the alarm message (MessageType.ALARM) to production line users; and setting process variables, including setting waitingForDevice=true, waitingReason_{detailId}, and waitingEquipment_{detailId} through the process engine. In this embodiment, the corresponding scanning module is configured to scan unconfirmed alarm records every 5 minutes, parse the anomaly type from the alarm records, query the current device status (Online status, STANDBY / WORK status), and determine whether the recovery conditions are met. The recovery conditions are determined based on the type of exception: DEVICE_OFFLINE requires the online status to be ONLINE, DEVICE_FAULT requires the working status to be STANDBY or WORK, NO_AVAILABLE_DEVICE requires the existence of an available device, and CALL_FAILED and TIMEOUT are recoverable by default.

[0039] In this embodiment, the corresponding recovery module is configured to, when the recovery conditions are met, extract the task ID and process instance ID from the alarm record, set `resumeFromWait_{detailId}=true`, set the exception status to `PROCESSED` (handled), find the execution instance waiting for the `deviceAvailable` signal, and resume execution by sending the signal. After successful recovery, `waitingForDevice=false` is cleared, and `resumeFromWait_{detailId}` is cleaned up.

[0040] It should be noted that the scheduled task executes every 5 minutes (300,000 milliseconds), querying unconfirmed alarm records (i.e., querying the list of records with alarmStatus=UNCONFIRMED), iterating through each alarm record, checking and restoring it, counting the number of checks and restorations, and logging the results. Different restoration condition checks are performed based on the anomaly type: DEVICE_OFFLINE: Query the device's current online status; if onlineStatus=ONLINE, the problem is considered resolved; DEVICE_FAULT: Query the device's current working status; if workStatus=STANDBY or WORK, the problem is considered resolved; NO_AVAILABLE_DEVICE: Query the availability of similar devices; if an available device exists, the problem is considered resolved; CALL_FAILED / TIMEOUT: Usually allows retries; the default return value is true. Process recovery process: Extract task ID from alarm notes: use regular expressions to extract; Query task details: query task information based on task ID; Check task waiting status: call the method to check if waitingForDevice is true; Set recovery flag: set resumeFromWait_{detailId}=true; Send recovery signal: find the execution instance waiting for the deviceAvailable signal and send the recovery signal; Mark exception as resolved: update alarm status to PROCESSED, record recovery time and solution.

[0041] In this embodiment, the manual processing module is configured to support RETRY (retry device call), SKIP (skip current task), and ACK (acknowledge exception resolution) paths and runs in parallel with the recovery module. Three manual operations are supported: RETRY: Re-execute the device call; wait 1 second before retrying, up to a maximum of maxRetryCount times; if the retry succeeds, continue execution; if it fails, record the exception and enter a waiting state. SKIP: Mark the exception as resolved, skip the current task or process; set the process variable skipTaskDelegate=true, and the process continues to the next node; record the reason for skipping and the operator. ACK: Mark the exception as resolved; update the alarm status to PROCESSED, record the resolver and solution; optionally, resume the waiting process.

[0042] It should be noted that, in the case of a call failure, if a retry fails again or is not possible, the exception record is saved and awaited on the next scan. A retry threshold is set; once the threshold is reached, the user is prompted for manual intervention.

[0043] Through the embodiments of this disclosure, customized recovery is designed for four types of anomalies: device offline / failure, no available device, call failure, and production line alarm, achieving precise recovery.

[0044] Furthermore, a (dictionary, message) mapping is established for production line alarms / equipment alarms: the alarm code is parsed from the dictionary table to obtain the Chinese description, level, and handling suggestions; broadcast uniformly via WebSocket (the message body contains lineId / deviceCode / alarmCode / level / message / timestamp) to facilitate front-end subscription and display and auditing; linked with anomaly records, the broadcast is simultaneously written to the database to form a unified traceable link.

[0045] Based on the above embodiments, the step of determining whether the production line alarm has been resolved based on the production line status checklist and manual judgment includes: periodically reading the status value corresponding to each inspection item one by one according to the predefined production line status checklist; comparing each read status value with the predefined normal status of the inspection item; and determining that the production line alarm has been resolved after all the comparison results of the inspection items are normal and manual confirmation is received. The inspection items included in the production line status checklist include at least emergency stop status, safety protection status, equipment status, energy supply status, sensor status, and communication network status.

[0046] In this embodiment, in the production line alarm (LINE_ALARM) scenario, the equipment abnormality is saved to the alarm record table, the process variable is set to stop the issuance of production line tasks, the existing execution nodes enter the waiting state, and wait for the alarmResolved signal or manual ACK. After the conditions are met, the deviceAvailable or exceptionResolved signal is sent to the affected instances in batches to restore the system.

[0047] The embodiments disclosed herein cover key factors for production line safety, human-machine collaboration reduces the risk of misjudgment, and production line recovery is fast and safe.

[0048] Based on the above embodiments, the step of generating a recovery instruction based on the exception record, finding the execution instance waiting due to the exception, and sending an exception recovery signal includes: parsing the suspended task identifier from the exception record; in response to the absence of an associated exception record for the task identifier, setting the recovery flag variable associated with the task identifier to true; and sending an exception recovery signal to the execution instance associated with the task identifier.

[0049] Through the embodiments of this disclosure, the suspended task identifier is parsed from the abnormal record, the recovery flag is checked after checking for no associated abnormality, and a recovery signal is sent in a targeted manner. By binding the abnormality with the affected instance, the technical problems of false recovery signal sending, repeated wake-up of the same task, or state conflict are solved, and accurate and fast task recovery is achieved.

[0050] Based on the above embodiments, the step of executing the execution instance in response to the detection of the abnormal recovery signal includes: reading the value of the target node as the target value; calling a method of the target device to write control parameters based on the target value; reading back the value of the verification node as the verification value, and comparing the verification value with the target value; and executing the execution instance when the comparison result is consistent.

[0051] In this embodiment, based on the event triggering mechanism of OPC UA subscription, the target value (such as the length measurement node) is read when the triggering condition is met. If it fails, it automatically retryes once after waiting for 100ms. If it still fails, an error log is recorded and the linkage ends. The constructor parameters (such as the setR method, node 730, and parameter length) are used to call the OPC UA method to write control parameters. If it fails, it automatically retryes once after waiting for 100ms. If it still fails, an error log is recorded and the linkage ends. The verification node (such as node 176619) is read and the verification value is compared with the target value. If they are inconsistent, a warning log is recorded (writing not effective) and the verification ends without blocking the main process. If they are consistent, confirmation parameters (such as the setCBit method, node 840, and parameter true) are constructed, and a confirmation action is executed. If it fails, it automatically retryes once after waiting for 100ms. If it succeeds, a success log is recorded, and a confirmation action is performed, which can trigger chain linkage and WebSocket status notifications.

[0052] Each failed step is automatically retried once (every 100ms interval) and logged. An alarm is triggered when there is a discrepancy (write has not taken effect) but the main process is not blocked. Chained linkage and status notification are supported, and WebSocket push is used. The write and confirmation actions are completed through a unified OPC UA method call interface, which supports the transmission of structured parameter encoding (method name, node ID, parameter value). The timeout is configurable, for example, 5 seconds by default.

[0053] In this embodiment, the event-driven linkage closed loop includes:

[0054] (1) Triggering mechanism (based on OPC UA subscription): When the system starts, OpcUaStatusListener subscribes to the device trigger node; when the trigger node value changes from false to true, the onChange callback is triggered; check the triggering conditions (such as the device being online, the production line running, etc.), and if the conditions are met, the linkage logic is started.

[0055] (2) Linked Execution: Step 1: Read Target Value (Read Phase): Read the device node value. If the read fails, retry after 100ms. If it still fails, record the error log and end the linkage, then extract the data value. Step 2: Write Parameters (Write Phase): Construct method parameters, call the OPC UA method to execute the write. If the call fails, retry after 100ms. If it still fails, record the error log and end the linkage. Step 3: Verify Readback (Verify Phase): Read the verification node. If the read fails, retry after 100ms. If it still fails, record the error log and end the linkage, compare the verification values. If they are inconsistent, record a warning log (write not effective) and end the verification, but do not block the main process. Step 4: Execute Action (Execute Phase): Construct confirmation parameters, call the confirmation method to execute the final action. If the call fails, retry after 100ms. If it still fails, record the error log and end the linkage. If successful, record a success log, which can trigger chained linkage and WebSocket status notification.

[0056] Through the embodiments of this disclosure, the technical problems of disconnect between equipment status and control commands and erroneous parameters triggering malfunctions are solved by prior verification and data closed-loop verification, thereby improving the reliability of equipment execution.

[0057] Based on the above embodiments, the step of comparing the verification value with the target value further includes: if the verification value is inconsistent with the target value, then a warning log is recorded and the current linkage verification is terminated without blocking the main process of initiating the linkage control.

[0058] In this embodiment, after a file upload is successful, a 3-second waiting period (control-side cache / loading time) is set before issuing a start command. If the upload is triggered repeatedly, idempotency verification is performed based on the file name / task details to avoid repeated burning. Upload failure does not block the main link for abnormal recovery, but will stop the current linkage and store the data in the database.

[0059] Through the embodiments of this disclosure, alarm logs are recorded when verification values ​​do not match, skipping the current linkage but not blocking the main process, separating local linkage failure from the continuity of the global process, solving the problem of single-point verification failure causing the overall process to stall, and enhancing the stability of anomaly recovery.

[0060] Based on the above embodiments, the method of invoking the target device to write control parameters based on the target value includes: continuously writing multiple control parameters to the target device; in response to successful writing, polling and reading the receive confirmation flag of the target device until successful reading or the maximum number of retries is reached; in response to obtaining the confirmation flag of successful reading, writing a reset flag to the target device to complete the handshake.

[0061] Specifically, the parameter handshake and retry for the linkage between Device A and Device B includes the following handshake process: writing parameters, reading the receive flag, and resetting the flag for Device A: writing parameters continuously, writing multiple parameters sequentially, with each write operation timed out for 5 seconds, and terminating if any fails; polling to read the receive flag, reading the node, retrying up to 5 times with a 1-second interval between each retry, and proceeding to the next step if the read is successful and the value is true; resetting the valid flag, writing the flag bit, marking the handshake as complete upon success, and retrying after 1 second if the reset fails, recording a warning and terminating the linkage; this handshake serves as a prerequisite for subsequent instructions from Device B, and the entire linkage process terminates if the handshake fails.

[0062] The embodiments disclosed herein prevent single-frame loss and out-of-order issues that could lead to control failure.

[0063] The following example illustrates the entire process of automatic recovery from equipment failure when a cutting machine suddenly malfunctions (workStatus changes from STANDBY to FAULT) during the cutting process of a sheet metal processing task.

[0064] Step 1, Anomaly Detection and Recording: Time T0: The OPC UA subscription listens for a change in the workStatus node, with the value changing from 1 (STANDBY) to 3 (FAULT), triggering the listener event.

[0065] Step 2, exception persistence: Generate exception code: ALM_CUT101_DEVICE_FAULT_1699347600000; insert into the database table.

[0066] Step 3, process enters waiting: Device failure is detected, process variables are set; the process gateway (ExclusiveGateway) checks if {waitingForDevice == 'true'} is true; the process enters signal listening (IntermediateCatchEvent) and waits for the deviceAvailable signal.

[0067] Step 4, Equipment Repair: Time T1 (T0+5 minutes): Maintenance personnel repair the equipment or the equipment restarts automatically; workStatus is restored from FAULT to STANDBY; OPC UA subscription detects changes and updates the database.

[0068] Step 5: Scheduled Scan Detection: Time T2 (T1+30 seconds): Scheduled task execution (every 5 minutes), query unconfirmed alarm records: alarmStatus=UNCONFIRMED, traverse alarm records, and check whether the anomaly has been resolved.

[0069] Step Six: Recovery Condition Judgment: Parse the exception type from the alarm code: Parse out DEVICE_FAULT; Check the device status: Query the current workStatus of the device. If it is STANDBY or WORK, it is determined that the problem has been resolved. If it has not been resolved, record the log and skip it; if it has been resolved, proceed to the recovery process.

[0070] Step 7: Workflow Recovery: Extract Task ID from Alarm Records: Extract the task ID (2001) using a regular expression. Query Task Details: Obtain the workflow ID. Check Task Waiting Status: Check if waitingForDevice is true. Set Recovery Flag: Set resumeFromWait_2001=true. Send Recovery Signal: Find the execution instance waiting for the deviceAvailable signal, send a recovery signal, and mark the exception as resolved: Update the alarm status to PROCESSED, record the recovery time and solution (system automatic, exception automatically resolved).

[0071] Step 8: Process continues execution: When the signal listener (IntermediateCatchEvent) receives the deviceAvailable signal, the process resumes; execution restarts, and when resumeFromWait_2001=true is detected, execution proceeds directly, the distributed lock is acquired, the device status is checked (STANDBY), instructions are issued, and the task continues to execute.

[0072] The following example, taking the material loading process as an example, illustrates the entire closed-loop process of equipment linkage during the cutting operation of a sheet metal processing task.

[0073] After the feeder (FEED101) delivers the material to the cutting position, it needs to notify the cutter (CUT101) to begin cutting. The linkage parameters include measuring length, writing cutting length, verifying the write operation, and confirming start, specifically:

[0074] (1) Subscribe to trigger node: When the system starts, OpcUaStatusListener subscribes to the trigger node of the feeder.

[0075] (2) Read measurement length (Read Phase): Time T0: The trigger node becomes true and the onChange callback is triggered; Read the measurement length node; If the reading fails, wait 100ms and try again. If it still fails, record the error log and end the linkage; Extract data value: length=1234 (example value).

[0076] (3) Write phase: Parameters of constructor: node 730, parameter length=1234; call the OPC UA method to perform writing; if the call fails, wait 100ms and retry once, if it still fails, record the error log and end the linkage.

[0077] (4) Read back verification (Verify Phase): Read the verification node; if the read fails, wait 100ms and retry once. If it still fails, record the error log and end the linkage; compare the verification value: verifyValue == length (1234 == 1234); if they are inconsistent, record the warning log (write not effective) and end the verification, but do not block the main process.

[0078] (5) Confirm Start Cutting (Execute Phase): Construct confirmation parameters: node 840, parameter true; call the confirmation method to execute the final action; if the call fails, wait 100ms and retry once; if it still fails, record the error log and end the linkage; if it succeeds, record the success log.

[0079] (6) Linkage result notification: After successful linkage, a WebSocket notification (MessageType.LINKAGE_SUCCESS) is pushed, which can trigger chain linkage (such as notifying the start of the next process).

[0080] The following describes the parameter handshake process using the loading and cutting linkage as an example.

[0081] Before executing a cutting task, the cutting machine needs to transmit material parameters (task type, length, width, thickness) to the feeder and wait for the feeder to confirm receipt. Then, it resets the flag as a prerequisite for subsequent cutting instructions. Specifically, this includes:

[0082] (1) Continuous parameter writing: Time T0: The cutter calls the method and writes 5 parameter nodes in sequence, with a timeout of 5 seconds for each write operation: di_CurrentTaskType (task type, value is 0), di_CurrentTaskLength (length, value is task.getLength()), di_CurrentTaskHighth (width, value is task.getWidth()), di_CurrentTaskThickness (thickness, value is task.getThickness()), di_CurrentTaskFlag (valid flag, value is true). If any write fails, the handshake process is immediately terminated and false is returned.

[0083] (2) Polling to read the receive flag: Read the Mo_SLJReceive node, retry a maximum of 5 times, with an interval of 1 second between each time. If the reading is successful and the value is true, proceed to the next step; if all 5 attempts fail or the value is false, record a warning and terminate the linkage.

[0084] (3) Reset valid flag: Write di_CurrentTaskFlag=false. If the write is successful, the handshake is marked as complete and true is returned. If the write fails, wait 1 second and try again. If it still fails, record a warning and terminate the linkage.

[0085] (4) Subsequent process: After a successful handshake, the cutting command continues to be executed. If the handshake fails, the entire linkage process is terminated, the exception is recorded, and the process enters a waiting state.

[0086] Based on the above-mentioned method for automatic recovery of anomalies and event-driven linkage in industrial processes, this disclosure also provides a system for automatic recovery of anomalies and event-driven linkage in industrial processes. Figure 2 The diagram illustrates a structural block diagram of an automatic anomaly recovery and event-driven linkage system for industrial processes according to an embodiment of the present disclosure.

[0087] This embodiment of the automatic anomaly recovery and event-driven linkage system for industrial processes can be used to implement the aforementioned automatic anomaly recovery and event-driven linkage method for industrial processes. It includes: an anomaly recording module, used to classify and record anomalies occurring in the industrial process, and scan unprocessed anomaly records at a preset period. The anomalies include at least one of the following: equipment offline, equipment failure, no available equipment, call failure, and production line alarm; an anomaly recovery module, used to query the current status of the corresponding equipment for each scanned anomaly record based on its anomaly type, and determine whether it meets the preset recovery conditions corresponding to that anomaly type; a task recovery module, used to generate a recovery instruction based on the anomaly record in response to meeting the preset recovery conditions, locate the execution instance waiting due to the anomaly, and send an anomaly recovery signal; and an event-driven module, used to execute the execution instance in response to detecting the anomaly recovery signal.

[0088] Figure 3 A block diagram of an electronic device suitable for implementing an automatic recovery from anomalies and an event-driven linkage method for industrial processes, according to an embodiment of the present disclosure, is shown schematically.

[0089] like Figure 3As shown, an electronic device 300 according to an embodiment of this disclosure includes a processor 301, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 302 or a program loaded from a storage portion 308 into a random access memory (RAM) 303. The processor 301 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 301 may also include onboard memory for caching purposes. The processor 301 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this disclosure.

[0090] RAM 303 stores various programs and data required for the operation of electronic device 300. Processor 301, ROM 302, and RAM 303 are interconnected via bus 304. Processor 301 performs various operations of the method flow according to embodiments of the present disclosure by executing programs in ROM 302 and / or RAM 303. It should be noted that the programs may also be stored in one or more memories other than ROM 302 and RAM 303. Processor 301 may also perform various operations of the method flow according to embodiments of the present disclosure by executing programs stored in said one or more memories.

[0091] According to embodiments of this disclosure, the electronic device 300 may further include an input / output (I / O) interface 305, which is also connected to a bus 304. The electronic device 300 may also include one or more of the following components connected to the I / O interface 305: an input section 306 including a keyboard, mouse, etc.; an output section 307 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 308 including a hard disk, etc.; and a communication section 309 including a network interface card such as a LAN card, modem, etc. The communication section 309 performs communication processing via a network such as the Internet. A drive 310 is also connected to the I / O interface 305 as needed. A removable medium 311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 310 as needed so that computer programs read from it can be installed into the storage section 308 as needed.

[0092] This disclosure also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs that, when executed, implement the method according to the embodiments of this disclosure.

[0093] Embodiments of this disclosure also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the methods provided in the embodiments of this disclosure.

[0094] According to embodiments of this disclosure, program code for executing the computer programs provided in embodiments of this disclosure can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, Java, C++, Python, C, or similar programming languages. The program code can execute entirely on a user's computing device, partially on a user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0095] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0096] Those skilled in the art will understand that the features described in the various embodiments and / or claims of this disclosure can be combined or combined in various ways, even if such combinations or combinations are not explicitly described in this disclosure. In particular, the features described in the various embodiments and / or claims of this disclosure can be combined or combined in various ways without departing from the spirit and teachings of this disclosure. All such combinations and / or combinations fall within the scope of this disclosure.

[0097] The embodiments of this disclosure have been described above. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of this disclosure. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. The scope of this disclosure is defined by the appended claims and their equivalents. Various substitutions and modifications can be made by those skilled in the art without departing from the scope of this disclosure, and all such substitutions and modifications should fall within the scope of this disclosure.

Claims

1. A method for automatic anomaly recovery and event-driven linkage in industrial processes, characterized in that, include: Classify and record anomalies occurring in the industrial process, and scan unprocessed anomaly records at a preset cycle. The anomalies include at least one of the following: equipment offline, equipment failure, no available equipment, call failure, and production line alarm. For each abnormal record scanned, query the current status of the corresponding device according to its abnormality type, and determine whether it meets the preset recovery conditions corresponding to that abnormality type. In response to the fulfillment of the preset recovery conditions, a recovery instruction is generated based on the anomaly record, the execution instance that is waiting due to the anomaly is located, and an anomaly recovery signal is sent. In response to the detection of the abnormal recovery signal, the execution instance is executed.

2. The method according to claim 1, wherein, The step of querying the current status of the corresponding device based on its anomaly type and determining whether it meets the preset recovery conditions corresponding to that anomaly type includes: In response to the anomaly type being device offline or device malfunction, a determination is made as to whether to restore the device based on the corresponding device's operating status signal. If the anomaly type is "no available device", then determine whether to restore based on the availability of the same type of available device; If the exception type is "call failure", it is directly determined that the preset recovery conditions are met. In response to the abnormality being a production line alarm, the production line status checklist and manual judgment are used to determine whether to restore the line. The production line status checklist is used to store the signal items corresponding to the production line.

3. The method according to claim 1, wherein, The process of determining whether to restore production based on the production line status checklist and manual judgment includes: According to the predefined production line status checklist, the status value corresponding to each check item is periodically read one by one. Each read status value is compared with the predefined normal status of the check item; Once all the comparison results of the inspection items are normal and manual confirmation is received, the system determines that the production line alarm has been resolved. The production line status checklist includes at least the following items: emergency stop status, safety protection status, equipment status, energy supply status, sensor status, and communication network status.

4. The method according to claim 1, wherein, The step of generating a recovery instruction based on the anomaly record, locating the execution instance waiting due to the anomaly, and sending an anomaly recovery signal includes: Parse the suspended task identifier from the anomaly record; If no associated exception record exists for the task identifier, the recovery flag variable associated with the task identifier is set to true. Send an exception recovery signal to the execution instance associated with the task identifier.

5. The method according to claim 1, wherein, The step of executing the execution instance in response to detecting the abnormal recovery signal includes: Read the value of the target node as the target value; Invoke the target device's method to write control parameters based on the target value; Read back the value of the verification node as the verification value, and compare the verification value with the target value; If the comparison results are consistent, the execution instance is executed.

6. The method according to claim 1, wherein, The step of comparing the verification value with the target value further includes: If the verification value is inconsistent with the target value, a warning log is recorded and the current linkage verification is terminated without blocking the main process of initiating the linkage control.

7. The method according to claim 1, wherein, The method of invoking the target device to write control parameters based on the target value includes: Multiple control parameters are continuously written to the target device; In response to a successful write, the receiver confirmation flag of the target device is polled until the read is successful or the maximum number of retries is reached. Upon receiving a confirmation flag indicating successful read, a reset flag is written to the target device to complete the handshake.

8. An automatic anomaly recovery and event-driven linkage system for industrial processes, characterized in that, Capable of implementing the method of claim 1, comprising: The anomaly recording module is used to classify and record anomalies that occur in the industrial process, and scan unprocessed anomaly records at a preset cycle. The anomalies include at least one of the following: equipment offline, equipment failure, no available equipment, call failure, and production line alarm. The anomaly recovery module is used to query the current status of the corresponding device for each scanned anomaly record based on its anomaly type, and determine whether it meets the preset recovery conditions corresponding to that anomaly type. The task recovery module is used to generate a recovery instruction based on the exception record in response to the meeting of the preset recovery conditions, find the execution instance that is waiting due to the exception, and send an exception recovery signal. An event-driven module is used to execute the execution instance in response to the detection of the exception recovery signal.

9. An electronic device, comprising: One or more processors; Storage device for storing one or more programs. Wherein, when the one or more programs are executed by the one or more processors, the one or more processors perform the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, cause the processor to perform the method according to any one of claims 1 to 7.

Images