A single-vehicle online instant intelligent matching method for low-density wave order

Abstract

A single-vehicle online instant intelligent matching method for low-density wave order is provided, which belongs to the field of logistics distribution scheduling and aims to solve the problems of low efficiency and poor experience in order and delivery man matching in the low-density wave order scenario. The historical utility value of the delivery man in the online state is calculated. The delivery qualification of the delivery man is judged. According to the historical utility value, the display priority order of the candidate delivery man to the collection state of the set order is obtained. The candidate delivery man can see the set order in the collection state and the delivery available price according to the time sequence. According to the time sequence of the order request initiated by the candidate delivery man, the set order in the collection state visible to the candidate delivery man is distributed. The effect is to realize the intelligent order matching and accurate matching of the delivery man, and significantly improve the task value density, order success rate and platform operation efficiency in the low-density scenario.

Description

Technical Field

[0001] This invention belongs to the field of logistics and distribution scheduling technology, specifically relating to a single-vehicle online real-time intelligent matching method for low-density wave orders. Background Technology

[0002] With the rapid development of e-commerce, instant logistics, and local life services, the demand for last-mile delivery is constantly increasing. Delivery scenarios are gradually expanding from urban areas with dense orders, well-developed road networks, and sufficient dedicated delivery capacity to low-density areas with dispersed orders, complex road conditions, and unstable capacity supply. Traditional dedicated delivery models typically rely on fixed delivery personnel, fixed stations, and fixed routes, maintaining high efficiency in scenarios with large order volumes and stable demand distribution. However, in scenarios with sparse order demand, long delivery distances, and uneven delivery times, fixed delivery capacity is prone to problems such as high empty-run rates, high unit delivery costs, and insufficient service coverage.

[0003] To address this challenge, most last-mile delivery platforms rely on technologies such as mobile internet, electronic maps, satellite navigation, location communication, and cloud computing to collect real-time information on user orders, delivery personnel locations, delivery personnel order acceptance status, vehicle or vehicle type, road traffic conditions, and order fulfillment results. Based on this information, they allocate orders and recommend routes. Existing common scheduling methods often use spatiotemporal distance-based order aggregation and merging, selecting delivery personnel according to spatial proximity rules, and then assigning tasks to delivery personnel based on route distance or time cost. These technologies can improve dispatch efficiency, reduce platform manual scheduling costs, and to some extent alleviate the problem of uneven task allocation among delivery personnel in scenarios with high order density, sufficient delivery personnel, and relatively stable road conditions. However, as e-commerce and instant delivery platforms extend to low-density, decentralized areas with complex traffic conditions, last-mile delivery exhibits characteristics such as sparse order distribution, unstable task arrival, a hub-and-spoke or corridor-like road network structure, limited available capacity, and significant individual differences. In such scenarios, platforms need to increase the value density of each delivery task while avoiding excessive detours, long waiting times, or no one accepting orders due to unreasonable order consolidation. Therefore, targeted order aggregation methods are required to reduce costs and increase efficiency. Furthermore, to fully utilize social transportation capacity and reduce delivery costs, delivery platforms typically integrate crowdsourcing models into their dispatch strategies. This requires that order dispatch strategies fully consider the carrying capacity of part-time delivery personnel, as well as their task pricing, service area preferences, detour tolerance, and order acceptance behavior patterns, in order to improve order dispatch success rates and system operational efficiency.

[0004] In actual last-mile delivery operations, the system primarily serves four parties: users, riders accepting orders, delivery stations, and the dispatch center. Users submit delivery requests through the client, including pick-up and delivery addresses, cargo information, and time requirements. The orders then enter the platform for processing. The dispatch center consolidates incoming orders according to periodic or wave rules, generating a total package suitable for a single delivery. It then filters potential riders based on their location, carrying capacity, home route, and time window, pushing the task to the rider's app through recommendations or displays. Riders view the list of available tasks on their client and decide whether to accept the order based on their own circumstances. Once accepted, the system locks the task and notifies the user. Riders travel to the designated collection point or delivery station to pick up the package, complete package verification and handover via a terminal, and then perform last-mile delivery. During delivery, the rider's app continuously transmits location and task status, and the user can view the progress in real time. After delivery is completed and confirmed, the system settles the payment, and the rider receives the corresponding earnings. The delivery stations serve as intermediate nodes, handling temporary storage and transit of packages. The platform operators are responsible for overall monitoring, anomaly handling, and parameter adjustments, thus forming an operational process of user order placement, platform scheduling, rider execution, delivery station transit, and settlement feedback.

[0005] The patent publication CN 116228086 B, "Disclosing a Method for Equalizing Order Dispatch in Crowdsourced Instant Logistics Scenarios," divides the crowdsourced order dispatch process into two stages: pre-dispatch based on delivery cost and order balance decision-making. First, this invention primarily addresses the direct matching between individual new orders and delivery personnel in instant logistics. Its core lies in selecting delivery personnel from near the order and calculating the delivery cost, but it doesn't solve the problem of insufficient value density of individual orders in low-density delivery scenarios. When orders are sparsely distributed and delivery distances are long, dispatching only one order, even if a nearby delivery person can be found, may lead to delivery personnel refusing the order due to insufficient task benefits or uneconomical detours. Second, this invention selects delivery personnel based on the radius surrounding the order pickup address or user address. This method is suitable for instant delivery scenarios with strong road network connectivity and dense distribution of orders and delivery personnel, but it struggles to adapt to delivery environments with significant differences in road accessibility and where geographical proximity does not equate to path proximity. For scenarios with trunk and branch line structures, road detours, vehicle restrictions, or local road risks, selecting delivery personnel solely based on spatial radius easily produces candidate results that appear close but have high actual execution costs. Furthermore, while this invention considers the balance of delivery personnel's order volume, it primarily calculates the balance score based on historical average order volume, target order volume, and actual order volume. It does not adequately consider delivery personnel's order acceptance preferences, vehicle capacity, cargo suitability, detour tolerance, price differences, and historical order rejection feedback. Therefore, while this method can improve the issue of "whether the number of orders is balanced," it struggles to adequately determine "whether the delivery person will accept the task" and "whether the delivery person is suitable to perform the aggregated task." Finally, the order allocation object of this invention is still the order itself, not the aggregated order after order aggregation. For last-mile delivery scenarios that require increasing task revenue through order aggregation, this method struggles to improve the executability of the delivery plan from the task generation stage.

[0006] Patent application CN 121959075 A discloses a "delivery method based on spatiotemporal clustering in a shared delivery model for remote rural areas." The method transforms the shared delivery problem into a spatiotemporal clustering and multi-vehicle route optimization problem. First, this invention primarily constructs a spatiotemporal distance matrix based on customer location, order time window, and actual road network travel time, then performs clustering and route optimization, focusing on forming low-cost vehicle delivery routes. However, this method mainly addresses the issues of "how to cluster orders and how vehicles travel," failing to adequately address whether delivery personnel are willing to accept orders, how to accept orders, how to reject orders, and how to adjust matching strategies based on behavioral feedback in crowdsourcing scenarios. Second, while this invention considers multi-vehicle collaboration, the crowdsourced vehicles are primarily incorporated into the route planning model as a mode of transportation or vehicle type, rather than being modeled as independent participants with autonomous order-acceptance behavior, price differences, preference differences, and long-term retention issues. In actual crowdsourcing delivery, whether a delivery person accepts an order depends not only on route cost but also on their personal travel direction, time arrangement, expected income, handover convenience, and past platform experience. Treating them merely as vehicle resources fails to reflect the true operational patterns of the platform. Furthermore, the spatiotemporal clustering of this invention primarily emphasizes spatial distance, time window differences, and vehicle type constraints between customer points, lacking specific identification of the dominant order flow direction. For delivery networks with obvious trunk line convergence, terminal radiation, or corridor-like traffic characteristics, relying solely on spatiotemporal distance clustering may group orders with inconsistent directions, low merging efficiency, or high handover costs into the same category, thus affecting the execution effect of aggregated orders. Finally, this invention mainly uses optimization methods such as genetic algorithms, simulated annealing, and adaptive large neighborhood search to output delivery solutions, which are more suitable for batch planning and route optimization scenarios. However, in crowdsourced delivery platforms where orders and delivery personnel arrive dynamically, road conditions change in real time, and delivery personnel may refuse orders or confirm late, pre-optimized route solutions alone are insufficient to support online rolling scheduling and real-time re-matching requirements. Summary of the Invention

[0007] To address the above problems, this invention provides a single-vehicle online real-time intelligent matching method for low-density wave orders, comprising the following steps:

[0008] S1: Obtain orders with a status of "pending order" within the current rolling time window according to the preset wave rules, perform order merging processing based on order flow characteristics to generate a collection order, set the status of the collection order to "pending pickup", and calculate the delivery price based on the collection order;

[0009] S2: Add the collection order in the pending pickup status to the collection order pool to be delivered;

[0010] S3: Obtain online delivery personnel information, which includes historical delivery batch orders and their revenue information, historical route information, historical batch order cargo information, estimated order pickup time, single cargo transportation restriction information, and currently accepted but not yet delivered batch order information;

[0011] S4: Calculate the historical utility value of the online delivery personnel based on the collection of historical delivery orders and their revenue information within the most recent K delivery cycles.

[0012] S5: For the collection orders in the pool of orders to be delivered, the delivery qualification of the delivery personnel is determined based on the historical route information, historical collection order cargo information, estimated order pickup time and single cargo transportation restriction information of the online delivery personnel. Among them, those who meet the delivery qualification are candidate delivery personnel.

[0013] Based on the historical utility value, obtain the display priority order of the collection orders with the pending pickup status to the candidate delivery person;

[0014] S6: According to the display priority order, the candidate deliverymen are set into several display batches for display in different time sequences. The visibility permissions of the candidate deliverymen for the collection orders in the waiting-to-pickup state are set according to the display batches, so that the candidate deliverymen can see the collection orders in the waiting-to-pickup state and the delivery price in time sequence.

[0015] S7: The candidate deliveryman can initiate an order acceptance request for the collection of orders in the pending acceptance state that he / she can see. According to the time order in which the candidate deliveryman initiates the order acceptance request, the collection of orders in the pending acceptance state that the candidate deliveryman can see is allocated, and the allocated candidate deliveryman is unique; then the collection of orders in the pending acceptance state is set to accepted, so that the allocated candidate deliveryman can deliver all the orders in the allocated collection of orders alone.

[0016] The method further includes:

[0017] S8: For the collection order in the pending collection status, if the quotation is updated before the collection order is assigned, the delivery price is recalculated based on the updated quotation, and steps S3-S7 are executed; for collection orders in the collection status, the quotation cannot be updated.

[0018] S9: After the delivery cycle ends, settle the collection orders that have been picked up and completed, and update the delivery person's historical collection orders and their revenue information for use in calculating the historical utility value of the next delivery cycle.

[0019] In step S1, the preset wave rule is used to control the dynamic generation of waves and the determination of the rolling time window. The preset wave rule includes the basic time slice granularity Δt, the order quantity threshold N, and the maximum waiting time T. max ;

[0020] The basic time slice granularity Δt is a fixed period for the system to review the wave triggering conditions. The system periodically checks whether the triggering conditions for starting the next wave are met at intervals of basic time slice granularity Δt.

[0021] The order quantity threshold N is the lower limit of the cumulative number of pending order statuses required to trigger the generation of a new wave;

[0022] The maximum waiting time T max It is the maximum allowed time for an order to remain in the queue, set as an integer multiple of the base time slice granularity Δt;

[0023] The triggering condition for the dynamic generation of the wave is a logical OR operation of a quantity condition and a time condition. The quantity condition is that the currently accumulated number of pending orders reaches the order quantity threshold N; the time condition is that the waiting time since the end of the previous wave reaches the maximum waiting time T. max ;

[0024] The rolling time window is the time period from the end of the previous wave generation time to the current triggering of the new wave generation time, used to determine the time interval of the current set of orders to be processed.

[0025] The process of generating a collection list in step S1 includes:

[0026] Construct a directed attribute road network graph and load pre-trained road network node embedding vectors;

[0027] The order pickup and delivery points are mapped to the road network nodes to generate order flow feature vectors. With orders as nodes and the cosine similarity of the flow feature vectors as edge weights, a weighted similarity graph between orders is constructed to quantify the degree to which orders can be combined in terms of path and service.

[0028] The weighted similarity graph is input into a pre-trained graph neural network clustering model. Through multiple layers of graph attention convolution and differentiable clustering assignment layers, the probability distribution of each order belonging to each cluster is output, forming the initial soft clustering result.

[0029] Hard constraint checks are performed on the soft clustering results based on the set single rule base, illegal assignments are eliminated, and affected orders are redirected to legal clusters to generate candidate set singles that satisfy all rule constraints in the set single rule base;

[0030] Based on the order flow feature vector, the overall flow feature of the aggregated order is fused to form a structured order merging scheme. The status of the aggregated order is changed to pending pickup for subsequent delivery person matching and task assignment.

[0031] The set of single rule bases includes path distance constraints, transport capacity constraints, time window compatibility constraints, and cargo compatibility constraints.

[0032] The path distance constraint satisfies the formula:

[0033] D max =R×(1+η),

[0034] Among them, D max R is the maximum path distance, R is the baseline delivery radius, and η is the historical average detour tolerance coefficient. The historical average detour tolerance coefficient η is the median of the detour ratio among all completed orders in the most recent K delivery cycles. It is updated once per delivery cycle. The detour ratio is calculated from the actual driving distance and the shortest path distance between the origin and destination.

[0035] The capacity constraint means that the total weight of all goods in a single order must not exceed the preset weight limit of the single order, and the total volume of goods must not exceed the preset volume limit of the single order.

[0036] The preset weight limit and preset volume limit of the collection unit are threshold parameters set by the system based on the statistical distribution of the carrying capacity of online delivery personnel in a single trip within the historical delivery cycle.

[0037] The time window compatibility constraint is characterized by the fact that the pickup time windows of all orders within the set have a common intersection and are not lower than the preset lower limit of the common intersection of time windows; at the same time, the maximum deviation between the earliest pickup time and the latest pickup time must not exceed the maximum time offset allowed by the system.

[0038] The lower limit of the common intersection of time windows is a fixed duration parameter preset by the system, which represents the shortest duration during which the pickup time windows of all orders in the collection order must overlap. Orders with a duration shorter than this limit cannot be included in the same collection order.

[0039] The maximum time offset is a fixed duration parameter preset by the system, which represents the maximum allowed time span between the earliest and latest pickup times within a single order. Orders exceeding this span cannot be merged into the same order.

[0040] The cargo compatibility constraint is characterized by a mutually exclusive list based on cargo type, meaning that orders that cannot be mixed cannot be combined into the same set of orders.

[0041] Step S4, which involves calculating the historical utility value of the online delivery person, includes:

[0042] Retrieve historical delivery batches and their revenue information from the information of currently online delivery personnel, as well as information on currently accepted but not yet delivered batches.

[0043] The historical delivery aggregated orders and their revenue information include the number of aggregated orders completed within the most recent K delivery cycles. and the actual delivery revenue obtained in the most recent K delivery cycles. ;

[0044] Calculate all online delivery riders on the day in the most recent Number of consolidated orders completed within a delivery cycle The sum of N, where ;

[0045] Calculate the actual delivery revenue earned by all online delivery riders on that day over the most recent K delivery cycles. The sum of E, where: ;

[0046] Calculate the percentage of combined orders per delivery person , where: if ,but: ;like ,but ;

[0047] Calculate the revenue share of a single delivery person , where: if ,but: ;like ,but ;

[0048] Calculate the historical utility value of delivery personnel , is represented as: .

[0049] In step S5, the delivery qualification of the deliveryman is determined based on the historical route information, historical collection order information, estimated order pickup time and single shipment transportation restriction information of the online deliveryman, and the priority order for displaying the collection of pending pickup status to the candidate deliveryman is obtained.

[0050] The process of determining a delivery person's eligibility based on their historical route information, historical batch order information, estimated order pickup time, and single-trip delivery restriction information includes: eligibility based on route, eligibility based on time, and eligibility based on capacity.

[0051] The information on currently received but not yet delivered aggregated orders includes the number of currently received but not yet delivered aggregated orders, the weight of currently received but not yet delivered aggregated orders, and the volume of currently received but not yet delivered aggregated orders;

[0052] The historical route information includes the delivery person's regular home route, and the single cargo transportation restriction information includes the maximum weight and maximum volume that can be carried in a single trip.

[0053] The following are the criteria for determining the eligibility of following the route: determining the cosine similarity between the flow direction vector and the overall flow direction feature vector of the set. If the similarity is greater than or equal to a preset threshold, the eligibility of following the route is satisfied. The flow direction vector is obtained by converting the regular home route of the online deliveryman into a sequence of road network nodes and averaging the embedding vectors of each node to obtain the flow direction vector of the deliveryman's home route. The overall flow direction feature vector of the set is obtained based on a directed attribute road network graph.

[0054] The time eligibility determination includes: if the release time of the collection order in the pending pickup status is earlier than the estimated pickup time of the deliveryman in the online status, then the time eligibility determination is satisfied;

[0055] The capacity eligibility determination includes: the weight and volume of the currently received but not delivered collection orders of the online delivery person, plus the required weight and volume of the collection orders to be picked up, do not exceed the delivery person's maximum single-trip weight and maximum single-trip volume, then the capacity eligibility determination is satisfied.

[0056] The priority order for displaying the set of pending pickup statuses to the candidate delivery personnel includes:

[0057] Based on historical utility values The delivery personnel were ranked according to their online status that day. The smaller the value, the closer the delivery person is to the nearest location. The lower the number of batch orders and delivery revenue obtained within a delivery cycle, the higher the priority order displayed for the delivery person in the batch order display;

[0058] If the historical utility values ​​of the two deliverymen are obtained Similarly, based on the number of accepted but not yet delivered aggregated orders in the current delivery cycle of the delivery person, the orders with smaller numbers are displayed first.

[0059] If the number of currently accepted orders is the same, they will be sorted from morning to night according to the delivery person's estimated pickup time.

[0060] If the expected pickup times are the same, sort them by delivery personnel's terminal ID number from smallest to largest.

[0061] Specifically, step S6, which involves setting the candidate delivery personnel into several display batches for display in different time sequences, includes:

[0062] A collection of data on pending acceptance status Corresponding number of candidate delivery personnel Among them, if If the order j remains in a pending pickup state, the system will not display the order to any delivery personnel. Wait for the customer to raise the price or for a new delivery person to come online before re-executing step S4; if Then, according to the display priority order described in step S5, the candidate delivery personnel set is... The candidate delivery personnel were ranked.

[0063] Calculate a single set Number of display batches ,in: , where ceil represents rounding up;

[0064] Calculate a single set The number of delivery personnel included in each display batch ,in: ;

[0065] The ranked candidate delivery personnel will be arranged according to Divided into the following categories The displayed batches; among them, the first to the second... The delivery personnel with the highest number of names will be prioritized for display in the first batch, and will be ranked [number missing]. Name to the Delivery personnel with the first name are placed into the second display batch, and so on, until all candidate delivery personnel have been placed into a display batch, with batch intervals. Displayed in batches; among them, when the system time reaches the [number]th ... Batch display start time At that time, the assembly form was opened to the p-th batch of delivery personnel. Visibility permissions; if If it has already been received by a previous batch, it will not be displayed to subsequent batches;

[0066] The total duration is prioritized for display and calculated based on the following steps: determining the baseline response duration. If recently If there is a set of single items in the accepted state in each cycle, then This is the arithmetic mean of the response times of the accepted status set of orders, where the response time of the accepted status set of orders is the time elapsed from the first time the order is displayed to the time it is accepted; if it does not exist, then... Calculate the average remaining departure times of the candidate delivery riders, where the earliest remaining departure time is... Display total duration Where r is represented as:

[0067]

[0068] in, This indicates the departure time of the candidate delivery person. m represents the earliest order placement time of the orders in the aforementioned collection. j This represents the total number of candidate delivery personnel.

[0069] Specifically, step S7, which involves assigning the batch of orders in the "pending pickup" state visible to the candidate delivery person to one of the candidate delivery persons and setting the batch of orders in the "pending pickup" state to "pending pickup," enabling the candidate delivery person to deliver all orders in the batch of orders in the "pending pickup" state individually, includes:

[0070] Judging candidate deliverymen When initiating an order acceptance request, the set of pending acceptance statuses is... Is it still in the pending state? If the pending state set is single If the request is not in a pending state, the order will be rejected; if the pending state is a single If the device is in a pending state, then the pending state set will be added to the list. The status changes from pending to accepted, and the set of accepted status items is added to the list. With candidate delivery drivers Bind;

[0071] The set of the already accepted status Removed from the visible list of collection orders of other candidate delivery drivers, so that other delivery drivers can no longer access collection orders that are already accepted. Initiate an order acceptance request;

[0072] According to the collection of the received status Update candidate delivery drivers The formula for the currently received but not yet delivered collection order information is as follows:

[0073] ; ,

[0074] Among them, c i w represents the total number of collection orders received that day. i v represents the total weight of the orders received on that day. i w represents the total volume of the collection orders received on that day. j A collection of single items representing the received status. The weight, v j A collection of single items representing the received status. Volume;

[0075] If multiple delivery personnel simultaneously process the aforementioned collection order... Initiate an order acceptance request and allocate orders according to the order acceptance request received by the server in the order of time to determine the ownership of the collection order; if the system server receives order acceptance requests from different candidate deliverymen at the same time, priority is given to the deliveryman with the lower historical utility value; if different candidate deliverymen have the same historical utility value, priority is given to the deliveryman with the smaller deliveryman terminal ID number.

[0076] In step S8:

[0077] Deliveryman's available price The formula is:

[0078] ;

[0079] in, For collection single The initial quote, To maintain a fixed commission rate, the collection unit The initial quote is a collection order. The sum of the initial quotes for all orders within the scope;

[0080] If the collection is single If the request is already accepted, the collection cannot be increased further. Initial quote for orders within the country;

[0081] If the aggregate order is in a pending state, the initial price of the orders within aggregate order j can be changed to the updated price; at this time, the aggregate order will be processed according to the updated price of the orders within aggregate order j. initial quote Reset to update quote and according to the updated quote And the update time to obtain the updated price for the delivery person. The candidate delivery personnel for the collection order j, and the display priority order and display batch for the collection order j to the candidate delivery personnel;

[0082] The available price of the candidate delivery personnel will be updated based on the display priority and display batch. The information is simultaneously displayed to the candidate delivery personnel;

[0083] Among them, for those who did not initiate a call order before updating the quote If a delivery person who accepts an order is still a candidate delivery person after the price is updated, then that delivery person is allowed to see the set of orders j with the updated price and can initiate an order acceptance request.

[0084] The present invention has the following beneficial effects:

[0085] To address the issues of scattered order distribution and low execution value of individual orders in sparse and differentiated last-mile delivery scenarios in existing technologies, this invention integrates multiple orders into a set of aggregated orders, using this set as the minimum order set for delivery. This increases the value of delivery tasks and consequently improves the probability of delivery personnel accepting orders. Compared to single-order matching tasks, this invention uses the minimum order set for matching, reducing matching response time and improving matching efficiency. However, if the orders in the aggregated order lack correlation or are simply merged based on proximity, problems such as excessive detours can occur, leading to increased delivery difficulty and low efficiency. Therefore, matching efficiency and delivery efficiency present a dilemma. To address this, this invention further proposes an order merging method based on order flow direction feature expression and graph neural network clustering. This method maps order pickup and delivery points to road network nodes, integrates candidate path embeddings and order service attributes to generate a flow direction feature vector for each order, constructs a weighted similarity graph between orders, and then uses graph neural network clustering and order merging rules based on path distance, capacity, time window compatibility, and cargo compatibility to generate candidate aggregated orders that satisfy all business constraints and extracts the overall flow direction features of the aggregated orders. This reduces directional conflicts and unnecessary detours, improves the economy and feasibility of combined orders, enhances delivery personnel's willingness to accept orders from the task generation stage, and achieves the effect of simultaneously ensuring matching efficiency and delivery efficiency.

[0086] Considering the dynamic arrival characteristics of both orders and delivery personnel in low-density scenarios, this invention proposes a three-tiered qualification screening and online order-acceptance locking method for aggregated orders and delivery personnel, based on route proximity, time, and capacity. The system uses aggregated orders as matching units, determining route proximity qualification based on the cosine similarity between the aggregated order's flow vector and the delivery personnel's home route flow vector; determining time qualification based on the aggregated order's posting time and the delivery personnel's expected departure time; and determining capacity qualification based on the delivery personnel's remaining load, volume, and maximum number of packages. This generates a set of candidate delivery personnel, which are then displayed in batches. After a delivery person initiates an order acceptance request, the system performs a secondary qualification verification and performs locking and binding, with the status progressing from pending acceptance to locked and accepted. When a delivery person rejects an order, fails to confirm within the time limit, or the customer increases the price, the system can trigger a reordering of candidate delivery personnel and a re-division of display batches, thereby improving the scheduling scheme's adaptability to real-time changes.

[0087] Considering the characteristics of crowdsourced delivery riders, such as their ability to independently accept and reject orders and their varying preferences, this invention introduces a rider ranking and batch display mechanism based on historical utility values ​​in the matching and scheduling process. It employs a technical solution that uses the average of normalized quantity and revenue proportions as the historical utility value, and divides candidate riders into multiple display batches, granting them access to aggregated orders sequentially at batch intervals. Within their visible aggregated order list, riders independently choose whether to accept orders based on their home route, remaining transportation capacity, and the price of the aggregated order. This ensures that less active riders receive priority display opportunities while preventing high-quality tasks from being concentrated on a small number of riders, thereby increasing the participation enthusiasm of ordinary riders and the stability of the platform's transportation capacity pool.

[0088] In summary, this invention, through the aforementioned substantial technical improvements, forms a complete intelligent scheduling closed loop from order generation to task execution. In low-density wave order scenarios, it significantly improves the quality of aggregated order generation, the probability of delivery personnel accepting orders, task fulfillment efficiency, and the platform's continuous operation capability. It also makes up for the shortcomings of existing crowdsourced delivery platforms in terms of low order-delivery matching efficiency and poor experience under conditions of sparse demand, hub-and-spoke road networks, heterogeneous transportation capacity, and time-varying traffic. Attached Figure Description

[0089] Figure 1 Flowchart of a single-vehicle online real-time intelligent matching method for low-density wave orders.

[0090] Figure 2 A schematic diagram of a single-vehicle online real-time intelligent matching system for low-density, wave-order needs.

[0091] Figure 3 A schematic diagram of the architecture of a single-vehicle online real-time intelligent matching system for low-density wave orders. Detailed Implementation

[0092] To make the technical solutions and advantages of this application clearer, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only for explaining this application and are not intended to limit this application; that is, the described embodiments are only a part of the embodiments of this application, and not all of them. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in different configurations.

[0093] The terms used in this invention are defined as follows:

[0094] Road network topology data: Data describing the structural relationships of the road network, recording road intersections (nodes) and the road segments (edges) connecting each intersection and their connection methods.

[0095] Multidimensional road network adjacency data: Based on the road network topology, road connection relationship data with additional multidimensional information such as distance, travel time, traffic restriction rules, and road level is used to accurately calculate the path.

[0096] Low-density wave orders: These refer to orders that arrive in small quantities and are sparsely distributed within a unit of time. The system processes them in batches according to time, rather than processing each order as it arrives.

[0097] Wave: The system groups accumulated orders over a period of time into a processing batch, which is called a "wave". Each wave triggers one order merging and one order dispatch operation.

[0098] Order flow feature vector: A data structure that uses a set of values ​​to represent the pickup and delivery location, suggested driving route, and direction of movement of an order on the road network; the similarity of the vectors can reflect the degree to which two orders can be combined on the path.

[0099] Weighted similarity graph between orders: Each order is regarded as a node, and the "combinability" between orders is quantified as the weight of the connecting edge. The higher the weight, the more suitable it is to be combined together, which is the input of the subsequent clustering algorithm.

[0100] Graph Neural Network Clustering: An artificial intelligence method that automatically groups data on graph structures. It learns the deep relationships between orders through multi-layer computation, clusters similar orders into one category, and generates a preliminary order merging plan.

[0101] Soft assignment / soft clustering: The clustering result does not rigidly assign each order to a specific set of orders, but rather gives the probability distribution of each set of orders, retaining uncertainty and making it easier to make hard constraint corrections using business rules later.

[0102] Delivery cycle: The time unit for system statistics and settlement, usually one day. At the end of each cycle, the system settles the tasks completed within that cycle and updates the delivery person's historical data for the next cycle's calculation.

[0103] Origin and Destination Points: When a combined order is used as a whole delivery task, the suggested starting node (start) and final delivery node (end) on the road network are determined by merging the pick-up and delivery points of each order within the combined order.

[0104] To address the shortcomings of existing crowdsourced delivery platforms in terms of low order-delivery matching efficiency and poor user experience under conditions of sparse demand, hub-and-spoke road networks, heterogeneous transport capacity, and time-varying traffic, this invention provides an online real-time intelligent matching system and method for "single-vehicle" orders with low-density wave orders. This system enables order demand collection and representation, order clustering and aggregate order generation, delivery driver matching and scheduling, and operation management.

[0105] To achieve the above objectives, the "single-vehicle" online real-time intelligent matching system for low-density wave orders of the present invention includes an information storage module, a communication module, a scheduling and control module, and a terminal interaction module.

[0106] The information storage module contains basic order data, road network topology data, multi-dimensional road network adjacency data, delivery personnel basic data, historical fulfillment data, order consolidation rule base, matching rule base, and feedback record data, providing basic support for system scheduling. The communication module is used for information transmission between the dispatch center and users, delivery personnel, distribution points, and external systems, including order demand information, delivery personnel information and order acceptance status, package handover status, road traffic conditions, and weather risk information. It also uploads real-time data to the dispatch control module and simultaneously sends consolidation tasks, suggested routes, handover requirements, and exception handling instructions to each terminal. The dispatch control module uses the real-time data and information uploaded by the communication module... The pre-stored data in the storage module executes an online real-time intelligent matching method for low-density wave orders, generating order consolidation schemes and delivery personnel matching and scheduling schemes. The matching and scheduling schemes include basic information of the consolidation order, suggested routes for pickup and delivery locations and time windows, delivery personnel information, route and flow suggestions, handover and operation requirements, price and compensation information, etc. The terminal interaction module includes a user client, a delivery personnel mobile terminal, a smart handover terminal at the distribution point, an environmental status collection terminal, and an operation management terminal. It is used to complete order entry, task confirmation, package handover, road environment collection, and system operation monitoring, realizing a closed-loop interaction of the entire process of orders, personnel, packages, and environmental status.

[0107] To address the shortcomings of existing crowdsourced delivery platforms in terms of low order-delivery matching efficiency and poor user experience under conditions of sparse demand, hub-and-spoke road networks, heterogeneous transport capacity, and time-varying traffic, this invention provides an online real-time intelligent matching system and method for "single-vehicle" orders with low-density wave orders. This system enables order demand collection and representation, order clustering and aggregate order generation, delivery driver matching and scheduling, and operation management.

[0108] To achieve the above objectives, the "single-vehicle" online real-time intelligent matching system for low-density wave orders of the present invention includes an information storage module, a communication module, a scheduling and control module, and a terminal interaction module.

[0109] The information storage module contains basic order data, road network topology data, multi-dimensional road network adjacency data, delivery personnel basic data, historical fulfillment data, order consolidation rule base, matching rule base, and feedback record data, providing basic support for system scheduling. The communication module is used for information transmission between the dispatch center and users, delivery personnel, distribution points, and external systems, including order demand information, delivery personnel information and order acceptance status, package handover status, road traffic conditions, and weather risk information. It also uploads real-time data to the dispatch control module and simultaneously sends consolidation tasks, suggested routes, handover requirements, and exception handling instructions to each terminal. The dispatch control module uses the real-time data and information uploaded by the communication module... The pre-stored data in the storage module executes an online real-time intelligent matching method for low-density wave orders, generating order consolidation schemes and delivery personnel matching and scheduling schemes. The matching and scheduling schemes include basic information of the consolidation order, suggested routes for pickup and delivery locations and time windows, delivery personnel information, route and flow suggestions, handover and operation requirements, price and compensation information, etc. The terminal interaction module includes a user client, a delivery personnel mobile terminal, a smart handover terminal at the distribution point, an environmental status collection terminal, and an operation management terminal. It is used to complete order entry, task confirmation, package handover, road environment collection, and system operation monitoring, realizing a closed-loop interaction of the entire process of orders, personnel, packages, and environmental status.

[0110] The operation steps of the "bicycle-to-bicycle" online real-time intelligent matching system are as follows:

[0111] Step 1: Users send their delivery requests as orders to the dispatch center's communication module via their client or an external order system. Order information includes pickup point, delivery point, time window, goods type, weight and volume, customer quote, handover method, and service priority. The system categorizes low-density orders into the current rolling processing wave according to the time window or preset wave rules, and the initial order status is "pending consolidation".

[0112] Step 2: The communication module receives the order information from Step 1 and, for this wave of orders, collects data in real time, including the delivery person's location and order acceptance status, the delivery person's usual home route, the status of package handover at the distribution point, road traffic status, and weather risk information, and uploads it to the dispatch control module.

