International Port Training Conference (IPTC)
Developing skills for terminal automation
1. Introduction
In the 1960s advances in mechanisation supported the introduction of
maritime containers which enabled the unitisation of the loose packages that typified general cargo trades. Whilst traditional general cargo operations depended on the physical strength of dockworkers container berths utilised specialist handling equipment to lift and transport the large and heavy containers between the ship, yard and inland transport modes. The high payload of the container and the speed of handling meant that container berths reduced dock labour requirements by 78% and increased berth throughput by 400% compared to that of general cargo berth operations (Johnson & Garnett 1971). Improved ship handling rates also significantly reduced the time ships had to be at berth resulting in a single container berth in the 1970s equating to the throughput capacity of more than ten general cargo berths (National Ports Council 1970).
These step improvements in productivity required: co-ordinated planning of the yard and the ship; seamless operations between the yard and ship stowage location; and the introduction of intermodal transport to allow containers to move from inland origin to inland destination points (Erichsen 1966, Groeneveld 1966). The need for closer control of planning and
operation resulted in a restructuring of the port community with roles of berth superintendent, stevedore, master stevedore and cargo superintendent being combined within a single organisation, now known as the container terminal operator (Martin 1999).
Along with operational and organisational changes containerisation required improved administrative systems to allow terminal operators to cope with the volume of information and transactions associated with the high throughput levels that could be achieved. At the time when containerisation first evolved computer technology was not advanced enough to provide the necessary
instant access to information and data processing speeds required by terminal operations. Terminal operators initially relied on paper based administration systems to plan, control and record the movement and storage of containers (Thys 1992), with “T Cards” being typically used to record information and maintain yard inventories.
However, paper based systems were ill-suited to the requirements of container terminals, as Dally noted:
“Present manual systems for maintaining, processing and retrieving information do not lend themselves to providing required standards of service to management and customers without excessive use of clerical labour. They lack the flexibility and speed of response necessary if satisfactory levels of service are to be achieved …” (Dally 1979; 384)
So in the 1970s technology advances in computer processing power, direct access data storage and electronic data communications were quickly adopted by terminal operators. These advances enabled terminal operators to develop real time systems on central mainframe and mini-computers accessible from computer terminals located throughout the terminal complex (Verstraete 1977).
Today any visitor walking around a container terminal will observe the widespread use of computerised systems with terminal staff accessing computers via pcs, handhelds and in-cab terminals. In the most technically advanced terminals the observer will witness automated processes integrating computer systems with a wide range of other technologies such as remote sensors, image capture, robotics, navigational positioning and scanning. Automatic stacking cranes (ASCs) can be seen performing yard moves, automatic transfer vehicles (ATVs) transferring containers between the yard and identification technology verifying the identity of containers, trucks, rail wagons and people.
The deployment of automated solutions requires terminal operators to re-appraise the skills, knowledge and attributes required from portworkers. Successful terminals of the future will depend on people thinking in terms of
systems, processes, end-to-end flows, exception handling and configuration management. This paper reviews the development of computerised systems, and examines the impact the recent deployment of automated solutions is having on the skills and knowledge required for today’s modern terminal.
2. Computerized Terminal Operations
In the 1970s terminal operators began to integrate the control and operation of ship-to-shore, container yard and gate-house functions through the
development of computerised control systems, known as the Terminal Operating System (TOS). The TOS enabled a terminal operator to have access to a real time data providing work lists, container status details and container inventory locations. By the early 1980s some 78% of the world’s container terminals had invested in computerised administration systems and over 40% were using some form of TOS to control landside and marine operations (Couper 1985).
Today the TOS is one of many computerised systems used by terminal operators, with:
¾ Corporate systems supporting functions such manpower management, financial reporting, accounting and management reporting.
¾ Engineering systems managing spares procurement and inventory, scheduling maintenance and assisting in diagnosing equipment malfunctions.
¾ Gate applications supporting security procedures and scheduling the arrival pattern and service times of trucks.
¾ Equipment using computers for monitoring and control purposes as well as offering operator assistance functions.
Figure 1 below shows the range of computer systems that are now deployed within a container terminal. The complexity being increased when one
considers that although the TOS may be supplied by a single software house, it should really be viewed as a suite of software applications so adding to the overall number of applications deployed.
Figure 1 Terminal Operator Computer Systems Map
As computing costs have decreased, in terms of hardware, processing power and programming development, software applications have increasingly incorporated electronic problem solving functionality. Computers systems now perform the majority of data based operational decisions in a terminal. For example, grounding algorithms in the TOS are used to decide where containers should be stored in the yard based on the following information maintained in the TOS:
¾ Container status - size, type, weight, onward instructions and cargo type.
¾ Resources – available yard slots, equipment locations and workloads. ¾ Constraints - segregation rules, yard layout, traffic management and
equipment characteristics.
¾ Procedures - optimum and maximum stacking heights, container pile rules and traffic priorities.
Computers have proved very effective at performing data based decisions, being much better than humans at taking account of multiple parameters and
rules when making decisions. The trend towards computerised algorithms making decisions has made terminal employees increasingly responsible for resolving exceptions and unplanned events occurring outside normal
operating procedures.
In marine departments, vessel stowage applications assist vessel planners by automatically assigning export containers to vessel slot locations based on guideline rules, yard locations and stowage constraints. Vessel planners then review the vessel’s proposed plan and consider factors not accounted for by the system and resolve any stowage or segregation conflicts. More advanced vessel planning applications will take account of berth and yard locations and recommend to the vessel planner crane assignment splits, dual runs, tandem runs and dual cycle runs.
Whilst a vessel is being worked and yard moves are being undertaken the TOS oversees the performance of work and automatically dispatches jobs to internal transport vehicles (ITVs) and yard cranes. In the office instead of dispatchers manually assigning work employees now act as controllers, monitoring work progress and taking corrective action where work falls behind or proceeds in advance of plan. Controllers also react to exceptions arising from events which cannot be planned for in advance, for example adapting operations to account for: incorrectly declared vessel bay plans; damaged containers; and equipment breakdowns.
Outside on the quay, in the yard, at the gate and in equipment handheld and in-cab mounted terminals now link operators directly with the TOS and other systems, allowing operators to receive work instructions, make enquiries and update data. Programmable logic controllers (PLC) and Supervisory Control And Data Acquisition systems (SCADA) are incorporated in equipment control and optimise equipment movement, reduce fuel consumption, monitor and diagnose equipment status and provide operator assistance tools such as anti-sway and automatic positioning.
To function effectively modern terminals are dependent on numerous software systems for inputting, processing, interpreting, storing and categorizing data. Each system has functionality designed to focus on a specific process and as
such each system generally makes decisions and functions to optimise its own processing areas. Where data is passed between systems this is not in true real time as there is a time lag between the recording of an event by one system and it being communicated to and used by another system. However, it is common for terminal staff to believe that information they view in one system which originates from another is real time data. Many terminal
operational and control staff are unaware of the plethora of systems that they depend on and are unaware of the complex plethora of software applications that support this.
The challenge facing terminal operators seeking to improve planning and operational performance is the “silo” mentality of each of the applications with each system being designed to optimise the processes it is responsible for. In many instances the structure of data used by the various systems is
inconsistent and so prevents or limits the meaningful exchange of data between systems. Thus, whilst it may be possible to optimise the various steps of a process by optimising each system involved this will not optimise the end-to-end process. Consequently, individual sub-processes may be optimised but the end-to-end process may functional sub-optimally as each system makes decisions in isolation of the needs of the other systems
involved. Each system will also have to be configured independently requiring a duplication of effort and risk of inconsistent configuration data being used.
3. Automation
Since the early 1990s a number of terminals have developed automated solutions integrating systems and robotic equipment to provide an apparently seamless end-to-end computerised controlled solution. The first two such examples are ECT Delta Terminal in Rotterdam and Thamesport near
London. ECT Delta automated the end-to-end flow of containers between the yard storage location and the backreach of the quay crane with ASCs and Automatically Guided Vehicles (AGVs). On the landside manually operated straddle carriers perform the link between trucks and the yard. Control systems seek to optimise the end-to-end movement of containers between the backreach of the ship-to-shore quay crane and the yard storage location
and between internal transport vehicles transfer points and the yard storage location.
More recent examples of the deployment of ASC-ATV operations include CBA in Hamburg, Fishermans Island in Brisbane (using automated straddle
carriers) and Euromax in Rotterdam. In the case of CBA and Euromax the end-to-end automation flow has been extended on the waterside to include an automated second trolley on the quay crane which performs the move
between the quay crane platform and the AGV.
Since the development of Delta Terminal there has only been limited interest in integrating ASCs and ATVs, be they AGVs, automated straddle carriers or shuttle carriers. Resistance to the integration of ASCs and ATVs has largely been due to:
¾ The business complexity and resultant risks of automating the serving of the handover of containers between the quay crane and the ATVs. ¾ An impression in the industry that ATV operations are too immature to
achieve comparable performance levels to manually operated internal transfer vehicles.
¾ The increased time need during terminal commissioning for developing, testing and optimising an ASC-ATV operation.
¾ A fear that an ASC-ATV operation once deployed is difficult to redesign and adapt should market conditions and traffic needs alter.
¾ Operational inflexibility and time delays resulting from the dependency on software systems to perform the majority of quay-yard transfer moves.
With continued advances in the technology and optimisation techniques the ASC-ATV solution continues to be assessed during the design of new container terminals.
The design of Thamesport restricted the use of automated equipment to ASCs working in the yard storage areas, with transport to and from the quay still being performed by manually operated terminal trucks. On the landside external trucks drive to the yard area where they are serviced by the ASCs
controlled by terminal employees working in the yard with remote control units. This limited use of automation significantly simplifies the business scenarios that have to be designed into the automated systems and as a consequence this more limited use of automated equipment has become a common yard operation for new terminals and terminals undergoing major upgrades.
The gate-in and gate-out process, although traditionally seen by terminal operators as the Cinderella process, has recently received considerable attention and there are now a growing number of instances of automated gate solutions. These automated solutions combine:
¾ Vehicle booking systems which manage truck arrival patterns.
¾ Optical Character Recognition (OCR) systems to identify truck licence plates, chassis numbers, rail wagon IDs, container numbers, size types and IMO placards.
¾ RFID readers and transponders to recognise and confirm the location of equipment.
¾ Employee and visitor identification schemes using SMART Cards or biometric readers to confirm personal details, access and usage rights to areas and equipment.
¾ Algorithms to plan and optimise the external truck route plans and to preposition containers ready for collection.
¾ Scanning devices to validate declared cargo with actual contents. ¾ Numerous other devices such as printers, security barriers, intercoms,
closed circuit television (CCTV), weight scales, pedestal entry pads and screens, billboard announcement screens.
Figure 2 below depicts the wide range of hardware and software applications which could be integrated to provide an automated gate solution, highlighting the numerous suppliers, systems and hardware that are integrated as part of an automated solution.
Figure 2 Automated Gate Systems Integration
To optimise automated solutions it is necessary that the integrated sub-systems are overseen by a controlling system that has an awareness of the end-to-end process or for the sub-systems themselves to have an awareness of the end-to-end process. This high level of systems integration means that should one sub-system malfunction, crash or perform slowly then all the other sub-systems are likely to be significantly impacted. In the design phase considerable attention has to be given to identifying all the possible
operational permutations that could be encountered in the real world such that the automatic solution will include functionality to deal with all eventualities. This requires considerable analysis, design and alignment by the equipment, electronics and software providers as well as the business users. Prior to going live the solution requires thorough testing of the end-to-end automated process to ensure the solution provided by the interdependent sub-systems can function effectively for all expected and identified unexpected operational scenarios.
In contrast, where malfunctions or exception scenarios (also referred to as unhappy day scenarios) occur when using computerised systems which are not automated it is possible to find a manual work around, with operators
performing the operation manually outside of the system or by using existing functionality in a way for which it was not designed for. In the worst case scenario should one system not be usable then operations usually continue, albeit at a lower level of performance. In the case of automation a failure by a sub-system will impact the ability to perform the end-to-end process bringing operations to a standstill.
Automation requires terminal operators to reconsider the knowledge, skills and attributes they require in their workforce. Awareness is needed of the end-to-end processes taking place on the terminal and a knowledge of the interdependency of the tasks performed. As well as being trained in the functionality of systems as it is essential that they know the limitations of systems and have a sufficient understanding of the decision logic being used by the system to allow them to perform exceptions handling and to use override features effectively. Certain job functions are fundamentally altered by automation with for example yard crane drivers no longer being located in equipment cabs but instead operating remotely via computer and video
screens located in an office environment. Senior executives are not excluded from the impact of automation which also impacts the cost structure, risk profile, performance measure methodology, organizational structure and employment requirements of terminals.
4. Skill Requirements for Automation
The container terminal sector has long been characterised as being the domain of portworkers operating large mobile cargo handling equipment. Rarely is it seen by outsiders, or insiders, as being a sector deploying advanced electronics, sophisticated computerised systems and robotic solutions. In the past five years this impression is starting to change as
terminal operators have increasingly deployed automated solutions to improve planning and operations to increase capacity, reduce manning and improve performance.
New skills have been required to ensure the design, development and performance of automated solutions are robust enough for the challenges faced in day-to-day operations. Projects for the development of new terminals
and terminal upgrades including aspects of automation have to find people skilled in engineering business processes and integrating systems. Typical roles required to be filled include:
Enterprise Systems Architect work with management, subject matter
experts, Business Architect and IT suppliers and IT suppliers to align business and IT soltutions. Their goal is to ensure that the systems and hardware deployed are the most efficient, compatible, scalable and adaptable to meet the organisation’s processes and strategy. They maintain a systems map detailing the flows between and responsibilities of each system. A vital player in defining the holistic IT footprint of an organisation required to support a competitive advantage through information technology.
Enterprise Business Architect, work with management, subject matter experts, Enterprise Architect and business partners to ensure the business and IT soltutions are aligned with each other and. Their goal is to ensure that the proceses and operations deployed are the most efficient, compatible, scalable and adaptable to meet the organisation’s processes and strategy. In owning the business process model they ensure processes are streamlined and aligned to achieve a competitive advantage.
Systems Integration Engineer, ensure the successful integration of systems dependent on multiple harware and software sub-systems. They negotiate with the suppliers of the different hardware and software sub-systems to define the interfaces and means by which data is exchanged. As experts in the detailed inter-relationship of systems they are key in diagnosing and troubleshooting integrated soutions.
Business Analyst liaises with stakeholders to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems. They are trained in documenting and analysing user requirements as well as recommending solutions in a manner which can be understood by the business and software developers.
Domain Experts with knowledge or skills in a particular area of the business, being both knowledgeable and extremely experienced within their area. They are seconded into a project to represent the end user of the system, having to work closely with business analysts to ensure requirements are interpretered correctly and proposed solutions meet the business need.
User Acceptance Test Engineer ensure through trial usage that the system meets the agreed functional requirements. The tests they perform verify that the system will function correctly under real-world conditions when used by end-users and so they give confidence to the business that the system will perform correctly when deployed.
Technical Process Author, a professional writer who designs, writes,
output differs from that of software user and reference manuals as they take account of how the functionality will be used by the business. They write documents such as, user guides, white papers, design specifications and system manuals targeted at end-users and system administrators.
Configuration/Optimisation Manager, establishes and maintains
consistency of the system settings and configeration parameters to ensure systems function securely and according to the layout and design of the terminal, as well as the operating procedures and processes. They control changes made to hardware, software, firmware, documentation, and test documentation throughout the life cycle of an information system. They also work with the business to assess the impact of system configerations settings on operational performance and to optimise configerable algorithms settings. Super Users, being special end users with an advanced knowledge of the functional and technical aspects of a system. They are tasked with on the job training and support and have additional systems access rights to normal users to allow them to investigate and resolve system issues. To support the techncial team they will be trained in documentation methods and will assist in systems testing.
It is important to note that the need for the above skills is not limited to the project development phase of a new terminal but is ongoing throughout the operational life of a terminal. Continued access to these skills is necessary to perform the analysis, editing of artefacts, process re-engineering, functional design and testing as the systems footprint of the terminal evolves due to the:
¾ Release of new functionality to satisfy business and institutional demands.
¾ Replacement of existing application versions as deployed versions become obsolete and are no longer supported by suppliers.
¾ Deployment of new hardware and networks to handle changes in transaction volumes, increased performance requirements and replacement programmes.
¾ Changing of system settings to account for variations to terminal layout and revisions to operating procedures.
¾ Enhancement of algorithms aimed at improving system decision making and thereby operating performance.
¾ Introduction of new systems extending the systems footprint and the replacement of old systems as systems become technically obsolete or systems are replaced by competing systems which are thought to offer better performance.
¾ Revision of systems integration solutions arising from the deployment of new and upgraded equipment or the need to electronically
The occurrence and timing of the above events which trigger the need for the new skills are often outside the control of the terminal operator, arising due to new demands by government bodies, generic software and hardware
upgrades issued by third party suppliers. What may appear a simple a small change such as the need to replace a failed hardware device such as a keyboard in a Gate Pedestal will require the end-to-end gate in and gate out process to be assessed and tested to ensure that the new component integrates with all of the other elements of an automated gate solution. Failure to retain the skills identified above or to maintain the artefacts significantly increases the risk that a terminal operator will incur a
considerable time delay and cost to maintain automated solutions or adapt them to changes in business need.
The deployment of automated solutions also has a major impact on the skills and training requirements of operators, controllers and front line managers who need to be much more aware of the end-to-end flow and
interdependency of operations. Increasing dependency on systems and automation raises the risk that staff portworkers become mere “button pushers” unable to handle unexpected events and too readily able to blame poor performance on perceived system short comings.
To overcome this risk training must be extended from the traditional task based focus to a broader more holistic understanding of the why and the what of container terminal operations. Without this broadening of the training scope staff will lack the understanding of the importance and consequences of their interactions (or failure to interact) with systems. Staff must be aware of the consequences of:
¾ Entering inaccurate information which is likely to give rise to
subsequent exception events - for example if a gate-in clerk incorrectly records the door direction of a 20ft container the error will, in the case of an ASC-ATV, result in the container arriving facing the wrong direction under the quay crane.
¾ Untimely or non-entry of status changes which will cause computerised decisions to be based on erroneous data – for example failure to
record the occurrence of a quay crane breakdown will cause the TOS to continue to allocate automated / internal transport vehicles to service the quay crane.
¾ Inappropriate functional usage or working outside of the system which will result in inaccurate container inventory, sub-optimal decision making and incorrect equipment status - for example, operators using override functions when not required will alter the priority decision making of the system without knowing all of the conditions that should be considered.
¾ Constant tweaking of settings which will prevent systems from
establishing a constant state – for example, if in an attempt to prioritise a particular move an operator changes settings without considering the timeframe of the end-to-end flow it is possible that the impact of the setting change will not take effect until after the completion of the task they are seeking to prioritise. Eventually such users conclude that the functionality does not work and either incorrectly log it as a bug or they say nothing and loose faith in the system.
In an automated environment operators have to ensure that tasks they
perform are recorded with a very high degree of accuracy and timeliness. For some operators, such as the gate clerks and inspection clerks, their role becomes much more focused on resolving issues and managing exceptions instead of performing repetitive happy day processes. In many cases such portworkers may no longer be physically located where the operation is
performed but are instead located in remote control rooms observing incidents on monitors and communicating by audio channels to truck drivers and other visitors. When things go wrong either operationally, out of schedule or due to breakdowns operators have to consider the impact this has on the system and the lead time required to affect any solutions within the system. In the worse case scenario if systems fail and manual work arounds are deployed then the systems will have to be updated once they return online. Portworkers must have a good understanding of the end-to-end process flows, systems decision logic and timelines and the functionality required to undertake problem solving and exception management.
It is hard to imagine how a modern terminal with several ships being simultaneously worked along a long linear quay from a single storage yard could operate without the support of computerised systems. For an
increasing number of terminals there is a total dependency on systems to perform their primary landside and marineside operations. The modern terminal requires employees prized for their IT literacy and problem solving attitude. The focus and style of human resource management in terminals must adapt to this fundamental change occurring in the workforce by
reviewing the impact it has on its selection, development and retention policies. Likewise the training provided to existing and new staff must be developed to equip them with a broader understanding of the business processes and to have an understanding of the impact their actions have on the overall performance of an operation.
Couper A (1985), Social Consequences of Maritime Technological Change. Washington Sea Grant Program, Washington.
Dally HK (1979), “Systems Analysis - 1: Study of Deep-sea Multi-User Berths.” In: Containers - Their Handling and Transport: A Survey of Current Practice. Cargo Systems International, London.
Erichsen S (1966), "The Need for Pre-planning and Centralised Supervision of Cargo Handling - Essential to Owners with a General Change to Unitised Cargo.” ICHCA Journal (April), pp. 13-9.
Groeneveld AP (1966), “Containers: a rational solution for the user.” In: Europort Congress, Netherlands.
Johnson KM & Garnett HC (1971), The Economics of Containerisation. George Allen & Unwin, London.
Martin J (1999), Inter-Organisational Relationships in the Container Transport Industry. PhD Thesis, University of Wales, Cardiff.
National Ports Council (1970), Digest of Port Statistics 1970. National Ports Council, London.
Thys J (1992), “Real-time Container Terminal.” In: 7th Terminal Operations Conference, Genoa. Cargo Systems, London, pp. 159-62.
Verstraete E (1977), Container Fleet Tracing and Computers. 2nd
International Container Industry Conference, Cargo Systems International, London.
