Logistics unmanned vehicle abnormal behavior active monitoring method based on multi-source perception fusion and dynamic threshold self-adaption

Abstract

The application discloses a logistics unmanned vehicle abnormal behavior active monitoring method based on multi-source perception fusion and dynamic threshold self-adaption, and comprises the following steps: constructing a multi-dimensional perception data fusion layer, establishing a dynamic threshold configuration model, implementing a multi-modal abnormal behavior judgment logic, abnormal recovery closed loop processing, full life cycle state management and feedback, visual display and configuration. The application adopts a multi-source perception fusion technology, accurately distinguishes normal operation behavior from abnormal behavior by combining task state, geographical position and vehicle real-time state, avoids invalid low power alarm, and avoids misjudging normal parking as abnormal by combining position information to determine non-stopping point abnormal parking, greatly adapting to the problem of complex operation environment.

Description

Technical Field

[0001] This invention relates to the fields of intelligent logistics and autonomous driving technology, and in particular to a method for proactively monitoring abnormal behavior of unmanned logistics vehicles based on multi-source perception fusion and dynamic threshold adaptation. Background Technology

[0002] With the development of logistics automation technology, unmanned vehicles (UAVs) have been widely used in logistics scenarios such as park delivery, warehousing and transshipment, and long-haul transportation. The operational safety and stability of UAVs have become the core guarantee for logistics operation efficiency. Timely and accurate monitoring of abnormal vehicle behavior is a key link in the operation monitoring of UAVs and the early warning of related component failures. However, existing methods for abnormal monitoring of UAVs still have many shortcomings: 1. The coverage of abnormal behavior monitoring types is incomplete, mostly targeting only a single or a few types of abnormalities such as offline and speeding, and lacking monitoring of abnormal behaviors specific to logistics business scenarios such as parking at non-stop points, parking exceeding the stop time, frequent parking, abnormal door opening, and task timeout. 2. The abnormal behavior judgment logic is too simple and does not combine vehicle task status, stop point status and speed status for multi-dimensional condition judgment. In addition, some abnormal judgments lack flexible threshold configuration and cannot adapt to the monitoring needs of different logistics scenarios. 3. Poor real-time monitoring: It mostly uses persistent storage in pure databases without combining caching technology to enable fast reading and updating of real-time data such as vehicle speed and abnormal status, resulting in delays in anomaly detection. 4. Inconsistent synchronization of abnormal states: There is a lack of linkage and update mechanism between the vehicle's basic state, abnormal state, and real-time cache state, which can easily lead to data inconsistency. 5. Fault alarms for unmanned vehicle components are generally passive, lacking proactive prediction and early warning based on abnormal behavior.

[0003] To address the aforementioned issues, there is an urgent need to design an anomaly monitoring method that is comprehensive, accurate, real-time, highly configurable, capable of integrating multi-dimensional sensing data, and supports dynamic adaptive adjustment of thresholds. This method would be suitable for the large-scale and diverse operational monitoring needs of unmanned logistics vehicles, thereby improving the safety and management efficiency of unmanned vehicle operations. Summary of the Invention

[0004] This invention aims to overcome the shortcomings of existing technologies and provide a proactive monitoring method for abnormal behavior of unmanned logistics vehicles based on multi-source perception fusion and dynamic threshold adaptation. This method enables accurate identification, early prediction, and tiered handling of abnormal behavior, thereby improving the safety and continuity of unmanned vehicle operation.

[0005] The objective of this invention is achieved as follows: a proactive monitoring method for abnormal behavior of unmanned logistics vehicles based on multi-source perception fusion and dynamic threshold adaptation, comprising the following steps: S1. Construct a multi-dimensional perception data fusion layer: Collect multi-source heterogeneous data from unmanned vehicles in real time, including vehicle basic state data, task execution data, and geospatial data, and store the above data in a relational database and a time-series database respectively; construct a vehicle speed state machine through an in-memory data structure to transform real-time speed stream data into discrete "stopped", "driving", or "unknown" states, and record state transition timestamps. S2. Establish a dynamic threshold configuration model: Configure an anomaly monitoring parameter library, set independent threshold parameters and monitoring switches for different types of abnormal behaviors; the threshold parameters can be adaptively adjusted according to the vehicle operation scenario, and configure two sets of differentiated power thresholds for "on the go" and "idle state" to realize dynamic early warning based on scenario perception. S3. Implement multimodal abnormal behavior judgment logic: Based on the timed polling mechanism, integrate the multidimensional perception data described in step S1 with the dynamic threshold described in step S2, and execute the following abnormal judgment sub-logic: S31. Vehicle connectivity anomaly monitoring: By periodically reading the offline status code, fault status, usage status and offline duration in the vehicle status table, it distinguishes between "abnormal vehicle offline" and "long-term vehicle offline", which are used to capture sudden communication failures and long-term disconnection vehicles respectively. For unmanned vehicles that have multiple connection anomalies, a vehicle communication module fault warning notification will be generated. S32. Spatiotemporal Fusion Abnormal Parking Behavior Monitoring: Combining stop point information in the task path, task start and end time information, and vehicle real-time location, determine whether the vehicle is in a non-stop point area or a non-end stop point; simultaneously, fuse the "parking" state and duration in the speed state machine to identify "abnormal parking at non-stop points" or "abnormal parking at stop points"; within the task execution cycle, count the frequency and duration of parking at non-stop points, and trigger a "frequent parking at non-stop points" warning when the frequency exceeds a set threshold, and automatically reset the counter after the task ends; S33. Driving behavior safety monitoring: Real-time matching of the vehicle's current speed with the configured speed threshold to determine "speeding abnormality"; Simultaneous monitoring of vehicle speed and door sensor status. When the vehicle is in motion and the door is open, it is determined as "abnormal door opening". For unmanned vehicles that repeatedly exhibit abnormal door opening, a door lock malfunction warning notification will be generated. S34, Dynamic Performance Monitoring: Compare the task start time with the current time to identify "task execution timeout"; Based on the scenario-based dynamic threshold configured in S2, and combined with the current task status, monitor the battery level in real time to determine "low battery warning". For vehicles that trigger low battery warnings multiple times during driving, a battery fault warning notification will be generated. S4. Abnormal Recovery Closed-Loop Processing: While actively judging various abnormalities, abnormal recovery judgment is performed simultaneously. When the vehicle no longer meets the judgment conditions of the corresponding abnormality, it is judged as abnormal recovery. The recovery conditions of different abnormalities correspond to the judgment conditions. Among them, frequent parking at non-stop points is based on the end of the task as the recovery condition, and task execution timeout is based on the completion / cancellation of the task or the vehicle being idle. S5. Full lifecycle status management and feedback: Establish a real-time snapshot table and a historical log table for abnormal status. When an abnormality is detected or recovered, the abnormal status flag in the database and the overall abnormal flag of the vehicle in the Redis cache are updated synchronously, and an abnormal record containing start time, end time and duration is generated to realize the closed-loop management of the entire process of abnormal events. S6. Visualization and Configuration: The front-end presentation layer features four types of functional pages to visualize monitoring data and facilitate threshold configuration. These pages include the following four types of functional pages: Operation monitoring page: Add abnormal vehicle status icons to vehicle details and vehicle list, add abnormal sorting function to realize the rapid identification of abnormal vehicles; Historical anomaly record query page: Supports querying vehicle historical anomaly logs by license plate number, anomaly code, time, and other conditions; Real-time anomaly status query page: Displays the current anomaly status and anomaly type of all vehicles; Threshold parameter configuration page: Supports querying and modifying various abnormal judgment thresholds and monitoring switches, and the modified thresholds are synchronized to the threshold configuration table in the database in real time.

[0006] Preferably, the active monitoring method is implemented based on an integrated collaborative three-layer system architecture, which includes a data acquisition layer CLS module, a monitoring and judgment layer CMS module, and a heterogeneous data storage layer. The heterogeneous data storage layer adopts a hybrid storage strategy of time-series database layer, relational database layer and cache database layer; Time-series database layer: The time-series database DATALAYER is used to store high-frequency vehicle operation data; the real-time speed and location trajectory information of the vehicle received by the CLS module is written to the DATALAYER in real time. Utilizing its high-performance writing and compression capabilities, the trajectory data of the vehicle throughout its entire operation cycle is persisted, providing basic data support for subsequent big data behavior analysis and path backtracking. Relational database layer: TiDB database is used to store business logic and configuration data, and three core database tables are designed and added; Anomaly Log Table: Used to record historical anomaly information, including vehicle identification, anomaly type, occurrence time, resolution time, duration, and anomaly status. The data retention period is set to 1 month to provide a basis for subsequent big data analysis. Abnormal Status Table: Used to record the current real-time abnormal status of the vehicle. It is updated in real time as abnormalities occur and are resolved, ensuring that the system can quickly query the current health status of the vehicle. Threshold configuration table: Stores threshold parameters and monitoring switches for various anomalies; among them, for low battery warnings, different threshold parameters are set for "in progress" and "idle state", realizing scenario-based adaptive thresholding; Caching database layer: Redis is used to store real-time vehicle status data to support high-frequency and fast read and write of monitoring logic; a vehicle speed status table is set in the Redis; while storing the original trajectory into the DATALAYER, the CLS module performs status determination on the speed value, converts it into discrete status value and stores it into Redis.

[0007] Preferably, based on the anomaly log table of the TiDB database, the unmanned logistics vehicle is configured with various anomaly judgment thresholds, monitoring frequencies, and monitoring switches. The core configuration parameters for the nine types of vehicle anomalies are as follows: A. Vehicle abnormally offline: No threshold, monitoring frequency is 5 minutes, monitoring switch Y; B. Vehicle offline for extended periods: Offline duration threshold of 7 days, monitoring frequency of 60 minutes, monitoring switch Y; C. Abnormal parking outside designated stops: Parking duration threshold of 20 minutes, monitoring frequency of 1 minute, monitoring switch Y; D. Abnormal parking at the stop: parking duration threshold of 120 minutes, monitoring frequency of 5 minutes, monitoring switch Y; E. Frequent parking at non-stop points: Single parking threshold is 10 minutes, cumulative number of parkings threshold is 5 times, monitoring frequency is 1 minute, and monitoring switch Y is used. F. Speeding Abnormality: Vehicle speed limit threshold 35km / h, monitoring frequency 1 minute, monitoring switch Y; H. Abnormal door opening: No numerical threshold, monitoring frequency is 1 minute, monitoring switch Y; I. Low Battery Warning: Battery threshold of 30% during task, battery threshold of 10% in idle state, monitoring frequency of 5 minutes, monitoring switch Y; J. Task execution timeout: The task timeout duration threshold is 4 hours, the monitoring frequency is 10 minutes, and the monitoring switch is Y.

[0008] Preferably, the CLS module receives speed reports from all autonomous vehicles in real time and determines the speed value of each vehicle: When the speed value is 0, it is determined as 0 - stopped; when the speed value is > 0, it is determined as 1 - moving. After each determination, the current speed status of the vehicle is read from Redis. If the status changes, the SPEED_STATUS and START_TIME of the vehicle in Redis are updated immediately.

[0009] Preferably, the CMS module performs proactive anomaly detection at a fixed and configurable frequency. The types of anomaly detection include at least non-stop point abnormal parking and speeding anomalies. The specific execution process is as follows: Abnormal parking outside designated stops: The CMS module reads the list of vehicles in TiDB whose status is online, not idle, and en route, and filters out vehicles that have been away from the stop for more than 20 minutes; then it matches the vehicles in the list from Redis whose speed status is 0 and whose current time START_TIME is more than 20 minutes, and determines them as abnormal parking outside designated stops; the abnormal status table marks the abnormal parking outside designated stops as Y, and an abnormal record is added to the abnormal log table, with the occurrence time being the current time; Speeding anomaly: The CMS module reads the list of online and in-use vehicles in TiDB, matches vehicles with a real-time speed > 35km / h from Redis, and directly determines them as speeding anomalies; then it performs the above-mentioned abnormal status synchronization and log recording operations without determining the duration.

[0010] Preferably, the CMS module performs anomaly recovery determination at a fixed and configurable frequency. The types of anomaly recovery determination include at least frequent stops outside designated stops and low battery warnings. The specific execution process is as follows: Frequent parking outside designated stops: If an autonomous vehicle accumulates 5 valid stops outside designated stops during a task, it is considered an anomaly of frequent parking outside designated stops. When the vehicle completes the task and its status changes to idle, the CMS module determines that the anomaly of frequent parking outside designated stops has been resolved. Subsequently, the duration of the anomaly is calculated, and the end time and duration of the anomaly record in the anomaly log table are updated, marking the anomaly status as N. At the same time, the anomaly N in the anomaly status table is updated, and the accumulated number of vehicle stops in the Redis cache is cleared. Low battery warning: If the battery level of the autonomous vehicle drops to 28% during the mission, it is judged as a low battery anomaly; when the vehicle finishes the mission, the CMS module determines that the low battery anomaly has been resolved and performs the above-mentioned log update and status synchronization operations for anomaly recovery.

[0011] Preferably, the CMS module has an independent vehicle abnormal status reversal thread that reads the vehicle abnormal status record table in real time to comprehensively judge whether the vehicle status has changed. If all abnormalities are recovered, the vehicle status is normal; if there are abnormalities that have not been recovered, the vehicle status is abnormal. At the same time, the vehicle abnormal status field in Redis and the database is updated.

[0012] Preferably, in step S6, the maintenance personnel perform the following operations through the front-end page: On the monitoring page, the abnormal vehicle can be quickly identified by the abnormal icon, and all abnormal vehicles can be displayed at the top by using the abnormal sorting function. On the historical anomaly record page, you can search for recent anomaly logs of a certain driverless car by license plate number and time range, including at least the anomaly type, occurrence time, and duration. On the threshold configuration page, you can modify the threshold settings, frequency settings, and on / off switches for various exception types in real time.

[0013] Compared with the prior art, the advantages of the present invention are: 1. This invention abandons single-dimensional threshold alarms and adopts multi-source perception fusion technology. By combining task status (on the way / idle), geographical location (stop point / non-stop point) and vehicle real-time status (speed, battery level, door status), it can accurately distinguish between normal operation behavior and abnormal behavior, avoiding invalid low battery alarms. By combining location information to determine "abnormal parking at non-stop points", it avoids misjudging normal parking as abnormal.

[0014] 2. A dynamic threshold configuration mechanism is introduced to support adaptive adjustment of judgment criteria according to different vehicle operating scenarios. In particular, for scenarios such as low battery warnings, the system automatically switches threshold parameters according to the current task status of the vehicle, realizing refined management and solving the problem that traditional fixed thresholds cannot adapt to complex operating environments.

[0015] 3. A vehicle speed state machine is constructed using an in-memory data structure, updating data only when the state changes, which greatly reduces the write pressure on the database from high-frequency speed messages. At the same time, real-time exception flags are cached using an in-memory data structure, and the database state is synchronized periodically by an independent thread, which ensures both the millisecond-level response speed of the monitoring platform to abnormal events and the consistency and integrity of the data.

