Vehicle-mounted data storage method and device

Abstract

The invention provides a vehicle-mounted data storage method and device, and is applied to the technical field of vehicle-mounted electronics. The method comprises the following steps: acquiring driving data of a vehicle in real time in the driving process of the vehicle; and determining the risk level of the risk event according to the driving data under the condition of identifying that the risk event exists in the vehicle. And according to the risk level, determining a storage medium corresponding to the risk data extracted from the driving data. Wherein the risk events of different risk levels are stored in different storage media, and the stored risk data are different. And storing the risk data to a corresponding storage medium by using a compression storage strategy matched with the risk level. Wherein the risk event degrees of different risk levels correspond to different compression storage strategies. The problems that according to a traditional vehicle-mounted data recording method, key event data is prone to being covered, complex risk events are difficult to effectively recognize, and the storage efficiency is low can be solved.

Description

Technical Field

[0001] This application relates to the field of vehicle electronic technology, and in particular to a method and apparatus for storing vehicle data. Background Technology

[0002] With rapid social development and the gradual improvement of people's living standards, vehicle usage has increased dramatically, and intelligent connected vehicles have become increasingly popular. Consequently, the demand for collecting and recording vehicle operation data has also grown significantly. Vehicle data recorders, as crucial equipment for monitoring vehicle operating status, tracing accident causes, and analyzing driving behavior, are now widely used in passenger cars, commercial vehicles, and autonomous driving test vehicles.

[0003] Traditional vehicle data recording systems generally employ a continuous full-data storage mode, causing the storage medium to fill up quickly, leading to frequent data overwriting and making critical event data highly susceptible to loss. Furthermore, these systems primarily rely on simple static threshold triggering mechanisms, capable of identifying only extreme events such as obvious collisions, and struggling to effectively capture potential risky behaviors such as sudden braking, frequent lane changes, and driver distraction, thus limiting their level of intelligence. To alleviate storage pressure, some solutions have had to reduce sampling accuracy or introduce expensive hardware acceleration units, but this either sacrifices data value or increases system costs.

[0004] Therefore, how to achieve intelligent filtering, efficient storage, and reliable preservation of data under limited vehicle resources has become a technical challenge that urgently needs to be solved in this field. Summary of the Invention

[0005] The purpose of this application is to provide a method and apparatus for storing vehicle data, which solves the problems of key event data being easily overwritten, difficulty in effectively identifying complex risk events, and low storage efficiency in traditional vehicle data recording methods.

[0006] Firstly, embodiments of this application provide a method for storing vehicle-mounted data. This method includes collecting vehicle driving data in real time during vehicle operation. When a risk event is detected, the risk level of the risk event is determined based on the driving data. Based on the risk level, the storage medium corresponding to the risk data extracted from the driving data is determined. Risk events of different risk levels are stored in different storage media, and the stored risk data is different. The risk data is stored in the corresponding storage medium using a compression storage strategy matched to the risk level. Different risk levels of risk events correspond to different compression storage strategies.

[0007] The vehicle data storage method provided in this application collects vehicle driving data in real time during vehicle operation. After identifying a risk event, it dynamically determines the risk level based on the driving data. Then, based on the risk level, different storage media are allocated to different levels of risk data. This process allows high-speed and high-reliability storage media to prioritize storing high-value risk data, while low-value or normal data occupies less costly storage space. This optimizes the storage architecture at the physical level, significantly extends the effective retention period of critical data, and avoids the loss of critical event data due to cyclic overwriting. Furthermore, a differentiated processing method is used, employing a compression storage strategy matched to the risk level. High-level data is compressed with high fidelity or lossless compression to retain its analytical value, while low-level data is compressed with a high compression ratio algorithm to save space. This maximizes storage efficiency while ensuring the availability and integrity of core data.

[0008] One possible implementation involves determining the risk level of a risk event based on driving data, including: determining whether the risk event meets a first judgment condition based on the driving data; if the risk event meets the first judgment condition, generating a Level 1 event marker and determining the risk level of the risk event as Level 1; in response to the Level 1 event marker, extracting video data of the vehicle within a preset time period after the Level 1 risk event is triggered; based on the video data, determining whether the Level 1 risk event meets a second judgment condition; if the Level 1 risk event meets the second judgment condition, updating the risk level of the Level 1 risk event to Level 2.

[0009] One possible implementation involves determining whether a risk event meets a first criterion based on driving data. This includes: determining a dynamic sampling window for acceleration data in the driving data based on the current vehicle speed; determining the standard deviation of the acceleration data; and determining that the standard deviation is greater than an emergency braking threshold, and the lateral acceleration data in the driving data is less than the lateral acceleration threshold. If the standard deviation is greater than the emergency braking threshold and the lateral acceleration data is less than the lateral acceleration threshold, then the risk event meets the first criterion for an emergency braking event, and the risk event is identified as an emergency braking event.

[0010] One possible implementation involves determining whether a risk event meets a first criterion based on driving data. This includes: if the vehicle's steering wheel angle exceeds a preset angle in the driving data and does not meet normal steering conditions, then the risk event is determined to meet the first criterion for an abnormal steering event, and the risk event is thus identified as an abnormal steering event. Normal steering conditions include: the current vehicle speed being lower than a preset vehicle speed and the yaw rate in the driving data being lower than a yaw rate threshold.

[0011] One possible implementation involves determining whether a Level 1 risk event meets the second criterion based on video data. This includes: extracting shared feature information between each frame of the video data; superimposing the shared feature information in chronological order to obtain a temporal feature tensor; determining the motion change characteristics of the video target between each frame based on the temporal feature tensor; and determining whether the Level 1 risk event meets the second criterion based on the motion change characteristics.

[0012] One possible implementation involves determining whether a Level 1 risk event meets the second criterion based on motion change characteristics. This includes: determining the lane line parameters of the current video frame based on motion change characteristics; performing smoothness constraint calculations on the lane line parameters of multiple video frames within a preset time period to determine the lane line curvature; and determining that the lane line curvature consistency is below a preset stability threshold if the Level 1 risk event meets the second criterion for a lane departure event, thus classifying the event as a Level 2 risk event.

[0013] One possible implementation involves determining whether a Level 1 risk event meets the second criterion based on motion change characteristics. This includes: detecting the relative distance between the vehicle and the video target in multiple consecutive video frames based on motion change characteristics; calculating the rate of change of the relative distance between consecutive video frames; and determining that the rate of change continuously decreases within a preset number of consecutive video frames, and the cumulative decrease exceeds a preset percentage threshold, thus confirming that the Level 1 risk event meets the second criterion corresponding to a vehicle approaching event, and the Level 2 risk event is a vehicle approaching event.

[0014] One possible implementation involves determining whether a Level 1 risk event meets the second criterion based on motion change characteristics. This includes: identifying the driver's head posture and eye state characteristics based on motion change characteristics; classifying the driver's driving state based on the head posture and eye state characteristics; determining that the driving state is classified as distracted driving if the classification result is distracted driving; and classifying the Level 1 risk event as a distracted driving event. And / or, determining that the classification result is fatigued driving if the classification result is fatigued driving; and classifying the Level 1 risk event as a fatigued driving event.

[0015] One possible implementation involves storing risk data to a corresponding storage medium using a compression storage strategy matched to the risk level. This includes: when the risk level is unrated, using a compression storage strategy of differential encoding and Huffman compression to compress and store the raw sensor data from the driving data within a preset time window, with a data retention period of a first duration. And / or, when the risk level is level two, using a compression storage strategy of differential encoding and Huffman compression to compress and store the raw sensor data and video clip data from the driving data within a preset time window, with a data retention period of a second duration. And / or, when the risk level is level three, using a compression storage strategy of differential encoding and Huffman compression to compress and store the raw sensor data from the driving data within a preset time window, and applying a first compression strategy to key frames in the video data and a second compression strategy to non-key frames in the video data, with a data retention period of a third duration. The first compression strategy is a lossless compression strategy.

[0016] Secondly, embodiments of this application provide a vehicle data storage device, which includes: a data acquisition module, a determination module, and a storage module.

[0017] The data acquisition module is used to collect vehicle driving data in real time during vehicle operation.

[0018] The determination module is used to determine the risk level of a risk event based on driving data when a risk event is detected in a vehicle.

[0019] The determination module is also used to determine the storage medium corresponding to the risk data extracted from the driving data based on the risk level. Specifically, risk events of different risk levels are stored on different storage media, and the stored risk data is different.

[0020] The storage module is used to store risky data to corresponding storage media using a compression storage strategy that matches the risk level. Different compression storage strategies correspond to different risk levels of risk events.

[0021] One possible implementation involves the module determining the risk level of a risk event based on driving data, specifically by: determining whether the risk event meets a first judgment condition based on the driving data; if the risk event meets the first judgment condition, generating a Level 1 event marker and determining the risk level of the risk event as Level 1; responding to the Level 1 event marker, extracting video data of the vehicle within a preset time period after the Level 1 risk event is triggered; based on the video data, determining whether the Level 1 risk event meets a second judgment condition; if the Level 1 risk event meets the second judgment condition, updating the risk level of the Level 1 risk event to Level 2.

[0022] One possible implementation involves the module determining whether a risk event meets the first determination condition based on driving data. Specifically, this involves: determining a dynamic sampling window for acceleration data in the driving data based on the current vehicle speed; determining the standard deviation of the acceleration data; and determining that the standard deviation is greater than an emergency braking threshold, and the lateral acceleration data in the driving data is less than the lateral acceleration threshold. If the standard deviation is greater than the emergency braking threshold and the lateral acceleration data in the driving data is less than the lateral acceleration threshold, then the risk event meets the first determination condition corresponding to an emergency braking event, and the risk event is determined to be an emergency braking event.

[0023] One possible implementation is that, when determining whether a risk event meets the first determination condition based on driving data, the module specifically determines that the risk event meets the first determination condition corresponding to an abnormal steering event if it detects that the steering wheel angle of the vehicle in the driving data exceeds a preset angle and does not meet the normal steering conditions. The normal steering conditions include: the current vehicle speed is lower than a preset vehicle speed and the yaw rate in the driving data is lower than a yaw rate threshold.

[0024] One possible implementation involves the module determining whether a Level 1 risk event meets the second criterion based on video data. Specifically, this involves: extracting shared feature information between each frame of the video data; superimposing the shared feature information in chronological order to obtain a temporal feature tensor; determining the motion change characteristics of the video target between each frame based on the temporal feature tensor; and determining whether the Level 1 risk event meets the second criterion based on the motion change characteristics.

[0025] One possible implementation involves the module determining whether a Level 1 risk event meets the second criterion based on motion change characteristics. Specifically, this involves: determining the lane line parameters of the current video frame based on motion change characteristics; performing smoothness constraint calculations on the lane line parameters of multiple video frames within a preset time period to determine the lane line curvature; and determining that the lane line curvature consistency is below a preset stability threshold if the Level 1 risk event meets the second criterion for a lane departure event, thus classifying the Level 2 risk event as a lane departure event.

[0026] One possible implementation involves the module determining whether a Level 1 risk event meets the second criterion based on motion change characteristics. Specifically, this involves: detecting the relative distance between the vehicle and the video target in multiple consecutive video frames based on motion change characteristics; calculating the rate of change of the relative distance between consecutive video frames; and determining that the rate of change continuously decreases within a preset number of consecutive video frames, and the cumulative decrease exceeds a preset percentage threshold, thus confirming that the Level 1 risk event meets the second criterion corresponding to the preceding vehicle approach event, and the Level 2 risk event is a preceding vehicle approach event.

[0027] One possible implementation involves the determining module, when used to determine whether a Level 1 risk event meets the second judgment condition based on motion change characteristics, specifically performing the following: Identifying the driver's head posture and eye state characteristics based on motion change characteristics; classifying the driver's driving state based on the head posture and eye state characteristics; if the classification result indicates a distracted driving state, determining that the Level 1 risk event meets the second judgment condition corresponding to a distracted driving event, and the Level 2 risk event is a distracted driving event; and / or, if the classification result indicates a fatigued driving state, determining that the Level 1 risk event meets the second judgment condition corresponding to a fatigued driving event, and the Level 2 risk event is a fatigued driving event.

[0028] One possible implementation involves the storage module storing risk data to the corresponding storage medium using a compression storage strategy matched to the risk level. Specifically, when the risk level is unrated, the module compresses and stores the raw sensor data from the driving data within a preset time window using a compression storage strategy of differential encoding and Huffman compression, with a data retention period of a first duration. And / or, when the risk level is level two, the module compresses and stores the raw sensor data and video clip data from the driving data within a preset time window using a compression storage strategy of differential encoding and Huffman compression, with a data retention period of a second duration. And / or, when the risk level is level three, the module compresses and stores the raw sensor data from the driving data within a preset time window using a compression storage strategy of differential encoding and Huffman compression, and applies a first compression strategy to key frames in the video data and a second compression strategy to non-key frames in the video data, with a data retention period of a third duration. The first compression strategy is a lossless compression strategy.

[0029] Thirdly, embodiments of this application provide a vehicle data storage device that has the function of implementing the vehicle data storage method of the first aspect or any possible implementation thereof. This function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above-described function.

[0030] Fourthly, embodiments of this application provide a computer-readable storage medium storing instructions that, when executed on a computer, enable the computer to perform the vehicle data storage method described in the first aspect or any possible implementation thereof.

[0031] Fifthly, embodiments of this application provide a computer program product containing instructions that, when run on a computer, enable the computer to execute the vehicle data storage method described in the first aspect or any possible implementation thereof.

[0032] The technical effects of any of the design methods in aspects two through five can be found in aspect one or in different possible implementations of aspect one, and will not be repeated here. Attached Figure Description

[0033] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0034] Figure 1 A system architecture diagram of an in-vehicle data storage system provided in an embodiment of this application; Figure 2 A flowchart illustrating a method for storing vehicle data provided in an embodiment of this application; Figure 3 A schematic diagram of a vehicle data storage device provided in an embodiment of this application; Figure 4 Another system architecture diagram of an in-vehicle data storage system provided in this application embodiment. Detailed Implementation

[0035] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0036] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0037] Existing vehicle-mounted data recording devices continuously collect high-frequency sensor data and video streams during vehicle operation, leading to rapid depletion of storage capacity and making it easy for critical event data to be overwritten by subsequent non-critical data. Simultaneously, traditional risk identification mechanisms often rely on single threshold judgments (such as sudden acceleration changes), making it difficult to effectively distinguish between risk behaviors of varying severity. This results in potentially high-risk scenarios (such as lane departure after sudden braking or approaching vehicles) failing to be accurately captured and graded. Furthermore, a uniform data storage strategy lacks differentiated management based on event importance, leading to wasted storage resources and low retrieval efficiency, particularly in edge computing environments where local computing power and storage bandwidth are limited.

[0038] Based on this, embodiments of this application provide a method and apparatus for storing vehicle data. The method includes collecting vehicle driving data in real time during vehicle operation. When a risk event is detected, the risk level of the risk event is determined based on the driving data. Based on the risk level, the storage medium corresponding to the risk data extracted from the driving data is determined. Risk events of different risk levels are stored in different storage media, and the stored risk data is different. The risk data is stored in the corresponding storage medium using a compression storage strategy matched to the risk level. Different compression storage strategies correspond to different risk levels of risk events.

[0039] The vehicle data storage method provided in this application collects vehicle driving data in real time during vehicle operation. After identifying a risk event, it dynamically determines the risk level based on the driving data. Then, based on the risk level, different storage media are allocated to different levels of risk data. This process allows high-speed and high-reliability storage media to prioritize storing high-value risk data, while low-value or normal data occupies less costly storage space. This optimizes the storage architecture at the physical level, significantly extends the effective retention period of critical data, and avoids the loss of critical event data due to cyclic overwriting. Furthermore, a differentiated processing method is used, employing a compression storage strategy matched to the risk level. High-level data is compressed with high fidelity or lossless compression to retain its analytical value, while low-level data is compressed with a high compression ratio algorithm to save space. This maximizes storage efficiency while ensuring the availability and integrity of core data.

[0040] The methods provided in the embodiments of this application will now be described in conjunction with the specific accompanying drawings.

[0041] On the one hand, embodiments of this application provide a vehicle data storage system. For example... Figure 1 As shown, the vehicle data storage system 100 may include a vehicle data recorder 101 and a communication module 102.

[0042] The vehicle data recorder 101 can be used to collect driving data and perform preliminary processing on the collected driving data. The vehicle data recorder 101 may include a sensor array, an event recognition processor, and a compressed storage manager.

[0043] Specifically, the sensor array can be used to collect real-time driving data of the vehicle during operation. For example, the sensor array may include a three-axis accelerometer, a gyroscope, a GPS module, and interfaces for connecting to communication buses such as the vehicle controller area network (CAN) bus and in-vehicle Ethernet, to acquire vehicle status information such as vehicle speed, steering wheel angle, yaw rate, and engine status. Simultaneously, the sensor array may also include a camera module to acquire video data from the front of the vehicle and video data from inside the vehicle, including the driver.

[0044] An event recognition processor can be used to identify risk events and determine the risk level corresponding to each event. For example, it can monitor driving data collected by a sensor array based on preset thresholds (such as emergency braking thresholds or abnormal steering judgment logic). Once a condition is met, a Level 1 event marker is generated. Then, upon receiving a Level 1 event marker, the processor activates, receives video data collected by the sensor array, and runs a lightweight video analysis model. If the Level 1 risk event meets the second judgment adjustment corresponding to a Level 2 risk event, the processor classifies the Level 2 risk event.

[0045] The compressed storage manager can allocate risk data corresponding to risk events of different risk levels to different storage media based on the classification results of the event recognition processor, and adopt different compression storage strategies for risk events of different risk levels.

[0046] It should be noted that the above Figure 1 The illustrated vehicle data storage system 100 is merely an example illustrating the application scenario of this application and is not intended to limit the application scenario of this application. With the evolution of automotive electronic and electrical architecture, the functions of the vehicle data recorder 101 can be fully integrated into the vehicle terminal. In this case, the vehicle terminal will possess all the functions of the aforementioned vehicle data recorder 101. The system architecture of this invention fully supports this integrated deployment, where the vehicle data recorder 101 is a functional module or software process within the vehicle terminal.

[0047] On the one hand, embodiments of this application provide a method for storing vehicle-mounted data, which can be provided by... Figure 1 The vehicle data storage system 100 shown is executed. For example... Figure 2 As shown, the method may include the following steps.

[0048] S201 collects vehicle driving data in real time during vehicle operation.

[0049] The driving data may include, but is not limited to, three-axis acceleration (ax, ay, az), angular velocity (gyroscope output), steering wheel angle, vehicle speed (obtained from GPS or CAN bus), yaw rate, brake pedal status, throttle opening, turn signal, camera video stream (dual streams for forward road and driver monitoring), and millimeter-wave radar target distance and relative speed.

[0050] One possible implementation involves an inertial measurement unit (IMU) acquiring raw acceleration and angular velocity data at a frequency of 100 Hz, with a time resolution of 10 ms. The vehicle control area network (CAN) polls key status parameters at 50 Hz. Front, rear, and interior cameras record H.264 encoded video streams at 10 fps, preserving timestamp alignment capabilities.

[0051] After collecting vehicle driving data, all driving data is timestamped according to a unified time base to ensure the temporal consistency of cross-modal data and support subsequent multi-dimensional joint analysis.

[0052] Furthermore, under specific operating conditions, the sampling rate of some sensors can be dynamically adjusted based on environmental perception results. For example, during highway cruising, the sampling frequency of the in-cabin camera can be appropriately reduced to 5fps, and automatically restored to 10fps when increased traffic density or deteriorating weather is detected ahead, thereby reducing energy consumption while ensuring the quality of driving data.

[0053] S202, when a risk event is identified in a vehicle, determines the risk level of the risk event based on driving data.

[0054] Risk events refer to behavioral segments that deviate from normal driving behavior patterns, may cause safety accidents, or require subsequent investigation, such as emergency braking, abnormal steering, and collision impacts.

