TIC 4.0

Whitepaper Terminal Automation

Owned by NextPort
Last updated: may 13, 2024 by Valenciaport Foundation
11 min read

Introduction

Terminal Automation is a continuously evolving industry trend, which all Terminal Operators have relied upon in order to achieve greater levels of efficiency, safety and sustainability.

  • The efficiency  benefits are normally identified with more consistent and reliable performance (24x7), gaining a more repeatable and predictable productivity.

  • The safety benefits and values are usually underestimated or forgotten, as the automation of equipment handling is generating safer working environments and in general, more system oriented and process driven jobs.

  • The sustainability benefits are related to handling equipment electrification (zero emissions) but also due to the machinery suffering less shock loads and in general consuming less energy while extending their lifecycle.

Another important aspect from Terminal Automation is its power as an enabler of #Future-of-Work for new generations. It brings talent to our industry with technical and analytical skills in high-demand in order to work with sophisticated systems and to learn in harmony with the digitalization and automation of Terminal Operations.

Having said that, during recent decades Terminal Automation went through different inflection points, and quantum leaps, where technology and its integration were taken to the next level by major projects that were implemented across the globe: to the examples created in Hamburg and Rotterdam in the 1990s, evolving in the 2000s with new Projects in Virginia, Busan, Algeciras, London, Abu Dhabi and in the 2010s again in Rotterdam but also Long Beach, Qingdao, Shanghai, Melbourne and Tanger.

In general, all of these projects were very different from each other, with an overall industry impression that each one was "reinventing-the-wheel" with the same Terminal Operator and Solution Providers trying different solution architecture, integration patterns & interfaces as they went into each project.

The expectation of Terminal Operators having "all-operations-recorded" with data pointing in specific directions for continuous improvements and optimization has not been fulfilled today.

Data is produced, but it is not always useful, because it is difficult to generate a precise understanding of handling processes from all existing systems.  

Problem Statement

Holistically, Terminal Automation is assessed as complex, risky, immature, etcetera and, in some cases, not worth the effort and investment as it does not guarantee the expected outcome.

Implementing Automation has historically taken too long in order to leverage its benefits and further its potential.

Let us evaluate which are the main problems, from both the Terminal Operators and the Solution Providers point of view.

Problems Terminal Operators are facing:

  • There is no reference implementation for Terminal Automation: what are the functional components, what are the technical components, how to integrate these.

  • It is not possible to make an apple-to-apple comparison across solutions when evaluating different providers that offer an Automated Solution: in regards to requirements, specifications, scope but also pricing or certification.

  • There is no understanding about what Process Automation and Decision Automation are, with Terminal Automation being solely connected to Equipment Automation or Robotization.

  • There is little experience and expertise on Terminal Automation, and the project team or organizations needed to implement it are very different. It is difficult to teach, learn or get qualified without hands-on experience.

 Challenges Solution Providers are facing:

  • It is difficult to understand what the Terminal Operators aim to achieve when implementing Automation, with over-optimistic expectations both at project pre-requisite but also their outcome.

  • Terminal Operators are not deploying enough quality resources, with some grey areas like System Integration not clear enough in regards to responsibility and accountability.

  • The connection of Project Implementation stages like Civil Construction, Equipment Commissioning, Integration Testing, Staff Training, etc. are not well connected and "punch-lists" are inherited from one stage to another.

  • It's difficult to work across Solution Providers with continuous improvements and optimizations, as the Customer-Provider relationship is too rigid and not data-driven. In general a ‘not-my-problem’ attitude is adopted.

Probably as a consequence of the above, Terminal Automation projects often fail to deliver upon the expected efficiencies and while doing so they take too long, normally with major efforts to get there which may result in the ‘not-worth it’ feeling for Operators.

What can TIC4.0 do?

TIC4.0 has a focus on getting Terminal Digitalization to the next level via standardization and interoperability. Digitalization is becoming a pre-requisite for Terminal Automation and the proposal is that TIC4.0 establishes some guidelines in the industry in order to ease Automation and facilitate associated System Integration. Finally, to make sure Terminal Automation provides the expected level of precision and quality in regards to Data 'production', it needs a pre-defined Data core as a foundation to ensure Terminal Automation solutions will function properly.

TIC4.0 also provides a common and unambiguous language, so that the meaning becomes clear. Therefore, a glossary can be found at the end of the document to have a reference for the used abbreviations.

As in other Industries with Automation standards like IS-95, the proposal is for TIC4.0 to become an authorized party by Terminal Operators and Solution Providers in order to establish publications and subsequent standards that can provide solutions and/or references to following points:

FUNCTIONAL HIERARCHY

Conceptualize the system functions that are part of a generic Terminal Automation solution: defining the high-level scope for each of the functions and leaving flexibility for the specifics of the solution implementation, thus framing a generally applicable functional architecture.

SUPPORTING DATA COMPONENTS

For each of the defined functions a clear understanding of function Input, Configuration and Output: and supporting Data Components which can be related to the Output, but also the required data for each function to perform correctly (having quality, timely, consistent input).

SOLUTIONS INTEROPERABILITY

With functions and supporting data defined by TIC4.0, shaping an interoperability framework for defining Solutions interfaces & interactions will be more straightforward - without specifying technology specifics but more on the underlying integration patterns and data consistency guidelines.

 Goal for Terminal Automation Taskforce:

Above points can be endorsed as pre-requisites when a Terminal Operator is launching a tender for Terminal Automation and also in the different processes for acquiring the different components needed in order to realize a Terminal Automation Project. 

Any contribution of TIC4.0 needs to be Solution Agnostic. In addition the main topic, Exceptions Handling needs to be included into the further discussions. 

Terminal Automation Functional Hierarchy

Please find below the schema which illustrates the Terminal Automation Functions discussed herein.

In the below table you can find an outline of the high-level description and context for each of those functions and the subsequent review for each of those identified processes in the Terminal Automation Functional Hierarchy:

Planning Process -
Standard Functions

Supporting Data

System Solution

Berth planners assign space and time windows to vessels based on Carrier SLAs.

 Schedule Proforma

 Vessel Geometry

TOS

In-house Solutions

Vessel planners sequence containers and assign them to cranes and shifts for a vessel.

Crane Split

New Optimization solutions

Yard planners establish the rules for container grounding and for discharge and selection of loads.

Work Queues

Yard Allocations

Gate throughput demand

Sometimes Simulation tools

 

Scheduling Process -
Standard Functions

Supporting Data

System Solution

From generated work queues and work instructions at Planning process, the scheduling process is calculating the best assignment coupling CHE with Move - the scheduling models can run with long-term (hours) or short-term (minutes) assignments.

 Terminal geospatial model

 From and To Position

 EMTs windows

 Work Queues (WQ)

 Work Instructions (WI)

 Transfer Areas

 CHE fleet and pools

 Routing Possibilities (physical)

 Driving Distances (& times)

TOS or ECS

External solutions for Optimization

 

Dispatching Process -

Standard Function

Required Data

System Solution

