Introduction
...
“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 operator is requesting and what the solution provider is providing.At a very high level
Management Summary
This document provides a guideline and structure supporting the technical clarification process between terminal operator and solution provider is described first and identified at which point in the process it is important . The aim is to support the clarification and help to understand 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 identified at which point in the process it is important to apply the two “CHE talks TIC” principles: “Content Level” and “Data Provision Level”.Both principles will then be explained, before this guideline becomes quite technical and dives deep into…. The required definitions and background ideas 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 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.
High-Level technical clarification process
...
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.
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
...
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 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 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
...
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).
...
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
Content Level requirements (Level 1, Level 2, Level 3 as specified by TIC4.0)
Data Provision Level requirements
Physical network (e.g., WiFi, Wireless mesh, 4G, 5G, etc.) that is implemented at the terminal for data exchange.
Messaging framework (PUB/SUB software) and provide
the lightweight client version to the CHE operator (for them to install on the CHE for communicating with the broker).
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
...
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.
...
Provide an additional add-on computer or provide the software on the existing computer.
...
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 first in an example ….concept applied… also for spreader. Then Excel spreadsheet as well as PDFs.
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.
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 date to where? (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).
| Drawio | ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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 more strategic considerations
for a terminal operator:
Which “TIC4.0 Content Level” do we want to achieve?
as well for 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: 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.
| Drawio | ||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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
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 mechanism. “AVAILABLE” 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 processed or 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 processed data provisioning from the CHE to the terminal operator.
Technical Specifications
Given the explained background, definitions and scope, the following shall be included in the technical specification:
Terminal operator to specify the following to CHE solution provider
TIC4.0 Content Level requirements (Level 1, Level 2, Level 3, Level 4)
TIC4.0 Data Provision Level requirements (Available, Provided, Processed)
Physical network (e.g., WiFi, Wireless mesh, 4G, 5G, etc.) that is implemented at the terminal for data exchange.
Messaging framework (PUB/SUB software) and provide
the lightweight client version to the CHE operator (for them to install on the CHE for communicating with the broker).
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
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.
Provide an additional add-on computer or provide the software on the existing computer.
CHE solution provider has to support the underlying physical network.
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.
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.
...
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.
Illustration - proposed system architecture to achieve “CHE talks TIC”
...