Intelligent scheduling method and system based on road operation data analysis

Abstract

The application discloses an intelligent scheduling method and system based on road operation data analysis, and belongs to the technical field of big data processing, and comprises the following steps: obtaining road operation data and determining a congestion road unit; generating a congestion cause label, a scheduling instruction and a planned scheduling parameter value according to the congestion road unit; obtaining an execution effectiveness coefficient of the scheduling instruction and an influence road unit set; determining a single-instruction feedback observation unit and an overlapping feedback observation unit according to the influence road unit set and obtaining a sub-item attribution change amount of each scheduling instruction; and generating a scheduling parameter correction basis according to the sub-item attribution change amount. Through execution effectiveness verification, influence road unit division and sub-item attribution calculation, the application forms a scheduling parameter correction and cause reverse verification basis, achieves the technical effect of distinguishing the actual effect of parallel scheduling measures and improving the accuracy of parameter correction, and solves the problems that in the prior art, only overall index is used to evaluate scheduling effect and the single-instruction feedback basis is insufficient.

Description

Technical Field

[0001] This invention relates to the field of big data processing technology, and in particular to an intelligent scheduling method and system based on road operation data analysis. Background Technology

[0002] With the continuous growth of urban road traffic flow, main urban roads, intersections, areas around schools and hospitals, entrances and exits of commercial districts, and commuter corridors are prone to traffic anomalies such as slow speeds, increased queues, and decreased traffic efficiency during morning and evening rush hours, holidays, and emergencies. Because road traffic operations have a clear network interconnectedness, the congestion status of a road segment or intersection is not only affected by the traffic flow of that segment but also by upstream release intensity, downstream capacity, queue lengths at adjacent intersections, lane occupancy incidents, and vehicle detour behavior. Relying solely on manual inspections, fixed signal timings, or single-point traffic control methods makes it difficult to promptly grasp the operational changes between multiple road units, and also makes it difficult to coordinate signal release, route guidance, upstream flow control, and incident handling based on real-time road conditions. Therefore, an intelligent scheduling method and system based on road operation data analysis is needed to process road operation data by computer and generate traffic scheduling schemes adapted to changes in road conditions based on the analysis results.

[0003] Existing intelligent urban road dispatching systems typically monitor the operational status of target road segments, intersections, or intersection groups by accessing intersection signal phase data, geomagnetic or radar detection data, video recognition data, vehicle trajectory data, road event data, and road network topology data. These systems generally first clean, time-align, and spatially match the collected road operation data. Then, based on indicators such as average vehicle speed, queue length, road occupancy, traffic delay, and traffic flow, they determine whether the road is congested. After identifying congested road segments or intersections, they generate dispatching instructions such as signal timing adjustments, route guidance, upstream traffic restrictions, or event handling, thereby dispatching traffic signal control equipment, traffic guidance dissemination terminals, vehicle terminals, or traffic management and processing terminals.

[0004] The above-mentioned technology has at least the following technical problems: Existing intelligent dispatching methods based on road operation data analysis typically evaluate the dispatching effectiveness based on changes in road operation status before and after dispatching instructions are issued and executed. These methods often use overall indicators such as regional average vehicle speed, congestion index, queue length, and travel time as the basis for judgment to determine whether the current round of dispatching has improved the traffic conditions of the target area. However, in actual urban road dispatching, multiple dispatching measures, such as signal timing adjustments, route guidance, upstream flow control, regional coordinated control, incident handling, and lane management, may be executed concurrently within the same or adjacent time windows. The impacts of different dispatching measures on the same or adjacent road units can easily overlap. Existing methods mainly evaluate dispatching effectiveness based on changes in overall operation indicators. The feedback results usually tend to reflect the overall improvement degree of the target area or target road segment, and do not adequately express the correlation between the target of the dispatching instructions, execution time, dispatching parameter values, affected road range, and changes in road operation. This results in a lack of more detailed data basis for subsequent reuse, adjustment, or rollback of dispatching parameters.

[0005] Furthermore, existing methods, in the process of feedback and correction of scheduling effects, typically fail to fully establish the correspondence between the target of scheduling instructions, execution time, scheduling parameter values, affected road range, and changes in road operation before and after scheduling. When the average vehicle speed increases, queue length decreases, or travel time shortens within a certain time window, the platform struggles to determine whether this change primarily stems from green light increments, diversion ratios, traffic restriction intensity, handling priorities, or other parallel scheduling measures. Similarly, when road operation does not improve or exhibits a reverse change, it is difficult to determine whether it is due to improper setting of specific scheduling parameters or the cumulative effect of other scheduling measures. Therefore, subsequent adjustments to scheduling parameters often lack feedback basis specific to individual scheduling instructions and parameters, easily leading to unclear grounds for parameter reuse, adjustment, or rollback. Summary of the Invention

[0006] To address the technical problems in existing technologies where evaluation of scheduling effectiveness relies solely on overall indicators and feedback from individual instructions is insufficient, this invention provides an intelligent scheduling method and system based on road operation data analysis. The technical solution is as follows: On the one hand, an intelligent scheduling method based on road operation data analysis is provided. This method is applied to an urban road traffic management platform and includes: acquiring road operation data and identifying congested road units; generating congestion cause labels, scheduling instructions, and planned scheduling parameter values ​​based on the congested road units, and issuing scheduling instructions; acquiring execution data of scheduling instructions and calculating execution effectiveness coefficients, and determining the set of affected road units based on the target of the scheduling instructions and the road network topology; determining single-instruction feedback observation units and overlapping feedback observation units based on the set of affected road units, road operation data before and after scheduling, and the number of associated scheduling instructions; obtaining the sub-item attribution change of each scheduling instruction based on the single-instruction feedback observation units and overlapping feedback observation units; generating a scheduling parameter correction basis based on the sub-item attribution change, correcting the planned scheduling parameter values ​​in subsequent similar scheduling scenarios based on the scheduling parameter correction basis, and generating scheduling instructions in subsequent similar scheduling scenarios.

[0007] On the other hand, an intelligent dispatching system based on road operation data analysis is provided. This system is applied to urban road traffic management platforms and includes: a road operation identification module for acquiring road operation data and identifying congested road units; a dispatch instruction generation module for generating congestion cause labels, dispatch instructions, and planned dispatch parameter values ​​based on congested road units, and issuing dispatch instructions; an execution verification module for acquiring execution data of dispatch instructions, calculating execution effectiveness coefficients, and determining the set of affected road units based on the target of the dispatch instructions and the road network topology; a feedback observation module for determining single-instruction feedback observation units and overlapping feedback observation units based on the set of affected road units, road operation data before and after dispatch, and the number of associated dispatch instructions; a component attribution module for obtaining the component attribution change of each dispatch instruction based on the single-instruction feedback observation units and overlapping feedback observation units; and a parameter correction module for generating dispatch parameter correction basis based on the component attribution change, correcting the planned dispatch parameter values ​​in subsequent similar dispatch scenarios based on the dispatch parameter correction basis, and generating dispatch instructions in subsequent similar dispatch scenarios.

[0008] The beneficial effects of the technical solutions provided in the embodiments of the present invention include at least the following: After dispatch instructions are issued, an execution effectiveness coefficient is calculated based on different instruction types, and the dispatch instructions are categorized into fully effective execution instructions, partially effective execution instructions, and execution abnormal instructions. Since the execution effectiveness coefficient is derived from actual execution logs, release logs, vehicle trajectory data, or feedback data from the handling terminal, it reflects whether the dispatch instructions were received, whether they actually took effect, and the degree of actual execution. Therefore, in subsequent feedback corrections, the platform can exclude execution abnormal instructions such as those that were not executed, had abnormal parameters, or had no valid response samples, and only include dispatch instructions that meet the execution effectiveness conditions in the feedback attribution. This avoids associating instructions that did not actually take effect with the road operation change results, thereby reducing the contamination of dispatch effectiveness evaluation and parameter correction results by invalid samples.

[0009] Based on the target of the dispatching instruction and the road network topology, the set of affected road units is determined, and feedback observation units are formed based on road operation data before and after the dispatching period. Simultaneously, single-instruction feedback observation units and overlapping feedback observation units are distinguished. Single-instruction feedback observation units are affected by only one dispatching instruction, and their road operation changes are more suitable for calculating the individual effect of that instruction. Overlapping feedback observation units are affected by two or more dispatching instructions simultaneously; directly attributing them to a single instruction could easily misrepresent the changes resulting from the superposition of multiple measures as the effect of a single instruction. Therefore, by distinguishing between these two types of feedback observation units, a relatively independent action benchmark can be first established using single-instruction feedback observation units, and then overlapping feedback observation units can be proportionally allocated or jointly recorded, improving the reliability of feedback attribution results in scenarios where multiple dispatching measures are executed in parallel.

[0010] By calculating the attribution changes of each dispatch instruction using single-instruction feedback observation units and overlapping feedback observation units, the platform can establish a correspondence between changes in road operation before and after dispatch and specific dispatch instructions, dispatch parameter values, and affected road units. Thus, the platform can not only determine whether the overall traffic condition has improved, but also further determine the actual effect of a particular green light increment, diversion ratio, flow restriction intensity, handling priority, or lane control parameter on the road operation status, providing traceable data for subsequent dispatch parameter adjustments.

[0011] Based on the changes in attribution for each item, reusable parameter records, partially valid parameter records, parameter records to be corrected, and rollback parameter records are generated and written to the scheduling parameter correction library. Through these records, the platform can prioritize scheduling parameters that have generated valid feedback in subsequent similar scheduling scenarios, re-test scheduling parameters that have not generated clear feedback, and roll back or prohibit the reuse of scheduling parameters that generate negative feedback. This reduces the repeated use of invalid or negative parameters in similar scenarios, improving the stability and adaptability of scheduling parameter selection. Furthermore, the platform performs reverse verification of congestion cause labels based on the changes in attribution for each item, and corrects the trigger thresholds, verification conditions, verification order, or priority in the cause determination parameter table when the sample quantity condition is met. Therefore, when a scheduling instruction is invalid or generates negative feedback, the platform can not only correct the scheduling parameter values ​​but also reverse-check whether the previous congestion cause judgment matches the actual road operating status, reducing the probability of repeatedly generating mismatched congestion cause labels in subsequent similar scenarios. Attached Figure Description

[0012] Figure 1 A flowchart of an intelligent scheduling method based on road operation data analysis provided in this application embodiment; Figure 2 A flowchart illustrating the method for modifying the cause determination parameter table provided in this application embodiment; Figure 3 A schematic diagram of the structure of an intelligent dispatching system based on road operation data analysis provided in an embodiment of this application; Figure 4 A typical road segment daily traffic flow variation curve is provided for the embodiments of this application; Figure 5 The traffic flow distribution line graph provided in this application embodiment. Detailed Implementation

