Redefining Terminal Automation: Progressing towards a Solution Framework – Status November 2024 (2024.13 Release)

This document outlines the approach taken to address the challenge of developing standardized references for terminal automation. This critical first step has provided a solid foundation for tackling the project’s various challenges and demonstrating the progress achieved across different working groups. The following sections will describe the established structure, explaining the progress made, and outline the upcoming steps.

TIC4.0 Automation TF (Context)

In April 2024, and after releasing an initial Whitepaper on Terminal Automation – the General Assembly celebrated in Valencia proposed to refocus the efforts on this taskforce:

1. Emphasizing the need for Terminal Operators to lead this effort.

2. With the established goal of framing a standards foundation in TIC4.0 that can help Automation Implementations to be more consistent and repeatable.

3. In turn, the efforts would ultimately enhance time-to-value for Container Terminal Automation. 

This section summarizes the content of various discussions held by the TIC4.0 Automation task force, particularly in the area related to System-to-System communication as part of the proposed scope for one of the task force’s working groups. The goals for the new iterations of the working group are as follows:

TF Way Of Working

Due to the complexity and scope of the terminal automation landscape, it is essential to define three key aspects in order to establish a standard reference. A first step is to define a process that reflects the specific functional needs of automated terminals. The second aspect is identifying the systems and interactions required to meet those functional needs that arise from the previously defined process. Finally, it will be necessary to ensure that the previously defined process aligns with the nomenclature, syntax, and semantics outlined in TIC4.0. These three key needs will be addressed by different working groups, each focusing on one of these fundamental aspects, to ensure a comprehensive and coordinated approach to the automation process.

With this in mind, the following breakdown in Working Groups (WGs) and preliminary scope have been discussed with different Terminal Operators and Solution Providers:

Efforts have been made to structure content development for each WG in a way that supports joint progress and establishes clear initial steps. In line with this premise, and as an introduction (further details will be provided in the following sections of the document), the first steps of each WG to achieve the TF's objectives in this initial stage are the following: WG1 will focus on presenting the Transport Function of the process outlined by HHLA, WG2 will elaborate on the existing information model to support that function, and WG3 will explain how this connects with the existing Job Instruction definition in TIC4.0.

In the document, some terms, such as "order," "command," and "status," are not always used according to the formal TIC4.0 definition. These terms are used in the industry and in everyday interaction between existing solutions (e.g. TOS or ECS). Part of the taskforce's work is to align and define these terms so that there is a standard and a common understanding for RFQs, specifications, and implementations.

In the following chapters the current progress and next steps for each of the workgroups are described. The workgroups individual results will be co-ordinated to fulfill the goal.

WG#1 End-To-End Processes

The working group utilized an approach deployed by HHLA, and proven in automated terminals like Altenwerden (CTA) or Burchardkai (CTB). This approach takes automation from a top-down perspective. By choosing this approach, processes can be mapped at a high level, including business objects and their related “order execution steps”. Furthermore, the different “building blocks” of the operating system and how automation affects them can be analysed as well.

The overall view of the processes, as explained by HHLA, is as follows, see figure ‘End-To-End Terminal Business Process’ for details:

1. At the beginning of the process, a customer, usually an operator, issues an order to the terminal operator. This order contains information about the container to be handled, the carrier involved, the activity to be done, i.e. loading or discharging the container, and the invoice recipient. In case that some of this information is missing, the administration has to contact the customer in order to clear the missing information. Once that is done, the order is CLARIFIED and ready for execution. 

2. Thereafter, all CLARIFIED orders belonging to a specific carrier are planned, i.e., their execution sequence and all required resources are determined. The result of this planning is an ordered sequence of transport demands, ready to be executed by the operating. 

3. After determining the chain of CHE types required to move the container from its current position to its target position, specific CHEs for each leg are selected and the move is executed. This changes the underlying order to EXECUTED, i.e., the order is now billable. 

4. Once the carrier left the terminal, all EXECUTED orders are billed and invoices sent to the invoice recipient. Related orders that are not EXECUTED are ABORTED and may or may not be billed to the invoice recipient.

 Note, that CLARIFYing an order is an important step in this process, since the terminal operator obligates itself to execute the order thereafter, as required by contract (and law).

Open

End-To-End Terminal Business Process

1. The focus for each of the processes' high-level mapping includes “business objects” and related “steps of order execution” with description of supporting data components. The focus of the subsequent definitions in system-to-system communication (WG2) and supporting data components (WG3) will be on the Transport function, as defined in the HHLA system architecture outlined below:

Open

HHLA Terminal Operating System

2. While the discussion covered specific functions described before like scheduling, dispatching or routing – and how those are translated to different functional split for connecting involved systems like TOS or ECS: it is emphasized from TIC4.0 that the System Architecture should be a conclusion and interpretation by each Actor, regardless of how each Terminal Operator decides how to employ and integrate TIC4.0 in their Digitalization and Automation strategies.

