A vehicle-mounted data query method, device and equipment and readable storage medium

Abstract

This invention discloses a method, apparatus, device, and readable storage medium for querying vehicle-mounted data, applied in the field of data storage technology. The method includes: searching a mapping index file based on a query request to determine a target index entry corresponding to the target query time range; the mapping index file includes index entries corresponding to each time range, and each index entry includes the offset range of video data corresponding to each time range in a target video file and the offset range of bus data corresponding to each time range in a target bus file; and reading the target query vehicle-mounted data from the target video file and the target bus file according to the video file offset range and bus file offset range recorded in the target index entry. This invention determines the offset range of two files based on the target index directory determined by the time range, thereby quickly reading vehicle-mounted data. Since it only requires locating once in the mapping index file, it can improve the efficiency of vehicle-mounted data query.

Description

Technical Field

[0001] This invention relates to the field of data storage technology, and in particular to a method, apparatus, device, and readable storage medium for querying in-vehicle data. Background Technology

[0002] In-vehicle systems continuously generate video streams and bus message streams during long-term operation. In engineering practice, to achieve stable write performance, a common approach is to write video sequentially to video files and append bus messages sequentially to log files. This method has a simple write path, a low probability of error, and makes partial recovery easier when a single file is corrupted. However, physical separation introduces verification efficiency issues. When upper-layer applications perform time-based verification, they need to locate segments within the same time range in both files. If only a full scan based on timestamps is used, the search will be slow; if fine-grained indexes are built separately, the index size will increase, further increasing the write burden.

[0003] It is evident that improving the efficiency of vehicle data retrieval is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0004] In view of this, the purpose of the present invention is to provide a vehicle data query method that solves the technical problem of low efficiency in vehicle data query in the prior art.

[0005] To solve the above-mentioned technical problems, the present invention provides a vehicle data query method, comprising: Receive query requests containing the target query time range; Based on the query request, a search is performed in the mapping index file to determine the target index entry corresponding to the target query time range; wherein, the mapping index file includes an index entry corresponding to each time range, and each index entry includes the offset range of the video data corresponding to each time range in the target video file, and the offset range of the bus data corresponding to each time range in the target bus file; Based on the video file offset range and bus file offset range recorded in the target index entry, the corresponding target query vehicle data is read from the target video file and the target bus file.

[0006] Optionally, before searching the mapping index file based on the query request to determine the target index entry corresponding to the target query time range, the method further includes: The video data is written to the target video file in a sequential manner, in units of data blocks, and the video data parameter information corresponding to each video data is recorded; wherein, the video data parameter information includes the position information of each video data in the target video file; Bus data is written to the target bus file in append mode, and bus parameter information corresponding to each bus data is recorded; the bus parameter information includes the position information of each bus data in the target bus file; When the conditions for generating an index entry are met, an index entry is generated based on all currently accumulated video data parameter information and bus parameter information, and the index entry is stored in the mapping index file.

[0007] Optionally, when it is determined that the index entry generation conditions are met, an index entry is generated based on all currently accumulated video data parameter information and bus parameter information, and the index entry is stored in the mapping index file, including: When it is determined that the conditions for generating an index entry are met, the start time, end time, video file offset range, bus file offset range, version, and verification field of the index entry are determined based on all currently accumulated video data parameter information and bus parameter information. The index entry is constructed based on the start time, end time, video file offset range, bus file offset range, version, and verification field of the index entry.

[0008] Optionally, before generating an index entry based on all currently accumulated video data parameter information and bus parameter information, and storing the index entry in the mapping index file, the method further includes: The index entry generation conditions are determined based on a limited maximum latency, a limited index size, and video keyframe coverage conditions; wherein the limited maximum latency is determined by an upper limit of the time span, the limited index size is determined by an upper limit of the byte span and the upper limit of the time span, and the video keyframe coverage conditions are determined by keyframe identifiers.

[0009] Optionally, the video data parameter information is determined to include at least the start and end timestamps of the video data and the start offset of the video data in the target video file; the bus parameter information is determined to include at least the bus message timestamp, bus message identifier, flag bits, data length code, and data payload.

[0010] Optionally, based on the video file offset range and bus file offset range recorded in the target index entry, the corresponding target query vehicle data is read from the target video file and the target bus file, including: Obtain the set of target index entries determined based on the start and end time points of the target query time range; Based on the time range, video data offset range, and bus data offset position recorded for each target index entry in the target index entry set, the approximate position of the current time range in the target video file and the target bus file is determined; Starting from the approximate position, determine the frame-level timestamps in the target video file and the target bus file that correspond to the current time range; The in-vehicle video data and in-vehicle bus data are determined based on the frame-level timestamp, and the in-vehicle video data and in-vehicle bus data are used as the target query in-vehicle data.

[0011] Optionally, after receiving a query request containing the target query time range, the following steps are also included: When it is determined that the mapping index file is corrupted, the target video file is scanned at a first preset data volume interval to determine the timestamp of the first video keyframe and the timestamp of the second video keyframe; wherein, the first video keyframe and the second video keyframe are adjacent video keyframes. The reconstruction time range and the offset range of the reconstructed video data are determined based on the timestamps of the first and second video keyframes. Read the target bus file at a second preset data interval to determine the offset range of the reconstruction bus data corresponding to the reconstruction time range; Based on the reconstruction time range, the offset range of the reconstructed video data, and the offset range of the reconstructed bus data, reconstruction index entries are determined and appended to the target mapping index file.

[0012] This invention also provides an in-vehicle data query device, comprising: The query request determination module is used to receive query requests that contain a target query time range; The target index entry determination module is used to search in the mapping index file based on the query request to determine the target index entry corresponding to the target query time range; wherein, the mapping index file includes index entries corresponding to each time range, and each index entry includes the offset range of video data corresponding to each time range in the target video file, and the offset range of bus data corresponding to each time range in the target bus file; The vehicle data determination module is used to read the corresponding target query vehicle data from the target video file and the target bus file based on the video file offset range and bus file offset range recorded in the target index entry.

[0013] This invention also provides an in-vehicle data query device, comprising: Memory, used to store computer programs; A processor is used to execute the computer program to implement the steps of the above-described vehicle data query method.

[0014] This invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the above-described vehicle data query method.

[0015] The present invention also provides a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the above-described vehicle data query method.

[0016] As can be seen, this invention receives a query request containing a target query time range; based on the query request, it searches in a mapping index file to determine the target index entry corresponding to the target query time range; wherein, the mapping index file includes index entries corresponding to each time range, and each index entry includes the offset range of the video data corresponding to each time range in the target video file, and the offset range of the bus data corresponding to each time range in the target bus file; according to the video file offset range and bus file offset range recorded in the target index entry, the corresponding target query vehicle data is read from the target video file and the target bus file. The beneficial effect of this invention is that by locating the index entry in the mapping index file, the time range can be directly mapped to the offset range of the two files. Since only one location is required, the query efficiency can be improved, and a long-term scan of the full data can be avoided.

[0017] In addition, the present invention also provides an in-vehicle data query device, equipment and readable storage medium, which also have the above-mentioned beneficial effects. Attached Figure Description

[0018] 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 only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0019] Figure 1 A flowchart of a vehicle data query method provided in an embodiment of the present invention; Figure 2 This is an overall architecture diagram of an in-vehicle data query system provided in an embodiment of the present invention; Figure 3 This is a data flow diagram of an in-vehicle data query method provided in an embodiment of the present invention; Figure 4 A flowchart for index entry generation decision-making is provided in an embodiment of the present invention; Figure 5 A flowchart of location and retrieval based on time is provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of an in-vehicle data query device provided in an embodiment of the present invention; Figure 7 This is a schematic diagram of the structure of an in-vehicle data query device provided in an embodiment of the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] During long-term operation, in-vehicle systems continuously generate video streams and bus message streams. In engineering practice, to achieve stable write performance, a common approach is to write video messages sequentially to video files and append bus messages sequentially to log files. This method has a simple write path, a low probability of error, and makes partial recovery easier if a single file is corrupted.

[0022] However, physical separation can lead to verification efficiency issues. When upper-layer applications verify by time, they need to locate segments within the same time range in both files. If they rely solely on a full scan of timestamps, the search will be slow. If they create fine-grained indexes separately, the index size will increase and the write burden will be increased.

[0023] Meanwhile, containerized single-file solutions may face risks such as complex write paths, overall unreadableness due to damage to the header or index structure caused by power failure on some embedded platforms, and insufficient flexibility in lifecycle management.

[0024] Please refer to Figure 1 , Figure 1 A flowchart illustrating a vehicle data query method provided in an embodiment of the present invention. The method may include: S101, Receive a query request containing the target query time range.

[0025] The steps in this embodiment can be performed by a designated electronic device, which may specifically be a server, a portable terminal, or other form. The query request in this embodiment includes a target query time range, thereby enabling the location of index entries based on the input target time range.

[0026] S102, based on the query request, search in the mapping index file to determine the target index entry corresponding to the target query time range; wherein, the mapping index file includes index entries corresponding to each time range, and each index entry includes the offset range of the video data corresponding to each time range in the target video file, and the offset range of the bus data corresponding to each time range in the target bus file.

[0027] The mapping index file in this embodiment can be a sparse mapping index file. Sparseness primarily refers to the fact that instead of creating index entries for every video frame or every message, the index is generated by sampling according to a set span (e.g., time span or byte span). The index entries in this embodiment record the correspondence between "a unified time period," "the physical offset range of that time period in the video file," and "the physical offset range of that time period in the bus file." This embodiment does not limit the number of target index entries obtained; for example, the number of target index entries in this embodiment can be one or multiple.

[0028] It should be further noted that, based on any of the above embodiments, before searching the mapping index file based on the query request to determine the target index entry corresponding to the target query time range, a step of constructing the mapping index file may be included, which may specifically include: S01, write the video data into the target video file in a sequential manner, in units of data blocks, and record the video data parameter information corresponding to each video data; wherein, the video data parameter information includes the position information of each video data in the target video file.

[0029] This embodiment allows for the continuous sequential writing of encoded video data to video files, organized by chunks (i.e., data blocks as units) and maintaining sequential I / O (input / output). Chunk boundaries can correspond to natural boundaries such as GOP (Group of Pictures) boundaries, fixed-duration windows, or file system cluster alignment. It is understood that in existing technologies, the generation of headers / indexes (e.g., directory tables / index tables) involves write-back (Seek) or supplementary index information during the writing process or at the end of the file. If the file is not properly closed (e.g., due to power failure), the index may be incomplete, leading to difficulties in subsequent location and even affecting overall readability / playability. The video files of this invention adopt a segmented organization method of "streaming sequential appending." A "chunk" refers to a logical data unit divided according to the natural boundaries of video encoding, using GOPs / keyframes (IDRs) as boundaries; it can also be combined with fixed-duration or fixed-byte thresholds, ending the current chunk and starting a new chunk at the next keyframe after reaching the threshold. Each chunk is appended directly to the end of the file as a continuous byte segment, and the start and end timestamps of the chunk and its starting offset / length in the video file are recorded synchronously for subsequent generation of the mapping index file. The video write path maintains sequential appending, reducing the overhead of non-sequential addressing; in the event of power failure or other abnormal situations, the preceding chunks that have been written can be preserved, and damage to the tail does not affect the reading and recovery of preceding data.

[0030] S02, write the bus data to the target bus file in append mode, and record the bus parameter information corresponding to each bus data; the bus parameter information includes the position information of each bus data in the target bus file.

[0031] This embodiment allows for continuous sequential appending of bus message records or lightweight encapsulated records to the bus file, maintaining the append-only writing characteristic. It is understood that in existing technologies, the storage format of vehicle bus data may include text logs, general databases, and binary formats with extensive encapsulation and metadata management. In embedded long-term continuous recording scenarios, the above solutions may lead to problems such as write amplification, increased CPU (central processing unit) usage, or random write increases. The bus file of this invention adopts a lightweight binary sequential append structure, appending each message to the end of the file record by record. This structure avoids complex database engine maintenance and redundant text characters, and facilitates fast retrieval through "offset range reading + local timestamp fine filtering," naturally cooperating with the bus offset boundaries in the mapped index entries, thereby supporting continuous recording of high-throughput bus data with lower CPU and IO resource consumption.

