An event-driven belt conveying system operation and maintenance control system and method

Abstract

The application discloses an event-driven belt conveying system operation and maintenance control method and system, and belongs to the field of industrial automation. The method comprises the following steps: acquiring multi-source heterogeneous original abnormal information and converting the multi-source heterogeneous original abnormal information into standardized structured event objects; generating structured disposal tasks according to the event objects and a preset rule library; selecting a path according to an execution subject identifier, analyzing the tasks into bottom-layer instructions, and issuing the bottom-layer instructions to intelligent equipment or pushing the bottom-layer instructions to a mobile terminal; receiving execution state feedback, creating and tracking electronic work orders, and updating the work order states after receiving a mobile terminal completion signal. The application realizes an end-to-end automation closed loop from abnormal sensing to execution confirmation, shortens emergency response from an hour level to a second level, and solves the problems of islandization, process breakpoints, execution dependence on manual work and lack of a closed loop of an existing system.

Description

Technical Field

[0001] This invention relates to the field of industrial automation and equipment operation and maintenance, specifically to an event-driven operation and maintenance control system and method for belt conveyor systems. Background Technology

[0002] Current belt conveyor systems comprise a mechanical system consisting of a frame, belt, and idlers; an electric drive system consisting of a motor, PLC controller, and cables; and a monitoring system consisting of cameras and displays. Existing systems suffer from poor data interoperability, numerous process breakpoints, high reliance on manual labor, and a lack of closed-loop systems, exhibiting significant bottlenecks such as: 1. System isolation and difficulty in data collaboration: Systems such as Supervisory Control and Data Acquisition (SCADA), video surveillance, fault diagnosis, and work order management are independent of each other, forming multiple "data silos." Maintenance personnel need to manually switch, compare, and transmit information between these scattered systems, resulting in low decision-making efficiency and a high risk of misjudgment due to information asynchrony.

[0003] 2. Process breaks and discontinuous response: After the monitoring system detects an anomaly, it usually only triggers basic audible and visual alarms. Subsequent steps such as anomaly confirmation, responsibility assignment, on-site handling, and result feedback still heavily rely on manual telephone communication and paper-based work orders. The process has breaks, is lengthy, and is difficult to track, which can easily lead to delays and oversights.

[0004] 3. Execution relies on manpower and has a low degree of automation: Even if a fault is identified, critical maintenance operations such as material removal and inspection still require personnel to be on-site, making it impossible to perform troubleshooting actions remotely or automatically. This not only restricts response efficiency but also poses personal safety risks, making it difficult to support the goal of "unmanned or minimally manned" maintenance.

[0005] In summary, there is an urgent need for an event-driven operation and maintenance control system for belt conveyor systems to solve, or at least partially solve, the problems existing in the current technology. Summary of the Invention

[0006] The purpose of this invention is to provide an event-driven operation and maintenance control system for belt conveyor systems, aiming to solve the problems of poor system coordination, numerous process breakpoints, high dependence on manual intervention, and inability to automatically troubleshoot faults in existing belt conveyor systems. The specific technical solution is as follows: An event-driven operation and maintenance control method for a belt conveyor system, applied to an event-driven operation and maintenance control system for belt conveyors, includes the following steps: S1. Obtain raw anomaly information from multiple independent sensing subsystems and transform the raw anomaly information into standardized structured event objects; S2. Based on the structured event object and according to the preset event-action rule library, automatically match the rules to generate a structured processing task corresponding to the structured event object; S3. Select the execution path based on the execution entity identifier in the structured processing task: If the execution entity identifier points to the intelligent execution equipment, the processing task is parsed into a low-level control command and sent to the intelligent execution equipment; If the execution entity identifier points to a mobile terminal, the processing task will be pushed to the mobile terminal in the form of a digital work order data packet; S4. Receive execution status feedback returned by the selected execution subject, create and track electronic work orders associated with the structured event object; when the received execution status feedback indicates successful execution, update the status of the electronic work order to completed.

[0007] Preferably, step S1, "converting the original anomaly information into standardized structured event objects," specifically includes the following sub-steps: S11. Receive raw anomaly information from at least two sensing subsystems among the distributed fiber optic sensing system, high-definition industrial camera and infrared thermal imager through the event perception and aggregation module. S12. Perform a mandatory field integrity check on the original anomaly information. The mandatory fields include device identifier, event type, and occurrence time. S13. Based on the system's pre-set digital twin model, equipment topology and spatial coordinate mapping table, automatically fill in the missing required fields to generate complete event information; S14. Encapsulate the complete event information into a structured event object. The structured event object includes at least: identification information for uniquely identifying the event, device information for identifying the device from which the event originates, location information for indicating the location where the event occurs, event type information for classifying the event, level information for characterizing the urgency of the event, time information for recording the time when the event occurs, and data source link information for associating with the original data.

[0008] Preferably, the "automatic rule matching based on a preset event-action rule base" in step S2 specifically includes: S21. The rule engine and decision module receive the structured event object and extract the event type and severity level fields from the object as the core matching key. S22. Match the core matching key with the preset rules in the event-action rule base; S23. If a match is found, a structured processing task is generated according to the processing actions defined in the rule. If a match fails, the structured event object is marked as an unhandled exception and pushed to the visualization and alerting center.

[0009] Preferably, the step S3, where the execution subject identifier points to the intelligent execution equipment, includes: S31. Parse the target equipment identifier, action type, and execution parameters from the structured processing task; S32. Based on the target equipment identifier, query the preset equipment instruction adaptation library to obtain the communication protocol type, data link layer format and data address mapping relationship of the equipment. S33. Map the action type and execution parameters to control command codes and execution parameter values ​​that the equipment can recognize, and generate the underlying control command frame; S34. Send the generated low-level control command frame to the corresponding intelligent execution equipment; S35. Establish an instruction monitoring mechanism to monitor and capture the execution status feedback returned by the intelligent execution equipment. The execution status feedback includes three states: success, failure, or exception.

[0010] Preferably, step S4 further includes: when the execution entity identifier points to the intelligent execution equipment and the captured execution status feedback indication is successful, calling the corresponding sensing subsystem to collect on-site data and comparing it with the preset completion standard to generate an automatic verification result; wherein, the sensing subsystem includes at least one of a vibration sensor, a temperature sensor, and an image sensor for verifying the operation and maintenance effect.

[0011] Preferably, the step of calling the corresponding sensing subsystem to collect on-site data and comparing it with a preset completion standard includes: Based on the geographical location in the structured event object, the corresponding sensing subsystem is invoked to collect on-site data; The collected data is compared with the standard threshold. If the standard is met, the automatic verification result is passed; otherwise, it is failed.

[0012] Preferably, receiving the completion signal from the mobile terminal in step S4 includes: When the automatic verification result is passed, the verification result data packet is pushed to the mobile terminal through the communication network. The system receives a signal frame from the mobile terminal in response to the verification result data packet. The signal frame carries a status code, a timestamp, and optional additional data fields.

[0013] Preferably, after step S2 and before or simultaneously with step S3, the method further includes: displaying event information associated with the structured event object on a digital map built into the system, and pushing initial alarm information to the corresponding mobile terminal.

[0014] Preferably, after step S4, the method further includes: Complete cases of handling are recorded in the operation and maintenance knowledge base. The complete case includes at least: structured event object, matching rules, generated handling task, execution status feedback of intelligent execution equipment, automatic verification result, signal frame from mobile terminal, and original abnormal information that triggered the event. Based on case data in the operations and maintenance knowledge base, the event-action rule base is adjusted, added, or updated.

[0015] On the other hand, this application also provides an event-driven operation and maintenance control system for a belt conveyor system, which, by applying the above method, includes: The event perception and aggregation module is used to receive raw abnormal information from multiple independent perception subsystems and transform the raw abnormal information into standardized structured event objects; The rules engine and decision module are used to receive the structured event objects and automatically generate corresponding structured processing tasks based on the preset event-action rule library. The task scheduling and execution control module is used to schedule execution based on the execution subject identifier in the structured task: if the execution subject identifier points to the intelligent execution equipment, the task is parsed into a low-level control command and sent to the intelligent execution equipment; if the execution subject identifier points to the mobile terminal, the task is pushed to the mobile terminal in the form of a digital work order data packet and feedback signals from the mobile terminal are received. The closed-loop management and feedback module is used to obtain execution status feedback, create and track electronic work orders, receive completion signals from mobile terminals, and update work order status. The closed-loop management and feedback module is also used to store complete cases in the operation and maintenance knowledge base, and to adjust, add or update the event-action rule base based on the case data.

