The attached PDF is an edited and condensed version:

Open

Executive summary

The TIC4.0 Whitepaper on Terminal Automation outlines the industry’s roadmap toward a standardized, interoperable framework for automating container terminals. Automation promises major gains in efficiency, safety, and sustainability, but progress has been hindered by fragmented technologies, inconsistent data models, and the absence of common reference architectures. To address this, TIC4.0 acts as a neutral, vendor-agnostic body developing shared data semantics, functional hierarchies, and process models that enable scalable and repeatable automation.

The current phase operationalizes these concepts through a Task Force on Terminal Automation and three Working Groups focusing respectively on:

1. Mapping end-to-end terminal processes and automation impacts;

2. Defining consistent system-to-system information flows;

3. Extending TIC4.0’s semantic model with precise definitions for automation workflows.

A key deliverable will be a TIC4.0 Automation Appendix — a standard reference for tenders, helping operators and vendors design and procure automation systems based on a harmonized functional and data framework.

Despite growing adoption of automated and semi-automated terminals, significant challenges remain: high capital costs, long payback periods, legacy infrastructure, fragmented IT/OT systems, and limited interoperability, especially at the interface and process alignment levels. Workforce reskilling, social acceptance, regulatory constraints, and cybersecurity also pose major hurdles. Overcoming these barriers requires shared standards that align business, operational, and control layers.

To fill this structural gap, TIC4.0 proposes adapting the IEC 62264 (ISA-95) “Enterprise-control system integration” standard — widely used in manufacturing for enterprise–control system integration — to the port environment. This framework defines standardized functional levels (from business planning to physical process control), data objects, and workflows that ensure interoperability between Information Technology (IT) and Operational Technology (OT) systems while remaining technology-agnostic. Its application in other industries (mining, pharma, oil & gas, SMEs) has proven its flexibility and scalability, making it an ideal foundation for port automation.

Within terminals, the adapted model introduces clear functional levels:

• Level 5: Business Intelligence (strategic insights and analytics). This level, not present in IEC 62264 (ISA-95), has been added as an overarching concept, since all monitoring results might be used to obtain valuable insights and data.

• Level 4: Business Planning & Logistics (order management, billing, planning, resource forecasting, maintenance)

• Level 3: Operations Management (scheduling and coordination)

• Level 2: Supervision & Control (real-time dispatching and monitoring)

• Level 1–0: Machine control, sensors, and physical execution

This hierarchy connects commercial intent with operational reality, ensuring consistent data flow and progressive automation across manual, semi-automated, and fully automated terminals.

A successful implementation depends on balancing standardization with flexibility. This very important insight results from intense discussions within TIC4.0 among Terminal Operators and Solution Provider and still remains to be discussed. The adapted model emphasizes three key attributes:

1. Compatibility – integration with existing and legacy systems, both in greenfield and brownfield contexts.

2. Flexible Decision-Making – allowing for different levels of automation to distribute operational authority according to the philosophy of the individual terminal.

3. Future Development – scalability to support emerging technologies, decentralized decision-making, and autonomous operations.

By adopting this framework, TIC4.0 aims to reduce risk, improve interoperability, shorten implementation times, and create a sustainable pathway for terminal automation aligned with global industry standards.

Cybersecurity, in turn, shall be taken into account when designing interfaces, systems and other aspects of an automated terminal, as for example defined in IEC 62433 Industrial Security. However, as a final note, please bear in mind that it is not in the scope of this Task Force/White Paper to establish cybersecurity requirements.

Background and Context

The TIC4.0 Whitepaper on Terminal Automation (published in March 2024) and its subsequent update, Redefining Terminal Automation: Progressing towards a Solution Framework (published in November 2024), together outline the vision, challenges, and progress of efforts to create a standardized framework for automating container terminals. At the heart of both documents lies the recognition that automation in ports holds enormous potential to improve efficiency, safety, and sustainability, yet projects often fall short of expectations due to fragmented solutions, lack of reference models, unclear objectives, and weak integration across systems. Terminal operators face difficulties in navigating inconsistent technologies and limited expertise, while solution providers struggle with imprecise requirements and insufficient coordination. To address this, TIC4.0 positions itself as a neutral, solution-agnostic body capable of providing the common language and standards needed to bridge these gaps.

The first whitepaper establishee the foundations: a functional hierarchy of automation processes, the identification of supporting data components, and the need for interoperability across diverse systems. By doing so, it seeks to enable clearer tendering processes, reduce risk, and make automation solutions more scalable and repeatable. The November 2024 update demonstrated how these ideas are being operationalized through a dedicated Task Force and three Working Groups. The first group focuses on mapping end-to-end terminal processes—from order initiation to billing—and analyzing how automation alters their execution. The second group is dedicated to system-to-system communication, identifying how information such as orders, commands, and status updates should flow consistently between systems like terminal operating systems (TOS) and equipment control systems (ECS). The third group builds on existing TIC4.0 semantics, extending data models such as the job instruction lifecycle and introducing concepts like Points of Measurement in space and time to ensure that automation workflows are grounded in precise, shared definitions.

Together, these efforts represent a transition from conceptual ambitions to structured implementation. The initiative emphasizes that interoperability should remain technology-agnostic, ensuring flexibility across different integration models while maintaining semantic consistency. A key long-term goal is the creation of a TIC4.0 Automation Appendix that can be attached to tender documents, giving operators and vendors a unified reference point for designing, procuring, and deploying automation systems. By providing a harmonized framework of functions, data definitions, and interaction models, TIC4.0 aims to accelerate the digital transformation of ports, reduce project risks, and bring the industry closer to realizing the full benefits of terminal automation.

Challenges for Automation in the terminal industry: system integration, inconsistent data, and long implementation cycles.

Terminal automation is advancing rapidly as ports seek greater efficiency, safety, and sustainability, with semi- and fully automated terminals becoming increasingly common, particularly in new greenfield projects. The trend is driven by the integration of digital technologies such as IoT, artificial intelligence, predictive analytics, and real-time monitoring, which allow for more reliable planning, optimization of vessel calls, and predictive maintenance. At the same time, automation is closely linked to environmental goals, with electric equipment and energy optimization helping ports reduce their carbon footprint. The shift is also reshaping the workforce: operational jobs are giving way to more technical and data-oriented roles, requiring reskilling and careful management of social impacts. Taken together, these tendencies point to a growing market for automation solutions, with operators pursuing 24/7 operations and more consistent performance to handle congestion and global trade pressures.

Yet significant challenges remain. The most pressing is the high cost of automation, with long payback periods that make investment difficult for smaller or less busy terminals. Many facilities must also contend with legacy infrastructure (in some cases, limited bandwidth and latency) and fragmented IT systems, which complicate integration and create data silos that undermine visibility and interoperability. Operational risks during the transition are another concern, as converting a manual or semi-automated process to a semi-automated or fully automated one can disrupt throughput and efficiency. Moreover, automation of terminals works best under predictable conditions, but ports must often deal with irregularities such as weather, equipment failures, or customs delays, which demand flexible exception-handling. Beyond the technical dimension, workforce adaptation and labor relations present persistent obstacles, as unions and employees express concerns about job security. These issues are compounded by regulatory hurdles, safety certifications, and the growing need to secure increasingly digital operations against cyberattacks. Finally, terminals must ensure that automated systems are robust against environmental stresses and supported by adequate electrification and grid infrastructure.

In short, while terminal automation is poised to transform global port operations through digitalization, sustainability, and greater reliability, its widespread adoption will depend on overcoming steep financial, technical, and social barriers, and on developing shared standards to reduce risks and ensure interoperability.

Lack of a Standardized Integration Structure

Despite the growing momentum behind terminal automation, there is still no standardized structure or reference model that defines how different functions should be integrated and interact within a terminal environment. Each terminal—depending on its size, geography, and operational philosophy—adopts its own interpretation of automation, leading to a large variety of architectures and functional hierarchies. As a result, projects remain largely bespoke, with limited potential for reuse or scalability. What proves efficient in one terminal often requires substantial redesign in another, increasing costs, complexity, and implementation times.

The absence of a common integration structure is particularly evident in brownfield environments, where existing assets, workflows, and digital tools were not originally conceived for automated coordination. In practice, the lack of standards does not allow to copy solutions (functions or functional logics) from one project to another, even if two terminals are performing in similar ways or have similar processes. This also hinders to levy synergies.

The lack of shared definitions of where one function ends and another begins—whether related to planning, control, or execution—creates ambiguity and dependency on proprietary interpretations. This fragmentation undermines the ability to harmonize data flows and operational behaviour across the sector.

To address this, the industry should avoid “re-inventing the wheel” and instead draw inspiration from reference models that have already proven effective in other industrial domains. The international electrotechnical standard IEC 62264 (equivalent to the North American ISA-95) provides a structured approach for defining the interaction between enterprise and control domains. By establishing hierarchical levels and standardized information exchanges, it enables consistent communication between functional layers—business, operations, and equipment. Translating these principles into the port environment could lead to a generic reference architecture for functional and system integration, serving as a foundation for TIC4.0’s harmonization efforts while maintaining flexibility across both greenfield and brownfield implementations.

Target of the Terminal Automation Task Force

The target of the Task Force Automation is to develop a technology agnostic framework, and provide data standards and an ontology to improve future Terminal Automation projects: reduce risk, improve interoperability, reduce implementation time, improve repeatability, being vendor neutral.

IEC 62264 Description

IEC 62264, based on the North American ISA-95 standard, is an international standard for enterprise–control system integration. It establishes common models, terminology, and interfaces so that manufacturing systems (like Manufacturing Execution Systems (MES), Supervisory Control And Data Acquisition (SCADA) or shop-floor automation) and enterprise systems (such as ERP, logistics, and planning) can work together more seamlessly. The standard is widely used across industries to support Industry 4.0, digital manufacturing, and IT/OT convergence.

Its main objectives are to:

• Facilitate interoperability by defining standard object models, attributes, and transaction structures.

• Reduce risk, cost, and errors when integrating business systems with manufacturing operations.

• Provide a common vocabulary and activity models for engineers, IT staff, and business stakeholders.

• Support modular, scalable architectures that evolve with technology.

The standard is structured into several parts, each addressing a different aspect of integration:

• Part 1 – Models and Terminology: defines the scope, terminology, and functional boundaries between enterprise and control systems.

• Part 2 – Object Model Attributes: specifies standard data objects and attributes exchanged between systems.

• Part 3 – Activity Models: describes the workflows and functions of manufacturing operations.

• Part 4 – Manufacturing Operations Management (MOM) Integration: refines object models for integration within manufacturing operations management.

• Part 5 – Business-to-Manufacturing Transactions: details the types of transactions between enterprise systems and manufacturing systems.

• Part 6 – Messaging Service Model: defines abstract messaging services to support information exchange in a technology-agnostic way.

In practice, IEC 62264 is often implemented using B2MML (Business to Manufacturing Markup Language), which translates the models into XML schemas, or through Open Platform Communications (OPC) Unified Architecture (UA) information models, which embed the standard’s concepts into industrial interoperability frameworks.

The areas of application include:

• Integration of shop-floor automation (PLCs, SCADA, MES) with enterprise IT systems (ERP, SCM).

• Process, batch, and discrete manufacturing industries with complex operations.

• Industry 4.0 and digital factory initiatives where standardized data exchange and system interoperability are crucial.

• Projects requiring a clear mapping between level 3 (manufacturing operations) and level 4 (enterprise planning) in the automation hierarchy.

The following section presents the functional hierarchy defined by the IEC 62264 (ISA-95) standard. This framework divides industrial activities into five levels — from business planning to the physical process — providing a structured model to understand how information flows between enterprise systems and plant operations.

• Level 4: Business Planning and Logistics
  Level 4 defines the functions that manage and coordinate the organization as a whole. It establishes objectives, allocates resources, and sets the conditions under which operations take place. Information from this level guides lower levels, ensuring alignment between enterprise goals and operational execution.

• Level 3: Operations Management
  Level 3 coordinates and oversees the execution of operational activities within a facility or network. It manages resources, monitors progress, and ensures that operations are carried out according to the objectives and constraints defined at higher levels.

• Level 2: Supervision and Control
  Level 2 manages the real-time supervision and control of processes and assets. It executes operational instructions, maintains stability and safety, and provides continuous feedback on process status and performance to higher levels.

• Level 1: Sensing and Actuation
  Level 1 includes the devices and components that measure and influence the physical process. Sensors, actuators, and other field devices collect data and execute commands that enable automated control.

• Level 0: Physical Process
  Level 0 represents the actual physical activities taking place in the field — the transformation, movement, or interaction of materials, energy, or information that the higher levels monitor and control.

Examples / Case Studies beyond ports

1. Product Information Traceability via Architecture Frameworks
   A case study mapping the IEC 62264 models onto the Zachman framework explored their use for product traceability across the product lifecycle. By using IEC 62264 to define generic logical models for exchanging product and process information, the authors helped design information systems to capture traceability not just during production but across design, logistics, and disposal phases. SpringerLink

2. Small/Medium Enterprises (SMEs) in Wood Processing + Production Planning under Variable Energy Costs
   A SME in wood processing faced problems with variable production loads and electricity pricing. Researchers proposed using IEC 62264 models to standardize operations and enable optimization (short-term planning) under energy market fluctuations. The standard’s modeling helped structure production planning while integrating constraints like electricity cost forecasts. stumejournals.com

3. Mining Operations & IT/OT Convergence
   In mining, IEC 62264 (ISA-95) is used to bridge planning and execution across widely distributed assets (e.g. pits, plants, haulage, sampling). For instance, scheduling in mining must account for capacity, product grade & quality, equipment availability, team competency and safety. Applying IEC 62264 (ISA-95) helps integrate data from drilling, maintenance, logistics etc., improving prediction, scheduling, and productivity. isa.org

4. Pharmaceutical / Pharma 4.0 Setting
   Life sciences / pharmaceutical firms have rigid compliance and quality requirements. Some have used IEC 62264 (ISA-95) as a foundational model for developing data models/frameworks to connect MES, enterprise systems, data lakes, analytics, and IoT. For example, IEC 62264 (ISA-95) helps standardize naming/data structure, simplify the creation of unified namespaces for industrial data, making integration easier in regulated environments. pharmaceuticalonline.com

5. Information Security Policy Compliance in Oil & Gas
   One empirical study in oil & gas organizations used an IEC 62264 (ISA-95)-based framework (particularly its governance / structural components) to improve compliance with information security policies between “control / operational levels” (levels 2-3) and “enterprise level” (level 4). The standard’s clear definitions of functions, interfaces, roles helped in setting up governance practices. ACM Digital Library

6. Industry 4.0 Testbeds: Planning & Reactive Control
   In a research/industrial testbed setting (e.g. robotic cells linked by intra-logistics, shuttles, etc.), IEC 62264 models were used as the description of system state + capability. Then production planning tools (Planning Domain Definition Language (PDDL) planners) consume that model to generate production plans; changes in the IEC model (e.g. material availability, machine status) trigger replanning. This lets the system react to changes in near real-time. publik.tuwien.ac.at

Insights: Why & How IEC 62264 Works “Outside the Box”

These examples show some of the reasons IEC 62264 finds success in non-traditional or extended domains:

• Modeling flexibility: The standard is technology-agnostic and defines object models, activity models, transactions in a way that can map to many contexts, not only discrete manufacturing.

• Common vocabulary and structure: In sectors where processes cross over business, operations, logistics, health/safety, etc., having shared definitions reduces misunderstanding. This is of special significance for TIC4.0, given that TIC4.0 provides a “semantic model” designed for use with any ontology or dictionary.

• Better planning / optimization: When constraints go beyond production (e.g. energy cost, safety, regulations), the structured models help integrate those into planning or scheduling.

• Governance & compliance: Sectors like pharma or oil & gas can leverage the structural clarity in roles, responsibilities, data exchange, to support regulatory/compliance requirements.

Why was IEC 62264 (ISA-95) chosen?

Ensuring interoperability between systems, regardless of the specific case or region, is critical for modern industrial environments. Current “As-Is” setups often face limitations, as direct communication between the OT (Operational Technology) level and the Planning level becomes unfeasible due to firewalls and other security barriers, leading to challenges in error and exception handling. The separation of Information Technologies (IT) and OT technologies¹ is increasingly enforced by regulatory obligations, particularly in critical infrastructure sectors (CRITIS). To address this, IT and OT require a well-defined interface that enables reliable conversion and integration between the two domains. The IEC62264 (ISA-95) standard serves as a foundational framework in this context, providing guidelines for both cyber security and automation, and facilitating structured, secure communication across IT and OT systems.

¹ Hardware and software that detects or causes a change through the direct monitoring and/or control of physical devices, processes and events, as per IEC 62443-1-1:2013, Clause 3.1.68 (co-published as ISO/IEC 62443)

Lastly, an alternative framework: The Purdue model - based on IEC 62264 (ISA-95) - could also be used as an alternative to the standards. The Purdue Model and IEC 62264 (ISA-95) are complementary frameworks that guide industrial digitalization and system integration. The Purdue Model provides a hierarchical reference architecture, clearly separating OT (Operational Technology) and IT layers to enhance security, define responsibilities, and structure industrial processes from sensors and control systems up to enterprise systems. IEC62264 (ISA-95), in contrast, focuses on standardizing information exchange and workflows between manufacturing operations and enterprise management, particularly MES and ERP systems. While Purdue defines where systems sit, IEC62264 (ISA-95) defines how information flows between them, making the combination of both frameworks essential for achieving secure, interoperable, and efficient industrial operations.

Within the TIC4.0 taskforce for Automation it was widely discussed and finally agreed among Terminal Operators and Solution Provider to utilize IEC 62264 as the basic framework for the future.

Aligning with the standard IEC 62264 (ISA-95) brings the following advantages

• interoperability with proven standard

• future implementations will be easier → faster turnaround and implementation times

• terminal automation in line with proven standard for integration of business and
     control systems

Adaptation of IEC62264 (ISA-95) to the Port Terminal Sector

The adaptation of the IEC62264 (ISA-95) framework to this sector provides a structured model to describe the main interfaces between business, operational, and control layers. It does not define specific responsibilities or system boundaries, but rather offers a common reference to understand how these layers interact. This structure establishes a foundation for scalable and progressive automation across all terminal processes.

TIC4.0 Topology for Automation acc. to IEC 62264 (ISA-95)

The following figure shows the essential building blocks (functions) required for terminal automation, their assignment to levels according to IEC 62264, and their interrelations.

Open

Overview of Levels and sub-systems/sub-functions. Source: TIC4.0 Automation Task Force

Definitions of Levels and short description of building bricks

Modern port operations rely on a structured, hierarchical approach to manage complex systems, from the physical processes on the ground to high-level business decision-making. This hierarchy, often represented in levels 5 through 0, ensures that every aspect of the operation, ranging from field devices and sensors, through process control and fleet management, to enterprise resource planning and analytics, is clearly defined, coordinated, and optimized. By mapping responsibilities and data flow across these levels, organizations can achieve seamless integration, improve operational efficiency, and leverage real-time insights to make informed strategic decisions.

“Business intelligence (BI)”

In the context of port terminals, an additional layer — Level 5: Business Intelligence — is introduced above the traditional IEC 62264 (ISA-95) hierarchy. This level encompasses the systems and functions dedicated to aggregating, analyzing, and interpreting information from all other levels to support strategic decision-making, performance monitoring, and long-term optimization. While it does not directly control operations, it provides insights that guide policy, planning, and continuous improvement across the entire terminal ecosystem.

Interface to the Terminal Customer

The functions “Order Management” and “Billing” represent the main connection between the terminal’s operational systems and its external customers. They translate commercial requests into operational actions and ensure that completed services are properly recorded and charged. Together, they form the bridge that links customer interaction with terminal execution and business processes.

• “Order Management”
  The function “Order Management” handles the exchange of service requests between the terminal and its customers, such as shipping lines, freight forwarders, or inland operators. It manages booking requests, cargo information, and service orders related to vessel, yard, gate, or rail operations. This function ensures that all operational plans are based on validated customer requests and that order statuses are updated according to real-time execution feedback.

• “Billing”
  The “Billing” function manages the generation and validation of financial transactions derived from operational activities and customer orders. It consolidates service data, applies contractual rates or tariffs, and issues invoices to customers. This process ensures traceability between executed operations and commercial charges, maintaining alignment between operational performance and financial reporting.

Both functions belong to Level 4 (Business and Logistics), where the interface between commercial management and operational execution is defined.

Core Functionalities to Manage a Cargo Terminal

The Planning and Resource Forecasting functions form the core of the terminal’s operational coordination at the business level. They translate commercial and logistical objectives into actionable operational frameworks, ensuring that resources are anticipated and allocated according to future demand. Together, they provide the foundation for aligning capacity, assets, and labor with the expected flow of cargo through the terminal.

• “Planning”
  The “Planning” function defines the operational plans for carrier, cargo, berth, yard, gate, and rail activities (“What and How”, strategic and resource-focused). It establishes the framework for upcoming operations by integrating customer requirements, resource availability, and infrastructure constraints.

• “Resource Forecasting” (Equipment and Labor)
  Predicts the demand for equipment and labor based on planned activities and historical data, supporting informed decisions on resource allocation and workforce management.

These functions operate within Level 4 (Business and Logistics), serving as the link between commercial intent and the coordinated preparation of terminal operations.

Supporting Functionalities

Supporting functionalities ensure that the terminal can operate efficiently and without interruptions. Among them, Health and Maintenance are essential for keeping equipment and infrastructure in good working order and guaranteeing safe, reliable operations.

“Asset Health Management”
The function “Asset Health Management” oversees the condition and upkeep of the terminal’s assets. It includes monitoring, preventive maintenance, and timely repairs to avoid unexpected failures and maintain equipment availability. By aligning maintenance activities with operational needs, it helps sustain performance and extend the lifespan of key assets.

Within the Level 4 (Business and Logistics) scope, Health and Maintenance provide the link between long-term asset management and day-to-day operational reliability.

Fleet Management

The group Fleet Management coordinates the use of the terminal’s mobile equipment to ensure efficient and timely operations across all areas of activity. It connects planning decisions with real-time execution, translating operational requirements into specific equipment assignments and task execution. Fleet Management is grouping the two functions “Scheduling” and “Dispatching”.

“Scheduling”
“Scheduling” is the function responsible for transforming the planning intent (Work Queues, Work Packages and Work Instructions) into executable, time-bound job lists (When and In What Order, operational and time-focused).
It operates as the intermediary between the functions “Planning” and “Dispatching”, ensuring that planned work is converted into feasible sequences aligned with available resources, timing constraints, and operational priorities. This function operates at Level 3 (Operations Management), where planning and coordination are transformed into detailed work instructions.

“Dispatching”
”Dispatching” is the function responsible for executing - in real time - the job instructions prepared by “Scheduling”. It confirms or performs specific CHE assignments and dispatches job instructions, validates feasibility, monitors execution, and reports completion and exceptions.

It operates as the intermediary between “Scheduling” and Execution Control.

Execution Process

The group Execution Process encompasses the functions that directly carry out terminal operations. It translates operational instructions into physical actions through coordinated layers of control, monitoring, and interaction with the equipment and field devices that perform the work. Execution process includes the functions “Real-time asset supervision (SCADA)”, “Execution control”, “Machine Control” and “I/O, Devices, Sensors” and spans over Level 2, Level 1 and Level 0.

“Real-time asset supervision (SCADA)” and “Execution Control”
Operating at Level 2 (Supervision and Control), these functions manage the real-time execution and supervision of terminal activities. They collect and distribute operational data, coordinate task execution across equipment, and ensure that every process runs safely and in accordance with defined parameters. Together, they provide the control layer that connects operational planning with physical execution.

“Machine Control”
Located at Level 1 (Sensing and Actuation), this function governs the direct operation of cranes, vehicles, and other handling equipment. It executes movement commands, interprets sensor data, and ensures accuracy and safety during operations.

“I/O, Devices, Sensors”
At Level 0 (Physical Process), these elements form the interface between control and the physical environment. They detect and transmit process variables while executing low-level actions such as actuation, positioning, or signaling.

Together, these functions form the operational backbone of the terminal, linking system logic with the real-world processes that move cargo and operate equipment.

Conclusion for the TIC4.0 Topology for Terminal Automation

By structuring terminal activities across clearly defined functional levels — from enterprise management to field execution — this model provides a consistent framework for system integration and data flow. Although it does not prescribe specific responsibilities or technologies, it establishes a shared reference that supports interoperability among heterogeneous systems. This layered architecture enables port terminals to progressively introduce automation, connecting business intent with operational reality, and ensuring that every automated function operates within a coherent, scalable, and coordinated environment.

Ensuring successful adaptation: Standards Framework vs Real Word Implementation

After an internal collaborative evaluation involving industry experts, it became clear that the framework must balance standardization with practical applicability across diverse operational environments. To ensure a successful and sustainable implementation, three key attributes were identified as essential for the adapted model:

• Compatibility with existing solutions

• Flexibility for different philosophies (e.g. decision making process)

• Allowing future development while still being a standard

These principles form the foundation for aligning standardized data structures with real-world practices, enabling gradual adoption and interoperability across different terminal types and technologies. They represent the main learnings derived from the consulting and review process carried out with expert stakeholders.

What Do we Understand and Ensure: Compatibility

Compatibility refers to the framework’s ability to integrate seamlessly with the wide variety of systems, configurations, and automation levels currently present in port terminals. The adapted model must accommodate existing infrastructures and legacy systems—including those from brownfield projects—while remaining equally applicable to manual, semi-automated, and fully automated terminals.

This requires a flexible structure capable of describing the same operational logic regardless of technological maturity or organizational approach, ensuring that the framework is not limited to advanced or newly developed implementations. Moreover, as the boundary between scheduling and planning varies significantly among terminals, the model must tolerate these differences without forcing uniformity.

To achieve true compatibility, it is essential not to define every implementation detail rigidly, but to maintain an adaptable framework that can represent diverse terminal realities through a shared set of levels, functions, and data structures. Implementations in other industries, such as how the European Schuko Type F and Type E domestic power plugs can be made compatible with just a minimum change to the connector, show that interoperability can be achieved with minimum changes when standards allow for it. Therefore, the standard shall allow for “interoperability through flexibility”; by defining these general layers and common information elements rather than prescribing exact interfaces or workflows, the model provides a consistent foundation that each terminal can interpret according to its own systems and degree of automation.

This approach preserves interoperability while allowing evolution and innovation, ensuring that all terminals —regardless of complexity or automation level— can align under the same conceptual architecture without constraining their individual implementations.

What Do We Understand and Ensure: Decision Making

In the context of terminal automation the requirement of a subsequent function to alter decisions embedded e.g. in task orders is emerging as part of the discussions. The working title for this topic is 'decision modes', which could explicitly define the degree of autonomy granted to subsequent functions for altering decisions.

While the industry has not yet converged on a formal definition or taxonomy, it is increasingly clear that consistent classification of decision levels will be essential to ensure interoperability between Terminal Operating Systems, Equipment Control Systems, and automated assets. Although TIC4.0 is not defining these modes in detail at this stage, the association has already incorporated the topic in the following paragraphs to ensure alignment with future standards and support a coherent evolution of automation practices across the sector. Further investigation and discussion in the industry is required to conclude on whether ‘decision modes’ are required, for which information and how they can be incorporated into the existing TIC4.0 semantic.

Decision making within a terminal is not fixed to a single function or system. Depending on the operational setup, organizational philosophy, and level of automation, decisions may occur at different layers — for example, a Scheduler might decide which equipment performs a task, or a Dispatcher may assign the task during execution. Similarly, a Planner might define that a container must move from block A to block B, but leave open which specific handling equipment will execute the movement.

This flexibility is essential to reflect the diversity of decision-making processes across terminals. In some cases, downstream functions must be able to modify a proposed task or reassign resources without triggering rigid approval workflows and causing disruptions or confusion. For instance, switching from crane STS#1 to STS#2 to meet timing constraints should be possible without breaking system consistency or requiring manual intervention.

To ensure this flexibility, the adapted framework must not prescribe where or how each decision is made (i.e., what function shall be performed by what system/element), but rather define the information required to support autonomous and coordinated decisions at any level. By maintaining functional boundaries that are interoperable yet adaptable, terminals can determine the most efficient distribution of decision-making authority according to their operational model and technological maturity.

The current state of discussion suggests that the following levels of decision-making could be useful for a limited number of information:

• decision: mandatory to fulfil, can only be changed by the function, issuing the decision

• proposal: recommendation that can be changed with the obligation to be informed about change

• traverse/pass through: data that is only processed and might be of importance for the following functions

In the TIC4.0 semantic these levels could be implemented within the observed property and the exact functionality would be described in one of the coming releases.

This approach aligns with the IEC 62264 (ISA-95) topology while keeping decision-making logic modular. It allows automation to evolve progressively—from human-supervised to fully autonomous operations—without requiring structural redesigns of the functional model. Thus, the framework supports both current practices and future advancements in autonomous terminal control.

As stated earlier: Further input from the industry and discussions among the experts is required to come to a final conclusion on the topic of 'decision modes'.

What Do We Understand and Ensure: Future Development

Future development refers to the framework’s ability to evolve alongside technological progress and emerging operational paradigms. As computational capacity increases and edge technologies such as IoT devices, PLCs, and embedded controllers become more powerful, a greater portion of decision-making can be executed closer to the physical process itself.

The architecture layers will remain including all tasks and responsibilities and independent from future computation power.

The framework must therefore anticipate this evolution, allowing intelligence and autonomy to be distributed dynamically across different layers without compromising standardization or interoperability. This means defining information models and interfaces that remain stable even as the control logic becomes more localized or autonomous.

By ensuring this scalability, the adapted IEC 62264 (ISA-95) model can support both current centralized control structures and future decentralized or self-optimizing systems, enabling a continuous and seamless path toward higher levels of automation in port terminals.

In Release 2025.017 Published Definitions:

This paper establishes a unified framework to address the long-standing fragmentation in port-terminal technologies, data models, and system interactions. Building on the IEC 62264 (ISA-95) standard, it outlines a hierarchical topology that organizes terminal functions from business intelligence and planning down to execution control, machine operation, and physical processes. This structure enables standardized information flows between enterprise systems, operational management, and equipment-level control. By adapting a globally proven industrial integration model, it provides terminals with a common architectural reference capable of supporting manual, semi-automated, and fully automated environments alike, while remaining flexible for diverse operational philosophies and legacy infrastructures.

The paper also highlights the practical requirements for achieving real-world automation: compatibility with existing systems, adaptable decision-making across functions, and a scalable foundation for future autonomous operations.

It formalizes functions such as “Scheduling” and “Dispatching”, clarifies interactions between planning, coordination, and control, and emphasizes the importance of standardized semantics, interfaces, and naming conventions.

Within the Release R2025.017 the functions “Scheduling” and “Dispatching” are defined.

Open

Overview of Levels and sub-systems/sub-functions. Source: TIC4.0 Automation Task Force

Scheduling definition:

Scheduling is the function responsible for transforming the planning intent (Work Packages and Work Instructions) into executable, time-bound job lists/Work Queues.
It operates as the intermediary between Planning and Dispatching, ensuring that planned work is converted into feasible sequences aligned with available resources, timing constraints, and operational priorities.

Dispatching definition:

The Dispatching function is responsible for executing in real time the job instructions prepared by the Scheduling function. It confirms the CHE assignment, if provided by scheduling or selects and assigns the CHE if not provided by scheduling, and dispatches job instructions, validates feasibility, monitors execution, and reports completion and exceptions.

It operates as the intermediary between Scheduling and Execution Control.

The Next Steps

The adoption of the IEC 62264 (ISA-95) framework establishes a common, industry-ready framework that finally gives terminal automation a shared reference from business intelligence down to execution control. It offers enough structure to make projects comparable and repeatable, while remaining flexible enough to respect different terminal philosophies and legacy environments.

At the same time, it is only the starting point. The next phase will focus on:

• Further investigating and formalizing “decision modes”.

• Defining the key functions, with priority on “planning” and “execution control”.

• Defining robust, technology-agnostic interfaces between the functions.

• Prioritize the development of interfaces between “scheduling” and “planning”, as well as “dispatching” and “execution control”.

• Continue to elaborate and refine all functional definitions.

There is still a lot of work to do, but the direction is clear: with this TIC4.0 framework for Terminal Automation as a shared foundation, the industry can move step by step towards interoperable, future-proof terminal automation.