Cross-platform robot operation management system and method based on ROS-Kafka heterogeneous communication

Abstract

The invention discloses a cross-platform robot operation management system and method based on ROS-Kafka heterogeneous communication, a traditional ROS Bridge is replaced by a self-defined ROS-Kafka bridging node, and a heartbeat detection mechanism and Protobuf protocol compression are combined, so that the communication stability is remarkably improved, and the communication efficiency is improved. And load balancing of an emergency instruction exclusive partition and a conventional task hash partition is realized based on a Kafka theme dynamic partition strategy. The system integrates a multi-mode sensor fusion technology to trigger three-level safety response, task interruption time is shortened from 45 seconds to less than or equal to 15 seconds, meanwhile, bolt loosening frequency is counted, short-term and long-term early warning rules are combined, a purchase work order is automatically generated, and railway operation and maintenance are promoted to be transformed from post maintenance to preventive maintenance. In addition, the layered architecture supports cross-platform deployment, hardware-level sudden stop and sound-light alarm linkage are integrated, the accident rate is greatly reduced, and the operation safety and the operation and maintenance efficiency are remarkably improved.

Description

Technical Field

[0001] The present invention relates to the technical field of railway overhead line maintenance automation, and in particular to a cross-platform robot operation management system and method based on ROS-Kafka heterogeneous communication. Background Art

[0002] The catenary system is a core component of electrified railways, responsible for providing a stable power supply to trains. Its operating status directly impacts the safety and efficiency of train operations. In particular, the stability of the catenary arm bolts in the traction power supply system is crucial for ensuring reliable operation of electrified railways. Catenary arm maintenance involves complex tasks such as tightening bolts and cleaning insulators. Traditional manual labor is inefficient and poses safety risks. With the advancement of robotics, automated maintenance systems are gradually being implemented, but existing robotic operation management systems have limitations.

[0003] Traditional systems use ROS Bridge to enable communication between robots (ROS environments) and external systems (such as web management platforms), but ROS Bridge suffers from poor stability, high latency, and low throughput. "ROS-Kafka Gateway for Scalable, Remote and Cross-Platform Robotic System Communication" proposes a general communication solution, but it fails to consider the image transmission requirements of catenary maintenance (such as the large amount of visual positioning data), making it difficult to meet real-time task scheduling requirements. Furthermore, for railway catenary maintenance scenarios, a single inspection can take several hours, and existing general ROS-Kafka solutions lack a heartbeat detection mechanism designed for this scenario. Furthermore, existing management systems are often developed based on a single platform, making it difficult to integrate web front-ends (such as Vue), back-end services (such as Java / Spring Boot), and robot control (ROS), resulting in inefficient interactions. Furthermore, there is a lack of efficient exception response mechanisms during task execution (such as the manual intervention process after a bolt tightening failure), leading to job interruptions or repeated operations. Furthermore, traditional systems only record basic operational data and fail to leverage historical information for proactive maintenance. Bolt loosening or failure requires post-repair, resulting in high operational costs and significant safety risks. Existing technologies lack early warning rules based on loosening frequency (e.g., ≥3 loosenings within 30 days) or long-term trends (annual loosening frequency exceeding twice the category average), making it difficult to support the transition to preventive maintenance. Summary of the Invention

[0004] In order to solve the problems of communication architecture defects, insufficient cross-platform compatibility, weak exception handling capabilities and insufficient data-driven capabilities in the robot operation management system in the prior art, the present invention proposes a cross-platform robot operation management system and method based on ROS-Kafka heterogeneous communication to solve the above problems.

[0005] This application discloses a cross-platform robot operation management system based on ROS-Kafka heterogeneous communication, including:

[0006] The front-end interaction layer uses the Vue framework to build a responsive web interface, integrating the task management module, real-time monitoring module, and abnormal alarm module;

[0007] The backend service layer implements the business logic engine based on the Spring Boot framework, configures the Kafka message queue, and defines three topics: routine tasks, emergency instructions, and status feedback. It implements priority scheduling through a dynamic partitioning strategy.

[0008] The communication adaptation layer deploys ROS-Kafka bridge nodes, integrates the librdkafka library, implements bidirectional conversion between ROS messages and the Kafka protocol, uses the Protobuf protocol for serialization and compression, and configures a heartbeat detection mechanism.

