An ETC online billing method and system based on cloud edge collaboration

Abstract

The application provides an ETC online billing method and system based on cloud edge cooperation, which comprises the following steps: a provincial center platform captures vehicle license plate data in real time, generates a real-time path sequence in combination with positioning data, and predicts at least one exit toll station through a path prediction model; based on the path sequence and the predicted exit, a real-time billing engine is called to pre-calculate the toll amount, a pre-calculation fee result package is generated and distributed to the edge server cache of the corresponding exit; when the vehicle arrives at the exit, the lane terminal initiates a billing request to the edge server, if the cache retrieval is successful, the billing result is returned to complete the transaction, otherwise, the standby billing mode is switched to; after the transaction is completed, the edge server manages the cache data, and uploads the log and state data to the provincial center platform for whole-process monitoring. The application can improve the ETC exit passing efficiency, guarantee the billing consistency, realize the unified control of differentiated policies, and enhance the system fault tolerance.

Description

Technical Field

[0001] This invention relates to the field of intelligent toll collection technology for highways, and in particular to an ETC online tolling method and system based on cloud-edge collaboration. Background Technology

[0002] Since the full implementation of the project to eliminate provincial toll stations on expressways, my country's expressways have officially entered a new development stage of "unified network operation and integrated service." The national expressway network is vast and complex, with high-density and highly volatile traffic flow, placing unprecedented demands on the stability, accuracy, and real-time processing capabilities of the toll collection system. As a mainstream toll collection method for improving traffic efficiency and reducing operating costs, the accuracy and response speed of ETC (Electronic Toll Collection) billing directly affect user experience, toll fairness, and the overall operational efficiency of the road network.

[0003] Currently, the highway tolling system mainly consists of four modules: online tolling service, tolling module tolling, media-based tolling, and lane-based last-resort tolling. Among these, online tolling service, as the core tolling method, is divided into provincial central platform tolling service and national central platform tolling service, responsible for calculating vehicle tolls in real time to ensure the accuracy and timeliness of toll information. Tolling module tolling relies on ETC gantries and toll station virtual gantries for path identification and segmented tolling; media-based tolling relies on gantry information recorded in OBU or CPC cards to calculate exit tolls; and lane-based last-resort tolling serves as a final line of defense, charging according to the national minimum toll table when online tolling fails, ensuring that the toll floor is not breached.

[0004] However, in actual operation, the existing ETC billing model still faces many technical bottlenecks. First, traditional online billing adopts a synchronous interactive mode of "exit request - center response." When a vehicle exits the toll station, it needs to send a billing request to the provincial central platform in real time, relying on the central platform to complete route reconstruction, toll calculation, and return the result. During peak hours, network latency and central computing pressure can easily lead to transaction response timeouts, forcing vehicles to slow down or even reverse, seriously affecting the original design intent of ETC's "non-stop passage" and lane efficiency. Second, the accuracy of billing is difficult to guarantee in ambiguous path environments. When a vehicle passes through multiple ETC gantries, there is a risk of delay or packet loss in the uploading of gantry identification data to the backend, resulting in incomplete route reconstruction at the exit billing, which in turn leads to billing errors or user disputes. Third, the mechanism for handling differentiated toll policies is fragmented and rigid. Differentiated discounts for different vehicle types, time periods, road sections, or specific users (such as ETC discounts, interval discounts, and free passage on holidays) need to be configured and maintained separately in multiple systems. When policies are adjusted, it is difficult to ensure the uniformity and real-time implementation across the entire road network, resulting in high maintenance costs and a high risk of errors. Finally, the existing system has shortcomings in fault tolerance. When the central billing service or communication network fails, the lane system is forced to degrade to use a fallback toll meter for charging. While this ensures vehicle passage, it sacrifices billing accuracy, resulting in toll revenue loss or user complaints, and affecting toll fairness and road network revenue. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide an online ETC billing method and system based on cloud-edge collaboration to solve the problems of low passage efficiency due to exit response delays, billing disputes caused by incomplete path restoration, difficulty in unified management of decentralized configuration of differentiated policies, and loss of toll fees due to degraded billing when the center fails, which are caused by the centralized synchronous response mode of the existing ETC billing system.