[0016] The application of the technical solution of the present invention has the following beneficial effects: This invention transforms multi-source heterogeneous sensing information into standardized structured event objects through an event perception and aggregation module, breaking down system silos and enabling automatic data fusion without manual cross-system switching and comparison. A rule engine automatically matches event-action rule bases to generate structured handling tasks, compressing the manual decision-making process to millisecond-level responses and eliminating delays and oversights caused by process breakpoints. Based on the executing entity identifier, it automatically selects intelligent equipment for execution or dispatches via mobile terminals, reducing standardized operation response time from tens of minutes to seconds, eliminating the need for personnel to enter high-risk areas, and enabling full digital tracking of complex maintenance tasks. By receiving execution status feedback, automatically verifying effects, and receiving confirmation signals from mobile terminals, a complete operational closed loop is formed, and cases are stored in a knowledge base to drive continuous rule evolution. Therefore, this invention achieves full-process automation from anomaly perception to execution confirmation, solving the fundamental defects of existing technologies such as system isolation, process breakpoints, reliance on human labor, and lack of closed loops.

[0017] In addition to the objectives, features, and advantages described above, the present invention has other objectives, features, and advantages. The invention will now be described in further detail with reference to the figures. Attached Figure Description

[0018] The accompanying drawings, which form part of this application, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings: Figure 1 This is a flowchart of an event-driven operation and maintenance control method for a belt conveyor system according to the present invention; Detailed Implementation To facilitate understanding of the present invention, a more comprehensive description is provided below, along with preferred embodiments. However, the present invention can be implemented in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided to provide a thorough and complete understanding of the disclosure of the present invention.

[0019] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.

[0020] This invention provides an event-driven operation and maintenance control method and system for belt conveyor systems. The complete process of the method and the system for implementing it are described below through two embodiments, and the working process of this invention in a real industrial environment is demonstrated through two specific application scenarios.

[0021] Example 1: Reference Figure 1This embodiment provides an event-driven operation and maintenance control method for a belt conveyor system, including the following steps S1 to S4.

[0022] S1. Event Awareness and Standardization: The event awareness and aggregation module, deployed in the edge computing server at the belt conveyor site, receives raw anomaly information from multiple independent sensing subsystems in real time via the MQTT protocol. These independent sensing subsystems include: a distributed fiber optic sensing system for collecting vibration and acoustic signals; a high-definition industrial camera for collecting image information; and an infrared thermal imager for collecting temperature distribution. The data formats of the above three subsystems are different: the distributed fiber optic sensing system outputs vibration spectrum data (binary format), the camera outputs video streams or image files (such as JPEG), and the thermal imager outputs a temperature matrix (such as CSV format).

[0023] The event awareness and aggregation module executes a standardized process, which consists of three sub-steps, as follows: Standardized format: Data from different sources and in different formats is uniformly converted into JSON format for easier subsequent processing.

[0024] Field Validation and Completion: Based on the system's predefined event format specifications, each message is checked to ensure it contains the three required fields: device identifier, event type, and occurrence time. If any field is missing, the digital twin model is invoked for automatic completion. The digital twin model is a pre-built virtual mapping system that internally stores a table of correspondences between device identifiers, fiber optic meter markers, and geographic coordinates, as well as the device topology. For example, when a distributed fiber optic sensing system reports an abnormal vibration at fiber optic meter marker 1250.5, the digital twin model can use that meter marker to retrieve the specific device identifier and precise geographic location, such as the device identifier being "Chute-L1" and the specific location coordinates being (X:1250.5, Y:345.2, Z:12.1), thus completing the missing information.

