The publication TIC4.0 2025.017 covers the following topics:

• Digital Twin: Continuing our work in the Digital Twin domain, the Paper: Digital Twin for Port Terminals introduces a unified methodology to classify Digital Twins using four dimensions—Data Scope, Timing, Function, and Interface. This framework provides terminals with a clear and consistent way to identify the type of Digital Twin that best aligns with their operational objectives and maturity level.

• Terminal Automation: Significant progress has been made within the Automation Task Force. One major achievement is the adaptation of the IEC 62264 (ISA-95) standard to the context of port terminals, presented in the White Paper: Terminal Automation Topology according to IEC 62264 (ISA-95) & Definitions of Automation Levels. In addition, key conceptual definitions—such as Scheduling and Dispatching—have also been published.

• Smart eCHE Operations for Container Terminal: Another milestone is the Smart eCHE Operations for Container Terminals white paper, which defines a structured framework for managing electric container-handling equipment, including the key operational data, energy flows, and interfaces needed for efficient fleet operations. It also sets the basis for future semantic alignment across terminal systems.

• KPIs: In this publication, the KPI Crane Density (CD), Crane Time Intensity (CTI), Effective Crane Count (ECC), and Unplanned Assignment Interruption Duration (UAID) have been published.

• Yard Inventory: For this release, definitions such as Train Rails, Train Tracks, Crane Rails, and Crane Tracks have been completed.

• Short definitions: Continuing the work of the last Release, a new set of short definitions has been finalised to cover important elements of the Data Model which were lacking a formal definition.

White Paper: Terminal Automation Topology according to IEC 62264 (ISA-95) & Definitions of Automation Levels

This White 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 document 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 roles such as Scheduler and Dispatcher, clarifies interactions between planning, coordination, and control, and emphasizes the importance of standardized semantics, interfaces, and naming conventions. Additionally, it sets the direction for the next steps of the Automation Task Force, including detailed function definitions, interface modelling, and semantic.

White Paper: Smart eCHE Operations for Container Terminal

This work defines a structured framework for Smart eCHE operations in container terminals, addressing the growing need to manage electric container-handling equipment through consistent data, coordinated energy flows, and interoperable system interactions. It outlines how telemetry, operational status, charging behaviour, and energy availability must be captured and exchanged across eCHE, terminal control, charging systems, and energy management functions. By establishing a unified semantic and architectural approach, it helps terminals understand the information required to operate electric fleets efficiently, safely, and at scale, regardless of their current level of digital maturity.

In addition, the White Paper highlights the practical steps needed to operationalize this framework, including the definition of functions, interfaces, and data elements that enable real-time decision-making and energy-aware operations. It emphasizes the importance of harmonized semantics to support interoperability and lays the foundation for future extensions—such as advanced energy intelligence, charging optimization, and integrated fleet–grid coordination. By providing a clear structure for information flows and system roles, the document accelerates the transition to electrified CHE fleets and supports consistent, repeatable, and scalable Smart eCHE implementations across terminals.

For the digital formatting of the semantic and Dataset we need a Data Model to structure the data and a Data Schema to define the details of the content, such as the validity of the format, the type of data (Boolean, entire, real etc.), which data is mandatory or could be omitted etc.

The Dataset has been defined based upon the RDF Resource Description Framework using the subject->predicate->object schema.

Following the semantic web standard (subject: object) the model has 3 main components: header, asset description and measurement.

Open

Open

SUBJECT creates the hierarchy tree structure (we have sub-subjects) that helps to identify the boundary of the value. The hierarchy is fixed by TIC4.0 for each kind of subject (CHE, TOS, Terminal) and can mix any type of subjects (e.g. machine.process = che.move). The subjects conform to an array defined by the (concept) metadata so various identical subjects but with different metadata (id or name or location or…) can be sent in the same message. (one message with several CHE's or one CHE with several spreaders).

The CONCEPT's metadata defines ‘what is’ and the CONCEPT ‘what does’. Both are flat (no hierarchy, no arrays) and as many as necessary can be used. Additionally, two concepts can be combined with ‘and’ or ‘or’ creating a new concept which includes the condition that makes both true. For e.g. ‘hoisting_and_trolleying’ that represents the action of hoisting and trolleying at the same time (both statuses must be true).

OBSERVED PROPERTIES define the ‘magnitude’ of the CONCEPT, are flat (no hierarchy) and can be used as many times as necessary with a CONCEPT.

For each OBSERVED PROPERTY, an array created by the combination of the different POINT OF MEASUREMENTs in time (actual, estimated, etc), place (input, iinput, ioutput, output), timestamps and the different Units will give an array (a list) of VALUEs. The array could be if necessary in each message. The length will depend on the relation between the data frequency and the message frequency and also the amount of different POINT OF MEASUREMENTs that need to be represented.

A detailed definition of the Data Model can be found in Data Model.

The Dataset is the content of the Data Model, a flat version without hierarchy or rules. The Dataset is used by humans, but machines need the Data Model and the Data Schema to translate it to a digital format. 

 In this release, the following generic documents, definitions and other information are available: 

The following definitions have been created or modified in this 2025.017 publication:

4.1 Short Definitions

4.2 General Definitions

4.3 Space

 4.4 KPIs