Introduction

The TIC 4.0 data model is based on the TIC 4.0 semantic that usually is represented in a flat version (human readable).

The concept descriptions are done by TIC 4.0 in their definitions and are not part of this document. The data model is a technical implementation to represent these definitions in a digital format to work in Java, XML, Python etc. Several entities could be used (JSON, XML, MQTT, etc.) and a schema will be published.

From the JSON Schema we will use a JSON validator that will verify if the format is correct. From JSON format, translation can be done to any other format (Java, YAMLK, XML etc) or for human readable format also a flat format algorithm will be implemented.

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 measurement and unique reference.

SUBJECT (who) is the entity that is doing or being the CONCEPT. Could be a device (light, petrol station….), machine (che, vessel…), systems (hoist, trolley…) , component (spreader, wheel….), processes (move, cycle…).

CONCEPT (what is-does) refers always to a particular subject (or subject-subsystem) specifying what the subject is (status, metadata…) or does (movement…).

OBSERVED PROPERTY (how much) is the magnitude of the concept (status, pieces, length, volume, weight, energy, time, speed, power, duration, acceleration…) represented in the value with a specific measurement unit.

POINT OF MEASUREMENT (where) defines where in place and time (past, present, future) the value representing the observed property of the concept 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. Several units could be used.

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.

All the details could be find at https://tic40.atlassian.net/wiki/spaces/TIC40Definitions/pages/8618041

Structure

For the digital formating of the semantic and data set we need a data model to structure the data and a data schema to define the details of the content like the validity of the format or the type of data (boolean, entire, real etc), what data is mandatory or could be omitted etc.

For the 2021.1 release, the data model has been defined based on the RDF https://en.wikipedia.org/wiki/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.