[0009] The robot execution layer is equipped with a robotic arm vision module, a tightening gun and a force sensor, and achieves high-precision operations through multi-source data fusion algorithms and visual servo control.

[0010] Preferably, the dynamic partitioning strategy includes allocating exclusive partitions for urgent instructions and allocating hash partitions for regular tasks.

[0011] Preferably, the heartbeat detection mechanism is as follows:

[0012] Send heartbeat packets to Kafka's heartbeat topic every 500ms. If the timeout exceeds 3 times, automatic reconnection will be triggered.

[0013] This application also discloses a cross-platform robot job management method based on ROS-Kafka heterogeneous communication, which is implemented based on the above-mentioned cross-platform robot job management system and includes the following steps:

[0014] S1. Task initialization and parameter configuration, including parameter configuration and instruction issuance for bolt tightening tasks and insulator cleaning tasks;

[0015] S2, command transmission and robotic arm control, achieves cross-platform communication through a custom ROS-Kafka bridge node, parses commands, maintains communication links based on heartbeat detection, and controls the robotic arm to perform operations;

[0016] S3, real-time monitoring and anomaly detection, real-time collection of torque values and visual positioning data, triggering a three-level safety response mechanism;

[0017] S4, manual intervention and task continuation, switching the control mode after responding to an exception and recording breakpoint information, supporting manual adjustment and task recovery from breakpoints;

[0018] S5. Data archiving and preventive maintenance: store operation records and count the frequency of bolt loosening, generate early warning work orders and push them.

[0019] Preferably, said S1 comprises the following steps:

[0020] S11. Initialization of bolt tightening task:

[0021] The operator selects the target arm and bolt through the front-end interface, loads the bolt information and displays it in a 3D highlighted form;

[0022] The backend generates a unique task ID, encapsulates the bolt coordinates and preset torque value into a Protobuf message, and sends it through the bolt_tighten_command topic of Kafka;

[0023] Task metadata is written to the Tightening_Records table in MySQL;

[0024] S12, insulator cleaning task initialization:

[0025] The operator starts the cleaning task through the front-end interface. The system automatically identifies the insulator position and uses visual servoing to the target position to start cleaning.

[0026] The backend encapsulates the path coordinate sequence as a Protobuf message and sends it through the insulator_clean_command topic of Kafka;

[0027] Task metadata is written to the Cleaning_Records table in MongoDB.

[0028] Preferably, said S2 comprises the following steps:

[0029] S21. Listen to the Kafka topic through the ROS-Kafka bridge node and deserialize the received Protobuf message into the ROS standard message format.

[0030] S22. Heartbeat detection mechanism: The ROS-Kafka bridge node sends a heartbeat packet to Kafka's heartbeat topic every 500ms. If it times out three times, it will trigger an automatic reconnection.

[0031] S23. When the bolt is tightened, the robot arm moves to the target bolt position, and the tightening gun collects the torque value in real time and feeds it back to the front end;

[0032] S24. When the insulator cleaning is executed, the depth camera locates the insulator position in real time, and the robotic arm moves according to the cleaning path and controls the nozzle operation.

[0033] Preferably, the three-level security response mechanism in S3 includes:

[0034] If the average value of five consecutive samples is lower than 95% of the preset value, a warning will be triggered and the task priority will be upgraded;

[0035] If the visual positioning error is ≥ 2cm for 3 consecutive frames, or the insulator positioning fails, a pause command is triggered and the breakpoint information is recorded;

[0036] If a high-priority exception is detected, an emergency stop command is issued through the exclusive partition.

[0037] Preferably, the manual intervention in S4 includes:

[0038] After receiving the abnormal code, the front end pops up a warning window and switches the robotic arm to manual control mode;

[0039] The operator uses the virtual joystick to adjust the robot arm position or nozzle angle, and clicks the resume button to resume the task after completion.

[0040] Preferably, the S5 comprises the following steps:

[0041] S51. The torque value, operator ID, and operation results of the bolt operation are written to the Tightening_Records table of MySQL.

[0042] S52. The insulator cleaning operation time, the cleaning insulator number, and the operator ID are written to the Cleaning_Records table of MongoDB.

[0043] S53. Scan the bolt loosening records daily and count the bolts that have loosened 3 or more times within 30 days;

[0044] S54. Generate a purchase work order and push it to the front-end interface and Kafka's replacement_alert topic.

[0045] Beneficial effects of the present invention:

[0046] (1) Communication stability and real-time performance are significantly improved: Through customized ROS-Kafka bridge nodes, heartbeat detection mechanism and Protobuf protocol compression, cross-platform communication efficiency is optimized, bandwidth usage is reduced by 30%, communication failure rate is reduced from 8.5% to 3.2%, and instruction delay is ≤50ms, meeting the needs of high-concurrency real-time operations.

[0047] (2) Cross-platform collaboration and dynamic expansion of multiple robotic arms: The layered architecture and Kafka dynamic partitioning strategy support multi-platform deployment, can support dual robotic arms collaborative operation, improve task parallel processing efficiency, and adapt to complex maintenance scenarios.

[0048] (3) Efficient abnormal response and task continuation mechanism: The three-level safety response is combined with the breakpoint resume design, the emergency command response delay is ≤10ms, the hardware emergency stop response is ≤20ms, the task interruption time is shortened to ≤15 seconds, the efficiency of manual intervention is improved, and the continuity and safety of operations are guaranteed.

[0049] (4) Data-driven preventive maintenance and operation and maintenance optimization: Spark-based analysis of bolt loosening frequency automatically generates work orders, promotes "preventive maintenance", and realizes proactive and intelligent operation and maintenance management. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] Figure 1 This is a schematic diagram of the architecture of a cross-platform robot operation management system based on ROS-Kafka heterogeneous communication according to an embodiment of the present invention;

[0051] Figure 2 This is a flow chart of a cross-platform robot job management method based on ROS-Kafka heterogeneous communication according to an embodiment of the present invention. DETAILED DESCRIPTION

[0052] In order to make the objectives, technical solutions and advantages of this application more clear, the application is further described in detail below with reference to the accompanying drawings and examples.

[0053] One embodiment of the present application discloses a cross-platform robot operation management system based on ROS-Kafka heterogeneous communication, whose architecture is as follows: Figure 1 As shown, including:

[0054] The front-end interaction layer uses the Vue 3.0 framework to build a responsive web interface, integrating task management module, real-time monitoring module and abnormal alarm module, and supports three-dimensional visualization and dynamic data rendering.

[0055] The backend service layer implements a business logic engine based on the Spring Boot framework and configures a Kafka 3.0 message queue for command distribution. It defines three topics: task_command (routine tasks), emergency_stop (emergency commands), and robot_status (status feedback). Priority scheduling is achieved through a dynamic partitioning strategy, which allocates exclusive partitions for emergency commands and hash partitions for routine tasks.

[0056] The communication adaptation layer develops a custom Kafka bridge node in ROS Noetic, integrating the librdkafka library to implement bidirectional conversion between ROS messages (std_msgs and sensor_msgs) and the Kafka protocol. Protobuf v3.15 is used for serialization and compression to reduce message size. A heartbeat detection mechanism is configured: heartbeat packets are sent to the Kafka heartbeat topic every 500ms, and three timeouts trigger automatic reconnection.

[0057] The robot execution layer is equipped with a robotic arm (UR12e), an Intel RealSense D456i vision module, a Mech-EyeNANO ULTRA depth camera, an SMG-SF-200 tightening gun, and a force sensor. It achieves high-precision operations based on a multi-source data fusion algorithm (i.e., an image and point cloud fusion algorithm, using YOLO for coarse positioning and a point cloud algorithm for fine positioning) and visual servo control.

[0058] The front-end interaction layer and the back-end service layer are linked via WebSocket, the back-end service layer and the communication adaptation layer transmit data via binary streams, and the communication adaptation layer transmits data via ROS topic commands. The Vue Web interface of the front-end interaction layer includes task management, real-time monitoring, and exception warning interfaces. The back-end server includes task parsing and data storage of Spring Boot services, and the Kafka cluster includes commands such as task_command. The ros-kafka bridge node of the communication adaptation layer includes protobuf serialization and a disconnection reconnection mechanism. The robot execution layer includes functions such as A* path planning and visual servoing of the robotic arm, positioning through radar and cameras, and force sensors to confirm that the robotic arm has inserted bolts.

[0059] This embodiment proposes a cross-platform robotic operation management system based on ROS-Kafka heterogeneous communication. This system replaces the traditional ROS Bridge with a ROS-Kafka bridge. Experiments show that the ROS Bridge has an 8.5% disconnection rate, while this embodiment's disconnection rate is 3.2%, reducing the communication failure rate by 62% and minimizing data latency. Furthermore, it supports collaboration across multiple environments, including Windows (front-end), Linux (ROS robots), and Java services (back-end), significantly shortening system deployment cycles and ensuring cross-platform compatibility.

[0060] Another embodiment of the present application discloses a cross-platform robot job management method based on ROS-Kafka heterogeneous communication, the process of which is as follows: Figure 2 As shown, the implementation based on the above cross-platform robot operation management system includes the following steps:

[0061] S1. Task initialization and parameter configuration, including parameter configuration and instruction issuance for bolt tightening tasks and insulator cleaning tasks.

[0062] S11. Initialization of bolt tightening task:

[0063] Front-end operation: The operator selects the target arm (e.g., "Arm Segment A3") through the Vue front-end interface. The system automatically loads information for all bolts under that arm (from the Bolt_Info table) and displays them in a three-dimensional, highlighted format (green indicates repaired, red indicates pending repair). The robotic arm selects a specific bolt according to pre-set settings (e.g., Bolt_ID = "B5") and enters a preset torque value (e.g., 50 N·m) and priority (normal / urgent).

[0064] Backend processing: The Spring Boot backend generates a unique task ID (format: TASK_20231001_001), encapsulates the task parameters (bolt coordinates, preset torque, etc.) into a Protobuf message (BoltCommand.proto), and sends it through the bolt_tighten_command topic of Kafka.

[0065] Task metadata (task ID, operator ID, timestamp, etc.) is written to the Tightening_Records table in MySQL.

[0066] S12, insulator cleaning task initialization:

[0067] Front-end operation: The operator starts the cleaning task through the front-end interface. The system automatically identifies the insulator position and visually servoes to the target position to start cleaning.

[0068] Backend processing: The backend calls the point cloud processing algorithm, rasterizes the selected area into a cleaning path (coordinate sequence), encapsulates it into a Protobuf message (CleanCommand.proto), and sends it through the insulator_clean_command topic of Kafka.

[0069] Task metadata (insulator location, cleaning duration, etc.) is written to the Cleaning_Records table in MongoDB.

[0070] S2, command transmission and robotic arm control, achieves cross-platform communication through a custom ROS-Kafka bridge node, parses commands and maintains the communication link based on heartbeat detection to control the robotic arm to perform operations.

[0071] S21. Communication adaptation layer processing: The ROS-Kafka bridge node listens to the bolt_tighten_command and insulator_clean_command topics. After receiving the Protobuf message, it deserializes it into the ROS standard message format (such as std_msgs / Float32 for torque commands and geometry_msgs / Point for coordinate commands).

[0072] S22. Heartbeat detection mechanism: The ROS-Kafka bridge node sends a heartbeat packet (including node status and timestamp) to Kafka's heartbeat topic every 500ms. If no response is received for three consecutive times, the reconnection mechanism is triggered and the command is temporarily stored in the retransmission queue.

[0073] S23, Robotic arm execution control:

[0074] Bolt tightening execution: The UR12e robot arm receives the target coordinates through the ROS / arm_control topic and moves to the bolt position (error tolerance ±5mm).

[0075] The SMG-SF-200 tightening gun is started, and the force sensor collects the actual torque value at a frequency of 50Hz, feeds it back to the / torque_feedback topic of ROS in real time, and synchronizes it to the front-end interface.

[0076] S24, Insulator cleaning execution: The Mech-Eye NANO ULTRA depth camera captures the insulator's position in real time, the robotic arm moves along the cleaning path, the high-pressure nozzle sprays cleaning fluid at high water pressure, and the end effector begins clamping and cleaning.

[0077] S3: Real-time monitoring and anomaly detection, real-time collection of torque values and visual positioning data, triggering a three-level safety response mechanism.

[0078] Abnormal determination of bolt operation: If the average value of 5 consecutive samples is less than 95% of the preset value (i.e., less than 47.5N·m), the E101 abnormal code is triggered and the priority is raised to a high level.

[0079] Visual positioning failure: The MSFF algorithm calculates the bolt center coordinates. If the positioning error for three consecutive frames is ≥ 2 cm, the E102 exception code is triggered and the current task is suspended.

[0080] Insulator operation abnormality judgment: Insulator positioning fails, triggering E102 abnormal code and pausing the current task.

[0081] Emergency command processing:

[0082] High-priority exceptions (such as E101) are sent exclusively to partition 0 of the emergency_stop topic of Kafka. The consumer thread monitors the exception in real time, and the robotic arm stops suddenly within 10ms (hard power is cut off to the motor).

[0083] Regular task resumption: If the exception is a recoverable type (such as E102 positioning deviation), the system automatically records the breakpoint information (current bolt ID, executed steps) and resumes from the breakpoint after manual intervention.

[0084] S4, manual intervention and task continuation, switching control mode after responding to an exception and recording breakpoint information, supporting task recovery from breakpoints after manual adjustment.

[0085] Pop-up prompt: The front end receives an exception code (such as E101) through WebSocket, pops up a warning window ("Insufficient torque for bolt B5, please intervene"), and highlights the abnormal bolt in flashing red.

[0086] Manual mode switching: When the operator clicks the "Manual Assist" button, the system switches the control of the robotic arm to manual mode. The front-end interface enables the virtual joystick control, which supports manual adjustment of the robotic arm's position or nozzle angle.

[0087] Bolt tightening continuation: After the operator adjusts the robotic arm to the correct position, he clicks "Continue Task". The backend reads the breakpoint information from the Tightening_Records table in MySQL (for example, bolt B5 has been tightened), and the robotic arm continues to execute the remaining steps.

[0088] Insulator cleaning and continuation: If the automatic retry fails, the operator manually adjusts the end effector posture. After completion, the system continues cleaning from the breakpoint.

[0089] S5. Data archiving and preventive maintenance: store operation records and count the frequency of bolt loosening, generate early warning work orders and push them.

[0090] S51. Bolt operation data: The torque value, operator ID, and operation result (Success / E101 / E102) of the bolt operation are written to the Tightening_Records table in MySQL, supporting fast retrieval by bolt ID (B+ tree index, latency ≤ 5ms).

[0091] S52. Insulator operation data: The insulator cleaning operation time, cleaning insulator number, and operator ID are written to the Cleaning_Records table of MongoDB, supporting aggregate queries by time range.

[0092] S53. Bolt loosening warning: Scan the Bolt_Info table daily to obtain bolt loosening records. Count the bolts that have loosened 3 or more times within 30 days and mark them as "need to be replaced."

[0093] S54. Automatically generate a purchase order (including bolt specifications, location, and supplier information) and push it to the highlighted front-end interface and Kafka's replacement_alert topic.

[0094] To meet the needs of bolt information storage and maintenance record management, this application proposes the following three standardized data tables to ensure data consistency, reduce redundancy, and support efficient query.

[0095] Table 1 Arm information table (Arm_Info)

[0096]

[0097]

[0098] Table 2 Bolt information table (Bolt_Info)

[0099]

[0100] Table 3 Tightening Records

[0101]

[0102]

[0103] Table 4 Cleaning Records

[0104]

[0105] The basic principles, main features, and advantages of the present invention are shown and described above. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The above embodiments and descriptions are merely illustrative of the principles of the present invention. Various changes and modifications may be made to the present invention without departing from the spirit and scope of the present invention. Such changes and modifications are intended to fall within the scope of the present invention. The scope of protection claimed in the present invention is defined by the appended claims and their equivalents.

Claims

1. A cross-platform robot operation management system based on ROS-Kafka heterogeneous communication, characterized in that: include: The front-end interaction layer uses the Vue framework to build a responsive web interface, integrating the task management module, real-time monitoring module, and abnormal alarm module; The backend service layer implements the business logic engine based on the Spring Boot framework, configures the Kafka message queue, and defines three topics: routine tasks, emergency instructions, and status feedback. It implements priority scheduling through a dynamic partitioning strategy. The communication adaptation layer deploys ROS-Kafka bridge nodes, integrates the librdkafka library, implements bidirectional conversion between ROS messages and the Kafka protocol, uses the Protobuf protocol for serialization and compression, and configures a heartbeat detection mechanism. The robot execution layer is equipped with a robotic arm vision module, a tightening gun and a force sensor, and achieves high-precision operations through multi-source data fusion algorithms and visual servo control.

2. The cross-platform robot operation management system based on ROS-Kafka heterogeneous communication according to claim 1 is characterized in that: The dynamic partitioning strategy includes allocating exclusive partitions for urgent instructions and allocating hash partitions for regular tasks.

3. The cross-platform robot operation management system based on ROS-Kafka heterogeneous communication according to claim 2 is characterized in that: The heartbeat detection mechanism is as follows: Send heartbeat packets to Kafka's heartbeat topic every 500ms. If the timeout exceeds 3 times, automatic reconnection will be triggered.

4. A cross-platform robot job management method based on ROS-Kafka heterogeneous communication, characterized in that: The cross-platform robot operation management system according to any one of claims 1 to 3 is implemented, comprising the following steps: S1. Task initialization and parameter configuration, including parameter configuration and instruction issuance for bolt tightening tasks and insulator cleaning tasks; S2, command transmission and robotic arm control, achieves cross-platform communication through a custom ROS-Kafka bridge node, parses commands, maintains communication links based on heartbeat detection, and controls the robotic arm to perform operations; S3, real-time monitoring and anomaly detection, real-time collection of torque values and visual positioning data, triggering a three-level safety response mechanism; S4, manual intervention and task continuation, switching the control mode after responding to an exception and recording breakpoint information, supporting manual adjustment and task recovery from breakpoints; S5. Data archiving and preventive maintenance: store operation records and count the frequency of bolt loosening, generate early warning work orders and push them.

5. The cross-platform robot operation management method based on ROS-Kafka heterogeneous communication according to claim 4 is characterized in that: Said S1 comprises the following steps: S11. Initialization of bolt tightening task: The operator selects the target arm and bolt through the front-end interface, loads the bolt information and displays it in a 3D highlighted form; The backend generates a unique task ID, encapsulates the bolt coordinates and preset torque value into a Protobuf message, and sends it through the bolt_tighten_command topic of Kafka; Task metadata is written to the Tightening_Records table in MySQL; S12, insulator cleaning task initialization: The operator starts the cleaning task through the front-end interface. The system automatically identifies the insulator position and uses visual servoing to the target position to start cleaning. The backend encapsulates the path coordinate sequence as a Protobuf message and sends it through the insulator_clean_command topic of Kafka; Task metadata is written to the Cleaning_Records table in MongoDB.

6. The cross-platform robot operation management method based on ROS-Kafka heterogeneous communication according to claim 5 is characterized in that: The S2 comprises the following steps: S21. Listen to the Kafka topic through the ROS-Kafka bridge node and deserialize the received Protobuf message into the ROS standard message format. S22. Heartbeat detection mechanism: The ROS-Kafka bridge node sends a heartbeat packet to Kafka's heartbeat topic every 500ms. If it times out three times, it will trigger an automatic reconnection. S23. When the bolt is tightened, the robot arm moves to the target bolt position, and the tightening gun collects the torque value in real time and feeds it back to the front end; S24. When the insulator cleaning is executed, the depth camera locates the insulator position in real time, and the robotic arm moves according to the cleaning path and controls the nozzle operation.

7. The cross-platform robot operation management method based on ROS-Kafka heterogeneous communication according to claim 6 is characterized in that: The three-level security response mechanism in S3 includes: If the average value of five consecutive samples is lower than 95% of the preset value, a warning will be triggered and the task priority will be upgraded; If the visual positioning error is ≥ 2cm for 3 consecutive frames, or the insulator positioning fails, a pause command is triggered and the breakpoint information is recorded; If a high-priority exception is detected, an emergency stop command is issued through the exclusive partition.

8. The cross-platform robot operation management method based on ROS-Kafka heterogeneous communication according to claim 7 is characterized in that: The manual intervention in S4 includes: After receiving the abnormal code, the front end pops up a warning window and switches the robotic arm to manual control mode; The operator uses the virtual joystick to adjust the robot arm position or nozzle angle, and clicks the resume button to resume the task after completion.

9. The cross-platform robot operation management method based on ROS-Kafka heterogeneous communication according to claim 8 is characterized in that: The S5 comprises the following steps: S51. The torque value, operator ID, and operation results of the bolt operation are written to the Tightening_Records table of MySQL. S52. The insulator cleaning operation time, the cleaning insulator number, and the operator ID are written to the Cleaning_Records table of MongoDB. S53. Scan the bolt loosening records daily and count the bolts that have loosened 3 or more times within 30 days; S54. Generate a purchase work order and push it to the front-end interface and Kafka's replacement_alert topic.

Images