[0055] Specifically, the system first performs online analysis of real-time driving data based on preset Level 1 judgment criteria to identify any initial signs of risk. When any of the triggering conditions is met, the risk assessment process is initiated. The initial judgment focuses on the trend of changes in quickly calculable physical quantities, such as longitudinal acceleration standard deviation exceeding the emergency braking threshold, lateral acceleration falling below the sideslip warning threshold, and steering wheel angle exceeding limits and not conforming to normal low-speed steering logic. Once any condition is met, a Level-1 Event Flag is generated, and the current event is tentatively classified as a Level 1 risk.

[0056] The processing logic at this stage is designed with lightweight features, making it suitable for automotive embedded platforms with limited computing power, and the response latency is controlled within 100ms. The judgment rules can be dynamically optimized through a cloud-based remote update mechanism. For example, the standard deviation threshold range for emergency braking can be adjusted according to the traffic characteristics of different regions (e.g., set to >2.5 m / s² for urban roads and >3.2 m / s² for highways), enhancing the system's adaptability.

[0057] Furthermore, after a Level 1 event is triggered, a Level 2 verification phase begins, invoking a higher-order perception model to conduct in-depth analysis of the event context. This process involves video semantic understanding, motion trajectory modeling, and driver state recognition to comprehensively determine whether a higher-level risk behavior has been identified. If the second judgment condition is confirmed to be met (such as a sudden change in lane curvature, a continuously decreasing distance to the vehicle in front, or the driver exhibiting signs of distraction / fatigue), the risk level is upgraded from Level 1 to Level 2.

[0058] Specifically, determining whether a risk event meets the first criterion based on driving data can include: Based on the driving data, determining whether the risk event meets the first criterion. If the risk event meets the first criterion, generating a Level 1 event marker and determining the risk level of the risk event as Level 1. In response to the Level 1 event marker, extracting video data of the vehicle within a preset time period after the Level 1 risk event is triggered. Based on the video data, determining whether the Level 1 risk event meets the second criterion. If the Level 1 risk event meets the second criterion, updating the risk level of the Level 1 risk event to Level 2.

[0059] The first judgment condition is a lightweight set of rules used to initially identify potential high-risk driving behaviors. Its design principle is to achieve real-time triggering with low latency (end-to-end response ≤ 50ms) and low false alarm rate (target false alarm rate < 8%) under the constraint of limited computing power at the edge. This first judgment condition does not rely on video analysis, but only makes logical judgments based on structured sensor data, which can avoid the computational resource occupation caused by continuously calling the visual model.

[0060] The second judgment condition can be a video verification rule based on video semantic understanding, with a judgment threshold higher than the first judgment condition, aiming to exclude false triggers caused by sensor noise, instantaneous jitter, or non-safety-related actions.

[0061] It should be noted that once the risk level of a risk event is upgraded from Level 1 to Level 2, its risk level is locked and write-protected, prohibiting any overwriting, deletion, or modification operations; that is, it will not be downgraded to Level 1.

[0062] One possible implementation involves determining whether a risk event meets a first criterion based on driving data. This includes: determining a dynamic sampling window for acceleration data in the driving data based on the current vehicle speed; determining the standard deviation of the acceleration data; and determining that the standard deviation is greater than an emergency braking threshold, and the lateral acceleration data in the driving data is less than the lateral acceleration threshold. If the standard deviation is greater than the emergency braking threshold and the lateral acceleration data is less than the lateral acceleration threshold, then the risk event meets the first criterion for an emergency braking event, and the risk event is identified as an emergency braking event.

[0063] For example, the vehicle data recorder continuously collects raw data from the vehicle's three-axis accelerometer at a fixed sampling frequency of 100 Hz. This raw data contains time-series signals of three axial components: a_x(t): longitudinal acceleration (positive in the vehicle's forward direction), a_y(t): lateral acceleration (positive in the left direction of the vehicle), and a_z(t): vertical acceleration (positive in the upward direction of the vehicle). Simultaneously, the current vehicle speed information v(t) is acquired in real time via the vehicle's CAN bus.

[0064] Furthermore, the vehicle data and recorder do not use a fixed-length analysis window at this time. Instead, the window size is dynamically adjusted according to the current driving speed to adapt to the time-varying characteristics of the vehicle's dynamic response at different speeds. Specifically, the length of the dynamic sampling window, window_size, can be calculated using the following formula: window_size = vehicle speed (km / h) / 10. For example, when the vehicle speed is 60 (km / h), the dynamic sampling window window_size is 60 / 10 = 6, corresponding to a 60ms time window.

[0065] Using the current moment as a reference, take the longitudinal acceleration data sequence within the most recent dynamic window and calculate the acceleration standard deviation accel_std of the data within that window, as shown in the following formula:

[0066] Where N is the dynamic window size, N = window_size. I represents the number of sampling points, and μ is the mean longitudinal acceleration within the window. This represents the longitudinal acceleration value of the i-th sampling point within the window.

[0067] Finally, the calculated acceleration standard deviation (accel_std) is compared with the preset emergency braking threshold, and a comprehensive judgment is made in conjunction with the lateral acceleration. If the standard deviation is greater than the emergency braking threshold, and the lateral acceleration data in the driving data is less than the lateral acceleration threshold, then it is determined that the vehicle has experienced an emergency braking event, and a corresponding first-level event flag is generated.

[0068] For example, accel_std>0.3 * 9.8 means the standard deviation of acceleration is greater than 2.94 m / s², indicating a drastic change in deceleration, and lateral acceleration<-0.5 * 9.8 means the mean lateral acceleration is less than -4.9 m / s², which is a typical characteristic of a sudden braking dive.

[0069] It should be noted that the above thresholds can be calibrated according to different vehicle models, loads, and sensor characteristics. For example, the following calibration reference range can be established based on a large number of real vehicle tests: under normal braking / acceleration conditions, accel_std is usually between 0.5 and 1.5 m / s²; under emergency lane change / obstacle avoidance conditions, accel_std can be between 1.5 and 3.0 m / s²; and under collision or extreme braking events, accel_std is generally greater than 3.0 m / s².

[0070] Another possible implementation involves determining whether a risk event meets a first determination condition based on driving data. This includes: if the vehicle's steering wheel angle exceeds a preset angle in the driving data and does not meet normal steering conditions, then the risk event is determined to meet the first determination condition corresponding to an abnormal steering event, and the risk event is identified as an abnormal steering event. Normal steering conditions include: the current vehicle speed is lower than a preset vehicle speed and the yaw rate in the driving data is lower than a yaw rate threshold.

[0071] For example, by continuously monitoring steering wheel angle, vehicle speed and yaw rate data, when the absolute value of the steering wheel angle is detected to continuously exceed a set angle (e.g., 45 degrees), an abnormal steering monitoring timer is started to first determine whether the vehicle currently meets the normal steering conditions.

[0072] When a vehicle meets the normal steering conditions, that is, when the absolute value of the steering wheel angle is greater than 45 degrees, the vehicle speed is less than 10 km / h, and the absolute value of the yaw rate is less than 5° / s, it can be determined that the vehicle meets the normal steering conditions. At this time, the vehicle may be in a parking lot or making a low-speed U-turn. Such conditions are added to the whitelist to avoid generating invalid alarms or storing redundant events.

[0073] When a vehicle does not meet normal steering conditions, i.e., its speed exceeds 10 km / h or its yaw rate exceeds 5° / s, it can be determined that the vehicle is currently in an abnormal steering state. For example, a vehicle may experience a sharp turn while traveling at medium to high speeds, or a vehicle may experience severe yaw while traveling at medium to high speeds. In this case, a continuous monitoring timer will keep running. When the continuous duration of the detected abnormal steering state exceeds a threshold (e.g., 2 seconds), an abnormal steering event is determined to have occurred.

[0074] Furthermore, based on the video data, determining whether a Level 1 risk event meets the second criterion includes: extracting shared feature information between each frame of the video data; superimposing the shared feature information in chronological order to obtain a temporal feature tensor; determining the motion change characteristics of the video target between each frame of the video data based on the temporal feature tensor; and determining whether the Level 1 risk event meets the second criterion based on the motion change characteristics.

[0075] Specifically, once a Level 1 risk event is identified and triggered, a sequence of consecutive video frames within a preset time period before and after the event occurs is extracted. For example, sampling is performed at 10fps, with each 2-second interval (20 frames) serving as a time window (T=20), a sliding step of 1 second (10 frames), and each frame is scaled to a resolution of 224×224, with pixel values ​​normalized to the range [0,1]. These video frames are uniformly scaled to the preset resolution and their pixel values ​​are normalized, forming regular input data. Subsequently, a pre-trained convolutional neural network is used to process each frame, extracting a shared feature map that can represent the semantic content of the image. This feature map retains key spatial structural information.

[0076] The feature maps from multiple consecutive frames arranged in chronological order are then stacked along the temporal dimension to construct a temporal feature tensor. This tensor not only contains the static features of each frame but also implicitly encodes the continuous changes of targets in the scene over time through its arrangement along the time axis. To explicitly capture and enhance this temporal dynamic information, a 3D convolution operation is used to process this temporal feature tensor. The 3D convolution kernel slides along both spatial and temporal dimensions, effectively modeling the correlation and evolution of features between adjacent frames, thereby extracting the motion change features of moving targets (such as vehicles, lane lines, and drivers) in the video across consecutive frames. Finally, based on the extracted motion change features, it is determined whether a Level 1 risk event meets the second criterion.

[0077] One possible implementation involves determining whether a Level 1 risk event meets the second criterion based on motion change characteristics. This includes: determining the lane line parameters of the current video frame based on motion change characteristics; performing smoothness constraint calculations on the lane line parameters of multiple video frames within a preset time period to determine the lane line curvature; and determining that the lane line curvature consistency is below a preset stability threshold if the Level 1 risk event meets the second criterion for a lane departure event, thus classifying the event as a Level 2 risk event.

[0078] Specifically, after performing temporal analysis on the video data and obtaining the fused motion change features, information related to lane lines is extracted from these motion change features. Then, based on these motion change features, lane line parameters are predicted for the current video frame, and regression prediction of lane line parameters is performed for each video frame, outputting key geometric parameters such as lane line curvature and lateral offset.

[0079] Furthermore, to assess the stability of driving behavior, temporal consistency analysis is performed on the lane line parameters predicted across multiple consecutive frames. A consistency index is calculated to determine the smoothness of the vehicle's trajectory by assessing the changes in lane line curvature within a preset time window. This consistency index measures the stability of lane line prediction results over time, and its calculation process is optimized during model training by introducing smoothness constraints, enabling the network to learn and output temporally coherent predictions.

[0080] When analysis shows that the lane curvature undergoes a significant and unstable abrupt change within a short period of time, and the calculated consistency index is lower than the stability threshold calibrated according to the safe driving model, it can be determined that the Level 1 risk event poses a lane departure risk. At this point, it can be confirmed that the event meets the second criterion for lane departure, the event level is updated to Level 2, and the Level 2 risk event is marked as a lane departure event.

[0081] Another possible implementation involves determining whether a Level 1 risk event meets the second criterion based on motion change characteristics. This includes: detecting the relative distance between the vehicle and the video target in multiple consecutive video frames based on motion change characteristics; calculating the rate of change of the relative distance between consecutive video frames; and determining that the rate of change continuously decreases within a preset number of consecutive video frames, and the cumulative decrease exceeds a preset percentage threshold, thus confirming that the Level 1 risk event meets the second criterion corresponding to a vehicle approaching event, and the Level 2 risk event is a vehicle approaching event.

[0082] Specifically, based on motion change characteristics, multiple frames of video data are used to detect and identify vehicles or obstacles ahead as video targets, and the relative distance between the vehicle and the target is calculated frame by frame. This distance information constitutes a time-series data in a continuous sequence of video frames.

[0083] Based on this relative distance sequence, the rate of change of distance between adjacent frames is calculated. This rate of change directly reflects the instantaneous speed at which the target approaches the vehicle. The sign and magnitude of this rate of change are tracked within a series of frames. For example, if the rate of change of distance is detected to be negative for five consecutive frames, it indicates that the relative distance is continuously decreasing.

[0084] To confirm the approach risk, it is further determined whether the cumulative decrease in relative distance within a preset number of consecutive frames exceeds a set percentage threshold (e.g., 15% of the total distance). If the distance not only continues to decrease but also the cumulative decrease is significant, then a clear risk of a vehicle rapidly approaching from the front is identified. At this point, it can be confirmed that the initial Level 1 risk event meets the second criterion for approaching from the front, and the event is updated to a Level 2 risk event and classified as an approaching vehicle event.

[0085] Another possible implementation involves determining whether a Level 1 risk event meets the second criterion based on motion change characteristics. This includes: identifying the driver's head posture and eye state characteristics based on motion change characteristics; classifying the driver's driving state based on these characteristics; determining that the driving state is classified as distracted driving if the classification result is distracted driving; and classifying the driving state as fatigued driving if the classification result is fatigued driving.

[0086] Specifically, based on motion change characteristics, visual information directly related to the driver is extracted, such as the driver's head posture angles in three-dimensional space, eye opening and closing states, and gaze direction. The driver's head posture features are obtained by estimating the angles in pitch, yaw, and roll directions. The technician's eye state features are obtained by calculating parameters such as eye aspect ratio. The extracted head posture and eye state features are then fused and classified. The classification results can include normal driving, distracted driving, and fatigued driving states. Classification decisions can be based on patterns of features within a short time window, such as persistent gaze deviation from the road, abnormal head rotation frequency or amplitude, and the duration and frequency of eyelid closure.

[0087] When the classification results indicate that the driver is in a distracted state, such as when their gaze is off the road ahead for a long time or frequently, the initial Level 1 risk event is determined to meet the second determination condition associated with distracted driving, and the event is finally classified as a distracted driving event, and its risk level is upgraded to Level 2.

[0088] Similarly, if the classification results show that the driver exhibits fatigue characteristics, such as frequent drowsiness or prolonged eye closure, the system determines that the second judgment condition corresponding to driver fatigue driving is met, updates the event to a driver fatigue driving event, and marks it as a level two risk.

[0089] S203, based on the risk level, determine the storage medium corresponding to the risk data extracted from the driving data.

[0090] Risk events of different risk levels are stored in different storage media, and the risk data stored is different.

[0091] The storage media consists of multiple independent or logically isolated storage areas configured locally on-board for tiered data management. Different risk levels correspond to different types and characteristics of storage space, ensuring that high-priority data has higher persistence guarantees and access permissions.

[0092] Once the risk level of a risk event is finalized, corresponding physical or logical storage media are assigned to event data of different levels according to pre-defined hierarchical storage mapping rules. These mapping rules clearly define the storage area to be used for each risk level, the scope of the stored data, and the data retention strategy.

[0093] Specifically, when the risk level is determined to be Level 1, the associated risk data—typically including raw sensor data (such as acceleration, angular velocity, CAN signals) within a preset time period before and after the event trigger point, as well as low-resolution or pre-edited video clips—will be routed to media designated as the first storage tier in the system. This tier typically employs storage units with high durability and cost-effectiveness, such as specific partitions in an eMMC chip or medium-speed flash memory blocks.

[0094] For risk events classified as Level 2 or higher, their associated data is redirected to the second storage tier. This tier requires higher write speeds and data reliability, and can correspond to higher-performance solid-state storage areas or dedicated cache areas in automotive storage systems. The risk data stored at this level is also more complete, typically including all raw sensor data within the event window as well as uncompressed or high-resolution complete video streams.

[0095] Furthermore, the content of risk data stored at different risk levels also differs. For example, low-risk events may only store metadata summaries of key sensors or highly aggregated statistical features, while high-risk events store raw, high-sampling-rate time-series data and video frames. This mechanism, which binds risk level, storage medium, and data content together, achieves persistent protection of high-value risk data and intelligent cleanup of low-value data within a limited total storage space, optimizing the overall utilization efficiency of storage resources and the value of data retention.

[0096] For example, the storage area can be divided into three storage tiers.

[0097] The first-level storage area corresponds to events of the no-risk level and can be oriented towards no-risk or normal operating states. It is usually a circular overlay flash partition (such as a FIFO queue in eMMC or SSD) that only stores low-frequency metadata (such as a key sensor summary at 1 Hz per second).

[0098] The secondary storage area corresponds to the primary risk event. It uses independent solid-state storage units or encrypted partitions to retain the original sensor data (50Hz sampling) and video clips within a few seconds before and after the event.

[0099] Level 3 storage corresponds to Level 2 and above risk events. It can use dedicated secure storage chips that are tamper-proof and power-loss resistant to permanently store full-resolution video, complete raw sensor data, and event context information, supporting judicial evidence collection purposes.

[0100] Access isolation between storage media can be achieved through hardware isolation or file system-level access control to prevent low-level data write intrusions from occupying high-level area space. At the same time, a dynamic mapping table is maintained to record each risk level and its corresponding target storage path, retention policy, and encryption method, which facilitates flexible expansion and addition of new event types.

[0101] S204 uses a compression storage strategy that matches the risk level to store risky data to the corresponding storage medium.

[0102] Different risk levels correspond to different compression storage strategies.

[0103] One possible implementation is to use a compression storage strategy of differential coding and Huffman compression to compress and store the original sensor data in the driving data within a preset time window when the risk level is unrated, with the data retention time being the first duration.

[0104] For example, when the risk level is unrated, a difference encoding + Huffman compression strategy can be used to process sensor data. For instance, the difference [0, +0.02, -0.03, +0.35] can be stored for a continuous acceleration sequence [9.81, 9.83, 9.80, 10.15, ...].

[0105] Another possible implementation, when the risk level is level two, is to use a compression storage strategy of differential coding and Huffman compression to compress and store the original sensor data and video clip data in the driving data within a preset time window, and the data retention time is the second duration.

[0106] For example, when the risk level is Level 1, a differential coding + Huffman compression strategy is used to process sensor data. Meanwhile, for Level 1 events containing video clips, lossy compression (such as H.264 Baseline Profile) is used for I-frames in the video stream, and the bitrate of P / B frames is adaptively allocated according to motion intensity, significantly reducing the bitrate in static background areas while maintaining clarity in moving foregrounds.

[0107] Another possible implementation, when the risk level is three, employs a compression storage strategy combining differential coding and Huffman compression to compress and store the raw sensor data within a preset time window of the driving data. A first compression strategy is used for key frames in the video data, and a second compression strategy is used for non-key frames. The data retention period is a third duration. The first compression strategy is a lossless compression strategy.

[0108] For example, when the risk level is level two, more refined processing is applied to the video data while retaining the aforementioned sensor compression. Specifically, lossless compression (such as PNG or FLIF format) is performed on keyframes (e.g., the moment an event is triggered) to ensure that image details are fully visible. For non-keyframes, efficient perceptual encoding is still used, balancing file size and image quality.

[0109] It should be noted that all compression operations are completed at the edge, packaging the data into standardized data blocks (such as Protocol Buffer format encapsulation), and including metadata such as event tags, time windows, and compression method identifiers, to facilitate later parsing and retrieval.

[0110] Furthermore, after storing the risk data to the corresponding storage medium using a compression storage strategy matched to the risk level, this application can also send the risk data to the cloud. At this point, the vehicle-mounted device, acting as an edge node, continuously performs local event detection, data classification, and pre-compression. When a Level 1 or Level 2 risk event is identified, the associated key data packets (including sensor data and video data) are uploaded to the cloud server via a secure encrypted communication link.

[0111] After receiving uploaded data from a large number of vehicles, the cloud server aggregates, analyzes, and deeply mines this long-term, multi-dimensional driving data. Through machine learning and statistical analysis, the cloud can identify new risk patterns, verify the effectiveness of existing judgment thresholds, or discover better rules for specific vehicle models, regions, or driving scenarios. For example, by analyzing massive amounts of emergency braking event data, the cloud may calculate more accurate acceleration thresholds under different road surface adhesion conditions or vehicle loads.

[0112] The new rules, model parameters, or threshold configurations generated after analysis and optimization are packaged into update packages and sent to each vehicle terminal via a secure channel. Upon receiving the update package, the vehicle terminal uses techniques such as memory mapping to directly load the new rule parameters into the running event detection engine. This process does not require restarting the entire vehicle data recording system or interrupting ongoing data acquisition and recording, achieving hot rule updates and ensuring that the system can apply the latest recognition logic within milliseconds.

[0113] This dynamic, data-driven iterative closed loop enables the entire system to continuously learn and adapt to the ever-changing real-world driving environment, constantly improving the accuracy and efficiency of event recognition. At the same time, by uploading critical data only when necessary, it greatly optimizes the use of network bandwidth.

