In einer IoT-Anwendung soll eine Hardware mit ihren Sensoren und Aktoren als physische Repräsentanz ein jeweils aktuelles Datenabbild an eine virtuelle Repräsentanz liefern. SSV
In vielen Maschinen und Anlagen ist lediglich die zentrale Steuerung, zum Beispiel eine SPS, über die angeschlossenen Sensoren in der Lage, eine Störung sicher zu erkennen. Liegt die Störungsursache aber außerhalb des von der SPS gesteuerten Prozesses, wird der Störungsfall vermutlich erst dann erkannt, wenn ein Schaden bereits eingetreten ist. Typisches Beispiel dafür sind eine unsaubere Energieversorgung mit Spannungsschwankungen oder durch fehlerhafte Frequenzumrichter verursachte Netzstörungen. Die SPS kann in diesem Fall erst dann eine Störung erkennen, wenn ein an sie angeschlossener Aktor beschädigt wurde. Zusätzliche Sensoren, die nicht mit der SPS verbunden sind, weil sie ausschließlich zum Anlagen-Monitoring und zur präventiven Wartungsplanung genutzt werden, ermöglichen die frühzeitige Störungserkennung – bevor überhaupt ein Schaden und somit ein unnötiger Stillstand eintritt.
Doch wie bekommen Anwender diese Daten in ein IoT- oder Fernwartungssystem? Anbieterneutrale Orientierungshilfen findet man zum Beispiel über das Förderprojekt Internet of Things Architecture (IoT-A) der Europäischen Union. In diesem EU-Flagship-Projekt aus dem FP7-Forschungsprogramm, unter dessen Schirm auch das Programm ‚Horizon 2020‘ läuft, sollte ein möglichst universelles Referenzmodell für zukünftige IoT-Anwendungen entwickelt werden. Sensoren, Aktoren und Devices – also die Things des Internet of Things – bilden in diesem Modell die physischen Repräsentanzen. Zu jeder physischen Repräsentanz gehört eine virtuelle (Daten-)Repräsentanz, die zum Beispiel durch einen Cloud- oder IoT-Service im Internet realisiert wird. Auf einer solchen IoT-Serviceplattform wird der aktuelle Zustand der Sensoren und Aktoren gespeichert und bei Bedarf erneuert, zum Beispiel bei jeder Zustandsänderung. Auf das jeweils aktuelle Datenabbild können andere Systeme und Benutzer mit einem Application Programming Interface (API) zugreifen. Ein solches Cloud- oder IoT-Service-API muss in der Regel unterschiedliche IT-Protokolle sowie plattformunabhängige Datenformate unterstützen und darüber hinaus geeignete Sicherheitsmechanismen anbieten.
In einer IoT-Anwendung soll eine Hardware mit ihren Sensoren und Aktoren als physische Repräsentanz ein jeweils aktuelles Datenabbild an eine virtuelle Repräsentanz liefern. SSV
Von real zu virtuell
Die Daten der virtuellen Repräsentanzen und die dazugehörenden APIs bilden den eigentlichen Funktionskern einer IoT-Anwendung. Über die APIs sind alle externen Komponenten – von der Hardware eines Sensors oder Aktors bis zu den übergeordneten IT-Systemen (Scada, ERP, CRM, MES oder SQL) sowie Smartphone-Apps und Webanwendungen in eine IoT-Applikation eingebunden. Mithilfe der IoT-Service-APIs lassen sich Datenobjekte anlegen, verwalten, die einzelnen Datenelemente lesen, mit neuen Werten versehen und – falls erforderlich – auch wieder löschen. Die Daten selbst werden in der Regel in einer speziellen Datenbank gespeichert.
Für die externe Benutzer- und Anwendungssicht kommen bei der IoT-Serviceplattform Real Time Data Channels von SSV Datenformate wie JSON (Javascript Object Notation) oder XML (Extensible Markup Language) zum Einsatz. Auf der Plattform ist so jede einzelne IoT-Anwendung ein separates Datenprojekt mit einem individuellen Schlüsselpaar für die Zugriffsberechtigung per API. Ein solches Datenprojekt enthält beliebig viele Datenobjekte, die sich wiederum aus einzelnen Daten-Items zusammensetzen. Ein Datenobjekt ist zum Beispiel ein Lagesensor, die Positionswerte sind das Daten-Item. Die Anzahl der Datenprojekte, -objekte und Items ist nicht begrenzt. Grenzen existieren lediglich durch die Hardware-Ressourcen der Server, auf denen die Serviceplattform läuft.
Ein IoT-Service dient als universelle Datenschnittstelle für Smartphone-Apps, andere IT-Systeme (zum Beispiel ERP, CRM, MES, oder SQL) und zur Benachrichtigung der Servicemitarbeiter im Störungsfall. SSV
Mehr Sensordaten, mehr Möglichkeiten
Durch die zentrale Datenhaltung auf Basis offener IT-Formate und die entsprechenden APIs existieren verschiedene Möglichkeiten, die Daten zu nutzen. Hierzu drei Beispiele:
Schnittstellen für Scada, Monitoring und Apps: Visualisierungslösungen und Monitoring-Anwendungen über das Simple Network Management Protocol (SNMP) können über die dafür vorgesehenen Schnittstellen auf die Daten zugreifen, um den jeweils aktuellen Gesamtzustand darzustellen. Dabei stehen nicht nur die einzelnen Datenbausteine einer Steuerung, sondern auch alle weiteren Sensordatenpunkte für die weitere Nutzung zur Verfügung.
Datenquelle für Enterprise-IT-Systeme: Die aktuellen Werte aller Datenpunkte können von der IoT-Serviceplattform aus an übergeordnete IT-Systeme weitergegeben werden. SPS- und Prozessdaten aus der Feldebene lassen sich zum Beispiel direkt in SQL-Datenbanken einfügen. In der Unternehmens-IT sind so Prozessdatenhistorien sowie Condition-Monitoring-Anwendungen für die Maschinen- und Anlagendaten möglich, ohne zusätzliche OPC-Server dazwischenzuschalten.
Echtzeitdaten für Alarmmeldungen: Da die Steuerungs- und Sensordaten bei jeder Änderung mithilfe eines Echtzeit-Message-Protokolls unverzüglich von der Feldebene an die virtuelle Repräsentanz auf der IoT-Serviceplattform übergeben werden, kann der IoT-Service sie hinsichtlich eventueller Alarmkonditionen prüfen. Wenn die Daten bei jeder Änderung auf die gleiche Art und Weise weitergeleitet werden, sind diese Prüfungen und die eventuell erforderliche Alarmierung auch direkt beim Daten-Abonnenten (Subscriber) möglich, also beim Instandhalter oder Techniker.
Eine Steuerung oder externe Sensoren liefern bei jeder Änderung aktuelle Daten über IoT-Service-APIs per Rest, MQTT oder Websocket an die virtuelle Repräsentanz. Von dort aus werden sie zum Beispiel bei jeder Änderung sofort an eine Smartphone-App weiterg SSV
Application Gateway statt VPN-Router
In vielen Fernzugriffslösungen in der Automatisierung kommen keine einfachen VPN-Router, sondern spezielle Application Gateways zum Einsatz. Solche Systeme können neben den VPN-Funktionen zusätzlich auch SPS- und Sensordaten an eine IoT-Serviceplattform liefern, um eine virtuelle Repräsentanz mit aktuellen Zustandsdaten zu versorgen. Auf diese Daten kann zum Beispiel eine Smartphone-App zugreifen, um Servicemitarbeitern jederzeit den aktuellen Maschinenzustand anzuzeigen. Wenn für die Kommunikation zwischen IoT-Service und App ein Message-Protokoll mit entsprechendem Echtzeitverhalten wie Message Queue Telemetry Transport (MQTT) verwendet wird, kann die Smartphone-App auch die Alarmierung übernehmen. Möglich wird dies in erster Linie durch das ereignisgesteuerte MQTT-Publish/Subscribe-Verhalten. Wenn sich mindestens ein Sensorwert in der Anlage verändert hat, übermittelt das Fernzugriffs-Gateway neue Daten an den IoT-Service. Von dort werden die geänderten Daten sofort an alle Nutzer weitergeleitet. Und es wird geprüft, ob eine Alarmkondition vorliegt. Ist dies der Fall, erzeugt die App einen Klingelton oder löst den Vibrationsalarm aus. Die Alarmierung bleibt solange bestehen, bis ein Mitarbeiter per VPN aus der Ferne auf die Maschine zugreift und die Ursache beseitigt.
Hannover Messe 2015
Halle 8, Stand D37
Jörg Neumann
(mf)