Proposed Next Steps

Define the planning and transport systems associated automation functions with the examples outlined in the other working groups – initially planning, scheduling, dispatching and execution.

WG#2 System-To-System Communication

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.

TIC4.0 provides a common and unambiguous language, so that the meaning becomes clear. For the sake of clarity, a glossary of the used abbreviations can be found at the end of the document as a reference.

As in other Industries with Automation standards like ISA-95* (see below in italics), the proposal is for TIC4.0 to become a reference standard by Terminal Operators and Solution Providers that can provide solutions and/or references to following points:

* The ISA-95 standard, also known internationally as IEC/ISO 62264, is an automation and control integration framework that helps bridge the gap between manufacturing operations and enterprise systems like ERP (Enterprise Resource Planning). By defining models and terminologies, ISA-95 enables standardised communication across different functions in manufacturing, from production activities to business-level logistics and planning.

ISA-95 organizes this integration across five functional levels:

• Levels 0-2 focus on the physical production process and involve actions like sensing, manipulating, and controlling equipment on the factory floor. These levels ensure real-time data is collected and managed through devices like sensors and control systems (PLC and SCADA).

• Level 3 handles manufacturing operations management, integrating various MES (Manufacturing Execution System) tasks. This level coordinates production workflows, scheduling, quality assurance, and maintenance, connecting plant operations with business goals.

• Level 4 addresses business planning and logistics, where ERP systems help determine production quantities, scheduling, and raw materials allocation using data from Level 3​.
  
  

The proposed approach can be later complemented by a reference System Architecture that ensures continuation on the functional hierarchy, and supporting protocols – in order to generate a uniform approach for Systems and Interfaces.