[0114] The foregoing mainly describes the solutions provided in the embodiments of this application from the perspective of the working principle of the device. It is understood that, in order to achieve the above functions, the vehicle data storage device includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, in conjunction with the algorithm steps of the various examples described in the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0115] This application embodiment can divide the vehicle data storage device into functional modules according to the above method example. For example, each function can be divided into a separate functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module.

[0116] It should be noted that the module division in this embodiment is illustrative and represents only one logical functional division; in actual implementation, other division methods may be used. When dividing functional modules according to their respective functions, Figure 3 A schematic diagram illustrating a possible configuration of the vehicle data storage device involved in the above and embodiment examples is shown. Figure 3 As shown, the vehicle data storage device 300 may include: a data acquisition module 301, a determination module 302, and a storage module 303.

[0117] The acquisition module 301 is used to support the execution of the vehicle data storage device 300. Figure 2 S201 in the illustrated method for storing vehicle data.

[0118] Determine module 302, used to support the execution of vehicle data storage device 300 Figure 2 S202 and S303 in the illustrated vehicle data storage method.

[0119] Storage module 303 is used to support the execution of the vehicle data storage device 300. Figure 2 S204 in the illustrated method for storing vehicle data.

[0120] One possible implementation involves the module determining the risk level of a risk event based on driving data, specifically by: determining whether the risk event meets a first judgment condition based on the driving data; if the risk event meets the first judgment condition, generating a Level 1 event marker and determining the risk level of the risk event as Level 1; responding to the Level 1 event marker, extracting video data of the vehicle within a preset time period after the Level 1 risk event is triggered; based on the video data, determining whether the Level 1 risk event meets a second judgment condition; if the Level 1 risk event meets the second judgment condition, updating the risk level of the Level 1 risk event to Level 2.

[0121] One possible implementation involves the module determining whether a risk event meets the first determination condition based on driving data. Specifically, this involves: determining a dynamic sampling window for acceleration data in the driving data based on the current vehicle speed; determining the standard deviation of the acceleration data; and determining that the standard deviation is greater than an emergency braking threshold, and the lateral acceleration data in the driving data is less than the lateral acceleration threshold. If the standard deviation is greater than the emergency braking threshold and the lateral acceleration data in the driving data is less than the lateral acceleration threshold, then the risk event meets the first determination condition corresponding to an emergency braking event, and the risk event is determined to be an emergency braking event.

[0122] One possible implementation is that, when determining whether a risk event meets the first determination condition based on driving data, the module specifically determines that the risk event meets the first determination condition corresponding to an abnormal steering event if it detects that the steering wheel angle of the vehicle in the driving data exceeds a preset angle and does not meet the normal steering conditions. The normal steering conditions include: the current vehicle speed is lower than a preset vehicle speed and the yaw rate in the driving data is lower than a yaw rate threshold.

[0123] One possible implementation involves the module determining whether a Level 1 risk event meets the second criterion based on video data. Specifically, this involves: extracting shared feature information between each frame of the video data; superimposing the shared feature information in chronological order to obtain a temporal feature tensor; determining the motion change characteristics of the video target between each frame based on the temporal feature tensor; and determining whether the Level 1 risk event meets the second criterion based on the motion change characteristics.

[0124] One possible implementation involves the module determining whether a Level 1 risk event meets the second criterion based on motion change characteristics. Specifically, this involves: determining the lane line parameters of the current video frame based on motion change characteristics; performing smoothness constraint calculations on the lane line parameters of multiple video frames within a preset time period to determine the lane line curvature; and determining that the lane line curvature consistency is below a preset stability threshold if the Level 1 risk event meets the second criterion for a lane departure event, thus classifying the Level 2 risk event as a lane departure event.

[0125] One possible implementation involves the module determining whether a Level 1 risk event meets the second criterion based on motion change characteristics. Specifically, this involves: detecting the relative distance between the vehicle and the video target in multiple consecutive video frames based on motion change characteristics; calculating the rate of change of the relative distance between consecutive video frames; and determining that the rate of change continuously decreases within a preset number of consecutive video frames, and the cumulative decrease exceeds a preset percentage threshold, thus confirming that the Level 1 risk event meets the second criterion corresponding to the preceding vehicle approach event, and the Level 2 risk event is a preceding vehicle approach event.

[0126] One possible implementation involves the determining module, when used to determine whether a Level 1 risk event meets the second judgment condition based on motion change characteristics, specifically performing the following: Identifying the driver's head posture and eye state characteristics based on motion change characteristics; classifying the driver's driving state based on the head posture and eye state characteristics; if the classification result indicates a distracted driving state, determining that the Level 1 risk event meets the second judgment condition corresponding to a distracted driving event, and the Level 2 risk event is a distracted driving event; and / or, if the classification result indicates a fatigued driving state, determining that the Level 1 risk event meets the second judgment condition corresponding to a fatigued driving event, and the Level 2 risk event is a fatigued driving event.

[0127] One possible implementation involves the storage module storing risk data to the corresponding storage medium using a compression storage strategy matched to the risk level. Specifically, when the risk level is unrated, the module compresses and stores the raw sensor data from the driving data within a preset time window using a compression storage strategy of differential encoding and Huffman compression, with a data retention period of a first duration. And / or, when the risk level is level two, the module compresses and stores the raw sensor data and video clip data from the driving data within a preset time window using a compression storage strategy of differential encoding and Huffman compression, with a data retention period of a second duration. And / or, when the risk level is level three, the module compresses and stores the raw sensor data from the driving data within a preset time window using a compression storage strategy of differential encoding and Huffman compression, and applies a first compression strategy to key frames in the video data and a second compression strategy to non-key frames in the video data, with a data retention period of a third duration. The first compression strategy is a lossless compression strategy.

[0128] It should be noted that all relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0129] The vehicle data storage device 300 provided in this embodiment is used to perform the above-described... Figure 2 The method for storing vehicle data shown can achieve the same effect as the method for storing vehicle data described above.

[0130] This application also provides a vehicle data storage device that can execute the vehicle data storage method and related steps described in the above method embodiments.

[0131] This application also provides a computer-readable storage medium storing instructions thereon, which, when executed, perform the vehicle data storage method and related steps in the above method embodiments.

[0132] This application also provides a computer program product that, when run on a computer, causes the computer to execute the vehicle data storage method and related steps described in the above method embodiments.

[0133] In some embodiments, the methods shown in this application can be implemented as computer program instructions encoded in a machine-readable format on a computer-readable storage medium or on other non-transitory media or articles of art.

[0134] This application embodiment also provides a vehicle data storage system 100, such as Figure 4 As shown, the vehicle data storage system 100 includes at least one processor 401 and at least one interface circuit 402.

