A centralized special situation cloud processing control method based on a highway toll collection system

Abstract

The application discloses a centralized special situation cloud treatment control method based on an expressway toll collection system and belongs to the technical field of expressway toll collection special situation treatment. The method first collects vehicle multi-source data through each site terminal device, realizes cross-section sharing after washing heterogeneous data; then, an AI multi-classification prediction model deployed by an edge node is combined with real-time and shared data to predict whether a vehicle is at the next site and a possible special situation type, and is synchronized to a cloud hub platform; if a next special situation is predicted, the cloud hub platform monitors the task amount of a value-keeping personnel, dynamically allocates tasks and gives an early warning; and the value-keeping personnel generates a processing report containing prediction, process and result after treatment. The application solves the problems of data fragmentation, passive treatment and task allocation imbalance in the prior art, shortens special situation processing time, reduces lane congestion rate, and improves treatment efficiency and accuracy.

Description

Technical Field

[0001] This invention relates to the field of emergency handling technology for highway toll collection, and in particular to a centralized emergency cloud handling and control method based on a highway toll collection system. Background Technology

[0002] With the continuous improvement of my country's expressway network and the in-depth promotion of the unified network operation model, expressway traffic volume continues to grow, and vehicle traffic scenarios are becoming increasingly complex, highlighting the growing need for emergency handling in toll collection systems. In existing technologies, cloud-based monitoring systems, through hardware deployed in smart booths or cloud warehouses, utilize audio and video communication technology to enable toll collectors to remotely handle emergency situations across multiple lanes at a single station. Their main functions include:

[0003] Real-time monitoring: Vehicle information and equipment status are collected through lane cameras, sensors, and other devices, and transaction records, equipment malfunction data, etc., are displayed on the local terminal. Remote handling: For common special situations such as license plate recognition errors and ETC transaction failures, on-duty personnel can guide drivers through the operation via voice intercom or remotely control devices such as barrier gates and toll display to complete the passage. Data storage: Special situation handling records, lane logs, and other data are stored on a station-level server, supporting post-event query and statistics.

[0004] The existing system architecture operates on a single toll station basis, limiting data processing and task allocation to the station's own scope. It relies on manual judgment of emergency priorities and lacks a cross-segment collaboration mechanism. For example, a certain segment's center can only receive aggregated data uploaded by each toll station and cannot directly intervene in emergency handling procedures. When vehicles travel to different segments, prior traffic data is difficult to share, leading to duplicate verification issues.

[0005] The existing centralized emergency response model has significant limitations in cross-regional collaboration, processing efficiency, and predictive capabilities. Specifically: First, data is fragmented across road segments, with each toll station storing data independently and lacking a unified multi-source data fusion mechanism. When vehicles travel across provinces or road segments, route information and historical emergency records collected by the gantry system cannot be shared in real time, leading to repeated verification of vehicle information and increased average processing time. Second, the response is reactive; the existing system only triggers emergency alarms after a vehicle arrives at the toll station, without establishing a pre-emptive prediction mechanism. For example, for high-frequency emergencies such as "no entrance information" and "overloading," the response process can only be initiated after the vehicle enters the lane, easily causing lane congestion. Third, task allocation is unbalanced; emergency tasks are assigned to personnel in lane order without considering personnel load and skill matching. During peak hours, when a single personnel handles more than five emergencies simultaneously, the accuracy rate decreases, and missed cases are more likely. Fourth, intelligent decision-making is lacking, relying on manual judgment of emergency types and response plans, without utilizing big data analysis to uncover emergency patterns. For example, the inability to predict the peak times and lane distribution for "green channel vehicle inspections" during holidays based on historical data leads to delays in on-site personnel deployment.

[0006] For example, invention application No. 202311210811.X discloses a method, device, and medium for special situation analysis on highways. Using this solution, through rapid clustering, association analysis, core feature word extraction, and the establishment of a category model, similar special situation data can be quickly found in historical special situation data for new special situation data, which facilitates rapid processing by staff. However, this solution also has the following drawbacks: it does not solve the problem of data fragmentation across road segments, and still relies on historical data from a single region for matching; and it lacks a pre-event prediction mechanism, only relying on historical data to find solutions after a special situation occurs, which is still a passive response and cannot avoid lane congestion in advance. It cannot meet the needs of cross-domain collaboration and proactive prediction of special situations under the unified operation of highway networks.

[0007] Therefore, a new centralized cloud-based emergency response and control method based on the highway toll system is needed to solve many problems existing in the current highway toll system emergency response. Summary of the Invention

[0008] To address the aforementioned problems, the present invention aims to provide a centralized cloud-based emergency response and control method based on a highway toll system, thereby resolving issues such as passive response, unbalanced task allocation, and lack of intelligent decision-making in existing highway toll emergency response methods.

[0009] This invention provides a centralized cloud-based emergency response and control method based on a highway toll collection system.

[0010] First aspect: A centralized emergency cloud-based handling and control method based on a highway toll system, including:

[0011] S1. Collect multi-source vehicle data through terminal equipment at each station, clean the heterogeneous data, and share the processed data across road segments.

[0012] S2. The AI ​​multi-class prediction model, after being trained and deployed at the edge nodes, performs special situation prediction based on real-time collected vehicle data and shared multi-source vehicle data. It predicts whether a vehicle will exit the road at this station and the types of special situations that may occur, and synchronizes the special situation prediction results to the cloud hub platform.