[0016] 4. An independent abnormal state threshold configuration table (CAR_ERROR_CONFIG) was designed, which supports dynamic modification of threshold parameters and monitoring switches for each abnormal type. It can adapt to changes in different vehicle models or operating scenarios without modifying the code. In addition, the system covers the entire lifecycle management of abnormal occurrence, duration, and recovery, and automatically records the duration and end time, providing maintenance personnel with complete fault tracing basis and significantly improving maintenance efficiency.

[0017] 5. Proactively prevent risks and ensure operational safety: It can identify potential risk behaviors such as "frequent parking at non-stop points", "task execution timeout", and "abnormal vehicle door opening", enabling maintenance personnel to shift from "post-event remediation" to "in-event intervention" or "pre-event prevention", effectively preventing cargo damage, vehicle loss or traffic accidents caused by vehicle abnormalities, and ensuring the safety and stability of logistics operations.

[0018] 6. By analyzing the frequency of abnormal behavior, predict potential faults in related components, notify maintenance personnel to check and handle them in advance, and avoid business interruptions caused by vehicle downtime due to related faults during use. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating the invention process. Detailed Implementation

[0020] The following specific embodiments illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification.

[0021] It should be noted that in the description of this invention, the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, or the orientation or positional relationship commonly used when the product is in use. These terms are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first," "second," and "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance. The terms "horizontal," "vertical," and "suspended," etc., do not indicate that the component must be absolutely horizontal or suspended, but rather that it can be slightly tilted. For example, "horizontal" simply means that its direction is more horizontal than "vertical," and does not mean that the structure must be completely horizontal, but can be slightly tilted.

[0022] In the description of this invention, it should also be noted that, unless otherwise explicitly specified and limited, the terms "set," "install," "connect," and "link" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal communication between two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0023] like Figure 1 As shown, the active detection method for abnormal behavior of unmanned logistics vehicles based on multi-source perception fusion and dynamic threshold adaptation includes the following steps: S1. Construct a multi-dimensional perception data fusion layer: Collect multi-source heterogeneous data from unmanned vehicles in real time, including basic vehicle status data (speed, battery level, door status, online status), task execution data (task ID, start point, end point, waypoints, task status), and geospatial data. Store the above data in relational databases (e.g., but not limited to TiDB) and time-series databases (e.g., but not limited to Datalayer). Construct a vehicle speed state machine using in-memory data structures (e.g., but not limited to Redis) to transform real-time speed stream data into discrete "stopped," "driving," or "unknown" states, and record state transition timestamps. S2. Establish a dynamic threshold configuration model: Configure an anomaly monitoring parameter library, set independent threshold parameters and monitoring switches for different types of abnormal behaviors; the threshold parameters can be adaptively adjusted according to the vehicle operation scenario, and configure two sets of differentiated power thresholds for "on the go" and "idle state" to realize dynamic early warning based on scenario perception. S3. Implement multimodal abnormal behavior judgment logic: Based on the timed polling mechanism, integrate the multidimensional perception data described in step S1 with the dynamic threshold described in step S2, and execute the following abnormal judgment sub-logic: S31. Vehicle connectivity anomaly monitoring: By periodically reading the offline status code, fault status, usage status and offline duration in the vehicle status table, it distinguishes between "vehicle abnormal offline" (code 401) and "vehicle long-term offline" (code 409), which are used to capture vehicles with sudden communication failures and long-term disconnection, respectively. For unmanned vehicles that have multiple connection anomalies, a vehicle communication module fault warning notification will be generated. S32. Spatiotemporal Fusion Abnormal Parking Behavior Monitoring: Combining stop information in the task path, task start and end time information, and vehicle real-time location, determine whether the vehicle is in a non-stop area or a non-end stop; simultaneously, fuse the "parking" state and duration in the speed state machine to identify "abnormal parking at non-stops" (code 402) or "abnormal parking at stops" (code 407); within the task execution cycle, count the frequency and duration of parking at non-stops, and trigger a "frequent parking at non-stops" warning (code 403) when the frequency exceeds a set threshold, and automatically reset the counter after the task ends; S33. Driving behavior safety monitoring: Real-time matching of the vehicle's current speed with the configured speed threshold to determine "speeding abnormality" (code 404); Simultaneous monitoring of vehicle speed and door sensor status. When the vehicle is in motion (speed greater than zero) and the door is open, it is determined as "abnormal door opening" (code 405). For unmanned vehicles that repeatedly exhibit abnormal door opening, a door lock malfunction warning notification will be generated. S34, Dynamic Performance Monitoring: Compare the task start time with the current time to identify "task execution timeout" (code 408); Based on the scenario-based dynamic threshold configured in S2, and combined with the current task status, monitor the battery level in real time to determine "low battery warning" (code 406); For vehicles that trigger low battery warning multiple times during driving, a battery fault warning notification will be generated. S4. Abnormal Recovery Closed-Loop Processing: While actively judging various abnormalities, abnormal recovery judgment is performed simultaneously. When the vehicle no longer meets the judgment conditions of the corresponding abnormality, it is judged as abnormal recovery. The recovery conditions of different abnormalities correspond to the judgment conditions. Among them, frequent parking at non-stop points is based on the end of the task as the recovery condition, and task execution timeout is based on the completion / cancellation of the task or the vehicle being idle. S5. Full lifecycle status management and feedback: Establish a real-time snapshot table and a historical log table for abnormal status. When an abnormality is detected or recovered, the abnormal status flag in the database and the overall abnormal flag of the vehicle in the Redis cache are updated synchronously, and an abnormal record containing start time, end time and duration is generated to realize the closed-loop management of the entire process of abnormal events. S6. Visualization and Configuration: The front-end presentation layer features four types of functional pages to visualize monitoring data and facilitate threshold configuration. These pages include the following four types of functional pages: Operation monitoring page: Add abnormal vehicle status icons to vehicle details and vehicle list, add abnormal sorting function to realize the rapid identification of abnormal vehicles; Historical anomaly record query page: Supports querying vehicle historical anomaly logs by license plate number, anomaly code, time, and other conditions; Real-time anomaly status query page: Displays the current anomaly status and anomaly type of all vehicles; Threshold parameter configuration page: Supports querying and modifying various abnormal judgment thresholds and monitoring switches, and the modified thresholds are synchronized to the threshold configuration table in the database in real time.

[0024] Preferably, the active monitoring method is implemented based on an integrated collaborative three-layer system architecture, which includes a data acquisition layer CLS module, a monitoring and judgment layer CMS module, and a heterogeneous data storage layer. The heterogeneous data storage layer adopts a hybrid storage strategy of time-series database layer, relational database layer and cache database layer; Time-series database layer: The time-series database DATALAYER is used to store high-frequency vehicle operation data; the real-time speed and location trajectory information of the vehicle received by the CLS module is written to the DATALAYER in real time. Utilizing its high-performance writing and compression capabilities, the trajectory data of the vehicle throughout its entire operation cycle is persisted, providing basic data support for subsequent big data behavior analysis and path backtracking. Relational database layer: TiDB database is used to store business logic and configuration data, and three core database tables are designed and added; The CAR_ERROR_LOG table is used to record historical anomaly information, including vehicle identification, anomaly type, occurrence time, resolution time, duration, and anomaly status. The data retention period is set to 1 month to provide a basis for subsequent big data analysis. CAR_ERROR_STATUS: This table records the vehicle's current real-time abnormal status and updates it in real time as abnormalities occur and are resolved, ensuring that the system can quickly query the vehicle's current health status. Threshold configuration table (CAR_ERROR_CONFIG): Stores threshold parameters and monitoring switches for various anomalies; among them, for low battery warnings, different threshold parameters are set for "in progress" and "idle state", realizing scenario-based adaptive thresholding; Caching database layer: Redis is used to store real-time vehicle status data to support high-frequency and fast read and write of monitoring logic; a vehicle speed status table is set in Redis. When the CLS module stores the original trajectory into the DATALAYER, it performs status determination on the speed value, converts it into discrete status (0-stop, 1-driving, 9-unknown) value and stores it into Redis.

[0025] Preferably, based on the anomaly log table of the TiDB database, the unmanned logistics vehicle is configured with various anomaly judgment thresholds, monitoring frequencies, and monitoring switches. The core configuration parameters for the nine types of vehicle anomalies are as follows: A. Vehicle abnormally offline: No threshold, monitoring frequency is 5 minutes, monitoring switch Y; B. Vehicle offline for extended periods: Offline duration threshold of 7 days, monitoring frequency of 60 minutes, monitoring switch Y; C. Abnormal parking outside designated stops: Parking duration threshold of 20 minutes, monitoring frequency of 1 minute, monitoring switch Y; D. Abnormal parking at the stop: parking duration threshold of 120 minutes, monitoring frequency of 5 minutes, monitoring switch Y; E. Frequent parking at non-stop points: Single parking threshold is 10 minutes, cumulative number of parkings threshold is 5 times, monitoring frequency is 1 minute, and monitoring switch Y is used. F. Speeding Abnormality: Vehicle speed limit threshold 35km / h, monitoring frequency 1 minute, monitoring switch Y; H. Abnormal door opening: No numerical threshold, monitoring frequency is 1 minute, monitoring switch Y; I. Low Battery Warning: Battery threshold of 30% during task, battery threshold of 10% in idle state, monitoring frequency of 5 minutes, monitoring switch Y; J. Task execution timeout: The task timeout duration threshold is 4 hours, the monitoring frequency is 10 minutes, and the monitoring switch is Y.

[0026] Preferably, the CLS module receives speed reports from all autonomous vehicles in real time and determines the speed value of each vehicle: When the speed value is 0, it is determined as 0 - parked; when the speed value is > 0, it is determined as 1 - moving. After each determination, the current speed status of the vehicle is read from Redis. If the status changes, the SPEED_STATUS and START_TIME of the vehicle in Redis are updated immediately. For example, if an autonomous vehicle has a speed of 3 km / h at time t1 (state 1) and a speed of 0 at time t2 (state 0), the CLS module detects the status change and updates the SPEED_STATUS of the vehicle in Redis to 0 and the START_TIME to t2.

[0027] Preferably, the CMS module performs proactive anomaly detection at a fixed and configurable frequency. The types of anomaly detection include at least non-stop point abnormal parking and speeding anomalies. The specific execution process is as follows: Abnormal parking outside designated stops: The CMS module reads the list of vehicles in TiDB whose status is online, not idle, and en route, and filters out vehicles that have been away from the stop for more than 20 minutes; then it matches the vehicles in the list from Redis whose speed status is 0 and whose current time START_TIME is more than 20 minutes, and determines them as abnormal parking outside designated stops; the abnormal status table marks the abnormal parking outside designated stops as Y, and an abnormal record is added to the abnormal log table, with the occurrence time being the current time; Speeding anomaly: The CMS module reads the list of online and in-use vehicles in TiDB, matches vehicles with a real-time speed > 35km / h from Redis, and directly determines them as speeding anomalies; then it performs the above-mentioned abnormal status synchronization and log recording operations without determining the duration.

[0028] Preferably, the CMS module performs anomaly recovery determination at a fixed and configurable frequency. The types of anomaly recovery determination include at least frequent stops outside designated stops and low battery warnings. The specific execution process is as follows: Frequent parking outside designated stops: If an autonomous vehicle accumulates 5 valid stops outside designated stops during a task, it is considered an anomaly of frequent parking outside designated stops. When the vehicle completes the task and its status changes to idle, the CMS module determines that the anomaly of frequent parking outside designated stops has been resolved. Subsequently, the duration of the anomaly is calculated, and the end time and duration of the anomaly record in the anomaly log table are updated, marking the anomaly status as N. At the same time, the anomaly N in the anomaly status table is updated, and the accumulated number of vehicle stops in the Redis cache is cleared. Low battery warning: If the battery level of the autonomous vehicle drops to 28% during the mission (the threshold is set to be below 30%), it is judged as a low battery anomaly; when the vehicle finishes the mission, the CMS module determines that the low battery anomaly has been resolved and performs the above-mentioned log update and status synchronization operations for anomaly recovery.

[0029] Preferably, the CMS module has an independent vehicle abnormal status reversal thread that reads the vehicle abnormal status record table in real time to comprehensively judge whether the vehicle status has changed. If all abnormalities are recovered, the vehicle status is normal; if there are abnormalities that have not been recovered, the vehicle status is abnormal. At the same time, the vehicle abnormal status field in Redis and the database is updated.

[0030] Preferably, in step S6, the maintenance personnel perform the following operations through the front-end page: On the monitoring page, the abnormal vehicle can be quickly identified by the abnormal icon, and all abnormal vehicles can be displayed at the top by using the abnormal sorting function. On the historical anomaly record page, you can search for recent anomaly logs of a certain driverless car by license plate number and time range, including at least the anomaly type, occurrence time, and duration. On the threshold configuration page, you can modify the threshold settings, frequency settings, and on / off switches for various exception types in real time.

[0031] The embodiments described above are merely preferred embodiments of the present invention and are not intended to limit the concept and scope of the present invention. Various modifications and improvements made to the technical solutions of the present invention by those skilled in the art without departing from the inventive concept should fall within the protection scope of the present invention. All technical contents for which protection is sought in this invention are fully described in the claims.

Claims

1. A proactive monitoring method for abnormal behavior of unmanned logistics vehicles based on multi-source perception fusion and dynamic threshold adaptation, characterized in that, Includes the following steps, S1. Construct a multi-dimensional perception data fusion layer: collect multi-source heterogeneous data from unmanned vehicles in real time, including basic vehicle status data, task execution data, and geospatial data, and store the above data in a relational database and a time-series database respectively; A vehicle speed state machine is constructed using an in-memory data structure to transform real-time speed stream data into discrete "stopped", "driving", or "unknown" states, and to record state transition timestamps. S2. Establish a dynamic threshold configuration model: Configure an anomaly monitoring parameter library, set independent threshold parameters and monitoring switches for different types of abnormal behaviors; the threshold parameters can be adaptively adjusted according to the vehicle operation scenario, and configure two sets of differentiated power thresholds for "on the go" and "idle state" to realize dynamic early warning based on scenario perception. S3. Implement multimodal abnormal behavior judgment logic: Based on the timed polling mechanism, integrate the multidimensional perception data described in step S1 with the dynamic threshold described in step S2, and execute the following abnormal judgment sub-logic: S31. Vehicle connectivity anomaly monitoring: By periodically reading the offline status code, fault status, usage status and offline duration in the vehicle status table, it distinguishes between "abnormal vehicle offline" and "long-term vehicle offline", which are used to capture sudden communication failures and long-term disconnection vehicles respectively. For unmanned vehicles that have multiple connection anomalies, a vehicle communication module fault warning notification will be generated. S32. Spatiotemporal Fusion Abnormal Parking Behavior Monitoring: Combining stop point information in the task path, task start and end time information, and vehicle real-time location, determine whether the vehicle is in a non-stop point area or a non-end stop point; simultaneously, fuse the "parking" state and duration in the speed state machine to identify "abnormal parking at non-stop points" or "abnormal parking at stop points"; within the task execution cycle, count the frequency and duration of parking at non-stop points, and trigger a "frequent parking at non-stop points" warning when the frequency exceeds a set threshold, and automatically reset the counter after the task ends; S33. Driving behavior safety monitoring: Real-time matching of the vehicle's current speed with the configured speed threshold to determine "speeding abnormality"; Simultaneous monitoring of vehicle speed and door sensor status. When the vehicle is in motion and the door is open, it is determined as "abnormal door opening". For unmanned vehicles that repeatedly exhibit abnormal door opening, a door lock malfunction warning notification will be generated. S34, Dynamic Performance Monitoring: Compare the task start time with the current time to identify "task execution timeout"; Based on the scenario-based dynamic threshold configured in S2, and combined with the current task status, monitor the battery level in real time to determine "low battery warning". For vehicles that trigger low battery warnings multiple times during driving, a battery fault warning notification will be generated. S4. Abnormal Recovery Closed-Loop Processing: While actively judging various abnormalities, abnormal recovery judgment is performed simultaneously. When the vehicle no longer meets the judgment conditions of the corresponding abnormality, it is judged as abnormal recovery. The recovery conditions of different abnormalities correspond to the judgment conditions. Among them, frequent parking at non-stop points is based on the end of the task as the recovery condition, and task execution timeout is based on the completion / cancellation of the task or the vehicle being idle. S5. Full lifecycle status management and feedback: Establish a real-time snapshot table and a historical log table for abnormal status. When an abnormality is detected or recovered, the abnormal status flag in the database and the overall abnormal flag of the vehicle in the Redis cache are updated synchronously, and an abnormal record containing start time, end time and duration is generated to realize the closed-loop management of the entire process of abnormal events. S6. Visualization and Configuration: The front-end presentation layer features four types of functional pages to visualize monitoring data and facilitate threshold configuration. These pages include the following four types of functional pages: Operation monitoring page: Add abnormal vehicle status icons to vehicle details and vehicle list, add abnormal sorting function to realize the rapid identification of abnormal vehicles; Historical anomaly record query page: Supports querying vehicle historical anomaly logs by license plate number, anomaly code, time, and other conditions; Real-time anomaly status query page: Displays the current anomaly status and anomaly type of all vehicles; Threshold parameter configuration page: Supports querying and modifying various abnormal judgment thresholds and monitoring switches, and the modified thresholds are synchronized to the threshold configuration table in the database in real time.

2. The active monitoring method for abnormal behavior of unmanned logistics vehicles based on multi-source perception fusion and dynamic threshold adaptation as described in claim 1, characterized in that, The active monitoring method is based on an integrated collaborative three-layer system architecture, which includes a data acquisition layer CLS module, a monitoring and judgment layer CMS module, and a heterogeneous data storage layer. The heterogeneous data storage layer adopts a hybrid storage strategy of time-series database layer, relational database layer and cache database layer; Time-series database layer: The time-series database DATALAYER is used to store high-frequency vehicle operation data; the real-time speed and location trajectory information of the vehicle received by the CLS module is written to the DATALAYER in real time. Utilizing its high-performance writing and compression capabilities, the trajectory data of the vehicle throughout its entire operation cycle is persisted, providing basic data support for subsequent big data behavior analysis and path backtracking. Relational database layer: TiDB database is used to store business logic and configuration data, and three core database tables are designed and added; Anomaly Log Table: Used to record historical anomaly information, including vehicle identification, anomaly type, occurrence time, resolution time, duration, and anomaly status. The data retention period is set to 1 month to provide a basis for subsequent big data analysis. Abnormal Status Table: Used to record the current real-time abnormal status of the vehicle. It is updated in real time as abnormalities occur and are resolved, ensuring that the system can quickly query the current health status of the vehicle. Threshold configuration table: Stores threshold parameters and monitoring switches for various anomalies; among them, for low battery warnings, different threshold parameters are set for "in progress" and "idle state", realizing scenario-based adaptive thresholding; Caching database layer: Redis is used to store real-time vehicle status data to support high-frequency and fast read and write of monitoring logic; a vehicle speed status table is set in the Redis; while storing the original trajectory into the DATALAYER, the CLS module performs status determination on the speed value, converts it into discrete status value and stores it into Redis.

3. The active monitoring method for abnormal behavior of unmanned logistics vehicles based on multi-source perception fusion and dynamic threshold adaptation as described in claim 2, characterized in that, Based on the anomaly log table of the TiDB database, the system configures various anomaly judgment thresholds, monitoring frequencies, and monitoring switches for the unmanned logistics vehicle. The core configuration parameters for the nine types of vehicle anomalies are as follows: A. Vehicle abnormally offline: No threshold, monitoring frequency is 5 minutes, monitoring switch Y; B. Vehicle offline for extended periods: Offline duration threshold of 7 days, monitoring frequency of 60 minutes, monitoring switch Y; C. Abnormal parking outside designated stops: Parking duration threshold of 20 minutes, monitoring frequency of 1 minute, monitoring switch Y; D. Abnormal parking at the stop: parking duration threshold of 120 minutes, monitoring frequency of 5 minutes, monitoring switch Y; E. Frequent parking at non-stop points: Single parking threshold is 10 minutes, cumulative number of parkings threshold is 5 times, monitoring frequency is 1 minute, and monitoring switch Y is used. F. Speeding Abnormality: Vehicle speed limit threshold 35km / h, monitoring frequency 1 minute, monitoring switch Y; H. Abnormal door opening: No numerical threshold, monitoring frequency is 1 minute, monitoring switch Y; I. Low Battery Warning: Battery threshold of 30% during task, battery threshold of 10% in idle state, monitoring frequency of 5 minutes, monitoring switch Y; J. Task execution timeout: The task timeout duration threshold is 4 hours, the monitoring frequency is 10 minutes, and the monitoring switch is Y.

4. The active monitoring method for abnormal behavior of unmanned logistics vehicles based on multi-source perception fusion and dynamic threshold adaptation as described in claim 2, characterized in that, The CLS module receives speed reports from all autonomous vehicles in real time and determines the speed value of each vehicle: When the speed value is 0, it is judged as 0 - stopped; when the speed value is > 0, it is judged as 1 - moving. After each determination, the current speed status of the vehicle is read from Redis. If the status changes, the SPEED_STATUS and START_TIME of the vehicle in Redis are updated immediately.

5. The active monitoring method for abnormal behavior of unmanned logistics vehicles based on multi-source perception fusion and dynamic threshold adaptation as described in claim 4, characterized in that, The CMS module performs proactive anomaly detection at a fixed and configurable frequency. The types of anomalies detected include at least non-stop point abnormal parking and speeding anomalies. The specific execution process is as follows. Abnormal parking outside designated stops: The CMS module reads the list of vehicles in TiDB whose status is online, not idle, or on the way, and filters out vehicles that have been away from the stop for more than 20 minutes. Next, match the vehicles in the list from Redis whose speed status is 0 and current time START_TIME > 20 minutes, and determine them as abnormal parking outside the stop; mark the abnormal parking of the vehicle outside the stop as Y in the abnormal status table, and add an abnormal record to the abnormal log table with the occurrence time as the current time; Speeding anomaly: The CMS module reads the list of online and in-use vehicles in TiDB, matches vehicles with a real-time speed > 35km / h from Redis, and directly determines them as speeding anomalies; then it performs the above-mentioned abnormal status synchronization and log recording operations without determining the duration.

6. The active monitoring method for abnormal behavior of unmanned logistics vehicles based on multi-source perception fusion and dynamic threshold adaptation as described in claim 4, characterized in that, The CMS module performs anomaly recovery determination at a fixed and configurable frequency. The types of anomaly recovery determination include at least frequent stops outside designated docking points and low battery warnings. The specific execution process is as follows. Frequent stops at non-stop points: If the unmanned vehicle makes 5 valid stops at non-stop points during the mission, it will be judged as an abnormality of frequent stops at non-stop points. When the vehicle completes its task and its status changes to idle, the CMS module determines that the frequent stopping at non-stop points is an abnormal recovery. Then, the duration of the anomaly is calculated, the end time and duration of the anomaly record in the anomaly log table are updated, and the anomaly status is marked as N; at the same time, the anomaly N in the anomaly status table is updated; and the accumulated number of vehicle parking times in the Redis cache is cleared. Low battery warning: If the battery level of the autonomous vehicle drops to 28% during the mission, it is judged as a low battery anomaly; when the vehicle finishes the mission, the CMS module determines that the low battery anomaly has been resolved and performs the above-mentioned log update and status synchronization operations for anomaly recovery.

7. The active monitoring method for abnormal behavior of unmanned logistics vehicles based on multi-source perception fusion and dynamic threshold adaptation as described in claim 6, characterized in that, The CMS module has an independent vehicle abnormal status reversal thread that reads the vehicle abnormal status record table in real time to comprehensively determine whether the vehicle status has changed. If all abnormalities are recovered, the vehicle status is normal; if there are any abnormalities that have not been recovered, the vehicle status is abnormal. At the same time, the vehicle abnormal status field in Redis and the database is updated.

8. The active monitoring method for abnormal behavior of unmanned logistics vehicles based on multi-source perception fusion and dynamic threshold adaptation as described in claim 1, characterized in that, In step S6, maintenance personnel perform the following operations through the front-end page: On the monitoring page, the abnormal vehicle can be quickly identified by the abnormal icon, and all abnormal vehicles can be displayed at the top by using the abnormal sorting function. On the historical anomaly record page, you can search for recent anomaly logs of a certain driverless car by license plate number and time range, including at least the anomaly type, occurrence time, and duration. On the threshold configuration page, you can modify the threshold settings, frequency settings, and on / off switches for various exception types in real time.

Images