A control method, device, equipment and medium of an underground engineering machine

Abstract

The application provides a control method, device, equipment and medium of an underground engineering machine, the method comprising: collecting real-time running data of multi-dimensional key topics in the automatic driving process of an underground engineering environment, the key topics representing data flow channels for data interaction between functional modules of a vehicle-mounted perception layer, a control layer, a communication layer and a decision layer; respectively performing abnormal diagnosis on the real-time running data of each dimension key topic to obtain a target diagnosis result; and switching the running state of the underground engineering machine according to the target diagnosis result. The abnormal diagnosis includes topic health diagnosis, collision detection diagnosis, positioning accuracy diagnosis, path tracking diagnosis and communication timeout diagnosis. The application realizes full-link multi-dimensional collaborative monitoring and diagnosis control direct closed loop of the data interaction state between each functional module of the vehicle, can independently run in an underground environment without external network, and improves the safety and reliability of the automatic driving of the underground engineering machine.

Description

Technical Field

[0001] This application relates to the field of autonomous driving technology, and more specifically, to a control method, device, equipment, and medium for underground engineering machinery. Background Technology

[0002] Automatic driving of underground construction machinery is an important development direction for improving the efficiency and safety of construction operations in mines, tunnels, underground utility tunnels, and other engineering projects. The underground engineering environment is characterized by complex spatial structures, confined spaces, and easily interrupted communication, which places stringent requirements on the fault diagnosis and safety control of automatic driving systems.

[0003] Currently, fault diagnosis technologies for autonomous vehicles mainly suffer from the following problems: First, the diagnostic coverage is limited, often focusing on independent testing of single-level sensors or actuators, lacking end-to-end monitoring of the data interaction status between functional modules at the perception, control, communication, and decision-making levels, making it difficult to comprehensively reflect the overall operational health of the system. Second, there is a lack of effective linkage between diagnostic logic and control response. Existing solutions often require manual intervention or complex intermediate processing steps to trigger vehicle state switching after detecting anomalies, failing to achieve a rapid closed-loop response from anomaly identification to state control. Third, the implementation of diagnostic functions largely relies on cloud or external networks for data aggregation and decision calculation. In underground engineering network blind spots or communication interruption scenarios, the availability and real-time performance of diagnostic functions are difficult to guarantee.

[0004] In summary, existing technologies in underground engineering environments suffer from problems such as incomplete diagnostic coverage, disconnect between diagnosis and control, and reliance on external networks. There is an urgent need for a solution that can operate autonomously in a closed underground working environment, perform multi-dimensional monitoring of the data interaction status between various onboard functional modules, and directly link vehicle status control. Summary of the Invention

[0005] In view of this, the purpose of this application is to provide a control method, device, equipment and medium for underground engineering machinery to overcome the problems in the prior art.

[0006] In a first aspect, embodiments of this application provide a control method for underground engineering machinery, which operates on an on-board edge controller, the method comprising: During the autonomous driving process of underground engineering machinery in underground engineering environments, real-time operational data on multiple key topics are collected; wherein, the key topics represent the data flow channels for data interaction between the functional modules of the vehicle perception layer, control layer, communication layer and decision-making layer. Anomaly diagnosis is performed on the real-time operational data of the key topics mentioned in each dimension to obtain the target diagnostic results; Based on the target diagnosis results, switch the operating status of the underground engineering machinery.

[0007] In some technical solutions of this application, the aforementioned real-time operational data of underground engineering machinery during automatic driving in underground engineering environments is collected from multiple dimensions of key aspects, including: Collect LiDAR data, IMU sensor data, map information data, point cloud stitching data, front axle pose data, and rear axle pose data from the environmental perception dimension; Collect steering sensor data, boom sensor data, and bucket sensor data in the execution feedback dimension; Collect intelligent driving and chassis communication data and CMOA communication data in the communication status dimension; Collect data from the task control module, obstacle detection module, and access control system in the decision-making and security dimensions.

[0008] In some technical solutions of this application, anomaly diagnosis is performed on the real-time operational data of the key topics for each dimension to obtain target diagnostic results, including: By performing topic health diagnosis on the real-time operational data of key topics in each dimension, a first sub-result is obtained that characterizes whether the data transmission frequency of each key topic is abnormal. Collision detection and diagnosis are performed on real-time operational data of key topics in the environmental perception dimension to obtain a second sub-result that characterizes the surrounding collision risk level; The positioning accuracy is diagnosed by performing real-time operation data on key topics in the environmental perception dimension, and a third sub-result is obtained to characterize whether the positioning matching degree is abnormal. The real-time running data of key topics in the execution feedback dimension are tracked for accuracy diagnosis to obtain a fourth sub-result that characterizes whether the path tracking deviation exceeds the limit; The real-time operational data of key topics in the communication status dimension are used to diagnose communication timeouts, resulting in a fifth sub-result that characterizes whether the communication heartbeat of each functional module has timed out. The target diagnostic result is generated based on the first sub-result, the second sub-result, the third sub-result, the fourth sub-result, and the fifth sub-result.

[0009] In some technical solutions of this application, the generation of the target diagnostic result based on the first sub-result, the second sub-result, the third sub-result, the fourth sub-result, and the fifth sub-result includes: Based on the first sub-result, the second sub-result, the third sub-result, the fourth sub-result, and the fifth sub-result, determine the corresponding control event; Based on the preset priority, the control event with the highest priority is selected as the target diagnostic result.

[0010] In some technical solutions of this application, the determination of the corresponding control event based on the first sub-result, the second sub-result, the third sub-result, the fourth sub-result, and the fifth sub-result includes: When the first sub-result indicates that there is a topic health abnormality, the corresponding control event is determined to be a stop event; When the second sub-result indicates a safe collision risk level, the corresponding control event is determined to be a recovery event; when the second sub-result indicates a warning collision risk level, the corresponding control event is determined to be a deceleration event; when the second sub-result indicates a dangerous collision risk level, the corresponding control event is determined to be an emergency stop event. When the third sub-result indicates an abnormality in positioning accuracy, the corresponding control event is determined to be a stop event; When the fourth sub-result indicates a path tracking anomaly, the corresponding control event is determined to be an emergency stop event; When the fifth sub-result indicates a communication timeout exception, the corresponding control event is determined to be a stop event.

