1.   Introduction

...

Translation: Reefer Monitoring Systems to TIC4.0 (2024.013)

In the previous version of this document, the equivalencies of the data flowing between the TOS and the RMS were detailed, mainly related to the measurements from IoT sensors, the different Set Points, and the characteristics of the Reefer Cargo Visit. This allowed for the representation of the most relevant states of the reefer through the exchanged data. In this iteration, a key aspect has been incorporated: the tasks that a reefer cargo must receive from various parties while within the terminal's domains. This task focused on establishing the equivalencies between these actions and their representation using the terms defined in TIC4.0, such as "Job Instruction" and "Order." This new set of translations allows the TOS and RMS to exchange messages, incorporating actions to be taken by a party on a reefer cargo, such as connecting or disconnecting the cargo from the power source.

...

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'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 MEASUREMENTsin 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 MEASUREMENTsthat need to be represented.

...

 4.2 TOS

4.3 KPI