Multi-element heterogeneous payment method for urban roadside parking ETC networking application

Abstract

The invention relates to the technical field of smart city Internet of Things, and discloses a multivariate heterogeneous payment method for urban roadside parking ETC networking application, a controller is utilized to read vehicle information through information interaction between a roadside unit (RSU) and an on-board unit (OBU), and data verification and fee deduction processing are performed through an SAAS system platform, so that on the basis of one-time OBU identification, on the basis of one-time on-board unit (OBU) identification, the vehicle information is read, and the payment efficiency is improved. The method is advantaged in that multiple non-inductive payment automatic fee deduction is supported, extra time delay of the ETC fee deduction process is not brought, the ETC fee deduction success rate of urban roadside parking is effectively improved, and work efficiency and accuracy are improved. A distributed lock mechanism is introduced to prevent repeated fee deduction, and meanwhile, a Kafka message queue is utilized to realize real-time updating of an order state, so that quick response of a payment system is ensured. Besides, multiple payment modes and payment sequence definitions, such as non-sensing of farming and non-sensing of construction, are supported, orders of different payment modes are processed through a heterogeneous payment worker, and the flexibility and expansibility of the system are improved. The order confirmation worker ensures the consistency and accuracy of order state processing, and prevents the ETC clearing record from being missed or expired. Through the comprehensive application of the technologies, the method effectively solves the technical problems in urban roadside parking charging, and improves the quality and efficiency of parking services.

Description

Technical Field

[0001] The present invention belongs to the technical field of smart city Internet of Things, and specifically relates to a multi-heterogeneous payment method for urban roadside parking ETC networking application. Background Art

[0002] In recent years, urban construction has been changing with each passing day, and the number of motor vehicles has increased rapidly. As a result, the problem of unpaid parking fees in cities has become obvious. Due to the open parking characteristics of the roads themselves, the parking and departure of vehicles are not restricted by external forces. Urban parking fee evasion has become a problem that affects the loss of operating income.

[0003] At present, the roadside parking management and charging model in most cities is still mainly based on handheld POS machines + manual charging. This model has a large workload, low efficiency, limited single-person management area, and large process loopholes, which leads to serious parking fee omissions and under-collection. Nowadays, most urban parking fee collection businesses have introduced the traditional ETC network identification and charging model to carry out the parking fee payment assistance function. However, due to the influence of many factors such as project network interaction, system delay, vehicle driving speed, and single ETC binding account, there are still problems such as low vehicle recognition rate, ETC network transaction failure, and untimely generation of user transaction bills, resulting in the ETC network application technology failing to maximize its role. Therefore, it is necessary to develop a method that can effectively solve the above problems and further improve the success rate of network charging. Summary of the invention

[0004] The present invention aims to solve the problems of low efficiency, strong dependence on manual work, low ETC recognition rate, etc. in the existing urban roadside parking management in the above-mentioned prior art. At the same time, user bills are delayed and abnormal situations such as insufficient balance or interrupted transaction process cannot be effectively handled. The lack of multi-payment support and data application value, as well as the lack of distributed processing mechanism, limit the system's high concurrency and distributed scene processing capabilities.

[0005] To achieve the above object, the present invention provides the following technical solutions: A multi-heterogeneous payment method for urban roadside parking ETC networking application, comprising the following steps: S1. When a vehicle passes through the ETC identification and deduction device, the controller identifies the vehicle's on-board unit (OBU) information through the roadside unit (RSU). The controller then accesses the application program interface (API) of the SAAS system platform to query the order information related to the license plate number. After performing data verification through the SAAS system platform, the controller completes the deduction through the interaction between the roadside unit (RSU) and the on-board unit (OBU); S2. The deduction result is sent to the SAAS server, and the SAAS writes the transaction order into the ETC order table; S3, based on the order library binlog log, pushes each data to the message queue Kafka message queue TopicA; S4. The payment worker subscribes to Topic A of Kafka and notifies the roadside smart city parking platform of the successful payment order status in a timely manner; S5. The heterogeneous payment worker subscribes to TopicA of Kafka. When there is a new order, the following fields are triggered: read_card_type, status; S6. Write the order information into the delayqueue worker module and set the expiration time to 50 seconds. At the same time, initiate the payment channel deduction logic for the order, and try to deduct the fees in sequence according to the payment order and the corresponding activation status of the vehicle, until one of the payment channels is successfully paid, and the payment record is written into the contactless payment table; The delayqueue worker implements the following logic: When the delayqueue worker receives order information, it hashes the order ID and groups it into 32 logical buckets (the number is adjusted according to the actual business volume). It selects the sortset data structure of the redis database for storage. It then starts the corresponding number of coroutines for the corresponding buckets, scans them every second, identifies the expired orders, and writes them to Topic B of Kafka. S7, the order confirmation worker subscribes to Kafka's Topic B for consumption, performs contactless payment record search and confirmation on the expired order, and marks the order as the corresponding status according to different situations, and writes it into the clearing table or cancellation status; S8, sending the data of the ETC clearing table to the road network for clearing; S9. Complete the entire payment process.

[0006] Preferably, in step S1, the controller is installed on a monitoring pole beside the road, and the controller reads the information of the vehicle's on-board unit OBU through the roadside unit RSU, including the vehicle's license plate number, vehicle type, and ETC card information.

[0007] Preferably, in step S1, the SAAS system is a cloud service platform that provides services such as vehicle management, order processing, and payment processing. After receiving the query request, the SAAS system will perform a data verification process, which may include verifying the matching of the license plate number and the ETC card information, and checking the order status (such as whether it has been paid, whether it is valid, etc.). The deduction operation performed by the SAAS system and the controller includes using the controller to deduct the corresponding fees from the ETC accounts of the roadside unit (RSU) and the on-board unit (OBU), or after identifying the vehicle information during the ETC deduction process, selecting the appropriate payment channel for deduction in a system that supports multiple payment methods.

[0008] Preferably, in step S1, in order to ensure that the SAAS system platform does not repeatedly deduct fees for orders with the same license plate number in a short period of time, the SAAS system will add a distributed lock to the license plate number. In a distributed system, a distributed lock is a mechanism used to ensure that only one process or thread can access specific resources or perform specific operations at the same time. Redis is used here to implement a distributed lock. By executing the SET command, a distributed lock is set for a specific order ID (order_id). The validity period of this lock is set to 60 seconds. The NX parameter in the SET command ensures that the key is set only when the key does not exist, thus avoiding the problem of repeated locking. After the deduction operation is completed, the SAAS system will perform an unlocking operation, remove the previously added distributed lock, and release resources so that other requests can access the order for the license plate number.

[0009] At the same time, the SAAS system platform adds a distributed lock to the license plate for 60 seconds, uses redis to implement distributed locks, and adds a distributed lock to the order through the SETorder:lock:{order_id} 1 EX 60 NX command. At this time, there will be a record in redis with the key order:lock:{order_id}; Preferably, in step S2, the deduction result includes failure or unsuccessful deduction, where the unsuccessful deduction includes insufficient balance and the user card is on the blacklist, and the unsuccessful deduction means that the deduction transaction step is not completed due to excessive speed, resulting in the interruption of the process; Identification and deduction are achieved by the controller accessing SAAS to obtain the vehicle's outstanding amount information, and then initiating instructions to the RSU and the OBU to perform deduction communication instructions. When the deduction is initiated, an order record will be generated and the deduction status will be identified, which will eventually be sent to SAAS.

[0010] Preferably, in step S3, binlog is a database data change log, and each data insertion, modification, and deletion will generate a binlog; TopicA is the message topic of Kafka, which workers can produce or subscribe to.

[0011] Preferably, in step S4, the worker is a module unit in the program; The roadside smart city parking platform refers to a third-party city platform for the parking system of the smart city.

[0012] Preferably, in step S5, when there is a new order, the check of the read_card_type and status fields is triggered: S5.1. When the order fails to be charged due to insufficient balance or ETC not being deducted, step S6 is executed; S5.2: When the order payment is made by credit card, step S6 is executed; S5.3. When the order payment is made by an ETC stored-value card, the order is written into the clearing table and the process proceeds to step S8.

[0013] Preferably, in step S7, for each time-expired order, a contactless payment record search and confirmation is performed, and the logic is as follows: S7.1. If the order ETC payment is successful and the non-contact deduction is also successful, the ETC order will be marked as cancelled and no clearing will be performed, and the process will proceed to step S8; S7.2. If the order ETC payment is successful and there is no record of successful non-contact deduction, the ETC order is written into the clearing table and the process goes to step S8; S7.3. If the ETC payment of the order fails, but the non-contact deduction succeeds, go to step S9; S7.4. If the ETC payment for the order fails and there is no record of successful contactless deduction, go to step S9.

