Using simulation and emulation throughout the life cycle of a container terminal

24 min read
Dec 1, 2017 12:00:00 PM


The life cycle of a container terminal includes four important life stages: design, implementation, operation and optimization. In order to accomplish any one of these stages, it is crucial to use the appropriate approaches and tools. Two essential ingredients that help to accomplish the life stages of a container terminal are simulation and emulation. In this paper the reader is guided through the maturity process of the container terminal, presenting the simulation and emulation approaches and tools applied to support each life stage.


The life cycle of a container terminal includes four important life stages: design, implementation, operation and optimization. Simulation and emulation are two approaches applied to support the success of these life stages (Figure 1). Twenty years ago, TBA BV got the first chance to apply simulation in container logistics. This led to a birth of a product, a simulation model, that aimed to support the early design phase of a container terminal. Key decisions and forecast productivity values, such as possible infrastructure layouts, number and types of handling systems, and the impact of scheduling algorithms were provided to the terminal operator early in the process of a container terminal design. These results were obtained by using a configurable, building-block-based simulation model, representing a container terminal with a valid representation of all handling systems available in the market. During the past twenty years this simulation product has been used in over 500 projects for more than 250 terminals worldwide.


Figure 1: Simulation and emulation support in the life cycle of a container terminal.

After making the design decisions based on the forecast values obtained from simulation, a terminal development project enters the implementation phase. This phase consists of activities such as the construction work, purchase of the handling equipment and selection and implementation of a Terminal Operating System (TOS), and related software. A TOS is a software application that supports the planning, scheduling and equipment control activities of a container terminal and it is responsible for accurate operations within the terminal. As such, it is the heart of terminal operations, making its reliability and ability to enable high performing operations of essence. Implementing a TOS has been always a challenge for container terminals. This challenge created a new opportunity for us when container terminals requested us to assist in the testing of the TOS before actually implementing it in the live terminal. At that time – we are talking 2003 here - we decided to use a new and interesting approach, that was to use the same simulation model that has been used in the design phase with the real TOS instead of the simulated one. This led to a system that combines a simulation of the physical processes at a container terminal and real planning control software (Terminal Operating System). The main purpose of this combined (emulation) system was to test the TOS. This innovative emulation approach was implemented in a product called CONTROLS (which stands for CONtainer TeRminal Optimized Logistics Simulation), and it provides value during the second stage of the lifecycle of a container terminal (Boer and Saanen 2008, Boer and Saanen 2012a). The success of applying an emulation approach in testing the TOS is meanwhile recognized not only by our customers but also by the TOS vendors who could get rid of bugs and performance issues before applying it to live operation, hence reducing the overall cost of implementation. Since the introduction of emulation for testing we applied CONTROLS for more than 30 container terminals.

The next phase of a container terminal is around the go-live in operation. Just before this event, the terminal operation staff needs to be trained in using the TOS. Training used to be an on-the-job process in container terminals with its associated flaws (Boer et al. 2014a). Hence, we proposed to use a ‘near to live’ training environment, consisting of the real TOS with the virtual terminal in the emulation environment. The proper use of the new or updated TOS for the terminal operators is crucial. A proficient use of a TOS for planning and equipment control is essential for efficient and productive operation of container terminals. The degree to which the TOS is used effectively is highly dependent on human operators. We introduced a systematic training approach that we have applied in a number of cases to improve the skills of control room operators on various container terminals. The approach is supported by emulation and allows for accurate measurement of the operator’s performance. As such, we have been able to measure the impact of the training, and the impact of changed ways of operating, in the sense of improved ways of planning and controlling the terminal. Since the introduction of emulation for testing we applied it for more than 30 container terminals.

