A method, apparatus and electronic device for vehicle anomaly monitoring

Abstract

The application belongs to the field of vehicle anomaly monitoring, and discloses a vehicle anomaly monitoring method, device and electronic equipment, the method comprising: determining whether the vehicle is offline through uploaded driving data of the vehicle; if not, determining whether the vehicle has an anomaly according to the driving data; and if there is an anomaly, marking the vehicle as an abnormal vehicle. The application can accurately determine the offline state of the vehicle by analyzing the driving data uploaded by the unmanned vehicle in real time, timely identify and mark abnormal vehicles, and realize comprehensive monitoring of the abnormal state of the unmanned vehicle. Thus, the dispatching system can quickly respond, avoiding potential traffic congestion and accidents. This not only optimizes vehicle dispatching decisions, but also reduces delays caused by vehicle malfunctions or improper operation, improving the overall efficiency of logistics transportation.

Description

Technical Field

[0001] This invention relates to the field of vehicle anomaly monitoring, and more specifically, to a method, apparatus, electronic device, and computer-readable storage medium for vehicle anomaly monitoring. Background Technology

[0002] With the rapid development of autonomous driving technology, unmanned logistics vehicles are now able to utilize single-vehicle intelligent modules, such as perception, localization, control, decision-making, and system control, to achieve automated cargo transportation from point A to point B within a park. When performing tasks, these vehicles need to navigate autonomously in complex traffic environments, including parking, two-way travel, and crossing intersections.

[0003] However, in actual operation, unmanned logistics vehicles may encounter various unforeseen situations, leading to abnormal vehicle behavior. These abnormal states not only affect the vehicle's own operational safety but may also interfere with other normally operating vehicles and dispatch decisions. For example, when parking, traveling in both directions, or crossing intersections, the presence of abnormal vehicles may cause traffic congestion or increase the risk of collisions, thereby affecting the efficiency and safety of the entire logistics system.

[0004] Therefore, how to achieve comprehensive monitoring of the abnormal status of unmanned logistics vehicles is a technical problem that needs to be solved by those skilled in the art. Summary of the Invention

[0005] To address the problem that existing technologies cannot comprehensively monitor the abnormal states of unmanned logistics vehicles, this invention provides a method, apparatus, electronic device, and computer-readable storage medium for vehicle anomaly monitoring.

[0006] A method for detecting vehicle anomalies includes:

[0007] Receive driving data uploaded by the vehicle; the driving data includes at least one of the following: location coordinates, current speed, driving status, and fault code;

[0008] Determine whether the vehicle is offline based on the driving data;

[0009] If not, then determine whether the vehicle has any abnormalities based on the driving data;

[0010] If such a vehicle exists, it will be marked as an abnormal vehicle.

[0011] Optionally, receiving the driving data uploaded by the vehicle includes:

[0012] The data acquisition thread determines the time to receive the driving data and stores the driving data in the first data processing queue;

[0013] When new driving data uploaded by the vehicle is received, the data acquisition thread determines the reception time of the new driving data and causes the new driving data to overwrite the driving data in the first data processing queue.

[0014] Optionally, determining whether the vehicle is offline based on the driving data includes:

[0015] The preprocessing thread performs a deep copy of the first data processing queue to obtain the second data processing queue;

[0016] The preprocessing thread determines a first interval between the reception time of the driving data in the second data processing queue and the current time, and determines whether the first interval exceeds the offline threshold.

[0017] If so, the preprocessing thread confirms that the vehicle is offline, generates an offline record based on the vehicle's driving data, and saves it to the database;

[0018] The preprocessing thread removes the driving data of offline vehicles from the first data processing queue and the second data processing queue.

[0019] Optionally, after the preprocessing thread confirms that the vehicle is offline, the method further includes:

[0020] The preprocessing thread retrieves all offline records of the offline vehicles from the database.

[0021] The preprocessing thread determines the offline interval based on all offline records of the vehicle and determines whether the offline interval exceeds the abnormal threshold.

[0022] If so, the preprocessing thread generates a special offline exception report and sends the special offline exception report to a preset location;

[0023] If not, the preprocessing thread generates a normal offline exception report and sends the normal offline exception report to the preset location.

[0024] Optionally, the driving data includes position coordinates, current speed, driving status, and fault codes;

[0025] The step of determining whether the vehicle has any abnormalities based on the driving data includes:

[0026] The exception handling thread performs a deep copy of the second data processing queue to obtain the third data processing queue;

[0027] The exception handling thread divides the third data processing queue into a manual driving queue and an automatic driving queue according to the action status; the action status includes manual driving status and automatic driving status.

[0028] The anomaly detection and processing thread divides the autonomous driving queue into a moving vehicle queue and a stationary vehicle queue based on the current speed.

[0029] The exception handling thread determines whether the fault codes in the vehicle queue match the fault code table in the database.

[0030] If so, the anomaly detection and processing thread will mark the vehicle whose fault code matches the fault code table as the first abnormal vehicle, and add the driving data of the first abnormal vehicle to the driving abnormal vehicle queue.

[0031] The exception handling thread determines whether a vehicle is in a prohibited area based on its position coordinates in the vehicle queue.

[0032] If the vehicle is in the prohibited area, the anomaly detection and processing thread will mark the vehicle in the prohibited area as a second abnormal vehicle and add the driving data of the second abnormal vehicle to the driving abnormal vehicle queue.

[0033] The anomaly detection and processing thread generates a driving vehicle fault report for all abnormal vehicles whose driving data is in the driving anomaly vehicle queue, and sends the driving vehicle fault report to a preset location.

[0034] Optionally, after the exception handling thread divides the third data processing queue into a manual driving queue and an automatic driving queue based on the action state, the method further includes:

[0035] The anomaly detection and processing thread determines whether the fault codes in the stationary vehicle queue match the fault code table.

[0036] If so, the anomaly detection and processing thread will mark the vehicle whose fault code matches the fault code table as the third abnormal vehicle, and add the driving data of the third abnormal vehicle to the stationary abnormal vehicle queue.

[0037] If not, the exception handling thread will add the driving data of vehicles whose fault codes do not match the fault code table to the stationary vehicle monitoring queue.

[0038] The anomaly detection and processing thread determines the area where the vehicle is located based on the coordinates in the stationary vehicle monitoring queue, and determines the allowed parking time of the vehicle based on the area.

[0039] The anomaly detection and processing thread determines a second interval between the reception time of the driving data in the stationary vehicle monitoring queue and the current time, and determines whether the second interval exceeds the allowed parking time.

[0040] If the second interval exceeds the allowed parking time, the exception handling thread determines whether the action status in the stationary vehicle monitoring queue matches the parking status table in the database.

[0041] If the action status in the stationary vehicle monitoring queue does not match the parking status table in the database, the vehicle is marked as the fourth abnormal vehicle, and the driving data of the fourth abnormal vehicle is added to the stationary abnormal vehicle queue.

[0042] If the action status in the stationary vehicle monitoring queue matches the parking status table in the database, then determine whether the second interval exceeds the global parking limit time.

[0043] If the second interval exceeds the global parking time limit, the vehicle is marked as the fifth abnormal vehicle, and the driving data of the fifth abnormal vehicle is added to the stationary abnormal vehicle queue.

[0044] Optionally, the method further includes:

[0045] All abnormal vehicles in the abnormal driving vehicle queue and the abnormal stationary vehicle queue are marked as warning vehicles and displayed on the monitoring web page.

[0046] An upload command is sent to all the abnormal vehicles so that each of the abnormal vehicles uploads the driving data to the database.

[0047] A device for vehicle anomaly monitoring, comprising:

[0048] A receiving module is used to receive driving data uploaded by the vehicle; the driving data includes at least one of the following: position coordinates, current speed, driving status, and fault code.

[0049] The first judgment module is used to determine whether the vehicle is offline based on the driving data;

[0050] The second judgment module is used to determine whether the vehicle is abnormal based on the driving data when the vehicle is not offline;

[0051] The anomaly marking module is used to mark the vehicle as an abnormal vehicle when the vehicle has an anomaly.

[0052] An electronic device, comprising:

[0053] A processor and a memory, the memory being used to store at least one instruction, which, when loaded and executed by the processor, implements the vehicle anomaly monitoring method as described in any of the preceding embodiments.

[0054] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method for vehicle anomaly monitoring as described in any of the preceding claims.

[0055] The vehicle anomaly monitoring method provided in this invention determines whether a vehicle is offline based on its uploaded driving data. If not, it determines whether the vehicle is abnormal based on the driving data. If an anomaly is found, the vehicle is marked as an abnormal vehicle. This invention, by analyzing the driving data uploaded by unmanned logistics vehicles in real time, can accurately determine the offline status of vehicles, promptly identify and mark abnormal vehicles, and achieve comprehensive monitoring of the abnormal status of unmanned logistics vehicles. This allows the dispatching system to react quickly, avoiding potential traffic congestion and accidents. This not only optimizes vehicle dispatching decisions but also reduces delays caused by vehicle malfunctions or improper operation, improving the overall efficiency of logistics transportation. Attached Figure Description

[0056] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0057] Figure 1 A flowchart illustrating a method for vehicle anomaly monitoring provided in an embodiment of the present invention;

[0058] Figure 2 for Figure 1 A flowchart illustrating one actual manifestation of S02 in a provided method for vehicle anomaly detection;

[0059] Figure 3 for Figure 1 A flowchart illustrating an actual manifestation of S03 in a provided method for vehicle anomaly detection;

[0060] Figure 4 for Figure 1 A flowchart illustrating another practical manifestation of S03 in a provided method for vehicle anomaly detection;

[0061] Figure 5 This is a schematic diagram of the structure of a vehicle anomaly monitoring device provided in an embodiment of the present invention. Detailed Implementation

[0062] To better understand the technical solution of the present invention, the embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0063] It should be understood that the described embodiments are merely some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0064] The terminology used in the embodiments of this invention is for the purpose of describing particular embodiments only and is not intended to limit the invention. The singular forms “a,” “the,” and “the” as used in the embodiments of this invention and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0065] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0066] With the rapid development of autonomous driving technology, unmanned logistics vehicles are now able to utilize single-vehicle intelligent modules, such as perception, localization, control, decision-making, and system control, to achieve automated cargo transportation from point A to point B within a park. When performing tasks, these vehicles need to navigate autonomously in complex traffic environments, including parking, two-way travel, and crossing intersections.

[0067] However, in actual operation, unmanned logistics vehicles may encounter various unforeseen situations, leading to abnormal vehicle behavior. These abnormal states not only affect the vehicle's own operational safety but may also interfere with other normally operating vehicles and dispatch decisions. For example, when parking, traveling in both directions, or crossing intersections, the presence of abnormal vehicles may cause traffic congestion or increase the risk of collisions, thereby affecting the efficiency and safety of the entire logistics system.

[0068] Therefore, the present invention provides a method for vehicle anomaly monitoring to solve the above-mentioned problems.

[0069] Please refer to Figure 1 The flowchart below shows a method for vehicle anomaly monitoring provided by an embodiment of the present invention, which includes the following steps:

[0070] Step S01: Receive driving data uploaded by the vehicle.

[0071] The driving data includes at least one of the following: location coordinates, current speed, driving status, and fault codes.

[0072] In this embodiment, the cloud server acquires various data generated by the unmanned logistics vehicle in real time during operation via wireless communication technologies such as the MQTT protocol. This data includes at least key information such as location coordinates, current speed, operational status, and fault codes. Location coordinates provide the vehicle's precise geographical location, current speed reflects the vehicle's motion state, operational status describes the vehicle's operating mode, such as driving, parking, or turning, and fault codes are any potential problems or errors reported by the vehicle after self-diagnosis.

[0073] The collection of this driving data is used to determine whether the vehicle is operating normally. By analyzing the driving data, the vehicle's status can be monitored in real time, abnormal behavior or malfunctions can be detected in a timely manner, and corresponding measures can be taken. Such monitoring not only improves the safety of vehicle operation, but also helps to optimize scheduling decisions, reduce traffic congestion and accident risks, and improve the efficiency of the entire logistics system.

[0074] In some embodiments, receiving driving data uploaded by the vehicle is achieved by integrating sensors and communication modules onto the unmanned logistics vehicle. These devices are capable of collecting vehicle operating information in real time. Specific operations include:

[0075] 1) Install sensors: Install a GPS positioning system on the vehicle to obtain location coordinates, a speed sensor to monitor the current speed, and sensors for detecting the vehicle's motion status, such as steering angle sensors and brake sensors.

[0076] 2) Integrated fault diagnosis system: The vehicle is equipped with an on-board diagnostic system to monitor the vehicle's health status in real time and generate fault codes.

[0077] 3) Communication module configuration: The vehicle is equipped with a module that uses MQTT or other communication protocols to upload the collected data to the cloud server.

[0078] 4) Data upload: During the vehicle's operation, it periodically sends the collected data, such as location coordinates, current speed, action status, and fault codes, to the cloud via the communication module.

[0079] 5) Cloud data processing: After receiving the data, the cloud server stores and analyzes it to determine whether the vehicle is offline or exhibits abnormal behavior.

[0080] In this way, the cloud server can monitor the vehicle's dynamics in real time, promptly identify and respond to potential problems, and ensure the safe and efficient operation of unmanned logistics vehicles.

[0081] Step S02: Determine whether the vehicle is offline based on the driving data.

[0082] If not, proceed to step S03.

[0083] In this embodiment, the system determines whether a vehicle has lost communication with the monitoring system by analyzing the driving data uploaded by the vehicle. This process involves analyzing the continuity and timestamps of data transmission. For example, if a vehicle does not upload new data within the expected time, or if data transmission is suddenly interrupted, the system will consider the vehicle offline. Based on this, the system can promptly detect vehicle communication problems and take corresponding measures, such as attempting to re-establish the connection, sending alarms, or adjusting the scheduling plan, to ensure the continuity and security of logistics operations.

[0084] In some embodiments, a predefined time threshold can be set to measure the frequency of vehicle data reporting. The system continuously monitors the data stream uploaded by the vehicle, and if the vehicle fails to upload new driving data within the time threshold, the system will consider the vehicle to be offline. The specific operation steps are as follows:

[0085] 1) Set a time threshold: Based on the data reporting frequency during normal vehicle operation, set a reasonable time threshold, such as reporting data once every 5 minutes.

[0086] 2) Monitoring data reporting: The system continuously monitors the data reporting status of vehicles and records the timestamp of each data report.

[0087] 3) Detecting offline status: If a vehicle fails to report new data after a time threshold has elapsed, the system will trigger an offline detection mechanism to further confirm the vehicle's offline status.

[0088] 4) Send an alarm or attempt to reconnect: Once the vehicle is confirmed to be offline, the system will send an alarm notification and attempt to re-establish the connection with the vehicle through the communication module.

[0089] 5) Record offline events: Regardless of whether the vehicle comes back online, the system will record the offline event, including the offline time, duration, and possible causes, for subsequent analysis and maintenance.

[0090] This method can effectively monitor the online status of unmanned logistics vehicles, promptly identify and address offline issues, and ensure stable vehicle operation and continuity of cargo transportation.

[0091] Step S03: Determine whether there is any abnormality in the vehicle based on the driving data.

[0092] If so, proceed to step S04.

[0093] In this embodiment, driving data uploaded by the vehicle is used to analyze and determine whether the vehicle exhibits abnormal behavior. This process involves real-time monitoring and analysis of vehicle data to identify any deviations from the expected operating pattern. For example, sudden abnormal changes in vehicle speed, significant deviations in position coordinates from the expected path, discrepancies between the vehicle's operating state and actual driving conditions, or problems with fault code indications could all be abnormal signals.

[0094] In some embodiments, the cloud server can pre-set baseline values ​​for normal driving parameters, such as speed range, reasonable changes in position coordinates, normal operating modes, and normal fault code states. Then, the real-time collected data is compared with the preset baselines, and algorithms are used to detect whether the data is within the normal range. If the data exceeds the normal range or pattern, the system will identify it as an anomaly, such as abnormal speed, position deviation, incorrect operating mode, or fault code indication problems. Once an anomaly is detected, the system will trigger an alarm mechanism, notify monitoring personnel, and may automatically take countermeasures, such as adjusting the vehicle's route or requesting maintenance. Finally, detailed information about the anomaly event is recorded for subsequent analysis and system optimization, and feedback is also provided to the vehicle maintenance team for necessary inspection and repair.

[0095] In some embodiments, if it is determined from the driving data that the vehicle does not have any abnormalities, the process can return to step S01 to continue receiving the driving data uploaded by the vehicle and perform the next vehicle abnormality monitoring.

[0096] Step S04: Mark the vehicle as an abnormal vehicle.

[0097] In this embodiment, when the cloud server detects abnormal behavior or status of a vehicle by analyzing its driving data, the system automatically identifies and classifies the vehicle as an abnormal vehicle. This labeling behavior enables the vehicle management and dispatch system to quickly identify and respond to potentially problematic vehicles.

[0098] In some embodiments, after marking abnormal vehicles, the cloud server can automatically execute a series of preset emergency measures, such as adjusting the vehicle's route to avoid potential dangers or restricting certain vehicle functions to prevent the fault from spreading. Simultaneously, this information will also be used for subsequent data analysis and vehicle maintenance to improve the operational efficiency and safety of the entire fleet.

[0099] Based on the above technical solution, the vehicle anomaly monitoring method provided in this embodiment of the invention determines whether a vehicle is offline by analyzing the driving data uploaded by the vehicle; if not, it determines whether the vehicle is abnormal based on the driving data; if an anomaly is found, the vehicle is marked as an abnormal vehicle. This invention, by analyzing the driving data uploaded by unmanned logistics vehicles in real time, can accurately determine the offline status of vehicles, promptly identify and mark abnormal vehicles, and achieve comprehensive monitoring of the abnormal status of unmanned logistics vehicles. This allows the dispatching system to react quickly, avoiding potential traffic congestion and accidents. This not only optimizes vehicle dispatching decisions but also reduces delays caused by vehicle malfunctions or improper operation, improving the overall efficiency of logistics transportation.

[0100] Based on the above embodiments, in some embodiments, the step S01 mentioned, receiving the driving data uploaded by the vehicle, may specifically include the following steps:

[0101] In step S11, the data acquisition thread determines the time to receive the driving data and stores the driving data in the first data processing queue.

[0102] In this embodiment, the data acquisition thread, as part of the system, is responsible for monitoring and receiving data uploaded from the vehicle. Once the data arrives, the thread records the data reception time; this timestamp is crucial for subsequent analysis of the timeliness of the data and changes in vehicle status.

[0103] Storing this data in the first data processing queue is for preliminary data organization and queuing, so that subsequent processing can proceed efficiently and orderly. This is done to ensure the continuity and real-time nature of data processing, enabling the system to quickly respond to the real-time status of vehicles and promptly detect anomalies and make dispatching decisions.

[0104] The implementation of this mechanism improves the efficiency and accuracy of data processing, helps to promptly detect and handle any anomalies that may occur during vehicle operation, thereby ensuring the safe operation of unmanned logistics vehicles and the smooth operation of the entire logistics system. In this way, the intelligence level of unmanned logistics vehicles can be significantly enhanced, ensuring the continuity and reliability of cargo transportation.

[0105] In step S12, when new driving data uploaded by the vehicle is received, the data acquisition thread determines the reception time of the new driving data and causes the new driving data to overwrite the driving data in the first data processing queue.

[0106] This embodiment provides a mechanism for updating vehicle status information. The core of this mechanism is to ensure that the monitoring system always has the latest vehicle information. When the data acquisition thread receives new driving data, it records the reception time of this data; this timestamp is a key indicator for determining whether the vehicle is offline. Subsequently, the new driving data replaces the old driving data in the first data processing queue, ensuring that the queue always contains the latest vehicle status information.

[0107] The purpose of this approach is to maintain the real-time nature and accuracy of driving data, as vehicle conditions can change rapidly, such as speed, position, or motion status. By overwriting older data, the system ensures that anomaly detection or dispatch decisions are based on the most up-to-date information.

[0108] Based on the above technical solution, this embodiment provides a dynamically updated vehicle status snapshot, enabling the system to perform vehicle behavior analysis and anomaly detection based on the latest data. By overwriting old data with newly received data, the system always maintains the latest vehicle status, which helps improve the timeliness and accuracy of anomaly monitoring. This allows the system to respond more quickly to changes in vehicle status, promptly identify and handle anomalies, thereby improving the operational efficiency and safety of the entire unmanned logistics system.

[0109] Please refer to Figure 2 ,for Figure 1 A flowchart illustrating one actual manifestation of step S02 in a vehicle anomaly detection method is provided. Based on the above embodiments, in some embodiments, step S02, which involves determining whether the vehicle is offline based on driving data, may specifically include the following steps:

[0110] Step S21: The preprocessing thread performs a deep copy of the first data processing queue to obtain the second data processing queue.

[0111] In this embodiment, to ensure the integrity and security of the original data while allowing independent operation on the data, the preprocessing thread creates a complete copy of all data in the first data processing queue and stores this copy in the second data processing queue. This is done to ensure that the original data is not affected during data preprocessing and analysis, thereby avoiding potential data corruption or loss during processing.

