Illustration use case

De Boer et al. (2022) presented the “one cutter, many barges” problem. This case, illustrated in Figure 1, provides a representative yet simple test case of a real-world project. The basic setup resembles the dredging works for the Fehmarnbelt tunnel. An overall activity is executed until all material has been added to a reclamation from a trench. This activity determines when the simulation is finished. The while activity repeats a predefined sequence activity that is composed of four activities: first a barge moves towards the trench, then a cutter fills the barge, the barge then moves to the reclamation and finally the barge offloads the material to the reclamation, after which the barge is available for a next cycle. In Figure 2, the results are shown as the cumulative location of material in all sites and vessels, while Figure 3 shows the sequencing of activities by all vessels over time. In this example with four barges, the cutter is always on the critical path, as well as the barges when they are being loaded by the cutter. The trench where the cutter is located is also always on the critical path. For the final load, the unloading at the reclamation is at the critical path.

OpenCLSim

OpenCLSim is based on the generic discrete events simulation package SimPy programmed in Python. OpenCLSim has been created as a separate layer on top of SimPy (Matloff, 2009) to mimic concepts from the world of maritime transport. This includes commercial cargo vessels, but also covers dredging or offshore construction. Due to its open-source nature, each maritime contractor can model its own confidential load processes (e.g. pumping, lifting, etc.) with internal code that can remain proprietary. OpenCLSim has been created by Delft University of Technology, research institute Deltares, marine contractor Van Oord and engineering consultancy Witteveen+Bos.

The core of SimPy, and hence the core of OpenCLSim, is a series of events in time. The events can be coupled to states of properties of vessels and sites using conditions. Hence a network of connected events can be created that can adapt to random conditions such as weather events. The core of OpenCLSim is a small library representing the core processes in maritime transportation: the loading and unloading of material – either discrete goods or bulk quantities – and the transport thereof. These events occur in vessels or at sites.

In OpenCLSim, vessels and sites are composed of building blocks to create a site or vessel with certain capabilities, like being able to process and/or move material. A typical trailing suction hopper dredger (TSHD) is a mover and a processor, whereas a classic cutter suction dredger (CSD) on anker lines can only process. Using this modular approach with so-called “mixins” (Bracha, 1990), custom vessel types can be created. The mixins concept is core to OpenCLSim and by design extensible. This means that users can create additional proprietary mixins to model confidential properties. Van Oord, for instance, has an internal class of mixins for dredging and offshore wind installation, but also contributes to open-source mixins that have a more pre-competitive nature. An OpenCLSim simulation progresses until a predefined criterion goal is met. Examples include the removal of an amount of material for capital dredging, the addition of an amount of material for land reclamation, or the installation of a number of components in an offshore wind farm.

Comparing alternatives

The aim of this article is to simulate a range of scenarios and rank these scenarios on a number of classic KPIs and add energy efficiency as an additional KPI. Here we choose the full optimisation case that we can create using a fleet of one cutter with a number of barges from De Boer et al. (2022). We predefine a series of nine available barges with random variations for production speed and energy use. From this available fleet, we compose barge fleets of one up to seven barges. Using the mathematical concept of the binomial coefficient, there are 501 possible ways to combine a fleet of up to seven barges out of nine  . For a project, this would be all barges available in the project period by the contractor, a possible joint venture partner or via third-party rental.

Our optimisation use case is only meant as a verification and illustration of how one could take energy efficiency into account using OpenCLSim. Hence our input values are only selected to be in a reasonable order of magnitude. For more realistic values, information from the proprietary internal fleet equipment databases of a contractor, or the IADC database would be required. In the design of our use case, the cutter is chosen to be five times more expensive than a barge.

