Translate reality in figures is not easy. Bottom to top approach requires being able to aggregate or consolidate the information that comes from data. The transversal approach (process driving) requires defining where, when, what and who very precisely. Top to bottom approach requires to be human-friendly base on concepts (ideas). In any case, the exchange of information should be defined as technology-independent to allow competition and the improvement of the technology in the future.

The most restrictive requirement comes from the need to define from whom, who, what, where, when and how much the reality is or does. To comply with these requirements TIC 4.0 propose a semantic base on the human one.

Open

The semantic combines 6 basic elements: HEADER, SUBJECT, CONCEPT, OBSERVED PROPERTY, POINT OF MEASUREMENT and VALUE to represent a unique reality.

HEADER identifies the message in origin, (destination), time of reference for the message and unique reference.

SUBJECT (who) is the entity that is doing or being the CONCEPT.

CONCEPT (what is-does) refers always to a particular subject (or subject-subsystem) specifying what the subject is (status) or does (action-event)

OBSERVED PROPERTY (how much) is the magnitude of the concept (status, pieces, length, volume, time, speed, power, duration, acceleration…) represented in the value.

POINT OF MEASUREMENT (where) defines where in place and time (past, present, future) the value representing the concept observed property of the subject is measured and represented.

VALUE is the actual measured result for a specific combination of time of measurement + subject+ concept + observed property + point of measurement. Same value can be represented in several units.

The combination of a SUBJECT with multiple combinations of CONCEPTs, OBSERVED PROPERTies and POINT OF MEASUREMENTs give us a unique meaning of a VALUE.

TIC 4.0 aims to define each of these elements.

HEADER identifies the message with the origin, (destination), time and unique reference.

1 HEADER could contain as many SUBJECTs as necessary (with multiple CONCEPTs, subSUBJECTs, OBSERVED PROPERTies, POINT OF MEASUREMENTs, and VALUEs). (99.9% cases will be only 1 message per subject).

Header message identifier: (id) Unique identifier reference for any message. Default format: (GUID generator → 128bit number combined by e.g. MAC, time and random number) + sender as URL/IP (Format could be by JSON Schema).

Header sender identifier: (sender) Unique device identification that publishes the data. (Typically is the Subject id).

Header message timestamp:  (timestamp) Number code that defines the time when a message was generated (timestamp of the message creation); Format: ISO8601; Example: 2020-06-04T09:37:08.000Z

Header topic: (topic) Subject to publish-subscribe the information to be used for publishing – subscribing technology (broker).

Header destination identifier: (destination) Unique device identification that message is target to.

Header Content Creation Time: (creation_timestamp) is the time that corresponds to the content of the value in the message. This is necessary when the message is not built at the same time that the content data.

Header Time Start-End: (start_timestamp; end_timestamp) is the start and end time of the frame time that corresponds to the content of the value in the message (for aggregated values as average, max, counter etc).

Protocol: what protocol is written the message

Version: Version of the TIC 4.0 Data model

A message could contains 1 header, unlimited subjects, compatible sub-subjects, list of compatible concepts per subject, list of observed properties per concepts, list of compatible points of application and units per observed property.

JSON header example

SUBJECT identifies and defines the perimeter of the element that is executing or being something defined in the CONCEPT. The subject can be broken down into hierarchical pieces (sub-subject = sub-systems).

Any SUBJECT belongs to another SUBJECT so all of them are subSUBJECT of someone and usually every SUBJECT usually has subSUBJECT

ie: Terminal->RS->Spreader

The SUBJECT and subSUBJECT hierarchy is defined within the context of the message defined by the HEADER

ie:

Message from RS: RS = SUBJECT = ; Spreader = subSUBJECT ; flipper = subSUBJECT

The VALUE refers always to the SUBJECT, this means that the VALUE of the subSUBJECT does not have to match with the VALUE of the subject.

In message 1 and 2 CHE.powersource.on.totaltimer.hours refers to the number of hours done by any engine installed in the CHE

In message 3 and 4, powersource.on.totaltimer.hours refers to the engine itself, because the subject id corresponds to the engine itself = power unit.

Identifier (id): Unique device identification of the data subject. This id has to be unique not only for one specific data pool (DB, terminal group, manufacturer) but also at a global level. A Combination of Manufacturer name + manufacturer id (typically a serial number).

Name: (name) A common name for the subject, human-readable. MT_MFT_RTG_003. don't need to be unique but we suggest to use a combination of (UN location code) + (terminal code) + subject type + (number)

examples: MT_MFT_RTG_003 ; DEHAM_CTH_VC_025; MT_MFT_TZ_STS-SC; ES_VLC_APMT_TOS ; MT_MFT_TT_225

Type:

It is a “tag” for filtering or facilitating the description of the subject (sub-subject or device group). Several tags could be applied in one message for the same object if the tags are compatible.

1. Terminal

   1. Container

   2. Bulk

   3. Ro-Ro

2. BERTH

   1. Deepsea

   2. Barged

3. Bollard

4. Yard

   1. Reefer

   2. Full

   3. Empty

   4. Electrified

5. Rail

6. TZ

7. GATE

8. CHE

   1. STS

   2. RTG

   3. TT

   4. ECH

   5. RS

   6. SC

   7. MC

   8. RMG

   9. ASC

9. VESSEL

   1. Mainliner

   2. Feeder

10. Lightpole

    1. Lighting

    2. Communication

    3. CCTV

11. IT

    1. TOS

    2. GOS (Gate operating system)

    3. MMS

    4. ERP

    5. ….

12. Powersource

    1. genset

    2. IC_engine

    3. fuelcell

    4. cablereel

    5. busbar

13. Control

    1. plc

    2. controler

14. tool (to be defined)

SubSUBJECT defines a main component of the SUBJECT about the CONCEPT is related (specifying what the subSUBJECT is or does).

1. control

2. health

3. powersource

4. deftank

5. energytank

6. drive

7. axe

8. wheel

9. tyre

10. motor

11. brake

12. spreader

13. twislock

14. hoist

15. trolley

16. boom

17. firefighting

18. cabin

19. seatoperator

20. Drivers

21. wharf

22. yard

23. gate

24. rail

25. planning

26. execution

27. …. (to be extended)

Subject - sub-system matrix compatibility list: