Container port horizontal transportation mixed fleet scheduling method and system

Abstract

This application primarily relates to the field of automated horizontal transport technology in container ports, specifically to a method and system for scheduling mixed-unit fleets in container port horizontal transport. The method provided in this application includes: acquiring container weight and type data of containers to be transported, and generating transport tasks to be assigned; establishing a mixed-unit fleet model; performing vehicle type matching for the transport tasks to be assigned based on the container weight data, container type data, and a preset container weight threshold, obtaining vehicle type matching results; and, based on the vehicle type matching results and vehicle status, determining target vehicles from the matched categories of automated guided vehicles, and issuing transport tasks to the target vehicles for execution, thereby reducing the total lifecycle cost of horizontal transport in ports.

Description

Technical Field

[0001] This application mainly relates to the field of automated horizontal transport technology in container ports, specifically to a method and system for scheduling mixed fleets in horizontal transport at container ports. Background Technology

[0002] Automated container terminals typically utilize AGVs (Automated Guided Vehicles), unmanned trucks, or other automated guided vehicles to perform horizontal transport operations between quay cranes and container yards. Existing automated terminals often employ standardized configurations for horizontal transport vehicles, meaning they are configured with heavy-duty vehicles based on maximum load capacity. For example, a common 65-ton AGV can handle various transport needs, including heavy containers, long containers, and special container types. However, in the large volume of medium- and light-duty container transport tasks, this type of vehicle suffers from issues such as heavy weight, high procurement costs, high energy consumption, long road occupancy times, and large turning radii.

[0003] Current port horizontal transport vehicle configurations typically allocate heavy-duty vehicles uniformly based on maximum load capacity, but lack a differentiated vehicle configuration and scheduling mechanism based on the actual container weight distribution at the port. Since a large number of containers in port transport tasks weigh less than the design capacity of heavy-duty vehicles, uniformly using heavy-duty vehicles results in a waste of resources, essentially "using oversized vehicles for small loads." Furthermore, existing AGV scheduling methods often treat vehicles as homogeneous transport resources, or allocate them solely based on vehicle location, idle status, battery level, and route status, failing to incorporate "predicted container weight data, container type data, and differences in vehicle parameters across different load levels" into a unified vehicle type matching rule. This leads to low-load tasks potentially being assigned to high-cost, heavy-duty vehicles with large turning radii.

[0004] Therefore, there is a need for a method and system for scheduling mixed fleets of horizontal transport at container ports that can be optimized based on container weight prediction, vehicle type differentiation configuration, and actual transport data feedback. Summary of the Invention

[0005] This application provides a method and system for scheduling mixed fleets in horizontal transport at container ports, which can solve the technical problem of how to accurately match and dynamically schedule automated guided vehicles of different load levels based on known container weight and type data in horizontal transport operations at container ports.

[0006] The technical solution adopted in this application to solve the above-mentioned technical problems is a method for scheduling mixed fleets of horizontal transport in container ports, including: Obtain the container weight and container type data of the container to be transported, and generate the transportation tasks to be assigned based on the container weight and container type data; A mixed fleet model is established, which includes a first type of automated guided vehicles and a second type of automated guided vehicles; Based on the container weight data, container type data, and preset container weight threshold, vehicle type matching is performed on the transportation tasks to be assigned to obtain vehicle type matching results; Based on the vehicle model matching results and vehicle status, the target vehicle is determined from the automatically guided transport vehicles of the matching category, and the transport task is issued to the target vehicle to perform the transport operation. Collect actual transportation data during the target vehicle's transportation task, and update the preset container weight threshold and / or the vehicle type configuration ratio in the mixed fleet model based on the actual transportation data to form a dynamic optimization of mixed fleet scheduling.

[0007] In one embodiment of this application, the rated load of the first type of automated guided vehicle is greater than the rated load of the second type of automated guided vehicle; The first type of automated guided vehicles differs from the second type of automated guided vehicles in at least three parameters: rated load, number of axles, vehicle length, tare weight, and turning radius.