SUBJECT creates the hierarchy tree structure (we have sub-subjects) that helps to identify the boundary of the value. The hierarchy is fixed by TIC 4.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 many subjects identical but with different metadata (id or name or location or…) can be sent in the same message. (1 message with several CHEs 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 we can use as many as necessary. Also, two concepts can be combined with “and” or “or” creating a new concept that in fact is the condition that makes both true. E.g. “hoisting_and_trolleying” that represents the action of hoisting and trolleying at the same time (both status must be true).

OBSERVED PROPERTies define the magnitudes of the CONCEPT, are flat (no hierarchy) and can be used as many times as necessary per 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 differents Units will give an array (a list) of VALUEs. The array could be as long as necessary per 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 needs to be represented.

Below is one example of one message with 3 subjects (1 subject and 2 sub-subjects), 3 metadata per subject, 2 different concepts that apply to several subjects and 3 observed properties that affect all the subjects.

The data model representation follows then this hierarchy (please notice the array objects represented by a [number] that contains several values)

Another example of one observed property which contains an array of 4 values for the different pom (input, iinput, iouput, ouput) but could contain as many as necessary if different pomt or timestamps or units combination are represented.

The same example of this structure in JSON format can be found below:

{
  "msg": {
    "id": {},
    "timestamp": "2021-04-07T15:28:46.160Z"
  },
  "subject_1": [
    {
      "concept_metadata_1": "",
      "concept_metadata_2": "",
      "concept_metadata_n": "",
      "subject_2": [
        {
          "concept_metadata_1": "",
          "concept_metadata_2": "",
          "concept_metadata_n": "",
          "concept_1": {
            "observed_property_1": [
              {
                "pom": "input",
                "pomt": "actual",
                "timestamp": "2021-04-07T15:28:46.160Z",
                "unit": "seconds",
                "value": 0
              },
              {
                "pom": "iinput",
                "pomt": "actual",
                "timestamp": "2021-04-07T15:28:46.160Z",
                "unit": "seconds",
                "value": 0
              },
              {
                "pom": "iouput",
                "pomt": "actual",
                "timestamp": "2021-04-07T15:28:46.160Z",
                "unit": "seconds",
                "value": 0
              },
              {
                "pom": "ouput",
                "pomt": "actual",
                "timestamp": "2021-04-07T15:28:46.160Z",
                "unit": "seconds",
                "value": 0
              }
            ],
            "observed_property_2": [
              {
                "pom": "input",
                "pomt": "actual",
                "timestamp": "2021-04-07T15:28:46.160Z",
                "unit": "km/h",
                "value": 0
              },
              {
                "pom": "iinput",
                "pomt": "actual",
                "timestamp": "2021-04-07T15:28:46.160Z",
                "unit": "km/h",
                "value": 0
              },
              {
                "pom": "iouput",
                "pomt": "actual",
                "timestamp": "2021-04-07T15:28:46.160Z",
                "unit": "km/h",
                "value": 0
              },
              {
                "pom": "ouput",
                "pomt": "actual",
                "timestamp": "2021-04-07T15:28:46.160Z",
                "unit": "km/h",
                "value": 0
              }
            ],
            "observed_property_n": [
              {
                "pom": "",
                "pomt": "",
                "timestamp": "2021-04-07T15:28:46.160Z",
                "unit": "",
                "value": 0
              }
            ]
          },
          "concept_2": {
            "observed_property_1": [
              {
                "pom": "input",
                "pomt": "actual",
                "timestamp": "2021-04-07T15:28:46.160Z",
                "unit": "seconds",
                "value": 0
              },
              {
                "pom": "iinput",
                "pomt": "actual",
                "timestamp": "2021-04-07T15:28:46.160Z",
                "unit": "seconds",
                "value": 0
              },
              {
                "pom": "iouput",
                "pomt": "actual",
                "timestamp": "2021-04-07T15:28:46.160Z",
                "unit": "seconds",
                "value": 0
              }
            ],
            "observed_property_2": [
              {
                "pom": "input",
                "pomt": "actual",
                "timestamp": "2021-04-07T15:28:46.160Z",
                "unit": "km/h",
                "value": 0
              },
              {
                "pom": "iinput",
                "pomt": "actual",
                "timestamp": "2021-04-07T15:28:46.161Z",
                "unit": "km/h",
                "value": 0
              },
              {
                "pom": "iouput",
                "pomt": "actual",
                "timestamp": "2021-04-07T15:28:46.161Z",
                "unit": "km/h",
                "value": 0
              }
            ],
            "observed_property_n": [
              {
                "pom": "",
                "pomt": "",
                "timestamp": "2021-04-07T15:28:46.161Z",
                "unit": "",
                "value": 0
              }
            ]
          },
          "subject_3": [
            {
              "concept_metadata_1": "",
              "concept_metadata_2": "",
              "concept_metadata_n": "",
              "concept_1": {
                "observed_property_1": [
                  {
                    "pom": "input",
                    "pomt": "actual",
                    "timestamp": "2021-04-07T15:28:46.161Z",
                    "unit": "seconds",
                    "value": 0
                  },
                  {
                    "pom": "output",
                    "pomt": "actual",
                    "timestamp": "2021-04-07T15:28:46.161Z",
                    "unit": "seconds",
                    "value": 0
                  }
                ],
                "observed_property_2": [
                  {
                    "pom": "input",
                    "pomt": "actual",
                    "timestamp": "2021-04-07T15:28:46.161Z",
                    "unit": "km/h",
                    "value": 0
                  },
                  {
                    "pom": "output",
                    "pomt": "actual",
                    "timestamp": "2021-04-07T15:28:46.162Z",
                    "unit": "seconds",
                    "value": 0
                  }
                ],
                "observed_property_n": [
                  {
                    "pom": "input",
                    "pomt": "",
                    "timestamp": "2021-04-07T15:28:46.162Z",
                    "unit": "",
                    "value": 0
                  },
                  {
                    "pom": "output",
                    "pomt": "",
                    "timestamp": "2021-04-07T15:28:46.162Z",
                    "unit": "",
                    "value": 0
                  }
                ]
              }
            }
          ]
        }
      ]
    }
  ]
}

This data model allows having huge flexibility to add as many subjects as necessary and as many point of measurements, timestamps or units as necessary in the future.

MSG

The message header data model is quite simple as all the concepts are metadata.

A msg header example in JSON format:

{
  "msg": {
    "id": "",
    "sender": "",
    "timestamp": "2021-04-15T10:27:22.023Z",
    "topic": "",
    "destinantion": "",
    "creation_timestamp": "2021-04-15T10:27:22.023Z",
    "start_timestamp": "2021-04-15T10:27:22.023Z",
    "end_timestamp": "2021-04-15T10:27:22.023Z",
    "protocol": "JSON",
    "version": "2021.1"
  }
}

Subjects

Subject hierarchy is fixed by TIC 4.0 for each root subject (at this point CHE, TOS, Terminal). The hierarchy can not be changed but non of them are mandatory.

CHE

Subjects in JSON format for CHE:

{
  "msg": {},
  "che": [
    {
      "control": [],
      "health": [],
      "powersource": [
        {
          "control": [],
          "deftank": [],
          "energytank": []
        }
      ],
      "drive": [
        {
          "control": [],
          "axe": [
            {
              "wheel": [
                {
                  "tyre": []
                }
              ],
              "motor": [],
              "brake": []
            }
          ]
        }
      ],
      "spreader": [
        {
          "control": [],
          "twislock": []
        }
      ],
      "hoist": [
        {
          "control": []
        }
      ],
      "trolley": [
        {
          "control": []
        }
      ],
      "boom": [
        {
          "control": []
        }
      ],
      "firefighting": [
        {
          "control": []
        }
      ],
      "cabin": [
        {
          "seatoperator": []
        }
      ],
      "drivers": [],
      "cycle": [
        {
          "cargo": [
            {
              "visit": []
            }
          ]
        }
      ]
    }
  ]
}

TOS

pending

Terminal

pending

Concept

Each subject has a list of compatible concepts that make sense to be applied with it. TIC 4.0 includes a list of the most common ones, but this list could be easyly extended if anyone requires it.

CHE

A quite extensive list of concepts can be used for each subject. The valid list for 2021.1 version can be found below but this list will increase in further releases.

2021.001 concepts in JSON format for CHE

Plain TXT tab format for http://www.objgen.com/json editor

TOS

release 2021.002 included the first draft for the TOS Data model.

Plain TXT tab format for http://www.objgen.com/json editor

Terminal

pending release 2022.003

Data Schema

pending release 2021.003

Flattering

The flattering algorithm to move from any dataset value in the data model to a unique “sentence” is pending.

Preliminary version proposed follows this structure: subject.subsubject_name.concept.pom.pomt.pomp.unit

EXAMPLES

Complete 2021.001 roadmap example in JSON Format and Plain TXT tab format for editor

4. Publish

Data Model

Introduction

Structure

MSG

Subjects

CHE

TOS

Terminal

Concept

CHE

TOS

Terminal

Data Schema

Flattering

EXAMPLES