Versiones comparadas

Clave

  • Se ha añadido esta línea.
  • Se ha eliminado esta línea.
  • El formato se ha cambiado.

Introduction

This publication TIC4.0 2022.004 contains the Semantics, Dataset Roadmap, Data Model and Definitions on the following topics

...

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.

...

Release

Definition

Link

Definition

TIC4.0 semantic

2022.004

Inbound

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 to be unloaded (carriervisit cargooperations can start).

CONCEPT EVENT

2022.004

Check-In

Check-inIn

The “Check-In" is the event that identifies the cargo incoming to the terminal from an administrative point of view.

CONCEPT EVENT

2022.004

Dwell

Dwell

The cargo visit “Dwell" concept is the administrative representation of a cargo is remaining at a terminal. The status of the concept is “true”, from 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

Check-out

The “Check-Out" is the event that identifies the cargo departure from the terminal from an administrative point of view.

CONCEPT

EVENT

2022.004

Outbound

Outbound

The cargo visit “Outbound” event happens when the carriervisit departure process starts (carriervisit.arrival.start = carriervisit.firsttimereadytodeparture) with the cargo (of the cargovisit).

CONCEPT EVENT

2022.004

Weight

Weight

The force that gravity exerts upon the TIC4.0 subject, equal to the mass of the payload multiplied by the local acceleration of gravity.

CONCEPT

2022.004

Gross

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

Nett

The whole weight of the subject (gross) not including the weight of the subject itself (tare).

OBSERVED PROPERTY

2022.004

Tare

Tare

The weight of the subject itself, only including its own weight without any extra payload it is carrying (nett).

OBSERVED PROPERTY

...

Release

Definition

Link

Definition

TIC4.0 semantic

2022.004

JSON Schema

JSON Schema

TIC4.0 uses the JSON format by default because it allows to express an array of subjects (for several sub-subjects) 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, such as XML, are possible in TIC4.0 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

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