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 so 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 provides a guideline and structure supporting the technical clarification process between terminal operator and solution provider.The aim is to support the clarification and help to understand what the terminal provider is requesting and what the solution provider is providing.

The required definitions and background ideas will be explained first, the main points that need to be agreed upon are explained, illustrations of a possible system architecture are given and based on the CHE Data Model 2022.005 an example is given on how the two main dimensions “Content Level” and “Level of Data Provision” should be clustered to gain mutual understanding.

Therefore, this document describes the “Content Level” and the “Level of Data Provision” and concepts with a view towards including TIC4.0 in technical specifications. It is independent of the current data level supported by the CHE, an actual implementation or the direction of data flow.

Definitions and background

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.

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 forth be referred to as the 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.

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.

Content Level

Apart from the more technical definitions - as described above - one of the most important questions 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: Contains the full package including for example the permission to access a CHE.

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.

Data Provision

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 PROCESSES. The level of Data Provision also has an influence on the number or the quality of data points that can be provided or computed 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

The terminal operator has to physically collect the raw data from the data source and decide what raw data needs to be collected. CHE provides a mechanism to connect to the data source in the machine i.e., PLC/SCADA and the terminal operator has to pull the data by connecting to this data source. “Low” Data Provision is only assigned to data points of the type “value”.

PROVIDED

CHE provides the data in a raw format. Terminal operator communicates with the CHE over a network in order to gain access to the raw data. The terminal operator needs to implement the required logic to derive any analytics from the raw data received.

PROCESSED

CHE is capable of providing a varying degree of information (raw to insightful analytics). CHE is optionally able to communicate with a third-party sensor and data sensor systems (which can be externally provisioned onto the CHEs, like GNSS devices for location, camera systems for OCR activities, etc) and perform the comprehensive data provisioning from the CHE to the terminal operator.

Note:

The computational unit (MCU/CPU/Memory, etc) is beyond the scope of the document.

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 us 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” is a classification of what is actually required to observe the data, aggregate and combine it to create information. It can go from raw (just the status of True/False) to a very complex way to aggregate and combine 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.

Technical Specifications

Given the above background, definitions and scope, the following shall be included in the technical specification:

Terminal operator to specify the following to CHE solution provider

1. Content level requirements (Level 1, Level 2, Level 3 as specified by TIC4.0)

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

3. 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.

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

Annex

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

Content level of Spreader: