Vehicle data tracking method and system based on two-dimensional code recognition

Abstract

The invention relates to the technical field of vehicle data tracking, in particular to a vehicle data tracking method and system based on two-dimensional code recognition. The method comprises the following steps: generating a two-dimensional code identifier for a vehicle, establishing a vehicle state recording unit corresponding to the identifier, and storing the use state and the last end mileage value of the vehicle; when the two-dimensional code identifier of the vehicle is scanned, the vehicle state recording unit is read, state judgment is executed according to the use state, when the judgment result is idle, the vehicle use starting process is started, and when the judgment result is use, the code scanning operation is terminated; in the vehicle using starting process, the last ending mileage value is called and displayed on a vehicle using interface, the current actual mileage value of the vehicle is collected, comparison is executed, the requirement is evaluated and corrected, and a vehicle state recording unit is updated; according to the invention, through vehicle data tracking, automatic determination of a vehicle use state and dynamic correction of mileage data are realized, and accuracy and tracing reliability of vehicle use data are improved.

Description

Technical Field

[0001] This invention relates to the field of vehicle data tracking technology, and in particular to a vehicle data tracking method and system based on QR code recognition. Background Technology

[0002] Interference often occurs during vehicle activation, return, and mileage verification, leading to poor data consistency, record delays, and frequent errors. In multi-user shared vehicle or company vehicle management scenarios, vehicle usage status is difficult to synchronize in a timely manner, often resulting in duplicate scanning, status conflicts, or inconsistent mileage records, increasing the complexity of vehicle scheduling and statistics. While QR code recognition is used for vehicle identification, it is only for static identification and does not establish a dynamic link with vehicle operating status or historical data, failing to support automatic determination and data verification of vehicle status before and after use. Furthermore, mileage data is mostly manually entered by users, lacking image recognition and automatic correction mechanisms; input errors directly affect mileage data statistics and subsequent management. Therefore, there is an urgent need for a vehicle data tracking method that can dynamically determine vehicle status, compare and correct mileage based on QR code recognition. Summary of the Invention

[0003] Therefore, it is necessary to provide a vehicle data tracking method and system based on QR code recognition to solve at least one of the above-mentioned technical problems.

[0004] To achieve the above objectives, a vehicle data tracking method based on QR code recognition includes the following steps: Step S1: Generate a QR code identifier for the vehicle, establish a vehicle status record unit corresponding to the identifier, and store the vehicle's usage status and last mileage value. Step S2: When scanning the vehicle's QR code identifier, read the vehicle status recording unit and perform a status determination based on the usage status. If the determination result is "idle", proceed to the vehicle start-up process. If the determination result is "used", terminate the scanning operation. Step S3: In the vehicle start-up process, the last completed mileage value is retrieved and displayed on the vehicle interface, the current actual mileage value of the vehicle is collected and compared, the correction needs are evaluated, the correction value is recorded, and the vehicle status recording unit is updated. Step S4: When the vehicle usage ends, scan the vehicle's QR code identifier, collect the vehicle's current actual mileage value, calculate the mileage difference and generate verification data, write the verification data and vehicle number into the vehicle usage record chain, and update the vehicle status to empty.

[0005] The present invention also provides a vehicle data tracking system based on QR code recognition, for executing the vehicle data tracking method based on QR code recognition as described above, the vehicle data tracking system based on QR code recognition includes: The identifier creation module is used to generate a QR code identifier for the vehicle, establish a vehicle status record unit corresponding to the identifier, and store the vehicle's usage status and last mileage value. The vehicle status recognition module is used to read the vehicle status record unit when scanning the vehicle's QR code identifier, and perform status determination based on the usage status. When the determination result is idle, the vehicle start-up process is initiated; when the determination result is used, the scanning operation is terminated. The correction requirement assessment module is used to retrieve the last completed mileage value and display it on the vehicle usage interface during the vehicle start-up process, collect the current actual mileage value of the vehicle and perform comparison, assess the correction requirement, record the correction value, and update the vehicle status recording unit. The mileage difference calculation module is used to scan the vehicle's QR code identifier when the vehicle use ends, collect the vehicle's current actual mileage value, calculate the mileage difference and generate verification data, write the verification data and vehicle number into the vehicle use record chain, and update the vehicle status to empty.

[0006] The beneficial effects of this invention are as follows: Through the above steps, a two-way binding between the QR code identifier and the vehicle status recording unit is achieved, enabling the vehicle's usage status, mileage changes, and recording process to form an automated data closed loop. The QR code identifier serves as the sole entry point, and combined with the status judgment and dynamic correction process, it can automatically identify the usage status, verify mileage consistency, and correct deviations before the vehicle starts, effectively avoiding manual input errors and conflicts caused by concurrent operations by multiple users. At the same time, by generating mileage difference and verification data at the end of vehicle use, the traceability and integrity of the data throughout the entire vehicle usage process are ensured, realizing full-link digital management of vehicle status from "identification—comparison—correction—archiving," and improving the authenticity of vehicle usage data and the security and consistency of system records. Attached Figure Description

[0007] Figure 1 This is a flowchart illustrating the steps of a vehicle data tracking method based on QR code recognition. Figure 2 This is a schematic diagram of the vehicle status display on the QR code recognition interface; Figure 3 This is a schematic diagram of the vehicle data tracking process; The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0008] The technical method of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0009] Furthermore, the accompanying drawings are merely illustrative of the invention and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor methods and / or microcontroller methods.

[0010] It should be understood that although the terms "first," "second," etc., may be used herein to describe various units, these units should not be limited by these terms. These terms are used merely to distinguish one unit from another. For example, without departing from the scope of the exemplary embodiments, a first unit may be referred to as a second unit, and similarly, a second unit may be referred to as a first unit. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0011] To achieve the above objectives, please refer to Figures 1 to 3 The vehicle data tracking method based on QR code recognition includes the following steps: Step S1: Generate a QR code identifier for the vehicle, establish a vehicle status record unit corresponding to the identifier, and store the vehicle's usage status and last mileage value. Step S2: When scanning the vehicle's QR code identifier, read the vehicle status recording unit and perform a status determination based on the usage status. If the determination result is "idle", proceed to the vehicle start-up process. If the determination result is "used", terminate the scanning operation. Step S3: In the vehicle start-up process, the last completed mileage value is retrieved and displayed on the vehicle interface, the current actual mileage value of the vehicle is collected and compared, the correction needs are evaluated, the correction value is recorded, and the vehicle status recording unit is updated. Step S4: When the vehicle usage ends, scan the vehicle's QR code identifier, collect the vehicle's current actual mileage value, calculate the mileage difference and generate verification data, write the verification data and vehicle number into the vehicle usage record chain, and update the vehicle status to empty.

[0012] In one embodiment, a QR code version 10 (33×33 module) is used to encode the vehicle's unique serial number (16 bytes) and hash checksum (first 8 bytes), with the error correction level set to medium. After encoding, it is printed at 600 dpi on reflective stickers and affixed to the inside of the vehicle's B-pillar. The backend establishes a status record unit using the vehicle's unique serial number as the key, containing the following fields: status flag (1 byte, 0 for idle, 1 for in use), last ended mileage (4-byte integer, in 0.1 km units), and update timestamp (8-byte system time). Initially, the last ended mileage is written as 100.0 km, the status flag is set to idle, and the timestamp is the current system time.

[0013] The rear camera operates at 60 frames per second, capturing a 1920×1080 video stream. Upon detecting a QR code, the current frame is frozen, converted to grayscale, and automatically binarized after Gaussian blurring. The three corner points are located, the module's side length is calculated to be approximately 28 pixels, and the vehicle's unique ID is decoded and verified via hash. The ID is used to query the status database, and the status flag is read as "idle." A 32-byte random session token is generated, written to the status record unit, and the status flag is changed to "in use," initiating the vehicle startup interface. If the status flag is "in use," the interface displays "Vehicle in use" and exits the QR code scanning process.

[0014] The user interface displays "Last mileage: 100.0 km". The user takes 5 consecutive frames (0.5-second intervals) of images pointing at the dashboard, with a resolution of 1280×720. Each frame is first converted to grayscale and its contrast is enhanced. The digit region (approximately 6:1 aspect ratio) is detected, and the 7-digit number is segmented. A digit recognition model is used for processing, with a confidence level higher than 90%, yielding mileage values ​​[100.0, 100.1, 100.0, 100.0, 100.0] km. The most frequent value, 100.0 km, is taken and compared with the last mileage. A difference of 0.0 is within the tolerance range. Within a certain range, the starting mileage is directly set and written to the status record. If the recognition result is [102.3, 102.4, 102.3, 102.3, 102.2] kilometers, the mode of 102.3 kilometers is taken. The difference of 2.3 kilometers exceeds the tolerance, so a correction record is generated containing the original value, the actual value, the difference, and 5 frames of image data, and stored in the status unit. The starting mileage is set to 102.3 kilometers.

[0015] After the user clicks to end the ride, they scan the code again to decode the vehicle's unique ID, and the verification passes. The starting mileage is read as 102.3 kilometers. Four frames are captured on the instrument panel, revealing kilometers in the range [108.7, 108.7, 108.8, 108.7]. The mode is taken as 108.7 kilometers. The difference is calculated as 108.7 - 102.3 = 6.4 kilometers. Verification data is generated: the ID, starting mileage, ending mileage, and timestamp are concatenated, and a hash value (first 16 bytes) is calculated to form a record containing the trip ID, mileage information, hash, and time, which is appended to the chained log database. The status unit is updated: the status flag is changed to idle, the last ending mileage is set to 108.7 kilometers, and the session token is cleared.

[0016] In another embodiment, QR code version 15 (53×53 module) is used to encode the license plate number (7 bytes) and check digit (4 bytes), providing a high error correction level. The QR code is thermally transferred onto an aluminum alloy nameplate at 300dpi and fixed to the right side of the dashboard. The status recording unit uses a key-value database, where the key is the first 8 bytes of the license plate number hash value. The record includes: status (string "idle" or "in use"), last mileage (floating-point number, in kilometers), last update time (standard time format), and lock holder (user identifier, empty indicates no lock). Initially, the last mileage is recorded as 152.3 kilometers, the status is idle, and the update time is the current time.

[0017] The tablet's front-facing camera captures images at 720p resolution and 30 frames per second. QR code recognition uses an open-source library to decode and verify the license plate number. The vehicle status table is queried; if the status is "idle," a standard-format session token is generated, the status is updated to "in use," the current user's identifier is recorded, and the user is redirected to the startup page. If the status is "in use" and the lock holder is different from the current user, "Vehicle already in use" is displayed, conflict information is recorded, and scanning is closed.

[0018] The interface displays "Last End: 152.3 km". Three frames are captured (1 second interval), with a resolution of 1920×1080. Template matching is used to locate the digit region, segmenting it into a 6-digit integer plus 1-digit decimal. A convolutional network is used for recognition, outputting [152.3, 152.3, 152.4] km. The average value of 152.33 km is taken, with a difference of 0.03 km from the previous mileage within a tolerance of ±0.2 km, and is set as the starting mileage. If the output is [155.8, 155.9, 155.8] km, with an average of 155.83 km, the difference of 3.53 km exceeds the tolerance. Correction information is recorded, including the three frames and recognition details, and the starting mileage is set to 155.8 km.

[0019] The license plate scanning and decoding process is complete. The starting mileage of 155.8 km is read. Three frames are captured, recognizing distances within the range of [162.5, 162.5, 162.6] km, and the average is taken as 162.53 km. The difference is 162.5 - 155.8 = 6.7 km. A record string containing the license plate, starting and ending mileage, distance, and time is constructed, hashed, and written to the trip log table. A chain is formed by setting the preceding record pointer. The status is updated to "idle," the previous mileage of 162.5 km is recorded, and the lock information is cleared.