With above context, System-To-System Communication working group (WG#2) concentrates the efforts on the Transport Process that connects Planning with Execution at container movement level – the below scope is defined from the different discussions. The Working Group, in fact, performs a detailed breakdown of the “transport system” detailed in the previous section:

Building on the context above, the System-To-System Communication Working Group (WG#2) concentrates the efforts on the Transport Process that connects Planning with Execution at container movement level – the below scope was derived from the discussions that took place during the sessions:

The ultimate goal should be to generate a universal “TIC4.0 automation appendix” that could be integrated into tender or RFP documents, serving as an additional specification to comply with by Equipment and Solution providers.

• In turn, more “repeatability” and “uniformity” in automation implementations will be achieved across the Terminal Industry – as well as achieving enhanced interoperability between Equipment and Solutions (e.g. vendor locking avoidance).

Interface and Interaction Schemes

The conceptualized information model defines the data components to be exchanged between different functions for Terminal Automation, with core focus on the following:

(*) Execution & Control function will be defined as a transversal feature that can be covered by different Systems and at a central level also, with an important focus on instrumenting Exception Handling.

With the conceptualized interface, TIC4.0 can define the System-To-System Communication at information level in terms of:

1. How the above information components can support different interaction schemes to support different container movements,

2. under specific assumption about the functional split between Planning and Execution,

3. and taking into account the core functions of Scheduling and Dispatching.

• To illustrate an example related to those Interaction Schemes, below is a description of how the Order Information Component can be used to instrument the interaction between Planning – Scheduling – Dispatching – Execution functions, independently of the system performing those functions.
  
  

The working group highlighted the importance of defining an agnostic Information Model. This approach shall remain agnostic not only from the System’s Functional Hierarchy, which can prove difficult to “abstract”, but also from the interface technology or the transport mechanism employed to exchange those information components:

• Technologies utilised so far are diverse and go from webservices to databases or messaging supporting interfaces: TIC4.0 needs to support all existing ones but not restrict to any other and mostly guarantee modern & new technology receives support for adoption if applicable and if beneficial for Terminal Automation purposes

Proposed Next Steps

Start by defining more detailed sequence diagrams and schemes to “dissect” the definition of interactions between the defined functional components.

• MS Visio diagrams are provided with a model that assumes Scheduling function at TOS level and ECS (Equipment Control System) performing a central role to all CHE types - and in connection with PLC, IOT, PDS of each.

WG#3 Supporting Data Components

The existing TIC4.0 definitions and data models already cover most of the data components necessary for the automation application described in WG#1 and WG#2. The WG#3 will link the automation data points required to the existing TIC 4.0 data catalogue and will expand the missing definitions.

The reference used by the Working Group is based on the approach taken by TIC4.0 for the existing definitions of the relevant data components, such as Job Instruction.

From the different discussions, it was concluded that TIC4.0’s current definition of Job Instruction supports the approach based on the following:

1. define the supporting data components for the defined functions in the system-to-system communications interfaces and interactions definition.

2. and also between the automation functions defined.

Before moving forward to the description of the data components that are part of the Job Instruction process, it is important to explain two critical aspects of TIC4.0 semantics, which help clarify how the standard can support the concepts defined in the two previously mentioned WGs. These two fundamental elements are the Point of Measurement (pom) and the Point of Measurement in Time (pomt). By using these two elements of the semantics, it is possible to represent the necessary "when" and "where" to capture past, present, and future contexts. Below are the descriptions of the aforementioned elements.

pom: Where in the subject (device or process)

• Input (IN; Command; Request; Demand): External (from the cabin, remote control, Autonomous control, etc) order (input, instruction, signal) to the SUBJECT (CHE/TOS/Gate) requiring one action or status to be observed and represented by a value. For a process SUBJECT is the input to the process (start).

• Output (OUT; Result; Final result): direct information from a sensor about the action or status to be observed. The output is a direct measurement confirming the Observed Property VALUE. For a process SUBJECT is the output to the process (end).

pomt: Where/When in the timeline

pomt (Point of Measurement Time) Defines when in time the VALUE is expressed (future, present or past) in reference to the moment when the information was created. Default format ISO 8601. Although the pomt defined in TIC4.0 are more extensive, for discussions on the representation of orders, commands, and statuses in TIC4.0, the following three pomt are sufficient:

• Request: indicates the requirement to the owner of the action to do an action/status (concept) in the future in a certain way and time.

• Planned: indicates the intention of all the actors to do an action/status (concept) in the future in a specific and detailed way and time.

• Actual: indicates that the value property of the concept is actually observed.

The table below lists the concepts (statuses and events) already defined in TIC4.0 that describe the Job Instruction Lifecycle. This previous work, completed by the Job Instruction Task Force, should serve as input for discussions aimed at identifying gaps between the current traditional process and the future process related to Terminal Automation, to be represented in TIC4.0.

Proposed Next Steps

Connect the detailed sequence diagrams defined by the WG#2 with the Job Instruction nomenclature, terms and semantics based on existing model in TIC4.0.

This will support also how the planning, scheduling, dispatching and execution functions are defined. By doing this from both the data component’s and interoperability’s point of view, both can serve as a standard input for RFPs by Terminal Operators when procuring Equipment, Systems or Solutions.

Proposed Next Steps and Summary

This document outlines the progress made towards establishing standardized references in terminal automation, under the guidance of the TIC4.0 Automation Task Force. The work aims to develop a reference for future developments in container terminal automation, with a focus on consistency, repeatability, and reducing the time to implement automation projects.

In response to feedback from TIC4.0 members, the Task Force has been restructured to align efforts with this goal, leading to a collaborative approach between Terminal Operators and Solution Providers. This collaboration ensures that diverse perspectives are considered and a framework is built in the near future.

The creation of three distinct Working Groups (WGs) has allowed for parallel progress in key areas:

• WG#1 End-To-End Processes: has focused on mapping high-level terminal processes and identifying key functions based on proven methodologies, such as those used by HHLA. In this first work cycle, the Transport Function from the HHLA process was addressed.

• WG#2 System-To-System Communication: is working on developing guidelines for seamless communication between critical systems, such as TOS and ECS, without imposing specific technologies. Based on the WG#1 topic, the work has focused on identifying the main components supporting the transport function, which are Order, Command, and Status.

• WG#3 Supporting Data Components: has concentrated on the data requirements necessary for effective automation. During this period, decisions were focused on identifying whether existing definitions in TIC4.0 could support the transport function, particularly components such as Order, Command, and Status, with the TIC4.0 Job Instruction definitions serving as the foundation for this task.

The combined efforts of these WGs are directed toward a broader objective: creating a common standard for terminal automation that can be universally applied. This standard aims to serve as a reference in Requests for Proposals (RFPs), providing clear expectations for Equipment and Solution Providers.

Next steps:

In the next phase, the focus will be on improving co-ordination between the different Working Groups (WGs) to ensure alignment with the overall goal. The specific steps for each WG will be as follows:

• WG#1:

  • Further define automation functions related to planning and transport systems.

  • Build on examples from other WGs, with an initial focus on planning, scheduling, dispatching, and execution.

  • Ensure a cohesive approach to these core functions.

• WG#2:

  • Develop detailed sequence diagrams and workflows to clarify interactions between functional components.

  • Create MS Visio models assuming the scheduling function at the TOS level.

  • Ensure the ECS plays a central role across all CHE types.

  • Consider connections with PLCs, IoT systems, and PDS for each equipment type.

• WG#3:

  • Integrate the detailed sequence diagrams with Job Instruction terminology.

  • Ensure alignment with the existing nomenclature and semantics in the TIC4.0 model.

  • Ensure full alignment of job instructions with the standards required for terminal automation.

Glossary Table: