A data checking anti-tampering supervision method and system based on automobile OBD

Abstract

The application discloses a kind of based on the data checking and verifying tamper-proofing supervision method and system of automobile OBD, and is related to motor vehicle emission detection supervision technical field.The present application is by being accessed between the passive listening full-quantity communication message of listening device access vehicle OBD interface and checking and verifying equipment, extract vehicle identification code, calibration identification code, calibration verification code, fault code and readiness status bit, bind generation checking and verifying process original record with acquisition time stamp and encrypt storage, then upload to cloud supervision platform, by platform, the OBD checking and verifying result reported by detection agency is consistent with original record Comparison, when inconsistent, generate false alarm information;The present application can solve the problem that OBD checking and verifying process full-quantity communication message record is not complete and data is easy to be tampered with in the current motor vehicle OBD checking and verifying data tamper-proofing supervision scene, and the problem that the checking and verifying result reported by detection agency and original record lack automatic consistency comparison leads to false behavior cannot be timely warned.

Description

Technical Field

[0001] This invention relates to the field of motor vehicle emission testing and supervision technology, and in particular to a data verification and anti-tampering supervision method and system based on vehicle OBD. Background Technology

[0002] Currently, during OBD inspections at vehicle emission testing institutions, to prevent data falsification, the industry commonly employs either adding simple monitoring equipment to the vehicle's OBD interface or relying on the built-in log recording function of the inspection equipment. These solutions typically involve the inspection equipment actively sending read commands to the vehicle's ECU to obtain data such as the vehicle identification number (VIN), calibration identification number (CIN), calibration verification number (CIN), fault codes, and readiness status bits, which are then stored manually or locally on the equipment. This method, to a certain extent, achieves electronic recording of OBD inspection data, providing a foundation for subsequent data verification.

[0003] However, the aforementioned existing technologies generally suffer from the following shortcomings in the face of increasingly sophisticated methods of falsifying vehicle emission test results: First, existing monitoring equipment mostly adopts active query or bypass monitoring modes, which not only easily interferes with the normal communication of the original communication links, but also cannot fully capture the full amount of interactive messages between the inspection equipment and the vehicle ECU, resulting in the loss of key communication data and making it difficult to reconstruct the true inspection process; Second, there is a lack of effective anti-tampering mechanisms, and locally stored inspection data is easily maliciously deleted or tampered with, and is not strongly bound to the vehicle identification number, making data traceability difficult and unable to serve as valid evidence for determining fraud; Third, existing systems mostly operate in isolation and do not achieve real-time linkage with cloud-based monitoring platforms, making it impossible to perform real-time consistency comparison between the OBD inspection results reported by the testing agency and the original communication data recorded by the black box, resulting in the inability to detect and warn of fraudulent behavior in a timely manner, and making it difficult to effectively curb cheating behaviors such as using OBD simulators, blocking fault codes, or rewriting ECUs. Summary of the Invention

[0004] The technical problem to be solved by this invention is to overcome the problems of incomplete full communication message records and easy data tampering in the current supervision scenario of OBD inspection data of motor vehicles, as well as the problem that the inspection results reported by the testing agency lack automated consistency comparison with the original records, which leads to the inability to timely warn of fraudulent behavior.

[0005] To address the aforementioned technical problems, a first aspect of this invention discloses a data verification and anti-tampering monitoring method based on vehicle OBD, the method comprising: The listening device is connected between the vehicle's OBD interface and the inspection equipment, and the listening device passively listens to all communication messages between the OBD interface and the inspection equipment. Extract the vehicle identification code, calibration identification code, calibration verification code, fault code, and ready status bit from the full communication message; The vehicle identification code, calibration identification code, calibration verification code, fault code, and ready status bit are bound to the collection timestamp to generate the original record of the inspection process; The original records of the inspection process are encrypted using a preset encryption algorithm, and the encrypted original records of the inspection process are stored in a local storage medium. The encrypted original record of the inspection process is uploaded to the cloud-based monitoring platform; The cloud-based monitoring platform receives the OBD inspection results reported by the testing agency, compares the OBD inspection results with the original records of the inspection process, and generates a fraud warning when the comparison is inconsistent.

[0006] As an optional implementation, in the first aspect of the present invention, the step of connecting the listening device between the vehicle's OBD interface and the inspection device, and passively listening to all communication messages between the OBD interface and the inspection device through the listening device, includes: The monitoring device includes a housing and a main control chip, an OBD male connector, and an OBD female connector disposed within the housing; The OBD male connector is plugged into the vehicle's OBD interface, and the OBD female connector is used for the diagnostic connector of the inspection equipment to be plugged in. The main control chip passively collects command frames and response frames transmitted between the OBD interface and the inspection device through the OBD male connector and the OBD female connector without interfering with the original communication link. The full communication messages include controller area network messages and K-line communication messages.

[0007] As an optional implementation, in the first aspect of the present invention, the step of extracting the vehicle identification code, calibration identification code, calibration verification code, fault code, and ready status bit from the full communication message includes: The entire communication message is parsed to identify the service identifier and data identifier in the message; When the service identifier corresponds to the vehicle identification code reading service, extract the vehicle identification code field from the response frame; When the service identifier corresponds to the calibration data reading service, the calibration identification code field and the calibration verification code field in the response frame are extracted; When the service identifier corresponds to the fault code read service, the fault code field and the ready status bit field in the response frame are extracted.

[0008] As an optional implementation, in the first aspect of the present invention, the encryption of the original record of the verification process using a preset encryption algorithm includes: The preset encryption algorithm is a hash algorithm or a national cryptographic algorithm; The vehicle identification code in the original record of the inspection process is used as the encryption key input parameter, and an encrypted digest is generated by combining it with the collection timestamp. The encrypted digest is appended to the original record of the verification process to form a tamper-proof data block.

[0009] As an optional implementation, in the first aspect of the present invention, the cloud-based monitoring platform receives the OBD verification results reported by the testing agency, and performs a consistency comparison between the OBD verification results and the original records of the verification process, including: The cloud-based monitoring platform pre-stores OBD inspection and reporting data from motor vehicle emission testing agencies. The OBD inspection and reporting data includes the reported vehicle identification code, the reported calibration identification code, the reported calibration verification code, the reported fault code, and the reported ready status bit. The cloud-based monitoring platform compares the reported vehicle identification number with the vehicle identification number in the original record of the inspection process; The cloud-based monitoring platform compares the reported identification code with the identification code in the original record of the inspection process; The cloud-based monitoring platform compares the reported verification code with the verification code in the original record of the inspection process; The cloud-based monitoring platform compares the reported fault codes and ready status bits with the fault codes and ready status bits in the original records of the inspection process.

[0010] As an optional implementation, in the first aspect of the present invention, the step of generating a forgery warning message when the comparison is inconsistent includes: When the reported calibration identification code is inconsistent with the calibration identification code in the original record of the inspection process, it is determined that there is a risk of calibration data being tampered with, and a calibration tampering warning message is generated. When the reported ready status bit is inconsistent with the ready status bit in the original record of the inspection process, it is determined that there is a risk that the ready status is masked, and an abnormal ready status warning message is generated. When the reported fault code is inconsistent with the fault code in the original record of the inspection process, it is determined that there is a risk that the fault code has been cleared, and an abnormal fault code warning message is generated. The cloud-based monitoring platform records the trigger time of the fraud warning information, the corresponding testing agency identification and vehicle identification code, and generates a traceability audit log.

[0011] As an optional implementation, in the first aspect of the present invention, the method further includes: The monitoring device has a built-in self-check module. The self-check module actively sends standard inspection command frames to the vehicle according to preset inspection standards, receives response frames returned by the vehicle, extracts the self-check vehicle identification code, self-check calibration identification code, self-check calibration verification code, self-check fault code and self-check ready status bit, and generates benchmark inspection data. The cloud-based monitoring platform performs a secondary comparison between the benchmark inspection data and the original records of the inspection process. When there is a discrepancy, it generates an early warning of data falsification for the inspection equipment.

[0012] As an optional implementation, in the first aspect of the present invention, the method further includes: The monitoring device records the device identification information of the currently connected inspection device; When different inspection devices are used, the listening device records the original inspection process records corresponding to each inspection device. The cloud-based monitoring platform cross-compares the original records of the inspection process corresponding to different inspection devices. When there are differences between the calibration identification code or calibration verification code corresponding to the same vehicle identification code on different inspection devices, it determines that there is OBD simulator or ECU rewriting behavior and generates a hardware fraud warning.

[0013] The second aspect of this invention discloses a data verification and anti-tampering monitoring system based on vehicle OBD, used to implement the data verification and anti-tampering monitoring method based on vehicle OBD as described in any one of claims 1-8, the system comprising: The message monitoring module is configured to connect the monitoring device between the vehicle's OBD interface and the inspection equipment, and passively monitor all communication messages between the OBD interface and the inspection equipment through the monitoring device. The parameter extraction module is configured to extract the vehicle identification code, calibration identification code, calibration verification code, fault code, and ready status bit from the full communication message. The record generation module is configured to bind the vehicle identification code, calibration identification code, calibration verification code, fault code and ready status bit with the collection timestamp to generate the original record of the inspection process; The encrypted storage module is configured to encrypt the original records of the inspection process using a preset encryption algorithm and store the encrypted original records of the inspection process in a local storage medium. The data upload module is configured to upload the encrypted original record of the inspection process to the cloud-based monitoring platform; The cloud-based comparison module is configured to receive the OBD inspection results reported by the testing agency on the cloud-based monitoring platform, compare the OBD inspection results with the original records of the inspection process, and generate a fraud warning message when the comparison is inconsistent.

[0014] A third aspect of this invention discloses another data verification and anti-tampering monitoring device based on vehicle OBD, the device comprising: Memory containing executable program code; A processor coupled to the memory; The processor calls the executable program code stored in the memory to execute a data verification and anti-tampering monitoring method based on vehicle OBD as described in the first aspect.

[0015] The beneficial technical effects of the present invention are at least as follows: This invention uses a monitoring device connected in series between the vehicle's OBD interface and the inspection equipment via a topology of physical parallel connection of OBD male and female connectors. Combined with the passive monitoring mode of the main control chip, it replaces the situation where the underlying communication messages cannot be fully recorded by third parties due to the independent direct connection of the inspection equipment to the vehicle. It can capture command frames and response frames on the CAN bus and K-Line from the physical layer without interfering with the original communication link. This helps to alleviate the problem of incomplete recording of all communication messages in the OBD inspection process and the ease with which data can be tampered with in the current supervision scenario of preventing tampering of motor vehicle OBD inspection data. It provides the original communication records for subsequent data solidification. This invention also binds the extracted vehicle identification code, calibration identification code, calibration verification code, fault code and ready status bit with the high-precision acquisition timestamp stamped by the real-time clock module, replacing the deficiency of traditional inspection records lacking time sequence anchors. It can transform unstructured low-level messages into structured original records of the inspection process containing sequential order, making it easier to trace the true state of various parameters in the actual inspection process. This invention also uses the vehicle identification code as one of the input parameters of the encryption key, combined with the collection timestamp, and adopts the national cryptographic SM3 algorithm to generate an encrypted digest of the original record of the inspection process and attach it to form a tamper-proof data block. This replaces the traditional plaintext storage method, which is easily tampered with after the fact. This allows the cloud monitoring platform to detect any modification to the stored data through digest verification, thereby improving the integrity and credibility of the original data of the inspection process. This invention also uploads the encrypted original records of the inspection process to the cloud-based monitoring platform through a communication transmission module and stores them with the vehicle identification code as the primary key. This replaces the traditional scattered mode where inspection data is only stored in local testing equipment or isolated databases, enabling centralized archiving of inspection data and providing data support for automated comparison and analysis on the platform side. This invention also uses a cloud-based monitoring platform to perform a step-by-step consistency comparison between the OBD inspection results reported by the testing agency and the original inspection process records recorded by the monitoring device, based on the vehicle identification code, calibration identification code, calibration verification code, fault code, and ready status bit. When there is a discrepancy, it automatically generates a calibration tampering warning, a ready status abnormality warning, or a fault code abnormality warning according to the type of difference parameter. It also associates the trigger time, testing agency identification, and vehicle identification code to generate a traceability audit log, replacing the traditional ex-post supervision method that relies on manual spot checks or paper file comparison. This can solve the problem that the lack of automated consistency comparison between the inspection results reported by the testing agency and the original records leads to the inability to provide timely warnings of fraudulent behavior. It can automatically identify difference parameters, trigger warnings in a timely manner, and associate them with specific testing agencies and operators, thereby improving the monitoring system's ability to identify hidden fraudulent behavior. This invention also utilizes a built-in self-checking module in the monitoring device to proactively send standard inspection command frames to generate baseline inspection data before formal inspection. This baseline data is then compared a second time with the original records of the passively monitored inspection process via a cloud platform. Furthermore, when different inspection devices are used, the calibration identification codes or calibration verification codes obtained from different devices are cross-compared to identify OBD simulator or ECU remapping behavior. This replaces the traditional method of relying solely on passive monitoring, which struggles to detect data filtering or hardware fraud at the inspection device level. It further identifies data shielding behaviors inherent in the inspection device itself and the risk of illegal tampering with the vehicle's ECU, thereby improving the coverage of motor vehicle emission inspection supervision. Attached Figure Description

[0016] The present invention will be further described with reference to the accompanying drawings, but the embodiments in the drawings do not constitute any limitation on the present invention. For those skilled in the art, other drawings can be obtained based on the following drawings without creative effort.

[0017] Figure 1 This is a simplified flowchart illustrating a data verification and anti-tampering monitoring method based on vehicle OBD, as disclosed in one embodiment of the present invention. Figure 2 This is a schematic diagram of the structure of a data verification and anti-tampering monitoring system based on vehicle OBD, disclosed in one embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a data verification and anti-tampering monitoring device based on vehicle OBD, disclosed in one embodiment of the present invention; Figure 4 This is a hardware structure block diagram of a listening device disclosed in one embodiment of the present invention; Figure 5 This is a physical diagram of a listening device disclosed in one embodiment of the present invention; Figure 6This is a schematic diagram of the installation position of the listening device on the detection line according to one embodiment of the present invention; Figure 7 This is a schematic diagram of the network architecture and data flow between the listening device and the cloud monitoring platform disclosed in one embodiment of the present invention; Figure 8 This is a flowchart of the abnormal data comparison logic of a cloud monitoring platform disclosed in one embodiment of the present invention; Figure 9 This is a schematic diagram of the pin connection between the OBD interface and the monitoring device and diagnostic instrument, as disclosed in one embodiment of the present invention. Detailed Implementation

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

[0019] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this invention are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or end that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or ends.

[0020] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0021] This invention discloses a data verification and anti-tampering monitoring method based on automotive OBD. The invention uses a monitoring device connected in series between the vehicle's OBD interface and the verification equipment in a topology where the OBD male and female connectors are physically connected in parallel. Combined with the passive monitoring mode of the main control chip, this replaces the traditional method where the verification equipment is directly connected to the vehicle, resulting in incomplete recording of underlying communication messages by a third party. It can capture command and response frames from the CAN bus and K-Line at the physical layer without interfering with the original communication link. This helps alleviate the problem of incomplete recording of all communication messages and easy data tampering during the OBD verification process in current automotive OBD data verification and anti-tampering monitoring scenarios. This system provides original communication records for subsequent data solidification. Furthermore, by binding the extracted vehicle identification code, calibration identification code, calibration verification code, fault code, and ready status bit with the high-precision acquisition timestamp added by the real-time clock module, it overcomes the lack of time-series anchors in traditional inspection records. This transforms unstructured underlying messages into structured original records of the inspection process containing sequential information, facilitating subsequent tracing of the actual status of various parameters during the inspection process. Additionally, by using the vehicle identification code as one of the encryption key input parameters, combined with the acquisition timestamp, and employing the national cryptographic SM3 algorithm, it generates an encrypted digest of the original inspection process record and appends it to form a tamper-proof data block, replacing the traditional plaintext storage method. The storage method, which prevents post-incident tampering, ensures that any modifications to the stored data can be detected by the cloud-based monitoring platform through digest verification, thereby improving the integrity and reliability of the original data during the inspection process. Furthermore, the encrypted original inspection records are uploaded to the cloud-based monitoring platform via a communication transmission module and stored with the vehicle identification number (VIN) as the primary key. This replaces the traditional scattered model where inspection data is stored only on local testing equipment or in isolated databases, enabling centralized archiving of inspection data and providing data support for automated comparison and analysis on the platform side. Additionally, the cloud-based monitoring platform compares the OBD inspection results reported by the testing agency with the original inspection records recorded by the monitoring device, categorized by vehicle identification number and label... The system performs a step-by-step consistency comparison of the identification code, calibration verification code, fault code, and ready status bit. When inconsistencies are found, it automatically generates a calibration tampering warning, a ready status abnormality warning, or a fault code abnormality warning based on the type of difference parameter. It also associates the trigger time, testing agency identification, and vehicle identification code to generate a traceability audit log. This replaces the traditional ex-post supervision method that relies on manual spot checks or paper file comparison. It can solve the problem that the lack of automated consistency comparison between the inspection results reported by the testing agency and the original records leads to the inability to provide timely warnings of fraudulent behavior. It can automatically identify difference parameters, trigger warnings in a timely manner, and associate them with specific testing agencies and operators, thereby improving the regulatory system's ability to identify hidden fraudulent behavior.Furthermore, the built-in self-checking module of the monitoring device proactively sends standard inspection command frames to generate benchmark inspection data before formal inspection. This benchmark data is then compared a second time with the original records of the passively monitored inspection process via a cloud platform. Additionally, when different inspection devices are used, the calibration identification codes or calibration verification codes obtained from different devices are cross-compared to identify OBD simulator or ECU remapping behavior. This replaces the traditional method of relying solely on passive monitoring, which struggles to detect data filtering or hardware fraud at the inspection device level. It further identifies data masking behavior inherent in the inspection device itself and the risk of illegal tampering with the vehicle's ECU, thereby improving the coverage of motor vehicle emission inspection supervision.

[0022] Example 1

[0023] Please see Figure 1 , Figure 1 This is a simplified flowchart illustrating a data verification and anti-tampering monitoring method based on vehicle OBD, as disclosed in one embodiment of the present invention. This method is applied in the field of motor vehicle emission testing technology and is used to execute the data verification and anti-tampering monitoring method based on vehicle OBD as described in claim 1. Figure 1 As shown, this data verification and tamper-proof supervision method based on vehicle OBD can include the following operations: 101. Connect the listening device between the vehicle's OBD interface and the inspection equipment, and passively listen to all communication messages between the OBD interface and the inspection equipment through the listening device.

[0024] Specifically, the listening device is connected between the vehicle's OBD interface and the inspection equipment. The listening device contains a main control chip, an OBD male connector, and an OBD female connector. It should be noted that the hardware entity shown as a "black box device" or "black box" in the accompanying drawings is essentially the listening device itself; both are different names for the same physical entity. To maintain terminology consistency, it will be consistently referred to as the listening device below. The OBD male connector plugs into the vehicle's OBD interface, and the OBD female connector is for the diagnostic connector of the inspection equipment. The main control chip passively collects command and response frames transmitted between the OBD interface and the inspection equipment via the OBD male and female connectors, without interfering with the existing communication link. All communication messages include controller area network messages and K-line communication messages. Figure 6 As shown, the male connector of the listening device is inserted into the vehicle's OBD interface, and the original factory OBD diagnostic equipment is inserted into the female connector of the listening device. A physical parallel connection is achieved through a 1-to-2 OBD interface cable. Figure 9As shown, the corresponding pins of the OBD male connector and female connector are directly connected, and the CAN bus signal line and K-Line signal line are led out. The bus monitoring and data acquisition module is electrically connected to the CAN bus signal line and K-Line signal line, configured in passive monitoring mode, to capture all low-level communication messages between the inspection device and the vehicle ECU in real time.

[0025] More specifically, taking a vehicle emissions testing scenario as an example, the operator first inserts the male connector of the monitoring device into the vehicle's OBD interface, and then inserts the OBD verification device into the female connector of the monitoring device. After the verification device is powered on, it begins handshaking communication with the vehicle's ECU, and the monitoring device immediately starts silent monitoring mode. When the verification device sends a command frame to read the VIN code, such as 09 02, the vehicle ECU returns the actual VIN code, such as LVSHDAC. The monitoring device instantly captures this question-and-answer message and timestamps it. When the verification device sends a command frame to read the fault code, such as 03, if the vehicle has a P0420 fault, the ECU will return this code, and the monitoring device records it accordingly. Throughout the entire process, the monitoring device does not send any active requests to the bus, but only passively sniffs and records all the underlying communication messages.

[0026] It is evident that by using physical parallel connection and passive monitoring mechanism, the interaction messages between the inspection equipment and the vehicle ECU can be fully obtained without modifying the original communication link, providing a data source for subsequent data solidification and consistency comparison.

[0027] 102. Extract the vehicle identification code, calibration identification code, calibration verification code, fault code, and ready status bit from the full communication message.

[0028] Specifically, the entire communication message is parsed to identify the service identifier and data identifier. When the service identifier corresponds to the vehicle identification code (VIC) read service, the VIC field in the response frame is extracted; when the service identifier corresponds to the calibration data read service, the calibration identification code field and calibration verification code field in the response frame are extracted; when the service identifier corresponds to the fault code read service, the fault code field and ready status bit field in the response frame are extracted. The data processing and control module is connected to the bus monitoring and data acquisition module to parse and cache communication messages and extract key OBD parameters.

[0029] More specifically, taking a gasoline vehicle OBD inspection scenario as an example, the monitoring device detects a command to read the VIN code sent by the inspection equipment. The service identifier corresponds to service 09, and the data identifier is 02. The 17-byte vehicle identification code is extracted from the response frame returned by the ECU. Upon detecting a command to read calibration data, the service identifier corresponds to service 04, and the calibration identification code and calibration verification code are extracted. Upon detecting a command to read fault codes, the service identifier corresponds to service 03. If the vehicle has a low catalytic efficiency fault, the fault code P0420 and the catalytic converter ready flag being 0 in the ready status bit are extracted from the response frame.

[0030] It is evident that by parsing the protocol of all communication messages and extracting key parameters according to service type, unstructured underlying messages can be transformed into structured data that can be used for comparison, providing clear input for subsequent steps.

[0031] 103. Bind the vehicle identification code, calibration identification code, calibration verification code, fault code and ready status bit to the collection timestamp to generate the original record of the inspection process.

[0032] Specifically, a real-time clock module is used to assign a high-precision timestamp to each set of extracted key OBD parameters. The vehicle identification number (VIN), calibration identification number (CIN), calibration verification number (CIN), fault code, and ready status bit are bound to the acquisition timestamp to form an original record of the verification process containing timing logic. The real-time clock module is used to assign a high-precision timestamp to each set of acquired communication messages to establish the timing logic of data generation.

[0033] More specifically, taking a daily inspection scenario as an example, the monitoring device captures the command and response to read the VIN code at time T1, extracting the vehicle identification number; and captures the command and response to read the fault code at time T2, extracting the fault code and the ready status bit. The system binds the above parameters with their respective timestamps to generate an original record of the inspection process. This record clearly records the values ​​of each key parameter and the order in which they were generated, forming an undeniable chain of evidence.

[0034] It is evident that binding and storing key OBD parameters with the collection timestamp preserves the chronological order of data generation, facilitating the actual status of each parameter during subsequent traceability and verification.

[0035] 104. Encrypt the original record of the verification process using a preset encryption algorithm, and store the encrypted original record of the verification process in a local storage medium.

[0036] Specifically, a preset encryption algorithm is used to encrypt the original records of the inspection process. The preset encryption algorithm is either a hash algorithm or a national cryptographic algorithm. The vehicle identification number in the original records of the inspection process is used as the encryption key input parameter. Combined with the collection timestamp, an encrypted digest is generated and appended to the original records of the inspection process to form a tamper-proof data block. The encryption and secure storage module is used to perform tamper-proof encryption processing on the collected original communication data stream and the parsed key data, and store them in non-volatile memory.

[0037] More specifically, taking a specific inspection as an example, the monitoring device extracts the vehicle identification number, calibration identification number, calibration verification number, fault code, and ready status bit. Combined with the acquisition timestamp, it uses the national cryptographic SM3 algorithm to generate a digital signature on the original communication message stream. This signature is then appended to the original inspection record, forming a tamper-proof data block and saved to local Flash memory. Even if someone attempts to modify the stored fault code field, the monitoring platform can immediately identify that the data has been tampered with because the digital signature verification fails.

[0038] It is evident that by using encryption algorithms to process and store the original records of the verification process locally, any modification to the stored data can be detected, thereby improving the integrity and credibility of the data.

[0039] 105. Upload the encrypted original record of the verification process to the cloud monitoring platform.

[0040] Specifically, a data channel is established between the data processing and control module and the cloud-based monitoring platform via a communication transmission module. This allows for the uploading of encrypted original records of the inspection process, which are then bound to the corresponding vehicle identification number (VIN). The communication transmission module supports Ethernet, 4G, 5G, or NB-IoT wireless communication methods, enabling automatic triggering of uploads after inspection or immediate alarm uploads upon detection of abnormal communication commands. Figure 7 As shown, the monitoring device is deployed between the industrial control computer and the OBD inspection equipment on the testing line of each motor vehicle emission testing agency. The encrypted data is uploaded to the cloud monitoring platform for archiving via the network architecture.

[0041] More specifically, taking a testing station scenario as an example, after the inspection is completed, the listening device automatically triggers an upload, sending the encrypted original record of the inspection process to the cloud-based monitoring platform via a 4G network. Upon receiving the data, the platform stores it using the vehicle identification number (VIN) as the primary key, achieving a strong binding between the inspection data and the specific vehicle. Supervisory personnel can retrieve the VIN and its historical inspection records at any time through the platform.

[0042] As can be seen, uploading the encrypted original records of the inspection process to the cloud and binding them with the vehicle identification number enables centralized archiving of inspection data, providing data support for subsequent comparison and analysis on the platform side.

[0043] 106. The cloud-based monitoring platform receives the OBD inspection results reported by the testing agency, compares the OBD inspection results with the original records of the inspection process, and generates a fraud warning when the comparison is inconsistent.

[0044] Specifically, the cloud-based monitoring platform pre-stores OBD inspection reporting data from motor vehicle emission testing agencies. This data includes the reported vehicle identification number (VIN), calibration identification number (CIN), calibration verification number (CIN), fault code, and ready status bit. The cloud-based monitoring platform retrieves the original inspection records for the same VIN during the same time period. Based on the logic of GB 3847 and GB 18285 standards, it compares the reported VIN with the VIN in the original inspection records, the reported CIN with the CIN in the original inspection records, the reported CIN with the CIN in the original inspection records, the reported CIN with the CIN in the original inspection records, and the reported fault code and ready status bit with the fault code and ready status bit in the original inspection records. For example... Figure 8 As shown, when the testing agency reports a qualified result but the original record data contains emission-related fault codes or is in a state of insecurity, it is automatically marked as abnormal data, generating a fraud warning message. The warning and traceability module is used to link to the corresponding testing agency, testing time, and operator to achieve accurate source tracing.

[0045] More specifically, taking a scenario where a testing agency reports a qualified OBD inspection result as an example, the cloud-based monitoring platform retrieves the original data recorded by the vehicle's monitoring device. It finds that the original record contains fault code P0420 and the catalytic converter is not ready in the ready status bit. Based on the logic of GB 3847 and GB 18285 standards, the platform determines that the reported result is inconsistent with the original record, automatically marks it as abnormal data, and generates a fraud warning. If the inspection device has built-in filtering software, its interface may display no fault code, but the data packet recorded by the monitoring device may still contain P0420; the platform can still identify this difference and issue a warning.

[0046] It is evident that by comparing the OBD verification results reported by the testing agency with the original communication data recorded by the monitoring device, the discrepancies between the reported data and the actual communication records can be identified, thus providing a basis for identifying potential tampering or blocking behavior.

[0047] As an optional embodiment, the step described above, namely connecting the listening device between the vehicle's OBD interface and the inspection device, and passively monitoring all communication messages between the OBD interface and the inspection device through the listening device, includes: The monitoring device includes a housing and a main control chip, an OBD male connector, and an OBD female connector disposed within the housing; The OBD male connector is plugged into the vehicle's OBD interface, and the OBD female connector is used for the diagnostic connector of the inspection equipment to be plugged in. The main control chip passively collects command frames and response frames transmitted between the OBD interface and the inspection device through the OBD male connector and the OBD female connector without interfering with the original communication link. The full communication messages include controller area network messages and K-line communication messages.

[0048] Specifically, such as Figures 4-5 As shown, Figure 4 The connection relationships of the internal hardware modules of the monitoring device are shown. Figure 5 The diagram shows the physical cable configuration of the listening device, which is connected in series between the vehicle's OBD interface and the inspection equipment via a 1-to-2 parallel topology. Figure 9 As shown, the corresponding pins of the OBD male connector and the OBD female connector are directly connected via internal flying wires, forming a physical parallel bypass. This parallel structure ensures a complete and direct diagnostic communication link between the inspection equipment and the vehicle, while allowing the monitoring device to passively acquire data from the backbone communication line. The bus monitoring and data acquisition module is electrically connected to the CAN bus signal line and K-Line signal line led out from the OBD parallel interface unit, configured in passive monitoring mode, supporting ISO 15765, ISO 9141, ISO 14230 and SAE J1850 protocol standards, and is capable of capturing complete frame data from the physical layer to the data link layer.

[0049] More specifically, taking the testing scenario of a certain motor vehicle emissions testing agency as an example, the OBD interface uses the standard OBD-II 16-pin pin. After the male connector of the listening device is inserted into the vehicle's OBD interface, it obtains vehicle bus data through the internally connected pins. According to... Figure 9 The circuit connections shown are illustrated below, with key communication pin mappings as follows: CAN_H is the controller area network high signal, corresponding to pin 6 of the car's OBD interface. This pin is directly connected to pin 6 of the monitoring device interface and the OBD diagnostic tool interface. CAN_L is the Controller Area Network low signal, corresponding to pin 14 of the car's OBD interface. This pin is directly connected to pin 14 of the monitoring device interface and the OBD diagnostic tool interface. K-Line, or K-line, corresponds to pin 7 of the car's OBD interface. This pin is directly connected to pin 7 of the monitoring device interface and the OBD diagnostic tool interface.

[0050] After the female connector is connected to the inspection equipment, the diagnostic connector of the inspection equipment establishes communication with the vehicle's OBD interface through a direct connection cable inside the listening device. The main control chip of the listening device passively captures all underlying communication messages from the above three key pins through a coupling circuit, including but not limited to command frames and response frames of the CAN bus and K-line, to achieve full message recording.

[0051] It is evident that by using the physical parallel structure of the OBD male and female connectors and the passive acquisition method, it is possible to obtain the full communication messages between the inspection equipment and the vehicle without modifying the original detection equipment, providing a complete data source for subsequent analysis and extraction.

[0052] As an optional embodiment, the step described above, extracting the vehicle identification code, calibration identification code, calibration verification code, fault code, and ready status bit from the full communication message, includes: The entire communication message is parsed to identify the service identifier and data identifier in the message; When the service identifier corresponds to the vehicle identification code reading service, extract the vehicle identification code field from the response frame; When the service identifier corresponds to the calibration data reading service, the calibration identification code field and the calibration verification code field in the response frame are extracted; When the service identifier corresponds to the fault code read service, the fault code field and the ready status bit field in the response frame are extracted.

[0053] Specifically, the data processing and control module connects to the bus monitoring and data acquisition module to parse and cache all captured communication messages, extracting key OBD data. The system identifies the application layer service identifier and data identifier in the message, and locates and reads the corresponding data fields from the response frame according to the service type: when the service identifier corresponds to the vehicle identification code, the vehicle identification code field is extracted; when the service identifier corresponds to the calibration data, the calibration identification code field and calibration verification code field are extracted; and when the service identifier corresponds to the fault code, the fault code field and ready status bit field are extracted.

[0054] More specifically, taking a gasoline vehicle OBD inspection scenario as an example, the monitoring device detects a command to read the VIN code sent by the inspection equipment. The service identifier corresponds to service 09, and the data identifier is 02. The response frame returned by the vehicle ECU contains the vehicle identification code, such as LVSHDAC, which the system extracts. Upon detecting a command to read a fault code, the service identifier corresponds to service 03, and the vehicle ECU returns a fault code, such as P0420, which the system extracts. For calibration identification codes and calibration verification codes, the monitoring device detects a command to read calibration data, the service identifier corresponding to the calibration data read service. The response frame returned by the vehicle ECU carries the calibration identification code and calibration verification code. The system extracts these two fields from the response frame and also extracts the ready status bit along with the fault code response frame. The above process fully covers the acquisition of five key parameters: vehicle identification code, calibration identification code, calibration verification code, fault code, and ready status bit.

[0055] As can be seen, by parsing the protocol to identify the service identifier and extracting the corresponding fields in the response frame according to the type, the unstructured underlying messages captured by the monitoring device can be transformed into the original records of the verification process containing specific parameter values, providing a structured data foundation for subsequent timestamp binding and consistency comparison.

[0056] As an optional embodiment, the step above, encrypting the original record of the verification process using a preset encryption algorithm, includes: The preset encryption algorithm is a hash algorithm or a national cryptographic algorithm; The vehicle identification code in the original record of the inspection process is used as the encryption key input parameter, and an encrypted digest is generated by combining it with the collection timestamp. The encrypted digest is appended to the original record of the verification process to form a tamper-proof data block.

[0057] Specifically, the encryption and secure storage module performs tamper-proof encryption on the original verification process records output by the data processing and control module. The default encryption algorithm is a hash algorithm or the national cryptographic algorithm SM3. The system uses the vehicle identification code in the original verification process record as one of the encryption key input parameters, along with the collection timestamp, to generate a fixed-length encrypted digest through hash operations. The vehicle identification code is a unique identifier for a vehicle; using it as a key input parameter ensures that the encrypted digests for different vehicles are different, thereby enhancing tamper-proof strength. Subsequently, this encrypted digest is appended to the original verification process record to form a tamper-proof data block and stored in local non-volatile memory.

[0058] More specifically, taking a gasoline vehicle inspection as an example, the monitoring device captures the commands and responses for reading the VIN code and fault code at times T1 and T2 respectively, extracting parameters such as the Vehicle Identification Number (LVSHDAC), fault code P0420, and ready status bits, and binding them with timestamps to generate the original record of the inspection process. The encryption and secure storage module uses the LVSHDAC as the key input parameter, combined with the acquisition timestamp, and performs a hash operation on the data stream of the original record using the national cryptographic algorithm SM3, obtaining a 256-bit digital signature as the encryption digest. This digital signature is appended to the end of the original inspection record, forming a tamper-proof data block and saved to local Flash memory. When subsequent data is uploaded to the cloud monitoring platform, the platform can recalculate the digest using the same algorithm and the LVSHDAC. If the digest is inconsistent with the appended digest, it indicates that the data was modified during storage or transmission.

[0059] It is evident that by using the vehicle identification number as the input parameter for encryption and combining it with the collection timestamp to generate an encrypted digest, each vehicle's tamper-proof data block can have a unique and verifiable digital fingerprint. Any tampering with key parameters or timestamps in the original record will cause the digest verification to fail, thereby effectively improving the integrity and credibility of the original data in the inspection process and providing a reliable data foundation for comparison and analysis on the cloud-based monitoring platform.

[0060] As an optional embodiment, in the above steps, the cloud-based monitoring platform receives the OBD verification results reported by the testing agency and performs a consistency comparison between the OBD verification results and the original records of the verification process, including: The cloud-based monitoring platform pre-stores OBD inspection and reporting data from motor vehicle emission testing agencies. The OBD inspection and reporting data includes the reported vehicle identification code, the reported calibration identification code, the reported calibration verification code, the reported fault code, and the reported ready status bit. The cloud-based monitoring platform compares the reported vehicle identification number with the vehicle identification number in the original record of the inspection process; The cloud-based monitoring platform compares the reported identification code with the identification code in the original record of the inspection process; The cloud-based monitoring platform compares the reported verification code with the verification code in the original record of the inspection process; The cloud-based monitoring platform compares the reported fault codes and ready status bits with the fault codes and ready status bits in the original records of the inspection process.

[0061] Specifically, the data analysis and comparison engine runs on a cloud-based monitoring platform. It is configured to receive OBD inspection results reported by testing agencies and retrieve original recordings from monitoring devices for the same vehicle identification number (VIN) during the same time period. The engine incorporates GB 3847 and GB 18285 standard logic, comparing the reported OBD inspection data with key parameters in the original records item by item. First, it compares whether the reported VIN matches the VIN in the original records. Second, it compares whether the reported calibration identification code matches the calibration identification code in the original records. Third, it compares whether the reported calibration verification code matches the calibration verification code in the original records. Finally, it compares whether the reported fault codes and ready status bits match the fault codes and ready status bits in the original records. Through this item-by-item comparison, it can accurately pinpoint the categories of parameters with discrepancies.

[0062] More specifically, taking a scenario where a testing agency reports a qualified OBD inspection result as an example, the cloud-based monitoring platform receives the OBD inspection report data from the testing agency, which includes a reported result of "qualified," no reported fault codes, and a reported ready status bit of "all ready." The platform retrieves the original data recorded by the corresponding monitoring device based on the vehicle identification number (VIN). It finds that the original record contains fault code P0420 and the catalytic converter is not ready in the ready status bit. Following the logic of GB 3847 and GB18285 standards, the platform compares the reported fault code with the fault code in the original record, finding that the reported fault code is "none" while the original record shows P0420, indicating a discrepancy. It also compares the reported ready status bit with the ready status bit in the original record, finding that the reported ready status is "all ready" while the original record shows the catalytic converter is not ready, again indicating a discrepancy. Based on these comparison results, the platform determines that the reported result is inconsistent with the original record. Figure 8 As shown. At this point, the system triggers the anomaly handling procedure, issuing a question to Station I, which needs to replace the equipment for re-inspection; if the re-inspection data still does not match the monitored data, a fraud warning report will be generated.

[0063] It is evident that by comparing each OBD inspection parameter reported by the testing agency with the original communication data recorded by the monitoring device, the differences in specific parameters between the reported data and the actual communication records can be accurately identified. This provides clear and traceable basis for identifying potential calibration data tampering, fault code masking, or readiness status forgery, triggering subsequent anomaly handling procedures and significantly improving the regulatory platform's ability to identify concealed fraudulent activities.

[0064] As an optional embodiment, the step described above, generating a forgery warning when the comparison is inconsistent, includes: When the reported calibration identification code is inconsistent with the calibration identification code in the original record of the inspection process, it is determined that there is a risk of calibration data being tampered with, and a calibration tampering warning message is generated. When the reported ready status bit is inconsistent with the ready status bit in the original record of the inspection process, it is determined that there is a risk that the ready status is masked, and an abnormal ready status warning message is generated. When the reported fault code is inconsistent with the fault code in the original record of the inspection process, it is determined that there is a risk that the fault code has been cleared, and an abnormal fault code warning message is generated. The cloud-based monitoring platform records the trigger time of the fraud warning information, the corresponding testing agency identification and vehicle identification code, and generates a traceability audit log.

[0065] Specifically, the early warning and traceability module runs on the cloud-based monitoring platform. It is configured to generate categorized early warning information based on the type of inconsistency when the data analysis and comparison engine determines that the reported results are inconsistent with the original records. For example, if the reported calibration identification code is inconsistent with the calibration identification code in the original records, it indicates a risk of calibration data tampering and generates a calibration tampering early warning; if the reported ready status bit is inconsistent with the ready status bit in the original records, it indicates a risk of the ready status being masked and generates a ready status anomaly early warning; and if the reported fault code is inconsistent with the fault code in the original records, it indicates a risk of the fault code being cleared and generates a fault code anomaly early warning. Simultaneously, the cloud-based monitoring platform records the trigger time, corresponding testing agency identifier, and vehicle identification code for each fraud early warning message, storing these three pieces of information in association to generate a traceability audit log, enabling precise traceability.

[0066] More specifically, taking a scenario where a testing agency reports a qualified OBD inspection result as an example, the cloud-based monitoring platform retrieves the original records from the vehicle's monitoring device. The original records contain fault code P0420 and the catalytic converter is not ready in the ready status bit, while the reported fault code is none and the reported ready status bit is all ready. The platform determines that the reported fault code is inconsistent with the original record, indicating a risk of the fault code being cleared, and generates a fault code anomaly warning. Simultaneously, it determines that the reported ready status bit is inconsistent with the original record, indicating a risk of the ready status being masked, and generates a ready status anomaly warning. The platform records the current time as the trigger time, obtains the testing agency's unique identifier and the vehicle identification number (LVSHDAC) of the vehicle, and associates this information with the warning information to generate a traceability audit log. After logging into the platform, regulatory personnel can quickly locate the specific testing agency, testing time, and involved vehicle based on this log, thus achieving responsibility determination.

[0067] It is evident that by generating classified early warning information based on inconsistent parameter types and recording the trigger time, testing agency identification, and vehicle identification code to generate traceability audit logs, different fraudulent methods can be accurately distinguished, and regulatory authorities can be provided with a clear and traceable chain of evidence of violations, thereby effectively enhancing the ability to trace and deter the concealed fraudulent behavior of testing agencies.

[0068] As an optional embodiment, in the above steps, the monitoring device has a built-in self-check module. This self-check module actively sends standard inspection command frames to the vehicle according to preset inspection standards, receives response frames returned by the vehicle, extracts the self-check vehicle identification code, self-check calibration identification code, self-check calibration verification code, self-check fault code, and self-check ready status bit, and generates baseline inspection data. The cloud-based monitoring platform performs a secondary comparison between the baseline inspection data and the original records of the inspection process. When inconsistencies are found, it generates a data falsification warning for the inspection equipment, including: The monitoring device has a built-in self-check module. The self-check module actively sends standard inspection command frames to the vehicle according to preset inspection standards, receives response frames returned by the vehicle, extracts the self-check vehicle identification code, self-check calibration identification code, self-check calibration verification code, self-check fault code and self-check ready status bit, and generates benchmark inspection data. The cloud-based monitoring platform performs a secondary comparison between the benchmark inspection data and the original records of the inspection process. When there is a discrepancy, it generates an early warning of data falsification for the inspection equipment.

[0069] Specifically, the self-check module built into the monitoring device is configured to proactively send standard inspection command frames to the vehicle ECU according to the national standards GB 3847 and GB18285 before the formal inspection begins, performing a complete pre-check. The self-check module sends command frames to read the VIN code, read the calibration data, and read the fault code, and the vehicle ECU returns the corresponding response frames. The system extracts the self-check vehicle identification code, self-check calibration identification code, self-check calibration verification code, self-check fault code, and self-check ready status bit from the response frames, combines these parameters to generate baseline inspection data, and uploads it to the cloud monitoring platform for archiving via the communication transmission module. Subsequently, the inspection device is inserted into the monitoring device's female connector for formal inspection. The monitoring device passively records the communication messages between the inspection device and the vehicle ECU and generates the original inspection process record. The cloud monitoring platform retrieves the baseline inspection data corresponding to the same vehicle identification code and compares it with the original inspection process record. If there is a difference in any key parameter, it determines that the inspection device may have engaged in data filtering or tampering, generating a data falsification warning for the inspection device.

[0070] More specifically, taking the testing scenario of a motor vehicle emissions testing agency as an example, before the test begins, the operator first activates the self-check function of the monitoring device. The monitoring device actively sends a command to the vehicle ECU to read the VIN code, with the service identifier corresponding to service 09 and the data identifier being 02. The vehicle ECU returns a vehicle identification code such as LVSHDAC, which the system extracts as the self-check vehicle identification code. A command to read calibration data is then sent, with the service identifier corresponding to the calibration data read service, extracting the self-check calibration identification code and self-check calibration verification code. A command to read fault codes is then sent, with the service identifier corresponding to service 03. The vehicle ECU returns a fault code such as P0420, which the system extracts as the self-check fault code and the ready status bit as the self-check ready status bit. These five self-check parameters constitute the baseline verification data and are uploaded to the cloud monitoring platform. The operator then inserts the original OBD diagnostic equipment into the female connector of the listening device for formal inspection. The listening device records all communication messages between the diagnostic equipment and the vehicle's ECU, extracting the vehicle identification number (VIN), calibration identification number (CIN), calibration verification number (CIN), fault codes, and ready status bits. This generates and uploads the original inspection process record. The cloud-based monitoring platform performs a secondary comparison between the baseline inspection data and the original inspection process record. It discovers a fault code P0420 in the baseline data, while the original inspection process record does not contain this code. This discrepancy triggers a data falsification warning from the platform, indicating that the diagnostic equipment may be filtering fault codes. In practical use, the testing station can also use OBD diagnostic tools from different brands for separate inspections. The listening device records the original inspection process for each instance, and the cloud platform cross-compares the baseline data with multiple inspection records to further verify the authenticity of the diagnostic equipment's data.

[0071] It is evident that by proactively sending standard inspection commands through the self-inspection module to generate benchmark inspection data and comparing it with the original records of the inspection process passively monitored, the cloud-based monitoring platform can be provided with independent and authentic data references. This effectively identifies data filtering or tampering behaviors that may exist on the inspection equipment itself, making up for the regulatory blind spots that may not be detected by relying solely on passive monitoring, and improving the comprehensiveness and reliability of supervision.

[0072] As an optional embodiment, in the above steps, the monitoring device records the device identification information of the currently connected inspection device; when different inspection devices are replaced, the monitoring device records the original inspection process records corresponding to each inspection device; the cloud monitoring platform cross-compares the original inspection process records corresponding to different inspection devices, and when there are differences between the calibration identification code or calibration verification code corresponding to the same vehicle identification code in different inspection devices, it determines that there is OBD simulator or ECU rewriting behavior, and generates a hardware fraud warning, including: The monitoring device records the device identification information of the currently connected inspection device; When different inspection devices are used, the listening device records the original inspection process records corresponding to each inspection device. The cloud-based monitoring platform cross-compares the original records of the inspection process corresponding to different inspection devices. When there are differences between the calibration identification code or calibration verification code corresponding to the same vehicle identification code on different inspection devices, it determines that there is OBD simulator or ECU rewriting behavior and generates a hardware fraud warning.

[0073] Specifically, each time the monitoring device establishes a connection with the inspection equipment, it automatically records the device identification information of the currently connected inspection equipment through the communication transmission module. The device identification information includes the device serial number or brand and model. When the inspection station uses different brands of inspection equipment to repeatedly inspect the same vehicle, the monitoring device records each original inspection process record separately. Each record carries the corresponding device identification information and vehicle identification code, and is uploaded to the cloud monitoring platform. For the same vehicle identification code, the cloud monitoring platform extracts the calibration identification code and calibration verification code from the original inspection process records corresponding to different inspection equipment and performs cross-comparison. Under normal circumstances, the ECU calibration data of the same vehicle should remain fixed. If the calibration identification code or calibration verification code read by different inspection equipment differs, it indicates that one of the inspection equipment may have connected to an OBD simulator and returned forged calibration data, or that the vehicle's ECU has been rewritten or replaced. Based on this, the cloud platform determines that there has been OBD simulator or ECU rewriting behavior and generates a hardware fraud warning.

[0074] More specifically, taking a suspicious vehicle inspection scenario at a certain inspection station as an example, the station first used a diagnostic tool of brand A connected to a listening device for inspection. The listening device recorded the calibration identification code A123 in the original record of this inspection process, with the device identification being brand A. Subsequently, the inspection station switched to a diagnostic tool of brand B and inspected the same vehicle again. The listening device recorded the calibration identification code B456, with the device identification being brand B. The cloud monitoring platform retrieved the two original inspection process records under the same vehicle identification code and cross-compared the calibration identification code A123 corresponding to brand A with the calibration identification code B456 corresponding to brand B, finding that they were inconsistent. Since the ECU calibration identification code of the same vehicle should be unique and fixed, the platform determined that the discrepancy indicated a risk of data forgery using an OBD simulator or that the vehicle's ECU had been rewritten or replaced, and thus generated a hardware fraud warning. In addition, the monitoring device also provides vehicle diagnostic software to execute a multi-system VIN code reading program. It compares the monitored vehicle VIN code with the VIN codes read from each major component system. If a missing or changed VIN code is found, it can further confirm whether a component has been replaced or whether there has been simulator behavior, providing auxiliary analysis basis for the cloud platform's judgment.

[0075] It is evident that by recording the identification information of different inspection devices and cross-comparing the calibration identification codes or calibration verification codes obtained from different devices, it is possible to effectively detect abnormal phenomena such as inconsistencies in key parameters of the same vehicle under different diagnostic devices. This provides a reliable basis for identifying OBD simulator cheating or illegal ECU remapping, fills the regulatory blind spots that may exist in single-device inspection, and further improves the comprehensiveness and accuracy of the regulatory system.

[0076] Example 2

[0077] Please see Figure 2 , Figure 2 This is a schematic diagram of a data verification and anti-tampering monitoring system based on vehicle OBD, disclosed in one embodiment of the present invention. This system is applied in the field of motor vehicle emission testing technology to implement a data verification and anti-tampering monitoring method based on vehicle OBD as described in Embodiment 1. Figure 2 As shown, the system may specifically include the following modules: The message monitoring module 201 is configured to connect the monitoring device between the vehicle's OBD interface and the inspection device, and passively monitor all communication messages between the OBD interface and the inspection device through the monitoring device. The parameter extraction module 202 is configured to extract the vehicle identification code, calibration identification code, calibration verification code, fault code, and ready status bit from the full communication message. The record generation module 203 is configured to bind the vehicle identification code, calibration identification code, calibration verification code, fault code and ready status bit with the collection timestamp to generate the original record of the inspection process; The encrypted storage module 204 is configured to: encrypt the original record of the inspection process using a preset encryption algorithm, and store the encrypted original record of the inspection process in a local storage medium; The data upload module 205 is configured to upload the encrypted original record of the inspection process to the cloud-based monitoring platform. The cloud-based comparison module 206 is configured as follows: the cloud-based monitoring platform receives the OBD inspection results reported by the testing agency, compares the OBD inspection results with the original records of the inspection process, and generates a fraud warning message when the comparison is inconsistent.

[0078] The message monitoring module 201 is configured to connect the monitoring device between the vehicle's OBD interface and the inspection device, and passively monitor all communication messages between the OBD interface and the inspection device through the monitoring device.

[0079] Specifically, this module corresponds to the bus monitoring and data acquisition module and main control chip within the monitoring device. Through a physical parallel structure of the OBD male and female connectors, it passively captures command and response frames transmitted between the inspection device and the vehicle ECU without interfering with the existing communication link. All communication messages include controller area network messages and K-line communication messages. For specific details regarding passive monitoring and physical connection, please refer to the above explanation of connecting the monitoring device to the vehicle's OBD interface and the inspection device.

[0080] As can be seen, this module provides a complete and authentic source of original messages for subsequent data parsing and cloud comparison through parallel access and passive acquisition at the physical layer, avoiding communication anomalies caused by active interference.

[0081] The parameter extraction module 202 is configured to extract the vehicle identification code, calibration identification code, calibration verification code, fault code, and ready status bit from the full communication message.

[0082] Specifically, this module corresponds to the data processing and control module within the monitoring device. It performs protocol parsing on all communication messages captured by the bus monitoring and data acquisition module, identifies the application layer service identifier and data identifier in the messages, and locates and reads the corresponding data fields from the response frame according to the service type. For the specific process of protocol parsing and extracting key parameters according to service type, please refer to the above explanation on extracting vehicle identification code, calibration identification code, calibration verification code, fault code, and ready status bit from the full communication messages.

[0083] As can be seen, this module transforms unstructured underlying messages into structured data containing specific parameter values, providing clear input for subsequent timestamp binding and cloud comparison.

[0084] The record generation module 203 is configured to bind the vehicle identification code, calibration identification code, calibration verification code, fault code and ready status bit with the collection timestamp to generate the original record of the inspection process.

[0085] Specifically, this module relies on the real-time clock module within the monitoring device to assign a high-precision timestamp to each set of extracted key OBD parameters. It binds the vehicle identification code, calibration identification code, calibration verification code, fault code, and ready status bit to the acquisition timestamp, forming a raw record of the inspection process containing temporal logic. For details on the specific operation of binding timestamps to generate raw records, please refer to the above explanation regarding binding key parameters to acquisition timestamps to generate raw records of the inspection process.

[0086] It is evident that this module preserves the chronological order in which various data are generated during the inspection process, providing a time benchmark for accurate traceability by the subsequent regulatory platform.

[0087] The encrypted storage module 204 is configured to: encrypt the original record of the inspection process using a preset encryption algorithm, and store the encrypted original record of the inspection process in a local storage medium.

[0088] Specifically, this module corresponds to the encryption and secure storage module within the monitoring device. It employs a hash algorithm or the national standard SM3 algorithm, using the vehicle identification code from the original verification process record as one of the encryption key input parameters. Combined with the collection timestamp, a fixed-length encrypted digest is generated and appended to the original verification process record to form a tamper-proof data block, which is then saved to the local Flash memory. For details regarding the encryption algorithm selection, digest generation, and local storage implementation, please refer to the above explanation of encrypting the original verification process record using a preset encryption algorithm.

[0089] As can be seen, this module enables the storage of data to be detected once it has been modified, thus improving the integrity and reliability of the original data during the verification process.

[0090] The data upload module 205 is configured to upload the encrypted original record of the inspection process to the cloud-based monitoring platform.

[0091] Specifically, this module corresponds to the communication transmission module within the monitoring device. It supports Ethernet, 4G, 5G, or NB-IoT wireless communication methods. Upon completion of the inspection, it automatically triggers an upload, sending the encrypted original record of the inspection process to the cloud-based monitoring platform and storing it using the vehicle identification number as the primary key. For specific configuration details regarding wireless transmission and automatic upload triggering, please refer to the above explanation of uploading the encrypted original record of the inspection process to the cloud-based monitoring platform.

[0092] As can be seen, this module enables centralized archiving of inspection data, providing data support for comparison and analysis on the cloud-based monitoring platform.

[0093] The cloud-based comparison module 206 is configured as follows: the cloud-based monitoring platform receives the OBD inspection results reported by the testing agency, compares the OBD inspection results with the original records of the inspection process, and generates a fraud warning message when the comparison is inconsistent.

[0094] Specifically, this module is deployed on a cloud-based monitoring platform and incorporates GB 3847 and GB 18285 standard logic. It compares the OBD inspection data reported by testing agencies with key parameters in the original records of the same vehicle identification number (VIN) inspection process during the same time period, item by item. When the reported calibration identification number, ready status bit, or fault code is inconsistent with the original record, it is automatically marked as abnormal data and a fraud warning message is generated. For the specific logic of item-by-item comparison of reported data with original records and warning generation, please refer to the above explanation regarding the cloud-based monitoring platform receiving OBD inspection results reported by testing agencies and performing consistency comparison.

[0095] It is evident that this module can accurately identify the differences between reported data and actual communication records, providing a basis for judgment to detect potential calibration data tampering, fault code masking, or readiness status forgery, thereby improving the regulatory system's ability to identify covert fraudulent activities.