[0013] S3. If it is predicted that a vehicle will exit at this station and an emergency may occur, the cloud hub platform will monitor the workload of the personnel on duty at each station in real time, dynamically allocate emergency tasks, and issue early warnings.

[0014] S4. The on-duty personnel complete the handling of special situations and generate a processing report on the handling process and results.

[0015] In one embodiment of the present invention, the terminal device includes a gantry system, a lane camera, an ETC antenna, and a handheld terminal. The collected multi-source vehicle data includes vehicle location, speed, route information, license plate, axle load, overload status, vehicle type, and historical transaction records.

[0016] In one embodiment of the present invention, the cleaning of heterogeneous data includes:

[0017] S11. Convert non-uniform format vehicle data collected from different manufacturers and different types of equipment into JSON structure data;

[0018] S12. Handle missing data, format errors, and logical conflicts in JSON structured data;

[0019] S13. Filter out redundant fields that are irrelevant to the handling of special situations, remove redundant information, and obtain complete, accurate vehicle data that conforms to the standard JSON structure.

[0020] S14. Synchronize vehicle data in standard JSON structure to the cloud hub platform to achieve cross-road segment data sharing.

[0021] In one embodiment of the present invention, the AI ​​multi-class prediction model is built on LSTM and trained on a cloud hub platform. The training samples include at least 3 years of historical special situation data within the road segment and are updated in real time.

[0022] In one embodiment of the present invention, the dynamic allocation of special task in S3 includes:

[0023] Real-time monitoring of the current workload of special tasks handled by personnel at each station, calculation of load coefficient, and priority allocation of tasks to personnel with lower load coefficients;

[0024] Establish a personnel skill tag database and prioritize assigning skills to personnel with corresponding tags based on the type of special situation task prediction;

[0025] When the workload of staff at a certain station is saturated, the cloud hub platform will prioritize transferring the task to available staff in adjacent road sections based on the task type.

[0026] In one embodiment of the present invention, the early warning includes:

[0027] The system pushes early warning information to the handheld terminals of on-duty personnel at least 5 minutes in advance. The early warning information includes the type of emergency, vehicle characteristics, and suggested handling procedures.

[0028] In one embodiment of the present invention, the training database of the AI ​​multi-class prediction model is updated based on the processing report, and the model is iteratively optimized.

[0029] In one embodiment of the present invention, when the AI ​​multi-classification prediction model is deployed, the model is deployed in layers, with the front end deployed on edge nodes and the back end running on the cloud hub platform, thus balancing data utility.

[0030] In one embodiment of the present invention, when synchronizing standardized data, special situation predictions, task allocation and handling results to the cloud hub platform, a blockchain-enhanced storage mode is adopted.

[0031] In one embodiment of the present invention, special situation prediction information is pushed to the vehicle to guide the driver to cooperate in handling special situations.

[0032] Second aspect: An electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, performs the steps of the method provided in the first aspect.

[0033] Third aspect: A non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method provided in the first aspect.

[0034] The beneficial effects of this invention are:

[0035] 1. The method of this invention can leverage cloud technology to achieve real-time data sharing of the gantry system, enabling timely synchronization of route information and historical incident records for vehicles traveling across provinces or road sections. This avoids repeated verification of vehicle information during incident handling and effectively shortens the average processing time. Simultaneously, it establishes a pre-emptive prediction mechanism, changing the passive response mode. By utilizing big data analysis of past incident data, it can predict potential situations in advance and formulate response strategies, preparing for congestion before vehicles arrive at the toll station.

[0036] 2. This invention collects multi-source vehicle data through terminal devices, cleans it using JSON standardization, and utilizes blockchain storage to achieve one-time data entry and network-wide sharing across road segments, breaking down traditional single-station data silos. Compared to existing technologies that require repeated verification of vehicle information for cross-road segment emergency handling, this solution shortens data verification time, reduces the rate of duplicate verification, solves the problem of data fragmentation in cross-provincial emergency handling, and lays a data foundation for efficient subsequent handling.

[0037] 3. This invention utilizes an AI multi-classification prediction model built on LSTM, integrating multi-dimensional vehicle features to predict exit conditions and emergency types when a vehicle is 20km away from the toll station. Compared to the passive mode of existing technologies that triggers handling only after the vehicle enters the lane, this solution enables emergency handling to start preparation at least 5 minutes in advance, reducing average processing time, lowering lane congestion rates, and avoiding lane congestion problems during peak hours from the source.

[0038] 4. The cloud hub platform of this invention allocates tasks through a dual-dimensional approach of load awareness algorithm and skill tag library, prioritizing tasks for personnel with low load coefficients and matching skills. Compared to existing technologies that allocate tasks by lane order and ignore peak periods caused by load and skills, this invention reduces the average number of tasks that on-duty personnel can handle simultaneously, improves the accuracy of handling tasks, and achieves dynamic task allocation to optimize manpower configuration.

[0039] 5. This invention relies on emergency response reports to incrementally update the AI ​​model training database, while simultaneously optimizing the personnel skill tag library. This collaborative iterative mechanism overcomes the limitations of existing technologies that rely on manual judgment and lack intelligent optimization, continuously improving the intelligence and precision of emergency response. Attached Figure Description

