A vehicle-mounted data consistency verification method and a synchronous acquisition device

Abstract

The application provides a vehicle-mounted data consistency verification method and a synchronous acquisition device, and belongs to the technical field of automobile data monitoring. The method comprises the following steps: acquiring vehicle-mounted data, and capturing the current value of a hardware clock counter as a receiving timestamp of the vehicle-mounted data; performing data screening and message verification on the vehicle-mounted data; performing time domain alignment on the vehicle-mounted data that passes the data screening and message verification; and performing consistency verification on the vehicle-mounted data that is aligned in the time domain to obtain a consistency verification result. According to the application, at least two CAN FD controllers and at least two ADC sampling trigger logics are arranged in parallel, and a FPGA processing unit captures the current value of a hardware clock counter of a unified clock unit as a timestamp of corresponding data, so that all data directly acquire the timestamp from the tamed unified clock unit, and the absolute consistency of the timestamps of the multi-source vehicle-mounted data is guaranteed from the physical layer.

Description

Technical Field

[0001] This invention belongs to the field of automotive data monitoring technology, and specifically relates to a method for verifying the consistency of vehicle data and a synchronous acquisition device. Background Technology

[0002] Before a vehicle is listed in the announcement, a remote data access and verification test is required on the prototype vehicle to verify the authenticity and real-time nature of the data uploaded by the T-BOX.

[0003] As the electronic and electrical architecture of new energy vehicles becomes more complex, simple bus data verification can no longer meet the requirements for in-depth consistency determination. In order to accurately assess the authenticity of vehicle energy consumption, power system status and trajectory behavior, it is necessary to synchronously collect and fuse the vehicle's CAN / CAN FD bus data (millisecond-level frame interval), high-precision power data (200kHz sampling rate), and inertial navigation / RTK positioning data (200Hz data stream).

[0004] However, existing vehicle-mounted data detection systems suffer from insufficient cross-domain time synchronization accuracy. Current platforms typically rely on independent clock units or software time synchronization (such as the NTP protocol) for data acquisition from different data sources (bus, power, positioning). NTP accuracy is usually in the millisecond range (approximately several hundred microseconds under LAN optimization conditions) and is significantly affected by network fluctuations, falling far short of the microsecond-level data alignment requirements. When the system relies solely on GNSS second pulses, it cannot effectively compensate for the random drift of the local crystal oscillator between two pulses, directly leading to time synchronization failure in GNSS signal rejection scenarios such as tunnels and overpasses. Due to the lack of a unified high-precision clock reference for multi-source heterogeneous data, there is a non-negligible time deviation in the sampling time of the same physical event from different data sources, resulting in large subsequent time-domain alignment errors and unreliable consistency verification results, making it difficult to meet the high-precision verification requirements for the authenticity and real-time performance of T-BOX uploaded data in announcement detection. Furthermore, in traditional solutions, the power analyzer, bus acquisition device, and inertial navigation system are three independent devices, which inherently suffer from large space requirements, complex wiring, and the inability to unify timestamps at the physical layer, further exacerbating the difficulty of time synchronization. Summary of the Invention

[0005] To address the problems in the background art, this invention proposes a method for verifying vehicle-mounted data consistency and a synchronous acquisition device.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: In a first aspect, the present invention proposes a method for verifying the consistency of vehicle-mounted data, comprising the following steps: Acquire vehicle data and capture the current value of the hardware clock counter as the timestamp for receiving the vehicle data; Perform data filtering and message verification on the vehicle data; Time-domain alignment is performed on the vehicle data that has passed data filtering and message verification. Consistency verification is performed on the time-domain aligned vehicle data to obtain the consistency verification results.

[0007] Preferably, before acquiring the vehicle data, the method further includes: Determine if the PPS signal is valid; If the PPS signal is valid, the system enters the discipline mode to discipline the OCXO frequency and generate a unified clock reference. If the PPS signal is invalid, the system enters hold mode, activates the LSTM timing prediction model, and uses the OCXO frequency, temperature and running time before the signal loss as input to predict the frequency drift compensation of the OCXO. The frequency drift compensation is then added to the deviation correction term of the hardware clock counter to maintain a unified clock reference. When the PPS signal recovers from invalid to valid, the system switches from the hold mode to the docile mode.

[0008] Preferably, the step of frequency discipline of the OCXO to generate a unified clock reference specifically includes: Measure the phase difference between the PPS signal edge and the local clock count; The frequency adjustment of the OCXO is calculated based on the phase error and the cumulative value of the phase error; The frequency adjustment amount is converted into an analog control signal to control the oscillation frequency of the OCXO; Closed-loop control locks the frequency to the satellite clock reference, completes clock initialization, and generates a unified clock reference.

[0009] Preferably, the data filtering and message verification includes data integrity verification, data enhancement verification, VIN consistency verification, and command identifier matching verification performed sequentially.

[0010] Preferably, the step of performing time-domain alignment on the vehicle data that has passed the data filtering and message verification specifically includes: Determine whether the vehicle data carries its own timestamp; If so, calculate the estimated time deviation between the received timestamp and its own timestamp, smooth the multiple estimated time deviations using a sliding window mean filter, and use the least squares method to linearly fit the smoothed deviation sequence to obtain the clock drift rate and the initial fixed deviation. Correct the own timestamp based on the clock drift rate and the initial fixed deviation.

[0011] Preferably, the consistency verification includes mechanism verification, data rationality verification, data accuracy verification, data quality verification, and data difference analysis; The mechanism-based verification is used to verify whether the data message conforms to the timing logic and state flow of the preset working conditions; The data rationality verification is used to determine whether the data conforms to physical laws; The data accuracy verification is used to perform threshold analysis and outlier detection on the numerical values ​​of data fields. The data quality verification is used to calculate and quantify the null value rate, zero value rate, outlier rate, and invalid value rate of data fields.

[0012] Secondly, the present invention also proposes an in-vehicle data synchronization acquisition device for implementing the in-vehicle data consistency verification method of the first aspect, comprising an in-vehicle data acquisition module, an FPGA processing unit, a unified clock unit, and a host computer processing module; wherein: The vehicle data acquisition module is used to acquire vehicle data; The FPGA processing unit is equipped with at least two CAN FD controllers and at least two ADC sampling trigger logics in parallel. The FPGA processing unit is used to capture the current value of the hardware clock counter of the unified clock unit as the timestamp of the corresponding data. The unified clock unit includes a GNSS receiver, a DPLL, and an OCXO. The unified clock unit is used to perform frequency discipline on the OCXO through the DPLL when the PPS signal output by the GNSS receiver is valid. The host computer processing module is used to sequentially perform message filtering and integrity verification, time domain alignment and consistency verification on the vehicle data.

[0013] Preferably, the FPGA processing unit further includes a DMA engine, which is configured to operate always-on in a mode combining continuous circular buffering and ping-pong double buffering, for emptying the hardware FIFO buffer. And / or, The FPGA processing unit is also equipped with a protocol adaptation interface, which is used to convert vehicle data into a unified frame format.

[0014] Preferably, the FPGA processing unit further includes a hardware frame boundary recognition state machine; the hardware frame boundary recognition state machine includes a frame delimitation state machine and packet fragmentation elimination logic; The frame delimiting state machine is used to identify the SOF and EOF flags; The packet fragmentation elimination logic is configured to pre-read the length field of the packet header to lock the byte boundary of the current packet, temporarily store data bytes that exceed the current packet boundary in a sliding window buffer for concatenation of the next packet, and timestamp the concatenated packet before transmitting it to the host computer processing module via the DMA engine. The sliding window buffer is used to temporarily store the remaining data bytes from the packet merging process.

[0015] Preferably, the device further includes an NPU, which is connected to the FPGA processing unit; The NPU is used to deploy LSTM time series prediction models; When the PPS signal output by the GNSS receiver is lost, the LSTM timing prediction model is activated to predict the frequency drift compensation of the OCXO in the future period, using the OCXO frequency, temperature and runtime feature sequence before the signal loss as input, and superimposed on the deviation correction term of the hardware clock counter. When the PPS signal output by the GNSS receiver is restored, the unified clock unit is configured to re-enter frequency discipline mode.

[0016] The beneficial effects of this invention are: 1. This invention uses at least two CAN FD controllers and at least two ADC sampling trigger logics set up in parallel. The FPGA processing unit captures the current value of the hardware clock counter of the unified clock unit as the timestamp of the corresponding data. All data directly obtains the timestamp from the tamed unified clock unit, which ensures the absolute consistency of timestamps of multi-source vehicle data at the physical layer. This solves the problem in the prior art where different data sources such as bus, power, and positioning rely on their own independent clocks, resulting in the inability to unify timestamps.

[0017] 2. This invention improves accuracy by using DPLL to frequency discipline the OCXO when the PPS signal output by the GNSS receiver is valid, thereby locking the frequency stability of the local hardware clock to the level of a satellite atomic clock and generating a nanosecond-level clock source. This is in contrast to existing technologies that rely on NTP software for time synchronization.

[0018] 3. This invention integrates the vehicle data acquisition module, FPGA processing unit, unified clock unit and host computer processing module into the same device, which solves the inherent problems of large space occupation, complex wiring and inability to unify timestamps at the physical layer in the traditional solution of three independent devices: power analyzer, bus acquisition device and inertial navigation system. It realizes unified synchronous acquisition of heterogeneous data on the end side.

[0019] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures pointed out in the description and the drawings. Attached Figure Description

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

[0021] Figure 1 A flowchart of an in-vehicle data consistency verification method according to the present invention is shown; Figure 2 The overall platform architecture diagram of the present invention is shown; Figure 3 A schematic diagram of the platform test items and verification model of the present invention is shown; Figure 4 A conceptual architecture diagram of the platform of the present invention is shown. Detailed Implementation

[0022] 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, 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.

[0023] The vehicle-mounted data synchronization acquisition device consists of four components: a vehicle-mounted data acquisition module, an FPGA processing unit, a unified clock unit, and a host computer processing module.

[0024] The vehicle data acquisition module is used to acquire vehicle data and serves as the data entry point for the entire system. Data acquisition comprises two parallel paths. In the active acquisition path, the vehicle data acquisition module connects to the vehicle's six CAN / CAN FD buses via an OBD 1-to-6 cable, covering the power domain, chassis domain, and body domain buses accessed via the OBD gateway. Simultaneously, it connects to power measurement points via voltage / current sensors, and uses a GNSS antenna to receive satellite signals, combined with the inertial navigation unit to acquire positioning and attitude data. In the passive reception path, the vehicle data acquisition module receives vehicle data messages reported by the vehicle terminal according to the GB / T32960 protocol via UART and Ethernet interfaces. These messages carry the timestamp of the vehicle terminal's own clock, which deviates from the system's unified clock reference. Therefore, it needs to be corrected through time domain alignment in subsequent steps. The two paths can be used independently or simultaneously. When simultaneously enabled, the data acquired through the active acquisition path serves as the truth reference, while the data acquired through the passive reception path serves as the measured object. The two are compared and verified under a unified clock reference.

[0025] The FPGA processing unit internally integrates at least two CAN FD controller IP cores and at least two ADC sampling triggering logics in parallel. In a specific embodiment, the number of CAN FD controllers can be configured to 6 based on the number of vehicle buses, and the ADC sampling triggering logic can be configured to 8 to support multi-channel power synchronous sampling. When a CAN FD frame enters the cable, the hardware CAN controller immediately captures the current value of the hardware clock counter of the unified clock unit at the frame start bit moment as the timestamp of the frame, and packages the timestamp and frame payload together into a hardware FIFO buffer. For power sampling data, the ADC sampling triggering logic captures the current value of the hardware clock counter of the unified clock unit at each sampling point moment as the sampling timestamp, and stores the sampling data and the corresponding timestamp into the hardware FIFO buffer. For positioning and inertial navigation data output from the GNSS and IMU interfaces, the FPGA processing unit captures the current value of the hardware clock counter of the unified clock unit as the timestamp at the data reception moment. The above-mentioned stamping process is executed entirely in parallel by the hardware logic circuits, with zero intervention from the main CPU, and the timestamp resolution reaches 10 nanoseconds, physically ensuring the absolute consistency of timestamps for multi-source vehicle data.

[0026] To achieve lossless, low-latency transmission of high-frequency data, the FPGA processing unit also includes a DMA engine. The DMA engine operates continuously using a combination of continuous circular buffering and ping-pong double buffering, freely emptying the hardware FIFO buffer without requiring a water level trigger for startup. The DMA engine's emptying rate is no less than 100MB / s, approximately 10 times the system's average throughput, with a bus occupancy rate below 10%, keeping the hardware FIFO buffer nearly empty in steady state. The latency of data acquisition to memory is determined by the emptying rate, not the water level, with a steady-state latency of less than 1 microsecond. The high-water mark on the hardware FIFO buffer is only used for overflow or bus pause alarms and is not used to set latency. Half-buffering switching in the ping-pong double buffer generates CPU consumption notifications, driving the host computer to read data. Timestamps are applied frame-by-frame or sample-by-sample at the FPGA entry point, independent of the DMA transmission path, ensuring the accuracy of the timestamp is unaffected by transmission latency. The total raw data throughput of the system consists of three parts: CAN FD bus data, power sampling data, and inertial navigation positioning data, calculated using the following formula:

[0027] in, This represents the total number of CAN FD lines. For each CAN FD full load frame rate, The number of payload bytes per frame. This represents the number of ADC sampling channels. L_ADC represents the power sampling rate, and L_ADC represents the number of bytes sampled per channel. For inertial navigation data rate, This refers to the number of bytes of inertial navigation data per frame. In one specific embodiment... , , , , , , , ,but The speed is approximately 9.5 MB / s. The depth of the hardware FIFO buffer is determined by the need to absorb the worst-case burst. Modeled using a conservative upper bound, under the condition of a DMA drain rate of 100 MB / s, the net backlog of a 1 microsecond burst window is approximately 290 bytes. Therefore, the on-chip FIFO depth can be 512 bytes or 1KB to reserve a margin of 2. In steady state, the FIFO level is only 10 to 30 bytes, corresponding to a latency of 0.1 to 0.3 microseconds. The DDR-side circular buffer can be 16KB, with ping-pong half-buffering of 1 to 4KB to generate consumption notifications. The interrupt frequency is approximately 2.3 to 9.3 kHz, decoupled from the on-chip FIFO depth.

[0028] To address the issues of packet fragmentation and partial packet generation during end-side data reception, the FPGA processing unit incorporates a hardware frame boundary recognition state machine. This state machine comprises two parts: a frame delimitation state machine and packet fragmentation elimination logic. The frame delimitation state machine identifies the SOF and EOF flags of the CAN FD bus frame, locking the frame boundary at the physical signal layer and preventing packet fragmentation in the CAN FD bus data from the source. For GB / T32960 protocol messages (passive reception path) reported by the vehicle terminal via the UART and Ethernet interfaces, the packet fragmentation elimination logic is configured to pre-read the length field of the message header to lock the byte boundary of the current message, temporarily storing data bytes exceeding the current message boundary in a sliding window buffer for concatenation in the next message. This sliding window buffer and the aforementioned hardware FIFO buffer used to temporarily store CAN FD frames and ADC sampling data are two independent hardware structures. The former is dedicated to packet fragmentation elimination and message concatenation for the streaming interface, while the latter is used to temporarily store data frames already packaged by the CAN FD controller and ADC sampling trigger logic. The specific rule for packet fragmentation determination is as follows: Let the number of bytes accumulated in the current receive buffer be... The total length of the current message header declaration is ,like Greater than or equal to If the current window contains the complete message, then the previous one can be extracted. Bytes are framed, and the remaining bytes are stored in the window as the remaining part of the packet merging; if Less than If the packet is partially filled, it is in a half-packet state, waiting for subsequent bytes to be appended to continue accumulating. The sliding window buffer is used to temporarily store the remaining data bytes after packet merging, and its size should meet the following requirements:

[0029] in, The size of the sliding window buffer. This represents the maximum length of the protocol message. The length field of the GB / T32960.3 message is 2 bytes, which theoretically has a large upper limit, but in practical engineering measurements, a single packet typically does not exceed 1024 bytes, therefore, we use [the specified value]. =1024 bytes The maximum length is ≥2048 bytes, but 4096 bytes are used in the implementation to ensure sufficient margin. This formula ensures that the sliding window buffer can accommodate extreme packet-merging scenarios where two maximum-length packets are joined end-to-end. After splicing the complete packets, a unified timestamp is added, and then the data is transmitted to the host computer processing module via the DMA engine. The entire process is completed in the hardware circuit, and the data stream received by the host computer is already a clean and complete packet sequence, eliminating the need for secondary packet-merging processing in software.

[0030] To unify the message formats of different hardware interfaces, a protocol adaptation interface is also set up in the FPGA processing unit. The protocol adaptation interface is used to convert heterogeneous vehicle data from the CAN FD bus interface, UART interface (transmitting GB / T32960.3 messages), and Ethernet interface (transmitting RTK positioning and inertial navigation data) into a unified frame format that includes frame type, timestamp, and data payload, and then send it to the high-performance data transmission layer. This eliminates the impact of differences in different protocol formats on subsequent verification logic and reduces the complexity of upper computer processing.

[0031] A timestamp refers to the current value of the hardware clock counter of the unified clock unit captured by the FPGA processing unit at the moment an event occurs, with its counting reference being a disciplined unified clock. A receive timestamp is a specific type of timestamp, referring to the timestamp captured by the FPGA processing unit at the moment a message arrives at the receive buffer and completes splicing on the passive receive path (UART interface, Ethernet interface). Timestamps generated by active acquisition paths (CAN FD bus data at the start-of-frame bit, power sampling data at the sampling point, GNSS and IMU data at the reception time) are collectively referred to as timestamps, not receive timestamps. The counting reference for all types of timestamps mentioned above is the same hardware clock counter of the unified clock unit, thus allowing for unified time alignment on the host computer.

[0032] The unified clock unit, comprising a GNSS receiver, DPLL, and OCXO, provides a high-precision unified clock reference for the entire system. The system uses the PPS (Pulse Per Second) output from the GNSS receiver as the absolute time reference, and continuously disciplines the local high-stability OCXO via the DPLL within the FPGA. When the PPS signal output from the GNSS receiver is valid, the unified clock unit enters discipline mode. The TDC (Time Difference Controller) within the DPLL continuously measures the minute phase difference between the PPS second edge and the local clock count. The PI controller calculates a fine frequency adjustment based on the phase error and its cumulative value across measurements. This adjustment is converted into an analog control signal by a high-precision DAC to control the OCXO's oscillation frequency. This closed-loop control locks the local hardware clock frequency to a satellite atomic clock level over the long term, generating a nanosecond-level clock source. All acquisition modules (including the CAN FD controller and ADC sampling trigger logic) directly obtain timestamps from this disciplined unified clock unit, physically ensuring absolute consistency of timestamps for multi-source vehicle data.

[0033] The PI control process of DPLL is as follows: Let the phase error in the nth PPS cycle be:

[0034] in, The phase error in the nth PPS period is... The nth PPS interval measured by the local counter is converted into seconds. For standard PPS cycle ( =1.000000000s). The DPLL uses a proportional-integral (PI) controller to calculate the OCXO frequency adjustment:

[0035] in, This represents the OCXO frequency adjustment amount for the nth PPS cycle. For proportional gain, For integral gain, The phase error in the nth PPS period is... This is the cumulative value of the phase error from the 1st to the nth measurement (i.e., the integral term). Proportional gain. and integral gain The loop bandwidth of the OCXO and damping coefficient Decide:

[0036]

[0037]

[0038] in, The natural angular frequency of the loop. For loop bandwidth, This is the damping coefficient. In engineering implementation, it is taken as... , (Optimal damping), corresponding to the loop time constant The timestamp error converges to the nanosecond level within seconds.

[0039] The short-term frequency stability of an OCXO is quantified using Allan variance. For a set of N adjacent samples of average frequency deviation, the Allan variance is defined as:

[0040] in, Integration time Allan variance under The sampling integration time is 1 second (here). The total number of samples, For the first Each integration interval The average normalized frequency deviation within. Generally, OCXOs are required to... hour Corresponding time error This ensures that the time uncertainty within a single PPS period is well below 1 ns.

[0041] When GNSS signal rejection scenarios, such as vehicles entering tunnels, lead to PPS signal loss, the unified clock unit seamlessly switches from disciplined mode to hold mode. Furthermore, the device of this invention also includes an NPU, which is connected to an FPGA processing unit for deploying an LSTM timing prediction model. When the PPS signal output by the GNSS receiver is lost, the LSTM timing prediction model is activated. Using the OCXO frequency, temperature, and runtime characteristic sequence before signal loss as input, it predicts the nonlinear frequency drift compensation amount of the OCXO in real time for future periods and adds this frequency drift compensation amount to the deviation correction term of the hardware clock counter to maintain a unified clock reference. Let the drift characteristic sequence be... (Representing current frequency offset, chip temperature, and runtime, respectively), the LSTM hidden layer state update equation is:

[0042]

[0043]

[0044]

[0045]

[0046]

[0047] in, For input gate, For the Gate of Oblivion Candidate cell state, For output gate, In cellular state, For hidden layer output, It is the sigmoid activation function. This is the Hadamard product (element-by-element multiplication). , , , Here is the weight matrix for each goalkeeper. , , , Let be the bias vector for each goalkeeper. The drift characteristic sequence at time t, This represents the hidden state at the previous time step. This represents the cell state at the previous time step. The model's output layer predicts the future state. Cumulative frequency drift compensation of the OCXO over time:

[0048] in, For the future The cumulative frequency drift compensation of the OCXO over a given time period. This is the output layer weight matrix. This is the output layer bias vector. The hidden layer output is at time t. The predicted compensation is added to the local clock counter offset correction term to ensure that the cumulative time error during GNSS denial meets the following requirements:

[0049] in, During GNSS denial period Cumulative time error over a period of time This is the frequency drift compensation amount predicted by the LSTM model. This represents the actual frequency drift of the OCXO. GNSS denial duration ( (In scenarios with a time limit of ≤30 minutes). This model has continuously learned the drift characteristics of the OCXO at different temperatures and aging stages while the device is running, thus providing high-precision drift prediction in hold mode. The compensated time base is also used by the inertial navigation unit for attitude calculation in dead reckoning, forming a tight coupling between the AI ​​timing model and the physical sensors. When the vehicle exits the tunnel and the GNSS signal is restored, after the system detects a stable PPS signal, the unified clock unit smoothly re-enters the frequency discipline mode, avoiding clock jumps and completing the time consistency closed loop across the entire scenario. In a 30-minute GNSS signal rejection scenario, the cumulative time error of LSTM intelligent compensation does not exceed 1 microsecond, which is about 600 times more accurate than the traditional NTP time synchronization scheme and about 72 times more accurate than the pure OCXO hold scheme.

[0050] The host computer processing module is responsible for sequentially performing data filtering, message verification, time domain alignment, and consistency verification on the vehicle-mounted data, and is the core of data verification and analysis. It should be noted that clock initialization (including frequency discipline and LSTM prediction compensation in discipline and hold modes) is a task completed by the unified clock unit before data acquisition, executed by the FPGA hardware layer, and is not within the scope of the host computer processing module. The host computer processing module processes the tagged data after data acquisition. The host computer uses a memory mapping mechanism to directly access the kernel-mode DMA buffer with a user-mode pointer, achieving zero-copy data reading and avoiding the memory copy overhead of traditional read / write system calls. The receiving thread pushes data blocks in batches to the processing thread through a lock-free circular queue based on CAS atomic operations, achieving efficient multi-threaded data scheduling. The write and read pointers of the lock-free circular queue are maintained using atomic operations, and the current number of frames occupied by the queue is:

[0051] in, The number of frames currently occupied in the queue. To write pointers, To read the pointer, The capacity of the circular buffer (number of frames). This is a modulo operation. A successful write operation is conditional on the queue not being full. In high-frequency acquisition scenarios, to ensure that writes do not overflow, the capacity of the circular buffer should meet the following requirements:

[0052] in, Peak frame rate (frames per second). The maximum latency (in seconds) for downstream processing of a batch of data. , hour, To achieve (Powers of 2 facilitate bitwise operations to optimize modulo operations and retain a margin of more than 16 times).

[0053] The host computer processing module is also responsible for three management functions: First, data acquisition logic scheduling, which manages the acquisition timing of multiple hardware interfaces and coordinates the buffering and distribution of high-frequency data streams. Second, secondary processing of packet fragmentation, which provides a fallback for remaining boundary issues that have been initially processed by the hardware layer. Third, data reporting, which writes compliant messages that have passed verification to the Kafka message queue.

[0054] Furthermore, refer to Figure 1As shown, the vehicle data consistency verification method of the present invention is based on the aforementioned vehicle data synchronization acquisition device, and includes four core steps: data acquisition and stamping, data filtering and message verification, time domain alignment, and consistency verification. In the data acquisition and stamping step, vehicle data is acquired through the vehicle data acquisition module, and the FPGA processing unit captures the current value of the hardware clock counter of the unified clock unit as the timestamp of the vehicle data (i.e., the receiving timestamp for the passive receiving path). For CAN FD bus data, power sampling data, and positioning and inertial navigation data acquired through the active acquisition path, the FPGA processing unit captures the current value of the hardware clock counter as the timestamp at the frame start bit time, sampling point time, and data reception time, respectively. For vehicle terminal reporting messages acquired through the passive receiving path, the FPGA processing unit captures the current value of the hardware clock counter as the receiving timestamp at the time the message is fully assembled.

[0055] After data is transferred to the host computer processing module via DMA and before it is written to the message queue, the host computer processing module performs data filtering and message verification on the message. Data filtering and message verification include sequentially performing data integrity verification (BCC check), data enhancement verification (CRC check), VIN consistency verification, and command identifier matching verification. Data integrity verification uses BCC XOR verification conforming to GB / T32960.3. The byte sequence of the valid data area of ​​the message is then checked. The BCC checksum is:

[0056] in, It is an XOR checksum. The k-th byte of the valid data area of ​​the message, where m is the number of valid data bytes. This is a bitwise XOR operation. The BCC checksum is appended to the end of the message, and the receiver checks the received data. Perform an overall XOR operation. If the result is 0x00, the verification passes; otherwise, discard the data and request a retransmission.

[0057] Data augmentation check adds an additional CRC-16 / XMODEM check on top of BCC check to enhance error detection capabilities. This check is not required by the GB / T32960 standard and is a self-incrementing augmentation layer. Its generator polynomial is:

[0058] in, The generator polynomial of CRC-16 / XMODEM (corresponding to hexadecimal 0x1021), initial value Input / output is non-reflected. For data packets of length n bytes... The CRC iterative calculation process is as follows:

[0059] right :

[0060] in, This is the initial value for CRC. To process the CRC value after the i-th byte, The i-th byte of the data packet. This is a single-byte CRC update function.

[0061] The specific calculation is as follows: First, and XOR, then XOR Loop: If ,but ,otherwise Finally return .

[0062] final This is the 16-bit checksum of the data packet, appended to the end of the packet. The receiver recalculates the checksum for the received n bytes using the same algorithm. ,like If the data is found to be complete, it is considered intact; otherwise, it is discarded and a retransmission is requested. The VIN consistency check parses the VIN code in the message to determine if the VIN belongs to the test vehicle used in this experiment. The command identifier matching check determines whether the message belongs to the item that needs to be tested in this business based on the command identifier in the message (including vehicle login, real-time information reporting, resend information reporting, vehicle logout, platform login / logout, heartbeat, etc.). Messages that fail any of the above checks return an error message to the sender, while compliant messages that pass the screening are written to the Kafka message queue.

[0063] After data filtering and message verification are passed, the host computer processing module performs a time-domain alignment step on the data. Time-domain alignment is only performed when the data carries its own timestamp to correct the timestamp deviation of the messages reported by the vehicle terminal obtained by the passive receiving channel. It is determined whether the vehicle data carries its own timestamp. If so, an estimated time deviation between the received timestamp and its own timestamp is calculated. A sliding window mean filter is used to smooth multiple time deviation estimates. The least squares method is used to linearly fit the smoothed deviation sequence to obtain the clock drift rate and initial fixed deviation. Based on the clock drift rate and initial fixed deviation, the timestamp is corrected to the clock reference of the unified clock unit. If the vehicle data does not carry its own timestamp (i.e., data obtained by the active acquisition channel), the timestamp of this data has already been generated based on the clock reference of the unified clock unit, requiring no additional correction, and subsequent consistency verification is performed directly.

[0064] Let sensor A (such as the vehicle terminal T-BOX, corresponding to its own timestamp) and sensor B (such as the FPGA local clock, corresponding to the received timestamp) be at time... and For the k-th sample of the same physical event, the estimated time deviation between the two samples is:

[0065] in, This is the estimated time deviation value for the k-th sampling. Let k be the timestamp of sensor A (the vehicle terminal's own clock) during the kth sampling. This is the timestamp of sensor B (FPGA local clock, i.e., the received timestamp) at the kth sampling point. Since the vehicle terminal continuously reports a series of messages, a timestamp is obtained for each received message. This results in a bias sequence. .

[0066] A sliding window mean filter is used to smooth the multiple bias estimates, with a window length of M.

[0067] in, This is the estimated bias value after mean filtering via a sliding window. The length of the sliding window (take a positive integer). For from the first One to the first The sum of the estimated deviations.

[0068] Considering the linear component introduced by crystal oscillator drift, the least squares method is used to perform linear fitting on the deviation sequence:

[0069] in, Clock drift rate, measured in seconds per sample, reflects the rate of change of the vehicle terminal clock relative to the system's unified clock per second. The initial fixed deviation (unit: seconds, reflecting the constant time difference between two clocks from the initial moment). For sampling sequence number, To measure noise, the least squares estimate is:

[0070] in, This is the least squares estimate of the clock drift rate. The least squares estimate of the initial fixed bias. To design the matrix, For the deviation sequence vector, for transpose, for The inverse matrix. Design the matrix. for:

[0071] Right now The first column is the sampling number. (corresponding clock drift rate) The coefficients), the second column is all 1 (corresponding to the initial fixed deviation). (coefficients), parameter vector is Deviation sequence vector for:

[0072] During time-domain alignment, the timestamp of sensor A (the vehicle terminal's own clock) is corrected to:

[0073] in, This is the corrected timestamp of the kth sampling. This is the original timestamp of the vehicle terminal's own clock. This represents the total deviation of the k-th sample, calculated from the clock drift rate and the initial fixed deviation. After correction, the vehicle terminal data is aligned with the system's unified clock reference, eliminating time differences from multi-source acquisition and providing a precise timing basis for subsequent consistency verification.

[0074] After time-domain alignment is completed, the host computer processing module performs consistency verification on the aligned data. Consistency verification includes five dimensions: mechanism verification, data rationality verification, data accuracy verification, data quality verification, and data difference analysis, forming a complete data consistency verification system.

[0075] Mechanistic verification is used to confirm whether data messages conform to the preset operating conditions' timing logic and state flow, including verification of typical scenarios such as charging and alarm conditions. For charging conditions, generally, mechanism verification requires a charging duration of no less than 15 minutes (corresponding to a total number of charging packets of no less than 90 and a time difference between the first and last charging packets of no less than 14.5 minutes), a continuous zero vehicle speed during charging, and a current less than zero for each charging packet (negative values ​​indicate the charging direction). Its compliance conditions are as follows:

[0076] in, The charging termination time. The charging start time is 870 seconds, which corresponds to a compliance minimum of at least 14.5 minutes. The total number of packages during the charging period. This represents the current sample value in the k-th packet (negative values ​​indicate the charging direction). This indicates that the data packets are valid for all charging periods. For alarm conditions, the general, mechanism-based verification requires that the number of retransmissions in the 35 seconds before the alarm point be no less than 29, and the sum of the number of retransmissions and the number of real-time retransmissions in the 40 seconds after the alarm point be no less than 60.

[0077] Data rationality verification uses multi-source information fusion technology to comprehensively judge whether on-board data conforms to physical laws. A typical application is determining the authenticity of charging conditions. The rationality constraint for the SOC change rate is:

[0078] in, Let SOC be the rate of change of the k-th sampling interval. This represents the state of charge value at the k-th sampling time. This represents the state of charge value at the (k+1)th sampling time. Sampling interval. Requirements under charging conditions. (SOC increases monotonically), and the maximum charging rate does not exceed the rated charging rate. (Generally, 2C corresponds to the theoretical SOC rise rate.) Combining the charging current direction, SOC change rate, and vehicle speed signal, the comprehensive criterion for the authenticity of the charging condition is:

[0079] in, This is the result of determining the authenticity of the charging condition (true indicates that it is determined to be a true parking and charging state). Charging current ( (Indicates the charging direction). SOC change rate ( (Indicates that SOC is monotonically increasing). For vehicle speed signal ( (This indicates the vehicle is stationary). When all three conditions above are met simultaneously, it is determined to be a true parking and charging state.

[0080] Data accuracy verification involves threshold analysis of the values ​​in each field of the message to determine whether they exceed the valid range defined by national standards. Simultaneously, multivariate statistical analysis methods, such as outlier detection, are used to determine data accuracy and compliance. Taking battery cell voltage as an example, an improved Z-Score method is used for outlier detection. Let N battery cell voltage sampling values ​​be used. Calculate the sample mean with standard deviation :

[0081]

[0082] in, The average of N individual voltage samples. Here, N represents the sample standard deviation, and N is the number of individual voltage samples. For the voltage sample value of the i-th cell, This is a square root operation. The Z-Score of the i-th unit is:

[0083] in, Let Z-score be the voltage of the i-th cell. Let be the absolute deviation of the voltage of the i-th cell from the sample mean. (Pick (corresponding to the 3σ criterion) or Exceeding the national standard rated range If the condition is: .

[0084] The data quality verification statistics report includes the null value rate, zero value rate, outlier rate, and invalid value rate of each field, which quantitatively scores the data integrity. This applies to the set of fields. Each field Define its quality ratios (all based on the total number of samples). ): (Negative value rate) (Zero value rate) (Invalid value rate) (Outlier rate).

[0085] Fields The quality score is:

[0086] in, For fields Quality score (0-1, the higher the better). , , , These are the weights for the null value rate, zero value rate, invalid value rate, and outlier rate, respectively. , , , fields respectively The null value rate, zero value rate, invalid value rate, and outlier rate. The engineering values ​​can be: , , , (Subject to adjustment according to business rules), and (Quality score not lower than zero). The overall message quality score is the average of each field weighted by its business importance:

[0087] in, To provide a comprehensive score for the overall message quality, Total number of fields The business importance weight of the j-th field, Let j be the quality score of the j-th field. To ensure quality, This is a quality warning. The quality is substandard.

[0088] Data discrepancy analysis employs the isolated forest method based on multivariate and multi-information dimensions to detect and analyze anomalies in individual or overall vehicle data. This method describes the region of normal samples in the feature space, with samples deviating from this region considered anomalous. The isolated forest consists of T isolated trees (iTrees). For each tree, a sub-sample is randomly selected from the data sample set to construct a binary tree. Each time, a feature dimension and split point are randomly selected (uniformly sampled within the data range of that dimension), dividing the sample into left and right branches, until each leaf node contains only one sample or the tree height reaches its upper limit. The path length h(x) of a data point x in a single iTree is defined as the number of edges traversed from the root node to the leaf node containing x. The average path length over the T trees is calculated as follows:

[0089] in, Let x be the average path length of data point x across all T isolated trees, where T is the number of isolated trees. Let x be the path length of data point x in the t-th isolated tree. The expected mean correction function c(n) for the path length (used for normalization) is defined as:

[0090] in, The subsample size is The expected mean correction function for path length at time , Subsample size (i.e., the number of samples drawn from each tree) ), For the harmonic series approximation (0.5772 is Euler's constant γ), i.e. The outlier score for data point x is defined as:

[0091] in, Let x be the outlier score for data point x. When, it means much smaller x is isolated early in the tree, making it highly likely to be an anomaly; when When, it means , x is a normal sample; when When, it means Much larger In the deeply embedded tree, x belongs to a dense, normal region. Generally, an anomaly detection threshold is set. ,when If the data point is flagged as abnormal, further manual or automated verification processes will be triggered.

[0092] In one specific embodiment, the edge hardware uses a Xilinx Zynq UltraScale+ series SoC chip for the FPGA. A 6-channel CAN FD controller IP core, a multi-protocol frame boundary identification state machine, and a DMA engine are deployed on the PL side, while Linux host computer software runs on the PS side. The OCXO uses a chip with a stability better than 5×10⁻⁶ Ω for 1 second. -12 The system uses a temperature-controlled crystal oscillator; the embedded NPU has a computing power of no less than 1 TOPS, and deploys an LSTM drift prediction model quantized by INT8; power sampling uses a 16-bit, 8-channel synchronous sampling ADC with a sampling rate of 200kHz. In the time synchronization embodiment, the DPLL loop bandwidth is 0.1Hz and the damping coefficient is 0.707; when GNSS is rejected, the LSTM model uses the frequency offset, temperature, and runtime feature sequence of at least 10 minutes before signal loss as input to predict the nonlinear frequency drift compensation of the OCXO in the next 30 minutes online, ensuring that the cumulative time error during the rejection period does not exceed 1 microsecond. In the platform deployment example, the Kafka cluster is deployed with 3 brokers and multiple partitions. The Spark cluster runs Spark Streaming real-time parsing tasks. HBase, Redis, Elasticsearch, and ClickHouse are all deployed in a cluster. MySQL adopts a master-slave architecture and achieves read-write separation through the MyCat middleware. The platform application service is deployed based on Docker containerization. The front end provides services to the outside world through Nginx load balancing. The detection tasks are issued through a mobile APP detection assistant. The detection images and videos are uniformly stored by the web server and FFmpeg streaming media service, respectively.

[0093] Furthermore, refer to Figure 2 As shown, this invention designs a platform based on the aforementioned vehicle-mounted data synchronization acquisition device and consistency verification method. The platform is conceptually divided into six layers: data source layer, data communication layer, platform data layer, platform business layer, front-end / back-end communication layer, and platform presentation layer, with the operation and maintenance management layer running through each layer.

[0094] Reference Figure 4As shown, the data source layer provides specific data access sources, including access data forwarded by the platform and access data directly sent by vehicle terminal devices; in the data communication layer, regular business uses the HTTP communication protocol, while data forwarded or directly connected to the testing center by the platform, vehicles, and chassis uses the TCP communication protocol; the platform data layer provides data computing and data storage services, uses CDH to monitor and manage various components and data acquisition and processing services of the big data platform, uses ZooKeeper to allocate and coordinate various services, uses Yarn for job scheduling, and uses Oozie for task scheduling; the platform business layer encapsulates business functions such as platform registration, vehicle application, chassis application, test tracking, vehicle review, and system management into common components and exposes them to the platform presentation layer according to service specifications; the front-end and back-end communication layer adopts front-end and back-end separation technology, assembling, reorganizing, and converting the atomic services of the platform business layer according to business needs; the platform presentation layer provides users with functional modules such as entrustment application, entrustment review, test tracking, and report management; the operation and maintenance management layer interacts with other layers, monitors the service operation status of each layer, and ensures business continuity.

[0095] The platform is deployed in a high-availability mode and consists of seven core services: data acquisition, data parsing, scheduled tasks, data push, platform application, streaming media, and front-end display. The data acquisition service is divided into two methods based on business needs: platform forwarding and direct acquisition and transmission from vehicle terminal devices. After the platform, vehicle, or chassis to be tested opens its port, it assembles vehicle data packets according to the platform's specified protocol, establishes a long-lived socket communication with the data receiving server via the internet, and sends the data packets. Upon receiving the packets, the receiver performs integrity verification; successful data is written to a Kafka message queue, otherwise an error message is returned to the sender. An Nginx load balancer is deployed on the data receiving server to distribute data, improving throughput while ensuring high availability of the data acquisition service, providing support for high-concurrency scenarios such as alarm detection. The data parsing service continuously consumes data packets from the Kafka message queue using Spark Streaming, parsing them according to the GB / T 32960.3 communication protocol. It transforms the raw data packets into object-like data structures and stores them in the HBase cluster, supporting segmented processing and display of each packet. The scheduled task service, based on Hive and MapReduce, periodically statistically analyzes the detection items in the process. For different detection items such as charging tests and driving tests, it performs statistics from different dimensions such as null value rate, outlier rate, and invalid value rate, and stores the statistical results in the Elasticsearch cluster. The data push service uses WebSocket technology to push real-time cached data and related business data to the front end for display. Verification personnel can view the original packets and parsed packet content in real time. The platform application service is split into functional modules, with each service packaged separately and encapsulated in Docker containers along with its runtime environment. Multiple instances can be deployed on one or more physical machines. After starting, each service registers its information with the service registry center, and services collaborate by dynamically calling each other's REST API interfaces through a loosely coupled service discovery mechanism. The streaming media service is built using FFmpeg, pulling video stream data from a remote location, storing it on the server, and providing it for real-time display on the front end. This fulfills the requirements for collecting, storing, and displaying video during testing. The front-end display service consists of a front-end Nginx load balancer and a front-end website cluster. User requests are forwarded to the front-end website cluster via the load balancer, and the front end interacts with the backend by calling the backend REST API interface using Ajax.

[0096] The platform's data pipeline is designed with dual-path support: a real-time pipeline and a batch pipeline. In the real-time pipeline, messages in the Kafka message queue are parsed in real-time by Spark Streaming and stored in a Redis cluster for real-time querying, and then pushed to the front end in real-time via WebSocket push service. In the batch pipeline, parsed data is stored in an HBase cluster for large-scale historical storage, while Hive and MapReduce periodically store statistical results in an Elasticsearch cluster. Real-time messages are batch-stored in the ClickHouse database for the web server to query the original messages and parsing results. Business data (including account registration, vehicle application, static parameters, etc.) and verification results are written to a MySQL master-slave cluster via the MyCat middleware. The master node is responsible for writing, and the slave nodes are responsible for reading, achieving read-write separation. Verification results are automatically aggregated to generate a standardized data consistency detection report. Hadoop and HDFS handle distributed file storage, while Redis also supports online vehicle status queries. The mobile app detection assistant sends detection tasks and uploads detection images to the web server. These images are stored uniformly by the web server as evidence of the detection process.

[0097] Reference Figure 3 As shown, the platform performs detection and analysis on five operating conditions based on actual vehicle usage: vehicle login / logout detection, vehicle driving detection, vehicle alarm detection, vehicle charging detection, and vehicle data reissue detection, along with corresponding verification methods. For different test items, the data field requirements vary. The platform performs corresponding mechanism-based verification for each detection item, and simultaneously constructs a data rationality model for verification analysis based on actual usage conditions, while also verifying and analyzing the overall quality and accuracy of the messages. The verification model comprehensively employs information fusion, multivariate statistical analysis, electrochemical mechanism algorithms, and machine learning fault diagnosis methods for data analysis and verification. Taking charging tests as an example, in accordance with testing standards, the system performs null value rate, zero value rate, outlier rate, invalid value rate, and range anomaly detection on vehicle data, drive motor data, vehicle positioning data, extreme value data, alarm data, rechargeable energy storage device voltage data, and rechargeable energy storage device temperature data. Compliance results are obtained through multivariate statistical analysis. At the same time, information fusion technology is used to perform comprehensive calculations on charging current, SOC change rate, and vehicle speed. Historical charging data is used to analyze the causes of charging test failures through machine learning fault diagnosis. Ultimately, the system achieves comprehensive coverage of operating conditions, intelligent data review, and timely feedback of test problems, providing testers with an automatic report generation function.

[0098] The consistency verification method of this invention includes six steps: equipment installation and connection, vehicle terminal configuration, system power-on and initialization, test execution, verification and storage, and report generation. In the equipment installation and connection stage, the system host is fixed in the center of the vehicle under test, connected to the vehicle's OBD interface via an OBD 1-to-6 cable to access the CAN / CAN FD bus signal, a voltage / current sensor is installed to the power circuit under test, and a GNSS antenna is installed at a designated location on the roof. In the vehicle terminal configuration stage, the IP address and port corresponding to the testing platform are set in the vehicle terminal T-BOX of the vehicle under test to ensure a reachable communication link with the testing platform. In the system power-on and initialization stage, after powering on, the system waits for the GNSS antenna indicator light to illuminate, confirming that the device has completed satellite positioning and hardware clock training. The host computer software is connected via a network cable to configure the CAN bus baud rate, import the DBC file, configure the power calculation channel, and complete the initialization of the acquisition logic parameters. In the test execution stage, each test task (including login / logout, driving, charging, alarm, and re-sending) is sequentially issued via a mobile APP test assistant, and the APP simultaneously uploads test images to a web server for evidence storage. During this phase, the system performs the following operations according to the aforementioned technical solution: First, high-frequency concurrent data acquisition and hardware timestamp marking are performed. Specifically, the FPGA processing unit captures the current value of the hardware clock counter of the unified clock unit as a timestamp at the frame start bit time, ADC sampling point time, and GNSS / IMU data reception time of the CAN FD frame. Then, end-side hardware protocol parsing and packet fragmentation elimination are performed. This involves using a hardware frame boundary recognition state machine to identify the SOF / EOF flags of the CAN FD bus frame to lock the frame boundary. For streaming data from the UART / Ethernet interface, packet fragmentation elimination and message splicing are performed using a sliding window buffer. Finally, message filtering and streaming parsing are performed. This involves filtering compliant messages through data filtering and message verification (including BCC / CRC verification, VIN consistency verification, and command identifier matching verification), and performing consistency verification through multi-level platform-side verification (including mechanism verification, data rationality verification, data accuracy verification, data quality verification, and data difference analysis). During the testing process, verification personnel can view the original messages and parsed message content in real time via a web interface to monitor the testing progress. During the verification and storage phase, the platform performs real-time calculations on the real-time data in the Kafka queue using various verification logics, and writes the verification results to the MySQL master-slave cluster. In the report generation phase, after the test tasks are completed, the platform automatically summarizes and generates a standardized data consistency test report based on the judgment results of each verification model. The report includes photographic evidence of the testing process.

[0099] Any references to memory, storage, database, or other media used in the embodiments provided in this invention may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory.

[0100] It should be noted that, in this document, relational terms 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 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.

[0101] Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for verifying the consistency of vehicle-mounted data, characterized in that, Includes the following steps: Determine if the PPS signal is valid; If the PPS signal is valid, the system enters the disciplined mode and measures the phase difference between the PPS signal edge and the local clock count; the frequency adjustment of the OCXO is calculated based on the phase error and the cumulative value of the phase error. The frequency adjustment amount is converted into an analog control signal to control the oscillation frequency of the OCXO; closed-loop control locks the frequency to the satellite clock reference, completes clock initialization, and generates a unified clock reference. If the PPS signal is invalid, the system enters hold mode, activates the LSTM timing prediction model, and uses the OCXO frequency, temperature and running time before the signal loss as input to predict the frequency drift compensation of the OCXO. The frequency drift compensation is then added to the deviation correction term of the hardware clock counter to maintain a unified clock reference. When the PPS signal recovers from invalid to valid, the system switches from the hold mode to the docile mode. Acquire vehicle data and capture the current value of the hardware clock counter as the timestamp for receiving the vehicle data; Perform data filtering and message verification on the vehicle data; Time-domain alignment is performed on the vehicle data that has passed data filtering and message verification. Consistency verification is performed on the time-domain aligned vehicle data to obtain the consistency verification results.

2. The method for verifying vehicle data consistency according to claim 1, characterized in that, The data filtering and message verification includes sequentially performing data integrity verification, data enhancement verification, VIN consistency verification, and command identifier matching verification.

3. The method for verifying vehicle data consistency according to claim 1, characterized in that, The step of performing time-domain alignment on the vehicle data that has passed the data filtering and message verification specifically includes: Determine whether the vehicle data carries its own timestamp; If so, calculate the estimated time deviation between the received timestamp and its own timestamp, smooth the multiple estimated time deviations using a sliding window mean filter, and use the least squares method to linearly fit the smoothed deviation sequence to obtain the clock drift rate and the initial fixed deviation. Correct the own timestamp based on the clock drift rate and the initial fixed deviation.

4. The method for verifying vehicle data consistency according to claim 1, characterized in that, The consistency verification includes mechanism verification, data rationality verification, data accuracy verification, data quality verification, and data difference analysis; The mechanism-based verification is used to verify whether the data message conforms to the timing logic and state flow of the preset working conditions; The data rationality verification is used to determine whether the data conforms to physical laws; The data accuracy verification is used to perform threshold analysis and outlier detection on the numerical values ​​of data fields. The data quality verification is used to calculate and quantify the null value rate, zero value rate, outlier rate, and invalid value rate of data fields.

5. A vehicle-mounted data synchronization acquisition device, used to implement the vehicle-mounted data consistency verification method according to any one of claims 1-4, characterized in that, It includes an onboard data acquisition module, an FPGA processing unit, a unified clock unit, and a host computer processing module; among which: The vehicle data acquisition module is used to acquire vehicle data; The FPGA processing unit is equipped with at least two CAN FD controllers and at least two ADC sampling trigger logics in parallel. The FPGA processing unit is used to capture the current value of the hardware clock counter of the unified clock unit as the timestamp of the corresponding data. The unified clock unit includes a GNSS receiver, a DPLL, and an OCXO. The unified clock unit is used to perform frequency discipline on the OCXO through the DPLL when the PPS signal output by the GNSS receiver is valid. The host computer processing module is used to sequentially perform message filtering and integrity verification, time domain alignment and consistency verification on the vehicle data.

6. The vehicle-mounted data synchronization acquisition device according to claim 5, characterized in that, The FPGA processing unit also includes a DMA engine, which is configured to operate always-on in a mode combining continuous circular buffering and ping-pong double buffering, for emptying the hardware FIFO buffer. And / or, The FPGA processing unit is also equipped with a protocol adaptation interface, which is used to convert vehicle data into a unified frame format.

7. The vehicle-mounted data synchronization acquisition device according to claim 6, characterized in that, The FPGA processing unit further includes a hardware frame boundary recognition state machine; the hardware frame boundary recognition state machine includes a frame delimitation state machine and packet fragmentation elimination logic. The frame delimiting state machine is used to identify the SOF and EOF flags; The packet fragmentation elimination logic is configured to pre-read the length field of the packet header to lock the byte boundary of the current packet, temporarily store data bytes that exceed the current packet boundary in a sliding window buffer for concatenation of the next packet, and timestamp the concatenated packet before transmitting it to the host computer processing module via the DMA engine. The sliding window buffer is used to temporarily store the remaining data bytes from the packet merging process.

8. The vehicle-mounted data synchronization acquisition device according to claim 5, characterized in that, The device also includes an NPU, which is connected to the FPGA processing unit; The NPU is used to deploy LSTM time series prediction models; When the PPS signal output by the GNSS receiver is lost, the LSTM timing prediction model is activated to predict the frequency drift compensation of the OCXO in the future period, using the OCXO frequency, temperature and runtime feature sequence before the signal loss as input, and superimposed on the deviation correction term of the hardware clock counter. When the PPS signal output by the GNSS receiver is restored, the unified clock unit is configured to re-enter frequency discipline mode.

Images