[0020] It should be added that, such as Figure 3 The diagram illustrates the vehicle data tracking process. A QR code is generated for each vehicle. After a user scans the code, a request is sent to the status recording unit. The status determination module checks whether the vehicle is currently idle or in use. The process only continues when the vehicle is determined to be idle. After passing the status determination, a vehicle usage verification is performed. If the verification is successful, the vehicle usage initiation process is triggered, which calls and compares the corrected mileage value to ensure billing accuracy. The diagram specifically highlights the mileage correction function, which is used to handle mileage errors caused by GPS signal drift or other reasons, ensuring data reliability. When the user clicks "End of Use," mileage collection and status update are performed. This step ultimately collects the mileage, calculates the cost, and updates the vehicle status back to idle in the status recording unit for the next user.

[0021] Of particular importance is that step S1 includes the following steps: When registering a vehicle, a QR code identifier is generated based on the vehicle's unique identification code, and the generated QR code identifier is registered in correspondence with the vehicle information. Establish a vehicle status recording unit corresponding to the identifier, and pre-set the use of status field, mileage record field and timestamp field; The vehicle's actual mileage value collected for the first time is written into the mileage record field as the initial end mileage value, and an initialization check code is generated. The QR code identifier is associated with the vehicle status recording unit through a verification code, thus completing the initial registration of vehicle data and the establishment of status recording benchmark.

[0022] In one embodiment, the management terminal inputs the vehicle's unique identification code (16-byte hexadecimal), encodes it using QR code version 12 (37×37 module), and appends the first 8 bytes of the SHA-256 hash value, with the error correction level set to medium. After encoding, it is printed at 600dpi on a waterproof adhesive label and affixed to the lower right corner of the vehicle's windshield. The backend creates a status record unit using the unique identification code as the key, containing the following fields: status (1 byte, 0 for idle), mileage record (4-byte integer, unit 0.1 km), and timestamp (8-byte system time). On-site, a handheld terminal is used to capture a single frame of the dashboard at a resolution of 1280×720. After grayscale conversion, the digit area is located, segmented into 6-digit integers, and the digit recognition model is used to output a confidence level of 96%, yielding a mileage value of 235.6 km. This mileage record is written as 0x000927C0 (i.e., 235.6 km). The unique identification code, initial mileage, and timestamp are concatenated and then used to calculate a SHA-256 hash. The first 16 bytes are taken as the initialization check code and stored in the check field of the status record unit. The QR code data, check code, and vehicle unique identification code are written into the registration table to form a one-to-one correspondence, completing the initial registration.

[0023] In another embodiment, the license plate number (7 bytes) is input during data entry. QR code version 14 (49×49 module) is used to encode the license plate number, and an MD5 checksum (4 bytes) is added, resulting in a high error correction level. The QR code is laser-etched onto a stainless steel nameplate at 400dpi and fixed to the inside of the vehicle door. The status recording unit uses the first 8 bytes of the license plate hash value as the key, with fields including: status (string "idle"), last completed mileage (floating-point number, unit: kilometers), and update time (standard time format). A tablet camera captures three frames of the instrument panel (0.8-second intervals) at a resolution of 1920×1080. Each frame is contrast-stretched and template-matched to locate the mileage area. A convolutional network is used for recognition, outputting [318.9, 318.9, 319.0] kilometers. The average value of 318.9 kilometers is taken and written to the mileage recording field. The license plate number, average mileage, and current time are concatenated to calculate the MD5 hash, which is then stored in the recording unit as the initialization checksum. Write the QR code content, verification code, and license plate number into the vehicle's basic information table, establish a binding relationship, and complete the establishment of the status baseline.

[0024] Preferably, step S2 includes: The vehicle code and embedded tamper-proof hash check bits are extracted from the QR code identifier captured by the scanning terminal camera. Use the unique code to query the status record unit to obtain the vehicle usage status flag and update timestamp; Calculate the difference between the current time and the timestamp of the most recent state update. If the difference exceeds the preset timeout threshold, forcibly release the state lock, set the usage state flag to idle, and record the timeout release event. If the status flag is idle and the status lock is not held, a temporary session token is generated and written to the status record unit, and the vehicle start-up process begins. If the status flag is "in use", the status lock holder is compared with the current user's identity. If they match, the original session continues. If they do not match, the operation is terminated and a occupancy notification is pushed. The conflict event is recorded to the status recording unit.

[0025] In one embodiment, the phone's rear camera is activated at 60 frames per second, capturing a 1920×1080 video stream. Upon detecting a QR code, the current frame is frozen, converted to grayscale, and automatically binarized after Gaussian blurring. The three corner points are located, the module's side length is calculated to be approximately 28 pixels, and the vehicle's unique ID and embedded hash verification bits (first 8 bytes) are decoded. The data hash is recalculated and compared bit by bit; verification passes. The unique ID is used to query the status database; the status flag is read as idle, and the timestamp is updated to the current time minus 2 hours and 37 minutes. The time difference is calculated to be 157 minutes and compared with a preset timeout threshold of 120 minutes. If the timeout is exceeded, the state lock is forcibly released, the status flag is set to idle, and a timeout release event containing the event number, release time, and vehicle ID is generated and written to the timeout log table. If the status flag is idle and there is no lock holder record, a 32-byte random session token is generated, written to the status record unit, the status flag is changed to "in use," and the vehicle startup interface is entered. If the status flag is "in use", compare the lock holder's identifier with the current user's identifier. If the fields match, continue the original session; if any part does not match, terminate the operation, push a "vehicle has been occupied by someone else" prompt on the interface, generate a conflict event record including conflict number, user identifier, and scan time, and store it in the status record unit.

[0026] In another embodiment, a tablet's front-facing camera is used to capture images at 720p resolution and 30 frames per second. QR code recognition utilizes an open-source library, decoding the license plate number and embedded checksum (4 bytes), recalculating the hash, and verifying it. The vehicle status table is queried, obtaining a status of "in use" with the last update time 45 minutes prior to the current time. A time difference of 45 minutes is calculated; if this is less than the dynamic timeout threshold (base value 60 minutes plus the average usage time of the last ten times, 20 minutes, totaling 80 minutes), release is not triggered. If the status is idle and the lock holder field is empty, a standard format session token is generated, the status is updated to "in use," the current user identifier is recorded, and the user is redirected to the startup page. If the status is "in use," the lock holder and the current user identifier are compared; if the fields match completely, the original session interface is restored; otherwise, scanning is terminated, a "Vehicle in use" notification is pushed, and a conflict event is recorded, including the event identifier, both user identifiers, and the time of the conflict, written to the conflict log field of the status recording unit.

[0027] It should be added that, for example, Figure 2The diagram shown is a schematic of the vehicle status display interface displayed after the rear camera detects the QR code.

[0028] Preferably, the process of capturing a QR code identifier using a scanning terminal camera and extracting the vehicle code and embedded tamper-proof hash check bits from the identifier includes: The QR code identifier is captured using the camera of the scanning terminal, the QR code image is converted into a grayscale image and the contrast in low light is improved; Correct lens distortion and adjust the image to the correct position, then locate the three corner points of the QR code. Calculate the pixel distance between corner points. If the distance deviation between any two corner points exceeds a preset pixel threshold, rotate the image until the deviation is less than the threshold. Once the location is established, decode the QR code data and extract the vehicle's unique code and embedded hash check bits; Calculate the hash value of the extracted data and compare it with the hash check bit. If they do not match, it is determined that the QR code has been tampered with, the operation is terminated and the anti-tampering failure event is recorded. If they match, output the vehicle's unique code and the embedded tamper-proof hash check bit.

[0029] In one embodiment, the phone's rear camera is activated at 60 frames per second, capturing a 1920×1080 video stream. Upon detecting a QR code, the current frame is frozen, converted to an 8-bit grayscale image, and histogram equalization is performed to improve contrast in low-light areas. The camera's intrinsic parameter matrix is ​​loaded, lens distortion correction is performed, and the image is projected onto the orthographic plane. The three corner locators of the QR code are located, and the center coordinates of each corner are calculated, resulting in two sets of side length pixel distances of 312 pixels and 315 pixels respectively. A deviation of 3 pixels does not exceed a preset threshold of 5 pixels, so no rotation is required. If the deviation reaches 8 pixels, the location is repositioned by rotating 2 degrees clockwise each time until the deviation is less than the threshold. After positioning, an open-source decoding library is used to parse the QR code data, extracting the vehicle's unique code (16 bytes) and the embedded hash check bit (first 8 bytes). The extracted vehicle unique code is recalculated using the SHA-256 hash. The first 8 bytes are compared bit by bit with the embedded check bit. If all bytes match, the code and check bit are output. If any bit is different, it is determined to be tampered with, the scanning process is terminated, and an anti-tampering failure event record containing the event number, image frame, and deviation bitmap is generated. This record is written to the local log and uploaded to the server.

[0030] In another embodiment, a tablet's front-facing camera is used to capture images at 720p resolution and 30 frames per second. After capturing the QR code, a single frame is extracted, converted to grayscale, and adaptive contrast stretching is applied to enhance dark details. Pre-stored lens distortion parameters are used for distortion correction, and the image is adjusted to a frontal view. Three corner locators are detected, with side lengths measured at 210 pixels, 208 pixels, and 211 pixels respectively. The maximum deviation of 3 pixels is less than the threshold of 6 pixels, so the original image is preserved. If the deviation reaches 9 pixels, iterative adjustment is performed by rotating counterclockwise by 1.5 degrees each time until the threshold is met. After decoding, the license plate number (7 bytes) and the embedded MD5 checksum (4 bytes) are extracted. The MD5 hash of the license plate number is recalculated and completely compared with the embedded checksum. If they match, the license plate number and checksum are output; if they do not match, it is marked as tampering, the operation is immediately terminated, and the failure event, including the event identifier, the original image, and the checksum difference value, is recorded and stored in the anti-tampering log field of the status recording unit.

[0031] Preferably, the hash value of the extracted data is calculated and compared with the check bit. If they do not match, the QR code is determined to have been tampered with, the operation is terminated, and the anti-tampering failure event is recorded, including: Calculate the hash value of the extracted data and compare it bit by bit with the embedded hash check bits; If any bit in the comparison is inconsistent, mark the offset of the check bit and generate a tampering event; Match the tampering event with the preset tampering pattern library; if a match is found, the tampering type is identified. If the matching fails, it is determined that the QR code has been tampered with, the scanning operation is terminated, and the anti-tampering failure event is recorded.

[0032] In one embodiment, after decoding, the vehicle's unique code (16 bytes) and the embedded hash check bit (first 8 bytes) are extracted. The SHA-256 hash of the unique code is recalculated, and the first 8 bytes are used to obtain the calculated value 0xA3F7C91B2D4E5601. This value is compared bit by bit with the embedded check bit 0xA3F7C91B2D4E5601. If all 64 bits are identical, the comparison is successful. If the comparison finds that the 23rd bit is different (calculated value 0, embedded value 1), the offset is marked as 23, and a tampering event record is generated, including the event number, offset bitmap, original code, calculated value, and embedded value. The event features (offset 23, single bit flip) are compared with a preset tampering pattern library. If a "single-point tampering" type is matched, the identification is successful. If the offsets at positions 45, 47, and 49 are flipped simultaneously and not matched in the pattern library, it is determined to be an unknown tampering, the scanning is immediately terminated, and an anti-tampering failure event containing an event identifier, image frame, and offset details is generated and written to the anti-tampering log field of the status record unit.

[0033] In another embodiment, the license plate number (7 bytes) and the embedded MD5 checksum (4 bytes) are extracted. The MD5 hash of the license plate number is recalculated to obtain the calculated value 0x89ABCDEF, which is compared bit by bit with the embedded checksum 0x89ABCDEF. If all 32 bits are identical, the checksum passes. If the 12th bit is inconsistent (calculated value 1, embedded value 0), the offset is marked as 12, and a tampering event is generated, including the event number, offset position, license plate number, and bidirectional hash value. The event characteristics (offset 12, single-byte modification) are matched with the tampering pattern library. If a character replacement type is matched, the identification is complete. If offsets of 4, 8, 12, and 16 are found at four equidistant positions, and there is no corresponding entry in the pattern library, it is determined to be an unknown tampering, the scanning operation is terminated, and the anti-tampering failure event, including the event identifier, the original image, and the offset list, is recorded and stored in the anti-tampering log chain of the vehicle status recording unit.

[0034] Preferably, the difference between the current time and the timestamp of the most recent state update is calculated. If the difference exceeds a preset timeout threshold, the state lock is forcibly released, the usage state flag is set to idle, and the timeout release event is recorded, including: Calculate the difference between the current time and the timestamp of the most recent status update; The difference is compared with the dynamic timeout threshold, which is weighted and adjusted based on the preset base value of the vehicle license plate number and the average duration of the last ten vehicle uses. If the difference exceeds the dynamic timeout threshold, query the vehicle applicant ID associated with the status lock; If the applicant for vehicle use is identified as having no request within the threshold, the state lock will be forcibly released. Set the usage status flag to idle and generate a timeout release event code; Write the event code, release time, and corresponding license plate number into the timeout release log chain.

[0035] In one embodiment, the most recent update timestamp is read from the status recording unit and subtracted from the current system time by 157 minutes, calculating a time difference of 157 minutes. The dynamic timeout threshold is calculated by weighting the vehicle's unique ID with a preset base value of 120 minutes and the average usage time of the last ten uses (weight 0.4), resulting in a threshold of 120 + 35 × 0.4 = 134 minutes. The difference of 157 minutes exceeds 134 minutes, triggering the timeout logic. The user ID associated with the status lock is queried, and it is found that this ID has no active request records in the past 134 minutes, confirming that it can be released. The status lock is forcibly cleared, the usage status flag is set to 0 (idle), and a timeout release event code 0xE001 (16-bit integer) is generated. The event code 0xE001, the release time timestamp, and the vehicle's unique ID are concatenated and written to the timeout release log database. The log adopts a chain structure, with the current record pointing to the previous event hash, forming an immutable sequence.

[0036] In another embodiment, the last update time is read as 95 minutes before the current time, and the difference of 95 minutes is calculated. The dynamic timeout threshold is based on a preset base value of 90 minutes for the license plate number, combined with a weighted average of 48 minutes for the last ten usages (weight 0.5), resulting in a threshold of 90 + 48 × 0.5 = 114 minutes. If the difference of 95 minutes does not exceed 114 minutes, release is not triggered. If the difference reaches 125 minutes and exceeds the threshold, the user ID bound to the lock is queried. If there is no renewal or heartbeat request within the 114-minute window, forced release is executed. The status field is changed to "Idle", and a timeout release event code TO-REL-001 (string format) is generated. The event code, release time, and license plate number are packaged into a record, appended to the timeout release log table, and a preceding record pointer is set to maintain the integrity of the log chain.

[0037] Preferably, if the status flag is "in use," the status lock holder is compared with the current user's identity. If they match, the original session continues; otherwise, the operation is terminated and a occupancy notification is pushed. Recording the conflict event to the status recording unit includes: If the status flag is "in use", compare the status lock holder identifier with the user identity identifier of the current scanning terminal; The unique identifier fields of the two are compared bit by bit. If they match, the original session process can continue. If any digit is inconsistent, a conflict check code and a vehicle use conflict record are generated, the scanning operation is terminated, a vehicle occupancy notification is pushed, and the conflict check code and user identity are written into the vehicle status record unit.

[0038] In one embodiment, the query status record unit obtains a usage status flag of 1 (in use) and reads the status lock holder identifier (32-byte user unique identifier). The current scanning terminal obtains the user identity identifier (also 32 bytes) through the login interface. The unique identifier fields of the two are compared bit by bit. If all 256 bits are consistent, the holder is confirmed to match, allowing the continuation of the original session process, restoring the previous vehicle usage interface and refreshing the session token. If the comparison finds that the 87th bit is inconsistent (holder is 0, current is 1), a conflict check code is generated: calculated based on the vehicle's unique number and the number of historical conflicts (currently 3 times), check code = 0xCF03 (16 bits). At the same time, a vehicle usage conflict record is generated, including the conflict number, the user identifiers of both parties, and the scanning time. The scanning operation is immediately terminated, the interface pushes a "vehicle occupied" prompt, and the conflict check code 0xCF03, the current user identity identifier, and the conflict record are written into the conflict event field of the status record unit to form an append-only log.

[0039] In another embodiment, the status log displays the status as "in use," and the lock holder's identifier (user openid string, 40 characters long) is extracted. The current terminal obtains the user identifier (in the same format) through authentication. The unique identifier fields of the two are compared bit by bit. If the characters are completely identical, the original session is allowed to continue, and the user is redirected to the previously paused mileage confirmation interface. If the 23rd character is different (holder is "A," current user is "B"), a conflict check code is generated: using the license plate number as the seed and weighted by the cumulative number of conflicts (currently 5), the check code is "CONFLICT-005." The generated conflict record includes the record identifier, the holder and current user identifiers, and the conflict time. The scanning is terminated, a "Vehicle in use" prompt is pushed, and the conflict check code, current user identifier, and complete conflict record are written to the conflict log field of the status log unit to maintain event traceability.

[0040] Preferably, step S3 includes: The vehicle status recording unit retrieves the last mileage value, the vehicle instrument panel captures the current mileage image, and multi-frame digital recognition is performed to extract the actual mileage value. Calculate the difference between the actual mileage and the last ending mileage. If the difference is within the preset tolerance range, it will be directly set as the starting mileage for vehicle use. Generate a session token to bind the current user's identity and starting mileage, and update the vehicle status record unit to the "in use" status.

