1 Simulation in Logistics

In the last century, simulation has found its way into the automotive industry, where nearly each investment is verified by simulation means (see, e.g., Burges and Mayer 2006). Nowadays, this approach becomes more and more accepted in the analysis of logistic processes, especially in the field of container terminals. Early examples for terminal simulation are presented by Khoshnevis and Asef-Vaziri (2000), and an overview of various simulation projects is given, e.g., by Stahlbock and Voß (2008), Angeloudis and Bell (2011), and Dragovic et al. (2017).

The challenge to be managed with this technology is: logisticians normally are not able to handle simulation systems. Therefore, special simulation tools are developed to close this gap between application knowledge and the theory of simulation. First examples and a base for such tools which uses terminal operator’s vocabulary were already published by Boll (1992).

A new field of application of simulation models is coming up this century: The use of simulation for forecasting the operation of the coming shifts and days. These results will support terminal operators in the personal planning for the next days. Additionally, it will start a paradigm change in the short-term planning on the terminal: Instead of waiting for bottlenecks to occur during operation and then to react, terminal operator’s staff in the control room will be able to locate bottlenecks in advance and thus they are in the position to work pro-actively.

2 The Planning Phase of a Container Terminal

As a result of the strong competition between ports and terminals, it is essential to improve service quality as well as to reduce the costs. To satisfy customers’ demand, like short lead times and high quality products, it is nowadays necessary to carry out all operations fast and efficiently. To meet these demands, terminals are looking for new technologies, such as automated transportation systems and process automation. Furthermore, there are many significant industry changes that influence the development of terminals, e.g., ever increasing vessel sizesFootnote 1 in all services and regions, space limitations as well as labor agreements and labor costs. These constraints raise the question whether the terminals will optimize operations to increase the throughput of existing terminals or if new facilities will replace or expand existing capabilities.

However, the more complex and automated the operation at the container terminal becomes, the more rises the importance of a highly sophisticated IT-system to cope with the demands (see Schütt 2015). Nowadays, handling volumes between 6000 and 8000 containers per vessel call are not uncommon in case of mainliner services. Furthermore, some of the influencing quantities have a random character, e.g., arrival times, daily no. of boxes, loading and discharging times of vessels, container movement time of cranes, etc. Last but not least, most decisions have to be made based on uncertainty, as still not all information required is available at the time of the decision making.

With the use of simulation technology, it is possible to reproduce the system “container terminal” as a virtual system in order to analyze an existing or planned terminal in detail. As simulation of logistic processes normally uses IT components as means of representation, the real system “container terminal” has to be represented by a software model that is executable on related (hardware) components and reproduces terminal processes – including fortuitous events – in an equivalent or adequate way, respectively. Thus, a simulation system is a powerful tool by which the user can “play through” and subsequently analyze the processes of a terminal in order to get a transparent basis for the decision-making process.

The planning phases of a container terminal may be supported by means of simulation. For each of these phases, distinct simulation tools have been designed in such a way that users can, even without availing themselves on a software engineer’s specialized expertise, “play through” several scenarios with input parameters chosen by themselves.

As shown in Fig. 2.1, various tasks have to be taken into account during the planning phase. While in the beginning of the planning (pre-planning) the amount of information about the terminal is very small (low level of detail) it increases with time until the implementation of the operation starts at the end of the planning phase. Due to the amount of information available, different simulation tools may be used for the analysis and decision support. In the pre-planning phase, the planner has to think about the annual workflow of the terminal, typically spreadsheets are used in this phase. Knowing more about the seasonality of the container flow and the planning basics of the terminal (area size and quay length) a first calculation of the capacity of the terminal can be done. By getting more information about the operations system, the layout and the technical data of the equipment, detailed planning of the productivity, and the amount of terminal devices needed may be carried out. At the end of this main planning phase and during terminal start-up, the fine-tuning of the (operations) strategies can be supported. Examples for such kind of tools supporting these tasks are discussed in the following sections.

Fig. 2.1
figure 1

Tasks during the planning phase of container terminal operation

2.1 Terminal Capacity

The first question while planning a terminal is calculating terminal’s capacity. A tool working on the lowest level of detail of available information does not consider the operations system the terminal uses (beyond the quay wall). The capacity of a container terminal is limited by the capacity of the container stacking area or the quay. The latter is limited by its length and the capacity of the Ship-To-Shore (STS) cranes available. The aim of such a tool is to identify the current bottleneck of a terminal. With this, the user can determine how much throughput a terminal handles with the existing facilities, as well as the possible capacity of a planned terminal, i.e., how much throughput does the terminal handle in maximum. Such kind of a simulation tool requires a multitude of input data for simulation, e.g.,

  • information about the yearly throughput,

  • its distribution over the year in order to simulate peak times,

  • the number of container slots available in the yard area,

  • the container dwell times regarding individual container types,

  • several vessel types for automated generation of vessel schedules,

  • the apron shape to model the quay in any desired configuration,

  • the distribution of the STS cranes along the quay,

  • a shift plan determining the available work power (if requested).

Figure 2.2 shows a screenshot of the capacity planning tool called CHESSCON Capacity (see ISL 2018) based on Boll (2004). The terminal processes in the yard and other subareas are not regarded in the simulation.

Fig. 2.2
figure 2

Screenshot of the capacity planning tool CHESSCON Capacity

After the simulation runs, the tool evaluates the quay as well as the stacking area and provides information about the utilization of the quay and the crane performance. The user is informed, e.g., if the quay length fits to handle a definite container volume and how many STS cranes are necessary to serve the arriving vessels. For the area evaluation, the tool ideally distinguishes various area types (e.g., areas to stack standard, reefer, dangerous, and empty containers) and provides an indication of the sufficient number of stacking slots.

The terminal operations system responsible for stacking and transporting the incoming and outgoing containers is not examined. This is part of a further step of terminal planning going into details.

2.2 Simulation and Analysis of Container Terminal’s Operations System

The simulation of the operations system used supports the user in investigating planning alternatives or elaborated designs of container terminals. The design comprises the layout and the deployment of equipment. The interdependence of these two factors of terminal superstructure is a focal point of the model, i.e., it investigates which areas are available and which equipment types and operations system should be deployed best.

The evaluation of the simulated container terminal is carried out with regard to economic and technical aspects. The output of the target variables, measured against each other and interpreted, are in particular the costs incurred and the handling volumes achieved. This strategic level covers the planning of new terminals, the expansion of existing ones, and changes in organizational structures. Simulation tools applied for this purpose do not track each single container but the behavior of the whole system “container terminal.” With regard to the simulation analysis of terminal’s operations system, a separate module is usually applied for drawing up appropriate simulation scenarios. The scenario module combines all input data needed by the respective simulation tool and builds a frame for each analysis. In this regard, Hartmann (2004) describes how to generate consistent data.

The simulation approach shown in Fig. 2.3 includes a scenario module (input) and provides the necessary flexibility for taking new concepts of the system interfaces quayside, gate, and railway into consideration. After entering the information about the terminal layout (typically using a graphical editor), the terminal equipment (amount and technical data), and the workload at terminal quayside, gate, and railway station, the tool will generate job lists which have to be processed by the simulation. An animation is used to let the user understand, what happens within the “black-box simulation.” All steps of the operation are recorded into a database to get information, e.g., about waiting and idle times as well as the productivity achieved. With the results of the simulation, the user can calculate the operating costs for each terminal operations system. In the end, a technical and economical evaluation of all analyzed systems will be executed.

Fig. 2.3
figure 3

General procedure for simulation of container terminals. OD Information: Information about the origin or the planned destination of the container

In this way, the whole terminal operation can be analyzed and optimized. Different operations systems (e.g., straddle carriers, Rail- Mounted Gantry (RMG) cranes combined with Automated Guided Vehicles (AGV) or shuttle carriers,Footnote 2 Rubber-Tyred Gantry (RTG) cranes combined with tractor-trailer units or multi-trailers) may be compared by Key Production Indicators (KPI) or costs per container move. Similarly, the layout may be optimized regarding the size of the stacking blocks (length, width, and height) and the traffic control (e.g., one way tracks and priority handling). Furthermore, operations strategies (e.g., for pooling transport equipment, twin, and tandem operation or block allocation) may be analyzed and optimized with tools of this level of detail. The latter delivers valuable insights into organization principles for economic use of terminal resources assuming typical operations cases (see Sect. 2.3).

3 Terminal Start-up, Optimization, and Operational Planning

Additionally to the simulation tools and purposes described at the strategic level (see Sect. 2.2), today, simulation is also used to support commissioning activities as well as the day-to-day operation of container terminals. Both areas of application are discussed in the following subsections mentioning various examples for using simulation in this manner.

3.1 Equipment Emulation

Applying simulation for emulation of terminal equipment has proved to be promising when analyzing (and solving) problems at the operational level. Emulation is defined as “a model that accepts the same inputs and produces the same outputs as a given system” (see IEEE 1989). The emulation is directly coupled to the real Terminal Operating System (TOS). With these attributes, emulation can be used among others for:

  • Evaluation and optimization of strategies used in the TOS

    While in typical simulation tools the control strategies for terminal operations are usually modeled within the tool, in the case of emulation the implemented strategies in the real TOS are used. Thus, a more realistic model may be built using this available level of detail. In this way, the strategies may be optimized by finding the values of their parameters, which fits best to the container flow and equipment used.

  • Test bed for the real TOS

    While the device emulators are reacting in the same manner as the real devices do, the TOS may be tested against a software system instead of the real terminal. Setting up of new releases of the TOS will be much smoother after testing it against software emulators. Furthermore, the tests are more time, maintenance, and fuel saving than testing with the real equipment. This test bed may be used by software engineers as well as by terminal operators.

  • Visualization of new terminals

    Using the 3D-animation component of an emulation tool, the planned operation of new terminals as well as new processes at existing terminals can be demonstrated visually. The animation can be used to explain the changes in operation and to show their benefits.

  • Test bed for acceptance tests of equipment

    Within the start-up phase of a terminal, the acceptance test of devices needs trouble free surroundings. Typically this is not given within this start-up phase. The failures of neighboring subsystems (e.g., STS cranes, horizontal transport, or stacking equipment) will disturb the acceptance test. By using the emulators for related subsystems, these failures can be omitted and the acceptance test may concentrate on the behavior of the device to be tested.

  • Training purposes of terminal operators

    With means of emulation, the crew of the control tower can be trained without impacts on the real operation. They use the real TOS within their training and use the 3D animation as their “looking out of the window.” The evaluation tool shows the results of their work in terms of KPI, e.g., quay crane and vessel productivity or waiting and idle times of the handling equipment. In this way also extreme situations (e.g., breakdown of equipment or delay of vessel arrivals) may be trained without impacts on the real live.

Thus, in contrast to simulation an emulator clones the functionality of the target system. The emulated system receives identical data, works in the same manner, and produces identical results like the original system, i.e., the emulated system imitates the original one (see Rintanen and Allen 2016). Considering terminal simulation elaborated models reproduce, among other things, the behavior of devices applied for container handling. These representations may be used as base for drawing up device emulators. Note, however, that emulation typically represents dynamic aspects of the real system in a more detailed way and that an interface between the emulation model and the TOS has to be built, additionally.

Within simulation tools of container terminals the behavior of the transport and handling devices is modeled. The respective modeling of equipment may be used as a base for drawing up device emulators. Note, however, that emulation typically represents dynamic aspects of the real system in a more detailed way and that an interface between the emulation model(s) and the TOS has to be built, additionally. The core system of the CHESSCON Virtual Terminal tool (see Fig. 2.4) is based on the simulation tool SCUSY (see Boll 1992). The layout definition as well as the evaluation and operation database is re-used. While in the case of simulation the information flow and in particular the control strategies are part of the model (depending on the level of detail available), the real TOS or the implemented TOS algorithms, respectively, cover control tasks in the emulation case.

Fig. 2.4
figure 4

Architecture of CHESSCON Virtual Terminal combining the simulation and the emulation (using the TOS as control module) functionality within one tool

The behavior of the equipment has to be simulated in both cases. While in the simulation tool typically all devices are included in one model, the Virtual Terminal tool provides the Device-emulator Communication Network (DeCoNet) for conducting emulation studies, for details see Kassl et al. (2008). In this way, the (device) emulators may use different computers in a network. Furthermore, this open architecture provides the possibility to use emulators of different suppliers. Thus, a terminal operator may connect the emulator of his device supplier (if available). Especially for the use of complex routing algorithms within the horizontal transport this functionality will be helpful.

Since various modules of the Virtual Terminal tool required for simulation form also the basis for its emulation functionality, the latter may be used as a logical additional function after simulation-based terminal planning. Of course, the level of detail may require some more data concerning the layout or scenario description, but the main input data may be re-used out of the planning phase. In this way, the terminal operator may use the Virtual Terminal tool in a similar way as he applies tools in the field of simulation. Only the interface to the TOS (called business connector) has to be configured by simulation specialists. In the case of emulation, the scenario generator may be substituted by a replay function of historical data, which have been logged during real terminal operation.

The methodology described has been used for the planning, start-up, and is still in operation at the fully automated Container Terminal Altenwerder in Hamburg (Germany). Each software release is still tested against the emulators before “going live” at the terminal. Saanen (2004) and Ha (2007) describe similar approaches as well. While the huge greenfield projects – especially the automated ones – are using this technology as a standard, nowadays also smaller and existing terminals count on emulation for securing new TOS releases and/or training issues. For example, Eurogate IT Services GmbH uses it for optimizing and emulating the terminals of the Eurogate group (see Fig. 2.5 as well as Sect. 2.3.2).

Fig. 2.5
figure 5

Screenshot of the emulation of Eurogate’s container terminal Bremerhaven (Germany)

3.2 Pro-Active Operational Planning – Using Simulation to Have a Look into the Future

Most terminals today use a re-active approach within their terminal operation: Terminal planners on the operational level (yard, vessel, berth, and process planners) are using their experience to pre-plan the operation of the next shift/the next days. Sometimes this experience is increased by trainings using the means of simulation as mentioned before.

Once the planning is finished, the staff in the control room is monitoring the operation and is re-acting on bottlenecks that may occur during the operation. Some of these obstacles are generated randomly by breakdowns of equipment, these may not been foreseen at all. But others are a result of the planning parameters, set by the planners. In this case, simulation of the coming shift (or longer periods) may detect them before they occur in reality. The reason for these bottlenecks (e.g., overload of a block with one RTG or congestion due to high traffic in a specific area) may be deleted by changing the planning parameters. This pro-active planning will avoid bottlenecks, which are to be foreseen. With two examples this new and advanced approach will be discussed.

3.2.1 Shift Preview – the Look into the Crystal Ball

The Bremerhaven terminal operator North Sea Terminal Bremerhaven, a joint venture of APM Terminals and Eurogate, uses emulation technology mainly for TOS functionality and strategy testing. But they complained about the time to build scenarios and to run the simulation, as they wanted to use the technology to check the current shift planning. The idea of Shift Preview was born. It includes the following steps (see Fig. 2.6):

Fig. 2.6
figure 6

Stepwise optimization of the planning with Shift Preview

  • Terminal’s shift planner plans the next shift (his day-to-day task).

  • After finishing his planning, he starts the Shift Preview by pressing the backup button of the TOS (in this case NAVIS).

  • The current planning state including the yard inventory, the work queues defined, and all planning parameters (e.g., allocation filters) are imported to the simulation model.

  • A fast simulation starts.

  • After a short time, the result of the forecast for the next shift is presented in a compact format, the Overall Equipment Effectiveness (OEE) evaluation. The OEE combines information about the productivity, the utilization of the used equipment, and the quality of the process within one KPI. Thus, the control staff detects potential bottlenecks or underutilization in one view on the dashboard and may go into deeper in the hierarchical structure of the evaluation to understand the reasons. A similar approach has been used by Pinto et al. (2017).

  • The planner may – after analyzing the results – change some planning parameters and run the simulation again (steps 1–4).

In this way, the shift planner will be set into the position to plan in a pro-active way instead of waiting for bottlenecks during the operation and re-act accordingly. This approach combines the following benefits:

  • All data is directly imported by using the interfaces to the Navis TOS, which are provided by the Virtual Terminal technology. This results in a very fast scenario generation and guarantees a very accurate modelling of the next shift.

  • Instead of asking the TOS for each decision, a model of the TOS is rebuild within the simulation system, which is able to depict the strategies of the real TOS by reading their parameters (e.g., yard planning’s allocation filters). Thus, a very accurate modeling of the strategies has been achieved.

  • The speed of the simulation has been increased by changing from time-based to event-based mode. In this mode, the computer is no longer speeding up by a defined factor (e.g., 5-times real-time), but it jumps from event to event and actualizes the clock in each step. In emulation mode, the interface between TOS and the Virtual Terminal model typically uses asynchronous communication which requires the time-based mode. By using the detailed TOS model, as described before, the faster event-based mode is available.

The system is installed at North Sea Terminal Bremerhaven and the result may be summarized by the statement of the operations manager Marc Dieterich: “Why do we use Shift Preview? …Terminals, which today are not in the position to analyze their operation predictively, are living yesterday!”

3.2.2 SimTOS – Simulation-Based Online Evaluation Engine for Container Terminal Operating System

The SimTOSFootnote 3 approach also combines the TOS with an emulator, but is looking further into the future than the Shift Preview. The approach is being developed in conjunction with a South Korean control system supplier Total Soft Bank (TSB), the University of Bremen (Germany), and the Pusan National University (Korea).

With the help of Big Data, a forecast for expected workload on different areas of the terminal beyond the current shift plan and beyond the current detailed planning schedule can be generated. Historical data, taken from a customer’s terminal, has been analyzed (see Riaventin et al. 2015). Based on these results, the workload as well as container parameters of the future period is forecasted (see Nam et al. 2016).

The resulting scenario may be simulated directly using the configuration shown in Fig. 2.7 (emulation system integrated into the TOS) and again the OEE evaluation supports the planner in finding the optimal planning parameters. This includes the number of equipment and gangs required for the next shifts as well as their allocation to the working queues on the terminal. In this way, the terminal planner is provided with a decision-making support in the field of equipment and staff scheduling for the next days.

Fig. 2.7
figure 7

Emulation system integrated as a tool into the control system (here TSB’s CATOS – Computer Automated Terminal Operating System)

4 Evaluating Ecological Impacts

More and more ecological impacts become important for container terminal planners. Therefore, the integration of these aspects into simulation tools is state of the art. As an example, the inclusion of an acoustical analysis into the tool CHESSCON Simulation will be shown in this section. The aim is to provide the planner of a container terminal with noise-relating evaluations. It shall be mentioned that the planner still works within the same environment using his well-known tools and that any noise-relating facts are reduced to a minimum. The implementation needs the following three steps (see Fig. 2.9):

  • Generating sound emission in the simulation model

    Inside simulation tool, all devices used from the available terminal equipment are included with their technical parameters (device type definition), as far as they are required for the task of productivity and cost evaluation. Additionally, a database was created containing known types of devices and their noise values for different states of operation (device noise parameters). Afterwards, these values will be used to calculate the emissions of the terminal by allocating the devices saved in the database with the states of operation measured in the simulation. Noise emissions are created in each active operating state, i.e., when a device moves around, receives/delivers a container or even when it is standing still with running engine. Each action generated by the simulation will be recorded in a given time pattern (1 h) and assigned to the corresponding sector(s). After the simulation finished, there will be information for each sector which device has worked (in each time slot) how long in which operating state (state/time).

  • Noise transmission

    While generating device related emission values is part of the main module of the simulation tool, the noise propagation calculation is realized by means of an additional module. The (transmission) formulas using climate correction parameters correspond to the norm DIN ISO 9613-211 (see DIN 1999). The calculated emission results can be provided as one overall value and/or as value for each sector of the terminal area. Figure 2.8 illustrates the graphical output which allows a fast overview of emission distribution. Each sector of the emission diagram is dyed regarding the amount of noise emissions.

    Fig. 2.8
    figure 8

    Noise emission of each sector of the terminal (color regarding the amount of noise emissions)

    Fig. 2.9
    figure 9

    Modules of the noise evaluation enhancement called EPSIC (see Hünerberg et al. 2009)

A planner using related emission diagrams can identify noise sources that have a great impact on the target locations and he is able to modify the planning (at short notice). Relocating areas with a strong noise impact or implementing noise protection packages may help to reduce the noise impact at the target location. This tool gives the planner the possibility to make noise-relating decisions at a point in time long before the beginning of the licensing procedure for envisaged (terminal) construction measures, which may avoid protracted, and therefore, expensive amendments.

5 Conclusion

Nowadays, there is a large range of simulation tools which are mostly used for analyzing and solving (planning) problems at the strategic level. This concerns, e.g., the planning phase of new (greenfield) terminals or the reorganization and optimization of existing terminals structures. In recent years, more and more simulation technology was also applied to operational issues within the start-up phase of new terminals using the principle of equipment emulation (see Sect. 2.3.1). In the emulation case, an interface between the simulation tool and the TOS is necessary to combine the material flows of the emulation model with the information flows of the TOS (induced by the implemented strategies for resource control).

Additionally, the tool examples presented in Sect. 2.3.2 show that simulation technology is already taking place in the day-to-day operation of container terminals. The main idea of these tools is that the terminal operator is not required to define extra scenarios to start simulation or emulation runs, respectively. Instead, operational planning and forecasting results are used for scenario definition. They will just be a (further) component part within the TOS and can be used for a look into the “crystal ball” (at any time). This way terminal operators have an effective instrument for meeting the tremendous operational challenges of today, such as the processing of mega container vessels (with thousands of containers) in comparatively short berthing times.

Furthermore, ecological impacts may be analyzed in the field of noise emissions by combining the simulation of terminal operations with appropriate emission parameters. Using transmission formulas, the noise impact of a terminal at any point in the surrounding area may be calculated. As a result, the terminal planner is able to evaluate related impacts in a very early planning phase, long before the licensing procedure forces him to do. At this stage, a re-planning is much cheaper than it will be later on. In a similar way, the carbon footprint of the terminal may be calculated by assigning emission parameters to the device types in use.

By making simulation technology accessible to logisticians and management, numerous software solutions have helped simulation to find its way into the logistics and provide support, e.g., for planning “greenfield” projects, optimizing processes, and implementing new control strategies, thus contributing to major cost savings and quality improvements in the industry.