A logistics path planning method and system based on collaborative distribution

Abstract

The application relates to the fields of logistics information technology and intelligent path planning technology, and particularly discloses a logistics path planning method and system based on cooperative distribution, which comprises the following steps: obtaining multi-agent distribution original data, obtaining a cooperative distribution record set through subject normalization and permission marking; performing order exchangeability analysis on the cooperative distribution record set to obtain an order exchangeability result; constructing a candidate handover network, and obtaining a stable handover node set through cooperative handover stability index evaluation and screening; performing order cooperation grouping on the stable handover node set and the order exchangeability result to obtain a cooperative distribution task cluster; performing joint path planning on the task cluster to obtain an initial path, and then obtaining an executable path result through path freezing and dynamic re-planning. The application realizes handover scheme stability pre-screening, goods risk control, subject income balance and local re-planning under dynamic disturbance without exposing original data of the subjects, and improves the fulfillment success rate of cooperative distribution.

Description

Technical Field

[0001] This invention relates to the fields of logistics information technology and intelligent route planning technology, specifically to a logistics route planning method and system based on collaborative delivery. Background Technology

[0002] Currently, with the rapid development of new retail and instant logistics, urban logistics and delivery are characterized by fragmented orders, high timeliness requirements, and diversified participating entities (such as forward warehouses, convenience stores, couriers, riders, and smart parcel lockers). In the context of last-mile collaborative delivery, a mainstream route planning method abstracts this problem into a vehicle route planning problem with time windows. A typical approach involves aggregating order addresses, delivery time limits, vehicle capacity, and delivery rider locations from different platforms, and then using heuristic algorithms such as clustering, nearest neighbor matching, genetic algorithms, and ant colony optimization to centrally optimize the merged order set, ultimately outputting the travel order and estimated arrival time of each transportation unit. This type of method aims to reduce total travel distance and delivery costs by merging orders.

[0003] However, the existing route planning methods mentioned above face severe challenges when applied to urban instant retail and last-mile delivery scenarios. In this scenario, the orders, capacity, handover point status, and data sharing permissions of different delivery entities are all highly dynamic. Existing solutions typically assume that orders can be successfully merged, handover points are always available, and the capacity of each entity can arrive synchronously according to plan. However, in practice, due to fluctuations in rider arrival times, insufficient smart locker capacity, differences in courier work rhythms, and the stringent time and temperature requirements of fresh produce and medicines, many theoretically optimal routes frequently fail in actual execution, manifesting as handover failures, damaged goods, or entities refusing to execute. At the same time, most existing methods take the shortest distance, shortest time, or highest vehicle utilization rate as a single optimization objective, failing to organically integrate constraints such as the risk of goods status, the acceptability of collaborative entity benefits, and data sharing boundaries into the route planning decision, resulting in poor stability and low executability of the generated collaborative solutions.

[0004] Therefore, how to generate collaborative delivery route solutions that are not only highly efficient in terms of route, but also stable in terms of handover, controllable in terms of cargo risk, balanced in terms of benefits for all parties, and flexible in responding to dynamic disturbances, without fully exposing the core data of each party, has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0005] The purpose of this invention is to provide a logistics route planning method and system based on collaborative delivery, so as to solve the technical problem that the collaborative delivery scheme generated by the existing route planning method in the scenario of dynamic co-delivery by multiple entities has poor actual executability and is prone to frequent failure.

[0006] The objective of this invention can be achieved through the following technical solutions:

[0007] The first aspect of this invention provides a logistics route planning method based on collaborative delivery, comprising the following steps:

[0008] Obtain raw delivery data from multiple entities to obtain a collaborative delivery dataset; perform entity normalization and permission marking on the collaborative delivery dataset to obtain a collaborative delivery record set;

[0009] Perform order exchangeability parsing on the collaborative delivery record set to obtain the order exchangeability results;

[0010] Based on the exchangeable order results, a candidate handover network is constructed by combining the handover point data, and the candidate handover network is evaluated and screened for collaborative handover stability to obtain a set of stable handover nodes;

[0011] The stable set of handover nodes and the order exchangeable results are grouped together to obtain a collaborative delivery task cluster;

[0012] Perform joint path planning on the collaborative delivery task cluster to obtain the initial collaborative delivery path results;

[0013] The initial collaborative delivery path results are frozen and dynamically replanned to obtain an executable collaborative delivery path result.

[0014] Optionally, in a first implementation of the first aspect of the present invention, subject normalization and permission marking are performed on the collaborative delivery dataset to obtain a collaborative delivery record set, including:

[0015] The collaborative delivery dataset is mapped to fields and unified with entities to obtain a normalized intermediate dataset;

[0016] A shareable level label is attached to each field of the normalized intermediate dataset to obtain a collaborative delivery record set; the shareable level label includes public fields, collaborative computing fields, and non-shareable fields.

[0017] Optionally, in a second implementation of the first aspect of the present invention, performing order exchangeability parsing on the collaborative delivery record set to obtain order exchangeability results includes:

[0018] Based on the collaborative delivery record set, the earliest pickup time, latest delivery time, estimated service duration, and safety buffer time for each order are extracted to determine the exchangeable time period;

[0019] Extract the pickup and delivery locations for each order to determine the range of exchangeable space;

[0020] Extract the product attributes, promised delivery time, and effective duration of insulated packaging for each order to determine the waiting time. Determine the number of possible handovers based on whether the order allows for mid-transfer. Combine the exchangeable time period, exchangeable spatial range, waiting time, number of handovers, and product status restrictions to form the exchangeable spatiotemporal envelope of the order, thus generating the order exchangeable result.

[0021] Optionally, in a third implementation of the first aspect of the present invention, constructing a candidate handover network based on the order exchangeability results and handover point data includes:

[0022] Based on the exchangeable space range in the order exchangeable results, select the exchange nodes within that range from the exchange point data;

[0023] Based on the capacity, available time period, and historical congestion level of each handover node, determine whether the handover node is available in the target time period and remove unavailable handover nodes.

[0024] The remaining available handover nodes are used as candidate handover nodes. The order's pickup and receipt nodes are used as endpoints, and the candidate handover nodes are used as intermediate nodes to form a graph structure that includes nodes and edges, thus obtaining the candidate handover network.

[0025] Optionally, in the fourth implementation of the first aspect of the present invention, the candidate handover network is subjected to a cooperative handover stability assessment and screening to obtain a set of stable handover nodes, including:

[0026] For each candidate handover scheme in the candidate handover network, calculate the scheme's time synchronization degree, node capacity matching degree, capacity margin matching degree, data permission matching degree, and cargo status risk degree.

[0027] A pre-defined collaborative handover stability assessment model is established. The time synchronization degree, node capacity matching degree, capacity margin matching degree, data permission matching degree, and cargo status risk degree are substituted into the collaborative handover stability assessment model to obtain the collaborative handover stability index.

[0028] The collaborative handover stability index is compared with a preset collaborative stability index threshold, and the handover nodes corresponding to candidate handover schemes that are greater than or equal to the collaborative stability index threshold are retained to obtain a set of stable handover nodes.

[0029] Optionally, in a fifth implementation of the first aspect of the present invention, the stable handover node set and the order exchangeable results are grouped together to obtain a collaborative delivery task cluster, including:

[0030] Data association mapping is performed on the stable set of handover nodes and the exchangeable results of orders to obtain the order-handover node association mapping table;

[0031] Based on the order-handover node association mapping table, iterative clustering and grouping are performed to obtain an initial collaborative delivery task cluster;

[0032] Based on the initial collaborative delivery task cluster, carrier allocation, cost accounting, and revenue constraint verification are performed to obtain a compliant and optimized collaborative delivery task cluster.

[0033] Optionally, in a sixth implementation of the first aspect of the present invention, the order-handover node association mapping table is iteratively clustered into groups to obtain an initial collaborative delivery task cluster, including:

[0034] S4.3.1: Based on the order-handover node association mapping table, mark all orders as ungrouped;

[0035] S4.3.2: Select an ungrouped order as a seed order, create a new candidate task cluster, and add the seed order to the candidate task cluster;

[0036] S4.3.3: Traverse the remaining ungrouped orders. For each order to be inspected, determine whether it meets the preset grouping conditions simultaneously with all orders in the current candidate task cluster. If all conditions are met, add the order to the current candidate task cluster and update the joint constraints of the candidate task cluster.

[0037] S4.3.4: Repeat sub-step S4.3.3 until no new orders can be added to the current candidate task cluster. At this point, the candidate task cluster is confirmed as an initial collaborative delivery task cluster, and all orders contained therein are marked as grouped.

[0038] S4.3.5: Repeat sub-steps S4.3.2 to S4.3.4 until all orders are marked as grouped, resulting in the initial collaborative delivery task cluster.

[0039] Optionally, in the seventh implementation of the first aspect of the present invention, joint path planning is performed on the collaborative delivery task cluster to obtain an initial collaborative delivery path result, including:

[0040] The path planning association data is extracted from the collaborative delivery task cluster to obtain the path planning association dataset;

[0041] A comprehensive cost objective function is constructed based on the aforementioned path planning associated dataset;

[0042] Under the preset constraints, the delivery sequence, handover nodes, handover time, and carrier allocation that minimize the overall cost objective function are solved to obtain the initial collaborative delivery path results.

[0043] Optionally, in the eighth implementation of the first aspect of the present invention, the initial collaborative delivery path result is frozen and dynamically replanned to obtain an executable collaborative delivery path result, including:

[0044] Obtain real-time execution feedback data of the initial collaborative delivery route results;

[0045] Extract the delivery person's current location, distance to the next node, and remaining handover time from the execution feedback data; determine whether each path segment in the initial collaborative delivery path result meets the freezing conditions; and mark the path segments that meet the freezing conditions as frozen path segments.

[0046] When a state change event is received, it is determined whether the state change event affects the frozen path segment;

[0047] If the state change event affects the frozen path segment, an alternative handover scheme or an error message will be output, and the frozen path segment will remain unchanged.

[0048] If the state change event does not affect the frozen path segment, then the unexecuted path segment is replanned on a rolling basis, and the replanned path is concatenated with the frozen path segment to obtain an executable collaborative delivery path result.

[0049] A second aspect of the present invention provides a logistics route planning system based on collaborative delivery, comprising:

[0050] The data processing module is used to acquire raw delivery data from multiple entities to obtain a collaborative delivery dataset; and to perform entity normalization and permission marking on the collaborative delivery dataset to obtain a collaborative delivery record set.

[0051] The order interchangeability parsing module is used to perform order interchangeability parsing on the collaborative delivery record set to obtain the order interchangeability result;

[0052] The handover node filtering module is used to construct a candidate handover network based on the order exchangeability results and handover point data, and to perform collaborative handover stability evaluation and filtering on the candidate handover network to obtain a set of stable handover nodes;

[0053] The order collaboration grouping module is used to collaboratively group the stable handover node set and the order exchangeable results to obtain collaborative delivery task clusters.

[0054] The collaborative path planning module is used to perform joint path planning on the collaborative delivery task cluster to obtain the initial collaborative delivery path result;

[0055] The path dynamic adjustment module is used to freeze and dynamically replan the initial collaborative delivery path results to obtain an executable collaborative delivery path result.

[0056] The beneficial effects of this invention are:

[0057] This invention solves the problems of data heterogeneity, privacy conflicts, and sharing difficulties in multi-entity logistics collaboration by mapping fields, unifying entities, and marking hierarchical permissions on multi-source heterogeneous delivery data, thereby achieving cross-platform data fusion and collaborative computing while protecting the core data privacy of each participating entity.

[0058] This invention constructs an exchangeable spatiotemporal envelope for orders, quantifies the collaborative flexibility boundary of orders, and further constructs a candidate handover network. It calculates the collaborative handover stability index by using time synchronization degree, node capacity matching degree, capacity reserve matching degree, data permission matching degree, and cargo status risk degree. This allows for the early elimination of handover nodes and schemes with poor stability, thereby reducing the handover failure rate to a certain extent and improving the actual fulfillment success rate of delivery tasks.

[0059] This invention is based on an order-handover node association mapping table. It combines the pickup area, delivery area, product attributes, time window, and handover node association to perform multi-dimensional grouping judgment and iterative clustering to form collaborative delivery task clusters. Then, through subject benefit constraint verification, it ensures that the cost of each carrier does not increase significantly or the benefit can be compensated in collaborative delivery, avoids invalid order consolidation and interest imbalance, and enhances the willingness of multiple parties to participate in collaboration.

[0060] This invention constructs a comprehensive cost objective function that includes travel costs, waiting costs, timeout penalties, cargo risk penalties, handover failure penalties, and penalties for uneven revenue distribution. It then employs mixed-integer programming or adaptive large neighborhood search algorithms for joint path planning based on the task cluster size. This overcomes the limitations of traditional methods that only optimize travel distance, achieving a better balance between efficiency, risk, stability, and executability in the path results. Furthermore, based on real-time execution feedback data from the initial path results, path freezing and rolling replanning are performed. Path segments nearing execution are frozen and fixed, while unexecuted segments undergo local dynamic replanning. This avoids frequent changes to the global path due to disturbances such as new orders, capacity delays, and road congestion, ensuring the continuity and stability of on-site delivery operations. Attached Figure Description

[0061] The invention will now be further described with reference to the accompanying drawings.

[0062] Figure 1 This is a flowchart of the logistics route planning method based on collaborative delivery of the present invention.

[0063] Figure 2 This is a schematic diagram of the logistics route planning system framework based on collaborative delivery of the present invention.

[0064] Figure 3 This is a comparison diagram of the effects of the present invention and the prior art. Detailed Implementation

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

[0066] Please see Figure 1 As shown, this invention is a logistics route planning method based on collaborative delivery. Taking a scenario of joint delivery of instant retail and last-mile express delivery within a 5-kilometer radius of a core business district in a city as an example, the specific steps are as follows:

[0067] S1. Obtain the original data of multi-entity delivery to obtain a collaborative delivery dataset; perform entity normalization and permission marking on the collaborative delivery dataset to obtain a collaborative delivery record set;

[0068] Specifically, subject normalization and permission labeling are performed on the collaborative delivery dataset to obtain a collaborative delivery record set, including:

[0069] The collaborative delivery dataset is mapped to fields and unified with entities to obtain a normalized intermediate dataset;

[0070] A shareable level label is attached to each field of the normalized intermediate dataset to obtain a collaborative delivery record set; the shareable level label includes public fields, collaborative computing fields, and non-shareable fields.

[0071] Specifically, the system connects to instant retail platforms, courier company information systems, rider apps, delivery vehicle terminals, and smart locker management platforms via API interfaces. It acquires raw data in parallel within a preset collection cycle, including order data, delivery capacity data, handover point data, and road data. Order data includes order number, pickup location, delivery location, earliest pickup time, latest delivery time, product type (e.g., fresh produce, general parcels, medicine, cold drinks), volume, weight, whether temperature control is required, and whether mid-journey handover is permitted. This order data determines whether an order meets the basic conditions for collaborative delivery. For example, a fresh produce order marked as temperature-controlled and not allowing mid-journey handover has far less collaborative flexibility than a general courier order. Delivery capacity data includes the delivery person's current location, vehicle remaining capacity (e.g., 5kg), vehicle type (e.g., electric bicycle, van), remaining battery power or range (e.g., 80%, 40km), current number of tasks (e.g., 2), and service area (grid code). This capacity data is used to determine whether the delivery capacity can handle additional orders or arrive at the handover point within a specified time. The handover point data includes the location, capacity (e.g., 3 remaining slots in a smart locker), and available time (e.g., 09:00-18:00 daily) of delivery stations, smart lockers, forward warehouses, temporary stops, and community service stations. This handover point data is crucial for cross-entity collaborative delivery, and its availability directly impacts the feasibility of the handover plan. Road data includes road speeds, traffic light waiting times, and real-time traffic conditions, used for travel time estimation in subsequent route planning. After format verification, the above data is merged to form a collaborative delivery dataset. It should be noted that the preset collection period directly affects the system's responsiveness to changes in status. In commercial areas with high concentrations of immediate orders, a shorter period (e.g., 1 minute) is used to quickly capture new orders and changes in delivery capacity location; in areas with regular express delivery, a longer period (e.g., 5 minutes) is used to reduce the system's computational burden. This period can be dynamically adjusted based on the order insertion frequency and route replanning frequency statistics from the trial operation phase. Unified collection of heterogeneous data scattered across multiple systems provides a complete and reliable data source for subsequent normalization processing, order exchangeability assessment, and handover network construction, solving the problem of inaccurate collaborative decision-making caused by incomplete data sources or inconsistent collection granularity in existing solutions.

[0072] Because data fields are named differently across different platforms, and the same type of entity is represented differently in different systems, and because each entity is unwilling to fully disclose its original data, normalization is needed to eliminate heterogeneity, and permission marking is used to support collaborative computing while protecting privacy. Specifically, field mapping and entity unification operations are first performed on each record in the collaborative delivery dataset to generate an intermediate dataset, which serves as the normalized intermediate dataset. This operation process solves the semantic alignment problem of heterogeneous data. A pre-defined field mapping table maps fields with the same meaning but different names from different data sources to a unified target field name. The specific mapping rules are as follows: Original fields such as "Delivery Deadline," "Promised Delivery Time," and "Signing Deadline" from different platforms are unified to the target field "Last Delivery Time"; original fields such as "Customer Coordinates," "Receiving Latitude and Longitude," and "Delivery Location" from different platforms are unified to the target field "Receiving Location"; original fields such as "Estimated Delivery Time," "ETA," and "Estimated Arrival Time" from different platforms are unified to the target field "Estimated Arrival Time"; and original fields such as "Pickup Window Start," "Earliest Pickup Time," and "Available Pickup Time" from different platforms are unified to the target field "Earliest Pickup Time." Upon receiving the collaborative delivery dataset, the system iterates through each data entry, finds the corresponding field mapping rule based on the data source identifier, replaces the original field name with the target field name, and converts the field values ​​to a unified format. In addition, time fields are uniformly converted to Unix timestamps accurate to the second for subsequent time difference calculations. For volume, weight, and distance fields, physical quantity segments are uniformly converted to ensure consistency in distance, time, and capacity calculations during subsequent route planning. Since different platforms use different names for the same type of logistics entity, these names are mapped to standard terminology. For example, riders, couriers, drivers, delivery personnel, food delivery workers, and crowdsourcing workers—all entities actually performing delivery tasks—are unified as capacity units. Each capacity unit is assigned a globally unique capacity ID with a type label for distinguishing its service capabilities and business scope. Facilities that can be used for cross-entity handover, such as delivery stations, smart lockers, smart parcel lockers, pre-positioned warehouse parking areas, community service stations, collection points, and convenience stores (collection), are unified as handover nodes. Each handover node is assigned a global node ID and its type and capacity attributes are recorded. After the above field mapping and entity unification, a normalized intermediate dataset is output, in which all records have unified field names, units, and entity identifiers.

[0073] Considering the commercial competition and user privacy concerns among various stakeholders, such as riders from different e-commerce platforms and couriers from different courier companies, the system does not require all stakeholders to disclose all data. Instead, each data item in the normalized intermediate dataset is labeled with a shareability level, which is divided into three categories: public fields, collaborative calculation fields, and non-shareable fields. Public fields are those that can be directly viewed by all participating stakeholders. These fields are usually obfuscated or aggregated and do not involve specific business details. Public fields include gridded location, capacity range, and available time window. Collaborative calculation fields are those that the system can use on the server side, but the calculation results are not displayed to unrelated stakeholders. These fields contain key information necessary for performing route planning and handover matching, but the original data details are not exposed to other participants. Collaborative calculation fields include precise address, latest delivery time, product type, and product volume and weight. Non-shareable fields refer to data that is completely prohibited from leaving the original system. This type of data is retained only on the original system's side and is neither uploaded to the collaborative computing server nor made available to other systems. Typical non-shareable fields include customer name, contact number, payment amount, order discount information, and internal cost data such as the order's delivery cost and subsidy amount. After normalization and permission marking, a collaborative delivery record set is output. Each order and each delivery unit in this record set includes a clear declaration of the scope of shareable data. For example, the original order data of a fresh food platform contains "Customer: Zhang**, Phone: 138****, Address: Room 101, Building 3, Community A". After this step, the public part is "Grid: GC1002", the collaborative computing part is "Precise Address: Room 101, Building 3, Community A, Latest Delivery Time: 11:00, Goods: Strawberries (requires refrigeration)", and the non-shareable part, "Customer Name and Phone Number", is retained on the original platform. Therefore, the system can calculate that the order is suitable for handover near Community A, but will not expose the customer's privacy to the courier company handling the handover.

[0074] It should be noted that step S1 establishes a unified data standard and sharing boundary without requiring all entities to fully disclose the original data, enabling subsequent steps to perform collaborative calculations within the scope of legal and compliant data permissions, thus solving the problem of data availability but invisibility in multi-entity collaboration.

[0075] S2. Perform order exchangeability parsing on the collaborative delivery record set to obtain the order exchangeability result;

[0076] Specifically, the order exchangeability is parsed on the collaborative delivery record set to obtain the order exchangeability result, including:

[0077] Based on the collaborative delivery record set, the earliest pickup time, latest delivery time, estimated service duration, and safety buffer time for each order are extracted to determine the exchangeable time period;

[0078] Extract the pickup and delivery locations for each order to determine the range of exchangeable space;

[0079] Extract the product attributes, promised delivery time, and effective duration of insulated packaging for each order to determine the waiting time. Determine the number of possible handovers based on whether the order allows for mid-transfer. Combine the exchangeable time period, exchangeable spatial range, waiting time, number of handovers, and product status restrictions to form the exchangeable spatiotemporal envelope of the order, thus generating the order exchangeable result.

[0080] Specifically, this step determines whether each order meets the conditions for collaborative transport or mid-journey handover by other entities, and what the specific boundaries of these conditions are. Transforming orders from immutable tasks into flexible tasks with exchangeable space and time windows forms the foundation for subsequent handover network construction. For each order in the collaborative delivery record set, an exchangeable time period is calculated based on the earliest pickup time, latest delivery time, estimated service duration, and safety buffer time. The exchangeable time period refers to the time interval within which the order can be picked up or handed over by other entities. Exchangeable time period = [earliest pickup time, latest delivery time - estimated service duration - safety buffer time]. The safety buffer time is used to address uncertainties in the route; in a specific embodiment, it can be 10%-20% of the estimated delivery time. More preferably, calibration can be performed based on the 90th percentile delay time in historical delay samples. For example, if the earliest pickup time for an order is 10:00 and the latest delivery time is 11:00, the estimated delivery time from the pickup point to the receiving point is 8 minutes, the estimated service time for handover or delivery is 2 minutes, and the safety buffer time is 20% of the 8 minutes, i.e., 1.6 minutes, then the exchangeable time period is [10:00, 11:00 - 0:02 - 0:016 = 10:58.4]. After the exchangeable time period, it is no longer suitable for handover, that is, the actual available window is about 58 minutes.

[0081] The interchangeable space range is determined based on the order's pickup and delivery locations. This interchangeable space range refers to the geographical area within a certain distance of the line connecting the pickup and delivery points. This range can be calculated geometrically: using the line connecting the pickup and delivery points as an axis, extend a preset width (e.g., 200 meters) to both sides, and then add a preset radius (e.g., 100 meters) with the delivery point as the center, forming an envelope area. Only delivery points falling within this envelope area are considered as candidate delivery points for that order.

[0082] The acceptable waiting time is determined based on the order's product attributes, promised delivery time, and the effective duration of insulated packaging. The acceptable waiting time refers to the maximum acceptable waiting period during which the order can be handed over; exceeding this time may compromise product or service quality. The calculation of the acceptable waiting time varies depending on the product type. For example, for fresh produce or temperature-controlled orders, the acceptable waiting time = min(promised delivery time - current pickup time - estimated delivery time + effective duration of insulated packaging). For instance, if the effective duration of insulated packaging for strawberries is 30 minutes, and after deducting 8 minutes of delivery time, 22 minutes remain, then the acceptable waiting time is 22 minutes. For regular express orders, the acceptable waiting time is mainly determined by the delivery batch time limit and the network's pickup and delivery rhythm, and is usually more lenient, ranging from 30 to 60 minutes. For immediate orders, such as hot coffee, the acceptable waiting time is very small, even zero, requiring direct delivery.

[0083] The number of permissible handovers is determined by whether mid-order handovers are allowed. The number of permissible handovers refers to the number of cross-entity handovers permitted during the entire order process from pickup to delivery. The number of permissible handovers is determined by the order creator or the attributes of the goods. For example, for high-value, fragile, or time-sensitive goods, it is usually set to 0, meaning handovers are not allowed; for ordinary express parcels, it can be set to 1-2 times.

[0084] Cargo condition restrictions refer to the environmental conditions that need to be maintained for goods during transportation, such as refrigeration (2-8℃), freezing (below -18℃), insulation (above 60℃), and shock protection. These restrictions dictate that the transport capacity must be equipped with corresponding equipment (such as insulated boxes and ice packs) or adopt specific operating procedures.

[0085] The exchangeable time period, exchangeable spatial range, waiting time, number of handovers, and product status restrictions collectively constitute the exchangeable spatiotemporal envelope of an order, forming the order's exchangeable result. For example, order A, product type is strawberries (fresh produce), the exchangeable time period is [10:00, 10:40], the exchangeable spatial range is the area within 200 meters of the line connecting pickup point P1 and delivery point C1, the waiting time is 22 minutes, the number of handovers is 1, and the product status restriction is refrigerated 2-8℃. Order B, product type is ordinary express parcel, the exchangeable time period is [09:00, 11:30], the exchangeable spatial range is wider, the waiting time is 60 minutes, the number of handovers is 2, and there are no temperature control restrictions.

[0086] It should be noted that transforming each order from a static pickup to delivery task into a collaborative resource with clear exchange boundaries provides constraints for the subsequent handover network construction. Through the exchangeable spatiotemporal envelope of orders, orders and handover schemes that do not meet the collaborative conditions can be quickly filtered out in subsequent steps, avoiding invalid calculations.

[0087] S3. Based on the order exchangeability results, construct a candidate handover network by combining the handover point data, and conduct a collaborative handover stability assessment and screening of the candidate handover network to obtain a set of stable handover nodes;

[0088] Specifically, based on the order exchangeability results and combined with handover point data, a candidate handover network is constructed, including:

[0089] Based on the exchangeable space range in the order exchangeable results, select the exchange nodes within that range from the exchange point data;

[0090] Based on the capacity, available time period, and historical congestion level of each handover node, determine whether the handover node is available in the target time period and remove unavailable handover nodes.

[0091] The remaining available handover nodes are used as candidate handover nodes. The order's pickup and receipt nodes are used as endpoints, and the candidate handover nodes are used as intermediate nodes to form a graph structure that includes nodes and edges, thus obtaining the candidate handover network.

[0092] Specifically, this step combines the judgment result of whether an order is exchangeable with the actual situation of whether the handover point is available, constructing a graph network structure to transform the abstract collaborative delivery problem into a specific path selection problem of which points, which transportation capacities, and when the handover is completed. First, for each order, the exchangeable spatiotemporal envelope is used to extract the exchangeable spatial range. Then, all handover nodes, such as stations, smart lockers, and forward warehouses, are traversed to filter out the handover nodes whose locations fall within the spatial range. For example, the exchangeable spatial range of order A is an envelope area with a width of 200 meters centered on the line connecting P1 (pickup point) and C1 (receiver point). The handover nodes within this envelope area include smart locker L1, station S1, and smart locker L2. Smart locker L1 is 80 meters away from the vertical distance of the connecting line, station S1 is 120 meters away, and smart locker L2 is 300 meters away, so smart locker L2 is excluded.

[0093] Secondly, for each eligible handover node in the space, its availability during the target time period is further determined. The determination criteria include three sub-conditions. Condition 1 is sufficient capacity, for example, the number of remaining spaces in the smart locker is greater than or equal to 1, or the current queuing time at the station is less than or equal to a preset threshold, such as 5 minutes. Condition 2 is available time period matching, that is, the opening time of the handover node covers the exchangeable time period of the order. For example, if a community station is only open from 09:00 to 18:00, while the exchangeable time period for the order is from 20:00 to 21:00, then the node is unavailable. Condition 3 is acceptable historical congestion level, that is, according to historical data, the average handover waiting time of the node during the target time period is less than a preset threshold, such as 10 minutes. Only handover nodes that simultaneously meet the above three sub-conditions are included in the candidate handover network and recorded as candidate handover nodes.

[0094] Using the order's pickup and receiving nodes as endpoints and candidate handover nodes as intermediate nodes, a graph structure consisting of nodes and edges is formed, resulting in a candidate handover network. The candidate handover network is a directed graph containing nodes and edges. Nodes include pickup nodes, handover nodes, delivery nodes, and return nodes. Pickup nodes are the pickup locations for orders; handover nodes are the candidate handover nodes selected in the previous steps; delivery nodes are the receiving locations for orders; and return nodes are the aggregation points after the transportation capacity completes its tasks. Each node is subject to time window constraints and capacity constraints. Edges include pickup edges, handover edges, delivery edges, and return edges. Pickup edges are from the transportation capacity's starting point to the pickup node; handover edges are from the pickup node to the handover node; delivery edges are from the handover node to the delivery node; and return edges are from the delivery node to the return node. Each edge is accompanied by estimated travel time, historical fluctuation time (standard deviation), distance, capacity occupancy, cargo status risk (such as temperature control interruption risk), and subject permission flags. For example, the candidate handover network for order A includes nodes P1 (pickup node), L1 (smart locker, serving as a handover node), and C1 (receiver node). Edges include P1→L1, transported by rider R1 with an estimated travel time of 3 minutes (fluctuation ±1 minute), and L1→C1, transported by courier D1 with an estimated travel time of 5 minutes (fluctuation ±1.5 minutes). If order A also matches another handover node S1 (station), the network will also contain edges P1→S1 and S1→C1.

[0095] It should be noted that by spatially and temporally matching the two independent information sources—the order exchange results and the handover point data—a complete candidate network is formed. This network reduces the scope of subsequent path planning from all nodes to candidate nodes, significantly reducing computational complexity. Simultaneously, by preemptively eliminating unusable handover nodes, such as those with insufficient capacity or time mismatches, invalid attempts in subsequent steps are avoided.

[0096] The stability evaluation and screening of the candidate handover networks yields a set of stable handover nodes, including:

[0097] For each candidate handover scheme in the candidate handover network, calculate the scheme's time synchronization degree, node capacity matching degree, capacity margin matching degree, data permission matching degree, and cargo status risk degree; preset a collaborative handover stability evaluation model, and substitute the time synchronization degree, node capacity matching degree, capacity margin matching degree, data permission matching degree, and cargo status risk degree into the collaborative handover stability evaluation model to obtain the collaborative handover stability index;

[0098] The collaborative handover stability index is compared with a preset collaborative stability index threshold, and the handover nodes corresponding to candidate handover schemes that are greater than or equal to the collaborative stability index threshold are retained to obtain a set of stable handover nodes.

[0099] Specifically, this step uses the collaborative handover stability index as a quantitative evaluation metric to predict the likelihood of success for each candidate handover scheme in actual execution. In existing technologies, path planning algorithms typically assume a handover scheme is feasible, but in practice, it frequently fails due to time asynchrony, insufficient capacity, or insufficient transport capacity. The collaborative handover stability index is used to preemptively eliminate theoretically feasible but practically unsuccessful schemes. First, for each candidate handover scheme j in the candidate handover network, the time synchronization degree T of scheme j is calculated. j Node capacity matching degree Q j B. Capacity margin matching degree j Data permission matching degree P j and the risk level of the goods status R j Time synchronization reflects the time difference between the expected arrival times of the two parties at the handover point; the smaller the time difference, the higher the synchronization. The specific formula for calculating time synchronization is: For example, rider R1 is expected to arrive at L1 at 10:20, and courier D1 is expected to arrive at L1 at 10:22, a time difference of 2 minutes. The maximum tolerable time difference is set to 10 minutes. Then T j =1-2 / 10=0.8; If the time difference is 0, then T j =1; if the time difference is greater than or equal to 10 minutes, then T j =0. Node capacity matching degree reflects whether the remaining capacity of the handover node is sufficient during the target time period; for example, if the handover node is a smart cabinet, its corresponding node capacity matching degree is 0. The handover node is a relay station, and its corresponding node capacity matching degree The node capacity matching degree ranges from [0,1], with a larger value indicating more sufficient capacity. The capacity reserve matching degree reflects whether the receiving party's capacity meets the receiving requirements; it integrates multiple sub-factors, including vehicle remaining capacity matching degree, battery range matching degree, and current task quantity matching degree, with the capacity reserve matching degree being a weighted sum of these sub-factors. It should be noted that the vehicle remaining capacity matching degree is used to assess whether the order capacity is within the remaining capacity range, and the calculation formula for the vehicle remaining capacity matching degree is: In the formula, For the capacity of orders awaiting handover, To take over the current remaining capacity, The remaining vehicle capacity matching degree; the battery range matching degree is used to assess whether the remaining battery power can support additional distance, and the formula for calculating the battery range matching degree is: In the formula, This indicates the estimated driving range corresponding to the current remaining battery power. This indicates the total remaining mileage of the transportation capacity that was originally planned but has not yet been executed. This indicates the additional mileage required after the order is received and handed over. For battery life matching, The battery life safety factor is set to 0.8 in a specific embodiment, representing a 20% battery reserve to cope with changes in road conditions and power consumption of the temperature control equipment; the current task quantity matching degree is used to assess whether the current task quantity exceeds a threshold, and the formula for calculating the current task quantity matching degree is: In the formula, represents the matching degree of the current task quantity. To take over the number of tasks that the transportation capacity has not yet completed, To accommodate the maximum reasonable number of simultaneous tasks within the transport capacity

[0100] Data access permission matching reflects whether the data fields required to complete the handover scheme are allowed to be shared among the relevant entities; for example, if the scheme requires sharing the exact delivery address of an order, but this field is marked as non-shareable, then P j =0; if all required fields are marked as public or collaboratively computed fields, then P j =1.

[0101] Goods status risk R jThis value reflects the negative impact of waiting, detours, or temperature control interruptions on the condition of goods. A higher value indicates a higher risk to the condition of the goods, and therefore it is subtracted from the collaborative handover stability index calculation formula. The risk Rj of the goods condition is calculated based on a preset goods condition risk mapping table. This table includes the risk value corresponding to each type of goods condition. Each type of goods condition is matched with the preset goods condition risk mapping table to obtain the risk value for each type of goods condition. These risk values ​​are then weighted and summed to obtain the goods condition risk Rj.

[0102] A pre-defined collaborative handover stability assessment model is established, and the expression of the collaborative handover stability assessment model is as follows: The time synchronization degree, node capacity matching degree, capacity margin matching degree, and data permission matching degree of each candidate handover scheme j in the candidate handover network are substituted into the collaborative handover stability evaluation model to obtain the collaborative handover stability index C of each candidate handover scheme j. j In the formula, These represent weighting factors. In a specific embodiment, the weights are equal in weight, both being 0.2.

[0103] A preset collaborative handover stability index threshold, for example, 0.7, is set for each candidate handover scheme j, if C j If C ≥ 0.7, then the corresponding handover node is included in the set of stable handover nodes; if C j If the value is less than 0.7, the proposed solution is eliminated and will not be included in subsequent path planning. It should be noted that the threshold value for the collaborative handover stability index can be adaptively adjusted based on actual operational conditions: if the handover failure rate is high during the trial run, it indicates that the threshold may be too high, allowing too many unstable solutions. In this case, the threshold is re-determined based on the lower quartile of the stability index among the successful handover samples in the most recent 30 days (the lower quartile is the 25th percentile), ensuring higher reliability for solutions entering the planning process. For example, for the handover of order A to courier D1 via smart locker L1, the calculated time synchronization degree T... j =0.9, capacity matching degree Q j =0.85, capacity margin B j =1.0, permission matching degree P j =1.0, Goods Risk R j =0.3, which means the coordinated handover stability index C of this scheme is 0.3. j =0.2×0.9+0.2×0.85+0.2×1.0+0.2×1.0-0.2×0.3=0.18+0.17+0.2+0.2-0.06=0.69, the coordinated handover stability index C of this scheme is 0.2×0.9+0.2×0.85+0.2×1.0+0.2×1.0-0.2×0.3=0.18+0.17+0.2+0.2-0.06=0.69. j=0.69 < 0.7, which means it is not included in the stable set. This indicates that although the handover scheme is theoretically feasible, its stability is insufficient. Therefore, it is necessary to find a more stable alternative, such as changing the handover node or taking over the transport capacity.

[0104] It should be noted that this step quantifies the collaborative handover stability index of candidate handover schemes and eliminates schemes that do not meet stability requirements based on a preset threshold before route planning. This provides handover nodes and schemes with high execution reliability for subsequent joint route planning. This approach differs from existing route planning methods that assume the handover scheme is feasible and can effectively improve the actual fulfillment success rate of collaborative delivery schemes.

[0105] S4. Perform order coordination grouping on the stable handover node set and the order exchangeable results to obtain a coordinated delivery task cluster;

[0106] Specifically, the stable set of handover nodes and the order exchangeable results are grouped together to obtain a collaborative delivery task cluster, including:

[0107] Data association mapping is performed on the stable set of handover nodes and the exchangeable results of orders to obtain the order-handover node association mapping table;

[0108] Based on the order-handover node association mapping table, iterative clustering and grouping are performed to obtain an initial collaborative delivery task cluster;

[0109] Based on the initial collaborative delivery task cluster, carrier allocation, cost accounting, and revenue constraint verification are performed to obtain a compliant and optimized collaborative delivery task cluster.

[0110] Specifically, the order-handover node association mapping table is iteratively clustered into groups to obtain an initial collaborative delivery task cluster, including:

[0111] S4.3.1: Based on the order-handover node association mapping table, mark all orders as ungrouped;

[0112] S4.3.2: Select an ungrouped order as a seed order, create a new candidate task cluster, and add the seed order to the candidate task cluster;

[0113] S4.3.3: Traverse the remaining ungrouped orders. For each order to be inspected, determine whether it meets the preset grouping conditions simultaneously with all orders in the current candidate task cluster. If all conditions are met, add the order to the current candidate task cluster and update the joint constraints of the candidate task cluster.

[0114] S4.3.4: Repeat sub-step S4.3.3 until no new orders can be added to the current candidate task cluster. At this point, the candidate task cluster is confirmed as an initial collaborative delivery task cluster, and all orders contained therein are marked as grouped.

[0115] S4.3.5: Repeat sub-steps S4.3.2 to S4.3.4 until all orders are marked as grouped, resulting in the initial collaborative delivery task cluster.

[0116] Specifically, this step combines the stable handover node set obtained after stability screening with the exchangeable results of orders, aggregating scattered orders into collaborative delivery task clusters according to collaboration conditions. Each task cluster represents a set of orders that can be delivered jointly by multiple carriers through collaboration (relay or handover). The purpose of grouping is to reduce invalid order merging, that is, to forcibly merge orders that are not suitable for joint delivery, while reducing cross-entity collaboration conflicts. First, the order ID, pickup grid, delivery grid, product type, exchangeable time period, waiting time, number of handovers, temperature control requirements, etc., of each order in the exchangeable results are read. Then, the node ID, location (latitude and longitude and grid), available time period, remaining capacity, type of transport capacity that can be accepted, and collaborative handover stability index of each stable handover node in the stable handover node set are read, and data association mapping processing is performed. The specific execution steps are as follows:

[0117] S4.1.1: For each order, extract the exchangeable spatial range from its exchangeable spatiotemporal envelope, that is, the spatial envelope area formed by expanding the line connecting the pickup point and the receiving point with a preset width as the center;

[0118] S4.1.2: Select all the exchange nodes whose locations fall within the exchangeable space range from the set of stable exchange nodes to obtain the candidate stable exchange node list for this order;

[0119] S4.1.3: For each candidate stable handover node, further check the time matching: take the intersection of the order's exchangeable time period and the node's available time period. If the intersection is not empty and the intersection length is greater than the preset minimum handover time (such as 1 minute), then the node and its available time intersection segment are recorded as a valid match.

[0120] S4.1.4: Store the above matching results in the form of the intersection of order ID, node ID, and available time period into the order-handover node association mapping table. This table records the stable handover nodes that each order can use and their specific available time windows.

[0121] For example, the exchangeable space range of order A (strawberries) covers smart locker L1 and station S1. The available time period of L1 is 09:00-18:00, and the exchangeable time period of order A is 10:00-10:40. The intersection is 10:00-10:40, so the match is successful. The available time period of S1 is 14:00-16:00, which has no intersection with order A, so the match fails. Therefore, the association mapping table of order A only contains L1 and its available window [10:00, 10:40].

[0122] S4.2. Based on the order-handover node association mapping table, a preset grouping condition determination is performed. For any two or more orders, when determining whether they belong to the same collaborative delivery task cluster, the following five conditions must be met simultaneously:

[0123] The first grouping condition is that the pickup areas are close, meaning that the pickup locations of each order belong to the same preset geographical grid, or the shortest path distance between any two pickup points is less than a preset first distance threshold. The size of the preset geographical grid is set according to the regional order density, and in a specific embodiment, it is 500 meters × 500 meters; the first distance threshold is 1 kilometer. This condition is used to ensure that orders within the same task cluster can be picked up centrally by the same pickup capacity within a reasonable distance.

[0124] The second grouping condition is proximity in delivery areas, meaning that the delivery locations of all orders belong to the same preset geographical grid, or the shortest path distance between any two delivery points is less than a preset second distance threshold. This second distance threshold is set to 1 kilometer. This condition ensures that orders within the same task cluster can be delivered collectively by the same delivery capacity within a reasonable distance.

[0125] The third grouping condition is product attribute compatibility, which means that there are no conflicts in the temperature control requirements of all orders within the same task cluster, and that the waiting time for orders sensitive to waiting time does not exceed their allowable waiting time under the expected execution order. Among them, temperature control requirement conflicts include mixed loading of refrigerated and frozen orders, and mixed loading of room temperature orders and orders requiring cold chain transportation, where the transportation vehicle does not have the capability for zoned temperature control. Specifically, this is determined by querying the preset temperature control compatibility table and the prohibited mixed loading category table.

[0126] The fourth grouping condition is time window compatibility, which means that the exchangeable time periods of all orders within the same task cluster have a common intersection, or that, without changing the latest delivery time constraints of each order, there exists a task execution order that allows the pickup, handover, and delivery operations of each order to be completed within its corresponding exchangeable time period. Specifically, this is achieved by calculating the intersection interval of the exchangeable time periods of each order. If the intersection is not empty, the condition is directly satisfied; otherwise, the feasibility is verified by simulating the order arrangement in ascending order of the latest delivery time.

[0127] The fifth grouping condition is that the candidate stable handover nodes are the same or adjacent. This means that the candidate stable handover node sets of each order within the same task cluster have a common node, or the spatial distance between the candidate stable handover nodes of each order is less than a preset third distance threshold. The third distance threshold is set to 200 meters and is used to determine whether the nodes are adjacent, such as smart lockers on different floors in the same building, or two stations that are close to each other in the same block. This condition ensures that handover operations can be completed in the same or adjacent locations, avoiding the ineffective movement of transportation capacity between different handover points.

[0128] Then, iterative clustering is performed, which includes the following steps:

[0129] S4.3.1: Mark all orders as ungrouped;

[0130] S4.3.2: Select an ungrouped order as a seed order, create a new candidate task cluster, and add the seed order to the candidate task cluster;

[0131] S4.3.3: Traverse the remaining ungrouped orders. For each order to be inspected, determine whether it simultaneously satisfies the five grouping conditions described in step S4.2 with all orders in the current candidate task cluster. If all conditions are met, add the order to the current candidate task cluster and update the joint constraints of the candidate task cluster, including the union of pickup areas, the union of delivery areas, the intersection of exchangeable time periods, and the union of candidate handover nodes.

[0132] S4.3.4: Repeat sub-step S4.3.3 until no new orders can be added to the current candidate task cluster. At this point, the candidate task cluster is confirmed as an initial collaborative delivery task cluster, and all orders contained therein are marked as grouped.

[0133] S4.3.5: Repeat sub-steps S4.3.2 to S4.3.4 until all orders are marked as grouped, and output the initial collaborative delivery task cluster; it should be noted that orders that cannot meet the grouping conditions with other orders will each become an independent initial collaborative delivery task cluster containing only a single order.

[0134] S4.4. Based on the generated initial collaborative delivery task cluster, further apply entity revenue constraints. These constraints ensure that after collaborative delivery, the unit order delivery cost for each carrier within the task cluster is not higher than the cost of independent delivery, or that the increased cost can be covered by cost savings from other entities or subsidies provided by the system. The specific execution steps are as follows:

[0135] S4.4.1: For the initial collaborative delivery task cluster, based on its order set, recommended handover nodes, and available handover time periods, a recommended first-leg carrier and a second-leg carrier are assigned to the task cluster; the assignment method is as follows: select the transportation unit with the lowest current load and the lowest pickup cost as the first-leg carrier based on the pickup area; select the transportation unit with the lowest current load and the lowest delivery cost as the second-leg carrier based on the delivery area and the location of the handover node.

[0136] S4.4.2: Obtain the cost for each assigned carrier in an independent delivery scenario, denoted as... And the cost in the collaborative delivery scenario, denoted as The costs include travel distance costs, time costs, and vehicle usage costs.

[0137] S4.4.3: For each carrier, if the condition is not met... or However, if the excess can be covered by cost savings or system compensation from other entities, then the collaborative delivery task cluster is determined not to meet the entity's revenue constraint, the current allocation scheme for the task cluster is rejected, and an attempt is made to adjust the handover node or carrier allocation; if all possible adjustments fail to meet the constraint, the task cluster is split into smaller sub-clusters or downgraded to an independent delivery task, and finally the collaborative delivery task cluster after the entity's revenue constraint is verified is obtained.

[0138] It should be noted that by grouping orders collaboratively, scattered orders are aggregated into independently plannable task blocks, reducing the complexity of subsequent joint path planning. At the same time, the introduction of principal revenue constraints ensures the generated task clusters are practically executable, guaranteeing that the solution is not only algorithmically optimal but also commercially and operationally acceptable to all participating parties.

[0139] S5. Perform joint path planning on the collaborative delivery task cluster to obtain the initial collaborative delivery path results;

[0140] The process includes joint path planning for the collaborative delivery task cluster to obtain initial collaborative delivery path results, including:

[0141] The path planning association data is extracted from the collaborative delivery task cluster to obtain the path planning association dataset;

[0142] A comprehensive cost objective function is constructed based on the aforementioned path planning associated dataset;

[0143] Under the preset constraints, the delivery sequence, handover nodes, handover time, and carrier allocation that minimize the overall cost objective function are solved to obtain the initial collaborative delivery path results.

[0144] Specifically, this step involves finding the optimal delivery sequence, carrier allocation, and handover time arrangement that satisfy all constraints for each collaborative delivery task cluster. Unlike existing technologies that only aim for the shortest distance, this step constructs a comprehensive cost objective function that integrates path efficiency and solution feasibility into the optimization. Based on the generated collaborative delivery task clusters, joint path planning is performed for each cluster. First, the pickup location, delivery location, product type, latest delivery time, volume, weight, temperature control requirements, and waiting time for each order in the order set contained in the task cluster are obtained. Simultaneously, the location, available time period, and remaining capacity of the recommended handover nodes allocated to the task cluster are obtained, along with the current location, remaining capacity, remaining battery power, current number of tasks, unit mileage cost, and unit time cost of the allocated first-leg and second-leg carriers. The estimated travel time, travel distance, and historical fluctuation data between any two nodes are also loaded. Based on the above data, a comprehensive cost objective function is constructed as the optimization objective of the path planning. The comprehensive cost objective function is: ,in, For driving costs, Due to waiting costs, As a penalty for exceeding the time limit, Goods risk penalties Penalties for failed handover Punishment for unequal distribution of benefits among the main body. These are the weighting factors corresponding to each cost item. These weighting factors are used to balance the importance of each cost item. In a specific embodiment, .

[0145] It should be noted that the operating cost The total travel distance cost of all capacity units participating in this task cluster is represented by the following formula: In the formula, K represents the set of transportation units participating in the task cluster, including the first and second leg carriers. Let k be the total mileage traveled by the transport unit during the execution of this task cluster. Let k be the unit mileage cost of the transport unit. The unit mileage cost can be preset according to the type of transport (such as electric bicycles, fuel vans, etc.) and energy prices.

[0146] Waiting cost This represents the time cost incurred by a transport unit while waiting for the other party to arrive at the handover node. The formula for calculating this cost is: In the formula, H is the set of handover events where waiting occurs. The waiting time, in minutes, is the time for the party arriving first in the h-th handover. This waiting time is calculated as the absolute value of the difference between the expected arrival times of both parties. If one party arrives earlier, the waiting time is the difference between its arrival time and the other party's arrival time; if both parties arrive simultaneously or there is no waiting, then... ; This represents the unit time cost of this transportation unit, expressed in yuan per minute.

[0147] Overtime penalty This represents the penalty cost incurred when an order is not delivered before the latest delivery time, and its calculation formula is as follows: In the formula, For the set of orders within the task cluster, For orders The estimated delivery time, For orders The latest delivery time, The penalty coefficient is set at 10 yuan / minute for each unit of timeout. In a specific example, this is applied when the order does not time out. .

[0148] Goods risk penalty This represents the risk cost of decreased product quality due to waiting, detours, or temperature control disruptions. For orders requiring temperature control or sensitive to time, this penalty increases with the length of the waiting time. The calculation formula is as follows: In the formula, For sensitive order collections, such as fresh produce, medicines, and cold drinks, The total waiting time for order o during transportation includes waiting at the handover point and additional time incurred due to detours. The waiting time for order o is the waiting time within the exchangeable spatiotemporal envelope of the order determined in step S2. The risk penalty coefficient for exceeding the allowed waiting time is set at 20 yuan / minute in a specific embodiment. When the cumulative waiting time does not exceed the permissible waiting time, the risk penalty for the goods is applied. .

[0149] Penalty for Failed Handover This indicates that if the current path scheme uses a handover scheme with a low collaborative handover stability index from step S3, or if the handover node is not included in the set of stable handover nodes, an additional penalty is applied, calculated as follows: In the formula, This is the set of handover schemes used in the routing plan. Let be the collaborative handover stability index of the j-th handover scheme. Let τ be the threshold for coordinated handover stability, and τ be the penalty coefficient for unit stability exponent deviation. When the coordinated handover stability exponent is greater than or equal to the threshold, a penalty is applied for handover failure. Otherwise, the penalty increases linearly with the degree to which the stability index falls below the threshold.

[0150] Punishment for Uneven Main Benefits This indicates that if the cost-benefit distribution among the carriers within a task cluster is severely unbalanced, an additional penalty will be imposed to prevent any entity from refusing to perform due to loss of interest. The calculation formula is as follows: In the formula, Let k be the cost of the transport unit under the collaborative scheme. This refers to the cost of independent delivery by this capacity unit. The imbalance penalty coefficient is set to 2.0 in a specific embodiment. This penalty term only applies to capacity units with increased costs and is proportional to the amount of the cost increase, prompting the optimization process to favor solutions where costs for all parties do not increase or increase only slightly.

[0151] Simultaneously, pre-defined constraints must be met, including capacity constraints, time window constraints, handover frequency constraints, capacity reserve constraints, and entity revenue constraints. Among these, the capacity constraint means that the loading volume of each capacity at any given time does not exceed the remaining capacity; the time window constraint means that order pickups are not earlier than the earliest pickup time and deliverys are not later than the latest delivery time, with handover nodes used within their available time periods; the handover frequency constraint means that the actual number of handovers does not exceed the allowed number of handovers for an order; the capacity reserve constraint means that the remaining battery power supports the entire mileage and the number of tasks does not exceed the maximum reasonable number of tasks; and the entity revenue constraint means that any increase in collaborative costs can be saved or compensated by other entities.

[0152] Subsequently, under the preset constraints of the collaborative delivery task cluster, the delivery order, handover nodes, handover times, and carrier allocation that minimize the overall cost objective function are solved. Specifically, different algorithms are selected based on the number of orders within the task cluster. When the number of orders in the task cluster does not exceed 10, mixed integer programming is used for exact solution. The objective function and constraints are linearized and then input into a commercial solver (such as Gurobi or CPLEX) to obtain the globally optimal solution. When the number of orders in the task cluster exceeds 10, an adaptive large neighborhood search heuristic algorithm is used. Through initial solution generation, iterative removal and re-insertion operations, and a simulated annealing mechanism, an approximate optimal solution is obtained. After the solution is completed, the output initial collaborative delivery path results include the pickup order and estimated arrival time at the handover node for each first-leg carrier, the delivery order from the handover node and estimated delivery time to each receiving point for each second-leg carrier, the segment carrier allocation and handover node identifiers for each order, and the overall cost and individual cost values ​​for the entire task cluster. The resulting initial collaborative delivery route takes into account route efficiency, handover stability, cargo security, and balance of entity benefits, providing a reliable foundation for dynamic replanning in subsequent steps.

[0153] It should be noted that by incorporating driving costs, waiting costs, timeout penalties, cargo risk penalties, handover failure penalties, and entity benefit imbalance penalties into the objective function, and solving for the optimal path under multiple constraints, the output initial collaborative delivery path not only has a low driving distance, but also has high feasibility in terms of handover stability, cargo safety, and entity acceptance.

[0154] S6. Freeze and dynamically replan the initial collaborative delivery path results to obtain an executable collaborative delivery path result;

[0155] The initial collaborative delivery route result is frozen and dynamically replanned to obtain an executable collaborative delivery route result, including:

[0156] Obtain real-time execution feedback data of the initial collaborative delivery route results;

[0157] Extract the delivery person's current location, distance to the next node, and remaining handover time from the execution feedback data; determine whether each path segment in the initial collaborative delivery path result meets the freezing conditions; and mark the path segments that meet the freezing conditions as frozen path segments.

[0158] When a state change event is received, it is determined whether the state change event affects the frozen path segment;

[0159] If the state change event affects the frozen path segment, an alternative handover scheme or an error message will be output, and the frozen path segment will remain unchanged.

[0160] If the state change event does not affect the frozen path segment, then the unexecuted path segment is replanned on a rolling basis, and the replanned path is concatenated with the frozen path segment to obtain an executable collaborative delivery path result.

[0161] Specifically, this step addresses the dynamic disturbances in real-world logistics scenarios, where events such as new orders, capacity delays, road congestion, and changes in handover point capacity can occur at any time. Existing technologies often employ global replanning, but this can lead to frequent disruptive new instructions for delivery personnel, causing execution chaos. This step utilizes a mechanism of path freezing combined with rolling replanning to make local adjustments only to the unexecuted portions while maintaining the stability of the already executed parts. Based on the generated initial collaborative delivery path results, real-time execution and monitoring are performed. The system continuously acquires execution feedback data from delivery personnel terminals, vehicle GPS, and intelligent handover facilities, including the delivery person's current location, completed task status, estimated arrival time of uncompleted route segments, changes in handover point capacity, new order information, road congestion events, and capacity delay reports. Based on this real-time execution feedback data, path freezing and dynamic replanning are performed on the initial collaborative delivery path results to address the unavoidable dynamic disturbances in real-world logistics scenarios, while avoiding execution chaos caused by global replanning. Specifically, each route segment in the initial collaborative delivery route result is first frozen based on two conditions: First, whether the distance from the delivery person's current location to the next node (pickup point or handover node) of the route segment is less than a preset distance threshold. The preset distance threshold is 500 to 1000 meters, determined based on average urban road speeds and typical rider response times after accepting orders. Second, whether the estimated arrival time is less than the agreed handover time for the route segment is less than a preset time threshold. The preset time threshold is 5 to 10 minutes, adjustable based on order urgency and handover node type. If either condition is met, the route segment is marked as a frozen route segment. A frozen route segment indicates that the execution plan for that task segment is unchangeable; any subsequent dynamic disturbances will not cause the system to modify the route and task allocation for that segment, thus ensuring the stability of tasks that are nearing completion or have been confirmed.

[0162] When the system receives a status change event, such as a new order, a delayed delivery capacity report, road congestion causing a delay in estimated arrival time, a handover point reaching capacity, or an order cancellation, the system first analyzes the range of path segments affected by the event. The specific analysis method is as follows: Based on the location of the event, the identified delivery capacity, and the estimated impact time, all potentially affected unexecuted path segments are located from the initial collaborative delivery path results. Next, it is determined whether the affected path segments contain any marked frozen path segments. If the affected path segments contain frozen path segments, no modification to those frozen path segments is required; instead, an alternative handover plan or an error message is output. For example, if a courier is expected to arrive at the handover point 10 minutes late due to traffic congestion, and the courier's current location is less than 500 meters from the handover point (i.e., the segment is frozen), the courier's original path will remain unchanged. Simultaneously, an error message will be sent to the upstream rider, suggesting that the rider transfer the order to other available delivery capacity or adjust their waiting strategy at the handover point. If the affected route segment does not contain any frozen route segments, rolling replanning is performed on the unexecuted route segments. Using the end point of the frozen route segment as the new starting point, local replanning is performed on the unexecuted route segments, and steps S3-S5 are re-executed. This involves constructing a candidate handover network, calculating the collaborative handover stability index, generating collaborative delivery task clusters, and performing joint route planning based on the latest order status, capacity location, handover point capacity, and road data, but limited to the unexecuted route segments; the frozen portions remain unchanged. After replanning, the newly generated route segments are concatenated with the original frozen route segments to form a complete executable collaborative delivery route result. This result is then redistributed to the relevant delivery personnel terminals and the handover facility management system to guide subsequent execution.

[0163] It should be noted that the path freezing and local replanning mechanisms described above maintain the stability of already executed tasks when dealing with dynamic disturbances, avoiding the execution chaos caused by global recalculation due to a single change affecting the entire system. This invention differs from traditional real-time replanning schemes, significantly improving the robustness and practical availability of the collaborative delivery system.

[0164] Please see Figure 2 As shown, the present invention is a logistics route planning system based on collaborative delivery, comprising:

[0165] The data processing module is used to acquire raw delivery data from multiple entities to obtain a collaborative delivery dataset; and to perform entity normalization and permission marking on the collaborative delivery dataset to obtain a collaborative delivery record set.

[0166] The order interchangeability parsing module is used to perform order interchangeability parsing on the collaborative delivery record set to obtain the order interchangeability result;

[0167] The handover node filtering module is used to construct a candidate handover network based on the order exchangeability results and handover point data, and to perform collaborative handover stability evaluation and filtering on the candidate handover network to obtain a set of stable handover nodes;

[0168] The order collaboration grouping module is used to collaboratively group the stable handover node set and the order exchangeable results to obtain collaborative delivery task clusters.

[0169] The collaborative path planning module is used to perform joint path planning on the collaborative delivery task cluster to obtain the initial collaborative delivery path result;

[0170] The path dynamic adjustment module is used to freeze and dynamically replan the initial collaborative delivery path results to obtain an executable collaborative delivery path result.

