A method and system for toll collection of free-flowing traffic based on state snapshots

Abstract

This invention relates to the field of intelligent transportation technology, and more particularly to a method and system for toll collection based on state snapshots of free-flow traffic. The method includes the following steps: when a vehicle enters the first tolling gantry, the roadside unit communicates with the onboard digital tag (IDT), requests a tolling rule set from the central system, generates a state snapshot summary, and writes it to the volatile trip storage area of ​​the IDT; when the vehicle passes subsequent tolling gantryes, the roadside unit reads the state snapshot summary and compares the version number of the tolling rule set with the version number of the locally cached tolling rule set. This invention avoids tolling rule drift caused by data synchronization delays at edge nodes by physically carrying the tolling rule benchmark with the vehicle in the form of a state snapshot summary, thus achieving unified tolling basis throughout the entire trip and closed-loop correction of tolling differences across nodes.

Description

Technical Field

[0001] This invention relates to the field of intelligent transportation technology, and in particular to a traffic free-flow tolling method and system based on state snapshots. Background Technology

[0002] In the segmented tolling free-flow tolling scenario of urban expressways, when vehicles pass through roadside gantries, contactless transactions are completed between the roadside unit and the onboard electronic tag, enabling automatic deduction of tolls without stopping. Existing technologies typically employ communication between the onboard unit (OBU) and the roadside unit (RSU), combined with a back-end account system to complete the deduction.

[0003] However, as free-flow tolling expands from a single-point closed system to segmented tolling across open road networks, vehicles continuously pass through multiple tolling nodes within a short period, exposing systemic problems in tolling accuracy and transaction security in existing technologies. Specifically, each tolling gantry independently interacts with the backend system to obtain tolling parameters. Since these backend parameters may change dynamically, and there is a time delay in data synchronization between edge nodes and the backend, when vehicles continuously pass through adjacent gantry at high speeds, different gantry may complete transactions based on parameters at different times, leading to discrepancies in tolling results for the same trip. Furthermore, these discrepancies are difficult to fully resolve through post-trip reconciliation. Moreover, the existing technology relies primarily on pre-set binding information on the vehicle's onboard electronic tag to the vehicle's identity. In an open environment, the tags are at risk of being removed or replaced. The lack of an effective verification mechanism for the authenticity of tag holders during high-speed contactless transactions poses security risks to the tolling system.

[0004] In addition, the existing vehicle perception system of the billing gantry is fragmented. The high-definition cameras, millimeter-wave radar, lidar and other perception devices of each gantry operate independently and the data is isolated. They lack the ability to form an IoT collaborative network and have a high failure rate in complex scenarios such as rain, fog, night, backlight, and vehicles passing each other and obstructing each other. The existing toll evasion audit mechanism is lagging behind. Abnormal behaviors such as license plate cloning, license plate replacement and OBU blocking are mostly checked manually after the fact, and there is a lack of real-time identification and closed-loop processing capabilities. Summary of the Invention

[0005] Therefore, it is necessary for the present invention to provide a traffic free-flow tolling method and system based on state snapshots to solve at least one of the above-mentioned technical problems.

[0006] To achieve the above objectives, a traffic free-flow tolling method based on state snapshots is applied to a road segment containing several tolling gantries equipped with roadside units, each of which is communicatively connected to a central system. The method includes the following steps: When a vehicle enters the first billing gantry, the roadside unit communicates with the on-board digital tag, requests a billing rule set from the central system, generates a status snapshot summary, and writes it into the volatile travel storage area of ​​the on-board digital tag. When the vehicle passes through the subsequent billing gantry, the roadside unit reads the status snapshot summary and compares the version number of the billing rule set with the version number of the locally cached billing rule set. If they match, billing is performed according to the locally cached billing rule set, and a transaction log is generated and uploaded. If they do not match, the unit requests the status incremental change log from the central system and backtracks to calibrate the billing data to obtain the calibrated billing amount. The difference between the calibrated billing amount and the billing amount calculated according to the locally cached billing rule set is marked as a data item to be compensated, and a transaction log is generated and uploaded. When the vehicle leaves the toll road section, the exit roadside unit reads the status snapshot summary and uploads it to the central system. The central system performs consistency verification and difference compensation on the vehicle's full-trip toll data based on the transaction data and data items to be compensated for each toll gantry, using the status snapshot summary as a benchmark.

[0007] Preferably, the present invention also provides a traffic free-flow tolling system based on state snapshots, the system comprising: A vehicle-mounted digital tag is installed in a vehicle. The vehicle-mounted digital tag includes a volatile trip storage area and a persistent storage area, which are isolated from each other in a physical storage layer. A roadside unit, deployed on a billing gantry, includes a local cache unit and a microwave communication unit; The central system communicates with each roadside unit via a wired or wireless communication network; The vehicle-mounted digital tag, the roadside unit, and the central system work together to execute the traffic free-flow tolling method based on state snapshots as described above.

[0008] The beneficial effects of this invention are as follows: On the one hand, by writing the billing rule set obtained by the first billing node into the volatile trip storage area of ​​the vehicle digital tag in the form of a state snapshot summary, the billing rule benchmark is carried by the vehicle and remains constant throughout the trip. This transforms the distributed parameter synchronization problem when each gantry bills independently into a centralized consistency verification problem with the vehicle tag as the carrier, avoiding the billing rule drift within the same trip caused by the synchronization delay between edge nodes and backend data, and ensuring the uniformity of the billing basis throughout the trip.

[0009] On the other hand, by using the state snapshot summary as a benchmark to perform retrospective consistency verification and difference compensation on the billing flow uploaded by each billing gantry, the billing logic break caused by the independent generation of transaction records by each gantry under the segmented billing mode is broken. This enables the backend system to accurately restore the billing parameter status when the vehicle passes through each node, and realizes closed-loop correction of cross-node billing differences.

[0010] On the other hand, by utilizing the volatile trip storage area of ​​the vehicle digital tag to carry trip-level temporary data, which is physically isolated from the persistent storage area and automatically expired and cleared after the trip ends, it not only avoids the interference of the trip's intermediate state on regular account information, but also enhances the reliability of the tag-vehicle correspondence by associating the state snapshot summary with the vehicle's physical identity, thus improving transaction security in an open free-flow environment.

[0011] On the other hand, by deploying vehicle feature acquisition modules on roadside units and associating them with state snapshot summaries, multi-source perception collaboration and strong association with tag physical identity are achieved, improving recognition stability and transaction security in complex scenarios. Attached Figure Description

[0012] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description taken in conjunction with the accompanying drawings: Figure 1 A schematic diagram of the state snapshot summary generation and writing process of one embodiment is shown.

[0013] Figure 2 A schematic diagram of version comparison and backtracking calibration logic in one embodiment is shown.

[0014] Figure 3 A schematic diagram of an embodiment of an in-vehicle digital tag storage structure is shown.

[0015] Figure 4 A schematic diagram of the internal structure of a roadside unit according to one embodiment is shown.

[0016] Figure 5 A schematic diagram of the overall hardware architecture of a system according to one embodiment is shown. Detailed Implementation

[0017] 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.

[0018] 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.

[0019] 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.

[0020] In this case, Figure 1 The diagram illustrates the complete data flow and processing procedure of the roadside unit at the first billing gantry generating a status snapshot summary and writing it into the volatile trip storage area of ​​the vehicle digital tag. The left side of the diagram shows how vehicle type classification version number, discount strategy version number, rate table version number, and billing rule set effective timestamp are used as input data. After processing by a preset hash algorithm (such as SHA-256 or concatenated hash), a fixed-length status snapshot digest is generated. The upper right side shows the process of assigning a globally unique trip session identifier to this status snapshot digest. The lower left side shows the process of generating corresponding hash values ​​from vehicle static physical feature identifiers (such as vehicle length, wheelbase, number of axles, etc.) through hash operations. The middle section shows the process of associating and binding the hash values ​​of vehicle static physical feature identifiers with the status snapshot digest, thereby making the status snapshot digest uniquely correspond to the vehicle's physical identity. The right side shows the process of generating an integrity check code (such as CRC-32 or HMAC) based on the status snapshot digest. The lower middle section shows the process of encapsulating the status snapshot digest, integrity check code, trip session identifier, and physical feature hash value into a unified data frame. The bottom section shows the process of writing this data frame together into the volatile trip storage area of ​​the on-board digital tag.

[0021] In this case, Figure 2The diagram illustrates the complete logical judgment process of the roadside unit at the subsequent billing gantry, including reading the status snapshot summary, integrity verification, identity consistency verification, version comparison, and retrospective calibration. The diagram shows, in sequence: after reading the status snapshot summary, integrity verification code verification (S111) is performed. If the verification fails, use is rejected, an anomaly alarm is triggered, and the billing transaction is terminated. If the verification passes, the identity consistency verification begins. In the identity consistency verification stage, the vehicle's physical identity is verified through physical feature hash comparison. If the comparison is inconsistent, an identity anomaly warning is triggered, and the billing transaction is terminated. If the comparison is consistent, the billing rule set version number in the status snapshot summary is extracted. The extracted version number is then compared with the locally cached billing rule set version number. If the versions match, billing is based on the locally cached version number, and a transaction log is generated and uploaded. If the versions do not match, the incremental status change log is requested from the central system, and segmented retrospective calibration is performed. The difference between the calibrated billing amount and the original billing amount is marked as a data item to be compensated, and finally, a transaction log is generated and uploaded.

[0022] In this case, Figure 3 This diagram schematically illustrates the physical storage layer isolation structure within an on-board digital tag. The diagram shows that the on-board digital tag comprises two physically isolated storage areas: an upper volatile trip storage area, used to store trip-level temporary data such as status snapshot summaries, integrity check codes, trip session identifiers, and vehicle static physical feature hash values; and a lower persistent storage area, used to store long-term data such as regular account information, user balances, and tag issuance information. The left side of the diagram shows roadside units performing write / read operations on the volatile trip storage area, and regular transactions performing read / write operations on the persistent storage area, with the independent relationship between the two marked. The right side illustrates the isolation characteristic of the physical storage layers, meaning that data read / write operations on the volatile trip storage area do not affect the regular account information in the persistent storage area.

[0023] In this case, Figure 4The diagram schematically illustrates the internal functional modules of a Roadside Unit (RSU) deployed on a billing gantry and their interactions with external entities. The upper layer of the diagram shows three data source modules side-by-side: on the left is a microwave communication unit (DSRC / C-V2X), responsible for bidirectional communication with onboard digital tags and reading / writing volatile trip storage; on the upper right is a local cache unit, which pre-stores copies of the billing rule set (including vehicle type classification, discount strategies, and rate tables) on non-volatile storage media and maintains bidirectional communication with the central system; the lower middle layer is a vehicle feature acquisition module, integrating three sensing methods: LiDAR (3D point cloud scanning), structured light sensors (contour measurement), and high-definition industrial cameras (image recognition). The lower layer of the diagram shows an edge computing processing unit, including a version comparison engine, a backtracking calibration engine, a hash operation module, an integrity verification module, an identity consistency verification module, and a pipeline generation module. The diagram shows the logical relationship of the three upper-level data source modules independently inputting the collected or read data into the edge computing processing unit for processing, as well as the path of outputting the processing results (billing amount, data items to be compensated, abnormal alarms or transaction records) to the central system or back to the vehicle digital tag.

[0024] In this case, Figure 5 This diagram schematically illustrates the overall hardware deployment architecture of the traffic free-flow tolling system based on state snapshots of this invention. The top of the diagram shows the central system, which is connected via wired / wireless communication networks to the first tolling gantry, subsequent tolling gantry, and exit tolling gantry deployed sequentially along the tolling segment. Each tolling gantry is equipped with a roadside unit (RSU, including a local buffer unit and a microwave communication unit) and a vehicle feature acquisition module (LiDAR / camera). The vehicle feature acquisition module communicates with the corresponding roadside unit via wired or wireless means to collaboratively complete the collection and verification of vehicle static physical feature identification. The bottom of the diagram shows passing vehicles and their on-board units (OBUs). Vehicles pass through each tolling gantry sequentially along the travel direction and interact with the roadside units of each gantry non-contactly via microwave communication, thereby achieving physical carrying and consistency verification of the tolling rule benchmark throughout the entire journey.

[0025] It should be noted that all the accompanying drawings in this application are exemplary illustrations of the technical solutions of this invention, intended to help understand the generation and writing mechanism of the state snapshot summary, the logical judgment and processing flow of subsequent billing nodes, the storage isolation mechanism of the vehicle-mounted digital tag, the internal composition and data interaction relationship of the roadside unit, and the system hardware architecture and deployment relationship, and are not intended to limit the invention. The hash algorithm types (such as SHA-256, CRC-32, HMAC, etc.), communication protocol types (such as DSRC, C-V2X), storage medium types (such as SRAM, DRAM, Flash, EEPROM, etc.), sensing device types (such as LiDAR, structured light sensors, high-definition industrial cameras), specific parameters of vehicle static physical feature identification (such as vehicle length, wheelbase, number of axles), data frame encapsulation format, physical layout of storage areas, execution order and branch layout of judgment nodes, exception handling levels, sub-module division of edge computing processing units, physical layout positions of each module, connection topology between modules, communication network types, number of gantries, and communication methods between vehicles and gantries shown in the accompanying drawings are all illustrative only. This invention does not impose any limitations on this. Those skilled in the art can choose other hash algorithms, communication protocols, storage media, sensing devices, feature parameters, encapsulation protocols, network architectures, device configurations, module division methods, or layout architectures with equivalent functions to replace them according to actual security needs, storage capacity, computing performance, communication environment, sensing accuracy requirements, system architecture, road network conditions, and cost constraints. All such replacements should be covered within the protection scope of this invention.

[0026] To achieve the above objectives, please refer to Figures 1 to 5 This invention provides a traffic free-flow tolling method based on state snapshots, applied to road sections containing several tolling gantries equipped with roadside units, each of which is communicatively connected to a central system, and includes the following steps: Optionally, S10 may be included before S100.

[0027] S10: Deploy roadside units on the billing gantry. Each roadside unit includes a local cache unit, a microwave communication unit, and a vehicle feature acquisition module. The vehicle feature acquisition module includes at least one of a lidar, a structured light sensor, and a high-definition industrial camera, used to collect static physical feature identifiers of vehicles. The roadside units of each billing gantry are networked and linked with the central system through a wired or wireless communication network to achieve cross-terminal data synchronization and abnormal data re-collection.

[0028] Optionally, S10 is followed by S20.

[0029] S20: The roadside unit collects static physical feature data of the vehicle through the vehicle feature acquisition module, including vehicle exterior features, vehicle size and model; the edge computing unit of the roadside unit performs standardization processing on the static physical feature data and generates the vehicle static physical feature identifier through a hash encryption algorithm.

[0030] S100: When the vehicle enters the first billing gantry, the roadside unit communicates with the vehicle-mounted digital tag, requests the billing rule set from the central system, generates a status snapshot summary, and writes it into the volatile travel storage area of ​​the vehicle-mounted digital tag. S200: When the vehicle passes through the subsequent billing gantry, the roadside unit reads the status snapshot summary and compares the version number of the billing rule set with the version number of the locally cached billing rule set. If they match, billing is performed according to the locally cached billing rule set, and a transaction log is generated and uploaded. If they do not match, the unit requests the status incremental change log from the central system and backtracks to calibrate the billing data to obtain the calibrated billing amount. The difference between the calibrated billing amount and the billing amount calculated according to the locally cached billing rule set is marked as a data item to be compensated, and a transaction log is generated and uploaded. S300: When the vehicle leaves the toll section, the exit roadside unit reads the status snapshot summary and uploads it to the central system. The central system performs consistency verification and difference compensation on the vehicle's full-trip toll data based on the flow of each toll gantry and the data items to be compensated, using the status snapshot summary as a benchmark.

[0031] Optionally, the S300 is followed by the S400.

[0032] S400: When the roadside unit detects abnormal behavior during identity consistency verification or version comparison, it automatically locks the identity of the vehicle digital tag, solidifies the entire process passage evidence chain, and triggers a real-time warning; the central system synchronizes the abnormal behavior to the traffic credit platform.

[0033] Optionally, the S400 is followed by the S500.

[0034] S500: The central system encrypts the vehicle's full-trip billing data, the status snapshot summary, and the data items to be compensated, and uploads them synchronously to the blockchain storage node to establish a permanent standardized data archive.

[0035] Preferably, the retrospective calibration billing data mentioned in S200 includes S201-S202.

[0036] S201: Request the central system for the incremental state change log since the effective timestamp of the state snapshot summary. The incremental state change log includes change records for each billing rule parameter item, and the change record carries the change timestamp and parameter values ​​before and after the change. In some embodiments, the incremental state change log refers to a collection of data records recorded by the central system in time series form after a change in the billing rule set, containing only the changed portions. Unlike the full billing rule set, the incremental state change log only records the parameter items that have changed from a certain reference time point to the current time.

[0037] Optionally, the query basis for the incremental status change log is the effective timestamp carried in the status snapshot summary. The effective timestamp refers to the timestamp corresponding to the currently effective billing rule set returned by the central system when the first billing gantry requests a billing rule set. Starting from this effective timestamp, the central system retrieves change records for all billing rule parameter items, generates the incremental status change log, and returns it to the roadside unit that initiated the request.

[0038] In some embodiments, the billing rule parameter item refers to the smallest independently changeable unit constituting the billing rule set. The billing rule set includes a vehicle classification version number, a discount strategy version number, and a rate table version number; correspondingly, the billing rule parameter item includes at least one of a vehicle classification parameter, a discount strategy parameter, and a rate table parameter. Each change to a billing rule parameter item corresponds to a change record.

[0039] Optionally, the change record is a structured data entry generated by the central system when a single billing rule parameter item is changed. The change record carries a change timestamp and parameter values ​​before and after the change, wherein the parameter values ​​before and after the change are used to record the original parameter value of the billing rule parameter item before the change takes effect and the updated parameter value after the change takes effect.

[0040] In some embodiments, if the billing rule set has not changed since the effective timestamp, the status incremental change log returned by the central system is an empty log or only carries a no-change flag. Based on this, the roadside unit confirms that the billing rule set remains constant during the trip and can directly use the billing rule set corresponding to the status snapshot summary as a benchmark for billing calibration.

[0041] In some embodiments, the incremental status change log is encapsulated in a structured data format, and each change record stores the change timestamp, parameter item identifier, parameter value before change, and parameter value after change in key-value pairs.

[0042] S202: The roadside unit performs segmented backtracking calculations on the current billing data of the vehicle based on the change timestamp and the parameter values ​​before and after the change, and obtains the calibrated billing amount.

[0043] In some embodiments, the current billing data refers to the original billing amount generated by the roadside unit after performing billing calculations on the vehicle based on a locally cached billing rule set (which may be inconsistent with the version of the billing rule set in the state snapshot summary). In free-flow tolling scenarios, the roadside unit prioritizes calling the billing rule set stored in the local cache unit for real-time billing to complete fast contactless transactions, thereby generating the current billing data. However, since the locally cached billing rule set may be ahead of the version of the billing rule set corresponding to the state snapshot summary due to periodic data synchronization between edge nodes and the central system, the current billing data may deviate from the unified benchmark for the entire trip. Therefore, the segmented backtracking calculation needs to be performed to eliminate this deviation.

[0044] Optionally, the segmented backtracking calculation refers to the process by which the roadside unit, for each billing rule parameter item change record carried in the state incremental change log, backtracks the version evolution process of each parameter item according to its category, and reverses from the locally cached version on which the current billing data is based to the baseline version corresponding to the state snapshot summary, and then recalculates the billing amount. Specifically, the roadside unit parses the state incremental change log and groups it according to the category of billing rule parameter items (such as vehicle type classification parameters, discount strategy parameters, and rate table parameters); for each type of billing rule parameter item, it determines the original parameter value of the parameter item at the effective timestamp of the state snapshot summary based on its change timestamp (i.e., the parameter value before the change of the first change record, or directly taking the locally cached parameter value when there is no change record), and substitutes the baseline parameter value after backtracking of each parameter item into the billing calculation to obtain the calibrated billing amount.

[0045] In some embodiments, if the state incremental change log contains multiple change records for the same billing rule parameter item (e.g., the rate table parameter changes from V1.0 to V1.1 in T1, and then from V1.1 to V1.2 in T2), the roadside unit, during segmented backtracking calculation, starts from the effective timestamp of the state snapshot summary and traces forward along the change timestamps to the moment the vehicle passes the billing gantry to determine the version parameter value applicable to the billing rule parameter item at the moment the vehicle passes. Specifically, if the moment the vehicle passes the billing gantry is between T1 and T2, the billing rule parameter item applies the parameter value changed in T1 (V1.1); if it is after T2, the parameter value changed in T2 (V1.2) applies. After determining the applicable parameter value for each billing rule parameter item according to this rule, the roadside unit calculates the calibrated billing amount.

[0046] In some embodiments, when the roadside unit performs the segmented backtracking calculation, it simultaneously records the backtracking path of each billing rule parameter item and the selected parameter version identifier, and appends the backtracking path information to the data item to be compensated, so that when the central system performs the full-journey consistency verification, it can reproduce the segmented backtracking calculation process of the roadside unit and verify the rationality of the calibrated billing amount.

[0047] Preferably, the billing rule set in S200 includes a vehicle type classification version number, a discount strategy version number, and a rate table version number; the generation of the status snapshot summary includes S211-S212.

[0048] S211: Based on the vehicle type classification version number, the discount strategy version number, the rate table version number, and the effective timestamp of the billing rule set, generate a status snapshot summary using a preset hash algorithm, and assign a unique trip session identifier to this trip; In some embodiments, the state snapshot digest refers to a fixed-length string identifier generated by performing a one-way hash operation on the key version information and time base of the billing rule set. The state snapshot digest serves as the digital fingerprint of the billing rule set at a specific moment, physically carried by the vehicle throughout the entire trip, and is used to provide a unified billing rule base for subsequent billing gantry units. Since the state snapshot digest only records the hash result of the version identifier and timestamp, rather than the complete billing rule parameter content, its data volume is much smaller than the full billing rule set, facilitating rapid writing and reading in the volatile trip storage area of ​​the onboard digital tag, while avoiding the plaintext exposure of sensitive billing parameters to the onboard unit, thus improving data security in an open, free-flowing environment.

[0049] Optionally, the trip session identifier is a unique identifier assigned by the roadside unit to the vehicle for this trip when it enters the first toll gantry. The trip session identifier remains constant within a single trip and is used to associate multiple transaction records and data items to be compensated generated by the same vehicle passing through various toll gantryes. This allows the central system to accurately identify and aggregate all toll data belonging to the same trip when the vehicle exits the toll section, in order to perform end-trip consistency verification and difference compensation. The trip session identifier is stored in the volatile trip storage area of ​​the on-board digital tag along with the status snapshot digest and is synchronously cleared along with the status snapshot digest after the trip ends.

[0050] In some embodiments, the roadside unit extracts the vehicle type classification version number, the discount strategy version number, and the rate table version number from the billing rule set returned by the central system, and reads the effective timestamp of the billing rule set. The vehicle type classification version number is used to identify the currently applicable vehicle type classification rule (e.g., passenger cars classified by number of seats, freight cars by number of axles and rated load capacity); the discount strategy version number is used to identify the currently applicable toll reduction rules (e.g., ETC user discounts, differentiated toll strategies, and free passage rules on holidays); and the rate table version number is used to identify the currently applicable unit mileage rate standard for each road segment.

[0051] In some embodiments, when generating the state snapshot digest, the roadside unit also appends a random salt value to the original string to defend against hash collision attacks based on common version number combinations. The random salt value is either issued by the central system when returning the billing rule set, or generated by the roadside unit based on its local security module and written to the volatile trip storage area along with the state snapshot digest after its generation. When the subsequent billing gantry reads the state snapshot digest, it does not need to parse the specific content of the random salt value; it only needs to compare the overall hash values ​​for consistency.

[0052] In some embodiments, the trip session identifier is generated using an encoding rule that includes a timestamp and a random number element to ensure global uniqueness in a statistical sense. The roadside unit encapsulates the trip session identifier and the status snapshot summary into a structured data object and writes it into the volatile trip storage area. The order and separators of the fields in the structured data object are pre-agreed between the roadside unit and the central system to ensure data interoperability between devices from different manufacturers.

[0053] S212: The roadside unit collects the static physical feature identifier of the vehicle, and associates and binds the hash value of the static physical feature identifier of the vehicle with the state snapshot digest, so that the state snapshot digest uniquely corresponds to the physical identity of the vehicle.

[0054] In some embodiments, the vehicle static physical feature identifier refers to a set of structural feature parameters inherent to the vehicle at the physical level that are difficult to tamper with or transfer. Unlike the pre-set logical binding information (such as license plate number, OBU code, etc.) in the vehicle digital tag, the vehicle static physical feature identifier directly originates from the physical attributes of the vehicle itself, such as vehicle dimensions (length, width, height), wheelbase, number of axles, number and specifications of tires, and chassis feature contours. In an open free-flow tolling environment, there is a risk that the vehicle digital tag may be removed and installed on other vehicles (i.e., tag cloning) or interchanged with other vehicles. Relying solely on the pre-set logical binding information of the tag cannot effectively verify whether the physical vehicle currently holding the tag is a legitimate bound vehicle. Therefore, by collecting the vehicle static physical feature identifier and associating it with the state snapshot summary, a strong correlation between the trip data within the tag and the vehicle's physical identity can be established without adding additional hardware authentication equipment, preventing the tag from being illegally misappropriated and still passing the identity verification of the tolling system.

[0055] Optionally, the roadside unit is equipped with a vehicle feature acquisition module, which includes at least one or more combinations of LiDAR, structured light sensors, or high-definition industrial cameras. When a vehicle enters the first billing gantry, the roadside unit, while establishing a communication link with the vehicle-mounted digital tag via a microwave communication unit, triggers the vehicle feature acquisition module to perform non-contact scanning or image acquisition of the passing vehicle, extracting the vehicle's static physical feature identifiers. For example, the roadside unit obtains the vehicle's three-dimensional point cloud contour using LiDAR and extracts the vehicle's external dimensions; or it captures side images of the vehicle using a high-definition industrial camera and extracts feature parameters such as wheelbase and number of axles based on image recognition algorithms.

[0056] In some embodiments, the roadside unit standardizes the collected vehicle static physical feature identifiers (e.g., unifies dimensions, removes noise points, and normalizes size data), and generates a hash value for the vehicle static physical feature identifier using a preset hash algorithm. The roadside unit associates and binds the hash value of the vehicle static physical feature identifier with the state snapshot summary. Specifically, the hash value of the vehicle static physical feature identifier is embedded as an additional field into the data structure of the state snapshot summary, or a cascaded hashing method is used to hash the state snapshot summary and the hash value of the vehicle static physical feature identifier again to generate a composite hash value. The composite hash value is then written as a new state snapshot summary into the volatile trip storage area of ​​the on-board digital tag. Thus, the state snapshot summary not only carries the version baseline information of the billing rule set, but also uniquely corresponds to the physical vehicle features collected at the time of generation. Any attempt to transfer the on-board digital tag to another vehicle will be identified because the vehicle static physical feature identifier collected by the subsequent billing gantry does not match the hash value bound in the state snapshot summary.

[0057] In some embodiments, considering that the accuracy of vehicle static physical feature identification acquisition may be affected by environmental factors (such as rain, snow, lighting conditions, and vehicle speed), the roadside unit sets a tolerance threshold for the acquired feature parameters before generating the hash value of the vehicle static physical feature identification. For example, the vehicle length acquisition value is allowed a measurement error of ±5 cm, and the wheelbase is allowed a measurement error of ±3 cm. When the roadside unit performs identity consistency verification at the subsequent billing gantry, if the currently acquired vehicle static physical feature identification matches the hash value bound in the status snapshot summary within the tolerance threshold range, the identity is determined to be consistent; if it exceeds the tolerance threshold, the identity is determined to be abnormal. The tolerance threshold is uniformly configured and distributed by the central system among all roadside units to ensure the consistency of the identity verification standard throughout the entire journey.

[0058] In some embodiments, the association between the hash value of the vehicle static physical feature identifier and the state snapshot summary is stored in the volatile trip storage area of ​​the on-board digital tag as a key-value pair, where the key name is a preset identifier and the key value is the hash value of the vehicle static physical feature identifier. After the roadside unit of the subsequent billing gantry reads the volatile trip storage area, it can extract the bound vehicle static physical feature identifier hash value by parsing the key-value pair, without having to reverse-parse the state snapshot summary itself, thereby protecting the privacy of the billing rule set version information.

[0059] Preferably, the vehicle-mounted digital tag in S100 includes a volatile trip storage area and a persistent storage area, which are isolated from each other in the physical storage layer; the status snapshot summary is written to the volatile trip storage area, and the status snapshot summary is automatically invalidated and cleared after the vehicle trip ends or the vehicle-mounted digital tag loses power, and the data read and write operations of the volatile trip storage area do not affect the regular account information in the persistent storage area, and also includes S110-S111.

[0060] S110: When the roadside unit writes the status snapshot summary into the volatile travel storage area, it simultaneously generates an integrity check code for the status snapshot summary and writes it into the volatile travel storage area as well. In some embodiments, the integrity check code refers to a short-length verification identifier generated by the roadside unit based on the data content of the status snapshot digest using a preset verification algorithm. This identifier is used to verify whether the status snapshot digest has been corrupted or illegally tampered with during writing, storage, and reading. In free-flow tolling scenarios, vehicles pass through the billing gantry at normal speeds. The microwave communication time window between the roadside unit and the on-board digital tag is extremely limited, and the volatile trip storage area of ​​the on-board digital tag may be affected by fluctuations in on-board power, electromagnetic interference, or malicious radio frequency attacks during high-speed vehicle travel, causing individual bits of the status snapshot digest to flip or the data content to be tampered with. If the subsequent billing gantry directly reads the corrupted status snapshot digest and performs billing comparison based on an incorrect version number, it will cause billing logic confusion or transaction security vulnerabilities. Therefore, generating and storing the integrity check code while writing the status snapshot digest allows for rapid verification of data integrity during subsequent reading, ensuring the reliability of the entire trip billing benchmark.

[0061] Optionally, after generating the status snapshot digest, the roadside unit uses the status snapshot digest as input data and generates the integrity check code using a preset verification algorithm (e.g., CRC-32, truncated digest of SHA-256, or HMAC based on a symmetric key). The data length of the integrity check code is much shorter than that of the status snapshot digest, thereby avoiding excessive occupation of the limited storage space of the volatile trip storage area. The roadside unit encapsulates the status snapshot digest and the integrity check code into a data frame structure and writes them together into the volatile trip storage area of ​​the vehicle-mounted digital tag. In the data frame structure, the status snapshot digest and the integrity check code are arranged in a preset field order and are supplemented with a frame header identifier and a frame tail identifier.

[0062] In some embodiments, when the roadside unit writes the integrity check code into the volatile trip storage area, it explicitly limits the writing location of the integrity check code and the writing location of the status snapshot summary to the same logical page or the same data block in the volatile trip storage area, ensuring that the two are adjacent or continuous in physical storage address.

[0063] In some embodiments, considering the risk of malicious radio frequency attacks against vehicle-mounted digital tags in an open free-flow environment, the roadside unit uses a message authentication code algorithm based on a symmetric key to generate the integrity check code. The symmetric key is uniformly generated and periodically updated by the central system, and distributed to each roadside unit through a secure channel or a remote key distribution mechanism. The roadside unit uses the symmetric key and the state snapshot digest to generate an HMAC check code, ensuring that even if an attacker intercepts and tampers with the content of the state snapshot digest, they cannot generate a valid integrity check code without knowing the symmetric key. This elevates simple data integrity verification to a dual security mechanism that combines data source authentication and tamper-proof capabilities.

[0064] In some embodiments, when generating the integrity check code, the roadside unit also includes the trip session identifier in the input data of the verification operation. Since the trip session identifier remains unique within the current trip, including it in the verification operation allows the integrity check code to be simultaneously bound to the context information of the current trip, preventing attackers from porting the legitimate state snapshot digests and integrity check codes of other vehicles to the volatile trip storage area of ​​the target vehicle to carry out replay attacks. During subsequent verification, the roadside unit simultaneously verifies the consistency between the trip session identifier and the state snapshot digest. If it finds that the trip session identifier does not match the current traffic scenario, it also triggers an anomaly alarm.

[0065] S111: When the roadside unit reads the status snapshot digest, it first verifies the integrity check code. Only after the verification is successful will the comparison be performed. If the verification fails, the status snapshot digest will be rejected and an abnormal alarm will be triggered.

[0066] Optionally, the roadside unit reads the data frame of the status snapshot digest from the volatile trip storage area of ​​the vehicle-mounted digital tag, and extracts the status snapshot digest and the integrity check code from a preset field position in the data frame. The roadside unit uses the same preset verification algorithm and algorithm parameters (e.g., the same CRC-32 polynomial or the same symmetric key) as when generating the integrity check code in S110 to recalculate the check value of the extracted status snapshot digest to obtain the current check value. The roadside unit compares the current check value with the integrity check code extracted from the data frame; if the two are completely consistent, the verification is deemed successful; if the two are inconsistent, the verification is deemed unsuccessful, the roadside unit immediately refuses to use the status snapshot digest, terminates any billing calculation based on the status snapshot digest, and triggers an anomaly alarm.

[0067] In some embodiments, if the roadside unit uses a message authentication code algorithm based on a symmetric key to generate the integrity check code, then when the verification fails, the roadside unit further distinguishes the anomaly type: if the comparison result between the current check value and the integrity check code is a numerical difference, it is determined that the data integrity is damaged (possibly due to random interference); if the roadside unit finds that the frame header or frame tail identifier of the data frame is abnormal during the verification process, or that the trip session identifier does not match the current travel scenario, it is determined to be a potential malicious tampering attack. For different anomaly types, the roadside unit executes differentiated alarm responses: for data integrity damage, the roadside unit may request the central system to re-acquire the vehicle's status snapshot digest to attempt to restore the transaction; for potential malicious tampering attacks, the transaction is directly locked and a security audit process is initiated, while a high-priority security alarm is sent to the central system.

[0068] In some embodiments, the rejection operation after verification failure specifically manifests as the roadside unit marking the currently read data frame in the volatile trip storage area as invalid, or sending a data reset command to the on-board digital tag to clear the damaged state snapshot summary and the integrity check code, preventing the billing gantry from reading invalid data again in subsequent transactions. After triggering an abnormal alarm, the roadside unit records this communication event as an abnormal transaction. This abnormal transaction is not included in the normal billing transaction sequence, but is uploaded to the central system along with the data of the same batch for future reference, ensuring the integrity of the entire trip data loop.

[0069] Preferably, the step of requesting a billing rule set from the central system in step S100 includes steps S120-S121.

[0070] S120: The roadside unit initiates a real-time status query request for the vehicle-mounted digital tag to the central system. The real-time status query request carries the identity identifier and communication link authentication information of the vehicle-mounted digital tag. In some embodiments, when a vehicle enters the first billing gantry, the roadside unit needs to determine the initial billing rule base for the vehicle's current trip. If the roadside unit directly calls the billing rule set stored in its local cache unit, the periodic synchronization delay between the local cache and the central system may cause the billing rule set applicable to the vehicle at the start of the trip to be different from the latest effective version on the central system side, thus creating a potential deviation for subsequent consistency verification throughout the entire trip. Therefore, when the vehicle enters the first billing gantry, the roadside unit first initiates the real-time status query request to the central system to directly obtain the currently effective billing rule set from the central system.

[0071] Optionally, the real-time status query request refers to an immediate data request sent by the roadside unit to the central system via a wired or wireless communication network to query the current applicable billing rule set status of a specific vehicle-mounted digital tag. The real-time status query request carries the identification identifier of the vehicle-mounted digital tag. This identifier is a logical identifier pre-embedded in the vehicle-mounted digital tag, used to uniquely identify the tag's account attributes in the central system. Examples include the vehicle-mounted digital tag's serial number, user account number, OBU code (On-Board Unit unique code), or a combination of the tag issuing agency code and the tag's serial number. The OBU code is a globally unique hardware device identifier written into the vehicle-mounted digital tag during the manufacturing or issuance stage. After establishing a communication link with the vehicle-mounted digital tag via a microwave communication unit, the roadside unit can directly read the OBU code to complete device-level identification. The central system retrieves the account information bound to the tag (such as vehicle type classification registration, account credit status, preferential policy binding relationship, etc.) based on the identification identifier to determine which billing rule set should be returned to the vehicle.

[0072] In some embodiments, the communication link authentication information refers to the security credentials attached by the roadside unit when initiating the real-time status query request, used to prove to the central system that the roadside unit has a legitimate communication identity and that the request is real-time. In an open free-flow environment, billing gantries are deployed dispersedly along road segments, and the communication link between the roadside unit and the central system may traverse public networks or wireless channels. This poses a risk that unauthorized devices may impersonate roadside units to obtain billing parameters from the central system, or that attackers may intercept and replay historical requests to disrupt system operation. The communication link authentication information includes at least one or more combinations of roadside unit device certificate signatures, session tokens based on the current timestamp, or challenge-response verification codes. After receiving the real-time status query request, the central system verifies the communication link authentication information to verify the legitimacy of the roadside unit's device and the real-time nature of the request. If the verification passes, the central system returns a billing rule set based on the identity identifier; if the verification fails, the system refuses to respond to the request and records a security event.

[0073] In some embodiments, before initiating the real-time status query request, the roadside unit first completes bidirectional link activation and basic handshake with the vehicle-mounted digital tag through the microwave communication unit to confirm that the vehicle-mounted digital tag is in a readable and writable state and that the communication signal strength meets the transaction requirements. Only when the vehicle-mounted digital tag responds normally and the communication link is stable will the roadside unit execute the real-time status query to the central system, avoiding invalid requests to the central system due to tag communication failures or communication interruptions caused by high-speed vehicle passage, thus reducing the concurrent processing pressure on the central system.

[0074] In some embodiments, if the roadside unit initiates the real-time status query request to the central system and does not receive a response from the central system within a preset timeout threshold (e.g., due to network congestion or excessive load on the central system), the roadside unit executes a degradation strategy: it prioritizes using the billing rule set stored in the local cache unit as the initial baseline for this trip, and adds a degradation identifier to the generated status snapshot summary so that the subsequent billing gantry and central system can identify that the baseline data for this trip comes from the local cache rather than a real-time query.

[0075] S121: The central system receives the real-time status query request, verifies the communication link authentication information, and returns the currently effective billing rule set to the roadside unit according to the identity identifier after the verification is successful.

[0076] In some embodiments, the central system acts as the management node for the billing rule set, centrally maintaining the version library and effectiveness status table of each billing rule parameter item. When the central system receives a real-time status query request initiated by the roadside unit through a wired or wireless communication network, it parses the data frame structure of the real-time status query request, extracts the communication link authentication information and the identity identifier carried therein, and prioritizes the execution of the verification process of the communication link authentication information to confirm the legality of the request source and the real-time nature of the requested data.

[0077] Optionally, the central system's verification of the communication link authentication information includes two dimensions: device authentication and request timeliness verification. In the device authentication dimension, the central system compares the roadside unit device certificate signature carried in the real-time status query request with a pre-set legitimate device public key library to confirm whether the roadside unit initiating the request is a registered and filed legitimate edge node. In the request timeliness verification dimension, the central system extracts the timestamp element from the communication link authentication information, calculates the deviation between the timestamp and the central system's current system time, and determines whether the deviation is within a preset anti-replay window range. Only when both device authentication and request timeliness verification pass, does the central system determine that the communication link authentication information verification is successful and continue executing the subsequent billing rule set query and return process; if either dimension verification fails, the central system refuses to return the billing rule set and records a security audit log.

[0078] In some embodiments, the currently effective billing rule set refers to a set of billing rule parameters that has been officially released and is in execution at the time of request processing by the central system. The central system maintains the version lifecycle of the billing rule parameter items. Each billing rule parameter item (vehicle classification parameter, discount strategy parameter, rate table parameter) may have multiple historical versions and one currently effective version. The central system parses the account attributes (e.g., vehicle registration category, applicable region, discount eligibility, etc.) bound to the vehicle digital tag based on the identity identifier, retrieves the currently effective version number of each billing rule parameter item matching the account attributes from the version library, and assembles the retrieved currently effective version numbers and their corresponding parameter contents into the billing rule set. At the same time, the central system records the effective timestamp of the billing rule set on the central system side. The effective timestamp is used to mark the specific time when the billing rule set is officially enabled and begins to apply to newly initiated trips, serving as the time base for subsequent status incremental change log queries.

[0079] In some embodiments, if the central system finds that the device certificate signature is invalid when verifying the communication link authentication information, it determines that there is a risk of unauthorized device access, immediately refuses to respond, triggers a high-priority security alarm, and adds the network address of the roadside unit to a temporary blacklist. If it finds that the timestamp deviation value exceeds the anti-replay window, it determines that the request may be a replay attack or a roadside unit clock anomaly, refuses to respond, and notifies the roadside unit to perform clock synchronization calibration. For cases where the verification passes but the identity identifier has no corresponding account record in the central system or the account is in an abnormal state (such as reported lost, frozen due to overdue payment), the central system returns an abnormal status code to the roadside unit, and the roadside unit executes the corresponding transaction interception or guides manual processing strategy according to the abnormality type.

[0080] In some embodiments, when the central system returns the currently effective charging rule set to the roadside unit, it encrypts the response data frame using an encryption transmission protocol agreed upon with the roadside unit to prevent the charging rule set from being intercepted or tampered with during transmission. The central system also appends the sequence number and timestamp of this response to the response data frame. After receiving the data, the roadside unit compares the response sequence number with the request sequence number to confirm that the received charging rule set corresponds one-to-one with the issued real-time status query request, thus avoiding data mismatch in concurrent request scenarios.

[0081] Preferably, the data item to be compensated in S300 includes the billing difference, the current billing gantry number, and the version difference identifier of the billing rule set; the roadside unit associates and encapsulates the data item to be compensated and attaches it to the flow chart before uploading it to the central system.

[0082] In some embodiments, when the same vehicle passes through multiple billing gantries consecutively within a short period, the roadside units of each gantry independently complete real-time billing and generate transaction logs based on locally cached billing rule sets. Due to the time delay in data synchronization between each billing gantry and the central system, and the potential dynamic changes in the billing rule sets during the trip, different gantries may complete transactions based on different versions of the billing rule sets, leading to discrepancies in billing results for different segments within the same trip. If only the original transaction logs are uploaded by each gantry, the central system cannot accurately reconstruct the actual billing rule version applied when the vehicle passed each node afterward, nor can it pinpoint the specific nodes and causes of the billing discrepancies. Therefore, when a roadside unit of a billing gantry detects an inconsistency between the version of its locally cached billing rule set and the state snapshot summary, and performs backtracking calibration, the discrepancy information generated during the calibration process must be structurally recorded in the form of the data items to be compensated and attached to the transaction logs for uploading.

[0083] Optionally, the billing difference refers to the numerical difference between the calibrated billing amount and the billing amount calculated based on the locally cached billing rule set. The calibrated billing amount is the amount recalculated by the roadside unit using the billing rule set corresponding to the state snapshot summary as a unified benchmark through segmented backtracking calculation; the billing amount calculated based on the locally cached billing rule set is the original amount calculated in real time by the roadside unit based on the billing rule set stored in the local cache unit to complete fast contactless billing when an actual transaction occurs.

[0084] Optionally, the current billing gantry number refers to the unique location identifier of the physical billing node that generates the billing difference within the road network. In free-flow tolling sections, each billing gantry is distributed longitudinally along the road, corresponding to different road segment intervals and operating entities. The current billing gantry number enables the central system to map the billing difference to specific road segment intervals during full-trip consistency verification, and then perform difference clearing and settlement based on the road segment operating entity identifier corresponding to each billing gantry. If the current billing gantry number is missing, the central system only knows that there is a deviation in the total trip amount, but cannot decompose the deviation to each road segment operating entity, resulting in a lack of basis for cross-entity clearing and settlement.

[0085] Optionally, the version difference identifier of the billing rule set refers to structured information describing the difference attributes between the version of the locally cached billing rule set and the version of the billing rule set carried in the state snapshot summary. The version difference identifier at least records the overall version number of the locally cached billing rule set, the base version number in the state snapshot summary, and the specific billing rule parameter category where the version difference occurred (e.g., version difference of vehicle classification parameters, version difference of discount strategy parameters, or version difference of rate table parameters). Through the version difference identifier, the central system can quickly identify the technical root cause of the current billing difference without comparing all billing rule parameters one by one, improving the processing efficiency of end-to-end consistency verification.

[0086] In some embodiments, if multiple billing rule parameter items in the locally cached billing rule set and the status snapshot summary undergo version differences simultaneously when the same vehicle passes through a billing gantry (e.g., both vehicle type classification parameters and rate table parameters change), the roadside unit lists the category of each differing parameter item in the version difference identifier of the billing rule set, calculates the billing difference component contributed by each parameter item change, and summarizes each component into the billing difference. The roadside unit can also encapsulate the component details of each parameter item as an extended subfield of the version difference identifier, enabling the central system to analyze the impact of billing rule changes on toll revenue by parameter item dimension when performing difference compensation.

[0087] Preferably, in S300, the central system performs consistency verification and difference compensation on the vehicle's full-trip billing data based on the flow and data items to be compensated for each billing gantry, using the status snapshot summary as a benchmark, including S301-S302.

[0088] S301: The central system receives the status snapshot summary uploaded by the exit roadside unit, extracts the transaction data and data items to be compensated uploaded by each billing gantry within the same trip, and recalculates each transaction data based on the billing rule set corresponding to the status snapshot summary as a unified benchmark to obtain the recalculated billing amount. In some embodiments, when a vehicle exits a toll road section, the exit roadside unit reads the status snapshot summary from the volatile trip storage area of ​​the on-board digital tag and uploads it to the central system via a wired or wireless communication network. The status snapshot summary serves as a digital fingerprint for the current trip's billing rules, carrying the vehicle type classification version number, discount strategy version number, rate table version number, and effective timestamp determined when the first billing gantry requested the billing rule set. Upon receiving the status snapshot summary, the central system uses it as an anchor point for end-trip consistency verification and initiates a retrospective audit of all billing data for the current trip.

[0089] Optionally, the central system parses the trip session identifier from the status snapshot summary, and extracts the transaction logs and pending compensation data items uploaded by each billing gantry within the same trip from the database or message queue based on the trip session identifier. The transaction log refers to the original transaction record generated by each billing gantry when a vehicle passes through, and includes at least the billing gantry number, transaction timestamp, vehicle identification, version number of the locally cached billing rule set, and the billing amount calculated based on that version. The pending compensation data item refers to the compensation information uploaded along with the transaction log by some billing gantry after detecting an inconsistency between the locally cached version and the status snapshot summary, and includes at least the billing difference, the current billing gantry number, and a version difference identifier for the billing rule set. The central system sorts all transaction logs belonging to the same trip by the passage timestamp to form a complete trip transaction sequence.

[0090] In some embodiments, the central system uses the billing rule set corresponding to the state snapshot summary as a unified benchmark. This means that the central system retrieves the actual billing parameters corresponding to the vehicle type classification version number, discount strategy version number, and rate table version number carried in the state snapshot summary from the central system version library, and reconstructs the complete billing rule set applicable when the vehicle enters the first billing gantry. This billing rule set serves as the golden benchmark for the entire trip and does not change due to differences in the local cache versions of subsequent billing gantryes. The central system applies this unified benchmark to each transaction, replacing the original locally cached billing rule set version recorded for each transaction, and re-executes the billing calculation for each transaction to obtain the recalculated billing amount.

[0091] In some embodiments, if the transaction record uploaded by a billing gantry does not carry any data items to be compensated (i.e., the local cache version of the gantry is consistent with the status snapshot summary), the central system still recalculates the transaction record based on the unified benchmark to verify the correctness of the local billing amount of the gantry. If the recalculated billing amount is consistent with the billing amount recorded in the transaction record, the transaction is confirmed to be correct; if there is a discrepancy (e.g., due to corrupted local cache parameters), the discrepancy is included in the subsequent trip difference summary to ensure the completeness of the entire trip audit.

[0092] S302: The difference between the recalculated billing amount and the billing amount in the corresponding transaction log is summarized as the trip difference. Based on the segment operation entity identifier corresponding to each billing gantry, the trip difference is decomposed into the difference to be cleared for each operation entity according to the segment ownership, and the difference clearing and settlement are performed separately.

[0093] In some embodiments, the tolling gantries are physically distributed within the boundaries of road segments managed by different operating entities. The original toll revenue generated by a vehicle passing through a single tolling gantry belongs to the operating entity of the road segment corresponding to that gantry at the time of the transaction. However, since each tolling gantry may complete the tolling based on different versions of the tolling rule set at the time of the transaction, there is an overall deviation between the sum of the original toll amounts for each segment within the same trip and the correct toll amount for the entire trip after recalculation using a unified benchmark. If only the total trip difference is summarized without distinguishing the ownership of the road segments corresponding to each tolling gantry, it will be impossible to determine which operating entities should bear or enjoy this overall deviation, thus leading to a lack of accurate basis for cross-entity revenue clearing. Therefore, after obtaining the recalculated toll amounts for each transaction, the central system needs to first summarize them to form a trip difference, and then decompose it into the difference to be cleared for each operating entity according to the ownership of the road segments, and perform difference clearing and settlement separately.

[0094] Optionally, the trip difference refers to the overall difference between the sum of the recalculated billing amounts for all transactions within the same trip and the sum of the original billing amounts for each corresponding transaction. The central system compares each transaction belonging to the same trip one by one, calculates the individual difference between the recalculated billing amount for each transaction and the original billing amount recorded for that transaction, and then summarizes each individual difference according to algebraic rules (overcharged portions are recorded as negative values ​​and need to be refunded, undercharged portions are recorded as positive values ​​and need to be deducted), forming the trip difference. The trip difference reflects the overall billing deviation scale caused by the drift of the billing rule set version for this trip, and is the basic total amount for subsequent difference clearing and settlement.

[0095] Optionally, the road segment operator identifier refers to a unique identification code pre-installed in the central system, used to identify the property owner or operator of each tolling gantry. In a segmented tolling free-flow road network, different tolling gantry may belong to different road segment operators.

[0096] Optionally, the pending settlement difference refers to the portion of the trip difference allocated to each individual operating entity after being broken down by the road segment operating entity corresponding to each billing gantry. The central system decomposes the trip difference according to road segment ownership based on the billing difference generated by each transaction and its corresponding road segment operating entity identifier. Specifically, if a billing difference exists in a transaction for a certain billing gantry (i.e., the recalculated billing amount is inconsistent with the original billing amount), then the billing difference is fully allocated to the road segment operating entity corresponding to that billing gantry; if a billing difference does not exist in a transaction for a certain billing gantry (i.e., the version is consistent and the calculation is correct), then the road segment operating entity corresponding to that gantry does not generate a pending settlement difference. The sum of the pending settlement differences for all operating entities equals the trip difference.

[0097] Optionally, the differential settlement refers to the central system performing cross-entity fund transfers or account balance adjustments based on the differentials to be settled for each operating entity. If the differential to be settled for an operating entity is negative (indicating that the operating entity overcharged tolls due to an outdated local cache version), the central system deducts the corresponding amount from the operating entity's revenue settlement account and transfers it to other operating entities that should receive the differential or refunds it to the user's account. If the differential to be settled for an operating entity is positive (indicating that the operating entity undercharged tolls due to a lagging local cache version), the central system makes up the difference to the operating entity from the deductions made by other operating entities that overcharged, or allocates funds from a unified risk reserve account. After the differential settlement is completed, the revenue account balances of each operating entity are consistent with the road segment revenue distribution results recalculated based on a unified benchmark.

[0098] In some embodiments, when performing differential settlement, the central system also combines the billing rule set version difference identifier in the data items to be compensated uploaded by each billing gantry to analyze the technical root cause of the differential to be settled by each operator (e.g., due to the excessively long data synchronization cycle of the roadside unit in the road section under the operator's jurisdiction, resulting in version lag).

[0099] Preferably, in S200, when the vehicle passes through the subsequent billing gantry, the roadside unit reads the status snapshot summary and performs identity consistency verification and version comparison, including S220-S222.

[0100] S220: The roadside unit first reads the status snapshot summary in the volatile travel storage area and extracts the version number of the billing rule set in the status snapshot summary; In some embodiments, when the vehicle subsequently passes through other billing gantry units, after each billing gantry establishes a communication link with the on-board digital tag via a microwave communication unit, it prioritizes reading the state snapshot summary in the volatile trip storage area, rather than directly requesting a new billing rule set from the central system or prioritizing reading the billing rule set from the local cache unit. This priority reading strategy ensures that all billing nodes throughout the trip use the same state snapshot summary physically carried by the vehicle as the billing comparison benchmark, avoiding new time synchronization deviations caused by each node independently requesting from the central system, or introducing billing rule versions inconsistent with the first billing node due to direct use of the local cache.

[0101] Optionally, when reading the volatile travel storage area, the roadside unit first executes the integrity check code verification process described in S111 to confirm that the status snapshot digest has not been tampered with or damaged, and then parses the data structure of the status snapshot digest. The roadside unit extracts the vehicle type classification version number, the discount strategy version number, and the rate table version number sequentially from the status snapshot digest according to a preset field parsing protocol, and uses each extracted version number as the base version number set for this comparison operation.

[0102] In some embodiments, if the roadside unit, when preferentially reading the volatile trip storage area, finds that the volatile trip storage area is empty or the status snapshot summary has expired (e.g., due to the volatile data being cleared after the on-board digital tag loses power and restarts), then the roadside unit executes a degraded reading strategy: it initiates a real-time status query request to the central system, re-acquires the billing rule set based on the current time, generates a new status snapshot summary, and writes it into the volatile trip storage area. This degraded reading strategy ensures that even under extreme abnormal conditions, subsequent billing nodes can still obtain a valid billing rule base. Simultaneously, the data integrity of the volatile trip storage area is restored through a rewrite operation, enabling subsequent billing gantry to continue version comparison using the on-board tag as the carrier.

[0103] In some embodiments, after extracting the version number of the billing rule set, the roadside unit temporarily stores each extracted version number in a local memory buffer and simultaneously records the timestamp of this read operation and the identification identifier of the vehicle-mounted digital tag, forming a read log. The read log is uploaded to the central system along with the transaction log.

[0104] S221: The roadside unit collects the static physical feature identifier of the vehicle and generates the current hash value. It compares the current hash value with the hash value associated with and bound in the status snapshot summary. If the comparison is inconsistent, it triggers an identity anomaly warning and terminates the billing transaction. Optionally, when a vehicle passes through the toll gantry, the roadside unit synchronously triggers a vehicle feature acquisition module (e.g., LiDAR, structured light sensor, or high-definition industrial camera) deployed on the gantry to perform non-contact scanning or image acquisition of the passing vehicle, extracting the static physical feature identifier of the current vehicle. The roadside unit performs the same standardization processing on the extracted static physical feature identifier of the current vehicle as in S212 (e.g., unifying dimensions, removing noise points, and normalizing size data), and uses the same preset hash algorithm and algorithm parameters as in S212 to generate the current hash value. The current hash value is an instant verification identifier used for identity comparison, obtained by hashing the physical features of the actual passing vehicle at the current moment.

[0105] Optionally, while generating the current hash value, the roadside unit also parses and extracts the hash value of the vehicle static physical feature identifier associated with and bound in S212 from the data structure of the state snapshot digest. Specifically, if a cascaded hashing method is used to generate a composite state snapshot digest in S212, the roadside unit reverse-parses the embedded or cascaded hash value of the vehicle static physical feature identifier from the composite state snapshot digest; if the hash value of the vehicle static physical feature identifier is stored as an additional field alongside the state snapshot digest in key-value pair form in S212, the roadside unit directly reads it from the corresponding key-value field of the volatile travel storage area. The roadside unit compares the current hash value with the parsed and extracted associated hash value bit by bit.

[0106] In some embodiments, if the current hash value is completely consistent with the associated hash value, the roadside unit determines that the currently passing vehicle and the physical vehicle bound when entering the first billing gantry are the same entity, the identity consistency verification passes, and the roadside unit continues to execute the subsequent billing rule set version comparison and billing transaction process. If there is any difference between the current hash value and the associated hash value, the roadside unit determines that the identity is inconsistent, immediately triggers an identity anomaly warning, and terminates the billing transaction.

[0107] Optionally, the termination of the billing transaction means that, after determining that the identity is inconsistent, the roadside unit refuses to perform any comparison of the billing rule set version based on the state snapshot summary, refuses to call the locally cached billing rule set for billing calculation, refuses to generate a normal billing transaction record, and returns a transaction rejection response to the vehicle-mounted digital tag. The transaction rejection response informs the vehicle-mounted digital tag that the current transaction has been terminated due to identity verification failure. The volatile trip storage area of ​​the vehicle-mounted digital tag is not modified or cleared during this abnormal transaction to maintain the integrity of the abnormal site data for subsequent manual verification. Simultaneously, the roadside unit guides the vehicle away from the automated transaction lane for handling by on-site management personnel or subsequent manual toll collection lanes.

[0108] In some embodiments, if the roadside unit finds that the associated hash value is not stored in the volatile trip storage area during the comparison process (e.g., due to data frame corruption or illegal deletion), it directly determines that the identity verification has failed, triggers an identity anomaly warning and terminates the billing transaction, and reports an abnormal event of missing binding data to the central system. The central system then decides whether to allow the transaction to be downgraded or to force manual verification based on the historical trip records and account status of the tag.

[0109] Optionally, S200 also includes S250 during the process of performing identity consistency verification and version comparison.

[0110] S250: After performing identity consistency verification, the roadside unit also compares whether the OBU code carried by the vehicle digital tag is consistent with the OBU code read by the roadside unit through the microwave communication unit. If they are inconsistent, an equipment abnormality alarm is triggered and the billing transaction is terminated.

[0111] S222: The roadside unit reads the version number of the locally cached billing rule set, compares the version number of the billing rule set in the status snapshot summary with the version number of the locally cached billing rule set, and outputs a comparison result indicating whether the versions are consistent or inconsistent.

[0112] In some embodiments, the locally cached billing rule set refers to the set of billing rule parameters that the roadside unit has obtained from the central system through a background synchronization mechanism and stored in the local non-volatile storage medium before the vehicle arrives. It includes at least vehicle type classification parameters, discount strategy parameters, and rate table parameters, and each parameter item carries a corresponding version number identifier.

[0113] Optionally, the roadside unit compares the version number of the billing rule set in the state snapshot summary in S220 with the version number of the locally cached billing rule set item by item. Specifically, it compares the vehicle classification version number, discount strategy version number, and rate table version number separately: if all three version numbers are completely identical, the roadside unit outputs a version-consistent comparison result; if any of the three version numbers differs, the roadside unit outputs a version-inconsistent comparison result. This item-by-item comparison strategy can accurately locate the specific billing rule parameter item category where version drift has occurred.

[0114] In some embodiments, if the roadside unit outputs a matching comparison result, the billing rule set parameters (vehicle type classification standard, discount strategy, rate table) stored in the local cache unit are directly called to perform billing calculations on the current vehicle, generating a transaction record containing the local billing amount, and uploading the transaction record to the central system. Since the local cache version is consistent with the baseline version of the state snapshot summary, this transaction record does not generate any data items to be compensated, and the central system can directly confirm the validity of this transaction segment during the full-trip consistency verification.

[0115] In some embodiments, if the roadside unit outputs a comparison result that is inconsistent with the version, the direct invocation of the locally cached billing rule set for billing calculation is suspended, and the backtracking calibration process described in S201-S202 is executed instead.

[0116] Preferably, after the consistency verification and difference compensation in S300 are completed, S311-S312 are also included.

[0117] S311: The exit roadside unit sends a trip end command to the vehicle-mounted digital tag, the trip end command carrying the trip session identifier of this trip; In some embodiments, when a vehicle exits a toll road section, although the central system has completed the full-trip consistency verification and difference compensation, the volatile trip storage area of ​​the on-board digital tag still retains trip-level temporary data such as the status snapshot summary, the integrity check code, and the trip session identifier for this trip. If such temporary data is not cleared in time, it may lead to the following problems: First, if the vehicle subsequently re-enters the toll road section, the roadside unit of the subsequent billing gantry may misread the residual old status snapshot summary, incorrectly binding the billing basis of the new trip to the historical billing rule version, resulting in confusion in the billing logic of the new trip; Second, the storage capacity of the volatile trip storage area is limited, and the long-term residue of historical trip data will occupy effective storage space, affecting the reliability of writing new trip data; Third, the residual status snapshot summary is associated with the hash value of the vehicle's static physical feature identifier, which, if illegally read, may expose the vehicle's historical passage feature information. Therefore, after the central system confirms the completion of consistency verification and difference compensation, the exit roadside unit needs to send a trip end command to the vehicle-mounted digital tag to trigger the vehicle-mounted digital tag to perform a trip-level temporary data clearing operation, thereby realizing the formal closure of this trip.

[0118] Optionally, the trip end command refers to a control frame sent by the exit roadside unit to the vehicle-mounted digital tag via the microwave communication unit, used to declare the formal termination of the current trip and request the clearing of trip-level temporary data in the volatile trip storage area. The trip end command is an application-layer control command in the communication protocol between the roadside unit and the vehicle-mounted digital tag, distinct from conventional data read / write commands. Its command type code is defined as the control category with the highest priority, ensuring that it can be preferentially received and processed by the vehicle-mounted digital tag before the vehicle leaves the microwave communication coverage area of ​​the exit toll gantry.

[0119] Optionally, the trip end command carries a trip session identifier for this trip. This trip session identifier, generated in S211 by the roadside unit of the first tolling gantry, remains unique within this trip and is used to associate all transaction records and data items to be compensated generated by the same vehicle passing through each tolling gantry. When the exit roadside unit sends the trip end command, it embeds the trip session identifier into a preset field position in the command payload, enabling the on-board digital tag to confirm which trip data stored in the current volatile trip storage area the command targets, preventing erroneous deletion of historical trip data in scenarios of rapid continuous vehicle passage or communication failure retransmission.

[0120] In some embodiments, before sending the trip end command, the exit roadside unit first confirms that the central system has returned a confirmation response indicating that the full trip consistency verification and difference compensation have been completed. Only after confirming that the full trip billing data loop has been completed will the exit roadside unit send the trip end command, avoiding the central system's inability to obtain the status snapshot summary or the trip session identifier during the full trip consistency verification phase due to prematurely clearing trip data. If the vehicle has left the microwave communication coverage area while the exit roadside unit is waiting for the central system's confirmation response, the exit roadside unit delegates the triggering logic of the trip end command to the local timeout mechanism of the vehicle-mounted digital tag: after the vehicle-mounted digital tag writes data to the volatile trip storage area, it starts an internal timer. If the trip end command is not received after exceeding a preset maximum trip duration threshold (e.g., 24 hours), the trip is automatically determined to have terminated abnormally and the volatile trip storage area is automatically cleared.

[0121] S312: The vehicle-mounted digital tag receives the trip end command, clears the status snapshot summary in the volatile trip storage area according to the trip session identifier, and returns a clear confirmation response to the exit roadside unit.

[0122] In some embodiments, when a vehicle exits a toll road section, the on-board digital tag establishes a communication link with the exit roadside unit via its built-in microwave communication unit and receives a trip end command sent by the exit roadside unit. Since the on-board digital tag is in a low-power standby state during vehicle operation and is only awakened and activated when entering the microwave communication coverage area of ​​the roadside unit, the on-board digital tag is in a receptive state when the vehicle passes the exit toll gantry. The on-board digital tag parses the data frame structure of the trip end command and extracts the trip session identifier from the command payload.

[0123] Optionally, after extracting the trip session identifier, the vehicle-mounted digital tag does not immediately perform a full clear operation. Instead, it first compares the extracted trip session identifier with the currently stored trip session identifiers in the volatile trip storage area. This comparison aims to prevent accidental clearing caused by communication protocol retransmission mechanisms, rapid continuous vehicle passage, or malicious command injection. If the extracted trip session identifier matches the trip session identifier in the volatile trip storage area, it is confirmed that the trip end command targets a currently valid trip, and the vehicle-mounted digital tag continues the clearing operation. If the comparison is inconsistent (e.g., there is no data in the volatile trip storage area or it stores historically abnormal session identifiers), the vehicle-mounted digital tag refuses to perform the clearing and returns a clearing failure response to the exit roadside unit. The clearing failure response carries a failure reason identifier, which the exit roadside unit uses to determine whether to retry or report the anomaly.

[0124] Optionally, the clearing operation refers to the data erasure operation performed by the storage controller of the vehicle digital tag on the volatile trip storage area. The specific objects of the clearing operation include at least: the status snapshot summary, the integrity check code, the trip session identifier, and the hash value of the vehicle static physical feature identifier associated with and bound in S212. After the clearing operation is completed, the volatile trip storage area is restored to a blank initialization state, awaiting the next trip data write.

[0125] In some embodiments, if the vehicle-mounted digital tag loses power due to vehicle shutdown, tag battery depletion, or abnormal power failure before receiving the trip end command, the volatile trip storage area, relying on the physical characteristics of volatile storage media (such as SRAM or DRAM requiring continuous power to maintain data), automatically loses all data after power loss, achieving automatic failure clearing at the physical level. This automatic failure clearing mechanism, together with the active clearing mechanism triggered by the trip end command, provides dual protection: under normal circumstances, the active clearing triggered by the trip end command ensures the integrity of the data loop; in abnormal power failure scenarios, physical characteristics ensure that data will not remain in the volatile storage medium for a long time, avoiding interference of the intermediate trip state with regular account information.

[0126] In some embodiments, after the vehicle-mounted digital tag completes the clearing operation, the clearing confirmation response returned to the exit roadside unit also includes the current status identifier of the volatile trip storage area, so that the exit roadside unit can confirm that the clearing operation has actually taken effect rather than just being received as an instruction.

[0127] Preferably, the present invention also provides a traffic free-flow tolling system based on state snapshots, the system comprising: A vehicle-mounted digital tag is installed in a vehicle. The vehicle-mounted digital tag includes a volatile trip storage area and a persistent storage area, which are isolated from each other in a physical storage layer. A roadside unit, deployed on a billing gantry, includes a local cache unit and a microwave communication unit; The central system communicates with each roadside unit via a wired or wireless communication network; The vehicle-mounted digital tag, the roadside unit, and the central system work together to execute the traffic free-flow tolling method based on state snapshots as described above.

[0128] It should be noted that the roadside unit includes a local caching unit and a microwave communication unit, which is a general description of the core communication and caching functions of the roadside unit. In actual deployment, the vehicle feature acquisition module can be independently configured on the billing gantry as an external collaborative module of the roadside unit and communicate with the roadside unit via wired or wireless means; alternatively, the vehicle feature acquisition module can also be integrated into the roadside unit, packaged together with the local caching unit and the microwave communication unit in the same physical device. Regardless of the deployment method, the static physical feature identifiers of vehicles collected by the vehicle feature acquisition module are input to the edge computing processing unit of the roadside unit for hash calculation and identity consistency verification, and its functional implementation is covered within the protection scope of this invention.

[0129] Therefore, the embodiments should be considered as exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of the equivalents of the application are intended to be included within the invention.

[0130] 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 traffic free-flow tolling method based on state snapshots, applied to a road segment containing several tolling gantries equipped with roadside units, each roadside unit being communicatively connected to a central system, characterized in that, Includes the following steps: When a vehicle enters the first billing gantry, the roadside unit communicates with the on-board digital tag, requests a billing rule set from the central system, generates a status snapshot summary, and writes it into the volatile travel storage area of ​​the on-board digital tag. When the vehicle passes through the subsequent billing gantry, the roadside unit reads the status snapshot summary and compares the version number of the billing rule set with the version number of the billing rule set cached locally. If they match, billing will be based on the locally cached billing rule set, and a transaction log will be generated and uploaded. If there is a discrepancy, request the status incremental change log from the central system and backtrack the calibration billing data to obtain the calibrated billing amount. Mark the difference between the calibrated billing amount and the billing amount calculated based on the locally cached billing rule set as a data item to be compensated and generate a transaction log for uploading. When the vehicle leaves the toll road section, the exit roadside unit reads the status snapshot summary and uploads it to the central system. The central system performs consistency verification and difference compensation on the vehicle's full-trip toll data based on the transaction data and data items to be compensated for each toll gantry, using the status snapshot summary as a benchmark.

2. The traffic free-flow tolling method based on state snapshots according to claim 1, characterized in that, The retrospective calibration billing data includes: The system requests an incremental state change log from the effective timestamp of the state snapshot summary to the central system. The incremental state change log includes change records for each billing rule parameter item, and the change record carries a change timestamp and parameter values ​​before and after the change. The roadside unit performs segmented back-calculation of the vehicle's current billing data based on the change timestamp and the parameter values ​​before and after the change, to obtain the calibrated billing amount.

3. The traffic free-flow tolling method based on state snapshots according to claim 1, characterized in that, The billing rule set includes vehicle type classification version number, discount strategy version number, and rate table version number; The generated state snapshot summary includes: Based on the vehicle type classification version number, the discount strategy version number, the rate table version number, and the effective timestamp of the billing rule set, a status snapshot summary is generated using a preset hash algorithm, and a unique trip session identifier is assigned to this trip. The roadside unit collects the static physical feature identifiers of the vehicle, and associates and binds the hash value of the vehicle's static physical feature identifiers with the state snapshot digest, so that the state snapshot digest uniquely corresponds to the physical identity of the vehicle.

4. The traffic free-flow tolling method based on state snapshots according to claim 1, characterized in that, The vehicle-mounted digital tag includes a volatile trip storage area and a persistent storage area, which are physically isolated from each other. A status snapshot digest is written to the volatile trip storage area. The status snapshot digest is automatically deleted after the vehicle trip ends or the vehicle-mounted digital tag loses power. Furthermore, data read / write operations on the volatile trip storage area do not affect the regular account information in the persistent storage area. The tag also includes: When the roadside unit writes the status snapshot summary into the volatile travel storage area, it simultaneously generates an integrity check code for the status snapshot summary and writes it into the volatile travel storage area as well. When reading the status snapshot digest, the roadside unit first verifies the integrity check code. Only after the verification is successful will the comparison be performed. If the verification fails, the status snapshot digest will be rejected and an abnormal alarm will be triggered.

5. The traffic free-flow tolling method based on state snapshots according to claim 1, characterized in that, The request for a billing rule set from the central system includes: The roadside unit initiates a real-time status query request for the vehicle-mounted digital tag to the central system. The real-time status query request carries the identification and communication link authentication information of the vehicle-mounted digital tag. The central system receives the real-time status query request, verifies the communication link authentication information, and returns the currently effective billing rule set to the roadside unit based on the identity identifier after the verification is successful.

6. The traffic free-flow tolling method based on state snapshots according to claim 1, characterized in that, The data items to be compensated include the billing difference, the current billing gantry number, and the version difference identifier of the billing rule set; the roadside unit associates and encapsulates the data items to be compensated and attaches them to the flow chart before uploading them to the central system.

7. The traffic free-flow tolling method based on state snapshots according to claim 1 or 6, characterized in that, The central system performs consistency verification and difference compensation on the vehicle's full-trip billing data based on the flow and data items to be compensated for at each billing gantry, using the status snapshot summary as a benchmark. This includes: The central system receives the status snapshot summary uploaded by the exit roadside unit, extracts the transaction data and data items to be compensated uploaded by each billing gantry within the same trip, and recalculates each transaction data based on the billing rule set corresponding to the status snapshot summary to obtain the recalculated billing amount. The difference between the recalculated billing amount and the billing amount in the corresponding transaction log is summarized as the trip difference. Based on the segment operation entity identifier corresponding to each billing gantry, the trip difference is decomposed into the difference to be cleared for each operation entity according to the segment ownership, and the difference clearing and settlement are performed separately.

8. The traffic free-flow tolling method based on state snapshots according to claim 3, characterized in that, When the vehicle passes the subsequent billing gantry, the roadside unit reads the status snapshot summary and performs identity consistency verification and version comparison, including: The roadside unit first reads the state snapshot summary in the volatile travel storage area and extracts the version number of the billing rule set in the state snapshot summary; The roadside unit collects the static physical feature identifier of the vehicle and generates a current hash value. It compares the current hash value with the hash value associated with the state snapshot summary. If the comparison is inconsistent, it triggers an identity anomaly warning and terminates the billing transaction. The roadside unit reads the version number of the locally cached billing rule set, compares the version number of the billing rule set in the status snapshot summary with the version number of the locally cached billing rule set, and outputs a comparison result indicating whether the versions are consistent or inconsistent.

9. The traffic free-flow tolling method based on state snapshots according to claim 3, characterized in that, After the consistency verification and difference compensation are completed, the following steps are also included: The exit roadside unit sends a trip end command to the vehicle-mounted digital tag, and the trip end command carries the trip session identifier of this trip; The vehicle-mounted digital tag receives the trip end command, clears the status snapshot summary in the volatile trip storage area according to the trip session identifier, and returns a clear confirmation response to the exit roadside unit.

10. A traffic free-flow tolling system based on state snapshots, characterized in that, The system includes: A vehicle-mounted digital tag is installed in a vehicle. The vehicle-mounted digital tag includes a volatile trip storage area and a persistent storage area, which are physically isolated from each other. A roadside unit, deployed on a billing gantry, includes a local cache unit and a microwave communication unit; The central system communicates with each roadside unit via a wired or wireless communication network; The vehicle-mounted digital tag, the roadside unit, and the central system work together to execute the traffic free-flow tolling method based on state snapshots as described in any one of claims 1-9.

Images