Implementation method and system of low-power-consumption high-reliability built-in automobile data recorder

Abstract

The invention discloses an implementation method and system of a low-power-consumption and high-reliability built-in automobile data recorder, and relates to the technical field of vehicle-mounted electronics and intelligent monitoring. Automatically waking up the main control module and initializing a sensor, a lens, a memory and an accelerometer; constructing a multi-modal data stream, storing historical data of the latest T1 seconds through a cache region, and performing beforehand pre-recording; continuously analyzing the running state and the acceleration abnormal value of the vehicle, and when the multi-source data meets a set threshold value, judging as event triggering; when an event trigger signal is detected, combining the pre-recorded data in the cache region with a video T2 seconds after an event occurs, and executing a hierarchical locking strategy; and an uploading strategy is automatically selected according to the wireless network bandwidth and the event level. According to the method, the multi-modal data stream cache region is constructed, the latest vehicle video and sensing data are stored in real time, the evidence obtaining effectiveness is improved, and the event recognition precision is improved.

Description

Technical Field

[0001] This invention relates to the field of vehicle electronics and intelligent monitoring technology, and in particular to a method and system for implementing a low-power, high-reliability built-in dashcam. Background Technology

[0002] With the widespread adoption of intelligent connected vehicles and Advanced Driver Assistance Systems (ADAS), dashcams have evolved from simple video recording devices into intelligent systems with collision detection, event alerts, and cloud-based interaction capabilities. Traditional dashcams often use independent installation methods, relying on external interfaces for power supply and communication, resulting in problems such as complex wiring, low system integration, high energy consumption, and poor data security.

[0003] On the other hand, standalone dashcams typically rely on video channels to trigger recording, lacking the ability to fuse and perceive vehicle status and inertial information. This prevents them from pre-recording before abnormal vehicle conditions occur, resulting in incomplete recording of some accident events. Furthermore, traditional systems maintain continuous monitoring while the vehicle is in standby mode for extended periods, easily leading to excessive battery consumption. In unstable network environments or with limited bandwidth, video upload strategies lack intelligent scheduling, often resulting in critical events not being uploaded in a timely manner or ordinary data consuming excessive bandwidth.

[0004] While existing intelligent dashcam systems incorporate collision sensors or CAN bus information, most still rely on single-signal triggering, lacking multi-source fusion judgment and hierarchical management mechanisms, making them prone to false triggers or missed triggers. Furthermore, traditional systems often employ a uniform locking strategy for recorded data, failing to provide tiered protection based on event severity, impacting storage efficiency and compromising the security of event evidence. Additionally, existing dashcams lack bandwidth awareness and adaptive upload strategies when wireless network bandwidth fluctuates, failing to dynamically adjust uploaded content and priorities, resulting in the loss of critical video under low bandwidth conditions or underutilization of resources under high bandwidth conditions. In summary, existing technologies suffer from the following main problems: single wake-up trigger, unable to combine vehicle status signals and IMU inertial data for intelligent judgment; inability to pre-cachise and pre-record multimodal data, leading to the loss of critical pre-accident information; lack of a multi-source fusion event judgment mechanism, resulting in high false alarm and missed alarm rates; single event data locking strategy, unable to dynamically protect based on event severity; and failure to dynamically adjust the upload process according to wireless bandwidth, resulting in low network resource utilization.

[0005] Therefore, there is an urgent need for a built-in dashcam implementation method that can achieve intelligent wake-up in low-power standby mode, support multimodal pre-recording and fusion judgment, and perform adaptive uploading based on event level and network bandwidth, so as to improve the integrity of vehicle safety records, data security and system intelligence. Summary of the Invention

[0006] In view of the above-mentioned problems, the present invention is proposed.

[0007] Therefore, the problem to be solved by this invention is how to achieve intelligent wake-up by fusing vehicle status signals and IMU data, and to construct a low-power, high-reliability and intelligent built-in dashcam implementation method by combining multimodal pre-recording, event judgment, hierarchical locking and bandwidth adaptive upload strategies.

[0008] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0009] In a first aspect, embodiments of the present invention provide a method for implementing a low-power, high-reliability built-in vehicle dashcam, comprising: when an ignition signal, battery voltage fluctuation, or vibration signal is detected in the vehicle bus, automatically waking up the main control module and initializing the sensors, lens, storage, and accelerometer;

[0010] Construct a multimodal data stream and store the most recent T1 second of historical data in a buffer for pre-recording.

[0011] Continuously analyze vehicle operating status and acceleration anomalies; when multi-source data meets the set threshold, it is determined to be an event triggered.

[0012] When an event trigger signal is detected, the pre-recorded data in the buffer is merged with the video T2 seconds after the event occurs to generate a complete event segment, and a hierarchical locking strategy is executed.

