A cloud computing-based warehouse logistics digital scheduling method and system

Abstract

The present application relates to the technical field of warehouse logistics scheduling, and particularly relates to a warehouse logistics digital scheduling method and system based on cloud computing. The method comprises the following steps: receiving a goods scheduling task issued by a warehouse management cloud platform, identifying the current position, volume and weight of the goods to be scheduled in the warehouse scheduling task; allocating a transport vehicle according to the current position, volume and weight of the goods to be scheduled; calculating the transport operation load and the estimated time consumption of the transport operation based on the transport vehicle allocation result; dividing the transport operation vehicle allocation result into a transport operation wave set using the mobile operation load, and dynamically coordinating the transport operation path in the transport operation wave set, which has an estimated time consumption of the transport operation exceeding a preset transport time tolerance range, with the adjacent transport operation path, to obtain a to-be-executed transport operation wave set; and uploading the to-be-executed transport operation wave set to the warehouse management cloud platform. The present application helps to improve the timeliness, stability and overall operation efficiency of warehouse logistics scheduling.

Description

Technical Field

[0001] This invention relates to the field of warehousing and logistics scheduling technology, and in particular to a cloud computing-based digital scheduling method and system for warehousing and logistics. Background Technology

[0002] As a crucial component of the supply chain system, warehousing and logistics efficiency directly impacts a company's production pace and market responsiveness. Early warehousing and logistics scheduling relied heavily on manual experience and paper-based work orders for arranging the processes of goods entering, leaving, and being delivered. This approach suffers from significant delays in information transmission, task allocation, and progress tracking, making it difficult to meet the demands for efficient circulation of multiple batches and categories of goods.

[0003] Existing cloud-based scheduling applications mainly focus on static inventory management and order processing. For complex scheduling scenarios involving cross-regional delivery and emergency adjustments, there are still problems such as high response latency, uneven vehicle allocation, and data silos. Summary of the Invention

[0004] Therefore, it is necessary for the present invention to provide a cloud computing-based digital scheduling method and system for warehousing and logistics to solve at least one of the above-mentioned technical problems.

[0005] To achieve the above objectives, a cloud-based digital scheduling method for warehousing and logistics includes the following steps:

[0006] Step S1: Receive the cargo scheduling task issued by the warehouse management cloud platform, and identify the current location, volume and weight of the cargo to be scheduled in the warehouse scheduling task;

[0007] Step S2: Allocate transport vehicles based on the current location, volume, and weight of the goods to be dispatched; calculate the transport operation load and estimated transport operation time based on the transport vehicle allocation results;

[0008] Step S3: The mobile operation load is used to divide the mobile operation vehicle allocation results into a transportation operation wave set, and the transportation operation routes in the transportation operation wave set whose estimated transportation time exceeds the preset transportation time tolerance range are dynamically coordinated with adjacent transportation operation routes to obtain the transportation operation wave set to be executed;

[0009] Step S4: Upload the set of transportation operations to be executed to the warehouse management cloud platform, and then issue the transportation operations to the corresponding transportation vehicles for execution.

[0010] This application relies on a warehouse management cloud platform to first receive cargo scheduling tasks and identify the current location, volume, and weight of the goods. Through multi-dimensional matching of cargo type, load capacity, and spatial distance, it achieves precise allocation of transport vehicles and calculates the transport workload and estimated time for each vehicle. Based on the mobile workload and time constraints, the vehicle allocation results are divided into transport operation waves. Paths with estimated time exceeding the tolerance range are dynamically and collaboratively optimized with adjacent paths to generate a set of transport operation waves to be executed. During the operation, the vehicle status is monitored in real time using positioning signal frequency, and the operation paths of abnormal vehicles are intelligently replaced and adjusted to ensure the continuity and timeliness of transport tasks. This application achieves efficient utilization of vehicle resources, balanced scheduling of wave operations, dynamic optimization of the transportation process, and emergency support, effectively improving the timeliness, stability, and overall operational efficiency of warehouse logistics scheduling.

[0011] Optionally, this application also provides a cloud-based digital scheduling system for warehousing and logistics, used to execute the cloud-based digital scheduling method for warehousing and logistics described above. The cloud-based digital scheduling system for warehousing and logistics includes:

[0012] The task receiving module is used to receive cargo scheduling tasks issued by the warehouse management cloud platform and identify the current location, volume and weight of the cargo to be scheduled in the warehouse scheduling task.

[0013] The vehicle allocation module is used to allocate transport vehicles based on the current location, volume, and weight of the goods to be dispatched; and to calculate the transport operation load and estimated transport operation time based on the transport vehicle allocation results.

[0014] The dynamic coordination module is used to divide the mobile operation load into mobile operation vehicle allocation results into a transportation operation wave set, and dynamically coordinate the transportation operation routes in the transportation operation wave set whose estimated transportation time exceeds the preset transportation time tolerance range with adjacent transportation operation routes to obtain the transportation operation wave set to be executed.

[0015] The job execution module is used to upload the set of transportation jobs to be executed to the warehouse management cloud platform, and then distribute the transportation jobs to the corresponding transportation vehicles for execution.

[0016] The present invention relates to a cloud-based digital scheduling system for warehousing and logistics. This system can implement any of the cloud-based digital scheduling methods for warehousing and logistics of the present invention. It serves as a medium for coordinating the operation and signal transmission between various modules to complete the cloud-based digital scheduling method for warehousing and logistics. The modules within the system cooperate with each other, thereby effectively improving the timeliness, stability and overall operational efficiency of warehousing and logistics scheduling. Attached Figure Description

[0017] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0018] Figure 1 This is a flowchart illustrating the steps of the cloud computing-based digital scheduling method for warehousing and logistics of the present invention.

[0019] Figure 2 This is a schematic diagram of the mechanical loading and unloading method in an embodiment of the present invention;

[0020] Figure 3 This is a schematic diagram of the conveyor belt loading and unloading method in an embodiment of the present invention;

[0021] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] The technical method of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0023] Furthermore, the accompanying drawings are merely illustrative of the invention and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor methods and / or microcontroller methods.

[0024] It should be understood that although the terms "first," "second," etc., may be used herein to describe various units, these units should not be limited by these terms. These terms are used merely to distinguish one unit from another. For example, without departing from the scope of the exemplary embodiments, a first unit may be referred to as a second unit, and similarly, a second unit may be referred to as a first unit. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0025] To achieve the above objectives, please refer to Figures 1 to 3 This invention provides a cloud computing-based digital scheduling method for warehousing and logistics, the method comprising the following steps:

[0026] Step S1: Receive the cargo scheduling task issued by the warehouse management cloud platform, and identify the current location, volume and weight of the cargo to be scheduled in the warehouse scheduling task;

[0027] In some embodiments, the warehouse management cloud platform is deployed on a distributed computing cluster. The cluster adopts the Kubernetes container orchestration framework, supports horizontal scaling to cope with large-scale scheduling requests, and uses MQ (Message Queue) to achieve asynchronous distribution and acknowledgment of task messages.

[0028] In another embodiment, the warehouse management cloud platform receives a scheduling request from the enterprise order system. The scheduling request data structure follows JSON format and includes fields such as task ID, cargo number, cargo type, current location coordinates (WGS-84 latitude and longitude), destination coordinates, cargo volume (cubic meters), and cargo weight (kg). Upon receiving the request, the platform converts the current cargo location into an efficient index code based on GeoHash, facilitating rapid matching of vehicle location data. Simultaneously, the task information is loaded into the scheduling cache database (Redis cluster) through an ETL (Extract-Transform-Load) process for parallel processing.

[0029] In other embodiments, a cargo file data table in the warehouse management database (generated in real-time by electronic weighbridges and 3D dimension measuring instruments when goods enter the warehouse) can be accessed to query the volume and weight information of the goods by associating them with the cargo number. The volume is automatically calculated from the 3D dimensions; the weight information comes from the inbound weighing data of the electronic weighbridge, accurate to 0.1 kg. If the volume and weight fields are already directly included in the scheduling task, they are checked for consistency with the historical records in the database. If the deviation is greater than 3%, the latest sensor data shall prevail.

[0030] Step S2: Allocate transport vehicles based on the current location, volume, and weight of the goods to be dispatched; calculate the transport operation load and estimated transport operation time based on the transport vehicle allocation results;

[0031] It is worth noting that the transport vehicle information is reported to the cloud platform in real time by the vehicle terminal via the 4G / 5G network, including vehicle type (van, flatbed truck, refrigerated truck, etc.), maximum rated load (kg), maximum loading volume (cubic meters), current remaining load weight (kg), remaining loading volume (cubic meters), real-time GPS location, etc.

[0032] In this embodiment, vehicle types that meet the cargo type transportation conditions are filtered through rule matching; then, the cargo volume and weight are calculated to see if they are lower than the vehicle's remaining carrying capacity. If they are greater than or equal to the remaining carrying capacity, the vehicle is deemed capable of carrying the cargo; otherwise, it is discarded. Next, the road distance between the current location of the cargo and the current location of the vehicle is calculated using the Dijkstra algorithm. When the distance is ≤15km (configurable parameter), the vehicle is marked as a matching vehicle. The intersection of the three matching results (vehicle type, carrying capacity, and road distance) is taken to obtain the final cargo-vehicle allocation relationship.

[0033] In another embodiment, the transport operation load and the estimated transport operation time are calculated. The transport operation load is obtained by summing the total volume and total weight of the goods allocated to the same vehicle and comparing it with the vehicle's maximum carrying capacity to generate a load percentage for constraint reference in subsequent wave division.

[0034] It should be noted that the estimated time calculation consists of two parts:

[0035] 1) Route planning-based travel time estimation: The map API is called to obtain the road path from the vehicle to each cargo location and to the destination. The vehicle's historical average speed (from the vehicle's OBD historical data) and real-time road speed limit information are combined in segments for weighted calculation.

[0036] 2) Loading and unloading time estimation based on historical loading and unloading operation time database: The loading and unloading operation time database maintained by the cloud platform establishes a baseline time (seconds / piece) according to the loading and unloading method (forklift handling, manual loading and unloading, scooter pushing, etc.), and corrects the baseline time according to the handling correction coefficient of cargo volume and weight (obtained through historical data regression analysis), and finally sums them up to obtain the total loading and unloading time of a single vehicle.

[0037] The estimated time for transportation operations is the sum of the travel time and the loading and unloading time, with the time accuracy down to the second.

[0038] Step S3: The mobile operation load is used to divide the mobile operation vehicle allocation results into a transportation operation wave set, and the transportation operation routes in the transportation operation wave set whose estimated transportation time exceeds the preset transportation time tolerance range are dynamically coordinated with adjacent transportation operation routes to obtain the transportation operation wave set to be executed;

[0039] In this embodiment, the transportation operation wave set is divided using mobile operation load. First, the wave division constraints are determined based on the total cargo scheduling task, the load percentage of each vehicle, and the batch upper limit set by the system (e.g., the total weight of a single wave task does not exceed 30 tons, and the total volume does not exceed 120 cubic meters). Vehicles are sorted from shortest to longest estimated transportation operation time to generate a candidate sequence for wave division. This sequence is then iterated through, and vehicles that meet the batch constraints are grouped into a wave. If any constraint is broken after adding a new vehicle, the current wave ends and the next wave begins. After wave generation, if the average estimated time of a certain wave exceeds the set time tolerance range (e.g., 90 minutes), vehicles whose estimated time exceeds the average by more than 15% are moved to the next wave, and the wave structure is recalculated to obtain a balanced transportation operation wave set.

[0040] In another embodiment, dynamic collaborative optimization is performed on transportation routes whose estimated time exceeds the tolerance range of transportation time in the transportation operation wave set. The process first marks the time-out paths and retrieves adjacent paths with a start-end distance of no more than 3km (configurable) in the wave as a collaborative candidate set; after removing paths with the same timeout, the cargo tasks corresponding to the time-out paths are matched to available adjacent paths according to their location, and the task execution order of inserting into the path is simulated. The estimated time after insertion is calculated by a scheduling optimizer (implemented based on a genetic algorithm). If it is within the time tolerance range, the wave structure is updated; otherwise, the next adjacent path is tried until optimization is completed.

[0041] Step S4: Upload the set of transportation operations to be executed to the warehouse management cloud platform, and then issue the transportation operations to the corresponding transportation vehicles for execution.

[0042] In this embodiment, the generated set of transportation operations to be executed is pushed back to the warehouse management cloud platform via HTTPS API. The cloud platform then distributes the tasks to the on-board terminals of each vehicle. During the execution of the tasks, the on-board terminals periodically (e.g., every 10 seconds) upload location signals. The cloud platform determines the vehicle's operating status based on the frequency of the location signal changes. If the frequency is abnormal (e.g., below the preset 5 times / minute or above the preset 30 times / minute), the vehicle is marked as abnormal, triggering route replacement and task reassignment logic, thereby ensuring the timeliness and stability of the transportation operations.

[0043] Optionally, after the transport vehicle performs the transport operation, it may also include:

[0044] The system detects the positioning signal of the transport vehicle and determines the status of the transport vehicle based on the changing frequency of the positioning signal. If the changing frequency exceeds the preset changing frequency tolerance range, the corresponding transport vehicle is marked as an abnormal transport vehicle; if the changing frequency is within the changing frequency tolerance range, the corresponding transport vehicle is marked as a normal transport vehicle and continues to perform transport operations.

[0045] In one embodiment, a GPS / BeiDou dual-mode positioning terminal deployed on a transport vehicle uploads data such as vehicle number, latitude and longitude, speed, and timestamp to the warehouse management cloud platform every 5 seconds. The warehouse management cloud platform receives the data through a Kafka message queue, performs location parsing, and writes it to a time-series database (TimescaleDB). The preset tolerance range for positioning signal change frequency is 0.15Hz to 0.35Hz, meaning a valid location change occurs once every 3 to 7 seconds. During operation, the dispatch center counts the number of location data changes for each vehicle in the last 180 seconds and calculates the location change frequency: if the frequency is higher than 0.35Hz, the vehicle is considered to have frequent location jumps or detours and is marked as an abnormal transport vehicle; if it is between 0.15Hz and 0.35Hz, it is marked as a normal transport vehicle, and the current transport task continues. Vehicle status information is cached in real time in Redis for subsequent decision-making.

[0046] The actual transport operation time is calculated based on the change frequency of the positioning signal of the abnormal transport vehicle, and it is determined whether the actual transport operation time exceeds the tolerance range of transport time.

[0047] In another embodiment, when a vehicle is marked as an abnormal transport vehicle, its actual transport route time is calculated based on the vehicle's location data trajectory and road network topology (stored in a PostGIS database). The calculation method is as follows: extract the timestamps of the task's start and end points, subtract the loading and unloading operation time (identified by detecting stops where the vehicle speed is below 0.5 m / s and lasts for more than 120 seconds), obtain the pure travel time, and compare it with a preset transport time tolerance range (e.g., 120 minutes). If the time exceeds the tolerance range, a route replacement process will be initiated, searching within the same transport wave for normal transport vehicle routes that are no more than 500 meters away from the vehicle's start or end point and have a task execution time overlap ratio of no less than 30%, as candidate replacement routes.

[0048] Replace the transportation operation route that exceeds the transportation time tolerance range with the transportation operation route of normal transportation vehicles whose location signals are adjacent and whose task execution times overlap in the current transportation operation wave;

[0049] In this embodiment, after the candidate replacement path is determined, the task of the abnormal vehicle is inserted into the transportation sequence of the candidate vehicle, and a path planning algorithm such as A*, which combines real-time traffic information (obtained from traffic sensors or third-party map APIs), is invoked to recalculate the combined transportation operation time. If the calculation result is less than or equal to the transportation time tolerance range, the transportation wave task table is updated, the replacement plan is written into the MySQL scheduling database, and distributed to the vehicle terminal of the executing vehicle through the warehouse management cloud platform.

[0050] Transport routes that do not exceed the tolerance range for transport time will be retained in the current transport wave and transport operations will continue to be carried out according to the established routes.

[0051] In this embodiment, for those paths that are marked as abnormal but whose actual time consumption does not exceed the tolerance range of transportation time, their original task arrangements remain unchanged, and the vehicles continue to perform transportation operations according to the predetermined path. The warehouse management cloud platform only continuously monitors their subsequent location signals so as to handle new abnormalities in a timely manner.

[0052] Optionally, replacing transport routes that exceed the tolerance range for transport time includes:

[0053] The transportation routes of normal transportation vehicles with the closest location signals and overlapping task execution times in the current transportation operation wave are used as candidate transportation routes for abnormal transportation vehicles that exceed the transportation time tolerance range.

[0054] If the predicted transport operation path time is less than 80% of the transport time tolerance range, the transport operation path of the abnormal transport vehicle will be replaced with the transport operation candidate path. Otherwise, the transport operation path of the abnormal transport vehicle will be replaced with the transport operation path of the normal transport vehicle that is the second adjacent in the transport operation wave and whose task execution time overlaps.

[0055] In one embodiment, when the warehouse management cloud platform detects that the actual transportation operation time of a certain transport vehicle exceeds a preset transportation time tolerance range (e.g., 120 minutes), it will search the task table of the current transportation operation wave for the normal transport vehicle route with the smallest spatial distance to the start or end point of the abnormal vehicle. The spatial distance calculation is based on the latitude and longitude data of the vehicle's current location and the task location, using the Haversine formula, and setting an adjacent distance threshold of 500 meters as a matching condition. At the same time, the task execution time periods of the two vehicles will be compared. If the time overlap ratio is not less than 30% (i.e., the overlap time divided by the shorter task time ≥ 0.3), the normal vehicle route is confirmed as the preferred candidate transportation operation route.

[0056] In another embodiment, after a candidate route is determined, the warehouse management cloud platform calls its built-in ETA (Estimated Time of Arrival) prediction module to calculate the predicted travel time for that candidate route. This module integrates the vehicle's historical average speed (calculated from similar road data over the past 30 days), current road speed limit information (from a third-party map API), and real-time traffic congestion factors (obtained in real-time through traffic data streams, with values ​​ranging from 0.8 to 1.5; higher values ​​indicate greater congestion). The calculation result is the predicted travel time for the transportation operation route, for example, 92 minutes. This predicted value is compared with the 80% threshold of the transportation time tolerance range (i.e., 96 minutes). If the predicted travel time is less than 96 minutes, the transportation operation route of the abnormal vehicle is directly replaced with this candidate route, the route allocation table is updated in the task management module, and a scheduling instruction containing the new task sequence is sent to the vehicle executing the route.

[0057] In some embodiments, if the prediction time is greater than or equal to 96 minutes, the system will continue to search the current transport wave task table for a normal transport vehicle path that is the second closest in spatial distance to the abnormal vehicle (e.g., the second closest in distance and not exceeding 800 meters) and whose task execution time overlap is still not less than 30%. For this second closest path, the ETA prediction process will also be performed, and the abnormal vehicle task will be replaced if the prediction time is less than 96 minutes. If the conditions still cannot be met, the abnormal vehicle task will be marked as requiring manual intervention and pushed to the manual dispatch interface so that the dispatcher can manually adjust or assign it to the next transport wave.

[0058] Optionally, the allocation of transport vehicles in step S2 includes:

[0059] The goods to be dispatched are selected from the transport vehicles according to the type of goods, and the types of vehicles that meet the corresponding transport conditions are obtained to obtain the goods type-vehicle type matching relationship.

[0060] In one embodiment, the cargo type field (e.g., "fragile," "cold chain," "general goods," etc.) of each item in the goods to be dispatched is parsed, and then the vehicle type transportation condition table stored in the vehicle database of the warehouse management cloud platform is called for comparison and filtering. The transportation condition table records the transportation capacity parameters of each vehicle type. For example, cold chain vehicles have a temperature control range of -20℃ to 8℃, fragile goods transport vehicles have shock absorption devices and fixing frames, and general vans have no special transportation capabilities. Using the correspondence between cargo type and vehicle type transportation conditions, vehicle types that can meet the cargo transportation requirements are filtered out, and a cargo type-vehicle type matching relationship table is generated.

[0061] Based on the volume and weight of the goods to be dispatched, a corresponding load vehicle is matched from the transport vehicles to obtain the matching relationship between the volume and weight of the goods and the vehicle load.

[0062] In another embodiment, the maximum rated load and maximum loading volume information of each vehicle recorded in the vehicle database are used in conjunction with the real-time transportation status of the vehicles (remaining load and remaining volume are collected by on-board weighing sensors and cargo compartment volume sensors, and uploaded every 30 seconds). The volume and weight of the goods to be dispatched are compared with the remaining carrying capacity of each vehicle. If the remaining load of a vehicle is greater than or equal to the weight of the goods and the remaining loading volume is greater than or equal to the volume of the goods, then the vehicle is considered to be able to carry the goods, and the vehicle is added to the goods volume and weight-vehicle load matching table. To ensure transportation safety, the system also reserves a 10% safety margin during matching, that is, the actual usable load and loading volume of the vehicle must be greater than 1.1 times the weight and volume of the goods, respectively.

[0063] Calculate the current location of the goods to be dispatched and the road travel distance of each transport vehicle, select vehicles whose road travel distance is not greater than a preset distance threshold as matching vehicles, and obtain the goods location-vehicle location matching relationship;

[0064] In one embodiment, the map service API is called to obtain the road travel distance between the current location of the goods and the current location of each transport vehicle. The distance calculation uses Dijkstra's shortest path algorithm combined with real-time road traffic data obtained in cooperation with a third-party map service for optimization, so as to reflect the actual transport distance. The preset distance threshold is 15 kilometers. That is, if the road travel distance between the vehicle and the goods does not exceed 15 kilometers, the spatial match between the vehicle and the goods is considered valid, and it is recorded in the goods location-vehicle location matching table.

[0065] The intersection of the cargo type-vehicle type matching relationship, the cargo volume and weight-vehicle load matching relationship, and the cargo location-vehicle location matching relationship is calculated, and the cargo-vehicle matching relationship that exists simultaneously is selected as the transportation vehicle allocation result.

[0066] In this embodiment, the cargo type-vehicle type matching table, the cargo volume and weight-vehicle load matching table, and the cargo location-vehicle location matching table are intersected. Only cargo-vehicle matching pairs that appear in all three tables are retained as the final transportation vehicle allocation result. This intersection operation is implemented based on multi-table join queries in a relational database (e.g., through SQL's INNER JOIN operation) to ensure that each matching result simultaneously meets scheduling requirements in terms of transportation conditions, load capacity, and spatial distance.

[0067] Optionally, obtaining the cargo volume and weight-vehicle load matching relationship includes:

[0068] Collect the real-time carrying status of all transport vehicles, and calculate the remaining load weight and remaining loading volume under the real-time carrying status based on the maximum rated load and maximum loading volume of each transport vehicle.

[0069] In one embodiment, weighing sensors and a volume detection module deployed in the vehicle compartment collect real-time data on the current load and loading volume of all transport vehicles. The weighing sensors have an accuracy of ±2 kg, and the volume detection module calculates the remaining usable space inside the compartment using ultrasonic ranging and 3D modeling, with an accuracy of ±0.01 cubic meters. The maximum rated load (e.g., 8 tons) and maximum loading volume (e.g., 40 cubic meters) of each vehicle are pre-stored in a vehicle database. The remaining carrying capacity under real-time transport conditions is calculated using the formulas: Remaining load weight = Maximum rated load - Current load, Remaining loading volume = Maximum loading volume - Currently used volume. This data is updated every 20 seconds and uploaded to the scheduling server via the MQTT protocol.

[0070] Vehicles with remaining load weight and remaining loading volume that are higher than the volume and weight of the goods to be dispatched are removed from the corresponding load vehicles. The remaining vehicles are then matched with the corresponding goods to be dispatched that are lower than the remaining load weight and remaining loading volume, thus obtaining the matching relationship between the goods volume and weight and the vehicle load.

[0071] In another embodiment, the matching range is first filtered out based on the volume and weight information of the goods to be scheduled. Specifically, if the remaining load weight and remaining loading volume of a vehicle are both higher than the weight and volume of the goods to be scheduled, the vehicle is removed from the matching list for this round. This helps to prevent high-capacity vehicles from being occupied by small-item tasks. After the removal, a one-to-one matching relationship is established between the remaining vehicles and the goods to be scheduled that have a weight less than the vehicle's remaining load weight and a volume less than the vehicle's remaining loading volume. During the matching process, a safety factor of a=1.05 can be selectively introduced, i.e., the vehicle's remaining load weight ≥ the goods weight × a, and the vehicle's remaining loading volume ≥ the goods volume × a, to ensure that there is no risk of overloading due to errors or extra goods during transportation. Finally, all the goods-vehicle pairing records that meet the conditions are formed into a goods volume and weight-vehicle load matching relationship table and stored in the task allocation database for use by subsequent scheduling algorithms.

[0072] Optionally, the calculation of transportation operation load and estimated transportation operation time in step S2 includes:

[0073] The volume and weight of all goods to be dispatched assigned to the same transport vehicle in the transport vehicle allocation result are summed separately, and the sum of the volume and weight of all goods to be dispatched in the same transport vehicle is taken as the transport operation load of the corresponding transport vehicle.

[0074] In some embodiments, information on all cargo to be dispatched corresponding to each assigned vehicle is extracted from the vehicle allocation results, and the volume and weight of these cargoes are summed. The volume unit is cubic meters, and the weight unit is kilograms (kg), calculating the total loading volume and total loading weight of each vehicle. This summation result is taken as the transport operation load of the transport vehicle.

[0075] Calculate the total travel distance of the transport vehicle from its current location to each location of the goods to be dispatched and to the destination of the goods dispatching task, which is the total travel distance of the transport operation route;

[0076] In some embodiments, the vehicle's current position is obtained using a high-precision positioning module (GNSS + inertial navigation combined positioning, positioning accuracy ±1m), and a route is planned sequentially for the vehicle to travel to the locations of its assigned goods to be dispatched, and then transported to the destination specified in the goods dispatching task. Route planning is dynamically generated based on an improved Dijkstra algorithm, combined with real-time traffic information (such as congestion index and road closure information). The total travel distance of this planned route is recorded as the total travel distance of the transportation operation path, in kilometers (km), accurate to two decimal places.

[0077] The estimated travel time for the total distance is calculated by combining the historical average speed of each transport vehicle with the real-time road speed limit information, and then the estimated time for loading and unloading of goods is added to obtain the estimated time for the transport operation.

[0078] In some embodiments, the total travel time is estimated in segments. Segmentation is based on road type and speed limit information: highway segments reference real-time speed limits (obtained via traffic management API), while ordinary road segments reference historical average vehicle speeds (obtained from vehicle travel data over the past 30 days, updated daily). In the segmented calculation, the time for each segment = distance / speed, and the total travel time is summed to obtain the vehicle's pure travel time. The estimated loading and unloading time is then added to the travel time. The estimated loading and unloading time is based on the number of cargo pieces, the average loading and unloading time per piece (calculated from historical records and the number of loading and unloading workers), and a correction factor for the number of on-site personnel. For example, if the vehicle needs to load and unload a total of 120 pieces of cargo, the average loading and unloading time per piece is 25 seconds, and there are 4 loading and unloading workers on-site, then the estimated loading and unloading time formula is T = (120 × 25 seconds) / 4 ≈ 12.5 minutes. The system adds the loading and unloading time to the segmented travel time to obtain the estimated transport time of the transport vehicle, and stores this value with an accuracy of minutes for subsequent wave division and scheduling optimization calculations.

[0079] Optionally, obtaining the estimated time for cargo loading and unloading includes:

[0080] Extract the loading and unloading methods of each cargo to be dispatched and assigned to the same transport vehicle from the cargo dispatch task;

[0081] In one implementation of this application, the loading and unloading method requirements for each cargo to be scheduled are extracted from the cargo scheduling task. These requirements include, but are not limited to, manual handling, forklift loading (machine loading and unloading), automatic loading and unloading (conveyor belt loading and unloading), or hydraulic lifting platform operation. The loading and unloading method requirements are generated by the task scheduling system when the task is created and stored in the cargo attribute table. Each loading and unloading method corresponds to a standard operating procedure, and the required number of personnel, tool types, and average operation time are identified based on the procedure.

[0082] By utilizing the loading and unloading methods of each cargo to be scheduled, the corresponding loading and unloading time benchmarks in the preset historical loading and unloading operation time database are matched;

[0083] In this embodiment, the extracted loading and unloading methods are matched with loading and unloading time benchmarks in the historical loading and unloading operation time database. The historical loading and unloading operation time database contains measured loading and unloading time data from the past three years under different warehousing environments, different numbers of personnel, and different types of goods. The data is stored in a two-dimensional table format, with rows representing loading and unloading methods and columns representing the volume and weight ranges of the goods. During the matching operation, a time benchmark consistent with the current loading and unloading method is found, and the corresponding average time value is read, in seconds per piece.

[0084] Based on the difference in loading and unloading time for goods of different volumes and weights under the same loading and unloading method in the historical loading and unloading operation time warehouse, determine the handling correction coefficient for goods of different volumes and weights.

[0085] In another embodiment, a cargo handling correction factor is calculated based on the difference in loading and unloading times for goods of different volumes and weights under the same loading and unloading method in the historical loading and unloading operation time database. Specifically, the volume and weight of the target cargo are proportionally calculated to the volume and weight of a baseline cargo in the historical database. The coefficient is accurate to one decimal place and is used to reflect the increased handling time for large or heavy goods.

[0086] Multiply the loading and unloading time base by the cargo handling correction factor to obtain the loading and unloading time per piece; sum up the loading and unloading times of each piece of cargo to be dispatched and assigned to the same transport vehicle to obtain the estimated loading and unloading time.

[0087] In this embodiment, the loading and unloading time baseline is multiplied by the cargo handling correction factor to obtain the loading and unloading time for a single piece of cargo. For example, if the baseline time is 30 seconds and the correction factor is 1.2, then the loading and unloading time for a single piece = 30 seconds × 1.2 = 36 seconds. The estimated loading and unloading time for a vehicle is obtained by summing the loading and unloading times of all cargoes assigned to the same transport vehicle.

[0088] Optionally, the result of dividing the mobile operation vehicle allocation in step S3 into a transportation operation wave set includes:

[0089] The constraints are determined based on the number of cargo dispatching tasks and the mobile operation load of each transport vehicle.

[0090] In this embodiment, the constraints for transportation operation batches are determined based on the total number of cargo scheduling tasks and the mobile operation load of each transport vehicle. The mobile operation load refers to the total volume and weight of cargo allocated to each transport vehicle in the current wave. The constraints may include a maximum of 50 transport vehicles per wave, a total cargo volume of no more than 50 cubic meters per wave, and a total cargo weight of no more than 10 tons per wave. The specific values ​​can be dynamically adjusted according to the scale of warehousing operations and vehicle configuration to ensure that the transportation operation load of each wave is within the vehicle's carrying capacity.

[0091] In another embodiment, the total number of goods to be dispatched and the sum of the volume and weight of each goods are counted; then, the maximum number of goods that can be carried is calculated based on the rated load and loading volume of each transport vehicle; on this basis, the total number of goods that can be allocated in a single wave is set to not exceed 80% to 90% of the total carrying capacity of the vehicles, so as to reserve buffer space to deal with abnormal or temporary scheduling adjustments, thereby determining the constraints on the maximum number of transport vehicles, total cargo volume and total cargo weight that can be accommodated in a single wave.

[0092] The transport vehicles are sorted from shortest to longest estimated transport time to obtain a candidate sequence for wave division.

[0093] In this embodiment, the transport vehicles are sorted from shortest to longest estimated transport time to generate a candidate sequence for wave partitioning. The estimated time is the sum of the total travel time from the current location of the transport vehicle to the location of each cargo to be dispatched and the cargo destination, plus the estimated loading and unloading time, in minutes. Quick sort or heap sort methods can be used during the sorting process.

[0094] The candidate sequence of wave divisions is traversed sequentially, and the transport vehicles that meet the batch constraints of the transport operation are combined into a transport operation wave. When a vehicle exceeds any constraint after being added to a transport operation wave, the addition of vehicles to that transport operation wave is stopped, and the combination of the next transport operation wave begins.

[0095] In some embodiments, when traversing the candidate sequence of wave divisions, transport vehicles that meet the batch constraints of transport operations are sequentially combined into a transport operation wave. When a vehicle is added to a wave, the total number of vehicles, total cargo volume, and total cargo weight of the current wave are accumulated in real time. When adding a new vehicle causes any constraint to exceed a threshold, the addition of vehicles to the current wave stops, and the combination of the next transport operation wave begins, ensuring that each wave is evenly distributed within the vehicle carrying capacity and workload range.

[0096] If the average estimated time of transportation operations in the same transportation operation wave exceeds the tolerance range of transportation time, then the transportation vehicles whose estimated time exceeds the average by 15% will be moved to the next transportation operation wave in the wave division candidate sequence, thus obtaining the transportation operation wave set.

[0097] In some embodiments, if the average estimated time of transportation operations within the same transportation wave exceeds the tolerable range, such as an average time exceeding 120 minutes, transportation vehicles with estimated times exceeding the average by 15% will be identified and moved to the next transportation wave in the wave partitioning candidate sequence. This operation ensures that time-consuming vehicles do not prolong the overall execution time of the current wave, optimizes the operation balance between waves, and maintains the continuity and flexibility of wave partitioning using a dynamic candidate sequence, thereby obtaining the final set of transportation wave assignments for subsequent scheduling.

[0098] Optionally, step S3, which involves dynamically coordinating transport routes whose estimated transport time exceeds a preset transport time tolerance range with adjacent transport routes, includes:

[0099] The path in the transportation operation cluster where the estimated transportation time exceeds the transportation time tolerance range is marked as an overtime path.

[0100] In this embodiment, the estimated time for each transportation operation is compared with a preset transportation time tolerance range (e.g., 6 hours). If the estimated time for a certain route exceeds the tolerance range, the difference of the excess is calculated, and an overdue route identifier is added to the transportation operation management table of the transportation operation wave. At the same time, the overdue time difference parameter is recorded.

[0101] Select transportation operation routes whose start and end point distances do not exceed a preset adjacent distance threshold as the adjacent route candidate set, and remove routes whose estimated transportation operation time exceeds the transportation time tolerance range to obtain collaborative available routes;

[0102] In this embodiment, the Euclidean distance or actual driving distance is calculated based on the GPS positioning start and end points of each transportation operation route, and compared with a preset adjacent distance threshold (e.g., 2 kilometers). Paths with a distance less than the threshold are included in the adjacent path candidate set. At the same time, paths in the candidate set whose estimated time still exceeds the tolerance range are eliminated, and a list of cooperative available paths containing only normal cooperative paths is generated.

[0103] The cargo scheduling tasks corresponding to the timed-out paths are matched with the available collaborative paths according to the task locations to generate task subsets;

[0104] In this embodiment, in another embodiment, the location coordinate information of all goods to be transported in the timeout path is extracted and spatially matched with the road segment coordinates of the cooperative available path to determine the candidate path position into which each goods can be inserted; then, the successfully matched goods are formed into a task subset.

[0105] Most importantly, the process of generating a subset of tasks also includes:

[0106] Use the matching results as a subset of candidate tasks;

[0107] Based on the remaining load weight, remaining loading volume, and remaining available time margin of the vehicles corresponding to the collaborative available routes, a subset of candidate tasks is screened, and tasks with remaining available time margin less than a preset time margin threshold or exceeding either the remaining load weight or the remaining loading volume are removed, thus obtaining a task subset; where the remaining available time margin is the margin between the expected time consumption of the transportation operation and the tolerance range of the transportation time.

[0108] In this embodiment, the matching results are used as a subset of candidate tasks. The remaining load weight, remaining loading volume, and remaining available time margin of the vehicles corresponding to each cooperative available path are obtained. The remaining available time margin is defined as the difference between the estimated transportation time for that path and the tolerable transportation time range. The remaining load weight and remaining loading volume are calculated from the vehicle's real-time carrying status and its rated load capacity and loading volume. The data is recorded in the form of a vehicle status matrix, where each row represents a vehicle and the columns represent weight, volume, and time margin. In the operation parameters, a preset time margin threshold of 15 minutes can be set; that is, when the remaining available time margin of a task path is less than 15 minutes, it is marked as unexecutable.

[0109] In another embodiment, each task path in the candidate task subset is evaluated. If its remaining available time margin is lower than a preset time margin threshold or its cargo volume / weight exceeds either the vehicle's remaining load weight / remaining loading volume, then the task path is removed from the candidate task subset. This ensures that the removed task subset meets the constraints of vehicle load and transportation time. The removal operation is performed using a task subset index list to maintain the integrity of the original data structure.

[0110] Insert the task subset into the travel sequence of the available collaborative paths and calculate the estimated time after merging. If the estimated time after merging is within the transportation time tolerance range, update the transportation operation wave set to obtain the transportation operation wave set to be executed.

[0111] In another embodiment, the existing driving sequence of the available collaborative paths is extracted, including the coordinates of the starting point, the locations of the goods along the route, and the coordinates of the destination. A path driving sequence data structure (e.g., a list or matrix stored by node index) is constructed in the wave management framework. Then, the shortest insertion point is calculated based on the location coordinates of each goods in the task subset and the node coordinates of the collaborative path. The position with the smallest increase in total driving distance after insertion is selected, and the task subsets are sequentially inserted into the driving sequence of the available collaborative paths. At the same time, the path node index and the goods number are recorded for each insertion point to ensure the consistency of task order and spatial location.

[0112] It is worth noting that the estimated time after merging is calculated by combining the inserted path node sequence with real-time road information, historical average driving speed and segmented speed limit data, and calculating the total driving time according to the segmented path driving time accumulation method. The estimated loading and unloading time of each newly added cargo is then added (refer to the historical loading and unloading operation time database and cargo volume and weight correction coefficient) to obtain the merged estimated time value. During the calculation process, operation parameters can be set, such as a segmented calculation accuracy of 100 meters / segment and an upper limit of 1.5 for loading and unloading time correction coefficient, to ensure that the time estimation is accurate and controllable.

[0113] In another embodiment, the combined estimated time is compared with a preset transportation time tolerance range (e.g., 6 hours). If the time does not exceed the tolerance range, the path and its task subset information are written into the pending transportation operation wave set table of the wave management framework, the original wave structure is updated, and the index of each path node, cargo number and estimated time parameters are recorded. If the time still exceeds the tolerance range, the original wave structure is retained, and the task subsets that were not successfully inserted are remarked as timed-out path tasks for the next round of dynamic collaborative scheduling, so as to realize the dynamic optimization and refined management of the transportation operation wave set.

[0114] Of particular importance, the calculation of the estimated time after merging also includes:

[0115] If the estimated time after merging is not within the tolerance range of transportation time, the current task subset will be removed from the merged collaborative available paths and sorted from high to low according to the distance between the origin and destination and the remaining available time margin, in order to filter and supplement the collaborative available paths; where the remaining available time margin is the margin between the estimated time of transportation operation and the tolerance range of transportation time.

[0116] The estimated time of the merged task subset is calculated by iteratively executing the supplementary and available paths until the merged estimated time is within the tolerance range of transportation time, thus obtaining the set of transportation operation waves to be executed.

[0117] In this embodiment, the current task subset is removed from the merged collaborative available paths. Candidate paths are prioritized based on the spatial proximity between the path's origin and destination points and the remaining available time margin. The proximity between the origin and destination points can be calculated by determining the Euclidean distance or road travel distance between the timed-out path and the candidate path. The remaining available time margin is calculated by subtracting the estimated travel time of the path from the transportation time tolerance range. For example, if the transportation time tolerance range is 90 minutes and the estimated travel time of a certain path is 72 minutes, then the remaining available time margin is 18 minutes.

[0118] The priority ranking is as follows: candidate paths are ranked according to proximity, followed by time margin. For example, paths with a proximity of less than 500 meters are prioritized over paths with a proximity of more than 500 meters. In the case of paths with the same proximity, paths with a larger remaining available time margin are prioritized. After ranking, supplementary available paths and task subsets are selected and iteratively merged. After each merge, the estimated time is calculated immediately and compared with the transportation time tolerance range. The time calculation is based on segmented speed limits on roads, historical average vehicle speeds, and estimated loading and unloading times, with segmented accumulation to ensure the accuracy of the result is controllable within ±1 minute. If the estimated time after merging falls within the transportation time tolerance range during the iteration process, the merge scheme is immediately deemed valid, and the merge result is written into the transportation operation wave set as part of the wave set to be executed. If, after traversing all supplementary available paths, the estimated time still cannot meet the transportation time tolerance range, the task subset is marked as requiring separate scheduling and executed in the next transportation operation wave to ensure overall compliance and execution stability of transportation scheduling.

[0119] Optionally, this application also provides a cloud-based digital scheduling system for warehousing and logistics, used to execute the cloud-based digital scheduling method for warehousing and logistics described above. The cloud-based digital scheduling system for warehousing and logistics includes:

[0120] The task receiving module is used to receive cargo scheduling tasks issued by the warehouse management cloud platform and identify the current location, volume and weight of the cargo to be scheduled in the warehouse scheduling task.

[0121] The vehicle allocation module is used to allocate transport vehicles based on the current location, volume, and weight of the goods to be dispatched; and to calculate the transport operation load and estimated transport operation time based on the transport vehicle allocation results.

[0122] The dynamic coordination module is used to divide the mobile operation load into mobile operation vehicle allocation results into a transportation operation wave set, and dynamically coordinate the transportation operation routes in the transportation operation wave set whose estimated transportation time exceeds the preset transportation time tolerance range with adjacent transportation operation routes to obtain the transportation operation wave set to be executed.

[0123] The job execution module is used to upload the set of transportation jobs to be executed to the warehouse management cloud platform, and then distribute the transportation jobs to the corresponding transportation vehicles for execution.

[0124] Therefore, the embodiments should be considered as exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of the equivalents of the application are intended to be included within the invention.

[0125] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features of the invention herein.

Claims

1. A cloud computing-based digital scheduling method for warehousing and logistics, characterized in that, Includes the following steps: Step S1: Receive the cargo scheduling task issued by the warehouse management cloud platform, and identify the current location, volume and weight of the cargo to be scheduled in the warehouse scheduling task; Step S2: Allocate transport vehicles based on the current location, volume, and weight of the goods to be dispatched; Calculate the transportation operation load and estimated transportation operation time based on the transportation vehicle allocation results; Step S3: The mobile operation load is used to divide the mobile operation vehicle allocation results into a transportation operation wave set. Transportation operation routes within this wave set whose estimated transport time exceeds a preset transport time tolerance range are dynamically coordinated with adjacent transportation operation routes to obtain the transportation operation wave set to be executed. Step S3, which involves dynamically coordinating transportation operation routes within the wave set whose estimated transport time exceeds a preset transport time tolerance range with adjacent transportation operation routes, includes: The path in the transportation operation cluster where the estimated transportation time exceeds the transportation time tolerance range is marked as an overtime path. Select transportation operation routes whose start and end point distances do not exceed a preset adjacent distance threshold as the adjacent route candidate set, and remove routes whose estimated transportation operation time exceeds the transportation time tolerance range to obtain collaborative available routes; The cargo scheduling tasks corresponding to the timed-out paths are matched with the available collaborative paths according to the task locations to generate task subsets; before generating task subsets, the following steps are also included: Use the matching results as a subset of candidate tasks; Based on the remaining load weight, remaining loading volume and remaining available time margin of the vehicles corresponding to the cooperative available routes, the candidate task subset is screened, and tasks with remaining available time margin less than the preset time margin threshold or exceeding either the remaining load weight or the remaining loading volume are removed, thus obtaining the task subset; where the remaining available time margin is the margin of the expected transportation operation time from the transportation time tolerance range. Insert the task subset into the travel sequence of the available collaborative paths and calculate the estimated time after merging. If the estimated time after merging is within the transportation time tolerance range, update the transportation operation wave set to obtain the transportation operation wave set to be executed. Step S4: Upload the set of transportation operations to be executed to the warehouse management cloud platform, and then issue the transportation operations to the corresponding transportation vehicles for execution.

2. The cloud computing-based digital scheduling method for warehousing and logistics according to claim 1, characterized in that, After a transport vehicle performs its transport operations, it also includes: The system detects the positioning signal of the transport vehicle and determines the status of the transport vehicle based on the changing frequency of the positioning signal. If the changing frequency exceeds the preset changing frequency tolerance range, the corresponding transport vehicle is marked as an abnormal transport vehicle; if the changing frequency is within the changing frequency tolerance range, the corresponding transport vehicle is marked as a normal transport vehicle and continues to perform transport operations. The actual transport operation time is calculated based on the change frequency of the positioning signal of the abnormal transport vehicle, and it is determined whether the actual transport operation time exceeds the tolerance range of transport time. Replace the transportation operation route that exceeds the transportation time tolerance range with the transportation operation route of normal transportation vehicles whose location signals are adjacent and whose task execution times overlap in the current transportation operation wave; Transport routes that do not exceed the tolerance range for transport time will be retained in the current transport wave and transport operations will continue to be carried out according to the established routes.

3. The cloud computing-based digital scheduling method for warehousing and logistics according to claim 2, characterized in that, Replacing transport routes that exceed the tolerance range for transit time includes: The transportation routes of normal transportation vehicles with the closest location signals and overlapping task execution times in the current transportation operation wave are used as candidate transportation routes for abnormal transportation vehicles that exceed the transportation time tolerance range. If the predicted transport operation path time is less than 80% of the transport time tolerance range, the transport operation path of the abnormal transport vehicle will be replaced with the transport operation candidate path. Otherwise, the transport operation path of the abnormal transport vehicle will be replaced with the transport operation path of the normal transport vehicle that is the second adjacent in the transport operation wave and whose task execution time overlaps.

4. The cloud computing-based digital scheduling method for warehousing and logistics according to claim 1, characterized in that, The allocation of transport vehicles in step S2 includes: The goods to be dispatched are selected from the transport vehicles according to the type of goods, and the types of vehicles that meet the corresponding transport conditions are obtained to obtain the goods type-vehicle type matching relationship. Based on the volume and weight of the goods to be dispatched, a corresponding load vehicle is matched from the transport vehicles to obtain the matching relationship between the volume and weight of the goods and the vehicle load. Calculate the current location of the goods to be dispatched and the road travel distance of each transport vehicle, select vehicles whose road travel distance is not greater than a preset distance threshold as matching vehicles, and obtain the goods location-vehicle location matching relationship; The intersection of the cargo type-vehicle type matching relationship, the cargo volume and weight-vehicle load matching relationship, and the cargo location-vehicle location matching relationship is calculated, and the cargo-vehicle matching relationship that exists simultaneously is selected as the transportation vehicle allocation result.

5. The cloud computing-based digital scheduling method for warehousing and logistics according to claim 4, characterized in that, The cargo volume and weight-vehicle load matching relationship is obtained as follows: Collect the real-time carrying status of all transport vehicles, and calculate the remaining load weight and remaining loading volume under the real-time carrying status based on the maximum rated load and maximum loading volume of each transport vehicle. Vehicles with remaining load weight and remaining loading volume that are higher than the volume and weight of the goods to be dispatched are removed from the corresponding load vehicles. The remaining vehicles are then matched with the corresponding goods to be dispatched that are lower than the remaining load weight and remaining loading volume, thus obtaining the matching relationship between the goods volume and weight and the vehicle load.

6. The cloud computing-based digital scheduling method for warehousing and logistics according to claim 5, characterized in that, Step S2, which calculates the transportation workload and the estimated transportation time, includes: The volume and weight of all goods to be dispatched assigned to the same transport vehicle in the transport vehicle allocation result are summed separately, and the sum of the volume and weight of all goods to be dispatched in the same transport vehicle is taken as the transport operation load of the corresponding transport vehicle. Calculate the total travel distance of the transport vehicle from its current location to each location of the goods to be dispatched and to the destination of the goods dispatching task, which is the total travel distance of the transport operation route; The estimated travel time for the total distance is calculated by combining the historical average speed of each transport vehicle with the real-time road speed limit information, and then the estimated time for loading and unloading of goods is added to obtain the estimated time for the transport operation.

7. The cloud computing-based digital scheduling method for warehousing and logistics according to claim 6, characterized in that, The estimated time for cargo loading and unloading includes: Extract the loading and unloading methods of each cargo to be dispatched and assigned to the same transport vehicle from the cargo dispatch task; By utilizing the loading and unloading methods of each cargo to be scheduled, the corresponding loading and unloading time benchmarks in the preset historical loading and unloading operation time database are matched; Based on the difference in loading and unloading time for goods of different volumes and weights under the same loading and unloading method in the historical loading and unloading operation time warehouse, determine the handling correction coefficient for goods of different volumes and weights. Multiply the loading and unloading time base by the cargo handling correction factor to obtain the loading and unloading time per piece; sum up the loading and unloading times of each piece of cargo to be dispatched and assigned to the same transport vehicle to obtain the estimated loading and unloading time.

8. The cloud computing-based digital scheduling method for warehousing and logistics according to claim 1, characterized in that, The results of dividing the mobile operation vehicle allocation in step S3 into a transportation operation wave set include: The constraints are determined based on the number of cargo dispatching tasks and the mobile operation load of each transport vehicle. The transport vehicles are sorted from shortest to longest estimated transport time to obtain a candidate sequence for wave division. The candidate sequence of wave divisions is traversed sequentially, and the transport vehicles that meet the batch constraints of the transport operation are combined into a transport operation wave. When a vehicle exceeds any constraint after being added to a transport operation wave, the addition of vehicles to that transport operation wave is stopped, and the combination of the next transport operation wave begins. If the average estimated time of transportation operations in the same transportation operation wave exceeds the tolerance range of transportation time, then the transportation vehicles whose estimated time exceeds the average by 15% will be moved to the next transportation operation wave in the wave division candidate sequence, thus obtaining the transportation operation wave set.

9. A cloud-based digital scheduling system for warehousing and logistics, characterized in that, For executing the cloud-based digital scheduling method for warehousing and logistics as described in claim 1, the cloud-based digital scheduling system for warehousing and logistics includes: The task receiving module is used to receive cargo scheduling tasks issued by the warehouse management cloud platform and identify the current location, volume and weight of the cargo to be scheduled in the warehouse scheduling task. The vehicle allocation module is used to allocate transport vehicles based on the current location, volume, and weight of the goods to be dispatched; and to calculate the transport operation load and estimated transport operation time based on the transport vehicle allocation results. The dynamic coordination module is used to divide the mobile operation load into mobile operation vehicle allocation results into a transportation operation wave set, and dynamically coordinate the transportation operation routes in the transportation operation wave set whose estimated transportation time exceeds the preset transportation time tolerance range with adjacent transportation operation routes to obtain the transportation operation wave set to be executed. The job execution module is used to upload the set of transportation jobs to be executed to the warehouse management cloud platform, and then distribute the transportation jobs to the corresponding transportation vehicles for execution.

Images