[0113] Step 3: The information storage module uploads pre-stored and real-time updated road network topology data, multi-dimensional road network adjacency data, candidate path data, delivery personnel basic data, delivery personnel historical performance data, order consolidation rule base, matching rule base, and pre-trained order clustering network model parameters to the scheduling control module.

[0114] Step 4: The dispatch control module receives data from the communication module and information storage module, executes the "order-vehicle" online real-time intelligent matching method, merges low-density wave orders within the current rolling time window according to order flow, and changes the status of the merged orders to "pending pickup." Then, it performs online real-time matching between the merged orders and available delivery personnel. After screening, sorting, and batching strategies, delivery personnel independently accept the orders, and the "order-vehicle" matching and dispatch plan is output. The matching and dispatch plan includes the executing delivery personnel, merged order task confirmation information, pickup and delivery time windows, suggested driving routes, handover requirements, and compensation plans.

[0115] Step 5: The dispatch control module uploads the order merging plan and the "order-vehicle" matching dispatch plan to the communication module and the information storage module, respectively. The communication module sends the merged order task, suggested route, and handover requirements to the deliveryman's mobile terminal, the intelligent handover terminal at the distribution point, and the user client; the information storage module updates the corresponding order, deliveryman, merged order, and matching record information based on task confirmation, order acceptance / rejection, fulfillment status, handover results, and anomaly feedback.

[0116] In some specific embodiments, the online real-time intelligent matching method for single-vehicle vehicles disclosed herein includes:

[0117] Step 1: The system extracts orders with a status of "Pending Consolidation" within the current rolling time window according to preset wave rules, performs consolidation processing based on order flow characteristics and consolidation rules to generate a collection order, extracts the overall flow characteristics of the collection order, and changes the status of the collection order to "Pending Acceptance".

[0118] The order merging process in step 1 includes the following steps:

[0119] Road network attribute graph construction and node embedding loading: The scheduling control module obtains the road network topology, multi-dimensional road network adjacency and real-time traffic dynamics from the information storage module, constructs a directed attribute road network graph, and directly loads the pre-trained road network node embedding vectors in the information storage module, providing a structured road network representation basis for order flow expression.

[0120] Order flow feature representation and similarity graph construction: The scheduling control module extracts all orders with the status of "pending order merging" in the current rolling wave, maps the pick-up and delivery points to road network nodes, integrates the candidate paths of the information storage module with the service attributes of the order itself, generates the flow feature vector of each order, and uses it to construct a weighted similarity graph between orders to quantify the degree of order merging in terms of path and service.

[0121] Graph Neural Network Clustering Generates Soft Assignment: The scheduling and control module loads the pre-trained graph neural network clustering model and its parameters from the information storage module, inputs the order similarity graph into the model, and outputs the probability distribution of each order belonging to each cluster through multi-layer graph attention convolution and differentiable clustering assignment layers, forming the initial soft clustering result.

[0122] Order merging rule correction based on order flow: The scheduling control module loads the order merging rule library based on order flow in the information storage module, performs hard constraint checks on the soft clustering results, eliminates illegal allocations and redirects affected orders to legal clusters, and generates candidate set order partitioning that meets all business constraints.

[0123] Order consolidation scheme generation and output: For each candidate consolidation order, the scheduling control module summarizes the order information, estimated time window and total customer quotation within the consolidation order, and generates the overall flow characteristics of the consolidation order based on the order flow feature vector fusion, forming a structured consolidation scheme. The status of the consolidation order is changed to "pending pickup", and uploaded to the communication module and information storage module to support subsequent delivery person matching and task issuance.

[0124] Table 1 shows an example of a single data set.

[0125]

[0126] The order merging rule base based on order flow, as described in the order merging method, includes the following rules:

[0127] Path distance constraint: The shortest path distance between the start and end points of any two orders within a combined order must not exceed the maximum combined order distance threshold set by the system. This threshold is determined based on the delivery radius and the delivery person's historical fulfillment data.

[0128] Capacity constraints: The total weight and volume of goods in all orders within a combined order must not exceed the system's preset combined order capacity limit. This limit is set based on the typical transportation capacity of the delivery personnel group, providing a preliminary screening for the specific delivery personnel capacity verification in the subsequent matching stage.

[0129] Time window compatibility constraint: The pickup time windows of all orders within the collection order must have a common intersection, and the duration of this intersection must not be lower than the preset lower limit; at the same time, the maximum deviation between the earliest pickup time and the latest pickup time must not exceed the maximum time offset allowed by the system.

[0130] Goods compatibility constraints: Based on a list of mutually exclusive goods types, orders that cannot be mixed due to safety or regulatory requirements are prohibited from being included in the same order. For example, food cannot be ordered with chemicals, while documents and electronic products can be mixed. Specific compatibility lists are maintained in the rule base.

[0131] Step 2: Add all pending delivery order information to the pending delivery order pool for the day. The order information includes pickup location, delivery area, delivery address, package weight, package volume, number of packages, customer's initial quote, order publication time, order status, and overall order flow characteristics.

[0132] Step 3: Obtain information on part-time delivery personnel who are online on the current day. The delivery personnel information includes the delivery personnel's terminal ID number, residential area, type of transportation vehicle, maximum number of items that can be carried in a single trip, maximum weight that can be carried in a single trip, maximum volume that can be carried in a single trip, regular home route, estimated order pickup time, number of currently accepted collection orders, total weight of currently accepted collection orders, and total volume of currently accepted collection orders.

[0133] Step 4: Based on the most recent The historical order-taking results of each part-time delivery person within a delivery cycle are used to calculate the historical utility value of each online delivery person, and the priority order for displaying aggregated orders for each part-time delivery person is determined based on the historical utility value; among which, The number of historical delivery cycles that the system can set is determined by the delivery personnel. The lower the historical utility value of a delivery person, the higher the priority of the aggregated orders will be displayed.

[0134] The method for calculating the historical utility value of each online delivery person and determining the priority order for displaying aggregated orders, as described in step 4, includes the following steps:

[0135] Statistics on delivery personnel In recent Number of consolidated orders completed within a delivery cycle and delivery personnel In recent Actual delivery revenue obtained within each delivery cycle .

[0136] Calculate all online delivery riders on the day in the most recent The total number of batch orders completed within a delivery cycle, N, is given by: , where i iterates through all online delivery drivers for the day.

[0137] Calculate the total actual delivery revenue E earned by all online delivery riders on that day over the most recent K delivery cycles, where: ,in It iterates through all online delivery drivers for the day.

[0138] Calculate the percentage of orders collected by delivery person i. ;like ,but: ;like ,but: .

[0139] Calculate delivery personnel Revenue share ;like ,but: ;like ,but: .

[0140] Calculate the historical utility value of delivery person i ,in: .

[0141] According to historical utility values The online delivery personnel for the day are sorted in ascending order of their number. The smaller the value, the more recent the delivery person has been. The lower the number of aggregated orders and delivery revenue obtained within a delivery cycle, the higher the priority of the aggregated orders will be in the display order.

[0142] If the historical utility values ​​of the two deliverymen If the numbers are the same, sort them by the number of collection orders received in the current delivery cycle from smallest to largest; if the number of collection orders received is still the same, sort them by their expected pickup time from earliest to latest; if the expected pickup time is still the same, sort them by the delivery person's terminal ID number from smallest to largest.

[0143] Step 5: The system will check the "pending pickup" status of the collection orders in the daily delivery collection order pool against the online delivery personnel of the day for eligibility based on route, time, and capacity. When a single delivery person meets all the eligibility criteria, the system will push the collection order to the delivery person's terminal and generate a set of candidate delivery personnel for each collection order. For delivery personnel who do not meet any of the eligibility criteria, the system will not show them the corresponding collection order.

[0144] The method for generating the candidate delivery person set corresponding to each collection order in step 5 includes the following steps:

[0145] For pending collection orders Read the collection single The receiving area and the weight of the package Package volume Number of packages and the release time of the collection order and the overall flow direction feature vector of the set .

[0146] For the online delivery personnel of that day Read delivery personnel regular route Expected pickup time Maximum number of items allowed per trip Maximum weight allowed per trip Maximum carry-on volume per trip Number of currently accepted collection orders Total weight of currently received collection orders and the total volume of currently received collection orders. .

