Spezifikationen für IoT-Cloud-gesteuerte Systeme

Neben einer allgemeinen Systemstruktur suchen wir nach den technischen Grenzen, die zur Funktionalität eines IoT-Cloud-gesteuerten Systems eingehalten werden müssen und beschäftigen uns hierunter mit nachfolgenden Aspekten.

Vorkonfiguration

Bei klassischen Systemen besteht ein nicht unwesentlicher Aufwand in der Verkabelung und Systemintegration der Geräte. Analog bedarf es bei IoT-Systemen ggf. eines höheren Konfigurationsaufwands, beispielsweise zur Herstellung von Internetkonnektivität und der Kommunikation mit der Cloud. Um den Einrichtungsprozess zu vereinfachen, könnten die Geräte bereits vorkonfiguriert den ausführenden Firmen bereitgestellt werden; zu berücksichtigen wären unter anderem:

  • Internetkonfigurationen
  • Firewall-Einstellungen
  • Cloud- / Server-Kommunikation
  • Sicherheitsspezifische Daten
    • Server- und ggf. Client-Zertifikate
  • Ggf. weitere Daten wie
    • Parametertemplates/-API
    • Geräte- und Datenpunkttyp

Genauigkeiten und Auflösung

Analog zu Verzögerungen wirken sich Sensorungenauigkeiten oder eine geringe Auflösung ebenfalls auf die Regelung eines Systems aus. Insbesondere neuartige IoT-Sensoren versprechen häufig durch günstige Kosten die Möglichkeit einer breiten Abdeckung mit Messtechnik, haben jedoch im Vergleich zur klassischen, im höheren Preissegment angesiedelten Messtechnik oft entsprechend nachteilige Eigenschaften wie geringere Genauigkeiten und Messwertauflösungen. Gleichermaßen muss die Messwertaufnahme im Falle von günstigen Gateways sowie die Auflösung der Sollwertsignale im Hinblick auf den Regelungseinfluss untersucht werden. Sollte die Stabilität der Regelung auch mit deutlich geringeren Genauigkeiten und Auflösungen zu realisieren sein, ist eine größere Abdeckung und Messbasis damit möglich.

Speichervorhaltung und Fallback-Strategien

Neben der Einrichtung von COV können Buffer in Kombination mit Datenkompression die Datenlast verringern. Eine Speichervorhaltung bei Ausfall der Kommunikation kann einen Datenverlust verhindern und wichtige Diagnosedaten für den Ausfall liefern. Grundsätzlich sind unseres Erachtens vier Szenarien zu bewerten:

  • Normalbetrieb
  • Stromausfall
  • Internetausfall
  • Ausfall von Strom und Internet

Insbesondere in dem Fall, in dem die Kommunikation über das Internet nicht besteht, muss ein definierter Anlagenbetrieb gewährleistet werden. Dieser könnte beispielsweise durch im Feld oder Edge-Gerät  hinterlegte Fallback-Parameter sichergestellt werden, sobald ein Kommunikationsausfall detektiert wird. Je nach Gebäude- und Anlagentyp müssen die Fallback-Parameter individuell gewählt werden. Im einfachsten Fall orientieren sich die Parameter am Beispiel des Stromausfalls und schalten die Anlage gezielt ab. Sollte der Kommunikationsausfall serverseitig verursacht sein, wäre beispielsweise ein redundantes System in der Lage, die Befehlskette aufrecht zu erhalten. Die Ausfallhäufigkeit und -dauer müssen daher für die Komponenten Internet/LTE/Strom geprüft und bewertet werden.

Latenzen und Zykluszeiten

Durch die Kommunikation zwischen Feld und Cloud wird die lokal meist schlanke Kommunikationsstrecke möglicherweise durch Router und Accesspoints oder Basisstationen im Falle einer LTE-Übertragung verlängert. Die Regelungsapplikation kann darüber hinaus ebenfalls auf einem anderen externen Server liegen, wodurch weitere Kommunikationsstrecken hinzukommen. In Summe könnten dadurch höhere Latenzen auftreten, die sich nachteilig auf die Regelung auswirken, die wiederum, je nach Regelparametern, instabil werden kann. Die Toleranz gegenüber Verzögerungen wird abhängig von der Systemdynamik sein. Hier sind die Zykluszeiten (für Sensorwerte und Aktorsollwerte) in verschiedenen Szenarien zu untersuchen und anhand des Regelverhaltens zu bewerten.

Mehrwert

Eine Frage, die sich auch den Herstellern der Geräte und Anbietern von Cloud-Diensten immer wieder stellt, ist die anschauliche Darstellung der Vorteile für den Kunden. Viele genannte Vorteile sind bisher eher diffus oder kaum in der Praxis nachgewiesen, sodass nicht ohne Weiteres eine Einsparung oder Ähnliches beziffert werden kann. Hier gilt es Vergleichsmethoden und -kriterien zu finden, nach denen sich anschließende Experimente zu einem entsprechenden anschaulichen Ergebnis kommen.

Format der Datenübertragung

Zur Übertragung der Daten können verschiedene Protokolle verwendet werden. Wir haben uns in einem ersten Versuch für MQTT entschieden. Eine Nachricht über das MQTT-Protokoll, welches mit dem Publish-Subscribe-Muster arbeitet, besteht aus einem topic und einem payload. Da der payload frei formatiert werden kann, ist MQTT als solches datenagnostisch. Beispielsweise können Daten im JSON-Format übertragen werden. Als minimal notwendige Kategorien sehen wir den Datenpunktnamen als eindeutige ID, den zu übermittelnden Wert sowie den Timestamp. Für einen String mit diesen Kategorien würden durchschnittlich 128 bytes pro gesendeter Nachricht anfallen. Ein COV auf Feldseite kann die Anzahl der Sendevorgänge und damit die Datenlast deutlich verringern. Metadaten wie Geräte- und Datenpunktypen sollten nur einmalig oder bei Änderung übertragen werden.

Anmeldung von Geräten bei der Cloud

Zur Anmeldung von Geräten bei der Cloud sollte ein standardisierter Workflow bestehen, der vor allem eine sichere Einrichtung unter Vermeidung von Schwachstellen für Angreifer ermöglicht. Hierunter fällt beispielsweise auch der Prozess zur Einrichtung von TLS-Zertifikaten. Unter Umständen können nicht alle Geräte bereits vollständig konfiguriert an den Einsatzort gebracht werden, sodass eine einfache Konfiguration vor Ort möglich sein muss. Die Konfiguration sollte hierbei bestenfalls nur mit unmittelbarem Zugang zum Gerät und mit einem zusätzlichen der Cloud vertrauten Gerät oder via sicherer Verbindung über eine Web-Schnittstelle erfolgen.

Informiert bleiben und mitmachen…