[0025] Output Encapsulation: The complete event information is encapsulated into a structured event object. This object contains seven fixed fields: a unique event identifier (e.g., EV20240520143055001), a device identifier (e.g., Chute-L1), a precise geographic location (e.g., a corresponding 3D coordinate value), an event type (e.g., "minor blockage in the chute"), a severity level (e.g., "moderate"), a timestamp (synchronized to milliseconds), and a link to the associated data source (e.g., video stream address, vibration spectrum address). Finally, this structured event object is output to the cloud platform in a structured data format (e.g., JSON).

[0026] Through the aforementioned methods, vibration, visual, and temperature sensing information, which were originally isolated and varied in data format, are unified into standardized, structured event objects. Maintenance personnel no longer need to manually switch and compare information between three independent systems: SCADA, video surveillance, and infrared thermal imaging. The system automatically completes the spatiotemporal alignment and fusion of multi-source data. This technology directly solves the problems of low decision-making efficiency and susceptibility to misjudgments due to information asynchrony caused by system isolation and difficulties in data collaboration in existing technologies. For example, when a high-definition camera detects a 40% reduction in the material cross-section, this alarm is automatically associated with the vibration data and infrared temperature data from the distributed fiber optic sensing system into the same event object, providing a complete data foundation for subsequent system-driven decision-making.

[0027] S2, Intelligent Decision Making and Task Generation: After standardized event objects are uploaded to the cloud platform, the rule engine and decision module receive the objects. The engine extracts the "event type" and "severity level" fields and matches them with the built-in event-action rule library. This matching process is an efficient table lookup or decision tree traversal process.

[0028] Upon successful matching, the engine automatically instantiates a structured processing task based on the action and responsibility matrix defined in the rules. The responsibility matrix is ​​a predefined mapping table used to determine the corresponding executor and notification method based on the event type and severity level, such as mobile application push or SMS push. The task content includes: executor identifier (pointing to the intelligent execution equipment or mobile terminal), operation instruction sequence, completion criteria, timeout period, etc.

[0029] For example, in the scenario of automatically handling minor blockage in a chute, the event object {type: minor blockage in chute, level: general} matches the rule RULE-001; the THEN part of rule RULE-001 is defined as: the executing entity is the high-pressure air cannon AirCannon-L1, the action is Fire, and the execution parameter is Count=1, that is, triggering one explosion; at the same time, the on-duty inspector Wang Wu is notified through the mobile terminal to confirm the clearing effect, thus realizing automatic fault handling.

[0030] For example, in the scenario of early bearing wear, the event object {Type: Early bearing wear, Level: Important} matches rule RULE-002. The THEN part of rule RULE-002 is defined as: the executing entity is the maintenance team leader, the action is to generate a predictive maintenance work order, and the parameters are {required completion time within 72 hours, bearing model 6316}, and the goal is to restore the vibration value detected by the standard distributed fiber optic sensing system to the normal range. Through this rule, the system can automatically assign maintenance tasks to the corresponding responsible personnel, achieving automatic task generation and assignment from anomaly detection. It should be noted that bearing model 6316 is only an example; in actual applications, the corresponding spare part model can be configured according to the equipment model.

[0031] By employing automated decision-making in the S2 step, the problems of process interruptions and low decision-making efficiency in existing technologies are solved. It solidifies the complex decision-making process that originally required human experience into automated logic with millisecond-level responses, eliminating the risk of delays, omissions, or wrong assignments that may occur with manual order dispatching from the source.

[0032] S3. Select the execution path based on the execution entity identifier; After receiving a structured processing task, the task scheduling and execution control module determines the execution path based on the execution entity identifier in the task, which falls into the following two categories: If the executing entity identifier points to intelligent execution equipment, such as an air cannon: the module parses the target equipment identifier, action type, and execution parameters from the task; it queries the pre-set equipment instruction adaptation library to obtain the communication protocol type and data format of the equipment; it should be noted that this library stores the communication protocol type, data address mapping, instruction frame format, etc. of each intelligent execution equipment; it maps the action type and execution parameters to equipment-recognizable low-level control instruction codes and execution parameter values, generating low-level control instruction frames; it sends the generated low-level control instruction frames to the corresponding intelligent execution equipment; specifically, for example, through network interfaces such as industrial Ethernet, RS485 bus, or wireless communication, the instructions are sent to the corresponding intelligent execution equipment; at the same time, an instruction listening mechanism is established to wait for and receive execution status feedback from the equipment, which may be success, failure, or anomaly.

