Vehicle end event triggered data collection method, device, equipment and medium

Abstract

The application discloses a vehicle-end event triggered data collection method, device, equipment and medium, relates to the network connection and big data technical field, and the method comprises the following steps: creating a first cache object in the form of a ring cache and a plurality of second cache objects in the form of FIFO queues used alternately; when a new trigger event is detected, overflowing the data of the last trigger event cached in the first cache object into the second cache object, and storing the data of the new trigger event into the first cache object; based on the data cache amount in the second cache object, and when the data cache amount of the current second cache object reaches the set cache amount, uploading the data in the current second cache object to the cloud, and using other second cache to receive the data of the first cache object. The application can effectively realize the uploading processing of the vehicle-end trigger event data.

Description

Technical Field

[0001] This application relates to the fields of connected and big data technology, specifically to a vehicle-side event-triggered data acquisition method, device, equipment, and medium. Background Technology

[0002] Currently, the common approach for trigger-based data acquisition of vehicle-side events is to use a ring memory to store the trigger event data. When the acquisition trigger is activated, the data from the ring memory is written to disk, and the event trigger type and trigger time are recorded. Then, the data sliced ​​from the disk is uploaded to the platform according to the event priority. However, this method of using a ring memory with a fixed-size storage area requires writing the data from the ring memory to disk when the acquisition trigger is activated. This can easily lead to Out of Memory (OOM) errors and redundant data uploads on the TBOX (Telematics Module for Vehicles) node.

[0003] Therefore, how to effectively upload and process event data triggered by the vehicle has become an urgent problem to be solved. Summary of the Invention

[0004] This application provides a vehicle-side event-triggered data acquisition method, apparatus, device, and medium, which can effectively realize the uploading and processing of vehicle-side triggered event data.

[0005] In a first aspect, embodiments of this application provide a vehicle-side event-triggered data acquisition method, the vehicle-side event-triggered data acquisition method comprising: Create a first cache object in the form of a circular cache and multiple second cache objects in the form of alternating FIFO queues; When a new triggering event is detected, the data of the previous triggering event cached in the first cache object is overflowed and injected into the second cache object, and the data of the new triggering event is stored in the first cache object; Based on the data cache amount in the second cache object, when the data cache amount of the current second cache object reaches the set cache amount, the data in the current second cache object is uploaded to the cloud, and other second caches are used to receive the data of the first cache object.

[0006] In conjunction with the first aspect, in one implementation method, The first cache object is a limited-length circular cache constructed using a doubly linked list; The second cache object includes a first sub-cache object and a second sub-cache object, which alternately cache and upload data. Specifically, when the current sub-cached object receives and caches the data of the first cache object to the set cache limit, the data cached by the current sub-cached object is uploaded to the cloud, and at the same time, another sub-cached object receives and caches the data of the first cache object.

[0007] In conjunction with the first aspect, in one implementation method, the detection of the triggering event specifically includes: When the vehicle-side ADCU detects a triggered event according to the event triggering rules, it sends the ID and data of the triggered event to the TBOX. TBOX receives the ID and data of the triggering event, records the current time, and stores the data of the triggering event from the header of the first cache object into the first cache object when caching the data of the triggering event. When multiple trigger events are detected simultaneously, the IDs and data of the trigger events are sent to the TBOX in sequence according to their priority.

[0008] In conjunction with the first aspect, in one implementation, when a new triggering event is detected, the data of the previous triggering event cached in the first cache object is overflowed and injected into the second cache object, and the data of the new triggering event is stored in the first cache object, specifically including: Continuously check if any new triggering events exist: If it exists, when the difference between the trigger time of the new trigger event and the trigger time of the previous trigger event is less than or equal to the preset time threshold, all data in the first cache object is overflowed and injected into the second cache object, and then the data of the new trigger event is stored in the first cache object. When the difference between the trigger time of the new trigger event and the trigger time of the previous trigger event is greater than the preset time threshold, all data in the first cache object is overflowed and injected into the second cache object, and then the data of the new trigger event is stored in the first cache object. The current time recorded by the latest TBOX is used as the trigger time of the new trigger event, and the edge-triggered lock last_flag and curr_flag are both updated to 0. If it does not exist, when the difference between the current time of the latest record in TBOX and the trigger time of the previous trigger event is greater than the preset time threshold, curr_flag is set to 1. When curr_flag is not equal to last_flag, all data in the first cache object is overflowed and injected into the second cache object, and last_flag is set to be equal to curr_flag. When curr_flag is equal to last_flag, when a new trigger event is detected later, the data of the new trigger event is stored from the header of the first cache object into the first cache object.

[0009] In conjunction with the first aspect, in one implementation, injecting all overflowed data from the first cache object into the second cache object specifically includes: Move the tail pointer of the first cache object forward, and inject all the data in the first cache object from the tail into the head of the second cache object. Update the head pointer and length of the second cache object.

[0010] In conjunction with the first aspect, in one implementation, the step of uploading data from the current second cache object to the cloud when the data cache size of the current second cache object reaches a set cache size, and using other second caches to receive data from the first cache object, specifically includes: Continuously monitor the data reception and caching of the first cached object and the second cached object, and determine whether the number of cached data entries for the second cached object exceeds a preset threshold: If not, continue receiving and caching data for the first cached object; If so, all cached data of the second cache object is retrieved, fragmented and packaged into a data packet and uploaded to the cloud. At the same time, another second cache object receives and caches data from the first cache object.

[0011] In conjunction with the first aspect, in one implementation method, If the data packet is uploaded successfully, the retrieved cached data is deleted. If the data packet upload fails, the retrieved cached data is stored in a local file, the upload is retried, and the cached data is deleted after the upload is successful.

[0012] Secondly, embodiments of this application provide a vehicle-side event-triggered data acquisition device, the vehicle-side event-triggered data acquisition device comprising: A module is created to create a first cache object in the form of a circular cache and a second cache object in the form of multiple alternating FIFO queues; The caching module is used to, when a new triggering event is detected, overflow the data of the previous triggering event cached in the first cache object and inject it into the second cache object, and store the data of the new triggering event into the first cache object; The upload module is used to upload the data in the current second cache object to the cloud when the data cache amount in the current second cache object reaches the set cache amount, and to receive the data of the first cache object using other second caches.

[0013] Thirdly, embodiments of this application provide a vehicle-side event-triggered data acquisition device, which includes a processor, a memory, and a vehicle-side event-triggered data acquisition program stored in the memory and executable by the processor. When the vehicle-side event-triggered data acquisition program is executed by the processor, it implements the steps of the vehicle-side event-triggered data acquisition method described above.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium storing a vehicle-side event-triggered data acquisition program, wherein when the vehicle-side event-triggered data acquisition program is executed by a processor, it implements the steps of the vehicle-side event-triggered data acquisition method described above.

[0015] The beneficial effects of the technical solutions provided in this application include: A doubly linked list combined with a fixed-length queue storage structure enables efficient data storage and flexible overflow, eliminating the need for overall data shifting within the cache and reducing on-device computing power consumption. The use of a dual FIFO cache alternating operation mechanism ensures seamless data reception while maintaining data order and integrity. State edge self-locking and secondary cache linkage trigger batch injection and caching only on the rising edge of the state edge lock, avoiding redundant operations. A parallel dual-state approach is adopted, with one receiving data and the other uploading in the background, allowing for parallel, non-blocking uploads. For scenarios with high event triggering frequency and long-lasting events, low-redundancy uploads are achieved, reducing upload load and data deduplication. Combined with a fault-tolerance mechanism, failed uploads are cached locally and re-uploaded after network recovery. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating the vehicle-side event-triggered data acquisition method of this application; Figure 2 This is a schematic diagram of the functional modules of the vehicle-side event-triggered data acquisition device of this application; Figure 3 This is a schematic diagram of the hardware structure of the vehicle-side event-triggered data acquisition device of this application. Detailed Implementation

[0017] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0019] In the first aspect, embodiments of this application provide a vehicle-side event-triggered data collection method to address the problem that frequent event triggering and long durations occur during data collection from the development stage to the mature and stable stage of the intelligent driving system, which leads to OOM and redundant data uploads in the TBOX node.

[0020] In one embodiment, reference is made to Figure 1 , Figure 1 This is a flowchart illustrating the vehicle-side event-triggered data acquisition method of this application. Figure 1 As shown, the vehicle-side event-triggered data acquisition method includes: S1: Create a first cache object in the form of a circular cache and a second cache object in the form of multiple alternating FIFO queues; S2: When a new triggering event is detected, the data of the previous triggering event cached in the first cache object is overflowed and injected into the second cache object, and the data of the new triggering event is stored in the first cache object; S3: Based on the data cache amount in the second cache object, and when the data cache amount of the current second cache object reaches the set cache amount, upload the data in the current second cache object to the cloud, and use other second caches to receive the data of the first cache object.

[0021] Furthermore, in one embodiment, the first cache object is a limited-length circular cache constructed using a doubly linked list; the second cache object includes a first sub-cache object and a second sub-cache object, which alternately cache and upload data; wherein, when the current sub-cache object receives and caches the data of the first cache object to the set cache amount, the data cached by the current sub-cache object is uploaded to the cloud, while another sub-cache object receives and caches the data of the first cache object.

[0022] Specifically, after TBOX starts, it first performs an initialization operation, which initializes the first cache object and the second cache object. The first cache object is a limited-length circular cache built using a doubly linked list, used to store recently collected real-time data. The second sub-cache object contains multiple objects, preferably two: the first sub-cache object and the second sub-cache object. The first and second sub-cache objects use a FIFO queue structure, and they alternately cache and package data to be uploaded. When one becomes overloaded, its data is uploaded to free up space for later use, and the other immediately takes over receiving data from the first cache object.

[0023] Simultaneously, after the TBOX starts, it performs initialization operations, initializing the edge-triggered lock state: last_flag=0, curr_flag=0. Here, last_flag represents the previous state, and curr_flag represents the current state. When last_flag=0 and curr_flag=0, it indicates a steady-state low with no edge triggering; when last_flag=0 and curr_flag=1, it indicates a rising edge; when last_flag=1 and curr_flag=0, it indicates a falling edge; and when last_flag=1 and curr_flag=1, it indicates a steady-state high with no edge triggering.

[0024] Furthermore, in one embodiment, the detection of the triggering event specifically includes: S201: When the vehicle-mounted ADCU (Automotive Intelligent Driving Domain Controller) detects a trigger event according to the event triggering rules, it sends the ID and data of the trigger event to the TBOX; S202: TBOX receives the ID and data of the triggering event, records the current time, and when TBOX caches the data of the triggering event, it stores the data of the triggering event from the header of the first cache object into the first cache object; When multiple trigger events are detected simultaneously, the IDs and data of the trigger events are sent to the TBOX in sequence according to their priority.

[0025] Specifically, the ADCU needs to upload data in real time at 100ms intervals according to the data upload protocol. Therefore, the ADCU detects the existence of trigger events based on the event triggering rules. When a trigger event is detected, the trigger event ID (greater than 0) and the data are sent to the TBOX via the CAN bus during the data upload operation. If multiple trigger events occur simultaneously, the trigger event with the highest priority is sent first. If no event is triggered, event ID=0 is transmitted.

[0026] Furthermore, in one embodiment, when a new triggering event is detected, the data of the previous triggering event cached in the first cache object is overflowed and injected into the second cache object, and the data of the new triggering event is stored in the first cache object, specifically including: Continuously check if any new triggering events exist: If it exists, when the difference between the trigger time of the new trigger event and the trigger time of the previous trigger event is less than or equal to the preset time threshold, all data in the first cache object is overflowed and injected into the second cache object, and then the data of the new trigger event is stored in the first cache object. When the difference between the trigger time of the new trigger event and the trigger time of the previous trigger event is greater than the preset time threshold, all data in the first cache object is overflowed and injected into the second cache object, and then the data of the new trigger event is stored in the first cache object. The current time recorded by the latest TBOX is used as the trigger time of the new trigger event, and the edge-triggered lock last_flag and curr_flag are both updated to 0. If it does not exist, when the difference between the current time of the latest record in TBOX and the trigger time of the previous trigger event is greater than the preset time threshold, curr_flag is set to 1. When curr_flag is not equal to last_flag, all data in the first cache object is overflowed and injected into the second cache object, and last_flag is set to be equal to curr_flag. When curr_flag is equal to last_flag, when a new trigger event is detected later, the data of the new trigger event is stored from the header of the first cache object into the first cache object.

[0027] Specifically, for TBOX, it checks in real time whether a new triggering event exists. If it does, based on the difference between the triggering time of the new triggering event and the triggering time of the previous triggering event, it overflows all data in the first cache object and injects it into the second cache object. Then, it stores the data of the new triggering event into the first cache object and updates last_flag and curr_flag accordingly. If it does not exist, it performs the following operations: when the difference between the current time of the latest record in TBOX and the triggering time of the previous triggering event is greater than a preset time threshold, it sets curr_flag to 1; when curr_flag is not equal to last_flag, it overflows all data in the first cache object and injects it into the second cache object, and sets last_flag to be equal to curr_flag; when curr_flag is equal to last_flag, when a new triggering event is subsequently detected, it stores the data of the new triggering event from the header of the first cache object into the first cache object.

[0028] Furthermore, in one embodiment, injecting all overflowed data from the first cache object into the second cache object specifically includes: Move the tail pointer of the first cache object forward, and inject all the data in the first cache object from the tail into the head of the second cache object. Update the head pointer and length of the second cache object.

[0029] Specifically, the tail pointer of the first cache object is set to Pa_r and the head pointer to Pa_h, and the tail pointer of the second cache object is set to Pb_r and the head pointer to Pb_h, with a length of Lb. When writing data from the first cache object to the second cache object, the tail pointer Pa_r of the first cache object is moved forward, and all data in the first cache object overflows from the tail and is injected into the head of the second cache object, and Pb_h and Lb are updated.

[0030] Furthermore, in one embodiment, based on the data cache size in the second cache object, and when the data cache size of the current second cache object reaches a set cache size, the data in the current second cache object is uploaded to the cloud, and other second caches are used to receive the data from the first cache object, specifically including: Continuously monitor the data reception and caching of the first cached object and the second cached object, and determine whether the number of cached data entries for the second cached object exceeds a preset threshold: If not, continue receiving and caching data for the first cached object; If so, all cached data of the second cache object is retrieved, fragmented and packaged into a data packet and uploaded to the cloud. At the same time, another second cache object receives and caches data from the first cache object.

[0031] Specifically, for TBOX data packaging and local disk storage, a dual second cache object is used. Assuming the currently used cache is the first sub-cache object, the data volume of the first sub-cache object is continuously monitored to complete the packaging, sending, and exception handling of the data to be uploaded. A preset data count threshold T is set for the first sub-cache object. It is determined whether the current data count in the first sub-cache object is greater than the preset threshold T: if it is not exceeded, the first sub-cache object continues to store data from the first cache object; if it exceeds the threshold T, a temporary cache is taken from the end of the first sub-cache object, and then fragmented and packaged to generate a data packet that conforms to the transmission standard. At the same time, the space of the first sub-cache object is freed up, and the second sub-cache object is used to receive data from the first cache object.

[0032] Next, the data packet is sent to the cloud server. If the transmission is successful, the temporary cached data is deleted, completing the packet upload process. If the transmission fails, the temporary cached data is written to a local file for temporary storage. The transmission will be retried once the network is restored, and the local file will be cleared upon successful transmission. Specifically, if the data packet upload is successful, the retrieved cached data is deleted; if the data packet upload fails, the retrieved cached data is stored in a local file, the upload is retried, and the cached data is deleted upon successful upload.

[0033] When an event trigger is activated on the vehicle, the TBOX receives a trigger flag and needs to upload data from a time window of n0 seconds before and n1 seconds after the trigger to the platform. This application proposes a two-level storage architecture combined with automatic data transfer to address the TBOX's data storage and upload needs. This architecture ensures event data integrity while achieving zero-redundancy data upload and avoiding OutOfMemoryError (OOM). First, an n0-second buffer (i.e., the first buffer object) is allocated in RAM to store the latest data. Two additional buffers (i.e., two second buffer objects, designated as the first and second sub-buffer objects respectively) are used alternately to cache event data from the first buffer object. When an event is triggered, the data to be uploaded overflows from the end of the first buffer object into one of the second buffer objects. Once the second buffer object reaches a certain size, it is packaged and uploaded, then stored in the other second buffer object. If the upload fails due to network issues, the data is written to a local file and re-uploaded after network recovery.

[0034] This application utilizes a storage structure combining a doubly linked list and a fixed-length queue to achieve efficient data storage and flexible overflow. It eliminates the need for a complete data shift within the cache, reducing computational power consumption on the vehicle side. It overcomes the limitation of existing circular caches, which can only passively overflow when full. By combining event ID and time threshold control, it achieves bidirectional adaptation between proactive overflow when the cache is not full and automatic overwriting when the cache is full. This ensures data integrity while avoiding duplicate data uploads, improving the reliability and standardization of data uploads. For scenarios with high event triggering frequency and long-lasting events, it solves the problem of duplicate data uploads and high redundancy. The doubly linked list design eliminates the need for a complete data shift when data overflows, significantly reducing computational power consumption on the vehicle side. The use of a dual FIFO cache alternating working mechanism ensures seamless data reception while maintaining data order and integrity. Upload is triggered when the cache reaches a certain size, preventing memory OOM (Out of Memory) errors.

[0035] The vehicle-side event-triggered data acquisition method in this application uses a doubly linked list combined with a fixed-length queue storage structure to achieve efficient data storage and flexible overflow, eliminating the need for overall data shifting within the cache and reducing vehicle-side computing power consumption. The use of a dual FIFO buffer alternating operation mechanism ensures seamless data reception while maintaining data order and integrity. State edge self-locking and secondary cache linkage trigger batch injection and caching only on the rising edge of the state edge lock, avoiding redundant operations. A parallel dual-state approach is adopted, with one receiving data and the other uploading in the background, allowing for parallel and non-blocking uploads. For scenarios with high event triggering frequency and long-lasting events, low-redundancy uploads are achieved, reducing upload load and data deduplication. Combined with a fault-tolerance mechanism, failed uploads are cached locally and re-uploaded after network recovery.

[0036] Secondly, embodiments of this application also provide a vehicle-side event-triggered data acquisition device.

[0037] In one embodiment, reference is made to Figure 2 , Figure 2 This is a schematic diagram of the functional modules of the vehicle-side event-triggered data acquisition device of this application. Figure 2 As shown, the vehicle-side event-triggered data acquisition device includes: a creation module, a caching module, and an upload module.

[0038] The creation module is used to create a first cache object in the form of a ring cache and multiple second cache objects in the form of alternating FIFO queues; the caching module is used to inject the overflow data of the previous triggering event cached in the first cache object into the second cache object when a new triggering event is detected, and to store the data of the new triggering event into the first cache object; the upload module is used to upload the data in the current second cache object to the cloud based on the data cache amount in the second cache object, and when the data cache amount of the current second cache object reaches the set cache amount, and to use other second caches to receive the data of the first cache object.

[0039] Thirdly, embodiments of this application provide a vehicle-side event-triggered data acquisition device, which can be a personal computer (PC), laptop computer, server, or other device with data processing capabilities.

[0040] Reference Figure 3 , Figure 3 This is a schematic diagram of the hardware structure of the vehicle-side event-triggered data acquisition device involved in the embodiments of this application. In this embodiment, the vehicle-side event-triggered data acquisition device may include a processor, a memory, a communication interface, and a communication bus.

[0041] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.

[0042] The communication interface includes input / output (I / O) interfaces, physical interfaces, and logical interfaces used for interconnecting internal components of the vehicle-mounted event-triggered data acquisition device, as well as interfaces used for interconnecting the vehicle-mounted event-triggered data acquisition device with other devices (such as other computing devices or user equipment). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.

[0043] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0044] The processor can be a general-purpose processor, which can call the vehicle-side event-triggered data acquisition program stored in the memory and execute the vehicle-side event-triggered data acquisition method provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the vehicle-side event-triggered data acquisition program is called can be referred to in the various embodiments of the vehicle-side event-triggered data acquisition method of this application, and will not be repeated here.

[0045] Those skilled in the art will understand that Figure 3 The hardware structure shown does not constitute a limitation of this application and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0046] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0047] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0048] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0049] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0050] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0051] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A vehicle-side event-triggered data acquisition method, characterized in that, The vehicle-side event-triggered data acquisition method includes: Create a first cache object in the form of a circular cache and multiple second cache objects in the form of alternating FIFO queues; When a new triggering event is detected, the data of the previous triggering event cached in the first cache object is overflowed and injected into the second cache object, and the data of the new triggering event is stored in the first cache object; Based on the data cache amount in the second cache object, when the data cache amount of the current second cache object reaches the set cache amount, the data in the current second cache object is uploaded to the cloud, and other second caches are used to receive the data of the first cache object.

2. The vehicle-side event-triggered data acquisition method as described in claim 1, characterized in that: The first cache object is a limited-length circular cache constructed using a doubly linked list; The second cache object includes a first sub-cache object and a second sub-cache object, which alternately cache and upload data. Specifically, when the current sub-cached object receives and caches the data of the first cache object to the set cache limit, the data cached by the current sub-cached object is uploaded to the cloud, and at the same time, another sub-cached object receives and caches the data of the first cache object.

3. The vehicle-side event-triggered data acquisition method as described in claim 1, characterized in that, The detection of triggering events specifically includes: When the vehicle-side ADCU detects a triggered event according to the event triggering rules, it sends the ID and data of the triggered event to the TBOX. TBOX receives the ID and data of the triggering event, records the current time, and stores the data of the triggering event from the header of the first cache object into the first cache object when caching the data of the triggering event. When multiple trigger events are detected simultaneously, the IDs and data of the trigger events are sent to the TBOX in sequence according to their priority.

4. The vehicle-side event-triggered data acquisition method as described in claim 3, characterized in that, When a new triggering event is detected, the data of the previous triggering event cached in the first cache object is overflowed and injected into the second cache object, and the data of the new triggering event is stored in the first cache object. Specifically, this includes: Continuously check if any new triggering events exist: If it exists, when the difference between the trigger time of the new trigger event and the trigger time of the previous trigger event is less than or equal to the preset time threshold, all data in the first cache object is overflowed and injected into the second cache object, and then the data of the new trigger event is stored in the first cache object. When the difference between the trigger time of the new trigger event and the trigger time of the previous trigger event is greater than the preset time threshold, all data in the first cache object is overflowed and injected into the second cache object, and then the data of the new trigger event is stored in the first cache object. The current time recorded by the latest TBOX is used as the trigger time of the new trigger event, and the edge-triggered lock last_flag and curr_flag are both updated to 0. If it does not exist, when the difference between the current time of the latest record in TBOX and the trigger time of the previous trigger event is greater than the preset time threshold, curr_flag is set to 1. When curr_flag is not equal to last_flag, all data in the first cache object is overflowed and injected into the second cache object, and last_flag is set to be equal to curr_flag. When curr_flag is equal to last_flag, when a new trigger event is detected later, the data of the new trigger event is stored from the header of the first cache object into the first cache object.

5. The vehicle-side event-triggered data acquisition method as described in claim 1, characterized in that, The step of injecting all overflowed data from the first cache object into the second cache object specifically includes: Move the tail pointer of the first cache object forward, and inject all the data in the first cache object from the tail into the head of the second cache object. Update the head pointer and length of the second cache object.

6. The vehicle-side event-triggered data acquisition method as described in claim 1, characterized in that, The process of caching data based on the data cache size in the second cache object, and uploading the data in the current second cache object to the cloud when the data cache size of the current second cache object reaches the set cache size, and using other second caches to receive data from the first cache object, specifically includes: Continuously monitor the data reception and caching of the first cached object and the second cached object, and determine whether the number of cached data entries for the second cached object exceeds a preset threshold: If not, continue receiving and caching data for the first cached object; If so, all cached data of the second cache object is retrieved, fragmented and packaged into a data packet and uploaded to the cloud. At the same time, another second cache object receives and caches data from the first cache object.

7. The vehicle-side event-triggered data acquisition method as described in claim 6, characterized in that: If the data packet is uploaded successfully, the retrieved cached data is deleted. If the data packet upload fails, the retrieved cached data is stored in a local file, the upload is retried, and the cached data is deleted after the upload is successful.

8. A vehicle-side event-triggered data acquisition device, characterized in that, The vehicle-mounted event-triggered data acquisition device includes: A module is created to create a first cache object in the form of a circular cache and a second cache object in the form of multiple alternating FIFO queues; The caching module is used to, when a new triggering event is detected, overflow the data of the previous triggering event cached in the first cache object and inject it into the second cache object, and store the data of the new triggering event into the first cache object; The upload module is used to upload the data in the current second cache object to the cloud when the data cache amount in the current second cache object reaches the set cache amount, and to receive the data of the first cache object using other second caches.

9. A vehicle-side event-triggered data acquisition device, characterized in that, The vehicle-side event-triggered data acquisition device includes a processor, a memory, and a vehicle-side event-triggered data acquisition program stored in the memory and executable by the processor, wherein when the vehicle-side event-triggered data acquisition program is executed by the processor, it implements the steps of the vehicle-side event-triggered data acquisition method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a vehicle-side event-triggered data acquisition program, wherein when the vehicle-side event-triggered data acquisition program is executed by a processor, it implements the steps of the vehicle-side event-triggered data acquisition method as described in any one of claims 1 to 7.

Images