Introduction

TIC 4.0 uses the JSON format as 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, which are 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 TIC 4.0 lbut we recommend using JSON as default.

Although the JSON is very powerful, other formats that are required for data processing at low level and program level and which are not compatible with hierarchical structures. So we require a solution to be able to express the same content in a flat format. It is important to be able to identify unambiguously the array elements and id if necessary.

The hierarchical structure allows to include in a single message many timestamps of many concepts per subject of many subjects per the main subject, without limits.

Open

Hierarchical data structure example

Using a flat format we are limited to only one timestamp per message, and to add in the name the critical information to identify what subject, concept, observed property and point of measurement are related.

Open

Two flat messages equivalent to one JSON

ou can download the example here

Open

A flat format is more suitable for low-level implementation such as PLCs or software code. JSON is better for sharing extensive messages. Both are valid in TIC 4.0.

This document contains the rules to convert the JSON structure into a Flat one (2022.005 will cover Flat to JSON).

This conversion is related to the opposite one JSON to FLAT https://tic40.atlassian.net/l/cp/kS1uF9qD

FLAT to JSON: the general concept

The main goal of the conversion is to ensure that all the FLAT message information is transferred in a JSON message after the conversion. One flat message will become one JSON message as the JSON format does not have the limitations of the FLAT format.

Rules to transform FLAT to JSON:

• Check integrity: Messages to be transformed to TIC 4.0 from FLAT needs to follow the expected format.

• Each key field of the message will be split by the "|" separator but also special symbols like "#" and "@" will be analysed:

1. When a "|" is found it means that the string before the symbol is the parent object and the string after is the child object or property.

2. When a "@" is found it means that the previous object is an array of elements, being the elements after the next "|" the object / properties of the first element of the array.

3. If "@" has an id string (ie "@sts01") it means that all elements with the same id belong to the same element of the array.

4. When a "#" is found it means that the string between two "#" (ie #unit#) is a property that should be included in the object. The content after the second "#" is the value of the property (ie #unit#meter will transform in the property "unit": "meter")

Exceptions to the "." rule:

1. When a value for the already know lists pom (see TIC4.0 Semantic | pom: Where in the subject (device or process) ) is found, the expected property should be included in the object (ie if "output" word is found, this will transform in the property "pom": "output")

2. When a value for the already know lists pomt is found (see TIC4.0 Semantic | Where/When in the timeline “pomt”: ), the expected property should be included in the object (ie if "actual" word is found, this will transform the property "pomt": "actual")

3. When a value for the already know lists pomp is found (see TIC4.0 Semantic | pomp: Process Started or Ended ), the expected property should be included in the object (ie if "started" word is found, this will transform the property "pomp": "started")

Example 1

One FLAT message with two “CHE”, each one with two “powersource” and two “spreader”:

Example 2

Open Source Code

The backend of this code is publicly available at

https://github.com/Fundacion-Valenciaport/TIC4.0