[0147] delivery personnel regular route Convert the sequence into a road network node sequence, and average the embedding vectors of each node in the sequence to obtain the delivery person's home route flow vector. ;calculate With collection single Flow direction feature vector The cosine similarity between them; if the similarity is greater than or equal to the system-set route similarity threshold, then the delivery person... The candidate must meet the "on the way" requirement; otherwise, the candidate must not.

[0148] Determine the current time Earlier than the delivery person Estimated pickup time ;like Then the deliveryman If the time eligibility is met; Then the deliveryman The time requirement is not met.

[0149] Determine whether delivery person i meets the transportation capacity limit after accepting the collection order j, and verify whether the remaining weight and volume of the delivery person meets the requirements of the collection order; if both are met, then the delivery person... The delivery person must meet the capacity requirements; if either the weight or volume requirements mentioned above are not met, the delivery person must... The capacity requirement is not met.

[0150] If the delivery person If the delivery person meets the requirements of being on the way, meeting the time requirement, and meeting the capacity requirement, then the delivery person will be... Add to collection list Collection of candidate delivery drivers Otherwise, the delivery person will not be included. Add to collection list Collection of candidate delivery drivers .

[0151] For each pending collection order, the system divides the candidate delivery personnel into several display batches according to the priority order of the collection orders displayed, and grants the delivery personnel the visibility permission of the collection order in the order of the batches; among them, the delivery personnel in the previous display batch see the collection order first, and the delivery personnel in the next display batch see the collection order after the corresponding batch interval.

[0152] Step 6, which describes the method for demonstrating batch division and batch interval calculation for candidate delivery personnel, includes the following steps:

[0153] Statistical collection unit Corresponding candidate delivery personnel set Number of delivery personnel .

[0154] like If the order j remains in the "pending pickup" state, the system will not show the order to any delivery person and will wait for the customer to raise the price or for a new delivery person to come online before re-executing step 4.

[0155] like Then, based on the priority order of the set of orders calculated in step 3, the candidate delivery personnel set will be displayed. The delivery personnel are sorted, with those having lower historical utility values ​​ranked higher.

[0156] Calculate a single set Number of display batches ,in: , where ceil means rounding up.

[0157] Calculate a single set The number of delivery personnel included in each display batch ,in: .

[0158] The ranked candidate delivery personnel will be arranged according to Divided into the following categories One display batch; among them, the first to the second... The delivery personnel named [name] are included in the first display batch, and are ranked [number]. Name to the Delivery personnel with the highest number of candidates will be included in the second display batch, and so on, until all candidate delivery personnel have been included in the display batch.

[0159] Calculate the most recent Average response time for all accepted batch orders within a delivery cycle The response time for each accepted order is equal to the time the order was accepted minus the time the order was first displayed. This is the arithmetic mean of all response times.

[0160] If recently If there are no accepted collection orders within a delivery cycle, then the collection order is calculated. Average remaining departure time for the corresponding candidate delivery riders ,in: ,in Traversing a collection Collection of candidate delivery drivers .

[0161] Calculate a single set Earliest remaining departure time among the corresponding candidate delivery personnel ,in: ,in Traversing a collection Collection of candidate delivery drivers .

[0162] Calculate a single set Total time of priority display ,in: .

[0163] Calculate a single set Display batch interval ,in: .

[0164] No. Visible start time of each display batch Calculate as follows: ,in To display the batch number, from Start counting.

[0165] When the current time reaches At that time, the system sent to the first Display batch of delivery personnel open collection forms Visibility permissions; if the collection is single If a package has already been picked up by a delivery person in the previous batch, the system will not show the package to delivery people in the next batch.

[0166] Step 7: The delivery person can choose whether to initiate an order acceptance request based on their own route, remaining transportation capacity and order price in the visible collection order list on their mobile terminal; after receiving the order acceptance request, the system will execute the collection order locking and allocation process.

[0167] The set locking and allocation process method described in step 7 includes the following steps:

[0168] Judging deliverymen When initiating an order request, the collection order Is it still in the "pending receipt" state? If the collection order... If the order is not in the "pending acceptance" state, the system will reject the order acceptance request.

[0169] If the collection is single If the order is still in the "pending pickup" state, the system will reassess the delivery person. Does the collection of single items meet the requirements? The system requires the system to assess the applicant's eligibility based on their route, time, and capacity; if any of these eligibility criteria are not met, the system will reject the order request.

[0170] If the delivery person Still meets the requirements of the collection single The system will combine the eligibility for being on the way, the eligibility for time, and the eligibility for capacity. The status changed from "pending" to "accepted", and the collection order was changed. With delivery personnel Bind.

[0171] The system will collect single Remove it from the list of visible collection orders for other delivery drivers, so that other delivery drivers can no longer accept the collection order.

[0172] System update delivery personnel The current number of accepted collection orders, the total weight of currently accepted collection orders, and the total volume of currently accepted collection orders, where: ; ; .

[0173] If multiple delivery personnel simultaneously process the combined order When an order request is initiated, the order allocation is determined by the order time the system server receives the request; if the server receives the request at the same time, it is assigned to the historical utility value first. Lower-ranking delivery drivers; if historical utility values ​​are still the same, priority is given to delivery drivers with lower driver IDs.

[0174] Step 8: If a customer increases the price before the delivery person locks the order, the system will recalculate the delivery person's available price for the order based on the increased price, and recalculate the candidate delivery person ranking, display batch, and batch interval for the order. For orders that have already been locked, customers cannot change the delivery person's available price by increasing the price.

[0175] The method for updating customer quotes and calculating prices available to delivery personnel, as described in step 8, includes the following steps:

[0176] Customer publishes collection order Fill in the initial quote you are willing to pay. The platform charges a fixed commission rate. Calculate the price that the delivery driver can get. ,in: .

[0177] If the collection is single If the quote is in the "pending" state, the customer can submit the quote. Increase to a new quote If the set is single If the order is already in the "accepted" status, the customer cannot increase the price of the order.

[0178] When the customer gives a quote Upgraded to Afterwards, the platform recalculated the price that the delivery driver could earn. ,in: .

[0179] The system will collect single Price version number plus and will The collection list is displayed synchronously to those who can currently see it. The deliveryman.

[0180] The system uses the price increase time as the new calculation time, re-executes steps 4 and 5, and regenerates the set list. The collection, display batches, and batch intervals of candidate delivery personnel.

[0181] For those who have already refused the group order before the price increase If a delivery driver still meets the eligibility criteria for route, time, and capacity after the price increase, the system will allow the delivery driver to see and accept the collection order again under the new price version.

[0182] Step 9: After the delivery cycle ends, the system settles all collection orders with a status of "accepted" and delivery confirmation completed, and writes the number of collection orders completed and the actual income earned by each delivery person in the current delivery cycle into the historical order acceptance results for use in the calculation of historical utility value for the next delivery cycle.

[0183] The historical utility update method described in step 9 after the delivery cycle ends includes the following steps:

[0184] At the end of each delivery cycle, the system counts the number of confirmed delivery orders completed by each delivery person within the current delivery cycle.

[0185] The system calculates the actual delivery revenue earned by each delivery person in the current delivery cycle, where the actual delivery revenue for each batch of orders is equal to the price that the delivery person can earn for that batch of orders.

[0186] The system will write the number of collection orders completed by each delivery person and the actual delivery revenue in the historical order results table within the current delivery cycle.

[0187] The system reads the most recent data at the start of the next delivery cycle. Historical order results within a delivery cycle, and follow the steps. Recalculate the historical utility value for each online delivery person.

[0188] If a delivery person recently If a delivery person completes fewer batch orders and generates lower actual delivery revenue within a delivery cycle, their historical utility value decreases, and they will receive a higher priority in the display of batch orders in the next delivery cycle. If a delivery person has a low number of completed batch orders and low actual delivery revenue in the most recent delivery cycle, their historical utility value will decrease, and they will receive a higher priority in the display of batch orders in the next delivery cycle. If a large number of aggregated orders are completed or the actual delivery revenue is high within a delivery cycle, its historical utility value will increase, and it will be placed in a relatively later display batch in the next delivery cycle.

[0189] This invention primarily addresses the issue of balancing order allocation between individual orders and delivery personnel in on-demand logistics scenarios. Its scheduling object remains independent orders, without involving order aggregation or aggregated order generation strategies. In scenarios where demand is dispersed and the value of individual order deliveries is low, simply allocating single orders is insufficient to improve task revenue density and can easily lead to insufficient willingness among delivery personnel to accept orders.

[0190] This invention uses the order pickup address or user address as the center, selects nearby delivery personnel according to a preset radius, and then calculates the delivery cost. This method assumes that spatial proximity represents delivery convenience, but in scenarios with complex road structures, obvious main and branch roads, large local detours, or limited transportation, geographical proximity does not necessarily equate to strong route accessibility, which can easily lead to inaccurate selection of candidate delivery personnel.

[0191] While this invention aims to alleviate the problem of uneven order distribution among delivery personnel by calculating a balanced allocation based on the target and actual order volume, its focus remains on the fairness of order allocation. It fails to adequately consider factors such as delivery personnel's carrying capacity, differences in task pricing, service area preferences, tolerance for detours, and order-accepting behavior patterns. Therefore, this method can determine "who is more balanced to assign to," but it struggles to determine "whether the delivery personnel are truly suitable and willing to perform the task."

[0192] The dispatching process of this invention mainly relies on order information, real-time location of delivery personnel, and historical order volume data, lacking systematic collection and feedback of data on the handover status of distribution points, vehicle status, changes in road conditions, and abnormal events. When road risks, handover anomalies, vehicle load limitations, or delivery personnel refusing orders occur during the delivery process, the original method lacks a closed-loop scheduling mechanism for task reconfiguration and online rematching.

[0193] This invention addresses the problem of scattered order distribution and low execution value of individual orders in sparse and differentiated last-mile delivery scenarios. The invention first solves the problem of how to generate executable set orders based on the dominant flow direction and path reachability of orders before dispatching them, thereby improving the task value density and the probability of delivery personnel accepting orders.

[0194] This invention addresses the issue that geographical proximity in complex road networks cannot guarantee low transportation costs and high accessibility. It aims to solve the problem of how to transform factors such as static road attributes, real-time traffic conditions, and weather risk factors into computable path edge weights and dynamic features based on directed attribute road network maps and pre-trained node embedding vectors, thereby providing a reliable basis for generating set orders and matching delivery personnel.

[0195] This invention takes into account the characteristics of crowdsourced delivery personnel, such as independent order acceptance, differences in preferences, and unstable transportation capacity. This invention aims to solve the problem of how to integrate the delivery personnel's historical completed quantity, actual income, regular routes, remaining transportation capacity, and expected departure time to establish a matching mechanism based on the ranking and batch display of historical utility values, so as to balance the fairness of order acceptance opportunities and the efficiency of task fulfillment, thereby improving the matching success rate and the platform's transportation capacity retention capacity.

[0196] This invention takes into account the dynamic nature of the delivery task execution process. It further aims to solve how to transmit task status in real time through customer mobile terminals, delivery personnel mobile terminals, intelligent handover terminals at distribution points, and environmental status collection terminals, and update order merging rule parameters, path edge weights, and matching priorities based on order acceptance, order rejection, fulfillment timeliness, detour distance, and abnormal events, thereby achieving continuous improvement of the crowdsourced delivery scheduling scheme.

[0197] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A single-vehicle online real-time intelligent matching method for low-density wave orders, characterized in that, Includes the following steps: S1: Obtain orders with a status of "pending order" within the current rolling time window according to the preset wave rules, perform order merging processing based on order flow characteristics to generate a collection order, set the status of the collection order to "pending pickup", and calculate the delivery price based on the collection order; S2: Add the collection order in the pending pickup status to the collection order pool to be delivered; S3: Obtain online delivery personnel information, which includes historical delivery batch orders and their revenue information, historical route information, historical batch order cargo information, estimated order pickup time, single cargo transportation restriction information, and currently accepted but not yet delivered batch order information; S4: Calculate the historical utility value of the online delivery personnel based on the collection of historical delivery orders and their revenue information within the most recent K delivery cycles. S5: For the collection orders in the pool of orders to be delivered, the delivery qualification of the delivery personnel is determined based on the historical route information, historical collection order cargo information, estimated order pickup time and single cargo transportation restriction information of the online delivery personnel. Among them, those who meet the delivery qualification are candidate delivery personnel. Based on the historical utility value, obtain the display priority order of the collection orders with the pending pickup status to the candidate delivery person; S6: According to the display priority order, the candidate deliverymen are set into several display batches for display in different time sequences. The visibility permissions of the candidate deliverymen for the collection orders in the waiting-to-pickup state are set according to the display batches, so that the candidate deliverymen can see the collection orders in the waiting-to-pickup state and the delivery price in time sequence. S7: The candidate deliveryman can initiate an order acceptance request for the collection of orders that are visible to him / her and are pending pickup. According to the order order of the candidate deliveryman, the collection of orders that are visible to him / her and are pending pickup are allocated, and the allocated candidate deliveryman is unique. Then, the collection order in the pending state is set to accepted, so that the assigned candidate delivery person can deliver all the orders in the assigned collection order individually.

2. The method according to claim 1, characterized in that, Also includes: S8: For the collection order in the pending collection status, if the quotation is updated before the collection order is assigned, the delivery price is recalculated based on the updated quotation, and steps S3-S7 are executed; for collection orders in the collection status, the quotation cannot be updated. S9: After the delivery cycle ends, settle the collection orders that have been picked up and completed, and update the delivery person's historical collection orders and their revenue information for use in calculating the historical utility value of the next delivery cycle.

3. The method according to claim 1, characterized in that, in, The preset wave rule in step S1 is used to control the dynamic generation of waves and the determination of the rolling time window. The preset wave rule includes the basic time slice granularity Δt, the order quantity threshold N, and the maximum waiting time T. max ; The basic time slice granularity Δt is a fixed period for the system to review the wave triggering conditions. The system periodically checks whether the triggering conditions for starting the next wave are met at intervals of basic time slice granularity Δt. The order quantity threshold N is the lower limit of the cumulative number of pending order statuses required to trigger the generation of a new wave; The maximum waiting time T max It is the maximum allowed time for an order to remain in the queue, set as an integer multiple of the base time slice granularity Δt; The triggering condition for the dynamic generation of the wave is a logical OR operation of a quantity condition and a time condition. The quantity condition is that the currently accumulated number of pending orders reaches the order quantity threshold N; the time condition is that the waiting time since the end of the previous wave reaches the maximum waiting time T. max ; The rolling time window is the time period from the end of the previous wave generation time to the current triggering of the new wave generation time, used to determine the time interval of the current set of orders to be processed.

4. The method according to claim 1, characterized in that, in, The process in step S1 that generates a collection list includes: Construct a directed attribute road network graph and load pre-trained road network node embedding vectors; The order pickup and delivery points are mapped to the road network nodes to generate order flow feature vectors. With orders as nodes and the cosine similarity of the flow feature vectors as edge weights, a weighted similarity graph between orders is constructed to quantify the degree to which orders can be combined in terms of path and service. The weighted similarity graph is input into a pre-trained graph neural network clustering model. Through multiple layers of graph attention convolution and differentiable clustering assignment layers, the probability distribution of each order belonging to each cluster is output, forming the initial soft clustering result. Hard constraint checks are performed on the soft clustering results based on the set single rule base, illegal assignments are eliminated, and affected orders are redirected to legal clusters to generate candidate set singles that satisfy all rule constraints in the set single rule base; Based on the order flow feature vector, the overall flow feature of the aggregated order is fused to form a structured order merging scheme. The status of the aggregated order is changed to pending pickup for subsequent delivery person matching and task assignment.

5. The method according to claim 4, characterized in that, The set of single rule bases includes path distance constraints, transport capacity constraints, time window compatibility constraints, and cargo compatibility constraints; The path distance constraint satisfies the formula: D max =R×(1+n), Among them, D max R is the maximum path distance, R is the baseline delivery radius, and η is the historical average detour tolerance coefficient. The historical average detour tolerance coefficient η is the median of the detour ratio among all completed orders in the most recent K delivery cycles. It is updated once per delivery cycle. The detour ratio is calculated from the actual driving distance and the shortest path distance between the origin and destination. The capacity constraint means that the total weight of all goods in a single order must not exceed the preset weight limit of the single order, and the total volume of goods must not exceed the preset volume limit of the single order. The preset weight limit and preset volume limit of the collection unit are threshold parameters set by the system based on the statistical distribution of the carrying capacity of online delivery personnel in a single trip within the historical delivery cycle. The time window compatibility constraint is characterized by the fact that the pickup time windows of all orders within the set have a common intersection and are not lower than the preset lower limit of the common intersection of time windows; at the same time, the maximum deviation between the earliest pickup time and the latest pickup time must not exceed the maximum time offset allowed by the system. The lower limit of the common intersection of time windows is a fixed duration parameter preset by the system, which represents the shortest duration during which the pickup time windows of all orders in the collection order must overlap. Orders with a duration shorter than this limit cannot be included in the same collection order. The maximum time offset is a fixed duration parameter preset by the system, which represents the maximum allowed time span between the earliest and latest pickup times within a single order. Orders exceeding this span cannot be merged into the same order. The cargo compatibility constraint is characterized by a mutually exclusive list based on cargo type, meaning that orders that cannot be mixed cannot be combined into the same set of orders.

