Cross-freight platform logistics demand collection, matching and dispatching method based on GPS positioning

Abstract

This invention discloses a GPS-based method for collecting, matching, and scheduling logistics demand across freight platforms, relating to the field of logistics scheduling technology. The method includes acquiring GPS positioning data (latitude, longitude, instantaneous speed, and vehicle orientation angle) via an onboard terminal; collecting on-the-go waybill data from multiple external freight platforms; calculating the straight-line distance between the vehicle and the waybill's origin and generating a distance matrix; filtering waybills within a preset economic radius to form a candidate set; and calculating the estimated empty-run time based on the vehicle's real-time driving status, using this as the core input parameter for matching and scheduling. This solution can construct a standardized distance data reference system, reduce the redundancy of scheduling data processing, adapt scheduling parameters to the actual driving conditions of vehicles, and enhance the accuracy and fit of cross-freight platform logistics matching and scheduling.

Description

Technical Field

[0001] This invention belongs to the field of logistics scheduling technology, specifically a method for collecting, matching, and scheduling logistics demands across freight platforms based on GPS positioning. Background Technology

[0002] In the current freight logistics scheduling field, scheduling work is mostly carried out using waybill data from a single freight platform. The distance between the freight vehicle and the waybill's origin is calculated individually based on the vehicle's latitude and longitude coordinates, and waybill matching is performed based on this distance value. Some scheduling solutions only calculate the distance between a single waybill and the vehicle, without establishing a systematic distance data processing method. The scheduling process directly performs matching and filtering on all external waybills without setting corresponding filtering boundaries based on the vehicle's economic operating range. Most existing scheduling solutions use distance as the core matching criterion, without integrating real-time vehicle driving status parameters to calculate empty-running time.

[0003] Simply calculating the distance between a vehicle and a waybill cannot establish a standardized distance data reference system, easily leading to chaotic comparisons of waybill distance data. A filtering mode without an economic radius will include a large number of waybills outside the economic operating range, increasing redundancy in dispatch data processing. Using only distance as the core dispatch parameter, without considering vehicle instantaneous speed and heading angle, cannot accurately calculate the empty-run time of vehicles to the waybill's origin, resulting in a disconnect between the selection of dispatch parameters and the actual driving status of the vehicles.

[0004] A systematic distance data processing mechanism between vehicles and the origin of waybills on multiple platforms needs to be established, and the scope of waybill screening should be determined based on economic radius. The empty-run time needs to be calculated by combining the vehicle's instantaneous speed, vehicle orientation angle, and the coordinates of the waybill's origin, and this time should be used as the core input parameter for matching and scheduling. Summary of the Invention

[0005] This invention aims to solve at least one of the technical problems existing in the prior art; To this end, the present invention proposes a GPS-based method for collecting, matching, and scheduling logistics demands across freight platforms, comprising: The GPS positioning data of the freight vehicle is obtained in real time through the on-board terminal deployed on the freight vehicle. The GPS positioning data includes latitude and longitude coordinates, instantaneous driving speed and vehicle orientation angle. Send data requests to multiple external freight platforms to obtain the in-transit waybill data of the multiple external freight platforms. The in-transit waybill data includes the coordinates of the origin of the goods, the coordinates of the destination of the goods, the volume and weight of the goods, and the expected arrival time. Based on the latitude and longitude coordinates in the GPS positioning data, the straight-line distance between the current location of the freight vehicle and the origin coordinates of the goods in each of the in-transit waybill data is calculated, and a distance matrix is ​​generated. Based on the distance matrix, the in-transit waybill data with a straight-line distance within a preset economic radius are selected to form a candidate waybill set; Using the instantaneous driving speed and vehicle orientation angle from the GPS positioning data, combined with the cargo origin coordinates in the candidate waybill set, the estimated empty driving time of the freight vehicle to each of the cargo origin coordinates is calculated. The estimated empty driving time serves as the core input parameter for matching and scheduling.

[0006] Furthermore, the step of sending data requests to multiple external freight platforms to obtain the in-transit waybill data of the multiple external freight platforms includes: Establish standardized application programming interface (API) communication links with various external freight platforms, wherein the standardized API communication links are used to transmit encrypted business data; According to the preset polling cycle, a waybill status query instruction is sent to the standardized application interface communication link. The waybill status query instruction is limited to retrieving only waybills with a status of pending acceptance or pending pickup. Receive waybill detail messages returned by the various external freight platforms, and parse the coordinates of the origin of the goods, the coordinates of the destination of the goods, the volume and weight of the goods, and the expected arrival time contained in the waybill detail messages; The parsed waybill data is classified and stored according to the source of the external freight platform to form a multi-source waybill pool, which provides the raw dataset for subsequent data cleaning.

[0007] Further, based on the latitude and longitude coordinates in the GPS positioning data, the straight-line distance between the current location of the freight vehicle and the origin coordinates of the goods in each of the in-transit waybill data is calculated, and a distance matrix is ​​generated, including: The current latitude and longitude coordinates of the freight vehicle are extracted from the GPS positioning data and used as the starting coordinates for distance calculation; Traverse each waybill in the candidate waybill set and extract the coordinates of the origin of the goods corresponding to the waybill, as the endpoint coordinates for distance calculation; The geospatial computing service is invoked to substitute each set of start and end coordinates into the spherical distance calculation model to obtain the actual ground distance between the two points. All the calculated actual ground distances are arranged into a two-dimensional array called the distance matrix according to the mapping relationship between the freight vehicles and the corresponding waybills. The rows and columns of the distance matrix correspond to the freight vehicle index and the waybill index, respectively.

[0008] Furthermore, using the instantaneous driving speed and vehicle orientation angle from the GPS positioning data, combined with the cargo origin coordinates in the candidate waybill set, the estimated empty driving time of the freight vehicle to each of the cargo origin coordinates is calculated, including: Based on the vehicle's orientation angle, the current latitude and longitude coordinates of the freight vehicle, and the cargo origin coordinates of a certain waybill in the candidate waybill set, the turning angle required for the vehicle to travel to the cargo origin is calculated. Retrieve preset road topology network data and find the optimal route plan that connects the current location of the freight vehicle with the coordinates of the origin of the goods. The optimal route plan includes the estimated path length. The instantaneous driving speed is converted to an hourly unit, and the estimated path length is divided by the converted instantaneous driving speed to obtain the preliminary driving time. By introducing the steering delay coefficient corresponding to the steering angle, the preliminary driving time is weighted and corrected to generate the final estimated empty driving time.

[0009] Furthermore, the step of introducing a steering delay coefficient corresponding to the steering angle to weight and correct the initial driving time, thereby generating the final estimated empty driving time, includes: Query the preset steering angle-delay coefficient mapping table, which defines fixed delay coefficient values ​​corresponding to different steering angle ranges; The calculated steering angle is matched with the angle range in the mapping table to determine the corresponding unique steering delay coefficient; Multiply the steering delay coefficient by the initial travel time to obtain the weighted and corrected travel time; Obtain historical traffic flow data of the road segment where the freight vehicle is currently located, and calculate a real-time traffic impact factor based on the historical traffic flow data; The corrected travel time is added to the real-time traffic impact factor to obtain the final estimated empty driving time, which is used for subsequent matching and scheduling decisions.

[0010] Furthermore, the method also includes a capacity load balancing step based on the expected empty running time: Obtain the current cargo status identifier of the freight vehicle, which is used to distinguish whether the vehicle is empty; If the cargo status is identified as empty, the estimated empty driving time is directly used as the time-efficiency cost corresponding to the freight vehicle in the matching calculation. If the cargo status is identified as not empty, the estimated empty driving time is added to the secondary driving time of the freight vehicle after unloading to the coordinates of the cargo origin, and the result is a composite time-efficiency cost. Sort all candidate waybills by their time-delivery costs, select waybills whose time-delivery costs are below a preset threshold, update the candidate waybill set, and remove waybills with excessively high time-delivery costs.

[0011] Furthermore, the method also includes a multi-dimensional matching constraint step that incorporates cargo attributes: Read the volumetric weight of each shipment in the candidate waybill set and compare it with the rated load and compartment volume of the freight vehicle to filter out waybills that exceed the carrying capacity. Extract the cargo type code for each shipment in the candidate waybill set, and verify whether the road transport permit of the freight vehicle includes the cargo type code. Check the difference between the expected arrival time and the current system time for each shipment in the candidate waybill set, and retain waybills with a difference greater than the estimated empty driving time to ensure that the vehicle can arrive at its destination before the expected arrival time. Waybills that pass the capacity verification, permitted scope verification, and time window verification will be identified as the final list of matchable waybills.

[0012] Furthermore, the method also includes a step for dynamically adjusting the priority of cross-platform waybills: The final list of matchable waybills shows the percentage of waybills originating from the same external freight platform. If the number of waybills from a certain external freight platform exceeds a preset monopoly threshold, a penalty weight will be applied to waybills from the external freight platform to reduce their sorting priority in the matching queue. Conversely, if a waybill from a certain external freight platform is not matched successfully for a long time, an incentive weight is applied to the waybill from that external freight platform to increase its ranking priority. Based on the adjusted sorting priority, rearrange the final list of matching waybills and output the adjusted matching sequence.

[0013] Furthermore, the method also includes steps for the immediate delivery and confirmation of matching results: From the adjusted matching sequence, the waybill with the highest ranking is selected as the target waybill; Generate a dispatch instruction that includes the identity information of the freight vehicle, the target waybill number, and the confirmed estimated arrival time; The dispatch command is sent to the vehicle terminal via wireless network, and a pop-up prompt is displayed on the human-machine interface of the vehicle terminal. The system monitors the driver confirmation feedback signal returned by the vehicle terminal. If the driver confirmation feedback signal is received, the status of the matching result is changed to locked, and the target waybill is removed from the candidate waybill set.

[0014] Furthermore, the method also includes a backtracking and recalculation step after a matching failure: If no confirmation signal from the driver is received within the preset waiting period, the matching operation will be marked as timed out. The expired target waybill is put back into the candidate waybill set, and its timeliness weight is adjusted to the highest level. A new round of matching calculation is triggered, and the comprehensive score of the remaining waybills in the candidate waybill set is recalculated using the updated weights; Repeat the scheduling process from screening to confirmation until the candidate waybill set is empty or the predetermined number of matching orders is reached.

[0015] Compared with the prior art, the beneficial effects of the present invention are: Based on the latitude and longitude coordinates of freight vehicle GPS positioning data, the straight-line distance between the vehicle's current location and the origin coordinates of goods on each in-transit waybill is calculated, and a distance matrix is ​​generated. This allows for the establishment of a systematic distance data carrier between vehicles and waybills from multiple platforms, creating a standardized reference system for distance data from different waybills and reducing the confusion in distance data comparisons. By filtering in-transit waybills whose straight-line distance is within a preset economic radius using the distance matrix, a candidate waybill set can be formed. Waybill data exceeding the economic operating range can be filtered out, reducing the data processing volume in the scheduling process and narrowing the coverage of scheduling screening.

[0016] By utilizing instantaneous vehicle speed and heading angle from GPS positioning data, and combining this with the coordinates of the originating points of goods in the candidate waybill set, the estimated empty-run time of the vehicle to each originating point can be calculated. This allows for the correlation between the real-time driving status of the vehicle and the location of the waybill's origin, ensuring that the calculation of empty-run time closely matches the actual driving conditions of the vehicle. Using the estimated empty-run time as the core input parameter for matching and scheduling can replace the traditional distance-based scheduling parameter selection method, ensuring that the selection of scheduling parameters matches the actual empty-running time status of the vehicle and optimizing the adaptability of the scheduling parameters. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating the steps of the GPS-based cross-freight platform logistics demand collection, matching, and scheduling method described in this invention. Figure 2 A flowchart illustrating how to send data requests to multiple external freight platforms; Figure 3 A flowchart for calculating the estimated empty running time. Detailed Implementation

[0018] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. 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 of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0019] See Figure 1 The system collects real-time GPS positioning data of freight vehicles via onboard terminals, including latitude and longitude coordinates, instantaneous speed, and vehicle heading angle. Simultaneously, it sends data requests to multiple connected external freight platforms to collect in-transit waybill data, including the coordinates of the goods' origin, destination, volume, weight, and expected arrival time. The matching and scheduling system calculates the straight-line distance between the freight vehicle's current location and the origin coordinates of each in-transit waybill, generating a distance matrix. Based on this matrix, it filters in-transit waybills whose straight-line distance falls within a preset economic radius, forming a candidate waybill set. Furthermore, the system uses the vehicle's instantaneous speed and heading angle, combined with the origin coordinates of the goods in the candidate waybill set, to calculate the estimated empty-trip time required for the freight vehicle to reach each origin. This estimated empty-trip time is the core input parameter for the final matching and scheduling decision.

[0020] In one embodiment of the present invention, see [reference] Figure 2 The external freight platforms include Freight Platform A, Freight Platform B, and Freight Platform C. The matching and scheduling system establishes independent standardized application programming interface (API) communication links with each of these platforms. These standardized API communication links are designed based on a RESTful architecture. The transport layer uses the TLS 1.3 protocol for communication encryption, and the application layer uses the AES-256-GCM algorithm to encrypt the transmitted business data packets. The keys are exchanged during the link initialization phase using asymmetric encryption. The matching and scheduling system sends structured waybill status query commands to each established standardized API communication link according to a preset, configurable polling period, such as a fixed time interval of 30 seconds. The waybill status query command is encapsulated in JSON format. The command body contains a filter field named "status," whose value is set to an array containing "PENDING_ACCEPT" and "PENDING_PICKUP," thus limiting the external freight platforms to only returning waybill records with a status of "pending acceptance" or "pending pickup."

[0021] After receiving the instruction, the external freight platform returns a response message containing waybill details. The matching and scheduling system receives waybill detail messages from freight platforms A, B, and C. The format of the waybill detail messages is pre-defined by each platform, and the matching and scheduling system deploys corresponding parser modules for different platform message formats. The parser module parses the waybill detail messages, extracting a pre-defined set of required fields. These required fields include: the coordinates of the origin of the goods expressed in latitude and longitude coordinates, the coordinates of the destination of the goods expressed in latitude and longitude coordinates, the volumetric weight of the goods in cubic meters and kilograms, and the expected arrival time expressed in Unix timestamp format. The parser module ensures that the coordinate format is uniformly in the WGS-84 coordinate system, the weight and volume units are uniform, and the time format is uniformly the system's internal timestamp. It can be understood that the parsing process also includes basic data validation, such as checking whether the latitude and longitude coordinates are within a valid range and whether the cargo weight is positive.

[0022] After parsing, the waybill data is categorized and stored according to its source platform identifier. In specific implementations, the platform identifier is a unique string encoding that identifies an external freight platform, such as "PLATFORM_A". The matching and scheduling system maintains a multi-source waybill pool, which is physically a distributed database with table partitioning capabilities. The database creates an independent partition table for each access platform identifier; data from freight platform A is stored in the "platform_a_orders" table, and data from freight platform B is stored in the "platform_b_orders" table. Each waybill data record, in addition to containing the parsed core fields, also stores the data collection timestamp, platform identifier, and original waybill number. As a structured data collection aggregating multiple heterogeneous data sources, the multi-source waybill pool provides the raw dataset for subsequent data cleaning, deduplication, and standardization processes. In some embodiments, each record in the multi-source waybill pool is set with an expiration time; the system periodically cleans up historical waybill data that has exceeded the predetermined validity period to ensure the timeliness of the data in the pool.

[0023] During data acquisition, the matching and scheduling system needs to handle network anomalies and platform interface return errors. The system sets connection and read timeouts for each request sent to the standardized application interface communication link. When a request times out or receives an HTTP error status code, the system records the request failure and retryes the link with the same platform identifier in the next polling cycle. After the maximum number of retries is reached, the system marks the platform identifier as "connection abnormal" and temporarily stops collecting data from that platform, while sending an alarm to the system monitoring module. When the waybill details message returned by an external freight platform has an incorrect format or lacks required fields, the parser module discards the unparseable message and records the error message content in the error log for subsequent troubleshooting and analysis. This fault-tolerance mechanism ensures the robustness of the core functions of the matching and scheduling system in multi-source data acquisition scenarios, preventing the overall scheduling process from being affected by the temporary unavailability of a single platform's data interface.

[0024] The establishment and maintenance of standardized application programming interface (API) communication links is an ongoing process. In practice, whenever a new external freight platform needs to connect, its access parameters must be registered in the configuration management module of the matching and scheduling system. These access parameters include the platform's base URL, authentication key, data encryption key pair, message format definition file, and initial polling cycle. Based on the access parameters, the matching and scheduling system dynamically generates the corresponding API client instance and establishes a new standardized API communication link. All established standardized API communication links are managed by a unified connection pool, which is responsible for link health checks, connection reuse, and load balancing. Through this approach, the matching and scheduling system can continuously collect in-transit waybill data from multiple external freight platforms in a standardized and scalable manner, integrating and storing multi-source heterogeneous data in a multi-source waybill pool, providing stable and reliable data input for subsequent matching calculations.

[0025] In one embodiment of the present invention, see [reference] Figure 3The implementation method for calculating the distance matrix and estimated empty driving time involves the matching and scheduling system extracting the latest and valid positioning points from the GPS positioning data stream continuously reported by the vehicle terminal. These positioning points include latitude, longitude, speed, and heading angle data. GPS positioning data is typically uploaded to the matching and scheduling system's data receiver via a wireless network in JSON format. The data receiver verifies the integrity and timeliness of the message and extracts the values ​​of the "latitude," "longitude," "speed," and "heading" fields. These values ​​are used as the current latitude and longitude coordinates, instantaneous speed, and heading angle of the freight vehicle. The current latitude and longitude coordinates are used as the starting point coordinates for distance calculation and are recorded in memory for subsequent calculations. During data extraction, the system filters out stationary points with zero speed for more than five minutes and inaccurate points with a horizontal positioning accuracy factor greater than a set threshold to ensure the validity of the starting point coordinates.

[0026] The distance matrix calculation process is based on a candidate waybill set, which consists of waybills that have undergone initial screening and whose straight-line distance to the freight vehicle is within a preset economic radius. The matching and scheduling system traverses each waybill record in the candidate waybill set, extracting the value of the cargo origin coordinate field from the waybill record. The cargo origin coordinate is a tuple containing latitude and longitude, which serves as the endpoint coordinate for distance calculation. The system then calls an integrated open-source geospatial computing library, such as "GeographicLib" or a similar library, to pair the current latitude and longitude coordinates of the freight vehicle with the cargo origin coordinates of each waybill, passing them as input parameters to the spherical distance calculation function. The spherical distance calculation function is based on the WGS-84 Earth ellipsoid model, calculating the actual ground distance between two points along the shortest arc on the Earth's surface. The calculation process considers the Earth's oblateness, and its core calculation formula can be expressed as a high-precision inverse geographic distance formula. In some embodiments, to improve computational efficiency, when the distance between the cargo origin coordinates of all waybills and the current location of the vehicle is very small relative to the Earth's radius... Multiplying the calculated central angle by the Earth's average radius yields the actual ground distance. The system organizes all calculated actual ground distance values ​​into a two-dimensional array structure—the distance matrix—based on the mapping between the unique identifier of the freight vehicle and the unique identifier of each waybill in the candidate waybill set. Each row of the distance matrix corresponds to a freight vehicle; in a single-vehicle dispatching scenario, the distance matrix degenerates into a row vector. Each column of the distance matrix corresponds to a waybill in the candidate waybill set, and the elements in the matrix... Indicates the first The car arrived at the The actual ground distance from the place of origin of the goods on the waybill.

[0027] The estimated empty driving time is calculated based on the distance matrix and further integrated with the vehicle's dynamic driving information. The matching and scheduling system performs vector geometry operations based on the vehicle's current latitude and longitude coordinates, vehicle orientation angle, and the cargo origin coordinates of a target waybill in the candidate waybill set to calculate the minimum turning angle required for the vehicle to reach the cargo origin. The calculation process involves converting the vehicle's current position and cargo origin coordinates into Cartesian space vectors, converting the vehicle orientation angle into a unit direction vector, and calculating the angle between the vehicle's current direction vector and the direction vector pointing to the cargo origin to obtain the turning angle. The turning angle ranges from 0 to 180 degrees. In some embodiments, the system retrieves pre-loaded road topology network data covering the area where the vehicle's current position and cargo origin are located. The road topology network data is stored in a graph structure, where nodes represent road intersections or key points, and edges represent road segments with length attributes. In the graph constructed by the road topology network data, the system uses the projection point of the vehicle's current position as the starting point and the projection point of the cargo origin coordinates as the ending point, and runs the A-pathfinding algorithm to find the optimal path planning connecting the two points. The heuristic function of Algorithm A uses the Euclidean distance between two points. The result of optimal path planning includes an ordered sequence of path nodes and an estimated path length obtained by accumulating the path edge lengths.

[0028] After obtaining the estimated path length, the matching and scheduling system converts the instantaneous speed in the GPS positioning data to different units. Instantaneous speed is usually measured in meters per second (m / s). The system multiplies the instantaneous speed by 3.6 to convert it to kilometers per hour (km / h). The estimated path length derived from optimal path planning is divided by the converted instantaneous speed to obtain the theoretical preliminary travel time. In practice, the system sets a lower threshold for instantaneous speed. For example, when the instantaneous speed is less than 1 m / s, the system uses the historical average speed of that road segment or the default design speed of urban roads as the calculation benchmark to avoid the calculated travel time being infinitely large due to brief vehicle stops. The calculated preliminary travel time is in hours and is a floating-point number. It can be understood that introducing road topology network data for path planning, compared to directly dividing the straight-line distance by the speed, more accurately reflects the mileage that the vehicle needs to travel in the actual road network, thereby improving the accuracy of the estimated empty-run time calculation.

[0029] The system introduces a steering delay coefficient calculated based on the steering angle to weighted correct the initial travel time. The steering delay coefficient is a real number greater than or equal to 1, and its value is positively correlated with the calculated steering angle. A larger steering angle means a more complex steering maneuver is required, resulting in a larger steering delay coefficient. The matching and scheduling system pre-defines a table corresponding to steering angles and steering delay coefficients, obtaining specific coefficient values ​​through table lookup. Multiplying the initial travel time by the steering delay coefficient yields the weighted corrected estimated empty travel time. For example, if the initial travel time is 0.5 hours, and a steering delay coefficient of 1.1 corresponds to a steering angle of 60 degrees, then the corrected estimated empty travel time is 0.55 hours. Through these steps, the matching and scheduling system completes the conversion from spatial distance calculation to time cost estimation, with the generated estimated empty travel time serving as the core input parameter for matching and scheduling decisions.

[0030] In one embodiment of the present invention, the matching and scheduling system internally maintains a preset steering angle-delay coefficient mapping table, which is a static, predefined lookup table data structure. The steering angle-delay coefficient mapping table is loaded into memory from the configuration file during system initialization. The mapping table is stored in key-value pairs, where the key is the range of steering angles and the value is the corresponding fixed delay coefficient value. For example, the steering angle-delay coefficient mapping table might contain the following entries: a steering angle range of [0°, 30°] corresponds to a delay coefficient value of 1.0, a steering angle range of (30°, 60°) corresponds to a delay coefficient value of 1.1, a steering angle range of (60°, 90°) corresponds to a delay coefficient value of 1.2, and a steering angle range of (90°, 180°) corresponds to a delay coefficient value of 1.4. The matching and scheduling system will compare the specific vehicle steering angle values ​​calculated in Example 2 with each angle range defined in the steering angle-delay coefficient mapping table. The comparison logic is to check which angle range the steering angle value falls into. When the steering angle value is greater than or equal to the lower limit of the range and less than or equal to the upper limit of the range, it is considered a successful match. Once a successful match is achieved, the system will extract the fixed delay coefficient value associated with this angle range as the unique steering delay coefficient used in this calculation.

[0031] In practice, the matching and dispatching system obtains historical traffic flow data of the current road segment of a freight vehicle from internal cache or external third-party traffic data service interfaces. The current road segment of the freight vehicle is determined by matching the vehicle's latest GPS positioning coordinates with the road segment ID in the road topology network data. Historical traffic flow data typically includes indicators such as the average speed and historical average travel time on that road segment over the past few days, the same week type, and the same time period. Historical traffic flow data is stored in a structured form in the traffic database and can be retrieved using the road segment ID and timestamp as a joint query key. Based on the retrieved historical traffic flow data, the system calculates a real-time traffic impact factor. The purpose of calculating the real-time traffic impact factor is to quantify the deviation between the current actual or predicted traffic conditions and the historical average level. The calculation process is as follows: first, the vehicle's current instantaneous speed is obtained; then, the historical average speed of the current road segment during the same time period is retrieved; the road segment length is divided by both the current instantaneous speed and the historical average speed to obtain the estimated current travel time and the estimated historical average travel time; the difference between these two travel time estimates is the real-time traffic impact factor. For example, if the road segment is 5 kilometers long and the current instantaneous speed is 30 km / h, the estimated current travel time is 10 minutes; if the historical average speed is 40 km / h, the estimated historical average travel time is 7.5 minutes; the real-time traffic impact factor is then 10 - 7.5 = 2.5 minutes. In some embodiments, the calculation of the real-time traffic impact factor can be simplified by directly using the ratio of the current instantaneous speed to the historical average speed, and then mapping it to a delay in minutes using a preset conversion coefficient. Regardless of the specific calculation method used, the output of the real-time traffic impact factor is a value in minutes. A positive value indicates that the current road conditions are more congested than the historical average, which will lead to additional delays; a negative value indicates that the current road conditions are smoother than the historical average, which may result in time savings.

[0032] After determining the turning delay coefficient and the real-time traffic impact factor, the matching and scheduling system performs the final estimated empty-run time calculation. The turning delay coefficient is a unitless scaling factor, and the initial travel time is a time value in hours; the two are combined through multiplication. Multiplying the turning delay coefficient by the initial travel time yields the weighted corrected travel time. The corrected travel time is still in hours, but it already includes the estimated time loss due to turning operations. It can be understood that if the turning delay coefficient is greater than 1, the corrected travel time will be greater than the initial travel time. Next, the system algebraically adds the corrected travel time to the real-time traffic impact factor. Before adding, the units need to be standardized, either converting the corrected travel time from hours to minutes, or converting the real-time traffic impact factor from minutes to hours, to ensure consistency. Assuming the corrected travel time is 0.55 hours (converted to 33 minutes) and the real-time traffic impact factor is +2.5 minutes, the final estimated empty-run time is 33 minutes + 2.5 minutes = 35.5 minutes. In some embodiments, the final estimated empty-running time can be standardized to minutes or hours and stored as a floating-point number in a memory variable for subsequent capacity load balancing and multi-dimensional matching constraint steps. The formula for calculating the final estimated empty-running time can be expressed as follows: Where: symbol Indicates the final estimated empty running time, symbol Indicates the initial travel time, symbol Represents the turning delay coefficient, symbol This represents the real-time traffic impact factor.

[0033] In one embodiment of the present invention, before calculating costs and filtering, the matching and scheduling system first obtains the cargo status identifier periodically reported by freight vehicles through their onboard terminals. The cargo status identifier is an enumerated variable, with possible values ​​including "empty," "partially loaded," and "fully loaded," used to distinguish the vehicle's current cargo status. The system reads the corresponding vehicle's cargo status identifier from the vehicle status database. If the cargo status identifier is "empty," the matching and scheduling engine directly uses the estimated empty driving time calculated for each candidate waybill as the time-efficiency cost representing the freight vehicle's obligation to accept this waybill during subsequent cost calculations and sorting. This time-efficiency cost is a time value in minutes and directly enters the subsequent sorting and comparison process. If the cargo status identifier is not "empty," for example, "partially loaded" or "fully loaded," it means the freight vehicle is performing an existing transportation task, and the system needs to calculate a composite time-efficiency cost. The calculation of composite transit cost consists of two parts. The first part is the time required for the vehicle to complete the current task, arrive at the current cargo destination, and unload the cargo. The second part is the secondary travel time required for the vehicle to travel from the current cargo destination to the origin coordinates of the new candidate waybill cargo. The calculation method for the secondary travel time is similar to that for calculating the estimated empty travel time, but the starting coordinates are the estimated unloading coordinates of the current task. The calculated estimated empty travel time and the secondary travel time are added together to obtain the total composite transit cost. This composite transit cost will be used as the transit cost for the vehicle to accept this new waybill in subsequent comparisons.

[0034] After determining the cargo loading status and calculating the time-sensitive cost, the system sorts all candidate waybills by their time-sensitive costs. The sorting is done from smallest to largest time-sensitive cost, generating an ordered list. The system reads a preset time-sensitive cost threshold, which is a configurable parameter, such as 120 minutes. The matching and scheduling system iterates through the ordered list, selecting all waybills whose time-sensitive costs are below the preset threshold. Waybills with time-sensitive costs above the threshold are considered non-time-sensitive and removed from the current candidate waybill set. The updated candidate waybill set only includes waybills whose vehicles can reach the origin within a reasonable empty-run time. This method achieves initial capacity load balancing, avoiding the inclusion of waybills with excessively long distances or requiring lengthy detours in subsequent, more complex matching calculations, thus improving overall computational efficiency.

[0035] The multi-dimensional matching constraint step, incorporating cargo attributes, is executed after capacity load balancing. The matching and scheduling system reads the cargo volume and weight data for each shipment from the updated candidate waybill set, with cargo volume in cubic meters and cargo weight in kilograms. The system queries the vehicle's rated load capacity and cargo compartment volume parameters from the vehicle file database, with rated load capacity in kilograms and cargo compartment volume in cubic meters. The system compares the cargo volume of each shipment with the vehicle's rated load capacity and cargo compartment volume, using the following criteria: cargo weight ≤ vehicle rated load capacity and cargo volume ≤ vehicle cargo compartment volume. Waybills that do not meet either of these criteria—that is, waybills with cargo weight exceeding the vehicle's rated load capacity or cargo volume exceeding the vehicle's cargo compartment volume—are filtered out. In some embodiments, the system considers the vehicle's current cargo loading status. If the vehicle's cargo status is marked as "partially loaded," the system retrieves the total volume and weight of the loaded cargo from the vehicle's current task. During comparison, the volume and weight of the cargo for the candidate new waybill are added to the currently loaded cargo, and then compared with the vehicle's rated load capacity and cargo compartment volume. This load-bearing capacity verification ensures that the waybills assigned to the vehicle are within its physical load-bearing capacity.

[0036] After completing the carrying capacity verification, the system extracts the cargo type code for each shipment in the candidate waybill set. The cargo type code is a standardized code used to identify the type of cargo, such as general cargo, cold chain cargo, dangerous goods, or oversized cargo. The system verifies the electronic file of the freight vehicle's road transport permit, which stores the range of cargo types the vehicle is permitted to transport, presented as a list of permitted cargo type codes. The system checks whether the cargo type code of the candidate waybill is included in the list of permitted cargo type codes on the vehicle's road transport permit. If the cargo type code of the candidate waybill is not in the permitted list, the waybill will be filtered. For example, a waybill with the cargo type code "Dangerous Goods-Class 3" cannot be transported by a vehicle whose permitted scope is only "general cargo." It can be understood that the permitted scope verification ensures that the transport capacity matching complies with national road transport regulations, which is a necessary prerequisite for safe transportation.

[0037] In practice, the system performs a time window check. This check examines the difference between the expected arrival time of each shipment in the candidate waybill set and the current system time; this difference is called the available transportation time window. The system calculates the estimated empty-run time for the vehicle to reach the shipment's origin, including turning delays and traffic impacts. The check logic is to determine if the available transportation time window is greater than the estimated empty-run time. The available transportation time window is the total time the vehicle has from the current moment to the expected arrival time of the goods, while the estimated empty-run time is the estimated time the vehicle will take to travel to the origin. If the available transportation time window is greater than the estimated empty-run time, it means that after arriving at the origin, the vehicle still has enough time for pickup, travel to the destination, and delivery before the expected arrival time; the waybill is retained. If the available transportation time window is less than or equal to the estimated empty-run time, it means the vehicle may not be able to arrive at the origin before the expected arrival time, or there may not be enough time to complete subsequent transportation after arrival; the waybill is filtered out. Waybills that pass the capacity verification, permitted scope verification, and time window verification are identified as the final list of matchable waybills and await priority sorting.

[0038] The dynamic priority adjustment step for cross-platform waybills applies to the final list of matchable waybills. The matching and scheduling system counts the number of waybills from each external freight platform in the final list of matchable waybills. The system calculates the proportion of waybills from each external freight platform to the total number of waybills in the final list of matchable waybills; this proportion is called the platform waybill percentage. The system presets a monopoly threshold, for example, 60%. The system iterates through all connected external freight platforms, checking whether the platform waybill percentage of each platform exceeds the preset monopoly threshold. If the platform waybill percentage of any external freight platform exceeds the preset monopoly threshold, the matching and scheduling system applies a penalty weight to all waybills from that external freight platform. The penalty weight is a positive floating-point number less than 1.0, for example, 0.9. The system multiplies the original matching score of these waybills (which may be calculated based on timeliness, cost, price, cargo matching degree, etc.) by the penalty weight, thereby reducing the ranking priority of these waybills in the matching queue. The application of the penalty weight aims to prevent a single platform from excessively dominating the matching results and promote fair scheduling of transportation resources among multiple platforms. The calculation logic for the platform's order percentage and penalty adjustment is shown in Table 1 below: Table 1: Calculation Logic of Platform Waybill Proportion and Penalty Adjustment In practice, the system also maintains a historical matching success rate record for waybills from each platform. If the matching scheduling system discovers through log analysis that a waybill from a certain external freight platform has not been successfully matched for multiple consecutive matching cycles (e.g., 5 consecutive cycles), the system will apply an incentive weight to all waybills originating from that external freight platform. The incentive weight is a positive floating-point number greater than 1.0, such as 1.1. The system multiplies the original matching score of these waybills by the incentive weight, thereby increasing their ranking priority. In some embodiments, the magnitude of the incentive weight can be positively correlated with the number of consecutive unmatched cycles; the more cycles, the larger the incentive weight, but not exceeding a preset upper limit. The purpose of applying the incentive weight is to increase the exposure opportunity of waybills from platforms with low matching rates and promote the overall efficiency of waybill processing. Based on the new matching score adjusted by the penalty weight or incentive weight, the matching scheduling system reorders the final list of matchable waybills in descending order. The calculation formula for the score adjustment can be expressed as: Where: symbol Indicates the adjusted matching score, symbol Indicates the original matching score of the waybill, symbol This indicates the applied weighting factor. The rule for determining the value is: if the platform's order volume exceeds the monopoly threshold, then... (Penalty weight, less than 1); if the platform's order fails to match successfully for an extended period, then... (Incentive weight, greater than 1); otherwise, After rearranging, the waybills at the top of the list have the highest adjusted matching score, which is the waybill with the highest current recommended matching priority. The system outputs this adjusted matching sequence.

[0039] In one embodiment of the present invention, after dynamically adjusting the priority of cross-platform waybills, the matching and scheduling engine obtains a final matching sequence sorted in descending order of the adjusted matching scores. From the adjusted matching sequence, the matching and scheduling engine selects the waybill ranked first and designates it as the target waybill, which is the best matching option currently recommended to the corresponding freight vehicle. The target waybill contains complete waybill information obtained from the external freight platform, including waybill number, cargo details, origin and destination coordinates, and expected arrival time. The matching and scheduling system generates a structured scheduling instruction, encapsulated in JSON format. Key fields included in the scheduling instruction are: a unique identifier of the freight vehicle making the scheduling request, such as the vehicle's VIN or license plate number; the device number of the on-board terminal; the unique number of the target waybill in the source platform and the matching and scheduling system; the system-calculated and confirmed expected arrival time of the vehicle at the cargo origin; and the detailed address information of the cargo origin. In some embodiments, the scheduling instruction also includes an operation time limit field, indicating how long the driver must respond to the instruction.

[0040] The matching and dispatching system sends encapsulated dispatch instructions to the onboard terminal bound to the target freight vehicle via a wireless communication network, which can be 4G, 5G, or a dedicated IoT network. The dispatch instructions are pushed to the onboard terminal asynchronously via MQTT protocol or HTTP long connection. Upon receiving the dispatch instructions, the onboard terminal's application displays a pop-up notification on the human-machine interface in the driver's cockpit. The pop-up highlights the core information of the waybill, such as "New waybill: From XX warehouse to XX logistics park, estimated income XXX yuan, required arrival before X o'clock. Estimated pickup time: X minutes later," and provides two clear interactive buttons: "Confirm Order" and "Reject." The driver provides feedback by clicking the corresponding button on the touchscreen. The onboard terminal packages the driver's selection, along with the terminal device number and instruction reception timestamp, into a confirmation feedback signal and transmits it back to the matching and dispatching system via the wireless network. The matching and dispatching system sets up a listening process to continuously monitor the confirmation feedback signals from each onboard terminal.

[0041] In practice, the matching and scheduling system receives a driver confirmation feedback signal from the target vehicle's onboard terminal. This confirmation feedback signal is a structured message containing the instruction confirmation status, the target waybill number, the vehicle identifier, and a timestamp. After parsing the confirmation feedback signal and verifying its validity, the system changes the status of this matching result from "pending confirmation" to "locked" in the system database. The locked status indicates that the matching relationship between the waybill and the vehicle has been established, and the fulfillment process begins. Simultaneously, the system removes the target waybill from the candidate waybill set for the current processing cycle and marks its status as "dispatched" from the multi-source waybill pool to prevent the same waybill from being repeatedly matched to other vehicles in subsequent scheduling cycles. In some embodiments, after receiving confirmation, the system also sends an order acceptance confirmation notification to the external freight platform that is the source of the target waybill via a standard application programming interface (API) communication link, notifying the external freight platform that the waybill has been received by a specific vehicle, thus completing cross-platform status synchronization.

[0042] The matching and dispatching system presets a waiting period, which is the maximum allowed time from when a driver receives a dispatch instruction to when they respond. The system's monitoring process starts a countdown timer for the matching operation simultaneously with the dispatch instruction. If, within the preset waiting period, the system does not receive a driver confirmation signal from the target vehicle's onboard terminal, or if the received signal is "rejection," the system marks the matching operation as timed out. This timeout status is recorded in the matching log, which includes the matching operation ID, target waybill number, vehicle identifier, dispatch instruction issuance time, timeout duration, and reason for failure. The system then processes timed-out matching operations by re-marking the target waybill that failed to lock in the match attempt as available and returning it to the currently valid candidate waybill set. This return operation allows the waybill to be reconsidered in subsequent matching calculations.

[0043] After the target waybill is returned to the candidate waybill set, the matching and scheduling system adjusts its weight parameters. Specifically, the system adjusts the waybill's timeliness weight to the highest level. Timeliness weight is a factor in the waybill matching score calculation, related to the estimated empty-run time. Adjusting it to the highest level means that in subsequent matching score calculations, the waybill's timeliness factor will receive a larger calculation coefficient, thus improving its overall matching score. For example, if the original timeliness weight factor was 1.0, adjusting it to the highest level makes it 1.5, resulting in a higher weighting for timeliness in the overall matching score calculation, thus placing it higher in the ranking. After completing the weight adjustment for the target waybill, the system immediately triggers a new round of matching calculation. This new round uses an updated candidate waybill set, which includes waybills that were not successfully assigned previously and the target waybill with adjusted weights. The system recalculates the overall matching score for all remaining waybills in the candidate waybill set using the updated weights. The formula for calculating the overall matching score considers multiple dimensions, and its general form can be expressed as: Where: symbol The overall matching score of the waybill is represented by the symbol. These represent weighting coefficients for different dimensions such as timeliness, revenue, platform balance, and cargo matching, with symbols... Based on the estimated empty running time The time-dependent function, symbol It is a revenue function based on freight costs, symbol It is a platform-based equilibrium function, symbol... It is a function based on the matching degree of cargo attributes. For waybills with increased weight, their performance in the function... Some parts will receive higher calculated values, thus improving the overall matching score. After recalculation, the system re-executes the complete scheduling process, from screening the candidate order set, calculating costs, performing multi-dimensional constraint filtering, dynamically adjusting platform priorities, to generating and issuing new scheduling instructions, and waiting for driver confirmation. This loop continues until the candidate order set for the current matching scheduling cycle becomes empty, meaning all matchable orders have been successfully assigned or ultimately filtered out, or the system has reached the predetermined number of matching orders to be completed within this cycle. For example, if the system is set to complete at least 20 matching orders within a scheduling cycle, when the number of successfully matched and confirmed orders reaches 20, the system may enter a dormant state, waiting for the next scheduling cycle to begin, even if the candidate order set is not empty. Through this backtracking and recalculation mechanism after matching failures, the system can dynamically respond to drivers' non-confirmation behavior, optimize resource reallocation, and improve the overall order matching success rate and efficiency.

[0044] The above embodiments are only used to illustrate the technical methods of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical methods of the present invention without departing from the spirit and scope of the technical methods of the present invention.

Claims

1. A method for collecting, matching, and scheduling logistics demand across freight platforms based on GPS positioning, characterized in that, The method includes: The GPS positioning data of the freight vehicle is obtained in real time through the on-board terminal deployed on the freight vehicle. The GPS positioning data includes latitude and longitude coordinates, instantaneous driving speed and vehicle orientation angle. Send data requests to multiple external freight platforms to obtain the in-transit waybill data of the multiple external freight platforms. The in-transit waybill data includes the coordinates of the origin of the goods, the coordinates of the destination of the goods, the volume and weight of the goods, and the expected arrival time. Based on the latitude and longitude coordinates in the GPS positioning data, the straight-line distance between the current location of the freight vehicle and the origin coordinates of the goods in each of the in-transit waybill data is calculated, and a distance matrix is ​​generated. Based on the distance matrix, the in-transit waybill data with a straight-line distance within a preset economic radius are selected to form a candidate waybill set; Using the instantaneous driving speed and vehicle orientation angle from the GPS positioning data, combined with the cargo origin coordinates in the candidate waybill set, the estimated empty driving time of the freight vehicle to each of the cargo origin coordinates is calculated. The estimated empty driving time serves as the core input parameter for matching and scheduling.

2. The method for collecting, matching, and scheduling logistics demand across freight platforms based on GPS positioning according to claim 1, characterized in that, The step of sending data requests to multiple external freight platforms and obtaining in-transit waybill data from these platforms includes: Establish standardized application programming interface (API) communication links with various external freight platforms, wherein the standardized API communication links are used to transmit encrypted business data; According to the preset polling cycle, a waybill status query instruction is sent to the standardized application interface communication link. The waybill status query instruction is limited to retrieving only waybills with a status of pending acceptance or pending pickup. Receive waybill detail messages returned by the various external freight platforms, and parse the coordinates of the origin of the goods, the coordinates of the destination of the goods, the volume and weight of the goods, and the expected arrival time contained in the waybill detail messages; The parsed waybill data is classified and stored according to the source of the external freight platform to form a multi-source waybill pool, which provides the raw dataset for subsequent data cleaning.

3. The method for collecting, matching, and scheduling logistics demand across freight platforms based on GPS positioning according to claim 1, characterized in that, Based on the latitude and longitude coordinates in the GPS positioning data, the straight-line distance between the current location of the freight vehicle and the origin coordinates of the goods in each of the in-transit waybill data is calculated, and a distance matrix is ​​generated, including: The current latitude and longitude coordinates of the freight vehicle are extracted from the GPS positioning data and used as the starting coordinates for distance calculation; Traverse each waybill in the candidate waybill set and extract the coordinates of the origin of the goods corresponding to the waybill, as the endpoint coordinates for distance calculation; The geospatial computing service is invoked to substitute each set of start and end coordinates into the spherical distance calculation model to obtain the actual ground distance between the two points. All the calculated actual ground distances are arranged into a two-dimensional array called the distance matrix according to the mapping relationship between the freight vehicles and the corresponding waybills. The rows and columns of the distance matrix correspond to the freight vehicle index and the waybill index, respectively.

4. The method for collecting, matching, and scheduling logistics demands across freight platforms based on GPS positioning according to claim 1, characterized in that, Using the instantaneous driving speed and vehicle orientation angle from the GPS positioning data, and combining them with the cargo origin coordinates in the candidate waybill set, the estimated empty driving time of the freight vehicle to each of the cargo origin coordinates is calculated, including: Based on the vehicle's orientation angle, the current latitude and longitude coordinates of the freight vehicle, and the cargo origin coordinates of a certain waybill in the candidate waybill set, the turning angle required for the vehicle to travel to the cargo origin is calculated. Retrieve preset road topology network data and find the optimal route plan that connects the current location of the freight vehicle with the coordinates of the origin of the goods. The optimal route plan includes the estimated path length. The instantaneous driving speed is converted to an hourly unit, and the estimated path length is divided by the converted instantaneous driving speed to obtain the preliminary driving time. By introducing the steering delay coefficient corresponding to the steering angle, the preliminary driving time is weighted and corrected to generate the final estimated empty driving time.

5. The method for collecting, matching, and scheduling logistics demands across freight platforms based on GPS positioning according to claim 4, characterized in that, The step of introducing a steering delay coefficient corresponding to the steering angle to weight and correct the initial driving time, and generating the final estimated empty driving time, includes: Query the preset steering angle-delay coefficient mapping table, which defines fixed delay coefficient values ​​corresponding to different steering angle ranges; The calculated steering angle is matched with the angle range in the mapping table to determine the corresponding unique steering delay coefficient; Multiply the steering delay coefficient by the initial travel time to obtain the weighted and corrected travel time; Obtain historical traffic flow data of the road segment where the freight vehicle is currently located, and calculate a real-time traffic impact factor based on the historical traffic flow data; The corrected travel time is added to the real-time traffic impact factor to obtain the final estimated empty driving time, which is used for subsequent matching and scheduling decisions.

6. The method for collecting, matching, and scheduling logistics demand across freight platforms based on GPS positioning according to claim 1, characterized in that, The method also includes a capacity load balancing step based on the expected empty running time: Obtain the current cargo status identifier of the freight vehicle, which is used to distinguish whether the vehicle is empty; If the cargo status is identified as empty, the estimated empty driving time is directly used as the time-efficiency cost corresponding to the freight vehicle in the matching calculation. If the cargo status is identified as not empty, the estimated empty driving time is added to the secondary driving time of the freight vehicle after unloading to the coordinates of the cargo origin, and the result is a composite time-efficiency cost. Sort all candidate waybills by their time-delivery costs, select waybills whose time-delivery costs are below a preset threshold, update the candidate waybill set, and remove waybills with excessively high time-delivery costs.

7. The method for collecting, matching, and scheduling logistics demands across freight platforms based on GPS positioning according to claim 6, characterized in that, The method also includes a multi-dimensional matching constraint step that incorporates cargo attributes: Read the volumetric weight of each shipment in the candidate waybill set and compare it with the rated load and compartment volume of the freight vehicle to filter out waybills that exceed the carrying capacity. Extract the cargo type code for each shipment in the candidate waybill set, and verify whether the road transport permit of the freight vehicle includes the cargo type code. Check the difference between the expected arrival time and the current system time for each shipment in the candidate waybill set, and retain waybills with a difference greater than the estimated empty driving time to ensure that the vehicle can arrive at its destination before the expected arrival time. Waybills that pass the capacity verification, permitted scope verification, and time window verification will be identified as the final list of matchable waybills.

8. The GPS-based cross-freight platform logistics demand collection, matching, and scheduling method according to claim 7, characterized in that, The method also includes a step for dynamically adjusting the priority of cross-platform waybills: The final list of matchable waybills shows the percentage of waybills originating from the same external freight platform. If the number of waybills from a certain external freight platform exceeds a preset monopoly threshold, a penalty weight will be applied to waybills from the external freight platform to reduce their sorting priority in the matching queue. Conversely, if a waybill from a certain external freight platform is not matched successfully for a long time, an incentive weight is applied to the waybill from that external freight platform to increase its ranking priority. Based on the adjusted sorting priority, rearrange the final list of matching waybills and output the adjusted matching sequence.

9. The GPS-based cross-freight platform logistics demand collection, matching, and scheduling method according to claim 8, characterized in that, The method also includes steps for immediate delivery and confirmation of matching results: From the adjusted matching sequence, the waybill with the highest ranking is selected as the target waybill; Generate a dispatch instruction that includes the identity information of the freight vehicle, the target waybill number, and the confirmed estimated arrival time; The dispatch command is sent to the vehicle terminal via wireless network, and a pop-up prompt is displayed on the human-machine interface of the vehicle terminal. The system monitors the driver confirmation feedback signal returned by the vehicle terminal. If the driver confirmation feedback signal is received, the status of the matching result is changed to locked, and the target waybill is removed from the candidate waybill set.

10. The GPS-based cross-freight platform logistics demand collection, matching, and scheduling method according to claim 9, characterized in that, The method also includes a backtracking and recalculation step after a matching failure: If no confirmation signal from the driver is received within the preset waiting period, the matching operation will be marked as timed out. The expired target waybill is put back into the candidate waybill set, and its timeliness weight is adjusted to the highest level. A new round of matching calculation is triggered, and the comprehensive score of the remaining waybills in the candidate waybill set is recalculated using the updated weights; Repeat the scheduling process from screening to confirmation until the candidate waybill set is empty or the predetermined number of matching orders is reached.

Images