...
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 TIC 4.0, but if the attribute is a TIC 4.0 attribute the Schema will check if the format is TIC 4.0.
JSON SCHEMA
Basic rules
All subjects are arrays
All concepts are not arrays
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.
| View file | ||
|---|---|---|
|
Custom validations
Arrays of Subjects, with more than one array element in the message, need to have a unique “arrayid”.
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.
“pom” https://tic40.atlassian.net/wiki/spaces/TIC40Definitions/pages/8618041/TIC4.0+Semantic#Where-in-the-subject-(device-or-process) , “pomt” https://tic40.atlassian.net/wiki/spaces/TIC40Definitions/pages/8618041/TIC4.0+Semantic#Where%2FWhen-in-the-timeline-%E2%80%9Cpomt%E2%80%9D%3A, 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.