[0011] In some technical solutions of this application, the above-mentioned switching of the operating state of the underground engineering machinery based on the target diagnosis results includes: When the target diagnostic result is a recovery event, control the underground engineering machinery to switch from decelerated operation to normal operation. When the target diagnosis result is a deceleration event, control the underground engineering machinery to switch from normal operation to deceleration operation; When the target diagnostic result is a stop event, control the underground engineering machinery to switch from normal operation or reduced speed operation to a stop state; When the target diagnosis result is an emergency stop event, control the underground engineering machinery to switch from normal operation or deceleration operation to emergency stop; When the target diagnostic result is a reset event, the underground engineering machinery is controlled to switch from a reduced speed operation state, a normal operation state, or a stopped state to an uninitialized state.

[0012] In some technical solutions of this application, the above method also includes: After the underground engineering machinery is started, communication timeout diagnosis is performed on the communication heartbeats corresponding to each key topic; when there is no communication timeout abnormality for all key topics within the first set time period, an initialization event is generated to control the vehicle to switch from the uninitialized state to the decelerated operation state. If any key topic experiences a communication timeout exception within the first set time period, the timer restarts until all key topics simultaneously meet the condition that there are no communication timeout exceptions within the first set time period.

[0013] Secondly, embodiments of this application provide a control device for underground engineering machinery, residing in an on-board edge controller, the device comprising: The data acquisition module is used to collect real-time operational data on multiple key topics during the autonomous driving process of underground engineering machinery in underground engineering environments; wherein, the key topics represent the data flow channels for data interaction between the functional modules of the vehicle perception layer, control layer, communication layer and decision layer. The diagnostic decision module is used to perform anomaly diagnosis on the real-time running data of the key topics in each dimension, and obtain the target diagnostic results. The status management module is used to switch the operating status of the underground engineering machinery based on the target diagnosis results.

[0014] Thirdly, embodiments of this application provide an electronic device, a processor, a memory, and a bus. The memory stores machine instructions executed by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine instructions are executed by the processor, the steps of the control method for the underground engineering machinery described above are performed.

[0015] Fourthly, embodiments of this application provide a computer storage medium storing a computer program, which, when run by a processor, executes the steps of the control method for the underground engineering machinery described above.

[0016] The technical solutions provided by the embodiments of this application may include the following beneficial effects: This application provides a control method for underground construction machinery, applied to an on-board edge controller. The method includes: collecting real-time operational data of multi-dimensional key topics during the autonomous driving process of the underground construction machinery in an underground engineering environment; wherein, the key topics represent the data flow channels for data interaction between various functional modules of the on-board perception layer, control layer, communication layer, and decision layer; performing anomaly diagnosis on the real-time operational data of each dimension of the key topics to obtain target diagnosis results; and switching the operating state of the underground construction machinery according to the target diagnosis results.

[0017] This application collects real-time operational data on multiple key aspects during autonomous driving in underground engineering environments, and incorporates the data interaction status between various functional modules into unified monitoring. This achieves full-link coverage of the data flow channels of the perception layer, control layer, communication layer, and decision-making layer, overcoming the shortcomings of existing technologies that only perform independent detection on a single level, resulting in an inability to comprehensively assess the system's operational health. On this basis, anomaly diagnosis is performed on the real-time operational data of each key aspect, which can promptly detect anomalies in different data flow channels and directly switch the operating status of underground engineering machinery based on the diagnostic results. This achieves a rapid closed-loop response from anomaly identification to vehicle status control, avoiding the problem of disconnect between diagnosis and control.

[0018] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 A flowchart illustrating a control method for underground engineering machinery provided in an embodiment of this application is shown. Figure 2 A schematic diagram of a control device for underground engineering machinery provided in an embodiment of this application is shown; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0022] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0023] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0024] Automatic driving of underground construction machinery is an important development direction for improving the efficiency and safety of construction operations in mines, tunnels, underground utility tunnels, and other engineering projects. The underground engineering environment is characterized by complex spatial structures, confined spaces, and easily interrupted communication, which places stringent requirements on the fault diagnosis and safety control of automatic driving systems.

[0025] Currently, fault diagnosis technologies for autonomous vehicles mainly suffer from the following problems: First, the diagnostic coverage is limited, often focusing on independent testing of single-level sensors or actuators, lacking end-to-end monitoring of the data interaction status between functional modules at the perception, control, communication, and decision-making levels, making it difficult to comprehensively reflect the overall operational health of the system. Second, there is a lack of effective linkage between diagnostic logic and control response. Existing solutions often require manual intervention or complex intermediate processing steps to trigger vehicle state switching after detecting anomalies, failing to achieve a rapid closed-loop response from anomaly identification to state control. Third, the implementation of diagnostic functions largely relies on cloud or external networks for data aggregation and decision calculation. In underground engineering network blind spots or communication interruption scenarios, the availability and real-time performance of diagnostic functions are difficult to guarantee.

[0026] In summary, existing technologies in underground engineering environments suffer from problems such as incomplete diagnostic coverage, disconnect between diagnosis and control, and reliance on external networks. There is an urgent need for a solution that can operate autonomously in a closed underground working environment, perform multi-dimensional monitoring of the data interaction status between various onboard functional modules, and directly link vehicle status control.

[0027] Based on this, the present application provides a control method, device, equipment and medium for underground engineering machinery, which will be described below through embodiments.

[0028] Figure 1 The diagram illustrates a flow chart of a control method for underground engineering machinery provided in an embodiment of this application, wherein the method includes steps S101-S103; specifically: S101. During the autonomous driving process of underground engineering machinery in underground engineering environment, real-time operation data of multi-dimensional key topics are collected; wherein, the key topics represent the data flow channels for data interaction between the functional modules of the vehicle perception layer, control layer, communication layer and decision layer. S102. Perform anomaly diagnosis on the real-time running data of the key topics in each dimension to obtain the target diagnosis results; S103. Based on the target diagnosis results, switch the operating status of the underground engineering machinery.

[0029] This application collects real-time operational data on multiple key aspects during autonomous driving in underground engineering environments, and incorporates the data interaction status between various functional modules into unified monitoring. This achieves full-link coverage of the data flow channels of the perception layer, control layer, communication layer, and decision-making layer, overcoming the shortcomings of existing technologies that only perform independent detection on a single level, resulting in an inability to comprehensively assess the system's operational health. On this basis, anomaly diagnosis is performed on the real-time operational data of each key aspect, which can promptly detect anomalies in different data flow channels and directly switch the operating status of underground engineering machinery based on the diagnostic results. This achieves a rapid closed-loop response from anomaly identification to vehicle status control, avoiding the problem of disconnect between diagnosis and control.

[0030] The following describes some embodiments of this application in detail. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0031] This application provides a control method for underground construction machinery. The underground construction machinery can be self-propelled engineering equipment used in enclosed or semi-enclosed construction scenarios such as mines, tunnels, and underground utility tunnels, including rock drilling rigs, loaders, underground dump trucks, anchor bolt rigs, and concrete spraying robotic arms. It can also be other special vehicles with autonomous driving capabilities that perform specific engineering tasks in underground environments. These underground construction machines typically need to operate continuously in complex geological structures hundreds or even thousands of meters underground, facing extreme conditions such as confined spaces, insufficient lighting, high dust concentrations, drastic temperature and humidity changes, and severe attenuation of wireless communication signals. This places far more stringent requirements on the environmental adaptability, fault self-diagnosis capabilities, and safety protection levels of the autonomous driving system than on open roads.

[0032] The implementation of this control method relies on a complete and collaborative hardware platform as its physical foundation. In one optional system architecture, this hardware platform uses an edge controller as the core control unit. This edge controller possesses powerful multi-core parallel processing capabilities and an industrial-grade wide-temperature operating range, enabling it to stably handle centralized data processing, complex logical operations, and the generation of final control decisions in harsh underground environments. As the computational hub of the entire autonomous driving system, the edge controller is responsible for running all diagnostic algorithms and state switching logic involved in this method. To comprehensively acquire environmental perception data of underground construction machinery during autonomous driving, the system integrates an intelligent driving perception module composed of multi-line LiDAR, high-definition cameras, and high-precision angle sensors. The lidar can be configured independently in four directions, installed at the front, rear, left, and right sides of the vehicle to cover the complete field of view around the vehicle. The raw 3D point cloud data it collects is timestamped and then sent to the edge controller for real-time stitching and processing. High-definition cameras are used to provide visual assistance information to enhance the ability to identify features of the tunnel walls, traffic signs, and obstacle types. Angle sensors are used to provide real-time feedback on key state quantities such as the steering angle of the vehicle's articulated parts and the attitude angle of the working devices such as the boom and bucket.

[0033] To acquire the vehicle's own operating parameters, the hardware system is also equipped with a vehicle status acquisition module. This module connects to the engine electronic control unit, brake system pressure sensor, and powertrain monitoring components via the vehicle bus interface, enabling real-time reading and analysis of multiple core vehicle operating parameters, such as engine speed, output torque, coolant temperature, brake master cylinder pressure, tire speed difference, and hydraulic system pressure. These parameters not only provide necessary feedback information for the longitudinal and lateral control of autonomous driving but also serve as a crucial data source for subsequent module communication timeout diagnostics and vehicle status assessments. Considering the unique characteristics of underground construction scenarios, the system also includes a dedicated access control module to ensure operational safety in areas where humans and machines mix. This access control module uses an independent LiDAR sensor to perform non-contact human detection in a designated warning area. When the LiDAR scan profile successfully matches the human feature model, the access control module immediately outputs its status as a risk state. At the same time, the module has a hardwired direct-connection remote stop command sending function, which can bypass the conventional communication protocol stack and send a stop command directly to the vehicle actuator in a very short time, forcing the vehicle to enter a braking and stopping state. Conversely, when there are no people in the detection area, the access control module does not output a risk state, and the vehicle can operate normally under the preset operating logic.

[0034] In terms of communication assurance, the hardware platform deploys an automotive-grade high-speed communication module as a remote control communication module. This module can adaptively switch between wired Ethernet and wireless networks. In areas with network coverage, such as underground parking lots, it ensures real-time monitoring of vehicle operating status and rapid issuance of temporary dispatch instructions by the remote dispatch center. Working in conjunction with this, the remote data transmission module undertakes broader network-side data transmission and reception tasks, including receiving map data update packets, uploading vehicle operating logs, and remotely pushing alarms for anomaly diagnostic results. Furthermore, the system is equipped with a high-capacity data storage device with power-loss protection. This device performs rolling temporary caching and rapid retrieval of real-time operating data for multi-dimensional key topics. It also persistently stores the structured fault descriptions, associated parameter snapshots, and precise timestamps generated for each anomaly diagnostic event on local non-volatile storage media, providing a reliable data foundation for subsequent fault backtracking, root cause analysis, and system optimization. At the command execution level, the hardware platform is equipped with high-response brake actuators and steering actuators and other underlying execution components. These actuators interact with the edge controller periodically via a high-real-time fieldbus. After receiving control decision commands, they quickly complete physical actions such as brake pressure build-up and release, steering wheel angle deflection, and attitude locking of vehicle working devices through hydraulic or electric drive servo systems. This enables the vehicle to switch quickly and smoothly between different safe operating states such as normal operation, deceleration, smooth parking, and emergency braking.

[0035] After the underground construction machinery is powered on and started, the diagnostic decision module first performs communication timeout diagnosis on the communication heartbeats corresponding to each key topic. The core task of this stage is to verify whether all functional modules constituting the autonomous driving system are in a normal communication state, and to avoid starting the vehicle to work rashly when some modules have not completed initialization or have communication failures.

[0036] Specifically, the diagnostic decision module uses a periodic heartbeat detection mechanism to check whether the communication links corresponding to each key topic are normal. When it detects that a module corresponding to a key topic maintains a normal communication heartbeat without any communication timeout anomalies for a preset first set time period, it determines that the module is in a ready state. Only when all modules corresponding to key topics simultaneously meet the condition of no communication timeout anomalies for a consecutive first set time period, does the diagnostic decision module determine that the system initialization is complete and generate an initialization event accordingly. In response to this initialization event, the state management module controls the state machine to switch from the uninitialized state to the decelerated operation state. At this time, the vehicle gains basic low-speed movement capability and can begin to execute subsequent work tasks.

[0037] During the initialization timing process, if any module corresponding to a critical topic experiences a communication timeout exception within the first set time period, it indicates that there are modules in the system that are not yet ready or have unstable communication. At this time, the diagnostic decision module immediately resets the current initialization time to zero and restarts the timing until all critical topics simultaneously meet the condition of no communication timeout exceptions within the first set time period, at which point initialization is re-determined as complete. This anti-jitter mechanism and counter-resetting design effectively filter out occasional communication fluctuations caused by differences in the power-on sequence of modules or momentary electromagnetic interference during the initial system startup phase. It prevents misjudgments of system readiness or accidental initialization failures due to brief signal jitter, thereby significantly improving the safety and reliability of the system startup phase.

[0038] After the system completes initialization and enters a reduced-speed operation state, the vehicle's autonomous driving process in the underground engineering environment officially begins. During this process, the data acquisition module continuously collects real-time operational data on multiple key aspects.

[0039] The key topics mentioned here refer to the data flow channels through which data interacts between the various functional modules of the perception, control, communication, and decision-making layers in an autonomous driving system. In a distributed software architecture, each functional module exchanges information by publishing and subscribing to specific topics. Each topic carries a specific type of data and is continuously transmitted across the network at a preset frequency. Therefore, monitoring the operational status of key topics is essentially monitoring the health of the entire autonomous driving system's data flow channels.

[0040] Specifically, the collected multi-dimensional real-time operational data covers all aspects of the entire autonomous driving chain. In the environmental perception dimension, the data acquisition module captures point cloud data streams from LiDAR, acceleration and angular velocity data from IMU sensors, road network and feature prior data from map information, multi-line radar fusion data from point cloud stitching, and localization calculation results from front axle and rear axle poses. These data collectively constitute the basic information for the vehicle's perception of its surroundings and its own localization.

[0041] In terms of execution feedback, the data acquisition module synchronously acquires real-time feedback data from the steering sensor, boom sensor, and bucket sensor. This data reflects the current actual state of the vehicle's actuators, providing a basis for closed-loop verification of control commands. In terms of communication status, the data acquisition module monitors the data interaction between the intelligent driving and chassis communication topics, as well as the CMOA communication topics. These topics carry key communication messages between the autonomous driving domain controller and the vehicle chassis domain controller, and between the autonomous driving domain controller and the remote control module. In terms of decision-making and security, the data acquisition module also receives data from the task control, obstacle detection, and access control system topics. This data reflects the operational status of the upper-level decision-making and planning module and the security status of the work area.

[0042] Through the aforementioned multi-dimensional data collection, the system can grasp the full picture of the data flow channels between various levels, from the bottom sensors and intermediate control execution to the upper decision-making and planning, providing a complete data foundation for subsequent anomaly diagnosis.

[0043] After collecting real-time operational data for multiple key topics across various dimensions, the diagnostic decision-making module performs anomaly diagnoses for each dimension to determine whether the vehicle's autonomous driving system exhibits faults or risks at various functional levels. These diagnoses are executed in parallel, covering multiple levels from basic data stream health to environmental collision risk, positioning reliability, path execution accuracy, and the status of inter-module communication links. Each diagnostic method generates a corresponding sub-result, which is then synthesized and arbitrated to form a unified target diagnostic result.

[0044] Specifically, anomaly diagnosis first includes topic health diagnosis of real-time operational data for key topics across various dimensions. The core of this diagnosis is monitoring whether the data transmission frequency of each key topic meets preset functional requirements. For each key topic, a frequency threshold is pre-set based on its functional importance and data update needs. For example, the transmission frequency threshold for LiDAR is set to 10-20 Hz, and for IMU sensor topics, it is set to 50 Hz. The actual threshold can be determined based on the specifications of each module and the operational scenario. The diagnostic decision module counts the number of messages received for each topic within a sliding time window in real time, calculates the actual transmission frequency, and compares it with the corresponding preset frequency threshold. Once the actual transmission frequency of any key topic falls below its preset frequency threshold, it is immediately determined that the topic has a health anomaly. This means that the data flow channel corresponding to the topic has been blocked, delayed, or interrupted, and the corresponding functional module may have failed or experienced performance degradation. At this point, the topic health diagnosis generates a first sub-result characterizing the anomaly.

[0045] Secondly, anomaly diagnosis includes collision detection diagnosis based on real-time operational data of key aspects of environmental perception. This diagnosis utilizes multiple collected LiDAR point cloud data points to construct a 360-degree environmental point cloud model around the vehicle using a point cloud stitching algorithm in the diagnostic decision module. Then, based on the vehicle's own body contour geometry model, the minimum straight-line distance between all environmental point cloud points and the vehicle contour is calculated. The diagnostic decision module compares this minimum distance with two preset thresholds: a warning threshold and a stopping threshold, to determine the current collision risk level. When the minimum distance between all point cloud points and the vehicle is greater than the warning threshold, it is classified as a safe level, indicating no collision risk. When the minimum distance between a point cloud point and the vehicle is less than or equal to the warning threshold but greater than the stopping threshold, it is classified as a warning level, indicating an obstacle is approaching the vehicle, posing a potential collision risk, but not yet requiring emergency braking. When the minimum distance between a point cloud point and the vehicle is less than or equal to the stopping threshold, it is classified as a dangerous level, indicating that the obstacle is very close, posing an imminent collision threat. The collision detection diagnosis generates a corresponding second sub-result based on the determined level, which directly characterizes the degree of surrounding collision risk.

[0046] Secondly, anomaly diagnosis includes positioning accuracy diagnosis of real-time operational data for key aspects of environmental perception. This diagnosis primarily relies on point cloud matching technology based on Normal Distribution Transform (NDT). NDT is an algorithm that matches the point cloud obtained from the current LiDAR scan with a pre-built high-precision point cloud map. By calculating the probability distribution of the point cloud within each grid and solving for the optimal transformation parameters, it obtains the vehicle's precise pose in the map and outputs a matching rate value characterizing the matching quality. The diagnostic decision module acquires this NDT matching rate in real time and compares it with a preset matching rate threshold, which is typically set to 0.75, but the specific value can be adjusted according to the actual map accuracy and environmental characteristics. If the real-time matching rate is lower than the threshold, a positioning error count is incremented; if the matching rate recovers to above the threshold, the positioning error counter is reset to zero. When the positioning error counter value reaches a first set number of consecutive times, for example, four consecutive times the matching rate is detected to be lower than the threshold, the diagnostic decision module determines that there is an anomaly in positioning accuracy. At this time, the vehicle's own pose estimation may have a large deviation, which cannot guarantee safe driving. Based on this, the positioning accuracy diagnosis generates a third sub-result characterizing whether the positioning is abnormal.

