Kanäle
In diesem Abschnitt werden smartCORE Kanäle vorgestellt und Prinzipien ihrer Verwendung beschrieben.
Architektur
Kanäle im smartCORE Kontext stellen die Kommunikation zwischen produzierenden und konsumierenden Modulen sicher. Sie werden seitens eines einzigen produzierenden Moduls angelegt sowie beschrieben und können von mehreren konsumierenden Modulen gelesen werden. Auf Sicht der Software stellt ein (zeitgestempelter) smartCORE Kanal im wesentlichen einen Ringpuffer zeitgestempelter Messwerte eines vorher festgelegten Datentyps dar. Darüberhinaus stellt ein sogenannter Prozessvariablen-Kanal einen einzigen Messwert mit zugehörigem Zeitstempel seiner letzten Aktualisierung dar.
Kanal- und Datentypen
Wir unterscheiden grundsätzlich zwischen
- zeitgestempelten Kanälen (timestamped channels), die eine Zeitreihe an Messwerten bereitstellen sowie
- Prozessvariablen (process values), welche lediglich den letzten Messwert (z.B. einen Parameter oder eine Eigenschaft) sowie den Zeitpunkt der letzten Änderung, jedoch KEINEN zeitlichen Verlauf bereitstellen.
Hierbei sind sämtliche innerhalb eines smartCORE Kanals "übertragenen" Messwerte stets eindeutig typisiert. Es werden folgende Datentypen unterstützt
| Datentyp | Beschreibung |
|---|---|
| bool | Boolesche Wahrheitswette wie true und false |
| int64 | vorzeichenbehaftete 64-bit Ganzzahlen |
| int32 | vorzeichenbehaftete 32-bit Ganzzahlen |
| int16 | vorzeichenbehaftete 16-bit Ganzzahlen |
| int8 | vorzeichenbehaftete 8-bit Ganzzahlen |
| uint64 | vorzeichenlose 64-bit Ganzzahlen |
| uint32 | vorzeichenlose 32-bit Ganzzahlen |
| uint16 | vorzeichenlose 16-bit Ganzzahlen |
| uint8 | vorzeichenlose 8-bit Ganzzahlen |
| double | Fließkommazahlen doppelter Genauigkeit |
| float | Fließkommazahlen einfacher Genauigkeit |
| string | UTF-8-kodierte Zeichenketten |
| bytearray | binäre Datenblöcke |
| gpslocation | Strukturen für GPS Positionsangaben, bestehend aus drei aufeinanderfolgenden Fließkommazahlen doppelter Genauigkeit für geographische Breite, Länge und Höhe über Meeresspiegel |
Kanalparameter
Insgesamt sind inklusive der o.g. Kanal- und Datentypen folgende Kanalparameter spezifizierbar
| Parameter | Datentyp | Beschreibung |
|---|---|---|
| name | STRING | Name des Kanals |
| channelType | STRING ENUM | Kanaltyp, entweder zeitgestempelt ("timestamped") oder Prozessvariable ("processvalue") |
| dataType | STRING ENUM | Datentyp der Messwerte (siehe oben) |
| bufferSize | UINT > 0 | Puffergröße, d.h. maximale Anzahl von Messwerten innerhalb einer Zeitreihe, bevor älteste Messwerte überschrieben werden |
| physicalDimension | STRING | Physikalische Dimension des Kanals (z.B. Geschwindigkeit, Spannung, Temperatur, ...) |
| physicalUnit | STRING | Physikalische Einheit des Kanals (km/h, V, °C, ...) |
| metaData | JSON OBJECT | Benutzerdefinierte Metadaten |
| filter | JSON ARRAY of channel filter specifications | Benutzerdefinierte Filterkaskade (i.d.R. zur Datenreduktion) |
| persistent | BOOL | Flag, ob Kanal einen Neustart des Systembetriebs überdauert |
| preserved | BOOL | Flag, ob Kanal bei smartCORE Start aus einer Datenbank auf dem Messgerät geladen und in regelmäßigen zeitlichen Abständen in diese Datenbank geschrieben wird (z.B. sinnvoll für Zähler oder anderweitige Betriebsinformationen) |
Integration in smartCORE Betriebszustände
Im Rahmen unterschiedlicher smartCORE Betriebszustände werden smartCORE Kanäle wie folgt gehandhabt. Für nähere Details wird auf die Dokumentation zur smartCORE Statemachine verwiesen.
Anlegen von zu produzierenden Kanälen
Das produzierende Modul fragt in der smartCORE Kanalverwaltung die Erstellung eines Kanalobjekts an und erhält eine Referenz hierauf zurück.
Dieser Vorgang ist aus Sicht der Software ausschließlich im Betriebszustand zur Initialisierung von Producer-Kanälen (InitProducerChannels) möglich.
Auswahl von zu konsumierenden Kanälen
Ein konsumierendes Modul kann zu beliebigen Zeitpunkten eine Referenz auf seitens der smartCORE Kanalverwaltung bereitgestellte Kanäle anfragen. Weiterhin muss ein solches Modul einen Konsumenten (Handle zum Lesen) dieses Kanals registrieren, was ebenfalls zu beliebigen Zeitpunkten möglich ist.
Falls diese Kanäle bereits zum Zeitpunkt der Modulkonfiguration feststehen, wird hierfür in der Software gewöhnlich der Betriebszustand zur Initialisierung von Consumer-Kanälen (InitConsumerChannels) verwendet.
Produktion von Messwerten in Kanäle
Nachdem die Produktion seitens eines Moduls an den smartCORE signalisiert wurde (StartProduce), können seitens dieses Moduls Messwerte in seine Producer-Kanäle geschrieben werden. Dies erfolgt unter Verwendung eines Zeitstempels, wobei dieser Zeitstempel unterschiedlichen Ursprungs (z.B. direkt aus den Daten resultierend oder aber auch der Zeitpunkt der Produktion) sein kann.
In den meisten Fällen erfolgt die Produktion der Messwerte nicht direkt, sondern über eine konfigurierte Kaskade von Filtern (Filter chain), meist mit dem Ziel der Datenreduktion.
Insbesondere im Kontext der Datenreduktion hat sich das Konzept eines vertrauenswürdigen Zeitstempels als sinnvoll erwiesen.
Vertrauenswürdige Zeitstempel (Trusted Timestamps)
Während in einer Teilfolge von zwei aufeinanderfolgenden zeitgestempelten Messwerten die Gültigkeit des ersten Messwerts bis zum Zeitstempel des zweiten Messwerts (AUSschließlich) angenommen werden kann, ist für den letzten Wert einer Folge und somit auch für den letzten produzierten Wert unbekannt, bis wann dieser gültig ist - oder anders formuliert, ob und wann weitere (identische oder veränderte) Messwerte kommen werden.
Dies hat zur Konsequenz, dass der komplette Zeitbereich seit dem letzten Sample NICHT verwendet werden kann, um z.B. in konsumierenden Modulen hierauf basierende Berechnungen auszuführen.
Im Rahmen der Datenreduktion hat sich dies als besonders hinderlich erwiesen, da z.B. ein konstanter Wert lediglich ein einziges Mal produziert und danach schlicht ausgefiltert, d.h. verworfen, wird.
Man kann also grundsätzlich NICHT unterscheiden zwischen
- Kanälen, deren Messwerte konstant sind und allesamt bis auf einen initalen Wert ausgefiltert wurden,
- Kanälen, die vorübergehend keine Messwerte mehr liefern (z.B. weil eine lastbedingte Verzögerung aufgetreten ist) und
- Kanälen, die endgültig keine Messwerte mehr liefern (z.B. weil ein Sensor ausgefallen ist).
Abhilfe schafft hier das Konzept eines vertrauenswürdigen Zeitstempels. Dieser vom produzierenden Modul festgelegte Zeitstempel entspricht
- entweder (implizit) dem Zeitstempel des zuletzt produzierten Messwerts
- oder kann (explizit) festgelegt werden. Sinnvollerweise ist dieser Zeitstempel neuer als der Zeitstempel des letzten produzierten Messwerts. In diesem Fall kann eine Gültigkeit des letzten Messwerts der Datenfolge bis zum vertrauenswürdigen Zeitstempel (EINschließlich) angenommen werden.
Filterarchitektur
Die smartCORE Filterarchitektur besteht im wesentlichen aus einer Kaskade aufeinanderfolgender Filterstufen.
Eine einzige Filterstufe hieraus erhält auf Eingangsseite sowohl eine zeitgestempelte Folge von Messwerten sowie einen vertrauenswürdigen Zeitstempel und transformiert dies auf prinzipiell beliebige Art und Weise in eine neue Folge zeitgestempelter Messwerte sowie einen neuen vertrauenswürdigen Zeitstempel.
Filter zur Datenreduktion
Für eine Datenreduktion auf seiten produzierender Module bietet sich die Konfiguration einer Filterkaskade an, die aus dem datareduction Filter besteht.
Dieses Filter wird (z.B. im Rahmen einer interaktiven Kanalkonfiguration durch den Benutzer) als JSON Objekt z.B. wie folgt konfiguriert
{
"name": "datareduction",
"absTolerance": 0.0,
"timeoutMs": 60000
}
Hierbei werden im Fall numerischer Messwerte sämtliche Werte, die vom zuletzt produzierten Wert um betragsmäßig weniger als die spezifizierte Abweichung absTolerance abweichen, verworfen.
Diese Ausfilterung erfolgt jedoch nur dann, wenn zwischen dem zuletzt produzierten Wert und dem aktuell betrachteten Wert weniger Zeit liegt, als seitens timeoutMs spezifiziert wurde, d.h. es wird nach Ablauf von timeoutMs in jedem Fall ein Sample in den zu produzierenden Kanal aufgenommen (Produktion zusätzlicher Stützwerte).
Für den Fall von string und bytearray Typen wird die spezifizierte absolute Toleranz ignoriert und jede Abweichung als wirksame Abweichung angesehen.
Die Produktion zusätzlicher Stützwerte ist (formal betrachtet) unnötig, da die konsumierenden Module für eine sinnhafte Interpretation der bereitgestellten Gültigkeitsbereiche der Daten (aufgrund vertrauenswürdiger Zeitstempel) selbst verantwortlich sind. Es hat sich jedoch als zweckmäßig erwiesen, zusätzliche (echte) Stützwerte auf seiten produzierender Module einzufügen, da dies die Verwendung produzierender Module mit fehlerhaft implementierten konsumierenden Modulen erlaubt (z.B. keine ungewünschte Timeout-Situation auftritt).