Introduction
This publication TIC4.0 2022.004 contains the Semantics, Dataset Roadmap, Data Model and Definitions on the following topics
Cycle: an update of the 2022.003 release. The terminal.gate.cycle is now included. With this definition the most important cycles within a terminal have been defined: the highest level process terminal.cycle, the subprocesses terminal.berth.cycle, terminal.yard.cycle, terminals.gate.cycle, terminal.train.cycle, terminal.horizontaltransport.cycle and on the equipment level CHE.cycle.
Carrier Visit: includes important definitions for processes from the perspective of a carrier visit: Arrival, TerminalOperations and Departure.
Cargo Visit: includes important definitions to follow the process of the cargo on a terminal, such as Inbound and Outbound as well as unambigous definitions related to the weight of cargo. With these definitions the most important definitions for the “Cargo Visit” have been defined.
Schema JSON to FLAT: very important work was done for anyone who really wants to implement TIC4.0. The JSON Schema is defined and clear instructions for a human to convert a dataset from a JSON format into a FLAT format are included. TIC4.0 developed and published an open source software tool to automatically convert datasets from JSON to FLAT. The source code can be included into any program and is available via GitHub.
Datamodel: The existing data models are updated reflecting the definitions of this release and the latest development around the TIC4.0 semantic.
Focus of the following would be extension of existing topics. Plus promoting JSON to FLAT Schema.
This publication extents defintions of previous releases on the most important processes found in terminal operations: the Cargo Visit - which constitutes the sole purpose of terminals, the Carrier Visit - which constitutes the major link(s) to the cargo value chain and the
In line with the priority set by TIC4.0 members, this publication constitutes a first attempt to cover the most important processes found in terminal operations: the Cargo Visit - which constitutes the sole purpose of terminals, the Carrier Visit - which constitutes the major link(s) to the cargo value chain, and the Health of CHE, which is very important as “healthy” equipment is required to perform all activities on a terminal. The additional topic Drive and Movement constitutes an important step from an engineering perspective to ensure an unambiguous understanding across the industry.
As in the case of Cycle from release 2021.002, Carrier Visit and Cargo Visit are real life processes that TIC4.0 chose to virtualise as “subjects” in the Data Model. Both have a significant and direct relationship to the cargo value chain and are critical to optimise and improve the client experience.
The Carrier Visit Data Model constitutes the pilar of Port Call Optimisation. In the spirit of decarbonising maritime transport, enhancing vessel navigation sustainability, and minimising energy consumption and carbon emissions, TIC4.0 provides a solid way to digitalise the port call process for the whole industry. The implementation of the TIC4.0 definitions leverages the vessel port call process from a very traditional point-to-point communication and analogue interactions between stakeholders, to a digital, highly connected and systematic interaction. The Carrier Visit Data Model will allow terminal operators and shipping lines (or any other type of carriers applying the same logic) to measure every single subprocess of the process, regardless of whether it is a vessel, truck, train. “If you cannot measure it, you cannot improve it”: the basis for big optimisation lies in these definitions.
Important benefits are foreseen for the different stakeholders:
Carriers can make vessel navigation more sustainable and more efficient,
Ports can maximise throughput and optimise assets utilisation,
Terminals can comply with agreed berthing windows and optimise assets utilisation,
Supply chain users can access more predictable and prescriptive cargo info.
Focussing on the Vessel Carrier Visit (carrier type: vessel), TIC4.0 has developed an extended definition of events and timestamps, which also integrates the more limited list of events adopted by IMO Compendium and DCSA, which articulate the vessel port call. The availability of a complete Data Model facilitates the use of existing and new supporting software applications for the digitalisation and systematic exchange of relevant events between stakeholders.
This work needs to be adopted broadly by the industry - ideally on a global level, to ensure that its benefits can be realised in terms of efficiency and decarbonisation by: (1) implementing data interactions across software applications within Port ecosystems and (2) digitalising & connecting associated planning processes between Carrier-Port-Terminal.
What we expect from the combination of these different standardisation initiatives is:
Empowerment from a systematic and compliance Framework,
Follow Data Modeling and API Architecture guidelines,
Endorse standards and validate published APIs (e.g. Vessel Schedules),
Improvement areas assessment (root-cause and benefit analysis),
Leverage pilots and proof-of-concepts outcome into (global) industry adoption.
...
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 work 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 bricks and together with the TIC4.0 semantic rules, allow the user to define 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 but will grow exponentially when 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 words in each entry in several digital protocols, a Data Schema is needed. TIC 4.0 will propose Data Schema for each of the most common protocols, but the Data Schema can be used for any protocol. For the examples, TIC 4.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.
...
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).
...
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 will be provided as part of the 2022.004 release and it will define the rules that the Data Model will follow, and will allow 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 Definitions
In this release we defined the following elements:
Cycle
...
Release
...
Definition
...
Link
...
Definition
...
TIC4.0 semantic
...
2022.004
...
Cycle
...
...
A Cycle is a discrete (individually, separate and distinct) process designed (destined) to move payloads from one location to another by a subject (che, tos, terminal, carrier, etc).
Extension of the 2021.003 release with regards to the terminal.gate.cycle. With this definition the most important cycles within a terminal have been defined: the highest level process terminal.cycle, the subprocesses terminal.berth.cycle, terminal.yard.cycle, terminals.gate.cycle, terminal.train.cycle, terminal.horizontaltransport.cycle and on the equipment level CHE.cycle.
...
SUBJECT-PROCESS
Carrier Visit
...
Release
...
Definition
...
Link
...
Definition
...
TIC4.0 semantic
...
2022.004
...
Arrival
...
...
Arrival is the process by which a carrier is physically approaching its destination (terminal), in preparation to the terminal operations activity or to receive other 3rd party services that the terminal site provides.
...
SUBJECT-PROCESS
...
2022.004
...
TerminalOperations
...
...
“terminaloperations” is the process in which the terminal is loading, unloading or moving cargo.
The definition of TerminalOperarations is a generic process definition and can also be applied to other parent processes.
...
SUBJECT-PROCESS
...
2022.004
...
Departure
...
...
Departure is the process by which a carrier is physically leaving the terminal, as the terminal operations or third party services are completed.
...
SUBJECT-PROCESS
Cargo Visit
...
Release
...
Definition
...
Link
...
Definition
...
TIC4.0 semantic
...
2022.004
...
Inbound
...
...
The cargo visit “inbound” event happens when the carriervisit arrival process ends (carriervisit.arrival.end = carriervisit.firsttimereadytowork) and the cargo transported by the carrier during the carriervisit is ready for being unloaded (carriervisit cargooperations can start).
...
CONCEPT EVENT
...
2022.004
...
Check-In
...
...
The Check-in is the event that identifies the cargo incoming to the terminal from the administrative point of view.
...
CONCEPT EVENT
...
2022.004
...
Dwell
...
...
The cargo visit dwell concept represents that the cargo is actually visiting a terminal from the administrative point of view. The status of the concept is “true”, between the moment the cargo is identified during the incoming of the cargo (check-in) and the moment of confirmation of the cargo’s departure (check-out).
...
CONCEPT STATUS
...
2022.004
...
Check-Out
...
...
The Check-out is the event that identifies the cargo departure from the terminal from the administrative point of view.
...
CONCEPT
EVENT
...
2022.004
...
Outbound
...
...
The cargo visit “outbound” event happens when the carriervisit departure process start (carriervisit.arrival.start = carriervisit.firsttimereadytodeparture) with the cargo (of the cargovisit).
...
CONCEPT EVENT
...
2022.004
...
Weight
...
...
The force that gravity exerts upon the TIC 4.0 “subject”, equal to the mass of the payload multiplied by the local acceleration of gravity.
...
CONCEPT
...
2022.004
...
Gross
...
...
The whole weight of the subject including the weight of the subject itself (tare) and all carried by it (nett).
...
OBSERVED PROPERTY
...
2022.004
...
Nett
...
...
The whole weight of the subject (gross) not including the weight of the subject itself (tare).
...
OBSERVED PROPERTY
...
2022.004
...
Tare
...
...
The weight of the subject itself, only including its own weight without any extra payload it is carrying (nett).
...
OBSERVED PROPERTY
Schema JSON to FLAT
...
Introduction
This publication TIC4.0 2022.004 contains the Semantics, Dataset Roadmap, Data Model and Definitions on the following topics
Cycle: an update of the 2022.003 release. The terminal.gate.cycle is now included. With this definition the most important cycles within a terminal have been defined: the highest level process terminal.cycle, the subprocesses terminal.berth.cycle, terminal.yard.cycle, terminals.gate.cycle, terminal.train.cycle, terminal.horizontaltransport.cycle and on the equipment level CHE.cycle.
Carrier Visit: includes important definitions for processes from the perspective of a carrier visit: Arrival, TerminalOperations and Departure.
Cargo Visit: includes important definitions to follow the process of the cargo on a terminal, such as Inbound and Outbound as well as unambigous definitions related to the weight of cargo. With these definitions the most important definitions for the “Cargo Visit” have been defined.
Schema JSON to FLAT: very important work was done for anyone who really wants to implement TIC4.0. The JSON Schema is defined and clear instructions for a human to convert a dataset from a JSON format into a FLAT format are included. TIC4.0 developed and published an open source software tool to automatically convert datasets from JSON to FLAT. The source code can be included into any program and is available via GitHub.
Datamodel: The existing data models are updated reflecting the definitions of this release and the latest development around the TIC4.0 semantic.
This publication extends defintions of previous releases on the most important processes found in terminal operations: the Cargo Visit - which constitutes the sole purpose of terminals, the Carrier Visit - which constitutes the major link(s) to the cargo value chain and the Cycle - which is required to describe the processes of a terminal related to moving payloads.
With the Schema JSON to FLAT this publication provides the required step by step instructions (and an open source conversion tool) to convert the data format from the JSON format to the FLAT format. This is important for the implementation of the semantics. TIC 4.0 uses the JSON format as default because it allows us to express a hierarchical structure and an array of subjects (for several subsubjects) or observed properties (for different combinations of timestamps, pom, pomt, names, etc). JSON is also the default file format for many protocols such as REST and MQTT extensively used to share data or publish IoT data. A flat format is more suitable for low-level implementation like PLCs or software code. JSON is better for sharing extensive messages. Both are valid in TIC 4.0 and for the implementation is very important to be able to automatically convert from one format to the other.
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 on 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 work 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 bricks and together with the TIC4.0 semantic rules, allow the user to define 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 but will grow exponentially when 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 words in each entry in several digital protocols, a Data Schema is needed. TIC 4.0 will propose Data Schema for each of the most common protocols, but the Data Schema can be used for any protocol. For the examples, TIC 4.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.
...
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'smetadata 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 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 will be provided as part of the 2022.004 release and it will define the rules that the Data Model will follow, and will allow 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 Definitions
In this release we defined the following elements:
Cycle
Release | Definition | Link | Definition | TIC4.0 semantic |
|---|---|---|---|---|
2022.004 | Cycle | A Cycle is a discrete (individually, separate and distinct) process designed (destined) to move payloads from one location to another by a subject (che, tos, terminal, carrier, etc). Extension of the 2021.003 release with regards to the terminal.gate.cycle. With this definition the most important cycles within a terminal have been defined: the highest level process terminal.cycle, the subprocesses terminal.berth.cycle, terminal.yard.cycle, terminals.gate.cycle, terminal.train.cycle, terminal.horizontaltransport.cycle and on the equipment level CHE.cycle. | SUBJECT-PROCESS |
Carrier Visit
Release | Definition | Link | Definition | TIC4.0 semantic |
|---|---|---|---|---|
2022.004 | Arrival | Arrival is the process by which a carrier is physically approaching its destination (terminal), in preparation to the terminal operations activity or to receive other 3rd party services that the terminal site provides. | SUBJECT-PROCESS | |
2022.004 | TerminalOperations | “terminaloperations” is the process in which the terminal is loading, unloading or moving cargo. The definition of TerminalOperarations is a generic process definition and can also be applied to other parent processes. | SUBJECT-PROCESS | |
2022.004 | Departure | Departure is the process by which a carrier is physically leaving the terminal, as the terminal operations or third party services are completed. | SUBJECT-PROCESS |
Cargo Visit
Release | Definition | Link | Definition | TIC4.0 semantic |
|---|---|---|---|---|
2022.004 | Inbound | The cargo visit “inbound” event happens when the carriervisit arrival process ends (carriervisit.arrival.end = carriervisit.firsttimereadytowork) and the cargo transported by the carrier during the carriervisit is ready for being unloaded (carriervisit cargooperations can start). | CONCEPT EVENT | |
2022.004 | Check-In | The Check-in is the event that identifies the cargo incoming to the terminal from the administrative point of view. | CONCEPT EVENT | |
2022.004 | Dwell | The cargo visit dwell concept represents that the cargo is actually visiting a terminal from the administrative point of view. The status of the concept is “true”, between the moment the cargo is identified during the incoming of the cargo (check-in) and the moment of confirmation of the cargo’s departure (check-out). | CONCEPT STATUS | |
2022.004 | Check-Out | The Check-out is the event that identifies the cargo departure from the terminal from the administrative point of view. | CONCEPT EVENT | |
2022.004 | Outbound | The cargo visit “outbound” event happens when the carriervisit departure process start (carriervisit.arrival.start = carriervisit.firsttimereadytodeparture) with the cargo (of the cargovisit). | CONCEPT EVENT | |
2022.004 | Weight | The force that gravity exerts upon the TIC 4.0 “subject”, equal to the mass of the payload multiplied by the local acceleration of gravity. | CONCEPT | |
2022.004 | Gross | The whole weight of the subject including the weight of the subject itself (tare) and all carried by it (nett). | OBSERVED PROPERTY | |
2022.004 | Nett | The whole weight of the subject (gross) not including the weight of the subject itself (tare). | OBSERVED PROPERTY | |
2022.004 | Tare | The weight of the subject itself, only including its own weight without any extra payload it is carrying (nett). | OBSERVED PROPERTY |
Schema JSON to FLAT
Release | Definition | Link | Definition | TIC4.0 semantic |
|---|---|---|---|---|
2022.004 | JSON Schema | TIC 4.0 uses the JSON format as default because it allows us to express an array of subjects (for several subsubjects) or observed properties (for different combinations of timestamps, pom, pomt, names, etc). JSON is also the default file format for many protocols such as REST and MQTT extensively used to share data or publish IoT data. These arrays give us a high flexibility thanks to the hierarchical structure. Other hierarchical structures are possible in TIC 4.0 like XML but we recommend using JSON as default. The hierarchical structure allows to include in one message many timestamps of many concepts per subject of many subjects per the main subject without limits. | DATA FORMAT | |
2022.004 | JSON to FLAT | The main goal of the conversion is to keep all the JSON information in the flat messages after the conversion. This definition includes the most important rules to perform the JSON to FLAT conversion. | DATA FORMAT |