Competition between harbors for inbound vessels has been increasing and is projected to continue to do so. Harbor operators attempt to attract carriers by providing faster turnaround times at lower costs than competitors. However, expanding and improving harbor infrastructure to meet these requirements is extremely costly and time-consuming.
Berth allocation refers to the assignment of a set of vessels to respective berth locations within a harbor at respective times. Berth allocation may be optimized for many different objectives, including minimization of time spent in the harbor and minimization of the overall cost of berthing. Accordingly, improvements to berth allocation may efficiently improve berthing speed and cost without requiring changes to harbor infrastructure.
A set of vessels to be berthed can be considered as the demand side of a berth allocation problem. Each vessel is associated with a stay (i.e., visit) duration, an incoming (i.e., arrival) time, vessel-specific attributes such as length and draft, and cargo-specific information such as a preferred storage area or special handling requirements. A harbor's infrastructure represents the supply side of the problem and includes berths with specific size capacities and equipment such as cranes, pumps etc. Additional constraints may include a maximum number of vessels per berth, a minimum distance between vessels and a minimum time between berthing vessels at a same berth position.
Improvements to existing approaches to the berth allocation problem are desired.
The following description is provided to enable any person in the art to make and use the described embodiments. Various modifications, however, will remain readily-apparent to those in the art.
Some embodiments allow a user to define an arbitrary set of attributes for objects (i.e., vessels) and cargo to be matched with the attributes of various berth positions. Vessel attributes may include flexible incoming times. For example, a user may specify an earliest and latest arrival time for a given vessel together with a minimal stay duration, and the system determines an optimal arrival time therefrom. This feature adds a degree of freedom to the berthing problem and models actual anticipated scenarios more realistically than alternatives.
Embodiments may also determine a berth plan in which a vessel is unloaded at a first berth position and is loaded at a second berth position. The first and second berth positions may be located in different berths. The user may selectively indicate whether a vessel is permitted to be assigned such berthings. This aspect allows the berth plan to take into account real customer scenarios in which the handling effort for loading and unloading differs significantly between berth positions. This aspect also allows for planning of vessels which could not otherwise be planned due to different unloading and loading constraints which could not be met at a single berth position. Moreover, this aspect increases the flexibility of the overall set of berth plans and might allow for more vessels to be berthed than otherwise.
Embodiments may model the berth allocation problem as a set partitioning problem. For example, the planning horizon is divided into discrete time intervals and a set of feasible berth plans is generated. Each berth plan represents a feasible berth assignment of a single vessel, considering cargo and vessel-specific attributes (e.g., special handling requirements, vessel draft) and flexible arrival and departure dates. Berth plans which specify movement of a vessel between berth positions during its visit are also generated.
The costs for each berth plan may be determined as the sum of the cargo handling effort and costs for moving a vessel between berth positions (if applicable). The resulting optimization problem is to find a subset of berth plans that provides berthing for each vessel, minimizes total costs, and considers constraints such as, but not limited to, minimum time and spatial distance between vessels, maximum vessel capacity of a berth, and prioritization of berth positions and/or vessels. Such a problem can be solved efficiently using commercial solvers.
The first set of berth plans may have been generated according to some embodiments based on characteristics of each of vessels V1-V6 (hereinafter referred to as “vessel visit information”) and of each of berths 1-4. For example, as denoted by “(C)”, loading or unloading of vessel V5 requires a crane. Vessel V5 has therefore been assigned to a berth which provides a crane, i.e., berth 1.
As shown in
Vessel V5 has moved from a position of berth 3 to a position of berth 1. More specifically, the second berth plan for vessel V5 specifies unloading vessel V5 at the position of berth 3 for a time period which includes time T1 and loading vessel V5 at the position of berth 1 for a time period which includes time T2.
As mentioned above, some embodiments allow for a berth plan to assign a vessel to a first berth position during unloading and to another berth position during loading. It will be assumed that such relocation is associated with a cost penalty (e.g., 100) and other constraints (e.g., 30 min relocation time). According to this example, the total cost of a berth plan as shown in
The respective durations of the incoming (i.e., inbound) and outgoing (i.e., outbound) portions of the berth plan may simply be one-half of the user-specified duration of the whole visit, plus one-half the relocation time. In some embodiments, the respective durations are user-specified or determined based on knowledge of the cargo to be loaded/unloaded, on an average cost of loading/unloading the vessel across all possible berth positions, and/or on other factors.
Initially, at S510, the arrival window for a vessel visit is determined. In the present example, vessel visit information 410 includes information associated with a set of vessel visits I, where each vessel visit is associated with an identifier, e.g., ID1, ID2. The arrival window for a given vessel visit i may be specified in vessel visit information 410 as a range, such as 10:00 to 11:30.
A set of arrival times for the given vessel visit is generated at S520 based on the arrival window. The set of arrival times is a discretized representation of the arrival window. The more arrival times in the set, the more granular the timing of the berthing plans may be. However, more arrival times also increases the time and processing resources requires to solve the berth allocation problem. In the present example, the arrival window is discretized into thirty-minute blocks, resulting in the set of arrival times ETAi for the given vessel visit i of 10.00, 10.30, 11.00, 11.30, 12:00 and 12:30.
Next, the duration of the visit is determined at S530. The duration of the visit may be explicitly specified within vessel visit information 110. In some embodiments, the duration is determined by pre-processing component 430 based on the cargo to be unloaded and the cargo to be loaded. Other techniques to determine the visit duration may be implemented.
S540 includes the determination of options for inbound visit intervals, outbound visit intervals and whole visit intervals. A whole visit interval specifies the start and end times of a visit in which the vessel is unloaded and loaded at a same berth position. An inbound visit interval specifies the start and end times of the unloading-only portion of a visit at a first berth position, while an outbound visit interval specifies the start and end times of the loading-only portion of the visit at a second berth position.
The visit intervals may be determined based on the set of arrival times generated at S520 and the visit duration determined at S530. For example, assuming a whole visit duration of four hours, the set of whole visit interval options HWhole for i=ID1 may be determined as ID1_10:00_14:00, ID1_10:30_14:30, ID1_11:00_15:00, ID1_11:30_15:30, ID1_12:00_16:00, and ID1_12:30_16:30.
The inbound visit intervals and outbound visit intervals may be determined based on the whole visit duration and on a specified relocation time. As described above, the duration of each inbound visit intervals and outbound visit interval may be equal to one-half the whole visit duration plus one-half the relocation time. In some embodiments, pre-processing component 430 determines the inbound visit intervals and outbound visit intervals based on the cargo to be loaded and unloaded, and/or on other suitable factors.
Continuing the present example, the set of inbound visit interval options Hinbound for i=ID1 may be determined as ID1_Inbound_10:00_12:00, ID1_Inbound_10:30_12:30, ID1_Inbound_11:00_13:00, ID1_Inbound_11:30_12:30, ID1_Inbound_12:00_14:00, and ID1_Inbound_12:30_14:30. Similarly, the set of outbound visit interval options HOutbound for i=ID1 may be determined as ID1_Outbound_12:00_14:00, ID1_Outbound_12:30_14:30, ID1_Outbound_13:00_15:00, ID1_Outbound_13:30_15:30, ID1_Outbound_14:00_16:00, ID1_Outbound_14:30_16:30.
Additional visit interval options may be determined for whole, inbound and/or outbound visits lasting longer than the minimum duration, at the cost of additional processing complexity. For purposes of the equations below, the entire set of interval options is denoted as H:=Hinbound∪HOutbound∪HWhole.
Inbound, outbound and whole visit values (i.e., costs) per berth position are determined at S550. Berth information 420 received by pre-processor may specify a set of berths B, e.g., AK1, AK2, KH_C, KH_D, a set of berth positions L per berth position B, e.g., AK1_60, AK1_70, and a set of berth positioning options J, e.g. AK1_60_U, AK1_60_D, AK1_70_U, AK1_70_D, where_D indicates a positioning in which the aft end of a vessel is at the specified berth position and the fore end is at a lower berth position. For example, AK1_60_D indicates that the aft end is at a 60 meter berth position and the fore end is at a 5 meter berth position in the case of a 55 meter vessel. Similarly, AK1_60_U indicates that the aft end is at a 60 meter berth position and the fore end is at a 115 meter berth position in the case of a 55 meter vessel.
Berth information 420 may be provided by a harbor employee. The berth positions may be specified at any granularity (e.g., every 2 meters, every 10 meters, every 25 meters), with finer granularity providing more planning flexibility but requiring more processing time and resources. Berth information 420 may further specify a maximum number of ships per berth Ob and time intervals bkI for which a section of or an entire berth cannot be used for berthing (e.g., due to maintenance work at the berth).
Pre-processing component 430 may determine costs per berth position at S550 based on the cargo to be loaded and unloaded at each berth position, the equipment available at each berth position, the distance from each berth position to storage for the cargo to be unloaded or loaded, etc. Such information may be provided by vessel visit information 410 and berth information 420. For purposes of the equations below, the determined costs may be represented as follows:
chjI=“Cost of inbound visit interval option h at berth option j”,∀h∈HInbound,j∈J
chj0=“Cost of outbound visit interval option h at berth option j”,∀h∈HOutbound,j∈J
chjW=“Cost of whole visit interval h at berth option j”,∀h∈HWhole,j∈J
In some embodiments, chji and chj0 each include half of a vessel relocation penalty.
Also defined for is {tilde over (c)}i, which represents the cost of not planning visit i. {tilde over (c)}i supports embodiments in which an optimal set of berth plans might not include berthing a particular vessel, even considering the (presumably high) cost of not planning the visit. As will be described below, some embodiments define a virtual berth to which a visit may be planned, where the cost of the visit is {tilde over (c)}i. {tilde over (c)}i may be defined within vessel visit information 410 by a vessel operator, or may be assigned by a harbor operator based on vessel priorities (e.g., a higher priority vessel is associated with a higher value of {tilde over (c)}i).
At S560, it is determined whether additional vessel visits should be considered in the generation of the set of berth plans. If so, flow returns to S510 and proceeds as described above with respect to a next vessel visit. If not, process 500 terminates.
Returning to
Solver 440 determines values of decision variables xhji, xhj0, xhjW, zi which minimize objective function 470 based on the information from pre-processing component 430 and in view of Boolean parameters 450 constraints 460. Objective function 470 according to some embodiments is as follows:
Constraints 460 may fall into several different categories. For example, constraints 460 may consist of assignment constraints to ensure that each vessel is associated with a single berth plan and that each inbound berthing is associated with a corresponding outbound berthing. Such assignment constraints may be represented mathematically as follows:
Constraints 460 may also include temporal constraints to ensure that a vessel moves to an outbound berth only after the inbound berth is complete:
It is noted that the option to schedule separate inbound and outbound berthings for a vessel may be disabled by setting HInbound=HOutbound=0, since xhjI and xhj0 will not exist in that case and the above constraint degenerates to 0<=1. Similarly, the option to consider flexible arrival times may be unused if only a single ETA is provided for each vessel visit.
Other constraints 460 prevent two vessels from occupying the same space at the same time:
Moreover, constraints 460 may include a constraint based on the maximum number of ships per berth (i.e., Kb), where xhjI,O,W means xhjI or xhjO or xhjW:
Solver 440 may comprise any suitable techniques to optimize objective function 470 based on the above-described inputs. Examples include but are not limited to SCIP and CPLEX solvers. The output of solver 440 includes values of xhjI or xhjO or xhjW, zi which specify berth plans 480. Berth plans 480 specify, for each vessel visit of vessel visit information 410, a visit interval for a whole visit at a particular berth position (which may be a berth position of a virtual berth), or an inbound visit interval at a first berth position and an outbound visit interval at a second berth position. Berth plans 480 may be presented to a user (e.g., a vessel operator or harbor operator) using any suitable graphical or other representation.
Pre-processing component 430 and solver 440 may be implemented using any combination of hardware and/or software that is or becomes known. Such combinations may include one or more programmable processors (microprocessors, central processing units, microprocessor cores, execution threads), one or more non-transitory electronic storage media, and processor-executable program code. In some embodiments, two or more components of system 400 are implemented by a single computing device, and/or two or more components of system 400 are co-located. One or more components of system 400 may be implemented using cloud-based resources, and/or other systems which apportion computing resources elastically according to demand, need, price, and/or any other metric.
Client device 610 executes client application 614 to communicate with server application 622 of application server 620. Application server 620 comprises a computing server, distributed group of servers, or cluster of servers which provide services for executing server applications. Web applications executing on application server 620 may receive Hypertext Transfer Protocol (HTTP) requests from corresponding client applications such as client application 614 and provide responses thereto.
In the present example, server application 622 may receive vessel visit information and berth information and pre-process the information as described above. Server application 622 may provide the pre-processed information to solver 624 along with Boolean parameters and constraints to generate berth plans. The generated berth plans may be presented to users via client application 614.
Received vessel visit information, received berth information and generated berth plans may be stored in storage system 630. Storage system 630 may comprise any suitable storage system, including distributed and cloud-based storage systems. The data of storage system 630 may comprise one or more of conventional tabular data, row-stored data, column-stored data, and object-based data. Moreover, the data may be indexed and/or selectively replicated in an index to allow fast searching and retrieval thereof.
Storage system 630 may comprise an “in-memory” database, in which a full database is stored in volatile (e.g., non-disk-based) memory (e.g., Random Access Memory). The full database may be persisted in and/or backed up to fixed disks. Embodiments are not limited to an in-memory implementation. For example, data may be stored in Random Access Memory (e.g., cache memory for storing recently-used data) and one or more fixed disks (e.g., persistent memory for storing their respective portions of the full database).
Section 710 of interface 700 allows submission, for a particular vessel visit, of a vessel ID, length, and draft. Section 710 also allows specification of an arrival window start time and an arrival window end time, which are usable as described above. Section 720 of interface 700 allows submission of details relating to the cargo which is to be unloaded from the vessel during the visit. Similarly, section 730 of interface 700 allows submission of details relating to the cargo which is to be loaded onto the vessel during the visit. As mentioned above, such information may be used to determine a whole visit duration, an inbound visit duration, an out bound visit duration, and berth equipment constraints.
Client device 810 may interact with user interfaces of a service or application executing on application server 820, for example via a Web browser executing on client device 810. These user interfaces may provide the ability to submit vessel visit information and/or berth information, and to initiate generation of a corresponding set of berth plans. The generation of the berth plans may be performed by an application or service executing on application server 820, in conjunction with data stored within database system 830. Database system 830 may also store the generated berth plans.
The foregoing diagrams represent logical architectures for describing processes according to some embodiments, and actual implementations may include more or different components arranged in other manners. Other topologies may be used in conjunction with other embodiments. Moreover, each component or device described herein may be implemented by any number of devices in communication via any number of other public and/or private networks. Two or more of such computing devices may be located remote from one another and may communicate with one another via any known manner of network(s) and/or a dedicated connection. Each component or device may comprise any number of hardware and/or software elements suitable to provide the functions described herein as well as any other functions. For example, any computing device used in an implementation of architectures described herein may include a programmable processor to execute program code such that the computing device operates as described herein.
All systems and processes discussed herein may be embodied in program code stored on one or more non-transitory computer-readable media. Such media may include, for example, a DVD-ROM, a Flash drive, magnetic tape, and solid-state Random Access Memory (RAM) or Read Only Memory (ROM) storage units. Embodiments are therefore not limited to any specific combination of hardware and software.
Elements described herein as communicating with one another are directly or indirectly capable of communicating over any number of different systems for transferring data, including but not limited to shared memory communication, a local area network, a wide area network, a telephone network, a cellular network, a fiber-optic network, a satellite network, an infrared network, a radio frequency network, and any other type of network that may be used to transmit information between devices. Moreover, communication between systems may proceed over any one or more transmission protocols that are or become known, such as Asynchronous Transfer Mode (ATM), Internet Protocol (IP), Hypertext Transfer Protocol (HTTP) and Wireless Application Protocol (WAP).
Embodiments described herein are solely for the purpose of illustration. Those in the art will recognize other embodiments may be practiced with modifications and alterations to that described above.