[0006] On the one hand, the present invention provides an online ETC billing method based on cloud-edge collaboration, the method comprising: During the vehicle's journey, the provincial center platform captures the vehicle license plate recognition data uploaded by the ETC gantry in real time, and combines it with the vehicle positioning data to generate a real-time vehicle path sequence. Based on the real-time vehicle path sequence, the platform uses a path prediction model to predict at least one predicted exit toll station that the vehicle is most likely to exit, and generates a predicted exit list. Based on the vehicle's real-time path sequence and the predicted exit list, the provincial central platform calls the real-time tolling engine, combines unified toll rate parameters and a differentiated policy rule base, pre-calculates the toll amount for the vehicle traveling from its current location to each predicted exit toll station, and generates a pre-calculated toll result package; the pre-calculated toll result package is then distributed to the edge server of the corresponding predicted exit toll station for local caching. When a vehicle arrives at the exit toll station, the lane terminal initiates a billing request to the edge server of the toll station. The edge server retrieves the pre-calculated fee result package for the vehicle from its local cache. If the pre-calculated fee result package is found, the billing result is returned, and the lane terminal uses the billing result to complete the deduction transaction. If the result is not found or the retrieval fails, the lane terminal switches to the backup billing mode to complete the transaction. After the transaction is completed, the edge server manages the local cached data and uploads the request logs and cache status data to the provincial center platform. The provincial center platform monitors the entire process of distribution, retrieval, and cleanup.

[0007] In some embodiments of the present invention, the path prediction model predicts the predicted exit list based on vehicle historical driving trajectories, road network topology, and real-time traffic flow data using a deep learning algorithm.

[0008] In some embodiments of the present invention, the vehicle positioning data includes BeiDou satellite positioning data, and the real-time vehicle path sequence is generated by the provincial center platform by fusing ETC gantry identification data and the BeiDou positioning data and performing real-time correction and calibration.

[0009] In some embodiments of the present invention, the differentiated policy rule base is a configurable unified rule base integrated into the real-time billing engine, used to encapsulate differentiated charging policies for different vehicle types, time periods, road sections or users, so as to realize unified policy updates and synchronous execution.

[0010] In some embodiments of the present invention, the standby billing mode includes at least one of the following: The system can initiate a real-time online billing request to the provincial central platform, call the lane's local billing module to perform billing, or charge according to the national minimum toll table.

[0011] In some embodiments of the present invention, the edge server manages locally cached data, including: Immediately after a successful transaction, clear or mark the vehicle's cached data. For cached data that has not been consumed after being distributed for a preset period of time, it will be cleaned up periodically according to the preset cache lifespan.

[0012] In some embodiments of the present invention, the provincial center platform monitors the entire process of distribution, retrieval, and cleanup, including: Real-time analysis of path prediction accuracy, pre-calculated fee result package distribution success rate, local cache retrieval success rate, and lane transaction success rate; When the monitored indicators exceed the preset threshold, an early warning message is generated and remote manual intervention is supported.

[0013] In some embodiments of the present invention, the pre-calculated fee result package includes vehicle identifier, predicted exit identifier, corresponding fee amount, and timestamp information.

[0014] On the other hand, the present invention also provides an ETC online billing system based on cloud-edge collaboration, the system being used to perform the steps of any of the methods mentioned above, the system comprising: Provincial central platform; Edge servers are deployed at toll booths; Lane terminals are deployed at ETC exit lanes.

[0015] On the other hand, the present invention also provides a computer-readable storage medium having a computer program / instructions stored thereon, characterized in that the computer program / instructions, when executed by a processor, implement the steps of any of the methods mentioned above.

[0016] This invention achieves significant technological progress by constructing a cloud-edge collaborative architecture of "global prediction and distribution in the cloud and real-time local response at the edge".

[0017] While a vehicle is en route, the provincial central platform predicts the exit and pre-calculates the toll amount, distributing the results to edge servers for caching. Exit lanes retrieve the toll calculation results locally within milliseconds, completely eliminating the impact of network latency and ensuring that ETC vehicles can pass through quickly without stopping, greatly improving lane throughput.

[0018] This invention achieves consistent management of billing rules across the entire road network by using unified rate parameters and a configurable, differentiated policy rule base. All fee calculations are completed by the provincial center based on the unified rule base, eliminating billing discrepancies at the source. Policy adjustments only require a single update in the cloud, which is then automatically applied to subsequent pre-calculations, completely resolving the problems of inconsistent policy implementation and high operation and maintenance costs under traditional decentralized configurations.

[0019] This invention designs a multi-level fault-tolerance mechanism. When edge cache retrieval fails, the lane terminal automatically and seamlessly switches to the backup billing mode, ensuring uninterrupted passage under any abnormal conditions. Simultaneously, intelligent cache management combining transaction-based cleanup and timeout-based cleanup ensures lightweight edge storage.

[0020] This invention constructs a visual monitoring system covering the entire process of "distribution-retrieval-cleaning", analyzes and predicts key indicators such as accuracy and cache retrieval success rate in real time, automatically issues warnings when anomalies occur and supports remote intervention, and provides data support for continuous system optimization.

[0021] Additional advantages, objects, and features of the invention will be set forth in part in the description which follows, and will also become apparent in part to those skilled in the art upon studying the description, or may be learned by practice of the invention. The objects and other advantages of the invention can be realized and obtained by means of the structures specifically pointed out in the description and drawings.

[0022] Those skilled in the art will understand that the objectives and advantages achievable with the present invention are not limited to those specifically described above, and that the above and other objectives achievable with the present invention will become clearer from the following detailed description. Attached Figure Description

[0023] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, are not intended to limit the scope of the invention. In the drawings: Figure 1 This is a schematic diagram of the steps of an ETC online billing method based on cloud-edge collaboration in one embodiment of the present invention.

[0024] Figure 2 This is a flowchart illustrating an embodiment of the ETC online billing method based on cloud-edge collaboration according to the present invention. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the embodiments and accompanying drawings. Here, the illustrative embodiments and descriptions of this invention are used to explain the invention, but are not intended to limit the invention.

[0026] It should also be noted that, in order to avoid obscuring the invention with unnecessary details, only the structures and / or processing steps closely related to the solution according to the invention are shown in the accompanying drawings, while other details that are not closely related to the invention are omitted.

[0027] It should be emphasized that the term "including / comprises" as used herein refers to the presence of a feature, element, step, or component, but does not exclude the presence or addition of one or more other features, elements, steps, or components.

[0028] It should also be noted that, unless otherwise specified, the term "connection" in this article can refer not only to a direct connection, but also to an indirect connection involving an intermediary.

[0029] In the following description, embodiments of the invention will be illustrated with reference to the accompanying drawings. In the drawings, the same reference numerals represent the same or similar parts, or the same or similar steps.

[0030] It should be emphasized here that the step markers mentioned below are not a limitation on the order of the steps, but should be understood as meaning that the steps can be executed in the order mentioned in the embodiments, or in a different order than in the embodiments, or several steps can be executed simultaneously.

[0031] To address the problems of existing technologies, such as delayed exit response leading to low traffic efficiency, incomplete route reconstruction causing billing disputes, fragmented configuration of differentiated policies making unified management difficult, and toll revenue loss due to degraded billing during central system failures, this invention provides a cloud-edge collaborative online ETC billing method, such as... Figure 1 As shown, the method includes the following steps S101~S104: Step S101: During the vehicle's journey, the provincial center platform captures the vehicle license plate recognition data uploaded by the ETC gantry in real time, and combines it with the vehicle positioning data to generate a real-time vehicle path sequence; based on the real-time vehicle path sequence, the platform uses a path prediction model to predict at least one predicted exit toll station that the vehicle is most likely to exit, and generates a predicted exit list.

[0032] Step S102: Based on the real-time route sequence of the vehicle and the predicted exit list, the provincial center platform calls the real-time tolling engine, combines the unified toll rate parameters and the differentiated policy rule library, pre-calculates the toll amount for the vehicle to travel from the current location to each predicted exit toll station, and generates a pre-calculated toll result package; the pre-calculated toll result package is distributed to the edge server of the corresponding predicted exit toll station for local caching.

[0033] Step S103: When a vehicle arrives at the exit toll station, the lane terminal initiates a billing request to the edge server of the toll station. The edge server retrieves the pre-calculated fee result packet of the vehicle from its local cache. If the pre-calculated fee result packet is found, the billing result is returned, and the lane terminal uses the billing result to complete the deduction transaction. If the result is not found or the retrieval fails, the lane terminal switches to the backup billing mode to complete the transaction.

[0034] Step S104: After the transaction is completed, the edge server manages the local cached data and uploads the request logs and cache status data to the provincial center platform. The provincial center platform monitors the entire process of distribution, retrieval, and cleanup.

[0035] In step S101, vehicle trajectory capture and intelligent exit prediction are performed.

[0036] Step S101 aims to address the problems of incomplete path reconstruction and high instantaneous calculation pressure at exits in existing technologies. By capturing the vehicle's travel trajectory in real time during its journey and predicting possible exits from toll stations in advance, it achieves a shift from passively waiting for exit queries to proactively predicting on-the-go decisions, laying a data foundation for subsequent pre-calculation and pre-distribution of tolls.

[0037] Specifically, this step achieves two core functions: first, it generates an accurate real-time vehicle path sequence as a digital representation of the vehicle's trajectory; second, based on this path sequence, it outputs a list of predicted exits through an intelligent prediction model, which is one or more toll stations that the vehicle is most likely to exit at.

[0038] The provincial center platform is equipped with a real-time toll monitoring service. This service maintains a long-term connection with the entire road network's ETC gantry system, monitoring and capturing vehicle license plate data uploaded when vehicles pass through gantries in real time. Each piece of gantry license plate data includes at least the following core fields: unique vehicle identifier (such as the vehicle ID or CPC card number in the OBU), gantry number, and passage timestamp.

[0039] In some embodiments, the provincial center platform interfaces with the BeiDou satellite positioning system (or other satellite positioning systems) to acquire real-time BeiDou positioning data of vehicles equipped with BeiDou terminals as vehicle positioning data. This positioning data includes the vehicle's real-time latitude and longitude coordinates, instantaneous speed, direction of travel, and corresponding timestamp information.

[0040] In some embodiments, the provincial center platform sends the aforementioned real-time captured ETC gantry identification data and BeiDou positioning data to the path fusion service. This service performs data fusion and calibration according to the following logic: Using ETC gantry identification data as the main path nodes, a sequence of gantry passes through by vehicles is constructed.

[0041] BeiDou positioning data is used as a supplement to continuous trajectory data. BeiDou positioning data can provide continuous driving trajectories between two gantries, including information such as whether the vehicle stopped in a service area or drove an abnormal route. The path fusion service interpolates BeiDou trajectory points between gantry sequences through timestamp alignment, forming a more refined driving path.

[0042] The path fusion service performs real-time correction and calibration of the data. When gantry identification data is missing (e.g., a gantry fails to identify a vehicle), the gantry that the vehicle should have passed through can be inferred based on the BeiDou trajectory; when the BeiDou signal drifts, the positioning point can be corrected based on the gantry position. This two-way calibration mechanism ensures that the generated path data is accurate and reliable.

[0043] After data fusion and calibration, the path fusion service outputs the vehicle's real-time path sequence. This sequence represents the vehicle's complete travel path from the entrance to the current moment in the form of an ordered list.

[0044] The vehicle's real-time route sequence is stored in the Redis cluster of the provincial center platform, with the vehicle identifier as the key and the route sequence as the value. It supports millisecond-level read and write access, providing real-time data support for subsequent exit prediction and fee calculation.

[0045] The provincial center platform is equipped with a route prediction model, which takes the real-time vehicle route sequence generated in the previous step as input and triggers prediction calculations in real time.

[0046] In some embodiments, the path prediction model predicts the exit list based on historical vehicle trajectories, road network topology, and real-time traffic flow data using a deep learning algorithm.

[0047] The specific network structure of the path prediction model can adopt deep learning architectures suitable for sequence prediction, such as Long Short-Term Memory (LSTM) networks or Transformers. During the model training phase, massive amounts of historical traffic data are used to learn the implicit mapping relationship between the traveled paths and the final exit.

[0048] In actual prediction, the model is triggered to recalculate whenever a vehicle passes through a new ETC gantry, outputting an updated prediction result, which is presented in the form of a predicted exit list. In practical applications, one or more exits can be selected as the predicted exit list based on preset probability or quantity thresholds for subsequent toll pre-calculation and distribution.

[0049] In step S102, the real-time billing engine in the cloud center pre-calculates the precise toll amount for a vehicle traveling from its current location to each predicted exit based on unified rates and policy rules, generates a structured pre-calculated toll result package, and actively pushes it to the corresponding toll station edge server for local caching.

[0050] Step S102 aims to address the problems of high instantaneous computational pressure at exits and the difficulty in unified management of dispersed configurations of differentiated policies in existing technologies. Building upon the real-time vehicle path sequence and predicted exit list generated in step S101, this step achieves two core functions: first, it pre-calculates tolls, shifting the computational burden from exit lanes to the cloud; second, it proactively distributes the calculation results to edge nodes, laying the foundation for millisecond-level responses in subsequent exit lanes.

[0051] The provincial central platform is equipped with a real-time billing engine, which is the core computing unit for billing services across the province. After step S101 generates and updates the real-time vehicle route sequence and predicted exit list, the system automatically triggers the real-time billing engine to start the pre-calculation process, including: First, the pre-calculated input data is obtained. The vehicle's real-time path sequence is read from the Redis cluster. At least one predicted exit toll station is retrieved from the predicted exit list generated in step S101. The billing rules based on unified toll rate parameters and a differentiated policy rule base are then obtained. The unified toll rate parameter base is stored in a MySQL database and contains basic toll rate standards (e.g., yuan / km), vehicle type classification coefficients, bridge and tunnel surcharges, and other basic billing parameters for each section of the province's expressways. The differentiated policy rule base is a configurable unified rule base integrated into the real-time billing engine. It is used to encapsulate differentiated toll policies for different vehicle types, time periods, road sections, or users, such as ETC discounts, interval discounts, holiday toll exemptions, green channel vehicle exemptions, and discounts for specific user groups.

