News section

News, papers, press releases, publications and technical articles by TBA Group
A design approach for robotized maritime container terminals
October 2019

Dr. Yvo Saanen, TBA Group, Delft, the Netherlands Terminal Operator – state of the industry 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 Would like to know more about our simulation and emulation services for terminal operations? Contact us

Publication
Optimisation as mantra for operational excellence
October 2019

Dr. Yvo Saanen, TBA Group, Delft, the Netherlands Experience with process improvement To most, TBA is known for its services during terminal planning and realisation, state-of-the-art simulation models to quantify the need of future operations. Following this approach, TBA has worked on many new terminals that meanwhile have gone into live operation – e.g. Euromax, Khalifa Port, Antwerp and London Gateway, APMT Virginia, DP World Brisbane, BNCT in Pusan, GTI in Mumbai, Transnet in Durban, Tercat in Barcelona, GCT in New York, LBCT in Long Beach, APMT MV2 in Rotterdam, and Rotterdam World Gateway. Probably, TBA is less known for its support of operational improvement, optimising the terminal's processes. Over the course of the last 10 years, TBA has looked at over 30 terminals, and applied its proven process improvement approach, based on the DMAIC or 6-sigma model. In this paper we discuss the approach and its results, arguing that every terminal should do it, one way or the other. The business case – as we will show in this paper – for process improvement at container terminals is very solid, meaning returns within 1 year. Objectives Most terminals strive for higher waterside performance (quay crane or berth productivity). The easiest way to achieve this is to deploy more equipment (yard equipment and horizontal transportation equipment). However, this typically leads to an increase in operating costs, which is not in the interest of the terminal, unless the shipping line is willing to pay more for shorter turn times in port (which is rarely the case). Hence, adding equipment is not the way to go. It also means that just measuring service levels (berth productivity, or truck turn time), is sufficient to determine whether the terminal has improved its efficiency. To overcome this, we introduce the performance-cost index (PCI), which looks at the change (ΔP) in performance in relation to the change in operating expenses (ΔC). In formula form: As example: The PCI would then turn out as: (1 + (27–25)/25)/(1 + (145-150)/150) = 1.08 / 0.97 = 1.12 (12% improvement). Similarly, other performance KPI's could be integrated in the P formula, weighted against their relative importance, in the form of: , where a is the relative weight of a KPI, and P the performance of that KPI. The approach The approach we have developed is divided into three main phases (see also Figure 1): Quick scan Improvement study Implementation & Continuous improvement Figure 1: Process improvement approach Quick scan The objective of this phase is to arrive at a diagnosis of the operation and to have insight into bottlenecks and opportunities. This quick scan consists of 4 steps: data analysis, layout review, site visit, and reporting. During the on-site visit, the results from the initial data analysis are discussed, which typically leads to observations the terminal staff was not entirely aware of. This range from the frequency of QC deployment, the distances driven by prime movers, the time equipment is idle, etcetera. Subsequently, several brainstorming sessions are held, followed by time and motion studies and staff interviews. The data analysis will commence prior to the initial site visit and focuses on: Container flow data, equipment characteristics, vessel patterns (pro forma berth schedule), and layout characteristics. Recent and past utilisation and productivity of equipment, using TBA’s KPI tool to analyze TOS data. Layout analysis. Capacity analysis of berth and yard. The final result of the quick scan phase is a list of identified bottlenecks, as well as a list with potential improvements. The latter list will be divided into 3 categories: Measures to implement immediately, without further study (internal or external) Measures to analyse using simulation in the coming period Measures to be put on hold until further notice The operational aspects that are typically covered in the list of improvement measures: Terminal capacity Key performance indicators Terminal layout, possibly of off-dock sites Operating procedures and processes (including planning and use of information) Yard strategy Equipment characteristics and productivity Time and motion in the operation Container and traffic flow Resource deployment Figure 2: Areas of attention for improvement measures Observations and performance numbers are compared to with peer sites and benchmarks for similar terminals, and applicable best practices. From this list of references, a list of identified bottlenecks, as well as possible improvement measures will be created. At the end of the on-site visit, the draft quick scan report will be presented; the final version is typically finalised within a week after the site visit. The report will include a list of improvement measures which will be roughly evaluated on expected effort and gain, and graphically displayed in an improvement matrix based on experience as shown in Figure 3. In this initial study, no quantified tools will be used to evaluate the measures. We will rank them based on experience into the 3 categories aforementioned. Here our Improvement Matrix helps categorising the benefits versus the costs of each measure. We distinguish 4 categories: Cash cows (high benefit, low implementation cost) Stars (high benefit, high implementation cost) Question marks (low benefit, low implementation cost) Dogs (low benefit, high implementation cost) Figure 3: TBA’s Improvement Matrix to Graphically Rank Performance Measures Improvement study The improvement study is the next step in the improvement approach, and takes the list with identified improvement measures to an in-depth analysis, to determine the impacts on performance and cost such measures would have. The aim of this step is to arrive at a list of evaluated improvement measures and an implementation plan. This phase will immediately commence, and the lead developer will be part of the team on-site, so he is involved from the beginning to ensure fast and accurate modeling. We discern three steps: Develop and validate a model of the terminal, and model the improvement measures as alternative solutions. Analyse in detail the impact of the improvement measures on performance and cost. Define an implementation plan based on the outcome. The most promising improvement measures that require additional study will be developed further and analysed in more detail. Jointly a list of improvement measures will be determined that needs detailed, quantitative investigation – this to avoid that the wrong strategies are implemented. Impact on both costs and performance will be analysed in more detail to update the graphical representation. For the evaluation of the impact of the improvement measures on terminal performance, we will make use of advanced models (TIMESQUARE) that are validated using real data from the terminal. These models can be used to determine the best improvement measures, and to quantify them for performance impact and operational cost impact. In Figure 4, a typical example of results from an analysis of improvement is tabled. The potential monthly (!) savings are exemplary for exercises like this. Figure 4: Example of results from a simulation, including PCI calculation The modelling and validation is part are the most time-consuming tasks. Although we have an extensive in-house library of terminal models – ranging from simple reach stacker models, to large scale automated terminals – the calibration to a specific terminal’s environment, with specific (labour) practices and processes takes time and diligence. It pays off though, because a validated model is a perfect play ground to investigate the various ideas that live at a terminal. Figure 5: Snapshots from TBA's TIMESQUARE simulation model In addition to performance analyses, the impact on cost (investment and operational cost) of the improvement measures will be analysed for labour hours, equipment running hours, equipment maintenance, equipment energy consumption, and equipment purchase. The results of the performance and cost analyses are combined in the performance cost index. See Figure 6 for an example where packages of improvement measures are combined. Figure 6: Comparison of Improvement Measures vs. Performance Cost Index and Required CAPEX In a joint session, the terminal and TBA will select the improvements that should be implemented. Implementation The hardest part is the implementation. After reaching a list of promising (and less promising improvements), the changes have to be implemented, and this requires change management. Typically, there is remaining resistance against change, although having the numbers in hand, it helps to convince people that this is the right way forward. Based on our experience, the following is key during the implementation: Only implement one improvement measure at the time; as such you allow for focus and measurement of the result. Ensure buy-in and understanding of all stakeholders involved; typically operations, IT, engineering, and the management. Do not give up after one trial; some changes require training, and practice. Ensure training beforehand; many changes fail due to a lack of training. Share success with all stakeholders. Check after a few months whether the new practice is still in place. Old habits are persistent. Concluding remarks As may have become clear from this paper: process improvement is a rewarding activity at container terminals. Therefore, it isn’t surprising that several global terminal operators have created there in-house lean 6-sigma teams. The returns of a successful implementation of improvement measures are large, and pay off in most cases within 1 year. The crucial point is the implementation (change) of the new practices, overcoming the resistance, and sticking to the new practices. In our experience, this has proved to be the hardest part. Nothing more difficult than change! The quantitative approach we follow, using proven, accurate models that reflect operational practices to great detail helps to convince people, and assist in defining which measures are worthwhile to implement, and which are better to stay untouched, just wasting resources. Moreover, bringing international benchmarks also helps placing practices in its context. As much as terminals think they are different, as much as operational practices prove to be applicable world-wide. This paper was previously published in Port Technology International magazine in 2014 and its contents has been slightly updated to reflect current date. Go here to see the original publication.

Publication
Making the transition to digital - Benefits for bulk operators by adopting a terminal operating system
September 2019

David Trueman, TBA Group, Doncaster, UK When you consider the latest technological developments, it is clear that whilst we are still in the early stages of widespread utilisation, they will fundamentally change the way that business is done. For many people, Artificial Intelligence, Big Data and the Internet of Things are just buzz words, but as these technologies move from the laboratory to the world of work, we need to consider how bulk terminal operators can derive the best value from them. The current system landscape Herein lies the challenge for dry bulk ports and terminals, which have been traditionally slow to adopt information technology for the following reasons. Unlike the container terminal environment, where using a terminal operating system (TOS) is a standard prerequisite, the bulk and general cargo sectors are so operationally diverse that the marketplace for TOS systems is still not clearly established. A survey of the sector would reveal numerous terminals using spreadsheets, with others using in-house or bespoke packages and a few using proprietary systems from established, specialist providers.A bulk cargo inventory is measured in multiple ways at many points along the supply chain and can change due to spillage, moisture loss/gain and accidental co-mingling. Inaccuracy and inconsistency in weighing equipment and draft surveys plus the possibility of losses through the poor recording of paper weigh tickets has created an environment where terminals are often nervous of sharing too much information with their customers and therefore the benefits afforded by standard EDI messaging, automatically scheduled reports and other information exchanges have been resisted. The term "glass ceiling" is often used to describe the human disconnection between engineering and IT departments within organisations. IT managers know that real time data would improve the performance of their business systems, but they do not know how to achieve it. They are also reluctant to allow automation systems to reside on and connect to their IT infrastructure because they fear that this will reduce the resilience to virus’ etc. Figure 1. CommTrac silo storage management system Conversely, engineers have the data but do not understand IT systems or the value of the data to the business. Therefore, the data may be used to improve uptime and maintenance routines, but remains at the engineering level. Operations and senior management often want the data but are unaware of the ability of these systems to cohesively connect. Therefore, the "glass ceiling" remains and the business fails to benefit from the improvements this connectivity would bring. The way forward The starting point is to realise that the creation of an optimal information system strategy will have a beneficial impact on the bottom line. Therefore, there is a return on investment (ROI) to justify the expenditure in executing the strategy. To decide the specifics of the strategy is more problematic and here the likely issue is that no one in the organisation will have the know-how to formulate a strategy, which embraces new technology to benefit all stakeholders in the business. At this point, an effective approach is to engage outside expertise, either a consultancy or a TOS provider. Each of these options has positive and negative aspects: A consultant can spend time with the customer to create a vision strategy and a functional specification aligned with the operational processes of the terminal. This can allow the client to go to the marketplace with a tender and create a competitive environment to deliver the best value for the business. Establishing a working relationship with a system provider can be more effective in that they have experience working with numerous terminals and can bring that experience to the project to shortcut learning. They are also likely to have a number of standard process workflows in their software that will provide users with an effective user experience without the need for customisation, which can have a big impact on budgets and timelines. Whichever approach is chosen, the operator needs to agree with the provider on what the success factors are for the project and these should be more than organisational success factors. What outcomes will improve the customer experience? How will the planner’s life be made easier? What do the finance department need from an operational system? Once understood, these success factors can be referenced throughout the project to ensure that the project is likely to deliver the expected outcomes. Core components For a terminal operator to derive optimal benefit from digitisation there are a number of core components which are intrinsic to the system landscape. At the core is a TOS. This software sits in the operational layer and collects, stores and presents key information relating to: Vessel planning and execution. Inventory management. All activities relating to cargo moves and cargo conditioning. Truck, barge and rail activities and transactions. Recording of events and processes relating to tariffs and demurrage/despatch. For the terminal operating system to be most effective, it should integrate with other systems in the terminal environment. In this environment, the TOS takes data from the real time equipment layer (control systems, weighbridges etc), presents it to users, to support their operational processes, before rationalising and distributing the data to other integrated systems such as: ERP/finance systems for billing or P&L. Maintenance management systems for the creation of work orders. Customer systems or portal to provide timely information to customers. Figure 2. Detailed reporting functionality. From a user perspective, this environment creates a single repository and therefore “one version of the truth”. Single data entries updating all users also radically reduces the amount of manually manipulated data therefore inherently the amount of administrative work load and paper errors. Mobile users Apps are universally used for various reasons, including booking travel, seeing the weather forecast, finding directions, playing games etc. So, humans are familiar with simple, smart tools on their mobile phones, which help them in their daily lives. It is clear, however that this type of software can also be of real benefit in the work environment. Figure 3. Mobile solutions for terminal management.“On the ground” workers cannot work effectively with desktop computers; they need to be in their working environment close to the activity they are performing. However, if they can receive timely information and record their activities easily, then this can greatly enhance their efficiency and that of the whole operation. Software working in this environment needs to be simple, easy to use with minimal key strokes and able to run on a mobile phone.Key operational areas where this can be most effective are: Event/delay logging during vessel activities. Tallying of cargo. Work instructions for payloader and forklift drivers. Scanning of cargo barcodes. To ensure that operations are uninterrupted, the technology can seamlessly operate in WiFi, 4G and offline modes, switching between the modes as required. If the devices operate in offline mode, they can automatically synch when they return to online mode. Business case The utilisation of technology systems provides clear, tangible results for the terminal operator and their customers. As well as the obvious reductions in administrative workload and improvements in customer information, the real ROIs are gained by utilising information to reduce demurrage and increase operational efficiency.By monitoring vessel loading/unloading in tonnes per hour and stoppage events, before comparing these to the contract terms for the activity, the terminal has a clear view of their commercial position. Decisions to change the process, add overtime shifts or other resources are made on the basis of clear factual information and not "finger in the air" supposition. Retrospective analysis of this data also allows the terminal to understand the root cause of performance losses and drives a culture of continuous improvement. Turning vessels around more quickly and optimising storage utilisations also provides the opportunity to handle more cargo.Other less tangible returns are the prevention of stock losses or cross-contamination of cargo, and although these can be difficult to quantify financially, any prevention of customer claims for this type of event is significant. For example, a grain terminal handling multiple product types would be faced with a potentially huge claim if it accidentally mixed genetically modified cargo with non-genetically modified cargo. The TOS can prevent this by ensuring that the conveyor routing has to carry cargo only to a storage position, which holds cargo of the same lot, removing the opportunity for human error. Conclusion Digitisation is no longer about a series of buzz words. When systems are implemented, incorporating digital technologies as practical tools, they can radically improve the operational and commercial performance of a terminal and enhance the working environment of all stakeholders, including customers.By understanding the ROI opportunities, as well as the practical advantages, it is easier to approve CAPEX funding for system implementations and even in more challenging commercial environments, software as a service agreements can move software costs into OPEX to avoid a large initial outlay.So, the technology is available and the ROI is clear, however for digitisation projects to be successful the human element has to be taken into consideration. Understanding and explaining the success factors for both the business and the individual users is essential to gain support and enthusiasm for the transition to an integrated, digitalised bulk terminal. This article has been published in the Autumn 2019 edition of Dry Bulk Magazine.

Publication
Technologies that bring value to ports and terminals
July 2019

Dr. Yvo Saanen, TBA Group, Delft, the Netherlands In 2018, the first version of this paper was published, reflecting on the technologies that bring value to ports and terminals, yet also reviewing the level to which these technologies have been adopted. The conclusion then was that despite the vast availability of technologies, few have been widely applied, and many are looking for problems to solve. The buzz today is centred around 5G. If the discussion is not about the suspected loopholes in Huawei’s technology, then it is focused on the enormous potential 5G offers for almost every environment. Once again though, is it a technology seeking a problem? 4G is already quite fast and has been applied across terminals as a viable alternative to narrow band or WiFi. Due to the price drop of access points, 4G and 5G will address a problem in container terminals: real-time connectivity of equipment without latency. However, the harsh conditions encountered in terminals – an outdoor environment, steel everywhere, large structures, impact of vibrations, wind and clashes - make it complicated to get a stable and reliable signal to all moving equipment. The 5G technology requires even more access points than 4G (due to the higher frequency), yet can also be powered more, creating a stronger signal. Asset Management and Control Enabled by 5G networks, real-time tracking of equipment and containers becomes feasible. This means that not only are all assets’ locations visible, but their technical status can be reported and made visible in the control room in real-time. The redundancy of connection points will not be a deal-breaker due to the acceptable pricing of the technology. For automated equipment as well, which requires a fail-safe and continuous communication, 5G provides a much better foundation than common WiFi connections. Due to the higher bandwidth and lower latency, delays in automated processes while communicating with the central control system will be reduced to insignificant levels, enhancing the productivity of the machines. Remote error handling and remote container placement will also become easier, due to high definition streaming of camera data. The reduced latency (resulting in lag of the movement after a remote input) will also be reduced even further, so that remote control becomes more natural and, as a result, faster. What About the Other Technology Trends? The word is not yet out on blockchain and, despite a true hype two to three years ago, it remains an underdeveloped technology. The complexity of implementation, due to the vast number of stakeholders required to make it work on a global scale, forms a barrier to the fast roll-out of this solution. How about artificial intelligence? While it is still a buzz word getting lots of attention, we are yet to see it really achieve a breakthrough in the maritime industry. Even when it is utilized in dedicated areas, such as predictive maintenance, one finds handling the vast amounts of collected data difficult, let alone deriving useful, reliable and predictive data from the pile of bits and bytes. Last but not least: the digital twin. Here we see adoption by some of the large equipment suppliers, developing digital twins of their equipment to facilitate the design and testing phase. 1.    Connected to the Outer World Although one would expect that all of the information sent to terminals is delivered in standardized digital formats, the reality is far from that. Timely data availability, data quality, and digitization are all problematic, leading to large inefficiencies in terminal operations and affecting the service that terminals provide. In many ports around the world, initiatives are taken to make the information accessible to all parties, yet there is resistance from certain stakeholders who believe their position may be weakened or even disappear if information flows freely. Today’s question is who gains control over the supply chain: large producers, whole sellers, 3PL suppliers, shipping lines, terminals, or consumers? Many platforms are launched, trying to become the travel agent of the container supply chain, or a centralized platform for buying goods. The verdict has not been delivered yet, but it is an area of large development. In all likelihood, terminals will not play a dominant role in controlling the supply chain. Instead, we expect their role as physical hubs - for handling large ships, but also fine distribution towards the end consumer – to increase. 2.    Connected to All Assets Terminals are a collection of high-value assets, yet real-time information about the assets is not readily available to enable intelligent control. In most cases, there is some information locally available, but not centrally, and certainly not across the entire fleet. It is scattered, has no standard structure, and is often incorrect. The technology to enable this is there - especially with the support of private 4G/5G networks - and in a large portion of equipment that is already available. Besides this, the maintenance of all the on-board technology is typically a problem. Regular calibration of sensors (e.g. weighing sensors) is required to make sure the information coming from the machine is accurate and reliable. This is not yet standard practice though, largely because the actual use of the information is limited and defies the purpose of proper maintenance. 3.    Connected to All Staff As important as connectivity to the physical assets is connectivity to human assets in the field, as this ensures people are removed from danger (think of location detection, or proximity sensors), as well as information in real-time to perform actions efficiently. Instead, people are often sent around to record information on paper that will be processed later. This, remember, is taking place in a time when almost everything can be accessed through smart-phones. We could even think one step further here into augmented reality (now accessible through technology like the Google Glass) so that operators get immediate visual information while keeping their hands free. While the possibilities are there, the maritime industry has not witnessed many developments when it comes to connecting people with intelligent sensor technology, although 5G may prove to be a game changer in this area. 4.    Real-Time, Holistic Planning, Control and Optimization A terminal consists of a series of interlinked, highly variable processes, hence dynamic, real-time planning and control is essential to be efficient. There are many planning, scheduling and dispatching tools in the market to assist and provide decision-making support, yet there is great resistance – especially from operators – to use these tools. On the one hand there is a degree of job protection behind this, but also lack of insight into the benefits. The efficiency gain does not come from some reductions in planning and dispatching staff, but by operating in a better way outside. Here the real expense is being spent on machines, fuel and labour. The rate of change, in terms of planning, scheduling and dispatching inside container terminals, is still slow, and even with the introduction of new technologies there are few changes to report. 5.    Real-Time Measuring of KPI’s In order to improve, one needs to know what’s going on. Hence, the performance of the operation should be measured continuously, and to a great level of detail. Only then can you really explain the peaks and troughs of performance. Only measuring STS productivity, for instance, does not provide sufficient insight. Also, the circumstances affecting performance must be gathered so that a complete picture can be formed. Yard occupancy, gate volume, driving distances, and number of unproductive moves should all be monitored. Some initiatives have been launched to gather information from various sources and create real-time insight into the state of equipment, its performance, and utilization levels. This is typically driven locally by terminals, which are creating data-warehouses and connecting TOS, maintenance systems and equipment to make sense of collected data. True success stories, however, are still limited. 6.    Continuous Analysis of Performance (KPI’s) When all this measurement is in order, there is a solid basis for analysis; just gathering the data serves no purpose. It needs to be turned into insight and then knowledge so that the actual control improves. The cycle of measuring, analysis, and action should be continuous, so that the learning cycle also reacts to changes. Changes in volume, dwell times, truck patterns, or just the arrival of a new vessel service are likely to require adjusting operational strategies. In this process, it is also key to make a record of implemented changes. While most changes in strategy will only have effect over a longer period of time, there will be cyclic, and independent factors - such as seasonal patterns – that have an influence. These effects must be taken into account when analyzing the result of change. In any case, a first, solid KPI measurement needs to be in place, with the real use following after once stable platforms have been established. 7.    Training and Certification of Staff Having a serious training programme, for both on-boarding and to enhance operating skills, is a key factor in operational performance. Even though most operators are conducting or setting up training programmes, certification of the control room staff is still rare; our findings across more than 25 terminals (>250 planners) show the difference between worst and best planners to be as high as 50% (measured in resulting berth productivity). Testing planners against a calibrated scenario – such as a near-to-live virtual terminal – is a possible way to get people in the right position. The importance of more advanced training tools has also become more widely accepted, albeit not as fast as the industry requires. We have seen quite dramatic results, but also improvements from the use of advanced training tools in the past year. 8.    Capability to Learn from the Past Returning to the hype word of artificial intelligence, it could be said that the ideas behind it are new, but the combination of large amounts of available data, and cheap, cloud-based computing power, brings the ability to recognize patterns quickly nearer to being useful. Still, computers have a tough time recognizing the context of data. The potential is significant though, as the container supply chain is highly repetitive and therefore predictable. Learning about dwell time, pick-up and roll-over patterns may reduce the number of unproductive moves by factors. As terminals are struggling to get well-organised KPI’s in place, the regular and consistent use of them remains a struggle as well. Too often, Excel is still the tool being used to analyze data, even with a range of more advanced data analytics tools available. 9.    Terminal Development Based on a ‘Master Plan’ When we look at how terminals have come about, we recognize that many resemble patchwork. Every expansion is planned when required, without looking at the bigger picture; buildings in the most inconvenient places, height differences, light poles, and roads with illogical routing, are all quite common. Of course, not everything can be taken into account, but we can go significantly further in looking ahead and making a robust masterplan, that withstands change of circumstances to a large extent. Modelling can greatly help in the assessment of cargo flows, ship sizes, hinterland transportation patterns and dwell times during master planning, as well as acting as a source of reference for future decision-making. Even the consequences of changes parameters can be easily analysed and quantified. Modelling is becoming the standard for new terminals and terminal expansions or retrofits. Across the globe, the default has become that master planning requires in-depth modelling to facilitate decision-making. 10.    A Solid Cybersecurity Layer in Place Last but not least, a terminal today needs to have its cybersecurity in order. There is a large degree of data exchange with many third parties, increasing the risk of receiving malware or viruses that can spread to others. The fact that containers carry high-value goods also makes them a potential target of cybercrime. Finding the right container by hacking into the system and setting up an illegal delivery is not a hypothetical scenario. This means that cyber security must be part of the daily IT process; making sure that staff are aware of the risk is key, as people are always the weakest link. It has become obvious that cyber security also needs to be a top priority for container terminals, especially at the board level. Reliance on IT and data, and their responsibility for valuable goods, are simply too great to ignore, yet there remains much to do. Concluding Remarks A quick inventory at a range of terminals during the last couple of months revealed that from these 10 pre-requisites  most terminals have not fulfilled most. None of the points mentioned will require large investments, or be too complex to implement, but they do require an ability and willingness to change. In many cases, this only arises when there is a serious problem, such as a damaging cyberattack, or pressure from the outside (e.g. from local authorities) to implement adjustments and efficiency enhancing measures for higher levels of productivity. So, there is still a long way to go. This paper has been published in Port Technology Magazine edition number 86.

Publication
Handling of solid biomass from the perspective of dry bulk terminals
July 2019

Dr. Mi-Rong (Kimberly) Wu, TBA Group, Delft, Netherlands Many dry bulk terminals have experienced the increase in biomass handling because of the use in feed and food sector, the recent technical development in bioenergy, and several governmental energy policies (e.g. EU directives) [1]. Normally the biomass for the application in the feed and food sector (e.g. corn, oats, soy meals, barley) is handled by grain terminals. However, because of the wide range of applications in the energy sector, the handling of solid biomass materials has been seen also in other dry bulk terminals. Camia et al. estimated that more than 1 billion tons per year of solid biomass has been used in the EU; primarily in the feed and food sector, followed by bioenergy sector and biomaterial (see Figure 1) [1]. IEA  has also estimated that by 2040 the demand for bioenergy will exceed 1,850 Mtoe [2]. Figure 1: Distribution of EU-28 biomass uses [1]. Solid biomass comes in various forms (e.g. pellets, chips) and from various sectors (e.g. agriculture, forestry) and increasingly it is being traded in international markets. Bradley et al. [3] have indicated that shipping is the main method to transport solid biomass. In addition, other studies ( [4] [5]) have concluded that the most preferable biomass supply chain is long distance transport via shipping. This implies that marine terminals in ports will be the important hubs within the logistics chain. Various aspects should be taken into account to have a thorough picture of solid biomass operations: the significant material types for large-scale handling, the implication from the physical/flow properties for cargo handling at the terminal, and the effects caused by the stochastic parameters (e.g. vessel arrival patterns) to the storage capacity and storage time of solid biomass operations. These aspects are further discussed in the following sections. Material type and physical properties of solid biomass There are various kinds of solid biomass, but not every type is suitable for being transported over long distances and handled in dry bulk terminals. Important criteria such as potential availability, the application preference/possibility by major users (e.g. power plants) and logistical concerns are the reasons that wood pellets and wood chips are the main feedstocks for bioenergy application. Another solid biomass with good potential is torrefied pellets because its material properties (e.g. higher energy content, hydrophobic), provided that the market implementation in the future will be successful. It is essential to understand the material properties of these selected solid biomass types, in order to know how to handle and store them properly. Selection and design of handling and storage equipment for solid biomass types strongly depends on their physical material properties/flow properties. Furthermore, the flow properties may also affect the operational process. For a better understanding regarding equipment it is important to look deeper to compare these solid biomass properties with other bulk materials that have been handled and studied frequently, such as coal and grain. Table 1 shows that there is four times more volume of solid biomass required for the same energy output compared with coal. Solid biomass properties show a much wider range per characteristic, in comparison with soybean and coal. Furthermore, the following aspects are important when it comes to solid biomass fuels from the perspective of a dry terminal: Because of the hydrophilic nature of solid biomass fuels, they are sensitive to material degradation. It is recommended to handle and store solid biomass fuels with enclosed or covered equipment/option (e.g. warehouses, covered trough belt conveyors). Solid biomass has a strong tendency for self-heating because of bio-activities and potential high moisture content. Thus, certain common prevention measures performed for coal handling (e.g. compaction) increase the risk of selfheating. Equipment designed for coal handling is suitable for the operation of solid biomass fuels. However, the handling processes/methods need to be adjusted according to the material properties. Because of the low bulk density, more equipment (capacity) is required for the same tonnage handling performance. For solid biomass handling, the volumetric performance should be the main benchmark rather than tonnage performance. Impact from stochastic elements to storage capacity and storage time It is challenging to simply calculate the storage capacity as a result from the following factors: the supply seasonality; the arrival patterns of the incoming and outgoing flows; the size composition of the vessels/inland transportation); the operational strategies and process at the dry bulk terminal; and the operational stoppages (e.g. rain, equipment breakdowns). Dynamic simulation tools are increasing used to make such an estimation for: the ability to cope with the above-mentioned stochastic elements, the capability for quantifying the measurable KPIs (see Figure 2 and Figure 3 for examples), and the strength to systematically compare various strategies/options. It is recommended to use such a simulation approach to design and assess the storage arrangement for the solid biomass handling. A common demand figure for a power station unit will be about 3 million tons of wood pellets per year and when the choice comes to wood chips even 4-4.5 million tons may be required.  Storage facilities for solid biomass require large areas as a result of their low bulk density and energy content (Table 1), to have the same energy output as coal, up to 8 times more volume of solid biomass is required [7]. Furthermore, the need for an uninterrupted supply, power stations typically ask for storage capacities of about 100,000 tons which requires a covered storage around 200,000 m3 (wood pellets). With the same stacking method, 1.3 times more land is needed (lower volumetric performances for biomass) [8]. Several enclosed/covered storage options can be used to store solid biomass, such as silos (assuring a first-in/first-out material flow); flat storage (wide sheds) or domes. The following recommendations apply to all storage options [8]: Measures against dry matter loss and material degradation, such as a good ventilation system and pre-drying before storage, should be applied. Measures against self-heating should be applied. Such measures can be having homogeneous storage piles (in terms of material particle size distribution), taking the geometry of storage piles into account, avoiding compacted storage piles, etc. The storage time of solid biomass should be controlled. Depending on the mois-ture content of the material, the recommended maximum storage time varies from 3 weeks (for fresh wood chips) to 3 months (wood pellets). Both storage capacity and storage time are sensitive to arrival and departure patterns. Good logistic control is required. Figure 2: An example of yearly stock level fluctuation from simulation experiments. Figure 3: An example of vessel turnaround time from simulation experiments.   Conclusions and recommedations Currently more and more dry bulk terminals are adding solid biomass into their cargo portfolio. It is expected that significant amount of wood pellets and wood chips will be handled by dry bulk terminals in the future, as well as “new type” of bioenergy feedstocks, such as torrefied pellets.The material characteristics of solid biomass come with a wide variation range compared to commonly handled bulk materials such as coal or grain; it is necessary to have adjustments in terms of handling process and storage requirement. The low bulk density makes the volumetric requirement more influential than the tonnage demand mostly seen from other commonly handled bulk commodities. Several handling processes need to be adjusted (e.g. enclosed storage, self-heating prevention method) to cope with solid biomass material properties.An analysis supported with simulation tools is recommended as this allows investigating the combined impact of stochastic events (e.g. material arrival and departure patterns, operational disruptions) and the material characteristics. This approach will result in a better terminal design in terms of berth capacity, equipment utilization, storage capacity and storage time.   About the author Dr. Mi-Rong (Kimberly) Wu is the principal bulk specialist at TBA Group. She has been involved with logistics, ports and terminals throughout her professional career since 2005. She has over 12 years’ experience in the bulk sector focusing on subjects such as: bulk terminal design, bulk material handling and simulation modelling for bulk terminaldesign. TBA’s services have been proven to add value to existing terminals by increasing operational efficiency, supporting existing terminals to plan for future expansion and validating design for terminals. TBA’s project portfolio covers terminals handling biomass, agri-bulk, coal, iron ore, sulphur, sugar and more. References [1]     A. Camia, N. Robert , R. Jonsson , R. Pilli , S. García-Condado, R. López-Lozano, M. van der Velde, T. Ronzon, P. Gurría , R. M’Barek, S. Tamosiunas, G. Fiore, R. Araujo, N. Hoepffner, L. Marelli and J. Giuntoli, "Biomass production, supply, uses and flows in the European Union: First results from an integrated assessment," Publications Office of the European Union, Luxembourg, 2018.[2]     International Energy Agency (IEA), "The World Energy Outlook 2018," OECD/IEA, 2018.[3]     D. Bradley, F. Diesenreiter, M. Wild and E. Tromborg, "World Biofuel Maritime Shipping Study for IEA Task 40," 2009.[4]     R. Suurs, Long distance bioenergy logistics An assessment of costs and energy consumption for various biomass energy transport chains, Copernicus Institute, Utrecht University. ISBN 90-73958-83-0, January 2002. [5]     C. N. Hamelinck, Outlook for advanced biofeuls -- International bioenergy transport costs and energy balance, Department of Science, Technology and Society, Utrecht University. ISBN 90-393-3691-1, 2004. [6]     M. Wu, "Transitions to biomass handling - A simulaiton approach," in BULK TERMINALS 2017: ACHIEVING EFFICIENCY AND COMPLIANCE, London, 2017. [7]     M. R. Wu, A large-scale biomass bulk terminal, Delft: Delft University of Technology, 2012. ISBN 978-94-6186-076-7. [8]     M.-R. Wu, "Analysing terminal facilities for biomass operations," Port Technology International, pp. 51-54, Edition 60 November 2014. This article has been published in Dry Cargo International Magazine Issue no. 225. Read the full article here