[0135] As an example, when the vehicle data storage system 100 includes a processor and an interface circuit, the processor can be... Figure 4 The processor 401 shown in the solid box (or the processor 401 shown in the dashed box) can be an interface circuit. Figure 4 The interface circuit 402 is shown in the solid box (or the dashed box). When the vehicle data storage system 100 includes two processors and two interface circuits, then the two processors include... Figure 4 The processor 401 shown in the solid box and the processor 401 shown in the dashed box, these two interface circuits include Figure 4 Interface circuit 402 is shown in both solid and dashed boxes. No limitations are imposed on this.

[0136] Processor 401 and interface circuit 402 can be interconnected via a line. For example, interface circuit 402 can be used to receive signals. Alternatively, interface circuit 402 can be used to send signals to other devices (e.g., processor 401). For instance, interface circuit 402 can read computer instructions stored in memory and send those instructions to processor 401. Processor 401 executes the instructions and, in conjunction with input / output devices, implements the various steps in the above embodiments, such as implementing... Figure 2 The methods illustrated are the steps performed in the embodiments shown. Of course, the vehicle data storage system may also include other discrete components, and this application embodiment does not specifically limit this.

[0137] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

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

[0139] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0140] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0141] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to it, or all or part of the technical solution, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0142] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for storing vehicle-mounted data, characterized in that, The method includes: During vehicle operation, the vehicle's driving data is collected in real time. If a risk event is identified in the vehicle, the risk level of the risk event is determined based on the driving data; Based on the risk level, the storage medium corresponding to the risk data extracted from the driving data is determined; wherein, risk events of different risk levels are stored in different storage media, and the stored risk data is different; The risk data is stored in the corresponding storage medium using a compression storage strategy that matches the risk level; wherein different risk levels correspond to different compression storage strategies.

2. The method according to claim 1, characterized in that, Determining the risk level of the risk event based on the driving data includes: Based on the driving data, determine whether the risk event meets the first determination condition; If the risk event is determined to meet the first determination condition, a level 1 event marker is generated, and the risk level of the risk event is determined to be level 1. In response to the Level 1 event marker, video data of the vehicle within a preset time period after the Level 1 risk event is triggered is extracted; Based on the video data, determine whether the Level 1 risk event meets the second determination condition; If the Level 1 risk event is determined to meet the second determination condition, the risk level of the Level 1 risk event is updated to Level 2.

3. The method according to claim 2, characterized in that, The step of determining whether the risk event meets the first determination condition based on the driving data includes: Based on the current vehicle speed in the driving data, determine the dynamic sampling window for the acceleration data in the driving data; Based on the acceleration data, determine the standard deviation of the acceleration data; If the standard deviation is greater than the emergency braking threshold and the lateral acceleration data in the driving data is less than the lateral acceleration threshold, the risk event is determined to meet the first determination condition corresponding to the emergency braking event, and the risk event is the emergency braking event.

4. The method according to claim 2, characterized in that, The step of determining whether the risk event meets the first determination condition based on the driving data includes: If the steering wheel angle of the vehicle in the driving data exceeds a preset angle and does not meet the normal steering conditions, the risk event is determined to meet the first determination condition corresponding to the abnormal steering event, and the risk event is the abnormal steering event; the normal steering conditions include: the current vehicle speed is lower than the preset vehicle speed and the yaw rate in the driving data is lower than the yaw rate threshold.

5. The method according to claim 2, characterized in that, The step of determining whether the Level 1 risk event meets the second judgment condition based on the video data includes: Based on the video data, the shared feature information between each video frame is extracted; The shared feature information is superimposed in chronological order to obtain a temporal feature tensor; Based on the temporal feature tensor, determine the motion change characteristics of the video target in the video data between each video frame; Based on the motion change characteristics, determine whether the Level 1 risk event meets the second determination condition.

6. The method according to claim 5, characterized in that, The step of determining whether the first-level risk event meets the second determination condition based on the motion change characteristics includes: Based on the motion change characteristics, determine the lane line parameters of the current video frame; Smoothness constraint calculations are performed based on lane line parameters from multiple video frames within a preset time period to determine lane line curvature; If the lane line curvature consistency is determined to be lower than a preset stability threshold, the first-level risk event is determined to meet the second judgment condition corresponding to the lane departure event, and the second-level risk event is a lane departure event.

7. The method according to claim 5, characterized in that, The step of determining whether the first-level risk event meets the second determination condition based on the motion change characteristics includes: Based on the motion change characteristics, the relative distance between the vehicle and the video target is detected in multiple consecutive video frames; Calculate the rate of change of the relative distance between consecutive video frames; If the rate of change is determined to decrease continuously within a preset number of consecutive video frames, and the cumulative decrease exceeds a preset percentage threshold, then the first-level risk event is determined to meet the second judgment condition corresponding to the preceding vehicle approaching event, and the second-level risk event is a preceding vehicle approaching event.

8. The method according to claim 5, characterized in that, The step of determining whether the first-level risk event meets the second determination condition based on the motion change characteristics includes: Based on the motion change characteristics, the head posture characteristics and eye state characteristics of the vehicle driver are identified; Based on the head posture features and the eye state features, the driver's driving state is classified. If the classification result of the driving state is determined to be a distracted driving state, the first-level risk event is determined to meet the second judgment condition corresponding to the driver distracted driving event, and the second-level risk event is the driver distracted driving event. And / or, if the classification result is determined to be a state of fatigued driving, the first-level risk event is determined to meet the second judgment condition corresponding to the driver fatigued driving event, and the second-level risk event is the driver fatigued driving event.

9. The method according to claim 1, characterized in that, The step of storing the risky data to the corresponding storage medium using a compression storage strategy that matches the risk level includes: When the risk level is no level, the original sensor data in the driving data within the preset time window is compressed and stored using a compression storage strategy of differential encoding and Huffman compression, and the data retention time is the first time period. And / or, when the risk level is level two, the original sensor data and video clip data in the driving data within a preset time window are compressed and stored using a compression storage strategy of differential encoding and Huffman compression, and the data retention time is the second duration; And / or, when the risk level is level three, the original sensor data in the driving data within a preset time window is compressed and stored using a compression storage strategy of differential coding and Huffman compression, and a first compression strategy is used for key frames in the video data, and a second compression strategy is used for non-key frames in the video data, with a data retention duration of a third duration; the first compression strategy is a lossless compression strategy.

10. A vehicle-mounted data storage device, characterized in that, The device includes: The data acquisition module is used to collect the vehicle's driving data in real time during the vehicle's operation. The determination module is used to determine the risk level of a risk event based on the driving data when a risk event is detected in the vehicle. The determining module is further configured to determine the storage medium corresponding to the risk data extracted from the driving data based on the risk level; wherein risk events of different risk levels are stored in different storage media, and the stored risk data is different; A storage module is used to store the risk data to a corresponding storage medium using a compression storage strategy that matches the risk level; wherein different risk levels correspond to different compression storage strategies.

Images