[0033] If the executing entity identifier points to a mobile terminal, such as the responsible person's mobile phone, the module will push the task to that mobile terminal in the form of a digital work order data packet, specifically through the mobile application push service. The system pre-maintains a mapping relationship between the responsible person and the mobile terminal address, for example, by associating them through mobile phone number or push token. The module queries this mapping table based on the responsible person identifier in the task to determine the target push address. The module also establishes a listening mechanism to receive execution status feedback from the mobile terminal. After receiving the feedback, the on-site personnel perform the operation according to the work order requirements. After completing the operation, the personnel then send back execution status feedback through the mobile application.

[0034] By employing the S3-step scheduling and execution method, the problem of low automation and complete reliance on manual labor in existing technologies has been solved. For standardized operations such as material clearing, emergency response time is reduced from tens of minutes to seconds; in high-risk environments, machines replace manual labor, fundamentally eliminating the safety risks of personnel injury or death.

[0035] S4. Closed-Loop Management and Feedback: The closed-loop management and feedback module receives execution status feedback returned by the selected execution entity, and creates and tracks electronic work orders associated with structured event objects. Specifically, when the execution entity identifier points to the intelligent execution equipment and the execution status feedback indicates successful execution, the system can call the corresponding sensing subsystem (e.g., a high-definition industrial camera for acquiring image information, a distributed fiber optic sensing system for acquiring vibration signals across the entire line, and an infrared thermal imager for acquiring temperature information) to collect on-site data. Those skilled in the art will understand that the sensing subsystem includes, but is not limited to, at least one of vibration sensors, image sensors, and temperature sensors; specific equipment can be selected according to actual working conditions. The relevant data is compared with preset completion standard thresholds to automatically verify the effectiveness of the operation and maintenance. For example, after the air cannon clears material, a high-definition industrial camera is called to visually confirm whether the material flow cross-sectional area has returned to normal.

[0036] It should be noted that the aforementioned completion standard thresholds are objective parameters preset by the system. The methods for determining these thresholds include, but are not limited to: based on rated parameters provided by the equipment manufacturer, statistical analysis of historical data under normal operating conditions, simulation output based on digital twin models, or industry safety standards. The thresholds are calibrated during system deployment and can be dynamically adjusted based on knowledge base cases during operation. The specific method for dynamic adjustment is as follows: the system periodically extracts "automatically verified passed" cases from all completed cases in the operation and maintenance knowledge base, statistically analyzes the actual deviation distribution between the collected data and the threshold, and if there is a systematic deviation between the statistical results and the preset threshold, the threshold is automatically corrected to ensure that the verification standard is adapted to actual operating conditions.

[0037] After automatic verification is successful, the system pushes a confirmation request to the designated person in charge through the application on the mobile terminal, and receives the confirmation feedback submitted by the person in charge on the application. Specifically, the person in charge can click "Processing Complete" and optionally fill in remarks or upload photos.

[0038] When both the execution status feedback is successful and the mobile terminal confirmation feedback is received, the system updates the electronic work order status to "completed", forming a complete operation and maintenance closed loop from anomaly detection to execution confirmation for this event.

[0039] Once the work order status changes to "Completed," the module stores all data from the event's occurrence to its closure—including raw vibration / image data, generated event objects, executed rules, equipment feedback, and manual confirmation records—as a complete case in the operations and maintenance knowledge base. Based on the case data accumulated in the knowledge base, the system can generate or optimize the event-action diagnostic model using incremental learning algorithms (such as sliding window statistical algorithms or decision tree algorithms). This event-action diagnostic model is a mathematical model trained on historical case data, used to learn the mapping relationship between event characteristics (such as event type, severity level, equipment parameters, and sensor values) and the optimal handling action. Its output can be converted into new IF-THEN rules or used to adjust parameter thresholds for existing rules. Thus, the system can automatically generate new or adjust existing "IF-THEN" business rules, achieving continuous self-evolution of the event-action rule base.

[0040] The above steps address the problem of the lack of a closed loop and the inability to accumulate experience in existing technologies. Every operation and maintenance activity is digitized and traceable, and successful experiences are automatically used to optimize future system decisions.

[0041] After step S2 and before or simultaneously with step S3, a visualization and alarm step is also included; the system displays event information associated with structured event objects on a digital map, accurately marks the location and status of events, and pushes initial alarm information to the designated responsible person.

[0042] Example 2: This embodiment provides an event-driven operation and maintenance control system for a belt conveyor system. This system is used to execute the control method described in Embodiment 1 and includes the following modules: Event Awareness and Aggregation Module: Deployed in an edge computing server system close to the belt conveyor site. This module establishes communication connections with multiple heterogeneous independent sensing subsystems (including at least two of the following: distributed fiber optic sensing systems, high-definition industrial cameras, and infrared thermal imagers) through predefined industry standard interface protocols (such as MQTT and OPC UA). It receives raw anomaly information from these subsystems and transforms the raw anomaly information into standardized structured event objects.

[0043] The rules engine and decision-making module are deployed on a cloud platform and communicate with the event perception and aggregation module. This module has a built-in event-action rule base and responsibility matrix. It receives structured event objects and automatically generates corresponding structured handling tasks based on the pre-defined event-action rule base. The rule base consists of a series of structured "IF-THEN" logical statements, and the responsibility matrix defines the executing entity and notification method corresponding to different event types and severity levels.

[0044] Task scheduling and execution control module: Deployed on the cloud platform, it communicates with the rule engine and decision-making module. This module internally maintains instruction sets and communication protocol libraries (i.e., equipment instruction adaptation libraries) for various intelligent execution equipment. It receives structured processing tasks and schedules execution based on the execution entity identifier: if the execution entity identifier points to an intelligent execution equipment, the processing task is parsed into low-level control instructions and sent to that equipment, while simultaneously receiving execution status feedback from the equipment; if the execution entity identifier points to a mobile terminal, the processing task is pushed to the mobile terminal in the form of a digital work order data packet, and feedback signals from the mobile terminal are received. This module also transmits execution status feedback to the closed-loop management and feedback module.

[0045] Visualization and Alarm Center: Includes electronic display screens and digital maps displayed on the electronic display screens. It communicates and connects with the rule engine and decision-making module to display event information on the digital map (accurately marking the location and status of events) and push alarm information to designated responsible persons.

[0046] Closed-loop management and feedback module: Deployed on the cloud platform, it communicates with the task scheduling and execution control module and the rule engine and decision module. This module receives execution status feedback and automatic verification results from the task scheduling and execution control module, creates and tracks electronic work orders associated with structured event objects, interacts with on-site personnel through mobile applications (receiving confirmation signals from mobile terminals and pushing verification result data packets to mobile terminals), records complete cases of completed handling to the operation and maintenance knowledge base, and adjusts, adds, or updates the event-action rule base in the rule engine and decision module based on case data.

[0047] The above modules work together to execute the steps of the control method described in Example 1, realizing a complete operation and maintenance control process from event perception to closed-loop feedback and then to knowledge evolution.

[0048] Specific application scenario 1: Automatically handling minor blockages in chutes S1 (Perception): The high-definition camera (visual AI) of the TR-01 transfer station detects a 40% reduction in the material cross-section at the chute outlet and generates an initial alarm; after the edge module associates the distributed fiber optic sensing system with the infrared data, it generates a standardized event EV001 (event type: minor chute blockage, severity level: moderate).

[0049] S2 (Decision): The cloud platform rule engine matches rule RULE-001 and generates a structured processing task: The intelligent execution equipment AirCannon-L1 executes the Fire action once, and at the same time notifies the person in charge, Wang Wu, to confirm the effect.

[0050] S3 (Execution): The task scheduling module sends a low-level control command frame to AirCannon-L1, and the air cannon responds and completes the blasting and clearing within 1 second; at the same time, the system pushes a work order notification to Wang Wu's mobile application, informing him that the clearing has been automatically executed and requires final confirmation.

[0051] S4 (Closed Loop): The air cannon automatically transmits a "Successful Execution" status; the system calls a high-definition camera to collect images after material removal, and confirms through visual recognition that the material cross-sectional area has returned to normal and reached the preset threshold, automatically verifying success; Wang Wu views the real-time video through a mobile application, clicks "Processing Completed," and receives a confirmation signal. The work order status is updated to "Completed," and the case is added to the database. The entire process takes only a few minutes, greatly shortening processing time, reducing production downtime caused by troubleshooting, and improving economic efficiency.

[0052] Specific application scenario two: Manually addressing premature wear of drive roller bearings S1 (Sensing): The distributed fiber optic sensing system detects an abnormal vibration in the vibration spectrum, such as a fault characteristic frequency of 128Hz, which corresponds to pitting corrosion on the outer ring of the bearing, generating a "early wear of bearing" event with a severity level of "important".

[0053] S2 (Decision): The rule engine matches the predictive maintenance rule RULE-002 and generates a structured handling task: the execution subject identifier points to the mobile terminal (such as the mobile phone of maintenance team leader Li Si), and a maintenance work order is generated. The rule pre-sets the requirement to replace the bearing within 72 hours. The bearing model is 6316.

[0054] S3 (Execution): The task scheduling module pushes the work order to Li Si's mobile application in the form of a digital work order data package. Li Si receives the task, prepares spare parts in advance, and completes the bearing replacement during the planned downtime. After replacement, Li Si fills in "Bearing replaced, model 6316" in the mobile application, uploads on-site photos, and submits the execution completion feedback.

[0055] S4 (Closed Loop): The system calls the distributed fiber optic sensing system to collect the vibration spectrum after repair, confirms that the fault characteristic frequency has disappeared, and automatically verifies the result. The system pushes the verification result to Li Si's mobile phone, and after Li Si confirms it, he sends back the final confirmation signal. The work order status is updated to "Completed," and the case is added to the database. The system uses this case to enhance the diagnostic model, and the reliability of the early warning will be further improved when the 128Hz abnormal vibration characteristic reappears in the future.

[0056] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. An event-driven operation and maintenance control method for a belt conveyor system, characterized in that, An event-driven operation and maintenance control system for belt conveyor systems includes the following steps: S1. Obtain raw anomaly information from multiple independent sensing subsystems and transform the raw anomaly information into standardized structured event objects; S2. Based on the structured event object and according to the preset event-action rule library, automatically match the rules to generate a structured processing task corresponding to the structured event object; S3. Select the execution path based on the execution entity identifier in the structured processing task: If the execution entity identifier points to the intelligent execution equipment, the processing task is parsed into a low-level control command and sent to the intelligent execution equipment; If the execution entity identifier points to a mobile terminal, the processing task will be pushed to the mobile terminal in the form of a digital work order data packet; S4. Receive execution status feedback returned by the selected execution subject, create and track electronic work orders associated with the structured event object; when the received execution status feedback indicates successful execution, update the status of the electronic work order to completed.

2. The event-driven operation and maintenance control method for a belt conveyor system according to claim 1, characterized in that, Step S1, "converting the raw anomaly information into standardized structured event objects," specifically includes the following sub-steps: S11. Receive raw anomaly information from at least two sensing subsystems among the distributed fiber optic sensing system, high-definition industrial camera and infrared thermal imager through the event perception and aggregation module. S12. Perform a mandatory field integrity check on the original anomaly information. The mandatory fields include device identifier, event type, and occurrence time. S13. Based on the system's pre-set digital twin model, equipment topology and spatial coordinate mapping table, automatically fill in the missing required fields to generate complete event information; S14. Encapsulate the complete event information into a structured event object. The structured event object includes at least: identification information for uniquely identifying the event, device information for identifying the device from which the event originates, location information for indicating the location where the event occurs, event type information for classifying the event, level information for characterizing the urgency of the event, time information for recording the time when the event occurs, and data source link information for associating with the original data.

3. The event-driven operation and maintenance control method for a belt conveyor system according to claim 1, characterized in that, The "automatic rule matching based on a preset event-action rule base" mentioned in step S2 specifically includes: S21. The rule engine and decision module receive the structured event object and extract the event type and severity level fields from the object as the core matching key. S22. Match the core matching key with the preset rules in the event-action rule base; S23. If a match is found, a structured processing task is generated according to the processing actions defined in the rule. If a match fails, the structured event object is marked as an unhandled exception and pushed to the visualization and alerting center.

4. The event-driven operation and maintenance control method for a belt conveyor system according to claim 1, characterized in that, The steps in step S3 when the execution subject identifier points to the intelligent execution equipment include: S31. Parse the target equipment identifier, action type, and execution parameters from the structured processing task; S32. Based on the target equipment identifier, query the preset equipment instruction adaptation library to obtain the communication protocol type, data link layer format and data address mapping relationship of the equipment. S33. Map the action type and execution parameters to control command codes and execution parameter values ​​that the equipment can recognize, and generate the underlying control command frame; S34. Send the generated low-level control command frame to the corresponding intelligent execution equipment; S35. Establish an instruction monitoring mechanism to monitor and capture the execution status feedback returned by the intelligent execution equipment. The execution status feedback includes three states: success, failure, or exception.

5. The event-driven operation and maintenance control method for a belt conveyor system according to claim 1, characterized in that, Step S4 also includes: When the execution entity identifier points to the intelligent execution equipment and the captured execution status feedback indication is successful, the corresponding sensing subsystem is invoked to collect on-site data and compare it with the preset completion standard to generate an automatic verification result; wherein, the sensing subsystem includes at least one of vibration sensor, temperature sensor and image sensor for verifying the operation and maintenance effect.

6. The event-driven operation and maintenance control method for a belt conveyor system according to claim 5, characterized in that, The step of calling the corresponding sensing subsystem to collect on-site data and comparing it with a preset completion standard includes: Based on the geographical location in the structured event object, the corresponding sensing subsystem is invoked to collect on-site data; The collected data is compared with the standard threshold. If the standard is met, the automatic verification result is passed; otherwise, it is failed.

7. The event-driven operation and maintenance control method for a belt conveyor system according to claim 5, characterized in that, Receiving the completion signal from the mobile terminal in step S4 includes: When the automatic verification result is passed, the verification result data packet is pushed to the mobile terminal through the communication network. The system receives a signal frame from the mobile terminal in response to the verification result data packet. The signal frame carries a status code, a timestamp, and optional additional data fields.

8. The event-driven operation and maintenance control method for a belt conveyor system according to claim 1, characterized in that, After step S2 and before or simultaneously with step S3, the method further includes: displaying event information associated with the structured event object on a digital map built into the system, and pushing initial alarm information to the corresponding mobile terminal.

9. The event-driven operation and maintenance control method for a belt conveyor system according to claim 1, characterized in that, Following step S4, the following is also included: Complete cases of handling are recorded in the operation and maintenance knowledge base. The complete case includes at least: structured event object, matching rules, generated handling task, execution status feedback of intelligent execution equipment, automatic verification result, signal frame from mobile terminal, and original abnormal information that triggered the event. Based on case data in the operations and maintenance knowledge base, the event-action rule base is adjusted, added, or updated.

10. An event-driven operation and maintenance control system for a belt conveyor system, characterized in that, The method described in any one of claims 1-9 comprises: The event perception and aggregation module is used to receive raw abnormal information from multiple independent perception subsystems and transform the raw abnormal information into standardized structured event objects; The rules engine and decision module are used to receive the structured event objects and automatically generate corresponding structured processing tasks based on the preset event-action rule library. The task scheduling and execution control module is used to schedule execution based on the execution subject identifier in the structured task: if the execution subject identifier points to the intelligent execution equipment, the task is parsed into a low-level control command and sent to the intelligent execution equipment; if the execution subject identifier points to the mobile terminal, the task is pushed to the mobile terminal in the form of a digital work order data packet and feedback signals from the mobile terminal are received. The closed-loop management and feedback module is used to obtain execution status feedback, create and track electronic work orders, receive completion signals from mobile terminals, and update work order status. The closed-loop management and feedback module is also used to store complete cases in the operation and maintenance knowledge base, and to adjust, add or update the event-action rule base based on the case data.

Images