[0041] In one embodiment, the last completed mileage value of 100.0 kilometers is retrieved from the status recording unit and displayed on the interface. The user takes five consecutive photos of the dashboard (0.5-second intervals) at a resolution of 1280×720. Each frame is grayscaled and contrast-enhanced to locate the digit region (approximately 6:1 aspect ratio), segmented into 7 digits, and the output of the digit recognition model is used, with a confidence level of over 90%, resulting in a mileage value of [100.0, 100.1, 100.0, 100.0, 100.0] kilometers. The mode of 100.0 kilometers is taken. The difference between the actual mileage and the last completed mileage is calculated to be 0.0 kilometers, within a preset tolerance. Within the kilometer range, the starting mileage for this vehicle use is directly set to 100.0 kilometers. A 32-byte random session token is generated, binding the current user identity (32 bytes), the starting mileage, and the token, and written into the status record unit. At the same time, the usage status flag is set to 1 (in use), and the timestamp is updated to the current time.

[0042] In another embodiment, the last completed mileage of 152.3 kilometers is read from the status record and displayed in real time on the interface. Three frames of instrument images are captured (1 second interval), with a resolution of 1920×1080. Each frame uses template matching to locate the mileage region, segments it into a 6-digit integer plus 1-digit decimal, and uses a convolutional network for recognition, outputting [152.3, 152.3, 152.4] kilometers. The average value is taken as 152.33 kilometers. The difference is calculated to be 0.03 kilometers, which is less than the tolerance. The starting mileage is set directly to 152.3 kilometers. A standard format session token (40-character string) is generated, bound to the current user identifier (openid), the starting mileage of 152.3 kilometers, and the token. This token is written to the status record unit, and the status field is updated to "in use". The update time is recorded as the current system time.

[0043] Preferably, the difference between the actual mileage and the previous ending mileage is calculated. If the difference is within a preset tolerance range, it is directly set as the starting mileage for vehicle use, including: After extracting the actual mileage value, retrieve the vehicle's last completed mileage value; Calculate the difference between the two and compare it with the preset tolerance range. If the difference is within the tolerance range, register the actual mileage value as the starting mileage and write it into the status record unit. If the difference exceeds the threshold, the average of the recognition results from multiple frames is used to generate a correction value, and the correction is then performed. After the correction is completed, update the starting mileage index of the vehicle status and generate a correction confirmation event.

[0044] In one embodiment, after multi-frame recognition, the mode is taken to obtain the actual mileage value of 102.3 kilometers, and the last ending mileage value of 100.0 kilometers is retrieved from the status recording unit. The difference between the two is calculated to be 2.3 kilometers, which is within a preset tolerance range. The kilometer comparison is out of range. A weighted average of the five recognition results [102.3, 102.4, 102.3, 102.3, 102.2] kilometers is calculated (the more recent the time, the higher the weight), generating a corrected value of 102.3 kilometers. The corrected value of 102.3 kilometers is then executed. This corrected value is recorded as the starting mileage for this trip and written to the starting mileage field of the status record unit. Simultaneously, the starting mileage index is updated to the current session pointer, and a correction confirmation event is generated, including event number 0xC001, original value 100.0, corrected value 102.3, difference 2.3, and image evidence chain, and appended to the event log of the status record unit.

[0045] In another embodiment, the average of multiple frames is used to obtain the actual mileage value of 155.83 kilometers, and the last ending mileage of 152.3 kilometers is retrieved. The calculated difference is 3.53 kilometers, which exceeds the preset tolerance. Kilometers. A simple average of the three recognition results [155.8, 155.9, 155.8] kilometers is taken to generate a corrected value of 155.83 kilometers, and the correction is performed. 155.8 kilometers (rounded to one decimal place) is registered as the starting mileage and written to the status record unit. The corresponding starting mileage index is updated to point to the current session record, and a correction confirmation event is generated, including the event identifier "CORR-001", the original value 152.3, the corrected value 155.8, the difference 3.5, and the frame image compressed package, and written to the correction event field of the status record unit.

[0046] Preferably, if the difference exceeds the threshold, the average of the recognition results from multiple frames is taken to generate a correction value, and the correction includes: If the difference exceeds the threshold, acquire the sequence of continuously collected instrument image frames and arrange them in order of timestamp. Character region localization and digit recognition are performed on the instrument image frame sequence to obtain the mileage recognition results for each frame; Calculate the difference between the recognition results of each frame and compare it with the inter-frame stability threshold; If the difference is less than the preset stability threshold, the weighted average of all frame recognition results is calculated to generate a corrected mileage value. If the deviation of any frame recognition result from the average value exceeds a preset limit, the frame is discarded and the calculation is repeated. The corrected mileage value is associated with the corresponding frame index and recognition time, written to the vehicle status record unit, and the starting mileage record of the current session is updated.

[0047] In one embodiment, after a difference of 2.3 kilometers exceeds the tolerance, a sequence of five consecutively acquired instrument images is obtained, arranged in ascending order by shooting timestamp as frames 1 to 5. Character region localization (6:1 aspect ratio) is performed frame by frame, the 7-digit number is segmented, and a digit recognition model is used to output [102.3, 102.4, 102.3, 102.3, 102.2] kilometers. The difference between adjacent frames is calculated sequentially. , , The maximum difference is 0.1 km, which is less than the preset stability threshold of 0.3 km. A weighted average is calculated on all 5 frames (weights increasing by time: 0.1, 0.15, 0.2, 0.25, 0.3), generating a corrected mileage value of 102.28 km. Each frame's deviation from the average is less than the preset limit of 0.4 km, so no frames need to be discarded. The corrected value of 102.3 km (rounded) is associated with the frame index [1,2,3,4,5] and the recognition time of each frame, and written to the corrected mileage field of the status record unit. Simultaneously, the starting mileage record for the current session is updated to 102.3 km.

[0048] In another embodiment, after the difference exceeds the threshold of 3.53 kilometers, a sequence of three instrument image frames is acquired, sorted by timestamp as frames 1 to 3. The digital region is located frame by frame, and a convolutional network is used to identify and output [155.8, 155.9, 160.2] kilometers. The difference between adjacent frames is calculated. , The maximum difference is 4.3 km, which is greater than the stability threshold of 0.5 km. First, calculate the preliminary average (155.8 + 155.9 + 160.2) / 3 = 157.3 km. Check that the deviation frame 3 deviates from the average by 2.9 km, which exceeds the preset limit of 1.0 km, so frame 3 is removed. Then, recalculate the average of the remaining frames 1 and 2 to 155.85 km, generating a corrected mileage value of 155.9 km (retaining one decimal place). Associate the corrected value of 155.9 km with the retained frame index [1,2] and the corresponding identification time, write it into the correction field of the status record unit, and update the current session start mileage record to 155.9 km.

[0049] Of particular importance, step S4 includes: When the vehicle is no longer in use, the data recycling process is triggered by scanning the vehicle's QR code identifier, and the starting mileage value in the vehicle status recording unit is read. Collect the vehicle's current actual mileage and perform difference calculation to obtain the mileage difference; Based on the mileage difference and vehicle number, a verification data block is generated and written into the vehicle usage record chain to form a closed record; After the write operation is complete, the vehicle status field is reset to idle state, the end timestamp is recorded, and the status index is updated for the next call.

[0050] In one embodiment, when the user finishes using the vehicle, they scan the QR code again. The phone's rear camera captures a 1920×1080 video stream at 60 frames per second. After freezing the frames, the QR code is grayscaled and located. The unique vehicle number is decoded, and after successful verification, a data recycling procedure is triggered. The initial mileage value of 102.3 kilometers is read from the status recording unit. Four frames of the instrument panel are continuously captured (0.6 seconds apart). Each frame is enhanced for contrast and the digital region is located before recognition, outputting [108.7, 108.7, 108.8, 108.7] kilometers. The mode, 108.7 kilometers, is taken. The difference in mileage is calculated. The process involves concatenating the vehicle's unique ID, starting mileage, ending mileage, and current timestamp. A SHA-256 hash is then calculated, and the first 16 bytes are used as a checksum block. This generates a record containing the trip number, mileage information, difference, checksum block, and time. This record is appended to the vehicle usage record chain database, with the current record pointing to the previous trip hash. After writing, the status flag is set to 0 (idle), the end timestamp is recorded, the status index is updated to the latest record pointer, and the session token is cleared.

[0051] In another embodiment, after scanning, the tablet's front-facing camera captures the license plate number at 720p and 30 frames per second, decodes and verifies the license plate number, and initiates the recycling process. The starting mileage of 155.9 km is read from the status record. Three frames of instrument panel images are captured (1 second apart). After template matching and positioning in each frame, a convolutional network identifies the data, outputting [162.5, 162.5, 162.6] km, averaging 162.53 km. The difference 162.5 - 155.9 = 6.6 km is calculated. A record string containing the license plate number, starting and ending mileage, travel distance, and time is constructed. An MD5 hash is calculated as a verification data block, written to the vehicle usage record chain table, and the preceding record pointer is set to form a closure. After completion, the status field is reset to "idle," an end timestamp is written, the status index is updated to point to the currently closed record, and the lock holder information is cleared.

[0052] The present invention also provides a vehicle data tracking system based on QR code recognition, for executing the vehicle data tracking method based on QR code recognition as described above, the vehicle data tracking system based on QR code recognition includes: The identifier creation module is used to generate a QR code identifier for the vehicle, establish a vehicle status record unit corresponding to the identifier, and store the vehicle's usage status and last mileage value. The vehicle status recognition module is used to read the vehicle status record unit when scanning the vehicle's QR code identifier, and perform status determination based on the usage status. When the determination result is idle, the vehicle start-up process is initiated; when the determination result is used, the scanning operation is terminated. The correction requirement assessment module is used to retrieve the last completed mileage value and display it on the vehicle usage interface during the vehicle start-up process, collect the current actual mileage value of the vehicle and perform comparison, assess the correction requirement, record the correction value, and update the vehicle status recording unit. The mileage difference calculation module is used to scan the vehicle's QR code identifier when the vehicle use ends, collect the vehicle's current actual mileage value, calculate the mileage difference and generate verification data, write the verification data and vehicle number into the vehicle use record chain, and update the vehicle status to empty.

[0053] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features of the invention herein.

Claims

1. A vehicle data tracking method based on QR code recognition, characterized in that, Includes the following steps: Step S1: Generate a QR code identifier for the vehicle, establish a vehicle status record unit corresponding to the identifier, and store the vehicle's usage status and last mileage value. Step S2: When scanning the vehicle's QR code identifier, read the vehicle status recording unit and perform a status determination based on the usage status. If the determination result is "idle", proceed to the vehicle start-up process. If the determination result is "used", terminate the scanning operation. Step S3: In the vehicle start-up process, the last completed mileage value is retrieved and displayed on the vehicle interface, the current actual mileage value of the vehicle is collected and compared, the correction needs are evaluated, the correction value is recorded, and the vehicle status recording unit is updated. Step S4: When the vehicle usage ends, scan the vehicle's QR code identifier, collect the vehicle's current actual mileage value, calculate the mileage difference and generate verification data, write the verification data and vehicle number into the vehicle usage record chain, and update the vehicle status to empty.

2. The vehicle data tracking method based on QR code recognition according to claim 1, characterized in that, Step S2 includes: The vehicle code and embedded tamper-proof hash check bits are extracted from the QR code identifier captured by the scanning terminal camera. Use the unique code to query the status record unit to obtain the vehicle usage status flag and update timestamp; Calculate the difference between the current time and the timestamp of the most recent state update. If the difference exceeds the preset timeout threshold, forcibly release the state lock, set the usage state flag to idle, and record the timeout release event. If the status flag is idle and the status lock is not held, a temporary session token is generated and written to the status record unit, and the vehicle start-up process begins. If the status flag is "in use", the status lock holder is compared with the current user's identity. If they match, the original session continues. If they do not match, the operation is terminated and a occupancy notification is pushed. The conflict event is recorded to the status recording unit.

