Service-VPNs werden in der Automatisierung für den Fernzugriff auf Steuerungen und andere Anlagenbestandteile eingesetzt. Häufig ist eine Störung der Auslöser für einen erforderlichen Zugriff. Zur Alarmierung im Störungsfall dient nach wie vor eine SMS, obwohl diese Nachrichtenform relativ unzuverlässig ist und Zusatzkosten verursacht. Mit Hilfe des M2M-Protokolls MQTT und einer virtuellen Datenrepräsentanz aus dem Internet der Dinge (Internet of Things/IoT) lassen sich auch bestehende Fernzugriffslösungen optimieren.
DER AUTOR Klaus-Dieter Walter ist Geschäftsführer der SSV Software Systems GmbH und Mitglied der M2M Alliance e.V.
Ein typisches Service-VPN (Virtual Private Network) dient in der Automatisierungstechnik als Infrastruktur, um Wartungsarbeiten und Störungsbeseitigungen ohne kostenintensive Reisezeiten und unnötigen Zeitverlust direkt am Arbeitsplatzrechner eines Servicemitarbeiters durchzuführen. Im Störungsfall muss der Mitarbeiter jedoch benachrichtigt werden, bevor er per PC und VPN auf die Anlage zugreifen kann. Dazu wird in der Regel eine SMS aus der Anlage heraus über ein SMS-Alarmmodem versendet. Eine solche SMS ist aus drei Gründen unzuverlässig: 1. Es gibt keine Garantie, wann und ob sie überhaupt den adressierten Empfänger erreicht. 2. Eine Quittierung ist nicht vorgesehen – die SMS kommt zwar beim Mitarbeiter an, wird aber nicht beachtet. 3. Die SMS wird im Klartext übertragen und bietet keinerlei Datensicherheit. Darüber hinaus verursacht ein SMS-Alarmmodem durch Beschaffung und Betrieb erhebliche Zusatzkosten.
Virtuelle Datenrepräsentanzen
Das Internet der Dinge steckt, genau wie die industrielle Variante Industrie 4.0, noch in den Kinderschuhen. Die einzelnen Bausteine und Komponenten existieren allerdings schon und können – unabhängig vom IoT-Marketing-Hype – zusammen mit M2M-Technik auch in Automatisierungslösungen zum Einsatz kommen. Anbieterneutrale Orientierungshilfen findet man zum Beispiel über das Internet-of-Things-Architecture-Förderprojekt (IoT-A) der Europäischen Union. Über dieses EU-Flagship-Projekt aus dem FP7-Forschungsprogramm sollte ein möglichst universelles Referenzmodell für zukünftige IoT-Anwendungen entwickelt werden. Sensoren, Aktoren und Devices – also die „Things“ des IoT – bilden in diesem Modell die physischen Repräsentanzen. Zu jeder physischen Repräsentanz gehört wiederum eine virtuelle Repräsentanz, die zum Beispiel durch einen Cloud- bzw. IoT-Service im Internet realisiert werden kann. Auf einer solchen IoT-Serviceplattform wird der aktuelle Zustand der Sensoren und Aktoren bzw. einer Hardware gespeichert und bei Bedarf (zum Beispiel bei jeder Zustandsänderung) erneuert. Auf das jeweils aktuelle Datenabbild können andere Systeme und Benutzer mittels eines Application Programming Interface (API, zum Beispiel sogenannte REST-APIs) zugreifen. Ein solches Cloud- bzw. IoT-Service-API muss in der Regel unterschiedliche M2M- und IT-Protokolle sowie plattformunabhängige Datenformate unterstützen und geeignete Sicherheitsmechanismen anbieten.
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 bzw. Aktors – bis zu den übergeordneten IT-Systemen (Scada, ERP, CRM, MES, SQL usw.) sowie Smartphone-Apps und Webanwendungen in eine IoT-Applikation eingebunden. Mit Hilfe der IoT-Service-APIs werden Datenobjekte angelegt, verwaltet, die einzelnen Datenelemente gelesen, mit neuen Werten versehen und – falls erforderlich – auch wieder gelöscht. Die Daten selbst werden in der Regel in einer speziellen Datenbank gehalten.
Für die externe Benutzer- bzw. Anwendungssicht kommen Datenformate wie JSON oder XML zum Einsatz, siehe zum Beispiel die JSON-basierten Real Time Data Channels (RTDC) unter http://tinyurl.com/pz7wpwr. Auf einer RTDC-basierten IoT-Serviceplattform bildet jede einzelne IoT-Anwendung ein separates Datenprojekt mit einem individuellen Schlüsselpaar für die Zugriffsberechtigung per API. Ein RTDC-Datenprojekt beinhaltet beliebig viele Datenobjekte, die sich aus einzelnen Daten-Items zusammensetzen. Limitierungen hinsichtlich der Datenprojekt-, Objekt- und Item-Anzahl existieren nur durch die Hardware-Ressourcen der Server, auf denen eine RTDC-IoT-Serviceplattform läuft.
Datennutzungsvielfalt
Durch die zentrale Datenhaltung auf Basis offener IT-Formate (JSON, XML) und die APIs existieren weitreichende Datennutzungsmöglichkeiten. Hierzu einige Beispiele:
Schnittstelle für Scada und Apps: Visualisierungslösungen 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 Sensordatenpunkte für den Zugriff zur Verfügung.
Datenquelle für 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 sind z.B. direkt in SQL-Datenbanken einfügbar. Dadurch lässt sich eine Prozessdatenhistorie in einer Datenbank realisieren, ohne einen zusätzlichen OPC-Server dazwischenzuschalten.
Echtzeitdaten für Alarmmeldungen: Da die Steuerungs- und Sensordaten bei jeder Änderung mit Hilfe eines M2M-Protokolls von der Feldebene an die virtuelle Repräsentanz auf der IoT-Serviceplattform übergeben werden, können sie vom IoT-Service hinsichtlich der Alarmkonditionen geprüft werden. Werden die Daten bei jeder Änderung auf die gleiche Art und Weise weitergeleitet, können die Prüfungen und die erforderliche Alarmierung beim Daten-Abonnenten (Subscriber), z.B. einer Smartphone-App, erfolgen.
Gateway statt VPN-Router
In vielen Fernzugriffslösungen in der Automatisierung kommen keine VPN-Router, sondern spezielle Remote-Access-Gateways (RAGs – z.B. http://tinyurl.com/lk3gd8l) oder M2M-Gateways zum Einsatz. Solche Systeme können neben den VPN-Funktionen zusätzlich auch Daten an eine Cloud- bzw. IoT-Serviceplattform liefern, um eine virtuelle Repräsentanz mit aktuellen Zustandsdaten zu versorgen. Auf diese Daten kann eine Smart-phone-App zugreifen, um einem oder einer Gruppe Servicemitarbeiter den aktuellen Anlagenzustand anzuzeigen. Wird für die Kommunikation zwischen IoT-Service und App ein modernes M2M-Message-Protokoll mit entsprechendem Echtzeitverhalten wie MQTT (http://mqtt.org/) verwendet, kann die App die SMS-Alarmierung vollständig ersetzen. Möglich wird dies durch das ereignisgesteuerte MQTT-Publish/Subscribe-Verhalten. Jedes Mal, wenn sich mindestens ein Datenwert verändert hat, übermittelt das RAG neue Daten an den IoT-Service. Von dort werden die geänderten Daten sofort an alle Subscriber – in diesem Fall die Smartphone-Apps – weitergeleitet. Dort wird geprüft, ob eine Alarmkondition vorliegt. Ist das der Fall, erzeugt die App einen Klingelton bzw. löst den Vibrationsalarm aus. Die Alarmierung bleibt bestehen, bis ein Mitarbeiter per VPN aus der Ferne auf die Maschine- bzw. Anlage zugreift und die Alarmierungsursache beseitigt. ge
INFO & KONTAKT
SSV Software Systems GmbH
Dünenweg 5
30419 Hannover
Tel.: 0511/40 000-0
Fax: 0511/40 000-40
Mehr Informationen zum Thema bietet der Flyer:
Teilen:
