1. Introduction
Access channels and waterways form the gateway to seaports and simultaneously an important element of coasts and estuaries [
1]. An ‘accessible’ port assures the safe and efficient transit of the calling (sea-going) vessels through the channel. Downtime of the access channel can cause significant waiting times for vessels, which decreases the port’s efficiency. Tide-related accessibility restrictions are a common cause of downtime, especially for the largest vessels, and therefore considered important for port authorities from a nautical-logistical perspective. A port can moreover be congested, meaning that the capacity of its infrastructure is overloaded. Port congestion and downtime are interconnected, which can lead to cascading effects that increase waiting times and thereby further decrease the port’s efficiency [
2].
So far such cascading effects have rarely been considered in port design, as common guidelines typically focus on (the largest) design vessels only [
3]. The most common approach to quantify port accessibility is the method described in the Harbour Approach Channels Design Guideline [
4]. It quantifies accessibility as the percentage of accessible tides for the deepest-draughted vessel(s) in the calling fleet (see also [
5,
6]). Although realistic hydrodynamics and detailed accessibility policies form the basis of this method, it ignores nautical traffic and, consequently, waiting times due to congestion and cascading effects.
Beyond the approach suggested by PIANC [
4], various simulation approaches are available that do resolve waiting times, at varying scales, ranging from micro- to macroscopic approaches [
7]. Most models in the literature are microscopic, meaning they resolve detailed manoeuvres including vessel-vessel and vessel-infrastructure interactions. They tend to focus on waiting times caused by single components of the port network/infrastructure. Examples include heuristic algorithms that minimize congestion-related waiting times at various types of terminals (i.e., [
8,
9,
10]), and on the waterway (i.e., [
11,
12]). Furthermore, analytical agent-based models are available that describe vessel motions and behaviour in waterways (i.e., [
13,
14,
15,
16,
17]), and discrete-event models that focus on land-based terminal operations (i.e., [
18,
19,
20,
21,
22]).
Although successful in estimating the delays of individual vessels at specific components of the port, microscopic models are typically unable to cover the entire port network or the full extent of the traffic, due to computational constraints. Furthermore, they rarely include (realistic) hydrodynamics, detailed accessibility policies, specific berth layouts, and berth allocation policies.
In contrast to the amount of microscopic models, only a few macroscopic shipping models are discussed in the literature. These models focus on traffic flows rather than the behaviour of individual vessels. Koldborg Jensen et al. [
23] used a mathematical model to calculate the efficiency of a waterway, while Tasseda and Shoji [
24] developed a framework to unravel the vessel traffic streams in Tokyo Bay. Queuing theory is another type of macroscopic model [
25,
26].
Macroscopic models, while good at scale, lack resolution to resolve the detailed causes of waiting times. Typically they also don’t include realistic hydrodynamics, detailed accessibility policies, and berth availability information.
Mesoscopic models aim for a compromise where the behaviour of large numbers of individual agents can be simulated but their behaviour is aggregated to the level of objectively distinguishable events (e.g., mooring, (un)loading, unmooring, anchoring). This allows for a realistic representation of important port processes at scale while keeping computation times at acceptable levels. One of the first mesoscopic simulation models for port operations was developed by Hansen [
27] and later expanded by Park and Noh [
28]. These models focused mainly on land-based terminal operations, typically ignoring hydrodynamic aspects like currents and tides. Similar models were presented by Kondratowicz [
29], Hassan [
30], Demirci [
31], Howard et al. [
32], Arango et al. [
33], Ugurlu and Yükseky [
34].
Mesoscopic simulation models with a more prominent focus on nautical traffic, schematize the wet infrastructure as a network of nodes and edges, over which vessels sail and interact. An early model by Clark et al. [
35] studied the Suez Canal, excluding port operations. Some later case-specific nautical traffic models that did include port operations did not include tidal restrictions, such as the work presented by Van de Ruit et al. [
36] who studied the Maasvlakte of the Port of Rotterdam (PoR), and Yeo et al. [
37] who studied the North Harbor of the Port of Busan. Furthermore, the models of Fransen et al. [
38] and Nikghadam [
39] focused on waiting times related to the availability of tugs and pilots in the PoR, but these approaches did not include downtime related to hydrodynamic restrictions.
More complete nautical traffic models with a clear focus on congestion and downtime were designed by Groenveld [
40], whose HarbourSim model did consider the interactions between calling vessels and the port’s infrastructure in detail, including terminals and (tidal) downtime. This model was applied to the Rio de la Plata in the work by Frima [
41]. Moser et al. [
42] created the similar HarborSym. Other comparable models were presented by Macquart [
43], Rayo [
44], Piccoli [
45]. Tang et al. [
46] developed a similar approach, albeit with a different process interaction-based approach. Furthermore, some case-specific nautical traffic models were constructed by Thiers and Janssens [
47] for the Scheldt Estuary, by Almaz and Altiok [
48] for the Delaware River, and by Scott et al. [
49] for the Port of Geraldton. Last, various in-house discrete-event models are known to exist in practice, such as DPCM
® [
50] and SiFlow21 [
51], that claim to include detailed port congestion and tidal downtime, but no detailed information on these models is available in the open literature.
The use of Automatic Identification System (AIS) data to assess waiting times in port and waterway systems is a relatively new trend. Franzkeit et al. [
52] and Ma et al. [
53] focused on vessel waiting times in anchorage areas, Martinicic et al. [
54] analysed arrival and turnaround times of vessels in the Port of Piraeus, Jafari Kang et al. [
55] studied congestion in the Port of Houston, and Steenari et al. [
56] investigated the performance of berths in the Port of Brest. A standalone AIS data analysis, however, is typically insufficient to unravel the detailed causes of vessel waiting times. This is due to the complex dependencies that exist between vessels and port infrastructure that cannot be deduced in full from AIS data alone without additional data and/or simulations [
57].
Although most of the above-mentioned mesoscale nautical traffic models are, in principle, able to resolve the cascading effects due to congestion and (tidal) downtime, none of the openly available models simultaneously accounts for (1) realistic hydrodynamics, (2) detailed accessibility policies, (3) realistic vessel properties, (4) cascading effects of vessel-priority rules, (5) detailed waterway and berth layouts and (6) concrete berth allocation policies. Also, none of the pre-mentioned studies provides a detailed decomposition of the causes for waiting times, let alone validates the predicted waiting times against actually observed vessel data. This paper adresses this gap by presenting a method that relies on a combination of data analysis and mesoscopic modelling.
We analyse one year of AIS data for a liquid bulk terminal in the 3rd Petroleumhaven (3rd PET) in the PoR. Based on these observations we quantify vessel arrivals, laytimes in the anchorage and at the terminals, and vessel departures. Furthermore, we determine sailing speeds, turning times, and the effect of tidal restrictions. We subsequently adapt and use the open-source mesoscopic nautical traffic model OpenTNSim [
58,
59] to reproduce the observed vessels’ behaviour through a hindcast study. The simulation allows us to analyse the effect of detailed hydrodynamics, Under Keel Clearance (UKC) regulations, reported vessel draughts, vessel-priority rules, waterway and berth layouts, and berth allocation policies. We compare the predicted laytimes in the anchorage area with those observed in the AIS data, and unravel which causes contributed to these laytimes, accounting for tidal restrictions, congestion of port infrastructure, and priority in berth allocation. The approach improves our understanding of port performance, which in turn enhances our capability to suggest improvements to port operations and infrastructure (component) design.
Section 2 describes the materials and methods used to set up and validate the nautical traffic model.
Section 3 compares the model results to the AIS data and demonstrates the model’s potential through a brief study of alternative Maintained Bed Level (MBL) designs for the 3rd PET’s entrance channel.
Section 4 and
Section 5 provide a discussion and our conclusions respectively.
2. Materials and Methods
To decompose the waiting times for the liquid bulk terminal in the 3rd PET harbour in the PoR we apply a mesoscale simulation model to hindcast a period for which observed AIS data is available. The following information is required for the model set-up:
-
a geospatial graph of the port network, including:
- -
schematizations of relevant port infrastructure,
- -
governing UKC policies,
- -
priority rules and berth allocation policies; and
-
the calling vessels in the form of agents, including:
- -
dimensions (i.e., length, beam, and draught), and
- -
-
followed trajectories to derive:
- *
origin-destination information,
- *
speeds, and
- *
laytimes in various port areas; and
-
realistic hydrodynamics over the port network, including:
- -
tidal elevations as a function of time and space, and
- -
current velocities at critical locations.
The required information can be derived from available geospatial data, AIS data, and hydrodynamic data (see
Figure 1).
Sub
Section 2.1 describes the case study.
Section 2.2 describes the data sources.
Section 2.3 describes processing steps applied to the AIS data (
Figure 1-I).
Section 2.4 describes the additional steps that are needed for simulation and validation (II).
Section 2.5 describes the nautical traffic model that was applied (III).
2.1. Case Study: 3rd Petroleum Harbour
The PoR is the largest seaport in Europe and serves as a transfer location of various types of cargo (mainly containers and liquid bulk) to other modalities bound for other destinations in Northern and Central Europe. An overview of the nautical infrastructure of the PoR is given in
Figure 2. Sea-going vessels arrive at the port’s Traffic Separation System (TSS) through which they sail to the port entrance, possibly visiting one of the anchorage areas. There are three routes to the port entrance. There is a west-east corridor (i), a north-south corridor (ii), and a north-west-north-east corridor (iii). The southern (northern) and western (eastern) lanes are dedicated to inbound (outbound) traffic, while the deepest-draughted vessels make use of the central access channel, called the Euro-Maasgeul, and its dedicated anchorage areas. There are two deep-sea routes (A and B) that cross the TSS from north(-east) to south(-west).
The 3rd PET is an important transfer hub within the petrochemical cluster of the PoR. Constructed in the 1960s as part of the Botlek expansion, the basin is located along the main waterway, the Nieuwe Waterweg and Scheur (hereafter jointly called Nieuwe Waterweg), 21.5 km inland. Various terminals are located in the basin, facilitating both sea-going and inland vessels. The Botlek Harbour is an important hub as it defines the MBL of the NWW. In 2018, the NWW, and Botlek Harbour have been deepened from 14.5 m to 16.2 m to facilitate partially loaded New Panamax and Suezmax-type vessels up to a draught of 15.0 m. This research focuses on one of the liquid bulk terminals in the 3rd PET that operates these vessels. It has various dedicated jetties and quays for deep-sea vessels, coasters, and barges, with varying MBL and lengths.
To enter the 3rd PET, vessels are prone to a tidal restriction policy, which is summarized in
Table 1. During navigation over the NWW, a vessel is obliged to have an UKC of 10% of its draught, increased with a Fresh Water Allowance (FWA) of 1.0% of the draught up to halfway the waterway and 2.5% of the draught in the remaining part of the channel. The maintained bed level of the NWW is optimized for the deepest-drafted vessels [
60], and varies from 16.2 m MBL in the first half to 16.4 m in the second half of the channel. Given this information, vessels with a draught of 13.0 m or more are prone to a vertical tidal window. Additionally, some vessels are prone to a horizontal tidal window when entering the 3rd PET. Vessels with a length equal to and greater than 180 m and a draught ranging from equal to and greater than 11.0 m (inbound) or 12.0 m (outbound) up to 14.3 m are in principle only allowed to enter or leave when the tidal currents are less than or equal to 2.0 kn. Outbound vessels, however, are exempt from this condition during ebb tide, which is fully accessible. In contrast, vessels with a draught equal to and greater than 14.3 m are only allowed to enter or leave during flood tide when the currents are 0.5 kn and decreasing (ebb tide inaccessible).
2.2. Data Sources
2.2.1. Geospatial Data
Geospatial data is a collective term for all data with a specified geometry. For the approach discussed here, we are interested in a schematic representation of the port’s wet infrastructure.
On the one hand, this relates to the network of waterways that is schematized in the nautical traffic model as a graph, typically consisting of connected lines (edges) and points (nodes). Various geospatial processing tools, such as
Shapely, are available in Python to derive such networks from shapes that mark the fairways and water bodies. Moreover, spatial-temporal processing tools, such as the Python-based
MovingPandas, are able to derive networks by aggregating observed tracks in the AIS data (see
Section 2.2.2). In many cases, more formal versions of such nautical traffic graphs exist. For the Netherlands, for instance, Rijkswaterstaat provides the latest information on the state of its waterways via the Fairway Information System (FIS) (
vaarweginformatie.nl). This network is used in the case study of the 3rd PET (see
Figure 2).
On the other hand, this relates to information on important port infrastructure, such as anchorage areas, fairways, turning basins, and berths. Generally, it is sufficient to specify such infrastructure in the form of shapes that specify their position and outline. In some cases further metadata is needed, e.g. the capacity of an anchorage area or berth, the applicable UKC policy for a fairway section. Port authorities may also have accurate geospatial datasets including metadata that can be used. In this research the geometric extents of the 3rd PET, the PoR and the areas of the TSS (see
Figure 2) were obtained from
OpenStreetMap using the open data mining tool
Overpass turbo. A polygon containing a specific area between the breakwaters, used in the AIS analysis in
Section 2.3.1, was created using GoogleEarth. Specific geospatial data with metadata on MBL and FWA was obtained via PoR, through its
Port Map application.
2.2.2. AIS Data
The AIS is an automatic vessel tracking system that is primarily used to guarantee safety in waters with heavy traffic. It consists of time series of various types of messages that contain either static vessel properties (e.g. the vessel’s unique Maritime Mobile Service Identity (MMSI) number, the vessel type, the vessel’s dimensions) or dynamic vessel properties (e.g. location, Speed Over Ground (SOG), Course Over Ground (COG)). The dynamic data is transmitted with a higher frequency than the static data; every 2–10 seconds a message is transmitted for a sailing vessel, increasing to 180 seconds for an idle vessel. By combining the static and dynamic components, the transit information of each individual vessel can be gathered, stored, and researched. Raw AIS data is available in National Marine Electronics Association (NMEA) encoding. The open-source Python package
PyAIS can be used to decode this raw data and convert it into readily usable dataframes (i.e.
Pandas,
MovingPandas). Ready-to-use, pre-decoded, and cleaned AIS data products may in some cases be available from organisations like the coast guard or the local water authority. For this study, decoded, anonymized AIS data for the entire area of the PoR, including the TSS, for the entire year of 2019 was provided by Rijkswaterstaat. The anonymization algorithm ensured that the vessels maintained a unique vessel ID. The data processing that was applied to this AIS data is discussed in
Section 2.3.
2.2.3. Hydrodynamic Data
Hydrodynamic data is required for the calculation of the vertical (water levels) and horizontal tidal windows (current velocities), where and if applicable. The data can furthermore be used to determine the vessels’ sailing speed over water. A useful data source should specify this hydrodynamic data as a function of time in at least two strategic locations. Data from measurement stations could be interpolated to relevant locations, e.g. to key nodes of the nautical traffic network. More measurement stations increase the accuracy. Another option, that is applied in this research, is the use of a well-calibrated and validated hydrodynamic model. The PoR makes current hydro-meteo data available via its
Weather, Tides and Water Depths platform. An important tool in this platform is the Operationeel Stromingsmodel Rotterdam (OSR) that calculates water levels and currents, while constantly being re-calibrated with the most recent measurement data. This numerical model calculates the present hydrodynamic situation and makes a 24-hour prediction on a daily basis. Furthermore, hindcast simulations can be made with the model, which was done for this study. Hydrodynamic data on relevant locations was acquired by adding monitoring points to the model’s computational grid. The model output was made available in NetCDF-files for further processing.
2.3. Data Processing (I)
The decoded AIS data contains information on all types of vessels, including barges, and tugs and pilot boats which constitute the majority of the data received. For our study, we are primarily interested in the behaviour of sea-going cargo vessels. To arrive at the desired level of detail the AIS data had to be filtered and trajectorised, and outliers had to be removed. For this sequence of algorithms, we followed the basic principle of performing the most computationally demanding algorithms on as little data as possible. The processing was performed using the multi-core
Planetary Computer of Microsoft.
2.3.1. Filtering of the AIS Data
Figure 1a shows some first filtering steps that were applied to arrive at the AIS data of interest. By filtering on vessel type, we reduced the overall dataset to cargo vessels and tankers. Next, we used a polygon encompassing the access channel between the breakwaters through which inland barges will not sail. This allowed us to further trim down the dataset to only the sea-going cargo vessels that call at the port. A combined polygon encompassing the berths of the specific liquid bulk terminal in the 3rd PET was used to select only those sea-going vessels that called at the liquid bulk terminal at least once during the entire year of 2019.
2.3.2. Trajectorization into Voyages and Trips
Next,
Figure 1b shows the subsequent steps that were taken to process the AIS data. First we ‘trajectorized’ the now filtered AIS data based on a unique static vessel property (i.c., vessel name). For each vessel, this resulted in a tabulated chronological overview of all time-position combinations in the 2019 AIS data. For each time-position combination, instantaneous vessel properties like speed, heading, and acceleration were added to the table for later use.
Since the total trajectory of one vessel for a given year generally consists of several voyages (or port calls) that in turn can consist of multiple trips (origin-destination combinations), the next processing step is to split the vessel trajectories into ‘voyages’ and ‘trips’.
A ‘voyage’ (or port call) is defined as a vessel’s in- and outbound time-of-stay within the port infrastructure, including the TSS. To distinguish between voyages we made use of a time gap without any messages in a vessel’s trajectory data. The open-source Python package
MovingPandas provides the so-called ObservationalGapSplitter method for this purpose. We used a gap of 6 hours to distinguish between voyages in a vessel’s trajectory data. Each individual voyage was assigned a unique ID for purposes of later analysis.
A ‘trip’ is defined as a subset of a vessel’s trajectory (or voyage) data that can be demarcated by a clear origin and destination. The start and stop of each voyage are taken as origin and destination, respectively. To distinguish between trips within each voyage we made use of the time that a vessel stays at a fixed location. The StopSplitter method of
MovingPandas can be used for this purpose. It creates splits based on the condition that a vessel stays within a certain radius for a minimum duration. Based on trial-and-error we used a diameter of 25 meters and a minimum duration of 30 minutes to identify intermediate stops in each voyage. Each individual trip was assigned a unique ID for purposes of later analysis.
As the StopSplitter operation proved to be time-consuming, we separated the trajectory data of each vessel into sub-sets of roughly equal size. This allowed for parallel processing, which greatly reduced the processing time. One artifact of this approach, however, was that artificial splits were created at the boundaries between the sub-sets. To resolve this, a merge step was required to rejoin sub-trips that belonged together. Another artifact was that the StopSplitter method deletes the trajectory data that falls within its search radius. As a consequence, the start and end points of subsequent trips would no longer match. In some cases, this caused significant shifts in a vessel’s position from the end of one trip to the start of the next, which in turn caused problems in the subsequent analysis. To resolve this issue the deleted data was retrieved and restored.
To focus on the in- and outbound traffic of the 3rd PET, we used the combined polygon of the 3rd PET berths to reject all trips that did not stop or start in this area. The remaining trips were sorted based on their start time, classified as in- or outbound depending on their start- and endpoint, and combined into round trips. If the inbound trip had one of the anchorage areas as its origin, the preceding trip that had this anchorage as its destination was added to the round trip. This resulted in 255 individual ships that undertook a total of 481 unique voyages, consisting of one or two inbound trips to the 3rd PET (depending on whether the vessel laid in one of the anchorage areas) and a single outbound trip from this terminal. Vessel properties such as length, beam, and draught, as derived from the AIS data, were added to each trip dataset. The difference in draught between the in- and outbound trips was added as the (un)loading quantity to each voyage.
2.3.3. AIS Data Outlier Removal
Unfortunately, AIS data is known to contain errors. Some of the AIS fields rely on manual input, so human error is to be expected here. But other fields rely on sensors, such as the vessel’s location as a function of time, as well as its SOG, COG, and derived speeds and accelerations. The last data processing step is to remove errors in this latter kind. Since this is a very time-consuming row-by-row operation this step was performed at the very end on the minimum subset of relevant voyages and trips. The following four conditions for sailing vessels, proposed by Abreu et al. [
61], were used to classify whether a data point was considered anomalous: stop, drift, acceleration, and turning. Based on trial and error the condition for sailing vessels was set to a speed of 2 kn minimum. Suspected outliers were removed accordingly.
2.4. Simulation and Validation Preparation (II)
The processed data from the previous subsection (I) can now be used to generate inputs for the nautical traffic simulation and validation.
2.4.1. Origins, Destinations and Other Trip Data
The ‘real world’ coordinates of origins and destinations can be extracted straightforwardly from the voyage and trip datasets. Next to origins and destinations, each simulation needs at least the following information for each calling vessel: arrival time, sailing speeds along the route, projected turning time in the turning basins, designated berth(s), and the (un)loading time at the berth(s). Also, the vessel’s actual laytime at the anchorage area must be recorded to validate the simulation results.
The designated berths of call are determined using the stoppage data between the in- and outbound ‘trips’. An algorithm counts the number of AIS points that fall inside the different berths and selects the berth with the most hits as the vessel’s most likely berth of call. The unloading times at these berths are estimated from the stoppage intervals between the in- and outbound trips. The time for (de)berthing is assumed to be included in these intervals.
Turning times are estimated with an algorithm that determines the time of stay in the turning basins that the sailing vessel passes during its voyage. The algorithm selects the turning time with the maximum time of stay, as the vessel only needs to turn once during its voyage. This may be during its inbound or outbound trip.
The laytimes in the anchorage areas are determined similarly to the unloading times at the berth, though with the start time of the second part of an inbound trip and the end time of the first inbound trip, starting and ending in the anchorage area respectively. If the vessel did not visit an anchorage area, the laytime is set to zero.
2.4.2. Mapping Locations to the Graph
The nautical traffic model requires the origin and destination nodes for each trip, rather than the ‘real world’ coordinates, to enable routing on the network graph.
To map the trajectories of the AIS trips onto the routing graph we used an algorithm that finds the nearest directional edge in the graph for each coordinate of the trajectory. Since this is a time-consuming operation for large amounts of data and complex, extensive networks, the algorithm was initially only applied to special way-points. These way points were derived based on a running criterion on cumulative distance (1000 m) and cumulative course difference (30 degrees). Based on the identified nearest directional edges of two consecutive way-points, a significantly smaller sub-graph could be defined, which was used for the search of the nearest directional edge for the coordinates between those way-points.
The origin and destination nodes of the trips were determined through a similar nearest-node algorithm. Accordingly, the timestamp of the AIS message closest to the origin node of the first trip was set as the arrival time at the port of the vessel. As vessels may originate from, or are bound for, another location within the port, the origin and destination of a voyage are not necessarily at the TSS. Since we decided to omit the modelling of traffic in the TSS (see
Section 2.5.1), for those vessels that did arrive from, or depart to, this area we decided to set the origin (including the arrival time) or destination to the node at the port entrance between the breakwaters. The observed arrival times of the vessels at this newly defined port entrance are of vessels that were cleared by the vessel traffic service to enter the port, as vessels originating from the TSS will wait in an offshore anchorage area for a tidal window and berth availability. Hence, to be able to quantify and resolve the waiting times in the anchorage areas, the arrival times had to be corrected (brought forward) for the time that the vessel waited in the anchorage area. Thus, if a waiting time is required for a vessel it will be ordered to wait at the port entrance in the nautical traffic model.
Now that the actual routes of the vessels are mapped onto the graph, we can identify speed distributions for each individual directional edge that was covered by the vessels of call. For the simulations in this study, we assumed, that vessels maintain their average speed over the edges. However, since the routes on the graph and AIS trips do not map exactly in space, the actual average speed of the vessel differs from the average vessel speed over the edge. For this study we concluded that the vessel’s average speed over the edge would be the most accurate, meaning that the edge length and arrival time at and departure time from the edge are used to determine the average network speeds. This information was added to the graph so that it would be available for the vessels during the simulation. The vessel speed over the network is important in the calculation of the tidal windows. The slower the vessel sails, the smaller these windows will be.
2.4.3. Adding Tidal Information to the Graph
Next to speeds, the simulations also require hydrodynamic data to be available on the network’s nodes to enable the determination of tidal windows.
Table 1 shows that different tidal restrictions apply for flood and ebb tidal periods. Determining the start and end times of these flood and ebb periods in astronomic tidal hydrodynamic data requires a tidal analysis. We performed a Fourier analysis on the water levels and current velocities, and a (preceding) Principal Component Analysis (PCA) on the current velocity magnitudes and directions. The tidal component analysis is performed using the
Hatyan package. The tidal periods were derived based on the intersection points of the abscissa (current velocity magnitude = 0 kn), i.e. the slack tides.
2.5. Nautical Traffic Model (III)
For our nautical traffic simulations we used the open source Python package
OpenTNSim, which is an agent-based discrete-event simulation package that is based on
SimPy. OpenTNSim provides a library of standardised ‘mixin’ classes that can be combined to create agents or infrastructure components with user-specified properties and behaviour.
Adding the ‘Identifiable’ mixin to an agent, for example, allows the user to give that agent a name and/or a Universal Unique Identifier (UUID). Adding the ‘Movable’ mixin gives that agent the ability to move at a predefined speed. The ‘Routeable’ mixin, which implies ‘Movable’, allows an agent to move over a graph following a specified route with an origin, intermediate waypoints, and a destination. The ‘VesselProperties’ mixin allows the user to specify agent properties, such as length (L), beam (B), draught (T), payload, etc. The ‘Log’ mixin ensures that key information is logged for later inspection.
The same mixins can be used to define infrastructure components in the transport network. Components like anchorage areas, turning circles, berths, jetties, quays, etc. can be named by adding the ‘Identifiable’ mixin. The user can furthermore specify how many vessels can make use of that object at the same time by adding the ‘HasResource’ mixin. If the maximum number has been achieved, i.e. a jetty can handle one vessel at a time and is already occupied, then the next vessel that wants to call on that jetty has to wait until it is available. Waiting is typically done in one of the ports anchorage areas.
Specifically for this study, we developed various new mixins. Most noteworthy are the VesselTrafficService-mixin and a PortInfrastructure-mixin. When these mixins are added to an object, it allows to request information from a port authority, i.e., regarding the availability of a berth, and the availability of a tidal window. The mixins communicate berth availability in advance, meaning that a vessel can already enter the port to sail to their berth of call when a vessel that is occupying this berth is scheduled to leave before the arrival of the next vessel.
The minimum required input for a simulation consists of the port infrastructure network and the generated vessels with their routing information and realistic properties. To achieve this paper’s aim we added the following specifics to the network: the detailed accessibility policies that apply at the different edges (i.e., tidal restrictions, vessel-priority rules), the average vessel speeds per edge, and the hydrodynamic data at key nodes to determine when vertical and horizontal tidal windows are available. The details of the nautical traffic simulation are discussed according to
Figure 3.
2.5.1. Port Infrastructure Network
The waterway network in
Figure 3 was extracted from Rijkswaterstaat’s FIS that includes the PoR area (see also
Figure 2). For simplicity, the TSS was not included. The complex vessel behaviour in the TSS is challenging to mimic and does not affect the waiting times of the vessels that sail to the 3rd PET. Since the TSS contains (the routes to) the anchorage areas, we placed a virtual anchorage at the port entrance to serve as the vessel waiting area. Vessels originating or departing to the TSS were modelled to be bound from/to the port entrance between the breakwaters. The arrival times of the vessels were corrected accordingly (see
Section 2.4.2).
The port infrastructure that was added to this network consists of the port entrance on the most seaward node with the virtual anchorage area, the waterways towards the Botlek area schematised as nodes and edges, the dedicated turning basin for the 3rd PET (for vessels up to a length of 290 m) on the penultimate node, and the liquid bulk terminal in the 3rd PET on the last edge with its various berths for sea-going vessels. The turning time does not contribute significantly to the total turnaround time, however, vessels waiting for other vessels to turn or to pass the turning basin before they can turn can slightly contribute to the waiting times of the vessels.
Key properties of these objects were specified using the OpenTNSim mixin classes. Anchorages, waterways and turning basins were modelled using the ‘HasResource’ mixin. The virtual anchorage area is assumed to have an infinite capacity to prevent vessels from entering the anchorage area and leaving the port without being processed. The waterway edges were also assumed to have an infinite capacity, and they were modelled as bi-directional edges to account for two-way traffic. It was assumed that a safe distance is maintained by the vessels so that encountering does not lead to a reduction in speed. Overtaking by the sea-going vessels is assumed not to occur, as these vessels are sailing over the network with similar speeds. The turning basin can handle one vessel at a time, and the manoeuvre of the vessels is modelled to occur during the inbound trip. Outbound vessels can still occupy the turning basin, as they have to pass through it when leaving the port. The berths of the liquid bulk terminal are modelled using the FilterStore class from
SimPy [
3]. This concept works as a store of products (berths) with each their own properties, such as a name, a MBL, and a maximum ship length that they can operate. The liquid bulk terminal has a few quays that do not have a unit capacity, like jetties, but that have a finite length. These quays, however, contain a limited number of fixed pumping facilities and are therefore modelled similarly to jetties. For simplicity, we assume empty berths at the start of the simulation.
Water level data was added to relevant nodes, and the governing MBL and the UKC policies were added to the edges (see
Figure 3). Current velocity data was included at the critical point along the route where the vessels turn (KM 1015 at the Scheurkade). The water level and current information are used to calculate the tidal windows according to the governing rules that are summarized in
Table 1.
2.5.2. Generated Vessels
For our model implementation, vessels have to be generated with the following required information:
length and draught per trip in the voyage,
origin, intermediate waypoints and destination nodes that constitute the route of the voyage and trips over the network,
arrival time at the vessel’s origin node,
designated berth(s) of call,
turning time in the turning basin,
the (un)loading time(s) at the designated berth(s), and
the change in draught at the berths.
Since we perform a hindcast study, we replicate the observed traffic using the processed AIS data (see in
Section 2.4). Each vessel travels past the nodes that are specified in its route. Between these specified nodes the route is determined with Dijkstra’s shortest path algorithm if needed. The route leads to the designated berth. In reality, berths can be assigned freely based on their properties and restrictions that prevent small vessels from berthing at the deep-sea berths (e.g. a minimum vessel length or draught requirement), which also could have been included in the model.
2.5.3. Modelling Strategy
After the port infrastructure network and the generated vessels have been specified,
SimPy works out how these vessels, together, move through the network. The simulation resolves where and when which vessel needs to wait and for how long. Waiting times in the anchorage area will occur if a vessel has to wait on either a tidal window or unavailable (congested) port infrastructure, either directly or indirectly through cascading effects. Priority rules to be included in the berth planning strategy to minimize the demurrage costs of vessels were omitted in this research but can be included in the model. Instead, the sporadically observed behaviour of newly calling vessels jumping ahead in the queue, over already waiting vessels, was mimicked by giving additional waiting times to these latter vessels. This waiting time equalled the difference between the arrival time between the two vessels and was presumed to be due to the priority rules. To quantify the individual contributions of the tidal restriction, berth unavailability and priority rules to the waiting times of vessels, as well as the cascading effects of these causes, the simulation was also run without tidal windows and prioritization. Besides the reference situation, the model is applied to test alternative MBL designs for the NWW.
4. Discussion
4.1. Further Challenges to Overcome the Approach’s Limitations
Although the results on the quantification of the waiting times are promising, we still found significant discrepancies between the modelled and observed laytimes of vessels in the anchorage area. The method has several limitations that may have to be addressed in future studies.
First, the model presented here relies on an extensive set of geospatial, hydrodynamic, and AIS data. In other case studies, these datasets may be unavailable. The availability of hydrodynamic data, for instance, depends on measurement campaigns and/or numerical models, which may be lacking and are costly to set up. Moreover, AIS data may be protected or absent (i.e., for new ports or future scenarios). While the availability of these datasets is expected to improve the results significantly, the simulation model can be also used with synthetic data.
Second, although the processing and analysis of AIS data successfully resulted in the required information, the dependency of the model on AIS is not fully reliable and could have potentially led to errors in the set-up and validation of the hindcast simulation with the nautical traffic model. AIS data is known to contain errors in the manual, static (i.e., draught) and dynamic (i.e. Global Positioning System (GPS), SOG) information, which was also observed in this research. As severe Global Positioning System (GPS) errors caused idle vessels to drift in space, our method could occasionally not distinguish idle from sailing vessels. These errors have potentially resulted in erroneous laytimes of vessels at the wrong infrastructure. Contributing to this problem was the fact that AIS data was sometimes lacking around the berth areas, seemingly caused by the operators of the vessel that forgot to switch on the AIS. We limited these errors by removing outliers based on the SOG, but this parameter was found to include inadequacies as well. The outlier removal process could therefore not be fully relied upon, and some errors remained to be present. A more extensive analysis may be required for further studies.
Third, various port processes have been neglected in this model that may explain part of the discrepancies and/or may be required in different case studies but were deemed out of scope in this research. Most prominently, the land-based terminal operations were disregarded. These are thought to have a significant effect on the waiting times of vessels, as, based on expert judgement, cargo is occasionally not ready to be (un)loaded. For example, preceding vessels that provide the cargo have not called at the terminal yet, or substances have not been processed by the terminal and cannot be discharged yet. This may lead to long-term, cascading waiting times in the order of several hours to days. Omitted processes that could have resulted in resolving more short-term waiting times are waterway congestion due to ambient traffic, congestion due to limited tug and pilot availability, and downtime due to other external environmental conditions. These processes may interact with each other, as more adverse weather conditions (i.e., strong winds from particular directions) may lead to a higher demand for tugs and pilots, which can exceed their capacity during peak traffic flows. Other neglected processes that affect the speed of vessels, and could have led to delays in the order of several minutes, are vessel encounters and overtaking, vessel properties (i.e., draught), and meteo-hydrological conditions (i.e., currents and winds). Modelling the correct speed for tide-bound vessels is important to calculate the tidal windows. In this study, due to the short distances and few tide-bound vessels, this would not have led to different results. However, we believe that the above-mentioned processes can in fact be included in the discrete-event simulation environment of the model, should a specific case demand this.
Last, the mapping of the AIS tracks onto the network has led to errors in vessel speed. Vessels did not necessarily follow the simplified network. This has contributed to errors in the delays in the order of several minutes. Future research may need to overcome this simplification for cases where small deviations like this are considered problematic.
Still, it is important to note that the majority of the waiting times discussed in this study are not caused by the physical limitations of the port and waterway infrastructure.
4.2. Significance of the Method for New Applications
Although many improvements to the model are possible, we want to stress that our data-driven modelling approach already gives very promising results. By including realistic hydrodynamics, detailed accessibility policies and berth availability information, the model was able to rapidly quantify and resolve the fleet’s laytime in the anchorage area due to the cascading delays of terminal congestion and tidal restrictions. Furthermore, we were able to create a relation between the degree of accessibility of ports, which for the 3rd PET was in accordance with De Jong [
60], and the waiting time of vessels. Therefore, our approach is able to test alternative MBL designs based on the impact of the fleet’s waiting time, rather than on the accessibility percentage of a single design vessel. This is a significant advantage over design-vessel approaches. In particular, the quantification of the cascading effects proved to be highly important for this. Although these effects have a limited effect on the fleet’s waiting time in the current situation, we observed that they become increasingly important when the MBL become shallower and more vessels are affected by the tidal restrictions.
We would also like to mention that the open-source environment of the nautical traffic model enables an excellent opportunity to include further improvements to the model, in joint development with other researchers and stakeholders. We expect that the model is capable of incorporating omitted port processes and infrastructure (i.e., container and dry bulk terminals) with minor additions and alterations. Besides, the model is not limited to the hindcast study that was presented in this paper. We foresee that the model can be implemented in worldwide port and waterway systems for various other purposes. The model could namely be used as an operational tool for real-time modelling or nowcasting to, for example, optimize short-term planning of operations. Moreover, the model can be applied as a forecasting tool on tactical (medium-term) and strategical (long-term) levels, namely to test alternative traffic regulations, accessibility policies, vessel-priority rules, waterway and berth layouts, and the effect of changing fleets of call on the port. Probabilistic and machine-learning tools on AIS data may be required to assist in these model applications. Most distinctively, the model is also suitable for integral design in areas with multiple stakeholders, as it is coupled with a hydrodynamic model. This is particularly useful when modelling alternative port infrastructure designs and port expansions, which may alter the hydrodynamics (i.e. channel deepening, and construction of new harbour basins). Such interventions may lead to enhanced salt intrusion and additional sedimentation, which are important for the functioning of ports and the local society.
5. Conclusions
The work in this paper was triggered by the observation that port accessibility designs are typically based on design vessels while neglecting or simplifying important, cascading waiting times for a representative fleet of vessels due to congestion and port downtime. Such strategies may lead to sub-optimal port and waterway designs.
To investigate this, a method was envisioned that simultaneously accounts for (1) realistic hydrodynamics, (2) detailed accessibility policies, (3) realistic vessel properties, (4) cascading effects of vessel-priority rules, (5) detailed waterway and berth layout, and (6) concrete berth allocation policies. It was postulated that such a method does not as yet exist. Therefore, we developed a discrete-event model that simulates nautical traffic by including these aspects of tidal downtime and infrastructure congestion. The model requires a geospatial graph of the port network, resources that schematise the port infrastructure (i.e., terminals, anchorage areas, and turning basins), agents with properties that represent the vessels of call (i.e., arrival times, draughts, laytimes at the terminal and turning basins), and tidal and traffic restrictions, including vessel speeds and realistic hydrodynamics over the graph. We applied the simulation model to a real-world case study of a liquid bulk terminal in the 3rd PET of the PoR. To derive the required information for this model, we jointly analysed geospatial data, AIS data, and hydrodynamic data from a numerical model. The approach was designed to result in a detailed decomposition of the causes of the fleet’s waiting time, which were validated against the observations in AIS data.
Using the mentioned data sources, we could successfully deploy the nautical traffic model, leading to a reproduction of 73.4% of the non-excessive laytimes, modelling 60.7% of the vessels-of-call in accordance with the observations. 98.0% of the observed waiting time was resolved by the model as terminal congestion while waiting time due to tidal restrictions was limited to only 2.0% of the observed waiting time. This finding met our expectations, as the channel’s MBL is designed for the deepest draughted design vessel that comprises 0.6% of the fleet. Consequently, only 5.0% of the fleet was prone to tidal restrictions, with 1.2% of the fleet having consequential waiting times. The resolved waiting time that was allegedly caused by vessel priority rules was excluded, as experts confirmed that such rules are not in place. Therefore, the cascading effects of tidal restrictions and vessel priority rules were limited for this specific case study. However, by running various alternative MBL designs, these cascading effects became important, highlighting the added value of the modelling approach of a fleet over a design vessel approach.
Still, a discrepancy of 69.2% between the modelled and observed laytimes was found. Most of this waiting time is expected not to be related to the wet infrastructure, but due to (cascading) congestion in cargo flows and other economic considerations. For further studies, improvements to the model may therefore be required. The open-source, and modular structure of the nautical traffic model is highly suitable for this. Despite these potential improvements, the model’s current performance is satisfactory. We have high confidence that our modelling approach will eventually enable us to analyse the inefficiency of the total port system while uncovering the specific, underlying contribution of each specific component. In this way, we can make rational improvements to the port’s wet infrastructure.
Author Contributions
Conceptualization, F.P.B., S.W., F.B., A.K, S.W. and M.K; methodology, F.P.B.; software, F.P.B., S.W., F.B., M.K.; validation, F.P.B.; formal analysis, F.P.B.; investigation, F.P.B.; resources, F.P.B. and S.W.; data curation, F.B.; writing—original draft preparation, F.P.B.; writing—review and editing, S.W., F.B., A.K, S.W. and M.K; visualization, F.P.B.; supervision, M.K.; project administration, M.K.; funding acquisition, M.K.
Figure 1.
Information flows for the set-up and validation of the nautical traffic model, consisting of data processing (I), simulation and validation preparation (II), and nautical traffic modelling (III).
Figure 1.
Information flows for the set-up and validation of the nautical traffic model, consisting of data processing (I), simulation and validation preparation (II), and nautical traffic modelling (III).
Figure 2.
Nautical infrastructure of the PoR (a), including its TSS, and the 3rd Petroleumhaven (b). The TSS consists of three routes to the port (i, ii, and iii); two deep-sea routes are crossing the system (A and B).
Figure 2.
Nautical infrastructure of the PoR (a), including its TSS, and the 3rd Petroleumhaven (b). The TSS consists of three routes to the port (i, ii, and iii); two deep-sea routes are crossing the system (A and B).
Figure 3.
Overview of the nautical traffic model based on an extraction of the graph following the route to the 3rd PET. The MBL, UKC, and FWA policies are added, which may be constant or dependent on the draught (T) of the vessel. The water levels (blue time series) and current velocities (red time series) are added to the nodes of the network.
Figure 3.
Overview of the nautical traffic model based on an extraction of the graph following the route to the 3rd PET. The MBL, UKC, and FWA policies are added, which may be constant or dependent on the draught (T) of the vessel. The water levels (blue time series) and current velocities (red time series) are added to the nodes of the network.
Figure 4.
Overview of the processed AIS data: inbound and outbound vessels are show that are navigating the TSS. Two close-ups are added of the trips’ track through the NWW (A) and the 3rd PET (B).
Figure 4.
Overview of the processed AIS data: inbound and outbound vessels are show that are navigating the TSS. Two close-ups are added of the trips’ track through the NWW (A) and the 3rd PET (B).
Figure 5.
Histograms and distributions of the calibration data derived from the processed AIS data: laytime at the offshore anchorage areas (a), sailing time for inbound and outbound vessels over the NWW and Scheur (b), turning time for inbound and outbound vessels (c), and the laytime at the terminal (d).
Figure 5.
Histograms and distributions of the calibration data derived from the processed AIS data: laytime at the offshore anchorage areas (a), sailing time for inbound and outbound vessels over the NWW and Scheur (b), turning time for inbound and outbound vessels (c), and the laytime at the terminal (d).
Figure 6.
Speed distributions over network derived from mapped AIS data.
Figure 6.
Speed distributions over network derived from mapped AIS data.
Figure 7.
Tidal restrictions of the incoming (a) and outgoing (b) vessels, based on the vessel’s length and draught, according to
Table 1.
Figure 7.
Tidal restrictions of the incoming (a) and outgoing (b) vessels, based on the vessel’s length and draught, according to
Table 1.
Figure 8.
Examples of a tidal window calculation: vertical tidal windows, governed by the net UKC (left axis; a positive value means excess water depth), with a horizontal tidal window based on a critical (panel a, current velocity should be smaller and equal to 2 kn) and a point-based (panel b, the current velocity should be 0.5 kn with a positive and negative spreading of both 30% based on practice) current velocity (right axis).
Figure 8.
Examples of a tidal window calculation: vertical tidal windows, governed by the net UKC (left axis; a positive value means excess water depth), with a horizontal tidal window based on a critical (panel a, current velocity should be smaller and equal to 2 kn) and a point-based (panel b, the current velocity should be 0.5 kn with a positive and negative spreading of both 30% based on practice) current velocity (right axis).
Figure 9.
The causes of the laytimes of the vessels of call in the anchorage area for the base case and for the scenario without inclusion of prioritization.
Figure 9.
The causes of the laytimes of the vessels of call in the anchorage area for the base case and for the scenario without inclusion of prioritization.
Figure 10.
Inverse cumulative distributions of the discrepancies of unloading (a) and loading (b) vessels, including the number of vessels that had unresolved waiting times
Figure 10.
Inverse cumulative distributions of the discrepancies of unloading (a) and loading (b) vessels, including the number of vessels that had unresolved waiting times
Table 1.
Entrance policy for tide-bound vessels to the 3rd Petroleumhaven.
Table 1.
Entrance policy for tide-bound vessels to the 3rd Petroleumhaven.