A method, system and device for processing expressway passing work orders based on multi-dimensional dynamic weights

Abstract

The present application relates to the field of highway automation operation, and particularly relates to a highway pass work order processing method, system and equipment based on multi-dimensional dynamic weight. The present application calculates and matches the score by comprehensively considering the work order dynamic priority weight of multiple factors and the personnel dynamic priority weight, and distributes the to-be-processed work order according to the matching score, and automatically iterates the calculation parameters of the priority weight according to the continuously running data, so as to realize the minimization of the whole process time consumption of the work order. Meanwhile, the present application also realizes hierarchical distribution through a distributed architecture, locally distributes low-priority work orders, globally schedules medium-high-priority work orders, reduces the time consumption of cross-level transmission, thereby shortens the distribution time consumption and avoids lane congestion.

Description

Technical Field

[0001] This invention relates to the field of automated highway operation, and in particular to a method, system and equipment for processing highway toll work orders based on multi-dimensional dynamic weights. Background Technology

[0002] In highway toll station operations, the efficiency of handling special situation work orders determines lane throughput efficiency, with the core metric being work order completion time (T = work order distribution time T1 + work order processing time T2). However, current technologies have the following problems:

[0003] 1. Static priority evaluation: It only relies on a few fixed attributes such as vehicle type and work order type, ignoring real-time variables such as sudden increases in real-time traffic flow at the exit and abnormal time of self-service equipment. High-impact work orders are delayed in allocation due to insufficient weight, which prolongs T1.

[0004] 2. Insufficient accuracy in resource matching: The allocation of agents does not take into account the "business type that the agent is good at" and the characteristics of the work order, which is prone to mismatch (such as assigning an ETC fault work order to an agent who is good at payment disputes), resulting in the T2 time exceeding the normal threshold.

[0005] 3. Lack of self-optimization capability: Weight rules need to be manually adjusted and cannot be iterated based on historical data. When business scenarios change (such as high traffic during holidays), the adaptation is delayed and the completion time of work orders fluctuates greatly.

[0006] Therefore, there is a need for a highway toll order processing method, system, and equipment that takes into account more comprehensive features, allocates more accurately, and can automatically optimize. Summary of the Invention

[0007] The purpose of this invention is to overcome the problems of incomplete consideration of factors, long processing time, and inability to automatically optimize existing technologies, and to provide a method, system, and equipment for processing highway toll work orders based on multi-dimensional dynamic weights.

[0008] To achieve the above-mentioned objectives, the present invention provides the following technical solution:

[0009] A method for processing highway toll tickets based on multi-dimensional dynamic weights includes the following steps:

[0010] S1: Receive pending work orders in real time, calculate the dynamic priority weight of each pending work order, and allocate the pending work orders to the corresponding processing queue.

[0011] When the dynamic priority weight of the work order is less than the preset allocation threshold, the corresponding work order to be processed will be allocated to the local queue of the service node; otherwise, it will be uploaded to the global queue of the cloud warehouse.

[0012] The work order characteristics of the dynamic priority weight of the work order include any one or more of the following: work order type, vehicle type, lane type, traffic flow scale at entrances and exits, traffic flow scale at toll stations, license plate color, real-time traffic flow at exits, real-time traffic flow at entrances, and abnormal self-service time.

[0013] S2: Based on the dynamic priority weight of the work orders, sort the work orders to be processed in the processing queue in descending order, and allocate each work order to be processed in order.

[0014] S3: Get the online agents in the area corresponding to the current pending work order, calculate the dynamic priority weight of each agent, and output the agent list in descending order;

[0015] The personnel characteristics for the dynamic priority weight of personnel include personnel role, idle time, number of work orders processed in a day, whether it is a station on the same road segment, number of pending work orders, and any one or more of the business types they are good at.

[0016] S4: Calculate the matching score between the current pending work order and the first set number of seats in the seat list, and assign the current pending work order to the seat with the highest matching score;

[0017] S5: After a pending work order is completed, the priority weight calculation parameters are dynamically updated based on the actual processing time of the pending work order.

[0018] As a preferred embodiment of the present invention, the expression for the dynamic priority weight of the work order is:

[0019] ,

[0020] ,

[0021] Where Wt is the dynamic priority weight of the work order. For the number of work order features, The sub-weights of the i-th work order feature are... Let be the real-time influencing factor of the i-th work order feature. Historical feedback coefficient, As a preset historical impact factor, This represents the target completion time for the work order. Let be the historical average completion time of the work order corresponding to the i-th work order feature.

[0022] As a preferred embodiment of the present invention, S4 further includes a secondary matching mechanism, comprising the following steps:

[0023] Once a work order is assigned, if no confirmation feedback is received from an agent within the preset confirmation time threshold, or if the processing exceeds the set timeout threshold, the assignment is deemed a failure. Increase by 0.1 and re-enter S1;

[0024] If a pending work order fails to be assigned three times, the corresponding pending work order will be marked as an urgent work order and pushed to all online agents until confirmation feedback is received from an agent.

[0025] As a preferred embodiment of the present invention, the expression for the dynamic priority weight of personnel is:

[0026] ,

[0027] ,

[0028] Where Ws represents the dynamic priority weight of personnel, and m represents the number of personnel features. For the sub-weight of the j-th person feature, Let j be the real-time influencing factor of the j-th personnel characteristic. This is the historical feedback coefficient for agent seats. The preset historical influence factor of the seats, This is the target value for work order processing time. Let be the historical average processing time of the s-th agent for work orders of type k.

[0029] As a preferred embodiment of the present invention, the expression for the matching score in step S4 is:

[0030] ,

[0031] in, For matching scores, Wt represents the dynamic priority weight of work orders, and Ws represents the dynamic priority weight of personnel. The historical average processing time for the s-th agent to process work orders of type k.

[0032] As a preferred embodiment of the present invention, the dynamic update in S5 includes the following steps:

[0033] S51: Obtain the allocation time and processing time of each processed work order within the set update time;

[0034] S52: Calculate the influence degree of each feature on time;

[0035] S53: Update each sub-weight according to the influence degree of the feature;

[0036] S54: Continuously run the verification time with the updated optimized weights, and calculate the average total time before the update and the average total time after the update;

[0037] If the average total time before the update is greater than the average total time after the update, the updated optimization weight is valid; otherwise, the updated optimization weight is invalid, and the sub-weights of the optimization weight are rolled back to the values ​​before the update.

[0038] As a preferred embodiment of the present invention, the expression for the feature influence degree in S52 is:

[0039] ,

[0040] in, The feature influence degree of feature X; The Pearson correlation coefficient between feature X and time T. This represents the average time consumed when feature X is a valid value; This represents the average time taken when X is an invalid value; This represents the average time spent on all work orders.

[0041] like Feature X is positively correlated with T, so the weight of feature X needs to be increased;

[0042] like Feature X is negatively correlated with T, and its weights need to be maintained or fine-tuned.

[0043] As a preferred embodiment of the present invention, step S53 employs gradient descent for iterative weight updates, the expression of which is:

[0044] , ,

[0045] in, The sub-weights are the updated values ​​for feature X. The sub-weights before feature X is updated. The preset learning rate, This is the maximum weight value set.

[0046] A highway toll order processing system based on multi-dimensional dynamic weights, the system being used to execute any of the above-described highway toll order processing methods based on multi-dimensional dynamic weights, including a feature acquisition layer, a toll station service node, and a cloud warehouse service node.

[0047] The feature acquisition layer includes several feature acquisition modules installed at each toll station, used to collect feature data of each work order;

[0048] The toll station service node includes a preliminary allocation module and several local agents; the preliminary allocation module is used to receive pending work orders and calculate the corresponding dynamic priority weight of the work orders for preliminary allocation; the local agents are used to process pending work orders in the current toll station whose dynamic priority weight is lower than a preset allocation threshold.

[0049] The cloud warehouse service node includes a work order allocation module, a weight update module, and several cloud warehouse agents; the work order allocation module is used to allocate work orders to be processed to each cloud warehouse agent; the weight update module is used to dynamically update the calculation parameters of priority weights.

[0050] A highway toll ticket processing device based on multi-dimensional dynamic weights includes at least one processor and a memory communicatively connected to the at least one processor; the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to execute any of the above-described highway toll ticket processing methods based on multi-dimensional dynamic weights.

[0051] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0052] This invention calculates a matching score by comprehensively considering the dynamic priority weights of work orders and personnel, taking into account multiple factors. Work orders to be processed are then allocated based on this matching score. Furthermore, the calculation parameters for the priority weights are automatically iterated based on continuously running data, thereby minimizing the overall time consumption of the work order process. Simultaneously, this invention also implements a distributed architecture for hierarchical traffic distribution: low-priority work orders are allocated locally, while medium- and high-priority work orders are globally scheduled, reducing cross-level transmission time and thus shortening distribution time, avoiding congestion. Attached Figure Description

[0053] Figure 1 This is a flowchart illustrating a highway toll order processing method based on multi-dimensional dynamic weights as described in Embodiment 1 of the present invention.

[0054] Figure 2 This is a schematic diagram of the dynamic update process in a highway toll order processing method based on multi-dimensional dynamic weights as described in Embodiment 2 of the present invention.

[0055] Figure 3 This is a schematic diagram of the structure of a highway toll order processing system based on multi-dimensional dynamic weights as described in Embodiment 4 of the present invention;

[0056] Figure 4 This is a schematic diagram of the structure of a highway toll order processing device based on multi-dimensional dynamic weights as described in Embodiment 5 of the present invention. Detailed Implementation

[0057] The present invention will be further described in detail below with reference to experimental examples and specific embodiments. However, this should not be construed as limiting the scope of the above-mentioned subject matter of the present invention to the following embodiments; all technologies implemented based on the content of the present invention fall within the scope of the present invention.

[0058] Example 1

[0059] like Figure 1 As shown, a method for processing highway toll tickets based on multi-dimensional dynamic weights includes the following steps:

[0060] S1: Receive pending work orders in real time, calculate the dynamic priority weight of each pending work order, and allocate the pending work orders to the corresponding processing queue.

[0061] When the dynamic priority weight of the work order is less than the preset allocation threshold, the corresponding work order to be processed will be allocated to the local queue of the service node; otherwise, it will be uploaded to the global queue of the cloud warehouse.

[0062] The work order characteristics for dynamic priority weighting include any one or more of the following: work order type, vehicle type, lane type, entrance / exit traffic flow, toll station traffic flow, license plate color, real-time exit traffic flow, real-time entrance traffic flow, and abnormal self-service time. Service nodes include toll stations, personal terminals with toll collection functions, or other nodes with toll collection functions.

[0063] S2: Based on the dynamic priority weight of the work orders, sort the work orders in the processing queue in descending order and allocate them in sequence.

[0064] S3: Obtain the online agents in the area corresponding to the current pending work order, calculate the dynamic priority weight of each agent, and output the agent list in descending order.

[0065] The personnel characteristics for the dynamic priority weight of personnel include personnel role, idle time, number of work orders processed in a day, whether it is a station on the same road segment, number of pending work orders, and any one or more of the business types they are good at.

[0066] S4: Calculate the matching score between the current pending work order and the first set number of seats in the seat list, and assign the current pending work order to the seat with the highest matching score.

[0067] S5: After a pending work order is completed, the priority weight calculation parameters are dynamically updated based on the actual processing time of the pending work order.

[0068] Example 2

[0069] This embodiment is a specific implementation of the highway toll order processing method based on multi-dimensional dynamic weights described in Embodiment 1, and includes the following steps:

[0070] S1: Receive pending work orders in real time, calculate the dynamic priority weight of each pending work order, and allocate the pending work orders to the corresponding processing queue.

[0071] When the dynamic priority weight of the work order is less than the preset allocation threshold, the corresponding work order to be processed will be allocated to the local queue of the service node; otherwise, it will be uploaded to the global queue of the cloud warehouse.

[0072] The dynamic priority weight Wt of a work order is used to measure the urgency of a pending work order in terms of "needing priority allocation". The higher the score, the shorter the T1 time (target ≤ 3 seconds). Specifically, the expression for the dynamic priority weight of the work order is:

[0073] ,

[0074] Symbol explanation:

[0075] The number of work order features is n=9 in this embodiment. Work order features include work order type, vehicle type, lane type, entrance / exit traffic flow scale, toll station traffic flow scale, license plate color, real-time exit traffic flow, real-time entrance traffic flow, and self-service time anomalies (work order features can be added or reduced as needed in actual use).

[0076] The sub-weights for the i-th work order feature (in this embodiment, the initial values ​​of each sub-weight are set by staff based on business experience, such as the initial sub-weight ω=12 for "abnormal self-service time", which is subsequently adjusted by self-supervision). Specifically, in this embodiment, the value range of the work order feature sub-weights is divided into regular features and key special cases according to their importance. The range of regular features is 5-20, and the range of key special cases is 15-30, which meets the following conditions:

[0077] 1. To avoid a single feature monopolizing the weight, the upper limit is set to 30 to ensure that the proportion of features without characteristics exceeds 30%;

[0078] 2. The range of key features (i.e., the core factors affecting T) is higher than that of regular features, reflecting "hierarchy of importance";

[0079] 3. Adapt to Wt total score (0-100): The score after multiple features are superimposed does not exceed 100 to avoid weight overflow.

[0080] This is the real-time impact factor for the i-th work order feature (used to reflect the impact of the current feature on the overall time consumption; continuous features are calculated after normalization, and categorical features are assigned values ​​according to rules). Specifically, in this embodiment, the value range of the real-time impact factor for work order features is divided into three categories according to the degree of correlation: low impact state, normal state, and high impact state. The range for low impact state is 0.5-0.8; the range for normal state is 0.8-1.2; and the range for high impact state is 1.2-1.8, which satisfies the following conditions:

[0081] 1. Use an impact factor of 1 as the baseline (i.e., no additional impact) to avoid excessive deviation that could render the basic weights ineffective;

[0082] 2. The upper limit for high-impact states (such as traffic flow) is 1.8 to ensure that "real-time bonuses" do not overshadow the importance of the basic weight;

[0083] 3. Low impact status limit of 0.5, used to reduce the priority of non-urgent work orders (such as ordinary work orders in the early morning).

[0084] Specific examples are as follows:

[0085] Continuous feature: This embodiment uses real-time exit traffic flow. For example, its characteristic is that of a normal influence state, and the corresponding real-time influence factor is:

[0086] ,

[0087] in, The maximum traffic flow at the station exit (e.g., 500 vehicles / hour). The higher the traffic flow, the better. The higher the value, the larger Wt becomes.

[0088] Classification characteristics: This example uses abnormal self-service time as an example. When an abnormal self-service time occurs, This indicates an anomaly that requires immediate attention to reduce the risk of further congestion; otherwise... .

[0089] The historical feedback coefficient (adjusted based on the historical time of this type of work order) is expressed as follows:

[0090] ,

[0091] in, As a preset historical impact factor, Set the target time for work order completion (e.g., 15 seconds for regular work orders and 60 seconds for special inspection work orders). Let be the historical average completion time of the work order corresponding to the i-th work order feature.

[0092] when hour, ;

[0093] when hour, Increasing the value of Wt will increase its priority for allocation.

[0094] Specifically, in this embodiment, the historical feedback coefficient is divided into a basic range, a sensitive adjustment range, and a strong feedback range based on the urgency of optimization of the work order characteristics; the basic range is 1.0-1.5; the sensitive adjustment range is 1.0-1.2; and the strong feedback range is 1.3-1.5. The specific allocation requirements are as follows:

[0095] 1. Use 1.0 as the baseline (i.e., the feature has no additional feedback) to avoid excessive weight fluctuations caused by coefficients > 1.5 (e.g., a coefficient of 1.5 would increase the base weight by 50%, which could easily lead to priority imbalance).

[0096] 2. The sensitive adjustment range (1.0-1.2) is used during the business stability period, while the strong feedback range (1.3-1.5) is used when there is an urgent need for time optimization.

[0097] 3. Adapts to the self-supervised learning rate (0.05-0.1) to avoid conflicts between feedback intensity and iteration step size.

[0098] This example uses a work order under a certain circumstances:

[0099] "ETC malfunction + Truck + Exit + Real-time Exit Traffic Flow of 400 Vehicles / Hour + Abnormal Self-Service Time" Work Order (F out,max =500, T target =15 seconds, T avg,i =18 seconds):

[0100] 1. Basic weight ω t,i ETC malfunction (basic weight = 8), trucks (basic weight = 8), exit (basic weight = 6), real-time traffic flow at the exit (basic weight = 7), abnormal self-service time (basic weight = 12).

[0101] 2. Real-time impact factor α t,i Real-time exit traffic flow (real-time impact factor = 0.5 + 0.5 × 400 / 500 = 0.9), abnormal self-service time (real-time impact factor = 1.3), and real-time impact factors α for other characteristics. t,i =1.

[0102] 3. Historical feedback coefficient βt = 1 + 0.2 × (15) 18) / 15=0.96.

[0103] 4. The corresponding dynamic priority weight of the work order is Wt = (8×1 + 8×1 + 6×1 + 7×0.9 + 12×1.3) × 0.96 ≈ 42.1 points (belonging to medium-high priority).

[0104] S2: Based on the dynamic priority weight of the work orders, sort the work orders in the processing queue in descending order and allocate them in sequence.

[0105] Furthermore, this includes the following steps:

[0106] S21: The work order enters the corresponding queue (including the local queue of the service node / global queue of the cloud warehouse), and is sorted in descending order by Wt;

[0107] S22: When multiple work orders have the same dynamic priority weight Wt, the queue adopts the "shortest job first" principle, giving priority to work order types with shorter historical average distribution time T1, thereby reducing work order waiting time.

[0108] S3: Obtain the online agents in the area corresponding to the current pending work order, calculate the dynamic priority weight of each agent, and output the agent list in descending order.

[0109] The personnel dynamic priority weight Ws is used to measure the agent's "adaptability to processing work orders". The higher the score, the shorter the T2 (the target in this embodiment is ≤12 seconds). Specifically, the expression for the personnel dynamic priority weight is:

[0110] ,

[0111] Symbol definition:

[0112] m represents the number of personnel characteristics. In this embodiment, m=6. Personnel characteristics include personnel role, idle time, number of work orders processed in a day, whether it is a station on the same road segment, number of pending work orders, and types of business they are good at. In actual use, work order characteristics can be added or reduced as needed.

[0113] The sub-weights for the j-th personnel feature (e.g., initial ω=15 for "Cloud Warehouse Agent" and initial ω=20 for "Proficient Business Types") are defined in this embodiment. Specifically, the range of sub-weights for personnel features is divided into regular features and key special cases based on their importance. The range for regular features is 5-20, and the range for key special cases is 15-30, satisfying the following conditions:

[0114] 1. To avoid a single feature monopolizing the weight, the upper limit is set to 30 to ensure that the proportion of features without characteristics exceeds 30%;

[0115] 2. The range of key features (i.e., the core factors affecting T) is higher than that of regular features, reflecting "hierarchy of importance";

[0116] 3. Adapt to Ws total score (0-100): The score after multiple features are superimposed should not exceed 100 to avoid weight overflow.

[0117] This is the real-time impact factor for the j-th personnel feature. The specific assignment is similar to that for work order features; continuous features are calculated after normalization, while categorical features are assigned values ​​according to rules. Specifically, in this embodiment, the range of the real-time impact factor for personnel features is divided into three categories based on the degree of correlation: low impact, normal, and high impact. The range for low impact is 0.5-0.8; the range for normal impact is 0.8-1.2; and the range for high impact is 1.2-1.8, satisfying the following conditions:

[0118] 1. Use an impact factor of 1 as the baseline (i.e., no additional impact) to avoid excessive deviation that could render the basic weights ineffective;

[0119] 2. The upper limit for high-impact states (such as idle time) is 1.8 to ensure that "real-time bonuses" do not overshadow the importance of the base weights;

[0120] 3. Low impact threshold of 0.5, used to reduce the priority of busy personnel (such as personnel with more work orders than the threshold).

[0121] Specific examples are as follows:

[0122] Continuous characteristics: Idle time (Tidle), α s,j =min(Tidle / 300,1) (In this embodiment, 300 seconds is used as the maximum idle threshold. The longer the idle time, the higher the threshold.) s,j The higher (the higher).

[0123] Classification characteristics: Proficient in business types, α s,j =Sk (where Sk is the agent's proficiency coefficient for the current work order type k, such as Sk=0.9 if the agent is proficient in ETC faults).

[0124] The historical feedback coefficient for the agent is adjusted based on the processing time T2 of the same type of work order handled by this agent. Its expression is:

[0125] ,

[0126] in, The preset historical influence factor of the seats, This is the target value for work order processing time. Let be the historical average processing time of the s-th agent for work orders of type k.

[0127] If T 2,s,k <T 2,target γ s Increasing this value will boost Ws to prioritize matching.

[0128] Specifically, in this embodiment, the historical feedback coefficient is divided into a basic range, a sensitive adjustment range, and a strong feedback range based on the urgency of personnel characteristics for optimization. The basic range is 1.0-1.5; the sensitive adjustment range is 1.0-1.2; and the strong feedback range is 1.3-1.5. The specific allocation requirements are as follows:

[0129] 1. Use 1.0 as the baseline (i.e., the feature has no additional feedback) to avoid excessive weight fluctuations caused by coefficients > 1.5 (e.g., a coefficient of 1.5 would increase the base weight by 50%, which could easily lead to priority imbalance).

[0130] 2. The sensitive adjustment range (1.0-1.2) is used during the business stability period, while the strong feedback range (1.3-1.5) is used when there is an urgent need for time optimization.

[0131] 3. Adapts to the self-supervised learning rate (0.05-0.1) to avoid conflicts between feedback intensity and iteration step size.

[0132] This example uses a work order under a certain circumstances:

[0133] A certain "cloud warehouse agent + 180 seconds of idle time + skilled in ETC fault diagnosis" +8 orders processed per day" agent seats (in this example: Second, Second):

[0134] 1. Basic weights : Cloud warehouse agent (basic weight = 15), idle time (basic weight = 10), business type of expertise (basic weight = 20), 8 orders processed per day (basic weight = 5);

[0135] 2. Real-time impact factor Idle time (real-time impact factor = ), areas of expertise (real-time impact factor = 0.9), other real-time impact factors ;

[0136] 3. Historical Feedback Coefficient : ;

[0137] 4. Priority weighting of personnel dynamics (High adaptability).

[0138] Furthermore, this embodiment also includes a secondary screening of online agents based on work order type k, followed by a dynamic priority weight calculation for personnel after the secondary screening. The secondary screening includes:

[0139] The coefficient Sk for the type of business being proficient is greater than or equal to 0.6 (to ensure adaptability).

[0140] The number of work orders processed on the same day is less than the set work order threshold (e.g., 100 orders, to avoid overload and extension of T2).

[0141] S4: Calculate the matching score between the current pending work order and the first set number of seats in the seat list, and assign the current pending work order to the seat with the highest matching score.

[0142] The expression for the matching score is:

[0143] ,

[0144] in, For matching scores, Wt represents the dynamic priority weight of work orders, and Ws represents the dynamic priority weight of personnel. The historical average processing time for the s-th agent to process work orders of type k.

[0145] Furthermore, this embodiment also includes a secondary matching mechanism, comprising the following steps:

[0146] Once a work order is assigned, if no confirmation feedback is received from an agent within the preset confirmation time threshold (i.e., T1 error), or if processing times out (i.e., T2 > set timeout threshold), the assignment is considered a failure. Increase by 0.1 and re-enter S1.

[0147] Furthermore, when selecting new agents, historical agents are excluded. Seating area.

[0148] If a pending work order fails to be assigned three times, the corresponding pending work order will be marked as an "urgent work order" and pushed to all online agents.

[0149] S5: After a pending work order is completed, the priority weight calculation parameters are dynamically updated based on the actual processing time of the pending work order.

[0150] Furthermore, in this embodiment, the actual processing time of the work orders is statistically analyzed according to the following steps:

[0151] 1. After receiving a work order, the terminal reports "Agent ID + Work Order ID + Receipt Timestamp" and records T1 (T1 = Current Time - Work Order Generation Time).

[0152] 2. After the agent completes the process, report "Processing Result + T2 (T2 = Completion Time - Receipt Time)";

[0153] 3. The cloud warehouse node writes "work order characteristics, agent characteristics, T1, T2" into the self-supervised database to provide data for weight updates.

[0154] Furthermore, this embodiment achieves weight self-optimization through four steps: "data acquisition - feedback analysis - weight update - iterative verification." The core is to adjust ω based on the T1 and T2 data. t,i With ω s,j This minimizes T = T1 + T2. Specifically, for example... Figure 2 As shown, the dynamic update includes the following steps:

[0155] S51: Get the allocation time and processing time of each processed work order within the set update time.

[0156] In this embodiment, the entire process data is stored in a MySQL database.

[0157] Furthermore, in this embodiment, the update time is set to be triggered once every 100 orders processed or every hour. After the update, a new weight version number is generated and synchronized to the configuration center, and each service node loads it in real time.

[0158] S52: Calculate the influence of each feature on time.

[0159] To calculate the influence of a feature on T and determine the direction of weight adjustment, the core formula is the feature influence, and its expression is:

[0160] ,

[0161] in, The feature influence degree of feature X (such as real-time exit traffic flow, business type of expertise); is the Pearson correlation coefficient between feature X and consumption time T (i.e., the larger the absolute value, the stronger the influence). This represents the average time taken when feature X is a valid value (e.g., real-time exit traffic flow > 300). This represents the average time taken when X is an invalid value; This represents the average time spent on all work orders.

[0162] like If feature X is positively correlated with T (e.g., the larger X is, the longer T is), the weight of feature X needs to be increased.

[0163] like If feature X is negatively correlated with T (e.g., the larger X is, the shorter T is), the weights need to be maintained or fine-tuned.

[0164] S53: Update each sub-weight according to the influence degree of the feature;

[0165] Furthermore, this embodiment employs gradient descent for iterative weight updates, based on... Adjust the base weights ω (including ω) t,i With ω s,j Its expression is:

[0166] , ,

[0167] in, The sub-weights are the updated values ​​for feature X. The sub-weights before feature X is updated. The preset learning rate (ranging from 0.05 to 0.1, used to balance update speed and stability); The maximum weight is set (e.g., 100). In this embodiment, the range of sub-weights is constrained to between 1 and 30, thereby avoiding excessively high or low weights for a single feature.

[0168] S54: Continuously run the verification time with the updated optimized weights, and calculate the average total time before the update and the average total time after the update;

[0169] If the average total time before the update is greater than the average total time after the update, the updated optimization weight is valid; otherwise, the updated optimization weight is invalid, and the sub-weights of the optimization weight are rolled back to the values ​​before the update.

[0170] Specifically, the average total time before and after the update The expression is:

[0171] ,

[0172] Symbol definition:

[0173] : The time taken to distribute the kth work order (i.e., the time from work order generation to its allocation to an agent);

[0174] : Processing time of the kth work order (i.e., the time it takes for the agent to receive the completed work order);

[0175] N: The total number of completed work orders in the previous verification cycle (or the next verification cycle) (the default verification cycle is 30 minutes, which can be configured according to actual needs).

[0176] This is the statistical average of "work order completion time (T=T1+T2)" under the new weight version, directly reflecting the optimization effect of the new weight on traffic efficiency. By comparing the average T of the new and old weight versions, we can determine whether the weight update is effective.

[0177] It is the average work order completion time of the old weighted version (such as v1.0) under the same time window and the same business scenario before the update (such as the average T of the same period of the previous day).

[0178] Once the new weights take effect, the average values ​​of T1 and T2 for all completed work orders within the statistical verification period will be calculated using the formula above. as well as .

[0179] like (i.e., T decreases by more than 5%): This indicates that the new weight optimization effect is significant, the optimization direction should be strengthened, the iteration can be accelerated appropriately, and this version should be retained as the benchmark for the next round of iteration;

[0180] like This falls under the "acceptable minor optimization" scenario. Its processing logic still aims for steady optimization through self-supervised iteration. In this case, the new version is retained, and the learning rate is maintained. .

[0181] like (i.e., the new weights increase the average T): This indicates that the weight adjustment was inappropriate. Immediately revert to the old version and reduce the self-supervised learning rate. (For example, adjust from 0.1 to 0.05) to avoid excessive fluctuations in subsequent updates.

[0182] In summary, the method described in this embodiment has the following advantages compared to the prior art:

[0183] I. Overcoming the limitations of static priority and improving work order distribution efficiency

[0184] Traditional work order priority assessment relies solely on fixed attributes, ignoring real-time scenario variables, leading to delayed allocation of high-impact work orders. This invention addresses this issue through a "dynamic weight model + distributed hierarchical architecture": the dynamic weight model integrates real-time traffic flow, equipment status, and historical data to quantify the urgency of work orders; the distributed architecture implements hierarchical traffic allocation, with low-priority work orders allocated locally and medium-to-high-priority work orders scheduled globally, reducing cross-level transmission time. This design ensures that critical work orders such as those experiencing faults or equipment malfunctions during congested periods receive priority access to resources, shortening distribution time and preventing lane congestion.

[0185] II. Optimize agent matching to reduce work order processing time.

[0186] Traditional agent allocation methods often fail to consider business suitability, leading to prolonged processing times. This invention constructs a "dynamic agent weighting system + bidirectional optimal matching algorithm": it collects agent characteristics (including expertise coefficients) from multiple dimensions, and calculates a matching score by combining work order urgency with agent suitability through an algorithm, selecting suitable agents without overload risk. This design ensures work orders are processed by suitable agents, reducing processing time, minimizing errors, and improving resource utilization.

[0187] III. Constructing a self-supervised iteration to achieve adaptive optimization of the system

[0188] Traditional rules require manual adjustment, resulting in slow adaptation and high maintenance costs. This invention employs a "self-supervised closed-loop" automatic iteration: it collects data throughout the entire process, analyzes and quantifies the impact of features on processing time, updates weights using gradient descent, and includes a verification and rollback mechanism to ensure stability. This mechanism allows the system to quickly adapt to scenarios such as high traffic during holidays and the launch of new devices, reducing manual labor costs.

[0189] Example 3

[0190] This embodiment is an application example of a simulated operation using the highway toll order processing method based on multi-dimensional dynamic weights described in Embodiment 2, including the following steps:

[0191] Step 1: Receive work orders to be processed.

[0192] Work order characteristics: Type = Assistance work order, Vehicle type = Truck, Lane type = ETC, Entrance / Exit = Exit, Real-time traffic flow at Exit = 400 vehicles / hour, Self-service time anomaly = 1, Generation timestamp = 2025-XX-XX10:05:30;

[0193] The pending work order is pushed to the toll station 2 service node, and the start time of T1 is cached locally.

[0194] Step 2: Initial work order allocation (the work order is currently at the toll station service node layer)

[0195] Preprocessing: Normalize real-time exit traffic flow (400 / 500=0.8), and correlate with historical data (for this type of work order). Second, Second);

[0196] Calculate Wt: Wt = 38.2 points (i.e., it belongs to medium-high priority);

[0197] Filter local agents: If all station-level agents are busy, push to Cloud Warehouse 2 service node.

[0198] Step 3: Global Allocation (The work order is currently at the cloud warehouse service node layer)

[0199] Agent screening: Two cloud warehouse agents were selected (screening criteria: both are proficient in troubleshooting ETC issues). );

[0200] Calculate Ws:

[0201] Seat A: Ws = 41.3 points (corresponding to) Second);

[0202] Seat B: Ws = 35.6 points (corresponding to) Second);

[0203] Match score:

[0204] Seat A: ;

[0205] Seat B: ;

[0206] Assign seat A, push work order, and record T1=2.8 seconds (T1=10:05:32.8-10:05:30=2.8).

[0207] Step 4: Work order processing (the work order is currently at the agent level)

[0208] Seat A received the work order (received at 10:05:32.8), provided voice guidance to the driver to reset the ETC, and completed the process at 10:05:42.3;

[0209] The report time is T2=9.5 seconds (T2=42.3-32.8=9.5), and the processing result is "successful passage".

[0210] Step 5: Data Reporting and Weight Update

[0211] The cloud warehouse node writes "work order characteristics, agent A characteristics, T1=2.8, T2=9.5" into the self-supervised database;

[0212] In subsequent weight updates, this data will be used to calculate the impact of "real-time exit traffic flow" and "proficient business types" to optimize performance. .

[0213] Example 4

[0214] like Figure 3 As shown, a highway toll order processing system based on multi-dimensional dynamic weights is provided. The system is used to execute a highway toll order processing method based on multi-dimensional dynamic weights as described in any of the foregoing embodiments, and includes a feature acquisition layer, a toll station service node, and a cloud warehouse service node.

[0215] The feature acquisition layer includes several feature acquisition modules installed at each toll station, used to collect feature data for each work order. In addition to work order attribute features (including work order type, vehicle type, lane type, entrance / exit, license plate color, etc.), real-time feature acquisition is also performed; for example:

[0216] ① Traffic flow characteristics: Real-time traffic flow at exits (unit: vehicles / hour), real-time traffic flow at entrances (unit: vehicles / hour);

[0217] ② Device characteristics: Self-service device time abnormality (in this embodiment, 0 = normal, 1 = abnormal, such as when the clock offset causes payment failure, the output is 1);

[0218] After data collection is completed, the "basic attributes + real-time features" are pushed to the toll station service node via TCP / IP protocol, while the work order and the T1 start timestamp are cached (this timestamp is used for subsequent T1 calculation).

[0219] The toll station service node includes a preliminary allocation module and several local agents. The preliminary allocation module receives pending work orders, calculates the priority of each work order based on a dynamic weight model, and prioritizes low-priority work orders (i.e., Wt < 25 points) to local agents, while medium- and high-priority work orders (i.e., Wt ≥ 25 points) are pushed to the cloud warehouse node to reduce the T1 increase caused by cross-level transmission. The local agents are used to process pending work orders at the current toll station whose dynamic priority weight is lower than a preset allocation threshold.

[0220] The cloud warehouse service node includes a work order allocation module, a weight update module, and several cloud warehouse agents; the work order allocation module is used to allocate work orders to be processed to each cloud warehouse agent; the weight update module is used to dynamically update the calculation parameters of priority weights.

[0221] After completing the processing, the local and cloud warehouse agents also need to report the T2 timestamp of the work order in real time (i.e., the time taken from receiving the work order to its completion).

[0222] Example 5

[0223] like Figure 4 As shown, a highway toll ticket processing device based on multi-dimensional dynamic weights includes at least one processor, a memory communicatively connected to the at least one processor, and at least one input / output interface communicatively connected to the at least one processor. The memory stores instructions executable by the at least one processor, which, when executed, enables the at least one processor to perform the highway toll ticket processing method based on multi-dimensional dynamic weights described in the foregoing embodiments. The input / output interface may include a display, keyboard, mouse, and USB interface for inputting and outputting data.

[0224] Furthermore, the highway toll processing device based on multi-dimensional dynamic weights can be a desktop computer, mobile phone, tablet computer, wearable highway toll processing device based on multi-dimensional dynamic weights, etc., capable of deep information recognition.

[0225] Furthermore, the processor may include one or more processing cores. The processor connects various parts of the highway toll processing device based on multi-dimensional dynamic weights using various interfaces and lines. It executes various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory, and by calling data stored in memory. Optionally, the processor may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor may integrate one or more of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the displayed content; and the modem handles wireless communication. It is understood that the modem may also be implemented separately as a communication chip, without being integrated into the processor.

[0226] The memory may include random access memory (RAM) or read-only memory (ROM). The memory can be used to store instructions, programs, code, code sets, or instruction sets, such as instructions or code sets used to implement the highway toll ticket processing method based on multi-dimensional dynamic weights provided in this application embodiment. The memory may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function, instructions for implementing the various method embodiments described above, etc. The data storage area may also store data created during the use of the highway toll ticket processing device based on multi-dimensional dynamic weights (such as a modulation sequence-depth mapping table, image data, spectrogram data, etc.).

[0227] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0228] When the integrated units of the present invention are implemented as software functional units and sold or used as independent products, they can also be stored in a computer-readable storage medium. The computer-readable storage medium stores program code, which can be called by a processor to execute the methods described in the above method embodiments. Based on this understanding, the technical solution of the embodiments of the present invention, or the part that contributes to the prior art, 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 methods described in the various embodiments of the present invention. The aforementioned storage medium includes electronic memories such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM. Optionally, the computer-readable storage medium includes a non-transitory computer-readable storage medium. The computer-readable storage medium has storage space for program code that executes any of the method steps described above. This program code can be read from or written to one or more computer program products. The program code can be compressed, for example, in an appropriate form.

[0229] This invention is used in a reasonable manner.

[0230] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for processing highway toll tickets based on multi-dimensional dynamic weights, characterized in that, Includes the following steps: S1: Receive pending work orders in real time, calculate the dynamic priority weight of each pending work order, and allocate the pending work orders to the corresponding processing queue. When the dynamic priority weight of the work order is less than the preset allocation threshold, the corresponding work order to be processed will be allocated to the local queue of the service node; otherwise, it will be uploaded to the global queue of the cloud warehouse. The work order characteristics of the dynamic priority weight of the work order include any one or more of the following: work order type, vehicle type, lane type, traffic flow scale at entrances and exits, traffic flow scale at toll stations, license plate color, real-time traffic flow at exits, real-time traffic flow at entrances, and abnormal self-service time. S2: Based on the dynamic priority weight of the work orders, sort the work orders to be processed in the processing queue in descending order, and allocate each work order to be processed in order. S3: Get the online agents in the area corresponding to the current pending work order, calculate the dynamic priority weight of each agent, and output the agent list in descending order; The personnel characteristics for the dynamic priority weight of personnel include personnel role, idle time, number of work orders processed in a day, whether it is a station on the same road segment, number of pending work orders, and any one or more of the business types they are good at. S4: Calculate the matching score between the current pending work order and the first set number of seats in the seat list, and assign the current pending work order to the seat with the highest matching score; S5: After a pending work order is completed, the priority weight calculation parameters are dynamically updated based on the actual processing time of the pending work order. The expression for the dynamic priority weight of the work order is: ， ， Where Wt is the dynamic priority weight of the work order, and n is the number of work order features. The sub-weights of the i-th work order feature are... Let be the real-time influencing factor of the i-th work order feature. Historical feedback coefficient, As a preset historical impact factor, This represents the target completion time for the work order. Let be the historical average completion time of the work order corresponding to the i-th work order feature; The expression for the dynamic priority weight of personnel is: ， ， Where Ws represents the dynamic priority weight of personnel, and m represents the number of personnel features. For the sub-weight of the j-th person feature, Let j be the real-time influencing factor of the j-th personnel characteristic. This is the historical feedback coefficient for agent seats. The preset historical influence factor of the seats, This is the target value for work order processing time. Let be the historical average processing time of the s-th agent for work orders of type k.

2. The highway toll order processing method based on multi-dimensional dynamic weights according to claim 1, characterized in that, The S4 also includes a secondary matching mechanism, comprising the following steps: Once a work order is assigned, if no confirmation feedback is received from an agent within the preset confirmation time threshold, or if the processing exceeds the set timeout threshold, the assignment is deemed a failure. Increase by 0.1 and re-enter S1; If a pending work order fails to be assigned three times, the corresponding pending work order will be marked as an urgent work order and pushed to all online agents until confirmation feedback is received from an agent.

3. The highway toll order processing method based on multi-dimensional dynamic weights according to claim 1, characterized in that, The expression for the matching score in S4 is: ， in, For matching scores, Wt represents the dynamic priority weight of work orders, and Ws represents the dynamic priority weight of personnel. The historical average processing time for the s-th agent to process work orders of type k.

4. The method for processing highway toll work orders based on multi-dimensional dynamic weights according to claim 1, characterized in that, The dynamic update in S5 includes the following steps: S51: Obtain the allocation time and processing time of each processed work order within the set update time; S52: Calculate the influence degree of each feature on time; S53: Update each sub-weight according to the influence degree of the feature; S54: Continuously run the verification time with the updated optimized weights, and calculate the average total time before the update and the average total time after the update; If the average total time before the update is greater than the average total time after the update, the updated optimization weight is valid; otherwise, the updated optimization weight is invalid, and the sub-weights of the optimization weight are rolled back to the values ​​before the update.

5. The highway toll order processing method based on multi-dimensional dynamic weights according to claim 4, characterized in that, The expression for the feature influence degree in S52 is: ， in, The feature influence degree of feature X; The Pearson correlation coefficient between feature X and time T. This represents the average time consumed when feature X is a valid value; This represents the average time taken when X is an invalid value; This represents the average time spent on all work orders. like Feature X is positively correlated with T, so the weight of feature X needs to be increased; like Feature X is negatively correlated with T, and its weights need to be maintained or fine-tuned.

6. The highway toll order processing method based on multi-dimensional dynamic weights according to claim 5, characterized in that, In S53, gradient descent is used for iterative weight updates, and its expression is: ， ， in, The sub-weights are the updated values ​​for feature X. The sub-weights before feature X is updated. The preset learning rate, This is the maximum weight value set.

7. A highway toll order processing system based on multi-dimensional dynamic weights, characterized in that, The system is used to execute a highway toll order processing method based on multi-dimensional dynamic weights as described in any one of claims 1 to 6, including a feature acquisition layer, a toll station service node, and a cloud warehouse service node; The feature acquisition layer includes several feature acquisition modules installed at each toll station, used to collect feature data of each work order; The toll station service node includes a preliminary allocation module and several local agents; the preliminary allocation module is used to receive pending work orders and calculate the corresponding dynamic priority weight of the work orders for preliminary allocation; the local agents are used to process pending work orders in the current toll station whose dynamic priority weight is lower than a preset allocation threshold. The cloud warehouse service node includes a work order allocation module, a weight update module, and several cloud warehouse agents; the work order allocation module is used to allocate work orders to be processed to each cloud warehouse agent; the weight update module is used to dynamically update the calculation parameters of priority weights.

8. A highway toll order processing device based on multi-dimensional dynamic weights, characterized in that, The device includes at least one processor and a memory communicatively connected to the at least one processor; the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform a highway toll order processing method based on multi-dimensional dynamic weights as described in any one of claims 1 to 6.

Images