Publication
Human Machine Interfaces - the key to productivity?
May 2019

Dr. Yvo Saanen & Dr. Azadeh Shirzad, TBA Group, Delft, Netherlands As terminal automation is commonly increasing, next steps towards the improvement of the human-machine interface need to be made. The software landscape in container terminals is not suited for the different nature of the interaction between system and human operator. To get the maximum benefit from automated terminals, we need to rethink and redesign the user system interaction. The starting point is to improve the steps that a human controller must take when certain situations occur. From these flows, we then can define the support that the system provides through its user interface to help user complete each step successfully. In this article, published in Port Technology Magazine, we discussed how we go about this at TBA Group, using the science of User-Centred design as a basis, combined with knowledge of operational processes. The notion of an ‘automated container terminal‘ suggests a very limited involvement of humans in the daily running of operations, however despite this conception, the reality is far from that. The truth is that automated terminals heavily rely on human influence to keep the fleets of driverless machines running, as well as to deal with unpredictable exceptions. This is because the handling of exceptions is poorly supported by today’s control systems (TOS and ECS), meaning a process controller requires mastermind skills. Information is divided over multiple systems rendering it (too) complex for process controllers to do their job effectively. Control room staff are also overloaded with information, which most of the time does not apply to their roles. This results in a stressful, and consequently tiring, work environment. Further, this scenario of a complex system with many unpredictable irregularities (that come with poor system support) eventually leads to a significant loss in productivity. Therefore, it is time to look for solutions to assist control room operators by providing them with an intuitive control system-user interface which includes standard operating procedures in order to deal with irregularities. In this paper, we discuss the science behind ‘Human-Machine-Interfaces’, a fast-developing field that can provide the answer to aforementioned problems. This approach is several years in the making, as we aim to redesign the way our systems interact with users by not placing the system centrally, but the user, positively influencing the way he executes his tasks. Human–Machine Interfaces ‘In the early days of industrial manufacturing, engineering and marketing process alone were sufficient to produce desirable products: it did not take much more than good engineering and reasonable pricing to produce a hammer, diesel engine, or tube of toothpaste that people would readily purchase’ (Cooper et al, 2007). The world has now evolved from this insight from Cooper et al, as eventually manufacturers realized that they need to differentiate their products from the ones made by competitors. Because of this, industrial and graphic design were introduced as means to increase desire for a product, with graphic design improving both product advertisement and industrial design. Now, with the design of software and its behaviour, desirability alone is not the unique selling point of a product any longer – software does not reveal its affordability through external form, like for example, a hammer does. Designing for interactive capabilities now requires knowledge of context as well as the users’ relationship with the given system. Understanding the users, their roles, their workflow and their goals is of essence when creating systems. Therefore, a good product reflects the users’ mental model and not the implementation/system model. The implementation details are too complicated and unnecessary for a user to be cognisant of (see Figure 1): ‘The designer must develop a conceptual model that is appropriate for the user, that captures the important parts of the operation of the device, and that is understandable by the user.’ (Norman, 2002) Figure 1 The difference between implementation model and users' mental model (Cooper et. al., 2007) User research is therefore the core of user-entered design. Qualitative and quantitative research methods are used in different design phases to keep the focus of the design on users and their needs. In the early design phase, qualitative research is mostly used to make the requirements clear, while later in the process, different research methods are practiced to modify the design based on user feedback. How simplicity can be complex To ensure automated terminals perform optimally, one of the most important challenges is to make operational control ‘simple’. We believe that simplicity will bring terminals further in terms of safety, efficiency and productivity. Therefore, understanding the context of use and users’ workflows and their goals has become the basis of the design of our products. At TBA, we are aiming to reduce excise and cognitive load by following goal-directed design guidelines while applying general interaction design principles to the design process. One of the other means to achieve this principle is integration, bringing functions for a particular operational role (say a planner, or a process controller) into one user interface, and integrating multiple systems in the background. This may seem quite easy to achieve, but conducting the proper user research (both qualitative and quantitative) has until now proven to be challenging. There are two main reasons for this: - There are few automated container terminals - Almost every terminal operates differently based on the terminal type and equipment they use   So standards are hard to be found, which in turn provides little opportunity to define the standard. Nevertheless, our functional experts and designers work closely with customers during each project to understand their needs and requirements. We also heavily rely on UX best practices when working on our products. For instance, creating a well-designed navigation app for a manual straddle carrier (SC) driver is a challenging task. He basically drives backwards and has all his attention on a container he is carrying as opposed to the route he is taking. However, he still wants to know all the details a ‘normal’ driver needs while driving – details such as whether he is driving toward his destination, if there is an exceptional situation in a terminal that requires him to take a different route, and the time to his destination, etcetera. In order to provide the best and safest driving experience, we not only looked into already-existing navigation apps, but we also drove in an SC to understand the driver’s limitations and to test our design ideas allowing us to discover inadequacies. We may not be able to perform such tests as frequently as we’d like to, but the tests offer us to: - Look into lessons learnt by best practices - Focus on achieving better performance via the information we present - Apply interaction design principles - Create user-friendly apps   Guidelines for simple HMI Besides considering the context of use and user needs, there are general principles which designers apply to the design process to optimize the user experience with product. Cooper et al name fifteen strategies for creating a harmonious interaction: - Follow users’ mental model - Less is more - Enable users to direct, don’t force them to discuss - Keep tools close at hand - Provide modeless feedback - Design for probable; provide for the possible - Provide comparisons - Provide direct manipulation and graphical input - Reflect object and application status - Avoid unnecessary reporting - Avoid blank slates - Differentiate between command and configuration - Provide choices - Hide the ejector seat levers - Optimize for responsiveness; accommodate latency   The design process of TBA products starts with the various user profiles and their roles and motivations. We not only look into their goals and strengths but also to their limitations. By defining ‘user stories’ we decide what needs to be considered in the interface to help users where they are weak and empower them where they are strong. One of the main things to keep in mind when creating a user-centred design is to give the user the feeling that he or she is always in control of the system. In order to keep users of a control system informed about the state of a terminal operation, designers often face the challenge of keeping the shown information in balance. The balance between maintaining user control on all details of the terminal operation while applying two principles of ‘less is more’ and ‘avoid unnecessary reporting’ are often the design challenges we face at TBA. Designing based on user role and workflow is our way of handling these sorts of challenges. In the next section some examples of our solutions to complicated situations are described. Theory in practice A terminal’s system landscape is a complicated combination of systems which are used by different types of users within or outside of the control room. Dispatcher (or as we say in automated terminals, ‘process controller’) is one of the main roles when it comes to managing operations. They have to keep a close eye on operations and handle every exception in a timely manner to provide their customers with a good quality service. In order to empower these kind of users in their roles, we have designed a dashboard – the ‘Action Board’ – which shows high-level information about different modules within the terminal. Figure 2 shows the concept of vessel widget in the Action Board. In case of a problem in a work queue of a quay crane (QC), a warning icon is shown on the QC’s visualization. A user can then track the source of the problem by taking two steps: - Clicking on the QC’s visualization - Expanding the work queue row with delay indication   Figure 2 The concept of Vessel widget in Action Board Figure 3 System notification As soon as the row is expanded, the details of that certain move and the root of the problem are shown. In case the problem is related to an automated vehicle, a notification also shows up in the notification panel. This notification includes a Call-To-Action button which helps the user resolve the issue immediately. Notifications in general consist of five parts (see Figure 3): - Explanation of the problem that just occurred - The consequences of the problem - Advice on how to resolve the issue - The time when the issue was reported - (If possible) a Call-To-Action button to resolve the issue   Conclusions and outlook As terminal automation is increasingly common, next steps towards the improvement of the human-machine interface need to be made. The software landscape in container terminals is not suited for the different nature of the interaction between system and human operator. To get the maximum benefit from automated terminals, we need to rethink and redesign the interaction, starting with the process steps that a human controller must carry out, when certain situations occur. From these process steps, we then can define the system support provided through the user interface, needed to complete each step successfully. In this article, we discussed how we go about this at TBA, using the science of YX design as a basis, combined with knowledge of operational processes.   Biographies Azadeh Shirzad is a User Experience Designer with over 10 years of working experience. She loves to create designs for diverse target groups. Following that passion she worked in different industries such as finance, aviation and healthcare. Currently she is working as UX Designer at TBA, where besides aligning the design of different apps she pro-actively is promoting user-centered design. Azadeh has a PDEng in User System Interaction, Eindhoven University of Technology, and an MSc in Interaction Design, Chalmers University of Technology. Yvo Saanen is commercial director and founder of TBA. He has been active in the maritime industry for over 20 years. He has consulted more than 200 terminals world-wide, and focusses on automation, process optimization, and design using simulation and emulation. In various bodies, he lectures about simulation in logistics. Yvo has a PhD in the design of automated container terminals from Delft University of Technology, and an MSc in Systems Engineering from the same university. References Cooper, Reimann, Cronin, 2007, About Face three, Wiley Publishing, Inc., Indianapolis, Indiana Norman, 2002, The design of everyday things, Basic Books, New York.   In this article, published in Port Technology Magazine, we discussed how we go about this at TBA Group, using the science of User-Centred design as a basis, combined with knowledge of operational processes. Read the full article here  

Publication
10 key actions for terminals: technologies providing value to make ports and terminals more effective, efficient, and safe.
February 2019

