A dynamic path and time window optimization method for trucks

Abstract

The present application relates to the technical field of intelligent logistics scheduling and transportation path optimization, and discloses a truck dynamic path and time window optimization method, which is used for solving the problems of instruction failure caused by cloud reconstruction delay and vehicle continuous displacement asynchronization in traditional methods, and the problems of global rearrangement range expansion and calculation efficiency reduction caused by the fact that local delay is not effectively isolated; the method firstly establishes a distribution session, uniformly processes vehicle operation data, task data and road network state data, finds future execution position and execution starting node after disturbance occurs, checks time sequence of subsequent distribution nodes, finds abnormal nodes, and sequentially carries out time extension absorption, node reorganization, path reconstruction and terminal confirmation within the local path boundary, completes dynamic path adjustment and version update, and realizes normal operation of truck distribution scheduling.

Description

Technical Field

[0001] This invention relates to the field of intelligent logistics scheduling and transportation route optimization technology, specifically a method for optimizing dynamic routes and time windows for trucks. Background Technology

[0002] In logistics transportation scenarios with high-frequency dynamic disturbances, truck routing and time window optimization are key issues in scheduling control. Existing technologies mainly solve delivery routes under given road network conditions and time window constraints. For example, the published invention patent application CN109034468B discloses a logistics delivery route planning method with time windows based on the Cuckoo algorithm. This method mainly optimizes the delivery order by constructing a vehicle route planning model with time window constraints. Another example is the published invention patent application CN114154394B, which discloses a parallel time window vehicle route planning method based on an improved ant colony algorithm. This method mainly optimizes vehicle route planning under parallel time window conditions. Although the above-mentioned existing technologies can improve the route planning effect to a certain extent, they mainly focus on the route solution process itself and do not adequately consider the consistency between the scheduling results and the actual execution state of vehicles under high-frequency dynamic disturbance conditions.

[0003] Existing methods lack consideration of the relationship between cloud-based reconstruction time and actual continuous displacement during dynamic optimization of truck routes and time windows. When congestion, order insertion, or abnormal events cause scheduling reconstruction, a certain amount of time is required in the cloud while the vehicle is still moving. This can easily lead to a situation where the vehicle's location has changed by the time a new scheduling instruction arrives, resulting in a discrepancy between the scheduling result and the actual execution location, making it impossible to effectively execute the instruction. In addition, existing methods often handle time window conflicts by adjusting the entire system. Delays at local nodes can easily affect subsequent nodes, leading to a larger rescheduling scope, increased computational load, and reduced reconstruction efficiency. In severe cases, this can even cause scheduling to fail. To address the instruction failure caused by the asynchrony between cloud-based reconstruction delays and continuous vehicle displacement, as well as the problem of increased global rescheduling scope and decreased computational efficiency due to the lack of effective isolation of local delays, it is necessary to provide a dynamic truck route and time window optimization method. This method aims to solve the problems of instruction failure caused by the asynchrony between cloud-based reconstruction delays and continuous vehicle displacement, and the problem of increased global rescheduling scope and decreased computational efficiency due to the lack of effective isolation of local delays, thereby improving the execution accuracy, response speed, and system stability of dynamic scheduling. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides a method for optimizing dynamic routes and time windows for trucks. This method solves the problems of instruction failure caused by cloud reconstruction delays and asynchronous vehicle displacements in traditional methods, as well as the problems of expanded global reordering range and decreased computational efficiency due to the lack of effective isolation of local delays.

[0005] To achieve the above objectives, the present invention provides the following technical solution:

[0006] A method for optimizing dynamic routes and time windows for trucks includes:

[0007] Obtain the target truck's current location, driving status, current delivery task, service time requirements for each delivery node, and road network traffic status;

[0008] Based on the session state identifier, road condition disturbances and business disturbances are judged. When road condition disturbances or business disturbances exist, the starting adjustment node for the subsequent delivery of the target truck is determined, and the subsequent route adjustment and time adjustment are executed from the starting adjustment node.

[0009] Based on the initial adjustment node, the expected arrival order and expected arrival time of the target truck's subsequent delivery nodes are checked to identify abnormal nodes that have service time conflicts;

[0010] Starting from the abnormal node, the arrival time of its subsequent delivery nodes is adjusted sequentially within the local delivery route.

[0011] If adjustments cannot be made within the scope of a local delivery route, the order of delivery nodes that have not yet been executed is adjusted, and the subsequent delivery routes and node arrival order of the target trucks are re-determined.

[0012] Preferably, the current location, driving status, current delivery task, service time requirements of each delivery node, and road network traffic status of the target truck are obtained, including:

[0013] Establish delivery sessions corresponding to target trucks, and perform unified time alignment and organization of vehicle dynamic operation data, task data, and road network status data;

[0014] The system sequentially performs integrity checks, validity checks, road matching, state normalization, missing information completion, and anomaly marking, generating a basic state table, a node constraint table, a road network state table, a session state identifier, and an anomaly record table.

[0015] Preferably, based on session state identifiers, road condition disturbances and business disturbances are determined. When road condition disturbances or business disturbances exist, the starting adjustment node for the subsequent delivery of the target truck is determined, including:

[0016] Traffic disturbances and service disturbances are determined based on session state identifiers;

[0017] When a disturbance occurs, candidate future execution locations are determined based on the current location, current speed, current heading angle, road connectivity direction, and estimated processing time. Road attribute verification, location safety verification, and reachability verification are then performed on the candidate future execution locations.

[0018] If a candidate future execution position does not meet the verification conditions, perform a sliding search along the current road connection direction until a legal future execution position is determined.

[0019] Preferably, subsequent path adjustments and time adjustments are executed starting from the initial adjustment node, including:

[0020] Based on the legal future execution location, adjustment benchmark time, and the order of roads and nodes on the current delivery route, the unexecuted delivery nodes are compared sequentially, and the first unexecuted delivery node after the future execution location is determined as the adjustment starting point;

[0021] If the future execution location exceeds the original candidate node, the corresponding node will be written into the exception record table and retained in the unresolved node set. Subsequent timing verification and path adjustment will be based on the future execution location and adjustment base time.

[0022] Preferably, based on the initial adjustment node, the expected arrival order and expected arrival time of the target truck's subsequent delivery nodes are checked, including:

[0023] A sequence to be checked is formed based on the adjustment benchmark location, adjustment benchmark time, node constraint table, and road network status table;

[0024] Using the adjusted base time as a unified time starting point, and combining the estimated departure time of upstream nodes, road travel time between nodes, road condition compensation, waiting time, and on-site operation time, the estimated arrival time, estimated service start time, and estimated departure time of each node are sequentially estimated to form an estimated arrival time sequence table.

[0025] Preferably, the abnormal nodes where service time conflicts occur include:

[0026] The estimated arrival time of each node is compared with the corresponding latest service time. The difference between the estimated arrival time and the latest service time is recorded as the node delay. The first node with a delay greater than zero is selected as the current abnormal node in the node order. The subsequent conflicting nodes are written into the candidate abnormal node list and an abnormal node record is generated.

[0027] Nodes with missing service time are categorized as weakly constrained nodes, and nodes with impassable road segments are categorized as path-blocked pending states.

[0028] Preferably, starting from the abnormal node, the arrival time of its subsequent delivery nodes is adjusted sequentially within the local delivery route, including:

[0029] Based on the abnormal node records, the expected arrival time table, the node constraint table, and the road network status table, the local path boundary is determined. Under the condition of satisfying business continuity and road connectivity, the buffer duration is read node by node. Delay absorption, delay propagation, state switching, and local reconstruction are performed according to the delay value to be absorbed, generating local adjustment records, local adjustment logs, and subsequent processing basis.

[0030] Preferably, when adjustments cannot be completed within a local delivery route, the order of delivery nodes that have not yet been executed is adjusted, including:

[0031] When the remaining unabsorbed delay value is greater than zero and the current session state is in the incomplete absorption state, a set of nodes to be reassembled is formed based on the local path information and the updated expected arrival time table.

[0032] The retention decision is made by combining task priority, service time urgency, service elasticity, and splittable flags, and the execution order is shifted to the back without changing the relative order of priority retention nodes.

[0033] For nodes that still cannot meet the service time requirements after being moved to the next order but meet the splitting conditions, write them into the task pool to be reassigned.

[0034] Preferably, the subsequent delivery route and node arrival order of the target truck are redefined, including:

[0035] The subsequent delivery routes are reconstructed based on the reorganized node sequence and road accessibility within the local boundaries. The arrival time of each reconstructed node is then verified to form a subsequent route table and execution instruction information.

[0036] If no reachable path exists within the local boundary, fall back to the most recent valid node sequential version;

[0037] The terminal confirms the path switch based on location and time conditions, maintains the current valid path in the event of boundary crossing, verification failure, or communication interruption, and performs invalid version update processing.

[0038] Compared with the prior art, the present invention provides a method for optimizing the dynamic path and time window of a truck, which has the following beneficial effects:

[0039] 1. This invention establishes a delivery session to unify the processing standards for vehicle operation data, task data, and road network status data. After a disturbance occurs, subsequent adjustments are based on the future execution position and the initial adjustment node. The path adjustment no longer depends on the changed instantaneous position, thus reducing the latency of cloud reconstruction processing and the cause of instruction lag and mismatch due to the asynchronous movement of vehicles. At the same time, subsequent nodes are checked for timing, and the first service time conflict node is extracted. Within the local path boundary, the delay is absorbed sequentially, the delay is transmitted, and the local reorganization is carried out. The digestion of delays takes priority over local nodes, reducing the number of subsequent nodes affected by the delay of local nodes and avoiding the uncontrolled expansion of the overall reordering scope. Moreover, after the local delay can no longer absorb delays, the node order is adjusted, the waiting for reallocation is processed, the path is rebuilt, and the terminal side position and time are confirmed under dual conditions. This makes the scheduling result consistent with the actual vehicle operation status, ultimately improving the accuracy of dynamic scheduling execution, the timeliness of response, and the stability of system operation.

[0040] 2. This invention incorporates anomaly identification, local continuation, node reorganization, path reconstruction, and terminal switching into the same processing link. It uniformly records and constrains abnormal nodes, candidate abnormal nodes, nodes to be reassigned, path versions, and failed versions. Therefore, it can ensure consistency in disturbance handling judgment, adjustment boundaries, and execution standards, avoiding problems such as repeated adjustments, version conflicts, and rollback confusion caused by inconsistent processing standards at different stages. At the same time, it uniformly retains judgments, extracts limited data, and distributes versioned data for reorganized nodes. The results of local adjustment, node reorganization, and terminal reception are continuous, facilitating the tracing and verification of anomaly sources, adjustment processes, and execution status. Ultimately, it achieves controllability, traceability, and continuity of anomaly handling in dynamic scheduling. Attached Figure Description

[0041] Figure 1 This is a schematic diagram of the process for optimizing the dynamic route and time window of a truck according to the present invention;

[0042] Figure 2 A schematic diagram for determining the execution location and starting adjustment node;

[0043] Figure 3 For time-series verification and abnormal node identification;

[0044] Figure 4 This is a schematic diagram illustrating localized sequential absorption and delayed propagation.

[0045] Figure 5 This diagram illustrates node reorganization, pending reallocation, and path version switching. Detailed Implementation

[0046] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0047] Example 1: Figures 1-5 A method for optimizing dynamic routes and time windows for trucks is presented, including:

[0048] Obtain the target truck's current location, driving status, current delivery task, service time requirements for each delivery node, and road network traffic status;

[0049] Based on the session state identifier, road condition disturbances and business disturbances are judged. When road condition disturbances or business disturbances exist, the starting adjustment node for the subsequent delivery of the target truck is determined, and the subsequent route adjustment and time adjustment are executed from the starting adjustment node.

[0050] Based on the initial adjustment node, the expected arrival order and expected arrival time of the target truck's subsequent delivery nodes are checked to identify abnormal nodes that have service time conflicts;

[0051] Starting from the abnormal node, the arrival time of its subsequent delivery nodes is adjusted sequentially within the local delivery route.

[0052] If adjustments cannot be made within the scope of a local delivery route, the order of delivery nodes that have not yet been executed is adjusted, and the subsequent delivery routes and node arrival order of the target trucks are re-determined.

[0053] First, a delivery session is established with the target truck, and the delivery session serves as the unified data basis for subsequent route adjustments and service time adjustments. The vehicle terminal sends vehicle dynamic operation data to the cloud according to a fixed sampling period. The cloud synchronously receives task data issued by the business platform and road network status data provided by the map platform, and collects and organizes multi-source data of the same vehicle in the same delivery period at a unified session time.

[0054] Vehicle dynamic operation data includes at least the following fields: vehicle identification, collection time, longitude, latitude, current speed, current heading angle, load ratio, and operating status. The vehicle identification is used to uniquely associate the target truck, the collection time uses an absolute timestamp, and the longitude and latitude are represented by floating-point numbers. The current speed ranges from 0 to 33.3 meters per second, covering common operating speed ranges in urban roads, expressways, and highway freight delivery. The current heading angle ranges from 0 to 359 degrees, conforming to the conventional representation of heading angles. The load ratio ranges from 0 to 100%, representing the current loading level of the vehicle. The operating status can be selected as driving, waiting, loading, unloading, temporary parking, and abnormal parking. The sampling period is preferably 500 milliseconds, based on the following: assuming a truck travels at 100 kilometers per hour in a high-speed scenario, the displacement within 500 milliseconds is approximately 13.8 meters, still within the road-level location recognition range. This reflects continuous vehicle displacement changes without significantly increasing the terminal communication burden.

[0055] Task data should include at least the following fields: task number, vehicle identifier, node sequence, node type, node location, planned arrival time, earliest service time, latest service time, on-site operation duration, task priority, and task status. Node types can be selected as loading nodes, unloading nodes, transit nodes, and temporary insertion nodes. The earliest and latest service times together constitute the node's service time requirements. The on-site operation duration is preferably between 15 and 90 minutes, based on the common durations of stopping, queuing, loading / unloading, signing, and handover in highway freight delivery nodes. 15 minutes covers short loading / unloading and quick handover scenarios, while 90 minutes covers scenarios with longer loading / unloading times, requiring on-site confirmation, or waiting for handover. Different node types can be configured with different default values ​​within this range. The task priority is preferably set from 1 to 10, with higher values ​​indicating higher timeliness requirements and priority retention in subsequent adjustments. The task status can be selected as not executed, executing, completed, canceled, and pending verification.

[0056] Road network status data includes at least the following fields: road sign, starting node, ending node, average traffic speed, congestion index, passability status, and update time. The congestion index is a real number between 0 and 1, with a higher value indicating a higher degree of congestion. Passability status can be selected as normal, slow, restricted, or prohibited. Update time is used to characterize the timeliness of road network status data. To facilitate subsequent processing, vehicle dynamic operation data, task data, and road network status data are all associated with vehicle identifiers and timestamps and written into the same delivery session.

[0057] After receiving vehicle dynamic operation data, task data, and road network status data, the cloud first performs session preprocessing before proceeding with disturbance judgment and path adjustment. Session preprocessing may include time alignment, integrity verification, validity verification, road matching, and status normalization. Time alignment is used to unify data from different sources to the same session time. The collection time of the latest vehicle dynamic operation data can be selected as the current session time, and the task data and road network status data are aligned to this session time. Integrity verification is used to determine whether key data is missing. Key data includes at least the following fields: vehicle identification, collection time, latitude and longitude, current speed, node order, latest service time, and road identification. Validity verification is used to determine whether the data is within a reasonable range. When the current speed is less than 0 or greater than 33.3 meters per second, the current heading angle exceeds 0 to 359 degrees, or the load ratio exceeds 0 to 100%, the corresponding data can be recorded as invalid data and not used as valid input for the current session.

[0058] Road matching is used to determine the current road segment and related road segments ahead of the vehicle based on latitude, longitude, and current heading angle. It prioritizes the road segment closest to the vehicle's current location and with a heading angle deviation less than a preset angle threshold. Then, it determines the adjacent roads ahead based on the connecting direction of this road segment. The preset angle threshold can be set between 30 and 60 degrees, for example, 45 degrees. This value is chosen because road matching needs to exclude reverse and lateral roads based on the vehicle's direction of travel, while also preserving normal directional fluctuations during lane changes, turns, and intersection transitions. Therefore, a value within this range balances matching accuracy and adaptability to different road scenarios. State normalization is used to unify the original operating states into driving, working, waiting, and abnormal states for easy retrieval in subsequent processing.

[0059] For situations where critical data is missing but session continuity can still be maintained temporarily, limited data completion can be performed. During completion, the same data from the previous valid sampling period of the same vehicle is used for temporary supplementation, with no more than 3 consecutive completion periods. Under a 500-millisecond sampling period, 3 sampling periods correspond to a short-term missing data tolerance interval of 1.5 seconds, which can cover data interruptions caused by communication jitter, momentary obstruction, or short-term upload anomalies, without significantly affecting the vehicle location continuity judgment. If valid data is still not recovered after 3 consecutive sampling periods, the session status corresponding to the vehicle can be adjusted to a pending confirmation status, and subsequent dynamic adjustments can be paused, while only data reception continues and waiting for recovery.

[0060] After session preprocessing, the cloud generates a basic status table, a node constraint table, a road network status table, a session status identifier, and an anomaly record table. The basic status table includes at least the following fields: vehicle identifier, session time, current road segment identifier, current location, current speed, current heading angle, load ratio, basic operating status, and data validity flag, used to record the vehicle's operating status at the current session moment. The node constraint table includes at least the following fields: node number, node order, planned arrival time, earliest service time, latest service time, on-site operation duration, task priority, and current execution status, used to record the service time requirements and operation constraints of unexecuted nodes. The road network status table includes at least the following fields: average traffic speed, congestion index, and passability status of the current road segment, the first consecutive adjacent road segment ahead, and the second consecutive adjacent road segment ahead, used to record the road status related to the current path. The anomaly record table records anomalies such as missing data, location drift, tasks pending verification, and expired road condition status, providing a basis for subsequent recovery, rollback, and anomaly branch handling.

