Introduction

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.

Open

Hierarchical data structure example

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

Open

Two flat messages equivalent to one JSON

You can download the example here

Open

A flat format is more suitable for low-level implementation like PLCs or software code. JSON is better for sharing extensive messages. Both are valid in TIC4.0.

Message Validation

It is a process to check if the message complies TIC4.0 schema. The validations are made based on a JSON Schema. The schema doesn't limit the content to TIC4.0, but if the attribute is a TIC4.0 attribute the Schema will check if the format is TIC4.0.

JSON SCHEMA

Basic rules

1. All subjects are arrays

2. All concepts are not arrays

3. All observed properties are arrays and contain at least the timestamp.

JSON schema validates the type of the “key” (objects and values), if exists in the registered sample and in the schema will verify is the type is the same (boolean, string, real, etc), if it doesn't exist in one of them will not be considered, you will not get any error. The JSON TIC40 schema can be extended with proprietary extra information as TIC4.0 doesn't limit the content of the message with new proprietary content.

Open

Custom validations

1. Arrays of Subjects, with more than one array element in the message, need to have a unique “arrayid”.

2. Arrays of “observed properties” need to have always a unique combination of name, pom, pomt, reference, unit and timestamp. These fields are optional but if exist it needs a unique combination.

3. “pom” TIC4.0 Semantic | Where in the subject (device or process) , “pomt” TIC4.0 Semantic | Where/When in the timeline “pomt”:, needs to have the expected values. pom: input, iinput, ioutput, output; pomt : schedule, proposal, request, estimated, planned, actual, performed, historic. For the observed properties the “name”, “reference” and “unit” values can have any value as they will be identified by #name#, #reference#, #unit# and #qualifier# in the flat name path.