Dr Yvo Saanen, TBA Group, Delft the NetherlandsSome say the technological revolution is going ever-faster. Although we have to realize that in the last 100 years, the amount of technological innovations has been enormous, we have to maintain a helicopter view on the world. In recent years, we have seen the latest hypes follow each other quite rapidly, with the Internet of Things (IoT), big data, blockchain, and artificial intelligence (AI) as buzzwords. The latest addition to this grouping is ‘the digital twin’. Although all of these technologies seem to offer great opportunities to the industry, and certainly to the logistics industry, the amount of clear success stories or largescale implementations is lacking. Some may point to the conservatism in the logistics business, but others may also question the true business case of these technologies. Moreover, some of these hypes are repetitions from the past, the digital twin not in the least. After all, a digital twin is a model of the physical reality, albeit with a great level of detail. But it will always remain a model, leaving away irrelevant details.What is clear from each of these trends is that technology has become an enabler in developing innovative, value adding solutions that actually address reallife problems. The technology is readily available, affordable, and delivered in mass-production. There are many suppliers who can also assist in deploying these technologies. Does this mean we are not facing any challenges anymore? On the contrary, to make use of them such that they actually serve the objectives of ports and terminals, there is a lot of work ahead of us. In this paper, I have tried to identify where these technologies can provide value to make ports and terminals more effective, efficient, and safe. 1. CONNECTED TO THE OUTER WORLD Terminals are a key component of the supply chain. One would expect that all information that is sent to terminals, is delivered in standardized digital formats. Reality is far from that. Timely data availability, data quality, and digitization are all problematic, leading to large inefficiencies in terminal operations, affecting the service thatterminals provide. Such errors range from BAPLIE files, to inaccurate vessel ETA’s, to changing modes of transportation after arrival at the terminal, to random truck arrivals at the gate.This is in a world where all the necessary information is available in digital form. However, such information is not made available to all stakeholders in the supply chain. In many ports around the world, initiatives are taken to make the information accessible to all parties, however it takes great effort, as there is resistance with certain stakeholders, as their position may be weakened or even disappear if information freely flows. It is our expectation though that it will be just a matter of time. 2. CONNECTED TO ALL ASSETS Terminals are a collection of highvalue assets, yet the real-time available information about the assets (location, status, technical state, et cetera) is not readily available to enable intelligent control. Control for asset deployment, but also for maintenance purposes. In most cases, there is already information locally available, but not centrally, and certainly not across the entire fleet, in one fleet management system, or in the TOS. It is scattered, has no standard structure, and is often incorrect.The technology to enable this is there, and a large portion of equipment is already available, including sensors of various kinds, location devices, and machinebound PLC’s. However, this all comes with a limited degree of standardisation. Further, basic mechanisms such as remote updating, version management, and health checking is rarely present.Besides this, the maintenance of all the on-board technology is typically a problem. Regular calibration of sensors (e.g. weighing sensors) is required to make sure the information coming from the machine is accurate and reliable. Yet, this is not yet standard (maintenance) practice because the actual use of the information is limited, defying the purpose of proper maintenance. 3. CONNECTED TO ALL STAFF As important as connectivity to the physical assets is connectivity to the human assets in the field, as well as real-time access of operators to central information. Both to ensure people are kept out of harm’s way (think of location detection, or proximity sensors), as well as information in real-time to perform actions efficiently (updated loading list, reefer (un)plugging list, etcetera) is rarely installed. Instead people are sent around with information on paper, and record information on paper to be processed later. This in a time when almost everything can be accessed through smartphones. Here, we could even think one step further into augmented reality (eventually through technology like the Google Glass), so that operators get immediate visual information while keeping their hands free. One could for instance think of twistlock information: should the container in the spreader be equipped with cones or not? 4. REAL-TIME, HOLISTIC PLANNING, CONTROL AND OPTIMIZATION A terminal consists of a series of interlinked, highly variable processes, hence dynamic, real-time planning and control is essential to be efficient. There are all kind of planning, scheduling and dispatching tools in the market to assist and provide decision-making support, or even automation. But there is great resistance – especially from operators – to use these tools. On the one hand there is a degree of job protection behind this, but also lack of insight in the benefits. The efficiency gain does not come from some reductions in planning and dispatching staff, but by operating in a better wayoutside. Here the real expense is being spent in machines, fuel and labour. 5. REAL-TIME MEASURING OF KPI’S In order to improve, one needs to know what’s going on. Hence, the performance of the operation should be measured continuously, and to a great level of detail. Only then, can one really determine what explains the peaks and troughs of performance. Simply measuring STS productivity, for instance, does not provide sufficient insight. Also, the circumstances affecting the performance must be gathered so that a complete picture results. Factors such as yard occupancy, gate volume, driving distances, and thenumber of unproductive moves should be monitored.The measurement should preferably take place in an automated way. Therefore, not MS-Excel spreadsheets filled in during or after the operation, but gathering at the source. The key questions are: What are the assets doing, how fast are they moving, how far are they driving? Finally, all information related to operational disturbances needs to be gathered, as this is the third explaining factor for performance. 6. CONTINUOUS ANALYSIS OF PERFORMANCE (KPI’S) When all this measurement is in order, there is a solid basis for analysis, and, most vitally, acting upon said analysis. Just gathering data serves no purpose. The data needs to be turned into insight, and insight into knowledge, so that the actual control improves. Equipment deployment, yard strategy and vessel planning are key ‘customers’ of proper operational analysis.This means that the lessons learned need to be fed back to the staff planning and controlling the operation. This will have substantial effect on the variable cost. The cycle of measuring, analysis, and action should always be continuous so that the learning cycle also reacts to changes. Changes in volume, dwell times, truck patterns, or just the arrival of a new vessel service are likely to require adjusting operational strategies.In this process, it is also key to make record of implemented changes. Most changes in strategy will only have effect over a longer period of time (typically more weeks than days). At the same time, there will be cyclic, independent influencing factors such as the seasonal patterns. These effects must be taken into account when analysing the result of change. 7. TRAINING AND CERTIFICATION OF STAFF In prior articles in The Journal of Ports and Terminals, we have written about the importance of training. We have seen very significant effects in improved planning capabilities after training. Having a serious training programme, first for on-boarding,and later to further enhance operating skills is a key factor in operational performance.Where most operators are having or setting up training programmes, certification of the control room staff is still rare. Which is surprising given the large impact this staff has on operational success. Our findings across more than 25 terminals (>250 planners) show the difference between worst and best planners by up to 50% (measured in resulting berth productivity). Testing planners against a calibrated scenario – for instance, in a near-to-live virtual terminal (see REF) – is one possible way to get people in the right position. 8. CAPABILITY TO LEARN FROM THE PAST One of the hype words often mentioned is artificial intelligence. Fundamentally, the ideas behind it are really new, but the combination of large amounts of data being available, and cheap (cloud-based) computing power, brings the ability to quickly recognize patters, rendering it much more useful. Still, computers have a tough time recognising context in data, but with help of experienced operational analysists, this gap can be bridged. The potential is large, as the container supply chain is highly repetitive, hence predictable. Where today, the terminal has almost zero information to use to allocate the right spot in the yard, learning about dwell time patterns, pick-up patterns, and roll-over patterns, may reduce the amount of unproductive moves by factors. Many terminals move a container more than four times, where an ‘ideal’ operation would do it with just two moves. One can imagine how many cost savings would be achieved. 9. TERMINAL DEVELOPMENT BASED ON ‘MASTER PLAN’ When we look at how terminals have come about, we recognize many look like patchwork. Every expansion is planned when required, without looking at the bigger picture. Buildings in the most inconvenient places, height differences, light poles, roads with illogical routing and so forth, are quite common situations. Of course, not everything can be taken into account, but we can go significantly further in looking ahead and making a robust masterplan, that withstands a change of circumstances to a large extent. Cargo flows, ship sizes, hinterland transportation patters, and dwell times are all subject to change, yet these can be addressed during the master planning. This means expansions become consecutive steps of the execution of a grand plan, rather than the isolated exercises typically leading to unwanted situations. Modelling can greatly help in these assessments, and also act as a source of reference for future decision-making. Even the consequences of changing parameters can be easily analysed and quantified (seeREF). 10. A SOLID CYBERSECURITY LAYER IN PLACE Last but not least, a terminal today needs to have its cybersecurity in order. There isa large degree of data exchange with many third parties. Such a scenario means the risk of receiving malware, viruses or alike, or spreading it to others, is quite large. Besides, the fact that containers contain high-value goods makes them a highly desirable target for cybercriminals. Finding the right container, filled with expensive electronics or cigarettes, by hacking in the system, and setting up an illegal delivery, is not a hypothetical scenario. This means that cyber security must be part of the daily IT process. Making sure that all protection layers are up-to-date, and making sure that staff is aware of the risks. As people are always the weakest link, continuous back-ups are essential, so that recovery in case of an attack is quickly feasible. CONCLUSIONA quick inventory we undertook at a range of terminals in two months in late 2018 revealed that from the ten prerequisites above, most terminals have not fulfilled most of the ten, and if they have they are to a limited extent. These are results in a time where the technology to help is available. None of the points mentioned will require large investments, nor be too complex to implement. However, it requires ability and willingness to change. In many cases, this only arises when there is a serious problem (for instance after a cyberattack causing substantial damage, people are willing to implement strict security procedures), or pressure from the outside (e.g. from local authorities) to implement these productivity, and efficiency enhancing measures.So, in closing, we still have a long way to go. Find the technical paper "10 Pre-requisites for smart terminals " - published in PTI magazine edition 81 - here

Publication
20 years of high-definition simulation in the port industry
November 2018

More than 20 years of operations, 1,000 projects across 250-plus terminals, over 500 man-years spent on simulation. Sound crazy? This the story so far for TBA, which is improving the quality of decision-making in ports and terminals. Multi-million projects require a firm foundation of decisionmaking, which solid models can provide. At the time we started our simulation practice, a large majority of terminals were designed using spreadsheets. It goes without saying that those analyses do not consider the process variations that take place in any container terminal operation. Read the entire article which has been published in Port Technology International magazine here.

Publication
Increase your RTG productivity by 10% within a ROI in less than 6 months
June 2018

Dr. Yvo Saanen, TBA Group, Delft, the Netherlands Most container terminals world-wide are equipped with RTGs and terminal trucks. Imagine you are responsible for one of these terminals these days. Volumes are growing as a result of global trade growth, productivity demands are also going through the roof due to increased vessel and call sizes, and at the same time, there is the pressure to electrify to reduce the carbon footprint of the typically diesel-powered equipment fleet. Sounds familiar? What if there is a way to significantly reduce the investment ahead? A way that has proven itself in one ultra-large container terminal, with a mixed (diesel, hybrid and fully electric) fleet of 100+ RTG’s? Let’s take an example Let’s assume you are currently handling some 1.5M TEUs annually, mostly gateway volume. Your terminal is equipped with 10 STS and approximately 30 RTGs. Now you are planning the CAPEX to support the expected growth in volume to 2.0M TEU.You have factored that an additional 10 machines are required, which will heb require a heavy CAPEX of some 15 Million USD. What if there is an alternative, which would enable you just to purchase 6 RTGs, instead of 10? At the same time, reducing OPEX by 700K –1.2M USD / year? ROI of less than 6 months This alternative is there. Readily available for any terminal running the NAVIS N4 TOS. It is called Yard Crane Scheduler, and provides fully automated RTG scheduling and dispatching. It has proven to increase RTG productivity by a mere 10%, still with more potential. The ROI of YCS is less than 6 months for any terminal over 1M TEU. Saving OPEX,reducing the carbon footprint, and creating a more predictable, consistent operation. Improved waterside productivity, better truck turn times towards the gate. No change to TOS needed YCS can be implemented without any changes to the TOS, provides a high degree of automation and enables the terminal management to move towards pro-active rather than re-active operational control.

Publication
Turning data into knowledge: Bridging the gap in the terminal industry
March 2018

Dr Yvo Saanen & Sander van Dijk, TBA Group, Delft, Netherlands Using data to drive operational improvements is a common industry practise, and the port logistics industry is no exception. However, collecting, analyzing and interpreting data to improve operations is not always as straightforward as it might seem. The fact is that the process poses a continuous challenge. The usage of data to improve your operation requires analytical skills and, in many cases, expert knowledge to fully comprehend the meaning of or draw conclusions about the data.UNDERSTANDING DATAWhile the collection of good data is still an advanced exercise, software is a great source for data, and automatic logging allows significant data creation. Since many terminals use advanced software in their operations, this is a great opportunity for data analysis. For container terminals this means they are able to record the activity and location of all equipment over time. It is, for example, possible to count the number of containers handled by terminal equipment or the duration of a cycle. After collecting the data, the main challenge is how to analyze the data and transform it into ‘knowledge’ or insights about the operation.SOFTWARE AS SOURCE FOR DATA COLLECTIONTo analyze the data available in the terminal, we need to determine which data is relevant and need to understand what the underlying processes are. At first glance, some data may seem easy to understand. Counting the number of containers handled by a quay crane (QC) in a certain period is easy to measure – we see how many containers per hour the crane has handled, for example. However, the question remains how this information must be interpreted. It does not directly provide any relevant insights about the operation, as we do not know what the scope is. In addition to counting the number of containers, the number of twin moves – or whether the QC was loading or discharging – has a big influence on the performance of a QC. Therefore, many terminals struggle with making profitable changes to their operation based on their collected data.To make a step forward in turning data into knowledge, both data analysis and data interpretation are needed, as both are necessary to create relevant insights. We need comprehensive information to understand the operation at the terminal, and while using data to improve operations has great potential, it is worthless if the data cannot be turned into knowledge. The generated data must therefore be analyzed to transform it into quantitative measurements. Combining different data sets will highlight import parts of the operation. However, this is only a first step, next we need to interpret the data, and for that we need to understand the data itself, as well as the complementary aspects of the operation.TRANSFORMING DATA INTO KPIsA proven tool for process improvement is the use of Key Performance Indicators (KPIs). These KPIs are an extension of data; a summary, or the highlights of the underlying data. KPI’s combine different data values into measurable quantities that are easier to understand. An example of such a KPI is the quay crane productivity. It combines the number of containers handled by the crane with respect to its working time. KPI productivity provides us information about containers per hour which is measurable and quantifiable. These characteristics of KPIs are important, because it makes them comparable and thereby understandable. Many different and even less straightforward KPIs can be calculated, such as the average time per move the quay crane is waiting for a terminal truck or straddle carrier. KPIs are well-defined targets that transform data into measurable goals.These KPIs give relevant information about the operation, such as: How many containers per hour are lifted by the quay cranes? How many of the vessel moves are twin moves or which percentage is load or discharge? Which percentage of their working time do terminal trucks spend waiting in the yard? How was work distributed among RMG modules? Information (data which has been processed into comprehensible material) is a logical step towards knowledge. While KPIs do provide information about operations, unfortunately they do not provide knowledge about it. Hence, deeper understanding of the processes is needed. Combining multiple KPIs with an understanding of the operation gives tangible insights about the operation. Knowledge includes information about the current terminal performance, as well as the knowhow to adapt to the operation accordingly.While the actual calculation of KPIs is usually a reasonably simple analytical process (and one that can even be automated) the interpretation of the data, and subsequent generation of relevant operational insights, requires problem-solving skills and expert knowledge about the operation in question. There is not one recipe to solve a problem, each realisation of KPIs needs an understanding of its own. Therefore, completing the step from data to knowledge is not easy to automate. Expert knowledge (the knowhow and experience of an expert) is an essential attribute to this.The above visual representation is an example of how KPIs can be transformed into knowledge for this specific operation. This graph shows the completion times of moves for one Quay Crane. The green arrow represents the steadily completing load moves of the QC. Until the point that it must wait for the load of AS005. The yellow part of the bar indicates that the ASC is late on this job execution. At the bottom part of the graph, it becomes visible that AS005 was doing a ‘Yard Shift’ in advance of the load move. It can be concluded that digging out the pile to collect the correct containers was the direct cause of delay at the QC. This real-life example shows how combining job completion times of the QC, ASC and AGV give insight in the cause of a QC delay.DATA AND KNOWLEDGE: BRIDGING THE GAPTo really understand what is going on we need to take a look at several KPIs simultaneously. If we want to understand how well the QCs have performed on a vessel, we need to know (a.o.): The QC productivity as well as the load percentage The twin percentage The average bay size The yard occupancy The average pile height/the number of reefers To compare the QC productivity of one vessel to another, we need many KPIs and we need to understand how they influence each other. The key aspect for this is benchmarks. They can be used to qualify the different KPIs to determine which facets of the operation are ‘good’ or ‘bad’. Benchmarks can be created by using historical data of the terminal or by using the data from other terminals that have similar operational processes. KPIs are useful when these are compared to benchmarks due to their measurable property. A well-defined KPI can be determined for different terminals even if their underlying data is different.To bridge the gap from data to knowledge, we need to use KPIs as an extension to the data. Well defined calculations are needed to transform data to measurable quantities. By combining different KPIs, valuable insight and/or knowledge about operations can be acquired. To make this final step from KPIs to knowledge, benchmark values and analytic skills of an expert are of utmost importance. By using this approach, data analysis can help to continuously improve operations in the terminal industry.This article has been published in the Spring edition magazine of Port Technology International. Read the article as pdf file here.

Publication
Using intelligent TOS plugins to increase terminal performance
January 2018

As volumes have found their way up again,and additional terminal capacity is not easily realised, terminals return to seeking improvements in their internal processes. Based on our experience, which covers over 50 terminals where we assisted in performance improvement programs, it is possible to make substantial performance gains for internal processes. This is also recognised by the terminals themselves. A recent survey by Navis indicates that 76% of the respondents put process improvement as a ‘number one priority’ for terminal operations.Read the full article here

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

On 4th of December in Las Vegas, TBA Group participated in the Winter Simulation Conference 2017 (WSC 2017) and gave a presentation on “Using Simulation and Emulation Throughout the Life Cycle of a Container Terminal”. Csaba A. Boer & Yvo A. Saanen, TBA Group, Delft, the Netherlands 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. 1 INTRODUCTION 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. 2 LIFE STAGE 1: TERMINAL DESIGN 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. 3 LIFE STAGE 2: TERMINAL IMPLEMENTATION 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: Real terminal operation vs. CONTROLS emulation. 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. 4 LIFE STAGE 3: TERMINAL OPERATION 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. 5 LIFE STAGE 4: TERMINAL OPTIMIZATION 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: Using emulation for tuning TOS parameters. 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: Application of Plan Validation by vessel planners. 6 FUTURE RESEARCH 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. 7 CONCLUSION 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. Read the article as pdf here ACKNOWLEDGMENTS We would like to thank our colleagues for their support in developing and testing CONTROLS and plan validation components. REFERENCES 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 http://hdl.handle.net/1765/6925 [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.

Publication
How can simulations help ports and terminals?
July 2017

News article published in Harbours Review June 2017 by Remmelt Thijs, Senior Project Manager and Dr. Yvo Saanen, Commercial Director and Principal Consultant at TBA.The container industry is dynamic by nature. Due to considerable growth, the competitive situation in and between ports, and the changes in shipping line alliances of recent years, the container market has gained a certain dynamic. This is reflected at container terminals accommodating larger vessels, new combinations of shipping lines and often a step-wise growth. This growth could result in higher utilization of existing sites as well as regular expansion projects and new greenfield development for which simulation modelling can be of value. Click here to read the full article

Publication
Applying new technologies in an existing automated terminal
March 2017