[0014] Preferably, in step S6, the main purpose of the delayqueue worker is to process orders that require heterogeneous contactless payment checks and store them for later checking.

[0015] When an order is created, its information is first written to the delayqueue worker module; To ensure that the payment check logic of the order is triggered before the distributed lock (set to 60 seconds) expires, the storage of order information in the delayqueue worker is set with an expiration time of 50 seconds.

[0016] At the same time, for each order, different payment channels will be tried in turn to deduct the payment according to the pre-set payment sequence and the corresponding activation status of the vehicle. This process will continue until one of the payment channels successfully deducts the payment. Once the deduction is successful, the relevant payment record will be written into the contactless payment table, which exists in the database on the SAAS side.

[0017] The delayqueue worker implementation logic is as follows: After receiving the order information, the order ID will be hashed and the hash value will be distributed to 32 logical buckets. Each bucket is stored in the sortset data structure of the Redis database to store the order ID. A certain number of coroutines are started for each bucket. These coroutines will scan once a second to find expired orders. Once an expired order is found, the relevant order information will be written to Kafka's Topic B so that the subsequent order confirmation worker can process it.

[0018] In general, the purpose of this step is to ensure that orders can be correctly assigned to different payment channels for attempted deductions, and to trigger the payment check logic before the distributed lock expires. At the same time, delayqueue workers are used to manage these orders to ensure the integrity and consistency of the payment process.

[0019] Compared with the prior art, the technical effects and advantages of the present invention are: The city's roadside parking ETC networking application's multiple heterogeneous payment methods are identified through ETC networking. This method can support multiple payment methods including bank cards, WeChat, Alipay, digital RMB, etc., providing users with convenient payment options while improving the coverage and convenience of network charging.

[0020] By introducing big data verification transactions, this method ensures the accuracy of ETC identification and deduction and the authenticity of data without increasing the delay of ETC identification and deduction, thus ensuring smooth traffic and user experience.

[0021] Based on ETC network identification, this method can link multiple scenarios, platforms and institutions, apply big data technology, comply with laws and regulations, and coordinate with all participating units to jointly explore and give play to the application value of data, thereby improving the capabilities and efficiency of IoT applications.

[0022] This payment method not only improves the efficiency and accuracy of urban roadside parking charges, but also enriches the payment methods and effectively improves the success rate of deductions based on ETC network deductions, enhances the application value of data, and is of great significance to the construction of smart cities. Through such technical applications, it can better serve urban traffic management, improve the level of intelligent urban management, and provide car owners with a more convenient and efficient service experience.

[0023] The heterogeneous method of the present invention introduces multiple contactless payment methods, which will not cause any delay in affecting ETC deductions. It supports switching to multiple contactless payment methods when ETC deductions fail or other contactless payment methods need to be prioritized. It also supports the scenario where the vehicle is in the stage of executing the deduction instruction but has exceeded the recognition range of the deduction device due to excessive speed. After ETC recognition, it switches to other contactless payment methods, effectively improving the success rate of online charging. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 It is a flow chart of the present invention. DETAILED DESCRIPTION

[0025] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0026] The following is combined with Figure 1 To further explain this application in detail, The embodiment of the present application discloses a multi-heterogeneous payment method for urban roadside parking ETC networking application, comprising the following steps: S1. When a vehicle passes through the ETC identification and deduction device, the controller (installed on the monitoring pole beside the road) identifies the vehicle's on-board unit OBU (On board Unit) information through the road-side unit RSU (Road-Side Units), and then accesses the SAAS system platform's application program interface API (Application Program Interface) to query the order information related to the license plate number, and completes the deduction after performing data verification through the SAAS system platform; Among them, the roadside unit RSU reads the information of the vehicle's on-board unit OBU, including the vehicle's license plate number, vehicle type, and ETC card information; The SAAS system is a cloud service platform that provides services such as vehicle management, order processing, and payment processing. After receiving a query request, the SAAS system will perform a data verification process, which may include verifying the matching of the license plate number and the ETC card information, and checking the order status (such as whether it has been paid, whether it is valid, etc.). The deduction operations performed by the SAAS system include deducting the corresponding fees from the ETC account, or selecting the appropriate payment channel for deduction in a system that supports multiple payment methods.

[0027] At the same time, in order to ensure that the SAAS system platform will not repeatedly deduct fees for orders with the same license plate number in a short period of time, the SAAS system will add a distributed lock to the license plate number. In a distributed system, a distributed lock is a mechanism used to ensure that only one process or thread can access specific resources or perform specific operations at the same time. Redis is used here to implement distributed locks. By executing the SET command, a distributed lock is set for a specific order ID (order_id). The validity period of this lock is set to 60 seconds. The NX parameter in the SET command ensures that the key is set only when the key does not exist, thus avoiding the problem of repeated locking; After the deduction operation is completed, the SAAS system will perform an unlocking operation, remove the previously added distributed lock, and release resources so that other requests can access the order for the license plate number.

[0028] Use redis to implement distributed locks. Use the SET order:lock:{order_id} 1 EX 60 NX command to add a distributed lock to the order. At this time, there will be a record with the key order:lock:{order_id} in redis to prevent other controllers on the road from continuing to identify the vehicle for repeated identification and deduction (multiple sets of equipment may be deployed on the road). In addition, reserve deduction time for the subsequent heterogeneous payment steps in step S5. S2. The deduction result is sent to the SAAS server, and the SAAS writes the transaction order into the ETC order table. The deduction result includes failure or unsuccessful deduction. Failed deduction includes insufficient balance and the user card is on the blacklist. Unsuccessful deduction means that the deduction transaction steps are not completed due to excessive speed, resulting in the interruption of the process. In the urban roadside parking ETC networking application, when a vehicle passes the ETC identification and deduction device on the roadside, the controller will identify the vehicle's on-board unit (OBU) information through the roadside unit (RSU). Then, the controller will access the application program interface (API) of the SAAS (Software as a Service) system platform to query the order information related to the license plate number.

[0029] After querying the order information, the controller will perform data verification to ensure that the information is accurate. If the verification passes, the controller will send a command to the RSU to communicate with the vehicle's OBU to perform the deduction operation. When the deduction operation is initiated, an order record will be generated, and the status of the deduction (such as success or failure) will be marked in this record.

[0030] Finally, the deduction result (including order record and deduction status) will be sent to the SAAS system. In this way, the SAAS system can track the parking fee of each vehicle, manage the deduction information, and ensure that the parking fee is charged correctly. This process is automated and does not require manual intervention, which improves the success rate and accuracy of parking charges.

[0031] S3, based on the order library binlog log, pushes each data to the message queue Kafka message queue TopicA; Among them, binlog is the database data change log. Each data insertion, modification and deletion will generate a binlog. TopicA is the message topic of Kafka, which can be produced or subscribed by workers. "Each piece of data" refers to the detailed information of each order recorded in the order database. This information may include but is not limited to the order number (order_num), payment type (pay_type), order status, creation time, update time, etc. When an order changes in the database, these changes will be recorded to form a binlog log. By pushing the binlog log to TopicA of the Kafka message queue, the system can capture the update of the order status in real time, and then trigger the subsequent payment processing process. This design can ensure that the payment system can respond quickly to changes in orders and improve the real-time and accuracy of transactions.

[0032] S4. The payment worker subscribes to Topic A of Kafka and promptly notifies the roadside smart city parking platform (referring to a third-party city platform, usually a parking system of a smart city) of the order status of successful payment (this status is recorded in the binlog data from the database, which contains the fields of each order, including the status), notifying it of the successful payment of the order; S5. Heterogeneous payment worker (heterogeneous payment worker is a component unit in the program) subscribes to TopicA of Kafka. When there is a new order, the following fields are triggered: read_card_type, status; When there is a new order, the check of read_card_type and status fields is triggered: S5.1. When the order fails to be charged due to insufficient balance or ETC not being deducted, step S6 is executed; S5.2, when the order payment is by credit card (read_card_type==23), start executing step S6; S5.3. When the order payment is an ETC stored-value card (read_card_type==22), the order will be written into the clearing table (the clearing table records the ETC orders that need to be cleared, and the information will eventually be sent to the road network center for clearing), and then proceed to step S8.

[0033] S6. Write the order information into the delayqueue worker (delayed check of heterogeneous contactless payment results) module first, and set the expiration time to 50 seconds to ensure that the order payment check confirmation logic is triggered before the distributed lock expires (<60 seconds, i.e. the time for setting the distributed lock in step 1). At the same time, initiate the payment channel deduction logic for the order, and try to deduct fees in sequence according to the payment order and the corresponding activation status of the vehicle until one of the payment channels is successfully paid. At the same time, the payment record is written into the contactless payment table (the contactless payment table exists in the database on the SaaS end); The main purpose of the delayqueue worker is to process orders that require heterogeneous contactless payment checks and store them for later checking.

[0034] When an order is created, its information is first written to the delayqueue worker module; To ensure that the payment check logic of the order is triggered before the distributed lock (set to 60 seconds) expires, the storage of order information in the delayqueue worker is set with an expiration time of 50 seconds.

[0035] At the same time, for each order, different payment channels will be tried in turn to deduct the payment according to the pre-set payment sequence and the corresponding activation status of the vehicle. This process will continue until one of the payment channels successfully deducts the payment. Once the deduction is successful, the relevant payment record will be written into the contactless payment table, which exists in the database on the SAAS side.

[0036] The delayqueue worker implementation logic is as follows: After receiving the order information, the order ID will be hashed and the hash value will be distributed to 32 logical buckets. Each bucket is stored in the sortset data structure of the Redis database to store the order ID. A certain number of coroutines are started for each bucket. These coroutines will scan once a second to find expired orders. Once an expired order is found, the relevant order information will be written to Kafka's Topic B so that the subsequent order confirmation worker can process it.

[0037] In general, the purpose of this step is to ensure that orders can be correctly assigned to different payment channels for attempted deductions, and to trigger the payment check logic before the distributed lock expires. At the same time, delayqueue workers are used to manage these orders to ensure the integrity and consistency of the payment process.

[0038] S7, the order confirmation worker subscribes to Kafka's Topic B for consumption, performs contactless payment record search and confirmation on the expired order, and marks the order as the corresponding status according to different situations, and writes it into the clearing table or cancellation status; For each time-expired order, perform contactless payment record search and confirmation. The logic is as follows: S7.1. If the order ETC payment is successful and the non-contact deduction is also successful, the ETC order will be marked as cancelled and no clearing will be performed, and the process will proceed to step S8; S7.2. If the order ETC payment is successful and there is no record of successful non-contact deduction, the ETC order is written into the clearing table and the process goes to step S8; S7.3. If the ETC payment of the order fails, but the non-contact deduction succeeds, go to step S9; S7.4. If the ETC payment for the order fails and there is no record of successful contactless deduction, go to step S9.

[0039] S8, sending the data of the ETC clearing table to the road network for clearing; S9. Complete the entire payment process.

[0040] Through ETC identification and data verification of SAAS system, the accuracy and success rate of deduction are improved, manual operations are reduced, and missed and arrears are prevented. The deduction results are recorded in the ETC order table to ensure the integrity of the transaction history and facilitate subsequent query and audit. By pushing binlog logs to the Kafka message queue, the order status is updated in real time, which improves the response speed of the payment system and the real-time nature of transaction processing. Timely notification of the successful payment of the smart city parking platform ensures that all related systems can update the order status in time and improves the collaborative efficiency of the overall system. The introduction of heterogeneous payment workers supports the integration of multiple other non-touch payment methods such as bank non-touch and digital RMB in addition to ETC, providing more abundant payment options. The delayqueue worker mechanism ensures the consistency and idempotence of order payment checks, avoiding the problem of repeated or missed payments. The order confirmation worker ensures the consistency and accuracy of order status processing, avoiding the omission or expiration of ETC clearing records. The data of the ETC clearing table is sent to the road network for clearing, ensuring the accuracy of financial records and facilitating subsequent financial verification and settlement. The completion of the entire payment process indicates that the system has handled the entire process of order from identification to payment to confirmation, realizing efficient and accurate urban roadside parking fee management.

[0041] The following is an introduction to the multi-heterogeneous payment system used to process urban roadside parking ETC networking applications. The following is a detailed description of each component and its workflow: About “Paying Workers” Idempotence and consistency: The payment worker uses a log table to ensure that each order has been successfully written to the delayqueue worker before attempting to deduct the payment. If an exception occurs, a panic will be triggered, causing the process to automatically restart (the process panics and crashes, causing the program to automatically crash, and then the management process is responsible for automatically restarting the process) to ensure that the order can be reprocessed. When processing records and consuming Kafka, manual commit is used to ensure that each record is committed only after successful processing.

[0042] The payment worker has two main functions: one is to process ETC order types, including the diversion logic of stored-value cards and credit cards; the other is to try to realize seamless deductions from other payment channels.

[0043] Scalability: It supports the expansion of access to other contactless payment channels and can adjust the deduction sequence while maintaining no impact on the deduction delay of the business-side controller.

[0044] About “delayqueue worker” Idempotence: Delayqueue worker uses Redis's sortset data structure to store orders. The characteristics of sortset ensure the consistency of multiple storages.

[0045] Consistency: When the time set for an order expires, the order will be written to Kafka successfully before being deleted. If an exception or write failure occurs when writing to Kafka, the order will not be deleted, but will be retried the next time the coroutine is executed.

[0046] Timeliness: Use multiple logical buckets and multiple coroutines for corresponding scanning to ensure that the expired order data can be pushed to the Kafka message queue in time so that the order confirmation worker can process it in time.

[0047] Order confirmation worker: Function: The order confirmation worker ensures that each order that needs to be confirmed can be processed in a timely manner to prevent ETC clearing records from being missed or expired.

[0048] Consistency: Manual commit is used when consuming Kafka, and the local transaction log table is used to ensure the consistency of the processing logic. If an exception occurs during the execution process, panic will be executed directly, and then the program will automatically restart and continue to consume. Commit is only made after the processing is successful.

[0049] Order distributed lock: Function: When an order payment is made, a 60-second distributed lock is performed on the license plate to ensure that the vehicle will not be charged repeatedly within 60 seconds, ensuring idempotence during concurrent deductions.

[0050] Delayqueue worker: The delayqueue worker ensures that each order is triggered after 50 seconds, and then processed by the order confirmation worker to end the process.

[0051] In general, this is a highly differentiated and distributed system for processing multiple heterogeneous payments, including ETC and contactless payments. The system uses distributed locks to ensure idempotence and consistency, log tables and Kafka to ensure transaction persistence and processing consistency, and multiple logical buckets and multiple coroutines to improve the system's processing speed and efficiency.

[0052] The multi-heterogeneous payment method of the urban roadside parking ETC networking application improves the efficiency and accuracy of urban on-street parking charges by introducing ETC networking identification and multi-heterogeneous payment systems.

[0053] By using ETC to identify charging devices and automated processing procedures, manual intervention is reduced, thereby improving work efficiency. The introduction of a distributed lock mechanism ensures that vehicles will not be charged repeatedly within a certain time frame, effectively reducing the problems of fee evasion and repeated charges. By using the SAAS system and Kafka message queue, order status updates are captured in real time, ensuring that the payment system can quickly respond to order changes and improve the success rate of transactions.

[0054] This method supports multiple payment methods, including ETC, bank-free payment, digital RMB, etc., and processes orders of different payment methods through heterogeneous payment workers, ensuring the flexibility and scalability of the system. By using log tables, distributed locks, and transaction logs, the consistency and idempotence of the system in different links are ensured, preventing data inconsistency problems caused by anomalies. The introduction of order confirmation workers ensures that each order is processed in a timely manner after expiration, preventing the omission or expiration of ETC clearing records.

[0055] In summary, this multi-heterogeneous payment method, through a series of technical means, has achieved the introduction of multiple contactless payment automatic deduction supports based on a single OBU identification without adding additional delay to the ETC deduction process. It has effectively solved the technical problems existing in urban roadside parking fees and improved the quality and efficiency of parking services.

[0056] Finally, it should be noted that the above is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the aforementioned embodiments, it is still possible for those skilled in the art to modify the technical solutions described in the aforementioned embodiments or to make equivalent substitutions for some of the technical features therein. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

Claims

1. A multi-heterogeneous payment method for urban roadside parking ETC networking application, characterized in that: The steps include: S1. When a vehicle passes through the ETC identification and deduction device, the controller identifies the vehicle's on-board unit (OBU) information through the roadside unit (RSU). The controller then accesses the application program interface (API) of the SAAS system platform to query the order information related to the license plate number. After performing data verification through the SAAS system platform, the controller interacts with the on-board unit (OBU) to complete the deduction through the roadside unit (RSU); S2. The deduction result is sent to the SAAS server, and the SAAS writes the transaction order into the ETC order table; S3, based on the order library binlog log, pushes each data to the message queue Kafka message queue TopicA; S4. The payment worker subscribes to Topic A of Kafka and notifies the roadside smart city parking platform of the successful payment order status in a timely manner; S5. The heterogeneous payment worker subscribes to TopicA of Kafka. When there is a new order, the following fields are triggered: read_card_type, status; S6. Write the order information into the delayqueue worker module first, and set the expiration time to 50 seconds. At the same time, initiate the logic of deducting money through the contactless payment channel for the order, and try to deduct money in sequence according to the payment order and the corresponding activation status of the vehicle, until one of the payment channels is successfully paid, and the payment record is written into the contactless payment table; S7, the order confirmation worker subscribes to Kafka's Topic B for consumption, performs contactless payment record search and confirmation on expired orders, marks the order with the corresponding status according to different situations, and writes it into the clearing table or cancellation status; S8, sending the data of the ETC clearing table to the road network for clearing; S9. Complete the entire payment process.

2. According to claim 1, a multi-heterogeneous payment method for urban roadside parking ETC networking application is characterized by: In step S1, the controller is installed on a monitoring pole beside the road. The controller reads the information of the vehicle's on-board unit OBU through the roadside unit RSU, including the vehicle's license plate number, vehicle type, and ETC card information.

3. According to claim 1, a multi-heterogeneous payment method for urban roadside parking ETC networking application is characterized by: In step S1, the SAAS system is a cloud service platform that provides vehicle management, order processing, and payment processing services. After receiving the query request, the SAAS system performs a data verification process, including verifying the matching of the license plate number and the ETC card information and checking the order status. The deduction operations performed by the SAAS system and the controller include deducting the corresponding fees from the ETC account, or selecting the appropriate payment channel for deduction in a system that supports multiple payment methods.

4. According to claim 1, a multi-heterogeneous payment method for urban roadside parking ETC networking application is characterized by: In step S1, in order to ensure that the SAAS system platform does not repeatedly deduct fees for orders with the same license plate number in a short period of time, the SAAS system will add a distributed lock to the license plate number to ensure that only one process or thread can access specific resources or perform specific operations at the same time; After the deduction operation is completed, the SAAS system will perform an unlocking operation, remove the previously added distributed lock, and release resources so that other requests can access the order for the license plate number.

5. According to claim 1, a multi-heterogeneous payment method for urban roadside parking ETC networking application is characterized by: In step S2, the deduction result includes failure or unsuccessful deduction. Failed deduction includes insufficient balance and the user card is on the blacklist. Unsuccessful deduction means that the deduction transaction step is not completed due to excessive vehicle speed, resulting in the interruption of the process.

6. According to claim 1, a multi-heterogeneous payment method for urban roadside parking ETC networking application is characterized by: In step S3, binlog is a database data change log. Each insertion, modification, and deletion of data will generate a binlog. TopicA is the message topic of Kafka, which workers can produce or subscribe to.

7. A multi-heterogeneous payment method for urban roadside parking ETC networking application according to claim 1, characterized in that: In step S4, worker is a module unit in the program; The roadside smart city parking platform refers to a third-party city platform for the smart city parking system.

8. According to claim 1, a multi-heterogeneous payment method for urban roadside parking ETC networking application is characterized by: In step S5, when there is a new order, the check of the read_card_type and status fields is triggered: S5.

1. When order deduction fails, start executing step S6; S5.2: When the order payment is made by credit card, step S6 is executed; S5.

3. When the order payment is made by an ETC stored-value card, the order is written into the clearing table and the process proceeds to step S8.

9. A multi-heterogeneous payment method for urban roadside parking ETC networking application according to claim 1, characterized in that: In step S7, for each time-expired order, the contactless payment record search and confirmation is performed, and the logic is as follows: S7.

1. If the order ETC payment is successful and the non-contact deduction is also successful, the ETC order will be marked as cancelled and no clearing will be performed, and the process will proceed to step S8; S7.

2. If the order ETC payment is successful and there is no record of successful non-contact deduction, the ETC order is written into the clearing table and the process goes to step S8; S7.

3. If the ETC payment of the order fails, but the non-contact deduction succeeds, go to step S9; S7.

4. If the ETC payment for the order fails and there is no record of successful contactless deduction, go to step S9.

10. According to claim 4, a multi-heterogeneous payment method for urban roadside parking ETC networking application is characterized by: Use redis to implement distributed locks. By executing the SET command, a distributed lock is set for a specific order ID, and the validity period of the lock is set to 60 seconds.

Images