[0032] S03, when it is determined that the conditions for generating index entries are met, an index entry is generated based on all currently accumulated video data parameter information and bus parameter information, and the index entry is stored in the mapping index file.

[0033] This embodiment does not limit the specific conditions for generating index entries, as long as the conditions are not based on each timestamp. For example, the conditions for generating index entries in this embodiment could be determined by time, or by byte size. This embodiment provides a method for generating index entries based on bus data and video data, and then generating a mapping index file based on these index entries, thereby improving the accuracy of the generated mapping index file.

[0034] It should be further explained that, based on any of the above embodiments, when S03 determines that the index entry generation conditions are met, generating an index entry based on all currently accumulated video data parameter information and bus parameter information, and storing the index entry in the mapping index file, may include: S031, when it is determined that the conditions for generating an index entry are met, the start time, end time, video file offset range, bus file offset range, version, and verification field of the index entry are determined based on all currently accumulated video data parameter information and bus parameter information.

[0035] In this embodiment, the mapping index file consists of a sequence of entries. Each index entry describes a time range and its offset within two files (the video file and the bus file). The offset range refers to the position (from the start byte position to the end byte position) of newly generated data appended to the video file and bus file within the same physical time period. Assuming the index entry records a time period of 10:00:00-10:00:05, within these 5 seconds, approximately 2MB of data was written to the video file, appended to positions 100MB to 102MB. That is, the video offset range is [104857600, 106954752]. Within these 5 seconds, approximately 50KB of data was written to the bus file, appended to positions 500KB to 550KB. That is, the bus offset range is [512000, 563200]. The index entry records these two sets of numbers. (100MB = 100...) 1024 1024Byte=104857600; 500KB=500 1024 bytes = 512000). Index entries Includes the following fields: start time With end time Video file offset range Bus file offset range Version and verification fields. The entry structure can be represented as follows: Start and End Times: Define the time interval covered by this index entry. Used as the search key during queries, the algorithm compares the target time with these two fields to determine if the target falls within the entry's range. Video File Offset Range: Defines the physical location of the video data on disk corresponding to this time interval. Used as a file pointer parameter during queries, the system calls `seek` to locate the starting point and then reads the specified length of data. Bus File Offset Range: Defines the physical location of the bus data on disk corresponding to this time interval. Also used as a file pointer parameter during queries for quickly locating and reading the corresponding bus data segment, achieving a rough alignment with the video segment. Version is for backward compatibility. Future software upgrades may change the index structure (e.g., adding fields). When reading older versions of the index, compatibility processing based on the version number is required to prevent program crashes. Verification is for detecting data corruption. The in-vehicle environment carries the risk of data bit flipping due to power outages, vibrations, etc. If verification fails during reading, an alarm can be triggered promptly or a reconstruction process can be initiated to prevent the use of incorrect data.

[0036] S032, construct index entries based on the start time, end time, video file offset range, bus file offset range, version, and checksum fields of the index entries.

[0037] In this embodiment, index entries are generated at the fragment level (logically dividing a continuous data stream into time slices; the index only manages the boundaries of these slices and does not concern itself with the details inside the slices), without pursuing frame-by-frame or message-by-message mapping. The focus is on ensuring that queries can be quickly narrowed down to a scannable local range (because the index itself is small (sparse) and can be loaded into memory and retrieved within milliseconds). The search results directly give the physical file pointer range of the data (e.g., "read from 100MB to 102MB"). Reading this 2MB of data only takes tens of milliseconds, which is a thousand times smaller than scanning several GB of files. As a fixed layout example, index entries may also include the offset of the video chunk. Offset range = [Start_Offset, End_Offset]. Offset usually refers to Start_Offset. The offset range describes the interval using two absolute positions, while Offset + Size describes the interval using "start point + length". They are mathematically equivalent, just expressed differently. Fields include size (used for read control, telling the file system driver "this Read instruction will only read this many bytes"), bus offset start and end, etc. When generation conditions are met (e.g., time span meets requirements, data volume meets requirements, or a critical event occurs), the currently accumulated video chunk time range and offset information, as well as the appended offset range of the bus file within the same time period, are encapsulated into an index entry. The information is then written to the mapping index file. This embodiment provides specific information about the index entries, improving the accuracy of index entry generation.

[0038] It should be further explained that, based on any of the above embodiments, before generating index entries based on all currently accumulated video data parameter information and bus parameter information and storing the index entries in the mapped index file, when it is determined in S03 that the index entry generation conditions are met, the process may further include: determining the index entry generation conditions based on a limited maximum delay, a limited index size, and video keyframe coverage conditions; wherein, the limited maximum delay is determined by the upper limit of the time span, the limited index size is determined by the upper limit of the byte span and the upper limit of the time span, and the video keyframe coverage conditions are determined by the keyframe identifier. In this embodiment, the index entry generation conditions are jointly determined by three conditions, respectively controlling the maximum delay (controlled by the upper limit of the time span), the index size (controlled by the upper limit of the byte span and the upper limit of the time span; the upper limit of the time span determines the generation frequency of index entries (not too dense), while the upper limit of the byte span mainly prevents the amount of data covered by a single index from being too large. It is precisely because of these two thresholds (rather than generating for every frame) that the number of index entries is kept at a sparse level, thereby controlling the overall size of the index file), and keyframe coverage (controlled by the keyframe identifier). ;in: This represents the time span since the previous entry. This is the upper limit of the time (typically 5-10 seconds), used to control the worst-case positioning span. This is the increment in bytes written to the video file since the previous entry (or the larger of the increments for the video and bus files). This is the upper limit in bytes (typically 1-4MB), used to control the size of the file range covered by the entry. This serves as a keyframe marker for the video, ensuring that entry boundaries are aligned with the GOP start point to support random access. Use it as an event trigger flag to ensure that critical events are indexed independently or with priority. This is a logical OR or logical AND operation. When `emit` is true, the system encapsulates the current time range and the current offsets of the two files into an entry and appends it to the index file. This strategy ensures that the index is only generated when the sparsity threshold is reached and a suitable cut point (keyframe) is encountered, guaranteeing both sparsity and decodability after location; it also handles sudden events through... Enables real-time indexing.

[0039] It should be further noted that, based on any of the above embodiments, the video data parameter information determined above includes at least the start and end timestamps of the video data and the start offset of the video data in the target video file; the bus parameter information determined includes at least the bus message timestamp, bus message identifier, flag bits, data length code, and data payload. In this embodiment, the video file adopts a sequential write mode. The system writes and records the time range and offset information of the chunk in units of chunks: ;in: Chunk number; For the start and end timestamps of the chunk; This is the starting offset of the chunk in the video file. The `chunk_id` and `size` are the number of bytes in a chunk. While `chunk_id` and `size` can be omitted or derived, the start and end times and the starting offset are essential core information. If stored strictly in sequence, `chunk_id` can be implicit (the Nth chunk is ID=N), and `size` can be calculated by subtracting the current offset from the next offset. Additional information such as whether it's a keyframe or the encoding type can be added to facilitate rapid filtering. `chunk_id` is used for continuity checks. After a query jump, reading this field confirms whether the correct logical block has been reached, preventing "read misalignment" caused by file truncation or overwriting. The start and end times are used for timeline mapping. This is the foundation for building a "time->space" index; the index generator generates sparse index entries by aggregating this time information. The starting offset is used for physical positioning. The query module needs this offset to call the `seek()` function to move the file pointer to the correct position to begin reading. The number of bytes in a chunk is used for boundary control. During partial reads, it tells the system "how many bytes to read before stopping," preventing over-boundary reading into the next chunk. In this embodiment, the bus file uses an append-only writing mode. As an example of implementable record organization, each message is appended in a fixed format: ;in: The message timestamp (8 bytes). This is the message identifier (4 bytes). This is a flag bit (1 byte, indicating standard frame / extended frame, CAN / CAN-FD and BRS / ESI and other extended information). The data length code is 1 byte. The data payload (0-8 bytes for classic CAN, 0-64 bytes for CAN-FD) is used by the parser. During the data parsing phase, the parser must first read the flags to determine the format for parsing subsequent data (e.g., determining whether it's a standard or extended frame to decide whether the ID should be 11 or 29 bits; determining whether it's CAN or CAN-FD to decide whether the data length is 8 or 64 bytes). Without this flag, subsequent data cannot be read correctly. The data length code (1 byte) indicates the number of valid bytes in the subsequent data field. During parsing, the program needs to determine how many bytes to read next based on the DLC value (e.g., DLC=8). When the data payload is fixed at 64 bytes (or 8 bytes according to classic CAN), (if there is no fixed padding, a TotalLength field must be added to the header of each record. During parsing, this length field is read first, and then the record is skipped directly to the beginning of the next record based on the length, achieving chained reading), the fixed record length facilitates offset calculation and binary search positioning (when a fine range needs to be defined in an "unindexed" area (e.g., within a 1-minute data block located by a sparse index), or when the index is lost and a specific time point needs to be found directly from the original file, fixed-length records allow binary search based on the file size). If variable-length payloads or compressed encapsulation are used, sequential parsing can also be achieved by adding a length field to the record header. The bus writer maintains the current file offset position after appending a record and uses this offset as the bus offset boundary of the entry when the index generation conditions are met. This embodiment provides the specific content of video data parameter information and bus parameter information, improving the accuracy of video parameter and bus parameter determination.

[0040] S103, based on the video file offset range and bus file offset range recorded in the target index entry, read the corresponding target query vehicle data from the target video file and the target bus file.

[0041] In this embodiment, based on the input target query time range, the index entry covering that time is located in the mapping index file. The offset range between the two files is output and a local read is performed. Then, precise positioning is performed within the local range to obtain the target query vehicle video data and vehicle bus data. The vehicle video data and vehicle bus data are then used as the target query vehicle data. In this embodiment, the vehicle video data and vehicle bus data obtained from the target query vehicle data are time-aligned data.

[0042] It should be further explained that, based on any of the above embodiments, the above-mentioned reading of the corresponding target query vehicle data from the target video file and the target bus file according to the video file offset range and bus file offset range recorded in the target index entry may include: S1031, Obtain the set of target index entries determined based on the start and end time points of the target query time range; The target query time range in this embodiment is: The index entries are incremented by time; the first one that satisfies the condition is located first. The index entries are read forward until the index is covered. This yields the set of target index entries that cover the query range.

[0043] S1032, Based on the time range, video data offset range and bus data offset position recorded for each target index entry in the target index entry set, determine the approximate position of the current time range in the target video file and the target bus file; In this embodiment, the target index entry can provide an intra-segment linear mapping approximation (the linear mapping approximation is applied to the "time-file offset" mapping in this scheme, based on the assumption that "the data generation rate is uniform in a short time." For example, if 5MB of data is written in 5 seconds, it is highly likely that it will be written at the 2.5MB position at the 2.5-second mark. Although the video is variable bitrate (VBR), within a very short slice (such as a GOP), the error caused by treating it as linear growth is usually within an acceptable range (a deviation of a few frames)). This approximation is used to map time points to offset points to reduce scan length. Because through approximate mapping, an "estimated file pointer position" can be directly calculated (e.g., jumping directly to the middle of a chunk), and then keyframes can be found starting from this estimated position. Compared to "scanning frame by frame from the beginning of a chunk to the target position," this "jumping directly to the middle" operation significantly reduces the reading and decoding of invalid data, thereby reducing scan length and IO time. Taking video as an example, the approximate mapping can be expressed as: ; For the target time The corresponding video file's estimated offset. For the current index entry The starting offset of the recorded video. For the current index entry End offset of the recorded video. For the current index entry The start time of the record. For the current index entry The end time of the record. The target time point for the query entered by the user. It can sometimes degenerate into direct taking. This approximation is applicable to coarse jump positioning.

[0044] S1033, Starting from the approximate position, determine the frame-level timestamps in the target video file and the target bus file that correspond to the current time range; In this embodiment, after coarse jump positioning, the precise location is determined by the timestamp of subsequent parsed frames; therefore, variable bitrate has no impact on the final positioning accuracy. Bus files can also use the same method for approximate jumps, followed by precise filtering using message timestamps.

[0045] S1034, determine the vehicle video data and vehicle bus data based on the frame-level timestamp, and use the vehicle video data and vehicle bus data as the target to query the vehicle data.

[0046] This embodiment provides a unified virtual fusion query interface to the outside world: ; This indicates the binary video data block returned by the query. This indicates that the structured bus record list returned by the query allows the application layer to obtain time-aligned video clips and bus clips with a single Query call, just like reading a merged file.

[0047] It should be further noted that, based on any of the above embodiments, after receiving a query request containing a target query time range, the process may further include: Step 1: When it is determined that the mapping index file is corrupted, the target video file is scanned at the first preset data volume interval to determine the timestamp of the first video keyframe and the timestamp of the second video keyframe; wherein, the first video keyframe and the second video keyframe are adjacent video keyframes. Step 2: Determine the reconstruction time range and the offset range of the reconstructed video data based on the timestamps of the first and second video keyframes; Step 3: Read the target bus file at the second preset data interval to determine the offset range of the reconstructed bus data corresponding to the reconstruction time range; Step 4: Determine the reconstruction index entries based on the reconstruction time range, the offset range of the reconstructed video data, and the offset range of the reconstructed bus data, and append the reconstruction index entries to the target mapping index file.

[0048] In this embodiment, when the index file is missing or corrupted, the system can reconstruct the index by extracting sparse timestamps from two files. Timestamps and offsets are obtained by parsing the container index or scanning keyframe boundaries. Bus-side reconstruction extracts message timestamps and offsets through sequential scanning or sampling at fixed steps. Subsequently, based on the video segment time range, the system searches for the corresponding offset range in the bus sampling points or index points (here, "index points" refers to the temporarily generated memory index nodes during reconstruction (i.e., the scanned timestamp-offset pairs), not the index points of the corrupted old file on the hard drive) and generates entries. The reconstructed entries remain sparse (during reconstruction scanning, it is not a byte-by-byte scan, but a skip-scan scan. For example, the video only records I-frame positions (which are inherently sparse), and the bus records a time point only every fixed byte (e.g., 1MB). The reconstructed index entries are generated only based on these sparse sampling points, so the generated index is naturally sparse), ensuring the recovery process is controllable and reducing additional storage burden. Because the three files are independent, the bus file can still be read even if the video file is corrupted, the video file can still be played even if the bus file is corrupted, and the mapping relationship can be rebuilt even if the index file is corrupted. Overall, its fault tolerance is stronger than that of physical reconstruction schemes. For ease of understanding, consider the following example: Open the video file `video.dat`, scan the video, and search for an I-frame every 10MB of data read. Assume an I-frame is found at Offset=100MB with a timestamp of 10:00:00; the next I-frame is found at Offset=102MB with a timestamp of 10:00:05. Record this interval. Open the bus file `bus.dat`, scan the bus, and read data in a skipping manner (e.g., every 100KB). It is found that the timestamp at Offset=500KB is 09:59:59, and the timestamp at Offset=550KB is 10:00:06. Based on the video's time (10:00:00-10:00:05), interpolation or fine-tuning is performed on the bus scan results to determine that the bus's corresponding offset range is approximately 501KB-548KB. This information (10:00:00-10:00:05, Video: 100-102MB, Bus: 501-548KB) is then encapsulated into an index entry and appended to a new index.idx file (mapping index file).

[0049] This invention provides a method for querying vehicle data, which may include: S101, receiving a query request containing a target query time range; S102, searching in a mapping index file based on the query request to determine the target index entry corresponding to the target query time range; wherein, the mapping index file includes index entries corresponding to each time range, and each index entry includes the offset range of video data corresponding to each time range in the target video file and the offset range of bus data corresponding to each time range in the target bus file; S103, reading the corresponding target query vehicle data from the target video file and the target bus file according to the video file offset range and bus file offset range recorded in the target index entry. The mapping index file in this invention is a sparse mapping index across files, with each index entry based on a time period, simultaneously recording the offset range boundaries of that time period in the video file and the bus file. During querying, only one location is needed in the mapping index file to simultaneously obtain the candidate reading intervals of both files, and then precise timestamp parsing and filtering are performed within the local interval to complete alignment, making the location during verification faster and avoiding long-term scanning of the full data.

[0050] For a clearer understanding of this invention, please refer to the following details. Figure 2 , Figure 2 The overall architecture diagram of an in-vehicle data query system provided in this embodiment of the invention may specifically include: a writing module, an index generation module, a query module, and an index reconstruction module.

[0051] The write module writes to the video file and records the timestamp and offset information of the chunk boundaries. It also writes to the bus file and records the current append offset position. Chunk boundaries define the data segments within the video file. Each chunk is a contiguous block of data in the video file, located by both the timestamp and the file offset. Specifically, chunk boundary information includes: timestamp: the start time of the chunk on the timeline (relative to the entire video stream); offset: the starting byte position of the chunk in the video file; and size: the data length of the chunk (calculated from the offsets of adjacent chunks). Figure 3This is a data flow diagram illustrating an in-vehicle data query method provided in an embodiment of the present invention. The "video writing" module transmits key information of the video data (such as timestamps and keyframe positions) to the index generation module. The "bus writing" module simultaneously transmits bus data and its location information to the index generation module. The index generation module integrates these two types of information, generates a mapping relationship, and writes / updates it to a central mapping index file. When querying by time, this module first searches the "mapping index file" and determines the corresponding offset range information based on the mapping index file. Precise data segments are then read from the video file and bus file according to the offset range. Finally, the read video and bus data undergo time synchronization and fusion processing.

[0052] Index generation module: Generates index entries and appends them to the index file when the sparse generation conditions are met.

[0053] Query module: Based on the input target time range, locate the entries covering that time in the index file, output the offset range between the two files and perform a local read, and then perform precise positioning and filtering within the local range.

[0054] When the index file is missing or corrupted, the index reconstruction module reconstructs sparse entries from the video timestamp and bus timestamp, and supports fault tolerance processing for breakpoints and corrupted segments.

[0055] The module collaboration process may include: During the writing phase, the video writer and the bus writer work in parallel. After each chunk is written, the video writer pushes the chunk's time range and offset information (the offset relative to the start position of the video file) to the index generation module; the bus writer maintains the current offset position (the offset relative to the start position of the bus file) while continuously appending data. Upon receiving the chunk information, the index generation module determines whether the generation conditions are met (for example, triggering conditions typically involve one of two conditions: a certain amount of time has elapsed since the last index write (e.g., 5 seconds); or the cumulative amount of data written since the last index write is large enough (e.g., 2MB). After triggering, the index is usually not written immediately, but waits until the next video keyframe (I-frame / IDR) boundary before being written to disk, allowing subsequent decoding by index skipping. If there are critical events such as collisions / alarms, an index can be forcibly written directly for quick post-event location). If the conditions are met, the entry is encapsulated and appended to the index file. This process is asynchronous with data writing to avoid blocking the main write path. Each chunk is determined by the video encoding keyframe (GOP) boundary or a preset fixed duration (e.g., 1 second). Video files are physically composed of sequentially concatenated chunks. A chunk is the smallest physical unit of a video stream on a storage medium. For better understanding, please refer to [link to documentation / reference]. Figure 4 , Figure 4 This invention provides a flowchart for index entry generation decision-making. This embodiment is based on keyframes... and Key events are used as conditions for generating index entries.

[0056] During the query phase, the query and positioning module first locates entries in the index file by time. After obtaining the offset range between the video and the bus, it reads the corresponding segments from both data files, performs precise timestamp matching within a local range, and outputs the alignment result. For easier understanding, please refer to [link / reference needed]. Figure 5 , Figure 5 This invention provides a flowchart for time-based query positioning and reading. Specifically, it includes: Query Initiation: The process begins with the "upper-layer application," which sends a specific time range query request to the system. Index Retrieval: The query request is first sent to the "index file." Based on the index file (i.e., the mapping index file mentioned above), the system quickly searches according to the time range and returns the covered entries and offset ranges. The key returned information here is twofold: the offset range of the target data in the video file and the offset range of the target data in the bus file. Parallel Data Reading and Fine Processing: After obtaining the offset range, the system simultaneously executes two parallel data acquisition pipelines: Video Data Processing Line: Based on the returned video offset range, the system "reads the video offset range and performs fine positioning." This means the system jumps to a specified location in the video file to read a data block and performs a fine-grained scan within that data block based on precise frame timestamps, ultimately extracting the video segment that perfectly meets the time requirements. Bus Data Processing Line: Similarly, based on the bus offset range, the system "reads the bus offset range and performs fine filtering." It reads messages from a specified segment of the bus file and filters and selects based on the high-precision timestamps of the messages to obtain precise bus segments. Finally, the video clips and bus clips are aligned.

[0057] During the reconstruction phase, the index reconstruction module is triggered when the query module detects a missing index file (checked via the file system interface; when the system starts or queries, it attempts to access the path of the index file; if it returns a "file does not exist" error code, it is determined to be missing) or a verification failure (usually occurring during abnormal power outages, disk bad sectors, or incomplete writes, resulting in corrupted file header metadata or truncated file tails). The reconstruction module scans the keyframe boundaries of the video file (identifying data packets with the type identifier I-frame by parsing the binary bitstream format of the video stream (such as the NAL Unit Header of the H.264 / H.265 standard; alternatively, a custom frame header can be added and recorded in the frame header; the keyframe boundary refers to the starting byte offset of the keyframe data in the video file. This is the physical starting point of this segment of video data) and the timestamp sequence of the bus file, regenerates sparse entries after time alignment, and writes them to the index file.

[0058] The beneficial effects of the embodiments of the present invention are as follows: 1. Physical separation of video and bus maintains a simple and stable sequential write path, reducing the cost of modifying the write end and the risk of anomalies, while also making it easier to retain remaining usable data when some files are corrupted.

[0059] 2. While the video and bus are written sequentially in a physically separate manner, a mapping index file is generated. This index file directly maps the time range to the offset range of the two files, making location during verification faster and avoiding lengthy scanning of the entire dataset. Furthermore, logical fusion reading is achieved, so the upper layer is unaware of the underlying physical separation.

[0060] 3. The index entry generation strategy is a joint control strategy that considers time span, byte span and key point coverage, so as to maintain a controllable balance between index size and positioning accuracy and adapt to different devices and different data volume scenarios.

[0061] 4. Employing a hierarchical positioning process combining coarse jumps and fine filtering, it can still quickly locate and output aligned segments even under sparse index conditions, improving the upper-level interactive experience. Within each index entry, it provides approximate intra-segment mapping combined with precise timestamp filtering, enabling rapid positioning even under sparse index conditions, thus achieving a hierarchical positioning process combining coarse jumps and fine positioning.

[0062] 5. The index supports reconstruction and fault tolerance, improving recoverability and fault tolerance in the event of index loss or damage, and reducing the risk of missing evidence chains due to index loss or damage.

[0063] The following describes the vehicle data query device provided in the embodiments of the present invention. The vehicle data query device described below and the vehicle data query method described above can be referred to each other.

[0064] Please refer to the details. Figure 6 , Figure 6 A schematic diagram of the structure of an in-vehicle data query device provided in an embodiment of the present invention may include: The query request determination module 100 is used to receive a query request containing a target query time range; The target index entry determination module 200 is used to search in the mapping index file based on the query request to determine the target index entry corresponding to the target query time range; wherein, the mapping index file includes index entries corresponding to each time range, and each index entry includes the offset range of video data corresponding to each time range in the target video file, and the offset range of bus data corresponding to each time range in the target bus file; The vehicle data determination module 300 is used to read the corresponding target query vehicle data from the target video file and the target bus file based on the video file offset range and bus file offset range recorded in the target index entry.

[0065] Furthermore, based on any of the above embodiments, the above-mentioned vehicle data query device may further include: The video data parameter information determination module is used to write video data into the target video file in a sequential manner, in units of data blocks, and record the video data parameter information corresponding to each video data; wherein, the video data parameter information includes the position information of each video data in the target video file; The bus parameter information determination module is used to write bus data into the target bus file in an append-only mode and record the bus parameter information corresponding to each bus data; the bus parameter information includes the position information of each bus data in the target bus file; The mapping index file determination module is used to determine that when the conditions for generating index entries are met, generate index entries based on all currently accumulated video data parameter information and bus parameter information, and store the index entries in the mapping index file.

[0066] Furthermore, based on any of the above embodiments, the mapping index file determination module may include: The index entry information determination unit is used to determine the start time, end time, video file offset range, bus file offset range, version, and verification field of the index entry based on all currently accumulated video data parameter information and bus parameter information when the index entry generation conditions are met. The index entry determination unit is used to construct the index entry based on the start time, end time, video file offset range, bus file offset range, version, and verification field of the index entry.

[0067] Furthermore, based on any of the above embodiments, the above-mentioned vehicle data query device may further include: An index entry generation condition-driven module is used to determine the index entry generation conditions based on a limited maximum delay, a limited index size, and video keyframe coverage conditions; wherein, the limited maximum delay is determined by an upper limit of the time span, the limited index size is determined by an upper limit of the byte span and the upper limit of the time span, and the video keyframe coverage conditions are determined by keyframe identifiers.

[0068] Furthermore, based on any of the above embodiments, the video data parameter information is determined to include at least the start and end timestamps of the video data and the start offset of the video data in the target video file; the bus parameter information is determined to include at least the bus message timestamp, bus message identifier, flag bit, data length code, and data payload.

[0069] Furthermore, based on any of the above embodiments, the vehicle data determination module 300 may include: The target index entry set determination unit is used to obtain a target index entry set determined based on the start time point and end time point of the target query time range; An approximate position determination unit is used to determine the approximate position of the current time range in the target video file and the target bus file based on the time range, video data offset range and bus data offset position recorded for each target index entry in the target index entry set; A frame-level timestamp determination unit is used to determine, starting from the approximate position, the frame-level timestamps in the target video file and the target bus file corresponding to the current time range; The target query vehicle data determination unit is used to determine vehicle video data and vehicle bus data based on the frame-level timestamp, and to use the vehicle video data and vehicle bus data as the target query vehicle data.

[0070] Furthermore, based on any of the above embodiments, the above-mentioned vehicle data query device may further include: The video keyframe determination module is used to scan the target video file at a first preset data interval when the mapping index file is corrupted, and determine the timestamps of the first and second video keyframes; wherein the first and second video keyframes are adjacent video keyframes. The video data offset range determination module is used to determine the reconstruction time range and the offset range of the reconstructed video data based on the timestamps of the first and second video keyframes. The bus data offset range determination module is used to read the target bus file at a second preset data volume interval and determine the offset range of the reconstructed bus data corresponding to the reconstruction time range. The reconstruction index entry module is used to determine reconstruction index entries based on the reconstruction time range, the offset range of the reconstruction video data, and the offset range of the reconstruction bus data, and to append the reconstruction index entries to the target mapping index file.

[0071] It should be noted that the order of the modules and units in the above-mentioned vehicle data query device can be changed without affecting the logic.

[0072] An embodiment of the present invention provides a vehicle-mounted data query device, which may include: a query request determination module 100, used to receive a query request containing a target query time range; a target index entry determination module 200, used to search in a mapping index file based on the query request to determine a target index entry corresponding to the target query time range; wherein, the mapping index file includes index entries corresponding to each time range, and each index entry includes the offset range of video data corresponding to each time range in a target video file and the offset range of bus data corresponding to each time range in a target bus file; and a vehicle-mounted data determination module 300, used to read the corresponding target query vehicle-mounted data from the target video file and the target bus file according to the video file offset range and bus file offset range recorded in the target index entry. The mapping index file in this invention is a sparse mapping index across files, and each index entry is in units of time periods, while simultaneously recording the offset range boundaries of that time period in the video file and the bus file. During a query, only one location needs to be found in the mapping index file to obtain the candidate reading range of both files simultaneously. Then, precise timestamp parsing and filtering are performed within the local range to complete the alignment, making the location during verification faster and avoiding long-term scanning of the full data.

[0073] The following is an introduction to an in-vehicle data query device provided by an embodiment of the present invention. The in-vehicle data query device described below can be referred to in correspondence with the in-vehicle data query method described above.

[0074] Please refer to Figure 7 , Figure 7 A schematic diagram of the structure of an in-vehicle data query device provided in an embodiment of the present invention may include: Memory 10 is used to store computer programs; The processor 20 is used to execute computer programs to implement the above-described vehicle data query method.

[0075] The memory 10, processor 20, and communication interface 30 all communicate with each other through the communication bus 40.

[0076] In this embodiment of the invention, the memory 10 is used to store one or more programs. The programs may include program code, which includes computer operation instructions. In this embodiment of the invention, the memory 10 may store programs for implementing the following functions: Receive query requests containing the target query time range; Based on the query request, a search is performed in the mapping index file to determine the target index entry corresponding to the target query time range; wherein, the mapping index file includes an index entry corresponding to each time range, and each index entry includes the offset range of the video data corresponding to each time range in the target video file, and the offset range of the bus data corresponding to each time range in the target bus file; Based on the video file offset range and bus file offset range recorded in the target index entry, read the corresponding target query vehicle data from the target video file and the target bus file.

[0077] In one possible implementation, the memory 10 may include a program storage area and a data storage area, wherein the program storage area may store the operating system and applications required for at least one function; and the data storage area may store data created during use.

[0078] Furthermore, memory 10 may include read-only memory and random access memory, providing instructions and data to the processor. A portion of the memory may also include NVRAM. The memory stores operating systems and operating instructions, executable modules, or data structures, or subsets thereof, or extended sets thereof, wherein the operating instructions may include various operating instructions for implementing various operations. The operating system may include various system programs for implementing various basic tasks and handling hardware-based tasks.

[0079] Processor 20 can be a central processing unit (CPU), an application-specific integrated circuit, a digital signal processor, a field-programmable gate array, or other programmable logic device. Processor 20 can be a microprocessor or any conventional processor. Processor 20 can call programs stored in memory 10.

[0080] The communication interface 30 can be an interface for the communication module, used to connect with other devices or systems.

[0081] Of course, it should be noted that, Figure 7The structure shown does not constitute a limitation on the vehicle data query device in the embodiments of the present invention. In practical applications, the vehicle data query device may include more than Figure 7 More or fewer components as shown, or combinations of certain components.

[0082] The following describes the computer-readable storage medium provided in the embodiments of the present invention. The computer-readable storage medium described below can be referred to in correspondence with the vehicle data query method described above.

[0083] The present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the above-described vehicle data query method.

[0084] The computer-readable storage medium may include various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0085] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0086] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0087] Finally, it should be noted that in this document, relationships such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0088] The present invention provides a detailed description of an in-vehicle data query method, apparatus, device, and readable storage medium. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, those skilled in the art will recognize that, based on the ideas of the present invention, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method for querying vehicle-mounted data, characterized in that, include: Receive query requests containing the target query time range; Based on the query request, a search is performed in the mapping index file to determine the target index entry corresponding to the target query time range; wherein, the mapping index file includes an index entry corresponding to each time range, and each index entry includes the offset range of the video data corresponding to each time range in the target video file, and the offset range of the bus data corresponding to each time range in the target bus file; Based on the video file offset range and bus file offset range recorded in the target index entry, the corresponding target query vehicle data is read from the target video file and the target bus file.

2. The vehicle data query method according to claim 1, characterized in that, Before searching the mapping index file based on the query request to determine the target index entry corresponding to the target query time range, the process further includes: The video data is written to the target video file in a sequential manner, in units of data blocks, and the video data parameter information corresponding to each video data is recorded; wherein, the video data parameter information includes the position information of each video data in the target video file; Bus data is written to the target bus file in append mode, and bus parameter information corresponding to each bus data is recorded; the bus parameter information includes the position information of each bus data in the target bus file; When the conditions for generating an index entry are met, an index entry is generated based on all currently accumulated video data parameter information and bus parameter information, and the index entry is stored in the mapping index file.

3. The vehicle data query method according to claim 2, characterized in that, When the conditions for generating an index entry are met, an index entry is generated based on all currently accumulated video data parameter information and bus parameter information, and the index entry is stored in the mapping index file, including: When it is determined that the conditions for generating an index entry are met, the start time, end time, video file offset range, bus file offset range, version, and verification field of the index entry are determined based on all currently accumulated video data parameter information and bus parameter information. The index entry is constructed based on the start time, end time, video file offset range, bus file offset range, version, and verification field of the index entry.

4. The vehicle data query method according to claim 2, characterized in that, Before generating index entries based on all currently accumulated video data parameter information and bus parameter information, and storing the index entries in the mapping index file, the process further includes: The index entry generation conditions are determined based on a limited maximum latency, a limited index size, and video keyframe coverage conditions; wherein the limited maximum latency is determined by an upper limit of the time span, the limited index size is determined by an upper limit of the byte span and the upper limit of the time span, and the video keyframe coverage conditions are determined by keyframe identifiers.

5. The vehicle data query method according to claim 2, characterized in that, The video data parameter information is determined to include at least the start and end timestamps of the video data and the start offset of the video data in the target video file; the bus parameter information is determined to include at least the bus message timestamp, bus message identifier, flag bits, data length code, and data payload.

6. The vehicle data query method according to any one of claims 1 to 5, characterized in that, Based on the video file offset range and bus file offset range recorded in the target index entry, read the corresponding target query vehicle data from the target video file and the target bus file, including: Obtain the set of target index entries determined based on the start and end time points of the target query time range; Based on the time range, video data offset range, and bus data offset position recorded for each target index entry in the target index entry set, the approximate position of the current time range in the target video file and the target bus file is determined; Starting from the approximate position, determine the frame-level timestamps in the target video file and the target bus file that correspond to the current time range; The in-vehicle video data and in-vehicle bus data are determined based on the frame-level timestamp, and the in-vehicle video data and in-vehicle bus data are used as the target query in-vehicle data.

7. The vehicle data query method according to claim 1, characterized in that, After receiving a query request containing the target query time range, the process also includes: When it is determined that the mapping index file is corrupted, the target video file is scanned at a first preset data volume interval to determine the timestamp of the first video keyframe and the timestamp of the second video keyframe; wherein, the first video keyframe and the second video keyframe are adjacent video keyframes. The reconstruction time range and the offset range of the reconstructed video data are determined based on the timestamps of the first and second video keyframes. Read the target bus file at a second preset data interval to determine the offset range of the reconstruction bus data corresponding to the reconstruction time range; Based on the reconstruction time range, the offset range of the reconstructed video data, and the offset range of the reconstructed bus data, reconstruction index entries are determined and appended to the target mapping index file.

8. A vehicle-mounted data query device, characterized in that, include: The query request determination module is used to receive query requests that contain a target query time range; The target index entry determination module is used to search in the mapping index file based on the query request to determine the target index entry corresponding to the target query time range; wherein, the mapping index file includes index entries corresponding to each time range, and each index entry includes the offset range of video data corresponding to each time range in the target video file, and the offset range of bus data corresponding to each time range in the target bus file; The vehicle data determination module is used to read the corresponding target query vehicle data from the target video file and the target bus file based on the video file offset range and bus file offset range recorded in the target index entry.

9. A vehicle-mounted data query device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the vehicle data query method as described in any one of claims 1 to 7.

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

Images