The publication TIC4.0 2025.016 covers the following topics:

• Short definitions: Continuing the work of the last Release, a new set of simple definitions has been finalised to cover important elements of the Data Model which were lacking a formal definition.

• European projects: A report on the latest developments of the European “Horizon Europe” projects in which TIC4.0 is participating: MISSION, which tackles port call optimisation, SEAMLESS, which aims to develop an automated, waterborne freight feeder service in Europe, and FOR-FREIGHT, an initiative to develop a digital platform for information exchange among transport stakeholders.

• KPIs: In this publication, the KPI Total Net Operating Time has been defined.

• KPIs amendment: As the KPIs were not included in publication 2025.015, we will use this publication to announce the release of Terminal Closed Is Scheduled and Terminal Closed Is Planned.

• FAQ: This publication introduces a new FAQ section explaining how to communicate the need to address a new topic or missing definitions in TIC4.0, along with a new blog that serves as a guide for communicating these new requirements.

Short Definitions

Thanks to the efforts of TIC4.0 members and Task Forces, a significant number of standard definitions have been developed, prompting the release of a Glossary to improve clarity and accessibility. This glossary includes concise explanations, data types, versioning, and practical examples for each term, with plans to present the full set in the 2025.017 release. Key updates in this edition include the deprecation of several data elements no longer deemed necessary, and renaming others for clarity (e.g. “Forecast Time” to “Forecast Horizon”, and “Software Id” to “Software Version”). Additionally, due to ongoing work on PAS4000, data types and ontology rules are being updated, with some definitions temporarily marked as To Be Defined (TBD).

European projects

The MISSION, SEAMLESS, and FOR-FREIGHT projects, all funded by Horizon Europe, aim to modernise and decarbonise freight transport through digital innovation, automation, and standardisation. MISSION focuses on reducing vessel waiting times and emissions via real-time data sharing and Just-In-Time coordination, with TIC4.0 leading interoperability efforts. SEAMLESS is developing a fully automated, zero-emission waterborne feeder system, with TIC4.0 contributing to port automation standards and digital platforms like ModalNET. FOR-FREIGHT is enhancing intermodal logistics across Europe through predictive tools, standardised data models, and real-time trials, also driven by TIC4.0’s leadership in standardisation. All three projects are progressing towards validation, integration, and scalable implementation.

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

In this release, the following generic documents, definitions and other information are available:

The following definitions have been created or modified in this 2025.016 publication:

4.1 Short Definitions

 4.2 KPIs