Methods, devices, equipment, media, and programs for reinjecting data based on vehicle components.

Abstract

The application provides a vehicle component-based to-be-pumped data pumping method, device, equipment, medium and program product, and relates to the technical field of vehicles.The vehicle component-based to-be-pumped data pumping method comprises the following steps: when to-be-pumped data of a vehicle component is acquired, the wake-up time of a thread corresponding to the data is determined according to the end time of the data; wherein the data has an end time, and the end time is used to indicate the time when the pre-given pumping processing of the data ends; the thread is woken up at the wake-up time; and the data is pumped based on the thread. The application can effectively improve the accuracy of to-be-pumped data of a vehicle component in pumping processing.

Description

Technical Field

[0001] This invention relates to the field of vehicle technology, and specifically to a method, apparatus, equipment, medium, and program product for data reinjection based on vehicle components. Background Technology

[0002] With the development and application of vehicles, it is necessary to perform data recovery testing on vehicle data. This is especially true in intelligent driving technology, where data generated during vehicle operation needs to be recovered and tested. Data recovery testing (i.e., recovery processing) refers to processing vehicle data to simulate and reproduce the vehicle's driving process.

[0003] Therefore, there is an urgent need for a solution that can accurately process vehicle data. Summary of the Invention

[0004] One of the objectives of this invention is to provide a method, apparatus, device, medium, and program product for backfilling data based on vehicle components, in order to solve the problem of low accuracy in backfilling data processing of vehicle components during the simulation and reproduction of vehicle driving.

[0005] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0006] A method for backfeeding data to be backfeeded based on vehicle components includes: upon acquiring backfeeding data of the vehicle components, determining the wake-up time of the thread corresponding to the backfeeding data based on the end time of the backfeeding data; wherein the backfeeding data has an end time, the end time being used to indicate a pre-given time when the backfeeding processing of the backfeeding data to be backfeeded ends; at the wake-up time, waking up the thread; and performing backfeeding processing on the backfeeding data based on the thread.

[0007] Based on the aforementioned technical methods, by accurately calculating the end time of the data to be re-fed and determining the thread wake-up time accordingly, it can be ensured that the data re-fed processing thread is woken up at the optimal time. This avoids the situation where the data to be re-fed is out of sync with the actual data to be re-fed during the data re-fed process, thereby improving the efficiency of data re-fed processing. By precisely controlling the thread wake-up time, it can be ensured that the data to be re-fed is processed at the correct time, thus guaranteeing the accuracy of data re-fed processing.

[0008] Furthermore, based on the end time of the data to be re-fed, the wake-up time of the thread corresponding to the data to be re-fed is determined, including: determining the time indicated by the end time of the data to be re-fed as the wake-up time of the thread corresponding to the data to be re-fed; or, extending the duration indicated by the end time of the data to be re-fed at the current time to obtain the wake-up time of the thread corresponding to the data to be re-fed.

[0009] Furthermore, the data to be re-fed carries data batches in a predefined data format; the wake-up time of the thread corresponding to the data to be re-fed is determined according to the end time of the data to be re-fed, including: for data to be re-fed belonging to the same data batch, the wake-up time of the thread corresponding to the data to be re-fed is determined according to the end time of the data to be re-fed.

[0010] Furthermore, at the wake-up time, waking up the thread includes: determining the call time that invokes the data to be backfetched; determining a wake-up function based on the call time and the wake-up time; and waking up the thread at the wake-up time according to the wake-up function.

[0011] Furthermore, determining the wake-up function based on the invocation time and the wake-up time includes: determining a first time and a second time based on the wake-up time; wherein the first time is less than the wake-up time, and the second time is less than the first time; and determining the wake-up function based on the relationship between the invocation time, the wake-up time, the first time, and the second time.

[0012] Furthermore, based on the relationship between the invocation time, the wake-up time, the first time, and the second time, the wake-up function is determined, including: if the invocation time is determined to be less than the wake-up time and the invocation time is greater than or equal to the first time, a first preset function is determined as the wake-up function; if the invocation time is determined to be less than the first time and the invocation time is greater than or equal to the second time, a second preset function is determined as the wake-up function; if the invocation time is determined to be less than the second time, a third preset function is determined as the wake-up function; wherein, the resource consumption of the first preset function is greater than the resource consumption of the second preset function, and the resource consumption of the second preset function is greater than the resource consumption of the third preset function.

[0013] Furthermore, the data to be recharged is generated by the same functional component of the vehicle; different functional components correspond to different threads.

[0014] Furthermore, the data to be re-injected carries data batches in a predefined data format; the method also includes: if it is determined that the data batch of the data to be re-injected is a continuous value, it is determined that no packet loss of the data to be re-injected has occurred; if it is determined that the data batch of the data to be re-injected is a non-continuous value, it is determined that packet loss of the data to be re-injected has occurred, and the data information of the data to be re-injected that has experienced packet loss is recorded.

[0015] Furthermore, the data to be re-fed has a data item to be re-fed, which is used to indicate the sensitivity of the data to be re-fed; the method further includes: when it is determined that packet loss has occurred in the data to be re-fed, if it is determined that the sensitivity indicated by the data item to be re-fed is greater than or equal to a preset threshold, then the data to be re-fed is discarded; when it is determined that packet loss has occurred in the data to be re-fed, if it is determined that the sensitivity indicated by the data item to be re-fed is less than a preset threshold, then the data to be re-fed in the previous re-fed process is determined to be the data to be re-fed in the current re-fed process.

[0016] Furthermore, before determining the wake-up time of the thread corresponding to the data to be re-fed based on the end time of the data to be re-fed, the method further includes: receiving a wake-up command sent by the main thread; wherein the wake-up command is used to instruct the thread corresponding to the data to be re-fed to be woken up.

[0017] A device for backfeeding data to be backfeeded based on vehicle components, characterized in that it includes: a determining module, used to determine the wake-up time of the thread corresponding to the backfeeding data based on the end time of the backfeeding data when the backfeeding data of the vehicle components is acquired; wherein the backfeeding data has an end time, the end time being used to indicate a pre-given time when the backfeeding processing of the backfeeding data to be backfeeded ends; and a wake-up module, used to wake up the thread at the wake-up time; and perform backfeeding processing on the backfeeding data based on the thread.

[0018] Furthermore, based on the end time of the data to be re-fed, the wake-up time of the thread corresponding to the data to be re-fed is determined. Specifically, the determining module is used to determine the time indicated by the end time of the data to be re-fed as the wake-up time of the thread corresponding to the data to be re-fed; or, at the current time, extend the duration indicated by the end time of the data to be re-fed to obtain the wake-up time of the thread corresponding to the data to be re-fed.

[0019] Furthermore, the data to be re-fed carries data batches in a predefined data format; based on the end time of the data to be re-fed, the wake-up time of the thread corresponding to the data to be re-fed is determined. Specifically, the module is used to determine the wake-up time of the thread corresponding to the data to be re-fed, based on the end time of the data to be re-fed, for data belonging to the same data batch.

[0020] Furthermore, at the wake-up time, the thread is woken up. Specifically, the wake-up module is used to: determine the call time when the data to be backfetched is invoked; determine the wake-up function based on the call time and the wake-up time; and wake up the thread according to the wake-up function at the wake-up time.

[0021] Furthermore, the wake-up module determines the wake-up function based on the call time and the wake-up time. Specifically, the wake-up module is used to determine a first time and a second time based on the wake-up time, wherein the first time is less than the wake-up time and the second time is less than the first time; and to determine the wake-up function based on the relationship between the call time, the wake-up time, the first time, and the second time.

[0022] Furthermore, based on the relationship between the invocation time, the wake-up time, the first time, and the second time, a wake-up function is determined. Specifically, the wake-up module is used to: determine a first preset function as the wake-up function if the invocation time is less than the wake-up time and the invocation time is greater than or equal to the first time; determine a second preset function as the wake-up function if the invocation time is less than the first time and the invocation time is greater than or equal to the second time; and determine a third preset function as the wake-up function if the invocation time is less than the second time. The resource consumption of the first preset function is greater than that of the second preset function, and the resource consumption of the second preset function is greater than that of the third preset function.

[0023] Furthermore, the data to be recharged is generated by the same functional component of the vehicle; different functional components correspond to different threads.

[0024] Furthermore, it also includes a packet loss monitoring module, which is used to determine that no packet loss has occurred when the data batch of the data to be re-uploaded is continuously selected; and to determine that packet loss has occurred when the data batch of the data to be re-uploaded is not continuously selected, and to record the re-uploaded data information of the data to be re-uploaded that has experienced packet loss.

[0025] Furthermore, the data to be re-fed has re-fed data items, which are used to indicate the sensitivity of the data to be re-fed. The packet loss monitoring module is specifically used to: when it is determined that packet loss has occurred in the data to be re-fed, if the sensitivity indicated by the re-fed data item is greater than or equal to a preset threshold, then discard the data to be re-fed; when it is determined that packet loss has occurred in the data to be re-fed, if the sensitivity indicated by the re-fed data item is less than a preset threshold, then determine that the data to be re-fed in the previous re-fed process is the data to be re-fed in the current re-fed process.

[0026] Furthermore, it also includes a receiving device, which is used to receive a wake-up command sent by the main thread; wherein the wake-up command is used to instruct the thread corresponding to the data to be re-fed to be woken up.

[0027] An electronic device includes: a processor, and a memory communicatively connected to the processor;

[0028] The memory stores the instructions that the computer executes;

[0029] The processor executes computer execution instructions stored in memory to implement the motion estimation compensation method as described in the first aspect of the present invention.

[0030] A computer-readable storage medium storing computer program instructions, which, when executed, implement the motion estimation compensation method as described in the first aspect of the present invention.

[0031] A computer program product includes a computer program that, when executed, implements the motion estimation compensation processing method as described in the first aspect of the present invention.

[0032] The beneficial effects of this invention are as follows: The method, apparatus, device, medium, and program product for backfilling data based on vehicle components provided by this invention, when acquiring backfilled data of vehicle components, determines the wake-up time of the thread corresponding to the backfilled data based on the end time of the backfilled data; wherein, the backfilled data has an end time, which is used to indicate a pre-given time when the backfilling processing of the backfilled data ends; at the wake-up time, the thread is woken up; and backfilling processing of the backfilled data is performed based on the thread. By accurately calculating the end time of the backfilled data and determining the wake-up time of the thread accordingly, it can be ensured that the backfilled data processing thread is woken up at the optimal time, avoiding the situation where the backfilled data to be backfilled is out of sync with the actual backfilled data during the backfilling process, thereby improving the efficiency of backfilled data processing. By precisely controlling the wake-up time of threads, it can be ensured that the data to be re-fed is processed at the correct time, thereby guaranteeing the accuracy of the data re-fed processing. This solves the problem of low accuracy in the re-fed data processing of vehicle components during the simulation and reproduction of vehicle driving, and effectively improves the accuracy of the re-fed data processing of vehicle components. Attached Figure Description

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

[0034] Figure 1 This is a schematic diagram illustrating the causes of inconsistencies in traditional reinjection according to an embodiment of the present invention;

[0035] Figure 2 A flowchart illustrating a method for re-feeding back data based on vehicle components according to an embodiment of the present invention;

[0036] Figure 3 A flowchart of a method for re-feeding back data based on vehicle components, provided as another embodiment of the present invention;

[0037] Figure 4 This is a flowchart of the recharge process provided in an embodiment of the present invention;

[0038] Figure 5 This is a schematic diagram of a wake-up function provided in an embodiment of the present invention;

[0039] Figure 6 This is a schematic diagram of the data format to be re-fed according to an embodiment of the present invention;

[0040] Figure 7 This is a schematic diagram illustrating the principle of consistent data reinjection for automobiles according to an embodiment of the present invention.

[0041] Figure 8 This is a schematic diagram illustrating the principle of consistent data reinjection for automobiles according to an embodiment of the present invention.

[0042] Figure 9 This is a schematic diagram of a data reinjection device based on vehicle components provided in an embodiment of the present invention.

[0043] Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0044] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0045] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0046] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and the data to be backfilled (including but not limited to the data to be backfilled for analysis, the data to be backfilled stored, the data to be backfilled displayed, etc.) involved in this invention are all information and data to be backfilled that have been authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data to be backfilled must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0047] A method for re-feeding back data based on vehicle components. With the rapid development of computer science, artificial intelligence, sensor technology, and communication technology, intelligent driving technology is becoming increasingly mature, and more and more intelligent driving algorithms are emerging. Intelligent driving systems require extensive testing to verify their safety and stability. Currently, the main method used by major manufacturers is to collect experimental data for re-feeding back on actual roads, and then conduct multiple re-feeding tests based on this experimental data to reproduce all or part of the test scenarios. Data re-feeding back refers to the process of re-inputting driving data (such as sensor data, vehicle status data, environmental perception data, etc.) collected in the actual road environment back into the intelligent driving system for simulation testing or algorithm verification.

[0048] This technical approach aims to simulate real-world road environments, evaluate the performance of intelligent driving systems, and ensure the stability and safety of the systems before actual deployment. Ensuring the consistency of the data to be fed back during the data feeding process is crucial, as it directly impacts the accuracy and reliability of the verification results.

[0049] However, due to the potential differences in the performance of the domain controller used in the actual vehicle and the bench platform used for data re-feedback, as well as the significant differences in the number of applications running in the actual vehicle mode and the data re-feedback mode, the overall system IO load and CPU usage also differ considerably. These factors can lead to inconsistent output results even when the input data to be re-feedback and the algorithm to be tested are the same, making it difficult to reproduce actual vehicle faults and resulting in unstable results from multiple re-feedback tests.

[0050] To address the aforementioned issues, this invention provides a method for backfeeding data based on vehicle components. In the field of vehicle technology, it provides a method for ensuring consistency in backfeeding data, maintaining consistent output results when the input backfeeding data and the algorithm to be tested are the same. This solves the problems of difficulty in reproducing real vehicle faults, instability in multiple backfeeding test results, and consequently, debugging difficulties.

[0051] Traditional data refeeding first involves collecting all published information (topic name, timestamp, and metadata) from the actual vehicle. Then, the local publishing application is shut down, while the subscription application remains unchanged. The refeeding data collected from the actual vehicle (meta metadata from all publishers) is preprocessed, and finally, the refeeding data is published again according to the frequency of the meta metadata recorded in the refeeding data to simulate the actual vehicle's publishing application. This method only guarantees that the refeeding data and frequency on the publishing side are consistent with the actual vehicle in refeeding mode. However, it does not guarantee the refeeding data obtained by the subscription side. If the subscription side experiences periodic fluctuations during actual vehicle operation, while it operates with a stable period in refeeding mode, the refeeding data obtained by the subscription side will differ, leading to inconsistencies in the refeeding data. Figure 1 As shown, Figure 1 This is a schematic diagram illustrating the cause of inconsistencies in traditional backfeeding provided by an embodiment of the present invention. During actual vehicle operation, the recv component should run according to a 20ms cycle, but due to system IO load, CPU scheduling, and other reasons, a delay occurs in the third cycle, causing the running time to become 40ms (this is just an assumption, sufficient to illustrate the problem). In reality, the delay may be longer, even reaching several hundred milliseconds. Traditional data refeeding first involves collecting all published information (topic name, timestamp, and metadata) from the actual vehicle. Then, the local publishing application is shut down, while the subscription application remains unchanged. The refeeding data collected from the actual vehicle (meta metadata from all publishers) is preprocessed, and finally, the refeeding data is published again according to the frequency of the meta metadata in the recorded refeeding data to simulate the actual vehicle publishing application. Because only part of the application is started during data refeeding, the system IO load is low. The recv component runs stably at a 20ms cycle, which can lead to situations where the actual vehicle does not obtain the refeeding data for the fourth cycle, but does obtain it during the refeeding process. This results in the refeeding data failing to accurately reproduce the actual vehicle test scenario, affecting the accuracy and reliability of the verification results.

[0052] The technical solution of the present invention will now be described in detail through specific embodiments. It should be noted that the following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0053] Figure 2 This is a flowchart illustrating a method for data reinjection based on vehicle components according to an embodiment of the present invention. This motion estimation compensation method can be executed by software and / or hardware devices. For example, the hardware device can be a data reinjection device for vehicle components, which can be an electronic device or a processing chip within an electronic device. Figure 2 As shown, the method of this embodiment of the invention includes:

[0054] S201. When the data to be recharged for the vehicle component is obtained, the wake-up time of the thread corresponding to the data to be recharged is determined according to the end time of the data to be recharged; wherein, the data to be recharged has an end time, and the end time is used to indicate the time when the recharge processing of the data to be recharged ends, which is given in advance.

[0055] For example, when the vehicle-generated data to be recharged is collected and transmitted to the data recharge processing system, each data item to be recharged is accompanied by an end time. That is, the end time of the data to be recharged from the actual vehicle equipment, and thus this end time indicates when the data recharge processing should be completed.

[0056] Based on the end time of the data to be re-fed, the system calculates when the thread should be woken up to begin processing the data. For example, if the end time of the data to be re-fed is 20ms from now, then the thread will be woken up after 20ms. At the preset wake-up time, the thread is activated and begins execution. At this time, the thread will load the corresponding data to be re-fed and perform the re-fed processing.

[0057] S202. At the wake-up time, wake up the thread; and perform backfilling processing on the data to be backfilled based on the thread.

[0058] For example, during the collection of data to be fed back, the system sets a timer based on the end time of the data to be fed back. This timer is used to trigger the thread at a specified wake-up time. The accuracy and reliability of the timer are critical, and it is necessary to ensure that the thread can be accurately woken up at the correct time. When the preset wake-up time is reached, the timer triggers an event, which is responsible for waking up the corresponding feedback thread.

[0059] This embodiment determines the wake-up time of the thread corresponding to the data to be re-fed when the data to be re-fed is acquired, based on the end time of the data to be re-fed. The data to be re-fed has an end time, which indicates a pre-defined time when the re-fed processing of the data to be re-fed will end. At the wake-up time, the thread is woken up, and the data to be re-fed is processed based on the thread. In other words, by accurately calculating the end time of the data to be re-fed and determining the thread wake-up time accordingly, it is ensured that the data re-fed processing thread is woken up at the optimal time, avoiding the situation where the data to be re-fed is out of sync with the actual data to be re-fed, thereby improving the efficiency of the data re-fed processing. By precisely controlling the thread wake-up time, it is ensured that the data to be re-fed is processed at the correct time, thus guaranteeing the accuracy of the data re-fed processing. This solves the problem of low accuracy in the re-fed processing of vehicle component data during the simulation of vehicle driving, effectively improving the accuracy of the data re-fed processing of vehicle component data.

[0060] Figure 3 This is a flowchart illustrating a method for data reinjection based on vehicle components, provided in another embodiment of the present invention. Based on the above embodiments, this embodiment further describes the method for data reinjection based on vehicle components. Figure 3 As shown, the method in this embodiment of the invention may include:

[0061] S301. When the data to be re-fed for the vehicle component is obtained, the wake-up time of the thread corresponding to the data to be re-fed is determined according to the end time of the data to be re-fed; wherein the data to be re-fed has an end time, the end time is used to indicate the time when the re-fed processing of the data to be re-fed is completed in advance; at the wake-up time, the thread is woken up; and the re-fed processing of the data to be re-fed is performed based on the thread.

[0062] In one example, the time indicated by the end time of the data to be re-fed is determined as the wake-up time of the thread corresponding to the data to be re-fed; or, the duration indicated by the end time of the data to be re-fed is extended at the current time to obtain the wake-up time of the thread corresponding to the data to be re-fed.

[0063] In the context of vehicle data backfeeding, determining the thread wake-up time is a crucial step, ensuring that the backfeeding data processing proceeds according to the predetermined plan. The following example illustrates how to determine the thread wake-up time as indicated by the end time of the backfeeding data, and how to extend the end time of the backfeeding data from the current time to obtain the thread wake-up time.

[0064] Example 1: Vehicle component A completed a trip at 10:00 AM and uploaded a data package to be re-fed. The end time of the data package was marked as 10:00 AM. The system sets the end time (10:00 AM) of the data package to be re-fed for vehicle component A as the wake-up time for its thread. The system sets a timer to ensure that the thread processing the data package to be re-fed for vehicle component A is woken up at 10:00 AM. At 10:00 AM, the thread is woken up and begins processing the data package to be re-fed for vehicle component A.

[0065] Example 2: Vehicle component A completed a trip at 2:00 PM and uploaded the data packet to be re-fed. The end time of the data packet to be re-fed is marked as 2:00 PM. Determining the wake-up time: Considering that processing the data packet to be re-fed may take some time, the system decides to start processing the data packet to be re-fed 15 minutes after the data collection ends. Therefore, the system's end time is extended from 2:00 PM to 2:15 PM, and this new time is set as the thread's wake-up time. Thread scheduling: The system sets a timer to ensure that the thread processing the data packet to be re-fed for vehicle component A is woken up at 2:15 PM. Data packet processing: At 2:15 PM, the thread is woken up and begins processing the data packet to be re-fed for vehicle B.

[0066] In one example, for data to be re-fed that belongs to the same data batch, the wake-up time of the thread corresponding to the data to be re-fed is determined based on the end time of the data to be re-fed.

[0067] Vehicle components a, b, and c uploaded their data to be re-fed to the system within the same time period. This data was marked as belonging to the same batch. Assume the end time of this batch is set to 3:00 PM. The system sets the thread wake-up time based on the batch end time (3:00 PM). This means that whenever the data to be re-fed actually arrives, as long as it belongs to the same batch, its processing will begin at 3:00 PM. The system sets a timer to ensure that the thread dedicated to processing this batch of data is woken up at 3:00 PM. This thread will be responsible for processing all data marked as belonging to this batch. Data processing: At 3:00 PM, the thread is woken up and begins processing the data to be re-fed for vehicle components a, b, and c. By centrally processing data uploaded within the same time period, the frequency of thread wake-ups and context switching can be reduced, thereby improving processing efficiency. This approach is particularly suitable for scenarios with large amounts of data to be re-fed and relatively fixed processing times. Processing the same batch of data to be re-injected at the same time helps maintain the processing order and consistency of the data, especially when there are dependencies between the data to be re-injected.

[0068] S302. Determine the call time when the data to be re-fed is invoked; determine the wake-up function based on the call time and the wake-up time; and wake up the thread according to the wake-up function at the wake-up time, and perform re-fed processing on the data to be re-fed based on the thread.

[0069] It should be noted that the accuracy and reliability of the wake-up are crucial. Only by ensuring that the thread is woken up accurately at the right time can the occurrence of errors during the backfeeding process be minimized.

[0070] Optionally, to reduce function execution cycle fluctuations caused by factors such as CPU scheduling during the backfeedback process, the scheduling strategy for each thread is set to FIFO (First In First Out), the priority is set to 99, and core binding (binding the thread to a fixed CPU core) is performed. For example... Figure 4 As shown, Figure 4 This is a flowchart of the recharge process provided in an embodiment of the present invention.

[0071] First, add breakpoints and collect function information: Before processing the data, breakpoints need to be added and function information collected. This helps to understand the structure and characteristics of the data, providing a reference for subsequent processing. Next, determine if it's the last thread: Check if the currently processing thread is the last one. If so, proceed directly to the next step; otherwise, continue processing other threads. Then, collect data from the actual vehicle: Acquire relevant data using a vehicle data acquisition device. This data may include vehicle trajectory, speed, and other information, providing foundational data for subsequent analysis. After collecting the data from the actual vehicle, it needs to be parsed and stored: Parse the collected data, convert it into a processable form, and store it in an appropriate location for later use. Further, create threads, set priorities and bind cores based on the parsed and stored data, and prepare the data. This means creating multiple threads to process the data in parallel as needed, and setting priorities for each thread. Simultaneously, the relevant data needs to be bound to specific cores so that the data can be correctly accessed and used when executing functions. Finally, block the main thread: In some cases, it may be necessary to temporarily stop the main thread to avoid interfering with or affecting the execution of other threads. This can be achieved by blocking the main thread. Main thread wake-up from block: When the main thread is blocked, it needs to wait for specific conditions to be met before it can continue execution. Once the conditions are met, the main thread can be woken up and its running state resumed by calling the corresponding function. Execution function: After the conditions are met, the main thread will be woken up and begin executing the relevant functions. These functions may include data analysis, result output, etc., aiming to extract useful information from the collected data and perform further processing. Setting wake-up time: To ensure that the main thread can be woken up and begin executing tasks within an appropriate time, a wake-up time can be set. This avoids resource waste or inefficiency caused by long waiting times. Waking up the main thread: When the preset wake-up time is reached, the system will automatically call the corresponding function to wake up the main thread and begin executing tasks. This ensures that the main thread can respond to external events or requests in a timely manner, improving the system's response speed and reliability.

[0072] It's important to note that after a thread is created, it blocks, waiting for the main thread to wake up all other threads. All threads then execute simultaneously, ensuring synchronization. If a thread is the last to execute, it notifies the main thread and then blocks. Once the main thread is woken up, all threads continue execution simultaneously. This design primarily ensures thread synchronization. This step is crucial in multi-threaded interactions. If threads are not synchronized, the data they obtain from each other will be random, entirely dependent on which thread executes first, severely impacting the final output consistency.

[0073] In one example, a first time and a second time are determined based on the wake-up time; wherein the first time is less than the wake-up time, and the second time is less than the first time; and a wake-up function is determined based on the relationship between the call time, the wake-up time, the first time, and the second time.

[0074] In one example, if it is determined that the call time is less than the wake-up time and the call time is greater than or equal to the first time, a first preset function is determined as the wake-up function; if it is determined that the call time is less than the first time and the call time is greater than or equal to the second time, a second preset function is determined as the wake-up function; if it is determined that the call time is less than the second time, a third preset function is determined as the wake-up function; wherein, the resource consumption of the first preset function is greater than the resource consumption of the second preset function, and the resource consumption of the second preset function is greater than the resource consumption of the third preset function.

[0075] It's important to note that when the call time is less than the wake-up time, it means the data to be re-fed needs to be ready before the wake-up time. In this case, the system will select the first preset function as the wake-up function. Although this function consumes the most resources, it ensures that the data to be re-fed is processed in the earliest possible time, making it suitable for scenarios with extremely high timeliness requirements.

[0076] If the call time is less than the first time but greater than or equal to the second time, the second preset function is selected as the wake-up function. This means that before the first time, but close to or reaching the second time, the system will select a function with moderate resource consumption to execute.

[0077] If the call time is less than the second time, the third preset function is selected as the wake-up function. This means that before the second time, the system will select the function with the least resource consumption to execute.

[0078] When the call time is greater than the first time but less than the second time: This means the data to be backfetched can be processed at a later time, but still needs to be completed before the second time. In this case, the system will select the third preset function as the wake-up function. This function consumes the least resources and is suitable for scenarios that have some flexibility in processing time but still need to ensure efficiency.

[0079] In other words, based on the relationship between the current time point (call time) and the predetermined time points (wake-up time, first time point, and second time point), an appropriate function is dynamically selected for execution to optimize resource utilization. By selecting appropriate functions to execute at different time points, the overall resource utilization efficiency is optimized.

[0080] In an optional embodiment, if the `Sleep_until` function (sleep until a specified time) is used as the wake-up function, the error is small when the call time is far from the set wake-up time (a few milliseconds); the error is large when the call time is relatively close to the set wake-up time (hundreds of microseconds); and the error is large when the call time is very close to the set wake-up time (a few microseconds). The main reason for this phenomenon is that system calls involve switching between kernel mode and user mode. This switching process causes instability in time consumption. Figure 5 As shown, Figure 5 This is a schematic diagram of a wake-up function provided in an embodiment of the present invention.

[0081] Therefore, Sleep_until is customized. First, the far time (equivalent to the second time step) and the near time (equivalent to the first time step) are defined. If the call time is less than the far time step, the futex system call (equivalent to the third preset function) is called. If the call time step is less than the near time step, the sleep_until system call (equivalent to the second preset function) is called. If the call time step is less than the wake-up time step, the call is repeated in a loop, and the CPU is yielded (equivalent to the first preset function) in the loop body.

[0082] The pseudocode is as follows:

[0083] Step 1: First, through extensive testing, determine the time required for wake-up from the futex system call timeout and the time required for wake-up from the sleep_until system call timeout on the corresponding platform.

[0084] Step 2: Set the remote time to equal the wake-up time minus the time required for the futex system call timeout to wake up.

[0085] Step 3: Set the near-end time to equal the wake-up time minus the time required to wake up after the sleep_until system call timeout.

[0086] Step 4: Get the current time and assign it to now.

[0087] Step 5: If the current time is less than the remote time, execute the futex(FUTEX_WAIT) system call, wake up the device, and then retrieve the current time again and assign it to now.

[0088] Step 6: If the current time is greater than the remote time but less than the near time, execute the sleep_until system call, wake up, and then retrieve the current time again and assign it to now.

[0089] Step 7: If the current time is greater than the near-end time but less than the set wake-up time, execute the while loop. In the loop body, yield the CPU and retrieve the current time again and assign it to now.

[0090] This design can effectively reduce time errors caused by switching between kernel mode and user mode, and more accurately guarantee the time flow.

[0091] Furthermore, in the solution provided in this embodiment, the data to be recharged is the data to be recharged generated by the same functional component of the vehicle; different functional components correspond to different threads.

[0092] Based on the above embodiments, optionally, the method for backfilling data based on vehicle components provided in this embodiment of the invention further includes: if it is determined that the data batch of the data to be backfilled is continuously selected, it is determined that no packet loss of the data to be backfilled has occurred; if it is determined that the data batch of the data to be backfilled is not continuously selected, it is determined that packet loss of the data to be backfilled has occurred, and the backfilling data information of the data to be backfilled that has experienced packet loss is recorded.

[0093] It should be noted that the data to be re-fed includes at least one of the following: data batch, start time, end time, and processing method of the data to be re-fed. The processing method of the data to be re-fed includes: discarding the data to be re-fed, and inheriting the data to be re-fed from the previous re-fed (using the data to be re-fed from the previous re-fed as the data to be re-fed in the current re-fed).

[0094] In a vehicle data reinjection system, the integrity and continuity of the data to be reinjected are crucial. To ensure no data loss, the system needs to monitor data batches. Consecutive data batches mean that each batch arrives in the expected order, without any gaps or omissions. The system checks the batch number to ensure they are consecutive. For example, if the batch numbers are from 1 to 10, the system confirms that these numbers are consecutive and no numbers are skipped. Consecutive data batches indicate that no packet loss occurred during the data transmission, ensuring the integrity of the reinjected data.

[0095] When data batches are discontinuous, it means there are gaps or missing batch numbers. The system checks the batch numbers; if it finds jumps or gaps, it determines that data loss has occurred. For example, if the batch numbers go from 1 to 5 and then jump directly to 7, it can be inferred that batch 6 is missing. Once data loss is detected, the system records information about the lost data, including the batch number and timestamp. This helps with subsequent data recovery or error analysis.

[0096] In one example, when it is determined that packet loss has occurred in the data to be re-fed, if the sensitivity indicated by the data item to be re-fed is greater than or equal to a preset threshold, the data to be re-fed is discarded; if it is determined that packet loss has occurred in the data to be re-fed, if the sensitivity indicated by the data item to be re-fed is less than a preset threshold, the data to be re-fed in the previous re-fed process is determined to be the data to be re-fed in the current re-fed process.

[0097] In other words, for data items that experience packet loss during the re-feedback process, their sensitivity needs to be determined, i.e., the importance of the data or its impact on the re-feedback results. If the sensitivity of a data item is greater than or equal to a preset threshold, it indicates that this data has a significant impact on the re-feedback results. To prevent error propagation or system instability, the system will discard this portion of the data. For data with a sensitivity below the threshold, a fault-tolerance mechanism can be used, which involves using the data from the previous successfully re-feedback process as the data for the current re-feedback process. This method can reduce the impact of lost data on the system while maintaining the continuity of the re-feedback data. The strategy for handling packet loss during the re-feedback process depends on the sensitivity of the data and the stability requirements. By setting a reasonable sensitivity threshold, the impact of data loss can be minimized while ensuring the quality of the re-feedback data.

[0098] Optionally, in the event of packet loss, a loop can be performed first to determine whether there is any data loss in the current cycle. If so, the current execution cycle is skipped; otherwise, the data to be re-uploaded is obtained and sent normally.

[0099] In one example, a wake-up command sent by the main thread is received; wherein the wake-up command is used to instruct the thread corresponding to the data to be re-fed to be woken up.

[0100] Furthermore, in the solution provided in this embodiment, the data to be reinjected can be in a custom format, such as... Figure 6 As shown, Figure 6 This is a schematic diagram of the data format to be re-fed according to an embodiment of the present invention.

[0101] Optionally, the data format for data to be re-injected in this invention is .dat, which is divided into four main parts: file header, file data to be re-injected, data header to be re-injected, and meta data to be re-injected. The file header contains four fields: version, proto data size to be re-injected, comment information size, and reserved. This part can indicate the protocol used by the current data to be re-injected and provide valid information about the data to be re-injected (e.g., when, where, who, and in what scenario the data to be re-injected is). The data header to be re-injected contains four fields: meta data name to be re-injected, meta data size to be re-injected, timestamp, and metadata batch number. This part provides valid information about the data to be re-injected sent by the publishing end (what data to be re-injected, data size to be re-injected, time, and which frame the data to be re-injected is).

[0102] Not only does it contain all the necessary information, but the metadata batch number field can effectively verify whether the recorded data to be re-uploaded is continuous and whether there is any packet loss. When re-uploading the data later, the corresponding metadata data to be re-uploaded can be quickly retrieved using the metadata data name and batch number in the summary information. Furthermore, since the amount of data to be re-uploaded in intelligent driving systems is very large, this design can also reduce the size of the recorded data to be re-uploaded, thus reducing disk I / O or cloud storage requirements.

[0103] Optionally, the aforementioned data to be re-injected, metadata batch number, etc., can all be included in the summary information. In the re-injection mode, by reading all the information in the summary information, the required data to be re-injected can be prepared in advance to ensure the consistency of the data to be re-injected.

[0104] In addition, the summary information may also include breakpoint information, such as... Figure 7 As shown, Figure 7 This is a schematic diagram of function summary information provided in an embodiment of the present invention.

[0105] The function summary information includes the start and end times of each thread's callback function execution, as well as all subscription information (name of metadata to be fed back, number of metadata batches) and internal time breakpoints within the function's execution cycle.

[0106] It should be noted that the function summary information can be applied not only to periodic callback functions during the backfeeding process but also to event callback functions. When applied to event callback functions, the summary information can also include additional information carried by the event callback function itself. Therefore, when problems occur in event callback functions, viewing the function summary information can quickly identify the root cause of the problem, thereby accelerating the debugging process.

[0107] Function summary information is recorded in the data file to be re-fed, with each function execution cycle (from the start to the end of execution) as a unit. This function summary information is crucial, as all subsequent data re-fing is based on it. By using the metadata name and batch number recorded in the summary information, the data to be re-fed that the subscriber will actually obtain on the actual vehicle can be prepared in advance. At the same time, the data re-fing is based on the recorded function execution start time, internal breakpoint time, and execution end time, which can maximize the restoration of the execution flow of the function on the actual vehicle (function execution start time - internal breakpoint time - function execution end time - function execution start time - internal breakpoint time - function execution end time... and so on).

[0108] For ease of use, a macro function is defined. To use it, simply add the macro function before the callback function. The macro function will create an object of the summary information collection class and automatically record the function execution start time, function execution end time, the data information to be fed back by the subscriber, and time breakpoint information after the callback function is executed.

[0109] The above method solves the problem of low accuracy in processing vehicle component data during simulation of vehicle driving, achieving consistent data reprocessing for vehicle components. Figure 8 As shown, Figure 8 This is a schematic diagram illustrating the principle of consistent data recharge for automobiles, provided in an embodiment of the present invention.

[0110] During actual vehicle operation, the recv component should have run at a 20ms cycle. However, due to factors such as system IO load and CPU scheduling, a delay occurred in the third cycle, causing the running time to become 40ms. The subscriber lost the data to be fed back sent by the publisher in the fourth cycle. In the feedback mode, based on the summary information, the data to be fed back (1, 2, 3, 5, 6...) is prepared in advance and the execution function is scheduled according to the timeline of 0-20, 20-40, 40-80, 80-100... The final data to be fed back is consistent with the actual vehicle data.

[0111] The following are embodiments of the apparatus of the present invention, which can be used to execute embodiments of the method of the present invention. For details not disclosed in the embodiments of the apparatus of the present invention, please refer to the embodiments of the method of the present invention.

[0112] Figure 9 This is a schematic diagram of a data reinjection device based on vehicle components according to an embodiment of the present invention, as shown below. Figure 9 As shown, the diagnostic processing device for vehicle Ethernet-based data to be re-fed in this embodiment of the invention includes: a determination module 901 and a wake-up module 902. Wherein:

[0113] The determining module 901 is used to determine the wake-up time of the thread corresponding to the data to be re-fed when the data to be re-fed of the vehicle component is acquired, based on the end time of the data to be re-fed; wherein the data to be re-fed has an end time, and the end time is used to indicate the time when the re-fed processing of the data to be re-fed is completed in advance.

[0114] The wake-up module 902 is used to wake up the thread at the wake-up time and perform backfilling processing on the data to be backfilled based on the thread.

[0115] Furthermore, based on the end time of the data to be re-fed, the wake-up time of the thread corresponding to the data to be re-fed is determined. Specifically, the determining module 901 is used to determine the time indicated by the end time of the data to be re-fed as the wake-up time of the thread corresponding to the data to be re-fed; or, at the current time, extend the duration indicated by the end time of the data to be re-fed to obtain the wake-up time of the thread corresponding to the data to be re-fed.

[0116] Furthermore, the data to be re-fed carries data batches in a predefined data format; based on the end time of the data to be re-fed, the wake-up time of the thread corresponding to the data to be re-fed is determined. Specifically, the determining module 901 is used to determine the wake-up time of the thread corresponding to the data to be re-fed, based on the end time of the data to be re-fed, for data belonging to the same data batch.

[0117] Furthermore, at the wake-up time, the thread is woken up. Specifically, the wake-up module 902 is used to: determine the call time when the data to be backfetched is invoked; determine the wake-up function based on the call time and the wake-up time; and wake up the thread at the wake-up time according to the wake-up function.

[0118] Furthermore, the wake-up module determines the wake-up function based on the call time and the wake-up time. Specifically, the wake-up module 902 is used to determine a first time and a second time based on the wake-up time, wherein the first time is less than the wake-up time and the second time is less than the first time; and to determine the wake-up function based on the relationship between the call time, the wake-up time, the first time, and the second time.

[0119] Furthermore, based on the relationship between the invocation time, the wake-up time, the first time, and the second time, a wake-up function is determined. The wake-up module 902 is specifically configured to: if it is determined that the invocation time is less than the wake-up time and the invocation time is greater than or equal to the first time, determine a first preset function as the wake-up function; if it is determined that the invocation time is less than the first time and the invocation time is greater than or equal to the second time, determine a second preset function as the wake-up function; if it is determined that the invocation time is less than the second time, determine a third preset function as the wake-up function; wherein, the resource consumption of the first preset function is greater than the resource consumption of the second preset function, and the resource consumption of the second preset function is greater than the resource consumption of the third preset function.

[0120] Furthermore, it also includes a packet loss monitoring module (not shown in the figure), which is used to determine that no packet loss of the data to be re-uploaded has occurred if the data batch of the data to be re-uploaded is determined to be continuous; and to determine that packet loss of the data to be re-uploaded has occurred if the data batch of the data to be re-uploaded is determined to be non-continuous, and to record the data information of the data to be re-uploaded that has experienced packet loss.

[0121] Furthermore, the data to be re-fed has re-fed data items, which are used to indicate the sensitivity of the data to be re-fed. The packet loss monitoring module (not shown in the figure) is specifically used to: when it is determined that packet loss has occurred in the data to be re-fed, if the sensitivity indicated by the re-fed data item is greater than or equal to a preset threshold, then discard the data to be re-fed; when it is determined that packet loss has occurred in the data to be re-fed, if the sensitivity indicated by the re-fed data item is less than the preset threshold, then determine that the data to be re-fed in the previous re-fed process is the data to be re-fed in the current re-fed process.

[0122] Furthermore, it also includes a receiving device (not shown in the figure), which is used to receive a wake-up command sent by the main thread; wherein the wake-up command is used to instruct the thread corresponding to the data to be re-fed to be woken up.

[0123] Figure 10 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of the present invention. Figure 10 As shown, the electronic device 1000 may include at least one processor 1001 and a memory 1002.

[0124] The memory 1002 is used to store programs. Specifically, the program may include program code, which includes computer-executable instructions.

[0125] The memory 1002 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device.

[0126] The processor 1001 executes computer execution instructions stored in the memory 502 to implement the file high-load environment construction method or the vehicle system testing method described in the foregoing method embodiments. The processor 501 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present invention. Specifically, when implementing the file high-load environment construction method described in the foregoing method embodiments, the electronic device may be, for example, a server or other electronic device with processing capabilities; when implementing the vehicle system testing method described in the foregoing method embodiments, the electronic device may be, for example, an electronic control unit in a vehicle or other electronic device with processing capabilities.

[0127] Optionally, the electronic device 1000 may also include a communication interface 1003. In specific implementations, if the communication interface 1003, memory 1002, and processor 1001 are implemented independently, they can be interconnected via a bus to complete communication. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses to be fed back, control buses, etc., but this does not imply that there is only one bus or one type of bus.

[0128] Optionally, in a specific implementation, if the communication interface 1003, memory 1002 and processor 1001 are integrated on a single chip, then the communication interface 1003, memory 1002 and processor 1001 can communicate through an internal interface.

[0129] The present invention also provides a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the above-described method for constructing a high-load file environment or a method for testing an in-vehicle system.

[0130] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method for constructing a high-load file environment or a method for testing an in-vehicle system.

[0131] The aforementioned computer-readable storage medium can be implemented from any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read Only Memory (PROM), Read Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0132] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an application-specific integrated circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in a file-intensive environment construction apparatus or a test apparatus for an in-vehicle system.

[0133] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0134] Finally, it should be noted that the above embodiments are merely preferred embodiments provided to fully illustrate the present invention, and the scope of protection of the present invention is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on the present invention are all within the scope of protection of the present invention.

[0135] The above embodiments are merely preferred embodiments provided to fully illustrate the present invention, and the scope of protection of the present invention is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on the present invention are all within the scope of protection of the present invention.

Claims

1. A method of vehicle component based data priming, the method comprising: The method comprises the following steps: When the to-be-refill data of the vehicle component is acquired, the wake-up time of the thread corresponding to the to-be-refill data is determined according to the end time of the to-be-refill data; wherein the to-be-refill data has an end time, and the end time is used to indicate the time when the pre-given refill processing of the to-be-refill data ends; At the wake-up time, the thread is woken up, and the to-be-refill data is processed based on the thread.

2. The method of claim 1, wherein, The wake-up time of the thread corresponding to the to-be-refill data is determined according to the end time of the to-be-refill data, which comprises the following steps: The time indicated by the end time of the to-be-refill data is determined as the wake-up time of the thread corresponding to the to-be-refill data; Or, the time length indicated by the end time of the to-be-refill data is extended at the current time to obtain the wake-up time of the thread corresponding to the to-be-refill data.

3. The method of claim 1, wherein, The to-be-refill data carries a data batch through a pre-defined data format; The wake-up time of the thread corresponding to the to-be-refill data is determined according to the end time of the to-be-refill data, which comprises the following steps: For the to-be-refill data belonging to the same data batch, the wake-up time of the thread corresponding to the to-be-refill data is determined according to the end time of the to-be-refill data.

4. The method of claim 1, wherein, At the wake-up time, the thread is woken up, which comprises the following steps: The calling time of the to-be-refill data is determined; According to the calling time and the wake-up time, the wake-up function is determined; and at the wake-up time, the thread is woken up according to the wake-up function.

5. The method of claim 4, wherein, The wake-up function is determined according to the calling time and the wake-up time, which comprises the following steps: According to the wake-up time, the first time and the second time are determined; wherein the first time is less than the wake-up time, and the second time is less than the first time; According to the relationship among the calling time, the wake-up time, the first time and the second time, the wake-up function is determined.

6. The method of claim 5, wherein, According to the relationship among the calling time, the wake-up time, the first time and the second time, the wake-up function is determined, which comprises the following steps: if it is determined that the calling time is less than the wake-up time, and the calling time is greater than or equal to the first time, a first preset function is determined as the wake-up function; If it is determined that the calling time is less than the first time, and the calling time is greater than or equal to the second time, a second preset function is determined as the wake-up function; If it is determined that the calling time is less than the second time, a third preset function is determined as the wake-up function; Wherein, the resource amount consumed by the first preset function is greater than the resource amount consumed by the second preset function, and the resource amount consumed by the second preset function is greater than the resource amount consumed by the third preset function.

7. The method of claim 1, wherein, The to-be-refill data is the to-be-refill data generated by the same functional component of the vehicle; different functional components correspond to different threads.

8. The method according to any one of claims 1-7, characterized in that, The to-be-refill data carries a data batch through a pre-defined data format; the method further comprises the following steps: If it is determined that the data batch of the to-be-refill data is continuously valued, it is determined that the to-be-refill data packet loss phenomenon has not occurred; If it is determined that the data batch of the to-be-injected data is not continuous, it is determined that the to-be-injected data packet loss phenomenon occurs, and to-be-injected data information of the to-be-injected data in which the to-be-injected data packet loss phenomenon occurs is recorded.

9. The method of claim 8, wherein, The to-be-injected data has a to-be-injected data item, and the to-be-injected data item is used to indicate the sensitivity of the to-be-injected data; the method further comprises: When it is determined that the to-be-injected data packet loss phenomenon occurs, if it is determined that the sensitivity indicated by the to-be-injected data item of the to-be-injected data is greater than or equal to a preset threshold, the to-be-injected data is discarded, wherein the sensitivity is positively correlated with the influence degree of the to-be-injected data item on the injection result; When it is determined that the to-be-injected data packet loss phenomenon occurs, if it is determined that the sensitivity indicated by the to-be-injected data item of the to-be-injected data is less than a preset threshold, the to-be-injected data of the last injection processing is determined as the to-be-injected data of the current injection processing.

10. The method according to any one of claims 1-7, characterized in that, Before the wake-up time of the thread corresponding to the to-be-injected data is determined according to the end time of the to-be-injected data, further comprising: Receiving a wake-up instruction sent by a main thread; wherein the wake-up instruction is used to indicate to wake up the thread corresponding to the to-be-injected data.

11. A vehicle component based data priming device for priming data, characterized in that, Comprising: A determination module, configured to, when the to-be-injected data of the vehicle component is acquired, determine the wake-up time of the thread corresponding to the to-be-injected data according to the end time of the to-be-injected data; wherein the to-be-injected data has an end time, and the end time is used to indicate the time when the pre-given injection processing of the to-be-injected data ends; A wake-up module, configured to, at the wake-up time, wake up the thread, and perform injection processing on the to-be-injected data based on the thread.

12. An electronic device, comprising: Comprising: A processor, and a memory in communication connection with the processor; The memory stores computer execution instructions; The processor executes the computer execution instructions stored in the memory, so that the processor executes the method in any one of claims 1-10.

13. A computer program product comprising a computer program, characterized in that, The computer program is executed to implement the method in any one of claims 1 to 10.

14. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer program instructions, and the computer program instructions are executed to implement the method in any one of claims 1 to 10.

Images