The basic approach for energy use is described in Van Koningsveld et al. (2023). The energy use is specified per vessel and for each activity separately. For the maximum energy during the cutter loading phase, we use a large medium-powered cutter of 15kW (IADC, 2014), while for the unloading of the barges, we use a large backhoe dredger of 4kW (IADC, 2014). For sailing, we use a tug of 1kW empty and 2.5 kW loaded. These values represent a Fehmarnbelt-like case where dredged material has to be placed (rather than pumped) in a specific location to prevent spill. Each piece of equipment is also assigned a separate basic energy use during waiting. Of course, for realistic simulations, contractors can query these values from their databases with supplier specifications or from reanalysis of historic experience data.

We run simulations for all these fleets and subsequently analyse all simulations on the KPIs for duration, cost and energy usage. The number of barges is used to discuss flexibility. The aim is first to facilitate the choice for the size of the barge fleet, but also on which specific barges to choose to compose that fleet. For example, there are 126 different configurations to make a fleet of four barges. Figures 4 and 5 show the results of the range of 501 simulations, binned per number of barges. The three main KPIs show quite some variation for small fleets, reflecting the different properties of the barges. For larger fleets, the variation reduces until the KPIs for duration and cost are nearly independent for the fleet size at five or more barges. Figure 4 allows us to conclude that the lowest cost can be obtained for a barge fleet of three to five. The overall project duration has reached a minimum at four barges and does not improve for larger fleet sizes.

Finally, the energy consumption has reached almost a minimum at five barges. The energy use keeps a variation for all fleet sizes. With the three KPIs in mind, the optimal choice is a fleet of three, four or five barges. This reduces the options to 336. We can conclude that the choice for the number of barges is not the most important one due to the variations in fleet composition, but the exact fleet composition is. In a more realistic use case, the mobilisation of each barge also must be taken into account.

Due to the variation in barge properties, a small fleet might sometimes lead to better results for project duration than a large fleet. Hence, the right fleet composition is important for the options of three or four barges, but hardly at five barges. We therefore aim to narrow the search window for the contractor to a manageable number of optimal choices. From our experience with project operations, we define manageable as a list that fits on one page. For each of the choices of three, four or five barges, we identify the optimal result for each of the KPIs. This approach yields nine options, as shown in Table 1.

Table 1, with the optimal choices, shows that four barges lead to the lowest overall cost (scenario c). For optimal project duration, four or five barges can both be optimal (c, d, f, g). For energy use, five barges are best (g), but a scenario with four barges is close (d). This means that four barges will be the most likely choice. However, the cheapest fleet of four barges (c) is different from the most energyefficient fleet of four barges (d). In this case, fleet (d) might be a good compromise as it is close to the cheapest fleet (c) and the most energy-efficient fleet of five barges (g). Without our simulations, including the calculation of energy efficiency, probably fleet (c) would have been chosen. Due to our simulations, an extra fleet option (d) appeared that saves 5.9% fuel with only 1.7% increase in cost compared to (c). Choosing the most fuel efficient option (g) would have saved 8% energy but increased cost by 12.3% compared to (c).

Note that because Table 1 only shows the best choice per KPI, a larger number of alternative fleets might be available, which are a similar compromise as fleet (d). The scatter plot in Figure 5 shows all scenarios with four and more barges. Many options are available that are close to the cheapest and close to the most energy efficient one. There is no option that is both the cheapest and the most energy efficient. Using Figure 5, alternative fleets could be considered in case the availability or mobilisation position of barges changes.

An extra consideration is that with four barges, the single cutter will have 100% occupancy. As there is only one cutter, the cutter will become the critical component of the entire project. Small repairs will immediately result in delays, extra cost and extra fuel. The choice for four barges only fits a setting with an experienced crew and equipment that has just had a docking. A more flexible scenario would be three barges, with only order 80% cutter occupancy. Three barges are sufficient to provide flexibility regarding the capacity to barge handling issues. However, project duration and cost increase rapidly when one barge fails and only two are left. This means that four barges provide partial insurance against barge delays, especially when the project has liquidated damages or a strict termination date for a permit. Note that a large number of barges also has downsides, as it will require additional coordination.