[0013] This invention, through validity verification, influencing road unit division, and itemized attribution calculation, forms the basis for scheduling parameter correction and reverse causal verification. This achieves the technical effect of distinguishing the actual effects of parallel scheduling measures and improving the accuracy of parameter correction, solving the problem in existing technologies where scheduling effectiveness is evaluated solely based on overall indicators and feedback from individual instructions is insufficient. To make the technical problems, solutions, and advantages of this invention clearer, a detailed description will be provided below in conjunction with the accompanying drawings and specific embodiments.

[0014] Example 1: As Figure 1The flowchart shown illustrates an intelligent scheduling method based on road operation data analysis. The urban road traffic management platform reads road operation data from road units within the target area from traffic signal control equipment, regional signal control systems, detection equipment, video recognition equipment, vehicle trajectory data sources, event reporting terminals, and the road network topology database. Road units include road segments, intersection approach lanes, intersection exit lanes, and adjacent upstream and downstream road units. Road operation data includes road unit number, collection time, data source number, average vehicle speed, queue length, inbound traffic flow, outbound traffic flow, road occupancy rate, travel time, vehicle trajectory location, signal phase number, phase start time, phase end time, green light duration, event type, event location, event start time, event end time, event-occupied lane number, and the corresponding upstream and downstream road unit numbers.

[0015] like Figure 4 The chart shown represents the daily traffic flow variation curve for a typical road segment within the PEMS04 road network. The horizontal axis represents the time step, with units of 5 minutes per step (i.e., a 5-minute interval between two adjacent time steps); the vertical axis represents vehicle flow, with units of vehicles per 5 minutes, indicating the number of vehicles passing through the road segment within the corresponding time step. The chart displays traffic flow changes over approximately 2000 consecutive time steps, reflecting the short-term fluctuations and periodic trends in traffic flow for this road segment. While the original data curve exhibits significant fluctuations, the smoothed trend curve reflects the overall direction of traffic flow change, providing a data foundation for subsequent road operation status analysis, abnormal traffic identification, and dynamic scheduling.

[0016] The collected road operation data is time-merged according to the judgment time window T; based on the road network topology, average vehicle speed, queue length, inbound flow, outbound flow, road occupancy, signal phase, and event location are matched to the corresponding road units; data records lacking road unit numbers or collection times are removed; for multiple detection data within the same road unit and the same time window, the time window statistical values ​​of the corresponding indicators are calculated. The judgment time window T is determined based on the road operation data collection cycle and the intersection signal control cycle; for intersection approach lanes, T is taken as one signal cycle or an integer multiple of the signal cycle; for non-signal-controlled road sections, T is taken as an integer multiple of the detection equipment's collection cycle, and is not less than the maximum upload latency of each data source. For each road unit, the average vehicle speed of the current time window is compared with the low-speed threshold V0, and the queue length of the current time window is compared with the queue length threshold Q0. The queue length of the previous time window is subtracted from the queue length of the current time window to obtain the queue growth. When the average vehicle speed is ≤ V0 and the queue length is ≥ Q0 or the queue growth is ≥ ΔQ0, the road unit is identified as a congested road unit; otherwise, it is not considered for scheduling in this round. The low-speed threshold V0, queue length threshold Q0, and queue growth threshold ΔQ0 are configured separately for each road unit. The low-speed threshold V0 is preferentially determined based on the preset low-speed percentile value of the average vehicle speed within the historical non-congested time window of the road unit. When historical samples are insufficient, the platform reads the road speed limit value S and generates an initial low-speed threshold according to V0 = S × ρv, where ρv is the low-speed ratio configuration value. In one specific implementation, the preset low-speed percentile value is set to the 15th percentile, and when historical samples are insufficient, ρv is set to 0.40, meaning V0 is 40% of the road speed limit value. The queue length threshold Q0 is determined based on the queuing length or the number of vehicles that a road unit can accommodate. The queuing length is determined by the road network topology database and road geometry data, including information such as stop lines, road start and end nodes, number of lanes, upstream intersections, merging points, bus stops, and no-parking zones. For intersection approach lanes, the queuing length is the effective length from the stop line upstream to the upstream intersection, the start of the road segment, or other queuing blockage point, after deducting non-queuing sections. If the queuing index is expressed in terms of length, then Q0 = Lq × ρq, where Lq is the queuing length and ρq is the preset queuing occupancy ratio. If the queuing index is expressed in terms of the number of vehicles, then the number of vehicles that can be accommodated is calculated based on the queuing length, the number of lanes, and the average queuing vehicle occupancy length, and Q0 is determined accordingly. The current queue length refers to the road projection length from the tail of the queue to the stop line, downstream bottleneck point, or road unit control point within the current judgment time window T. If the detection device directly outputs the queue length, then it is read directly; if it does not output it directly, then it is calculated based on the projected distance of the road centerline between the end of the queue and the stop line or bottleneck point; if only the number of vehicles in the queue is obtained, then it is converted by multiplying the number of vehicles in the queue by the average length occupied by the vehicles in the queue.The queue growth threshold ΔQ0 is primarily determined based on the preset growth quantile of the queue length growth in historical adjacent time windows for that road unit. When historical samples are insufficient, the platform reads the allowable queue growth length G0 per unit time from the queue growth configuration table and determines it according to ΔQ0 = G0 × T. The allowable queue growth length G0 per unit time is configured based on road grade, number of lanes, signal control cycle, average queue vehicle occupancy length, allowable number of new queue vehicles per unit time, and downstream remaining capacity. In one specific implementation, the preset growth quantile is taken as the 90th percentile of the queue length growth in historical adjacent time windows.

[0017] like Figure 5 The traffic flow distribution line chart shown is a histogram that statistically analyzes the traffic flow distribution pattern of typical road sections, intuitively presenting the difference between the normal operating load and peak traffic flow of the road network. The chart shows that most traffic flow data is concentrated in the low to medium range, with significant peaks only occurring in a few periods, clearly reflecting the distribution characteristics of the road network's normal operating level and extreme situations. This distribution characteristic provides a key reference for the intelligent dispatch system's congestion threshold setting and load balancing control strategies, helping the system accurately identify abnormal traffic events and initiate pre-control measures in advance to prevent congestion from spreading. For each congested road unit, the platform reads its upstream and downstream road units based on the road network topology, extracts the upstream release traffic flow, green light duration, and signal phase status within the current time window to form the upstream release situation; it also extracts the current queue length and road occupancy rate downstream, subtracting the current queue length from the downstream available queue length to obtain the remaining acceptance length, forming the downstream queue situation. Specifically, the platform reads the event number, event coordinates, event road unit number, event lane number, event start time, and event end time from road event data to form raw event location data. Then, it determines the spatial range of the congested road unit based on the road centerline, road boundaries, lane boundaries, and the start and end points of the road unit. If the event road unit number matches the congested road unit number, or the event coordinates fall within this spatial range, or the distance from the event coordinates to the road centerline is less than a preset spatial tolerance and the projected position is between the start and end points of the road unit, and the event time intersects with the current judgment time window, then the event is determined to be associated with the congested road unit, generating an event association result. The platform also subtracts the entry flow from the previous time window from the current entry flow of the congested road unit to obtain the change in entry flow between adjacent time windows, or subtracts the historical baseline entry flow from the current entry flow of the same time window to obtain the change in entry flow relative to the historical baseline.

[0018] The platform generates congestion cause tags for each congested road unit based on the cause determination parameter table. These tags include insufficient signal clearance, downstream overflow, sudden increase in inbound traffic, and event occupancy. Each congestion cause tag is associated with a trigger condition number, participating road operation indicators, cause determination parameter values, and candidate dispatch instruction types. The candidate dispatch instruction types are used to select corresponding dispatch instruction templates from the dispatch instruction template library. These types include signal timing adjustment instructions, upstream flow restriction instructions, regional linkage control instructions, route guidance instructions, event handling and dispatch instructions, and lane control instructions. The dispatch instruction template library consists of existing data tables or configuration files used in existing urban road traffic management platforms to unify dispatch instruction formats. This method does not change the template format of the dispatch instruction template library; instead, it calls the templates corresponding to the candidate dispatch instruction types and writes the current congested road unit, the corresponding congestion cause tag, and the planned dispatch parameter values ​​into the templates to form the initial dispatch instructions. The cause determination parameter table is a pre-configured data table of the urban road traffic management platform that can be updated and fed back. It is used to generate congestion cause labels and store the cause determination parameter values ​​corresponding to each congestion cause label. The cause determination parameter values ​​include at least the following: for the insufficient signal release label, the remaining queue threshold, downstream acceptance threshold, downstream acceptance verification conditions, and number of consecutive signal cycles; for the downstream overflow label, the overflow ratio threshold and downstream remaining acceptance length threshold; for the sudden increase in inbound traffic label, the inbound traffic growth threshold, inbound traffic growth ratio threshold, and verification order; and for the event occupancy label, the event space overlap threshold, event time overlap conditions, event individual trigger priority, joint verification flag, number of occupied lanes threshold, and travel time growth threshold.

[0019] When a congested road unit is an intersection approach lane, and the remaining queue length after the green light ends is greater than the remaining queue threshold for a consecutive preset number of signal cycles, while the remaining acceptance length of downstream road units is greater than the downstream acceptance threshold, and there are no event occupancy tags overlapping with the congested road unit, a signal insufficient release tag is generated, and a signal timing adjustment instruction is generated. When the ratio of the current queue length to the available queue length of the downstream road unit of the congested road unit is greater than or equal to the overflow ratio threshold, or the remaining acceptance length of the downstream road unit is less than or equal to the remaining acceptance length threshold, a downstream overflow tag is generated, and an upstream flow restriction instruction or regional linkage control instruction is generated. When the difference between the inbound traffic in the current time window and the inbound traffic in the previous time window of the congested road unit is greater than or equal to the inbound traffic growth threshold, or the growth ratio of the inbound traffic in the current time window relative to the baseline inbound traffic in the same historical time window is greater than or equal to the inbound traffic growth ratio threshold, and no downstream overflow tag or event occupancy tag is generated, an inbound traffic surge tag is generated, and a path guidance instruction is generated. When the location of an event in the road event data falls within the congested road unit space, or the event road unit number matches the congested road unit number, and the event start time overlaps with the current time window, an event occupancy tag is generated, along with an event handling dispatch instruction or lane control instruction. The remaining queue length after the green light ends is determined by the platform based on the queue length of the target approach lane at the end of the green light in the corresponding signal cycle. Specifically, the platform reads the signal phase end time of the approach lane and extracts the corresponding queue tail position and stop line position from video recognition data, radar detection data, geomagnetic detection data, or vehicle trajectory data. The road length between the queue tail position and the stop line position is taken as the remaining queue length after the green light ends. If the detection data directly outputs the queue length, the queue length corresponding to the green light end time is taken as the remaining queue length after the green light ends. If there is no detection value at the green light end time, the data closest to the green light end time with a time difference not exceeding the preset sampling allowable time is taken as the remaining queue length for that signal cycle. If the time difference exceeds the preset sampling allowable time, that signal cycle is not included in the continuous signal cycle judgment.