When using the TOS in live operation, the operators are confronted with a large number of complex options and features provided by the TOS in order to adjust certain strategic planning and dispatching decision, such as grounding or dispatching logic (Bish et al. 2005, Dekker et al. 2006, Van Ham and Rijsenbrij 2012). There is always the option to change and play with these parameters in live operations, but due to the risk of causing a negative effect, it is and should be done with the greatest caution. Besides, operational circumstances vary greatly, making operations to a large extent incomparable. As the effect of algorithm and parameter changes is often subtle, the ‘operational noise’ can be larger than the impact of a change, making the analysis virtually impossible. Again a new challenge and opportunity to use the emulation approach: creating a tuning environment for the business analyst in order to play with different strategies and parameter settings, and thus optimize the terminal operation. Tuning the TOS parameters and algorithms is an optimization approach that does not take place in live operation, but instead in an isolated environment. After business analysts identified the best TOS settings it is adjusted accordingly to the TOS available in live operation. From that moment the terminal planner can create the shift plans (vessel plans, yard plans). Shift plans are usually prepared a couple of hours (up to a day) before the operation begins. In order to achieve a high productivity and meet contractual berthing windows at the lowest costs, it is crucial to find the optimal amount of equipment to deploy. Not only the amount of equipment, but also where they are deployed, and how to pick and drop containers in the yard is key to an efficient operation. In order to create an appropriate shift plan the terminal planner has to properly investigate all these aspects and make a good decision in a limited time frame. To improve the quality of the shift plan, we introduced a new simulation approach called plan validation that supports the planners’ decision making to provide a high quality shift plan within a limited time frame (Boer and Saanen 2014b). The plan validation is an optimization approach that takes place in live operation. 
In the next sections we present each stage of the lifecycle of a container terminal and present the simulation and emulation approaches we developed, and list some examples and lessons learned.


The design process of a container terminal contains two main steps: berth design and handling system design.
In the design process of a container terminal the first step is to determine the dimension of the berth (quay side) taking into account the characteristics that influences the decision such as expected volume, service levels, type of cargo, transshipment ratio, modal split, dwell times, seasonal variation, etc. All these characteristics are surrounded with uncertainty and therefore it is important to analyze the consequences of variations by means of sensitivity analysis. In order to obtain the dimension of the berth that will meet the service level objectives and assumed cargo flow characteristics we need to analyze the vessel service time, gross berth productivities, and crane density on vessels under varying terminal configurations (quay length, number of quay cranes, gross quay crane productivity). For this purpose the principal focus of investigation is the terminal quayside a berth simulation is used (Kim and Moon 2003, Zeng and Yang 2009, Sheikholeslami 2013). Next to determining the quay length and the required number of quay cranes the simulation supports us in decisions such as finding the best locations for berthing the vessels and determining the required quay cranes per vessel.

When the dimension of the quayside is defined one can dive into the more detailed design, namely handling system design. The objective of a handling system design is to arrive at a layout and a plan of equipment types for various operations. This study should provide the number of prime movers (e.g., trucks, straddle carriers, AGVs (Automated Guided Vehicle)) and yard cranes (e.g., RMG (Rail Mounted Gantry), RTG (Rubber Tired Gantry), the number of rail cranes, the number of gate lanes and so forth. This is done by considering different logistical concepts, which includes the way containers are handled through the terminal, where they are stored (stacking strategies) and by which type of equipment (Agerschou et al. 2004, Stahlbock and Voss 2008). The availability of yard space is one of the main factors that influences the selection of handling systems (Chen 1999). As different handling systems, such as straddle carriers, RTGs, wheeled operations or RMGs, have different stacking densities and requirements for horizontal transportation, the throughput ability given a defined yard area varies from ca. 240 TEU/ha for wheeled operation to ca. 1400 TEU/h for a 1 over 5 RMG system. In order to analyze all the possible choices a container terminal simulation library is created that provides a valid representation for all the equipment types and operations. The container terminal simulation library, called TIMESQUARE has been created in a COTS (common-off-the-shelf) simulation package called eM-Plant. During the last twenty years this simulation product has been used in over 500 projects for more than 250 terminals worldwide. All terminal details (layout, equipment and operation) have been modeled thoroughly in order to get a valid and credible representation of a real container terminal. At the time when TIMESQUARE was built the use of simulation for container terminal was not unique yet not widely spread, the research community and other logistics commercial companies were active to use simulation to improve the performance of the container terminal. The research community has been mainly focusing on researching one specific problem using simulation, such as water side operation (Nam et al. 2002, Zeng and Yang 2009, Sheikholeslami 2013), routing and yard strategies (Kim et al. 2002, Lee and Hsu 2007), comparison of equipment types (Vis and Harika, 2004) or land side operation (Azab and Eltawil, 2016), and not simulating the whole terminal in a comprehensive detail. The main reason is commercial, since creating a library that allows to configure all type of container terminals in detail require significant investment. Nevertheless, the theoretical results created by research community provide an excellent input for the commercial community who have the possibility and budget to apply and test them in the practice. Next to TBA, other commercial parties, like Moffatt and Nichol and ISL, are also active in offering consultancy support for container terminals using a simulation packages such as FlexTerm and Scusy.


Two decades ago, the information technology became more and more important in container logistics. Software companies, like NAVIS, TSB, RBS and CyberLogitec, have realized the opportunities and started creating terminal operating systems (TOS), which aim for planning a vessel or yard, dispatch the equipment and supervise the operation on the terminal (Saanen 2010). In a short time, this piece of software that replaced the huge amount of paperwork and supported the terminal operation became a mission-critical product for the terminal. Introducing a new TOS to a terminal has been always a challenging task during the implementation phase, especially because the expectation from the terminal and the quality of the TOS are not always aligned. TBA took the opportunity to use a simulation model to test the TOS before applying it in live operation. The container terminal simulation model, that had been used for terminal design, turned out to be a good candidate to evolve to a next challenge. That was the moment of birth of a complete virtual container terminal (including layout, containers, equipment and operations), that was named CONTROLS and aimed to be coupled to various real TOS systems (Boer and Saanen 2008, Boer and Saanen 2012a). As interfacing between the virtual equipment and the TOS are the same as the real equipment, the TOS system is unaware that it is working with a virtual (simulated) environment instead of the real environment (see Figure 2). The first version of CONTROLS was based on the TIMESQUARE simulation model library. Later, due to the limitations of the eM-Plant simulation package (e.g., interfacing other systems) the whole simulation library was redesigned and implemented in Java.


Figure 2

This approach made it possible to test the quality of TOS systems. It is much more comprehensive than other testing methods. While the other traditional testing methods were mainly pre-programmed scripts used in isolated environments and focusing on a specific operation or equipment, the emulation approach went much further and checks the whole operation and the interaction between equipment and the TOS. The downside, however, is that errors are more difficult to find, due to the complexity of the test scenarios. An important added value of this emulation approach is that next to executing a comprehensive tests and finding bugs in TOS, the container terminal obtains key performance indicators, such as equipment productivity or waiting times. This testing approach that supports the implementation phase is highly appreciated by terminal operators and TOS vendors, and CONTROLS has been applied in more than 30 terminals worldwide for TOS testing.

Although the potential of using emulation for TOS testing has been always an interesting approach for container terminals, there has been very limited research and publications (Boer and Saanen 2008, Schütt 2011, Boer and Saanen 2012a). Furthermore, there were also limited commercial companies that applied this solution. Next to TBA’s CONTROLS it is worth to mention the ISL Applications who created a similar product called CHESSCON, and more recently Moffat & Nichol uses FlexTerm also for emulation purposes.


After successfully testing the TOS the next phase of a container terminal is to go live in operation. Just before this event, the terminal operation staff needs to be trained in using the TOS. The main objective of the training is to achieve a higher terminal productivity by giving operators hands-on knowledge and experience of using the system. This can be translated into the improvement of decision making and planning skills of the individual operators. We expect that improving the skills of individual operators will lead to the improvement of the organization (Read and Kleiner, 1996). The main challenge and difficulty, however, is to train the operators to make serious decisions without causing severe impact in the real operation. To remedy this we proposed the use of serious game training in a virtual reality, which is more effective and efficient than conventional training. Furthermore, it completely avoids the risks associated with conventional training. Most of the training performed on the terminals are either conventional or on-the-job training sessions. Conventional training usually consist of lectures, handbook studies or a combination of the two. The training and/or the training material is sometimes provided by other terminal staff, and occasionally by the TOS manufacturer. Despite its popularity, the conventional type of training cannot completely show the complexity of the real system as it focuses only on isolated learning points and ignores the interaction between the various points. Given its static approach, there are limitations to its ability to effectively train for the dynamic and complex environment that trainees encounter in their daily activities. Furthermore, we observe a pattern in the training material; we’ve seen that it focuses on the planning tools rather than the planning process. The training is IT-driven, and the focus is on the usage of the tool instead of on the actual planning strategies. A relatively new type of training, which has become increasingly popular in defense and health education, is serious game training using virtual reality tools. During this type of training the knowledge and the skills are acquired in a close to reality environment and later transferred to the real world (Waller et al. 1998). This type of training is a combination of games and pedagogy that typically consists of simulation models, which place the trainee in an artificial environment that closely imitates actual working conditions (Bakken et al. 1992) Although the use of virtual reality environments for training is not a very recent practice (Zyda 2005), its use for container terminals was still in infancy. That gap has been filled in by introducing a new systematic and ‘near-to-live’ virtual reality training environment for container terminal planners which has been applied in more than 30 terminals worldwide (Boer and Saanen 2012a, Boer and Saanen 2012b, Boer et al. 2014a).

In one of our training sessions an automated vessel planning module called Autostow from SPARCS (NAVIS) was considered that has been purchased by a terminal but never applied. The lack of knowledge of this new, automated module and the risk to use it in real life operation created barriers for terminal operators, and instead of using it they continued to manually plan the vessels. The emulation-supported training that we have conducted -involving 6 vessel planners- clearly shows the impact of a plan created manually and using Autostow. Each of the 6 planners was targeted to plan the same vessel. The vessel was consequently executed after completion of plan, all against an emulation of exactly the same operation, i.e. the same amount of equipment, the same initial yard, the same behavior of equipment. The results are shown in Figure 3; it shows for each vessel planner the average crane productivity (in boxes/hour) as well as the vessel turn time (in hours). Note that a higher crane productivity does not always mean a shorter turn time, as work distribution among the cranes (up to 4 cranes were deployed per vessel) determines how long it takes to handle a vessel.


Figure 3: Using emulation for training vessel planners.

Three vessel planners were requested to use the provided automated stowage planning module available in the TOS (Autostow). Despite their lacking experience with this tool, they all performed better by using it. Unfortunately, the group is too small to say anything statistically sound about the contribution of the automated stowage planning; however, the results as shown in Figure 3 give a clear indication that it is substantial. The average turn time (see the column in hours, varying from 10.3 hours to as high as 15.7 hours) decreased by 18%, whereas the average crane productivity increased by 26%. Furthermore, all planners that used the automated stowage planning turned the vessel quicker than the ones that practiced common procedures, and additionally they needed 25% less time to complete the planning process. Moreover, we can say that this way of training allows objective measurement, and safe tryout of new methods, in this case for vessel planning. The case studies clearly show that the presented emulation approach indeed provides a safer and cheaper way to test and tweak the TOS and train operators on an emulated virtual terminal.


During the optimization phase of the terminal there are two optimization approaches: tuning TOS parameters and plan validation.

5.1 Tuning TOS parameters

The heart of a TOS system is the planning, scheduling and dispatching modules. These are complex modules with a large number of parameters that have to be properly set in order to achieve the desired performance in the terminal. These parameters are mostly preconfigured by TOS vendors and due to their complexity and the risk they are rarely touched by terminal operators. Playing with these parameters during a live operation can have safety and productivity consequences. This gap opened a new challenge and perspective for emulation and simulation: tuning the TOS parameters in a simulated virtual environment (Boer and Saanen 2012a, Boer and Saanen 2012b). Tuning the TOS parameters and algorithms is an optimization approach that does not take place in live operation, but instead in an isolated environment.

In figure 4 we present a tuning study for an RTG terminal that uses SPARCS terminal operating system. The goal of the study was to investigate the possibility to replace the currently applied yard planning strategy (based on the use of pre-stacks) with controlled random stacking strategy. Proper yard planning strategies help to assign the containers to an optimal position in the yard. As a result of this, the re-handle moves and yard shifts can decrease, and the yard utilization and productivity can increase. There exist different planning strategies, such as pre-marshalling (Chen 1999, Lee and Hsu 2007), sort and store (Kim and Kim 1999, Kim and Park 2003) controlled random strategy (Dekker et al. 2006), etc.


Figure 4

We defined different scenarios, where in each one we modified the grounding parameters according to certain aspects, such as: the workload of RTGs (e.g., increase/decrease the influence of RTG related variables), the travelling distance of TTs (e.g., increase/decrease the value of penalties related to terminal truck driving distance), specific yard settings (e.g., impossible to stack containers on top of containers that have a different type or which are planned to be moved). For each scenario, we carried out experiments and investigated which aspects are the most relevant. We concluded that with proper settings of the parameters the controlled random stacking strategy indeed can be a good choice as it improves both the quay crane and RTG productivity.

We achieved significant improvements (5-10% increase) of quay crane productivity applying the SPARCS expert decking functionality (see Figure 4). We realized this by changing the grounding parameters (for instance allocation filters in combination with equipment control parameters, the weight factor of travel distance, etc.). This optimization TOS tuning approach has been applied in more than 30 terminals worldwide.

5.2 Plan Validation

After business analysts identified the best TOS settings using the emulation approach those settings can be applied in the TOS available in live operation. From that moment and before a vessel arrives to a terminal the terminal planner can create the shift plans (vessel plans, yard plans) and the TOS can take care of the proper scheduling and dispatching of the moves using the new settings. A shift planning contains the handling (loading and discharging) sequence of the containers, the planned location of the containers in yard and the utilization of the transportation equipment. In order to achieve a high productivity and meet contractual berthing windows at the lowest costs, it is crucial to find the optimal amount of equipment deployed. Not only the amount deployed, but also where they are deployed, and how the pick and drop containers in the yard is key to an efficient operation. In order to create an appropriate shift plan the planner has to properly investigate all these aspects and make a good decision in a limited time frame. Currently there is no possibility to verify and validate the quality of this plan; everything depends on the expertise of the planner. This lack of validation inspired us to introduce a new simulation approach called plan validation (Figure 5) that aims to support the planners’ decision making to provide a verified and validated shift plan within a limited time frame (Boer and Saanen 2014b).


Figure 5: Real terminal operation vs. emulation vs. plan validation (full simulation).

The simulation of the virtual terminal is capable of running up to 30 times faster than real-time depending on the size and complexity of the terminal. Although we can achieve a relatively high speed, it cannot always run faster than real time because of the concrete TOS with which it interacts. In order to run faster than real time there is a need for time synchronization between the simulated virtual terminal and the real TOS. Although there are different mechanisms for time synchronization (Boer 2005), not all TOS systems provide this functionality. We achieved time synchronization with SPARCS (Boer and Saanen 2008). However, running faster than two to three times real time causes unexpected behavior of the TOS due to the heavy calculations needed for planning and scheduling, as well as fixed time loops in the code. For this approach the execution speed is crucial since the planning has to be simulated in a short time period because the planner has to make a decision within a limited time frame. This requirement implies that the TOS system should also be capable of running faster than two or three times real time. Based on our experience, we found that with an actual TOS this is not yet possible, but this can be possible if the TOS is also simulated. Therefore a full simulation setting is proposed (see Figure 5, scenario c) where both the container terminal and the TOS are simulated. By this simulation setting we were able to use CONTROLS for plan validation (Boer and Saanen 2014b). The challenge that still remained is the simulation of the TOS, in a valid way, and still be able to run together with the virtual terminals much faster than real time.

On a very high level a TOS has three ingredients: the data, the business logic and the communication. The data module contains the data repositories (e.g., databases, setting and configuration files) to store all data used for planning and scheduling. The business logic module contains the implementation of algorithms used for planning and scheduling. The communication module comprises the implementation of communication protocols towards real equipment, as well as to third party systems. In order to create a simulation model of a TOS we have to consider these three ingredients. Boer and Saanen (2014b) presented in more detail these ingredients of a TOS system that needs to be simulated and a case study in which the same container terminal model was considered with a real TOS (emulation setting) and a simulated TOS (plan validation). We succeeded to achieve the desired speed, but still there remained a question concerning the presentation of the findings in an understandable way to the planner to lead to an improved plan. In other to achieve this we aimed to facilitate the presentation and learning by two means: by using detailed statistics and visualization. The statistics enable a planner to find performance hiccups and define solutions to overcome them. Detailed visualization of the operation includes all the logical information about the equipment and container flow (see Figure 6).


Figure 6: Learning cycle to continuously improve the plan using Plan Validation.

The above depicted learning cycle using plan validation has been tested by consecutive action taken by vessel planners which lead to an increase in the performance (see Figure 7). Moreover, the planners were able to carry through the improvements within the limited time before the plan had to be executed (Magnúsdóttir 2014).


Figure 7


The plan validation is an excellent optimization approach that takes places in live operation by providing live operational support during the shift plan creation process. After the shift plan is verified and validated, and ready to be performed in real life operation, the plan validation becomes irrelevant until the quality of a new shift plan has to be checked again. Although the plan validation plays a very important role in improving the quality of the shift plan, during operation certain incidents could still happen. Examples are equipment breakdown, late arriving containers, or even unexpected TOS behavior, which can have an impact on the originally expected outcome of the shift plan. In order to avoid this risk we propose a solution that is able to continuously provide support in live operation.

The approach that we propose is using simulation models that take the latest data from real operation and run experiments faster than reality, and thus they can provide continuous feedback to the user regarding the expected outcome. All this is realized by a feedback cycle: for the input the simulation uses real data, then it provides simulation output to the user, based on that the user adjusts the real data, which again is the input for the simulation (Figure 8). Using this feedback cycle approach the user gets a kind of telescope to look into the future providing continuous support for decision making based on recent simulation output.


Figure 8: Feedback cycle for live operation support using simulation.

After the user finishes with plan validation one has an initial dataset that is verified and validated, and ready for real life operation. During the real life operation the TOS is continuously changing this dataset. The new approach that we propose should be capable to get a copy of the latest dataset that will be fed in the simulation model, which is the same as has been used for plan validation, and start one or more experiments. If certain unexpected incidents happen in simulation, such as equipment being blocked or waiting too long, productivity of certain equipment drops below a threshold or there is too heavy traffic in certain quay area, the user is informed and one can take preventive actions in real life operation. Note that none of the predictions coming from simulation are guaranteed to occur in real life, but instead they are warnings to keep the user alert and support one in proper decision making.
This would be an innovative approach with a great value that does not exist yet in the market and it could be an excellent product supporting the optimization stage of the lifecycle of the terminal.


In this article we guided the reader through the four stages of the lifecycle of a container terminal: design, implementation, operation and optimization. For each stage we presented the potential of simulation and emulation approaches that support to accomplish the success of those stages. By looking back twenty years it is great to see how the simulation and emulation products evolved based on market needs, vision and innovation (Boer and Saanen 2016). Especially the rapid technological changes, such as automation, big data, SaaS, augmented reality, mobile devices, data mining, and machine learning have an impact in changing the traditional container handling. All these new technologies are going to be part in some extent either in equipment or in the software that controls them. In order to remain market leader in the segment we have to accommodate these changes and our products.


We would like to thank our colleagues for their support in developing and testing CONTROLS and plan validation components.


Agerschou H., I. Dand, T. Sorensen, and T. Ernst. 2004. Planning and Design of Ports and Maritime Terminals. 2nd ed. London: Thomas Telford Ltd.
Azab A. E. and A. B. Eltawil. 2016. “A Simulation Based Study of the Effect of Truck Arrival Patterns on Truck Turn Time in Container Terminals”. In Proceedings of the 30th European Conference on Modelling and Simulation, edited by T. Claus, F. Herrmann, M. Manitz, and O. Rose, 80-66.
Bakken B., J. Gould, and D. Kim 1992. “Experimentation in Learning Organizations: A Management Flight Simulator Approach”. European Journal of Operational Research 59: 167-182.
Bish E.K., F.Y. Chen, Y.T. Leong, B.L. Nelson, J.W.C. Ng, and D. Simchi-Levi. 2005. “Dispatching Vehicles in a Mega Container Terminal”. OR Spectrum 27(4): 491–506.
Boer C. A. 2005. Distributed Simulation in Industry. ERIM Ph.D. Series Research in Management: Rotterdam, The Netherlands. Available via [accessed April 4 2017].
Boer C.A. and Y. Saanen. 2008. “CONTROLS: Emulation to Improve the Performance of Container Terminals”. In Proceedings of the 2008 Winter Simulation Conference, edited by S. J. Mason, R. R. Hill, L. Monch, O. Rose, T. Jefferson, and J. W. Fowler, 1094-1102. Piscataway, New Jersey: Institute of Electrical and Electronics Engineers, Inc.
Boer C.A. and Y.A. Saanen. 2012a. “Improving Container Terminal Efficiency through Emulation”. Journal of Simulation 6(4): 267-278.
Boer C.A. and Y.A. Saanen. 2012b. “Testing, Tuning and Training Terminal Operating Systems. A Modern Approach”. In International Conference on Logistics and Maritime Systems (LOGMS), edited by H.O Gunther, K.H. Kim and H. Kopfer, 25-35, Bremen, Germany.
Boer C.A., Y. Saanen, M. Bruggeling, and N. Koumaniotis. 2014a. “Near-to-live Training for Container Terminal Planners: Bridging the Gap between Training and Live Operation”. In Proceedings of the 2014 International Conference on Logistics and Maritime Systems (LOGMS), edited by R. Dekker and R. de Koster, August 27-29, Rotterdam, The Netherlands.
Boer C.A. and Saanen Y. 2014b. “Plan Validation for Container Terminals”. In Proceedings of the 2014 Winter Simulation Conference, edited by A. Tolk, S.Y. Diallo, I.O. Ryzhov, L. Yilmaz, S. Buckley and J.A. Miller, 1783-1794. Piscataway, New Jersey: Institute of Electrical and Electronics Engineers, Inc.
Boer C.A. and Saanen Y. 2016. “The Journey of CONTROLS”. Port Technology International, 30(2), 30-32.
Chen T. 1999. “Yard Operations in the Container Terminal—A Study in the ‘Unproductive Moves”. Maritime Policy and Management 26(1): 27–38.
Dekker R, P. Voogd, and E. van Asperen. 2006. “Advanced Methods for Container Stacking”. OR Spectrum 28(4): 563–586.
Kim K.H. and H.B. Kim. 1999. “Segregating Space Allocation Models for Container Inventories in Port Container Terminals”. International Journal of Production Economics 59(1-3): 415–423.
Kim K.H, S.J. Wang, Y.M. Park, C.H. Yang, and J.W. Bae. 2002. “A Simulation Study on Operation Rules for Automated Container Yards”. In Proceedings of the 7th Annual International Conference on Industrial Engineering, 250-253, Busan, Korea.  
Kim K.H. and K.T. Park. 2003. “A Note on a Dynamic Space Allocation Method for Outbound Containers”. European Journal of Operations Research 148(1): 92–101.
Kim K.H. and  K.C. Moon. 2003. “Berth Scheduling by Simulated Annealing”. Journal of Transportation Research Part B, 37(6), 541-560.
Lee Y. and N. Hsu. 2007. “An Optimization Model for the Container Pre-marshalling Problem”. Computers & Operations Research 34(11): 3295–3313.
Magnúsdóttir J.G. 2014. “Exploring Container Terminal Planning: Effects of Vessel Plan Forecasting and Event-based Visualization on Planning and Situation Awareness”. Master Thesis, Delft, The Netherlands, 2014.
Nam K.C., K.S. Kwak, and M.S. Yu. 2002. “Simulation Study of Container Terminal Performance”. Journal of Waterway, Port, Coastal and Ocean Engineering 128(3): 126–132.
Read C.W. and B.H. Kleiner. 1996. “Which Training Methods are Effective?”. Management Development Review 9(2): 24-29.
Saanen Y. 2010. TOS Market Overview. Internal report, TBA B.V., Delft, The Netherlands.
Schütt H. 2011. “Simulation Technology in Planning, Implementation and Operation of Container Terminals”. In Handbook of Terminal Planning, edited by J.W. Böse, 103-116, Springer: New York.
Sheikholeslami A., G. Ilati, and E. Hassannayebi. 2013. “A Simulation Model for the Problem in Integrated Berth Allocation and Quay Crane Assignment”. Journal of Basic and Applied Scientific Research 3(8): 343-354.
Stahlbock R. and S. Voss. 2008. “Operations Research at Container Terminals—A Literature Update.” OR Spectrum 30(1): 1–52.
Van Ham J.C. and J.C. Rijsenbrij. 2012. Development of Containerization. Amsterdam: IOS Press.
Vis I.F.A. and I. Harika. 2004. “Comparison of Vehicle Types at an Automated Container Terminal”. OR Spectrum 26: 117–143.
Waller D., Hunt, E., and Knapp, D. 1998. “The Transfer of Spatial Knowledge in Virtual Environment Training”. Presence Teleoperators and Virtual Environments 7(2): 129–143.
Zeng Q. and Z. Yang. 2009. “Integrating Simulation and Optimization to Schedule Loading Operations in Container Terminals”. Computers and Operations Research 36: 1935–1944.
Zyda, M. 2005. “From Visual Simulation to Virtual Reality to Games”. Computer 38(9): 25-32.