A key follow-up analysis after the major decision as to which fleet to take, is to analyse this choice in more detail. As it is not the cheapest alternative in a highly competitive setting, further analysis is needed to gain support for an energy-efficient compromise choice. One aspect of this is to analyse in detail what the critical path is in this simulation.

Critical path analyser

In a project, the critical path is defined as the sequence of subsequent activities determining the minimum time needed to complete the project. A delay in any task on the critical path immediately causes a delay in the project delivery time. For project planning, it is important to identify the tasks that are on the critical path and the resources occupied by these tasks, because it gives insight into resource constraints and project risks.

Project management will aim to maximise the utilisation of the most expensive assets. The most expensive asset in the example case is the cutter. When we use five or more barges, the cutter will continuously be on the critical path. With less barges, there will be some waiting time until an empty barge arrives. Tasks that are not on the critical path allow for a delay without impact on the delivery time. When the moving activity of a barge is not critical, it can apply green or slow steaming as a strategy by lowering its speed or waiting for beneficial currents. This would further improve the energy and emission footprint of the project as a whole.

To detect activities on the critical path of an OpenCLSim simulation, we need the dependencies between activities. Note that the critical path is not always a unique series of subsequent activities. Independent (parallel) activities can be part of different critical paths of a project. Unfortunately, the trigger of an activity is not logged by SimPy (the core of OpenCLSim) during the simulation. Therefore, we have to derive a posteriori what activity (or what activities) cause an activity to start from the simulation log in combination with the model definition. We implemented two methods to derive the triggers from the log: one method using matching start/stop times of consecutive activities as indicator of a dependency (overestimate due to coincidence) and a second method using the model definition to find the connection between activities (underestimate since not all triggers are in the model definition). Although the information of both methods is incomplete, it leads to successful detection of the critical path in many cases. In our case, the resulting list of critical path activities is the same, which means we can be sure that all critical path activities have been detected.

Once the dependencies are identified, we construct a directed graph with activity duration as weight. We use the longest path function of the open-source Python toolbox NetworkX (Hagberg et al., 2008) in combination with a smart edge-pruning iteration to identify all activities that lie on critical paths. These activities are marked and can be visualised in a Gantt chart. The Gantt chart for our case simulation depicted in Figure 3 shows that resource Extra 1 is the first on the critical path because it has to sail to the trench where the Cutter T is waiting. Once the Cutter T has started, it is continuously on the critical path. In contrast, Barges II and III, Extra I and Carrier A are only on the critical path when they are at the Cutter T waiting to be filled. Finally, Barge II is on the critical path because it has to sail to the reclamation site.

The critical path analyser allows fast detection of activities on the critical path. All sailing activities that are not on the critical path allow for the optimisation of fuel use and routing as described in the next section.

Fuel use and routing

The sailing process involves sailing through route-bounded (ports, coastal seas) and free sailing regions (working areas, oceans). To reduce emissions over the whole project, it is important to be able to compute both cases. For the example in Figure 6, the routing module can be used to sail over the routebounded region and through unbounded regions for the mobilisation and demobilisation phases of a THSD. Strategies commonly used for route choices include emission reduction, fuel use optimisation and increasing comfort and safety. An optimal path can then be found by considering tidal windows (Bakker and Van Koningsveld, 2023), currents (van Halem, 2019) and weather events (see e.g., Grifoll, 2022).

To implement the concept of route-bounded sailing, we have implemented an OpenCLSim “routable” mixin that allows a ship to find its way over a graph. This component can used to sail over prepared network graphs that include information on depth such as De Jong (2022). To implement the calculation of fuel use, we have made it possible to connect the energy module of Jiang (2023). This energy module computes the fuel use and emissions as a function of engine parameters (e.g., engine age, fuel type) and power use (based on power setting and resistance) during sailing. Allowing to sail over the graph can result in more realistic distances travelled and also enables analysis of traffic interference (e.g. in case of capacity restrictions, or speed limitations). If a sailing graph is extended with information on width, depth, currents and sailing limits (e.g., tidal windows), it can also be used to compute more accurate durations and for energy consumptions and emissions.

Integrating simulation results into project planning and BI tools

For further analysis, we take fleet (d) with four barges that has been chosen as the compromise considering all criteria. The choice for a compromise implies that different stakeholders have to be handled that did not get their optimal choice. A detailed analysis of this chosen fleet is required to assess the pros and cons of this fleet. First, we enable this by extending OpenCLSim with a critical path analyser. The results are shown in Figure 3.

The second option is to make it easy for all stakeholders to analyse the simulation in their own context. For this purpose, we present the output results of the simulation as the concepts used by project planners: the Planning and the Schedule (Kelley and Walker, 1959). This is illustrated by the data model of the planners in Figure 7. They define the planning as what must occur and in what order, while the schedule follows the planning and adds timetables to the planned activities. The schedule can be created manually or automatically with scheduling software like CPM (Critical Path Method). An OpenCLSim model definition as in Figure 1 is a representation of what must occur, and can thus be regarded as the planning.

An OpenCLSim simulation subsequently adds timetables to the input, and thus replaces the role of scheduling software like CPM. We extract the schedule afterwards from the OpenCLSim log. The OpenCLSim core of Simpy generates a log of all events. For example, each “Move” by a “ShiftAmount” activity generates an event when it starts and when it ends. If an activity is forced to wait for weather events, it generates two additional events, at the start and end of the waiting. The OpenCLSim event log is reworked into schedule items with a start and stop time that can be plotted in a Gannt chart like Figure 3.

Subsequently, the time ranges of each activity in the schedule/planning are to be linked to the Resources in the terminology of project planners. In classic project planning terminology, activities in the schedule/ planning with associated resources are known as the Work Breakdown Structure (WBS). Each WBS activity is an instance of an Activity Breakdown Structure (ABS) where the resources are not associated yet. For OpenCLSim, the resources are attached to the activities in the model definition in Figure 1. In OpenCLSim, the available resource roles are processor, mover, origin or destination. For practical interpretation, the resources are split into concepts “Sites” and “Vessels”. The table of assignment of the resources to the schedule/planning are “Campaigns”.

The OpenCLSim log has been exported as separate csv files per table in the data model (Figure 7) and recomposed in two of the leading industry standard commercial BI tools: Qlik Sense and PowerBI (Gartner, 2022). Both tools have an optional Gannt chart extension that offers the same interactive behaviour as plots that are part of the OpenCLSim package (Figure 8) or part of dedicated project planning software. These commercial BI tools allow users to connect to data from their company data sources (Yessad and Labiod, 2016). For our example in Figures 4 and 5, we calculated energy use and cost with python code after running the OpenCLSim simulations. This required us to import additional tables into python. For actual applications at contractors, these data typically come from a database connected to the company’s choice as a central BI tool. Hence, for real cases, cost and energy calculations will most likely be done in a BI tool.

Conclusions

Most of the attention in the energy transition goes to equipment-based developments for new vessels, retrofitting and different fuel types (Joung et al., 2020). These measures will need to provide a major part of the IMO targets to reduce the carbon intensity of international shipping in 2030 at least 40%, compared to 2008 levels (IMO, 2022). The other IMO's candidate measures have received less attention but are also needed to meet the IMO targets. This article shows how simulations can add to the mix required for the dredging sector to meet these targets. Simulations are one aspect of the digitisation of processes in ship operation that have a great potential (KPMG, 2021). We believe optimisation can contribute to the energy transition, especially in the short term, while awaiting developments in equipment and fuel type that have a longer time horizon due to the capital investments involved.

We used the existing software framework OpenCLSim to simulate how fleet composition can lead to better choices for energy use, with minimal impact on cost and project duration. The optimisation software is one way to shape the IMO candidate measures that focus on lowering energy use via fleet composition, speed optimisation and speed reduction. IMO indicates that fleet management, logistics and incentives have a GHG reduction potential of 5-50%, voyage optimisation a potential of 1-10% and extensive speed optimisation up to 75% (IMO, 2023). We applied the simulation of vessels to a typical dredging project where one cutter and a fleet of barges carry out the work.

We generated hundreds of possible fleets from a predefined range of vessels. We analysed, ranked and sorted the simulations until – for a small range of fleet sizes – the fastest, cheapest and most fuel-efficient scenarios remained. Although we realise that the benefits from optimisation via simulation are different from case to case, our expert judgement based on these simulations is that contractors may be able to choose a compromise that saves a small percent of fuel, with only a small increase in cost, by considering different fleet compositions.

This already realises the lower reduction potential estimates mentioned by IMO (2023). Further fuel reduction is possible, but that will yield a more than proportional increase in cost. We propose to extend the classic optimisation between the fastest and cheapest option, with the most energy-efficient option.

The simulations we performed are just an illustration of what could be possible with a minimal impact on cost. To achieve realistic numbers on potential energy savings, this work will have to be repeated with actual data. The actual data required for a simulation like this consists of at least 10 numbers per vessel: energy use and production for each of the four dredging phases, the daily cost and the capacity. The typical fleet of a large marine contractor is in the order of 100 vessels. Hence, for realistic simulations, gathering the actual input data can be a significant effort. Moreover, in our example, we used simple bulk numbers to represent loading and sailing. However, for realistic energy simulations, simple bulk numbers are typically not enough to assess production (hence cost and duration) and energy use. Depending on the required accuracy, various subprocesses often need to be modelled in more detail. For example, to account for varying circumstances along a sailed route a semiempirical physics-based method like the one suggested by Holtrop and Mennen (1982) may be required to get realistic values. Proper simulations are an even more valuable investment to scan the full spectrum of possibilities that will contribute to better fuel efficiency in the dredging sector.

An ensemble of simulations can yield various fleets that compromise between duration, cost and energy use. With the critical path analyse we added to OpenCLSim as open source, this compromise can be analysed in detail. First, it will lead to acceptance of this option. In addition, by knowing the critical path more energy can be saved. Vessels that are not on the critical path can lower their speed without extra cost or delaying the project, also known as green or slow steaming. Once our simple numbers are replaced by proper implementation of methods like Holtrop and Mennen (1982), the green steaming potential of a scenario can be calculated upfront.

Reaching the climate goals set by the 2015 Paris agreement is a big endeavour. For the dredging sector, this will require collaboration and joint research, as stated by Verhoeven (2022). OpenCLSim was started with the collaboration of three partners in the Netherlands: Van Oord, Delft University of Technology (TU Delft) and Deltares. For this article, Witteveen+Bos joins the collaboration. OpenCLSim is fully open source and the setup with mixins allows anyone to use and co-develop OpenCLSim, while having the option (by design) to allow to keep sensitive details proprietary. TU Delft could lead in aligning these efforts in our industry. We invite everyone to join us at https://github.com/ TUDelft-CITG/OpenCLSim.

As shown in this article, logistical simulation software can make a project more energy efficient from a contractor's perspective. Energy and emission footprints are gaining importance as project design criteria. Anticipating developments to monetise greenhouse gas (GHG) emissions via legislation, project execution strategies that give the smallest fuel consumption and emission footprints need to be considered. By making such alternatives an optional part of the value offering already, marine contractors can stimulate a conversation with the client and government on the merits of an optimal GHG alternative and on funding in a level playing field. The same simulations could be initiated by governments and clients to explore the range of possible ways to execute a work. The OpenCLSim software we present here will allow to quantify that extra alternative.