A design approach for robotized maritime container terminals

Although container volume growth is stagnating, the terminal industry is still being challenged with change, and resulting pressure. Larger vessels resulting in higher performance demands and more peaky operational patterns, new alliances causing commercial uncertainty about volume and competition, and changing cargo patterns due to changes in manufacturing and consumption patterns require terminals to deal with changing modal splits, dwell times and operating patterns. The volume of containers handled through container terminals world-wide is about to exceed 700 million TEU, and ship sizes are about to touch 20,000 TEU, with exchange sizes exceeding 10,000 containers in some instances.

At the same time, there is an increasing emphasis on cost, environmental control and safety, which forces terminal operators to search for innovative solutions. Solutions that require less space and cost less per handled container. Here robotization and automation come into play, as they allow reducing labour by a significant amount, and allow decreasing the space usage of a terminal by percentages up to 50%.

However, this comes at a cost: the terminals that have implemented large-scale robotization and automation, have suffered from lower productivity than aimed for, as well as significant start-up problems. Many of these problems are on behalf of the terminal control software, as case research has shown us. In detail, we analysed the establishment of the ECT-DSL terminal in Rotterdam, which among others showed that:

• The occurrence rate of system failures had been underestimated, which led to inefficient recovery procedures.
• The time pressure in the project led to a focus on getting the system to run, instead of realising the functional specifications. This caused much of the specified functionality not to be implemented.
• The interfaces between various control system components were a result of a negotiation process between various design groups, instead of a rational architecture design.
• The terminal was used in a different way than planned by the terminal operator.
• The terminal was not designed from a holistic point of view, which led to sub-optimisation and components that did not work properly together.

Besides, literature and other recent case studies taught us that:

• A large gap exists between functional design of automated terminals and the technical design and software realisation.
• There is a lack of interaction between the design of robotized equipment and its control software, leading to sub-optimisation of each component. Even the equipment design is fragmented, which leads to different solutions for similar problems.
• Too little attention is paid to the interaction between the operator of the automated system and the system.
• A gap exists between aggregate, strategic targets, like throughput volumes and vessel service times, and operational, day-to-day, hour-to-hour operational targets, such as quay crane productivity and truck service times.
• There are no tools available to provide insight into the operation of automated equipment and/or automated terminals, including solutions for process control systems.
• A common-off-the-shelve, integrated process control system for automated terminals does not exist (yet), which increases the risk of realising an automated terminal.
• There is a lack of integration between cost analysis tools and performance analysis tools.
• Current design approaches do not address the activities after commissioning, apart from monitoring and post-evaluation.

Given this context, the question is how risks associated with the realization of automated terminals can be mitigated, and how the development and implementation process should be approached to maximize the chance of success within the shortest amount of time.

Developing a robust development and implementation approach

In the development of a new terminal, the following four main activities can be identified:

• Functional design
• Technical design
• Implementation
• Commissioning and operations.

In each activity we propose applying a simulation approach, relying heavily on the use of models. The models would be used throughout the entire process to support decisions on For this purpose we developed a model suite that may support the entire design-engineering process until the terminal has been commissioned. Even during operations, the model suite may be used for fine-tuning, or problem solving when the operational conditions change.

The basis of the approach consists of a framework of guidelines, which are the following:

• Using an object-oriented world-view.
• Applying a holistic, layered view on the terminal processes.
• Mirroring the real system’s architecture into the model’s architecture.
• Taking uncertainty and process variability into account.
• Using the operational processes as a leitmotiv for the design.
• Integrating the design of manual operations and automated operations.
• Integrating hardware and software design.
• Defining comprehensive and measurable objectives to assess the design.
• Basing the decisions within the design process on performance measurements.
• Continuing monitoring and measuring after commissioning.

These guidelines have been elaborated into a detailed approach, including a stepwise, iterative approach to design a terminal, supported by a model suite that can be applied during the various activities, providing a way to manage the process. The design process consists of the following main steps:

• Defining the function of the terminal, the throughput capacity, and the services the terminal should provide.
• Designing the terminal’s key components, i.e. quay wall length, terminal geometry, layout of the stack, handling system, and logistical control concept.
• Designing the equipment and the process control system.

