1.   Introduction

The publication TIC4.0 2024.010 covers the following topics:

• White Paper “Terminal Automation”: Terminal Automation is a continuously evolving industry trend, which all terminal operators have relied upon in order to achieve greater levels of efficiency, safety and sustainability. The White Paper “Technical Automation” shows how TIC4.0 can create a solution agnostic TIC4.0 interface in the area to ease automation and facilitate associated system integration.

• “Health” ensuring “Operational Performance” A terminal’s performance is highly dependent on the performance of its equipment, which, in turn, depends on its “health” condition. This White Paper describes how the integration of standardised metrics from an equipment health perspective contributes to the overall reliability and performance of port terminal operations.

• KPI “Throughput” definition: A definition of the “throughput” KPI has been made by the experts of the TIC4.0, making the first time a KPI has been expressed in TIC4.0’s semantics. The definition includes the way of calculating it and defines it as “the sum of objects moved by and/or in a subject during a period of time”.

• Container Handling Equipment (CHE): This release has made further refinements to the definitions of the movements of machines, its basic movements (pitch, yaw, roll) and specific positions (left, right, up and down). From this release (2024.010) onwards, these will be placed under “Container Handling Equipment” and no longer under “Drive”, since these concepts do apply to driving machines or components as well as to spreader movements.

• JSON to FLAT & FLAT to JSON “|” Version: In the grammar of TIC4.0, the dot “.” as a separator will be replaced by the bar “|”, which will increase performance. FLAT TIC4.0 has been tested in a large-scale non-relational database (hundreds of millions of registers) resulting in a not expected low performance. After investigating, the low performance was caused by the use of the “.” separator. After several tests, the pipe character “|” was selected as a separator because of its optimum performance.
  
  

“Terminal Automation”
As mentioned before, terminal Automation is a continuously evolving industry trend, which all terminal operators have relied upon in order to achieve greater levels of efficiency, safety and sustainability. Since TIC4.0 has a strong focus on improving Terminal Digitalisation via standardisation and interoperability, it will promote the establishment of industry guidelines that assist with the automation and system integration from a solution agnostic point of view.

When opting for the automation of a port terminal, a series of benefits in the areas of efficiency, safety and sustainability are usually associated with it. These are the following:

• The efficiency benefits are normally identified with more consistent and reliable performance (24x7), gaining a more repeatable and predictable productivity.

• The safety benefits and values are usually underestimated or forgotten, as the automation of equipment handling is generating safer working environments and in general more system oriented & process driven jobs.

• The sustainability benefits are related to handling equipment electrification (zero emissions) but also due to the machinery suffering less shock loads and in general consuming less energy while extending their lifecycle.

Finally, to ensure that terminal automation projects provide the desired level of precision and quality in data production, TIC4.0 will strive to provide a pre-defined “data core” as a foundation for the correct functioning of these solutions.

“Health” ensuring “Operational Performance”

Terminals play a crucial role in the global logistics chain, ensuring the efficient transfer of goods between ships and land-based networks. A notable trend within these infrastructures is the relentless pursuit of operational efficiency. This continuous quest for improvement stems from several factors, including the exponential growth of international trade, the increase in the volume of handled goods, and the need to reduce production times. From an equipment health perspective, the need for standardised efficiency metrics in port terminals is paramount for ensuring the well-being and longevity of the machinery and technology deployed.

The use of standardised metrics to monitor equipment health would help improve the efficiency of the terminal by ensuring that it remains operational and capable to endure the tough requirements of terminal environments. TIC4.0’s data model, due to its inherent arrangement and flexibility, would enable a way to classify the information that is coming from different signals equipment send and organise them to create health calculation processes.

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 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.010 publication:

KPI

CHE