[0008] In one embodiment of this application, the preset box weight threshold includes a first threshold and a second threshold, wherein the second threshold is less than the first threshold.

[0009] In one embodiment of this application, the step of matching the vehicle type to the transportation task to be assigned based on the container weight data, container type data, and a preset container weight threshold, and obtaining the vehicle type matching result, further includes: In response to the container weight data of the container to be transported being greater than a first threshold, or the container type data of the container to be transported being a special type, the corresponding transportation task to be assigned is matched to the first type of automated guided vehicle.

[0010] In one embodiment of this application, the step of matching the vehicle type to the transportation task to be assigned based on the container weight data, container type data, and a preset container weight threshold, and obtaining the vehicle type matching result, further includes: When the weight of the container to be transported is less than the second threshold, the corresponding transport task to be assigned is matched to the second type of automated guided vehicle.

[0011] In one embodiment of this application, the step of matching the vehicle type to the transportation task to be assigned based on the container weight data, container type data, and a preset container weight threshold, and obtaining the vehicle type matching result, further includes: In response to the container weight data of the container to be transported being between the first threshold and the second threshold, the task is preferentially matched to the second type of automated guided vehicle; If there are no available second-class automated guided vehicles, they will be matched with first-class automated guided vehicles.

[0012] In one embodiment of this application, determining the target vehicle based on the vehicle model matching result and the vehicle status further includes: The principle of proximity scheduling is adopted, and the vehicle closest to the starting point of the task is selected as the target vehicle to perform the transportation task.

[0013] In one embodiment of this application, the step of determining the target vehicle based on the vehicle model matching result and the vehicle status further includes a dynamic rescheduling step: In response to the target vehicle malfunction, vehicle battery level below a preset battery threshold, road abnormality, insertion of an emergency task, or change of the original transportation task, the issued transportation task instructions are canceled or adjusted, and the vehicle is rescheduled based on the updated vehicle status.

[0014] In one embodiment of this application, the first type of automated guided vehicle adopts a four-axle structure; The second type of automated guided vehicle adopts a two-axle structure.

[0015] To address the aforementioned technical problems, this application also proposes a container port horizontal transport mixed fleet scheduling system, including a terminal operating system, a wireless communication network, and multiple automated guided vehicles: The terminal operating system communicates with the automated guided vehicles via the wireless communication network. The terminal operating system executes the container port horizontal transport mixed fleet scheduling method described above.

[0016] This application provides a method for scheduling mixed fleets of container port horizontal transportation, which reduces the total lifecycle cost of port horizontal transportation by matching vehicle types and dynamic scheduling based on container weight data. Attached Figure Description

[0017] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the specific embodiments of this application will be described in detail below with reference to the accompanying drawings, wherein: Figure 1 This application discloses a step diagram of a container port horizontal transport mixed fleet scheduling method according to an embodiment; Figure 2 A flowchart illustrating the threshold determination and allocation logic for vehicle model matching according to an embodiment of this application is disclosed. Detailed Implementation

[0018] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the specific embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0019] Flowcharts are used in this application to illustrate the operations performed by the system according to embodiments of this application. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, various steps can be processed in reverse order or simultaneously. Furthermore, other operations may be added to these processes, or one or more steps may be removed from these processes.

[0020] Figure 1 This application discloses a step diagram of a container port horizontal transport mixed fleet scheduling method according to an embodiment of the present application, with reference to... Figure 1 As shown, the container port horizontal transport mixed fleet scheduling method of this embodiment includes the following steps: Step S1: Obtain the container weight data and container type data of the container to be transported, and generate the transportation task to be assigned based on the container weight data and container type data; Step S2: Establish a mixed fleet model, which includes a first type of automated guided vehicles and a second type of automated guided vehicles; Step S3: Based on the container weight data, container type data, and preset container weight threshold, perform vehicle type matching on the transportation task to be assigned to obtain the vehicle type matching result; Step S4: Based on the vehicle model matching results and vehicle status, determine the target vehicle from the automatically guided transport vehicles of the matching category, and issue a transport task to the target vehicle to perform the transport operation. Step S5: Collect actual transportation data during the target vehicle's transportation task, and update the preset container weight threshold and / or the vehicle type configuration ratio in the mixed fleet model based on the actual transportation data to form a dynamic optimization of the mixed fleet scheduling.

[0021] This application provides a method for scheduling mixed fleets of container port horizontal transportation, which reduces the total lifecycle cost of port horizontal transportation by matching vehicle types and dynamic scheduling based on container weight data.

[0022] The steps of the container port horizontal transport mixed fleet scheduling method proposed in this application will be described in detail below. It should be understood that, within the scope of this application, the above-mentioned technical features of this application and the technical features specifically described below (such as in the embodiments) can be combined and related to each other to form a preferred technical solution.

[0023] The following describes this application in more detail using a mixed fleet of 65-ton AGVs (Automated Guided Vehicles) and 40-ton AGVs as examples, combined with specific embodiments. However, the implementation of this application is not limited to this and can be extended to other similar scenarios.

[0024] This application provides a method for scheduling mixed fleets of horizontal transport vehicles in a container port, applied to horizontal transport operations between quay cranes and yards in an automated container terminal. The container port includes a Terminal Operating System (TOS), a wireless communication network, several Class I automated guided vehicles (AGVs), and several Class II automated guided vehicles (AGVs).

[0025] Step S1: Obtain the container weight data and container type data of the container to be transported, and generate the transportation task to be assigned based on the container weight data and container type data.

[0026] In this step, before the vessel arrives at the port, TOS obtains the vessel's container stowage information from the vessel's stowage system through the port's data exchange platform. This stowage information includes the container's unique identifier, declared weight, container type, container location, destination yard location, and planned operation time.

[0027] The declared container weight serves as the predicted container weight data. Container types include 20-foot standard containers, 40-foot standard containers, 45-foot containers, extra-wide containers, flat rack containers, open-top containers, and garment containers, etc. TOS cleans and verifies the acquired data, removing data with missing container numbers, empty container weight fields, or abnormal container type fields, and establishes a standardized container operation information database.

[0028] When assigning tasks, the Terminal Operating System (TOS) prioritizes the declared container weight. However, in actual operations, containers are typically weighed at port weighbridges during loading and unloading at the yard or quay crane. This actual weight data is captured by the data acquisition and feedback module and uploaded to the TOS.

[0029] Preferably, when the same container has both the declared container weight from the ship loading system and the actual container weight from the port weighing equipment, TOS will use the actual container weight as the container weight data with higher priority; when the actual container weight has not yet been generated, TOS will use the declared container weight as the basis for vehicle type matching.

[0030] Step S2: Establish a mixed fleet model, which includes a first type of automated guided vehicles and a second type of automated guided vehicles.

[0031] In this step, a mixed fleet model is established in TOS, which includes vehicle static parameters and vehicle states.

[0032] Vehicle static parameters include vehicle number, vehicle type, rated load, number of axles, vehicle length, curb weight, turning radius, maximum speed, and compatible box gantries. Vehicle status includes current location, idle status, current task status, battery level, fault status, estimated arrival time, and current route.

[0033] In one embodiment, the rated load of the first type of automated guided vehicle is greater than the rated load of the second type of automated guided vehicle; The first type of automated guided vehicles differs from the second type of automated guided vehicles in at least three parameters: rated load, number of axles, vehicle length, tare weight, and turning radius.

[0034] In this embodiment, the first type of automated guided vehicle is a 65-ton AGV with a rated load of 65 tons, a four-axle structure, and a tare weight of 28 tons. It is used to transport special container types such as heavy-duty containers, extra-long containers, extra-wide containers, flat rack containers, open-top containers, and garment containers.

[0035] Special container types refer to container types that exceed the scope of standard containers in terms of size, mainly including: extra-long containers, such as 40-foot extra-long containers and 45-foot extra-high containers. These containers are longer or taller than standard 20-foot or 40-foot containers, which places higher demands on the platform length and stability of the transport vehicles; Extra-wide containers / framed containers refer to containers that are wider than standard containers, or framed containers without a top or sides. Their transportation and securing methods differ from standard containers.

[0036] Open-top containers / garment containers, these special types of containers, also require special handling and suitable vehicles during hoisting and transportation.

[0037] Therefore, the criteria for allocating Category 1 65-ton AGVs are listed alongside "special box type" and "box weight greater than 40 tons" because even if the weight of such boxes does not exceed the limit, they still need to be transported by heavy-duty AGVs with stronger performance and more suitable size to ensure operational safety and efficiency.

[0038] The second type of automated guided vehicle (AGV) is a 40-ton class AGV with a rated load of 40 tons. It adopts a two-axle structure and has a tare weight of 18 tons, and is used for transporting medium- and light-load standard containers. Compared with the first type of AGV, the second type of AGV has a shorter vehicle length and a smaller turning radius, making it suitable for use in narrow port roads, intersections, and high-frequency short-distance transportation tasks.

[0039] Using the modeling method described above, TOS can distinguish the load-bearing capacity, traffic capacity, and energy consumption characteristics of different vehicle types when allocating tasks.

[0040] Step S3: Based on the container weight data, container type data, and preset container weight threshold, perform vehicle type matching on the transportation tasks to be assigned to obtain vehicle type matching results.

[0041] Figure 2 This application discloses a flowchart illustrating the threshold determination and allocation logic for vehicle model matching according to an embodiment of the present application, as follows: Figure 2As shown, in one embodiment, the preset box weight threshold includes a first threshold and a second threshold, wherein the second threshold is less than the first threshold.

[0042] The first threshold is 40 tons, which corresponds to the rated load limit of the second type of AGV; the second threshold is 29 tons, which is determined based on the port's historical container weight distribution data and is used to identify medium and light load container tasks that account for a relatively high proportion.

[0043] In one embodiment, the step of matching the vehicle type to the transportation task to be assigned based on the container weight data, container type data, and a preset container weight threshold, to obtain the vehicle type matching result, further includes: In response to the container weight data of the container to be transported being greater than a first threshold, or the container type data of the container to be transported being a special type, the corresponding transportation task to be assigned is matched to the first type of automated guided vehicle.

[0044] In this embodiment, TOS performs vehicle model matching according to the following rules: When the declared container weight exceeds 40 tons, the transportation task will be assigned to a 65-ton AGV. When the container type is a special type, the transportation task will be assigned to a 65-ton AGV. Special types include at least one of the following: extra-long container, extra-wide container, flat rack container, open top container, and garment container.

[0045] In one embodiment, the step of matching the vehicle type to the transportation task to be assigned based on the container weight data, container type data, and a preset container weight threshold, to obtain the vehicle type matching result, further includes: When the weight of the container to be transported is less than the second threshold, the corresponding transport task to be assigned is matched to the second type of automated guided vehicle.

[0046] In this embodiment, TOS matches vehicle types according to the following rules: when the declared container weight is less than 29 tons and the container type is a standard container, the transportation task is matched to a 40-ton AGV. Since containers weighing less than 29 tons account for more than 75%, using a 40-ton AGV can significantly reduce energy consumption and avoid the waste of resources by using a large AGV for a small vehicle.

[0047] In one embodiment, the step of matching the vehicle type to the transportation task to be assigned based on the container weight data, container type data, and a preset container weight threshold, to obtain the vehicle type matching result, further includes: In response to the container weight data of the container to be transported being between the second threshold and the first threshold, the task is preferentially matched to the second type of vehicle; If there are no available vehicles in the second category, the vehicle will be matched to a vehicle in the first category.

[0048] In this embodiment, TOS performs vehicle model matching according to the following rules: When the declared container weight is not less than 29 tons and not more than 40 tons, and the container type is a standard container, the transportation task will be assigned to a 40-ton AGV first. If there is no available 40-ton AGV, the transportation task will be assigned to a 65-ton AGV for supplementary execution, and the principle of nearby scheduling will be followed.

[0049] The above matching rules enable 40-ton AGVs to undertake a large number of medium and light load tasks, while ensuring that heavy load tasks and special box-type tasks are completed by 65-ton AGVs, thus balancing vehicle safety and resource utilization.

[0050] Step S4: Based on the vehicle type matching results and vehicle status, determine the target vehicle from the automatically guided transport vehicles of the matching category, and issue a transport task to the target vehicle to perform the transport operation.

[0051] In one embodiment, determining the target vehicle based on the vehicle model matching result and the vehicle status further includes: The principle of proximity scheduling is adopted, and the vehicle closest to the starting point of the task is selected as the target vehicle to perform the transportation task.

[0052] In this embodiment, the target vehicle for the transportation task is determined from the vehicles with matched vehicle models based on the vehicle model matching results and the real-time status of each vehicle.

[0053] After completing vehicle model matching, TOS determines the target vehicle from the candidate vehicle set corresponding to the vehicle model. The selection of the target vehicle takes into account the vehicle's current location, mission starting point, vehicle battery level, vehicle idle status, vehicle malfunction status, and vehicle current mission status. Specifically, based on the distance between the vehicle's current location and the mission starting point, the nearest vehicle to the mission starting point can be selected as the target vehicle to perform the transportation mission, using the principle of proximity scheduling.

[0054] TOS issues transportation task instructions to target vehicles via a wireless communication network. These instructions may include container number, task origin, task destination, container type, container weight, planned execution time, and recommended route.

[0055] After receiving the transportation task instruction, the target vehicle drives to the task starting point according to the instruction, picks up the container, transports the container to the task endpoint, and transmits the real-time location, operation progress, vehicle battery level, fault status and energy consumption data back to TOS.

[0056] In one embodiment, the step of determining the target vehicle based on the vehicle model matching result and the vehicle status further includes a dynamic rescheduling step: In response to the target vehicle malfunction, vehicle battery level below a preset battery threshold, road abnormality, insertion of an emergency task, or change of the original transportation task, the issued transportation task instructions are canceled or adjusted, and the vehicle is rescheduled based on the updated vehicle status.

[0057] In this embodiment, if abnormal scenarios such as AGV failure, vehicle battery level below a preset battery threshold, road congestion, road interruption, quay crane or yard crane failure, emergency task insertion, original task cancellation, or destination change occur during task execution, TOS initiates dynamic rescheduling and re-executes steps S3 and S4.

[0058] When the target vehicle malfunctions, TOS cancels the unfinished transportation task for that target vehicle and re-executes the vehicle type matching and target vehicle determination steps. When roads are congested or disrupted, TOS updates road conditions and reroutes transportation routes for affected vehicles. When loading and unloading equipment malfunctions, TOS adjusts the sequence of subsequent tasks and reduces the waiting time of vehicles at the malfunctioning loading and unloading point. When an emergency task is inserted, TOS reorders the tasks to be executed according to task priority and assigns available vehicles to the emergency task.

[0059] This embodiment, through the above-mentioned abnormal rescheduling mechanism, can maintain the continuity and reliability of scheduling in the actual complex working conditions of the port.

[0060] Step S5: Collect actual transportation data during the target vehicle's transportation task, and update the preset container weight threshold and / or the vehicle type configuration ratio in the mixed fleet model based on the actual transportation data to form a dynamic optimization of the mixed fleet scheduling.

[0061] During task execution, TOS collects actual transportation data. Actual transportation data includes actual container weight, actual container type, actual transportation route, energy consumption per unit mileage, operating time, empty run rate, task completion rate, on-time rate, lane occupancy rate, and vehicle meeting waiting time.

[0062] TOS compares the actual container weight with the declared container weight to determine the weight deviation. When a systematic deviation occurs among multiple containers from a specific route, batch, or customer, TOS adjusts the container weight threshold. For example, if multiple containers declared to have a weight of less than 29 tons are found to be concentrated above 30 tons after actual weighing, TOS adjusts the second container weight threshold from 29 tons to 30 tons to reduce vehicle type matching errors caused by declared weight deviations in subsequent tasks.

[0063] TOS also optimizes the vehicle configuration ratio in the mixed fleet model based on energy consumption per unit mileage, vehicle utilization rate, empty run rate, and lane occupancy rate. For example, when historical statistics show that the proportion of standard container tasks under 40 tons is continuously increasing, TOS outputs a configuration suggestion to increase the number of 40-ton AGVs and reduce the number of newly purchased 65-ton AGVs; when the proportion of heavy-duty or special container tasks increases, TOS outputs a configuration suggestion to increase the proportion of 65-ton AGVs.

[0064] To achieve the above objectives, this application also provides a container port horizontal transport mixed fleet dispatching system, including a terminal operating system, a wireless communication network, and multiple automated guided vehicles. The terminal operating system communicates with the automated guided vehicle via the wireless communication network. The terminal operating system executes the container port horizontal transport mixed fleet scheduling method described above.

[0065] Compared with the prior art, this application has at least the following beneficial effects: First, this application obtains the container weight and type data of the containers to be transported before the task is executed, and matches the vehicle type according to the container weight threshold and container type rules. This allows light and medium load container tasks to be preferentially matched with Category II automated guided vehicles (AGVs), while heavy load or special container type tasks are matched with Category I AGVs. Since the rated load, number of axles, vehicle length, tare weight, and turning radius of Category II AGVs can all be lower than those of Category I AGVs, the problem of "oversized vehicles for small loads" caused by uniformly using heavy load vehicles can be avoided.

[0066] Second, this application establishes a mixed fleet model including both Type I and Type II automated guided vehicles (AGVs), enabling port horizontal transport vehicles to be allocated differently based on task load requirements and vehicle performance envelopes, rather than being uniformly scheduled as homogeneous resources. Since medium- and light-load tasks account for a relatively high proportion, Type II AGVs can undertake a large number of routine transport tasks, thus reducing overall vehicle procurement costs and unit task energy consumption.

[0067] Third, this application introduces a first container weight threshold and a second container weight threshold during the vehicle matching process. The first container weight threshold is used to ensure the load-bearing safety of the second type of automated guided vehicles, while the second container weight threshold is used to identify medium- and light-load tasks that account for a high proportion of port operations. Since the dual-threshold structure can process low-load, medium-load, and heavy-load tasks in a tiered manner, it can simultaneously take into account safety, vehicle utilization, and scheduling flexibility.

[0068] Fourth, this application collects actual transportation data and updates the preset container weight threshold and / or vehicle configuration ratio based on this data, forming a closed loop from predicted container weight, vehicle matching, task execution, data feedback, and optimized scheduling strategies. Since actual container weight, energy consumption, empty run rate, lane occupancy rate, and vehicle meeting waiting time reflect the true operational status, the system can continuously correct for deviations in declared weight, changes in airline cargo volume, and road congestion, thereby improving long-term scheduling accuracy.

[0069] Fifth, since Type II automated guided vehicles have a smaller vehicle length and a smaller turning radius, using Type II automated guided vehicles in light and medium load tasks can reduce intersection occupation time and vehicle meeting waiting time, thereby improving port road traffic efficiency. In addition, the procurement cost of Type II automated guided vehicles is about 20% lower than that of heavy-duty vehicles.

[0070] When a container port horizontal transport mixed fleet scheduling method is implemented as a computer program, it can also be stored as an article of manufacture in a computer-readable storage medium. For example, computer-readable storage media can include, but are not limited to, magnetic storage devices (e.g., hard disks, floppy disks, magnetic stripes), optical discs (e.g., compact discs (CDs), digital multifunction discs (DVDs)), smart cards, and flash memory devices (e.g., electrically erasable programmable read-only memory (EPROM), cards, sticks, key drives). Furthermore, the various storage media described herein can represent one or more devices and / or other machine-readable media used for storing information. The term "machine-readable medium" can include, but is not limited to, wireless channels and various other media (and / or storage media) capable of storing, containing, and / or carrying code and / or instructions and / or data.