[0013] The upload strategy is automatically selected based on the wireless network bandwidth and the event level.

[0014] As a preferred embodiment of the low-power, high-reliability built-in dashcam implementation method of the present invention, the method includes: automatically waking up the main control module and initializing the sensors, lens, storage, and accelerometer, including:

[0015] The wake-up condition is determined by the fusion of vehicle status signals and IMU data, and the fusion score S is calculated based on the normalized score according to a weighted fusion strategy. total And determine wake-up;

[0016] Set the first threshold T high With the second threshold T low Satisfying T high >T low When S total ≥T high When T is active, immediately perform a full wake-up; when T is active... low ≤S total <T high At that time, enter the verification window and perform verification on S during the verification window. totalPerform repeated sampling and verification; if the verification passes, execute a full wake-up; otherwise, return to a low-power state.

[0017] As a preferred embodiment of the low-power, high-reliability built-in dashcam implementation method of the present invention, the method includes: constructing a multimodal data stream, storing historical data from the most recent T1 second in a buffer, and performing pre-recording, including:

[0018] The buffer uses a circular buffer queue structure to store the data of each channel in the most recent T1 seconds in time sequence; the buffer capacity is configured and dynamically managed according to the following strategy: The cache is allocated in a fixed amount by channel or by priority, with a high proportion of buffer capacity reserved for critical channels; When the cache is full, the oldest data is overwritten in the order of earliest time, and data segments marked with event retention are prohibited from being overwritten. The cache capacity is proportional to T1, and the T1 value is dynamically adjusted according to the vehicle's operating status.

[0019] As a preferred embodiment of the low-power, high-reliability built-in dashcam implementation method of the present invention, the method includes: continuously analyzing the vehicle's operating status and abnormal acceleration values; when multi-source data meets a set threshold, an event is determined to be triggered, including:

[0020] Within the sliding time window, short-term statistics and event indicators for each modality are aggregated to form a set of event candidate information within the time window; the event candidate information is then correlated over time. The anomalies of each modality are fused according to preset weights to obtain the event confidence score at the current time point or time window.

[0021] As a preferred embodiment of the low-power, high-reliability built-in dashcam implementation method of the present invention, the method further includes: continuously analyzing the vehicle's operating status and acceleration anomalies, and determining an event trigger when multi-source data meets a set threshold.

[0022] Three confidence levels are set as high, medium, and low thresholds. When the fusion score reaches or exceeds the high threshold, it is immediately confirmed as an event trigger and subsequent processing is performed. When the score is in the medium threshold range, a short verification window is entered. If the score is continuous within the verification window, the trigger is confirmed; otherwise, it is canceled. When the score is in the low threshold range, the data is simply marked as an early warning and monitoring continues.

[0023] In a preferred embodiment of the low-power, high-reliability built-in dashcam of the present invention, if a loss of connection is detected, the pre-recorded data in the buffer is merged with the video T2 seconds after the event to generate a complete event segment, and a tiered locking strategy is executed, including:

[0024] Set a three-level locking strategy: Level 1 locking is used for severe collisions or events triggered by airbags. Once the Level 1 locking condition is triggered, the event fragment is immediately marked as non-overwriteable, non-deletable, or non-tamperable and stored in the protected partition of the device; Level 2 locking is used for events unlocked by the device administrator. Level 2 events are prohibited from automatic overwriting by default and are unlocked by authorized operations under log recording and auditing; Level 3 locking is used for warning or low-severity events and is automatically overwritten after the retention period ends according to the device policy.

[0025] As a preferred embodiment of the low-power, high-reliability built-in dashcam implementation method of the present invention, the method includes: automatically selecting an upload strategy based on wireless network bandwidth and event level, including:

[0026] When the bandwidth is at a high level, Level 1 and Level 2 events perform full uploads, while Level 3 events upload compressed versions.

[0027] When the bandwidth is at a medium level, Level 1 events continue to upload the entire data, Level 2 events upload keyframes and metadata, and Level 3 events pause the upload.

[0028] When bandwidth is in a low-level state or momentary interruption, Level 1 events only upload event summary packets, and at the same time mark the event locally as pending recovery. Differential resume transmission will be performed first after the network is restored.

[0029] Secondly, embodiments of the present invention provide a system for implementing a low-power, high-reliability built-in vehicle dashcam, comprising:

[0030] The intelligent wake-up module is used to automatically wake up the main control module and initialize the sensors, lenses, storage and accelerometer when an ignition signal, battery voltage fluctuation or vibration signal is detected in the vehicle bus.

[0031] The buffer pre-recording module is used to construct a multimodal data stream and saves the historical data of the most recent T1 seconds in the buffer for pre-recording.

[0032] The trigger recognition module is used to continuously analyze the vehicle's operating status and acceleration anomalies. When the multi-source data meets the set threshold, it is determined to be an event trigger.

[0033] The tiered locking module is used to merge the pre-recorded data in the buffer with the video T2 seconds after the event occurs when an event trigger signal is detected, generate a complete event segment, and execute the tiered locking strategy.

[0034] The evidence upload module is used to automatically select an upload strategy based on wireless network bandwidth and event level.

[0035] Thirdly, embodiments of the present invention provide a computer device, including a memory and a processor, wherein the memory stores a computer program, wherein: when the computer program instructions are executed by the processor, they implement the steps of the method for implementing a low-power, high-reliability built-in dashcam as described in the first aspect of the present invention.

[0036] Fourthly, embodiments of the present invention provide a computer-readable storage medium having a computer program stored thereon, wherein: when the computer program instructions are executed by a processor, they implement the steps of the method for implementing a low-power, high-reliability built-in dashcam as described in the first aspect of the present invention.

[0037] The beneficial effects of this invention are as follows: By constructing a multimodal data stream buffer, this invention saves the most recent vehicle videos and sensor data in real time, enabling pre-recording of videos before accidents occur, ensuring complete event recording and improving the effectiveness of evidence collection. It continuously analyzes multi-source data such as vehicle operating status, acceleration, and attitude changes, triggering event judgment only when multiple parameters simultaneously exceed thresholds, effectively reducing false alarms and false negatives and improving event recognition accuracy. Based on the event level, a differentiated locking strategy is implemented for video segments; high-level event videos are stored using double-layer encryption and read-only storage, ensuring evidence security and traceability. Attached Figure Description

[0038] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying 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.

[0039] Figure 1 A flowchart illustrating the implementation method of a low-power, high-reliability built-in vehicle dashcam; Figure 2 A schematic diagram of the system structure for implementing a low-power, high-reliability built-in dashcam. Detailed Implementation

[0040] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0041] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0042] Secondly, the term "an embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0043] Example 1

[0044] Reference Figures 1-2 This is the first embodiment of the present invention, which provides a method for implementing a low-power, high-reliability built-in dashcam, including: S1: When an ignition signal, battery voltage fluctuation, or vibration signal is detected in the vehicle bus, the main control module is automatically woken up and the sensors, camera, storage, and accelerometer are initialized.

[0045] Furthermore, the wake-up condition is determined by the fusion of vehicle status signals and IMU data, and the fusion score S is calculated based on the normalized score according to a weighted fusion strategy. total And determine wake-up;

[0046] Set the first threshold T high With the second threshold T low Satisfying T high >T low When S total ≥T high When T is active, immediately perform a full wake-up; when T is active... low ≤S total <T high At that time, enter the verification window and perform verification on S during the verification window. total Perform repeated sampling and verification; if the verification passes, execute a full wake-up; otherwise, return to a low-power state.

[0047] It should be noted that the vehicle status signals include, but are not limited to, ignition signals, gear position signals, vehicle speed signals, door opening / closing signals, battery voltage status, and key operating parameters in the vehicle bus (CAN / LIN); the IMU data includes inertial parameters such as triaxial acceleration, triaxial angular velocity, and attitude change rate. The system samples the above signals at a fixed sampling period (e.g., 50ms to 100ms) and inputs the acquisition results into the fusion and determination module.

[0048] To eliminate differences in signal dimensions, the system first normalizes each input signal and then assigns a weight coefficient based on the importance of each signal in the wake-up determination. For example, ignition status and gear change signals have higher weights; acceleration and angular velocity signals have lower weights; and voltage fluctuations and door signals have relatively lower weights. A fusion score S is obtained through weighted fusion calculation. total It is used to reflect the overall dynamic activity level of a vehicle.

[0049] Preset first threshold T high With the second threshold T low Satisfying relation T high >T low When the fusion score S total ≥T high When the vehicle is considered to be in significant motion or an abnormal state (such as starting, rapid acceleration, or strong vibration), a full wake-up operation is immediately executed, activating the main controller, image acquisition module, and cache module; when T... low ≤S total <T high At this time, the system enters the verification window mode, in which it continuously verifies S. total Perform repeated sampling verification (e.g., 3-5 consecutive samplings). If the fusion score remains higher than T during the verification window... low If the fluctuation is stable, it is determined to be a real driving state or an abnormal state, and a full wake-up is executed; if the verification fails, the system automatically returns to a low-power standby state.

[0050] The verification window setting effectively suppresses false wake-ups caused by short-term interference. For example, when a vehicle is stationary, slight external vibrations, wind pressure changes, or the approach of a pedestrian can cause a momentary abnormality in the IMU output. Through multiple sampling and judgment by the verification window, this can be automatically identified as a non-continuous abnormal state, and the system will remain in sleep mode without starting, thus significantly reducing the false wake-up rate. During system operation, it automatically switches between three states: "low-power standby mode," "verification window mode," and "full wake-up mode." In low-power standby mode, only the low-power monitoring unit and the IMU module remain operational; when the fusion score enters T... low ~T high When the interval is reached, the system temporarily increases the sampling rate to enter the verification window; when the determination reaches T... high Upon successful verification, the system enters full wake-up mode. Through the aforementioned hierarchical control, the system can reduce power consumption to the milliwatt level during static standby, while ensuring immediate response during vehicle startup or in case of malfunction.

[0051] S2: Construct a multimodal data stream and save the historical data of the most recent T1 seconds in the buffer for pre-recording.

[0052] Furthermore, the buffer area adopts a circular buffer queue structure, storing the data of each channel in the most recent T1 seconds in time sequence; the buffer capacity is configured and dynamically managed according to a strategy as follows: The cache is allocated in a fixed amount by channel or by priority, with a high proportion of buffer capacity reserved for critical channels. When the cache is full, the oldest data is overwritten in the order of earliest time, and data segments marked with event retention are prohibited from being overwritten. The cache capacity is proportional to T1, and the T1 value is dynamically adjusted according to the vehicle's operating status.

[0053] It should be noted that the circular buffer is logically composed of several fixed-size segments, each corresponding to a continuous time slice (e.g., 1 second or 0.5 seconds). The segment contains synchronous data indexes from all channels, rather than redundant data copies. The buffer can be implemented using one of two allocation strategies or a combination of both: Channel partitioning: Allocate an independent sub-circular buffer for each channel (front camera, rear camera, in-vehicle camera, IMU, CAN, GPS, audio, etc.), with each sub-buffer segment aligned with the same time length unit, facilitating parallel writing and independent playback; Divide the buffer into a priority area and a circular area according to priority. Critical channels (e.g., front camera, IMU, CAN) retain a higher proportion of segments in the priority area, while non-critical channels share the remaining capacity in the circular area, ensuring that critical evidence can still be retained for a longer time when capacity is limited.

[0054] Each segment should contain the following information for fast retrieval and consistency verification: segment ID, start / end timestamp, keyframe or key sample location within the segment, channel bitmap, hash digest within the segment (e.g., SHA-256), and write status flags (writing, write complete, locked). The index table should reside in a fast metadata area (e.g., small NOR or SRAM) to support low-latency retrieval. To support concurrent writes across multiple channels, buffer writes employ segmented pre-allocation + transactional writing: before writing, the target segment status is set to "writing," and after writing, the segment hash is calculated and the status is updated to "write complete." If the write process is interrupted (e.g., power failure), the system will roll back or rewrite incomplete segments upon restart by checking the write status and transaction log, thereby avoiding corruption or forged timing. When the circular buffer reaches its capacity limit, the earliest overwriteable segment is overwritten by default (i.e., overwriting old data in a first-in-first-out manner); however, the "reservation / locking" flag of each segment must be checked before overwriting: segments marked as event-reserved or locked are strictly prohibited from being overwritten; the system will find the next earliest unlocked segment to overwrite. If a majority of consecutive segments are locked and there are no segments to cover, the overflow handling policy is triggered.

[0055] T1 represents the length of the pre-retention time window, and the total buffer capacity is directly related to T1. The system should support dynamic adjustment of the T1 value based on the vehicle's operating status. For example, when the vehicle is traveling at high speed or accelerating rapidly, T1 should be automatically increased to extend the pre-retention period (e.g., from 30s to 60s); when the vehicle is stopped or traveling at low speed, T1 can be shortened to save storage and extend the duration of parking monitoring. Dynamic adjustment is achieved by updating the number of segments allocated to each channel, and smooth switching should be implemented without losing the current critical segments. A channel priority matrix should be defined (e.g., front camera > IMU > CAN > rear camera > in-vehicle camera > audio) to determine the retention ratio of each channel when capacity is tight; a minimum retention threshold should be set for critical channels within the partition to avoid frequent overwriting of critical data. When the buffer becomes uncoverable due to a large number of locked segments, the system implements overflow handling: it prioritizes triggering a report or cloud alarm, prompting the need to upload data to the network or collect evidence manually as soon as possible; it can temporarily improve the write strategy (e.g., compress historical segments to a lower bit rate or reduce the sampling rate of non-critical channels) to free up space; if space still cannot be freed up, it can perform controlled overwriting according to a predefined strategy (e.g., "the oldest secondary event can be overwritten"), and each overflow decision is recorded in the audit log and signed.

[0056] S3: Continuously analyze vehicle operating status and acceleration anomalies. When multi-source data meets the set threshold, it is determined to be an event triggered.

[0057] Furthermore, within the sliding time window, short-term statistics and event indicators of each modality are aggregated to form a set of event candidate information within the time window; the event candidate information is temporally correlated; and the anomaly of each modality is fused according to preset weights to obtain the event confidence score at the current time point or time window.

[0058] Furthermore, thresholds corresponding to the three confidence levels are set as high threshold, medium threshold, and low threshold. When the fusion score reaches or exceeds the high threshold, it is immediately confirmed as an event trigger and subsequent processing is executed. When the score is in the medium threshold range, it enters a short-term verification window. If the score is continuous within the verification window, the trigger is confirmed; otherwise, it is canceled. When the score is in the low threshold range, the data is simply marked as an early warning and monitoring continues.

[0059] It should be noted that the sliding time window is a configurable time period used to collect short-term statistics and event indicators of each modality within that time period to construct an event candidate set. Common window lengths are 0.5 seconds, 1 second, or 2 seconds; the window step can be set to half the window length or a fixed sampling period (e.g., 50ms) to achieve overlapping sampling and continuous detection, with data within the window aligned according to a unified time reference.

[0060] Features from different modalities should be correlated based on their timestamps, allowing for a certain time tolerance (e.g., ±50-200ms) to accommodate sampling or data transmission delays from different modalities. Time correlation strategies include: treating modal features with temporal overlap within the same window or adjacent windows as constituent evidence of the same candidate event; if a modality experiences a short time lag before or after the main evidence, it should still be merged into the same candidate event, but the lag amount should be recorded in the metadata; if the time difference exceeds the tolerance threshold, it should be evaluated separately as independent candidate events. To enable weighted fusion of features from different modalities, the short-time statistics of each modality are first mapped to a normalized anomaly score. Common methods include linear normalization, Z-score mapping based on historical noise statistics, or sigmoid nonlinear mapping. The anomaly range after mapping is typically standardized to [0,1], where 0 indicates no anomaly and 1 indicates a strong anomaly. Mapping parameters (threshold, curve slope, etc.) should be configurable and calibrated according to vehicle / installation differences.

[0061] The verification window employs debouncing and redundancy-based judgment to prevent false alarms due to short-term noise. Specifically, this includes: continuous sampling requirements: requiring at least M consecutive samplings (e.g., M=3) with a score ≥ Mid within the verification window, or accumulating more than N set events (e.g., N=2) within the window; the ability to set at least two modalities to trigger anomalies within the window (e.g., simultaneous IMU and CAN anomalies or simultaneous IMU and vision anomalies); and adaptive window duration: extending the verification window in high-noise environments or parking scenarios to reduce false alarms, and shortening the window in emergency situations to improve response speed.

[0062] When a certain modality is unavailable (e.g., vision is blocked, GPS is temporarily lost), the fusion module should make a degradation judgment according to the available modalities: dynamically reallocate weights to available modalities and adjust thresholds to maintain judgment sensitivity; if a critical modality is missing for a long time, a diagnostic log is generated and a maintenance alarm can be issued, and the degradation factor is noted when adjusting the threshold or weight.

[0063] S4: When an event trigger signal is detected, the pre-recorded data in the buffer is merged with the video T2 seconds after the event occurs to generate a complete event segment, and a hierarchical locking strategy is executed.

[0064] Furthermore, a three-level locking strategy is set: Level 1 locking is used for severe collisions or events triggered by airbags. Once the Level 1 locking condition is triggered, the event fragment is immediately marked as non-overwriteable, non-deletable, or non-tamperable and stored in the protected partition of the device; Level 2 locking is used for events unlocked by the device administrator. Level 2 events are prohibited from automatic overwriting by default and are unlocked by authorized operations under log recording and auditing; Level 3 locking is used for warning or low-severity events and is automatically overwritten after the retention period ends according to the device policy.

[0065] It should be noted that the protected partition is used to store first-level event files, and its security is achieved through multiple mechanisms, including: file system-level protection: the protected partition adopts a read-only mount mode, and write or delete operations are prohibited except for system kernel services; integrity verification: each file calculates a SHA256 hash value when saved, and the hash digest and lock level are recorded together in an encrypted index table; encrypted storage: the files are encrypted using the AES-256 algorithm, and the key is stored inside the security chip (TPM / TEE) and is not exposed to the outside; anti-tampering mechanism: when an unauthorized write operation attempt is detected, the system immediately generates an audit log and reports it to the cloud event center.

[0066] For secondary locking events, the system has designed a secure and traceable administrator unlocking process, including: identity verification: the administrator needs to log in to the device management interface through two-factor authentication (password + dynamic token or NFC card);

[0067] Log auditing: The system automatically generates unlock request records, including timestamps, operator IDs, event numbers, and unlock reasons; Authorization confirmation: Unlocking operations require secondary confirmation (or remote authorization) before the "prohibited overwrite" status can be lifted; Automatic backup: Before unlocking, the system copies the original event files to the backup directory in the security zone to prevent data loss; Cloud synchronization: All unlocking actions must be synchronized to the cloud audit logs for subsequent tracking and compliance archiving.

[0068] Level 3 locked events are automatically overwritten after the retention period ends, according to the device policy. The retention period T is determined by the device's operating policy or cloud configuration (e.g., 7 days, 14 days, or 30 days). During the retention period: the cache management module will prioritize overwriting unlocked or expired Level 3 events when space is insufficient; if a high-priority event (Level 1 or Level 2) occurs, the system can temporarily compress or delete lower-level caches to ensure storage space; before the overwrite operation, the system performs a fast consistency check to ensure that files that have not expired or have been incorrectly marked are not deleted.

[0069] S5: Automatically selects upload strategy based on wireless network bandwidth and event level.

[0070] Furthermore, when the bandwidth is at a high level, Level 1 and Level 2 events perform full uploads, while Level 3 events upload compressed versions.

[0071] When the bandwidth is at a medium level, Level 1 events continue to upload the entire data, Level 2 events upload keyframes and metadata, and Level 3 events pause the upload.

[0072] When bandwidth is in a low-level state or momentary interruption, Level 1 events only upload event summary packets, and at the same time mark the event locally as pending recovery. Differential resume transmission will be performed first after the network is restored.

[0073] It should be noted that when the bandwidth is high, the system adopts a multi-threaded or chunked upload strategy: video data is uploaded in segments, each with a unique ID and hash value; sensor channel data and metadata are uploaded synchronously over time; for level 3 events, only compressed video (e.g., with reduced resolution or frame rate) is uploaded, while complete metadata is uploaded to ensure subsequent traceability.

[0074] When the bandwidth is at a medium level, Level 1 events still perform a full upload; Level 2 events selectively upload keyframes (e.g., 1-2 frames per second) and all sensor and metadata data; the system determines the keyframe position based on the time window or event segment index to ensure that the event sequence can be restored in subsequent playback; Level 3 events pause the upload, only retain the local cache, and decide whether to upload again according to the policy after the bandwidth is restored.

[0075] When bandwidth is low or a momentary interruption occurs, only the event ID, lock level, event time, preliminary sensor statistics, and event type label are uploaded. The system sets an "upload pending recovery" flag for the event locally and records the event segment index, uploaded content, and unuploaded content. After the network is restored, the upload module prioritizes the data blocks that have not been uploaded to perform differential resume transmission to avoid repeatedly uploading completed data. Differential resume transmission tasks prioritize first-level events, followed by second-level events, and third-level events have low priority or can be delayed until idle time for upload.

[0076] To ensure upload integrity and traceability, the system should implement the following: Upload failure retry mechanism: retrying exponentially or at fixed intervals until successful upload or bandwidth level change; Upload log recording: recording upload event ID, timestamp, chunk number, bandwidth level, and number of retries; Auditing and recovery: when upload interruption leads to differential resume, the system automatically generates a complete audit chain to support post-event evidence collection or cloud-based synchronous verification. The system should dynamically monitor bandwidth level changes and adjust upload strategies accordingly: when bandwidth recovers from a low level to a high level, the system immediately initiates the upload of full or compressed data for the events to be uploaded; when bandwidth drops from a high level to a medium or low level, the system suspends low-priority upload tasks and selectively uploads necessary data (keyframes or digest packets) based on event level; when bandwidth fluctuates frequently, the upload module can perform batch compression or delayed upload of low-priority events to ensure timely transmission of high-priority events.

[0077] Example 2

[0078] This embodiment is the second embodiment of the present invention, which provides a method for implementing a low-power, high-reliability built-in dashcam. In order to verify the beneficial effects of the present invention, a simulation experiment is conducted for scientific demonstration.

[0079] Step 1: Each sensor collects data at a fixed sampling rate. The buffer uses a circular buffer queue to store the data from the most recent T1 second. A high proportion of buffer capacity is allocated to key channels (front camera, IMU, CAN).

[0080] Step 2: Aggregate the short-term statistics of each modality within the sliding time window to form event candidate information, calculate the fusion score according to the preset weights and fusion anomaly degree, and trigger the event according to the three-level confidence thresholds (high=0.8, medium=0.5, low=0.25);

[0081] Step 3: Merge the pre-event T1-second cache with the post-event T2-second video to generate a complete event segment. Implement a three-level locking strategy based on the event level: Level 1 locks the protected partition and prevents overwriting; Level 2 locks prevent overwriting by default and requires administrator unlocking; Level 3 locks automatically overwrite according to the retention period.

[0082] Step 4: The system dynamically selects the upload strategy based on the bandwidth level. High bandwidth: Level 1 / Level 2 events are uploaded in full, and Level 3 events are uploaded in compressed form; Medium bandwidth: Level 1 events are uploaded in full, Level 2 events are uploaded with keyframes and metadata, and Level 3 events are paused; Low bandwidth or momentary interruption: Level 1 events are uploaded with a digest packet, and Level 2 / Level 3 events are resumed differentially after the network recovers.

[0083] Step 5: After the network is restored, differential resume transmission of Level 1 events will be executed first, Level 2 events will be uploaded according to the authorized priority order, and Level 3 events can be delayed or not uploaded.

[0084] Simulation results

[0085] Event trigger accuracy: High-confidence events (Level 1) trigger rate 100%, no missed reports; Medium-confidence events (Level 2) trigger rate 95%, verification window reduces false alarms; Low-confidence events (Level 3) trigger rate 80%, marking and warning are effective; Level 1 locked events are not overwritten or deleted, protected partitions are safe and reliable; Level 2 locked events cannot be overwritten before authorized unlocking, audit records are complete; Level 3 events are automatically overwritten at the end of the retention period, cache space management is effective.

[0086] Upload strategy verification: High bandwidth scenario: All high and medium events are uploaded in a timely manner, and the third-level events are compressed and uploaded successfully; Medium bandwidth scenario: First-level events are uploaded in full, second-level events are uploaded as keyframes, and third-level events are paused during the upload process.

[0087] Low bandwidth / disconnection: Level 1 event summary upload, differential resume transmission completes after recovery, ensuring data integrity.

[0088] The statistics of simulation data uploads are shown in Table 1 below:

[0089]

[0090] Table 1. Statistics on Event Upload under Different Bandwidth Levels

[0091] Table 1 illustrates that in this embodiment of the invention: Under high bandwidth conditions, all Level 1, Level 2, and Level 3 events can be successfully uploaded according to the strategy, with an upload success rate of 100%, verifying the effectiveness of timely uploading of high-priority events and compressed uploading of low-priority events; Under medium bandwidth conditions, Level 1 events are still fully uploaded, Level 2 events upload keyframes and metadata, and Level 3 events are paused in uploading, with an overall upload success rate of 97%, verifying the optimized utilization of resources by the bandwidth adaptive upload strategy under medium network conditions; Under low bandwidth or momentary interruption conditions, Level 1 events only upload digest packets, and the upload is completed through differential retransmission after the network is restored, while Level 2 / Level 3 events are paused in uploading, with an upload success rate of 95%, indicating that the differential retransmission mechanism effectively ensures data integrity and event traceability.

[0092] This embodiment also provides a computer device applicable to the implementation method of a low-power, high-reliability built-in dashcam, including a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement the low-power, high-reliability built-in dashcam implementation method proposed in the above embodiment.

[0093] The computer device can be a terminal, comprising a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, NFC (Near Field Communication), or other technologies. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device's casing, or an external keyboard, touchpad, or mouse.

[0094] This embodiment also provides a storage medium storing a computer program, which, when executed by a processor, implements the method for implementing a low-power, high-reliability built-in vehicle recorder as proposed in the above embodiments.

[0095] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A method for implementing a low-power, high-reliability built-in vehicle dashcam, characterized in that, include: When an ignition signal, battery voltage fluctuation, or vibration signal is detected in the vehicle bus, the main control module is automatically woken up and the sensors, camera, storage, and accelerometer are initialized. Construct a multimodal data stream and store the most recent T1 second of historical data in a buffer for pre-recording. Continuously analyze vehicle operating status and acceleration anomalies; when multi-source data meets the set threshold, it is determined to be an event triggered. When an event trigger signal is detected, the pre-recorded data in the buffer is merged with the video T2 seconds after the event occurs to generate a complete event segment, and a hierarchical locking strategy is executed. The upload strategy is automatically selected based on the wireless network bandwidth and the event level.

2. The method for implementing a low-power, high-reliability built-in dashcam as described in claim 1, characterized in that, The automatic wake-up of the main control module and initialization of sensors, lenses, storage, and accelerometers includes: The wake-up condition is determined by the fusion of vehicle status signals and IMU data, and the fusion score S is calculated based on the normalized score according to a weighted fusion strategy. total And determine wake-up; Set the first threshold T high With the second threshold T low Satisfying T high >T low When S total ≥T high When T is active, immediately perform a full wake-up; when T is active... low ≤S total <T high At that time, enter the verification window and perform verification on S during the verification window. total Perform repeated sampling and verification; if the verification passes, execute a full wake-up; otherwise, return to a low-power state.

3. The method for implementing a low-power, high-reliability built-in dashcam as described in claim 1, characterized in that: The construction of the multimodal data stream, which involves storing historical data from the most recent T1 second in a buffer for pre-recording, includes: The buffer uses a circular buffer queue structure to store the data of each channel in the most recent T1 seconds in time sequence; the buffer capacity is configured and dynamically managed according to the following strategy: The cache is allocated in a fixed amount by channel or by priority, with a high proportion of buffer capacity reserved for critical channels; When the cache is full, the oldest data is overwritten in the order of earliest time, and data segments marked with event retention are prohibited from being overwritten. The cache capacity is proportional to T1, and the T1 value is dynamically adjusted according to the vehicle's operating status.

4. The method for implementing a low-power, high-reliability built-in dashcam as described in claim 1, characterized in that: The continuous analysis of vehicle operating status and acceleration anomalies, when multi-source data meets a set threshold, is determined to be an event triggered, including: Within the sliding time window, short-term statistics and event indicators for each modality are aggregated to form a set of event candidate information within the time window; the event candidate information is then correlated over time. The anomalies of each modality are fused according to preset weights to obtain the event confidence score at the current time point or time window.

5. The method for implementing a low-power, high-reliability built-in dashcam as described in claim 1 or 4, characterized in that, The continuous analysis of vehicle operating status and acceleration anomalies, where an event is triggered when multi-source data meets a set threshold, also includes: Three confidence levels are set as high, medium, and low thresholds. When the fusion score reaches or exceeds the high threshold, it is immediately confirmed as an event trigger and subsequent processing is performed. When the score is in the medium threshold range, a short verification window is entered. If the score is continuous within the verification window, the trigger is confirmed; otherwise, it is canceled. When the score is in the low threshold range, the data is simply marked as an early warning and monitoring continues.

6. The method for implementing a low-power, high-reliability built-in dashcam as described in claim 1, characterized in that: If a loss of connection is detected, the pre-recorded data in the buffer is merged with the video two seconds after the event to generate a complete event segment, and a tiered locking strategy is executed, including: Set a three-level locking strategy: Level 1 locking is used for severe collisions or events triggered by airbags. Once the Level 1 locking condition is triggered, the event fragment is immediately marked as non-overwriteable, non-deletable, or non-tamperable and stored in the protected partition of the device; Level 2 locking is used for events unlocked by the device administrator. Level 2 events are prohibited from automatic overwriting by default and are unlocked by authorized operations under log recording and auditing; Level 3 locking is used for warning or low-severity events and is automatically overwritten after the retention period ends according to the device policy.

7. The method for implementing a low-power, high-reliability built-in dashcam as described in claim 1, characterized in that: The automatic selection of upload strategy based on wireless network bandwidth and event level includes: When the bandwidth is at a high level, Level 1 and Level 2 events perform full uploads, while Level 3 events upload compressed versions. When the bandwidth is at a medium level, Level 1 events continue to upload the entire data, Level 2 events upload keyframes and metadata, and Level 3 events pause the upload. When bandwidth is in a low-level state or momentary interruption, Level 1 events only upload event summary packets, and at the same time mark the event locally as pending recovery. Differential resume transmission will be performed first after the network is restored.

8. A system for implementing a low-power, high-reliability built-in vehicle dashcam, characterized in that, include: The intelligent wake-up module is used to automatically wake up the main control module and initialize the sensors, lenses, storage and accelerometer when an ignition signal, battery voltage fluctuation or vibration signal is detected in the vehicle bus. The buffer pre-recording module is used to construct a multimodal data stream and saves the historical data of the most recent T1 seconds in the buffer for pre-recording. The trigger recognition module is used to continuously analyze the vehicle's operating status and acceleration anomalies. When the multi-source data meets the set threshold, it is determined to be an event trigger. The tiered locking module is used to merge the pre-recorded data in the buffer with the video T2 seconds after the event occurs when an event trigger signal is detected, generate a complete event segment, and execute the tiered locking strategy. The evidence upload module is used to automatically select an upload strategy based on wireless network bandwidth and event level.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, it implements the steps of the method for implementing a low-power, high-reliability built-in vehicle recorder as described in any one of claims 1 to 7.

10. 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 steps of the method for implementing the low-power, high-reliability built-in dashcam as described in any one of claims 1 to 7.

Images