[0047] In addition, anomaly diagnosis also includes tracking accuracy diagnosis of real-time operational data on key topics in the execution feedback dimension. This diagnosis targets the vehicle's path tracking performance, specifically relying on deviation data generated by the Model Predictive Control (MPC) controller during real-time operation. MPC is an advanced control algorithm that solves an optimization problem online within a finite time domain, calculating the optimal control command to ensure the vehicle travels along the planned path as accurately as possible. During this process, it calculates in real-time the lateral error between the actual trajectory and the planned path, as well as the heading angle error between the actual heading angle and the planned heading angle. The diagnostic decision module acquires these two error values ​​and compares them with preset error thresholds: the lateral error threshold is typically set at 0.5 meters based on the working road width and safety margin, while the heading angle error threshold is set at 5 degrees based on the vehicle's turning radius and control accuracy. The diagnostic logic uses an "OR" logic, meaning that if either the lateral error or the heading angle error exceeds its corresponding deviation threshold, a path tracking anomaly is immediately identified. This indicates that the vehicle has significantly deviated from the predetermined path, and continuing along the current trend may result in a collision with the roadway wall or entry into a danger zone. The tracking accuracy diagnosis generates a fourth sub-result characterizing whether the path tracking deviation exceeds the limit.

[0048] Finally, the anomaly diagnosis also includes communication timeout diagnosis of real-time operational data for key topics in the communication status dimension. This diagnosis is a continuous detection mechanism used to monitor whether the communication links between various functional modules are interrupted or delayed. The diagnostic decision module maintains an independent timeout counter for each functional module corresponding to the key topic that needs to be monitored, and all counters are initialized to zero. At the same time, the status management module starts a periodic timer, the period of which can be set according to system requirements, such as 100 milliseconds. During operation, whenever the data acquisition module or the callback function of each module receives a normal communication message for the corresponding topic, the timeout counter of that module is immediately cleared to zero. And whenever the clock timer is triggered, the timeout counters of all modules are automatically incremented by 1. The diagnostic decision module checks in real time whether the timeout counter values ​​of each module have reached the corresponding timeout threshold. Considering the different real-time requirements of different modules, the timeout thresholds are also set differently. For example, the communication timeout threshold for topic detection is set to 2 seconds, while the communication timeout threshold for safety-critical modules such as collision detection, positioning, and vehicle status monitoring is set to 1 second. Taking a 100-millisecond period as an example, if the counter of a certain safety-critical module accumulates 10 times (i.e., no message is received within 1 second), the module is judged to have timed out. Once the timeout counter of any monitored module exceeds the limit, the communication timeout diagnosis immediately generates a fifth sub-result representing the communication heartbeat timeout.

[0049] After the five diagnostic methods generate the first to fifth sub-results in parallel, the diagnostic decision module needs to integrate these sub-results into a unified target diagnostic result to drive subsequent vehicle state transitions. This transformation process follows a hierarchical response strategy. First, based on the anomaly type represented by each sub-result, it is mapped to the corresponding control event: topic health anomalies, positioning accuracy anomalies, and communication timeout anomalies are all mapped to stop events; collision detection diagnostics are mapped to recovery events, deceleration events, or emergency stop events based on their safety, warning, or danger levels, respectively; path tracking anomalies are mapped to emergency stop events. If multiple sub-results map to different control events simultaneously, they are arbitrated according to a preset priority, and the one with the highest priority is selected as the final target diagnostic result. The priority order is set as follows: emergency stop events have the highest priority, followed by stop events, then deceleration events, and recovery events have the lowest priority. This priority design ensures that at any given time, the command with the highest safety requirements is executed first. Finally, the target diagnostic result obtained after arbitration is the final output of this diagnostic cycle, representing the highest level of safety action the vehicle should take at the current moment.

[0050] In an optional implementation, the diagnostic decision module transforms the abnormal states represented by each sub-result into corresponding control events according to a preset mapping rule. This mapping process achieves a deterministic conversion from diagnostic conclusions to control commands, ensuring that each abnormal situation has a clear and unique handling action.

[0051] Specifically, the mapping rules between each sub-result and the control event are as follows: When the first sub-result characterization shows a topic health anomaly, it indicates that a critical data flow channel in the autonomous driving system is blocked, delayed, or interrupted, and the corresponding functional module may have failed or be unable to provide valid data. In this case, the system cannot guarantee the correctness of subsequent decisions, therefore the corresponding control event is determined to be a stop event, requiring the vehicle to actively enter a stopped state and wait for the fault to be resolved.

[0052] When the second sub-result indicates a safe collision risk level, it means there is no collision threat around the vehicle. If the vehicle is currently decelerating, it can resume normal operating speed. Therefore, the corresponding control event is designated as a recovery event to instruct the vehicle to return to normal operation from the deceleration state. When the second sub-result indicates a warning collision risk level, it means an obstacle is approaching the vehicle but has not yet reached an emergency level, posing a potential collision risk. The vehicle needs to reduce its speed to increase the safety margin; therefore, the corresponding control event is designated as a deceleration event, putting the vehicle into a more cautious operating state. When the second sub-result indicates a dangerous collision risk level, it means the obstacle is very close, and the collision risk is imminent, requiring immediate and forceful intervention. Therefore, the corresponding control event is designated as an emergency stop event, requiring the vehicle to immediately perform emergency braking.

[0053] When the third sub-result indicates an anomaly in positioning accuracy, it means that the vehicle's positioning accuracy is consistently below the threshold, suggesting a significant deviation in the vehicle's position estimation. In cases of unreliable positioning, the autonomous driving system cannot ensure the vehicle is on the correct path, and continued operation carries the risk of lane departure or even collision. Therefore, the corresponding control event is determined to be a stop event, requiring the vehicle to come to a smooth stop and await positioning recovery or manual intervention.

