Using emulation to improve the performance of your TOS

Container terminals are struggling with ever increasing throughput, and are therefore searching for solutions to increase throughput capacity without expanding their physical footprint. At the same time, they target to increase their productivity to be able to handle bigger ships with larger call sizes in the same time windows. Terminal operating systems (TOS) are playing a major role in today’s terminal operations, as they support planning, scheduling and equipment control. More and more tasks are being performed by the TOS – stowage planning, grounding decisions, equipment dispatching – and therefore, they need to be well tuned to the operation, which remains a terminal specific characteristic. In this paper a method is presented to test and tweak the TOS, and train operators on a virtual terminal. It has been successfully applied on the software replacement project at ECT, for a new TOS development in Hong Kong, for a new terminal in Norfolk, UK, and is running in pilot form at APM’s terminal in Aarhus, Denmark.

Container terminal emulation (‘CONTROLS’)

Introduction

This paper concerns the concept behind the emulation tool ‘CONTROLS’ (which stands for CONtainer TeRminal Optimised Logistics Simulation). AS TOSs become of increasing importance in delivering high performance to the customer and still operate efficiently, it is therefore important to have a high quality TOS. Therefore, TBA has developed its emulation tool ‘CONTROLS’ to allow for off-line experimentation with the TOS, e.g. SPARCS from Navis, SPACE/Trafik from Cosmos, or CATOS from TSB, with which insight can be created and with which parameters can be fine-tuned during software development, commissioning, and during training and operations. The tool itself, together with the user of the tool, form the success factors for the application. To support the terminal in the use of the emulation tool a regular ‘fitness check’ is included during which the terminal performance is reviewed and the parameters of the TOS are optimised to the specifics of the terminal and its changing conditions. The emulation tool can be accompanied by a scenario creation tool, named SCENEMA (Scenario Manager), which can create all kinds of realistic operational scenarios, based on container flow input. It also acts as the ‘host’ system. This scenario can be fed into the TOS as if it was receiving regular information via EDI.

The structure of this paper is as follows. First, the objectives of an emulation approach are described. Then we describe the most imminent features of the tool. Finally, the way to use the tool during the development of the TOS and afterwards is described.

Objectives

The following objectives are strived for by developing and applying the container terminal emulation (‘CONTROLS’):

• Reduction of the risk of (complex) software development, by providing an early test environment that represents the terminal in an as realistic as possible manner.
• Assurance of terminal performance, expressed in various performance indicators, such as quay crane (QC) productivity, equipment utilisation and productivity, and truck turn around time.
• Improvement of the insight into the TOS by observing shortand long-term effects of certain configurations of the TOS parameters.
• Training of TOS users in a virtual environment. Without the risk of productivity loss, the emulation tool can be used to perform realistic training for operators.
• Visualisation of operations to increase the understanding of the operation.

The essence of the emulation is to provide a tool that acts as a very realistic virtual terminal, i.e. a tool that provides a valid representation of the physical processes at a terminal (equipment behaviour, driver behaviour, and operational scenarios – gate arrivals, train arrivals, vessel arrivals), which can be linked to the TOS in such a way that the TOS treats the tool as the ‘real world’ (this means via the already present interface between TOS and equipment), and which can be used to run operational scenarios, either as occurred in the past, or as configured by the user.

Figure 1: Basic structure of the TOS and emulation tool.

By examining the performance of the terminal controlled by TOS under various emulated conditions, an assessment can be made of the system (TOS but also the operational processes) and its actual configuration. This assessment will be made by actually running an operation as it would normally take place at a terminal as well, however without moving containers in a physical way. At this stage, the TOS is communicating with virtual drivers, clerks and other peripheral systems, rather than real ones. The communication protocol is identical to the communication in real life (Figure 1). The emulation model includes a representation of all relevant processes at the terminal, i.e. the layout (e.g. yard, rail terminal and quay cranes), a model of the equipment (kinematics, driver behaviour, routing, disturbances, and availability), and performance measurement functionalities.

All performance relevant interactions that take place between the equipment at the terminal (including gate and rail terminal) have to be defined and supported by the interface between the TOS and the emulation tool.

Key to successful application of CONTROLS

As with any modelling exercise, it is key that the model covers all relevant aspects of the operation in a valid way. This means yard congestion, queuing behaviour, delays due to problems with twistlock engagement, and so forth. During the configuration of the emulation for a specific terminal, validation takes place, aiming at creating a valid model. The validation process requires interaction between the terminal’s operational experts and the modellers. Furthermore, it may require measurements in the operation, or analysis of measurements captured by the TOS.

The connection between TOS and emulation

The TOS and the emulation communicate via an interface. This interface is defined together with the terminal operator and/or the TOS supplier. The interface is identical to the interface that is used during real operations, so that the TOS does not need to be adjusted, which is a core requirement to the emulation approach (because changes may cause deviations from what would happen during real operations!).

