Introduction

This publication TIC4.0 2023.008 contains the following topics:

• TIC4.0 Health White Paper: CHE are the most important assets to physically move goods. Their “health” (monitoring and managing the proper functioning) is a vital production factor for any terminal. This document gives an overview of the health ecosystem and its relevance in the port industry. It complements the existing definitions and provides the outlook to develop a complete health ecosystem, including taxonomies for health signals, diagnosis, and root causes, to enhance maintenance operations and facilitate predictive maintenance.

• Cycle: The existing definition Cycle 2022.004 was updated and reviewed with the following changes: the new definition “deliver” was included and the context between “deliver” and “end of cyle” was clarified. The links of related TIC4.0 standards were updated.

• Carrier Visit: The definition of “FirstTimeCarrierReadyforDeparture”was added to the extensive overview of events of the 2022.006 Release.

• Job instruction: The definition of the events “collect” and “deliver” in relation to moving cargo have been added. Both are important concepts to be able to describe the complete process from the terminal operation perspective.

• Spreader: In this third set of definitions for the topic spreader very important guidance is given to identify the unique position of devices located on a spreader in relation to a reference mark. Also the following definitions are being published: Flipper, FlipperIsUp an FlipperIsDown.

The “TIC4.0 Health White Paper” deals with the health ecosystem of the container handling industry. Container Handling Equipments (=CHE) are the most important assets to physically move goods. Their “health” (monitoring and managing the proper functioning) is a vital production factor for any terminal. The publication addresses the challenges faced by terminal managers, operations departments, and technical or maintenance departments in assessing the health of their equipment and making informed decisions. The publication emphasizes the importance of data transparency in providing qualified answers regarding equipment health. To gain the full benefits of digitalization, data analytics, and machine learning in the health ecosystem the concept needs to be broken down. Relying solely on equipment signals is insufficient, as external maintenance information is also crucial. TIC4.0 aims to provide the right semantics and data models to express both: the health based on equipment signals and the maintenance health. The White Paper also discusses the relation between the technical structure of the equipment, health messages, and fleet management, emphasizing the need for a taxonomy that standardizes functions across different original equipment manufacturers (OEMs). Additionally, the publication clarifies the distinctions between errors, warnings and faults.

These definitions are part of TIC4.0’s ongoing work to develop a common vocabulary for the cargo handling industry and will be followed by future releases, as defined by the TIC4.0 Dataset Roadmap. The current list of definitions being worked upon can be accessed on the digital platform of TIC4.0. This publication release provides the actual definitions and includes them in the TIC4.0 templates with the general approach on how to use these in Data Models, Data Schema's, JSON formats and provides high-level scenarios as examples.

1. TIC 4.0 scope

The purpose of TIC4.0 is to define a common language that can be represented in an understandable format, including data and information elements suitable for digitalization.

With the definitions and language, any reality (equipment or process) in a port terminal environment can be uniquely described. The vocabulary needs to be valid for any equipment, process and protocol (digital or human) in any port terminal in any location. The typical elements that make up the port terminal activities are cargo handling equipment (any kind of machine within the terminal that performs a job or task), external vehicles (trucks, vessels, trains), terminal infrastructure (berth, yard, gate), or auxiliary elements (energy, light, refuelling…).

For data-driven terminal operations, the subject of standardization concerns the data and information elements linking the digital solutions to the physical equipment and hardware.

To achieve the above goal TIC4.0 has developed a Semantic set of rules based on human language which helps in the creation process of the definitions/vocabulary. The definitions/vocabulary can be considered as the building blocks and together with the TIC4.0 semantic rules, allow the user to describe any reality in a specific, unambiguous way, irrespective of the level of technology used in a terminal.

The vocabulary is managed in a Dataset, which is basically a one-dimensional database list. This list is not static and will grow exponentially as TIC4.0 continues to work on more and more segments and areas of a terminal.

The work of TIC4.0 is to define the individual entries of the Dataset/Dictionary, focusing on a logical group or theme. In the Dataset/Dictionary the user can see the status of each entry and which entries are published and a link to the definition is provided.

To apply the vocabulary in each entry in several digital protocols, a Data Schema is needed. TIC4.0 will propose a Data Schema for each of the most common protocols, but the Data Schema is compatible with any protocol. In the examples that are provided, TIC4.0 usually uses JSON as it is very user-friendly and easy to read.

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 on the RDF https://en.wikipedia.org/wiki/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) which help 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” 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 PROPERTies 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 as long as 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 https://tic40.atlassian.net/l/c/XBT1vEBA

The Data Schema was provided as part of the 2022.004 release and it defines the rules that the Data Model will follow and allows the translation from a hierarchy format to a flat format.

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 we are publishing the following element:

4. Definitions

In this release we defined the following elements:

Generic Definitions

Carrier Visit

Job Instruction

Spreader