[0040] Figure 1 This is a flowchart illustrating the centralized emergency cloud handling and control method of the present invention;

[0041] Figure 2 This is a flowchart illustrating the principle of the centralized emergency cloud handling and control method of the present invention;

[0042] Figure 3 This is a schematic diagram of the structure of the electronic device of the present invention. Detailed Implementation

[0043] Embodiments of the present invention are described in detail below. Examples of these embodiments are illustrated in the accompanying drawings, wherein the same or similar symbols denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0044] To facilitate understanding of the present invention, special situations are first introduced. In this invention, special situations refer to unique circumstances in the highway toll collection process where abnormal vehicle information, transaction failures, abnormal travel routes, or equipment interaction problems prevent the toll collection system from completing vehicle identification, fee calculation, and release operations according to the normal procedure. These situations require manual intervention or special system processing mechanisms to resolve; otherwise, they will affect lane traffic efficiency, toll collection accuracy, and may even cause problems with the road network operation order. Special situation classifications mainly include:

[0045] Transaction-related special situations refer to transaction failures that occur when a vehicle is using ETC or manual toll collection. For example, if an ETC transaction fails, it means that the vehicle's OBU and the lane's ETC antenna cannot communicate normally, causing the toll collection process to be interrupted. In such cases, on-duty personnel need to remotely guide the driver to troubleshoot the equipment or switch to a different payment method.

[0046] Special situations related to vehicle identification: These refer to abnormalities in the system's identification of key vehicle information, such as license plate recognition errors, where the license plate image captured by the lane camera does not match the actual license plate, or the license plate cannot be identified due to weather, obstruction, or other factors. In such cases, manual verification of the actual license plate information is required to match the passage record.

[0047] Route-related special situations: These refer to situations where a vehicle's travel trajectory does not conform to the normal road network traffic logic, leading to abnormalities in toll calculation or information verification. For example, U / J turn special situations, where a U turn means that a vehicle enters from a toll station but does not go to another toll station, but instead turns around and exits from the same toll station; and a J turn means that a vehicle enters the road from a toll station and exits from an adjacent or nearby toll station within a short distance. Both of these situations will make it difficult for the system to calculate the toll according to the normal route, and additional verification of the vehicle's actual driving intention and trajectory is required.

[0048] Information missing situation: This refers to situations where key vehicle passage information is incomplete, such as no entry information. That is, when a vehicle arrives at the exit toll station, the system cannot find its card collection / ETC passage record at the entry toll station, and manual tracing of the entry information is required to confirm the tolling starting point.

[0049] Compliance-related special circumstances: These refer to situations where vehicles do not comply with highway traffic regulations, such as overloading or exceeding weight or size limits. In such cases, the actual load must be verified using weighing equipment, and the decision on whether passage is permitted and the corresponding fees charged must be made in accordance with policy regulations. This also includes green channel vehicle inspections, where a vehicle claims to comply with the free transportation policy for fresh agricultural products, but manual verification is required to confirm whether the goods are within the scope of the catalog. This is a special circumstance requiring special review.

[0050] In handling the aforementioned special situations, the existing model requires a passive response, with processing only triggered after the vehicle enters the lane; it involves single-station processing, preventing data sharing across road segments; and it is manually controlled, lacking intelligent prediction and allocation.

[0051] To address the aforementioned problems, this invention provides a centralized cloud-based emergency response and control method based on a highway toll collection system.

[0052] First, the application system implemented by the method of the present invention will be introduced. The deployment locations of the centralized special situation cloud handling control system of the present invention include: toll stations, road sections, and road section control centers.

[0053] The toll stations are used to deploy terminal equipment and edge nodes. The terminal equipment includes gantry systems, lane cameras, ETC antennas, and handheld terminals, which can collect vehicle characteristics and transaction data.

[0054] The edge nodes are equipped with trained AI multi-classification prediction models. Based on real-time collected vehicle data and shared multi-source vehicle data, the AI ​​multi-classification prediction models perform special situation predictions, predicting whether a vehicle will exit the road at this station and the types of special situations that may occur, and synchronize the special situation prediction results to the cloud hub platform.

[0055] Some terminal equipment is also deployed between road sections. For example, a gantry system can be deployed. The gantry system acts as a data collection device, transmitting real-time data of passing vehicles to the toll station in real time, ensuring that the edge node AI multi-classification prediction model or other systems can perform vehicle identification or special situation prediction.

[0056] Preferably, when deploying gantry systems between road sections, the distance should be at least 20 km from the nearest toll station to ensure that the system can predict emergencies in advance and push early warning information to the handheld terminals of on-duty personnel at least 5 minutes later, including the type of emergency, vehicle characteristics, and suggested handling procedures.

[0057] The road section control center is used to deploy the cloud hub platform, which is responsible for cross-station data aggregation, AI model training, and global task scheduling.

[0058] Example 1:

[0059] Based on the above-mentioned centralized emergency cloud-based response and control system deployment, such asFigure 1 and Figure 2 As shown, this embodiment discloses a centralized emergency cloud-based handling and control method based on a highway toll system, including the following steps:

[0060] S1. Collect multi-source vehicle data through terminal equipment at each station, clean the heterogeneous data, and share the processed data across road segments.

[0061] Terminal equipment includes gantry systems, lane cameras, ETC antennas, and handheld terminals. The collected multi-source vehicle data includes vehicle location, speed, route information, license plate, axle load, overload status, vehicle type, and historical transaction records.

[0062] This step can break down traditional single-station data silos and achieve cross-segment data interconnection and interoperability through data collection, heterogeneous cleaning, and shared storage.

[0063] First, multi-source vehicle data is collected. Relying on lane-level terminal equipment at stations, data is collected from multiple dimensions, including dynamic path tracking, static vehicle attributes, and transaction history, to ensure that data covers the entire vehicle passage link.

[0064] The gantry system is deployed at toll stations or road sections. The gantry system captures vehicle dynamic information in real time, including: real-time vehicle location, speed, timestamp of passing through the gantry, and cumulative mileage. The gantry camera can help identify preliminary license plate information for subsequent cross-verification with data from other devices.

[0065] ETC device data collection involves interacting with the vehicle's OBU / ETC card via the lane's ETC antenna to collect core vehicle identity and historical transaction data, including vehicle type, license plate number (accurate matching), OBU device number, historical travel routes, and ETC account status.

[0066] The toll stations are equipped with lane cameras, axle load meters, and handheld terminals to collect on-site vehicle status data. Among them, the lane cameras can identify license plate color, vehicle appearance, whether the license plate is obscured, and signs of overloading in high definition; the axle load meters detect the total weight of the vehicle and the weight of each axle to determine whether it is overloaded; and the handheld terminals can obtain special information entered by on-site personnel (such as the type of goods for green channel vehicles and descriptions of abnormal vehicle conditions).

[0067] Then, heterogeneous data cleaning is performed, which can be done through collaborative execution by edge nodes and cloud hub platforms.

[0068] Because the data collection equipment comes from different manufacturers—for example, gantry systems and ETC devices belong to different suppliers—the data formats are heterogeneous. For instance, timestamp formats differ between “YYYY-MM-DDHH:MM:SS” and “YYYY / MM / DDHHMMSS”. Standardization is needed to eliminate this heterogeneity, including:

[0069] To unify the data format, edge nodes can be used to call preset format conversion algorithms to convert it into a standard JSON structure of "timestamp-license plate-vehicle type-vehicle speed-core business field".

[0070] Then, the JSON structure data is processed for missing data, format errors, and logical conflicts. Among them, the handling of missing values ​​includes processing if a certain field is missing, such as weight axle load data, which can be supplemented by calculating it from the default weight of similar models and the speed of adjacent masts.

[0071] Outlier removal involves identifying and deleting obviously erroneous data, such as speed fields showing 200 km / h or -20 km / h, which are determined to be equipment malfunction data and replaced with the average speed of adjacent gantry units.

[0072] Filter out redundant fields that are irrelevant to the handling of special situations, remove redundant information, and merge duplicate data. For example, when the same vehicle passes through multiple gantries, duplicate path records are generated. Keep the record with the latest timestamp and delete redundant data to make the data more concise and efficient.

[0073] Through the above processing, complete, accurate vehicle data conforming to the standard JSON structure is obtained; finally, the vehicle data in the standard JSON structure is synchronized to the cloud hub platform to achieve cross-road segment data sharing.

[0074] S2. Deploy the trained AI multi-class prediction model, based on real-time collected vehicle data and shared multi-source vehicle data, to predict special situations, whether a vehicle will exit at this station, and the types of special situations that may occur, and synchronize the special situation prediction results to the cloud central platform.

[0075] AI multi-class prediction models can be built on LSTM (Long Short-Term Memory) networks and trained on a cloud-based platform. The training samples include at least three years of historical incident data within the road segment, and are updated in real time. By continuously incorporating new incident data, the timeliness and accuracy of the model are ensured.

[0076] During model training, historical incident data is analyzed from multiple dimensions to uncover the correlation between different features. When making predictions, the model uses real-time collected vehicle data and shared multi-source data, combined with the feature patterns it has learned, to accurately determine whether a vehicle will exit at this station and the types of incidents that may occur.

[0077] The training of the AI ​​multi-class prediction model relies on the cloud hub platform, while the front-end deployment relies on edge nodes. By combining real-time data collection and cross-road segment data sharing, special situation prediction is achieved, completing the entire process of model training, model deployment, data collection input, and prediction result synchronization. The AI ​​multi-class prediction model deployment adopts a distributed architecture of cloud hub platform training and edge node deployment inference, which balances training accuracy and real-time prediction efficiency.

[0078] The cloud-based central platform will solidify the LSTM multi-class prediction model trained on three years of historical special situation data within the road segment into a lightweight inference model file. The model can have built-in weight parameters for a 128-dimensional feature vector, including training weights for vehicle features, path features, and environmental features, ensuring that edge nodes can directly call upon them.

[0079] After the model training and update are completed, the cloud hub platform distributes the lightweight model file to all toll station edge nodes through a batch push mechanism. The edge nodes then deploy the model. After receiving the model, the edge nodes automatically deploy it to the local server and connect it with the local data acquisition interface and the cloud hub platform data synchronization interface to ensure that the model can obtain input data in real time.

[0080] Furthermore, the cloud hub platform establishes a model version management mechanism with real-time update triggers. When new special case samples are added, such as a combination of new ETC card failure and over-limit situations, incremental model training is automatically started. Training can be based on the existing LSTM model parameters iteratively, rather than retraining, thus shortening the training time. After training is completed, a version is pushed. The new version of the trained model is pushed to edge nodes in batches through the cloud hub platform. After receiving the new version, the edge nodes automatically replace the old version. The replacement process adopts a dual-instance operation mechanism, which can ensure that the current prediction business is not interrupted.

[0081] Furthermore, when deploying AI multi-class prediction models, the front end is deployed on edge nodes, while the back end runs on a cloud hub platform, balancing data utility.

[0082] The front-end (edge ​​node) focuses on low-latency real-time processing, deploying modules directly related to short-range vehicle prediction, enabling real-time processing of local site data, reducing data transmission volume, and ensuring real-time performance within a warning window of at least 20KM.

[0083] The front-end deployment model receives real-time data collected from terminal devices and uses a lightweight inference submodule to deploy a compressed LSTM lightweight model from the cloud hub platform. It outputs whether a vehicle exits at this station and preliminary predictions of basic emergency types, with low inference latency. This ensures timely emergency warnings and avoids lane congestion.

[0084] The front-end model processing results can be filtered to select high-confidence results and synchronized to the cloud hub platform, reducing the transmission of invalid data to the cloud hub platform and improving the subsequent processing efficiency of the cloud hub platform.

[0085] The backend (cloud hub platform) focuses on global data optimization, deploying modules that require cross-segment data support and high computing power, improving the global adaptability of the model, and avoiding accuracy limitations caused by insufficient computing power at edge nodes.

[0086] The backend deploys a global feature fusion submodule, which supplements global features such as historical cross-segment incident records of vehicles and traffic flow characteristics of adjacent road segments by calling cross-segment shared data stored on the blockchain. It optimizes prediction accuracy using global data from the cloud hub platform and can correct the prediction probability of edge nodes by combining vehicle over-limit records in adjacent road segments. The backend runs a complete LSTM model to perform secondary optimization on the high-confidence results synchronized by edge nodes, optimizes the output prediction results, and achieves accurate optimization of real-time response at the edge center.

[0087] When in use, the edge nodes integrate real-time collected data and cross-segment shared data to construct a 128-dimensional feature vector that meets the model input requirements.

[0088] The real-time data collection includes vehicle dynamic data obtained from terminal devices such as gantry systems, ETC devices, and toll station terminals, including real-time features such as current speed, real-time distance to the nearest toll station, current axle load, and real-time ETC transaction status.

[0089] Among them, cross-road segment shared data includes historical vehicle data retrieved from the blockchain storage network, which can include multi-dimensional shared features such as the number of cross-road segment passages in the past 3 months, historical U / J turn special incident records, overweight records in the past month, and historical inspection results of green channel vehicles.

[0090] Edge nodes integrate real-time collected data and cross-segment shared data to generate a 128-dimensional standardized feature vector, which serves as input data for the LSTM model. The edge nodes then invoke the deployed LSTM model to perform a two-dimensional prediction based on the input feature vector, determining whether a vehicle will exit at this station and the type of potential emergency.

[0091] Edge nodes monitor vehicle location in real time. When a vehicle is at least 20km away from the nearest toll station (calculated using real-time location data from the inter-segment gantry system), an emergency prediction process is automatically triggered.

[0092] The model outputs a special situation prediction, including the probability value of whether the vehicle will exit at this station. For example, if the probability is ≥80%, it is determined that the vehicle will exit; if the probability is <80%, it is determined that the vehicle will not exit. If it is determined that the vehicle will exit, the model further predicts the type of special situation and outputs the possible types of special situations and their corresponding probabilities. For example, the output is a 90% probability of an over-limit special situation and a 10% probability of a special situation with no entry information. The model selects the 1-2 special situations with the highest probabilities as the main predicted special situations and performs push processing.

[0093] Furthermore, edge nodes can also perform rule-based validation on the model output results. For example, if the model predicts that a vehicle is overloaded, but cross-road segment shared data shows that the vehicle has no overload records in the past 3 months and the real-time axle load data is normal, the system marks the prediction result as low confidence and increases the attention priority of other special situations to avoid misjudgment.

[0094] Edge nodes synchronize the special situation prediction results to the cloud hub platform. Through the real-time data synchronization mechanism, the cloud hub platform provides a basis for subsequent dynamic task allocation and cross-terminal collaborative handling. After receiving the data, the cloud hub platform automatically stores it in the special situation prediction result database and associates it with the cross-road segment shared data of the vehicle to ensure that the historical data of the prediction results can be obtained synchronously when called in the future.

[0095] S3. If it is predicted that a vehicle will exit the road at this station and an emergency may occur, the cloud hub platform will monitor the workload of the staff at each station in real time, automatically transfer the task to an available staff, provide early warning and dynamically allocate emergency tasks, and the staff will complete the emergency task handling.

[0096] By monitoring the current workload of special tasks handled by personnel at each station in real time, calculating the load factor, and prioritizing the allocation of tasks to personnel with lower load factors; establishing a personnel skill tag library, and prioritizing the allocation of tasks to personnel with corresponding tags based on the predicted type of special task; when the task load of personnel at a certain station is saturated, the cloud hub platform prioritizes transferring tasks to available personnel in adjacent road sections based on the task type.

[0097] The cloud-based central platform filters synchronized emergency prediction results and initiates a task allocation process for vehicles that meet the criteria for exiting the station or are experiencing emergencies. This achieves cross-station support collaboration through accurate prediction, balanced task allocation, and skill matching, transforming emergency tasks from passive reception to proactive allocation. Specifically:

[0098] If it is determined that the vehicle will exit at this station, which is a high-probability emergency situation, the emergency task allocation process will be triggered, and task allocation will be initiated. Emergency tasks will be dynamically allocated.

[0099] First, a preliminary task priority assessment is performed. For tasks that are triggered and assigned, priority is marked according to the urgency of the incident type. For example, incidents that may cause on-site delays or safety risks, such as ETC transaction failure leading to lane congestion or overloading posing safety hazards, are marked as high priority; routine incidents such as green channel vehicle inspections or route verification due to lack of entry information are marked as medium priority; and incidents that do not affect traffic efficiency, such as abnormal toll display or slightly blurred license plates requiring confirmation, are marked as low priority.

[0100] The cloud hub platform collects real-time task processing status data from personnel at each site, and addresses the issue of uneven workload by quantifying load factors. Specifically:

[0101] The cloud hub platform connects with the terminal systems of personnel at each site to obtain real-time data on the number of tasks currently being processed, the number of outstanding special cases being handled by personnel, and the average response time for each task. The cloud hub platform uses a weighted algorithm to calculate the load factor for each personnel on duty, using the following formula:

[0102]

[0103] in, t is the load factor, n is the number of tasks currently being processed, N is the maximum number of tasks that can be carried, t is the average response time, t0 is the standard response time, 0.6 and 0.4 are the allocation system, the maximum number of tasks that can be carried can be set to 3, and the standard response time can be set to 10 seconds.

[0104] For example: If a staff member is currently handling 2 tasks with an average response time of 8 seconds, then the load factor is... =(2 / 3)×0.6+(8 / 10)×0.4=0.4+0.32=0.72.

[0105] The status of on-duty personnel is classified according to the load factor, which serves as the basis for task allocation: Idle status, load factor < 0.6, indicates that the current task volume is low, the response is timely, and priority is given to allocation; Normal status, 0.6 ≤ load factor < 0.9, indicates that the task volume is moderate and low-priority tasks can be received; Saturated status, load factor ≥ 0.9, indicates that the task volume exceeds the capacity limit, no new tasks are allocated, and cross-site transfer is required.

[0106] Furthermore, based on the skill tags of on-duty personnel, the cloud hub platform can accurately match tasks and ensure that tasks are assigned to on-duty personnel with corresponding handling capabilities by mapping the special situation type to the skill tags, thus avoiding mismatches that lead to low handling efficiency.

[0107] First, a personnel skill tag library is built and updated. Tag categories are set according to special situation types, including skill categories such as green channel inspection expert, ETC fault handling specialist, overload inspection specialist, and no-entry information inspector. Tag values ​​are assigned through a two-way mechanism of manual annotation and automatic system update.

[0108] Based on the training qualifications and job responsibilities of the on-duty personnel, the person in charge enters the initial tags into the system. Furthermore, the system iterates the tags based on the historical handling data of the on-duty personnel.

[0109] When the workload of staff at a certain station reaches saturation, the cloud hub platform prioritizes transferring tasks to available staff on adjacent road sections based on task type, ensuring that tasks are not delayed. Specifically:

[0110] If the current site's candidate allocation list is empty, the cloud hub platform determines that the site's corresponding type of emergency handling load is saturated. Based on a preset road segment coordination relationship table, the cloud hub platform searches for personnel with the corresponding skill tags and a load coefficient < 0.6 in adjacent road segments. It first searches for the geographically closest adjacent road segments to ensure controllable response delays. A cross-road segment candidate personnel list is then generated, and the personnel's road segment, current load coefficient, and skill tag matching degree are marked. Based on the predicted emergency type, the cloud hub platform pushes the emergency handling task (including vehicle prediction information, shared data, and handling suggestions) to the terminals of the cross-road segment candidate personnel.

[0111] Furthermore, the cloud hub platform synchronizes task transfer information with the current site edge nodes and cross-segment edge nodes to ensure that both ends are aware of the task's ownership and avoid duplicate allocation.

[0112] S4. When on-duty personnel complete the handling of special situations, they generate a processing report that includes the handling process and the results.

[0113] After the cloud hub platform completes the task allocation, it ensures that the on-duty personnel are prepared in advance by using multi-terminal early warning and full information push. The cloud hub platform pushes early warning information to multiple terminals.

[0114] For example: push pop-up alerts to the handheld terminals of assigned personnel, displaying core information (including vehicle prediction information, shared data, and handling suggestions); pop up a task receiving window on the computer-based handling platform, displaying complete alert information and data access links, allowing personnel to directly click to view vehicle shared data; if it is a high-priority emergency, the task information is simultaneously displayed on the large screen in the station's duty hall, facilitating on-site management personnel to coordinate and cooperate.

[0115] Based on early warning information and their authorized permissions, on-duty personnel prepare in advance. For example, if an overload situation is predicted, they bring a handheld weighing terminal to the corresponding exit lane in advance; if a green channel inspection is predicted, they retrieve the green channel inspection standards in advance. If on-site verification is not required, on-duty personnel can remotely operate the terminal equipment through the cloud platform, such as adjusting the toll display to ask to retry the ETC card swipe, or controlling the barrier gate to pre-raise. If on-site verification is required, on-duty personnel use the handheld terminal to collect on-site data when the vehicle arrives at the lane and compare it with the shared data.

[0116] After the task is completed, the on-duty personnel enter the results into the terminal system and simultaneously upload the on-site documentation. The terminal system automatically synchronizes the results to the cloud hub platform, which then links the task's process and outcome to generate a processing report, providing data support for subsequent AI model optimization and skill tag updates.

[0117] Furthermore, the training database for the AI ​​multi-class prediction model can be updated based on the processing report to perform iterative optimization of the model. By leveraging the data from the processing report, the training database for the AI ​​multi-class prediction model can be incrementally updated, completing iterative optimization of the model and achieving the goal of improving the accuracy of the model's predictions on a regular basis. Simultaneously, the personnel skill tag library can be optimized to improve the overall efficiency of handling special situations.

[0118] Furthermore, when synchronizing standardized data, special situation predictions, task allocation, and handling results to the cloud hub platform, a blockchain-enhanced storage model is adopted.

[0119] By adopting a blockchain storage model and through distributed storage and data synchronization mechanisms, it is possible to achieve one-time entry and network-wide sharing, solving the problems of data fragmentation and difficulty in data integration and sharing in traditional single-site systems.

[0120] In a blockchain storage model, each node can synchronize data in real time. When a toll station enters emergency-related data, other nodes can quickly retrieve it, greatly improving the efficiency of information flow. Simultaneously, the immutability of blockchain ensures the authenticity and reliability of the data. During emergency response, whether it's the predicted outcome, the handling process, or the final result, once recorded on the blockchain, it cannot be arbitrarily modified. This provides a solid foundation for subsequent data analysis and accountability.

[0121] A cross-road segment blockchain storage network is built on the cloud hub platform. Each toll station edge node serves as the blockchain's ledger node. When standardized data, emergency predictions, task allocation, and handling results are uploaded to the blockchain synchronously, an immutable hash value (including data content, upload time, node number, etc.) is automatically generated to ensure that vehicle passage records are not forged or tampered with, providing a reliable basis for subsequent cross-road segment emergency handling.

[0122] Furthermore, edge nodes can synchronize local data to the cloud hub platform in real time, and edge nodes can also upload full historical data to the cloud hub platform during off-peak hours, such as all vehicle passage records for the day.

[0123] When a vehicle travels across provinces or road sections, the edge nodes at the target site can access the historical shared data stored on the vehicle's blockchain through the cloud hub platform. For example, if a vehicle travels from road section A to road section B, the toll station on road section B does not need to re-collect the vehicle's historical transaction records and previous route information. Instead, it can directly retrieve the data already uploaded from road section A from the blockchain network, enabling data to flow with the vehicle and avoiding duplicate verification.

[0124] Furthermore, information related to emergency predictions can be pushed to vehicles to guide drivers in handling emergencies. By leveraging the collaboration between the cloud hub platform, edge nodes, and vehicle interaction terminals, the system can accurately push emergency prediction information, guiding drivers to actively cooperate and improving the efficiency of emergency response.

[0125] Based on AI-powered situation predictions, the cloud-based central platform filters vehicles for which information needs to be pushed, ensuring that the push is only directed to the target vehicles that require cooperation in handling, thus avoiding invalid pushes. At the same time, if the cloud-based central platform determines that the prediction result has high credibility, it will trigger the vehicle information push; if it does not meet the high credibility requirement, it will archive the prediction result and not initiate the push, thus avoiding interference with the driver.

[0126] Furthermore, the cloud-based central platform prioritizes push notifications based on the urgency of the situation and the need for cooperation, only sending notifications when the vehicle is at least 10 kilometers from the toll station to avoid frequent interruptions. Push notifications integrate core data and are generated with a focus on simplicity, clarity, and guidance to ensure drivers quickly understand the requirements.

[0127] The push notification can include: the type of emergency, the target toll station, the processing lane, and vehicle information data, while also providing suggestions for handling and cooperating, which are translated into actionable guidance for drivers. For example, for green channel emergencies, it is recommended to prepare the driver's license and cargo list in advance.

[0128] Push notifications can be sent through multiple channels. For example, they can be sent via the vehicle's OBU terminal, using short text and icons, with no more than 50 characters. A possible push notification message could be: "[Special Warning] Anhui A-XXXXX, estimated arrival at XX exit in 3 minutes. Please enter XX lane. High risk of overloading. Please open the cargo door for weighing."

[0129] Furthermore, in-vehicle software systems (such as navigation apps) can be used to enable pre-registration and linkage between the software and the system of this invention, employing pop-up windows and voice broadcast formats, with voice content synchronized with text information. Additionally, information such as vehicle details, emergency type, expected arrival lane, cooperation requirements, and contact numbers can be sent via the vehicle owner's pre-registered mobile phone number.

[0130] Based on the above methods, emergency information can be quickly and accurately pushed out, allowing drivers to understand the emergency situation their vehicles are facing in a timely manner, so as to make corresponding preparations in advance and effectively improve the efficiency of handling emergency situations at highway toll booths.

[0131] The present invention also provides an electronic device, Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention, such as... Figure 3 As shown, the electronic device may include a processor, a communications interface, memory, and a communication bus, wherein the processor, communications interface, and memory communicate with each other via the communication bus. The processor can invoke logical instructions from the memory, for example, to execute the following method:

[0132] S1. Collect multi-source vehicle data through terminal equipment at each station, clean the heterogeneous data, and share the processed data across road segments.

[0133] S2. The AI ​​multi-class prediction model, after being trained and deployed at the edge nodes, performs special situation prediction based on real-time collected vehicle data and shared multi-source vehicle data. It predicts whether a vehicle will exit the road at this station and the types of special situations that may occur, and synchronizes the special situation prediction results to the cloud hub platform.

[0134] S3. If it is predicted that a vehicle will exit at this station and an emergency may occur, the cloud hub platform will monitor the workload of the personnel on duty at each station in real time, dynamically allocate emergency tasks, and issue early warnings.

[0135] S4. The on-duty personnel complete the handling of special situations and generate a processing report on the handling process and results.

[0136] Furthermore, the logical instructions in the aforementioned memory can be implemented as software functional units and sold or used as independent products, and can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0137] This invention also provides a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, is implemented to perform the methods provided in the above embodiments, including, for example:

[0138] S1. Collect multi-source vehicle data through terminal equipment at each station, clean the heterogeneous data, and share the processed data across road segments.

[0139] S2. The AI ​​multi-class prediction model, after being trained and deployed at the edge nodes, performs special situation prediction based on real-time collected vehicle data and shared multi-source vehicle data. It predicts whether a vehicle will exit the road at this station and the types of special situations that may occur, and synchronizes the special situation prediction results to the cloud hub platform.

[0140] S3. If it is predicted that a vehicle will exit at this station and an emergency may occur, the cloud hub platform will monitor the workload of the personnel on duty at each station in real time, dynamically allocate emergency tasks, and issue early warnings.

[0141] S4. The on-duty personnel complete the handling of special situations and generate a processing report on the handling process and results.

[0142] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0143] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0144] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A centralized emergency cloud-based handling and control method based on a highway toll system, characterized in that, include: S1. Collect multi-source vehicle data through terminal equipment at each station, clean the heterogeneous data, and share the processed data across road segments. S2. The AI ​​multi-class prediction model, after being trained and deployed at the edge nodes, performs special situation prediction based on real-time collected vehicle data and shared multi-source vehicle data. It predicts whether a vehicle will exit the road at this station and the types of special situations that may occur, and synchronizes the special situation prediction results to the cloud hub platform. S3. If it is predicted that a vehicle will exit at this station and an emergency may occur, the cloud hub platform will monitor the workload of the personnel on duty at each station in real time, dynamically allocate emergency tasks, and issue early warnings. S4. The on-duty personnel complete the handling of special situations and generate a processing report on the handling process and results; The AI ​​multi-class prediction model is built on LSTM and trained on a cloud hub platform. The training samples include at least 3 years of historical special situation data within the road segment and are updated in real time. The dynamic allocation of special task in S3 includes: Real-time monitoring of the current workload of special tasks handled by personnel at each station, calculation of load coefficient, and priority allocation of tasks to personnel with lower load coefficients; Establish a personnel skill tag database and prioritize assigning skills to personnel with corresponding tags based on the type of special situation task prediction; When the workload of the staff at a certain station is saturated, the cloud hub platform will prioritize transferring the task to available staff in adjacent road sections based on the task type. Update the training database of the AI ​​multi-class prediction model based on the processing report, and perform iterative optimization of the model; When deploying the AI ​​multi-class prediction model, the model is deployed in layers, with the front end deployed on edge nodes and the back end running on the cloud hub platform, balancing data utility. When synchronizing standardized data, special situation predictions, task allocation, and handling results to the cloud hub platform, a blockchain-enhanced storage model is adopted.

2. The control method according to claim 1, characterized in that, The terminal equipment includes a gantry system, lane camera, ETC antenna, and handheld terminal. The collected multi-source vehicle data includes vehicle location, speed, route information, license plate, axle load, overload status, vehicle type, and historical transaction records.

3. The control method according to claim 1, characterized in that, The process of cleaning heterogeneous data includes: S11. Convert non-uniform format vehicle data collected from different manufacturers and different types of equipment into JSON structure data; S12. Handle missing data, format errors, and logical conflicts in JSON structured data; S13. Filter out redundant fields that are irrelevant to the handling of special situations, remove redundant information, and obtain complete, accurate vehicle data that conforms to the standard JSON structure. S14. Synchronize vehicle data in standard JSON structure to the cloud hub platform to achieve cross-road segment data sharing.

4. The control method according to claim 1, characterized in that, The early warning includes: The system pushes early warning information to the handheld terminals of on-duty personnel at least 5 minutes in advance. The early warning information includes the type of emergency, vehicle characteristics, and suggested handling procedures.

5. The control method according to claim 1, characterized in that, Information related to emergency predictions is pushed to the vehicle to guide the driver in handling emergency situations.

Images