6. The method according to claim 1, characterized in that, in, Step S4, calculating the historical utility value of the online delivery person, includes: Retrieve historical delivery batches and their revenue information from the information of currently online delivery personnel, as well as information on currently accepted but not yet delivered batches. The historical delivery aggregated orders and their revenue information include the number of aggregated orders completed within the most recent K delivery cycles. and the actual delivery revenue obtained in the most recent K delivery cycles. ; Calculate all online delivery riders on the day in the most recent Number of consolidated orders completed within a delivery cycle The sum of N, where ; Calculate the actual delivery revenue earned by all online delivery riders on that day over the most recent K delivery cycles. The sum of E, where: ; Calculate the percentage of combined orders per delivery person , where: if ,but: ;like ,but ; Calculate the revenue share of a single delivery person , where: if ,but: ;like ,but ; Calculate the historical utility value of delivery personnel , is represented as: .

7. The method according to claim 1, characterized in that, in, In step S5, the delivery qualification of the deliveryman is determined based on the historical route information, historical collection order information, estimated pickup time and single shipment transportation restriction information of the online deliveryman, and the priority order for displaying the collection of pending pickup status to the candidate deliveryman is obtained. The process of determining a delivery person's eligibility based on their historical route information, historical batch order information, estimated order pickup time, and single-trip delivery restriction information includes: eligibility based on route, eligibility based on time, and eligibility based on capacity. The information on currently received but not yet delivered aggregated orders includes the number of currently received but not yet delivered aggregated orders, the weight of currently received but not yet delivered aggregated orders, and the volume of currently received but not yet delivered aggregated orders; The historical route information includes the delivery person's regular home route, and the single cargo transportation restriction information includes the maximum weight and maximum volume that can be carried in a single trip. The following are the criteria for determining the eligibility of following the route: determining the cosine similarity between the flow direction vector and the overall flow direction feature vector of the set. If the similarity is greater than or equal to a preset threshold, the eligibility of following the route is satisfied. The flow direction vector is obtained by converting the regular home route of the online deliveryman into a sequence of road network nodes and averaging the embedding vectors of each node to obtain the flow direction vector of the deliveryman's home route. The overall flow direction feature vector of the set is obtained based on a directed attribute road network graph. The time eligibility determination includes: if the release time of the collection order in the pending pickup status is earlier than the estimated pickup time of the deliveryman in the online status, then the time eligibility determination is satisfied; The capacity eligibility determination includes: the weight and volume of the currently received but not delivered collection orders of the online delivery person, plus the required weight and volume of the collection orders to be picked up, do not exceed the delivery person's maximum single-trip weight and maximum single-trip volume, then the capacity eligibility determination is satisfied. The priority order for displaying the set of pending pickup statuses to the candidate delivery personnel includes: Based on historical utility values The delivery personnel were ranked according to their online status that day. The smaller the value, the closer the delivery person is to the nearest location. The lower the number of batch orders and delivery revenue obtained within a delivery cycle, the higher the priority order displayed for the delivery person in the batch order display; If the historical utility values ​​of the two deliverymen are obtained Similarly, based on the number of accepted but not yet delivered aggregated orders in the current delivery cycle of the delivery person, the orders with smaller numbers are displayed first. If the number of currently accepted orders is the same, they will be sorted from morning to night according to the delivery person's estimated pickup time. If the expected pickup times are the same, sort them by delivery personnel's terminal ID number from smallest to largest.

8. The method according to claim 1, characterized in that, Step S6, which involves setting the candidate delivery personnel into several display batches for display in different time sequences, includes: A collection of data on pending acceptance status Corresponding number of candidate delivery personnel Among them, if If the order j remains in a pending pickup state, the system will not display the order to any delivery personnel. Wait for the customer to raise the price or for a new delivery person to come online before re-executing step S4; if Then, according to the display priority order described in step S5, the candidate delivery personnel set is... The candidate delivery personnel were ranked. Calculate a single set Number of display batches ,in: , where ceil represents rounding up; Calculate a single set The number of delivery personnel included in each display batch ,in: ; The ranked candidate delivery personnel will be arranged according to Divided into the following categories The displayed batches; among them, the first to the second... The delivery personnel with the highest number of names will be prioritized for display in the first batch, and will be ranked [number missing]. Name to the Delivery personnel with the first name are placed into the second display batch, and so on, until all candidate delivery personnel have been placed into a display batch, with batch intervals. Displayed in batches; among them, when the system time reaches the [number]th ... Batch display start time At that time, the assembly form was opened to the p-th batch of delivery personnel. Visibility permissions; if If it has already been received by a previous batch, it will not be displayed to subsequent batches; The interval between the first and second display batches is calculated based on the following steps: determining the baseline response time. If recently If there is a set of single items in the accepted state in each cycle, then This is the arithmetic mean of the response times of the accepted status set of orders, where the response time of the accepted status set of orders is the time elapsed from the first time the order is displayed to the time it is accepted; if it does not exist, then... Calculate the average remaining departure times of the candidate delivery riders, where the earliest remaining departure time is... The display batch interval time Where r is represented as: in, This indicates the departure time of the candidate delivery person. m represents the earliest order placement time of the orders in the aforementioned collection. j This represents the total number of candidate delivery personnel.

9. The method according to claim 1, characterized in that, Step S7, which involves assigning the batch of orders in the "pending pickup" state visible to the candidate delivery person to one of the candidate delivery persons and setting the batch of orders in the "pending pickup" state to "pickup" so that the candidate delivery person can deliver all orders in the batch of orders in the "pickup" state individually, includes: Judging candidate deliverymen When initiating an order acceptance request, the set of pending acceptance statuses is... Is it still in the pending state? If the pending state set is single If the request is not in a pending state, the order will be rejected; if the pending state is a single If the device is in a pending state, then the pending state set will be added to the list. The status changes from pending to accepted, and the set of accepted status items is added to the list. With candidate delivery drivers Bind; The set of the already accepted status Removed from the visible list of collection orders of other candidate delivery drivers, so that other delivery drivers can no longer access collection orders that are already accepted. Initiate an order acceptance request; According to the collection of the received status Update candidate delivery drivers The formula for the currently received but not yet delivered collection order information is as follows: ； , Among them, c i w represents the total number of collection orders received that day. i v represents the total weight of the orders received on that day. i w represents the total volume of the collection orders received on that day. j A collection of single items representing the received status. The weight, v j A collection of single items representing the received status. Volume; If multiple delivery personnel simultaneously process the aforementioned collection order... Initiate an order acceptance request and allocate orders according to the order acceptance request received by the server in the order of time to determine the ownership of the collection order; if the system server receives order acceptance requests from different candidate deliverymen at the same time, priority is given to the deliveryman with the lower historical utility value; if different candidate deliverymen have the same historical utility value, priority is given to the deliveryman with the smaller deliveryman terminal ID number.

10. The method according to claim 2, characterized in that, In step S8: Deliveryman's available price The formula is: ； in, For collection single The initial quote, To maintain a fixed commission rate, the collection unit The initial quote is a collection order. The sum of the initial quotes for all orders within the scope; If the collection is single If the request is already accepted, the collection cannot be increased further. Initial quote for orders within the country; If the aggregate order is in a pending state, the initial price of the orders within aggregate order j can be changed to the updated price; at this time, the aggregate order will be processed according to the updated price of the orders within aggregate order j. initial quote Reset to update quote and according to the updated quote And the update time to obtain the updated price for the delivery person. The candidate delivery personnel for the collection order j, and the display priority order and display batch for the collection order j to the candidate delivery personnel; The available price of the candidate delivery personnel will be updated based on the display priority and display batch. The information is simultaneously displayed to the candidate delivery personnel; Among them, for those who did not initiate a call order before updating the quote If a delivery person who accepts an order is still a candidate delivery person after the price is updated, then that delivery person is allowed to see the set of orders j with the updated price and can initiate an order acceptance request.

Images