Channels
This section introduces smartCORE channels and describes the principles of their use.
Architecture
Channels in the smartCORE context ensure communication between producing and consuming modules. They are created and written by a single producing module and can be read by several consuming modules. From a software perspective, a (time-stamped) smartCORE channel essentially represents a ring buffer of time-stamped measured values of a predefined data type. In addition, a so-called process variable channel represents a single measured value with the associated timestamp of its last update.
Channel and data types
We make a fundamental distinction between
- timestamped channels, which provide a time series of measured values and
- process variables (process values), which only provide the last measured value (e.g. a parameter or a property) and the time of the last change, but NO time history.
All measured values "transmitted" within a smartCORE channel are always uniquely typed. The following data types are supported
| Data type | Description |
|---|---|
| bool | Boolean truth bet like true and false |
| int64 | signed 64-bit integers |
| int32 | signed 32-bit integers |
| int16 | signed 16-bit integers |
| int8 | signed 8-bit integers |
| uint64 | unsigned 64-bit integers |
| uint32 | unsigned 32-bit integers |
| uint16 | unsigned 16-bit integers |
| uint8 | unsigned 8-bit integers |
| double | double precision floating point numbers |
| float | single precision floating point numbers |
| string | UTF-8 encoded strings |
| bytearray | binary data blocks |
| gpslocation | Structures for GPS position information, consisting of three consecutive double-precision floating point numbers for latitude, longitude and altitude above sea level |
Channel parameters
In total, the following channel parameters can be specified, including the above-mentioned channel and data types
| Parameter | Data type | Description |
|---|---|---|
| name | STRING | Name of the channel |
| channelType | STRING ENUM | Channel type, either timestamped ("timestamped") or process variable ("processvalue") |
| dataType | STRING ENUM | Data type of the measured values (see above) |
| bufferSize | UINT > 0 | Buffer size, i.e. maximum number of measured values within a time series before oldest measured values are overwritten |
| physicalDimension | STRING | Physical dimension of the channel (e.g. speed, voltage, temperature, ...) |
| physicalUnit | STRING | Physical unit of the channel (km/h, V, °C, ...) |
| metaData | JSON OBJECT | User-defined metadata |
| filter | JSON ARRAY of channel filter specifications | User-defined filter cascade (usually for data reduction) |
| persistent | BOOL | Flag indicating whether channel survives a restart of system operation |
| preserved | BOOL | Flag whether channel is loaded from a database on the measuring device at smartCORE start and written to this database at regular intervals (e.g. useful for counters or other operating information) |
Integration in smartCORE operating states
smartCORE channels are handled as follows in different smartCORE operating states. For further details, please refer to the smartCORE state machine documentation.
Creation of channels to be produced
The producing module requests the creation of a channel object in smartCORE channel management and receives a reference to it.
From the software's point of view, this process is only possible in the operating state for initializing producer channels (InitProducerChannels).
Selection of channels to be consumed
A consuming module can request a reference to channels provided by the smartCORE channel management at any time. Furthermore, such a module must register a consumer (handle for reading) of this channel, which is also possible at any time.
If these channels are already defined at the time of module configuration, the operating state for initializing consumer channels (InitConsumerChannels) is usually used in the software.
Production of measured values in channels
Once production has been signaled to the smartCORE by a module (StartProduce), this module can write measured values to its producer channels. This is done using a timestamp, whereby this timestamp can have different origins (e.g. resulting directly from the data or also the time of production).
In most cases, the measured values are not produced directly, but via a configured cascade of filters (filter chain), usually with the aim of data reduction.
The concept of a trusted timestamp has proven to be particularly useful in the context of data reduction.
Trusted Timestamps
While in a partial sequence of two consecutive time-stamped measured values the validity of the first measured value can be assumed until the time stamp of the second measured value (Exclusively), it is unknown for the last value of a sequence and therefore also for the last produced value until when it is valid - or in other words, whether and when further (identical or changed) measured values will come.
The consequence of this is that the complete time range since the last sample CANNOT be used, e.g. to perform calculations based on this in consuming modules.
In the context of data reduction, this has proven to be a particular hindrance, as, for example, a constant value is only produced once and then simply filtered out, i.e. discarded.
You can therefore basically NOT distinguish between
- Channels whose measured values are constant and have all been filtered out except for one initial value,
- channels that temporarily no longer provide measured values (e.g. because a load-related delay has occurred) and
- channels that no longer provide any measured values (e.g. because a sensor has failed).
The concept of a trusted timestamp provides a remedy here. This timestamp defined by the producing module corresponds to
- either (implicitly) the time stamp of the last measured value produced
- or can be (explicitly) defined. It makes sense for this timestamp to be more recent than the timestamp of the last measurement value produced. In this case, the last measured value of the data sequence can be assumed to be valid up to the trustworthy timestamp (INCLUDING).
Filter architecture
The smartCORE filter architecture essentially consists of a cascade of successive filter stages.
A single filter stage from this receives both a time-stamped sequence of measured values and a trustworthy time stamp on the input side and transforms this in principle in any way into a new sequence of time-stamped measured values and a new trustworthy time stamp.
Filter for data reduction
The configuration of a filter cascade consisting of the datareduction filter is suitable for data reduction on the part of producing modules.
This filter is configured (e.g. as part of an interactive channel configuration by the user) as a JSON object, e.g. as follows
{
"name": "datareduction",
"absTolerance": 0.0,
"timeoutMs": 60000
}
In the case of numerical measured values, all values that deviate from the last value produced by less than the specified deviation absTolerance are discarded.
However, this filtering only takes place if there is less time between the last value produced and the value currently under consideration than was specified by timeoutMs, i.e. a sample is always included in the channel to be produced after ``timeoutMs``` has expired (production of additional support values).
In the case of string and bytearray types, the specified absolute tolerance is ignored and any deviation is regarded as an effective deviation.
The production of additional supporting values is (formally speaking) unnecessary, as the consuming modules themselves are responsible for a meaningful interpretation of the provided validity ranges of the data (due to trustworthy timestamps). However, it has proven expedient to insert additional (real) support values on the part of producing modules, as this allows the use of producing modules with incorrectly implemented consuming modules (e.g. no undesired timeout situation occurs).