[0054] When the fourth sub-result indicates a path tracking anomaly, it means that the lateral or directional deviation between the vehicle's actual trajectory and the planned path has exceeded the safe allowable range, and the vehicle may be heading towards the tunnel wall or other dangerous areas. If this deviation continues to increase, it will directly lead to a collision. Therefore, the corresponding control event is determined to be an emergency stop event, requiring the vehicle to brake immediately to terminate the current dangerous driving state as quickly as possible.

[0055] When the fifth sub-result indicates a communication timeout anomaly, it means that a certain functional module failed to send a normal communication heartbeat message within the preset timeout threshold. This module may have gone offline, crashed, or the communication link was interrupted. Continuing autonomous driving without confirming the module's operational status poses a safety risk. Therefore, the corresponding control event is determined to be a stop event, requiring the vehicle to actively stop to ensure safe handling in the case of incomplete information.

[0056] Based on the mapping rules defined above, the anomalies reflected in each sub-result are transformed into corresponding control events. When multiple sub-results generate different control events simultaneously, the control event with the highest priority is selected as the final target diagnostic result according to the preset priority order: emergency stop events take precedence over stop events, stop events take precedence over deceleration events, and deceleration events take precedence over recovery events. This ensures that the system can prioritize the control action with the highest safety assurance level under any complex circumstances.

[0057] In one optional implementation, the state management module triggers the switching of underground engineering machinery between different operating states based on the final determined target diagnostic results, through a preset state machine logic. The state machine defines five core operating states: uninitialized state, normal operation state, deceleration operation state, stopped state, and emergency stop state. Each state corresponds to different vehicle behaviors and safety levels. Based on the received control events, the state management module strictly executes the switching actions according to the predefined state transition path.

[0058] When the target diagnostic result is a recovery event, it indicates that the risk factors that previously caused the vehicle to slow down have been eliminated, the collision detection diagnosis has consistently determined the safety level for a period of time, and the surrounding environment has returned to a state without collision threat. At this point, the state management module controls the underground engineering machinery to switch from the slowed-down operation state to the normal operation state, and the vehicle can resume its preset working speed to continue performing engineering tasks. This recovery process from slowing down to normal is not instantaneous but is verified by an anti-vibration mechanism to ensure the stability of the environmental safety state and avoid repeated state jumps caused by momentary interference.

[0059] When the target diagnostic result is a deceleration event, it indicates that the collision detection diagnosis has determined that an obstacle is approaching the vehicle, and the risk level is warning. At this time, the state management module controls the underground engineering machinery to switch from normal operation to deceleration operation. In deceleration operation, the vehicle travels at a lower safe speed, which provides more reaction time for subsequent perception and decision-making, and also shortens the braking distance required in emergency braking. During the deceleration operation, the diagnostic decision module continuously monitors the surrounding environment to determine whether the conditions for returning to normal operation are met.

[0060] When the target diagnostic result is a stop event, it indicates a fault in the system that affects the integrity of the autonomous driving function, such as abnormal topic health, abnormal positioning accuracy, or abnormal communication timeout. In this case, the safety basis for the vehicle to continue driving is compromised, and the state management module controls the underground engineering machinery to switch from normal operation or deceleration operation to a stop state. After entering the stop state, the vehicle performs smooth braking and remains stationary, waiting for the fault to be resolved or manual intervention. The stopping action triggered by the stop event is a controlled active stop, which is different from an emergency stop in an emergency situation. It is suitable for scenarios where the system detects a functional fault but there is no immediate threat of collision.

[0061] When the target diagnostic result is an emergency stop event, it indicates that the system has detected the highest level of threat. This could be due to a collision detection diagnosis determining it to be at a dangerous level, meaning the distance between the obstacle and the vehicle is less than or equal to the stopping threshold, posing an imminent risk of collision; or it could be due to a path tracking diagnosis determining that the vehicle's lateral or directional deviation is severely excessive, indicating that the vehicle is in a dangerous state of loss of control. Regardless of whether the vehicle is currently in normal operation or deceleration mode, the state management module immediately controls it to switch to emergency stop mode. In emergency stop mode, the vehicle performs emergency braking with the fastest response speed, the brake actuators operate at maximum braking torque, and the steering actuators maintain the current direction or engage safety locking, ensuring that the vehicle comes to a complete stop within the shortest distance, minimizing or avoiding collisions to the greatest extent possible.

[0062] When the target diagnostic result is a reset event, it indicates that the system has received a restart command or a manual reset signal. The state management module controls the underground engineering machinery to switch from any of the following states: reduced speed operation, normal operation, or stopped, to an uninitialized state. After entering the uninitialized state, the system clears the current operating status record, all modules enter a pending verification state, and the vehicle loses its ability to move. Subsequently, the system must re-execute the initialization diagnostic process, sequentially verifying whether the communication heartbeats of each key topic are normal and whether each functional module is ready. Only after all modules have no communication timeout anomalies within a first set period of time are the initialization events generated again, allowing the system to start from scratch and enter the reduced speed operation state again. This design ensures that after experiencing a major failure or manual intervention, the system must go through a complete safety self-check process before it can be put back into operation, effectively preventing secondary safety risks caused by restarting with defects or accidental recovery.

[0063] In an optional implementation, the diagnostic decision module triggers a fault tracing mechanism simultaneously upon detecting any anomaly and generating a corresponding control event. The core purpose of this mechanism is to establish a complete and easily searchable local fault file for each diagnosed anomaly, enabling maintenance personnel to accurately reconstruct the instantaneous state of the fault and quickly pinpoint the root cause of the problem even in an underground, enclosed environment without external network support, by retrieving stored data afterward.

[0064] Specifically, whenever an abnormal diagnostic sub-result is confirmed and used to generate a control event, the fault tracing module immediately encapsulates the relevant information of the fault into a structured Chinese description record. This record first includes a clear classification of the fault type, such as being labeled as a topic health abnormality, collision warning, insufficient positioning accuracy, path tracking error, or communication timeout, enabling maintenance personnel to grasp the nature of the fault from a macro perspective. Secondly, the record will specify in detail the specific sensors or functional modules involved in the fault, such as indicating "left-side LiDAR," "front axle pose topic," "MPC controller," or "intelligent driving and chassis communication link," thereby accurately locating the problem to a single replaceable or debuggable hardware and software unit, avoiding the difficulty of troubleshooting one by one in a large-scale system.

