Data processing method and device, electronic equipment and storage medium
By constructing and compressing CAN signal data packets, the problems of excessively large CAN signal log file size and low efficiency of traditional log acquisition are solved, achieving efficient and accurate signal acquisition and cross-platform compatibility.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-15
- Publication Date
- 2026-03-24
AI Technical Summary
Existing CAN signal log storage methods result in excessively large log file sizes, consuming significant storage resources and being prone to data loss. Furthermore, traditional log acquisition methods are complex to operate and inefficient, affecting the accuracy and completeness of signal analysis.
Data packets are constructed by acquiring CAN signals, and a block header is generated based on the write time range, frame count, CAN ID range, and offset index. The data packets are then compressed and stored in the queue cache to achieve cross-SoC compatibility.
Reduce storage space usage, improve signal acquisition efficiency and accuracy, address cross-SoC compatibility issues, reduce log loss risk, and simplify operation processes.
Smart Images
Figure CN121727883A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of data processing, and more specifically, to a data processing method, apparatus, electronic device, and storage medium. Background Technology
[0002] With the rapid development of intelligent vehicles and vehicle-to-everything (V2X) technologies, in-vehicle infotainment systems need to process and forward a large number of CAN (Controller Area Network) bus signals in real time to provide critical data support for upper-layer applications. These signals not only involve vehicle operating status and powertrain control, but also include multiple functional modules such as driver assistance systems and in-vehicle entertainment systems. During research, development, testing, and maintenance, developers must be able to efficiently and accurately analyze the accuracy and timeliness of CAN signal transmission to ensure the stability and reliability of the in-vehicle infotainment system.
[0003] Currently, signal debugging and troubleshooting within vehicle infotainment systems often rely on link layer logs. However, existing methods typically store CAN signals as strings. While intuitive, this leads to excessively large log files, consuming significant storage and bandwidth resources, and is prone to log loss, resulting in incomplete recording of critical system information. This not only increases the difficulty of debugging and reproducing intermittent problems but also poses a serious challenge to system iteration, optimization, and stability verification.
[0004] On the other hand, traditional CAN bus log collection methods mainly rely on external hardware devices, such as CANoe and TSMaster. These methods require manual wiring for data collection, which is complex and inefficient. Furthermore, the collected logs often cannot be strictly aligned with the vehicle's internal timestamps, leading to deviations in subsequent signal analysis. Additionally, manual operation can result in omissions and errors, further affecting the accuracy and completeness of the log data. Summary of the Invention
[0005] The purpose of this invention is to provide a data processing method, apparatus, electronic device, and storage medium that enables CAN signals to achieve cross-SoC compatibility.
[0006] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows: In a first aspect, embodiments of this application provide a data processing method, the method comprising: Acquire multiple CAN signals; Multiple data packets are constructed based on each of the aforementioned CAN signals, wherein the data packets include multiple CAN signals; Based on each CAN signal in the data packet, determine the write time range, frame count, CANID range, and offset index of the data packet; The packet header is constructed based on the write time range, frame count, CAN ID range, and offset index of the packet. The data packet is compressed based on the block header and each of the CAN signals to obtain a compressed data packet; The compressed data packets are stored in the queue cache.
[0007] In an optional implementation, the method further includes: Determine the total data volume of each of the compressed data packets; Compare the total data volume with the preset data volume; When the total data volume exceeds the preset data volume, each of the compressed data packets is deleted.
[0008] In an optional implementation, the step of deleting each of the compressed data packets when the total data volume exceeds the preset data volume includes: When the total data volume is greater than the preset data volume, the system time of each compressed data packet is determined; Determine the longest system time from each of the system time intervals; Determine the compressed data packet corresponding to the longest system time and delete it.
[0009] In an optional implementation, the step of compressing the data packet based on the block header and each of the CAN signals to obtain a compressed data packet includes: The CAN signals in the data packet are spliced together to obtain the spliced CAN signal; The header and the spliced CAN signal are compressed and encrypted to obtain a compressed data packet.
[0010] In an optional implementation, the method further includes: Determine the capacity of the queue buffer; Determine the number of frames of cached data in the queue buffer; When the number of frames exceeds the capacity, the compressed data packets are flushed.
[0011] In an optional implementation, the method further includes: Determine the time of the last write operation; Determine the current time; Determine the time interval between the last write operation and the current time; Compare the time interval with a preset time interval; When the time interval is greater than or equal to the preset time interval, the compressed data packet is flashed.
[0012] In an optional implementation, the step of determining the write time range of the data packet based on each CAN signal in the data packet includes: Determine the system time and network time of each of the CAN signals; The write time range of the data packet is determined based on the system time and network time of each of the CAN signals.
[0013] Secondly, embodiments of this application provide a data processing apparatus, the apparatus comprising: The acquisition module is used to acquire multiple CAN signals; A determining module is configured to construct multiple data packets based on each of the CAN signals, wherein the data packets include multiple CAN signals; determine the write time range, frame count, CANID range, and offset index of the data packets based on each CAN signal in the data packets; construct the block header of the data packets based on the write time range, frame count, CAN ID range, and offset index; and compress the data packets based on the block header and each of the CAN signals to obtain a compressed data packet. The storage module is used to store the compressed data packets into the queue cache.
[0014] Thirdly, embodiments of this application provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the data processing method.
[0015] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the data processing method.
[0016] This application has the following beneficial effects: This application acquires multiple CAN signals and constructs multiple data packets based on each CAN signal. Each data packet includes multiple CAN signals. Based on each CAN signal in the data packet, the write time range, frame count, CAN ID range, and offset index of the data packet are determined. A block header of the data packet is constructed based on the write time range, frame count, CAN ID range, and offset index. The data packets are compressed based on the block header and each CAN signal to obtain compressed data packets. Each compressed data packet is stored in a queue buffer. This reduces storage space usage and addresses the shortcomings of existing CAN log acquisition schemes in cross-SoC compatibility. Attached Figure Description
[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0018] Figure 1 A block diagram of an electronic device provided in an embodiment of the present invention; Figure 2 This is one of the flowcharts illustrating a data processing method provided in an embodiment of the present invention; Figure 3 A second schematic flowchart of a data processing method provided in an embodiment of the present invention; Figure 4 A third schematic flowchart of a data processing method provided in an embodiment of the present invention; Figure 5 The fourth schematic flowchart of a data processing method provided in an embodiment of the present invention; Figure 6 The fifth flowchart illustrates a data processing method provided in an embodiment of the present invention. Figure 7 A flowchart illustrating a data processing method provided in an embodiment of the present invention is shown in Figure 6. Figure 8 The seventh flowchart of a data processing method provided in an embodiment of the present invention; Figure 9 This is a structural block diagram of a data processing device provided in an embodiment of the present invention. Detailed Implementation
[0019] 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. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.
[0020] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.
[0021] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.
[0022] In the description of this invention, it should be noted that if terms such as "upper," "lower," "inner," or "outer" are used to indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, or the orientation or positional relationship in which the product of this invention is usually placed, they are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this invention.
[0023] Furthermore, the terms "first" and "second" are used only to distinguish descriptions and should not be interpreted as indicating or implying relative importance.
[0024] In the description of this application, it should also be noted that, unless otherwise expressly specified and limited, the terms "set up," "install," "connect," and "link" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.
[0025] Extensive research by the inventors revealed that signal debugging and troubleshooting within in-vehicle infotainment systems often rely on link-layer logs. However, existing methods typically store CAN signals as strings. While intuitive, this approach results in excessively large log files, consuming significant storage and bandwidth resources and increasing the risk of log loss. Consequently, some critical system information may not be fully recorded. This not only increases the difficulty of debugging and reproducing intermittent problems but also poses a serious challenge to system iteration, optimization, and stability verification.
[0026] On the other hand, traditional CAN bus log collection methods mainly rely on external hardware devices, such as specialized tools like CANoe and TSMaster. These methods require manual wiring for data collection, making them complex and inefficient. Furthermore, the collected logs often cannot be precisely aligned with the vehicle's internal timestamps, leading to discrepancies in subsequent signal analysis. Additionally, manual operation can result in omissions and errors, further affecting the accuracy and completeness of the log data. More importantly, using specialized tools requires an additional learning curve; for ordinary developers, signal analysis and visualization are more complex, hindering rapid problem localization and resolution.
[0027] In view of the above-mentioned problems, this embodiment provides a data processing method, apparatus, electronic device, and storage medium. It can acquire multiple CAN signals, construct multiple data packets based on each CAN signal, wherein each data packet includes multiple CAN signals. Based on each CAN signal in the data packet, the write time range, frame count, CAN ID range, and offset index of the data packet are determined. A block header of the data packet is constructed based on the write time range, frame count, CAN ID range, and offset index. The data packets are compressed based on the block header and each CAN signal to obtain compressed data packets, and each compressed data packet is stored in a queue buffer. This can reduce storage space usage and address the shortcomings of existing CAN log acquisition schemes in cross-SoC compatibility. The solution provided in this embodiment is described in detail below.
[0028] This embodiment provides an electronic device capable of processing data. In one possible implementation, the electronic device can be a user terminal, such as, but not limited to, a server, smartphone, personal computer (PC), tablet computer, personal digital assistant (PDA), mobile internet device (MID), and image acquisition device.
[0029] Please refer to Figure 1 , Figure 1 This is a schematic diagram of the structure of the electronic device 100 provided in the embodiments of this application. The electronic device 100 may further include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown. Figure 1 The components shown can be implemented using hardware, software, or a combination thereof.
[0030] The electronic device 100 includes a data processing device 110, a memory 120, and a processor 130.
[0031] The components of the memory 120 and processor 130 are electrically connected directly or indirectly to achieve data transmission or interaction. For example, these components can be electrically connected to each other through one or more communication buses or signal lines. The data processing device 110 includes at least one software function module that can be stored in the memory 120 in the form of software or firmware or embedded in the operating system (OS) of the electronic device 100. The processor 130 is used to execute executable modules stored in the memory 120, such as the software function modules and computer programs included in the data processing device 110.
[0032] The memory 120 may be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc. The memory 120 is used to store programs, and the processor 130 executes the programs after receiving execution instructions.
[0033] Please refer to Figure 2 , Figure 2 For application Figure 1 The flowchart below shows a data processing method for an electronic device 100, and the method includes each step in detail.
[0034] S201: Acquires multiple CAN signals.
[0035] S202: Construct multiple data packets based on each CAN signal.
[0036] The data packet includes multiple CAN signals.
[0037] S203: Based on each CAN signal in the data packet, determine the data packet's write time range, frame count, CAN ID range, and offset index.
[0038] S204: Construct the packet header based on the packet write time range, frame count, CAN ID range, and offset index.
[0039] S205: Compress the data packet based on the block header and each CAN signal to obtain the compressed data packet.
[0040] S206: Store each compressed data packet in the queue buffer.
[0041] CAN (Controller Area Network) is one of the core communication buses in automotive electronic systems, used for real-time data exchange between onboard ECUs, sensors, and actuators.
[0042] With the development of intelligent vehicles, vehicle systems need to process thousands or even tens of thousands of CAN signals simultaneously, serving both the underlying control logic and supporting complex applications such as in-vehicle entertainment and autonomous driving.
[0043] Therefore, the complete acquisition, accurate analysis, and traceability of CAN signals are key aspects of vehicle system debugging and verification.
[0044] The vehicle system receives the CAN signal at the bottom layer and uses the pushLogFrame method to store the CAN signal parameters, such as CANID, DLC, and Data.
[0045] The `pushLogFrame` method typically refers to pushing a new log frame onto the call stack. When code execution enters a new function, code block, or specific stage, the system creates a new "frame" to record current environment information (such as timestamp, function name, parameters, current state, etc.). These frames are usually managed in the form of a stack, with the most recently entered frame placed on top. `pushLogFrame` is the operation of pushing a new frame onto the top of this call stack. It is mainly used to trace the code execution path and nesting relationships, facilitating subsequent performance analysis, error troubleshooting, or structured log output.
[0046] Different data packets are constructed according to a preset length, each including multiple CAN signals. The write time range, frame count, CAN ID range, and offset index of the data packets are determined. Based on the write time range, frame count, CAN ID range, and offset index of the data packets, a block header of the data packets is generated. The multiple CAN signals in the data packets are concatenated into a contiguous block of memory. The ZSTD compression algorithm is used to compress this block of data to obtain compressed data packets. Each compressed data packet is stored in a queue buffer.
[0047] Finally, the compressed data adopts a unified protocol of fixed-length frame structure (86B) + block header (28B) + version control, with consistent field encoding, little-endian order, and alignment strategy; different SoCs share the same parser, thereby eliminating cross-platform adaptation costs; avoiding parsing ambiguity and "field drift", and enabling direct comparison and reuse of data between multiple chips / multi-domain controllers, shortening the joint debugging and positioning time.
[0048] To achieve log scrolling and space management, such as Figure 3 As shown, it includes the following steps: S301: Determine the total data size of each compressed data packet.
[0049] S302: Compare the total data volume with the preset data volume.
[0050] S303: When the total data volume exceeds the preset data volume, delete each compressed data packet.
[0051] The system continuously calculates the total size of all files in the current log directory to determine the total data volume of each compressed data packet. If the total data volume exceeds a preset limit, the compressed data packets are deleted to prevent log loss due to disk overload.
[0052] It should be noted that the preset data size can be set to 200MB.
[0053] There are several ways to delete compressed data packets when the total data volume exceeds the preset data volume. In one implementation, such as... Figure 4 As shown, it includes the following steps: S401: When the total data volume is greater than the preset data volume, determine the system time of each compressed data packet.
[0054] S402: Determine the longest system time from among all system times.
[0055] S403: Determine the compressed data packet corresponding to the longest system time and delete it.
[0056] The system calculates the total data volume of each compressed data packet in the current log directory in real time, compares the total data volume with the preset data volume, and if the total data volume exceeds the preset data volume, it automatically deletes the oldest compressed data packet to ensure that there is always space to write the latest log and avoids log loss due to disk fullness. The rolling management ensures the long-term stability of the log function.
[0057] Another way to implement the deletion operation of each compressed data packet is, in addition to deleting the oldest compressed data packet when the total data volume is greater than the preset data volume, it is also possible to determine the importance level of the oldest compressed data packet after determining it. If the importance level of the oldest compressed data packet is low, then the oldest compressed data packet is deleted. If the importance level of the oldest compressed data packet is high, then the previous compressed data packet of the oldest compressed data packet is determined and deleted.
[0058] For example, if the oldest compressed data packet is data packet A, and data packet B is the second oldest compressed data packet in the system time, if the importance level of data packet A is high, then the importance level of data packet B is determined; if the importance level of data packet B is low, then data packet B is deleted.
[0059] This allows for maximizing the retention of key event evidence chains under the same storage limit, reducing the risk of accidental deletion, and enhancing long-term traceability and problem reproducibility.
[0060] There are several ways to compress data packets based on the packet header and various CAN signals to obtain compressed data packets. In one implementation, such as... Figure 5 As shown, it includes the following steps: S501: Concatenates the CAN signals in the data packet to obtain the concatenated CAN signal.
[0061] S502: Compress and encrypt the header and the spliced CAN signal to obtain a compressed data packet.
[0062] It should be noted that the block header may also include the magic number, version number, compression flag, number of frames, original data size, compressed size, and first frame timestamp.
[0063] The magic number identifies the protocol type and is used to quickly identify the start position of the data packet. The version number is the protocol version for backward compatibility. The compression flag indicates whether the data is compressed and the compression algorithm. The frame number indicates the number of data frames contained in the data packet. The original data size indicates the total size of the data before compression. The compressed size indicates the size of the data transmitted in real time. The first frame timestamp indicates the acquisition time of the first frame of data.
[0064] The header and the spliced CAN signal are treated as a contiguous block of memory, and the ZSTD compression algorithm can be used to compress this block of data.
[0065] Symmetric encryption such as AES / ChaCha20 is applied to the compressed results to ensure the security and immutability of the logs.
[0066] By compressing and encrypting the block header and the spliced CAN signal, the size can be reduced, and the encryption ensures data security.
[0067] The header and the spliced CAN signal are compressed and then encrypted to ensure that the encrypted result cannot be decompressed and exploited.
[0068] The header and the concatenated CAN signal are compressed and encrypted to obtain compressed data packets. Each log file contains multiple such data packets, and the file name format can be canlog_startup_datetime.bin.
[0069] The block header ensures the self-descriptive nature of the log file, facilitating cross-platform parsing, while the filename ensures the uniqueness and traceability of multiple startups.
[0070] There are multiple ways to implement a log flushing trigger mechanism. In one implementation, such as... Figure 6 As shown, it includes the following steps: S601: Determine the capacity of the queue buffer.
[0071] S602: Determine the number of frames of cached data in the queue buffer.
[0072] S603: When the number of frames exceeds the capacity, the compressed data packets will be flushed.
[0073] The background log thread threadFunc continuously listens to the queue cache, and when a new frame is available, it is retrieved and added to the memory buffer staging_.
[0074] Queues decouple data collection from storage, preventing front-end blocking and improving real-time performance.
[0075] The system monitors the number of frames of cached data in the queue. When the number of frames of cached data in the queue exceeds the capacity of the queue, a flush operation is triggered, which means that the compressed data packets are flushed.
[0076] By triggering the flushing of compressed data packets based on the number of frames of cached data in the queue and the capacity of the queue, it is possible to ensure that there is no overflow in high-frequency scenarios.
[0077] Another implementation of the log flushing trigger mechanism, such as Figure 7 As shown, it includes the following steps: S701: Determines the time of the last write operation.
[0078] S702: Determine the current time.
[0079] S703: Determine the time interval between the last write operation and the current time.
[0080] S704: Compare the time interval with the preset time interval.
[0081] S705: When the time interval is greater than or equal to the preset time interval, the compressed data packet will be flushed.
[0082] The time interval between the last write operation and the current time is determined. This time interval is compared with a preset time interval. If the time interval is greater than or equal to the preset time interval, a write operation is triggered. If the time interval is less than the preset time interval, the capacity of the queue buffer and the number of frames of cached data in the queue buffer are determined. Based on the number of cached data frames and the capacity of the queue buffer, a decision is made on whether to trigger a write operation.
[0083] It should be noted that the preset time interval can be set to 10s, 15s, 20s, etc., and this application embodiment does not impose specific limitations on it.
[0084] By comparing the time interval between the last write operation and the current time with the preset time interval, a write operation can be triggered, ensuring that disk writes can be performed periodically even in low-frequency scenarios.
[0085] There are several ways to determine the write time range of a data packet based on the various CAN signals within the data packet. One such method is... Figure 8 As shown, it includes the following steps: S801: Determines the system time and network time of each CAN signal.
[0086] S802: Determines the data packet writing time range based on the system time and network time of each CAN signal.
[0087] The CAN signals include the system time CLOCK_MONOTONIC and the network time CLOCK_REALTIME.
[0088] For example, a data packet may include a first CAN signal, a second CAN signal, and a third CAN signal.
[0089] Determine the system time and network time of the first CAN signal, the system time and network time of the second CAN signal, and the system time and network time of the third CAN signal.
[0090] Each frame records CLOCK_MONOTONIC + CLOCK_REALTIME in parallel, and a linear drift calibration table is built in the background and uniformly mapped and aligned during parsing.
[0091] By collecting the system time and network time of CAN signals, relative timing stability and alignment with external events can be guaranteed simultaneously; the benchmark for multi-module delay analysis is consistent, and the cross-device time error is significantly converged (up to the millisecond level), which helps to locate occasional delays, facilitates cross-platform parsing, and avoids log bloat and loss caused by variable-length strings.
[0092] Multiple SOCs can utilize Python tools to parse log files, reading them through decompression → decryption (optional) → frame-by-frame parsing → conversion into industry-standard .asc, .txt, or image files. The .asc files can be directly imported into professional tools such as Vector CANoe and TSMaster, or used in a self-developed visualization platform for signal timing analysis.
[0093] Based on a unified conversion to a universal format, the barrier to entry is lowered, and it supports rapid analysis and cross-tool sharing.
[0094] Please refer to Figure 9 This application embodiment also provides an application for Figure 1 The data processing device 110 of the electronic device 100 includes: Acquisition module 111 is used to acquire multiple CAN signals; The determining module 112 is configured to construct multiple data packets based on each of the CAN signals, wherein the data packets include multiple CAN signals; determine the write time range, frame count, CANID range, and offset index of the data packets based on each CAN signal in the data packets; construct the block header of the data packets based on the write time range, frame count, CAN ID range, and offset index; and compress the data packets based on the block header and each of the CAN signals to obtain compressed data packets. Storage module 113 is used to store each of the compressed data packets into a queue buffer.
[0095] This application also provides an electronic device 100, which includes a processor 130 and a memory 120. The memory 120 stores computer-executable instructions, which, when executed by the processor 130, implement the data processing method.
[0096] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor 130, implements the data processing method.
[0097] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive 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 and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.
[0098] Furthermore, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part. If the function is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, optical disks, and other media capable of storing program code.
[0099] It should be noted that, in this document, relational terms such as "first" and "second" are used only 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 thereof 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 a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0100] The above descriptions are merely various embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A data processing method, characterized in that, The method includes: Acquire multiple CAN signals; Multiple data packets are constructed based on each of the aforementioned CAN signals, wherein the data packets include multiple CAN signals; Based on each CAN signal in the data packet, determine the write time range, frame count, CAN ID range, and offset index of the data packet; The packet header is constructed based on the write time range, frame count, CAN ID range, and offset index of the packet. The data packet is compressed based on the block header and each of the CAN signals to obtain a compressed data packet; The compressed data packets are stored in the queue cache.
2. The method according to claim 1, characterized in that, The method further includes: Determine the total data volume of each of the compressed data packets; Compare the total data volume with the preset data volume; When the total data volume exceeds the preset data volume, each of the compressed data packets is deleted.
3. The method according to claim 2, characterized in that, The step of deleting each of the compressed data packets when the total data volume exceeds the preset data volume includes: When the total data volume is greater than the preset data volume, the system time of each of the compressed data packets is determined; Determine the longest system time from each of the system time intervals; Determine the compressed data packet corresponding to the longest system time and delete it.
4. The method according to claim 1, characterized in that, The step of compressing the data packet based on the header and each of the CAN signals to obtain the compressed data packet includes: The CAN signals in the data packet are spliced together to obtain the spliced CAN signal; The header and the spliced CAN signal are compressed and encrypted to obtain a compressed data packet.
5. The method according to claim 1, characterized in that, The method further includes: Determine the capacity of the queue buffer; Determine the number of frames of cached data in the queue buffer; When the number of frames exceeds the capacity, the compressed data packets are flushed.
6. The method according to claim 1, characterized in that, The method further includes: Determine the time of the last write operation; Determine the current time; Determine the time interval between the last write operation and the current time; Compare the time interval with a preset time interval; When the time interval is greater than or equal to the preset time interval, the compressed data packet is flashed.
7. The method according to claim 1, characterized in that, The step of determining the write time range of the data packet based on each CAN signal in the data packet includes: Determine the system time and network time of each of the CAN signals; The write time range of the data packet is determined based on the system time and network time of each of the CAN signals.
8. A data processing apparatus, characterized in that, The device includes: The acquisition module is used to acquire multiple CAN signals; A determining module is configured to construct multiple data packets based on each of the CAN signals, wherein the data packets include multiple CAN signals; determine the write time range, frame count, CAN ID range, and offset index of the data packets based on each CAN signal in the data packets; construct a block header of the data packets based on the write time range, frame count, CAN ID range, and offset index; and compress the data packets based on the block header and each of the CAN signals to obtain a compressed data packet. The storage module is used to store the compressed data packets into the queue cache.
9. An electronic device, characterized in that, The method includes a memory and a processor, the memory storing a computer program, characterized in that the processor executes the computer program to implement the steps of the method according to any one of claims 1-7.
10. A storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the method described in any one of claims 1-7.