Arjen de Waal & Yvo Saanen, TBA Group, Delft, The Netherlands TBA’s vision is to improve the cost efficiency and productivity of container and bulk terminals world-wide through consultancy and software. We distinguish ourselves by state-of-the-art tools such as simulation and emulation. Our clients include all major container terminal operators worldwide and many local port operators. We have designed several automated container terminals worldwide from layout design, to performance testing by simulation, and to live operations with delivery of software for the robotized machines. As such we have experienced that automated terminals perform very well in a simulated environment, but often perform not so good, when actually going live. This article focuses on improvement measures for automated terminals. Introduction In the world of container terminals there is a conception that fully automated, or robotized, container terminals are performing at low productivity. How can it be that in the simulated world, the designed and tested automated terminals perform very well (above 35 moves per hour under peak circumstances), and not in real life? This question we have asked ourselves, also to critically review our simulation models. In order to do so, we started from one of the existing state-of-the art fully automated facilities, and added latest improvements to the model to see whether the performance could be increased. We used TBA’s own proven container terminal simulation suite to quantify the effects of each adjustment individually. In this article we describe this step-wise improvement approach from an imaginary existing terminal with Dual RMGs and AGVs, as would have been constructed around year 2000. For each step towards a state-of-the-art terminal with Twin-RMGs and Lift-AGVs we show the effect on productivity. We start by briefly describing the different equipment types. RMGs are Rail-Mounted Gantries that are installed on a stack module, the area where containers are stored and exchanged between ships, trucks and trains. Containers from the ships enter the stack module from one side. They are stored for several days in the stack, after which they are delivered to a truck that picks up the container on the other side. Of course, this process can also be supported in reverse order (truck → stack → ship); or containers that were delivered by a ship, are later loaded onto another ship, called transshipment. Dual RMGs are RMGs that can pass each other, because one is larger than the other. Both RMGs are able to work on both ends. Twin RMGs are equally large and cannot pass each other. Each is dedicated to serve one end of the stack module. These cranes require less space than dual RMGs, since they share the same rail track and they are faster. However, they have less flexibility in job selection.AGVs are Automated Guided Vehicles, robotized machines that carry containers and transport them between ships and stack. The AGVs of the start situation cannot take or drop containers. They wait under a quay crane at the ships, or an RMG in the stack until a container is lifted off, or dropped onto them. Lift-AGVs have a platform that can lift, and are able to take or drop containers at so-called racks. This makes them less reliable on other equipment, since they do not need to wait until a crane can serve them directly. They can deliver a container at the rack, and an RMG will take the container when it has time to do so. The RMG can also drop containers at the rack a few minutes before a Lift-AGV needs to pick it up. Racks are only installed at stack modules. The start terminal is suitable to handle approx. 1.3 million containers per year, with 16 double trolley Quay Cranes on 1,500m quay, and a landside peak of 320 containers per hour (this is how many containers are delivered and taken by road trucks in the busiest hours). The yard consists of 35 stack modules with dual RMGs. The containers in the stack can be stored on piles of 4 containers high. Waterside transport is done by AGVs.This investigation focuses on average quay crane productivity that can be achieved in the peak hours. The simulation results of all steps including the start situation are shown in Figure 2. The different steps are represented in the “improvement tree” shown in Figure 1.Figure 1: Improvement tree. Step 1: Replace dual RMGs by twin RMGs Twin RMGs cannot pass each other, but have a higher gantry speed (4.0 m/s instead of 3.5 m/s). Furthermore, the width of a 10 wide twin-RMG is less than for a cross-over RMG, hence in the same footprint 6 additional stacks can be realized: +19% storage capacity. Results The increase in quay crane performance equals 0.5 to 1.5 bx/hr, a quite limited result. The truck service times drastically decrease when we use twin-RMGs, with one RMG dedicated to the landside. Trucks are processed 6 minutes faster on average in the “Step 1” scenario with twin RMGs. Step 2: Increasing terminal throughput In step 1 we already saw an increase in storage capacity. In this step we also increased the maximum stacking height from 4 to 5. The overall throughput increase equals 119% * 125% = 48%. This means that the yearly throughput can be 1.9 million containers. The twin-RMGs should be able to process a larger volume because they are faster (4 m/s instead of 3.5 m/s) and there are more cranes (six extra modules: 82 instead of 70 RMGs). The peak landside volume increases to 470 boxes per hour. If the 16 quay cranes should be able to achieve 48% higher peak throughput as well, the cranes must perform 40 to 42 bx/hr. Results The impact of a higher stack and higher volume can mainly be observed on the landside: the RMGs have to do more digging for containers, and hence the service time of trucks increases. The required peak volume can be processed though. Step 3: Replacing AGVs by Lift-AGVs AGVs require a “hand-shake” interchange with RMGs at the yard. This causes waiting times for both RMGs and AGVs, because for almost every move one of them has to wait for the other to arrive. This hand- shake can be excluded from the process by using Lift- AGVs instead of AGVs. In this step we use Lift-AGVs with – besides the lifting ability – the same specs  as the (10 years old) AGVs. The racks require more space than interchange positions that are used for AGVs, hence the total number of interchange slots at the stack is reduced. Lift-AGVs need time to lift and lower their platform, which requires additional handling time. Results The quay crane performance increases with 3 to 3.5 bx/hr for any number of vehicles per crane. The reduced waiting times largely outweigh the longer handling times and fewer transfer points. The impact can be seen in the time per container move of the Lift-AGV versus AGV. Whereas AGVs stand still at the stack interchange for 2.6 minutes per cycle (waiting for RMG and the actual placement or removal of the container), Lift-AGVs only spend0.3 minutes per container at the rack, reducing the total handling time of one container from more than 11, to 10 minutes. Step 4: Using state-of-the-art Lift-AGVs In the previous step, we used year-2000 AGV technical specs for the Lift-AGVs. Now we increase the driving speeds according to latest standards, meaning increasing top speeds and acceleration values. The new Lift-AGVs can drive faster straight, faster in curves, and accelerate faster. This should cause shorter driving times per box, and hence increased QC productivity. Results The quay crane productivity increases significantly again: with 4 to 5 bx/hr. The quay crane productivity increase is caused by the huge reduction in Lift-AGV driving times per box: from 6.5 to 5 minutes. The Lift-AGVs generally arrive at the quay cranes earlier. Occasionally they have to wait before they can be served at the quay cranes now, because they are too early. Step 5A: More opportunity moves Glossary: handling opportunity moves is the handling of multiple containers in one order. E.g. two 20ft containers can be transported by one Lift- AGV because the platform is large enough for 45ft, and the quay crane can also lift two 20ft containers off the Lift-AGV. This is called twin-lift.In the original situation it was not beneficial to handle more than 10% of the containers with twin-lift moves at the quay cranes because of yard handling limitations. After step 4, both the waterside and the landside RMG in the stack modules have idle time. To make use of this spare time, we increased the twin-lift percentage at the quay cranes to 30%. We assume most 20ft containers could be twin-lifted when planned right.The quay cranes can now handle more containers per cycle (per move). If the container supply can   be increased the productivity will go up. The RMGs need to supply more containers faster, and the Lift- AGVs should transport and deliver them more just- in-time. Results The quay crane productivity is increased with about 3 bx/hr. The quay crane performance increase is only possible because the RMGs were able to supply more containers to the interchange racks (and take more containers from them). Each stack module was able to process one additional vessel job per hour. The increase in productive moves causes the time spent on productive moves to go up from 62% to 66%. Idle percentage decreased from 19% to 16%. The remaining idle time indicates there is still room for improvement. Step 5B: Faster quay cranes (and NO increased twin percentage) The (1990-2000) quay cranes in the original scenario that have been used up to now, are relatively slow. The landside hoist has an average cycle time of 99 seconds. With modern cranes cycle times of 63 seconds should be possible. The kinematics of the cranes in the model have been adjusted in step 5B to be able to make cycles of 63 seconds. Results The quay crane productivity increases by 5 to 7 bx/ hr. Step 6: All adjustments combined The final step is a comparison between the start scenario and all adjustments described in the previous steps. We will see the overall impact on performance levels.Quay crane productivity has increased with 17.2 bx/hr in the experiments with 5 vehicles per QC, or 68%! Remember that in step 2, with the increased throughput, we already stated that QC productivity needed to go up to between 40 and 42 bx/hr and this goal has been achieved.The increased quay crane productivity is only possible with more efficient Lift-AGVs and RMGs. The lift-AGVs in the final scenario only need 7 minutes to complete one container move, while originally the AGVs needed over 11 minutes.With the increased waterside productivities the stress on the yard has increased as well. The terminal throughput and according gate volume cause additional moves in the yard. The gate report shows that the RMGs are able to cope with this increased demand, because 460 truck moves have been handled and the truck service times are still acceptable.The increased demand on the yard is supported by the two RMGs in each stack module, which together handle 18 vessel boxes and 12 gate boxes per hour, about 50% more than the original scenario. Conclusions In this article we described a step-by-step approach to improve large automated terminals to state-of- the-art terminals and what each step can bring. Besides faster truck and vessel handling, the described adjustments lead to a throughput increase of almost 50%. Adjusting existing terminals with the described changes is a costly and time-consuming operation; this may be a bridge too far. However, this study shows how important it can be to build new terminals according to the latest technology, because the performance is highly dependent on this.Furthermore, the study proves that although the results of simulations seem to be too high compared to current experience, the steps from today’s state- of-the-art – which can be validly represented in the same type of simulation model – to the future’s state-of-the-art are concise and largely doable.  This provides a solid and prosperous outlook for tomorrow’s fully automated terminals! This article has been published in Sector Magazine  Click here to read the article as a pdf file

Publication
Merry Xmas and Happy 2017
December 2016

TBA wishes you a Merry Xmas and a Happy New Year.

Publication
Entering the Maritime Sector / Logistics 4.0 Revisited
November 2016

In a special edition of The Journal of Ports and Terminals (Top 30 Papers 2014-2016), an article on brownfield automation by Yvo Saanen that was originally published in Edition 69 – The Mega-Ship Issue has been updated. Find a pdf version of the same article here: Brownfield Automation    

Publication
TBA in Archis Volume #49: Hello World!
September 2016

Archis is an experimental think tank devoted to the process of real-time spatial and cultural reflexivity and action. One of their initiatives is publishing the Volume magazine. In which various editorial concepts and publishing formats of have been realized over the years. Archis Volume #49: Hello World! includes an article on the recent developments on Maasvlakte II in which TBA has played and is still playing its role.   

Publication
AGV Versus Lift AGV Versus ALV: a qualitative and quantative comparison
August 2016

Dr. Yvo Saanen, TBA Group, Delft, the Netherlands The question introduced It is a recurring question in the planning of automated terminals: what is the ‘best’ mode of horizontal transportation? For many, horizontal transportation is seen as one of the most complex components of terminal robotisation, and this is right in my view. The horizontal transportation system connects two (more expensive) pieces of equipment (the stacking system and the quay cranes), and therefore always fulfils the role as a buffer. Furthermore, it consists of many vehicles which are dynamically interacting in a space that is kept as tight as possible. After all, apron space is expensive real estate. The question we aim to answer in this article is: What is the most cost effective automated transportation system, with the today available technology? Before we do that, we need to discuss the accusation of a possible professional bias we at TBA may have. It is true that since the late nineties, we have carried out many studies with the emphasis on automated guided vehicles (AGVs) of various kinds. This work led to the implementation of the Lift-AGV at the new terminals in Rotterdam. In those studies, however, it was always the Automated Lift Vehicle (ALV) – also addressed as the automated shuttle carrier, or automated sprinter - was part of the comparison. The information with regard to the AGVs mostly came from former Gottwald, nowadays Terex Port Solutions (TPS), whereas most information with regard to the ALV came from Kalmar (Cargotec). The analyses were based on detailed time and motion studies of existing automated systems, for instance at CTA (Hamburg), and later at Patrick’s in Brisbane and Euromax in Rotterdam. In the study carried out for APMT Maasvlakte 2, an extensive peer review and validation of our simulation work has been done by an expert third party. This validation study did not reveal any irregularities or bias towards any of the systems. Finally, during the implementation process of the terminals in Rotterdam, a performance comparison between the real AGV system and the simulation was carried out. This test – highly recommendable by the way for any operator implementing an automated system – had a duration of at least 4 hours (even 8 at Rotterdam World Gateway) and did not deviate more than 5% from the simulation that determined the number of vehicles required to achieve the target performance. The result in both cases was more than satisfactory: the deviations were well within the tolerances, which means that our model of Lift-AGVs and its control system is very close to reality. For the ALV system this is lesser the case, hence we had to design the control logic ourselves. Meanwhile, TPS also developed and tested an ALV, of which the specifications could be used. The remainder of this article focuses on the comparison itself. First, we discuss the principle pros and cons of each of the systems (AGV, Lift-AGV and ALV) in a combined qualitative and quantitative way. Subsequently, we discuss some quantitative results from a recent comparison study. Finally, we conclude the picture with a cost comparison. Qualitative comparison In the qualitative comparison, we focus on a number of different aspects: Apron size Wheel load Energy consumption Maintenance Interaction with the QC Interaction with the ARMG Travel performance (speed, acceleration, deceleration) Technical complexity (breakdown risk, recovery, flexibility) Apron size The apron size is important as it determines how much real estate is required for a certain terminal throughput. In the cross sections below, two possible high density and high performance layouts are shown. There is little difference between the three systems (see the layouts of ALV and AGV in Figure 1). The fact that we chose to show layouts with four highways with ALVs and six with AGVs, is not because the fifth and sixth highways do not benefit the ALV system; they do. However, we reckon it takes too much (expensive) space, hence the performance impact (limited to 1-2 bx/h) we take for granted. Figure 1: A typical cross section of a high density, high performance ALV apron In the back reach of the quay crane four transfer lanes can be installed. All transfer lanes are also used as drive through lanes which means that picking up or dropping a container with an ALV occupies a drive through lane. Due to the driving patterns of ALV neighbouring lanes can be affected when entering transfer points. In contrast to this, in the AGV concept transfer lanes and drive through lanes are separated and can be used independently. In a typical back reach, four transfer lanes and two to three drive through lanes can be realised.Some argue that the ‘parallel buffer’ (the space where vehicles can wait until approaching the lanes in the back reach of the quay crane) is not required in case of ALVs. We completely disagree with that solution, when it concerns large terminals that require high performance. It may work when there are only three to four cranes at max on a vessel, but as soon as it exceeds that, a waiting area is required. More so because the ALV cannot always enter in case the quay crane (QC) is accessing the interchange zone. Actually, the AGV can access the transfer zones more frequently, as it can wait under the QC, where the ALV cannot. Figure 2: A typical cross section of a high density, high performance lift AGV apron Wheel load The deadweight of the vehicle, the maximum pay load and the number of wheels determine the maximum wheel loads, which is an important factor in the pavement design. In the below table, the static values (dynamic influences for ALV will be higher due to higher center of gravity) for various types of vehicles are shown:Figure 3: Vehicle weights and wheel pressures Two things can be seen in Figure 3: the wheel loads of an AGV and ALV are almost the same, where the maximum pay load of the ALV is 20 tonnes (t) less. This is an issue with twin containers above 50t, which is typically 5-10% of the twin pairs. They have to be delivered in singles, reducing the productivity of the ALV substantially. This can already be observed in many straddle facilities that have twin-lift QCs, and single lift straddles: during twin-lift operation, the QC is waiting for the straddles, despite the – in the end – higher QC productivity (as it lifts two containers per cycle). Energy consumption Fuel (or energy) consumption is an important cost factor when a machine operator is taken out of the equation. Obviously, a heavier machine consumes more fuel, especially in an operation where there is a lot of starting and stopping, as acceleration consumes most power. In addition, there is the need for lifting (Lift-AGV) and hoisting (ALV) that requires additional energy. Apart from the demand, there is the possibility to run the machines completely by battery; increasing the energy efficiency quite dramatically and resulting in a real zero-emission when purchasing green energy. In a linear fashion this also affects the CO2 emissions, which are two (diesel-electric) to ten (batteryelectric) times less between a Battery AGV and a diesel electric ALV. The Lift-AGV hovers somewhere in the middle, being heavier, and having to lift the containers at the interchange with the stacking crane (ARMG). Figure 4: Fuel consumption and emission data (diesel at 1 Euro per liter, and energy at 0.15 Euro per kWh) Maintenance Maintenance practices worldwide vary tremendously and solid comparative data is hard to get. Not least because maintenance cost are measured quite differently. Typically, one should consider the labour hours involved, the spare parts required, as well as the wearing materials such as tyres and lubricants. In general, one can say that the less moving parts, the less maintenance, and as a consequence, the battery AGV is very low on maintenance, followed by the Lift-AGV. Most maintenance – and easily five times as much per running hour – is the ALV. A hoisting mechanism, a spreader that locks and unlocks all the time, a heavier vehicle, a powerful diesel drivetrain and difficult accessibility of components: these are all factors that make it maintenance intensive. If we would have to rank them, the following table results: Interaction with the QC An area of much confusion and misunderstanding is the interaction with the QC. It is obvious to everyone that the AGV and Lift-AGV have a linked interchange with the crane, where ALV has an unlinked interchange with the crane. This inevitably means that the QC should never wait for the AGV, and in most cases the AGV has to wait for the crane (as it is supposed to be). Most operators think that the ALV never has to wait for the crane or vice versa, which is a misconception. When the QC is going to be at the transfer point, the ALV cannot always enter (it depends on the transfer point arrangement, but the access is certainly limited). The other way around is also true: in some cases the QC cannot enter because the ALV is at the transfer area. As a result, both QC and ALV lose time during this interchange process. Moreover, the picking up and dropping off of the container takes a substantial amount of time. Whereas crane and AGV will find each other blindly, the ALV has to search for the container, which is inherently slow (in practice we measured here interchange times of 60-120s, whereas the handshake crane-AGV typically takes in the range of 15-30s). Another complicating factor is access to the QC. As vessels are getting wider, the crane density on a vessel is increasing (sometimes to up to six to eight cranes). This leads to large clusters where access is limited (see Figure 5). AGVs are 3 metres wide, ALVs just over 5 metres, requiring lanes of 4 metres and 7 metres wide to drive on, respectively. Furthermore, the ALV needs to align before it drives over the container, where the AGV is not slowed down by containers standing on the ground. Driving over other containers (standing on transfer points of neighbouring cranes) seems so convenient, but takes place at very low speed (typically less than 5 km/h), blocking access of the QC to those transfer zones. Figure 5: Access with AGVs to a dense cluster of 5 QCs. As a consequence, we observe waiting times and the need for queueing also for ALVs, before entering the transfer zones, which requires space. This becomes worse in case a QC is operating in tandem 40, or quad 20, mode. Since ALVs cannot access two adjacent transfer lanes simultaneously (due to the limited spacing a dual hoist or tandem spreader can achieve between containers), the ALVs have to pick-up the containers individually. As the duration of two consecutive pick-up moves exceeds the cycle duration of the QC, the only way is to use at least four interchange lanes. As can be seen in above figure, this becomes quite complicated, if not impossible in case of large clusters. On the contrary, with AGVs side by side access is quite easily realised, especially because the solutions existing today, already cater for two adjacent transfer lanes per QC. A last remark plays a role in areas with swell: the vessel may move along the quay, causing the transfer point to move (up to 50 centimetres left and right). If a container is already placed by the ALV, the QC needs to gantry (at very low speed) to fetch the misplaced container, which will considerably reduce the crane productivity. AGVs, waiting for their turn, will follow the crane automatically, as such not influencing the STS productivity. Interaction with the ARMG At the stacking crane (automated rail mounted gantry, or ARMG), the decoupling (interchange) is less cumbersome, especially for the ALV. The interchange zone consists of nicely aligned lanes, typically offering up to 16/20 TGS space, even usable two high. The interference between ARMG and ALV is less (due to the lower productivity of the ARMG compared to the QC: an ARMG accesses the interchange zone 10-15 times per hour, the QC three times more), and can be controlled by the ECS in an easy way, as both are serving the QC. Here we can then observe the largest benefit of ALV over AGV and to a lesser degree over the Lift-AGV. The Lift-AGV also allows for decoupling through the rack, but this buffer has less capacity, and there are still containers (such as tank containers) that cannot be transferred through the rack. When we analyse the duration of a typical AGV cycle, we see that the AGV waits at the ARMG transfer point to be served in the range of 35-45% (of the entire cycle) under peak conditions (meaning also the ARMG’s are under pressure). Lift-AGVs and ALVs only spend approximately 5% at the ARMG transfer point, which immediately explains the benefit of Lift-AGVs over AGVs. Figure 6: Lift AGVs entering the racks If we compare the size of the ARMG interchange, we also see clear differences. In case of a nine wide stack (a typical average value), we see five AGV transfer lanes, four racks plus one direct interchange lane, or four independent transfer lanes for ALVs which are four TEU deep. The total decoupling possibilities hence range from 0 (AGV), to eight TEU (Lift-AGV) to 16 TEU (ALV). The larger buffer of the ALVs has another benefit, as has the rack interchange to a lesser extent: it improves peak productivity of theARMG’s by 10-15%, and by 5-10% in case of the Lift-AGV. So for a proper comparison between transportation systems, this is also a factor. Travel performance (speed, acceleration and deceleration) At equal waterside productivity, every horizontal transportation system has to deliver the same number of movements per hour. This means that the traffic – except for the space occupation of an individual vehicle – is equal as well, regardless of the amount of vehicles in operation. More important is the actual space consumption of an individual vehicle while driving. This is in the first place determined by the size of the vehicle, but also by the speed and the achievable acceleration/deceleration. Figure 7: AGVs waiting for each other Automated vehicles drive according to the ‘brick-wall’ concept, reserving space ahead of them equal to their braking distance extended with safety distance needed to compensate for reaction time. So the faster they drive, the more space is being reserved (with increases quadratically with speed increase). The actual deceleration helps to decrease the space consumption. This is one of the reasons why faster driving does not necessarily result in a higher vehicle productivity. Moreover, the speed in curves is also limited, and the vehicles need to decelerate to this lower speed before entering the curve – as such posing a blockage to succeeding vehicles on thesame path. Compare it to normal traffic: if you follow a car that has to take a turn, it slows down before doing so, causing a ripple effect behind him. Figure 8: Kinematics of vehicle types (Source: TPS) Summary pro’s and con’s Within the preceding sections we discussed various aspects of the options for automated horizontal transportation. In summary, we have listed the system, as well as a benchmark in the form of manual shuttle carriers (see Figure 10). Performance and cost comparison A single performance comparison between the systems in question cannot be made. Various terminals pose different circumstances, and therefore different results. Especially the type of QCs, the number of ARMG’s in relation to the number of QCs, as well as the overall targeted performance level determine to a great extend how large the fleet of vehicles needs to be to achieve the targeted performance levels. Figure 9: Performance and cost comparison (note: labour @50 Euro / h, 1.5 men per machine hour, fuel at 1 Euro / l, electricity at 0.15 Euro / kWh).However, if we have to provide a rule of thumb to compare the system, comparing results from at least 15 different terminal simulations across the world, the following ratio results (note that prices may vary based on commercial conditions; they should be treated as indicative): Figure 10: Overview of qualitative KPI's;(here green = best, orange = middle, and red = worst) In Figure 9, we see that the most productive vehicle is the manual shuttle carrier, which is proven in several highly productive ARMG-shuttle carrier operations. The ALV, due to restrictions in traffic, and at the QC, performs significantly less well, hence to achieve the same productivity level, more vehicles are required. The lack of decoupling of the Lift-AGV, requires an additional 0.5 vehicle per QC, despite other advantages in traffic compared to the ALV. The AGV system is least productive (per vehicle), mainly due to the coupling at ARMG and QC, which costs about 50% of its theoretical performance.The picture changes however when we combine the performance figures with the financials. We decided to quantify this as a CAPEX per QC and a yearly OPEX per QC (for the vehicle system). Here we can observe that in a developed country (with high labour costs, here assumed at 50 Euro per hour), the manned system is much more expensive than the automated systems. Already within the first year, the additional CAPEX for any of the automated systems is earned back. This leaves us with the comparison between the automated systems: here the lowest CAPEX and OPEX are achieved by the battery Lift-AGV, not in the least because of the much lower OPEX (the benefit of the fully electric drive and hence lesser maintenance, as well as the energy consumption being much lower) outperformance both the battery AGV and the ALV. Conclusion In our view, momentarily the battery driven Lift-AGV provides the best value for money and can present zero-emission at reasonable investments. The attractive performance of manual shuttle carriers in some terminals is no guarantee that an ALV will show the same high productivity. As can be seen from our simulations, there is a substantial decrease in vehicle performance to be expected when modifying manual shuttle carrier system into an automated ALV system.From a total cost of ownership point of view the Lift-AGV may prove to be he most attractive concept. However some operators prefer simplicity and lower infrastructural investments that an AGV brings. The somewhat larger fleet of vehicles (in an AGV system) has theadvantage of less risk from breakdowns and the replacement of vehicles (at the end of their lifetime) will come much later in time. After all, ECT, CTA and Euromax are proving to be very successful terminals, with reliably high performance levels. This article has been published in Port Technology Magazine edition number 70.

Publication
How can simulations help ports and terminals?
June 2016

Remmelt Thijs and Dr. Yvo Saanen, TBA Group, Delft, the Netherlands The container industry is dynamic by nature. Due to considerable growth, the competitive situation in and between ports, and the changes in shipping line alliances of recent years, the container market has gained a certain dynamic, reflected at container terminals accommodating larger vessels, new combinations of shipping lines and often a step-wise growth. However, this growth could result in higher utilization of existing sites as well as regular expansion projects and new greenfield developments.As one can imagine, planning of new sites and places of expansion as well as operations improvement is not that simple and requires answering several important questions about the lay-out, the attainable quay crane productivity, the yard operating strategy, the terminal operating system, and the equipment. We’ll try to show you that it all can be done in an efficient and reliable way. The power of simulations Although simulation is increasingly used in container terminals, it is not as common as for example in the automotive industry, where no significant investment is made without thorough proof by means of simulation. This is not strange at all when using a benchmark that for every Euro spent on simulation, ten are saved.But what exactly is “simulation”? The essence of it is to make a model of the (future) reality within the scope of a few objectives. With this model all kinds of experiments can be performed. Usually, simulation is used to assess the effect of different alternatives, for instance, an operation with straddle carriers versus an operation with rubber-tyred gantry cranes (RTGs) and terminal trucks. However, as we will discuss further on, simulation can be applied for many more uses. In general, a simulation project exists of four steps: First, specification and development of a model, second the validation of a model, then experimentation with a model, and finally analysis of the results. By means of the animation, which visualizes the behaviour of the system, people involved are able to look closer and validate the work of the system. Model terminal operations Some terminals are influenced by shipping alliances and may be under pressure to grow quickly. Therefore, a simulation can be a tool to help assess where bottlenecks could be expected – e.g. at the quay due to larger vessels, the yard due to storage constraints or in the yard or transport equipment to support the targeted service levels. It is very valuable to be able to ana-lyse a what-if-scenario, using suitable tools to answer such questions.Many terminals, for instance, are reconsidering their yard handling system to increase the stack density and therefore increase the throughput capacity of the terminal. As shipping lines are requesting higher service levels, terminal systems need to be designed striving for various – mostly contradictory – objectives. Quay crane productivity has to go up, stack density has to increase, operating costs have to go down, and the landside service has to be improved. In order to create handling systems that comply with those requirements, the use of a simulation approach can be beneficial to separate good from bad solutions and to prioritise improvement measures. Moreover, simulation provides an environment where one can evaluate under varying, but manageable, conditions, e.g. busy and quiet operations, breakdowns, and so forth. In the end, this will result in a more robust plan, solutions that are better thought through, increased software robustness, all leading to a reduction in risk. We aim to assess a solution within the overall system performance and include not only the technical capacity of a component, but also consider the una-voidable inefficiencies when considering a system comprised of several of those components. For instance we consider it much more realistic to consider the dynamics of 20 RMG blocks with twin cranes with its dynamics, than considering the capability of one block with twin cranes and multiply the result by 20. The overall system has in-efficiencies that should be considered and therefore a system view is preferred.The key to supporting these decisions by means of simulation is to model the equipment and operational procedures at a rather detailed level. Many attempts fail to link with reality, because the details that make an operation complicated – for instance the container loading sequence, the grounding rules, and the equipment assignment rules – are left away. We ad-here an approach where those aspects are considered, so that the results from the simulation are similar to the operational data. Close cooperation between a modelling team and terminal operator to arrive at a valid model is essential here.The output of these kinds of models typically consists of productivity numbers of all the equipment (quay cranes, RTGs, and so on), service times (e.g. of hauliers and trains), occupancy rates of equipment, but also the utilization of the stack, and also the equipment’s operating hours. Example view within a simulation model of operations using an automated rail mounted gantry crane (ARMG) and automated guided vehicles (Lift-AGV) Terminal planning of a greenfield site The development of a new container terminal and the expansion of existing ones create new questions to be answered. Which layout, what kind of equipment and how many pieces of that equipment to purchase in order to have lower costs per move, an acceptable investment level, and competitive performance? These are typical questions awaiting a new container terminal’s development team. In the decision making process around these questions, simulation can play a supportive role regarding the dimensions of the terminal (e.g. quay length, stack size), the type of handling system (equipment, operation, and layout), and detailed specifications for Under these external conditions, the main requirements are assessed. This means that we analyse the service level (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). Typically, per configuration, one year of operation is simulated, creating a picture of the service over the year. During the year, the variation in the stack (seasonal effects, peaks during the peak and even hourly peaks due to large discharge calls), the variation in berth occupancy (due to vessel delays, and variation in the call size), and the occupation of quay cranes can be observed, giving a rich pic-ture of the service the terminal provides.For a robust design, several important parameters can be modified to obtain an even richer picture in the terminal planning. A variation in cargo mix, dwell times and vessel mix can be varied to understand the terminal’s requirements for varying circumstances. As important input for the next step (determination of the handling system), the model creates an understanding of the peaks in handling (waterside, but also rail- and truck-side). These peaks are important to determine how much equipment is required to supply the quay cranes with enough containers .The key to supporting these decisions by means of simulation is to model the equipment and operational procedures at a rather detailed level. Many attempts fail to link with reality, because the details that make an operation complicated – for instance the container loading sequence, the grounding rules, and the equipment equipment, layout and terminal operating system’s (TOS) functionality. The first step is to determine the main requirements for the terminal. Here we apply an outside-in approach, taking the container flows that go through the terminal (vessel arrival pattern, rail pattern, truck pattern, dwell time) as a starting point. Example view within a simulation model of operations using an automated rail mounted gantry crane (ARMG) and automated guided vehicles (Lift-AGV)during these peak circumstances. Based on the outcome, decisions can be made concerning the quay length, the number of quay cranes, the gross productivity that quays have to achieve to accommodate a certain terminal throughput, the require-ments for storage capacity, and the peak handling conditions.The second step is more comprehensive, in the sense that there are many variables involved. Planning of the handling system involves the layout, type of equipment for the various operations – think of the number of trucks and RTGs, the number of rail cranes, the number of gate lanes, and so forth, and the logistical concept (incl. yard operating strategies). The latter is gaining importance in the case of automated terminals, since many tasks are taken over by computers. However, also at manually operated terminals is the emphasis put on efficient operations – for instance the implementation of truck or straddle carrier pooling. In this step, the TOS should be considered in close relation to the equipment as the TOS will make important decisions on grounding and dispatching and a realistic decision systematic is important to be included with a realistic feed of information from the operations, such as the equipment position and estimated time for finishing a job.An example of this second step is a recent comparison we carried out be-tween manually-driven shuttle carriers (SHC), automated shuttle carriers (ALV) and Lift-AGV’s. All in combination with an automated high density yard, operated by ARMGs. In terms of productivity, all three systems achieved the same performance level (40 net bx/h), but with different equipment numbers. In a peak operation the ratio between SHC, ALV, and L-AGV was 2.5-3.5-4 (per QC). The automated equipment is more sensitive to the density of the operation in terms of operating speed. Subsequently, one needs to compare the CAPEX required for each system, as well as the OPEX and understand key risk factors to coma to an evaluation of such systems. A simulation detailing such can be taken further getting close to civil design questions on pavement design, electric system requirements but also detailed kinematic characteristics of equipment and TOS functionality specifications. Optimise the day-to-day operation Although everyday operations at a container terminal differs from that of the day before, it is worthwhile to explore the possibilities of using models to improve such operations. The models are getting more comprehensive and are able to capture real operational procedures and handle real operational data. They can also depict processes at the level of individual container moves around the terminal and represent decision-making around grounding containers based on a container’s profile. With these models we see a great opportunity to apply them in the analysis and replay of past operations and in the pre-planning of upcoming operations. In this way, we can address questions around equipment usage and manning given a certain operation at a quay, rail and gate, as well as decisions concerning the in-advance preparation of the yard. Similarly operational procedures, namely equipment pooling, sharing part of the equipment, real-time re-allocation of equipment, and sizing the gangs, together with strategies and patterns for yard operations in terms of yard density, travel distance and unproductive moves (shuffles). Figure 1. Screenshot from the simulation model to determine the key terminal parametersThe outcome of these analyses can be fed back into the TOS functionality specifications, and into the minds of the managers, planners, dispatchers, and operators, running the terminal. It can overcome the often contradictory perceptions of the bottlenecks in the current operation, and prioritize improvement measures. Thanks to the use of real data and operations, the value of these exercises heavily increases, because it becomes much easier to translate the result back into the consequences for coming operations. Examples of the recent findings comprise the effect of equip-ment pooling (15% increase of equipment productivity and therefore the potential for reducing operating costs), and the effect of an improved RTG assignment and yard grounding strategy (20% less equipment required on average with the productivity level remaining at the same level).The essence of arriving at models that can accomplish this added value is a good understanding of the operation, including the rules in the terminal operating system. An alternative to overcome cumbersome modelling of TOS functionality is to link the simulation environment directly to the system. In this set-up, the simulation represents all the physical processes, the TOS uses the real container data to control the operation. By doing so, it can be configured much faster to accomplish a smooth and performing operation under various conditions.Operations at container terminals are highly complex, but automation makes them even more complex. Optimisation tools treating the operation as a deterministic process are difficult to apply because in real-time the operation differs highly from the planned situation due to the dynamic processes, weather delays and human intervention. Therefore, tools that explicitly consider the dynamics of a life operation should be favoured over others. Simulation is such a tool, able to represent and visualise container terminal operations – both the physical processes and the rules in the terminal operating system. Applying simulation makes the decisions concerning the investment in quay and quay cranes, the choice of handling system, and the configuration of a terminal’s control system better founded, better to understand, and more transparent to follow. It enables a terminal operator to reduce the risk of developing a new terminal or improving an existing one for similar or changing circumstances. If simulation is applied, one should make sure that the specific characteristics of an operation are validly represented in the model. Otherwise, the risk of nice pictures over sound results lies just around the corner. This article has been published in Harbours Review 2016/2. A pdf version can be found here: How can simulations help ports and terminals? 

Publication
The journey of CONTROLS: DPW Antwerp
May 2016

DPW ANTWERP DP World Antwerp Gateway is a high-class semi-automated terminal located on the left bank of the Port of Antwerp. Since 2007, it has been the first terminal in the global DPW portfolio to operate automated stacking cranes, providing the container storage for a large part of the terminal stacking capacity. The other part is done by a fleet of 1 over 2 and 1 over 3 straddle carriers. This mixes the benefits of a high stacking density on the yard by use of ASCs with the flexibility of straddle carriers. Combined with truck loading automation and world-class twin, tandem and quad ship-to-shore cranes, it delivers the tools to successfully run a container terminal in the Hamburg-Le Havre range. THE CONTROLS MODEL Because of the high-degree of automation in the terminal and the drive for optimisation, a good working TOS is essential. The operations have to be highly performant, even when in project roll out mode and after every update. This is where emulation kicks in for DPW Antwerp. The terminal came in contact with the CONTROLS product during the 2009 TOS implementation of Navis N4, coming from Cosmos. At that time, the emulation model was used for TOS testing in the pre go-live stage. This way, DPW Antwerp became acquainted with the benefits of emulation. After this TBA launched its new fully developed, now Java based emulation platform CONTROLS2. Because this new version could do much more, DPW Antwerp decided to upgrade, in order to use the potential of emulation to its maximum. This was the pilot project for TBA in 2011 to integrate CONTROLS2 with Navis XPS and ECN4, bringing emulation support to the latest generation of Navis TOSs. The CONTROLS2 model of DPW Antwerp was implemented with a high level of detail, modeled according to equipment specifications such as Gottwald’s trolley position dependent gantry speed system of the ASCs and load dependent quay crane (QC) hoisting speeds. Realistic operator behaviour was implemented in the emulation model as well, resulting in smooth QC spreader paths and realistic straddle carrier driving. The emulation model was validated against terminal data to ensure valid emulation results.   CONTROLS USAGEEver since, DPW Antwerp has embraced the usage of CONTROLS2 inits optimisation team for multiple purposes: TOS optimisation: Expert Decking and PrimeRoute offer advanced functionality and can bring major productivity improvements to terminals. These modules use complex parameter sets. Changing one parameter can affect the behavior in unexpected manners, even more so on a terminal with multiple types of stacking equipment. After determination of the desired improvements and corresponding parameter changes, CONTROLS brings the possibility to try the changes in real live situations and compare the outcomes to the benchmark. This way, a sensitivity analysis of the parameter can be made, showing the impact and side effects of the setting. Based on the outcome, the scenario is reset and run again with the lessons learned from the previous emulation experiments. This leads to a thorough understanding of the complex parameters, and optimal configuration for the specific terminal Patrick Van de Walle, Optimization Manager, says: “In the field of optimisation we have had several successes with the help of CONTROLS2. It has allowed us to verify the use of the Navis Autostow functionality and to determine the base parameter settings. Also, CONTROLS2 made it possible to reduce our horizontal driving distance by validating the renewed parameter sets for Expert Decking and Prime Route” TOS upgrade validation: Before the roll out of every TOS upgrade, DPW Antwerp runs complex emulation scenarios which allow the testing of the new TOS version to high volume scenarios under dynamic, near-to ­live circumstances. This enables a validation of both stability and productivity when using the new TOS version, prior to applying it onto the production environment. In this process, DPW Antwerp focuses on the handover scenarios between manual and automated equipment. This is a very important aspect for the semi­automated terminal, and shows the variety of benefits which CONTROLS2 can deliver. DPW Antwerp has used CONTROLS2 in conjunction with GTE and measurement tools to calculate the impact for significant civil changes to the terminal. This allowed to formulate the operational impact for civil restructuring. GRAPHICAL TERMINAL EDITOR As part of the CONTROLS suite, Graphical Terminal Editor (GTE) can be used to modify the terminal layout in the emulation model. The GTE application is aimed to support the CONTROLS user with the configuration of the terminal layout in a visual, user-friendly manner. The user can modify the terminal by adding or changing container terminal objects, such as stack, road, quay, parking places, buildings, and so forth. The real dimensions of each object can be entered and, for instance, sourced from CAD drawings of the terminal. For roadways, settings such as driving directions, maximum speed and the allowed equipment on each road can the configured. Extra yard blocks can also be added, or existing blocks changed. The output of the GTE application can be imported by the user into the CONTROLS2 model. CONCLUSION As witnessed by the examples in this article, CONTROLS has brought the benefits of emulation in the full extent to DPW Antwerp. In order to go even beyond, DPW Antwerp has decided to extend its CONTROLS model to include a full N4 cluster in the emulation setup. This will enable DPW Antwerp to further expand the scope and deployment of emulation. TBA will upgrade the emulation environment of DPW Antwerp to support this extension in the same user friendly manner. For instance, an upgrade of the MONITOR application, another part of the CONTROLS suite, will allow the users to start an emula-tion experiment by a single mouse click, including N4 database restore and startup of N4, regardless of the size of the N4 cluster. In summation, CONTROLS emulation will continue to support DPW Antwerp in this ever evolving industry. This article has been published in Port Technology Magazine Edition 70. Find the full article here:https://www.porttechnology.org/technical_papers/the_journey_of_controls_dp_world_antwerp Or view a pdf version of the same article here:The journey of CONTROLS: DPW Antwerp 

Publication
Entering the Maritime Sector: Logistics 4.0
March 2016

To read the article check:  https://www.porttechnology.org/technical_papers/entering_the_maritime_sector_logistics_4.0 

Publication
The journey of CONTROLS: 10 years
February 2016

A brief history about TBA's emulation platform CONTROLS. This article takes you through the development of this concept from the early days - more than 10 years ago - to today. The article can be found here: https://www.porttechnology.org/technical_papers/tba_the_journey_of_controls Or view a pdf version of the same article here: The journey of CONTROLS 

Publication
Terminal Automation: Key Questions Answered
January 2016

SWZ Maritime published the article and can be viewed here: Terminal Automation: Key Questions Answered

Publication
Merry Xmas and Happy 2016
December 2015

TBA wishes you a Merry Xmas and a Happy New Year.

Publication
Innovation and process optimisation drive succes
December 2015

The Ports of Auckland operates New Zealand’s largest container-based port. The terminals are situated in the heart of Auckland and hence have the largest consumer market in the country on their doorstep. More than 2 million people (out of 4.5 million in New Zealand) live in Auckland. Despite this relatively small population, large volumes of exports – New Zealand is one of the largest dairy exporters in the world – are handled through the Ports of Auckland (PoAL). The main container facility of PoAL is operated on the Fergusson berth and handles just over 1 million TEU annually. On a small footprint, operated with 1 over 2 straddle carriers, with the flow being predominantly import-export, this is an everyday puzzle to achieve quality of service both on the waterside and landside. Preparing for the future In order to be prepared for the future, PoAL partnered with TBA in 2008 to develop a long term plan, and to keep this up-to-date as time progresses. Since then, PoAL and TBA have been working together on the ‘master planning’, as well as enhancing operational efficiency to make it not only the largest but also the most productive and efficient terminal in New Zealand... To read more:  https://www.porttechnology.org/technical_papers/innovation_and_process_optimisation_drive_success

Publication
In 2025 werkt een derde van alle havens volautomatisch (Dutch)
August 2015

In 2025 werkt een derde van alle havens volautomatisch

Publication
Lean and Mean Terminal Design
June 2015

This article was published in Terminal Operator June 2015 View article

Publication
Machines zijn betrouwbaarder dan mensen (Dutch)
April 2015

Klik hieronder voor het interview  

Publication
Serious Simulation
March 2015

Port Industry has published an article on Serious Simulation To view the article in low resulotion: Serious Simulation Low Resolution To order the magazine: http://www.ynfpublishers.com/port-industry

Publication
Optimization as mantra for operational excellence
March 2015

In the first edition of Terminal Operator Yvo's article has been published: To see it in high quality on their website: http://issuu.com/terminaloperator/docs/terminal_operator_volume1_jan-mar20/19?e=0 To view it in low resolution: Optimization as mantra for operational excellence

Publication
De Havenindustrie is conservatief
March 2015

