Parking data efficient processing method and system supporting complex charging strategy
By employing a three-layer data processing framework with asynchronous preprocessing, intelligent scheduling, and parallel computing, the parking lot billing process was optimized, resolving database bottlenecks and resource waste issues under complex billing strategies, and achieving efficient billing processing.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHENZHEN DAS IOT TECH CO LTD
- Filing Date
- 2026-01-26
- Publication Date
- 2026-05-01
AI Technical Summary
Existing parking fee calculation methods suffer from database query bottlenecks, wasted computing resources, and system latency when dealing with complex fee calculation strategies, especially in high-concurrency scenarios where they struggle to meet low-latency requirements.
A three-layer data processing framework is adopted, including an asynchronous preprocessing and context building layer, an intelligent scheduling and execution layer, and a parallel computing resource layer. Through asynchronous processing, context-aware scheduling, and parallel computing, the billing process is optimized.
It significantly improves the execution efficiency of complex billing rules, reduces system latency, enhances resource utilization and system scalability, reduces database pressure, and improves system response time and throughput.
Smart Images
Figure CN121963327A_ABST
Abstract
Description
A method and system for efficient parking data processing that supports complex billing strategies Technical Field
[0001] This invention relates to the field of parking fee calculation methods, specifically to a method and system for efficient processing of parking data that supports complex fee calculation strategies. Background Technology
[0002] When implementing complex parking billing strategies such as "24-hour cumulative fee capping," existing technologies typically employ a real-time synchronous processing model: when a vehicle leaves the parking lot, the billing service synchronously queries the database for all historical records of that vehicle, performing calculations such as time window determination, fee accumulation, and minimum value comparison in memory. This model suffers from the following specific and serious technical defects:
[0003] 1. Database chained query and full scan bottleneck: Each billing transaction triggers a SELECT ... WHERE vehicle_id = ? query on the historical records table; during peak hours, massive concurrent similar queries lead to database connection pool exhaustion and disk I / O congestion, forming a systemic bottleneck; the query response time (RT) delay is directly converted into the waiting time of vehicles at the exit.
[0004] 2. Rigid waste of computing resources: The model adopts a "one-size-fits-all" approach and cannot identify business scenarios. According to statistics, more than 60% of parking events have no recent historical records, and their billing logic could be greatly simplified. However, the system still performs expensive historical data loading and complex window judgment logic for them, resulting in the ineffective consumption of CPU cycles and memory bandwidth.
[0005] 3. Worsening System Tail Latency: The computation time for complex billing is positively correlated with the number of historical records. When processing vehicles with a large number of historical records, the time taken for a single billing operation increases significantly, leading to a sharp rise in the P99 value of the overall system response time, making it difficult to meet the strong demand for stable and low latency at parking exits. Summary of the Invention
[0006] To address the technical problem that existing parking fee calculation methods, regardless of whether a vehicle has a history record, will execute all historical data loading and complex window judgment logic, resulting in wasted computing resources, complex fee calculation, and long processing time, this invention provides a parking data efficient processing method and system that supports complex fee calculation strategies. Through asynchronous processing, context-aware scheduling, and parallel computing, it significantly improves the execution efficiency of complex fee rules and the scalability of the system.
[0007] The technical solution adopted in this invention is to provide an efficient parking data processing method that supports complex billing strategies. This method includes asynchronous processing of vehicle exit billing using a three-layer data processing framework. The three-layer data processing framework includes an asynchronous preprocessing and context building layer, an intelligent scheduling and execution layer, and a parallel computing resource layer. Based on this, the processing method includes the following steps:
[0008] S1. Deploy a context builder independent of the real-time request chain in the asynchronous preprocessing and context building layer. When a vehicle entry event occurs, the context builder retrieves the historical records within a preset time window from the database based on the identified vehicle identifier.
[0009] S2. The context builder analyzes based on preset rules and generates a structured vehicle billing context, which includes the predicted conclusion, aggregate value and scene label.
[0010] S3. Deploy a scheduling decision-maker in the intelligent scheduling and execution layer. When a vehicle departure event occurs, the scheduling decision-maker reads the scene tag and key parameters in the vehicle billing context. Based on the scene tag, it allocates the billing request to the lightweight billing device or the standard billing device. The lightweight billing device or the standard billing device performs billing based on the key parameters.
[0011] S4. Deploy a parallel execution framework at the parallel computing resource layer. When the standard billing machine performs multi-dimensional billing, submit the billing request to the parallel execution framework for parallel execution.
[0012] Step S2 also includes serializing the vehicle billing context and storing it in distributed memory storage.
[0013] The prediction conclusion mentioned in step S2 is a key judgment conclusion derived from analyzing historical records based on preset rules. The aggregated value includes rolling cumulative cost and effective start time point, and the scene label includes simple scene and complex scene.
[0014] The method for allocating billing requests based on scene labels in step S3 includes the following: when the scheduling decision-maker identifies a scene label as a simple scene, it allocates the billing request to a lightweight billing machine for billing; when the scene label is identified as a complex scene, it allocates the billing request to a standard billing machine for billing.
[0015] The lightweight meter mentioned in step S3 calculates the parking fee based only on the current parking time, while the standard meter calculates the cumulative parking fee, including the current parking fee, based on the historical records in the vehicle billing context and the current parking time.
[0016] The parallel execution framework described in step S4 has multiple processing cores. The standard billing unit models the billing for each independent dimension as a stateless computation function, packages it, and submits it to the parallel execution framework. The parallel execution framework distributes the billing task to different cores for separate billing. After summarizing multiple billing results, the cumulative parking fee including the parking fee for this parking session is obtained.
[0017] The aforementioned aggregation uses a reduction operator to aggregate multiple billing results.
[0018] This invention also provides a system for efficient parking data processing to support complex billing strategies, comprising a central processing unit (CPU), a vehicle identification module, a database module, and a standard billing module, all communicating with the CPU. The CPU is used for control and data processing; the vehicle identification module is used to identify vehicles upon entry and obtain vehicle information; the database module is used to store historical data; and the system also includes a context building module and a lightweight billing module, all communicating with the CPU, as well as multiple parallel billing units associated with the standard billing module.
[0019] The context building module is used to obtain the vehicle's historical records from the database module based on the vehicle information identified by the vehicle identification module, and generate a structured billing context based on the historical records.
[0020] The central processing unit is also used to allocate billing requests to the lightweight billing module or the standard billing module for billing when the vehicle leaves the vehicle, based on the scene tag in the obtained vehicle billing context.
[0021] The lightweight billing module is used to calculate the parking fee based on the current parking record;
[0022] The standard billing module is used to perform cumulative billing including historical records based on the vehicle billing context and the current parking record. When there are multiple historical records, they are distributed to multiple parallel billing units for parallel billing. The final cumulative fee is obtained after the billing results are summarized.
[0023] The beneficial effects of this invention are that it provides an efficient parking data processing method that supports complex billing strategies. It employs a decoupled, preprocessing, and intelligent scheduling three-layer data processing framework to efficiently execute predetermined billing rules. The advantages are as follows:
[0024] 1. This invention adopts a three-layer data processing architecture, which shifts the large amount of computation required for billing rule analysis from the high-concurrency exit time to the off-peak or background asynchronous execution.
[0025] 2. This invention generates a serialized billing context from historical records and combines it with the current parking record for billing. Depending on the situation, the billing is allocated to a lightweight billing machine or a standard billing machine for processing, realizing on-demand allocation of computing resources and differentiated services, so that the system throughput is no longer constrained by the most complex requests.
[0026] 3. This invention addresses multi-dimensional billing requests. The standard billing machine distributes the request to multiple parallel frameworks for parallel processing according to each independent dimension. This transforms single-threaded, sequential complex logic calculations into a set of tasks that can be executed in parallel. By utilizing the parallel computing capabilities of multi-core CPUs, the required computation time is significantly reduced, and the tail latency of complex requests is improved. Attached Figure Description
[0027] Figure 1 is a flowchart of the method of the present invention. Detailed Implementation
[0028] As shown in Figure 1, this invention provides an efficient parking data processing method that supports complex billing strategies. The method includes asynchronous processing of vehicle exit billing using a three-layer data processing framework. This three-layer framework comprises an asynchronous preprocessing and context building layer, an intelligent scheduling and execution layer, and a parallel computing resource layer. Based on this, the processing method includes the following steps:
[0029] S1. Deploy a context builder independent of the real-time request chain in the asynchronous preprocessing and context building layer. When a vehicle entry event occurs, the context builder retrieves historical records within a preset time window, such as historical records within 24 hours, from the database based on the identified vehicle identifier.
[0030] S2, the context builder analyzes based on preset rules and generates a structured vehicle billing context, which is then serialized and stored in distributed memory storage. The vehicle billing context includes the predicted conclusion, aggregate value, and scene label.
[0031] The preset rules are analysis rules for asynchronously building the context. They are a set of rules that analyze historical records and build the vehicle billing context, and mainly include:
[0032] (1) Time window analysis rules: Determine the correlation between historical records and the current time. For example, analyze whether there are historical records in the last 24 hours.
[0033] (2) Cumulative Cost Rules: Calculate the cumulative costs incurred within a specific time window. For example, calculate the cumulative costs paid within a 24-hour rolling window.
[0034] (3) Key time point extraction rules: Extract valid time points from historical records. For example, find the most recent exit time and the earliest relevant entry time.
[0035] When a vehicle enters the parking lot, the context builder asynchronously analyzes its historical records according to preset rules, pre-calculates key indicators, and constructs a structured context, instead of waiting until the vehicle leaves to perform real-time analysis, thus realizing the forward shift of calculation.
[0036] The predictive conclusions are key judgments derived from analyzing historical records based on preset rules. These conclusions provide direct basis for subsequent dispatching decisions, avoiding repeated analysis upon vehicle departure. The predictive conclusions are stored in the vehicle billing context as flag bits or specific values, including:
[0037] hasRecentRecord (Boolean): Whether there are any historical records within a preset time window (e.g., 24 hours).
[0038] lastExitTime (timestamp): The time of the most recent appearance.
[0039] isOverlapWithCurrent (Boolean): Whether the time window of the historical record overlaps with the current parking.
[0040] isDailyCapReached (Boolean): Whether the accumulated cost within the rolling time window has reached the daily limit.
[0041] suggestedBillingStartTime (timestamp): The suggested billing start time (possibly the earliest incompletely settled historical entry time).
[0042] The aggregated value is key data derived from analyzing historical records based on preset rules, including rolling cumulative costs and effective start time points.
[0043] Scene tags are categorized into simple and complex scenarios, determined by analyzing predicted conclusions and aggregated values within the vehicle billing context. Parking requests with no or simple historical records (statistically exceeding 60%) are directed to lightweight paths for rapid processing; only requests requiring complex computations are directed to standard paths and parallel computing, achieving precise resource allocation. The scene tag determination criteria are as follows:
[0044] For simple scenarios, meeting any one of the following conditions is sufficient:
[0045] (1) hasRecentRecord == false: There are no historical records within a preset time window (e.g., 24 hours).
[0046] (2) lastExitTime is earlier than currentTime - 24h: the last exit time is more than 24 hours away from the current time, and this parking time does not overlap with the historical records.
[0047] (3) isDailyCapReached == true and the current parking is within the paid time window: the historical accumulated fee has reached the daily limit, and the current parking time does not exceed the continuous time period covered by the limit.
[0048] Criteria for determining complex scenarios:
[0049] (2) hasRecentRecord == true and the history overlaps with the current time.
[0050] (2) Multiple candidate costs need to be calculated based on multiple historical entry time points (relevantHistoricalCount> 1).
[0051] (3) It is necessary to handle cumulative billing across multiple rolling time windows.
[0052] Steps S1 and S2 offload the large amount of computation required for billing rule analysis from high-concurrency exit times to off-peak or background asynchronous execution.
[0053] S3. Deploy a scheduling decision-maker in the intelligent scheduling and execution layer. When a vehicle departure event occurs, the scheduling decision-maker reads the scene tag and key parameters in the vehicle billing context. Based on the scene tag, it allocates the billing request to the lightweight billing device or the standard billing device. The lightweight billing device or the standard billing device performs billing based on the key parameters.
[0054] When the scheduling decision-maker identifies a scenario as a simple scenario, it assigns the billing request to the lightweight billing machine for billing; when it identifies a scenario as a complex scenario, it assigns the billing request to the standard billing machine for billing.
[0055] The lightweight meter calculates the parking fee based solely on the current parking time, while the standard meter calculates the cumulative parking fee, including the current parking fee, based on historical records in the vehicle's billing context and the current parking time.
[0056] This method adds a scheduling decision-maker to the billing service entry point of the parking system. When a vehicle exit event occurs, the scheduling decision-maker first obtains the pre-constructed vehicle billing context, reads the scene label and key parameters in the vehicle billing context, and performs path allocation. This realizes on-demand allocation of computing resources and differentiated services, so that the system throughput is no longer constrained by the most complex requests.
[0057] Path 1, Lightweight Path: If the scene label is identified as a simple scene, for example, hasRecentRecord = false, the dispatch decision-maker will route the vehicle exit billing request to a lightweight billing device. The lightweight billing device has simple logic, which is based only on the current parking time, completely avoiding the query of historical records in the database and complex time window merging calculations, requiring very little data query volume.
[0058] Path 2, Standard Path: If the scene label is identified as a complex scene, the dispatch decision-maker will route the vehicle departure billing request to the standard billing unit; the standard billing unit uses the pre-calculated aggregate value in the vehicle billing context, i.e. the historical accumulated fee, to perform incremental calculation on the newly added part, reducing the amount of data query required.
[0059] S4. Deploy a parallel execution framework at the parallel computing resource layer. When the standard billing machine performs multi-dimensional billing, submit the billing request to the parallel execution framework for parallel execution, such as CompletableFuture or Goroutine pool.
[0060] Even if the standard billing system obtains the historical accumulated charges (aggregated value) through context, it still needs to perform parallel computation in complex scenarios. The reason for this is:
[0061] (1) Calculation of multiple candidate fees: For vehicles with multiple historical records, the final billing result is usually the minimum of multiple "candidate fees". Each candidate fee is the continuous parking fee calculated based on a different historical entry time point (Bk), and then the corresponding paid fee is subtracted. The calculation of each candidate fee is independent.
[0062] (2) Computational complexity: The calculation of each candidate cost may involve complex rules such as segmented billing, cross-day billing, and capping, resulting in a large amount of computation.
[0063] (3) Performance optimization: Parallelizing these independent candidate cost calculation tasks can make full use of multi-core CPU resources, reduce the serial calculation time from O(n) to close to O(1) (for the parallelizable part), and significantly reduce the overall response time of complex requests (P99 latency).
[0064] For example, if a vehicle has three historical parking records (B1, B2, B3), it is necessary to calculate four candidate costs, including the current individual cost. Serial computation takes four units of time, while parallel computation only takes one unit of time.
[0065] The parallel execution framework has multiple processing cores. The standard billing unit models the billing for each independent dimension as a stateless computation function, packages it, and submits it to the parallel execution framework. The parallel execution framework distributes the billing task to multiple CPU cores for execution and uses reduction operators, such as the min operator, to summarize the multiple billing results to obtain the cumulative parking fee that includes the parking fee for this parking session.
[0066] Multi-dimensional billing refers to the fact that a vehicle has multiple parking records from different time periods in its historical records.
[0067] Step S4 of this method transforms the single-threaded, sequential complex logic calculation into a set of tasks that can be executed in parallel. By utilizing the parallel computing capabilities of multi-core CPUs, the theoretical computation time is reduced from O(n) to close to O(1), which greatly improves the tail latency of complex requests.
[0068] This method significantly reduces database pressure: by preloading the vehicle billing context, it is expected to reduce direct historical record queries at the time of departure by more than 70%, smooth out database load peaks, and enhance system scalability.
[0069] This method improves system response time and throughput: lightweight paths enable most requests to be completed within 1 millisecond; parallel computing reduces the time taken for complex requests by more than 50%, the overall system P99 latency decreases measurably, and exit efficiency is improved.
[0070] This method improves resource utilization: computing resources are shifted from "average distribution" to "precise allocation," and the maximum concurrent billing request volume (QPS) that can be supported under the same hardware configuration is increased several times, or more complex derivative billing rules can be supported.
[0071] This invention also provides a system for efficient parking data processing to support complex billing strategies, comprising a central processing unit (CPU), a vehicle identification module, a database module, and a standard billing module, all communicating with the CPU. The CPU is used for control and data processing; the vehicle identification module is used to identify vehicles upon entry and obtain vehicle information; the database module is used to store historical data; and the system also includes a context building module and a lightweight billing module, all communicating with the CPU, as well as multiple parallel billing units associated with the standard billing module.
[0072] The context building module is used to obtain the vehicle's historical records from the database module based on the vehicle information identified by the vehicle recognition module, and generate a structured billing context based on the historical records. The central processing unit is also used to allocate the billing request to the lightweight billing module or the standard billing module for billing when the vehicle leaves the parking area, based on the scene label in the obtained vehicle billing context. The lightweight billing module is used to calculate the parking fee for the current parking based on the current parking record. The standard billing module is used to perform cumulative billing including historical records based on the vehicle billing context and the current parking record, and when there are multiple historical records, it allocates them to multiple parallel billing units for parallel billing, and obtains the final cumulative fee after summarizing the billing results.
Claims
1. A method for efficient processing of parking data supporting complex billing strategies, characterized in that: The method employs a three-layer data processing framework for asynchronous vehicle exit billing. This framework includes an asynchronous preprocessing and context building layer, an intelligent scheduling and execution layer, and a parallel computing resource layer. Based on this, the processing method includes the following steps: S1. Deploying a context builder independent of the real-time request chain in the asynchronous preprocessing and context building layer. When a vehicle entry event occurs, the context builder retrieves historical records within a preset time window from the database based on the identified vehicle identifier. S2. The context builder analyzes based on preset rules to generate a structured vehicle billing context, which includes a prediction conclusion, an aggregate value, and a scene label. S3. Deploying a scheduling decision-maker in the intelligent scheduling and execution layer. When a vehicle exit event occurs, the scheduling decision-maker reads the scene label and key parameters from the vehicle billing context and allocates the billing request to a lightweight billing unit or a standard billing unit based on the scene label. The lightweight billing unit or the standard billing unit then performs billing based on the key parameters. S4. Deploy a parallel execution framework at the parallel computing resource layer. When the standard billing machine performs multi-dimensional billing, submit the billing request to the parallel execution framework for parallel execution.
2. The efficient parking data processing method supporting complex billing strategies according to claim 1, characterized in that: Step S2 also includes serializing the vehicle billing context and storing it in distributed memory storage.
3. The efficient parking data processing method supporting complex billing strategies according to claim 1, characterized in that: The prediction conclusion mentioned in step S2 is a key judgment conclusion derived from analyzing historical records based on preset rules. The aggregated value includes rolling cumulative cost and effective start time point, and the scene label includes simple scene and complex scene.
4. The efficient parking data processing method supporting complex billing strategies according to claim 1, characterized in that: The method for allocating billing requests based on scene labels in step S3 includes the following: when the scheduling decision-maker identifies a scene label as a simple scene, it allocates the billing request to a lightweight billing machine for billing; when the scene label is identified as a complex scene, it allocates the billing request to a standard billing machine for billing.
5. The efficient parking data processing method supporting complex billing strategies according to claim 1, characterized in that: The lightweight meter mentioned in step S3 calculates the parking fee based only on the current parking time, while the standard meter calculates the cumulative parking fee, including the current parking fee, based on the historical records in the vehicle billing context and the current parking time.
6. The efficient parking data processing method supporting complex billing strategies according to claim 1, characterized in that: The parallel execution framework described in step S4 has multiple processing cores. The standard billing unit models the billing for each independent dimension as a stateless computation function, packages it, and submits it to the parallel execution framework. The parallel execution framework distributes the billing task to different cores for separate billing. After summarizing multiple billing results, the cumulative parking fee including the parking fee for this parking session is obtained.
7. The efficient parking data processing method supporting complex billing strategies according to claim 6, characterized in that: The aforementioned aggregation uses a reduction operator to aggregate multiple billing results.
8. A system for efficient parking data processing method supporting complex billing strategies as described in any one of claims 1-7, comprising a central processing unit, a vehicle identification module, a database module, and a standard billing module, each communicating with the central processing unit; the central processing unit being used for control and data processing; the vehicle identification module being used for identification and acquisition of vehicle information upon vehicle entry; and the database module being used for storing historical data; characterized in that: It also includes a context building module and a lightweight billing module that communicate with the central processing unit, as well as multiple parallel billing units associated with the standard billing module. The context building module is used to obtain the vehicle's historical records from the database module based on the vehicle information identified by the vehicle identification module, and generate a structured billing context based on the historical records. The central processing unit is also used to allocate the billing request to the lightweight billing module or the standard billing module for billing when the vehicle leaves the factory, based on the scene tag in the obtained vehicle billing context. The lightweight billing module is used to calculate the parking fee based on the current parking record; The standard billing module is used to perform cumulative billing including historical records based on the vehicle billing context and the current parking record. When there are multiple historical records, they are distributed to multiple parallel billing units for parallel billing. The final cumulative fee is obtained after the billing results are summarized.