ETC gas station handheld interactive device terminal

Abstract

The application discloses an ETC gas station handheld interaction device terminal, relates to the technical field of ETC gas station interaction devices, and aims to solve the technical problems of being unable to accurately diagnose faults and only being able to manually pay when ETC gas station device OBU reading fails, resulting in settlement lag and channel congestion, and comprises a handheld interaction device terminal body, a cloud data processor, a gas dispenser control system, a fee settlement processor, a fault repair tracking module and a multi-system data encryption interaction module; the handheld interaction device terminal body is used for reading vehicle ETC vehicle-mounted OBU information, triggering intelligent fault diagnosis and switching to an aggregated payment mode when reading fails, and simultaneously receiving confirmation feedback of the vehicle owner on fault prompts. The application has the advantages of accurately diagnosing OBU faults, automatically switching to aggregated payment, solving settlement lag and congestion, and providing a repair scheme.

Description

Technical Field

[0001] This invention relates to the field of ETC gas station interactive equipment technology, and more specifically, to an ETC gas station handheld interactive equipment terminal. Background Technology

[0002] With the widespread adoption of ETC technology in the transportation sector, ETC-enabled contactless refueling services are gradually being implemented at highway service area gas stations and gas stations in urban core commercial districts. The core need in these scenarios is to quickly complete refueling settlements, especially during peak traffic periods such as holidays, when drivers have an even more pressing demand for refueling efficiency. However, existing ETC gas station interactive devices have significant limitations: when a vehicle's ETC on-board unit (OBU) fails to read data due to signal obstruction, improper installation location, inactivation, or hardware failure, the device cannot accurately pinpoint the cause of the fault and can only switch directly to the traditional manual payment mode. This not only causes delays in the settlement process and prolongs the waiting time for drivers but also easily leads to congestion in the refueling lanes. At the same time, drivers cannot obtain targeted repair guidance for OBU malfunctions, and they will have to wait again when encountering similar problems in the future, seriously affecting the user experience. In view of this, we propose a handheld interactive device terminal for ETC gas stations. Summary of the Invention

[0003] The purpose of this invention is to provide a handheld interactive device terminal for ETC gas stations to solve the technical problems of inaccurate fault diagnosis and manual payment when the OBU of the ETC gas station fails to read the device, resulting in settlement delays and lane congestion.

[0004] To solve the above-mentioned technical problems, the present invention provides the following technical solution: an ETC gas station handheld interactive device terminal, comprising: a handheld interactive device terminal body, a cloud data processor, a gas pump control system, a payment settlement processor, a fault repair and tracking module, and a multi-system data encryption and interaction module; The handheld interactive device terminal is used to read the vehicle's ETC on-board unit (OBU) information. If the reading fails, it triggers intelligent diagnosis of the fault cause and switches to the aggregated payment mode. At the same time, it receives confirmation feedback from the vehicle owner regarding the fault prompt. The cloud data processor is connected to the handheld interactive device terminal, the fuel dispenser control system, the vehicle management office's vehicle model database, and the ETC issuer's fault handling system. It receives diagnostic results, synchronizes refueling operation data and real-time traffic data at the gas station, obtains vehicle information and OBU fault repair resources, and generates differentiated guidance strategies. The fee settlement processor communicates with the cloud data processor and pushes payment results, diagnostic related service information and OBU fault repair progress prompts to the vehicle owner's mobile device; The fault repair tracking module is linked to the cloud data processor and the gas station customer service system to realize a closed loop of fault handling work order generation, push, progress tracking and owner feedback.

[0005] Preferably, the handheld interactive device terminal body has a built-in fault diagnosis module, which is used to perform layered detection of the cause of OBU reading failure and owner feedback interaction. First, the signal strength is detected by the dedicated ETC frequency band antenna to determine whether there is signal obstruction or the distance is too far. The detection results are displayed in real time on the screen of the handheld interactive device terminal and the driver is prompted to confirm. When the signal detection is normal, the system interacts with the OBU through the general communication protocol of the ETC device to determine whether the protocol handshake has failed or the OBU hardware is faulty. At the same time, a fault type description is generated and pushed to the vehicle owner's mobile terminal for the vehicle owner to view and confirm. When there are no abnormalities in the protocol interaction, the cloud data processor is associated to query the OBU activation information or obtain the OBU power data to determine whether the OBU power is insufficient or not activated. The corresponding fault repair suggestions are generated simultaneously and the vehicle owner's confirmation feedback on the suggestions is obtained. The feedback results are uploaded to the cloud data processor. To quantify the correlation between signal strength detection results and fault diagnosis, the fault diagnosis module calculates the signal obstruction probability using the following algorithm formula to assist in determining the cause of the fault: ; in, For signal obstruction probability, This refers to the actual OBU signal strength detected by the handheld terminal. Standard signal strength for OBU devices. The signal attenuation coefficient is... This represents the actual distance between the handheld terminal and the OBU.

[0006] Preferably, the cloud data processor has a built-in scenario-based guidance strategy generation module. After receiving the fault diagnosis results and the car owner's feedback information, the module combines the real-time time information of the gas station with the real-time traffic data of the gas station synchronized by the cloud data processor to determine whether it is a peak traffic period and the current congestion status of the refueling lane. If it is a peak period and the corresponding lane is congested, a strategy of "simplified aggregated payment process + dynamic diversion guidance prompts" is generated. The simplified aggregated payment process includes canceling the paper voucher printing option by default and prioritizing the display of commonly used payment method entrances. The dynamic diversion guidance prompts are combined with the gas station lane layout information and pushed to the handheld interactive device terminal screen and the gas station lane guidance screen to guide staff to guide vehicles to the available temporary payment area. If it is during off-peak hours or when the channel is idle, a strategy of "aggregated payment + fault-related service entry + repair progress tracking" will be generated. The service entry includes cooperative service links for OBU application, activation, and battery replacement. The repair progress tracking function is linked to the fault handling system data of the ETC issuer. To accurately determine the congestion status of refueling lanes and match diversion strategies, the scenario-based guidance strategy generation module calculates the lane congestion index using the following algorithm formula: ; in, For the first Congestion index of each refueling lane. For the first The number of vehicles currently queuing in each lane. For the first The historical average refueling time for each lane For the first The maximum number of vehicles that each lane can accommodate. Standard refueling time, For the first The average probability of OBU signal obstruction for each channel.

[0007] Preferably, the cloud data processor establishes a communication connection with the vehicle management office's vehicle model database; After the handheld interactive device terminal collects vehicle license plate information and uploads it to the cloud data processor, the cloud data processor connects to the vehicle management office's vehicle model database to obtain multi-dimensional vehicle parameters such as vehicle type, vehicle height, driver's cab position, and recommended OBU installation area. If the fault diagnosis result is a signal problem, the cloud data processor combines the acquired vehicle body parameters to determine the source of the signal obstruction and adds OBU installation adjustment suggestions adapted to the vehicle model to the differentiated guidance strategy, including fine-tuning the direction of the installation position and prompts to avoid obstructions. To determine the optimal orientation for OBU installation and adjustment, the cloud data processor calculates the fine-tuning angle of the installation location using the following algorithm: ; in, Fine-tune the angle of the OBU installation position. The height of the windshield in front of the vehicle's driver's cab. This represents the current installation height of the OBU. The horizontal distance between the OBU and the handheld terminal. , These represent the standard signal strength of the OBU and the actual detected signal strength, respectively. This is the vehicle model correction factor.

[0008] Preferably, the cloud data processor only acquires activation links, binding process instructions, and repair progress data related to the currently faulty OBU; If the fault diagnosis result is that the OBU is not activated or the binding is invalid, the cloud data processor obtains the corresponding OBU repair resources through this interface, generates a "payment-repair" associated data package by associating it with the aggregated payment order information, and sends it to the fee settlement processor. The toll settlement processor pushes the payment result, repair resources, and repair progress query entry from the data packet to the vehicle owner's mobile device. After the vehicle owner provides feedback on the repair operation progress through the progress query entry, the cloud data processor receives the feedback information and synchronizes it to the ETC issuer's fault handling system to update the work order progress. At the same time, the toll settlement processor pushes progress update prompts to the vehicle owner. To quantify the OBU repair progress and trigger progress notifications, the cloud data processor calculates the repair completion rate using the following algorithm: ; in, For OBU repair completion rate, This represents the number of repair steps completed by the car owner. This represents the total number of steps required for OBU repair. This represents the probability of OBU signal occlusion.

[0009] Preferably, the ETC-dedicated frequency band antenna of the handheld interactive device terminal body is an adjustable gain antenna, and the antenna gain adjustment logic is associated with the vehicle information obtained by the cloud data processor; When the fault diagnosis module detects insufficient signal strength, the cloud data processor sends a gain adjustment suggestion adapted to the vehicle model to the handheld interactive device terminal body based on the acquired vehicle type and body parameters. The handheld interactive device terminal automatically adjusts the antenna gain amplitude according to the suggestion, and prompts the staff to adjust the relative position of the handheld terminal and the vehicle. It then attempts to read the OBU information a second time. If the second reading still fails, the fault diagnosis module records the current vehicle model, antenna gain parameters and reading failure scenario, and uploads it to the cloud data processor to optimize the subsequent gain adjustment logic, and then triggers the subsequent fault detection steps and aggregated payment mode switching. To determine the optimal gain adjustment range for the antenna, the cloud data processor calculates the gain adjustment value using the following algorithm: ; in, This is the antenna gain adjustment value. For antenna base gain, , These represent the standard signal strength of the OBU and the actual detected signal strength, respectively. This is the vehicle model correction factor.

[0010] Preferably, the top of the handheld interactive device terminal is equipped with a vehicle model recognition auxiliary camera. The vehicle exterior image captured by the camera is encrypted by a multi-system data encryption interaction module and then uploaded to the cloud data processor. When the cloud data processor is unable to obtain vehicle type information from the vehicle management office's vehicle model database, staff can use the camera to capture multi-feature images of the vehicle's cab location, body outline, and license plate location. After receiving the image, the cloud data processor extracts key vehicle features using image recognition algorithms and matches them with the vehicle model feature database stored in the database to help determine the vehicle type. If the matching result is a new vehicle model, the cloud data processor records the vehicle model characteristics and the corresponding OBU signal adaptation suggestions, and updates the vehicle model feature database. To quantify vehicle feature matching to determine vehicle model, the cloud data processor calculates the feature matching score using the following algorithm: ; in, The vehicle feature matching score, The number of key vehicle features extracted. For the first The weight of each feature, Extracting the first from the image eigenvalues, For the first in the vehicle feature library Standard values ​​of the feature This represents the probability of OBU signal occlusion.

[0011] Preferably, before the handheld interactive device terminal body establishes a communication connection with the cloud data processor, it needs to complete hierarchical identity authentication through a multi-system data encryption interaction module; The authentication process includes: the handheld interactive device terminal first sends the device identification information and the current staff member's identity information to the cloud data processor, and the cloud data processor verifies the validity of the device identification and the staff member's permission level; If it is a basic operation permission, only OBU read, aggregated payment and data upload functions are authorized; If it is an administrative privilege, additional authorization is granted for viewing fault diagnosis parameters, submitting suggestions for adjusting guidance strategies, and managing work order progress. After authentication is successful, the cloud data processor sends out the authorization command for the corresponding permission, and the handheld interactive device terminal receives the command and starts the corresponding function. To quantify authentication security levels and assign corresponding permissions, the cloud data processor calculates the authentication security score using the following algorithm: ; in, For authentication security score, For the device identification verification results, For staff identity verification results, This determines the encryption strength for data transmission.

[0012] Preferably, the fault repair tracking module includes a work order generation unit, a progress tracking unit, and a vehicle owner feedback unit; The work order generation unit is associated with the cloud data processor. When the fault diagnosis result is an OBU fault that requires subsequent repair, it automatically generates a fault handling work order containing vehicle owner information, vehicle information, fault type, repair resource link, and estimated completion time. The progress tracking unit connects to the gas station customer service system and the ETC issuer's fault handling system to synchronize customer service follow-up records and OBU repair progress in real time and update work order status. The vehicle owner feedback unit pushes the work order progress query portal and feedback questionnaire to the vehicle owner's mobile terminal through the fee settlement processor. After the vehicle owner submits feedback, the feedback information is uploaded to the cloud data processor for optimizing fault diagnosis logic and guidance strategies. Once a work order is completed, the fault repair tracking module generates a work order summary report, which is then synchronized to the cloud data processor and the gas station operations backend. To comprehensively evaluate the quality of work order processing, the fault repair tracking module calculates the work order service score using the following algorithm formula: ; in, Service points for work orders For OBU repair completion rate, Rate the feedback from car owners. Standard processing time for work orders. This refers to the actual processing time for the work order.

[0013] An interaction method for an ETC (Electronic Toll Collection) gas station handheld interactive device terminal includes the following steps: S1. The handheld interactive device terminal reads the vehicle's ETC on-board unit (OBU) information. If the reading fails, the fault diagnosis module is activated. The fault detection is performed in layers, including signal detection, protocol interaction, and OBU information query. The fault diagnosis result is output and displayed on the screen of the handheld interactive device terminal and pushed to the vehicle owner's mobile device to obtain the vehicle owner's confirmation feedback on the fault prompt. S2. The handheld interactive device terminal will encrypt the fault diagnosis results, vehicle owner confirmation feedback information and collected vehicle license plate information through the multi-system data encryption interaction module and then upload them to the cloud data processor. After receiving the encrypted uploaded information, the S3 cloud data processor synchronizes the refueling operation data and real-time vehicle flow data uploaded by the fuel dispenser control system, connects to the vehicle management office's vehicle model database to obtain multi-dimensional vehicle parameters such as vehicle type and vehicle height, connects to the ETC issuer's fault handling system to obtain OBU fault repair resources, and generates differentiated guidance strategies based on the real-time time information of the gas station. The guidance strategies are then fed back to the handheld interactive device terminal through the multi-system data encryption interaction module. S4. After receiving the differentiated guidance strategy, the handheld interactive device terminal automatically switches to the aggregated payment mode, prioritizing the display of payment method entrances adapted to the current scenario for car owners to complete the payment operation, while recording the operation data during the payment process in real time. S5. The handheld interactive device terminal transmits the payment result, payment process operation data and vehicle owner feedback information back to the cloud data processor and fuel dispenser control system. The cloud data processor associates the fault diagnosis results to generate service information containing OBU fault repair suggestions, which is synchronized to the fee settlement processor. At the same time, it triggers the fault repair tracking module to generate a fault handling work order containing vehicle owner information, vehicle information and fault type, and pushes it to the gas station customer service system. S6, the payment settlement processor pushes payment results, service information, and the OBU fault repair progress query portal to the vehicle owner's mobile device; the fault repair tracking module tracks the work order processing progress in real time and pushes progress update prompts to the vehicle owner through the payment settlement processor; after the vehicle owner completes the OBU repair, they submit repair completion feedback through the progress query portal. The feedback information is encrypted and uploaded to the cloud data processor through the multi-system data encryption interaction module. The cloud data processor updates the work order status and generates service summary data, which is synchronized to the gas station operation backend to complete the service loop.

[0014] Compared with the prior art, the beneficial effects of the present invention are: 1. This invention, through a layered fault diagnosis module and an automatic aggregated payment switching function, can quickly locate the cause of the fault at the signal, protocol, and device status levels when a reading fails. At the same time, it skips invalid operations and directly enters the payment process, fundamentally solving the core problems of settlement lag and channel congestion after traditional equipment reading failures.

[0015] 2. This invention also combines the vehicle registration office's vehicle model database with an adjustable gain antenna to generate vehicle model-specific OBU installation and adjustment suggestions and antenna gain optimization schemes for signal-related faults, significantly improving the success rate of fault repair, reducing the occurrence of subsequent recurring faults, and further solving the problem of no effective repair guidance after fault diagnosis.

[0016] 3. Based on a scenario-based guidance strategy and full-process work order tracking, this invention optimizes operational efficiency during peak hours by dynamically diverting traffic and simplifying the payment process, while providing one-stop fault repair services during off-peak hours. At the same time, it continuously optimizes the diagnostic logic through a closed loop of car owner feedback, thereby further improving service adaptability and car owner satisfaction while ensuring settlement efficiency and fault repair. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the system framework of the present invention; Figure 2 This is a schematic diagram of the system flow of the present invention. Detailed Implementation

[0018] To facilitate understanding of the technical solution of the present invention by those skilled in the art, the technical solution of the present invention will now be further described in conjunction with the accompanying drawings.

[0019] Example 1, such as Figure 1 and Figure 2 As shown, the present invention provides an ETC gas station handheld interactive device terminal, including: a handheld interactive device terminal body, a cloud data processor, a gas pump control system, a payment settlement processor, a fault repair and tracking module, and a multi-system data encryption and interaction module; The handheld interactive device terminal is used to read the vehicle's ETC on-board unit (OBU) information. If the reading fails, it triggers intelligent diagnosis of the fault cause and switches to the aggregated payment mode. At the same time, it receives confirmation feedback from the vehicle owner regarding the fault prompt. The cloud-based data processor communicates with the handheld interactive device terminal, the fuel dispenser control system, the vehicle management office's vehicle model database, and the ETC issuer's fault handling system to receive diagnostic results, synchronize fueling operation data and real-time vehicle flow data at the gas station, acquire vehicle information and OBU fault repair resources, and generate differentiated guidance strategies. The fee settlement processor communicates with the cloud data processor to push payment results, diagnostic related service information and OBU fault repair progress prompts to the vehicle owner's mobile device; The fault repair tracking module connects the cloud data processor with the gas station customer service system to realize a closed loop of fault handling work order generation, push, progress tracking and owner feedback; The multi-system data encryption interaction module is used to unify the communication encryption standards and interface permission management between the handheld interactive device terminal, the cloud data processor, and various external systems. After the handheld interactive device terminal executes the guidance strategy to complete the payment, it sends the payment result and the vehicle owner's feedback information back to the cloud data processor and the fuel dispenser control system, forming a service closed loop.

[0020] In an embodiment of the present invention, the handheld interactive device terminal body has a built-in fault diagnosis module, which is used to perform layered detection of the cause of OBU reading failure and vehicle owner feedback interaction. First, the signal strength is detected by the dedicated ETC frequency band antenna to determine whether there is signal obstruction or the distance is too far. The detection results are displayed in real time on the screen of the handheld interactive device terminal and the driver is prompted to confirm. When the signal detection is normal, the system interacts with the OBU through the general communication protocol of the ETC device to determine whether the protocol handshake has failed or the OBU hardware is faulty. At the same time, a fault type description is generated and pushed to the vehicle owner's mobile terminal for the vehicle owner to view and confirm. When there are no abnormalities in the protocol interaction, the cloud data processor is associated to query the OBU activation information or obtain the OBU power data to determine whether the OBU power is insufficient or not activated. The corresponding fault repair suggestions are generated simultaneously and the vehicle owner's confirmation feedback on the suggestions is obtained. The feedback results are uploaded to the cloud data processor. To quantify the correlation between signal strength detection results and fault diagnosis, the fault diagnosis module calculates the signal obstruction probability using the following algorithm formula to assist in determining the cause of the fault: ; in, The signal blockage probability ranges from 0 to 1 and is the core indicator for determining whether signal blockage exists. The higher the value, the greater the possibility that the signal is blocked. The signal strength of the OBU actually detected by the handheld terminal is collected in real time by the signal detection unit built into the handheld terminal, reflecting the actual reception of the OBU signal at present; The standard signal strength of the OBU device is obtained synchronously by the cloud data processor based on the OBU model and manufacturer parameters, and serves as a benchmark value for determining whether the signal is abnormal. The signal attenuation coefficient is calibrated by environmental parameters of the gas station (such as the type of obstruction and the degree of space enclosure) and is used to correct the influence of distance on signal attenuation under different environments. The actual distance between the handheld terminal and the OBU is collected by the ranging module (such as infrared ranging or ultrasonic ranging) built into the handheld terminal, reflecting the spatial relationship between the two. This formula quantifies the "probability of signal obstruction." Its core idea is to combine two key factors: the difference between the actual signal strength and the standard signal strength, and the distance between the handheld terminal and the OBU. It uses an exponential attenuation model to correct for the influence of distance on the signal, ultimately outputting a probability value in the 0-1 range. When the probability value is ≥0.6, it is determined to be "signal obstruction," achieving an upgrade from "qualitative judgment" to "quantitative judgment," avoiding the errors of traditional subjective judgments based solely on signal strength. This algorithm enables the fault diagnosis module to accurately distinguish between "signal obstruction" and "OBU hardware failure," avoiding misdiagnosis of "weak signal due to excessive distance" as "OBU failure," thus significantly improving the accuracy of fault diagnosis. Simultaneously, the quantitative probability values ​​provide data support for subsequent differentiated guidance strategies, such as only when... The system pushes out prompts to "adjust the position of the handheld terminal" only when necessary, reducing unnecessary operations and improving service efficiency.