From generated CHE-Move assignment at Scheduling Process, the Dispatching process is realizing the move, ready for execution. It means it initiates the move of the CHE - and as part of this process different dispatch validations can be executed such as, move feasibility or cross-checking specific business rules (e.g. container #ID mismatch).

 CHE Status

 Wok Instruction (WI) Status

 Work Order (WO) (to be discussed)

 Routing Plan

 Transfer Zone & Point Status

 Area Restrictions

 Assistance functions (remote)

 Traffic Control

 Any other business rule

 ROS

 ECS

 

Move Execution Process - Standard Function

Required Data

System Solution

From generated Move dispatch at Dispatching Process, move execution makes the move happen in physical terms but also implies monitoring and control of the move. Also with regard to the movement itself (and its safety) and the parameters related to machinery stress, energy and other parameters.

Exceptions Handling:

  •  Area Restrictions

  •  (Remote) Assistance

  •  Traffic Control

  •  Any other business rule

 CCS

 ECS

 

Status Reporting Process - Standard Function

Required Data

System Solution

The ECS, or any other CHE sub-system (e.g. CCS or PLC), reports status and conditions about the CHE, or eventually a decision process. This information is important at different stages for the automated functions properly generating their required output: as well as for automation being flexible to react to operational changing circumstances.

CHE Status

Work Instruction (WI) or Work Order (WO) Status

Geometry Parameters

Transfer Zone & Point Status

 

 CCS

 ECS

IOT

Automation Functions Examples - Supporting Data Components

As expressed in the previous chapter, the explanation of each Terminal Automation function is complex and the supporting Data Components are many, which have a diverse interpretation across Solution Providers. It is proposed to use a couple of specific examples to conclude a Scope that can allow progress in TIC4.0 while keeping the approach for the whole Terminal Automation functional hierarchy.

 Goal for Terminal Automation Taskforce:

Conceptualize the different Automation Functions as outlined in the functional hierarchy, so these can be referenced from data components and application interface / interaction perspectives. It will ease understanding and alignment when evaluating different solutions and their required interoperability.

Automation Function Example: SCHEDULING

Background > One of the identified functions in the Terminal Automation functional hierarchy is Scheduling.

  • There are different ways to conceptualize Scheduling, from the Solution Providers point of view (CHE, TOS or ECS as examples).

  • TIC4.0 will be agnostic to the Solution specifics and will conceptualize the Input, Config and Output required to perform the Scheduling function properly.

  • The purpose of the Whitepaper is to utilize Scheduling as an Example of the Data Components that are required to be standardized, in order to ease Automation Implementations and associated Solutions interoperability.

Scheduling Function Defined:

It translates high level planning into executable container moves/steps, where each step is assignable to a single piece of equipment. Scheduling should also infer due times for each step based on the planning deadlines.

Scheduling aims for optimal equipment usage, consider all applicable constraints such as container impediments or blocked areas of the terminal, and overall operational efficiency/performance.

Initial Concept > Following sketch outlines the Scheduling function from Input / Config / Output perspective:

 

imagen-20240229-094840.png

Proposed definition for Scheduling = {calculating / projecting the steps that each Container Movement will need to follow}.

The Table below refers to the definitions that will be taken to the next level by TIC 4.0 Automation Taskforce:

Scheduling Function Definitions

Scheduling Function Definitions

The Planning stage produces 'Work Instructions' (WI) and 'Work Queues' (WQ) / 'Work Packages' (WP) where 'Terminal Work' is allocated as preliminary

The concept of 'Meeting Times' across those steps are highlighted as a required Output from the Scheduling function

The concept of 'Available Executors' across CHEs and Zones are highlighted as a required Config for the Scheduling function

The concept of 'Pools' across CHEs is highlighted as a required Config for the Scheduling function, and its work assignment plan

The concept of 'Preassigned Work' is recommended as the boundary between Scheduling and Dispatching, it differs between Solutions

The concept of "Point Of Work" (POW) is important to allocate Work to Resources, but differs between Solutions so it will be conceptualized

The functional split by Solutions Providers between "Scheduling vs Dispatching" is diverse so it is important that the results of Terminal Automation Task Force are simple & agnostic

It has been discussed and agreed that other connected topics like "TZ Decking" or "Yard Path Model" are another level of complexity that should be considered in the future.

Automation Function Example: ROUTING

Background > One of the identified functions in Terminal Automation is Routing, not in the initial functional hierarchy, but a pre-requisite for Scheduling or Dispatching and fundamental for enabling Autonomous Equipment.

  • According to the discussions with Experts, the Routing function and its output is highly dependent on the Solution,

  • More input from Equipment Suppliers is necessary: also in the field of Autonomous Terminal Trucks;

The purpose of this Whitepaper is to utilize Routing as an Example of the Data Components that are required to standardize in order to ease Automation Implementations and associated Solutions interoperability.

Initial Concept > Following drawing outlines the Routing function from Input / Config / Output:

For a basic understanding, the following definition is proposed on Routing = {calculating the route for a particular move (or a section of it) that it is going to execute, and the parameters for the eventual driving}.

The Table below refers to the definitions that will be taken to the next level by TIC 4.0 Automation Taskforce:

Routing Function Definitions

Routing Function Definitions

Routing Component is a CHE level and it differs from CHE type (AGV, TT, Straddle Carrier, etc.).

Routing is very important for Scheduling, and also for establishing movement on suitable path calculations:

  • how frequent Schedulers will need Routing info and how to react to Deadlocks is an example,

  • but Scheduler might not need Routing input for assignment in some specific cases (e.g. Yard Move).

Drive Times is a fundamental Data Component that TIC4.0 might consider as focus for standardization:

  • the accuracy of Drive Time calculations might differ (discussion around autonomous vehicles).

There is strong dependency on some other definitions like Path Models for the geospatial modeling of Terminal areas: more in general a Digital Representation of the Terminals and its movement & traffic rules:

  • Path Models, in general GIS, requires a deeper dive to conclude what TIC4.0 should do (if anything).

Conclusion and Next Steps

In its mission to define Terminal Industry standards and to promote technology solutions interoperability, TIC 4.0 frame this whitepaper as an initial dissertation with following Objectives:

  1. Present to TIC 4.0 audience the current Challenges and Constraints for Terminal Automation adoption.

  2. Highlight to the importance of presenting Digitalization as a pre-requisite to effective Terminal Automation.

  3. Conceptualize a Functional Hierarchy that can help the discussion around required solutions functions.

  4. Define those functions and describe the Data Components that support those functions.

At this stage, the functions and core data components are outlined for further definition and discussion - it is important to remark the definitions so far are completely agnostic to which System performs which function.

As Next Steps the proposal is to breakdown the Terminal Automation taskforce in different sub-working groups that can take to the next level the definitions and can propose standards on supporting data components to selected functions:

  • The Scheduling function, and the subsequent (re) definition of WI, WQ and WP, is a fundamental one: the different implementations across the Industry doesn’t provide clarity on those definitions,

  • The Routing function, and the subsequent (re) definition of Drive Times and Path Models, is another fundamental one: standardizing those will help this function and its supporting role to others,

In general, and for Terminal Operator consideration - the end goal of this taskforce can be to structure a set of definitions that help framing the Equipment and Solution Providers proposals to RFP processes that can generate a more comprehensive and predictable outcome from those:

  • The definition of interfaces between different Systems (e.g. TOS & ECS) to support the mentioned functions is another area that must be deeply analyzed for proposing specific action in those.

 Overall Goal for Terminal Automation Taskforce:

Conceptualize the different Automation Functions as outlined in the functional hierarchy, so these can be referenced from data components and application interface / interaction perspectives. It will ease understanding and alignment when evaluating different solutions and their required interoperability.

Glossary

Abbreviation

Meaning

Abbreviation

Meaning

AGV

Automated Guided Vehicle

CCS

Crane Control System

CHE

Container Handling Equipment

ECS

Equipment Control System

EMT

Estimated Move Time

GIS

Geographic Information System

POW

Point of Work

ROS

Remote Operation Station

TOS

Terminal Operative System

TP

Transfer Point

TT

Terminal Truck

TZ

Transfer Zone

WI

Work Instruction

WO

Work Order

WP

Work Package

WQ

Work Queue

IOT

Internet Of Things (device or system)

Relevant References and Articles

For further reading please find the following references and articles. Please note that some references refer to some solution providers. TIC4.0 is solution agnostic whilst utilizing available resources. There are more solution provider offering their services then below mentioned.

(1) TU Delft System Engineering, PhD Yvo Saanen

(2) https://www.bcg.com/publications/2018/to-get-smart-ports-go-digital

(3) https://www.konecranes.com/discover/path-to-port-automation-whitepaper

(4) https://www.mckinsey.com/industries/travel-logistics-and-infrastructure/our-insights/the-future-of-automated-ports

(5) Automation Standards, PTI 2016

(6) https://porteconomicsmanagement.org/pemp/contents/part3/terminal-automation/

(7) https://www.kalmarglobal.com/automation/kalmarone/

(8) https://patentimages.storage.googleapis.com/d4/fb/c2/5ef12827bccec8/EP2863349A1.pdf

(9) https://www.pema.org/wp-content/uploads/2022/09/PEMA-IP12-Container-Terminal-Automation.pdf

(10) https://www.plm.automation.siemens.com/global/en/our-story/glossary/isa-95-framework-and-layers/53244

(11) https://maritime-executive.com/features/oscar-pernia-talks-terminal-automation

© Copyright - TIC 4.0 All rights reserved | Design web by Fundación Valenciaport