1.   Introduction

The publication TIC4.0 2024.011 covers the following topics:

• EDI to TIC4.0: Since its inception, the EDIFACT standard has been used by ports and other logistics providers. The goal is to translate EDIFACT data into the TIC4.0 data standard/model, providing definitions, data formats, models, and examples for easy implementation, facilitating the translation and integration of EDI data into TIC messages or data lakes.

• “Health” ensuring “Reliability”: This comprehensive overview emphasises the critical importance of measuring and monitoring equipment health in terminal operations, citing its impacts on efficiency, safety, and cost-effectiveness. The integration of TIC4.0 and the CHE health data model ensures monitoring and anticipation of equipment condition.

• “Health” definitions: “Repairing”, “Diagnosing” and “Inspecting” status definitions have been created for this release, the goal being to define the maintenance tasks of the same name.

• “Health” Data Model: A new version of the the Health Data Model has been created, including the new definitions and data points.

• KPI definitions: KPIs “Carrier Visit Turnaround Time”, “Average Carriervisit Turnaround Time”, “Vessel Turnaround Time”, “Truck Turnaround Time”, “Productivity”, “Productivity Gross”, “Productivity Net”, “Carrier Productivity Cargo Operations” and “Carrier Productivity Carrier Ready to Work” have been defined during this publication period, offering a comprehensive overview on these operational performance indicators.

• Reefer definitions: This Release defines the subject “Air”, with the aim of using it as a generic subject for other TIC4.0 areas. Furthermore, a revision of definitions for “Unplugged”, “Plugged”, “Unpowered” and “PowerSource” are provided including the characteristics of the cargo reefer.

EDI to TIC4.0:

This whitepaper focuses on implementing TIC4.0, which aims to integrate EDI into terminal operations. TIC4.0 seeks to leverage metadata from EDI to generate valuable data insights. It offers an overview of how to translate and integrate EDI data from various sources, including EDI messages and Terminal Operating Systems (TOS), into TIC messages, registers, or a centralised data lake.

One of the main challenges identified is the historical disconnect between EDI and terminal operations, which has hindered efficient data utilisation. However, TIC4.0 offers a solution to unify disparate data sources, providing a holistic view of terminal performance and improving operational efficiency.

The report also examines the technical complexities of EDI structure and the methodology used in its translation to the TIC4.0 model. This involves a systematic review of EDI messages, segment-by-segment analysis, and mapping data elements to their corresponding fields within the TIC4.0 framework.

The implementation of TIC4.0 represents a significant advancement in terminal operations. By leveraging EDI within a centralised framework, TIC4.0 has the potential to improve terminal operations, driving efficiency and collaboration in the global maritime industry.

“Health” ensuring “Reliability”:

In the changing landscape of port operations, the application of TIC4.0 standards has the potential to mark a fundamental shift towards prioritising systematic measurement and tracking of equipment health. This proactive approach not only empowers organisations to anticipate maintenance needs, it minimises downtime ensuring operational continuity with enhanced operational reliability. Furthermore, it establishes a solid foundation for safety protocols, fostering compliance with industry standards.

TIC4.0's focus on equipment health monitoring yields significant cost savings by detecting issues earlier, reducing expensive repairs, and extending equipment lifespan. Implementing preventative maintenance strategies in parallel further enhances financial efficiency over time.

Integration of TIC4.0 provides a semantic structure for a measured health assessment, allowing adaptive control strategies while reinforcing operational reliability and profitability.

2.   Data Model

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

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. 

3.  Generic Documentation

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

4.  Definitions

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

4.1 General

4.2 KPI

4.3 Health