A method, apparatus, electronic device, and storage medium for storing vehicle data.

Abstract

This application relates to the field of data storage, and discloses a method, apparatus, electronic device, and storage medium for storing vehicle data. The storage method includes: retrieving multiple types of data from cache areas in multiple storage queues; wherein different storage queues store different data types, and the storage queues stop caching data when there is no free cache area; parsing the multiple types of data based on their respective parsing strategies to obtain descriptive information of each type of data and the parsed data; the parsing strategy is a strategy for parsing corresponding types of data into storage data in a preset type file; determining the storage area of ​​each type of data in the preset type file based on the descriptive information of each type of data, storing the parsed data in its respective corresponding storage area, and storing the descriptive information of each type of data in another area of ​​the preset type file. This application achieves ordered coexistence and efficient retrieval of different types of data in a single file.

Description

Technical Field

[0001] This application relates to the field of data storage, specifically to a method, apparatus, electronic device, and storage medium for storing vehicle data. Background Technology

[0002] Vehicle data includes communication data from the Controller Area Network (CAN), Local Interconnect Network (LIN), Service-Oriented Architecture (SOA) middleware, and internal signals from the Microcontroller Unit (MCU). The relevant technology involves packaging CAN / LIN data through the area controller and transmitting it via Ethernet to the central controller for processing and storage.

[0003] However, due to the bottleneck of the central controller's short-term processing capacity, it is difficult to simultaneously receive and process high-concurrency data streams from multiple communication buses and systems, resulting in the loss of relevant data. At the same time, because the formats of multi-source vehicle data (i.e., different types of data) are different, they cannot be integrated and managed, and they need to be classified and stored, resulting in scattered storage data. Summary of the Invention

[0004] In view of the above problems, this application provides a method, apparatus, electronic device and storage medium for storing vehicle data, which can solve the problems of limited short-term data processing capabilities, data loss due to inconsistent formats of multi-source vehicle data and scattered data storage.

[0005] According to one aspect of this application, a method for storing vehicle data is provided. The method includes: obtaining multiple types of data from caches in multiple storage queues; wherein different storage queues store different data types, and the storage queues stop caching data when there are no free caches; parsing the multiple types of data based on a parsing strategy corresponding to each type of data to obtain descriptive information of each type of data and the parsed data; the parsing strategy is a strategy for parsing corresponding types of data into storage data in a preset type file; determining the storage area of ​​each type of data in the preset type file based on the descriptive information of each type of data, storing the parsed data in its corresponding storage area, and storing the descriptive information of each type of data in another area of ​​the preset type file.

[0006] In one optional approach, the storage method further includes: determining a data collection list based on the vehicle's operating condition type, and collecting various types of data based on the data collection list; if there is an idle buffer in the storage queue corresponding to the collected data of the corresponding type, then storing the data of the corresponding type in the corresponding storage queue; if there is no idle buffer in the storage queue corresponding to the collected data of the corresponding type, then performing packet loss processing on the data of the corresponding type.

[0007] In one optional approach, the storage method further includes: traversing each cache area in the storage queue corresponding to the various types of collected data, and detecting whether the data in the traversed cache area has been parsed and transferred; if all are yes, then determining that the traversed cache area is the free cache area, thereby identifying the free cache area in the storage queue corresponding to the various types of data.

[0008] In one optional approach, the description information corresponds to a data group identifier for a specific data type, with different data group identifiers for different data types. The process involves determining the storage area for each type of data within a preset type file based on the description information, and storing the parsed data in its respective storage area. This includes: determining the storage area for each type of data within the preset type file based on the data group identifier, and identifying available locations within each storage area; setting a timestamp for each type of parsed data and storing it in the available location within its corresponding storage area; and compressing the stored data in the corresponding storage area if the total amount of data that can be stored in all available locations within the corresponding storage area reaches a threshold.

[0009] In one optional approach, the storage method further includes: if the data storage duration corresponding to the preset type file is greater than a preset duration, or the data storage volume of the preset type file reaches a preset storage volume, then the preset type file is frozen, and a new preset type file is used to store various types of data; wherein, the data storage duration is determined based on the timestamps corresponding to various types of data in the preset type file.

[0010] In one optional approach, each parsing strategy includes the extraction location of feature information and the data transformation method; based on the parsing strategy corresponding to each type of data, the multiple types of data are parsed to obtain the descriptive information of each type of data and the parsed data of each type, including: determining the extraction location of feature information in each type of data to extract the feature information of each type of data, and determining the descriptive information of each type of data based on the feature information of each type of data; converting each type of data into storage data of the preset type file based on the corresponding data transformation method to obtain the parsed data of each type.

[0011] In one optional approach, the multiple data types include CAN data. The parsing strategy corresponding to the CAN data represents parsing the CAN data as parsed CAN data and parsing the corresponding description information from the DBC file corresponding to the CAN data. The multiple data types are parsed based on their respective parsing strategies to obtain description information for each type of data and the parsed data for each type, including: parsing the DBC file corresponding to the CAN data to obtain the description information corresponding to the CAN data, and using the CAN data as parsed CAN data; wherein the CAN data includes target CAN data converted from XCP data, the target CAN data being converted from the XCP data before being cached to the corresponding storage queue.

[0012] According to another aspect of this application, a vehicle data storage device is provided, the storage device comprising: an acquisition module, configured to acquire multiple types of data from cache areas in multiple storage queues; wherein different storage queues store different data types, and the storage queues stop caching data when there is no free cache area; a parsing module, configured to parse the multiple types of data based on a parsing strategy corresponding to each type of data, to obtain descriptive information of each type of data and the parsed data; the parsing strategy is a strategy to parse the corresponding type of data into storage data of a preset type file; and a storage module, configured to determine the storage area of ​​each type of data in the preset type file based on the descriptive information of each type of data, so as to store the parsed data of each type of data in its corresponding storage area, and store the descriptive information of each type of data in another area of ​​the preset type file.

[0013] According to one aspect of this application, an electronic device is provided, comprising: a controller; and a memory for storing one or more programs, which, when executed by the controller, perform the storage method described above.

[0014] According to one aspect of this application, a computer-readable storage medium is also provided, on which computer-readable instructions are stored, which, when executed by a computer's processor, cause the computer to perform the storage method described above.

[0015] According to one aspect of this application, a computer program product or computer program is also provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the storage method described above.

[0016] This application establishes a categorized cache queue for multi-source vehicle data to avoid data loss due to limited short-term processing capabilities, and introduces an idle detection mechanism to prevent memory overflow, ensuring the continuity of data acquisition and system robustness. Simultaneously, a customized parsing strategy is implemented for each data type to unify information parsing and storage formats, yielding descriptive information and parsed data for each type. Based on the descriptive information, the storage area for each type of data in a pre-defined type file is determined, achieving ordered coexistence and efficient retrieval of different data types within a single file. Furthermore, this application stores data and descriptive information separately. When management operations on related descriptive information are required, it is not necessary to separate it from the mixed data of various types; descriptive information can be managed independently, improving data management efficiency.

[0017] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0019] Figure 1 This is a flowchart illustrating a method for storing vehicle data, as shown in an exemplary embodiment of this application.

[0020] Figure 2 Based on Figure 1 The exemplary embodiment shown illustrates a flowchart of another method for storing vehicle data.

[0021] Figure 3 Based on Figure 1 The exemplary embodiment shown illustrates a flowchart of another method for storing vehicle data.

[0022] Figure 4 Based on Figures 1 to 3 The exemplary embodiment shown in any of the examples illustrates a flowchart of another method for storing vehicle data.

[0023] Figure 5 This is an architecture diagram of a vehicle data acquisition network that incorporates the vehicle data storage method described in this application.

[0024] Figure 6This is a schematic diagram of the structure of a vehicle data storage device illustrated in an exemplary embodiment of this application.

[0025] Figure 7 This is a schematic diagram of the structure of a computer system for an electronic device illustrated in an exemplary embodiment of this application. Detailed Implementation

[0026] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0027] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0028] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0029] In this application, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0030] As described in the background section, due to the short-term processing capacity bottleneck of the central controller, there are situations where it cannot simultaneously receive and process multiple types of data, resulting in missing related data. Furthermore, because vehicle data from different sources (i.e., different types of data) have different formats, they cannot be integrated and managed, requiring them to be categorized and stored separately, leading to fragmented data storage.

[0031] To address these issues, one aspect of this application provides a method for storing vehicle data, which solves the problems of limited short-term data processing capabilities, data loss due to inconsistent formats of multi-source vehicle data, and scattered data storage. Please refer to the details below. Figure 1 , Figure 1This is a schematic flowchart illustrating a method for storing vehicle data according to an exemplary embodiment of this application. The storage method includes at least steps S110 to S130, which are described in detail below:

[0032] S110: Retrieve multiple types of data from caches in multiple storage queues; where different storage queues store different types of data, and the storage queue stops caching data when there is no free cache.

[0033] Each storage queue stores data of its corresponding type, including at least several types of vehicle operation information such as CAN / LIN bus data, XCP measurement data, and SOA service communication data. This application configures an XCP module in the ECU or uses an XCP-related slave node to implement a program, thereby collecting data from the ECU via the XCP protocol. This enriches the types of vehicle data, covering as much of the vehicle's data as possible, to facilitate subsequent applications such as fault analysis based on various data types.

[0034] Each type of data corresponds to an independent storage queue, such as CAN storage queue, LIN storage queue, SOA message storage queue, and MCU storage queue. Each storage queue is a fixed-length circular buffer that can be deployed in a data logger (such as a VHR, Vehicle Health Recorder) to temporarily store raw data frames received from different communication channels. Each storage queue is divided into multiple buffers, each with a certain storage capacity sufficient to hold one or more complete data packets.

[0035] The allocation and release of the buffer uses a lock-free queue mechanism to avoid resource contention issues during multi-threaded access. When a certain type of data arrives, the system checks if there is a free buffer in its corresponding storage queue. If so, the newly arrived data is written to the free area and marked as "occupied." If all buffers are occupied and have not been released by subsequent processing threads, a stop-buffering strategy is triggered, i.e., the reception of new data of that type is suspended until a buffer is processed and released, preventing data overwriting or memory overflow due to continuous writing and ensuring system stability. This mechanism achieves load decoupling between acquisition and processing through front-end cache control, preventing system crashes and preserving critical data even under short-term overload of the central processing unit.

[0036] In some embodiments, two independent threads are used to process the data in the cache queue: one thread transfers the data in the storage queue, and the other parses the data. The corresponding cache area is only released, i.e. becomes an idle cache area, after both threads have processed it.

[0037] In some embodiments, the maximum capacity of the storage queue can be dynamically configured based on actual memory resources, for example, set between 64MB and 512MB. The granularity of the buffer can be set according to typical message lengths, such as dividing CAN messages into 8-byte aligned segments and XCP data packets into 64-byte units. For bursty data streams (such as event-triggered SOA messages), a minimum guaranteed buffer space can be reserved through a priority scheduling mechanism to ensure that critical information is not discarded.

[0038] S120: Based on the parsing strategies corresponding to each type of data, multiple types of data are parsed to obtain the descriptive information of each type of data and the parsed data of each type; the parsing strategy is the strategy of parsing the corresponding type of data into the storage data of the preset type file.

[0039] A dedicated parsing strategy is predefined for each data type. This strategy includes, but is not limited to, field extraction rules, encoding conversion methods, time synchronization methods, and metadata generation logic. For example, for CAN data, the parsing strategy might involve extracting attributes such as signal name, start bit, length, and scaling factor from the DBC (Database Container, CAN database file); while for SOA service call data, parameter deserialization might be based on the IDL (Interface Definition Language) interface definition document. To achieve flexible adaptation to multiple data sources, the parsing strategy for each data type exists in the form of independent configuration files. For example, the parsing strategy for XCP data can be automatically generated through an A2L file, which already contains information such as variable addresses, data types, and conversion formulas; the parsing strategy for CAN / LIN data comes from the DBC file; and the parsing strategy for SOA service data is embedded in the service definition table in the execution code.

[0040] Description information describes various data characteristics, including but not limited to data name, data type (signed, unsigned, floating-point), data size, starting position, and the conversion relationship between the original data value and the physical value. The data name is appended with the data source. For example, if data A comes from CAN channel 1, the data name of data A is A\CAN_1; if data A comes from ZCUR's XCP, the data name of A is A\XCP_ZCUR; if data A comes from domain0 of DDS service in SOA service, topic B, the data name of A is A\DDS_0_B; if data A is a member of a structure C, the data name of data A is CA\DDS_0_B.

[0041] The parsed data is uniformly formatted, meaning it shares the same data format. This embodiment normalizes the formats of different data types, converting them into a standard data format suitable for a preset file structure. This preset file type can be an MDF (Measurement Data Format) file, typically used for XCP data, or an ASCII or BLF file, typically used for CAN data. For example, storing multi-source vehicle data (multiple different data types) uniformly as an MDF file facilitates rapid parsing of the multi-source vehicle data using MDF viewing tools, improving data acquisition efficiency.

[0042] For example, when storing data uniformly as an MDF file, the parsing process outputs two types of results: one is structured descriptive information, which is used to construct the metadata segment of the MDF file; the other is the parsed data, which is a standardized numerical sequence formed by disassembling the original byte stream by field and converting its type, ready to be written into the data block.

[0043] S130: Based on the description information of various types of data, determine the storage area of ​​each type of data in the preset type file, so as to store the parsed data of each type of data in their respective corresponding storage areas, and store the description information of each type of data in another area of ​​the preset type file, that is, other areas outside the storage area in the preset type file.

[0044] This embodiment establishes a mapping relationship between the descriptive information of various types of data and the corresponding storage areas in preset type files to achieve classified storage of different types of data. For example, the descriptive information (such as data type identifiers, group labels, data lengths, etc.) is combined with a preset file layout planning algorithm to dynamically divide the storage areas in the preset type files. For instance, multiple contiguous blocks are set within the same preset type file, corresponding to CAN data areas, LIN data areas, event-triggered data areas, etc., respectively, ensuring that similar data are stored centrally, facilitating sequential read / write and compression optimization.

[0045] By separating descriptive information from various data types, a separate storage structure is formed. This structure supports efficient metadata query and update operations, enabling functions such as field retrieval, conditional filtering, and permission verification without traversing the entire data volume. For example, during the data analysis phase, users can first read the storage area containing descriptive information to quickly locate the required data category and its offset address, and then load the corresponding data block as needed, significantly reducing I / O overhead.

[0046] This embodiment establishes a categorized cache queue for multi-source vehicle data to avoid data loss due to limited short-term processing capabilities, and introduces an idle detection mechanism to prevent memory overflow, ensuring the continuity of data acquisition and system robustness. Simultaneously, a customized parsing strategy is implemented for each data type to unify information parsing and storage formats, yielding descriptive information and parsed data for each type. Based on the descriptive information, the storage area for each type of data in a preset type file is determined, achieving ordered coexistence and efficient retrieval of different data types within a single file. Because data and its descriptive information are stored separately, independent access and batch operations on metadata are supported, significantly improving data management flexibility and response speed.

[0047] In another exemplary embodiment of this application, how to optimize the data acquisition method is described in detail; please refer to [link / reference]. Figure 2 , Figure 2 Based on Figure 1 The illustrated exemplary embodiment presents a flowchart of another method for storing vehicle data. This storage method, as shown in the example... Figure 1 Based on S110 to S130 shown, at least S210 to S230 are also included, detailed below:

[0048] S210: Determine the data collection list based on the vehicle's operating condition type, and collect various types of data according to the data collection list.

[0049] Operating conditions include, but are not limited to, parking, driving, charging, air conditioning on, and energy recovery. The core signals monitored differ depending on the condition. For example, during driving, the focus is on collecting signals related to the powertrain, such as torque control, wheel speed, and pedal position. While charging, the focus shifts to voltage, current, temperature, and charging protocol interaction information within the battery management system. By pre-configuring multiple signal collection lists, each corresponding to one or more specific operating conditions, the system automatically matches and activates appropriate collection strategies based on the real-time perceived vehicle status.

[0050] This embodiment only collects data defined in the data acquisition list, that is, it obtains the corresponding type of data stream from the specified data source, rather than capturing all available data sources. This avoids redundant collection of non-critical data and significantly reduces data throughput and storage overhead. Data sources include CAN bus, LIN bus, service-oriented architecture (SOA) middleware communication interface, MCU register output, and other vehicle communication channels. The acquisition process can be carried out using polling, event triggering, or periodic sampling methods, depending on the data type and its timeliness requirements. For example, high-frequency control signals (such as engine speed and vehicle speed) are collected at fixed intervals, while event-driven signals (such as fault code reports) are captured through interrupt mechanisms.

[0051] Before acquiring XCP data, in addition to setting the data acquisition list in advance, it is also necessary to compile the MCU software to obtain the corresponding A2L and HEX / S19 files. Then, the data acquisition list and A2L and HEX / S19 files are used as inputs to generate multiple signal acquisition configuration files for acquiring XCP data.

[0052] S220: If there is a free buffer in the storage queue corresponding to the collected data of the corresponding type, then store the data of the corresponding type in the corresponding storage queue.

[0053] Each data type has its own corresponding storage queue for temporarily storing data packets to be processed. Data of different types is allocated to their respective independent storage queues for buffering management, enabling categorized caching and asynchronous processing. For example, CAN data enters a dedicated CAN storage queue, and XCP data enters an XCP storage queue, ensuring that different data types do not interfere with each other. Each storage queue has a preset capacity, typically measured in bytes or data frames. Queue management employs a two-pointer mechanism (read pointer and write pointer) to support thread-safe operations under concurrent access.

[0054] For a specific type of data collected, its associated storage queue is determined, and the availability of available cache space (i.e., a free cache area) is checked within that queue. A free cache area is an unoccupied storage space that can receive new data. Free cache areas include empty cache regions that do not store data, or cache regions that store corresponding data but are in a released state.

[0055] Free buffers can be detected by checking the difference between the write and read pointers to determine the remaining space, or by maintaining a free block bitmap for fast retrieval. Once a free buffer is confirmed, the collected data is written sequentially to the end of the queue, and the write pointer is updated. This design ensures that different types of data do not interfere with each other, preventing other critical data from becoming uncached due to a sudden surge in traffic for one type of data.

[0056] If there are empty cache areas in the storage queue that do not store data, it can be quickly determined that there are free cache areas in this storage queue. However, cache areas that store corresponding data may also be free cache areas. Here is an example of how to detect free cache areas that store corresponding data in each storage queue: Iterate through each cache area in the storage queue corresponding to the collected data of each type, and check whether the data in the traversed cache area has been parsed and transferred; if all are yes, then the traversed cache area is determined to be a free cache area, so as to determine the free cache areas in the storage queue corresponding to each type of data.

[0057] Here, all cache areas in the storage queue corresponding to each type of data are accessed one by one through a traversal. For each cache area that is traversed, it is checked whether it meets two key conditions: first, whether the data stored in it has been parsed, that is, whether the description information has been extracted according to the corresponding parsing strategy and the parsed data in a standardized format has been generated; second, whether the original data in the cache area has been transferred to the preset type file, ensuring that the original data content has been safely migrated to the preset type file.

[0058] If both of the above checks result in "yes", it indicates that the cache area has no valid data residing there and is no longer participating in any processing flow. At this time, it can be marked as a free cache area. This determination logic avoids the risks associated with judging the free state solely based on the data read pointer position or a simple flag bit, thus improving the security and accuracy of memory management. Furthermore, a dynamically updated list of free cache areas can be maintained, recording the addresses or indices of currently available cache units for subsequent data writing.

[0059] S230: If there is no free buffer in the storage queue corresponding to the collected data of the corresponding type, the data of the corresponding type will be dropped.

[0060] The absence of a free buffer area means the corresponding storage queue is full, i.e., the write pointer catches up with the read pointer or the maximum capacity limit has been reached, indicating that the current parsing and transfer processing speed is lower than the acquisition rate. At this point, to avoid memory overflow or system blocking, a packet loss strategy is proactively implemented, i.e., the currently acquired data packets are discarded and not written to the corresponding buffer queue. Packet loss decisions occur during the judgment phase before data writing and are a preventative measure, not a passive recovery mechanism after an abnormal interruption. Packet loss priorities can be set according to data importance; for example, non-critical diagnostic information is discarded first, while safety-related signals (such as braking status and steering angle) can retain higher priority cache permissions. Furthermore, packet loss event logs, including timestamps, data types, and reasons for packet loss, can be recorded for later analysis.

[0061] This embodiment flexibly configures the collection list according to different driving conditions, reducing the intake of irrelevant data and lowering system bandwidth and storage burden. Furthermore, by actively dropping packets instead of blocking and waiting when the cache is full, it avoids system anomalies caused by memory overflow. Moreover, by moving the packet loss judgment to the collection entry point, it reduces the processing pressure of subsequent parsing and storage, thereby improving the stability, real-time performance, and resource utilization efficiency of the multi-source vehicle data collection process.

[0062] In another exemplary embodiment of this application, it is described in detail how to determine the storage area of ​​various types of data in a preset type file based on the description information of various types of data, so as to store the parsed data of various types of data into their respective corresponding storage areas. Please refer to [link to relevant documentation] for details. Figure 3 , Figure 3 Based on Figure 1 The illustrated exemplary embodiment presents a flowchart of another method for storing vehicle data. This storage method, as shown in the example... Figure 1 The S130 shown includes at least S310 to S330; wherein, the description information corresponds to a data group identifier of the corresponding data type, and the data group identifiers corresponding to different data types are different, as detailed below:

[0063] S310: Based on the data group identifiers corresponding to various types of data, determine the storage area of ​​each type of data in the preset type file, and determine the free space in each storage area.

[0064] A data group identifier (dataGroupId) is a unique number or label used to identify a logical group of data of a certain type. The purpose of the data group identifier is to establish a mapping relationship between data types and storage areas. Each type of data corresponds to an independent data block area, and space for this data block area is reserved during the file initialization phase according to a preset strategy.

[0065] Data group identifiers are assigned incrementally starting from 0. Each data type (such as CAN / LIN data, XCP data, SOA service data, etc.) is assigned a different data group identifier, thereby achieving isolated management of different data types under a unified file structure. For example, CAN data can be assigned dataGroupId=0, XCP data dataGroupId=1, and SOA data dataGroupId=2. This identifier is written as metadata into the channel block of the MDF file for subsequent data block addressing and classification retrieval.

[0066] Free space identification involves identifying available areas within a known storage region that have not yet been written to. This can be achieved by maintaining write pointers for each region, updating the pointer position after each write operation, and identifying free spaces before the pointer reaches the end of the region. Another approach is to use a bitmap management method, where bits indicate whether a data block is occupied, and consecutive free blocks are quickly located by scanning the bitmap. A circular buffer mechanism can also be combined, automatically overwriting the oldest data when a region is full, suitable for circular recording scenarios. These methods can be used independently or in combination to adapt to different performance and reliability requirements.

[0067] S320: After setting a timestamp for each type of parsed data, store it in an empty location in its respective storage area.

[0068] Before storing the corresponding data in an available location, a timestamp reflecting the time of data acquisition is appended to it. This timestamp can originate from a unified clock source, such as a PTP (Precision Time Protocol) or a GPS (Global Positioning System) synchronized clock. The timestamp is written to the storage medium along with the data content, forming a data unit with time-series attributes. This design supports subsequent backtracking analysis along the time dimension, multi-source data alignment, and event reconstruction, which is particularly significant in fault diagnosis and driving behavior analysis.

[0069] S330: If the amount of data that can be stored in all free locations in the corresponding storage area reaches the threshold, then the stored data in the corresponding storage area is compressed.

[0070] If the threshold is reached, it indicates that the remaining free space in the buffer corresponding to the current data group is insufficient to accommodate the new data to be written, or that the amount of data accumulated meets the preset compression conditions.

[0071] For example, if the capacity threshold is 100MB, and the capacity of the data stored in the corresponding storage area reaches 100MB (that is, the amount of data that can be stored in all free locations in the corresponding storage area reaches the threshold, for example, the threshold is 0), then the stored data is compressed to release the storage space of the storage area.

[0072] In some embodiments, the compression timing can be determined based on the duration of data storage in the storage area (i.e., the duration threshold). For example, if the duration of data storage in a certain storage area reaches 30 seconds, then the data stored in that storage area will be compressed. The duration of data storage can be determined based on the timestamps corresponding to the data stored in the storage area. For example, the earliest timestamp corresponding to the data stored in the storage area can be used as the storage start time of that storage area, and the time difference between the current time and the storage start time can be used as the data storage duration.

[0073] This embodiment employs a partitioned storage management mechanism centered on data group identifiers, combined with timestamp alignment and dynamic compression strategies. It utilizes a combination of logical grouping, time synchronization, and resource allocation to solve the technical challenge of efficiently, orderly, and sustainably storing multi-source vehicle data in a unified file. This improves data organization standardization, enhances subsequent analysis capabilities, and optimizes system resource utilization. Specifically, this solution is widely applicable to integrated acquisition and storage scenarios in intelligent connected vehicles involving multiple data sources such as CAN / LIN, XCP, and SOA. It is compatible with the standard MDF format and supports seamless integration with mainstream analysis tools.

[0074] In another exemplary embodiment, it is explained how to use multiple preset type files to store related data, so that when the data storage volume of the corresponding file reaches the preset storage volume, a new file is enabled for relay storage.

[0075] For example, if the data storage duration corresponding to the preset type file is greater than the preset duration, or the data storage volume of the preset type file reaches the preset storage volume, the preset type file is frozen, and a new preset type file is used to store various types of data; wherein, the data storage duration is determined based on the timestamps corresponding to various types of data in the preset type file.

[0076] Data storage duration is the time span between the earliest and latest written data in the current preset type file. This duration is calculated by parsing the timestamp information carried by all stored data entries in the file, specifically by extracting the minimum timestamp T. min With the maximum timestamp T max And calculate the difference ΔT=T max -T min The timestamp is typically appended before the data enters the storage queue, with a precision of milliseconds or microseconds, ensuring accurate alignment in the time dimension.

[0077] The preset duration is a pre-configured time threshold used to control the maximum time window covered by a single preset file type. For example, in some implementation scenarios, the preset duration can be set to 10 minutes, 30 minutes, or 1 hour, and the specific value can be flexibly set according to the vehicle operation cycle, diagnostic needs, or cloud upload frequency.

[0078] The data storage capacity is the total amount of valid data that has been written into the current preset type file.

[0079] If any of the above freezing conditions (the freezing conditions corresponding to the preset duration and / or preset storage volume) are met, the write channel for the corresponding preset type of file is closed, prohibiting any new data from being appended, while maintaining its read-only attribute for subsequent reading, archiving, or transmission. This composite judgment mechanism enhances the system's adaptability and robustness: in high data throughput scenarios, even if the time is not yet full, the file may be switched in time as the capacity is quickly filled; while in low-frequency data acquisition scenarios, even if the data volume grows slowly, it can be proactively archived after the time window expires, avoiding long-term occupation of write resources.

[0080] The freeze operation can include updating file header metadata (such as marking a "frozen" status bit), synchronizing cached data to persistent storage, and releasing related memory-mapped resources to ensure file integrity and consistency. Simultaneously, a new, initial-state instance of a pre-defined type file is created to handle subsequent write tasks for various vehicle data. The new pre-defined type file inherits the original file structure specifications and storage strategy, but has an independent filename (e.g., named by timestamp), an independent storage area, and an independent lifecycle counter. New and old files can be linked through a chained index or directory structure to form a continuous sequence of data records.

[0081] This embodiment provides fine-grained management of the lifecycle of preset file types. By setting dual thresholds for duration and capacity, it effectively prevents the risk of decreased IO performance, file parsing delays, or memory overflows caused by the unlimited growth of a single file. By freezing old files and enabling new files, it achieves physical separation of historical and incremental data, facilitating data retrieval, backup, or uploading to cloud servers by time period later. By calculating storage duration based on timestamp aggregation, it ensures the accuracy and consistency of time dimension judgment, avoiding misjudgments caused by individual abnormal timestamps, thereby significantly improving the maintainability and stability of stored data, which is especially suitable for intelligent connected vehicle environments that require long-term continuous operation.

[0082] In another exemplary embodiment of this application, it is described in detail how to parse multiple types of data based on their respective parsing strategies to obtain descriptive information of each type of data and the parsed data. Please refer to [link to relevant documentation] for details. Figure 4 , Figure 4 Based on Figures 1 to 3 The exemplary embodiment shown in any of the examples illustrates a flowchart of another method for storing vehicle data. This storage method, in such a way... Figure 1 The S130 shown includes at least S410 to S420; each parsing strategy includes the extraction location of feature information and the data transformation method, which are described in detail below:

[0083] S410: Determine the extraction location of feature information in various types of data, so as to extract the feature information of various types of data, and determine the descriptive information of various types of data based on the feature information of various types of data.

[0084] Feature information consists of key fields that uniquely identify the semantic source of data, such as signal name, device address, and service interface identifier. The feature information differs for different data types. Taking CAN / LIN data as an example, its parsing strategy relies on a DBC file, extracting descriptive information such as signal name, start bit, length, data type (signed / unsigned integer, floating-point), scaling factor, offset, and physical unit; it also retains the original message ID and timestamp as a basic index. XCP data parsing, on the other hand, is based on an A2L file or an automatically generated signal configuration table, obtaining attributes such as variable address, data type, sampling period, and conversion formula, and combining this with the PID (Packet Identifier) ​​to identify the measurement object.

[0085] The extraction location refers to the byte offset, bit range, or structure field path used to locate critical metadata in the raw data stream or message. This extraction location is pre-configured in the respective parsing strategies based on the protocol specifications of different data types. For example, for XCP data, its characteristic information may include the PID field in the object attribute descriptor, and the extraction location is typically located within two consecutive bytes starting from byte 0 of the message header; for CAN data, the characteristic information includes the CAN ID, and the extraction location is located in the frame header identifier area; for SOA service data, the characteristic information may be the Topic name or Service UUID, and the extraction location is located in the prefix field of the serialized message.

[0086] For example, based on the parsing strategy of the current data type, the structural layout of the original data packet is identified, and key fields are accurately extracted according to preset extraction positions to form a preliminary feature information set. This feature information may include, but is not limited to: signal name, signal type, data length, sampling period, physical unit, effective range, and the corresponding message ID or service interface name. Based on this feature information, corresponding descriptive information, i.e., metadata tags, is automatically generated for subsequent data classification, index construction, and retrieval optimization. For instance, if a CAN message is received, the corresponding parsing strategy is matched according to its message ID, and the extraction position information (such as start bit 7, length 12 bits) is read from it. The corresponding fields are extracted from the original CAN frame to obtain the original values; then, combined with the signal name "VehicleSpeed", unit "km / h", factor "0.01", offset "0", and other attributes defined in the DBC file, a complete descriptive information entry is generated.

[0087] S420: Based on the corresponding data conversion method, convert various types of data into storage data of preset type files to obtain various types of parsed data.

[0088] To address the heterogeneity of different data types, a data transformation logic tied to their parsing strategy is employed to uniformly convert them into data structures suitable for the same preset file type (e.g., the data structure of MDF files). This transformation process includes not only format-level adaptation (such as endianness conversion and compression encoding selection) but also semantic-level alignment (such as coordinate system standardization).

[0089] For example, sensor data is originally transmitted in hexadecimal string format. According to the conversion method in its parsing strategy, it is parsed into an unsigned integer, multiplied by a preset scaling factor, and finally encapsulated into a single-precision floating-point number and written into the data block of the MDF file.

[0090] This embodiment can automatically identify core identifiers such as XCP PID, CAN ID, and SOA Topic without relying on external tools. It adopts a standardized data conversion method, which enables data from different protocols to be stored in alignment on the same timeline. The generated description information can be directly used for writing metadata to MDF files, which significantly simplifies the file generation process.

[0091] In another exemplary embodiment of this application, the CAN data parsing process is described in detail, namely, a detailed description of S130; wherein, among the various types of data is CAN data, the parsing strategy corresponding to the CAN data represents the CAN data as parsed CAN data, and the corresponding descriptive information is obtained by parsing from the DBC file corresponding to the CAN data, as detailed below:

[0092] The DBC file corresponding to the CAN data is parsed to obtain the description information corresponding to the CAN data, and the CAN data is used as the parsed CAN data. The CAN data includes the target CAN data converted from the XCP data. The target CAN data is converted from the XCP data before it is cached to the corresponding storage queue.

[0093] CAN data refers to data messages transmitted between vehicle electronic control systems via the CAN bus. These messages are typically stored in frames and contain an identifier (ID), a Data Length Code (DLC), and a data field of up to 8 bytes. The DLC file defines the semantic information of each signal in the CAN network, including but not limited to: signal name, start bit, signal length, byte order, physical unit, scaling factor, offset, valid value range, associated message ID, and transmission cycle. By parsing the DLC file, the semantics of the original binary CAN message can be reconstructed, thus obtaining its corresponding descriptive information.

[0094] For CAN data, no format conversion or content modification is required; it can be directly preserved as the data entity for subsequent storage and processing. This approach avoids the computational overhead and potential data distortion caused by format conversion, making it particularly suitable for scenarios with high real-time requirements.

[0095] This embodiment performs a pre-conversion of XCP data. Before the XCP data enters the corresponding buffer queue, it is mapped into target CAN data conforming to a specific CAN message format. Prior to this, a CAN channel is allocated for each ECU from which the XCP data originates, used to transmit the target CAN data converted from the XCP data. This conversion process includes the following operations: according to a preset mapping rule, the PID in the XCP data message is used as the CAN ID of the virtual CAN message, and according to the layout definition of the message in the DBC file, the PID is embedded into the position of the corresponding signal to assemble the target CAN data into a standard CAN frame structure.

[0096] This embodiment utilizes existing DBC files as the source of descriptive information, eliminating the need to import additional files and reducing system configuration costs. It also preserves the original CAN data format as the parsing result, reducing unnecessary data processing steps and improving overall throughput efficiency. Furthermore, XCP data is converted to target CAN data before buffering, unifying the data format across multiple input sources and enhancing system integration capabilities.

[0097] In another exemplary embodiment of this application, the application scenarios of the above-mentioned storage methods are illustrated by way of example. Please refer to the following for details. Figure 5 , Figure 5 This is an architecture diagram of a vehicle data acquisition network incorporating the vehicle data storage method described in this application. The vehicle data acquisition network includes a data logger 101 housed in a first physical chip 100, a second physical chip 200, a zone controller group 300, and a chip microcontroller 400. The first physical chip 100 is connected to the second physical chip 200, the zone controller group 300, and the chip microcontroller 400 via Ethernet. The first physical chip 100 and the second physical chip 200 can communicate via Ethernet using SOA services. Here, the physical chip is referred to as a System-on-Chip (SOC); the data logger is referred to as a Vehicle Data Recorder (VHR); the zone controller is referred to as a Zone Controller Unit (ZCU); the chip microcontroller is referred to as a System-on-Chip (SOC_MCU); and the microcontroller is referred to as a Microcontroller Unit (MCU).

[0098] The area controller group 300 includes a first area controller 301 and a second area controller 302. The chip microcontroller 400, the first area controller 301, and the second area controller 302 are each connected to their respective microcontroller groups 500 via CAN / LIN lines. Each microcontroller group 500 includes multiple microcontrollers 510 connected in parallel. The first physical chip 100 and the area controller group 300 are located on different PCBs (Printed Circuit Boards), while the first physical chip 100 and the chip microcontroller 400 are located on the same PCB.

[0099] Data logger 101 acquires internal signals of microcontroller 510 specified in chip microcontroller 400 which is physically connected to it via Ethernet, and internal signals of microcontroller 510 specified in area controller group 300 connected via Ethernet, via the XCP protocol. These specified microcontrollers 510 can communicate with the first physical chip 100 via Ethernet for SOA service.

[0100] Data logger 101 can execute any of the above storage methods, as illustrated below: Data logger 101 retrieves multiple types of data from the cache area in the storage queue corresponding to each type of data; wherein, the storage queue stops caching data when there is no free cache area; Data logger 101 parses the multiple types of data based on the parsing strategy corresponding to each type of data to obtain the description information of each type of data and the parsed data; the parsing strategy is a strategy to parse the corresponding type of data into storage data of a preset type file; Data logger 101 determines the storage area of ​​each type of data in the preset type file based on the description information of each type of data, so as to store the parsed data of each type of data in its corresponding storage area, and store the description information of each type of data in another area of ​​the preset type file.

[0101] Another aspect of this application provides a vehicle data storage device, such as... Figure 6 As shown, Figure 6 This is a schematic diagram illustrating the structure of a vehicle data storage device according to an exemplary embodiment of this application. The storage device 600 includes:

[0102] The acquisition module 610 is used to acquire multiple types of data from the cache areas of multiple storage queues; wherein, different storage queues store different types of data, and the storage queue stops caching data when there is no free cache area.

[0103] The parsing module 630 is used to parse multiple types of data based on their respective parsing strategies to obtain descriptive information of each type of data and the parsed data. The parsing strategy is a strategy for parsing the corresponding type of data into storage data of a preset type file.

[0104] The storage module 650 is used to determine the storage area of ​​each type of data in a preset type file based on the description information of each type of data, so as to store the parsed data of each type of data in their respective corresponding storage areas, and store the description information of each type of data in another area of ​​the preset type file.

[0105] In another exemplary embodiment, the storage device 600 further includes:

[0106] The data collection module is used to determine the data collection list based on the vehicle's operating condition and to collect various types of data based on the data collection list.

[0107] The caching module is used to store the corresponding type of data into the corresponding storage queue if there is a free cache area in the storage queue corresponding to the collected data type.

[0108] The packet loss module is used to process the corresponding type of data as packet loss if there is no free buffer in the storage queue corresponding to the collected data.

[0109] In another exemplary embodiment, the storage device 600 further includes:

[0110] The traversal module is used to traverse each cache area in the storage queue corresponding to the various types of data collected, and to check whether the data in the traversed cache area has been parsed and transferred.

[0111] The free buffer determination module is used to determine that the traversed buffer is a free buffer if all are true, so as to determine the free buffer in the storage queue corresponding to each type of data.

[0112] In another exemplary embodiment, the description information corresponds to a data group identifier of a corresponding data type, and different data group identifiers correspond to different data types; the storage module 650 includes:

[0113] The free space determination unit is used to determine the storage area of ​​each type of data in a preset type file based on the data group identifier corresponding to each type of data, and to determine the free space in each storage area.

[0114] The timestamp unit is used to set timestamps for various types of parsed data and store them in the free locations of their respective storage areas.

[0115] The compression unit is used to compress the stored data in the corresponding storage area if the amount of data that can be stored in all free locations in the corresponding storage area reaches a threshold.

[0116] In another exemplary embodiment, the storage device 600 further includes:

[0117] The file freeze module is used to freeze a preset type file and enable a new preset type file to store various types of data if the data storage duration corresponding to the preset type file exceeds the preset duration or the data storage volume of the preset type file reaches the preset storage volume. The data storage duration is determined based on the timestamps corresponding to various types of data in the preset type file.

[0118] In another exemplary embodiment, each parsing strategy includes the extraction location of feature information and the data transformation method; the parsing module 630 includes:

[0119] The description information determination unit is used to determine the extraction location of feature information in various types of data, so as to extract the feature information of various types of data, and determine the description information of various types of data based on the feature information of various types of data.

[0120] The parsing unit is used to convert various types of data into storage data of preset type files based on the corresponding data conversion method, so as to obtain various types of parsed data.

[0121] In another exemplary embodiment, the multiple types of data include CAN data. The parsing strategy corresponding to the CAN data represents the CAN data as parsed CAN data, and the corresponding description information is parsed from the DBC file corresponding to the CAN data. The parsing module 630 includes:

[0122] The CAN data parsing unit is used to parse the DBC file corresponding to the CAN data, obtain the description information corresponding to the CAN data, and use the CAN data as the parsed CAN data. The CAN data includes target CAN data converted from XCP data. The target CAN data is converted from XCP data before being cached into the corresponding storage queue.

[0123] This application's storage device establishes a categorized cache queue for multi-source vehicle data to avoid data loss due to limited short-term processing capabilities, and introduces an idle detection mechanism to prevent memory overflow, ensuring the continuity of data acquisition and system robustness. Simultaneously, a customized parsing strategy is implemented for each type of data to unify information parsing and storage formats, obtaining descriptive information and parsed data for each type. Based on the descriptive information, the storage area for each type of data in a preset type file is determined, achieving ordered coexistence and efficient retrieval of different types of data within a single file. Furthermore, this application's storage device stores data and descriptive information separately. When management operations on related descriptive information are required, it is not necessary to separate it from the mixed data of various types; descriptive information can be managed independently, improving data management efficiency.

[0124] It should be noted that the storage device provided in the above embodiments and the storage method provided in the foregoing embodiments belong to the same concept. The specific ways in which each module and unit performs operations have been described in detail in the method embodiments, and will not be repeated here.

[0125] Another aspect of this application provides an electronic device, including: a controller; and a memory for storing one or more programs, which, when executed by the controller, perform the storage method described above.

[0126] Please see Figure 7 , Figure 7 This is a schematic diagram of the structure of a computer system for an electronic device according to an exemplary embodiment of this application, illustrating a schematic diagram of the structure of a computer system suitable for implementing the embodiments of this application.

[0127] It should be noted that, Figure 7 The computer system 700 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0128] like Figure 7 As shown, the computer system 700 includes a Central Processing Unit (CPU) 701, which can perform various appropriate actions and processes, such as executing the methods described in the above embodiments, based on programs stored in Read-Only Memory (ROM) 702 or programs loaded from storage portion 708 into Random Access Memory (RAM) 703. The RAM 703 also stores various programs and data required for system operation. The CPU 701, ROM 702, and RAM 703 are interconnected via a bus 704. An Input / Output (I / O) interface 705 is also connected to the bus 704.

[0129] The following components are connected to I / O interface 705: an input section 706 including a keyboard, mouse, etc.; an output section 707 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to I / O interface 705 as needed. A removable medium 711, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 710 as needed so that computer programs read from it can be installed into storage section 708 as needed.

[0130] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 709, and / or installed from removable medium 711. When the computer program is executed by central processing unit (CPU) 701, it performs various functions defined in the system of this application.

[0131] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. The transmitted data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0132] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0133] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0134] Another aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the aforementioned storage method. This computer-readable storage medium may be included in the electronic device described in the above embodiments, or it may exist independently and not assembled into the electronic device.

[0135] Another aspect of this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the storage methods provided in the various embodiments described above.

[0136] According to one aspect of the embodiments of this application, a computer system is also provided, including a Central Processing Unit (CPU), which can perform various appropriate actions and processes based on a program stored in read-only memory (ROM) or a program loaded from storage into random access memory (RAM), such as performing the methods described above. Various programs and data required for system operation are also stored in the RAM. The CPU, ROM, and RAM are interconnected via a bus. Input / output (I / O) interfaces are also connected to the bus.

[0137] The following components are connected to the I / O interface: input components including keyboards, mice, etc.; output components including cathode ray tubes (CRTs), liquid crystal displays (LCDs), and speakers; storage components including hard drives; and communication components including network interface cards such as LAN (Local Area Network) cards and modems. The communication components perform communication processing via networks such as the Internet. Drives are also connected to the I / O interface as needed. Removable media, such as disks, optical discs, magneto-optical discs, semiconductor memories, etc., are installed on the drive as needed so that computer programs read from them can be installed into the storage components as required.

[0138] The above description is merely a preferred exemplary embodiment of this application and is not intended to limit the implementation of this application. Those skilled in the art can easily make corresponding modifications or alterations based on the main concept and spirit of this application. Therefore, the scope of protection of this application should be determined by the scope of protection claimed in the claims.

Claims

1. A storage method of vehicle data, characterized by, The storage method comprises: Obtaining multiple types of data from buffer areas in multiple storage queues; wherein different storage queues store different types of data, the storage queue stops caching data in the absence of a free buffer area, the capacity of the storage queue is configured according to actual memory resources and a priority scheduling mechanism, and the free buffer area includes a buffer area in which stored data has been parsed and original data has been transferred; the multiple types of data include CAN data; Parsing the multiple types of data based on respective parsing strategies corresponding to the types of data to obtain description information of the types of data and the parsed types of data, including: parsing a DBC file corresponding to the CAN data to obtain description information corresponding to the CAN data, and taking the CAN data as parsed CAN data; wherein the CAN data includes target CAN data converted from XCP data, the target CAN data is converted from the XCP data before being cached to the corresponding storage queue, and the conversion mode is: taking a PID in an XCP data packet as a virtual CAN packet CAN ID, and embedding the PID into the position of the corresponding signal according to the layout definition of the XCP data packet in the DBC file to assemble the target CAN data; the parsing strategy is a strategy of parsing data of a corresponding type into storage data of a preset type file; Determining storage areas of the types of data in the preset type file based on the description information of the types of data, to store the parsed types of data to the respective storage areas after time stamping, and store the description information of the types of data in another area in the preset type file; Performing backtracking analysis based on the stored parsed types of data.

2. The storage method of claim 1, wherein, The storage method further comprises: Determining a data acquisition list according to the working condition type of the vehicle, and acquiring the types of data according to the data acquisition list; If the free buffer area exists in the storage queue corresponding to the acquired type of data, storing the type of data to the corresponding storage queue; If the free buffer area does not exist in the storage queue corresponding to the acquired type of data, performing packet loss processing on the type of data.

3. The storage method of claim 2, wherein, The storage method further comprises: Traversing each buffer area in the storage queue corresponding to the acquired types of data, and detecting whether the data in the traversed buffer area has been parsed and transferred; If both are yes, determining that the traversed buffer area is the free buffer area, to determine the free buffer area in the storage queue corresponding to the types of data.

4. The storage method of claim 1, wherein, The description information corresponds to a data group identifier of the corresponding type of data, and the data group identifiers of different types of data are different; Determining the storage areas of the types of data in the preset type file based on the data group identifiers corresponding to the types of data, and determining the free positions in each storage area, to store the parsed types of data to the respective storage areas after time stamping, including: Determining the storage areas of the types of data in the preset type file based on the data group identifiers corresponding to the types of data, and determining the free positions in each storage area; timestamping the parsed data of each type and storing the timestamped data into a free location in a corresponding storage area; if the amount of data that can be stored in all free locations in the corresponding storage area reaches a threshold, compressing the stored data in the corresponding storage area.

5. The storage method of claim 4, wherein, The storage method further includes: if the data storage duration of the preset type file is greater than a preset duration or the data storage amount of the preset type file reaches a preset storage amount, freezing the preset type file and enabling a new preset type file to store data of each type; wherein the data storage duration is determined according to the timestamps of data of each type in the preset type file.

6. The storage method according to any one of claims 1 to 5, wherein, Each parsing strategy includes an extraction position of feature information and a data conversion mode; parsing the multiple types of data based on the parsing strategies corresponding to the multiple types of data, to obtain description information of the multiple types of data and parsed data of the multiple types of data, including: determining the extraction position of feature information in data of each type, to extract feature information of data of each type, and determining description information of data of each type based on the feature information of data of each type; converting data of each type into storage data of the preset type file based on the corresponding data conversion mode, to obtain parsed data of each type.

7. A storage device for vehicle data, characterized by The storage device includes: an acquisition module, configured to acquire multiple types of data from a cache area in a plurality of storage queues; wherein different storage queues store different types of data, the storage queues stop caching data in the absence of a free cache area, the capacity of the storage queues is configured according to actual memory resources and a priority scheduling mechanism, and the free cache area includes a cache area in which stored data has been parsed and original data has been transferred; the multiple types of data include CAN data; a parsing module, configured to parse the multiple types of data based on parsing strategies corresponding to the multiple types of data, to obtain description information of the multiple types of data and parsed data of the multiple types of data, including: parsing a DBC file corresponding to the CAN data, to obtain description information corresponding to the CAN data, and taking the CAN data as parsed CAN data; wherein the CAN data includes target CAN data converted from XCP data, the target CAN data is converted from the XCP data before being cached in a corresponding storage queue, and the conversion mode is: taking a PID in an XCP data packet as a virtual CAN packet CAN ID, embedding the PID into a position of a corresponding signal according to a layout definition of the XCP data packet in the DBC file, to assemble the target CAN data; the parsing strategy is a strategy of parsing corresponding type data into storage data of a preset type file; a storage module, configured to determine a storage area of data of each type in the preset type file based on the description information of data of each type, to timestamp the parsed data of each type and store the timestamped data into a corresponding storage area, and to store the description information of data of each type in another area in the preset type file; and performing backtracking analysis based on the stored parsed data of each type.

8. An electronic device, comprising: including: a controller; a memory for storing one or more programs which, when executed by the controller, cause the controller to implement the storage method of any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, a computer readable medium having stored thereon computer readable instructions which, when executed by a processor of a computer, cause the computer to perform the storage method of any one of claims 1 to 6.

Images