International transportation is rapidly growing. Even during the recent recession, trade growth percentages world-wide exceeded 5-10%. As a consequence, container handling capacity is rapidly growing as well. Larger vessels, bigger container terminals: it appears to be an on-going process of which the limits have not yet been reached. At the same time, there is an increasing emphasis on cost and environmental control, 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 process control system (PCS) 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. Thus, the container handling industry and in particular container terminals, are arrived at a point where new solutions are required; solutions that provide higher performance at lower cost and less space usage. Here, robotization and large-scale automation is the way to go. However, up to now, robotized terminal development has suffered from problems during and after the design-engineering process. Therefore, we defined the following objective for our research: To develop an approach for designing robotized, marine container terminals, which addresses the specific characteristics of such terminals, and considers the specific properties of terminal environments. We have explored and pursued this objective within the boundaries of marine, robotized container terminals. In our design process, we focus on the reduction of risk of development of robotized terminals, and intend to include the innovative nature within the design-engineering process. The research methodology follows the inductive hypothetic cycle. Based on inductive case studies we have designed a framework of guidelines, and developed based on these guidelines an approach for designing robotized container terminals. The approach is accompanied by an extensive suite of (simulation) models that we developed and applied in many projects (see Dobner et al. 1999, 2000, 2001, 2002, 2003, and 2004). The model suite has a building-block based architecture (Verbraeck et al., 2002), which basically means that each component is defined by its interface, whereas the implementation internally may vary according to the scope of the analysis for which the model is used. Throughout the design process, the interfaces remain unchanged, but the behaviour may change, independent of the implementation of other components. The approach and model suite have been applied in a number of case studies during which we have gained experience with its applicability and contribution to the design process and the suite of models. We have also questioned an expert panel on the main guidelines about their usefulness. As a starting point for our approach we chose a simulation approach (Sol, 1982), which has proven to be a solid problem solving approach for complex problems. The approach we have designed is founded on four main activities within the design-engineering process: ? Functional design ? Technical design ? Implementation ? Commissioning and operations. In each activity we propose applying a simulation approach, which means that for design and engineering issues a problem solving approach is used. This approach heavily relies on the use of models, especially simulation models. 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, 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. 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 TOS in particular, because the functionality of the TOS is a critical success factor. Representing the TOS of an automated terminal means – as compared to the representation of the TOS at manned terminals – 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. Finally, 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. At present, the models that could provide valuable decision support are still too slow; to get solid outcomes at least 8 to 24 hours of runtime is required. We expect that these kinds of applications will be used more in the future as technology will be more able to support them. A way to go here is also to apply distributed computing: all terminal operating systems of robotized terminals are running as distributed client-server applications; this may also be needed for the test-environment to cope with the required computation power. This is an additional reason for applying a building block based design of model systems, such as the model suite we developed as part of this research. A second application that we foresee in the near future is one that we address as reverse simulation. With this notion we mean that the past is replayed for analysis purposes. For instance, all events are logged from an operation of two weeks. The log is fed into the simulation environment and replayed so that all anomalies can be analysed off-line. Then, based on the analysis resulting from the replay, parameters can be adjusted and the effect of such adjustments can be analysed by repeating the replay. This approach, using the same environment as for other problem solving cycles, will lead to the ability to configure a terminal operating system avoiding a trial-and-error approach, which inevitably leads to performance loss in some cases. Because the comparison is based on real data, and is always of a comparative nature – after all, first the settings that are logged are replayed, then the new settings are analysed – the outcome of such simulation experiments are valid for the outcomes in practice.