Yvo Saanen heeft een missie: mensen winnen voor de techniek. “Iedereen moet een grafiek kunnen lezen in de huidige maatschappij.” Zijn bedrijf TBA levert besturingssoftware voor geautomatiseerde containerterminals in havens als Rotterdam, New York en Los Angeles. De TU-alumnus is genomineerd voor de titel Ingenieur van het Jaar. Foto's: Sam Rentmeester U vindt dat meer mensen ingenieur moeten worden. Hoe wilt u daarvoor zorgen?“Als ik deze prijs win, ga ik met lezingen het ingenieurswezen uitdragen. Het ingenieur-zijn en op die manier naar de wereld kijken, daar moet veel meer van zijn. Ik merk het in het college dat ik geef aan de Erasmus Universiteit: een deel van de alfa-studenten kan geen grafiek lezen. Iedereen moet dat kunnen in de huidige maatschappij. Het is verweven in alles wat je doet.” U wilt ook het ondernemerschap promoten. Wat weerhoudtmensen ervan om te ondernemen?“Risico mijden, maar ga voor jezelf na: wat is daadwerkelijk mijn risico? Dat kan erg meevallen. Je moet durven falen. Wij hebben ook dingen opgepakt die niet gelukt zijn. Denk erover na hoe je een bedrijf kunt opzetten waarmee je meteen een basisinkomen voor jezelf kunt genereren. Misschien moet je dingen erbij doen die niet na aan je hart liggen, maar waarbij je wel je eigen kennis en kunde inzet. Je moet daar wat minder kritisch in zijn. Daarnaast wil ik uitstralen hoe leuk de maritieme industrie is. Nederland is toonaangevend. Overal in de wereld kennen ze het Nederlandse watermanagement en de maritieme techniek: schepen ontwerpen, kades, terminals en alles wat erbij komt kijken. Dat maakt me trots, maar we hebben meer mensen nodig.” Uw bedrijf ontwerpt onder meer simulatie- en besturingssoftware voor geautomatiseerde terminals, overal in de wereld. Waarom is de havenindustrie daar nu pas mee bezig?“De havenindustrie is conservatief. Op veel hoge posities zitten oude dokwerkers. Ze hebben gesjouwd, op een kraan gezeten, waren kapitein. Zij hebben minder affiniteit met technologie en computers. De grote operators wijzigen dat stap voor stap: in de managementslagen komen steeds meer hoogopgeleiden. Dat is een onomkeerbare trend.” Wat zijn de voordelen van geautomatiseerde containerterminals?“Ze kunnen meer volume afhandelen, veroorzaken minder schade aan machines en containers, zijn stiller en emissievrij. In een traditionele haven werkt alles op diesel, in een automatische haven op elektriciteit. Neem Hamburg: daar ligt de haven in de stad. Daartegenover ligt een dure villawijk. De bewoners daarvan zijn niet blij als er containers worden overgeslagen vanwege lawaai, uitstoot en lichtvervuiling. De automatische haven is ook veiliger. Jaarlijks vallen er wereldwijd honderden slachtoffers, het is een gevaarlijke industrie. Sommige mensen komen onder een container terecht, de meesten worden overreden. Kijk naar India. Daar komt een truckchauffeur de terminal binnen, vaak met een tweede mannetje bij zich voor de papieren. Dat rent blootvoets over de terminal, tussen de trucks door. Haal je mensen weg van de werkvloer, dan worden de risico’s veel kleiner. Het gaat wel gepaard met banenverlies, dat is onvermijdelijk.” Hoe groot wil TBA worden?“We hebben de laatste drie jaar twee bedrijven gekocht. We zijn nu in totaal met tweehonderd man. We willen daarmee een meer compleet bedrijf worden. Een houdt zich bezig met bulk, de ander met planningssoftware. De omzet nu is ongeveer twintig miljoen euro. Gezamenlijk hebben we het doel binnen vijf jaar te verdubbelen. Dat moet lukken, want ik verwacht dat het aantal automatische terminals binnen tien jaar vertienvoudigt, als eerste in hoge-lonen landen, zoals de Verenigde Staten en Australië. Wij verwachten daar een flink aandeel in te hebben.” Waarom daar?“De loonkosten zijn er astronomisch hoog. Aan de westkust van de VS is het gemiddelde salaris van havenwerknemers 150 duizend dollar. In New York zijn er mensen die zeven dagen in de week 25 uur per dag betaald worden, maar niet eens op de terminal aanwezig zijn. Dat komt door de macht van de vakbonden. Het is daar helemaal uit de hand gelopen. Zijn er onderhandelingen tussen werknemers en werkgevers aan de westkust, dan gaan havenwerkers aan de hele kust langzaam werken. Zeventig, tachtig schepen liggen dan in de haven op afhandeling te wachten en op termijn raken de schappen in de supermarkten leeg.” De bonden zijn vast niet blij met jullie.“Onze opdrachtgevers zijn de terminals. Zij onderhandelen met de bonden. Als ontwerpers staan wij op afstand. Ook in China, waar we de afgelopen twee jaar twee grote projecten hebben gedaan, zijn stijgende lonen naast prestige een reden om te automatiseren. En verrassend genoeg kunnen ze niet aan personeel komen dat in de haven wil werken. Het verloop is er 25 procent per jaar. Dat leidt tot kwaliteitsinbreuk.” Hoe bent u in de havenwereld terechtgekomen?“We zijn met zijn tweeën – Klaas Pieter van Til en ik - begonnen met logistiek advies. TBA staat voor Technisch Bestuurskundige Adviesgroep. De combinatie van technische projecten met juridische aspecten, business cases, draagvlak creëren, dat was een niche. Daarmee zijn we bij ministeries langs geweest en diverse partijen in de Rotterdamse haven. Dat leidde tot allerlei verschillende projectjes. We pakten alles aan wat we konden krijgen. De TU heeft ons ook aan opdrachten geholpen: derde geldstroomonderzoek dat ze zelf niet aankonden. Zo zijn we op het simulatiespoor gekomen. Werktuigbouwkundehoogleraar Joan Rijsenbrij werkte voor het Duitse bedrijf Gottwald, dat automatisch geleide voertuigen heeft geleverd op de Maasvlakte. Gottwald had simulatiesoftware nodig en had gezien dat ik daar wel handig in was. Toen is het balletje richting havens gaan rollen. We hebben een bibliotheek aan simulatiemodellen ontwikkeld. Nog steeds is dat de basis van veel van ons werk wereldwijd.” Nu hebben jullie naast het Delftse kantoor vestigingen in Duitsland en Roemenië.Waarom daar?“In 2006 hebben we een groot deel van onze aandelen verkocht, aan Gottwald, dat weer onderdeel is geworden van Terex, een Amerikaans concern.Zo zijn we in Duitsland terecht gekomen. Tot die tijd deden we alleen advies en simulatie, daarna zijn we software gaan bouwen. Met onze simulatiesoftware voor ontwerp en verbeteringen zijn we wereldwijd veruit de grootste, net als met de besturingssoftware voor automatisch gestuurde terminals. In Roemenië belandden we, omdat er in 2005 in Nederland niet aan ingenieurs te komen was. Vlak voor de crisis was alles hype. We hadden een Roemeense werknemer die een paar vrienden aanbeval. We hebben ze een pilotproject gegeven en dat beviel goed. Roemenen zijn fijne mensen om mee te werken: uitstekende informatici en zeer loyaal. Met hen hebben we een nieuw product ontwikkeld: het emulatieprogramma, dat we gebruiken voor het testen en finetunen van software. We zijn de eerste die daarmee zijn begonnen en we zijn wereldmarktleider. Hoe je uit een promotietraject nog een leuke aanpak kunt halen.” Waarom wilde u promoveren? U had al een eigen bedrijf.“Ik werd enthousiast gemaakt door een paar simulatiecollega’s aan de TU. Het leek me leuk, maar ik zou het niet weer doen. Ik zou promoveren niemand aanraden, tenzij iemand een academische carrière ambieert. Het is erg individueel, je moet zelf dat boekje af krijgen, een heidens karwei. Ik houd meer van samen dingen doen. Maar er is wel iets uit voortgekomen. Ik ben er trots op dat emulatie een succes is geworden. Steeds meer internationale bedrijven doen ons na.” Wat is het verschil tussen simulatie en emulatie?“Emulatie is complexer. Je moet details toevoegen en in real time kunnen samenwerken met werkende software. Het is heel krachtige technologie. We zijn nu hard bezig met training van werknemers in dat soort omgevingen. Neem een planner in de containerterminal. Die doet gewoon zijn werk in zijn plansysteem, alleen is het een virtuele omgeving. Hij kan op een veilige manier aan moeilijke omstandigheden worden blootgesteld, zonder dat hij het fout kan doen. We maken nu de stap naar de combinatie met virtual reality, zodat we ook mensen kunnen trainen die buiten werken. Dat doen we met een Oculus Rift-bril. Daarmee waan je je in een 3D–omgeving. De man die in de containerterminal reparaties moet uitvoeren, zet die bril op en loopt rond. Waarbij alles wordt gesimuleerd: voertuigen rijden rond, schepen worden afgehandeld. Dan kan hij zijn taken uitvoeren volgens alle protocollen.” U zit in de raad van advies van uw oude faculteit TBM. Wordt er naar u geluisterd?“We zitten met zeven, acht mensen uit het bedrijfsleven en de ambtenarij twee keer per jaar bij elkaar om mee te denken over onderwijsprogramma’s en onderzoeksvelden. Het faculteitsbestuur legt zijn plannen aan ons voor en wij kraken wat kritische noten. We hebben geen zeggingskracht, het is puur klankborden. Iedereen neemt er het zijne van.” Is er veel veranderd sinds u technische bestuurskunde studeerde?“Natuurlijk is er van alles anders, maar de hoofdlijn van het curriculum staat overeind. Al zijn er wel wat dingen vervallen, waarvan ik me afvraag waarom. Ik vind dat elke techniekstudent zou moeten leren programmeren. Niet omdat ze later moeten gaan programmeren, maar omdat het ze een denkwijze aanleert die in elk vak buitengewoon nuttig is: objectgeoriënteerd en gestructureerd denken. Programmeren dwingt je structuur aan te brengen in je probleem. Maar helaas komen er nog steeds studenten van de TU die niet kunnen programmeren. Als van de afstudeerders vijftig procent zelf een app kan bouwen, vind ik het veel. Dat moet veel meer zijn.” CV Yvo Saanen (41) begon in 1991 aan de toen nieuwe opleiding technische bestuurskunde. Daarvoor deed hij een jaar wiskunde, maar vond dat te saai. “Te veel wiskunde.” Saanen was lid van het eerste bestuur van studievereniging Curius en medeoprichter van alumnivereniging Arachnion. Ook was hij als student bestuurslid van de Landelijk Overleg Bestuurskunde. Na zijn studie begon hij samen met studiegenoot en vriend Klaas Pieter van Til het bedrijf TBA. Terwijl ze wereldwijd opdrachten binnensleepten, promoveerde Saanen tussen 1998 en 2004 bij TBM op een nieuw vakgebied: emulatie. Tot 2008 gaf Saanen op de TU het vak simulatie en logistiek. Hij stopte toen hij het niet meer leuk vond. “Het was een verplicht vak. De motivatie van de studenten was niet altijd om over naar huis te schrijven. Het moet wel van beide kanten komen.” Saanen doceert aan de Erasmus Universiteit Rotterdam, binnen de postacademische master maritime economics and logistics. Een van zijn werknemers nomineerde Saanen voor de titel Ingenieur van het Jaar. Dit artikel is gepubliceerd in het universiteitsblad Delta van de TUDelft. http://delta.tudelft.nl/artikel/de-havenindustrie-is-conservatief/29637

Publication
Doing training Confusian style?
November 2014

The paper was published in Port Technology International. To view the PDF click: Doing training Confusian style? To view the article on PTI click: Doing training Confusian style?

Publication
Near-to-live-training for Container Terminal Planners
September 2014

A proficient use of a Terminal Operating System (TOS) for planning and equipment control isessential for efficient and productive operation of container terminals. The degree to whichTOS is used effectively is highly reliant on human operators. The training of these operatorsis traditionally done through conventional and on-the-job training, with a limited structure,and a narrow scope. Besides, it heavily relies on the expertise of the on-the-job trainer(s). Inthis article we report a systematic training approach we have applied in a number of cases toimprove the skills of control room operators in various container terminals. The approach issupported by a virtual terminal emulation and allows for accurate measuring of the operator’sperformance. As such, we have been able to measure the impact of the training, and theimpact of changed ways of operating, in the sense of improved ways of planning andcontrolling the terminal. Click here to view the paper.

Publication
Optimisation as mantra for operational excellence
July 2014

The paper was published in Port Technology International. To view the PDF click: Optimisation as mantra for operational excellence To view the article on PTI click: Optimisation as mantra for operational excellence PTI

Publication
Dry bulk terminal capacity planning
May 2014

The paper was published on Port Technology International. To view PDF click: Dry bulk terminal capacity planning To view article on PTI's website click: Dry bulk terminal capacity planning PTI

Publication
Analysing terminal facilities for biomass operations
November 2013

Port Technology - Analysing terminal facilities for biomass operations

Publication
Analysing the stockyard
October 2013

Dry Cargo International - Analysing the stockyard

Publication
Australian Bulk Handling Review
August 2013

Information technology: the aid for optimising bulk terminal logistics Information technology (IT) is a useful tool for improving the handling efficiency of bulk terminals and consequently reducing costs. To achieve this objective it is essential that the IT system is embedded into process flow and integrated into the operation system and considered as a part of the whole system, rather than treated merely as a tool for financial and administrative purposes. This paper explains why an optimal IT architecture ought to be selected, and how it is built and integrated into the terminal operation system at bulk terminals. Together with other significant aspects such as process flow mapping, real time data obtained through interfaces to other systems (e.g. automation, weighing) this optimal IT architecture shows improvements in handling efficiency and cost saving. In addition, three case studies that show the successful examples in real practice are presented. These case studies demonstrate how various operational issues can be solved by well-considered and well-implemented information technology systems.   

Publication
Next generation integrated container terminal
July 2013

Box Intermodal - Next generation integrated container terminal

Publication
Container simulation
June 2013

World Port Development: Container simulation

Publication
Mega ships: positive asset or terminals' worst nightmare?
May 2013

Port Technology: Mega ships: positive asset or terminals' worst nightmare?

Publication
Testing, tuning and training terminal operating systems: a modern approach
August 2012

LOGMS 2012 Proceedings - Testing, tuning and training terminal operating systems: a modern approach

Publication
Improving container terminal efficiency through emulation
June 2012

Journal of Simulation: Improving container terminal efficiency through emulation

Publication
An operations perspective on new twistlock handling in terminals
February 2012

Port Technology - An operations perspective on new twistlock handling in terminals.

Publication
Advanced 3D visualization for simulation using game technology
December 2011

WniterSim Proceedings: Advanced 3D visualization for simulation using game technology

Publication
Optimizing automated container terminals to boost productivity
September 2011

Port Technology - Optimizing automated container terminals to boost productivity

Publication
How simulation modeling can support environmental initiatives at container terminals
December 2010

Port Technology - How simulation modeling can support environmental initiatives at container terminals

Publication
TBA completes training program with CONTROLS at the Port of Göteborg
October 2009

Port Technology - TBA completes training program with CONTROLS at the Port of Göteborg

Publication
No Growth? Squeeze the Lemon!
August 2009

Port Technology - No Growth? Squeeze the Lemon!

Publication
EUROMAX, a new Standard in container handling
August 2009

Port Technology - EUROMAX, a new Standard in container handling

Publication
TOS designers make hub transitions easy
March 2009

Cargo Systems - TOS designers make hub transitions easy

Publication
CONTROLS: Emulation to improve the performance of container terminals
December 2008

WinterSim Proceedings: CONTROLS: Emulation to improve the performance of container terminals

Publication
Industry experts gather in California for TOC Americas 2008
November 2008

Port Technology - Industry experts gather in California for TOC Americas 2008

Publication
Advanced applications for terminal operations
October 2008

Port Technology - Advanced applications for terminal operations

Publication
Breaking free of ASC cycle
June 2008

Cargo Systems - Breaking free of ASC cycle

Publication
Simulations address issue of productivity
May 2008

Cargo Systems - Simulations address issue of productivity

Publication
TBA sets new standard for Port automation at APM's Virginia Terminal
April 2008

Port Technology - TBA sets new standard for Port automation at APM's Virginia Terminal

Publication
Informing choice for container terminals
March 2008

World Cargo News - Informing choice for container terminals

Publication
Heralding an era of automation
March 2008

Cargo Systems - Heralding an era of automation

Publication
EUROMAX on autopilot
February 2008

Port Strategy - EUROMAX on autopilot

Publication
Putting AGVs to the test
September 2007

Cargo Systems - Putting AGVs to the test

Publication
TBA passes CONTROLS to Eurogate
September 2007

Cargo Systems - TBA passes CONTROLS to Eurogate

Publication
Which system fits your hub?
June 2007

Cargo Systems - Which system fits your hub?

Publication
Craney Island moves forward
May 2007

World Cargo News: Craney Island moves forward

Publication
Intelligent stacking as way out of congested yards? Part 2
April 2007

Port Technology - Intelligent stacking as way out of congested yards? Part 2

Publication
Intelligent stacking as way out of congested yards? Part 1
March 2007

Port Technology - Intelligent stacking as way out of congested yards? Part 1

Publication
Picking the right crane
March 2007

Cargo Systems - Picking the right crane

Publication
Software for RMGs at hand
March 2007

Cargo Systems - Software for RMGs at hand

Publication
Simulation: It’s the real thing
March 2007

World Cargo News: Simulation: It’s the real thing

Publication
Using emulation to improve the performance of your TOS
January 2007

Port Technology - Using emulation to improve the performance of your TOS

Publication
Measure for measure
May 2006

Cargo Systems - Measure for measure

Publication
Comparison of three automated stacking alternatives by means of simulation
December 2005

WinterSim Proceedings: Comparison of three automated stacking alternatives by means of simulation

Publication
Emulation for Terminal Operating Systems
November 2005

Cargo Systems - Emulation for Terminal Operating Systems

Publication
Simulation software deal for Navis and TBA
July 2005

Cargo Systems - Simulation software deal for Navis and TBA

Publication
An approach for designing robotized marine container terminals
December 2004

Delft University of Technology - An approach for designing robotized marine container terminals

Publication
Expanding through the use of RMGs
September 2004

Cargo Systems: Expanding through the use of RMGs

Publication
Hemmed in its European heartland
June 2004

Cargo Systems - Hemmed in its European heartland

Publication
Finding the right answers through simulation
March 2004

World Cargo News - Finding the right answers through simulation

Publication
The design and assessment of next generation automated container terminals
October 2003

European Simulation Symposium Proceedings - The design and assessment of next generation automated container terminals

Publication
Distributed E-services for road container transport simulation
October 2003

15th European Simulation Symposium Proceedings - Distributed E-services for road container transport simulation

Publication