[0020] Signal timing adjustment instructions include target intersection number, target phase number, effective period, green light increment, and maximum green light constraint; upstream traffic restriction instructions include upstream intersection number, controlled phase number, effective period, and traffic restriction intensity; route guidance instructions include target congested road unit, candidate alternative route, guidance release time, diversion ratio, and guidance release terminal; incident handling dispatch instructions include incident number, incident location, incident type, occupied lane number, type of object to be handled, handling priority, and recommended arrival route; lane control instructions include target road unit, target lane number, and lane indication. The system includes the type, effective time, and termination conditions of regional coordinated control instructions. These instructions include a set of associated intersections, the target road unit, control actions corresponding to each associated intersection, control parameter values, effective period, and coordination constraints. Control actions include extending green lights or prioritizing phases at downstream intersections of the target congested road unit, shortening green lights, extending clearance intervals, or implementing flow control at upstream intersections of the target congested road unit, and adjusting phase differences or coordinating clearance at adjacent associated intersections. Control parameter values ​​include green light increments, green light shortening amounts, flow control intensity, phase difference adjustments, or the number of coordinated clearance cycles. Specifically, when a congested road unit has insufficient downstream capacity or a risk of queue overflow, the platform generates a regional coordinated control instruction and writes the target congested road unit, upstream associated intersections, and downstream associated intersections into the set of associated intersections. After receiving the regional linkage control command, the regional signal control system increases the green light duration or raises the priority of the target phase for downstream associated intersections to increase the vehicle dissipation capacity of downstream road units. At the same time, it reduces the green light duration, extends the release interval, or lowers the release ratio for the target congested road unit for upstream associated intersections to limit the number of vehicles continuing to enter the congested area. For adjacent associated intersections, it adjusts the phase difference or coordinates the release cycle according to the coordination constraints so that upstream traffic restriction and downstream evacuation are carried out in coordination within the same effective cycle.

[0021] The platform retrieves the corresponding dispatch instruction template from the dispatch instruction template library based on the candidate dispatch instruction types associated with congestion cause tags, and generates the planned dispatch parameter values ​​in the dispatch instruction according to the preset traffic dispatch rule library. The preset traffic dispatch rule library is an existing rule library in the urban road traffic management platform, and this method directly calls this rule library to determine the initial dispatch instruction parameters. Specifically, when the platform invokes existing signal timing adjustment rules, it generates green light increments based on the remaining queue length of the intersection approach lanes, the unit green light release capacity, and the maximum green light constraint; when the platform invokes existing upstream flow restriction rules, it generates flow restriction intensity based on the remaining downstream acceptance length, the expected number of vehicles to be released upstream, and the green light duration of the controlled phase; when the platform invokes existing route guidance rules, it generates diversion ratios based on the portion of the inflow into congested road units that exceeds the historical baseline inflow and the remaining capacity of candidate alternative routes; when the platform invokes existing event handling and dispatch rules, it generates handling priorities based on event type, number of lanes occupied by the event, road grade, queue length, and increase in travel time; when the platform invokes existing lane control rules, it generates target lane numbers and lane prompt types based on the lane number occupied by the event, lane traffic status, and road unit lane number; when the platform invokes existing regional linkage control rules, it generates green light increments or flow restriction intensity for each associated intersection based on the queue length, remaining acceptance length, and phase coordination constraints of the target road unit and its upstream and downstream road units.

[0022] The platform issues signal timing adjustment instructions, upstream flow restriction instructions, and regional linkage control instructions to traffic signal control equipment or regional signal control systems; route guidance instructions to navigation platforms, vehicle terminals, variable message signs, or roadside guidance screens; incident handling dispatch instructions to traffic management and handling terminals, clearing vehicle terminals, or road maintenance terminals; and lane control instructions to lane indicating devices, variable message signs, or traffic management terminals. After issuing a dispatch instruction, the platform confirms the instruction's issuance based on the returned issuance receipt and generates a dispatch instruction record indexed by the instruction number. The dispatch instruction record includes the instruction number, instruction type, issuance time, target road unit, target object, planned effective time, planned target object number, planned dispatch parameter value, planned display content, corresponding congestion cause label, trigger condition number, participating judgment indicators, and cause judgment parameter value. The planned display content refers to text, graphics, or lane status prompts that need to be displayed to vehicles or management personnel through navigation platforms, variable message signs, roadside guidance screens, or lane indicator devices, such as route guidance, lane control, or event alerts. For dispatch instructions that do not involve information dissemination or display prompts, the planned display content field is empty or marked as inapplicable. The corresponding congestion cause label is the congestion cause label generated when the dispatch instruction is triggered. When the same congested road unit simultaneously meets the triggering conditions of multiple congestion cause labels and generates multiple dispatch instructions, the platform writes the corresponding congestion cause label into each dispatch instruction record. When the same dispatch instruction is triggered by multiple congestion cause labels, the platform writes the highest priority congestion cause label into the corresponding congestion cause label field according to cause priority, and writes the remaining congestion cause labels into the auxiliary congestion cause label field.

[0023] For each issued dispatch instruction, the platform reads whether it has been received, whether it has been executed, and the start and end times of execution. For executed dispatch instructions, the platform reads their reception status, execution status, start and end times. For executed dispatch instructions, the platform retrieves the actual dispatch parameter values ​​from the corresponding data source according to the instruction type. For signal timing adjustment instructions, upstream flow restriction instructions, and regional linkage control instructions, the actual dispatch parameter values ​​are read from the execution log returned by the traffic signal control equipment or regional signal control system. The execution log includes at least the actual effective time, the actual intersection or phase affected, the actual green light increment, and the actual flow restriction intensity. For route guidance instructions, the platform determines the guidance release time, the scope of influence, and candidate alternative routes based on the guidance information release log. It then filters vehicles that entered the scope of influence after the guidance release time from vehicle trajectory data, counts the number of vehicles that actually entered candidate alternative routes, and uses the ratio of the number of vehicles actually entering candidate alternative routes to the total number of vehicles entering the scope of influence as the actual diversion response rate. If the total number of vehicles entering the scope of influence is 0, the actual diversion response rate is not calculated, and the route guidance instruction is marked as having no valid response sample. For incident handling dispatch instructions, the actual handling status and priority are read from the handling task feedback data returned by the traffic management handling terminal, clearing vehicle terminal, or road maintenance terminal. The handling task feedback data includes at least the task reception status, arrival status, completion status, actual arrival time, actual completion time, and handling priority. For lane control instructions, the actual number of lanes whose traffic indications are changed is read from the status log of the lane indicator device, variable message sign, or traffic management terminal. The status log includes at least the actual displayed content, actual effective time, actual lane number, and actual number of lanes whose traffic indications are changed.

[0024] The set of road units affected by each dispatch instruction is determined based on the road network topology. The set of road units affected refers to the set of road units that may be directly or indirectly affected by the dispatch instruction and are used for subsequent feedback observation. Specifically, the platform first adds the target road unit of the dispatch instruction to the set of road units affected. For signal timing adjustment instructions, the target approach lane, the corresponding exit lane of the target approach lane, and the downstream road units of the target exit lane are added to the set of road units affected. For upstream traffic restriction instructions, the controlled upstream approach lane, its downstream connecting road units, and the target congested road unit are added to the set of road units affected. For route guidance instructions, the original congested road unit, the road units contained in the candidate alternative route, and the merging point of the alternative route are added to the set of road units affected. For event handling dispatch instructions, the road unit where the event is located, the upstream adjacent road unit of the event, and the downstream adjacent road unit of the event are added to the set of road units affected. For lane control instructions, the road unit to which the target lane belongs and its upstream adjacent road units are added to the set of road units affected. For regional linkage control instructions, the approach lanes and exit lanes of the intersections participating in the linkage control and their adjacent upstream and downstream road units are added to the set of road units affected.

[0025] After acquiring the reception status, execution status, execution start time, execution end time, actual scheduling parameter values, and affected road unit set for each issued dispatch instruction, the platform uses the instruction number as an index to associate the instruction type, target road unit, planned scheduling parameter value, and corresponding congestion cause label in the issued dispatch instruction record with the reception status, execution status, execution start time, execution end time, and actual scheduling parameter values ​​obtained from execution logs, release logs, vehicle trajectory statistics results, or data feedback from the handling terminal. Then, the affected road unit set determined according to the road network topology is written into the same record, generating the initial execution record of the dispatch instruction. Specifically, when generating the affected road unit set, the platform uses the road unit number as a unique identifier to deduplicate road units obtained from target road units, upstream and downstream road units, candidate alternative path road units, associated intersection road units, and event-adjacent road units. When the same road unit is added from multiple sources, only one road unit record is retained in the affected road unit set, and the corresponding source type or associated instruction type is stored in this record. For dispatch instructions that are not received or executed, the platform retains the instruction number, instruction type, target road unit, planned dispatch parameter value and corresponding congestion cause label, and marks the reception status or execution status as not received or not executed, records the actual dispatch parameter value as null, does not generate an affected road unit set or records the affected road unit set as an empty set.

[0026] The platform calculates the execution effectiveness coefficient α for each dispatch instruction based on the instruction type. The execution effectiveness coefficient α represents the actual degree of execution of the dispatch instruction, and its value ranges from 0 to 1. For signal timing adjustment instructions, upstream flow restriction instructions, and regional linkage control instructions, the platform reads the execution log returned by the traffic signal control equipment or regional signal control system; the execution log includes at least the actual effective time, actual effective period, actual intersection number, actual phase number, actual green light increment, actual green light shortening amount, or actual flow restriction intensity. When the actual effective time in the execution log matches the planned effective time in the issued dispatch instruction record, the actual effective time falling within the allowed time range corresponding to the planned effective time, or the actual effective period being consistent with the planned effective period, the execution effectiveness coefficient α is set to 1. When the actual intersection number or actual phase number matches the planned target object number in the issued dispatch instruction record, and the actual dispatch parameter value is greater than or equal to the planned dispatch parameter value, the execution effectiveness coefficient α is set to 1. When the actual intersection number or actual phase number matches the planned target object number, and the actual dispatch parameter value is greater than 0 but less than the planned dispatch parameter value, the execution effectiveness coefficient α is set to the ratio of the actual dispatch parameter value to the planned dispatch parameter value. When there is no corresponding execution record in the execution log, or when the actual intersection number, actual phase number, and planned target object number are inconsistent, the execution effectiveness coefficient α is set to 0. When the planned dispatch parameter value is equal to 0, the execution effectiveness coefficient α is not calculated, and the dispatch instruction is marked as a parameter abnormal instruction. For lane control commands, the platform reads the status logs of lane indicator devices, variable message signs, or traffic management terminals. When the actual displayed content in the status log matches the planned displayed content in the issued dispatch command record, the actual lane number matches the planned target number in the issued dispatch command record, the actual effective time matches the planned effective time in the issued dispatch command record, and the actual number of lanes whose traffic indication is changed is greater than or equal to the planned number of lanes whose traffic indication is changed, the execution validity coefficient α is set to 1. When the actual displayed content, the actual lane number, and the actual effective time all meet the above matching conditions, and the actual number of lanes whose traffic indication is changed is greater than 0 but less than the planned number of lanes whose traffic indication is changed, the execution validity coefficient α is the ratio of the actual number of lanes whose traffic indication is changed to the planned number of lanes whose traffic indication is changed. When there is no corresponding display record in the status log, or the actual displayed content, the actual lane number, and the planned field in the issued dispatch command record are inconsistent, the execution validity coefficient α is set to 0. When the planned number of lanes whose traffic indication is changed is equal to 0, the execution validity coefficient α is not calculated, and the dispatch command is marked as a parameter abnormal command. For route guidance instructions, the release logs from the navigation platform, in-vehicle terminals, or guidance screens are read, and the actual diversion response rate is calculated by combining this log with vehicle trajectory data. The actual diversion response rate is the ratio of the number of vehicles entering the candidate alternative route after the guidance release time to the number of vehicles within the guidance's influence range.The effective execution coefficient α is the ratio of the actual diversion response rate to the planned diversion ratio, and α is not greater than 1; if the guidance information is not issued, the effective execution coefficient α is 0. For incident handling dispatch instructions, the task status returned by the traffic management handling terminal, the clearing vehicle terminal, or the road maintenance terminal is read; when the task has not been received, the effective execution coefficient α is 0; when the task has been received but has not reached the incident location, the effective execution coefficient α is the first preset execution coefficient; when the object to be handled has reached the incident location but has not completed the handling, the effective execution coefficient α is the second preset execution coefficient; when the handling task is completed and the completion time falls within the preset handling time range, the effective execution coefficient α is 1. The first preset execution coefficient is used to indicate the degree of execution when the incident handling task has been received but has not yet reached the incident location, and the second preset execution coefficient is used to indicate the degree of execution when the object to be handled has reached the incident location but has not yet completed the handling. The first and second preset execution coefficients are obtained from the task status level table and satisfy 0 < first preset execution coefficient < second preset execution coefficient < 1. The task status level table records the correspondence between task status and execution coefficient. The received but not arrived status corresponds to the first preset execution coefficient, and the arrived but not completed status corresponds to the second preset execution coefficient.

[0027] Within the same judgment time window, the same congested road unit can generate one or more dispatch instructions due to one or more congestion cause labels. The platform calculates the execution effectiveness coefficient α for each issued dispatch instruction. If multiple dispatch instructions act on the same equipment, the same intersection, the same phase, or the same lane, and there are conflicts between the planned dispatch parameters, the platform first resolves the conflicts according to the cause priority, road unit priority, and instruction type priority; if they can be merged, a merged dispatch parameter value is generated; if they cannot be merged, the dispatch instruction with higher priority is retained, and the suppressed dispatch instruction is written into the conflict resolution record. The dispatch instructions that are actually issued and executed after conflict resolution enter the execution effectiveness coefficient calculation process.

[0028] When α equals 1, the corresponding scheduling instruction is marked as a fully valid execution instruction. When α is greater than or equal to the preset valid execution threshold α0 and less than 1, the corresponding scheduling instruction is marked as a partially valid execution instruction, and the actual scheduling parameter value is used in subsequent sub-item attribution. When α is less than the preset valid execution threshold α0, the corresponding scheduling instruction is marked as an execution anomaly instruction, and no sub-item attribution change is generated for this scheduling instruction, nor is this scheduling instruction used for congestion cause reverse verification. The preset valid execution threshold α0 is configured according to the instruction type in the valid execution threshold table. For equipment-automatic execution instructions, α0 is determined based on the minimum identifiable execution ratio of the equipment; for path guidance instructions, α0 is determined based on the low quantile of the historical guidance response rate; for event handling dispatch instructions, α0 is determined based on the execution coefficient corresponding to the arrived but not completed task status level table. Execution anomaly instructions include unexecuted instructions, parameter anomaly instructions, and instructions with no valid response samples.

[0029] After calculating the execution effectiveness coefficient α for each dispatch instruction, the platform uses the instruction number as an index to read the instruction type, planned dispatch parameter values, actual dispatch parameter values, execution start time, and execution end time from the initial execution record of the dispatch instruction; it also reads the actual execution status and actual execution time from the corresponding execution log, status log, guidance information release log, vehicle trajectory statistics results, or data feedback from the handling terminal; and it associates and stores the execution effectiveness coefficient α and the corresponding execution effectiveness flag to generate a dispatch instruction execution verification record. The execution effectiveness flag includes fully effective execution, partially effective execution, and invalid execution. When α equals 1, the execution effectiveness flag is fully effective; when α is greater than or equal to the preset execution effectiveness threshold α0 and less than 1, the execution effectiveness flag is partially effective; when α is less than the preset execution effectiveness threshold α0, or when there are situations such as non-receipt, non-execution, abnormal parameters, no valid response sample, inconsistent actual target, or mismatched actual effective time, the execution effectiveness flag is invalid. The reason for invalid execution is used to explain the specific reason why the dispatch instruction did not enter the subsequent feedback attribution, including non-receipt, non-execution, time mismatch, inconsistent target, abnormal parameters, and no valid response sample. Parameter anomalies refer to planned scheduling parameter values ​​being empty, equal to 0, exceeding the equipment's allowable range, or unable to be effectively compared with actual scheduling parameter values. Lack of valid response samples means that although path guidance instructions have been issued, no vehicle trajectory samples that can be used to calculate the actual diversion response rate have been obtained within the guidance's influence range. Scheduling instructions marked as invalid do not generate sub-attribution change quantities, nor are they used for congestion cause reverse verification. The platform first filters fully valid and partially valid executed instructions from the scheduling instruction execution verification records as scheduling instructions participating in feedback attribution; for execution anomaly instructions, only the execution anomaly record is written, and they are not included in scheduling effect feedback correction or congestion cause reverse verification.

[0030] For each scheduling instruction participating in feedback attribution, the execution start time is preceded by a length of T. f The time period before scheduling is defined as the period before execution; the length after the execution start time plus the response delay τ is defined as T. f The time period is used as the post-scheduling time period. The feedback time window T... f The time window T is determined according to the type of scheduling instruction and the decision time window, where the feedback time window T is... f The determination is based on the decision time window T and the minimum observable action period corresponding to the scheduling command. f =m×T, where m is a positive integer. The platform reads the value of m from the feedback time window multiple table according to the type of scheduling instruction; for signal timing adjustment instructions, upstream current limiting instructions, and regional linkage control instructions, m is set to T. f The smallest positive integer covering at least one complete signal cycle; for path guidance instructions, m takes the value that makes T f The smallest positive integer covering the average travel time of vehicles from the induced influence area to the target road unit or candidate alternative path; for incident handling dispatch instructions and lane control instructions, m takes the value that makes T f The minimum positive integer representing the preset observation time after the coverage status or lane warning takes effect. If the calculated T... f If it is less than the decision time window T, then T f Let T be the response delay τ. This is determined by the time from the start of the dispatch instruction to when observable changes in road conditions become apparent. For signal timing adjustment instructions, τ is the time from the start of the next signal cycle to when vehicles complete one passage at the target approach lane. For upstream traffic restriction instructions, τ is the average travel time from the controlled upstream intersection to the target congested road unit. For route guidance instructions, τ is the average travel time from the time the guidance information is released to when vehicles enter the candidate alternative route. For incident handling dispatch instructions, τ is the estimated arrival time of the object to the incident location. For lane control instructions, τ is the preset observation delay after the lane indication actually takes effect. f Both τ and τ use seconds or minutes as a unified unit of time.

[0031] From road operation data, extract the average vehicle speed, queue length, inbound flow, outbound flow, passage time, and number of occupied lanes of the road unit set affected by the instruction during the pre-schedule and post-schedule time periods. Use a road unit as a comparison object formed within a set of pre-schedule and post-schedule time periods as a feedback observation unit, and record the road unit number, corresponding dispatch instruction number, pre-schedule time period, post-schedule time period, and evaluation index data within the feedback observation unit.

[0032] The platform determines the evaluation indicators and their expected direction of change based on the type of scheduling instruction, and calculates the signed beneficial change amount of the feedback observation unit. For each evaluation indicator, the platform first calculates the original change amount between the indicator value before and after scheduling. If the evaluation indicator is expected to increase, the original beneficial change amount equals the indicator value after scheduling minus the indicator value before scheduling; if the evaluation indicator is expected to decrease, the original beneficial change amount equals the indicator value before scheduling minus the indicator value after scheduling. A positive original beneficial change amount indicates that the indicator is improving in the expected direction; a negative value indicates that the indicator is changing in the opposite direction to the expected direction; zero or less than the preset minimum identifiable change amount indicates that the indicator has not formed an identifiable change. Since different evaluation indicators have different units of measurement, the platform normalizes the original beneficial change amount of each evaluation indicator before merging multiple indicators. Specifically, the platform reads the normalized benchmark value of the corresponding evaluation indicator from the feedback parameter table. The normalized benchmark value is determined based on the indicator's historical natural fluctuation, detection accuracy, historical average, or preset effective change threshold. The platform divides the original favorable change by the corresponding normalized baseline value to obtain the normalized signed favorable change of the evaluation indicator. After normalization, different evaluation indicators are converted into dimensionless values, thus avoiding the problem that indicators such as traffic flow, queue length, entry flow, number of occupied lanes, and travel time cannot be directly compared due to different units. When a dispatch instruction corresponds to multiple evaluation indicators, the platform calculates the normalized signed favorable change of each evaluation indicator separately and performs a weighted sum according to the preset indicator weights to obtain the comprehensive signed favorable change of the feedback observation unit. The calculation formula is: Comprehensive signed favorable change = Σ (Indicator weight × Normalized signed favorable change). Wherein, the preset indicator weights are configured by the feedback parameter table according to the instruction type, and the sum of the weights of each evaluation indicator under the same instruction type is 1. A positive comprehensive signed favorable change indicates that the overall road operation status of the feedback observation unit is improving in the direction expected by the dispatch instruction; 0 or close to 0 indicates that no identifiable improvement has been formed; a negative value indicates that the overall road operation status is changing in the opposite direction to the expectation.

[0033] Evaluation indicators include traffic flow, queue length, inbound traffic flow, number of lanes occupied, and travel time. Specifically, the evaluation indicators for signal timing adjustment instructions include traffic flow and queue length, with traffic flow representing the expected increase and queue length representing the expected decrease. The evaluation indicators for route guidance instructions include inbound traffic flow, which represents the expected decrease. The evaluation indicators for upstream flow restriction instructions include inbound traffic flow and queue length, both of which represent the expected decrease. The evaluation indicators for incident handling and dispatch instructions include the number of lanes occupied and travel time, both of which represent the expected decrease. The evaluation indicators for lane control instructions include travel time, which represents the expected decrease. The evaluation indicators for regional coordinated control instructions are determined based on the actual control direction and include traffic flow, inbound traffic flow, or queue length.

[0034] For each feedback observation unit, the platform retrieves all scheduling instructions involved in feedback attribution based on its road unit number and the time period after scheduling. If the road unit number corresponding to the feedback observation unit belongs to the set of road units affected by a certain scheduling instruction, and the time period after scheduling of the feedback observation unit overlaps with the time period after scheduling of the scheduling instruction, then the scheduling instruction is identified as the associated scheduling instruction of the feedback observation unit. If a feedback observation unit has only one associated scheduling instruction, then the feedback observation unit is marked as a single-instruction feedback observation unit. If a feedback observation unit has two or more associated scheduling instructions, then the feedback observation unit is marked as an overlapping feedback observation unit.

[0035] For each scheduling instruction participating in feedback attribution, feedback observation units that are solely affected by the instruction are first selected. If the number of single-instruction feedback observation units is greater than or equal to the minimum sample size N0, the signed favorable changes of these feedback observation units are taken as the individual action of the instruction. For partially executed instructions, the individual action is associated with the actual scheduling parameter value of the instruction and is not used as a direct reuse basis when the planned scheduling parameter value is fully executed. If the number of single-instruction feedback observation units is less than the minimum sample size N0, the scheduling instruction is determined to lack sufficient individual action samples, and the individual action of the scheduling instruction is not calculated; the scheduling instruction does not participate in the proportional allocation of overlapping feedback observation units. If the scheduling instruction still has overlapping feedback observation units, it is combined with other scheduling instructions that jointly affect the overlapping feedback observation units to form a joint instruction group, and the corresponding signed favorable changes are recorded as the joint instruction group changes; if the scheduling instruction has neither single-instruction feedback observation units that meet the minimum sample size requirement nor divisible overlapping feedback observation units, no itemized attribution changes are generated for the scheduling instruction, and the scheduling instruction is written into the unattributed instruction record. The minimum sample size N0 is determined based on the scheduling instruction type and road unit type. The platform groups the same scheduling instruction type and the same road unit type into a single statistical group, reads the 30 most recent valid execution records of this group, counts the number of single-instruction feedback observation units formed in each record, sorts them from smallest to largest, and takes the number corresponding to the 25th percentile as N0. If the number of historical valid execution records in this group is less than the preset historical sample lower limit, then N0 is set to 3. Different scheduling instruction types have different impact ranges, and different road unit types have different detection granularities and the number of observation units that can be formed. Therefore, N0 is determined separately for each of the above groups. N0 is used to avoid calculating individual effects based solely on a small number of single-instruction feedback observation units, thereby reducing the impact of accidental road fluctuations on the sub-attribution results.

[0036] For an overlapping feedback observation unit, if each instruction affecting the feedback observation unit has an individual action, then the individual action of each scheduling instruction is converted into a positive reference action strength. When the individual action is greater than 0, the positive reference action strength is taken as the individual action; when the individual action is less than or equal to 0, the positive reference action strength is taken as 0. If the sum of the positive reference action strengths of all relevant scheduling instructions is greater than 0, then according to the proportion of each positive reference action strength to the sum of the positive reference action strengths of all relevant scheduling instructions, the comprehensive signed favorable change of the overlapping feedback observation unit is allocated to the corresponding scheduling instruction, thus obtaining the allocation amount of the corresponding scheduling instruction from the overlapping feedback observation unit. If any relevant scheduling instruction has no individual action, or the sum of the positive reference action strengths of all relevant scheduling instructions is 0, then the overlapping feedback observation unit is not split, and it is recorded as a joint instruction group change.

[0037] The attributable variation for each instruction is obtained by adding the signed favorable variation from the single-instruction feedback observation unit and the allocated variation from the overlapping feedback observation unit. For fully effective executed instructions, the attributable variation is used to evaluate the execution effect of the planned scheduling parameter values; for partially effective executed instructions, the attributable variation is used to evaluate the execution effect of the actual scheduling parameter values.

[0038] After obtaining the attribution change for each scheduling instruction, the platform extracts the instruction type, corresponding congestion cause label, planned scheduling parameter value, actual scheduling parameter value, execution effectiveness coefficient α, and fully or partially effective execution flag from the scheduling instruction execution verification record, using the instruction number as an index. These fields are then associated with and stored in relation to the attribution change for that scheduling instruction, generating the attribution result for that instruction. For scheduling instructions for which no attribution change has been generated, the platform associates and stores the instruction number, instruction type, corresponding congestion cause label, execution effectiveness coefficient α, and unattributed cause, generating an unattributed instruction record. For inseparable overlapping feedback observation units, the platform associates and stores the set of scheduling instruction numbers, joint instruction group numbers, and joint change that collectively affect the feedback observation unit, generating a joint instruction group record. The attribution results include the attribution record for a single scheduling instruction, the unattributed instruction record, and the joint instruction group record.

[0039] For each dispatch instruction with a component attributable change, the platform compares the component attributable change with the minimum effective change threshold M0. The component attributable change is a signed value; a positive value indicates that the dispatch parameter value under the corresponding instruction causes the road's operating state to change in the expected direction, while a negative value indicates that the dispatch parameter value causes the road's operating state to change in the opposite direction. The minimum effective change threshold M0 is set according to the dispatch instruction type and evaluation index. The platform reads historical operating data of similar road units that did not execute dispatch instructions, calculates the natural fluctuation of the corresponding evaluation index within adjacent feedback time windows, and takes a preset quantile value as M0. If historical samples are insufficient, the platform compares the allowable error of the detection equipment, the minimum resolution corresponding to the index sampling accuracy, and the minimum identifiable change of the road unit, taking the maximum of the three as M0 to avoid small changes below the detection error or sampling accuracy being misjudged as valid feedback. In one specific embodiment, the preset quantile value is set to the 90th percentile. That is, when the number of historical natural fluctuation samples is a, the natural fluctuation with the sorting position ceil (0.90×a) is taken as M0; if the sorting position is less than 1, the first sample is taken; if the sorting position is greater than a, the a-th sample is taken.

[0040] When the change in sub-attribution is ≥ M0, the platform determines that the scheduling parameter value under the scheduling instruction has valid feedback basis. If the scheduling instruction is a fully valid execution instruction, the instruction type, target road unit, congestion cause label, and planned scheduling parameter value are associated and written into the reusable parameter record. If the scheduling instruction is a partially valid execution instruction, the instruction type, target road unit, congestion cause label, and actual scheduling parameter value are associated and written into the partially valid parameter record. The partially valid parameter record is only used to indicate that the actual scheduling parameter value has reference significance under the actual execution level in this case, and is not used as a direct reuse basis under the case of full execution of the planned scheduling parameter value. When the change in sub-attribution is less than M0 and greater than -M0, the platform determines that the scheduling parameter value under the scheduling instruction does not form a valid feedback basis, and writes the instruction type, target road unit, congestion cause label, and corresponding scheduling parameter value into the parameter record to be corrected. The parameter record to be corrected is used to indicate that the scheduling parameter value has not formed an identifiable improvement or a reverse impact in this road scenario, and will not be directly called as a priority candidate value in subsequent similar scenarios. When the change in the sub-item attribution is ≤ -M0, the platform determines that the scheduling parameter value under the scheduling instruction has a basis for reverse feedback, and associates the instruction type, target road unit, congestion cause label, and corresponding scheduling parameter value into the rollback parameter record. The rollback parameter record is used to indicate that the scheduling parameter value causes the road operation status to change in the opposite direction to the expected direction in the current road scenario, and the scheduling parameter value will be reduced or prohibited from direct reuse in subsequent similar scenarios. Among them, the scheduling parameter values ​​include the green light increment in the signal timing adjustment instruction, the diversion ratio in the route guidance instruction, the flow restriction intensity in the upstream flow restriction instruction, the handling priority in the event handling dispatch instruction, the number of lanes changed in the lane control instruction, and the green light increment or flow restriction intensity directly affecting the target road unit in the regional linkage control instruction. For joint instruction groups, the platform only retains the joint change and the joint instruction group number, and does not generate independent parameter correction basis for individual scheduling instructions within the group. For execution abnormal instructions and unattributed instructions, the platform does not generate reusable parameter records, partially valid parameter records, parameter records to be corrected, or rollback parameter records.

[0041] The platform writes reusable parameter records, partially valid parameter records, parameter records to be corrected, and rollback parameter records into the scheduling parameter correction library. The scheduling parameter correction library is a data table that the platform pre-establishes and updates during the scheduling feedback process. It is used to store the correlation records between road units, congestion cause labels, instruction types, scheduling parameter values, and sub-attribution changes. In the subsequent scheduling scheme generation steps, when a new congested road unit, instruction type, and congestion cause label matches the historical records in the scheduling parameter correction library, the platform generates candidate scheduling parameter values ​​according to the following rules: If a reusable parameter record is matched, the scheduling parameter value in that reusable parameter record is used as a priority candidate value and invoked under the conditions of satisfying traffic signal cycle, maximum green light time, downstream acceptance capacity, alternative path carrying capacity, and equipment execution range constraints; if a partially valid parameter record is matched, the actual scheduling parameter value in that partially valid parameter record is used as a candidate parameter reference value or candidate parameter upper limit, and the original planned scheduling parameter value is not directly invoked; if a parameter record to be corrected is matched, a new set of candidate parameters is generated based on the scheduling parameter value in that parameter record to be corrected, according to the scheduling parameter trial step size table; if a fallback parameter record is matched, the corresponding scheduling parameter value is reduced according to the scheduling parameter fallback step size table, or the scheduling parameter value is written into the prohibited reuse parameter set. The scheduling parameter trial step size table and scheduling parameter rollback step size table are pre-configured according to the instruction type. The values ​​are not less than the minimum identifiable adjustment unit of the corresponding execution device and not greater than the maximum adjustable range of the corresponding scheduling parameter. For signal timing adjustment instructions, the step size is the minimum green light adjustment unit allowed by the traffic signal control equipment; for route guidance instructions, the step size is the minimum diversion ratio adjustment unit allowed by the guidance release platform; for upstream flow restriction instructions, the step size is the minimum flow restriction intensity adjustment unit allowed by the regional signal control system; for lane control instructions, the step size is 1 lane; and for event handling dispatch instructions, the step size is 1 handling priority level.

[0042] Specifically, for signal timing adjustment commands, if the green light increment in the rollback parameter record is ΔG, then the candidate green light increments ΔG in subsequent similar scenarios... new Satisfy: ΔG new =max(ΔG min , ΔG-δG). For path guidance instructions, if the split ratio in the fallback parameter record is β, then the candidate split ratio β in subsequent similar scenarios is... new Satisfy: β new =max(β) min (β-δβ). For upstream current limiting commands, if the current limiting intensity recorded in the fallback parameter record is L, then the candidate current limiting intensity L in subsequent similar scenarios is... new Satisfy: L new =max(L minFor lane control commands, if the number of lanes for changing traffic prompts in the rollback parameter record is C, then the number of candidate lanes in subsequent similar scenarios is C. new Satisfy: C new =max(C min (C-δC). For event handling dispatch instructions, if the handling priority in the rollback parameter record is P, then the subsequent candidate handling priorities P in the same scenario are... new Satisfy: P new =max(P min , P-δP). Where, ΔG min β min L min C min and P min These are the minimum green light increment, minimum diversion ratio, minimum flow restriction intensity, minimum number of adjustable lanes, and minimum handling priority, respectively. These are configured by the platform based on the parameter range of traffic signal control equipment, guidance release rules, regional flow restriction rules, lane control equipment capabilities, and a handling priority level table. The handling priority P uses a coding method where larger values ​​indicate higher priority. δG, δβ, δL, δC, and δP are the preset green light increment rollback step, preset diversion ratio rollback step, preset flow restriction intensity rollback step, preset number of lanes rollback step, and preset handling priority rollback step, respectively. All are determined by the scheduling parameter rollback step table according to the instruction type. Each step value in the scheduling parameter rollback step table is determined by the minimum identifiable adjustment unit of the corresponding execution equipment or release platform and is subject to the allowable adjustment range of the corresponding scheduling parameters. Specifically, δG is taken as the minimum green light adjustment unit allowed by the traffic signal control equipment or an integer multiple thereof; δβ is taken as the minimum diversion ratio adjustment unit allowed by the guidance and information dissemination platform or an integer multiple thereof; δL is taken as the minimum flow restriction intensity adjustment unit allowed by the regional signal control system or an integer multiple thereof; δC is taken as the minimum number of lanes that the lane control equipment can independently change the passage prompt, i.e., one lane; and δP is taken as a priority level from the priority level table. Through the above value selection method, the candidate scheduling parameter values ​​after rollback can be recognized and executed by the corresponding execution equipment, guidance and information dissemination platform, or handling terminal.

[0043] For records of parameters to be corrected, the platform does not directly use the corresponding scheduling parameter values ​​as priority candidates. Instead, it generates a set of candidate parameters based on a scheduling parameter trial step size table. For the green light increment ΔG, the candidate parameter set includes ΔG-δG, ΔG, and ΔG+δG; for the diversion ratio β, the candidate parameter set includes β-δβ, β, and β+δβ; for the flow restriction intensity L, the candidate parameter set includes L-δL, L, and L+δL. The platform combines current road operation data, road capacity constraints, and scheduling instruction types to select the scheduling parameter values ​​for this round from the candidate parameter set.

[0044] After writing reusable parameter records, partially valid parameter records, parameter records to be corrected, and rollback parameter records, the platform uses the instruction number as an index to read the instruction type, target road unit, congestion cause label, planned scheduling parameter value, actual scheduling parameter value, and sub-item attribution change from the sub-item attribution results. Based on the comparison result of the sub-item attribution change with the minimum effective change threshold M0, the platform determines the parameter correction category corresponding to the scheduling instruction. Then, the corresponding reusable parameter records, partially valid parameter records, parameter records to be corrected, or rollback parameter records are associated and stored with the prohibited reuse parameter set, joint instruction group records, and unattributed instruction records to generate the basis for scheduling parameter correction. For execution abnormal instructions, unattributed instructions, and joint instruction groups, the platform writes the execution abnormality flag, unattributed flag, or joint instruction group number respectively, without generating an independent parameter correction basis for each individual scheduling instruction.

[0045] Example 2: Building upon Example 1, which already completed dispatch instruction execution verification, feedback observation unit division, and calculation of attribution changes, this example further performs reverse verification on congestion cause labels and corrects the cause determination parameter table based on the reverse verification results. Example 1 primarily determines the actual impact of each dispatch instruction and its parameter values ​​on road operation status; this example further determines whether the congestion cause labels used to generate the dispatch instruction match the actual feedback results, thereby reducing the likelihood of generating mismatched congestion cause labels repeatedly in similar road scenarios.

[0046] Specifically, such as Figure 2 The flowchart shown illustrates the method for correcting the cause determination parameter table. Based on the issued scheduling instruction records, the platform reads the congestion cause label, trigger condition number, participating judgment indicators, and cause determination parameter values ​​corresponding to each scheduling instruction. Each scheduling instruction corresponds to at least one congestion cause label, and one congestion cause label can correspond to one or more scheduling instructions. When the same scheduling instruction corresponds to multiple congestion cause labels, the platform uses the corresponding congestion cause label from the issued scheduling instruction records as the primary congestion cause label for this round of congestion cause reverse verification. Auxiliary congestion cause labels are only saved as subsequent verification fields. The platform only performs congestion cause reverse verification on scheduling instructions with sub-item attribution changes and an execution effectiveness coefficient α greater than or equal to the preset execution effectiveness threshold α0. When the execution effectiveness coefficient α is less than the preset execution effectiveness threshold α0, the platform writes the corresponding scheduling instruction into the execution anomaly record and does not use that scheduling instruction for congestion cause reverse verification. For unattributed instructions and joint instruction groups, the platform does not perform single-item congestion cause reverse verification. For scheduling instructions that participate in reverse verification of congestion causes, the platform will compare the changes in the attributed factors with the cause verification threshold M. c Comparison. Among them, the causation verification threshold M cThe system is configured separately according to congestion cause labels and dispatch instruction types. The platform reads the attribution changes of each item in the historical data for similar road units, under the same congestion cause label and dispatch instruction type, and selects those attribution changes greater than 0 as positive feedback samples. These positive feedback samples are then sorted from smallest to largest, and the sample value at the corresponding sorted position is read based on a preset low quantile value as M. c In one specific embodiment, the preset low percentile value is set to the 10th percentile. That is, when the number of positive feedback samples is a, the positive feedback sample value with a sorting position of ceil (0.10×a) is taken as M. c If the sorting position is less than 1, then the first sample value is taken. If the number of positive feedback samples is less than the preset sample lower limit, then M... c The maximum value among the minimum effective change threshold M0, the evaluation index sampling error, and the historical natural fluctuation is selected. When the attributable change of each component is greater than or equal to M0... c When the primary congestion cause label corresponding to the scheduling instruction is determined to form a positive cause feedback, the primary congestion cause label, trigger condition number, participating judgment indicators, cause judgment parameter values, scheduling instruction type, and sub-item attribution change are written into the cause valid matching record. When the sub-item attribution change is less than M... c And greater than -M c If the primary congestion cause label fails to generate a clear cause feedback, the primary congestion cause label, trigger condition number, cause determination parameter value, and sub-item attribution change amount are written into the cause pending review record. When the sub-item attribution change amount is less than or equal to -M... c When the main congestion cause label is determined to form a reverse cause feedback, the main congestion cause label, trigger condition number, participating judgment indicators, cause judgment parameter value, reverse change indicator and sub-attribution change amount are written into the cause reverse verification record.

[0047] The platform groups and statistically analyzes records of valid cause matching, records of cause pending verification, and records of cause reverse verification according to road unit type, congestion cause label, and trigger condition number. For each group, the platform first counts the number H of historical valid feedback records in the group within a preset historical statistical period, and then divides the data into N groups. c =min(N) max max(N) min ceil(β×H))) determines the minimum sample size for causal verification, where β is the sample proportion coefficient, and N min To preset the minimum sample size limit, N max This is a preset upper limit for the number of samples. Nmax is configured according to the maximum number of available feedback records for the same group within a preset historical statistical period, the feedback update period, and the maximum number of verification samples allowed by the platform. The platform then counts the cumulative number of records to be verified within the same group, C; when C is less than N... cWhen C is greater than or equal to N, only the corresponding record is retained, and the cause determination parameter table is not modified; c The platform corrects the corresponding parameters in the cause determination parameter table according to the cause correction step size table. The cause correction step size table is pre-configured according to congestion cause labels, road unit types, road grades, and parameter names, and is used to record the correction direction, single correction step size, parameter upper limit, and parameter lower limit for each cause determination parameter. Different congestion cause labels correspond to different determination parameters, different road unit types have different detection accuracy and traffic operation characteristics, and different road grades have different traffic capacity and allowable queuing levels; therefore, corresponding correction step sizes are configured for each. The cause correction step size is determined based on the minimum sampling resolution of the corresponding indicator, the allowable adjustment range of the parameter, historical natural fluctuations, and historical feedback correction effects. The single correction step size must not be less than the minimum sampling resolution of the corresponding indicator, must not be greater than the preset proportion of the allowable adjustment range of the corresponding parameter, and the corrected parameter value must not exceed the preset upper and lower limits of the parameter. After the historical feedback samples reach the preset update conditions, the platform can periodically update the cause correction step size table based on the corrected cause matching effect.

[0048] For tags with insufficient signal release, if the number of reverse verification records for cause analysis within the same group is greater than or equal to the minimum number of samples N for cause analysis... c The platform will then set the remaining queuing threshold from Q. sold Corrected to Q snew Q snew =min(Q) smax Q sold +ΔQs), where ΔQ s The step size Q is adjusted to the remaining queue length corresponding to the insufficient signal release label. smax The remaining queuing threshold is set to the upper limit; or the downstream acceptance verification flag is changed from disabled to enabled, and the downstream acceptance threshold is written into the necessary verification conditions for the insufficient signal release label. For downstream overflow labels, if the number of valid causal matching records in the same group is greater than or equal to the minimum number of causal verification samples Nc, the platform will change the overflow ratio threshold from R to R. old Revised to R new R new =max(R min R old -ΔR), where ΔR is the overflow ratio threshold correction step size, R min The lower limit of the spillover ratio threshold; or the downstream remaining acceptance length threshold can be changed from L old Revised to L new L new =min(L max L old +ΔL), where ΔL is the downstream remaining acceptance length threshold correction step size, L maxThis represents the upper limit of the remaining downstream acceptance length threshold. For incoming traffic surge labels, if the number of reverse verification records for the cause within the same group is greater than or equal to the minimum number of samples N for cause verification... c Then the platform will enter the traffic growth threshold set by F. old Revised to F new F new =min(F max F old +ΔF), where ΔF is the step size for correcting the entry flow growth threshold, and F max To enter the upper limit of the traffic growth threshold; or to change the entry traffic growth ratio threshold from H old Revised to H new H new =min(H max H old +ΔH), where ΔH is the step size for correcting the threshold of the inflow growth ratio, and H max To reach the upper limit of the traffic growth rate threshold; simultaneously, the verification order of downstream overflow tags and event occupancy tags is placed before that of traffic surge tags. For event occupancy tags, if the number of records awaiting verification of causes within the same group is greater than or equal to the minimum sample size N for cause verification. c The platform will then prioritize the event triggering separately from E. old Revised to E new E new =max(E min E old -1), where E min Set a separate priority lower limit for the event; or change the joint verification flag of the event occupancy tag from disabled to enabled, so that before generating subsequent event handling dispatch instructions, the number of occupied lanes must be greater than the lane occupancy threshold or the increase in travel time must be greater than the travel time increase threshold. Where Q smax R min L max F max H max and E min These are the boundary values ​​for the corresponding parameters in the cause determination parameter table, used to limit the cause determination parameters after one or more feedback corrections from exceeding the platform's allowed range. These boundary values ​​are pre-configured according to road unit type, road grade, number of lanes, detection equipment range, and existing traffic control rules. ΔQs, ΔR, ΔL, ΔF, and ΔH are all configured by the cause correction step size table according to congestion cause labels and road unit types.

[0049] In the subsequent congestion cause identification steps, if a new congested road unit matches the road unit type, congestion cause label, and trigger condition number in the valid cause matching record, the platform calls the corresponding corrected cause judgment parameter value in the cause judgment parameter table; if it matches the cause pending verification record, the platform participates in the congestion cause label sorting according to the corrected event trigger priority or candidate priority; if it matches the cause reverse verification record, the platform re-determines the congestion cause label according to the corrected trigger threshold, verification order, or necessary verification conditions.

[0050] After revising the cause determination parameter table, the platform uses road unit type, congestion cause label, and trigger condition number as indexes to read the number of records, sub-item attribution changes, and original cause determination parameter values ​​for the corresponding group from the valid cause matching records, cause pending verification records, and cause reverse verification records. Then, it reads the revised cause determination parameter values ​​from the cause determination parameter table, and associates and stores the original cause determination parameter values, revised cause determination parameter values, revision type, revision basis records, and subsequent calling rules to generate the cause determination parameter revision result. If the number of records in the same group is less than the minimum sample size N for cause verification... c If the number of records in the same group is greater than or equal to N, the platform will only generate uncorrected and retained records without changing the cause determination parameter table; c The platform then generates the corrected values ​​of the corresponding parameters according to the cause correction step size table, and writes the corrected values ​​into the cause determination parameter correction results.

[0051] Example 3: This example provides an intelligent dispatching system based on road operation data analysis, applied to an urban road traffic management platform. The urban road traffic management platform connects to road operation data sources, traffic signal control equipment, traffic guidance dissemination terminals, and traffic management and processing terminals to acquire road operation data within a target area, identify congested road units, generate traffic dispatching instructions, and adjust planned dispatching parameter values ​​in subsequent similar dispatching scenarios based on changes in road operation after the execution of the dispatching instructions. Figure 3 The diagram shown is a structural schematic of an intelligent dispatching system based on road operation data analysis. The system includes a road operation identification module, a dispatching instruction generation module, an execution verification module, a feedback observation module, a component attribution module, and a parameter correction module.

[0052] The road operation identification module is used to acquire road operation data and identify congested road units. Specifically, the road operation identification module reads the road operation data of each road unit within the target area and performs merging and matching according to the judgment time window and road network topology connection relationship to obtain the average vehicle speed, queue length, and queue growth. When the average vehicle speed is less than or equal to the low speed threshold and the queue length is greater than or equal to the queue length threshold, or the queue growth is greater than or equal to the queue growth threshold, the corresponding road unit is identified as a congested road unit.

[0053] The dispatch instruction generation module is used to generate congestion cause labels, dispatch instructions, and planned dispatch parameter values ​​based on congested road units, and then issue dispatch instructions. Specifically, the dispatch instruction generation module reads the upstream release status, downstream queuing status, event location, inbound traffic changes, and signal phase status of the congested road unit, and calls the cause determination parameter table to generate insufficient signal release labels, downstream overflow labels, inbound traffic surge labels, or event occupancy labels. Then, based on the congestion cause labels, it calls the corresponding dispatch instruction template to generate signal timing adjustment instructions, upstream flow restriction instructions, regional linkage control instructions, route guidance instructions, event handling dispatch instructions, or lane control instructions, and writes them into the planned dispatch parameter values ​​and issues them to the corresponding execution objects.

[0054] The execution verification module is used to acquire the execution data of scheduling instructions and calculate the execution effectiveness coefficient, and determine the set of affected road units based on the target of the scheduling instruction and the road network topology. Specifically, the execution verification module reads execution logs, release logs, vehicle trajectory data, or task feedback data, and calculates the execution effectiveness coefficient according to the type of scheduling instruction; at the same time, based on the target of the scheduling instruction and the road network topology connection relationship, it determines the road units that may be affected by the scheduling instruction, forming a set of affected road units.

[0055] The feedback observation module is used to determine single-instruction feedback observation units and overlapping feedback observation units based on the set of affected road units, road operation data within the time period before and after scheduling, and the number of associated scheduling instructions. Specifically, the feedback observation module determines the time period before and after scheduling based on the start time of scheduling instruction execution, extracts road operation data of the set of affected road units within the above time periods, and forms feedback observation units. When a feedback observation unit is associated with only one scheduling instruction, it is marked as a single-instruction feedback observation unit; when a feedback observation unit is associated with two or more scheduling instructions, it is marked as an overlapping feedback observation unit.

[0056] The sub-attribution module is used to obtain the sub-attributed change amount of each scheduling instruction based on single-instruction feedback observation units and overlapping feedback observation units. Specifically, the sub-attribution module determines the evaluation index and its expected change direction according to the type of scheduling instruction, calculates the signed favorable change amount of the feedback observation unit, and assigns the change amount of the single-instruction feedback observation unit to the corresponding scheduling instruction; for overlapping feedback observation units, when the relevant scheduling instructions all have individual effects, the change amount is allocated according to the proportion of individual effects to obtain the sub-attributed change amount of each scheduling instruction.

[0057] The parameter correction module generates a basis for correcting scheduling parameters based on the attribution changes of individual items, and corrects the planned scheduling parameter values ​​in subsequent similar scheduling scenarios based on this basis, thereby generating scheduling instructions for those scenarios. Specifically, the module compares the attribution changes of individual items with the minimum effective change threshold. When the attribution changes are greater than or equal to the minimum effective change threshold, the module writes the parameters to be corrected into a reusable parameter record or a partially effective parameter record, depending on whether the scheduling instruction is fully or partially effective. When the attribution changes are between the positive and negative minimum effective change thresholds, the module writes the parameters to be corrected into a parameter record. When the attribution changes are less than or equal to the negative minimum effective change threshold, the module writes the fallback parameter record. After these records are written to the scheduling parameter correction library, they are used to generate candidate scheduling parameter values ​​in subsequent similar scheduling scenarios. Candidate scheduling parameter values ​​that meet the equipment execution range and road carrying capacity constraints are determined as the corrected planned scheduling parameter values ​​to generate new scheduling instructions.

Claims

1. An intelligent scheduling method based on road operation data analysis, characterized in that, The method is applied to an urban road traffic management platform, and the method includes: Acquire road operation data and identify congested road units; Based on the congested road unit, generate congestion cause labels, dispatch instructions, and planned dispatch parameter values, and issue dispatch instructions; Obtain the execution data of the scheduling instructions and calculate the execution effectiveness coefficient, and determine the set of affected road units based on the target of the scheduling instructions and the road network topology; Based on the set of road units affected, the road operation data before and after the scheduling period, and the number of associated scheduling instructions, single instruction feedback observation units and overlapping feedback observation units are determined. The attribution variation of each scheduling instruction is obtained based on the single instruction feedback observation unit and the overlapping feedback observation unit; Based on the attribution changes of each item, a basis for adjusting scheduling parameters is generated. Based on the basis for adjusting scheduling parameters, the planned scheduling parameter values ​​in subsequent similar scheduling scenarios are adjusted, and scheduling instructions for subsequent similar scheduling scenarios are generated.

2. The intelligent scheduling method based on road operation data analysis according to claim 1, characterized in that, The step of acquiring road operation data and identifying congested roads includes: Read road operation data of road units within the target area from traffic signal control equipment, regional signal control system, detection equipment, video recognition equipment, vehicle trajectory data source, event reporting terminal and road network topology database; The collected road operation data is time-merged according to the determination time window; Based on the road network topology, average vehicle speed, queue length, inbound flow, outbound flow, road occupancy, signal phase, and event location are matched to the corresponding road units. For multiple detection data points within the same road unit and the same time window, calculate the time window statistical values ​​of the corresponding indicators; For each road unit, the average vehicle speed of the current time window is compared with the low speed threshold, the queue length of the current time window is compared with the queue length threshold, and the queue length of the previous time window is subtracted from the queue length of the current time window to obtain the queue growth. If at least one of the following conditions is met: the average vehicle speed is less than or equal to the low speed threshold, the queue length is greater than or equal to the queue length threshold, or the queue growth is greater than or equal to the queue growth threshold, the road unit is identified as a congested road unit; otherwise, it is not included in the scheduling of this round.

3. The intelligent scheduling method based on road operation data analysis according to claim 2, characterized in that, The process of generating congestion cause labels, scheduling instructions, and planned scheduling parameter values ​​based on congested road units, and issuing scheduling instructions, includes: For each congested road unit, read its upstream traffic release status, downstream queuing status, event location, inbound traffic changes, and signal phase status; Based on the cause determination parameter table, generate congestion cause labels for each congested road unit; Based on the candidate dispatch instruction type associated with the congestion cause label, the corresponding dispatch instruction template is called from the dispatch instruction template library, and the planned dispatch parameter value in the dispatch instruction is generated according to the preset traffic dispatch rule library; Write the congested road unit, congestion cause label, candidate dispatch instruction type, target road unit, target object, plan effective time, plan target object number, plan dispatch parameter value and plan display content into the dispatch instruction template to form a dispatch instruction to be issued; Using the instruction number as an index, the instruction type, target road unit, target object, planned effective time, planned target object number, planned scheduling parameter value, planned display content, corresponding congestion cause label, trigger condition number, participation judgment index and cause judgment parameter value of the scheduling instruction to be issued are associated and stored to generate a scheduling instruction generation record. Read the scheduling instructions to be issued from the scheduling instruction generation record, and determine the corresponding receiving end according to the instruction type; Signal timing adjustment instructions, upstream flow restriction instructions, and regional linkage control instructions are sent to traffic signal control equipment or regional signal control systems. Route guidance instructions are sent to navigation platforms, vehicle terminals, variable message signs, or roadside guidance screens. Incident handling dispatch instructions are sent to traffic management and handling terminals, clearing vehicle terminals, or road maintenance terminals. Lane control instructions are sent to lane indicating equipment, variable message signs, or traffic management terminals.

4. The intelligent scheduling method based on road operation data analysis according to claim 3, characterized in that, The process of acquiring execution data of scheduling instructions and calculating execution effectiveness coefficients, and determining the set of affected road units based on the target of the scheduling instructions and the road network topology, includes: After the scheduling instruction is issued, the sending receipt returned by the receiving end confirms that the scheduling instruction has been issued. Using the instruction number as an index, the sending time, receiving end information, and sending receipt are associated with the scheduling instruction generation record and stored to generate a scheduling instruction issued record. For each issued scheduling instruction, read its reception status, execution status, execution start time, and execution end time; For the executed dispatch instructions, the actual dispatch parameter values ​​are obtained from the execution log, release log, vehicle trajectory data, or data feedback from the disposal terminal according to the instruction type; The set of road units affected by each dispatch instruction is determined based on the road network topology; The set of road units affected refers to the set of road units that may be directly or indirectly affected by the dispatch instruction and are used for subsequent feedback observation. The execution effectiveness coefficient of each scheduling instruction is calculated based on the instruction type. The execution effectiveness coefficient is used to represent the actual degree of execution of the scheduling instruction, and its value ranges from 0 to 1. When the execution validity coefficient is equal to 1, the corresponding scheduling instruction is marked as a fully valid execution instruction; When the execution validity coefficient is greater than or equal to the preset execution validity threshold and less than 1, the corresponding scheduling instruction is marked as a partially valid execution instruction; When the execution validity coefficient is less than the preset execution validity threshold, the corresponding scheduling instruction will be marked as an execution exception instruction; The execution verification record of the scheduling instruction is obtained by associating the initial execution record of the scheduling instruction, the execution validity coefficient, and the execution validity flag.

5. The intelligent scheduling method based on road operation data analysis according to claim 4, characterized in that, The determination of single-instruction feedback observation units and overlapping feedback observation units based on the set of affected road units, road operation data within the time period before and after scheduling, and the number of associated scheduling instructions includes: First, select fully valid and partially valid execution instructions from the scheduling instruction execution verification record as scheduling instructions to participate in feedback attribution. For execution abnormal instructions, only write them into the execution abnormal record. For each scheduling instruction participating in feedback attribution, the time period before the execution start time is defined as the feedback time window, and the time period after the execution start time plus the response delay is defined as the feedback time window. From the road operation data, extract the average vehicle speed, queue length, inbound flow, outbound flow, passage time and number of occupied lanes of the road unit set affected by the instruction in the time period before and after the scheduling. A road unit is used as a comparison object formed in a set of pre-schedule time periods and post-schedule time periods as a feedback observation unit, and the road unit number, corresponding scheduling instruction number, pre-schedule time period, post-schedule time period and evaluation index data are recorded in the feedback observation unit; The evaluation indicators and their expected direction of change are determined based on the type of scheduling instruction, and the signed favorable change amount of the feedback observation unit is calculated. For each feedback observation unit, the platform retrieves all scheduling instructions that participated in feedback attribution based on its road unit number and the time period after scheduling. If the road unit number corresponding to the feedback observation unit belongs to the set of road units affected by a certain scheduling instruction, and the time period after scheduling of the feedback observation unit overlaps with the time period after scheduling of the scheduling instruction, then the scheduling instruction is determined as the associated scheduling instruction of the feedback observation unit. If a feedback observation unit has only one associated scheduling instruction, it is marked as a single-instruction feedback observation unit. If a feedback observation unit has two or more associated scheduling instructions, it is marked as an overlapping feedback observation unit.

6. The intelligent scheduling method based on road operation data analysis according to claim 5, characterized in that, The attribution variation of each scheduling instruction obtained based on the single instruction feedback observation unit and the overlapping feedback observation unit includes: For each scheduling instruction involved in feedback attribution, first filter out the feedback observation units that are affected solely by that instruction; If the number of single-instruction feedback observation units is greater than or equal to the minimum sample size, then the signed favorable changes of these feedback observation units are taken as the individual action of the instruction. If the number of single instruction feedback observation units is less than the minimum sample size, the individual effect of the scheduling instruction will not be calculated, and the scheduling instruction will not participate in the proportional allocation of overlapping feedback observation units. The minimum sample size is determined according to the historical effective execution records under the same scheduling instruction type and the same road unit type. For an overlapping feedback observation unit, if each scheduling instruction affecting the overlapping feedback observation unit has an individual action, then the individual action of each scheduling instruction is converted into a positive reference action strength. When the individual action is greater than 0, the positive reference action strength is taken as the individual action; when the individual action is less than or equal to 0, the positive reference action strength is taken as 0. If the sum of the positive reference action strengths of all relevant scheduling instructions is greater than 0, then according to the proportion of each positive reference action strength to the sum of the positive reference action strengths of all relevant scheduling instructions, the comprehensive signed favorable change amount of the overlapping feedback observation unit is allocated to the corresponding scheduling instruction, and the allocation amount of the corresponding scheduling instruction from the overlapping feedback observation unit is obtained. If any related scheduling instruction has no individual action, or the sum of the positive reference action strengths of all related scheduling instructions is 0, then the overlapping feedback observation unit is not split and is recorded as a change in the joint instruction group. The total signed favorable change from the single instruction feedback observation unit and the allocation from the overlapping feedback observation unit are added together to obtain the individual attributable change of the scheduling instruction. For scheduling instructions that do not obtain the attribution change amount, generate an unattributed instruction record.

7. The intelligent scheduling method based on road operation data analysis according to claim 6, characterized in that, The step of generating scheduling parameter correction criteria based on the attribution changes of each item, correcting the planned scheduling parameter values ​​in subsequent similar scheduling scenarios based on the scheduling parameter correction criteria, and generating scheduling instructions for subsequent similar scheduling scenarios includes: For each scheduling instruction with a component attribution change, the component attribution change is compared with the minimum effective change threshold; When the attribution change of a sub-item is greater than or equal to the minimum effective change threshold, the scheduling parameter value under the scheduling instruction is determined to have a valid feedback basis. If the scheduling instruction is a fully effective execution instruction, the corresponding scheduling parameter value is written into the reusable parameter record. If the scheduling instruction is a partially effective execution instruction, the corresponding scheduling parameter value is written into the partially effective parameter record. When the attribution change of a sub-item is less than the minimum effective change threshold but greater than the negative minimum effective change threshold, the corresponding scheduling parameter value is written into the parameter record to be corrected. When the attribution change of a sub-item is less than or equal to the minimum effective change threshold of negative, the corresponding scheduling parameter value is written into the rollback parameter record. Reusable parameter records, partially valid parameter records, parameter records to be corrected, and rollback parameter records are written into the scheduling parameter correction library. In subsequent similar scheduling scenarios, when a new congested road unit, instruction type, and congestion cause label matches the historical records in the scheduling parameter correction library, candidate scheduling parameter values ​​are generated based on the matched records. When a reusable parameter record is matched, the scheduling parameter value in that record is used as a candidate scheduling parameter value. If some valid parameter records are matched, the actual scheduling parameter values ​​in these valid parameter records are used as candidate parameter reference values ​​or candidate parameter upper limits, and the original planned scheduling parameter values ​​are not directly called. When a record of a parameter to be corrected is matched, the scheduling parameter value in that record is used as a benchmark, and a set of candidate scheduling parameters is generated according to the scheduling parameter trial step size table. When a rollback parameter record is matched, the corresponding scheduling parameter value is reduced according to the schedule parameter rollback step size table to generate a candidate schedule parameter value after rollback.

8. The intelligent scheduling method based on road operation data analysis according to claim 4, characterized in that, The calculation of the execution effectiveness coefficient for each scheduling instruction based on the instruction type includes: Read the execution log returned by the traffic signal control equipment or the area signal control system; For signal timing adjustment instructions, upstream flow limiting instructions, and regional linkage control instructions, the execution effectiveness coefficient is determined based on the matching results between the actual target, actual effective time, and actual scheduling parameter values ​​in the execution log and the planned target number, planned effective time, and planned scheduling parameter values ​​in the issued scheduling instruction records. For lane control instructions, the execution effectiveness coefficient is determined based on the actual displayed content in the status log, the actual lane number, the actual effective time, and the actual number of lanes whose passage prompts have been changed. For route guidance instructions, the actual diversion response rate is calculated based on the guidance information release log and vehicle trajectory data, and the effective execution coefficient is determined based on the ratio of the actual diversion response rate to the planned diversion ratio. For incident handling dispatch instructions, the execution effectiveness coefficient is determined based on the reception status, arrival status, and completion status of the handling task.

9. The intelligent scheduling method based on road operation data analysis according to claim 6, characterized in that, The method further includes revising the cause determination parameter table used to determine congestion cause labels in subsequent similar scheduling scenarios based on the attribution change of each item, including: Read the congestion cause label, trigger condition number, participation judgment index and cause judgment parameter value corresponding to the scheduling instruction; Only scheduling instructions with sub-attribution changes and execution effectiveness coefficients greater than or equal to the preset execution effectiveness threshold are subjected to reverse verification of congestion causes. When the effective execution coefficient is less than the preset effective execution threshold, the corresponding scheduling instruction will be written into the execution exception record and will not be used for reverse verification of congestion causes. For non-attributed instructions and joint instruction groups, no reverse verification of individual congestion causes is performed; For scheduling instructions that participate in the reverse verification of congestion causes, the sub-item attribution change is compared with the cause verification threshold to generate a valid cause matching record, a cause to be verified record, or a cause reverse verification record. Based on road unit type, congestion cause label, and trigger condition number, the effective matching records of causes, the records of causes pending verification, and the records of reverse verification of causes are grouped and statistically analyzed. When the number of records in the same group is less than the minimum number of samples for cause verification, the cause determination parameter table is not modified, and only the corresponding records are retained; When the number of records in the same group is greater than or equal to the minimum number of samples for cause verification, the corresponding parameters in the cause determination parameter table are corrected according to the cause correction step size table. In the subsequent congestion cause identification step, if the new congested road unit matches the road unit type, congestion cause label and trigger condition number in the effective cause matching record, the corresponding corrected cause determination parameter value in the cause determination parameter table is called. If it matches the record of cause to be reviewed, it will be sorted in the congestion cause label according to the corrected event trigger priority or candidate priority. If it matches the reverse verification record of the cause, the congestion cause label will be re-evaluated according to the corrected trigger threshold, verification order, or necessary verification conditions.

10. An intelligent dispatching system based on road operation data analysis, characterized in that, Applications to urban road traffic management platforms include: The road operation identification module is used to acquire road operation data and identify congested road units; The dispatch instruction generation module is used to generate congestion cause labels, dispatch instructions, and planned dispatch parameter values ​​based on congested road units, and then issue dispatch instructions. The execution verification module is used to obtain the execution data of the scheduling instructions and calculate the execution effectiveness coefficient, and determine the set of affected road units based on the target of the scheduling instructions and the road network topology. The feedback observation module is used to determine single-instruction feedback observation units and overlapping feedback observation units based on the set of affected road units, road operation data before and after scheduling, and the number of associated scheduling instructions. The sub-attribution module is used to obtain the sub-attribution change of each scheduling instruction based on the single instruction feedback observation unit and the overlapping feedback observation unit. The parameter correction module is used to generate a basis for correcting scheduling parameters based on the attribution changes of each item, and to correct the planned scheduling parameter values ​​in subsequent similar scheduling scenarios based on the basis for correcting scheduling parameters, and to generate scheduling instructions in subsequent similar scheduling scenarios.

Images