[0096] Example 3

[0097] Please see Figure 3 , Figure 3 This is a schematic diagram of a data verification and anti-tampering monitoring device based on vehicle OBD, disclosed in one embodiment of the present invention. The device may include: Memory 301 storing executable program code; Processor 302 coupled to memory 301; The processor 302 calls the executable program code stored in the memory 301 to execute a data verification and anti-tampering monitoring method based on vehicle OBD as described in Embodiment 1.

[0098] Example 4

[0099] This invention discloses a computer storage medium storing computer instructions. When these computer instructions are invoked, they are used to execute some or all of the steps in the data verification and anti-tampering monitoring method based on vehicle OBD disclosed in Embodiment 1 of this invention.

[0100] Example 5

[0101] This invention discloses a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program, and the computer program is operable to cause a computer to perform the steps of a data verification and anti-tampering monitoring method based on vehicle OBD described in Embodiment 1.

[0102] In the description of this specification, the references to terms such as "an embodiment," "example," "specific example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0103] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. If the integrated unit is implemented as a software functional unit 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 all 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 multiple 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 in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A data verification and anti-tampering monitoring method based on vehicle OBD, characterized in that, Includes the following steps: The listening device is connected between the vehicle's OBD interface and the inspection equipment, and the listening device passively listens to all communication messages between the OBD interface and the inspection equipment. Extract the vehicle identification code, calibration identification code, calibration verification code, fault code, and ready status bit from the full communication message; The vehicle identification code, calibration identification code, calibration verification code, fault code, and ready status bit are bound to the collection timestamp to generate the original record of the inspection process; The original records of the inspection process are encrypted using a preset encryption algorithm, and the encrypted original records of the inspection process are stored in a local storage medium. The encrypted original record of the inspection process is uploaded to the cloud-based monitoring platform; The cloud-based monitoring platform receives the OBD inspection results reported by the testing agency, compares the OBD inspection results with the original records of the inspection process, and generates a fraud warning when the comparison is inconsistent.

2. The data verification and anti-tampering monitoring method based on vehicle OBD according to claim 1, characterized in that, The step of connecting the listening device between the vehicle's OBD interface and the inspection equipment, and passively monitoring all communication messages between the OBD interface and the inspection equipment through the listening device, includes: The monitoring device includes a housing and a main control chip, an OBD male connector, and an OBD female connector disposed within the housing; The OBD male connector is plugged into the vehicle's OBD interface, and the OBD female connector is used for the diagnostic connector of the inspection equipment to be plugged in. The main control chip passively collects command frames and response frames transmitted between the OBD interface and the inspection device through the OBD male connector and the OBD female connector without interfering with the original communication link. The full communication messages include controller area network messages and K-line communication messages.

3. The data verification and anti-tampering monitoring method based on vehicle OBD according to claim 1, characterized in that, The extraction of the vehicle identification code, calibration identification code, calibration verification code, fault code, and ready status bit from the full communication message includes: The entire communication message is parsed to identify the service identifier and data identifier in the message; When the service identifier corresponds to the vehicle identification code reading service, extract the vehicle identification code field from the response frame; When the service identifier corresponds to the calibration data reading service, the calibration identification code field and the calibration verification code field in the response frame are extracted; When the service identifier corresponds to the fault code read service, the fault code field and the ready status bit field in the response frame are extracted.

4. The data verification and anti-tampering monitoring method based on vehicle OBD according to claim 1, characterized in that, The encryption process of the original verification record using a preset encryption algorithm includes: The preset encryption algorithm is a hash algorithm or a national cryptographic algorithm; The vehicle identification code in the original record of the inspection process is used as the encryption key input parameter, and an encrypted digest is generated by combining it with the collection timestamp. The encrypted digest is appended to the original record of the verification process to form a tamper-proof data block.

5. The data verification and anti-tampering monitoring method based on vehicle OBD according to claim 1, characterized in that, The cloud-based monitoring platform receives the OBD inspection results reported by the testing agency and compares the OBD inspection results with the original records of the inspection process, including: The cloud-based monitoring platform pre-stores OBD inspection and reporting data from motor vehicle emission testing agencies. The OBD inspection and reporting data includes the reported vehicle identification code, the reported calibration identification code, the reported calibration verification code, the reported fault code, and the reported ready status bit. The cloud-based monitoring platform compares the reported vehicle identification number with the vehicle identification number in the original record of the inspection process; The cloud-based monitoring platform compares the reported identification code with the identification code in the original record of the inspection process; The cloud-based monitoring platform compares the reported verification code with the verification code in the original record of the inspection process; The cloud-based monitoring platform compares the reported fault codes and ready status bits with the fault codes and ready status bits in the original records of the inspection process.

6. The data verification and anti-tampering monitoring method based on vehicle OBD according to claim 5, characterized in that, The generation of fraud warning information when the comparison is inconsistent includes: When the reported calibration identification code is inconsistent with the calibration identification code in the original record of the inspection process, it is determined that there is a risk of calibration data being tampered with, and a calibration tampering warning message is generated. When the reported ready status bit is inconsistent with the ready status bit in the original record of the inspection process, it is determined that there is a risk that the ready status is masked, and an abnormal ready status warning message is generated. When the reported fault code is inconsistent with the fault code in the original record of the inspection process, it is determined that there is a risk that the fault code has been cleared, and an abnormal fault code warning message is generated. The cloud-based monitoring platform records the trigger time of the fraud warning information, the corresponding testing agency identification and vehicle identification code, and generates a traceability audit log.

7. The data verification and anti-tampering monitoring method based on vehicle OBD according to claim 1, characterized in that, Also includes: The monitoring device has a built-in self-check module. The self-check module actively sends standard inspection command frames to the vehicle according to preset inspection standards, receives response frames returned by the vehicle, extracts the self-check vehicle identification code, self-check calibration identification code, self-check calibration verification code, self-check fault code and self-check ready status bit, and generates benchmark inspection data. The cloud-based monitoring platform performs a secondary comparison between the benchmark inspection data and the original records of the inspection process. When there is a discrepancy, it generates an early warning of data falsification for the inspection equipment.

8. The data verification and anti-tampering monitoring method based on vehicle OBD according to claim 1, characterized in that, The monitoring device records the device identification information of the currently connected inspection device; When different inspection devices are used, the listening device records the original inspection process records corresponding to each inspection device. The cloud-based monitoring platform cross-compares the original records of the inspection process corresponding to different inspection devices. When there are differences between the calibration identification code or calibration verification code corresponding to the same vehicle identification code on different inspection devices, it determines that there is OBD simulator or ECU rewriting behavior and generates a hardware fraud warning.

9. A data verification and anti-tampering monitoring system based on vehicle OBD, applied to the data verification and anti-tampering monitoring method based on vehicle OBD as described in any one of claims 1-8, characterized in that, include: The message monitoring module is configured to connect the monitoring device between the vehicle's OBD interface and the inspection equipment, and passively monitor all communication messages between the OBD interface and the inspection equipment through the monitoring device. The parameter extraction module is configured to extract the vehicle identification code, calibration identification code, calibration verification code, fault code, and ready status bit from the full communication message. The record generation module is configured to bind the vehicle identification code, calibration identification code, calibration verification code, fault code and ready status bit with the collection timestamp to generate the original record of the inspection process; The encrypted storage module is configured to encrypt the original records of the inspection process using a preset encryption algorithm and store the encrypted original records of the inspection process in a local storage medium. The data upload module is configured to upload the encrypted original record of the inspection process to the cloud-based monitoring platform; The cloud-based comparison module is configured to receive the OBD inspection results reported by the testing agency on the cloud-based monitoring platform, compare the OBD inspection results with the original records of the inspection process, and generate a fraud warning message when the comparison is inconsistent.

10. A data verification and anti-tampering monitoring device based on vehicle OBD, characterized in that, The device includes: Memory containing executable program code; A processor coupled to the memory; The processor calls the executable program code stored in the memory to execute a data verification and anti-tampering monitoring method based on vehicle OBD as described in any one of claims 1 to 8.

Images