[0071] It should be understood that the embodiments described above are merely illustrative. The embodiments described herein may be implemented in hardware, software, firmware, middleware, microcode, or any combination thereof. For hardware implementation, the processor may be implemented within one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, and / or other electronic units designed to perform the functions described herein, or combinations thereof.

[0072] Some aspects of this application can be executed entirely by hardware, entirely by software (including firmware, resident software, microcode, etc.), or by a combination of hardware and software. The aforementioned hardware or software may be referred to as a "data block," "module," "engine," "unit," "component," or "system." The processor may be one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DAPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, or combinations thereof. Furthermore, aspects of this application may manifest as computer products residing in one or more computer-readable media, including computer-readable program code. For example, computer-readable media may include, but are not limited to, magnetic storage devices (e.g., hard disks, floppy disks, magnetic tapes, etc.), optical discs (e.g., compressed CDs, digital multifunction DVDs, etc.), smart cards, and flash memory devices (e.g., cards, sticks, key drives, etc.).

[0073] A computer-readable medium may contain a propagated data signal containing computer program code, for example, on baseband or as part of a carrier wave. This propagated signal may take various forms, including electromagnetic, optical, and so on, or suitable combinations thereof. A computer-readable medium can be any computer-readable medium other than a computer-readable storage medium, which can be connected to an instruction execution system, apparatus, or device to enable communication, propagation, or transmission of a program for use. The program code located on the computer-readable medium can be propagated through any suitable medium, including radio, cable, fiber optic cable, radio frequency signals, or similar media, or any combination of the above media.

[0074] In the description of this application, it should be noted that, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection between two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0075] Furthermore, the terms “up,” “down,” “left,” “right,” “top,” “bottom,” “horizontal,” and “vertical” used in the following description should be understood as the orientations shown in the paragraph and related figures. This relative terminology is for illustrative purposes only and does not imply that the described device must be manufactured or operated in a specific orientation, and therefore should not be construed as a limitation of this application.

[0076] It is understood that although terms such as "first," "second," and "third" may be used herein to describe various components, regions, layers, and / or parts, these components, regions, layers, and / or parts should not be limited by these terms, and these terms are only used to distinguish different components, regions, layers, and / or parts. Therefore, the first component, region, layer, and / or part discussed below may be referred to as the second component, region, layer, and / or part without departing from some embodiments of this application.

[0077] The basic concepts have been described above. Obviously, for those skilled in the art, the above disclosure is merely illustrative and does not constitute a limitation of this application. Although not explicitly stated herein, those skilled in the art may make various modifications, improvements, and corrections to this application. Such modifications, improvements, and corrections are suggested in this application, and therefore remain within the spirit and scope of the exemplary embodiments of this application.

[0078] Furthermore, this application uses specific terms to describe embodiments of the application. For example, "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic related to at least one embodiment of the application. Therefore, it should be emphasized and noted that "an embodiment," "one embodiment," or "an alternative embodiment" mentioned twice or more in different locations in this specification do not necessarily refer to the same embodiment. In addition, certain features, structures, or characteristics in one or more embodiments of the application can be appropriately combined.

[0079] In some embodiments, numbers describing the quantity of components and attributes are used. It should be understood that such numbers used to describe embodiments are sometimes modified by the terms "approximately," "approximately," or "generally." Unless otherwise stated, "approximately," "approximately," or "generally" indicates that the numbers are allowed to vary by ±20%. Accordingly, in some embodiments, the numerical parameters used in this application are approximate values, which may be changed depending on the characteristics required by individual embodiments. In some embodiments, numerical parameters should take into account specified significant digits and employ a general method of digit reservation. Although the numerical ranges and parameters used to confirm their breadth of range in some embodiments of this application are approximate values, in specific embodiments, such values ​​are set as precisely as feasible.

Claims

1. A method for scheduling mixed fleets of container port horizontal transport, characterized in that, include: Obtain the container weight and container type data of the container to be transported, and generate the transportation tasks to be assigned based on the container weight and container type data; A mixed fleet model is established, which includes a first type of automated guided vehicles and a second type of automated guided vehicles; Based on the container weight data, container type data, and preset container weight threshold, vehicle type matching is performed on the transportation tasks to be assigned to obtain vehicle type matching results; Based on the vehicle model matching results and vehicle status, the target vehicle is determined from the automatically guided transport vehicles of the matching category, and the transport task is issued to the target vehicle to perform the transport operation. Collect actual transportation data during the target vehicle's transportation task, and update the preset container weight threshold and / or the vehicle type configuration ratio in the mixed fleet model based on the actual transportation data to form a dynamic optimization of mixed fleet scheduling.

2. The container port horizontal transport mixed fleet scheduling method as described in claim 1, characterized in that, The rated load of the first type of automated guided vehicle is greater than the rated load of the second type of automated guided vehicle; The first type of automated guided vehicles differs from the second type of automated guided vehicles in at least three parameters: rated load, number of axles, vehicle length, tare weight, and turning radius.

3. The container port horizontal transport mixed fleet scheduling method as described in claim 2, characterized in that, The preset box weight threshold includes a first threshold and a second threshold, wherein the second threshold is less than the first threshold.

4. The container port horizontal transport mixed fleet scheduling method as described in claim 3, characterized in that, The step of matching vehicle types for the transportation tasks to be assigned based on the container weight data, container type data, and a preset container weight threshold, to obtain vehicle type matching results, further includes: In response to the container weight data of the container to be transported being greater than a first threshold, or the container type data of the container to be transported being a special type, the corresponding transportation task to be assigned is matched to the first type of automated guided vehicle.

5. The container port horizontal transport mixed fleet scheduling method as described in claim 3, characterized in that, The step of matching vehicle types for the transportation tasks to be assigned based on the container weight data, container type data, and a preset container weight threshold, to obtain vehicle type matching results, further includes: When the weight of the container to be transported is less than the second threshold, the corresponding transport task to be assigned is matched to the second type of automated guided vehicle.

6. The container port horizontal transport mixed fleet scheduling method as described in claim 3, characterized in that, The step of matching vehicle types for the transportation tasks to be assigned based on the container weight data, container type data, and a preset container weight threshold, to obtain vehicle type matching results, further includes: In response to the container weight data of the container to be transported being between the first threshold and the second threshold, the task is preferentially matched to the second type of automated guided vehicle; If there are no available second-class automated guided vehicles, they will be matched with first-class automated guided vehicles.

7. The container port horizontal transport mixed fleet scheduling method as described in claim 1, characterized in that, The determination of the target vehicle based on vehicle model matching results and vehicle status further includes: The principle of proximity scheduling is adopted, and the vehicle closest to the starting point of the task is selected as the target vehicle to perform the transportation task.

8. The container port horizontal transport mixed fleet scheduling method as described in claim 1, characterized in that, The step of determining the target vehicle based on vehicle model matching results and vehicle status also includes a dynamic rescheduling step: In response to the target vehicle malfunction, vehicle battery level below a preset battery threshold, road abnormality, insertion of an emergency task, or change of the original transportation task, the issued transportation task instructions are canceled or adjusted, and the vehicle is rescheduled based on the updated vehicle status.

9. The container port horizontal transport mixed fleet scheduling method as described in claim 1, characterized in that, The first type of automated guided vehicle adopts a four-axle structure; The second type of automated guided vehicle adopts a two-axle structure.

10. A container port horizontal transport mixed fleet dispatching system, characterized in that, This includes the port operating system, wireless communication network, and multiple automated guided vehicles: The terminal operating system communicates with the automated guided vehicles via the wireless communication network. The terminal operating system executes the container port horizontal transport mixed fleet scheduling method according to any one of claims 1-9.

Images