Introduction

In TIC4.0 we started with a bottom-up approach defining the language to translate different equipment data into a unified, standardised data view, meaning into the same type of information. Then we realised the industry needs more: and expanded the engineering driven language into a language to represent any type of reality in a data driven digital view.

“CHE talks TIC” is only the beginning - and it is also a pre-requisite for digitization and digitilization in the terminal industry. Only if TIC4.0 is being requested by terminal operators in technical specifications and also only if TIC4.0 is being offered by solution providers to the industry, TIC4.0 will become reality.

This document defines and describes the “Content Level” and the “Level of Data Provision” to include TIC4.0 in technical specifications.

Management Summary

This document provides a guideline and structure supporting the technical clarification process between terminal operator and solution provider. The aim is to support the clarification process and the understanding of what the terminal operator is requesting and what the solution provider is providing.

At a very high level the technical clarification process between terminal operator and solution provider is described first and it is identified at which point in the process it is important to apply the two “CHE talks TIC” principles: “Content Level” and “Data Provision Level”. The “Content Level” ranges from Level 1 = Basic Data to Level 4 = Full Package. The “Data Provision Level” can be distinguished between AVAILABLE, PROVIDED and PROCESSED.

Both principles will be explained, then an overview of the outline of technical specifications in the light of TIC4.0 is given, before this guideline becomes quite technical and dives deep into definitions and some background explanation. Among others a proposed architecture to achieve “CHE talks TIC” is illustrated. At the end of the document the definition of the Content Level is detailed in two examples (a selection of concepts and specific for spreader), so that it becomes clear which TIC4.0 concepts can be achieved with which Content Level. These examples are based on the CHE Data Model 2022.005. A detailed Excel spreadsheet - as well based on CHE Data Model 2022.005 - to be used by any party as well as PDFs can be found at the bottom of the document.

High-Level description of technical clarification process

As part of the procurement process the terminal operator will provide a technical specification of the CHE. The specification will not only include physical and functional requirements of the CHE itself, but also requirements detailing the following:

• Which data is required from the CHE? (TIC4.0 Content Level)

• Who will be responsible to provide data? (TIC4.0 Data Provision Level)

• What is the physical network the data is embedded in?

• What is the messaging framework?

Replying to the requirements, the solution provider will provide a technical offer. Thereafter, in a clarification process between terminal operator and solution provider it will be agreed what will be delivered as part of the order (See below).

The framework for the “Content Level” and the “Data Provision Level” described in this document will support both parties to successfully agree on the scope of delivery.

The above mentioned framework could also support the following:

strategic considerations of a terminal operator:

• Which “TIC4.0 Content Level” do we want to achieve across our fleet?

as well as strategic considerations of a solution provider:

• Which “TIC4.0 Content Level” with which “TIC4.0 Data Provision Level” do we want to offer?

TIC4.0 Content Level

One of the most important questions in the technical clarification process is, which “Content Level” is requested / delivered. The CHE Data Model 2022.005 contains more than possible 6.500 data points if you combine the subject CHE with the existing concepts (such as spreader, on, off, working, location etc.) and the observed property, only looking at the point of measurement time (POMT) actual.

The aim of this guideline is to simplify the technical specification process between the terminal operator and the solution provider. To achieve this aim we developed 4 different “Content Level” with the following design principles:

Content Level 1: Basic Data to fulfil main terminal operation processes from CHE point of view on a manually operated CHE. It is mainly monitoring of status information. Minimum information of “what is” and “what does” the subject without the detail. Content Level 1 contains among others basic information about the CHE, the concepts On, Off and the (sub-)subject Spreader.

Content Level 2: “Help the terminal to become data-driven” is the design principle that led us. It contains all topics of Content Level 1 plus relevant concepts and (sub-)subjects to become data-driven. Content Level 2 contains among others the concepts Location, Standby, Notstandby, Working, Idle and the (sub-)subjects Powersource, Drive, additional data points for Spreader, Hoist, Trolley and Boom.

Content Level 3: Contains additional (sub-)subjects and concepts adding onto the data provided in Content Level 1 and 2, such as Cycle, Health, Lights.

Content Level 4: This level contains the full scope of the available content. The intent is to be able to express any reality at a terminal in the digital format. This could even allow to utilize TIC4.0 to give commands to the CHE. Concepts that require an interaction towards the CHE , for example the permission to access a CHE, can be handled.

Additional or fewer data points or concepts for a specific (sub-)subject may be added or subtracted and agreed upon between the parties involved. A “manual override” is possible, still, the Content Level provides the opportunity to start the negotiation on the same basis.

A detailed list in PDF format and a draft example in an Excel spreadsheet may be found at the bottom of this page.

To determine the “Content Level” we “uniquely” paired the (sub)subject and the concept to a topic and assigned the different Content Levels to each pair as per the above design principles.

Please see the below sketch to understand how the Content Levels build on each other.

TIC4.0 Data Provision Level

Another important question in the technical specification process is the question: “Who is actually delivering, which part of the solution?” To gain a clear understanding between terminal operator and solution provider we are differentiating into three different levels of “Data Provision”: AVAILABLE, PROVIDED and PROCESSED. The level of Data Provision also has an influence on the number or the quality of data points that can be provided or processed by the CHE. We developed a rule to identify the level of “Data Provision” depending on the observed property, which is part of the data set.

The categorization is as follows:

AVAILABLE

PROVIDED

PROCESSED

The “Data Provision Level” as described in this document is independent of the current implementation of the existing CHE fleet of a terminal. The purpose of above definitions is to support the technical clarification process and determine who will deliver / provide what.

Technical Specifications

Given the explained background, definitions and scope, the following shall be included in the technical specification in addition to the physical and functional requirements of the CHE:

Terminal operator to specify the following:

1. TIC4.0 Content Level requirements (Level 1, Level 2, Level 3, Level 4)

2. TIC4.0 Data Provision Level requirements (Available, Provided, Processed)

3. Physical network (e.g., WiFi, Wireless mesh, 4G, 5G, etc.) that is implemented at the terminal for data exchange.

4. Messaging framework (PUB/SUB software) and provide

   1.  the lightweight client version to the CHE operator (for them to install on the CHE for communicating with the broker).

   2. Broker details for CHE to establish the connections with the Broker

CHE solution provider is required to perform the following based on the specification from the terminal operator

1. To implement the required software and hardware on the CHE (e.g. CHE Talk TIC Application; PUB/SUB client provided by the terminal) to facilitate the data exchange from the CHE.

2. Provide an additional add-on computer or provide the software on the existing computer.

3. CHE solution provider has to support the underlying physical network.

Definitions and background information

Data

Data is information in digital format, which can be electronically accessed. It can be used to exchange information as raw data or control data.

Other information which cannot be provided electronically does not qualify as data e.g., mechanical devices like counters or closed devices with human machine interfaces (HMI) like digital thermostats.

CHE Data Source

CHE is a complex system made up of multiple sub-systems (from the same or different vendors). Each sub-system maybe capable of generating multiple data points.

It is assumed that a master PLC/SCADA system is available to compile all the subsystem data points together. Thus, allowing the data to be accessed via an IO interface as logically illustrated in Fig. 1 below. This will hence be referred to as the data source.

Open

Fig. 1 Data Source

Note:

The mechanism required to consolidate sub-system data is not considered within the scope of this document.

Data Exchange

The data is exchanged electronically between the CHE and the terminal operator using a network protocol. Various enterprise grade frameworks are prevalent today for data exchange and they predominantly fall under two models.

1. Request-Response model: Here the data is exchanged between the source and the consumer by means of the "source" sending the data in "response" to a "request" from the "consumer". This requires the source and consumers to be very tightly coupled and tends to be a bit heavier in terms of computational requirements.

Open

Fig. 2 Request-Response model

2. Publisher-Subscriber model: Here the "publisher" publishes the data. The consumer can "subscribe" to a topic at the broker. Upon subscription the framework ("Broker") ensures delivering of the data published. Frameworks following this model provide a greater amount of flexibility and independence to both the publisher and subscriber. Relatively these frameworks are light weight on the publisher and subscriber and work well even on a not so robust network. Thus, for the terminal environment, this model, which is also referred to as PUB/SUB model, is recommended for data exchange.

The Publisher-Subscriber model is the recommended model for implementing TIC4.0.

The idea of a “CHE talks TIC” Application

“CHE talks TIC” is a standards-based application which helps the entities to conform to the TIC4.0 standards and specifications as related to data models, definitions and formats. This application helps independent entities to convert their data into “data as per TIC4.0 specification” and ensures that data is interoperable between various independent entities (terminal operators, equipment manufacturers, 3rd party service providers, etc.). The “CHE talks TIC” Application is the translator.

Explanation of application of Content Level and Data Provision in the light of the semantic

The combination of the subject and the concept (che.@.on) enables the possibility to convert data into information. When the observed property (che.@.on.status) is added and the point of measurement (che.@.on.status.output.actual ) the provided value becomes information (che.@.on.status.output.actual.value: TRUE).

In this example only due to the combination of the subject CHE plus the concept ON plus the observed property STATUS plus the point of measurement OUTPUT ACTUAL and the provided value:TRUE, the information can be retrieved that the CHE is On in that moment.

Adding different observed properties to a concept allows to gain more and different information from the same concept, i.e: che.@.on.duration.output.actual.#unit#second.value = 2 this provides the information that the CHE was On for 2 seconds at that moment.

che.@.on.timer.output.actual.#unit#second.value = 364 provides for how long during two timestamps the CHE was on. (364 seconds).

che.@.on.totaltimer.output.actual.#unit#hour.value = 13.693 provides the information that the total timer for On counted 13.693 hours.

The “Content Level” describes the data and very often it is raw data. The “Data Provision Level” is a classification of what is actually required to observe the data, aggregate and combine it to create information. It can go from available raw data (just the status of True/False) to the provision of complex way aggregated and combined data to for example get the information “how long” or “how much cost incurred” by the concept for that specific subject”.

From information to business value

To create business value different pieces of information need to be compared to choose the best option or determine if some processes do not perform as they should:

che.@1.idle.timer.%.value vs che.@2.idle.timer.%.value: compares the idle time of two different CHE allows to understand which CHE is being used in a more efficient way.

che.@.idle.timer vs tos.@.jobinstruction.@.order.@.dispached.timer: compares how long the CHE is idle with the time since an order was placed by a jobinstruction from the TOS.

Illustration:
proposed system architecture to achieve “CHE talks TIC”

Annex

Example part of Content Level Definition based on Excel Sheet CHE_talks_TIC_Definition_221206.xlsx:

TRUE means, that the concept can be achieved with the given “Content Level”. The detail that can be achieved at the level of observed properties depends on the “Data Provision Level”.

Content level of Spreader: