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

GRAMMAR:

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

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

Mandatory

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

Optional:

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.

Example:

JSON header example

SUBJECT:

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.

Mandatory attributes

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)

Optional attributes

SubSUBJECT

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

SubSUBJECT List:

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:

The CHE list in Json format is made by arrays to allow several subjects per message and subsubjects per subject. It can be nested without limits. List 2021.1 to be extended…

CONCEPT

CONCEPT (what or verb) refers always to a particular subject (or subject-subsystem) specifying what the subject is (status), used (components action), consumed or does (action-event in a process).

Examples:

• Is: id, name, type, location, size, on, off, fault, lock, unlock,

• Used: oil, rope, battery.

• consumed: energy, def…

• Does: working, idle, driving, hoisting, “trolleying”, extending, move, locking, unlocking.

Mandatory

Concept identifier: unique reference, predefined, alphanumeric, human-readable. As some subjects (systems) are called by the infinitive of the main action the system does (drive, hoist, boom, trolley) the action will be described as the gerund of the verb driving, hoisting, booming, “trolleying”.

Optional

Concept name: Common long name for the concept id, to be human-readable and self-explanatory.

Concept type: an organisational administrative attribute that groups at a high level the property concept and establish a hierarchy. It is a Tag that helps to identify and describe the concept in the definition template, it is not used in the data model. The objective is to help the human to classify, find, filter the concepts. Ie: move; activity; status; functional; operational, control, TOS.

1. Activity: family concept related to the movement of the payload: ie The structure, spreader, hoist, trolley, gantry, drive, boom, platform, chassis, etc.
   It is not included the auxiliary elements like the engine, power supply, internal process, checking-testing process, etc as they are not directly related to the payload.

2. Status: describes the activity status.

3. Move: describes the process related to the movement of cargo.

4. Metadata: concept uses to identify and classify the subject. Usually is a constant value (id, name, code, number) and not requires any extra information (observed property, pom, pomt, unit) so it doesn't need to add the “metadata” observed property.

5. Functional: describe the operational function or reason: In Operations (Deployed), In Maintenance, In Training, Testing, Others.

6. TOS: Related with the work instructions, planning, job list.

7. IT: related to the network or IT hardware

8. Asset: related

9. Maintenance: related to the maintenance operations.

10. Energy: describes the energy flow, quantity or behaviour

11. Substance: material used in a subject (process or device)

12. To be extended.

OBSERVED PROPERTY

OBSERVED PROPERTY (how much) is the measured metric (physical magnitude) of the CONCEPT (see property list for reference) represented by the VALUE with a specific scale or measurement unit.

For any CONCEPT several fundamental (mass, time, temperature, length, etc) and derivative (speed, force, power, volume, press, etc) physical magnitude can be observed. Most of the observed properties need a unit of measurement to define proper VALUE.

Property list (default measurement unit):

1. status: True/False. Represents the subject concept status in a determined timestamp.

2. duration (seconds): Represents how long is valid the status true just before the timestamp. (see “duration vs timer”)

3. counter (integer): Count the number of times the concept status changes from False to true (events from false to true) during a defined period of time.

4. totalcounter (integer): Count the number of times the concept status change from False to true since the absolute origin of time (usually all the life of the subject)

5. timer: (seconds): How long the concept status is TRUE (duration is not zero) during a period of time.

6. totaltimer (hours): How long the concept status is true has lasted since the absolute origin of time (usually all the life of the subject)

7. distance (m): Integral of the concept value during a period of time.

8. totaldistance (m): Integral of the concept value since the absolute origin of time (usually all the life of the subject)

9. speed (km/h)(m/min): derivative of the concept value during a period of time.

10. temperature (ºC)

11. pressure (bar)

12. volume: Volume is the quantity of three-dimensional space enclosed by a closed surface, for example, the space that a substance (solid, liquid, gas, or plasma) or shape occupies or contains. (*Wikipedia)

13. flow: volume/duration or energy/duration

14. voltage (Volt): the difference of potential that would carry one ampere of current against one ohm resistance.

15. Coordinate: (lat/long) could be combined with the result, start, end, etc.

16. logical: representation of the concept using human common Names (ie location.logical)

17. technical: representation of the concept using technical references (ie location.technical)

18. time: (ISO8601) defines the time when an event of a process happens.

19. event: represents the change of value. It doesn't have a duration just a timestamp. It is necessary to include the old value and the new value.

20. consumed: the amount of concept that is consumed (get in) by the subject, (energy, oil, air…)

21. produced: the amount of concept that is produced (get out) by the subject, (energy, oil, air…)

22. recovered: the amount of concept that is recovered (already produced but later recover), (energy, oil, air…)

23. flowin: concept/duration (volume/duration or energy/duration) only consumed.

24. flowout: concept/duration (volume/duration or energy/duration) only produced.

25. flowrecovered: concept/duration (volume/duration or energy/duration) only recovered.

26. course: direction related to the North (references: true, magnetic), sexagesimal units by default.

27. metaelements: (metadaelements) if a concept type “metadata” can have different values depending on the “timestamp” or other attributes (like the name of one subject in different languages or codes) the observer property “metadata” allows to generate an array of possible values. If the concept metadata cannot change the observed property “metadata” is not required.

28. humidity: (%) Humidity is the measure of the amount of water vapor present in the air. It can be expressed in relative humidity.

29. flowexchange: (%) The CBM value indicates the amount of air moving into and out of the container within the given time frame, where a higher value signifies a greater ventilation rate.

30. freevolume: (m3) The free space (the difference of space between the cargo and the total volume) within the container itself

31. dewpoint: The definition of dew point is the temperature point at which the air can hold no more water (water vapor) and is one of the factors in the heat index.

32. ionization: In the context of a reefer container, the property of "ionization" refers to the ability to generate ions in the air to improve its quality.

33. particulatematter: A Particulate Matter (PM) Sensor measures the floating particles in the air. Fixed at the HVAC's air inlet and/or inside the container.

34. o2level: (%) The level of O2 in the air

35. co2level: (%) The level of CO2 in the air

36. nitrogenlevel: (%) The level of nitrogen in the air

37. https://tic40.atlassian.net/wiki/x/AQD3Gg: The whole weight of the subject (gross) not including the weight of the subject itself (tare).

38. https://tic40.atlassian.net/wiki/x/AYD2Gg: The whole weight of the subject including the weight of the subject itself (tare) and all carried by it (nett).

39. https://tic40.atlassian.net/wiki/x/DwCsNg: The weight of the subject itself, only including its own weight without any extra payload it is carrying (nett).

     

duration vs timer

It is important to understand the difference between duration/timer

“duration” is how long is valid the data true. A true is just an instant status of one concept in the moment of the timestamp. As it is an instantaneous concept it doesn't have duration or you can not aggregate it (you can not sum a true).

“duration” is the same as status but instead of a boolean without duration this observed property has duration. Basically is how long the “true” is valid for. It is considered also an instantaneous value but with duration (small). During this period we consider that the status didn't change at all, always was true.

This is critical because status can not be aggregated but duration can. With this observed property we can sum all the duration during a period of time.

The sum of all duration (status true) during a period of time is the “timer”. During this period of time the duration can be a number (usually 1 second) or a null (cero) so can be true or false. The timer sum the duration of the “trues”.

POINT OF MEASUREMENT

POINT OF MEASUREMENT (where) defines where in place or time (past, present, future) the VALUE representing the OBSERVED PROPERTY of the CONCEPT is measured and represented.

Mandatory

pom: Where in the subject (device or process)

• Input (IN; Command; Request; Demand): External (from the cabin, remote control, Autonomous control, etc) order (input, instruction, signal) to the SUBJECT (CHE/TOS/Gate) requiring one action or status to be observed and represented by a value. For a process SUBJECT is the input to the process (start).

• Internal_Input = iinput(Request; Command; PLC request; Internal Order; Instance): Internal (from the PLC or subsystems or any kind of internal control) order (it is not a fact) that controls/apply for one action or status to be observed and represented by a value.

• Internal_Output = ioutput (feedback): confirmation of the internal system (element/tool/functionality) that is trying to execute the request (applying power to a motor; deducting actions from a combination of different Internal_Inputs or Inputs; deducting from an algorithm, etc). Feedback is an indirect way to measure an Observed Property VALUE

• Output (OUT; Result; Final result): direct information from a sensor about the action or status to be observed. The output is a direct measurement confirming the Observed Property VALUE. For a process SUBJECT is the output to the process (end).

pomt: Where/When in the timeline

pomt (Point of Measurement Time) Defines when in time the VALUE is expressed (future, present or past) in reference to the moment when the information was created. Default format ISO 8601.

• Scheduled: indicates the intention to do an action/status (concept) in the far future in a regular way, for example a timetable.

• Proposal: indicates the intention of the owner of the action to do an action/status (concept) in the future in a specific way and time.

• Request: indicates the requirement to the owner of the action to do an action/status (concept) in the future in a specific way and time.

• Planned: indicates the intention to do an action/status (concept) in the future in a specific way and time.

• Estimated: is the calculation or forecast about what and when in the future an action/status (concept) would happen.

• Actual: indicates that the value property of the concept is actually observed.

• Performed: (Completed, executed, accomplished, fulfilled, formerly, done) indicates that the value property of the concept observed did, was or happened in the past it can not be determined exactly when.

• Historic: indicates that the value property of the concept observed did, was or happen in the past and can be determined exactly when.

Owner of the action and Proposal vs Request

Many processes have several partners that participate in them. The owner of the action is the one that executes and controls the process. The rest of the participants in the action are interlocks (conditions) that are necessary to execute it.

For example the carriervisit.arrival.mooring.firstline (classical vessel ETA Berth) depends on the carrier, the mooring service, tugging service, terminal berth ready for mooring (berth availability) but the one that controls the resources for mooring (owner ) is the “mooring service provider”. The carrier would require the mooring service provider to have the first line at a specific place and time but will not execute the mooring process so will not be able to activate, (start or end) the mooring process.

The owner of the action is the only one that can publish the planned pomt. Because it controls the process it is the only one that can indicate the intention to do the action in the future in a specific way and time. Although if the proposal and request don't match then, most probably, the actual will not become close to the planned.

For example in the carriervisit.arrival.pilot.firstimepilotonboard event is controlled (owned) by the pilot service. The pilot process can start and be active but if the vessel doesn't arrive at the boarding place will not happen. In this process the owner of carriervisit.pilot.vesselatpilotboardingplace is the vessel and the owner of the carriervisit.pilot.firstimepilotonboard is the pilot.

Similar examples could be found in the Carrier Visit definition.

Open

Optional

pomp: Process Started or Ended

Any process has a start and end. In case the value refers to a concept that has started but not ended the pomp would be “started”. By default all the values refer to pomp = “ended”

VALUE

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

The default unit of measure will be the international system (SI) if other is not specified in the observed property attribute. TIC 4.0 default unit is detailed in each concept definition. In case of not use the default, TIC 4.0 unit the unit used must be indicated.

1. duration (second)

2. timer (second)

3. total Timer (hour)

4. speed (kilometer_per_hour)

5. distance (meter)

6. totaldistance (kilometer)

7. temperature (celsius)

8. flow (kilowatt, liter_per_hour, kilogram_per_hour)

9. energy (kilowatt_per_hour)

10. voltage (Volt)

11. coordinate: (WGS84)

12. timestamp: ISO8601

13. %: percentage of the observed property over the reference. By default, the reference is the maximum design performance for the actual conditions. Usually limited by speed, load, thermal or energy (produced or consumed) limitations. If not indicated the one most restrictive will be applied.

Data model

The semantic is compatible with multiple protocols. A https://tic40.atlassian.net/l/c/80wcug0A is defined and compatible with the main protocols, included and not limited to:.

1. MQTT

2. JSON

3. OPC-UA

4. CanBUS

5. ModBus

6. Profinet (DB fix)

7. Plain text (email, handwritten document, etc)

Most of the examples will be found in JSON format.

EXAMPLES

Email

Email 2345345 From Jason Martial at 2020-06-04T09:37:08.000Z the subject with id STS8765745346 and subject name MFT-STS01 has the working status (output actual) on TRUE and the drive speed (output actual) is 25 km/h.

TXT

msg.id: D6wZ6ngBBIsOzhTbxvHG; msg.sender: CMS234; msg.timestamp 2020-06-04T20:55:08.000Z; che.id RTG15215; che.name: MFT-STS01; che.working.status.output.actual : TRUE; che.idle.status.output.actual : FALSE; che.idle.status.input.actual : TRUE; che.drive.left.status.input.actual:TRUE ; che.drive.driving.speed.output.actual.km/h: 25; che.drive.driving.speed.input.actual.%: -0.78; che.drive.driving.power.ioutput.actual.kw: 125; che.drive.right.status.iinput: FALSE; che.on.status.ioutput : TRUE; che.on.cost.total.ioutput.€ : 0.8; che.on_and_energy.cost.ioutput.€ : 0.2;

msg.id: D6wZ6ngBBIsOzhTbxvHy; msg.sender: TOSMFT; msg.timestamp 2020-06-04T20:55:08.000Z; msg.start_timestamp: 2019-06-04T20:55:08.000Z; terminal.id CLT_ES; terminal.name: “Curro Local Terminal”; terminal.type: “terminal”; terminal.berth.cycle.move_and_discharging.counter.actual.output.box : 265.568; terminal.berth.cycle.move_and_loading.counter.actual.output.box : 265.544 ; terminal.berth.cycle.move.actual.output.box : 531.112 ; terminal.berth.cycle.move_and_discharging.counter.actual.output.teu : 458.548; terminal.gate.cycle.move_and_discharging.counter.actual.output.box : 258; terminal.berth.cycle.move_and_loading.counter.actual.output.teu : 458.548 ; terminal.gate.cycle.move_and_loading.counter.actual.output.box : 244; terminal.cycle.move.counter.actual.output.ended.box : 531.614 ; terminal.move.cost.actual.output.started.€ : 50.444.333;

JSON