[0061] The session status identifier indicates whether the current delivery session meets the conditions for subsequent processing. The session status can be selected from initialization, normal monitoring, pending confirmation, and disturbance judgment. When the data is complete and passes verification, the session can transition from initialization to normal monitoring. If a short-term data gap occurs and can be filled within acceptable limits, the session can remain in normal monitoring. If more than three consecutive sampling periods are missing, road matching fails, or key data remains invalid, the session can transition to pending confirmation. After receiving data for two consecutive valid sampling periods in the pending confirmation state, the session can return to normal monitoring. With a 500-millisecond sampling period, two consecutive valid sampling periods correspond to a 1-second continuous recovery observation time. This duration avoids accidental state switching due to occasional valid data recovery and does not significantly delay process recovery. When the key data in the basic status table, node constraint table, and road network status table is complete and not marked as invalid, the session status can be adjusted to the disturbance judgment state.

[0062] For boundary situations, further anomaly handling can be implemented; when a vehicle experiences a short-term positioning drift upon entering a service area, tunnel, or elevated road obstruction area, one abnormal position jump is allowed within a single sampling period; if the road matching results for two consecutive sampling periods are inconsistent and do not match the current heading angle, this data can be recorded as drift data and will not be included in the current position confirmation; the basis for using two consecutive sampling periods as the judgment condition is that, under a 500-millisecond sampling period, two consecutive sampling periods correspond to approximately one second of continuous anomaly observation time, which is sufficient to distinguish between instantaneous positioning jitter and persistent position drift; when a new task is temporarily issued by the business platform, if any key data such as vehicle identification, node location, or latest service time is missing... Data is first written to the task pool to be verified, and not directly to the node constraint table. After the key data is completed, it is written to the node constraint table according to the receiving time and participates in subsequent processing. For road network status data, the effective threshold for update time can be set to 30 seconds to 120 seconds, for example, 60 seconds. The basis for this value is that road traffic status has strong timeliness, while map platform road condition updates usually have a delay of seconds to minutes. The above range can take into account both the timeliness of road conditions and the availability of data. Among them, 60 seconds is suitable as the default threshold for most delivery scenarios. If the effective threshold is exceeded, the corresponding road segment can be recorded as expired. For road segments with expired status, they will not be used as a separate triggering basis in subsequent judgments, but only as an auxiliary reference.

[0063] After the above processing, the cloud outputs delivery session records. The delivery session records should include basic status table, node constraint table, road network status table, session status identifier, and abnormal record table, which serve as the basis for determining disturbance triggers and starting adjustment nodes.

[0064] Specifically, such as Figure 2 As shown: After the aforementioned delivery session record is formed, the cloud performs disturbance monitoring based on the basic status table, node constraint table, road network status table, and session status identifier. When the disturbance triggering conditions are met, the cloud determines the future execution location and the starting adjustment node. The cloud first determines whether the current vehicle meets the conditions for entering the disturbance judgment based on the session status identifier. When the session status identifier is in the normal monitoring state or the state that can enter the disturbance judgment state, the disturbance identification is performed. When the session status identifier is in the pending confirmation state or the waiting recovery state, the current disturbance judgment is paused. The reason for this setting is that the starting adjustment node should be based on continuous, valid, and traceable data to avoid abnormal data causing the subsequent adjustment starting point to shift.

[0065] After the entry conditions are met, the cloud performs road condition disturbance judgment and business disturbance judgment in parallel. When either judgment is valid, the current session state is switched to the pending adjustment state, and the future execution location is generated. During the road condition disturbance judgment, the cloud extracts the speed values ​​of the target truck for the most recent 6 sampling periods from the continuous sampling records. Since the sampling period is the aforementioned 500 milliseconds, the 6 sampling periods correspond to a 3-second observation window. The 3-second observation window is chosen because a window that is too short is easily affected by short-term actions such as instantaneous braking and lane changing, while a window that is too long will reduce the timeliness of response to sudden congestion. Therefore, 3 seconds can balance judgment stability and response speed. The cloud calculates the average speed within the observation window and compares it with the historical average speed of the current road segment. When the average speed within the window decreases by more than 20% compared to the historical average speed of the current road segment, and the congestion index of the adjacent road ahead is greater than or equal to 0.75, a judgment is made. Road condition disturbance occurs; the historical average traffic speed of the current road segment can be taken as the statistical average of the same road segment at the same time period over the past 7 calendar days. The selection of the past 7 calendar days is based on the fact that this time length can cover weekdays and short-cycle road fluctuations, taking into account both sample stability and time period representativeness; the congestion index is taken as 0 to 1, where 0 represents smooth traffic and 1 represents severe congestion; the congestion index threshold can be taken as 0.70 to 0.80, preferably 0.75, which is based on the fact that this range can be used to distinguish between general slow traffic and severe congestion that is enough to affect subsequent delivery, and 0.75 is suitable as the default judgment value in most delivery scenarios; if the average speed decrease reaches the threshold but the congestion index of the adjacent road ahead does not reach the trigger threshold, the original session state is maintained; if the congestion index of the adjacent road ahead reaches the trigger threshold, but the duration of the speed decrease does not reach 6 sampling periods, the event is recorded as a warning event, and subsequent adjustments are not initiated temporarily;

[0066] When assessing business disruptions, the cloud monitors new order and temporary order insertion events in real time and performs field validation on the event records. Business event data must include at least the task number, insertion time, node location, latest service time, and mandatory fulfillment flag. A business disruption is determined to have occurred only when the mandatory fulfillment flag is valid and the latest service time is no more than 90 minutes from the current time. The threshold is determined to cover the common response time limits for high-efficiency urgent orders in urban delivery and intercity short-distance transportation, while also distinguishing it from ordinary appointment orders. To enhance applicability, this threshold can also be set from 30 minutes to 120 minutes depending on the business type, with 90 minutes serving as the default value. If a new task lacks a node location or latest service time, it is first written to the task pool to be validated without triggering the current disruption assessment. After the key fields are completed, it is written to the node constraint table according to the receipt time. If a new task meets the time limit conditions but does not have a mandatory fulfillment flag set, the current task sequence remains unchanged and is transferred to regular scheduling processing.

[0067] Once a road condition disturbance or business disturbance is determined, the cloud generates a future execution location. The future execution location represents the road position of the vehicle when the current adjustment result is formed and the conditions for its deployment are met. The data generated for the future execution location includes at least the following fields: current position, current speed, current heading angle, road connection direction, estimated processing time, and road connection relationship. The estimated processing time represents the time span from the current triggering moment to the formation of the current adjustment result and the conditions for its deployment. The estimated processing time can be between 3 seconds and 25 seconds. 3 seconds can cover the faster processing time in a light adjustment scenario, while 25 seconds can cover the longer processing time in a high-concurrency or complex disturbance scenario. The range is chosen to cover the common scheduling and processing latency range on the server side and to retain the latency fluctuation space under high load conditions.

[0068] To ensure parameter reproducibility, the estimated processing time can be determined based on processing latency records. These records should include at least the actual processing time, event type, task size, and concurrency level of the last 50 disturbances of the same magnitude. The 50-sample value is chosen because it balances statistical stability and historical representativeness, ensuring sufficient reference samples across different disturbance categories. When the current disturbance event matches a historical category, the median processing time of the corresponding category can be used as the estimated processing time. When historical samples are insufficient, the estimated processing time can be set to 8000 milliseconds. The value of 8000 milliseconds is chosen because it represents the median level of the server's historical processing latency distribution, covering typical processing times under mild to moderate disturbance scenarios.

[0069] After obtaining the estimated processing time, the cloud estimates the vehicle's forward movement distance based on its current location, current speed, and road connectivity direction. The forward movement distance can be determined by multiplying the current speed by the estimated processing time, and then adjusted based on road speed limits and the current operating status. When the operating status is normal driving, the product result can be directly used as the base forward movement distance. When the operating status is low-speed following or temporary parking, a reduction factor of 0.3 to 0.6 can be applied. The basis for this range of correction factor is that, in low-speed following and temporary parking states, the actual forward movement distance of the vehicle within the processing delay window is usually significantly lower than the direct product of speed and delay. Therefore, using a reduction range of 0.3 to 0.6 can cover two typical operating scenarios: slow-moving and short-term stagnation, avoiding overestimation of the future execution position.

[0070] After estimating the forward distance, the cloud searches for the corresponding location point or road node along the current road connection direction and uses the location as a candidate future execution location. The reason for using the search along the road connection direction instead of using latitude and longitude straight line extrapolation is that truck operation is constrained by the road geometry, and straight line extrapolation is easy to fall outside the road and is difficult to use as the starting point for subsequent adjustments.

[0071] After candidate future execution locations are generated, cloud-based location validity checks are performed. Location validity checks include at least road attribute checks, location safety checks, and accessibility checks. Road attribute checks determine whether the candidate location is located in a ramp merging area, a dangerous section of a long tunnel, a bridge no-parking zone, a construction closure area, or a map-marked no-parking zone. Location safety checks determine whether the candidate location meets the conditions for temporary switching and safe passage, and can be based on the distance between the candidate location and the no-parking zone boundary, road parking permissions, slow-moving switchable area markers, or the road boundary safety range. Accessibility checks determine whether it is possible to reach the location from the current location along the current direction without reversing direction or crossing impassable road sections.

[0072] If any verification fails, the cloud initiates a safe slip process. This process continues searching for a legal location along the current road connection direction in 50-meter increments. The 50-meter increment is chosen to cover most small conflict zones and localized dangerous sections of the ramps without making the search too coarse, thus maintaining road-level location accuracy. Each slip operation increments a corresponding time compensation value, calculated by dividing the step distance by the average traffic speed of the current road segment. If a legal location is found within the preset maximum search distance, the slipped legal location is used as the final unsuccessful search location. The execution location is determined by the preset maximum search distance, which can be between 500 and 1000 meters. The reason for this value is that it is not adaptable to complex road environments when the distance is less than 500 meters, and the future execution location is likely to deviate from the current disturbance range when the distance is greater than 1000 meters. If no legal location is found within the maximum search distance, the current session state is switched to the abnormal waiting state, the current task sequence remains unchanged, the trigger reason and search failure flag are written into the abnormal record table, and the disturbance monitoring is restarted in the next sampling cycle until a new legal future execution location is detected or the disturbance condition is resolved.

[0073] Once the future execution location is determined, the cloud uses this location as a standard to reposition the starting point of processing on the subsequent delivery chain. Based on the road sequence and entry order on the current delivery path, all unexecuted nodes are read, and each unexecuted node is compared to the order of the future execution location to locate the first unexecuted delivery node after the future execution location. This node becomes the starting adjustment node. If the future execution location does not enter the entry range of a certain unexecuted node, then that unexecuted node is directly used as the starting adjustment node. If the future execution location exceeds a candidate node in the original plan, this candidate node is written into the exception record table and stored in the unresolved node set for future node sequence verification and reorganization processing. The unresolved node set includes at least the following fields: node number, original node order, exceeded marker, and trigger time.

[0074] The output information of the starting adjustment node includes at least the following fields: vehicle identifier, starting adjustment node number, coordinates of the future execution position, road segment identifier corresponding to the future execution position, adjustment reference time, trigger reason code, and position determination method identifier. The adjustment reference time is obtained by adding the estimated processing time to the current time and superimposing the cumulative time compensation value during the safe slip process. The trigger reason code can be road condition disturbance, business disturbance, or a combination of disturbances. The position determination method identifier can be used to distinguish between direct forward movement generation and slip correction generation, which is convenient for subsequent tracking and recording.

[0075] To ensure seamless integration with subsequent processing, cloud-based boundary control rules are implemented. Once the initial adjustment node is determined, the verification of subsequent expected arrival order and expected arrival time is based on the future execution location and adjustment reference time as a unified starting point. When the current session is in an abnormal waiting state, subsequent timing verification is not initiated. When the same vehicle repeatedly triggers the same type of disturbance within two consecutive sampling periods, and the future execution location and initial adjustment node remain unchanged, only the timestamp is updated, and no new adjustment record is created. The value of two consecutive sampling periods is based on the fact that, under a 500-millisecond sampling period, a short-term repeated reporting window of 1 second is provided, which can cover the repeated triggering of the same disturbance in continuous sampling, avoiding the repeated amplification of the same event.

[0076] Specifically, such as Figure 3 As shown: After the starting adjustment node, adjustment reference time, and adjustment reference location are determined, the cloud calls the node constraint table and road network status table to perform time sequence verification on subsequent unexecuted delivery nodes, forming a verification sequence to identify the first abnormal node with a service time conflict. The node constraint table includes at least the following fields: node number, node order, node location, earliest service time, latest service time, on-site operation duration, task priority, and current execution status. The road network status table includes at least the following fields: average traffic speed, congestion index, passability status, and update time of the associated road segments between the starting adjustment node and subsequent nodes. If there are canceled, completed, or abnormally blocked nodes in the current delivery session, they are not written into the verification sequence. If there are duplicate records for the same node, the record corresponding to the latest version number shall prevail.

[0077] The nodes in the sequence to be verified use a consistent node timing record, which must include fields such as node number, node order, node position, upstream node number, earliest service time, latest service time, on-site operation duration, task priority, estimated arrival time, estimated start time, estimated departure time, waiting amount, delay amount, constraint status, and anomaly flag. Among them, the on-site operation duration and task priority can refer to the above-mentioned criteria; the waiting amount represents the time difference between a vehicle arriving early but not yet entering the service period; the delay amount represents the excess amount of a vehicle arriving later than the latest service time; and the constraint status represents normal nodes, waiting nodes, conflicting nodes, weakly constrained nodes, and path blocking nodes to be processed.

[0078] The cloud-based system uses the adjusted reference position and time as a starting point to estimate the arrival time of the first node in the verification sequence, and then iterates forward sequentially from node to node. The estimated arrival time of a node is determined by the estimated departure time of the upstream starting point, the road travel time between the upstream starting point and the current node, and road condition compensation. For the first node in the sequence, the upstream starting point is the adjusted reference position; for subsequent nodes, the upstream starting point is the immediately preceding node. The road travel time can be obtained by dividing the road segment length by the current effective average travel speed, with the current effective average travel speed preferentially taken from the most recent effective record in the road network status table. If the status update time of a road segment exceeds the aforementioned effective threshold, such as 60 seconds, then the average travel time of that road segment is... The average travel speed is adjusted by combining historical baseline speed with the current congestion index, and the higher the congestion index, the lower the adjusted average travel speed. 60 seconds is used as the default judgment value, which is determined by the need to balance the timeliness of road network status and data availability. This threshold has been adopted in the aforementioned road network status validity processing. The historical baseline speed can be the average speed of the same road segment in the same time period over the past 7 days. The value of the past 7 days is determined by the fact that this time length can cover weekdays and short-cycle road fluctuations, taking into account the stability of the sample and the representativeness of the time period. In order to avoid the short-term fluctuations at the road level being directly amplified to the node level judgment, the travel time of a single road segment can be retained to the integer of the second, and the travel time of all related road segments between adjacent nodes is accumulated before participating in the node time sequence estimation.

[0079] The estimated start time of a node is determined by the estimated arrival time and the earliest service time. When the estimated arrival time is earlier than the earliest service time, it means that the vehicle has arrived at the node but has not yet entered the permitted service period. In this case, the earliest service time is taken as the estimated start time, and the difference between the two is recorded as the node's waiting time. The waiting time is recorded in seconds, and its value is based on the fact that waiting behavior will occupy vehicle and time resources and directly affect the estimated arrival time of subsequent nodes. Therefore, it should be included in the continuous time sequence estimation process. When the estimated arrival time is later than or equal to the earliest service time, the estimated start time is directly taken as the estimated arrival time, and the waiting time is recorded as 0. The estimated departure time of a node is obtained by adding the on-site operation time of the node to the estimated start time. After the above processing, each node forms three consecutive moments: estimated arrival, estimated start time, and estimated departure, so that the time sequence estimation of subsequent nodes is based on the continuous advancement of the actual service chain.

[0080] After obtaining the estimated arrival time of each node, the cloud compares the estimated arrival time with the latest service time of that node. If the estimated arrival time is later than the latest service time, the difference between the two is recorded as the node delay, and the node is marked as a service time conflict node. The node delay is expressed in seconds. A delay greater than 0 indicates a conflict, and a delay equal to 0 indicates no late arrival conflict. To form a clear starting point for subsequent processing, the cloud selects the first node with a delay greater than 0 as the current abnormal node according to the node order of the sequence to be checked, and the conflicting nodes thereafter are kept in the candidate abnormal node list for re-checking after the subsequent local delay adjustment is completed. The basis for this processing method is that the delay of subsequent nodes is usually affected by the delay of the preceding nodes. If all conflicting nodes are processed at the same time, it is easy to cause the same delay to be repeatedly transmitted between multiple nodes.

[0081] The current abnormal node is represented by an abnormal node record. The abnormal node record includes at least the following fields: node number, node order, estimated arrival time, latest service time, node delay, node priority, preceding node number, abnormal flag, and current session version number. The candidate abnormal node list includes at least the following fields: node number, node order, delay, and priority. Nodes with a delay greater than 0 after the current abnormal node are stored in node order. Simultaneously, an updated estimated arrival time sequence table is generated in the cloud. The estimated arrival time sequence table includes at least the following fields for each node: estimated arrival time, estimated start time, estimated departure time, waiting time, delay, and constraint status. These fields are used to determine the scope of local adjustments and the sequential transmission relationship.

[0082] To ensure the reproducibility of timing verification, the estimated arrival time is uniformly estimated using the adjusted baseline time as the starting point, without mixing trigger time, data reception time, or map update time as alternative starting points; the current processing does not rearrange the node order, and node order adjustment is only performed when subsequent conditions are met; the impact of preceding nodes on the current node should include not only road passage time but also the waiting time of preceding nodes and on-site operation time, and the arrival time cannot be estimated solely based on the distance between nodes; for complex paths composed of multiple road segments, if there are impassable road sections in the middle, the estimated arrival time of the current node is not generated temporarily, but the constraint state of the current node is recorded as a path blockage pending processing state, and this state is written to the anomaly record table; when the blocked road section is reopened or the subsequent path adjustment is completed, the estimated arrival time of the node is regenerated; for nodes with higher priority, the delay judgment criteria are not relaxed due to their higher priority, and task priority is mainly used for subsequent postponement and reorganization processing;

[0083] For boundary cases, the following processing rules are further implemented: If a node is missing its earliest or latest service time, it is temporarily classified as a weakly constrained node. Weakly constrained nodes remain in the verification sequence, and their estimated arrival and departure times continue to be estimated to maintain the temporal continuity of the entire delivery chain and avoid interruptions due to missing fields. However, this node does not participate in the determination of current abnormal nodes, and its constraint status is recorded as pending completion, and a pending completion flag is simultaneously written. Once the service time field is completed, it can be restored to a normal node in the next verification cycle. If a node is missing on-site operation time, it can be supplemented by the historical median operation time of nodes of the same type. This historical median operation time can be taken from the last 30 days or the last 50 similar operations. The median value of the type of operation record; if historical samples are insufficient, the default value of 30 minutes can be used, and the node is recorded as a temporary estimated node; the 30-minute value is based on the fact that this duration can be taken as the typical median operation duration of short-term operation nodes of the same type, which can serve as the default supplementary value when historical samples are insufficient; if none of the nodes in the sequence to be checked have a delay greater than 0, the original node order is kept unchanged, and the current time series table is recorded as an executable time series table, which serves as the basis for subsequent local delay judgment or execution issuance; if the delay of the current abnormal node drops back to 0 due to the improvement of the road network status during the next sampling period check, the session state can be restored to the normal execution state, and the current abnormal node record and the candidate abnormal node list are cleared.

[0084] Specifically, such as Figure 4As shown: After the abnormal node record, candidate abnormal node list, and estimated arrival time sequence table are generated, the cloud performs sequential adjustments to the subsequent delivery nodes starting from the abnormal node. Nodes on the local delivery path must meet business continuity and path continuity requirements. Business continuity is determined by the vehicle number, current task chain number, and non-execution node number, while path continuity is determined by the sequence of passable roads in the current session. The current processing calls relevant data from the abnormal node record, candidate abnormal node list, estimated arrival time sequence table, node constraint table, and road network status table. Processing is performed if an abnormal node record exists and the current session status is pending. If no abnormal node is found, the estimated arrival time sequence table is retained, and no local sequential adjustment is performed. If there are multiple abnormal nodes in the current session, only the first abnormal node is used as the starting point for local adjustment, and the remaining candidate abnormal nodes are retained in the list for re-verification after the local adjustment is completed.

[0085] The cloud-based system first establishes a local adjustment scope starting from the abnormal node. This local adjustment scope then expands node by node downstream of the task sequence, confirming its effectiveness based on road connectivity. To prevent uncontrolled spread of local disturbances into global adjustments, a maximum expansion level can be set for the local associated paths. The maximum expansion level can range from 3 to 5 levels, with 4 being the preferred option. This value is chosen because below 3 levels, the local digestible space is too small, easily triggering premature global reorganization; above 5 levels, the local processing scope is too wide, easily evolving into a de facto full-link rearrangement. In addition to the maximum expansion level, a maximum cumulative path distance constraint can also be added. The maximum cumulative path distance can range from 20 to 50 kilometers. This value is chosen because below 20 kilometers, the local processing scope is insufficient for urban multi-node delivery scenarios; above 50 kilometers, the local boundary is too wide, easily weakening the local isolation effect. The above range can accommodate both urban delivery and intercity short-distance transportation scenarios.

[0086] Once the local associated path is determined, the cloud uses the node delay of the abnormal node as the current delay value to be absorbed. The node delay is taken from the abnormal node record, in seconds, and is greater than 0. The current delay value to be absorbed represents the total time deviation that needs to be digested, transmitted, or retained within the local associated path. To ensure the reproducibility of the data structure, the cloud generates a local adjustment record in the current session. The local adjustment record includes at least the following fields: local path number, abnormal node number, local path start point, local path end point, current delay value to be absorbed, current processing node number, local adjustment status, and session version number. The session version number can be the latest valid version number corresponding to the current delivery session, used to identify the data scope to which the current local adjustment record belongs. The local path number can be determined based on the vehicle identifier, abnormal node number, and adjustment initiation time for subsequent tracking and log correspondence. The local adjustment status can be divided into pending expansion status, absorption status, absorbed status, incompletely absorbed status, and interrupted reconstruction status.

[0087] Subsequently, the cloud executes buffer duration reading and sequential absorption processing according to the node order in the local association path, starting from the first downstream node of the abnormal node. The buffer duration represents the time space that a subsequent node can provide to absorb the preceding delay without exceeding its latest service time constraint. The buffer duration can be obtained by subtracting the current estimated arrival time from the node's latest service time, and then subtracting the node's on-site operation time. If a node has waiting time, the waiting time is not counted separately, but is already reflected in the difference between the estimated start time and the estimated arrival time. The buffer duration is expressed in seconds and can be positive, 0, or negative. A positive value indicates that the node still has available absorption space, 0 indicates that the node has no available absorption space, and a negative value indicates that the node no longer has the ability to absorb the preceding delay.

[0088] To avoid the instability caused by extreme values ​​in local processing, the maximum buffer time that a single node can absorb can be the smaller of its actual buffer time and the preset absorption limit. The preset absorption limit can be between 30 minutes and 60 minutes. The basis for this value is that 30 minutes corresponds to the acceptable delay time for nodes with low service time flexibility without significantly affecting performance, while 60 minutes corresponds to the acceptable delay time for nodes with queuing, handover waiting, or service window flexibility. The above range can cover the acceptable delay range for most field nodes in local delayed processing.

[0089] If the buffer duration of the current processing node is greater than or equal to the current delay value to be absorbed, it indicates that the node can absorb all remaining delays within its own service time elasticity. At this time, the cloud will uniformly extend the node's estimated arrival time, estimated start time, and estimated departure time by the current delay value to be absorbed, and regenerate the estimated arrival time for subsequent nodes in the local associated path that are affected by the change in the previous departure time, so as to maintain the temporal continuity within the delivery chain. After this extension is completed, the current delay value to be absorbed is set to 0, the local adjustment state is switched to the absorbed state, and the expansion to deeper nodes is stopped.

[0090] If the buffer duration of the current processing node is less than the current delay value to be absorbed but greater than 0, it indicates that the node can only partially absorb the preceding delay. In this case, the cloud first uses all available buffer duration of the node to absorb the delay, and adjusts the node's estimated arrival time, estimated start time, and estimated departure time according to the corresponding absorption amount. Then, the remaining unabsorbed delay value is passed to the next node. The remaining unabsorbed delay value is equal to the current delay value to be absorbed minus the actual absorption amount of the node. After the node finishes processing, the current processing node number is updated to the next node, and the local adjustment status remains in the absorption state. If the buffer duration of the current processing node is less than or equal to 0, the node does not participate in absorption, but only passes the current delay value to be absorbed to the next node as is, and the node is recorded as the transmission node. Through node-by-node absorption and node-by-node transmission, the delay amount in the local associated path propagates sequentially downstream.

[0091] Each participating node generates a node adjustment record. The node adjustment record must include at least the following fields: node number, node order, estimated arrival time before adjustment, estimated arrival time after adjustment, estimated departure time before adjustment, estimated departure time after adjustment, node buffer duration, actual absorption volume, adjustment status, and adjustment timestamp. All node adjustment records constitute a local adjustment log. The local adjustment log is used to record the local delayed processing process, as well as the source tracing and reorganization scope determination of the remaining unabsorbed delay values. The local adjustment log uses the same node number and session version number as the estimated arrival time sequence table and is written back to the current delivery session. The local adjustment log must include at least the following fields: node number, estimated arrival time after adjustment, estimated departure time after adjustment, actual absorption volume, and remaining unabsorbed delay values. Nodes outside the local associated path are read-only until the new local processing scope is determined; their estimated arrival time, estimated start time, and estimated departure time are not modified.

[0092] During the local adjustment process, the cloud sets the following state transition rules: If the current delay value to be absorbed has reached zero before the maximum expansion level is reached, the local adjustment state changes from the absorbing state to the absorbed state, the local delay processing ends, and a re-verification is triggered; during the re-verification, the aforementioned timing verification rules can be called to re-determine whether there are still service time conflicts for the adjusted nodes and the nodes in the candidate abnormal node list within the local associated path; if the current delay value to be absorbed is still greater than 0 after the maximum expansion level is reached, the local adjustment state changes to the incompletely absorbed state, and the remaining unabsorbed delay value, along with the local path number, the list of participating adjustment nodes, and the local adjustment log, are output as input for subsequent node order adjustment and task chain reorganization processing;

[0093] For anomalies and boundaries, interruption and reconstruction are performed. If a sudden change in node status occurs during local adjustment, such as the current processing node being closed, entry being prohibited, the road status changing to impassable, or the node priority being raised to non-delayable by the business system, the current local extension process is immediately stopped, and the local adjustment process is switched to interruption and reconstruction. After switching to interruption and reconstruction, the cloud retains the currently completed node adjustment records but does not return the currently completed node adjustment results. The local path range is regenerated based on the currently completed adjustment results. The starting point of the regenerated local path is still based on the current abnormal node, and the path endpoint, maximum expansion level, and set of processable nodes are recalculated based on the latest road network status and node status. If the new legal absorption node is a new node after reconstruction, the delay absorption method is still used. If there are still no usable nodes after reconstruction, the remaining unabsorbed delay values ​​are directly transferred to subsequent processing.

[0094] Regarding time and resource constraints, the processing time for a single local adjustment can be between 1 and 3 seconds. This value is chosen because it can cover the sequential traversal of a small number of nodes within the local path, buffer time calculation, timing adjustment, and result write-back processing, while maintaining a rapid response to real-time disturbances. For pending paths exceeding the preset node limit, the maximum number of nodes for local adjustment can be between 5 and 7. This value is chosen because it can cover the local absorption scenario of short links after abnormal nodes, while avoiding a significant increase in processing time due to an excessively wide local processing scope. For high-concurrency scenarios, only one effective local adjustment record is allowed for the same vehicle under the same session version. Subsequent new local disturbances are created only after the current local adjustment is completed or transferred to subsequent processing, to prevent the same task chain from being modified by multiple local adjustment records simultaneously.

[0095] Specifically, such as Figure 5As shown: When local delay processing fails to absorb the remaining delay value, the cloud performs reorganization processing on the unexecuted nodes within the local path boundary; the current processing calls the remaining unabsorbed delay value, local path information, updated expected arrival time table, node constraint table, and relevant data in the current session state; the remaining unabsorbed delay value is expressed in seconds, and a value greater than 0 indicates that the local delay has not been fully absorbed; the local path information includes at least the local path number, path start node, path end node, list of nodes participating in the adjustment, and local boundary marker; the updated expected arrival time table includes at least the expected arrival time, expected start time, expected departure time, waiting amount, delay amount, and constraint status of each unexecuted node; the node constraint table includes at least the node number, current order, node position, task priority, on-site operation duration, earliest service time, latest service time, splittable marker, and current execution status; node reorganization is only initiated when the remaining unabsorbed delay value is greater than 0 and the current session state is in a state of incomplete absorption; if the remaining unabsorbed delay value has returned to zero, the aforementioned local adjustment result is maintained, and reorganization processing is not initiated;

[0096] The cloud platform first filters unexecuted nodes based on local path information, forming a set of nodes to be reorganized. This set excludes completed nodes, cancelled nodes, nodes in a prohibited state, and nodes deemed unadjustable by the aforementioned processes; it only retains nodes within the local path boundaries that still have room for adjustment. Each node to be reorganized is represented using a unified reorganization node record. This record includes at least the node number, current order, node position, task priority, on-site operation duration, earliest service time, latest service time, estimated arrival time, current delay, service elasticity, and shardability. Fields such as flags and retention priority flags; service elasticity is used to represent the acceptable delay capacity of a node under the current time sequence, which can be obtained by subtracting the expected arrival time from the latest service time; when the service elasticity is less than or equal to 0, the node is not considered a priority to move backward; service elasticity is mainly used for node sorting and reorganization judgment, and its calculation method is different from that of the aforementioned buffer duration; splittable flag is used to indicate whether the node is allowed to be temporarily removed from the current vehicle task chain and transferred to subsequent capacity, which can be either allowed to split or prohibited from splitting; retention priority flag is used to indicate whether the node belongs to the priority retention node in the current round of reorganization;

[0097] After the reorganized node set is formed, the cloud performs a retention judgment on each node. The retention judgment considers task priority, service time urgency, current delay, and splittable attributes. Task priority can be set from 1 to 10, with higher values ​​indicating higher fulfillment requirements. Service time urgency can be represented by the remaining time between the latest service time and the current time, with smaller remaining time indicating greater urgency. Nodes with high task priority and tight latest service time are given priority for retention and are not considered for initial adjustment. Nodes with low task priority, large service elasticity, or splittable attributes are considered for initial adjustment. Task priority can be stratified into 1 to 3, 4 to 6, and 7 to 10, with nodes at levels 1 to 3 being the first priority for adjustment, nodes at levels 4 to 6 being the second priority for adjustment, and nodes at levels 7 to 10 being the priority for retention. The basis for these values ​​is that low-priority nodes are more suitable for being moved later in the order or temporarily removed, while high-priority nodes are more suitable for being retained in the current task chain to maintain overall fulfillment stability.

[0098] After completing the retention decision, the cloud performs a sequence adjustment within the local boundary. The sequence adjustment moves the first-adjusted objects backward without changing the relative order of the priority retention nodes, in order to relieve the service time pressure of the preceding path. The cloud first fixes the current position of the priority retention nodes, and then selects the node with the largest service elasticity from the first-adjusted objects to perform the backward movement. If the estimated arrival time of the node after the backward movement still does not exceed its latest service time, the backward movement is confirmed to be effective. If the backward movement will turn the node into a new high-risk conflict node, the backward movement is rolled back and the next candidate node is tried. To ensure reproducibility, each shift is adjusted in granularity of one node position, meaning that only one candidate node is moved one position backward each time, or moved after the next priority node. After each shift, the cloud recalculates the estimated arrival time, estimated start time, and estimated departure time of the affected nodes, and updates the current remaining unabsorbed delay value synchronously. If a shift reduces the current remaining unabsorbed delay value to 0, or restores all reserved nodes after the abnormal node to a conflict-free state, the order adjustment ends at the current position, and unnecessary shifts are no longer performed.

[0099] If the remaining unabsorbed delay value cannot be reduced to an acceptable range by sequential shifting, then node removal processing is initiated. Node removal is only open to nodes that simultaneously meet the criteria of low priority, large service elasticity, and are marked as splittable. Removed nodes are temporarily removed from the current task chain and written to the task pool awaiting reallocation. The task record awaiting reallocation must include at least the following fields: node number, original vehicle number, original order, node position, earliest service time, latest service time, on-site operation duration, task priority, removal reason code, and removal time. Removal reason codes can be of types such as unabsorbable delay, local boundary constraints, and missed execution window. To prevent excessive splitting, the maximum number of nodes removed in a single round can be 1 to 3; its value depends on… The rationale is that this range can relieve local reorganization pressure while avoiding excessive weakening of the current vehicle task chain, making it suitable for limited extraction scenarios with a small number of low-priority nodes within local boundaries; the extraction process can be judged by extracting single nodes one by one; if the number of candidate extraction nodes exceeds the upper limit, the node with the lowest priority and the latest service time furthest from the current time will be extracted first; if there are no nodes that can be split in the set of nodes to be reorganized, or if the service time requirement of the retained node cannot be met after extracting one node, the completed order adjustment result will be maintained, and the current session will be marked as a high-risk execution state; the path version in the high-risk execution state will only enter the observation branch or the manual confirmation branch, and will not be used as the default automatic switching version;

[0100] After adjusting the order and removing necessary nodes, the cloud regenerates subsequent delivery routes based on the new node sequence. During route reconstruction, the current vehicle adjustment reference position is used as the starting point, and the positions of each retained node are connected sequentially according to the new node order. The passage path between adjacent nodes is determined by combining the current road network status table. When there is a prohibited passage section between adjacent node pairs, an alternative path is selected first within the current local boundary. If there is no reachable path within the local boundary, the system reverts to the most recent valid node sequence version, writes it to the exception record table, and waits for the next session. The most recent valid node sequence version can be determined based on historical versions and the verified subsequent route table. After the route reconstruction is completed, the estimated arrival time of the new subsequent delivery route is verified. The estimated arrival time, estimated start time, and estimated departure time of each retained node are estimated sequentially. It is checked whether the latest service time is exceeded. Only when all retained nodes are executable and risk nodes have been marked as waiting for reallocation can the route version be issued.

[0101] To ensure that the data structure and interface can be directly implemented, the cloud will output the reorganization results as a subsequent path table and an execution instruction package. The subsequent path table should include at least the following fields: vehicle number, path version number, new node sequence, node number, new estimated arrival time, new estimated start time, new estimated departure time, node status, pending reallocation flag, and generation time. The node status can be either retained for execution, moved to the next execution stage, pending reallocation, or high-risk observation. The execution instruction package should include at least the following fields: vehicle number, path version number, effective time, effective duration, execution node sequence, verification flag, and source reason code. The path version number can be determined based on the vehicle number, generation time, and version number, and is used to identify different reorganization results. The effective time is used to limit the timing of path version switching; the effective duration is used to limit the effective window of the instruction packet; the verification flag is used by the terminal to confirm the integrity of the received content; and the source reason code is used to identify that the instruction comes from local reassembly processing. A buffer interval of 2 to 8 seconds can be reserved between the effective time and the current generation time. The basis for this value is that 2 seconds can cover the shortest preparation time for normal communication and terminal parsing, and 8 seconds can cover short-term communication jitter and terminal processing delay, thus providing a stable window for terminal reception, verification, and preparation for switching. The effective duration can be 8 to 20 seconds. The basis for this value is that this range can cover the switching uncertainty caused by short-term terminal communication jitter and continuous vehicle displacement.

[0102] Upon receiving the execution command packet, the terminal does not immediately switch to the new path. Instead, it performs boundary confirmation of both location and time conditions. The terminal uses the distance between the current vehicle position and the adjustment reference position as the location condition, and the difference between the current time and the effective time of the command packet as the time condition. Only when the distance between the current vehicle position and the adjustment reference position is less than or equal to 20 meters, and the difference between the current time and the effective time of the command is within the range of -4 seconds to +4 seconds, does it switch to the new path. The 20-meter distance threshold is suitable for the actual switching tolerance of trucks under road-level positioning conditions. The -4-second to +4-second time threshold can take into account vehicle clock deviation and short-term communication delays. If the vehicle crosses the effective position prematurely, or fails to reach the effective position after the effective time has expired, the terminal returns an out-of-bounds status code. Upon receiving the out-of-bounds status code, the cloud abandons the current path version and restarts a new round of adjustment processing based on the latest location, the latest time, and currently unexecuted tasks.

[0103] If communication interruption causes the execution command packet to not be delivered on time, the terminal maintains the current valid path, does not switch to the unconfirmed latest version in advance, and re-requests the latest version in the next communication recovery cycle; the communication recovery cycle can be 1 to 3 sampling cycles; the value is based on the fact that, under the aforementioned 500 millisecond sampling cycle, the corresponding retry window of 0.5 seconds to 1.5 seconds can cover short-term link fluctuations; if the terminal has received the new version but the verification mark fails, it maintains the current valid path and returns a verification failure code to the cloud; after receiving the verification failure code or out-of-bounds status code, the cloud marks the current path version as an invalid version, does not resend the same invalid version, but re-enters a new round of session processing based on the latest location and time returned by the terminal;

[0104] Regarding boundary conditions and anomaly recovery, the system extracts the features that only take effect within the local path boundary and do not affect nodes outside the local path that have been frozen into a read-only state; nodes in the task pool awaiting reallocation will only be marked and output during current processing and will not participate in the reordering of the current vehicle's reorganization path; the current vehicle will experience a higher level of disturbance before the instruction takes effect, such as a new forced fulfillment order entering, generating a new path version number with the new event, and stopping the issuance of old versions that have not yet taken effect in the future; for high-concurrency scenarios, only one path version awaiting effect is allowed to exist on a single vehicle at the same time, and the new path version will be issued after overwriting the old version.

[0105] Example 2: Taking a target truck performing urban trunk and branch line delivery tasks as an example, the truck's current delivery chain includes four incomplete delivery nodes, namely node A, node B, node C, and node D. Node A is a transfer and handover node, node B is a store replenishment node, node C is a temporary warehouse unloading node, and node D is a terminal signing node. At the start of this round of delivery, the cloud establishes a delivery session corresponding to the target truck and continuously receives vehicle dynamic operation data uploaded by the vehicle terminal, task data issued by the business platform, and road network status data provided by the map platform. The vehicle terminal uploads its current location, current speed, current heading angle, etc., at a sampling period of 500 milliseconds. Data such as load ratio and operating status are provided; the business platform synchronously provides data such as node sequence, node location, earliest service time, latest service time, on-site operation duration, and task priority from node A to node D; the map platform synchronously provides data such as average traffic speed, congestion index, passability status, and update time of the vehicle's current driving segment and subsequent related segments; after the cloud performs time alignment, integrity verification, validity verification, road matching, and status normalization on the above data, a basic status table, node constraint table, road network status table, and session status identifier are formed; at this time, the session status identifier is in the disturbance judgment state, indicating that the target truck has the conditions to enter the subsequent dynamic adjustment process;

[0106] During the delivery session, the target truck was originally scheduled to complete node A first, followed by nodes B, C, and D in sequence. The cloud continuously monitored the vehicle's operational status and business status. When the target truck reached the road adjacent to node A, the average speed over the last six sampling periods dropped from the historical average speed of 16 meters per second to below 11 meters per second, a decrease of over 20%, and the congestion index of the adjacent road ahead reached 0.81, exceeding the disturbance judgment threshold of 0.75. Based on this, the cloud determined that a road disturbance had occurred and switched the current session status from the disturbance judgment state to the pending adjustment state. At this point, the cloud did not directly use the vehicle's current instantaneous position as the starting point for subsequent adjustments but instead generated a future execution position. Specifically, the cloud determined the most likely road position the vehicle would reach when the adjustment results for this round were formed and ready for distribution, based on the current speed, current heading angle, road connection direction, and estimated processing time. The current disturbance type is one. Based on general congestion and historical processing delay records, the cloud platform estimates the processing time for this round to be 8 seconds. According to the current location, speed, and road connectivity, the vehicle is expected to move approximately 88 meters forward within this timeframe. Considering the current low-speed following mode, the cloud platform applies a correction factor of 0.5, ultimately determining the candidate future execution location to be approximately 44 meters ahead of the current road. This candidate location is deemed valid after road attribute verification, location safety verification, and accessibility verification, and does not enter the ramp conflict zone, bridge no-stopping zone, or construction closure zone; therefore, it is directly used as the future execution location. Subsequently, the cloud platform reads unexecuted nodes along the current delivery route, compares the order of each node with the future execution location, and determines the first unexecuted node after the future execution location as node A. Therefore, node A is designated as the starting adjustment node, and the current time plus the estimated processing time is used as the adjustment base time, with the future execution location as the adjustment base position.

[0107] After the initial adjustment node is determined, the cloud performs timing verification on the unexecuted nodes after node A. Using the adjustment reference position and adjustment reference time as a unified starting point, the cloud sequentially estimates the estimated arrival time, estimated start time, and estimated departure time of nodes A, B, C, and D. Specifically, the road travel time between nodes A and D is estimated segment by segment based on the effective average travel speed and road length in the road network status table. If the update time of a certain related road segment exceeds 60 seconds, it is adjusted by combining the historical reference speed with the current congestion index. The estimated arrival time of node A, after calculation, is later than its latest service time by 1 second. 20 seconds, therefore node A is marked as a service time conflict node, with a node delay of 120 seconds; although nodes B and C are also delayed to varying degrees due to the impact of previous delays, node A is the first node with a delay greater than 0 according to the node order, therefore node A is identified as the current abnormal node, and nodes B and C are added to the candidate abnormal node list; at the same time, the cloud generates an updated estimated arrival time table, which records the estimated arrival time, estimated service start time, estimated departure time, waiting time, delay, and constraint status of nodes A to D, as the data basis for subsequent local delay processing;

[0108] After identifying the abnormal node, the cloud establishes a local adjustment range starting from node A. The cloud expands the range node by node downstream of the task sequence, confirming local associated paths based on road connectivity. Nodes B, C, and D following node A all belong to the same unexecuted delivery chain for the same vehicle, and there are continuous road connections between node A and node D that are currently passable. Therefore, nodes B, C, and D are all included in the local associated paths. Considering the current scenario is short-chain urban delivery, the cloud uses a maximum expansion level of 4 layers, which is sufficient to cover all subsequent nodes after node A. Subsequently, the cloud uses the delay of 120 seconds for node A as the current delay value to be absorbed, and reads the buffer duration of each node in the order of node B, C, and D. The calculated buffer duration for node B is 3 seconds. At 00:00, the buffer time for node C is 90 seconds, and the buffer time for node D is 240 seconds. Since the buffer time for node B is 300 seconds, which is greater than the current delay value to be absorbed by 120 seconds, it indicates that node B can absorb all the remaining delays within its own service time elasticity. Therefore, the cloud extends the estimated arrival time, estimated start time, and estimated departure time of node B by 120 seconds, and regenerates the estimated arrival times for nodes C and D, which are affected by the change in their previous departure times. After this adjustment, the current delay value to be absorbed is zero, and the local adjustment state is switched to the absorbed state. Subsequently, the cloud re-executes the timing check on nodes A to D, confirming that nodes B, C, and D are no longer later than their respective latest service times, the candidate abnormal node list is cleared, and this round of local extension processing ends.

[0109] In another operational scenario, if node B's buffer time is only 40 seconds, node C's is 30 seconds, and node D's is 20 seconds, then nodes B, C, and D can only absorb a total of 90 seconds of delay, which is less than the 120 seconds of delay to be absorbed from node A. In this case, after the local associated paths are sequentially processed for delayed absorption, 30 seconds of unabsorbed delay remain, and the local adjustment state switches to an incomplete absorption state. The cloud then initiates node reorganization processing. The cloud first filters nodes B, C, and D based on local path boundaries, forming a set of nodes to be reorganized. Assume node B has a task priority of level 8, node C level 3, and node D level 6, and node C is marked as splittable, while nodes B and D are marked as not splittable. The cloud performs a retention judgment on the nodes to be reorganized, prioritizing node B, making node C the first priority adjustment target, and node D the second priority adjustment target. Subsequently, the cloud first attempts to move node C sequentially backwards... Node C is moved after Node D, and the estimated arrival time, estimated start time, and estimated departure time of Nodes B, D, and C are recalculated. If the estimated arrival time of Node C after the move still does not exceed its latest service time, and Nodes B and D return to a conflict-free state, then the order adjustment is confirmed to be effective, forming a new node execution order (BDC), and the subsequent delivery path is reconstructed based on this order. If Node C itself becomes a new high-risk conflict node after the order is moved, then the adjustment is rolled back, and an attempt is made to remove the node. Since Node C simultaneously meets the requirements of low priority, large service elasticity, and allows splitting, the cloud can remove Node C from the current vehicle task chain, write it into the task pool to be reassigned, and generate a task record to be reassigned for it. At this time, the cloud regenerates the subsequent delivery path based on the remaining retained Nodes B and D, and performs the estimated arrival time verification again. If both Nodes B and D are in an executable state, the current path version enters the distribution stage.

[0110] After path reconstruction is complete, the cloud outputs the results as a subsequent path table and an execution command package. The subsequent path table includes at least the following fields: vehicle number, path version number, new node order, node number, new estimated arrival time, new estimated start time, new estimated departure time, node status, and pending reallocation flag. The execution command package includes at least the following fields: vehicle number, path version number, effective time, effective duration, execution node sequence, verification flag, and source reason code. Assuming the current generation time is 10:00:00, the cloud reserves a 4-second buffer interval for the new path version, sets the effective time to 10:00:04, and the effective duration to 12 seconds. After receiving the execution command package, the terminal does not switch immediately but performs a dual-condition confirmation of location and time. If the current vehicle... If the distance between the vehicle's location and the adjustment reference location is less than 20 meters, and the difference between the current time and the effective time is within the range of -4 seconds to +4 seconds, the terminal switches to the new path for execution. If the vehicle crosses the effective location prematurely, or fails to enter the switching interval after the effective duration has expired, the terminal returns an out-of-bounds status code. The cloud marks the current path version as invalid and restarts a new round of adjustment processing with the latest location, latest time, and currently unexecuted tasks. If communication interruption causes the instruction packet to not be delivered on time, the terminal maintains the current valid path and requests the latest version again within a communication recovery window of 1 to 3 sampling cycles. If the execution instruction packet has been received but the verification mark fails, the terminal returns a verification failure code, the cloud abandons the current version and regenerates a new path version.

[0111] After a disturbance occurs, the cloud does not directly perform a global reordering. Instead, it first determines the future execution location and the starting adjustment node based on the delivery session and unified data standards. Then, it performs time sequence verification on subsequent delivery nodes at a unified time starting point and identifies the first abnormal node. Subsequently, it prioritizes absorbing and processing delays within the local path boundary through extension. When local extension cannot complete the absorption, it then performs sequence adjustment, node removal, and path reconstruction on the unexecuted nodes within the local path boundary. The terminal then executes the new path version after confirming the location and time conditions. Through the above processing, the cloud scheduling results can be kept consistent with the actual execution status of the vehicles, reducing the spread of local delays to the entire task chain and improving the execution accuracy, response timeliness, and operational stability of dynamic scheduling.

[0112] It should be noted that this invention can be deployed on the device itself to realize embedded applications, or it can run on a PC or other terminal with a user interface, thereby meeting various hardware environments and usage requirements.

[0113] The above embodiments can be implemented in whole or in part by software, hardware, firmware, or any other combination. When implemented in software, the above embodiments can be implemented in whole or in part by a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, the processes or functions of the embodiments of this application are implemented in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted wirelessly or wiredly from one website, computer, server, or data center to another website, computer, server, or data center. Wired methods include optical fiber, twisted pair, coaxial cable, etc. Wireless methods include infrared, microwave, etc. Available media include any available media that can be accessed by a computer or data storage devices such as servers and data centers that contain one or more sets of available media. Available media can be magnetic media (floppy disks, hard disks, magnetic tapes), optical media (DVDs), or semiconductor media. Semiconductor media can be solid-state drives.

[0114] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

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

Claims

1. A method for optimizing dynamic routes and time windows for freight trucks, characterized in that, include: Obtain the target truck's current location, driving status, current delivery task, service time requirements for each delivery node, and road network traffic status; Based on the session state identifier, road condition disturbances and business disturbances are judged. When road condition disturbances or business disturbances exist, the starting adjustment node for the subsequent delivery of the target truck is determined, and the subsequent route adjustment and time adjustment are executed from the starting adjustment node. Based on the initial adjustment node, the expected arrival order and expected arrival time of the target truck's subsequent delivery nodes are checked to identify abnormal nodes that have service time conflicts; Starting from the abnormal node, the arrival time of its subsequent delivery nodes is adjusted sequentially within the local delivery route. If adjustments cannot be made within the scope of a local delivery route, the order of delivery nodes that have not yet been executed is adjusted, and the subsequent delivery routes and node arrival order of the target trucks are re-determined.

2. The method for optimizing dynamic routes and time windows for trucks according to claim 1, characterized in that, Obtain the target truck's current location, driving status, current delivery task, service time requirements for each delivery node, and road network accessibility, including: Establish delivery sessions corresponding to target trucks, and perform unified time alignment and organization of vehicle dynamic operation data, task data, and road network status data; The system sequentially performs integrity checks, validity checks, road matching, state normalization, missing information completion, and anomaly marking, generating a basic state table, a node constraint table, a road network state table, a session state identifier, and an anomaly record table.

3. The method for optimizing dynamic routes and time windows for trucks according to claim 1, characterized in that, Based on session state identifiers, road condition disturbances and business disturbances are assessed. When road condition disturbances or business disturbances exist, the starting adjustment node for the subsequent delivery of the target truck is determined, including: Traffic disturbances and service disturbances are determined based on session state identifiers; When a disturbance occurs, candidate future execution locations are determined based on the current location, current speed, current heading angle, road connectivity direction, and estimated processing time. Road attribute verification, location safety verification, and reachability verification are then performed on the candidate future execution locations. If a candidate future execution position does not meet the verification conditions, perform a sliding search along the current road connection direction until a legal future execution position is determined.

4. The method for optimizing dynamic routes and time windows for trucks according to claim 1, characterized in that, Subsequent path and time adjustments will be executed starting from the initial adjustment node, including: Based on the legal future execution location, adjustment benchmark time, and the order of roads and nodes on the current delivery route, the unexecuted delivery nodes are compared sequentially, and the first unexecuted delivery node after the future execution location is determined as the adjustment starting point; If the future execution location exceeds the original candidate node, the corresponding node will be written into the exception record table and retained in the unresolved node set. Subsequent timing verification and path adjustment will be based on the future execution location and adjustment base time.

5. The method for optimizing dynamic routes and time windows for trucks according to claim 1, characterized in that, Based on the initial adjustment node, the expected arrival order and expected arrival time of the target truck's subsequent delivery nodes are verified, including: A sequence to be checked is formed based on the adjustment benchmark location, adjustment benchmark time, node constraint table, and road network status table; Using the adjusted base time as a unified time starting point, and combining the estimated departure time of upstream nodes, road travel time between nodes, road condition compensation, waiting time, and on-site operation time, the estimated arrival time, estimated service start time, and estimated departure time of each node are sequentially estimated to form an estimated arrival time sequence table.

6. The method for optimizing dynamic routes and time windows for trucks according to claim 1, characterized in that, Identify the abnormal nodes where service time conflicts occur, including: The estimated arrival time of each node is compared with the corresponding latest service time. The difference between the estimated arrival time and the latest service time is recorded as the node delay. The first node with a delay greater than zero is selected as the current abnormal node in the node order. The subsequent conflicting nodes are written into the candidate abnormal node list and an abnormal node record is generated. Nodes with missing service time are categorized as weakly constrained nodes, and nodes with impassable road segments are categorized as path-blocked pending states.

7. The method for optimizing dynamic routes and time windows for trucks according to claim 1, characterized in that, Starting with the abnormal node, the arrival times of its subsequent delivery nodes within the local delivery route are adjusted sequentially, including: Based on the abnormal node records, the expected arrival time table, the node constraint table, and the road network status table, the local path boundary is determined. Under the condition of satisfying business continuity and road connectivity, the buffer duration is read node by node. Delay absorption, delay propagation, state switching, and local reconstruction are performed according to the delay value to be absorbed, generating local adjustment records, local adjustment logs, and subsequent processing basis.

8. The method for optimizing dynamic routes and time windows for trucks according to claim 1, characterized in that, When adjustments cannot be completed within a specific delivery route, the order of delivery nodes that have not yet been executed will be adjusted, including: When the remaining unabsorbed delay value is greater than zero and the current session state is in the incomplete absorption state, a set of nodes to be reassembled is formed based on the local path information and the updated expected arrival time table. The retention decision is made by combining task priority, service time urgency, service elasticity, and splittable flags, and the execution order is shifted to the back without changing the relative order of priority retention nodes. For nodes that still cannot meet the service time requirements after being moved to the next order but meet the splitting conditions, write them into the task pool to be reassigned.

9. The method for optimizing dynamic routes and time windows for trucks according to claim 1, characterized in that, The subsequent delivery routes and node arrival sequences for the target trucks were redefined, including: The subsequent delivery routes are reconstructed based on the reorganized node sequence and road accessibility within the local boundaries. The arrival time of each reconstructed node is then verified to form a subsequent route table and execution instruction information. If no reachable path exists within the local boundary, fall back to the most recent valid node sequential version; The terminal confirms the path switch based on location and time conditions, maintains the current valid path in the event of boundary crossing, verification failure, or communication interruption, and performs invalid version update processing.

Images