[0052] After obtaining the input data, the fee is pre-calculated according to the following logic: First, the road segments already traveled by the vehicle are determined based on the vehicle's real-time path sequence, and the expected route from the current location to the predicted exit is determined based on the vehicle's current location. This expected route can be determined based on a road network topology model, calculating the shortest or most probable path from the gantry to the exit.

[0053] Secondly, the sum of the toll for the completed road section and the toll for the road section to be traveled is calculated to obtain the total toll for the entire route from the entrance to the exit.

[0054] Secondly, the real-time billing engine calls upon the differentiated policy rule library to adapt the calculated base fee to the policy. For example, if the vehicle is an ETC user and the current time period is a discount period, the corresponding discount coefficient is applied; if the vehicle's travel route involves a specific discount range, the fee for that range is reduced or waived.

[0055] In some embodiments, the differentiated policy rule base is a configurable unified rule base integrated into the real-time billing engine. It encapsulates differentiated toll policies for different vehicle types, time periods, road segments, or users, enabling unified policy updates and synchronized execution. This ensures the uniformity of policy execution across the entire road network. When rates or policies are adjusted, only one update is needed in the cloud-based rule base; all subsequent vehicle pre-calculations will automatically adopt the new rules, completely resolving the issues of inconsistent policy execution and high maintenance costs inherent in traditional distributed configuration models.

[0056] After pre-calculating the toll amount for each predicted exit, the real-time tolling engine generates the corresponding pre-calculated toll result. For the same vehicle, multiple pre-calculated toll results may be generated (corresponding to multiple predicted exits). These pre-calculated toll results are then encapsulated according to a predetermined data structure to generate a pre-calculated toll result package.

[0057] In some embodiments, the pre-calculated fee result package includes the following core fields: Vehicle identification: Used to uniquely identify a vehicle, such as OBU ID, CPC card number, or encrypted vehicle fingerprint information.

[0058] Predicted Exit Identifier: The corresponding predicted exit toll station number.

[0059] Corresponding fee amount: The final fee amount after adaptation to differentiated policies.

[0060] Timestamp information: The time point at which the fee is calculated, used for subsequent cache validity management and data consistency verification.

[0061] The provincial center platform is equipped with a billing result distribution strategy module, which is responsible for actively distributing the generated pre-calculated fee result package to the corresponding edge server.

[0062] For each predicted exit in the pre-calculated fee result package, the system determines the network address of the edge server corresponding to the toll station based on the exit identifier, and then pushes the pre-calculated fee result for that exit to the corresponding edge server separately through the dedicated network channel between the provincial center and the toll station.

[0063] In some embodiments, the distribution process can adopt an asynchronous non-blocking mode to ensure that the core calculation process of the real-time billing engine is not blocked when large-scale concurrent distribution is carried out. At the same time, the distribution module maintains a distribution status table to record the distribution status of each pre-calculated billing result (pending distribution, distributing in progress, successfully distributed, distribution failed). For records of distribution failure, the system automatically retries according to a preset retry strategy.

[0064] To ensure reliable data transmission, an acknowledgment mechanism is used between the distribution module and the edge server. After successfully receiving and storing the pre-calculated fee result, the edge server returns a receipt confirmation message to the provincial center; if the provincial center does not receive confirmation within the timeout period, the distribution is deemed to have failed and a retry is triggered.

[0065] Each toll station's edge server is equipped with a local high-speed caching system, preferably implemented using a Redis cluster.

[0066] In some embodiments, after the edge server receives the pre-calculated fee result package distributed by the provincial center, it performs local cache management according to the following logic: Parse the received pre-calculated fee result packet to extract information such as vehicle identifier, predicted exit identifier, fee amount, and timestamp.

[0067] Using the vehicle identifier as the key and the pre-calculated fee result package as the value, the data is written to the local Redis cache. To improve retrieval efficiency, a secondary index from the vehicle identifier to the exit identifier can be created simultaneously.

[0068] Set a preset time-to-live (TTL) for each cached data record. This TTL is dynamically adjusted based on the estimated arrival time predicted in step S101, and is typically set to "estimated arrival time + buffer duration". If the cached data is not consumed before the expiration date, it will be automatically cleaned up.

[0069] After the cache is successfully written, the edge server returns a receipt confirmation message to the provincial center platform, informing the provincial center that the distribution has been successfully completed.

[0070] In some embodiments, the pre-calculated fee result package generated in step S102 can also be tiered according to the predicted probability. For high-probability exits (e.g., probability > 50%), it can be distributed immediately and a longer cache time can be set; for low-probability exits, distribution can be delayed or a shorter cache time can be set to optimize network and storage resource utilization.

[0071] In step S103, the local interaction between the lane terminal and the edge server replaces the remote interaction with the provincial center platform in the traditional mode; at the same time, for abnormal scenarios such as cache not being retrieved or retrieval failure, a multi-level backup billing mode is preset to form a complete fault tolerance protection system.

[0072] Step S103 aims to address the core pain points of existing technologies, such as low traffic efficiency due to exit response delays and insufficient system fault tolerance. Building upon the pre-calculation of toll fees and the distribution of results to the local cache of edge servers in step S102, this step achieves two core functions: first, it utilizes the local cache of edge nodes to achieve millisecond-level tolling responses, ensuring ETC non-stop fast passage; second, it designs a tiered fault tolerance mechanism to ensure that lanes can still complete transactions under any abnormal circumstances, achieving high system availability.

[0073] When a vehicle arrives at the ETC exit toll lane, the lane antenna establishes communication with the on-board unit (OBU) or CPC card to obtain vehicle identification information. At this time, the lane terminal software no longer initiates a remote billing request to the provincial central platform in the traditional mode, but instead executes the upgraded local billing logic.

[0074] The lane terminal is pre-configured with the network address of the edge server of the toll station (usually a fixed IP or domain name within the same toll station's local area network). After obtaining the vehicle identification, the lane terminal immediately constructs a billing request message and sends the billing request to the edge server through the toll station's internal local area network (wired or wireless).

[0075] The edge server continuously listens for billing requests from each exit lane. Upon receiving a billing request from a lane terminal, the edge server immediately performs a retrieval operation in its local cache system.

[0076] In some embodiments, the local caching system is preferably implemented using a Redis cluster, which offers extremely high read and write performance. The retrieval logic is as follows: Using the vehicle identifier in the request message as the key, search the Redis cache to see if a corresponding pre-calculated fee result packet exists.

[0077] If a corresponding pre-calculated fee result package is retrieved, its validity is further verified, including checking whether the cache has expired and whether the fee data is complete. If the verification passes, it is considered a "retrieval successful". If no corresponding key is retrieved, or the retrieved result package has expired or the data is incomplete, it is considered a "retrieval failed".

[0078] If the retrieval is successful, the edge server reads the pre-calculated fee result packet from the cache, extracts the fee information for the current exit toll station, constructs a billing response message, and returns it to the lane terminal within milliseconds. The response message includes information such as the billing result status (success), fee amount, and fee calculation timestamp. If the retrieval fails, the edge server constructs a retrieval failure response message and returns it to the lane terminal, informing it that there are no available billing results in the local cache.

[0079] In some embodiments, after receiving the billing response from the edge server, the lane terminal performs transaction deduction according to the following logic: If the pre-calculated fee result package is retrieved: Parse the billing response message returned by the edge server to obtain the amount payable for this transaction.

[0080] The lane terminal confirms the transaction with the on-board unit (OBU) and completes the issuance and confirmation of the toll deduction instruction through Dedicated Short Range Communication (DSRC) technology.

[0081] After successful payment, the lane controller raises the barrier, and the lane indicator light turns green, indicating that the vehicle can proceed. The lane display screen simultaneously shows the transaction amount for the driver's confirmation.

[0082] The lane terminal temporarily stores the complete record of this transaction (including vehicle identification, transaction time, fee amount, cache retrieval success indicator, etc.) locally and asynchronously uploads it to the edge server and the provincial center platform for subsequent reconciliation, auditing and statistical analysis.

[0083] If the lane terminal receives a response indicating a retrieval failure, or if the request times out or a network error causes the retrieval to fail, the preset backup billing mode will be triggered immediately to ensure uninterrupted lane passage.

[0084] In some embodiments, the standby billing mode includes: Initiate a real-time online billing request to the provincial central platform, call the lane's local billing module to perform billing, or charge according to the national minimum toll table.

[0085] In some embodiments, the switching logic of the standby billing mode adopts a preset hierarchical strategy, and the switching between each level of mode is automatically completed by the lane terminal without manual intervention, ensuring traffic continuity.

[0086] In step S104, the lifecycle management of cached data is achieved through a dual mechanism of "cleaning upon transaction + cleaning upon timeout". At the same time, by uploading request logs and cache status data in real time, the provincial center platform can monitor the entire process of "distribution-retrieval-cleaning" in a panoramic way, providing data support for system optimization and operation and maintenance.

[0087] Step S104 aims to address the problems of wasted storage resources due to invalid accumulation of edge cache data and operational difficulties caused by the lack of end-to-end visualized management in existing technologies. Building upon the lane transaction completed in step S103, this step achieves two core functions: first, intelligently cleaning up the local cache of the edge server to ensure the lightweight and effectiveness of cached data; second, transmitting the end-to-end operational status data back to the provincial center platform to build a visualized monitoring system, enabling observability, management, and optimization of the cloud-edge collaborative billing system.

[0088] The edge server manages local cached data using a dual mechanism of "active cleanup + passive expiration" to ensure that cached data can meet normal transaction needs without occupying storage resources indefinitely.

[0089] In some embodiments, after a successful transaction, the edge server processes the vehicle's locally cached data according to a preset strategy, including: For vehicles that have already been successfully transacted, the edge server directly removes the pre-calculated fee result package for that vehicle from its local cache. This method is suitable for scenarios with high prediction accuracy and can free up storage space most quickly.

[0090] The edge server does not immediately delete cached data, but instead marks it as consumed, retaining it for a period of time. This approach is suitable when a vehicle transaction may need to be re-transaction due to abnormal circumstances (such as transaction failure and rollback), and retaining the marked data facilitates retries; or it can be used for subsequent auditing and reconciliation. The marked data is automatically cleared after a preset time.

[0091] For cached data that has been distributed to edge servers but has not been consumed by any vehicle transactions, the edge servers perform periodic cleanup according to a preset cache lifetime. The cache lifetime can be determined based on a combination of factors, including the predicted arrival time of the exit point, the predicted probability, and the system's default policy.

[0092] In some embodiments, the cache management strategy of the edge server can be dynamically adjusted according to its operating status. For example, when the cache utilization rate reaches a warning threshold (such as 80%), the edge server can proactively trigger a cleanup mechanism to prioritize the cleanup of cached data that is about to expire or has a low predicted probability, ensuring the continuity of core business operations.

[0093] In some embodiments, the edge server periodically analyzes the cached data, calculates the cache retrieval success rate of each predicted exit, and uploads the analysis results to the provincial center platform to optimize subsequent distribution strategies and TTL settings.

[0094] After the transaction is completed, the edge server uploads request log data and cache status data to the provincial center platform. The request log data includes basic information, processing results, billing information, performance metrics, and anomaly information. The cache status data includes retrieval success rate statistics, cleanup statistics, anomaly statistics, and hot data.

[0095] After receiving request logs and cache status data uploaded by various edge servers, the provincial center platform aggregates, analyzes, and visualizes them to build a monitoring system covering the entire process of "distribution-retrieval-cleaning".

[0096] In some embodiments, the provincial center platform monitors the entire process of distribution, retrieval, and cleanup, including real-time analysis of several core indicators: path prediction accuracy, pre-calculated fee result package distribution success rate, local cache retrieval success rate, and lane transaction success rate.

[0097] Path prediction accuracy measures the prediction performance of the path prediction model in step S101. Distribution success rate measures the completion of the distribution task from the provincial center to the edge server in step S102. Cache retrieval success rate is a core indicator for measuring cloud-edge collaboration efficiency. Transaction success rate measures the overall transaction completion rate of lane terminals.

[0098] The provincial center platform presents the above indicators in the form of a visual dashboard, supporting multi-dimensional drill-down analysis by time and space dimensions, providing operation and maintenance personnel with an intuitive and comprehensive view of system operation.

[0099] In some embodiments, when a monitoring indicator exceeds a preset threshold, the provincial center platform automatically generates an early warning and supports remote manual intervention. The provincial center platform can combine multi-dimensional data to conduct preliminary root cause analysis.

[0100] Corresponding to the above method, the present invention also provides an ETC online tolling system based on cloud-edge collaboration, used to perform the steps of implementing the ETC online tolling method based on cloud-edge collaboration, the system comprising: Provincial central platform; Edge servers are deployed at toll booths; Lane terminals are deployed at ETC exit lanes.

[0101] Corresponding to the above method, the present invention also provides an electronic device including a computer device, the computer device including a processor and a memory, the memory storing computer instructions, the processor executing the computer instructions stored in the memory, and when the computer instructions are executed by the processor, the electronic device performs the steps of the method as described above.

[0102] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the aforementioned method. The computer-readable storage medium may be a tangible storage medium, such as random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, register, floppy disk, hard disk, removable storage disk, CD-ROM, or any other form of storage medium known in the art.

[0103] Those skilled in the art will understand that the exemplary components, systems, and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software, or a combination of both. Whether implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this invention. When implemented in hardware, it can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this invention are programs or code segments used to perform the desired tasks. The programs or code segments can be stored in a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried in a carrier wave.

[0104] It should be clarified that the present invention is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of the present invention.

[0105] In this invention, features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, and / or combined with or in place of features of other embodiments.

[0106] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, various modifications and variations of the embodiments of the present invention are possible. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A cloud-edge collaborative online ETC billing method, characterized in that, The method includes: During the vehicle's journey, the provincial center platform captures the vehicle license plate recognition data uploaded by the ETC gantry in real time, and combines it with the vehicle positioning data to generate a real-time vehicle path sequence. Based on the real-time vehicle path sequence, the platform uses a path prediction model to predict at least one predicted exit toll station that the vehicle is most likely to exit, and generates a predicted exit list. Based on the vehicle's real-time path sequence and the predicted exit list, the provincial central platform calls the real-time tolling engine, combines unified toll rate parameters and a differentiated policy rule base, pre-calculates the toll amount for the vehicle traveling from its current location to each predicted exit toll station, and generates a pre-calculated toll result package; the pre-calculated toll result package is then distributed to the edge server of the corresponding predicted exit toll station for local caching. When a vehicle arrives at the exit toll station, the lane terminal initiates a billing request to the edge server of the toll station. The edge server retrieves the pre-calculated fee result package for the vehicle from its local cache. If the pre-calculated fee result package is found, the billing result is returned, and the lane terminal uses the billing result to complete the deduction transaction. If the result is not found or the retrieval fails, the lane terminal switches to the backup billing mode to complete the transaction. After the transaction is completed, the edge server manages the local cached data and uploads the request logs and cache status data to the provincial center platform. The provincial center platform monitors the entire process of distribution, retrieval, and cleanup.

2. The ETC online billing method based on cloud-edge collaboration according to claim 1, characterized in that, The path prediction model predicts the list of exits based on historical vehicle trajectories, road network topology, and real-time traffic flow data using a deep learning algorithm.

3. The ETC online billing method based on cloud-edge collaboration according to claim 1, characterized in that, The vehicle positioning data includes BeiDou satellite positioning data. The real-time vehicle route sequence is generated by the provincial center platform by fusing ETC gantry identification data and the BeiDou positioning data and performing real-time correction and calibration.

4. The ETC online billing method based on cloud-edge collaboration according to claim 1, characterized in that, The differentiated policy rule base is a configurable unified rule base integrated into the real-time billing engine. It is used to encapsulate differentiated charging policies for different vehicle types, time periods, road sections, or users, and to achieve unified policy updates and synchronous execution.

5. The ETC online billing method based on cloud-edge collaboration according to claim 1, characterized in that, The standby billing mode includes at least one of the following: The system can initiate a real-time online billing request to the provincial central platform, call the lane's local billing module to perform billing, or charge according to the national minimum toll table.

6. The ETC online billing method based on cloud-edge collaboration according to claim 1, characterized in that, The edge server manages locally cached data, including: Immediately after a successful transaction, clear or mark the vehicle's cached data. For cached data that has not been consumed after being distributed for a preset period of time, it will be cleaned up periodically according to the preset cache lifespan.

7. The ETC online billing method based on cloud-edge collaboration according to claim 1, characterized in that, The provincial center platform monitors the entire process of distribution, retrieval, and cleanup, including: Real-time analysis of path prediction accuracy, pre-calculated fee result package distribution success rate, local cache retrieval success rate, and lane transaction success rate; When the monitored indicators exceed the preset threshold, an early warning message is generated and remote manual intervention is supported.

8. The ETC online billing method based on cloud-edge collaboration according to claim 1, characterized in that, The pre-calculated fee result package includes vehicle identification, predicted exit identification, corresponding fee amount, and timestamp information.

9. An ETC online tolling system based on cloud-edge collaboration, characterized in that, The system is used to perform the steps of the method as described in any one of claims 1 to 8, the system comprising: Provincial central platform; Edge servers are deployed at toll booths; Lane terminals are deployed at ETC exit lanes.

10. A computer-readable storage medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method as described in any one of claims 1 to 8.

Images