3. The vehicle data tracking method based on QR code recognition according to claim 2, characterized in that, The QR code identifier is captured by scanning the terminal camera, and the vehicle code and embedded anti-tamper hash check bits in the identifier are extracted: The QR code identifier is captured using the camera of the scanning terminal, the QR code image is converted into a grayscale image and the contrast in low light is improved; Correct lens distortion and adjust the image to the correct position, then locate the three corner points of the QR code. Calculate the pixel distance between corner points. If the distance deviation between any two corner points exceeds a preset pixel threshold, rotate the image until the deviation is less than the threshold. Once the location is established, decode the QR code data and extract the vehicle's unique code and embedded hash check bits; Calculate the hash value of the extracted data and compare it with the hash check bit. If they do not match, it is determined that the QR code has been tampered with, the operation is terminated and the anti-tampering failure event is recorded. If they match, output the vehicle's unique code and the embedded tamper-proof hash check bit.

4. The vehicle data tracking method based on QR code recognition according to claim 3, characterized in that, Calculate the hash value of the extracted data and compare it with the checksum. If they do not match, the QR code is determined to have been tampered with. The operation is terminated, and the anti-tampering failure event is recorded, including: Calculate the hash value of the extracted data and compare it bit by bit with the embedded hash check bits; If any bit in the comparison is inconsistent, mark the offset of the check bit and generate a tampering event; Match the tampering event with the preset tampering pattern library; if a match is found, the tampering type is identified. If the matching fails, it is determined that the QR code has been tampered with, the scanning operation is terminated, and the anti-tampering failure event is recorded.

5. The vehicle data tracking method based on QR code recognition according to claim 2, characterized in that, Calculate the difference between the current time and the timestamp of the most recent state update. If the difference exceeds a preset timeout threshold, forcibly release the state lock, set the usage state flag to idle, and record the timeout release event, including: Calculate the difference between the current time and the timestamp of the most recent status update; The difference is compared with the dynamic timeout threshold, which is weighted and adjusted based on the preset base value of the vehicle license plate number and the average duration of the last ten vehicle uses. If the difference exceeds the dynamic timeout threshold, query the vehicle applicant ID associated with the status lock; If the applicant for vehicle use is identified as having no request within the threshold, the state lock will be forcibly released. Set the usage status flag to idle and generate a timeout release event code; Write the event code, release time, and corresponding license plate number into the timeout release log chain.

6. The vehicle data tracking method based on QR code recognition according to claim 2, characterized in that, If the status flag is "in use," the status lock holder's identity is compared with the current user's identity. If they match, the original session continues; otherwise, the operation is terminated, a lock occupancy notification is pushed, and conflict events are recorded to the status recording unit, including: If the status flag is "in use", compare the status lock holder identifier with the user identity identifier of the current scanning terminal; The unique identifier fields of the two are compared bit by bit. If they match, the original session process can continue. If any digit is inconsistent, a conflict check code and a vehicle use conflict record are generated, the scanning operation is terminated, a vehicle occupancy notification is pushed, and the conflict check code and user identity are written into the vehicle status record unit.

7. The vehicle data tracking method based on QR code recognition according to claim 1, characterized in that, Step S3 includes: The vehicle status recording unit retrieves the last mileage value, the vehicle instrument panel captures the current mileage image, and multi-frame digital recognition is performed to extract the actual mileage value. Calculate the difference between the actual mileage and the last ending mileage. If the difference is within the preset tolerance range, it will be directly set as the starting mileage for vehicle use. Generate a session token to bind the current user's identity and starting mileage, and update the vehicle status record unit to the "in use" status.

8. The vehicle data tracking method based on QR code recognition according to claim 6, characterized in that, Calculate the difference between the actual mileage and the previous ending mileage. If the difference is within the preset tolerance range, it is directly set as the starting mileage for vehicle use, including: After extracting the actual mileage value, retrieve the vehicle's last completed mileage value; Calculate the difference between the two and compare it with the preset tolerance range. If the difference is within the tolerance range, register the actual mileage value as the starting mileage and write it into the status record unit. If the difference exceeds the threshold, the average of the recognition results from multiple frames is used to generate a correction value, and the correction is then performed. After the correction is completed, update the starting mileage index of the vehicle status and generate a correction confirmation event.

9. The vehicle data tracking method based on QR code recognition according to claim 8, characterized in that, If the difference exceeds the threshold, the average of the recognition results from multiple frames is used to generate a correction value, and the correction includes: If the difference exceeds the threshold, acquire the sequence of continuously collected instrument image frames and arrange them in order of timestamp. Character region localization and digit recognition are performed on the instrument image frame sequence to obtain the mileage recognition results for each frame; Calculate the difference between the recognition results of each frame and compare it with the inter-frame stability threshold; If the difference is less than the preset stability threshold, the weighted average of all frame recognition results is calculated to generate a corrected mileage value. If the deviation of any frame recognition result from the average value exceeds a preset limit, the frame is discarded and the calculation is repeated. The corrected mileage value is associated with the corresponding frame index and recognition time, written to the vehicle status record unit, and the starting mileage record of the current session is updated.

10. A vehicle data tracking system based on QR code recognition, characterized in that, For performing the vehicle data tracking method based on QR code recognition as described in claim 1, the vehicle data tracking system based on QR code recognition includes: The identifier creation module is used to generate a QR code identifier for the vehicle, establish a vehicle status record unit corresponding to the identifier, and store the vehicle's usage status and last mileage value. The vehicle status recognition module is used to read the vehicle status record unit when scanning the vehicle's QR code identifier, and perform status determination based on the usage status. When the determination result is idle, the vehicle start-up process is initiated; when the determination result is used, the scanning operation is terminated. The correction requirement assessment module is used to retrieve the last completed mileage value and display it on the vehicle usage interface during the vehicle start-up process, collect the current actual mileage value of the vehicle and perform comparison, assess the correction requirement, record the correction value, and update the vehicle status recording unit. The mileage difference calculation module is used to scan the vehicle's QR code identifier when the vehicle use ends, collect the vehicle's current actual mileage value, calculate the mileage difference and generate verification data, write the verification data and vehicle number into the vehicle use record chain, and update the vehicle status to empty.

Images