[0065] Furthermore, each fault record is forcibly accompanied by a comparison of real-time monitoring data at the moment of the fault occurrence with preset thresholds, such as "LiDAR data transmission frequency 10Hz, threshold 20Hz," "minimum point cloud distance 0.3 meters, parking threshold 0.5 meters," or "NDT matching rate 0.62, threshold 0.75," etc. This parameter-level snapshot provides quantitative evidence for subsequent analysis, directly reflecting the severity of the fault and the extent of deviation from normal levels. Finally, all fault records are timestamped to the millisecond level, synchronized with the times of other operational logs in the system. Through this high-precision timestamp, maintenance personnel can align fault records with vehicle status data, point cloud playback data, and control command sequences in multiple dimensions afterward, fully reproducing the operational scenario before and after the fault, thereby conducting root cause analysis and optimizing system performance. All fault data described in Chinese is ultimately written to the corresponding data storage device for local persistent storage, ensuring that diagnostic history is not lost even if the vehicle operates deep underground without network connectivity for extended periods, providing solid data support for accumulating maintenance experience and iterating system design.

[0066] Figure 2 This invention provides a schematic diagram of the structure of a control device for underground engineering machinery, comprising: The data acquisition module is used to collect real-time operational data on multiple key topics during the autonomous driving process of underground engineering machinery in underground engineering environments; wherein, the key topics represent the data flow channels for data interaction between the functional modules of the vehicle perception layer, control layer, communication layer and decision layer. The diagnostic decision module is used to perform anomaly diagnosis on the real-time running data of the key topics in each dimension, and obtain the target diagnostic results. The status management module is used to switch the operating status of the underground engineering machinery based on the target diagnosis results.

[0067] The process of autonomous driving of underground engineering machinery in underground engineering environments involves collecting real-time operational data on multiple key aspects, including: Collect LiDAR data, IMU sensor data, map information data, point cloud stitching data, front axle pose data, and rear axle pose data from the environmental perception dimension; Collect steering sensor data, boom sensor data, and bucket sensor data in the execution feedback dimension; Collect intelligent driving and chassis communication data and CMOA communication data in the communication status dimension; Collect data from the task control module, obstacle detection module, and access control system in the decision-making and security dimensions.

[0068] The real-time operational data for each key topic in each dimension is subjected to anomaly diagnosis to obtain target diagnostic results, including: By performing topic health diagnosis on the real-time operational data of key topics in each dimension, a first sub-result is obtained that characterizes whether the data transmission frequency of each key topic is abnormal. Collision detection and diagnosis are performed on real-time operational data of key topics in the environmental perception dimension to obtain a second sub-result that characterizes the surrounding collision risk level; The positioning accuracy is diagnosed by performing real-time operation data on key topics in the environmental perception dimension, and a third sub-result is obtained to characterize whether the positioning matching degree is abnormal. The real-time running data of key topics in the execution feedback dimension are tracked for accuracy diagnosis to obtain a fourth sub-result that characterizes whether the path tracking deviation exceeds the limit; The real-time operational data of key topics in the communication status dimension are used to diagnose communication timeouts, resulting in a fifth sub-result that characterizes whether the communication heartbeat of each functional module has timed out. The target diagnostic result is generated based on the first sub-result, the second sub-result, the third sub-result, the fourth sub-result, and the fifth sub-result.

[0069] The step of generating the target diagnostic result based on the first sub-result, the second sub-result, the third sub-result, the fourth sub-result, and the fifth sub-result includes: Based on the first sub-result, the second sub-result, the third sub-result, the fourth sub-result, and the fifth sub-result, determine the corresponding control event; Based on the preset priority, the control event with the highest priority is selected as the target diagnostic result.

[0070] The step of determining the corresponding control event based on the first sub-result, the second sub-result, the third sub-result, the fourth sub-result, and the fifth sub-result includes: When the first sub-result indicates that there is a topic health abnormality, the corresponding control event is determined to be a stop event; When the second sub-result indicates a safe collision risk level, the corresponding control event is determined to be a recovery event; when the second sub-result indicates a warning collision risk level, the corresponding control event is determined to be a deceleration event; when the second sub-result indicates a dangerous collision risk level, the corresponding control event is determined to be an emergency stop event. When the third sub-result indicates an abnormality in positioning accuracy, the corresponding control event is determined to be a stop event; When the fourth sub-result indicates the existence of a path tracking anomaly, the corresponding control event is determined to be an emergency stop event; When the fifth sub-result indicates a communication timeout anomaly, the corresponding control event is determined to be a stop event.

[0071] The step of switching the operating status of the underground engineering machinery based on the target diagnosis result includes: When the target diagnostic result is a recovery event, control the underground engineering machinery to switch from decelerated operation to normal operation. When the target diagnosis result is a deceleration event, control the underground engineering machinery to switch from normal operation to deceleration operation; When the target diagnostic result is a stop event, control the underground engineering machinery to switch from normal operation or reduced speed operation to a stop state; When the target diagnosis result is an emergency stop event, control the underground engineering machinery to switch from normal operation or deceleration operation to emergency stop; When the target diagnostic result is a reset event, the underground engineering machinery is controlled to switch from a reduced speed operation state, a normal operation state, or a stopped state to an uninitialized state.

[0072] The diagnostic decision module is used to perform communication timeout diagnosis on the communication heartbeats corresponding to each key topic after the underground engineering machinery is started; when there is no communication timeout anomaly for all key topics within a continuous first set time period, an initialization event is generated to control the vehicle to switch from the uninitialized state to the decelerated operation state. If any key topic experiences a communication timeout exception within the first set time period, the timer restarts until all key topics simultaneously meet the condition that there are no communication timeout exceptions within the first set time period.

[0073] like Figure 3 As shown, this application provides an electronic device for executing the control method for underground engineering machinery in this application. The device includes a memory, a processor, a bus, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the control method for underground engineering machinery.

[0074] Specifically, the aforementioned memory and processor can be general-purpose memory and processor, without any specific limitations. When the processor runs the computer program stored in the memory, it can execute the aforementioned control method for underground engineering machinery.

[0075] Corresponding to the control method for underground engineering machinery in this application, this application embodiment also provides a computer storage medium storing a computer program, which is executed by a processor to perform the steps of the control method for underground engineering machinery described above.

[0076] Specifically, the storage medium can be a general-purpose storage medium, such as a removable disk or hard disk. When the computer program on the storage medium is run, it can execute the control method of the underground engineering machinery described above.

[0077] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. The system embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and there may be other division methods in actual implementation. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the coupling or direct coupling or communication connection shown or discussed may be through some communication interface; the indirect coupling or communication connection between systems or units may be electrical, mechanical, or other forms.

[0078] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0079] In addition, the functional units in the embodiments provided in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0080] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0081] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0082] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application. All should be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

Claims

1. A control method for underground engineering machinery, characterized in that, The method, applied to an in-vehicle edge controller, includes: During the autonomous driving process of underground engineering machinery in underground engineering environments, real-time operational data on multiple key topics are collected; wherein, the key topics represent the data flow channels for data interaction between the functional modules of the vehicle perception layer, control layer, communication layer and decision-making layer. Anomaly diagnosis is performed on the real-time operational data of the key topics mentioned in each dimension to obtain the target diagnostic results; Based on the target diagnosis results, switch the operating status of the underground engineering machinery.

2. The method according to claim 1, characterized in that, The process of autonomous driving of underground engineering machinery in underground engineering environments involves collecting real-time operational data on multiple key aspects, including: Collect LiDAR data, IMU sensor data, map information data, point cloud stitching data, front axle pose data, and rear axle pose data from the environmental perception dimension; Collect steering sensor data, boom sensor data, and bucket sensor data in the execution feedback dimension; Collect intelligent driving and chassis communication data and CMOA communication data in the communication status dimension; Collect data from the task control module, obstacle detection module, and access control system in the decision-making and security dimensions.

3. The method according to claim 1, characterized in that, The real-time operational data for each key topic in each dimension is subjected to anomaly diagnosis to obtain target diagnostic results, including: By performing topic health diagnosis on the real-time operational data of key topics in each dimension, a first sub-result is obtained that characterizes whether the data transmission frequency of each key topic is abnormal. Collision detection and diagnosis are performed on real-time operational data of key topics in the environmental perception dimension to obtain a second sub-result that characterizes the surrounding collision risk level; The positioning accuracy is diagnosed by performing real-time operation data on key topics in the environmental perception dimension, and a third sub-result is obtained to characterize whether the positioning matching degree is abnormal. The real-time running data of key topics in the execution feedback dimension are tracked for accuracy diagnosis to obtain a fourth sub-result that characterizes whether the path tracking deviation exceeds the limit; The real-time operational data of key topics in the communication status dimension are used to diagnose communication timeouts, resulting in a fifth sub-result that characterizes whether the communication heartbeat of each functional module has timed out. The target diagnostic result is generated based on the first sub-result, the second sub-result, the third sub-result, the fourth sub-result, and the fifth sub-result.

4. The method according to claim 3, characterized in that, The step of generating the target diagnostic result based on the first sub-result, the second sub-result, the third sub-result, the fourth sub-result, and the fifth sub-result includes: Based on the first sub-result, the second sub-result, the third sub-result, the fourth sub-result, and the fifth sub-result, determine the corresponding control event; Based on the preset priority, the control event with the highest priority is selected as the target diagnostic result.

5. The method according to claim 4, characterized in that, The step of determining the corresponding control event based on the first sub-result, the second sub-result, the third sub-result, the fourth sub-result, and the fifth sub-result includes: When the first sub-result indicates that there is a topic health abnormality, the corresponding control event is determined to be a stop event; When the second sub-result indicates a safe collision risk level, the corresponding control event is determined to be a recovery event; when the second sub-result indicates a warning collision risk level, the corresponding control event is determined to be a deceleration event; when the second sub-result indicates a dangerous collision risk level, the corresponding control event is determined to be an emergency stop event. When the third sub-result indicates an abnormality in positioning accuracy, the corresponding control event is determined to be a stop event; When the fourth sub-result indicates a path tracking anomaly, the corresponding control event is determined to be an emergency stop event; When the fifth sub-result indicates a communication timeout exception, the corresponding control event is determined to be a stop event.

6. The method according to claim 1, characterized in that, The step of switching the operating status of the underground engineering machinery based on the target diagnosis result includes: When the target diagnostic result is a recovery event, control the underground engineering machinery to switch from decelerated operation to normal operation. When the target diagnosis result is a deceleration event, control the underground engineering machinery to switch from normal operation to deceleration operation; When the target diagnostic result is a stop event, control the underground engineering machinery to switch from normal operation or reduced speed operation to a stop state; When the target diagnosis result is an emergency stop event, control the underground engineering machinery to switch from normal operation or deceleration operation to emergency stop; When the target diagnostic result is a reset event, the underground engineering machinery is controlled to switch from a reduced speed operation state, a normal operation state, or a stopped state to an uninitialized state.

7. The method according to claim 1, characterized in that, The method further includes: After the underground engineering machinery is started, communication timeout diagnosis is performed on the communication heartbeats corresponding to each key topic; when there is no communication timeout abnormality for all key topics within the first set time period, an initialization event is generated to control the vehicle to switch from the uninitialized state to the decelerated operation state. If any key topic experiences a communication timeout exception within the first set time period, the timer restarts until all key topics simultaneously meet the condition that there are no communication timeout exceptions within the first set time period.

8. A control device for underground engineering machinery, characterized in that, Residing in an in-vehicle edge controller, the device includes: The data acquisition module is used to collect real-time operational data on multiple key topics during the autonomous driving process of underground engineering machinery in underground engineering environments; wherein, the key topics represent the data flow channels for data interaction between the functional modules of the vehicle perception layer, control layer, communication layer and decision layer. The diagnostic decision module is used to perform anomaly diagnosis on the real-time running data of the key topics in each dimension, and obtain the target diagnostic results. The status management module is used to switch the operating status of the underground engineering machinery based on the target diagnosis results.

9. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine instructions that the processor executes. When the electronic device is running, the processor communicates with the memory via the bus. When the machine instructions are executed by the processor, they perform the steps of the control method for underground engineering machinery as described in any one of claims 1 to 7.

10. A computer storage medium, characterized in that, The computer storage medium stores a computer program that, when executed by a processor, performs the steps of the control method for underground engineering machinery as described in any one of claims 1 to 7.

Images