[0171] Please see Figure 3 As shown, compared with existing technologies, this invention demonstrates superior technical performance in terms of data sharing compliance, delivery fulfillment success rate, multi-entity collaboration acceptance rate, and dynamic disturbance response efficiency. Specifically, this invention achieves multi-entity data fusion by collecting multi-source heterogeneous delivery data and combining it with field mapping, entity normalization, and hierarchical permission marking processing, while ensuring the data privacy of each entity and achieving data usability without visibility. This solves the problems of data heterogeneity, privacy conflicts, and data sharing difficulties in existing collaborative delivery solutions. Simultaneously, by constructing an order exchangeable spatiotemporal envelope to quantitatively define the flexible boundaries of order collaboration, it achieves refined analysis of order exchangeability. Furthermore, it constructs a candidate handover network and builds an evaluation model from multiple dimensions, including time, capacity, transportation capacity, permissions, and cargo risk, to quantify the collaborative handover stability index, preemptively eliminating handover schemes with poor stability and significantly improving handover efficiency. Success rate of execution; by combining geographical location, cargo attributes, time window and node correlation to complete order clustering, and introducing entity benefit constraints to screen compliant task clusters, avoiding invalid order merging and ensuring the economic benefits of each carrier, and improving the willingness of multiple parties to cooperate; at the same time, this invention constructs a multi-dimensional comprehensive cost objective function for packages, and uses differentiated solution algorithms to complete joint route planning based on order size, overcoming the shortcomings of traditional route planning that only optimizes travel distance and ignores actual execution risks; finally, a route freezing and local rolling replanning mechanism is introduced to solidify the route segments that are close to execution, and only dynamically adjust the unexecuted route segments, avoiding execution chaos caused by global replanning under disturbance.

[0172] The above description is merely an example and illustration of the structure of the present invention. Those skilled in the art can make various modifications or additions to the specific embodiments described, or use similar methods to replace them, as long as they do not deviate from the structure of the invention or exceed the scope defined in the claims, all of which should fall within the protection scope of the present invention.

Claims

1. A logistics route planning method based on collaborative delivery, characterized in that, Includes the following steps: Obtain raw delivery data from multiple entities to obtain a collaborative delivery dataset; Subject normalization and permission marking are performed on the collaborative delivery dataset to obtain a collaborative delivery record set; Perform order exchangeability parsing on the collaborative delivery record set to obtain the order exchangeability results; Based on the exchangeable order results, a candidate handover network is constructed by combining the handover point data, and the candidate handover network is evaluated and screened for collaborative handover stability to obtain a set of stable handover nodes; The stable set of handover nodes and the order exchangeable results are grouped together to obtain a collaborative delivery task cluster; Perform joint path planning on the collaborative delivery task cluster to obtain the initial collaborative delivery path results; The initial collaborative delivery path results are frozen and dynamically replanned to obtain an executable collaborative delivery path result.

2. The logistics route planning method according to claim 1, characterized in that, Subject normalization and permission labeling are performed on the collaborative delivery dataset to obtain a collaborative delivery record set, including: The collaborative delivery dataset is mapped to fields and unified with entities to obtain a normalized intermediate dataset; A shareable level label is attached to each field of the normalized intermediate dataset to obtain a collaborative delivery record set; the shareable level label includes public fields, collaborative computing fields, and non-shareable fields.

3. The logistics route planning method according to claim 1, characterized in that, Perform order exchangeability parsing on the collaborative delivery record set to obtain order exchangeability results, including: Based on the collaborative delivery record set, the earliest pickup time, latest delivery time, estimated service duration, and safety buffer time for each order are extracted to determine the exchangeable time period; Extract the pickup and delivery locations for each order to determine the range of exchangeable space; Extract the product attributes, promised delivery time, and effective duration of insulated packaging for each order to determine the acceptable waiting time, and determine the number of handovers based on whether the order allows for mid-transit handover; The exchangeable time period, exchangeable spatial range, waiting time, number of handovers, and goods status restrictions together constitute the exchangeable spatiotemporal envelope of the order, forming the exchangeable result of the order.

4. The logistics route planning method according to claim 1, characterized in that, Based on the exchangeable order results, a candidate handover network is constructed using handover point data, including: Based on the exchangeable space range in the order exchangeable results, select the exchange nodes within that range from the exchange point data; Based on the capacity, available time period, and historical congestion level of each handover node, determine whether the handover node is available in the target time period and remove unavailable handover nodes. The remaining available handover nodes are used as candidate handover nodes. The order's pickup and receipt nodes are used as endpoints, and the candidate handover nodes are used as intermediate nodes to form a graph structure that includes nodes and edges, thus obtaining the candidate handover network.

5. The logistics route planning method according to claim 4, characterized in that, The candidate handover networks are evaluated and screened for collaborative handover stability to obtain a set of stable handover nodes, including: For each candidate handover scheme in the candidate handover network, calculate the scheme's time synchronization degree, node capacity matching degree, capacity margin matching degree, data permission matching degree, and cargo status risk degree. A pre-defined collaborative handover stability assessment model is established. The time synchronization degree, node capacity matching degree, capacity margin matching degree, data permission matching degree, and cargo status risk degree are substituted into the collaborative handover stability assessment model to obtain the collaborative handover stability index. The collaborative handover stability index is compared with a preset collaborative stability index threshold, and the handover nodes corresponding to candidate handover schemes that are greater than or equal to the collaborative stability index threshold are retained to obtain a set of stable handover nodes.

6. The logistics route planning method according to claim 1, characterized in that, The stable set of handover nodes and the order exchangeable results are grouped together to obtain a collaborative delivery task cluster, including: Data association mapping is performed on the stable set of handover nodes and the exchangeable results of orders to obtain the order-handover node association mapping table; Based on the order-handover node association mapping table, iterative clustering and grouping are performed to obtain an initial collaborative delivery task cluster; Based on the initial collaborative delivery task cluster, carrier allocation, cost accounting, and revenue constraint verification are performed to obtain a compliant and optimized collaborative delivery task cluster.

7. The logistics route planning method according to claim 6, characterized in that, The order-handover node association mapping table is iteratively clustered into groups to obtain an initial collaborative delivery task cluster, including: S4.3.1: Based on the order-handover node association mapping table, mark all orders as ungrouped; S4.3.2: Select an ungrouped order as a seed order, create a new candidate task cluster, and add the seed order to the candidate task cluster; S4.3.3: Traverse the remaining ungrouped orders. For each order to be inspected, determine whether it meets the preset grouping conditions simultaneously with all orders in the current candidate task cluster. If all conditions are met, add the order to the current candidate task cluster and update the joint constraints of the candidate task cluster. S4.3.4: Repeat sub-step S4.3.3 until no new orders can be added to the current candidate task cluster. At this point, the candidate task cluster is confirmed as an initial collaborative delivery task cluster, and all orders contained therein are marked as grouped. S4.3.5: Repeat sub-steps S4.3.2 to S4.3.4 until all orders are marked as grouped, resulting in the initial collaborative delivery task cluster.

8. The logistics route planning method according to claim 1, characterized in that, Joint path planning is performed on the collaborative delivery task cluster to obtain initial collaborative delivery path results, including: The path planning association data is extracted from the collaborative delivery task cluster to obtain the path planning association dataset; A comprehensive cost objective function is constructed based on the aforementioned path planning associated dataset; Under the preset constraints, the delivery sequence, handover nodes, handover time, and carrier allocation that minimize the overall cost objective function are solved to obtain the initial collaborative delivery path results.

9. The logistics route planning method according to claim 1, characterized in that, The initial collaborative delivery route results are frozen and dynamically replanned to obtain an executable collaborative delivery route result, including: Obtain real-time execution feedback data of the initial collaborative delivery route results; Extract the delivery person's current location, distance to the next node, and remaining handover time from the execution feedback data; determine whether each path segment in the initial collaborative delivery path result meets the freezing conditions; and mark the path segments that meet the freezing conditions as frozen path segments. When a state change event is received, it is determined whether the state change event affects the frozen path segment; If the state change event affects the frozen path segment, an alternative handover scheme or an error message will be output, and the frozen path segment will remain unchanged. If the state change event does not affect the frozen path segment, then the unexecuted path segment is replanned on a rolling basis, and the replanned path is concatenated with the frozen path segment to obtain an executable collaborative delivery path result.

10. A logistics route planning system based on collaborative delivery, characterized in that, The system, comprising the steps for implementing the method according to any one of claims 1-9, includes: The data processing module is used to acquire raw delivery data from multiple entities to obtain a collaborative delivery dataset; and to perform entity normalization and permission marking on the collaborative delivery dataset to obtain a collaborative delivery record set. The order interchangeability parsing module is used to perform order interchangeability parsing on the collaborative delivery record set to obtain the order interchangeability result; The handover node filtering module is used to construct a candidate handover network based on the order exchangeability results and handover point data, and to perform collaborative handover stability evaluation and filtering on the candidate handover network to obtain a set of stable handover nodes; The order collaboration grouping module is used to collaboratively group the stable handover node set and the order exchangeable results to obtain collaborative delivery task clusters. The collaborative path planning module is used to perform joint path planning on the collaborative delivery task cluster to obtain the initial collaborative delivery path result; The path dynamic adjustment module is used to freeze and dynamically replan the initial collaborative delivery path results to obtain an executable collaborative delivery path result.

Images