[0021] In an embodiment of the present invention, the cloud data processor has a built-in scenario-based guidance strategy generation module. After receiving the fault diagnosis results and the car owner's feedback information, the module combines the real-time time information of the gas station and the real-time traffic data of the gas station synchronized by the cloud data processor to determine whether it is a peak traffic period and the current congestion status of the refueling lane. If it is a peak period and the corresponding lane is congested, a strategy of "simplified aggregated payment process + dynamic diversion guidance prompts" is generated. The simplified aggregated payment process includes canceling the paper voucher printing option by default and prioritizing the display of commonly used payment method entrances. The dynamic diversion guidance prompts are combined with the gas station lane layout information and pushed to the handheld interactive device terminal screen and the gas station lane guidance screen to guide staff to guide vehicles to the available temporary payment area. If it is during off-peak hours or when the channel is idle, a strategy of "aggregated payment + fault-related service entry + repair progress tracking" will be generated. The service entry includes cooperative service links for OBU application, activation, and battery replacement. The repair progress tracking function is linked to the fault handling system data of the ETC issuer. To accurately determine the congestion status of refueling lanes and match diversion strategies, the scenario-based guidance strategy generation module calculates the lane congestion index using the following algorithm formula: ; in, For the first The congestion index of each refueling lane, ranging from 0 to 1, is the core indicator for judging whether the lane is congested. The higher the value, the heavier the current load on the lane. For the first The current number of vehicles queuing in each lane is collected by the gas station's monitoring system (such as camera counting and ground loop detection) to reflect the real-time traffic flow in the lane; For the first The historical average refueling time for each channel is calculated by cloud data processors based on the refueling time data of the channel over the past 7 days, reflecting the channel's regular service efficiency. For the first The maximum number of vehicles that a lane can accommodate is set by parameters such as the physical length of the gas station lane and the spacing between parking spaces, and is the upper limit of the lane's load. This is the standard refueling time, a unified benchmark value. The default setting is the average time under normal refueling scenarios, used to eliminate deviations in historical data from different channels. For the first The average probability of OBU signal blockage in each channel reflects the degree of impact of OBU failure on the channel process. This formula is used to calculate the "refueling lane congestion index." It quantifies the current load of the lane by multiplying the current number of vehicles in the queue by the average refueling time. It then sets a load limit by combining the lane's maximum capacity with the standard refueling time. Finally, it introduces the "mean probability of signal obstruction" to correct for the impact of process delays caused by OBU malfunctions on congestion. The final output is an index value in the range of 0-1. An index ≥ 0.7 is considered "congested," providing a precise basis for dynamic traffic diversion. This algorithm breaks through the limitations of traditional methods that rely solely on queue length to determine congestion. By combining factors such as refueling time and the impact of OBU malfunctions, it achieves dynamic and accurate determination of lane congestion status. Based on this index, the "dynamic diversion and guidance strategy" can guide vehicles in congested lanes to empty areas, preventing the spread of local congestion caused by OBU malfunctions. At the same time, it simplifies the payment process during peak hours, significantly improving the overall operational efficiency of gas stations.

[0022] In an embodiment of the present invention, the cloud data processor establishes a communication connection with the vehicle management office's vehicle model database. This connection is encrypted and interface permission verified through a multi-system data encryption and interaction module. After the handheld interactive device terminal collects vehicle license plate information and uploads it to the cloud data processor, the cloud data processor connects to the vehicle management office's vehicle model database to obtain multi-dimensional vehicle parameters such as vehicle type, vehicle height, driver's cab position, and recommended OBU installation area. If the fault diagnosis result is a signal problem, the cloud data processor combines the acquired vehicle body parameters to determine the source of the signal obstruction and adds OBU installation adjustment suggestions adapted to the vehicle model to the differentiated guidance strategy, including fine-tuning the direction of the installation position and prompts to avoid obstructions. These suggestions are simultaneously displayed on the screen of the handheld interactive device terminal for the owner and staff to view, and are also uploaded to the cloud data processor for storage as fault handling reference data for the vehicle model. To determine the optimal orientation for OBU installation and adjustment, the cloud data processor calculates the fine-tuning angle of the installation location using the following algorithm: ; in, Fine-tuning the OBU installation position angle, in degrees (°), a positive angle indicates that the OBU position needs to be adjusted upwards, and a negative angle indicates that the OBU position needs to be adjusted downwards. This is the core parameter to guide car owners in adjusting the OBU installation. The height of the windshield in front of the driver's cab is obtained synchronously from the vehicle model database of the vehicle management office, reflecting the physical dimensions of the vehicle's windshield; The current installation height of the OBU is calculated by taking an image of the windshield using the image recognition module built into the handheld terminal, reflecting the actual installation position of the OBU. The horizontal distance between the OBU and the handheld terminal is collected by the ranging module built into the handheld terminal, reflecting the horizontal spatial relationship between the two. , These are the standard signal strength of the OBU and the actual detected signal strength, used to quantify the degree of signal optimization required. The vehicle type correction coefficient is set according to the vehicle type (sedan 1.0, SUV 1.1, truck 1.3) to correct the influence of windshield angle and installation space on the fine-tuning effect of different vehicle types. This formula is used to calculate the "OBU installation position fine-tuning angle". It constructs a geometric model by "the difference between the vehicle windshield height and the current installation height of the OBU" and "the horizontal distance between the OBU and the handheld terminal". It combines "the difference between the standard signal strength and the actual signal strength" to quantify the signal optimization requirements. Then, it adapts to the structural differences of different vehicle models through "vehicle model correction coefficient" and finally outputs the fine-tuning angle (positive angle upward, negative angle downward) to provide precise guidance for OBU installation adjustment. This algorithm can generate personalized OBU installation and adjustment plans for different vehicle models, avoiding the problem of "uniform suggestions not being compatible with vehicle models". It helps car owners to accurately adjust the OBU position to improve signal reception. At the same time, the adjustment suggestions are based on quantitative calculations, which increases the car owners' trust in the suggestions, reduces repeated failures caused by improper OBU installation, and reduces the frequency of manual intervention.

[0023] In an embodiment of the present invention, the communication connection between the cloud data processor and the ETC issuer's fault handling system is managed by a multi-system data encryption interaction module, which only obtains activation links, binding process guidelines and repair progress data related to the current faulty OBU. If the fault diagnosis result is that the OBU is not activated or the binding is invalid, the cloud data processor obtains the corresponding OBU repair resources through this interface, generates a "payment-repair" associated data package by associating it with the aggregated payment order information, and sends it to the fee settlement processor. The toll settlement processor pushes the payment result, repair resources, and repair progress query entry from the data packet to the vehicle owner's mobile device. After the vehicle owner provides feedback on the repair operation progress through the progress query entry, the cloud data processor receives the feedback information and synchronizes it to the ETC issuer's fault handling system to update the work order progress. At the same time, the toll settlement processor pushes progress update prompts to the vehicle owner. To quantify the OBU repair progress and trigger progress notifications, the cloud data processor calculates the repair completion rate using the following algorithm: ; in, This represents the OBU repair completion rate, with a value ranging from 0 to 1. It is a core indicator for judging the progress of OBU repair; the higher the value, the closer the repair progress is to completion. This represents the number of repair steps completed by the vehicle owner. The ETC issuer's fault handling system provides feedback based on the vehicle owner's operation records (such as whether steps like "obtaining activation code" and "filling in vehicle information" have been completed), reflecting the actual progress of the repair. The total number of steps required for OBU repair is set according to the OBU fault type (3 steps for inactivation fault, 2 steps for binding failure fault), which serves as the benchmark for calculating repair progress. This is the probability of OBU signal obstruction, used to correct the impact of signal problems preventing car owners from successfully completing the repair operation (such as weak signal causing activation verification failure). This formula is used to calculate the "OBU repair completion rate." It quantifies the repair progress by dividing the number of completed repair steps by the total number of repair steps. It then incorporates the "signal obstruction probability" to correct for delays caused by signal issues, ultimately outputting a completion rate in the range of 0-1. A completion rate of 1 is considered "repair complete," providing a basis for progress tracking and notification pushes. This algorithm enables dynamic quantitative tracking of OBU repair progress, avoiding the inefficient traditional method of "relying solely on manual inquiries." Based on the completion rate, progress prompts can push information such as "remaining steps reminders" and "supplementary operation instructions" to vehicle owners during the repair process, improving the repair success rate. At the same time, the completion rate data is synchronized to the customer service system, making it easier for customer service to intervene in a timely manner when vehicle owners encounter repair obstacles, thus shortening the repair cycle.

[0024] In an embodiment of the present invention, the ETC-dedicated frequency band antenna of the handheld interactive device terminal body is an adjustable gain antenna, and the antenna gain adjustment logic is associated with the vehicle model information obtained by the cloud data processor. When the fault diagnosis module detects insufficient signal strength, the cloud data processor sends a gain adjustment suggestion adapted to the vehicle model to the handheld interactive device terminal body based on the acquired vehicle type and body parameters. The handheld interactive device terminal automatically adjusts the antenna gain amplitude according to the suggestion, and prompts the staff to adjust the relative position of the handheld terminal and the vehicle. It then attempts to read the OBU information a second time. If the second reading still fails, the fault diagnosis module records the current vehicle model, antenna gain parameters and reading failure scenario, and uploads it to the cloud data processor to optimize the subsequent gain adjustment logic, and then triggers the subsequent fault detection steps and aggregated payment mode switching. To determine the optimal gain adjustment range for the antenna, the cloud data processor calculates the gain adjustment value using the following algorithm: ; in, This is the antenna gain adjustment value, measured in dBi (decibel milliwatt). It is a core parameter that guides the adjustment of the signal gain of the handheld terminal antenna. The larger the value, the higher the signal strength that needs to be increased. This is the antenna base gain, an inherent parameter of the dedicated frequency band antenna for ETC in handheld terminals. It is set to the standard gain value of the antenna by default and serves as the reference for adjustment. , These are the standard signal strength of the OBU and the actual detected signal strength, respectively, used to quantify the adjustment requirements of the signal gain (the larger the ratio, the higher the gain needs to be adjusted). This is a vehicle model correction factor, used to correct for the differences in signal attenuation caused by different vehicle models (such as trucks with more body obstruction and SUVs with larger windshield angles). This formula is used to calculate the "antenna gain adjustment value". It uses the "antenna base gain" as a benchmark, combines the "logarithm of the ratio of standard signal strength to actual signal strength" to quantify the gain adjustment requirements, and then uses the "vehicle model correction coefficient" to adapt to the signal attenuation characteristics of different vehicle models. Finally, it outputs the gain adjustment value to guide the handheld terminal antenna to optimize the signal reception effect. This algorithm allows handheld terminals to precisely adjust antenna gain based on vehicle model and signal strength differences, avoiding the problem of "uniform gain adjustment causing some vehicle models to have excessively strong signals that interfere with other devices, while others still have insufficient signals." The success rate of secondary reading of OBU information is significantly improved, reducing the frequency of aggregated payments triggered by signal problems, while also reducing the operational costs of staff manually adjusting antennas.

[0025] In an embodiment of the present invention, a vehicle model recognition auxiliary camera is provided on the top of the handheld interactive device terminal body. The vehicle exterior image captured by the camera is encrypted by the multi-system data encryption interaction module and then uploaded to the cloud data processor. When the cloud data processor is unable to obtain vehicle type information from the vehicle management office's vehicle model database, staff can use the camera to capture multi-feature images of the vehicle's cab location, body outline, and license plate location. After receiving the image, the cloud data processor extracts key vehicle features using image recognition algorithms and matches them with the vehicle model feature database stored in the database to help determine the vehicle type. If the matching result is a new model, the cloud data processor records the characteristics of the model and the corresponding OBU signal adaptation suggestions, updates the model feature library, ensures the adaptability of the differentiated guidance strategy for similar models in the future, and feeds back the auxiliary judgment result to the screen of the handheld interactive device terminal. To quantify vehicle feature matching to determine vehicle model, the cloud data processor calculates the feature matching score using the following algorithm: ; in, The vehicle feature matching score, ranging from 0 to 1, is the core indicator for judging whether the vehicle model matches. The higher the value, the stronger the consistency between the extracted features from the image and the vehicle feature library. The number of key vehicle features extracted is set to 5 by default (vehicle height, wheelbase, windshield angle, hood length, and wheel size), which represents the number of dimensions for feature matching. For the first The weights of the features are summed to 1 (vehicle height 0.3, the other 4 features 0.175 each). Since vehicle height has the greatest impact on OBU installation, it is given the highest weight. Extracting the first from the image The feature value is obtained by the cloud data processor through image recognition algorithm analysis of the vehicle exterior image captured by the camera; For the first in the vehicle feature library The standard values ​​of each feature are constructed by the cloud data processor based on the vehicle management office's vehicle model database and historical data, and serve as the benchmark for feature matching; The OBU signal occlusion probability is used to correct feature extraction errors caused by unclear image capture due to signal occlusion (such as an obstruction blocking the vehicle body). This formula is used to calculate the "vehicle feature matching score." It involves a weighted sum of the "image extracted value / standard value" of key features such as "vehicle height" and "wheelbase," and then incorporates the "signal occlusion probability" to correct feature extraction errors caused by signal occlusion during image acquisition. The final output is a score in the 0-1 range. A score ≥ 0.8 is considered a "successful match," thus enabling assisted identification of new vehicle models. This algorithm solves the problem of "unrecognizable special vehicle models not recorded in the vehicle management office database". It achieves accurate vehicle model assistance judgment through multi-feature weighted matching. The recording of new vehicle model features and OBU adaptation suggestions can continuously enrich the vehicle model feature library, improve the recognition and service adaptation efficiency of similar vehicles in the future, and avoid deviations in guidance strategies caused by vehicle model recognition errors, thus ensuring the accuracy of services.

[0026] In an embodiment of the present invention, before the handheld interactive device terminal body establishes a communication connection with the cloud data processor, it is necessary to complete hierarchical identity authentication through the multi-system data encryption interaction module; The authentication process includes: the handheld interactive device terminal first sends the device identification information and the current staff member's identity information to the cloud data processor, and the cloud data processor verifies the validity of the device identification and the staff member's permission level; If it is a basic operation permission, only OBU read, aggregated payment and data upload functions are authorized; If it is an administrative privilege, additional authorization is granted for viewing fault diagnosis parameters, submitting suggestions for adjusting guidance strategies, and managing work order progress. After authentication is successful, the cloud data processor sends out the authorization command for the corresponding permission, and the handheld interactive device terminal receives the command and starts the corresponding function. All data transmission processes employ a unified encryption protocol defined by the multi-system data encryption interaction module to ensure triple security for equipment, personnel, and data. To quantify authentication security levels and assign corresponding permissions, the cloud data processor calculates the authentication security score using the following algorithm: ; in, The authentication security score ranges from 0 to 1 and is the core indicator for classifying access levels. A higher value indicates higher authentication security. The device identification verification result takes a value of 0 or 1 (1 for successful verification, 0 for failure), which is determined by the cloud data processor by comparing the device identification sent by the handheld terminal with the pre-registered device list. The result of staff identity verification is 0 or 1 (1 for successful fingerprint / password verification, 0 for failure), and is collected and verified by the identity verification module of the handheld terminal (such as fingerprint sensor, password input box); This represents the encryption strength for data transmission, ranging from 0.5 to 1, reflecting the security level of the data transmission process. This formula calculates the "authentication security score" by weighting and summing three dimensions: "device identification verification result," "staff identity verification result," and "data transmission encryption strength," ultimately outputting a score in the range of 0-1. "Management permissions" are then assigned based on the score, enabling hierarchical access control and balancing security with ease of operation. This algorithm implements triple security authentication of "device + personnel + data" to prevent unauthorized devices from accessing the system and unauthorized personnel from operating core functions. At the same time, it ensures that basic staff can only perform necessary operations (such as OBU reading and payment) through hierarchical permission, while managers can view fault parameters and adjust policies. This not only ensures system security but also avoids the inefficiency caused by excessive concentration of permissions.

[0027] In an embodiment of the present invention, the fault repair tracking module includes a work order generation unit, a progress tracking unit, and a vehicle owner feedback unit; The work order generation unit is associated with the cloud data processor. When the fault diagnosis result is an OBU fault that requires subsequent repair, it automatically generates a fault handling work order containing vehicle owner information, vehicle information, fault type, repair resource link, and estimated completion time. The progress tracking unit connects to the gas station customer service system and the ETC issuer's fault handling system to synchronize customer service follow-up records and OBU repair progress in real time and update work order status. The vehicle owner feedback unit pushes the work order progress query portal and feedback questionnaire to the vehicle owner's mobile terminal through the fee settlement processor. After the vehicle owner submits feedback, the feedback information is uploaded to the cloud data processor for optimizing fault diagnosis logic and guidance strategies. Once a work order is completed, the fault repair tracking module generates a work order summary report, which is synchronized to the cloud data processor and the gas station operation backend as a basis for service optimization. To comprehensively evaluate the quality of work order processing, the fault repair tracking module calculates the work order service score using the following algorithm: ; in, The service score for work orders, ranging from 0 to 1, is a core indicator for evaluating the quality of work order processing. A higher value indicates better service quality. The OBU repair completion rate reflects whether the core objective of the work order (OBU repair) has been achieved. The system provides feedback ratings from car owners, converting the 5-point ratings submitted by car owners into a 0-1 range to reflect their satisfaction with the service. The standard processing time limit for work orders is set according to the type of fault and serves as a benchmark for evaluating processing efficiency. The actual processing time for a work order is the time from when the work order is generated to when the vehicle owner reports "repair completed," reflecting the actual efficiency of work order processing. This formula is used to calculate the "work order service score". It quantifies the repair results through "repair completion rate", quantifies service satisfaction through "car owner feedback rating", and quantifies processing efficiency through "standard processing time / actual processing time". The three are weighted and summed to output a score in the range of 0-1, which comprehensively evaluates the quality of work order processing and provides a basis for service optimization. This algorithm comprehensively evaluates the quality of work order services from three dimensions: "results, satisfaction, and efficiency," avoiding the traditional single evaluation method of "only looking at whether the repair is completed." Based on the score, service shortcomings can be identified (e.g., if the score is low due to long processing time, the customer service response process will be optimized; if the feedback score is low, the guidance script will be improved), continuously improving the overall quality of fault repair services, while enhancing car owners' trust and stickiness to the gas station ETC service.

[0028] Example 2: An interaction method for an ETC gas station handheld interactive device terminal, comprising the following steps: S1. The handheld interactive device terminal reads the vehicle's ETC on-board unit (OBU) information. If the reading fails, the fault diagnosis module is activated. The fault detection is performed in layers, including signal detection, protocol interaction, and OBU information query. The fault diagnosis result is output and displayed on the screen of the handheld interactive device terminal and pushed to the vehicle owner's mobile device to obtain the vehicle owner's confirmation feedback on the fault prompt. S2. The handheld interactive device terminal will encrypt the fault diagnosis results, vehicle owner confirmation feedback information and collected vehicle license plate information through the multi-system data encryption interaction module and then upload them to the cloud data processor. After receiving the encrypted uploaded information, the S3 cloud data processor synchronizes the refueling operation data and real-time vehicle flow data uploaded by the fuel dispenser control system, connects to the vehicle management office's vehicle model database to obtain multi-dimensional vehicle parameters such as vehicle type and vehicle height, connects to the ETC issuer's fault handling system to obtain OBU fault repair resources, and generates differentiated guidance strategies based on the real-time time information of the gas station. The guidance strategies are then fed back to the handheld interactive device terminal through the multi-system data encryption interaction module. S4. After receiving the differentiated guidance strategy, the handheld interactive device terminal automatically switches to the aggregated payment mode, prioritizing the display of payment method entrances adapted to the current scenario (peak / off-peak, vehicle type) for car owners to complete the payment operation, while recording the operation data (including payment method selection and payment time) in real time during the payment process. S5. The handheld interactive device terminal transmits the payment result, payment process operation data and vehicle owner feedback information back to the cloud data processor and fuel dispenser control system. The cloud data processor associates the fault diagnosis results to generate service information containing OBU fault repair suggestions, which is synchronized to the fee settlement processor. At the same time, it triggers the fault repair tracking module to generate a fault handling work order containing vehicle owner information, vehicle information and fault type, and pushes it to the gas station customer service system. S6, the payment settlement processor pushes payment results, service information, and the OBU fault repair progress query portal to the vehicle owner's mobile device; the fault repair tracking module tracks the work order processing progress in real time (including customer service follow-up records and OBU repair status), and pushes progress update prompts to the vehicle owner through the payment settlement processor; after the vehicle owner completes the OBU repair, they submit repair completion feedback through the progress query portal. The feedback information is encrypted and uploaded to the cloud data processor through the multi-system data encryption interaction module. The cloud data processor updates the work order status and generates service summary data, which is synchronized to the gas station operation backend to complete the service loop.

[0029] The embodiments disclosed in this invention are preferred embodiments, but are not limited thereto. Those skilled in the art can easily understand the spirit of this invention based on the above embodiments and make different extensions and variations, but as long as they do not depart from the spirit of this invention, they are all within the protection scope of this invention.

Claims

1. A handheld interactive device terminal for ETC gas stations, characterized in that, include: The system includes a handheld interactive device terminal, a cloud data processor, a fuel dispenser control system, a payment settlement processor, a fault repair and tracking module, and a multi-system data encryption and interaction module. The handheld interactive device terminal is used to read the vehicle's ETC on-board unit (OBU) information. When reading fails, it triggers intelligent diagnosis of the fault cause and switches to the aggregated payment mode. At the same time, it receives confirmation feedback from the vehicle owner regarding the fault prompt. The cloud data processor is connected to the handheld interactive device terminal, the fuel dispenser control system, the vehicle management office's vehicle model database, and the ETC issuer's fault handling system. It receives diagnostic results, synchronizes refueling operation data and real-time traffic data at the gas station, obtains vehicle information and OBU fault repair resources, and generates differentiated guidance strategies. The fee settlement processor communicates with the cloud data processor and pushes payment results, diagnostic related service information and OBU fault repair progress prompts to the vehicle owner's mobile device; The fault repair tracking module is linked to the cloud data processor and the gas station customer service system to realize a closed loop of fault handling work order generation, push, progress tracking and owner feedback.

2. The ETC handheld interactive device terminal for gas stations according to claim 1, characterized in that, The handheld interactive device terminal has a built-in fault diagnosis module, which is used to perform layered detection of the cause of OBU read failure and interaction with vehicle owner feedback. First, the signal strength is detected by the dedicated ETC frequency band antenna to determine whether there is signal obstruction or the distance is too far. The detection results are displayed in real time on the screen of the handheld interactive device terminal and the driver is prompted to confirm. When the signal detection is normal, the system interacts with the OBU through the general communication protocol of the ETC device to determine whether the protocol handshake has failed or the OBU hardware is faulty. At the same time, a fault type description is generated and pushed to the vehicle owner's mobile terminal for the vehicle owner to view and confirm. When there are no abnormalities in the protocol interaction, the cloud data processor is associated to query the OBU activation information or obtain the OBU power data to determine whether the OBU power is insufficient or not activated. The corresponding fault repair suggestions are generated simultaneously and the vehicle owner's confirmation feedback on the suggestions is obtained. The feedback results are uploaded to the cloud data processor. To quantify the correlation between signal strength detection results and fault diagnosis, the fault diagnosis module calculates the signal obstruction probability using the following algorithm formula to assist in determining the cause of the fault: ； in, For signal obstruction probability, This refers to the actual OBU signal strength detected by the handheld terminal. Standard signal strength for OBU devices. The signal attenuation coefficient is... This represents the actual distance between the handheld terminal and the OBU.

3. The ETC handheld interactive device terminal for gas stations according to claim 2, characterized in that, The cloud data processor has a built-in scenario-based guidance strategy generation module. After receiving the fault diagnosis results and the car owner's feedback information, the module combines the real-time time information of the gas station with the real-time traffic data of the gas station synchronized by the cloud data processor to determine whether it is a peak traffic period and the current congestion status of the refueling lane. If it is a peak period and the corresponding lane is congested, a strategy of "simplified aggregated payment process + dynamic diversion guidance prompts" will be generated. The simplified aggregated payment process includes canceling the paper voucher printing option by default and prioritizing the display of commonly used payment method entrances. The dynamic diversion guidance prompts are combined with the gas station lane layout information and pushed to the handheld interactive device terminal screen and the gas station lane guidance screen to guide staff to guide vehicles to the available temporary payment area. If it is during off-peak hours or when the channel is idle, a strategy of "aggregated payment + fault-related service entry + repair progress tracking" will be generated. The service entry includes cooperative service links for OBU application, activation, and battery replacement. The repair progress tracking function is linked to the fault handling system data of the ETC issuer. To accurately determine the congestion status of refueling lanes and match diversion strategies, the scenario-based guidance strategy generation module calculates the lane congestion index using the following algorithm formula: ； in, For the first Congestion index of each refueling lane. For the first The number of vehicles currently queuing in each lane. For the first The historical average refueling time for each lane For the first The maximum number of vehicles that each lane can accommodate. Standard refueling time, For the first The average probability of OBU signal obstruction for each channel.

4. The ETC handheld interactive device terminal for gas stations according to claim 3, characterized in that, The cloud-based data processor establishes a communication connection with the vehicle management office's vehicle model database; After the handheld interactive device terminal collects vehicle license plate information and uploads it to the cloud data processor, the cloud data processor connects to the vehicle management office's vehicle model database to obtain multi-dimensional vehicle parameters such as vehicle type, vehicle height, driver's cab position, and recommended OBU installation area. If the fault diagnosis result is a signal problem, the cloud data processor combines the acquired vehicle body parameters to determine the source of the signal obstruction and adds OBU installation adjustment suggestions adapted to the vehicle model to the differentiated guidance strategy, including fine-tuning the direction of the installation position and prompts to avoid obstructions. To determine the optimal orientation for OBU installation and adjustment, the cloud data processor calculates the fine-tuning angle of the installation location using the following algorithm: ； in, Fine-tune the angle of the OBU installation position. The height of the windshield in front of the vehicle's driver's cab. This represents the current installation height of the OBU. The horizontal distance between the OBU and the handheld terminal. , These represent the standard signal strength of the OBU and the actual detected signal strength, respectively. This is the vehicle model correction factor.

5. The ETC handheld interactive device terminal for gas stations according to claim 4, characterized in that, The cloud data processor only obtains activation links, binding process instructions, and repair progress data related to the currently faulty OBU; If the fault diagnosis result is that the OBU is not activated or the binding is invalid, the cloud data processor obtains the corresponding OBU repair resources through this interface, generates a "payment-repair" associated data packet by associating it with the aggregated payment order information, and sends it to the fee settlement processor. The payment settlement processor will simultaneously push the payment results, repair resources, and repair progress query entry from the data package to the car owner's mobile device; After the vehicle owner provides feedback on the repair operation progress through the progress query portal, the cloud data processor receives the feedback information and synchronizes it to the ETC issuer's fault handling system to update the work order progress. At the same time, the toll settlement processor pushes progress update prompts to the vehicle owner. To quantify the OBU repair progress and trigger progress notifications, the cloud data processor calculates the repair completion rate using the following algorithm: ； in, For OBU repair completion rate, This represents the number of repair steps completed by the car owner. This represents the total number of steps required for OBU repair. This represents the probability of OBU signal occlusion.

6. The ETC handheld interactive device terminal for gas stations according to claim 2, characterized in that, The ETC-dedicated frequency band antenna of the handheld interactive device terminal is an adjustable gain antenna, and the antenna gain adjustment logic is associated with the vehicle information obtained by the cloud data processor. When the fault diagnosis module detects insufficient signal strength, the cloud data processor sends a gain adjustment suggestion adapted to the vehicle model to the handheld interactive device terminal body based on the acquired vehicle type and body parameters. The handheld interactive device terminal automatically adjusts the antenna gain amplitude according to the suggestion, and prompts the staff to adjust the relative position of the handheld terminal and the vehicle. It then attempts to read the OBU information a second time. If the second reading still fails, the fault diagnosis module records the current vehicle model, antenna gain parameters and reading failure scenario, and uploads it to the cloud data processor to optimize the subsequent gain adjustment logic, and then triggers the subsequent fault detection steps and aggregated payment mode switching. To determine the optimal gain adjustment range for the antenna, the cloud data processor calculates the gain adjustment value using the following algorithm: ； in, This is the antenna gain adjustment value. For antenna base gain, , These represent the standard signal strength of the OBU and the actual detected signal strength, respectively, and are vehicle model correction coefficients.

7. The ETC handheld interactive device terminal for gas stations according to claim 6, characterized in that, The handheld interactive device terminal is equipped with a vehicle model recognition auxiliary camera on its top. The vehicle exterior image captured by the camera is encrypted by the multi-system data encryption interaction module and then uploaded to the cloud data processor. When the cloud data processor is unable to obtain vehicle type information from the vehicle management office's vehicle model database, staff can use the camera to capture multi-feature images of the vehicle's cab location, body outline, and license plate location. After receiving the image, the cloud data processor extracts key vehicle features using image recognition algorithms and matches them with the vehicle model feature database stored in the database to help determine the vehicle type. If the matching result is a new vehicle model, the cloud data processor records the vehicle model characteristics and the corresponding OBU signal adaptation suggestions, and updates the vehicle model feature database. To quantify vehicle feature matching to determine vehicle model, the cloud data processor calculates the feature matching score using the following algorithm: ； in, The vehicle feature matching score, The number of key vehicle features extracted. For the first The weight of each feature, Extracting the first from the image eigenvalues, For the first in the vehicle feature library Standard values ​​of the feature This represents the probability of OBU signal occlusion.

8. The ETC handheld interactive device terminal for gas stations according to claim 7, characterized in that, Before the handheld interactive device terminal establishes a communication connection with the cloud data processor, it needs to complete hierarchical identity authentication through the multi-system data encryption interaction module; The authentication process includes: the handheld interactive device terminal first sends the device identification information and the current staff member's identity information to the cloud data processor, and the cloud data processor verifies the validity of the device identification and the staff member's permission level; If it is a basic operation permission, only OBU read, aggregated payment and data upload functions are authorized; If it is an administrative privilege, additional authorization is granted for viewing fault diagnosis parameters, submitting suggestions for adjusting guidance strategies, and managing work order progress. After authentication is successful, the cloud data processor sends out the authorization command for the corresponding permission, and the handheld interactive device terminal receives the command and starts the corresponding function. To quantify authentication security levels and assign corresponding permissions, the cloud data processor calculates the authentication security score using the following algorithm: ； in, For authentication security score, For the device identification verification results, For staff identity verification results, This determines the encryption strength for data transmission.

9. The ETC handheld interactive device terminal for gas stations according to claim 1, characterized in that, The fault repair tracking module includes a work order generation unit, a progress tracking unit, and a vehicle owner feedback unit. The work order generation unit is associated with the cloud data processor. When the fault diagnosis result is an OBU fault that requires subsequent repair, it automatically generates a fault handling work order containing vehicle owner information, vehicle information, fault type, repair resource link, and estimated completion time. The progress tracking unit connects to the gas station customer service system and the ETC issuer's fault handling system to synchronize customer service follow-up records and OBU repair progress in real time and update work order status. The vehicle owner feedback unit pushes the work order progress query portal and feedback questionnaire to the vehicle owner's mobile terminal through the fee settlement processor. After the vehicle owner submits feedback, the feedback information is uploaded to the cloud data processor for optimizing fault diagnosis logic and guidance strategies. Once a work order is completed, the fault repair tracking module generates a work order summary report, which is then synchronized to the cloud data processor and the gas station operations backend. To comprehensively evaluate the quality of work order processing, the fault repair tracking module calculates the work order service score using the following algorithm: ； in, Service points for work orders For OBU repair completion rate, Rate the feedback from car owners. Standard processing time for work orders. This refers to the actual processing time for the work order.

10. An interaction method for an ETC gas station handheld interactive device terminal, used in any one of claims 1-9 of the ETC gas station handheld interactive device terminal, characterized in that, Includes the following steps: S1. The handheld interactive device terminal reads the vehicle's ETC on-board unit (OBU) information. If the reading fails, the fault diagnosis module is activated. The fault detection is performed in layers, including signal detection, protocol interaction, and OBU information query. The fault diagnosis result is output and displayed on the screen of the handheld interactive device terminal and pushed to the vehicle owner's mobile device to obtain the vehicle owner's confirmation feedback on the fault prompt. S2. The handheld interactive device terminal will encrypt the fault diagnosis results, vehicle owner confirmation feedback information and collected vehicle license plate information through the multi-system data encryption interaction module and then upload them to the cloud data processor. After receiving the encrypted uploaded information, the S3 cloud data processor synchronizes the refueling operation data and real-time vehicle flow data uploaded by the fuel dispenser control system, connects to the vehicle management office's vehicle model database to obtain multi-dimensional vehicle parameters such as vehicle type and vehicle height, connects to the ETC issuer's fault handling system to obtain OBU fault repair resources, and generates differentiated guidance strategies based on the real-time time information of the gas station. The guidance strategies are then fed back to the handheld interactive device terminal through the multi-system data encryption interaction module. S4. After receiving the differentiated guidance strategy, the handheld interactive device terminal automatically switches to the aggregated payment mode, prioritizing the display of payment method entrances adapted to the current scenario for car owners to complete the payment operation, while recording the operation data during the payment process in real time. S5. The handheld interactive device terminal transmits the payment result, payment process operation data and vehicle owner feedback information back to the cloud data processor and fuel dispenser control system. The cloud data processor associates the fault diagnosis results to generate service information containing OBU fault repair suggestions, which is synchronized to the fee settlement processor. At the same time, it triggers the fault repair tracking module to generate a fault handling work order containing vehicle owner information, vehicle information and fault type, and pushes it to the gas station customer service system. S6. The fee settlement processor pushes the payment results, service information, and OBU fault repair progress query entry to the vehicle owner's mobile device. The fault repair tracking module tracks the work order processing progress in real time and pushes progress update prompts to vehicle owners through the cost settlement processor. After the vehicle owner completes the OBU repair, they submit a repair completion feedback through the progress query portal. The feedback information is encrypted by the multi-system data encryption interaction module and uploaded to the cloud data processor. The cloud data processor updates the work order status and generates service summary data, which is synchronized to the gas station's operation backend, completing the service loop.

Images