[0112] This deep copy mechanism is crucial for maintaining data consistency and reliability. By processing data in a second data processing queue, various operations, such as data cleaning, format conversion, and anomaly detection, can be performed safely without affecting the original data in the first data processing queue. This is essential for ensuring the accuracy of data analysis and the stability of the system. Furthermore, if errors occur during preprocessing, the original data remains unchanged and can be reprocessed, providing a fault-tolerant mechanism for data processing. In this way, the reliability of the unmanned logistics vehicle monitoring system and the flexibility of data processing can be improved.

[0113] In step S22, the preprocessing thread determines the first interval between the reception time of the driving data in the second data processing queue and the current time, and determines whether the first interval exceeds the offline threshold.

[0114] If so, proceed to step S23.

[0115] In this embodiment, the preprocessing thread calculates the time difference (i.e., the first interval) from the last time the vehicle uploaded data to the present, and compares the first interval with the offline threshold preset by the system. If the first interval exceeds the threshold, the system considers the vehicle to be offline.

[0116] The purpose of this process is to ensure timely detection and response to vehicle communication anomalies, thereby maintaining the stability and reliability of the entire logistics system. In this way, the monitoring system can take swift action when a vehicle loses contact, such as attempting to re-establish the connection, notifying the maintenance team, or adjusting the scheduling plan to avoid potential transportation delays or security risks.

[0117] Step S23: The preprocessing thread confirms that the vehicle is offline, generates offline records based on the vehicle's driving data, and saves them to the database.

[0118] In this embodiment, when the preprocessing thread determines that the first interval exceeds the preset offline threshold, it generates an offline record containing detailed information about the vehicle when it is offline (such as time, location, last received status, etc.) and saves this information to the database.

[0119] This process provides traceability of the vehicle's operational history, enabling the maintenance team to quickly understand the vehicle's offline status and take appropriate action. At the same time, these records also provide valuable data for the system to analyze vehicle behavior, predict potential problems, and optimize scheduling strategies.

[0120] In some embodiments, after the preprocessing thread confirms that the vehicle is offline in step S23, the following steps may also be performed:

[0121] Step S31: The preprocessing thread retrieves all offline records of offline vehicles from the database.

[0122] In this embodiment, after a vehicle is confirmed to be offline, the preprocessing thread retrieves all historical offline data of the vehicle from the database. The purpose is to conduct a more comprehensive analysis of the vehicle's offline behavior. By checking the vehicle's offline history, it is possible to more accurately determine whether the vehicle's current status is within the normal fluctuation range or whether it exhibits an abnormal offline mode.

[0123] In step S32, the preprocessing thread determines the offline interval based on all offline records of the vehicle and determines whether the offline interval exceeds the abnormal threshold.

[0124] If yes, proceed to step S33; otherwise, proceed to step S34.

[0125] In this embodiment, the preprocessing thread analyzes the vehicle offline records stored in the database and calculates the time intervals between offline events to determine the frequency and duration of vehicle offline events. The purpose of this step is to identify vehicle offline patterns so that they can be compared with preset anomaly thresholds to determine whether the vehicle's offline behavior is normal.

[0126] By comparing offline intervals with anomaly thresholds, the system can more accurately identify vehicles requiring urgent attention, thereby enabling timely action such as notifying the maintenance team, adjusting scheduling plans, or upgrading the system to reduce offline events and improve vehicle reliability and the efficiency of the entire logistics system.

[0127] Step S33: The preprocessing thread generates a special offline exception report and sends the special offline exception report to a preset location.

[0128] In this embodiment, when the preprocessing thread analyzes the vehicle's offline records and finds that the offline interval exceeds the system-set anomaly threshold, it indicates that the vehicle may have encountered a serious problem or is in a persistent fault state. In this case, the system will automatically trigger the generation of a special offline anomaly report that details the vehicle's offline status.

[0129] In some embodiments, a special offline anomaly report may include key information such as vehicle identification information, the specific time of offline occurrence, duration, frequency of offline occurrence, and possible cause analysis. After generating the report, the system will send it to a preset location, such as the monitoring center, the maintenance team's email address, the system administrator, or a relevant dispatch system. This is to ensure that all relevant parties are promptly notified and can take necessary countermeasures.

[0130] Step S34: The preprocessing thread generates a normal offline exception report and sends the normal offline exception report to a preset location.

[0131] In this embodiment, when the vehicle's offline interval does not exceed a predetermined anomaly threshold, it indicates that the vehicle's offline behavior may be due to normal fluctuations or minor communication problems. In this case, the preprocessing thread generates a normal offline anomaly report, recording the vehicle's offline event, but does not mark it as an emergency.

[0132] In some embodiments, the standard offline anomaly report may include basic vehicle information, offline time, duration, and possible causes of offline status, but will not include in-depth analysis or emergency response instructions found in a special offline anomaly report. Once generated, the standard offline anomaly report is sent to a pre-defined location, such as a monitoring system, maintenance team, or vehicle management personnel, so that they can conduct routine reviews and take necessary follow-up actions.

[0133] Based on the above technical solution, this embodiment can distinguish between ordinary vehicle offline situations and frequent or prolonged offline situations that may indicate more serious problems. This detailed offline anomaly reporting mechanism helps improve the intelligence level of the monitoring system, making vehicle management more accurate and efficient. Through in-depth analysis of offline behavior, the root causes of frequent offline situations can be identified and resolved in a timely manner, thereby improving the stability and reliability of the entire unmanned logistics system.

[0134] In step S24, the preprocessing thread removes the driving data of offline vehicles from the first data processing queue and the second data processing queue.

[0135] In this embodiment, after confirming a vehicle is offline, the preprocessing thread removes all driving data related to the offline vehicle from both data processing queues to optimize data storage and processing efficiency. Removing this data ensures a clean data queue, avoids unnecessary data redundancy, and also helps improve the speed and accuracy of data processing. By cleaning up unnecessary data, the system can more effectively allocate resources, such as storage space and processing power, thereby improving the monitoring quality of online vehicles. Furthermore, this also helps reduce the potential impact of erroneous data on system decisions, ensuring the accuracy of scheduling and anomaly detection.

[0136] Based on the above technical solution, this embodiment can promptly identify the offline status of a vehicle, thereby allowing the system to take appropriate measures to deal with possible communication failures or vehicle malfunctions. By comparing the interval between the data reception time and the current time, the system can automatically determine whether the vehicle has exceeded a preset offline threshold. Once offline is confirmed, an offline record is generated and saved to the database, while the relevant data is removed from the processing queue to ensure the accuracy of data processing and the cleanliness of the queue.

[0137] Please refer to Figure 3 ,for Figure 1A flowchart illustrating one actual manifestation of S03 in a provided method for vehicle anomaly monitoring. Based on the above embodiments, in some embodiments, the driving data includes position coordinates, current speed, operating status, and fault codes.

[0138] Step S03, which mentions determining whether a vehicle has any abnormalities based on driving data, may specifically include the following steps:

[0139] Step S41: The exception handling thread performs a deep copy of the second data processing queue to obtain the third data processing queue.

[0140] In this embodiment, the anomaly detection and processing thread creates a complete copy of all data in the second data processing queue and stores this copy in a new third data processing queue. This is done to ensure that the original data in the second data processing queue is not affected during anomaly detection and analysis, and to ensure that other processing threads that may be running concurrently can continue to access the unmodified data.

[0141] Deep copying avoids potential data modifications during anomaly detection that could negatively impact other system functions that rely on that data. Furthermore, if complex data operations or analysis are required during anomaly detection, deep copying provides a secure data environment, ensuring the integrity of the original data even if operations fail or require rollback. This approach improves data processing flexibility and system robustness, ensuring the accuracy of anomaly detection and stable system operation.

[0142] Step S42: The exception handling thread divides the third data processing queue into a manual driving queue and an automatic driving queue based on the action status.

[0143] The driving status includes manual driving status and automatic driving status.

[0144] Given the potential for program malfunctions in unmanned vehicles after manual takeover in existing technologies, these issues, if not properly identified and addressed, could affect the normal dispatching of unmanned logistics vehicles.

[0145] Therefore, by distinguishing between manual driving and autonomous driving states, this embodiment can more accurately monitor and evaluate vehicle behavior, ensuring that even if program malfunctions occur after manual takeover, they can be correctly identified and reported without affecting other normally operating unmanned logistics vehicles. This helps improve the accuracy of anomaly detection, enabling the scheduling system to take appropriate countermeasures for anomalies in different situations, thereby optimizing scheduling decisions and reducing scheduling chaos or errors caused by anomaly reporting. Through the clear distinction between manual driving and autonomous driving states,

[0146] Step S43: The exception handling thread divides the autonomous driving queue into a moving vehicle queue and a stationary vehicle queue based on the current speed.

[0147] In this embodiment, the anomaly detection thread analyzes the vehicle's current speed data to determine whether the vehicle is in motion or stationary. If the vehicle's current speed is below a preset threshold, it is classified as a stationary vehicle; conversely, if the speed is above the threshold, it is classified as a moving vehicle.

[0148] The purpose of this embodiment is to more accurately monitor and manage vehicle status, as moving and stationary vehicles may face different operational requirements and potential risks. For example, stationary vehicles may need to comply with specific parking rules, while moving vehicles need to pay attention to speed limits and traffic flow. Through this classification, the system can implement specific monitoring strategies and anomaly detection logic for different vehicle states, thereby improving the safety and efficiency of the unmanned logistics system.

[0149] Furthermore, this classification helps address specific scenarios, such as when parking, driving in both directions, or crossing intersections, the presence of abnormal vehicles can affect the dispatching decisions for vehicles already in traffic or already at intersections. By meticulously classifying autonomous vehicles, the system can more effectively identify and respond to abnormal behavior in these situations.

[0150] Step S44: The exception handling thread determines whether the fault codes in the vehicle queue match the fault code table in the database.

[0151] If so, proceed to step S45.

[0152] In this embodiment, the anomaly detection and processing thread compares the fault codes uploaded by the vehicle with a pre-defined fault code table in the database. The fault code table contains various known fault types and their corresponding error information, used to diagnose the vehicle's health status. This process enables the system to quickly identify whether a vehicle has a fault and to determine the type of fault and its potential impact.

[0153] In step S45, the anomaly detection and processing thread marks the vehicle whose fault code matches the fault code table as the first abnormal vehicle and adds the driving data of the first abnormal vehicle to the driving abnormal vehicle queue.

[0154] In this embodiment, when a fault code matches a fault code table stored in the database, it indicates that the vehicle may have encountered a predefined fault or problem. In this case, the anomaly detection and processing thread will identify the vehicle as the first abnormal vehicle and add its driving data to the abnormal vehicle queue for further monitoring and management.

[0155] Step S46: The exception handling thread determines whether a vehicle is in a prohibited area based on its position coordinates in the vehicle queue.

[0156] If so, proceed to step S47.

[0157] In this embodiment, the anomaly detection processing thread analyzes the vehicle's location coordinates and compares them with prohibited areas defined in the database. If the vehicle's location coordinates match these prohibited areas, the system will identify that the vehicle has violated driving rules. The purpose is to prevent vehicles from accidentally entering restricted areas, thereby avoiding potential safety risks and operational problems. By monitoring the vehicle's location in real time, the system can issue timely warnings or take measures, such as adjusting the vehicle's route, to ensure the vehicle operates safely and compliantly.

[0158] In step S47, the exception handling thread marks the vehicle in the prohibited area as the second abnormal vehicle and adds the driving data of the second abnormal vehicle to the driving abnormal vehicle queue.

[0159] In this embodiment, when the system confirms that a vehicle has illegally entered a prohibited area by comparing the vehicle's real-time location coordinates with the prohibited areas defined in the database, the anomaly detection and processing thread will mark these vehicles as second abnormal vehicles and add their driving data to the abnormal vehicle queue for further monitoring and management.

[0160] Step S48: The exception judgment and processing thread generates a driving vehicle fault report for all abnormal vehicles whose driving data is in the driving abnormal vehicle queue, and sends the driving vehicle fault report to a preset location.

[0161] In this embodiment, when a vehicle is marked as an abnormal vehicle and added to the queue of abnormal vehicles due to fault code matching or location anomalies, the system automatically generates detailed fault reports for these vehicles. These reports contain key data such as vehicle identification information, fault details, occurrence time, and location coordinates, providing necessary information for fault diagnosis and subsequent processing.

[0162] An malfunctioning vehicle while in motion is considered an emergency requiring immediate attention. After generating a vehicle malfunction report, the system will send it to pre-defined locations, such as the monitoring center, maintenance team, or vehicle management personnel, ensuring all relevant parties are promptly notified and can take necessary countermeasures. This is done to improve response speed, ensure timely handling of malfunctioning vehicles, and reduce potential safety risks and operational disruptions.

[0163] Based on the above technical solution, this embodiment achieves accurate identification and management of abnormal vehicle states, significantly improving the safety and reliability of the unmanned logistics system. By further subdividing autonomous vehicles, this embodiment enables the system to more accurately identify vehicles requiring special attention, such as those entering prohibited areas due to fault code matching or location anomalies. This embodiment improves the accuracy of anomaly detection, reduces false alarms and unnecessary maintenance work, optimizes resource allocation, and ensures timely intervention for vehicles that truly require emergency response.

[0164] Please refer to Figure 4 ,for Figure 1 A flowchart illustrating another practical manifestation of S03 in a provided method for vehicle anomaly detection. Based on the above embodiments, in some embodiments, after the anomaly judgment processing thread divides the third data processing queue into a manual driving queue and an autonomous driving queue according to the action state, the following steps may also be performed:

[0165] Step S51: The exception handling thread determines whether the fault codes in the stationary vehicle queue match the fault code table.

[0166] If yes, proceed to step S52; otherwise, proceed to step S53.

[0167] In this embodiment, the anomaly detection thread compares the fault codes of stationary vehicles with the fault code table stored in the database to determine whether the vehicle has any known faults or problems. This allows the system to quickly identify the fault status of stationary vehicles and take appropriate measures. If the fault code matches an entry in the fault code table, step S52 is executed. Otherwise, step S53 is executed.

[0168] In step S52, the anomaly detection and processing thread marks the vehicle whose fault code matches the fault code table as the third abnormal vehicle and adds the driving data of the third abnormal vehicle to the stationary abnormal vehicle queue.

[0169] In this embodiment, when a fault code of a stationary vehicle matches the fault code table in the database, it indicates that the vehicle has a known fault or problem. In this case, the anomaly detection and processing thread marks the vehicle as a third abnormal vehicle, indicating that it requires special attention and handling. The purpose of adding these potentially faulty vehicles to the stationary abnormal vehicle queue is to centrally manage and monitor them.

[0170] In step S53, the anomaly detection and processing thread adds the driving data of vehicles whose fault codes do not match the fault code table to the stationary vehicle monitoring queue.

[0171] In this embodiment, when a vehicle's fault codes are compared with the fault code table in the database, if no match is found, it may mean that the vehicle has not reported any known faults, or that there is a problem not covered by the fault code table. In this case, the driving data of these vehicles is added to the stationary vehicle monitoring queue for further observation and analysis of vehicle behavior to determine whether they are truly problem-free or require further inspection. This measure helps to identify vehicles that may not immediately trigger fault codes but may have potential problems, such as abnormal parking behavior or positional deviations.

[0172] Step S54: The exception handling thread determines the area where the vehicle is located based on the coordinates in the stationary vehicle monitoring queue, and determines the allowed parking time of the vehicle based on the area.

[0173] In this embodiment, the system analyzes the coordinates of stationary vehicles to identify their specific locations, such as parking lots, loading / unloading areas, or no-parking zones. Then, based on the parking rules and restrictions of these areas, the system determines the permitted parking duration for each vehicle within that area.

[0174] For example, to effectively manage stationary vehicles, staff can manually draw geofences on a digital map beforehand to distinguish between intersection monitoring areas and non-intersection monitoring areas. Intersection monitoring areas are defined as a range within a certain distance from the intersection; this distance is set based on traffic flow and safety requirements, for example, it might be set as a 50-meter radius around the intersection. The purpose of this area is to prioritize and schedule vehicles to pass through the intersection, ensuring smooth traffic flow.

[0175] Within the monitored area at the intersection, the system has a set short permitted parking time, such as 3 minutes, to reduce vehicle dwell time at the intersection and avoid traffic congestion. The monitoring system starts timing when a vehicle enters this area and stops. If the vehicle does not restart within 3 minutes, the system will issue a warning.

[0176] Step S55: The exception handling thread determines the second interval between the reception time of the driving data in the stationary vehicle monitoring queue and the current time, and determines whether the second interval exceeds the allowed parking time.

[0177] If so, proceed to step S56.

[0178] In this embodiment, the exception handling thread calculates a second interval between the time the driving data was received and the current time. By comparing the second interval with the allowed parking duration, the system can determine whether the vehicle has violated parking regulations. If the second interval exceeds the allowed parking duration, it may mean that the vehicle is illegally parked in the area or has malfunctioned, at which point step S56 is executed.

[0179] Step S56: The exception handling thread determines whether the action status in the stationary vehicle monitoring queue matches the parking status table in the database.

[0180] If not, proceed to step S57; if yes, proceed to step S58.

[0181] In this embodiment, when a vehicle's parking time in a specific area exceeds a preset allowed parking duration, the system further checks the vehicle's operational status to determine whether its parking is considered normal and acceptable. The operational status information is compared with a predefined table of acceptable parking states in the database. This table lists all situations considered normal parking, such as obstacle avoidance parking, arrival at the destination, loading / unloading operations, and waiting for a traffic signal.

[0182] This embodiment can distinguish between abnormal and normal parking behavior of a vehicle. If the vehicle's status does not match the entries in the parking status table, it indicates a problem with the vehicle, such as a malfunction or improper parking, requiring immediate attention. This judgment helps the system more accurately identify abnormal situations requiring intervention and avoids unnecessary interference with vehicles that are parked normally.

[0183] Step S57: Mark the vehicle as the fourth abnormal vehicle and add the driving data of the fourth abnormal vehicle to the queue of stationary abnormal vehicles.

[0184] In this embodiment, when a vehicle's parking time exceeds a preset time limit and its operational status does not match the parking status defined in the database, it indicates that the vehicle may be malfunctioning. At this point, these vehicles are marked as fourth abnormal vehicles and added to the queue of stationary abnormal vehicles, indicating that they require special attention and handling. The purpose of adding them to the queue of stationary abnormal vehicles is to centrally manage and monitor these potentially malfunctioning vehicles.

[0185] Step S58: Determine whether the second interval exceeds the global parking time limit.

[0186] If so, proceed to step S59.

[0187] In this embodiment, when the vehicle's movement state matches the parking-permitted states defined in the database, it indicates that the vehicle's stationary position is for a legitimate or anticipated reason, such as loading / unloading operations or waiting for a traffic signal. However, even in these permitted parking states, the vehicle cannot remain stationary indefinitely, therefore a global parking time limit needs to be set.

[0188] The global parking time limit is the maximum permissible parking time across the entire system, covering all areas and situations. If a vehicle's stationary time (second interval) exceeds this global limit, the system will consider it an anomaly, even if the vehicle's status matches the parking status table. This judgment helps prevent traffic congestion or safety risks that may be caused by vehicles remaining stationary for extended periods.

[0189] Step S59: Mark the vehicle as the fifth abnormal vehicle and add the driving data of the fifth abnormal vehicle to the stationary abnormal vehicle queue.

[0190] In this embodiment, when the stationary time (second interval) of a vehicle exceeds the global parking limit time set by the system, these vehicles are marked as the fifth abnormal vehicles and added to the stationary abnormal vehicle queue to ensure that these vehicles that have been parked for a long time can receive timely attention and handling.

[0191] Based on the above embodiments, in some embodiments, the following steps may also be performed:

[0192] Mark all abnormal vehicles in the abnormal driving vehicle queue and the abnormal stationary vehicle queue as warning vehicles and output the warning to the monitoring web page for display.

[0193] Send an upload command to all abnormal vehicles so that each abnormal vehicle uploads its driving data to the database.

[0194] In this embodiment, by highlighting these abnormal vehicles on the monitoring interface, dispatchers and maintenance teams can immediately identify and pay attention to vehicles that require emergency handling, thereby speeding up the response and reducing potential safety risks and operational disruptions.

[0195] Simultaneously, upload commands are sent to all malfunctioning vehicles to ensure that the driving data of each vehicle is uploaded to the database in a timely manner, providing comprehensive data support for fault diagnosis and subsequent analysis. This data not only helps to quickly locate the cause of the problem but can also be used to optimize vehicle performance and prevent similar faults from occurring in the future.

[0196] Based on the above embodiments, in some embodiments, the relative position and speed of vehicles in the abnormal vehicle queue with normal vehicles within a certain distance can also be calculated. For example, if an abnormal vehicle suddenly decelerates or changes direction, the system will immediately calculate its relative distance and speed with surrounding normal vehicles.

[0197] After calculating the relative data, the system assesses the potential collision risk. If the relative speed and distance between the two vehicles indicate a possible collision, the scheduling thread generates a warning message. This warning message includes the vehicle identification numbers, relative distance, relative speed, and suggested collision avoidance measures.

[0198] Subsequently, the dispatch thread transmits these warning messages to the normally operating unmanned logistics vehicles via wireless communication modules. Upon receiving the warning messages, the vehicles' autonomous driving systems automatically adjust their driving paths or speeds according to preset algorithms to avoid collisions with abnormal vehicles. Simultaneously, dispatchers at the monitoring center also receive these warning messages on the monitoring webpage, allowing them to monitor the situation in real time and take necessary manual intervention measures.

[0199] Please refer to Figure 5 The diagram below illustrates the structure of a vehicle anomaly monitoring device according to an embodiment of the present invention. The vehicle anomaly monitoring device may include:

[0200] The receiving module 100 is used to receive driving data uploaded by the vehicle; the driving data includes at least one of the following: position coordinates, current speed, driving status, and fault code;

[0201] The first judgment module 200 is used to determine whether the vehicle is offline based on driving data;

[0202] The second judgment module 300 is used to determine whether there is an abnormality in the vehicle based on the driving data when the vehicle is not offline;

[0203] The anomaly marking module 400 is used to mark a vehicle as an abnormal vehicle when an anomaly is found.

[0204] Based on the above embodiments, in one specific embodiment, the receiving module 100 may be used for:

[0205] The data acquisition thread determines the time to receive driving data and stores the driving data in the first data processing queue;

[0206] When new driving data uploaded by a vehicle is received, the data acquisition thread determines the time of receipt of the new driving data and causes the new driving data to overwrite the driving data in the first data processing queue.

[0207] Based on the above embodiments, in a specific embodiment, the first determination module 200 may be used for:

[0208] The preprocessing thread performs a deep copy of the first data processing queue to obtain the second data processing queue;

[0209] The preprocessing thread determines the first interval between the reception time of the driving data in the second data processing queue and the current time, and judges whether the first interval exceeds the offline threshold.

[0210] If so, the preprocessing thread confirms that the vehicle is offline, generates an offline record based on the vehicle's driving data, and saves it to the database;

[0211] The preprocessing thread removes the driving data of offline vehicles from the first and second data processing queues.

[0212] Based on the above embodiments, in one specific embodiment, the first determination module 200 can also be used for:

[0213] The preprocessing thread retrieves all offline records of offline vehicles from the database;

[0214] The preprocessing thread determines the offline interval based on all offline records of the vehicle and checks whether the offline interval exceeds the abnormal threshold.

[0215] If so, the preprocessing thread generates a special offline exception report and places the special offline exception report at a preset location;

[0216] If not, the preprocessing thread generates a normal offline exception report and places the normal offline exception report at a preset location.

[0217] Based on the above embodiments, in one specific embodiment, the driving data includes position coordinates, current speed, driving status, and fault codes;

[0218] The second judgment module 300 can be specifically used for:

[0219] The exception handling thread performs a deep copy of the second data processing queue to obtain the third data processing queue.

[0220] The exception handling thread divides the third data processing queue into a manual driving queue and an autonomous driving queue based on the action status; the action status includes manual driving status and autonomous driving status.

[0221] The exception handling thread divides the autonomous driving queue into a moving vehicle queue and a stationary vehicle queue based on the current speed.

[0222] The exception handling thread checks whether the fault codes in the vehicle queue match the fault code table in the database.

[0223] If so, the exception handling thread will mark the vehicle whose fault code matches the fault code table as the first abnormal vehicle and add the driving data of the first abnormal vehicle to the driving abnormal vehicle queue.

[0224] The exception handling thread determines whether a vehicle is in a prohibited area based on its position coordinates in the vehicle queue.

[0225] If a vehicle is in a prohibited area, the exception handling thread will mark the vehicle in the prohibited area as the second abnormal vehicle and add the driving data of the second abnormal vehicle to the driving abnormal vehicle queue.

[0226] Generate a vehicle malfunction report for all abnormal vehicles in the abnormal vehicle queue based on driving data, and send the vehicle malfunction report to a preset location.

[0227] Based on the above embodiments, in one specific embodiment, the second determination module 300 can also be used for:

[0228] The exception handling thread checks whether the fault codes in the queue of stationary vehicles match the fault code table.

[0229] If so, the exception handling thread will mark the vehicle whose fault code matches the fault code table as the third abnormal vehicle and add the driving data of the third abnormal vehicle to the stationary abnormal vehicle queue.

[0230] If not, the exception handling thread will add the driving data of vehicles whose fault codes do not match the fault code table to the stationary vehicle monitoring queue.

[0231] The exception handling thread determines the area where the vehicle is located based on the coordinates in the stationary vehicle monitoring queue, and determines the allowed parking time of the vehicle based on the area.

[0232] The exception handling thread determines the second interval between the reception time of the driving data in the stationary vehicle monitoring queue and the current time, and determines whether the second interval exceeds the allowed parking time.

[0233] If the second interval exceeds the allowed parking time, the exception handling thread will determine whether the action status in the stationary vehicle monitoring queue matches the parking status table in the database.

[0234] If the action status in the stationary vehicle monitoring queue does not match the parking status table in the database, the vehicle will be marked as the fourth abnormal vehicle, and the driving data of the fourth abnormal vehicle will be added to the stationary abnormal vehicle queue.

[0235] If the action status in the stationary vehicle monitoring queue matches the parking status table in the database, then determine whether the second interval exceeds the global parking limit time.

[0236] If the second interval exceeds the global parking time limit, the vehicle will be marked as the fifth abnormal vehicle, and the driving data of the fifth abnormal vehicle will be added to the stationary abnormal vehicle queue.

[0237] Based on the above embodiments, in one specific embodiment, the second determination module 300 can also be used for:

[0238] Mark all abnormal vehicles in the abnormal driving vehicle queue and the abnormal stationary vehicle queue as warning vehicles and output the warning to the monitoring web page for display.

[0239] Send an upload command to all abnormal vehicles so that each abnormal vehicle uploads its driving data to the database.

[0240] This embodiment provides an electronic device, including a processor and a memory. The memory is used to store at least one instruction. When the instruction is loaded and executed by the processor, it implements the above-mentioned method for vehicle anomaly monitoring. Its execution method and beneficial effects are similar and will not be described again here.

[0241] This invention provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the above-described method for vehicle anomaly monitoring. The execution method and beneficial effects are similar and will not be described again here.

[0242] It should be noted that although the steps are described in a specific order above, it does not mean that the steps must be executed in the above specific order. In fact, some of these steps can be executed concurrently, or even in a different order, as long as the required function can be achieved.

[0243] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method of vehicle anomaly monitoring, characterized by, include: Receive driving data uploaded by vehicles; Determine whether the vehicle is offline based on the driving data; If not, then determine whether the vehicle has any abnormalities based on the driving data; If it exists, mark the vehicle as an abnormal vehicle; The driving data includes location coordinates, current speed, driving status, and fault codes. The step of determining whether the vehicle has any abnormalities based on the driving data includes: The exception handling thread performs a deep copy of the second data processing queue to obtain a third data processing queue; wherein, the second data processing queue is a data processing queue obtained by performing a deep copy of the first data processing queue, and the first data processing queue contains the driving data; The exception handling thread divides the third data processing queue into a manual driving queue and an automatic driving queue according to the action status; the action status includes manual driving status and automatic driving status. The anomaly detection and processing thread divides the autonomous driving queue into a moving vehicle queue and a stationary vehicle queue based on the current speed. The anomaly detection and processing thread determines whether the fault codes in the stationary vehicle queue match the fault code table in the database. If the fault code in the stationary vehicle queue matches the fault code table, the anomaly judgment processing thread marks the vehicle whose fault code matches the fault code table as the third abnormal vehicle and adds the driving data of the third abnormal vehicle to the stationary abnormal vehicle queue. If the fault codes in the stationary vehicle queue do not match the fault code table, the exception judgment processing thread adds the driving data of the vehicles whose fault codes do not match the fault code table to the stationary vehicle monitoring queue. The anomaly detection and processing thread determines the area where the vehicle is located based on the position coordinates in the stationary vehicle monitoring queue, and determines the allowed parking time of the vehicle based on the area. The anomaly detection and processing thread determines a second interval between the reception time of the driving data in the stationary vehicle monitoring queue and the current time, and determines whether the second interval exceeds the allowed parking time. If the second interval exceeds the allowed parking time, the exception handling thread determines whether the action status in the stationary vehicle monitoring queue matches the parking status table in the database. If the action status in the stationary vehicle monitoring queue does not match the parking status table in the database, the vehicle is marked as the fourth abnormal vehicle, and the driving data of the fourth abnormal vehicle is added to the stationary abnormal vehicle queue. If the action status in the stationary vehicle monitoring queue matches the parking status table in the database, then determine whether the second interval exceeds the global parking limit time. If the second interval exceeds the global parking time limit, the vehicle is marked as the fifth abnormal vehicle, and the driving data of the fifth abnormal vehicle is added to the stationary abnormal vehicle queue.

2. The method according to claim 1, characterized in that, The received vehicle-uploaded driving data includes: The data acquisition thread determines the time to receive the driving data and stores the driving data in the first data processing queue; When new driving data uploaded by the vehicle is received, the data acquisition thread determines the reception time of the new driving data and causes the new driving data to overwrite the driving data in the first data processing queue.

3. The method according to claim 2, characterized in that, The step of determining whether the vehicle is offline based on the driving data includes: The preprocessing thread performs a deep copy of the first data processing queue to obtain the second data processing queue; The preprocessing thread determines a first interval between the reception time of the driving data in the second data processing queue and the current time, and determines whether the first interval exceeds the offline threshold. If so, the preprocessing thread confirms that the vehicle is offline, generates an offline record based on the vehicle's driving data, and saves it to the database; The preprocessing thread removes the driving data of offline vehicles from the first data processing queue and the second data processing queue.

4. The method according to claim 3, characterized in that, After the preprocessing thread confirms that the vehicle is offline, the method further includes: The preprocessing thread retrieves all offline records of the offline vehicles from the database. The preprocessing thread determines the offline interval based on all offline records of the vehicle and determines whether the offline interval exceeds an abnormal threshold; the offline interval is the time interval between offline events in the offline records. If so, the preprocessing thread generates a special offline exception report and sends the special offline exception report to a preset location; If not, the preprocessing thread generates a normal offline exception report and sends the normal offline exception report to the preset location.

5. The method according to claim 3, characterized in that, The step of determining whether the vehicle has any abnormalities based on the driving data includes: The exception handling thread determines whether the fault codes in the vehicle queue match the fault code table in the database. If so, the anomaly detection and processing thread will mark the vehicle whose fault code matches the fault code table as the first abnormal vehicle, and add the driving data of the first abnormal vehicle to the driving abnormal vehicle queue. The exception handling thread determines whether a vehicle is in a prohibited area based on its position coordinates in the vehicle queue. If the vehicle is in the prohibited area, the anomaly detection and processing thread will mark the vehicle in the prohibited area as a second abnormal vehicle and add the driving data of the second abnormal vehicle to the driving abnormal vehicle queue. The anomaly detection and processing thread generates a driving vehicle fault report for all abnormal vehicles whose driving data is in the driving anomaly vehicle queue, and sends the driving vehicle fault report to a preset location.

6. The method according to claim 5, characterized in that, The method further includes: All abnormal vehicles in the abnormal driving vehicle queue and the abnormal stationary vehicle queue are marked as warning vehicles and displayed on the monitoring web page. An upload command is sent to all the abnormal vehicles so that each of the abnormal vehicles uploads the driving data to the database.

7. A device for vehicle anomaly monitoring, characterized in that, include: The receiving module is used to receive driving data uploaded by the vehicle; The first judgment module is used to determine whether the vehicle is offline based on the driving data; The second judgment module is used to determine whether the vehicle is abnormal based on the driving data when the vehicle is not offline; An anomaly marking module is used to mark the vehicle as an abnormal vehicle when the vehicle has an anomaly. The driving data includes location coordinates, current speed, driving status, and fault codes. The step of determining whether the vehicle has any abnormalities based on the driving data includes: The exception handling thread performs a deep copy of the second data processing queue to obtain a third data processing queue; wherein, the second data processing queue is a data processing queue obtained by performing a deep copy of the first data processing queue, and the first data processing queue contains the driving data; The exception handling thread divides the third data processing queue into a manual driving queue and an automatic driving queue according to the action status; the action status includes manual driving status and automatic driving status. The anomaly detection and processing thread divides the autonomous driving queue into a moving vehicle queue and a stationary vehicle queue based on the current speed. The anomaly detection and processing thread determines whether the fault codes in the stationary vehicle queue match the fault code table in the database. If the fault code in the stationary vehicle queue matches the fault code table, the anomaly judgment processing thread marks the vehicle whose fault code matches the fault code table as the third abnormal vehicle and adds the driving data of the third abnormal vehicle to the stationary abnormal vehicle queue. If the fault codes in the stationary vehicle queue do not match the fault code table, the exception judgment processing thread adds the driving data of the vehicles whose fault codes do not match the fault code table to the stationary vehicle monitoring queue. The anomaly detection and processing thread determines the area where the vehicle is located based on the position coordinates in the stationary vehicle monitoring queue, and determines the allowed parking time of the vehicle based on the area. The anomaly detection and processing thread determines a second interval between the reception time of the driving data in the stationary vehicle monitoring queue and the current time, and determines whether the second interval exceeds the allowed parking time. If the second interval exceeds the allowed parking time, the exception handling thread determines whether the action status in the stationary vehicle monitoring queue matches the parking status table in the database. If the action status in the stationary vehicle monitoring queue does not match the parking status table in the database, the vehicle is marked as the fourth abnormal vehicle, and the driving data of the fourth abnormal vehicle is added to the stationary abnormal vehicle queue. If the action status in the stationary vehicle monitoring queue matches the parking status table in the database, then determine whether the second interval exceeds the global parking limit time. If the second interval exceeds the global parking time limit, the vehicle is marked as the fifth abnormal vehicle, and the driving data of the fifth abnormal vehicle is added to the stationary abnormal vehicle queue.

8. An electronic device, characterized in that, include: A processor and a memory, the memory being used to store at least one instruction, which, when loaded and executed by the processor, implements the method for vehicle anomaly monitoring as described in any one of claims 1-6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the vehicle anomaly monitoring method as described in any one of claims 1-6.

Images