Furthermore, all possible interactions between the TOS and the controlled equipment are represented as far as they affect performance. These interactions basically follow a pattern of order going from the TOS to the equipment and ready notifications or position updates sent back to the TOS. In case of disturbances, these interactions can be less obvious; this, therefore, requires in depth investigation.

Lastly, as the emulation also creates the external arrivals (for instance gate traffic) that have to be fed into the TOS, the messages for these processes have to be defined. Typically, this is a host system functionality. These are additional to the operational messages. The same is true for the time management, as the emulation model and the TOS will (preferably) run faster than real time. However, in that case, both programmes have to be synchronised on a continuous basis. Without time synchronisation, the emulation tool can run in real time mode only.

Features of the emulation tool

The emulation tool comprises all relevant components at the terminal, such as QC, rail cranes (RTGs or RMGs, but may also be reach stackers), transportation equipment, such as straddle (shuttle) carriers (SC) or Terminal Trucks (TT), or AGVs, yard handling equipment (RMGs, RTGs). It also comprises all relevant locations in the terminal, such as the gate and the truck transfer zones, road trucks, the yard plus special stacks, special areas such as the MT stack, reefer plugs, and a place for OOG containers. All equipment actually has a physical location, and occupies space in time. The dynamic movements of equipment are based on equipment kinematics and on the possible interaction between equipment at the terminal (for instance two SCs that want to access the same row in the stack, will lead to one SC waiting). The truck appointments may be included as well. Each terminal component has been modelled in such a way that all specified scenarios can be tested in an accurate way.

Typical features present in the emulation tool:

• The production run may be started over and over with the same or different parameter settings (configured in the TOS). The TOS may support this by capture and replay functionality.
• After a run, the output is available in the emulation tool as well as in a text format. Results from multiple production runs are uniquely recognisable afterwards.
• The layout (roads, stacks, apron, gate, etc) can be specified in the emulation tool. In the case something changes, the user can change it in the tool accordingly. Preferably, the input for these configuration parameters is used from the TOS. When the configuration files (.ini) used by the TOS are disclosed, ‘CONTROLS’ will use these, so that updates in the TOS are automatically reflected in the emulation tool.
• The specification of the control parameters, specifying the yard operating strategy, and equipment settings, equipment specification (height, speed), pooling rules, plus the period of coverage are done in the TOS.
• The speed of the tool depends on the length of the run. The emulation is capable of running 5 – 30 times faster than real time (of course, this requires the TOS to be able to run faster than real time as well; it also requires time synchronisation between the TOS and emulation tool in some TOS systems).
• During the run (and at the end of the run), the user can create some visual representations of the yard (views). For instance: visualisation of the locations of containers with a specific property (voyage number, size, weight class, IMO class, type).
• The emulation tool can run in ‘animation’ mode (Figures 2 and 3). Then, the user can follow the execution of specific moves (in a true-to-scale 2D animation), and tune the parameters on-line. All equipment will be clickable and represent its main properties at that point in time. The position of the equipment will be updated at least every five seconds (real time).

Figure 2: Example of emulation running in 2D mode.

Performance indicators for assessing the performance of the TOS

Typically, a TOS does not generate detailed statistics with regard to the equipment. However, the emulation tool will generate detailed statistics that go beyond QC productivity and truck turn around time. These statistics will enable much more detailed analysis of the reasons for a certain productivity – for instance longer travel distances.

Figure 3: Example of emulation running in 3D mode.

‘CONTROLS’ generates output of a single experiment – an experiment is a combination of the setting of the control parameters, the message log of a certain period, and the setting of the equipment – in the form of text files that can be loaded into an MS Access database. Via an on-line link to MS Excel, the data can be analysed. This will be prepared in such a way that the user can easily access all results.

The following data are registered (however this list is not exhaustive):

• Registered quay crane moves per hour
• Quay crane idle time
• Service time of road trucks
• Productivity of straddle carriers (productive and non productive moves)
• Status of stacking equipment (idle, working, waiting for other equipment)
• Detailed equipment behaviour (average distance per move, average speed, etc.)
• Average filling rate of the yard
• Average filling rate of ground slots

Furthermore, the actual state of the yard is available as a table and by means of visual representations (so called yard views) that show:

• Stacking height of each pile
• Location of containers that have a certain property (voyage number, PoD, weight class. This will depend on the available information given by the TOS. In case the scenario manager is used, this information is available.)

The latter information can be used for qualitative analysis of the state of the yard.

Using the emulation tool at the terminal

In order to evaluate the parameter settings (e.g. allocation ranges), algorithms, and allocation of resources to points of work (vessel, rail, gate, yard), operational scenarios have to be defined. These scenarios are either real scenarios, meaning that it’s a replay of a past existing operation, or they are representative created scenarios, for instance for peak circumstances (e.g. full yard, 20% volume growth, or a full berth after a storm) or breakdown situations.

Each scenario execution will consist of an initialisation step during which the user (or the scenario manager) configures the initial yard (in principle loaded from the TOS), and plans the operation. These settings can then be stored, so that this experiment can be repeated without initialising again. After the initial yard is loaded, the experiment run will be executed. The experiment run will cover for instance eight or 24 hours of operation – the ability to run longer experiments depends on the TOS, as the emulation tool is capable of running as long as the TOS controls the operation. Attended runs may last as long as the user wants, as the emulation behaves as the real world would behave. Unattended runs, however, depend on the capability of the TOS to run without an operator controlling it.

Figure 4: Screenshot from an operation visualised in the emulation, showing actual positions of straddle carrier and road trucks, parked at the truck interchange.

The experiment runs may be started over and over for various scenarios. The output of the experiment runs will be available in the simulation environment as well as in a standard Microsoft database (MS Access) format. Results from multiple experiment runs will be uniquely recognisable afterwards.

The TOS performance can be assessed by comparing the performance of various simulated operations (e.g. QC productivity, truck and rail service times, number of shuffle moves etc.).

The experiment has to be run without human interference, and preferably run faster than real time, dependent on the capabilities of the TOS. It may be that some experiments require human interference. This will be expressed in the operational scenarios.

In order to create scenarios for future operations, we have developed an extension module, called the scenario manager (‘SCENEMA’ – see also Figure 1). The scenario manager can be used to create scenarios for future throughputs, or changed container flow parameters (more rail, more transshipment, etc). The scenario manager converts the user input to consistent container flows, including vessel arrivals, gate arrivals, train arrivals, and containers remaining in the yard for a certain dwell time. They will be formatted such that the TOS can directly use them (BAPLIE and Movins formats).

Experiences with emulation

The experiences with emulation are based on seven projects so far, of which five in the container terminal industry, and two are outside. One of these is a automated baggage handling system, and one a large concrete factory. Both are 24/7 operations where, like the container terminal industry, the reliance on operational software is very high, as are the costs of stoppage.

In five of these projects, the emulation was used to support the introduction of new software, and therefore it was not only used for optimisation during the operation. In this phase, the emulation proved to be a very valuable tool, enabling the development team to dissolve about 95% of the errors that typically are found after going live.

Furthermore, the visualisation accompanying the emulation provided useful insight during the process, also for non software experts. Where usually the ‘customers’ of the system have to wait until the system goes live, they were now able to operate a virtual operation long before the system went into real operation. This gave the possibility to train future operators, but also allowed for early feedback from the future users.

Finally, it enabled the team to stay focused on performance of the terminal, or system, Where typically, the focus shifts from performance to ‘getting things to work’, a continued focus could be kept on performance (think of QC productivity, equipment utilisation, stacking efficiency, truck service, etc.) because the tool environment allowed for this.

Robert de Belder, Manager Terminal Systems, DP World, shared the following experience regarding the use of CONTROLS: “Stress testing with CONTROLS was part of the evaluation of our new TOS. Thanks to the stress testing we where able to debug our TOS system on the one hand and to evaluate the response times of our application on the other hand. We expect to use CONTROLS in the nearby future to evaluate the logistic performance of our TOS.”

In two cases, we applied the emulation to improve productivity in a live environment, replaying past operations, and evaluating different parameter settings. In one case, we aimed at improving truck turn around time by improving straddle carrier dispatching. It appeared from the experiments that the truck turn around time in the peak – by just changing the dispatching algorithm and the decision factors – could be reduced by more than 30% on average, and the peaks by even 50%. At a minimal investment – it implied some changes to the TOS – the service to trucks could Figure 4. Screenshot from an operation visualised in the emulation, showing actual positions of straddle carrier and road trucks, parked at the truck interchange. PORT TECHNOLOGY INTERNATIONAL 81 CONTAINER HANDLING be improved drastically, or in other words, the number of straddle carriers required to handle a certain truck peak could be reduced, saving labour and equipment costs.

The second case aiming at improving productivity, showed that changes to grounding parameters (allocation filters for instance) in combination with equipment control parameters (for instance the weight factor of travel distance) can lead to significant improvements of the QC productivity (5-10% increase).

Conclusions

As software for terminal operations gets more advanced and as terminals get more reliant on their TOS, the importance of sophisticated test, tuning and tweaking tools gets more vivid. Simply allowing software vendors to deliver new releases without running realistic scenarios, installing software without detailed performance testing during the commissioning, and developing software without the use of tools that make the performance metrics explicit, is something that is not acceptable in a time where we rely on correct information.

Furthermore, these type of tools also provide terminals with an opportunity to increase throughput without adding equipment or yard space, simply by doing more with less. As volumes are increasing, costs are rising, and space is scarce, this is the only viable solution.

This article has been published in Port Technology International in August 2011.