After the functional design of the terminal’s components, they can be further detailed into the technical design (and specification). Subsequently, they are built (hardware) and implemented (software).

After the implementation, commissioning takes place to verify whether every component works as it should. If this is successful, operations may start, during which a period of fine-tuning will take place.

The entire process, here described in a nutshell, is completely performed following a simulation approach. This means that in all activities the use of models to evaluate and assess the quality in terms of the objectives of the terminal – at various levels of detail.

During the functional design, the typical questions to be answered are to determine the right quay length, the required number of quay cranes, the required storage capacity, and the rail and gate capacity. Subsequently, the handling system is selected by assessing various alternatives, and the logistical control concept is being developed to match with the handling system.

During the technical design, the process control system (or terminal operating system – TOS) is designed at a more detailed level, prototyping control algorithms, specifying the parameters, and configuring the terminal. As for most robotized terminals, there is no common-off-the-shelf software yet; much of it has to be designed and developed.

During the realisation and implementation work, a simulation approach is used to provide a test-environment for components, i.e. equipment and software components. Because during this process, components become available piece by piece, the models may provide the remainder. This can be the rest of the TOS, or the real-life input from operators, or the equipment, or the representation of arrivals of vessels and/or trucks at the terminal. The model system provides an environment, manageable by the designers to create realistic circumstances to try out and test, especially from a performance point of view.

During commissioning and operations, a simulation approach may be used to find bottlenecks, to perform quick analyses in case something appears not to work as planned. It may also fulfil a role as yardstick for the production software, as the software should provide the same performance level as the model system under the same conditions.

Throughout this process (see below diagram), a suite of models is used that has an architecture similar to the real system’s architecture. This makes it possible to exchange model components with real components, and to link various modes of implementation to each other without needing to change any of them.

Figure 1: Continued use of simulation models throughout the design-engineering process

Evaluation

The approach has been applied in various cases. In the software re-design and replacement project at ECT, the approach so-far has been applied to support the functional design, technical design, and software implementation. The research can be classified as action research as we have been involved in the process ourselves. However, we have found the approach well applicable in terms of finding the solutions that contribute to the terminal’s objectives, and in terms of finding the problems in the software that may hamper performance during the operation. Besides, the feedback from the functional design teams and the software development teams has been very positive so-far.

The second case, in which the approach has been applied, is the design of a high density stacking crane, an overhead bridge crane. Here, the simulation approach has supported an integrated design of all components of the stacking crane. The crane has been modelled – both on behalf of equipment kinematics, as well as control software rules – at a very detailed level. The result was that many components could be optimized from a holistic point of view, i.e. aiming at the crane’s performance as part of an entire terminal system. This approach has saved a significant amount of money and has led to a more productive crane.

Finally, the approach has been discussed, via a remote expert survey, with various experts on behalf of container terminal and/or the use of simulation. Most of the concepts that underpin the approach are considered a contribution to the quality of the design-engineering process.

As a result the research has led to the following conclusions with regard to the research questions:

• In order to create an effective simulation approach, the models need to represent the Terminal Operating System (TOS) as well as the Equipment Control System (ECS) in particular, because the functionality of the TOS and ECS are a critical success factor. Representing the TOS and ECS of an automated terminal means – as compared to the representation of the TOS in conventional terminals (in conventional terminals there is no ECS, as the drivers take care of this role) – the modelling of the software that controls the automated equipment, i.e. routing, collision avoidance, deadlock avoidance, et cetera. On top of the representation of the functionality of the TOS, it is also important to represent the technical behaviour of the TOS, i.e. response times, asynchronous behaviour, and limited possibilities to optimize decisions.
• In order to reduce the risk of automation in terms of performance loss in the operation, the approach we propose focuses on the achievement of the performance goals throughout the process, i.e. including the development and realisation processes. Secondly, our approach proposes to test software in an early stage by linking it to a realistic test environment containing the specific dynamic elements that make an operation at a container terminal so complicated. As such, complex interaction can be found and dealt with as early as possible. Thirdly, the simulation environment allows for testing the system including the interaction with an operator.
• In order to ensure that the insight provided by the simulation approach during the process is correct, the models need to be valid. In cases where a system of a novel nature is built, especially on behalf of the TOS, the simulation can be considered a prototype of the TOS. However, during the implementation, one has to be sure that the software is built after the prototype, either by working closely together with the software supplier, or by developing a detailed software specification combined with performance requirements based on the prototype and the achieved performance levels in the design phase.
• The design approach should be independent of the technology of the solutions that are designed, compared, and assessed, to assure a comparison in the same formats and driven by the same set of variables. The set of guidelines we propose appears valid for any container terminal design, as most variables are similar to any container terminal design project. On top of the model suite we developed as part of this research, it may require additional model development in case of a completely new container terminal design. Currently most of the common handling systems at container terminals have been covered, but as technology progresses, new systems may arise. However, the basic structure of the model environment is not likely to change, just as the function of a container terminal is not likely to change. Therefore, we may presume that the model environment will be able to depict future container terminal systems as well.

With regard to applying a simulation approach throughout the entire design-engineering process, the following concluding observations can be made:

• First, we experienced that simulation is still associated to a large extent with indicative sayings rather than accurate assessments, which would make them principally unsuited for precise tasks such as prototyping and/or testing of software. However, we argue this not to be true for the model systems that we developed during our research, which contain a high level of detail to represent operations at a container terminal with sufficient realism to provide the possibility to prototype software components. This is an approach that is – based literature review – not often followed (see e.g. Wysk, 2001), which also contributes to the fact that a simulation approach is not commonly used for purposes and/or decisions to be taken further in the design process.
• Secondly, a simulation approach requires additional time, especially in the beginning of the project. This additional time is invested with the promise of a return on investment by means of better solutions that reduce the risk of the investment. However, the time needed, is not always available. Especially during the development of software, the time it takes to provide the feedback, may be longer than feasible, which leads to decisions made on perceptions rather than scientific analysis.
• Thirdly, the professional environment within container terminals can be characterised as primarily focussed on operations. Although we observe a trend of an increasing level of education within the managerial staff of container terminals, many positions are still occupied by people that come from operations. These people are less trained in using scientific approaches when solving problems, finding bottlenecks and taking decisions: they rather depend on observations in the operations. Although this leads to good results in many cases, the risk of taking the wrong solution, or a solution that is less effective than expected, is relatively large. Moreover, when it concerns solutions of a novel nature, as is the case in robotized container terminals, experience from the past is not always the best advisor.

In the two test cases – as well as many other projects we carried out over the last years -, we have gathered concrete experiences with most of the guidelines as proposed in our design approach:

• The approach proved applicable to new developments, terminal extensions, and terminal improvement programmes. The scope and the set of feasible solutions are determined by the type of project, but in terms of the methodology, we conclude that a simulation approach from start to finish appears to be viable. Even in projects where product-based TOS software is being implemented, many questions have to be answered, and many uncertainties concerning performance and technical robustness remain to be answered during the design and implementation process.
• A crucial contribution of a simulation approach in the context of an entire design-engineering project appears to be the see-throughs that have to be made, when creating the functional design. This process of elaboration on specific solutions – these may be equipment specifications, but also software components or algorithms – provides not only feedback to the functional design; it also provides an outlook to the technical design in terms of a prototype. Especially when the prototype (within the simulation environment) is built in accordance with the architecture of the real system – both hardware and software -, it can provide useful input to the technical specification and the implementation.
• Said prototyping functionality by means of simulation models is of high added value because most terminals are similar, which allows for re-use of components in the model suite. Here, a building block based approach appears to be valuable, as it allows changing components internally without affecting its interface.
• Our initial choice to apply a building block based architecture of our model suite has proven to be very valuable to enable the support throughout the design-engineering process. It clearly reduces development time, and therefore reduces the response time whenever a question pops up, especially during the software development. It also allows for a stable architecture of the model system during the process, where in the beginning a more aggregate behaviour is modelled, which is more detailed in later stages. However, the interface of each component remains unchanged. For particular purposes, it may even be the case that some components are applied in a detailed implementation, whereas others are present in a more aggregated mode. This significantly reduces development time, and speeds up the experimentation.
• The use of a simulation approach fosters continuous attention for performance issues. As every project is under time pressure, it is common that during implementation/realisation the focus of the people involved – including the managerial level – moves from the functional requirements to the basic requirement of getting the terminal running. The attention for performance issues is then deliberately delayed to a later point in time. However, this may cause changing things at this later point in time to be impossible, because of decisions made to bring the system to work. When a model system is available allowing the people involved to assess whether these decisions would affect performance, different solutions can be sought and decisions can be carried out knowing the consequences. Of course, it is essential to make sure that this model system is valid and trustworthy for these kinds of assessments.
• In addition to the previous point, the simulation approach can not only be used to keep the focus on performance (parallel to getting the system to work), but it also can be used to test the system under all kinds of operational circumstances. This means that the likelihood of huge performance losses in the case of break-downs, or other disrupting factors becomes less, herewith reducing the risk for the terminal operator. When the results of these tests are shared with the people that will operate the terminal after going live, the negative effects are likely to be smaller during the start-up of operations.
• A prerequisite to the success of the approach proposed in this research is the cooperation and coordination between the simulation group and the software engineering team. We have experienced that this process is not always easy because of two reasons. The main reason is the difference in objectives. The prototype in the simulation environment is built to assess the contribution to performance, rather than to develop a piece of software that can be used in an operational environment. Although the two can go together, it is not always the case, which may lead to a solution that works perfectly in the model system, but difficult to transfer to the production software. The second reason is the concurrency between the simulation approach and the actual software engineering and development. As the simulation approach continues during the software development, the detailed design runs on two tracks that may deviate at some points. A regular exchange of ideas and designs is required to keep it on the same track.

Instantiation

The design approach developed as part of our research has been applied in a number of recent projects, where it concerns the implementation of robotized container terminals. Throughout the design-engineering process, simulation models were used extensively for multiple purposes. In the initial phases for developing a terminal that satisfied the requirements, in later phases to answer detailed engineering questions, and during the implementation to assist in testing the real-time control software.

In order to illustrate this, the following diagram has been developed, showing the various phases of development and implementation. The key components of the IT landscape in an automated terminal – Terminal Operating System (TOS) and Equipment Control System (ECS) – are first specified, then prototyped by means of simulation models, and consequently tested in isolation of combined.

This approach has led to the opportunity to test early under ‘near to live’ circumstances, meaning large scale, dynamic, peak use of the systems, where traditional testing methods only allow for ‘simple’ scripts, testing limited system functionality in isolation.

Experience now shows the great value of this approach, even to the extent that such tools cannot be missed in such a complex system implementation. At least not until systems mature, and quality becomes better.

Further extension is required in the area of exception testing. In most of the applications so far, the focus has been on large-scale operations, yet undisturbed. Live operations though are – especially in the initial phases after go-live; yet we are talking here months to even years – characterised by a high number of disturbances, due to equipment unreliability, or due to software errors.

Figure 2: From complete virtual operations to live operations assisted by modeling for testing and tuning

Epilogue

When looking into the future, we see a further extension of the simulation approach at container terminals. First, apart from a monitoring function, a simulation approach may also be used to support real-time decision-making. For instance, when something unexpected happens, the actual situation may be loaded into the model system, with which then multiple courses of actions can be analysed. The outcome – i.e. the best course of action – may then be fed back into the real system. Although this is principally a typical simulation cycle, the requirements to the model system are of such a nature that this kind of use is not yet trivial. Hence, it requires an on-line interface between model system and the actual data sources (i.e. the database of the TOS), as well as requiring a short experiment lead time.

In order to make such predictions about the future, the models used need to be not only fast, but also reliable, in terms of predictive value. We recently have made progress in the development of such models, where we could show valid results up to 8 hours ahead. Further challenges ahead lie in the interpretation of results such models generate (Boer and Saanen, 2014). The audience, typically planners and supervisors are not data analysists, hence the translation of results of models into action is still a gap to bridge.

Literature

• Boer, C.A. and Y.A. Saanen (2014), Plan Validation for Container Terminals, in Proceedings of the Wintersim conference, Tolk et al (eds).
• Sol, H.G. (1982), Simulation in Information Systems Development, Doctoral Dissertation, University of Groningen.
• Wysk R., (2001), Rapid Prototyping and Development of FMS Control Software for Computer Integrated Manufacturing, retrieved from the internet at 21-06-2001, http://www.engr.psu.edu/cim/rc