Fernwartungslösungen in der Automatisierung
M2M- und IoT-Technik erweitern Service-VPNs
Service-VPNs kommen in der Automatisierung für den Fernzugriff auf Steuerungen und andere Anlagenbestandteile zum Einsatz. Häufig ist eine Störung der Auslöser für einen solchen Zugriff. Zur Alarmierung im Störungsfall dient nach wie vor eine SMS, ob-wohl diese Nachrichtenform relativ unzuverlässig ist und Zusatzkosten verursacht. Mithilfe des Machine-to-Machine-(M2M-)Protokolls MQTT und einer virtuellen Datenrepräsentanz aus dem Internet of Things (IoT) lassen sich auch bestehende Fernzugriffslösungen erheblich verbessern. Ein typisches Service-VPN dient in der Automatisierungstechnik als Infrastruktur, um Wartungsarbeiten und Störungsbeseitigungen ohne kostenintensive Reisezeiten und unnötigen Zeitverlust direkt vom Arbeitsplatzrechner eines Service-Mitarbeiters aus durchzuführen. Im Störungsfall muss der Mitarbeiter allerdings erst einmal eine Benachrichtigung erhalten, bevor er per PC und VPN auf die Anlage zugreifen kann. Dafür kommt in der Regel eine SMS zum Einsatz, die die Anlage automatisch über ein SMS-Alarmmodem verschickt. Eine solche SMS ist aus drei Gründen unzuverlässig: Erstens gibt es keine Garantie, wann und ob sie überhaupt den adressierten Empfänger erreicht. Zweitens ist keine Quittierung vorgesehen - die SMS kommt zwar beim Mitarbeiter an, dieser beachtet sie aber womöglich nicht. Drittens die Übertragung der SMS im Klartext und bietet keinerlei Datensicherheit. Darüber hinaus verursacht ein SMS-Alarmmodem durch Beschaffung und Betrieb nicht unerhebliche 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 finden Verantwortliche zum Beispiel über das "Internet of Things Architecture"-Förderprojekt (IoT-A) der Europäischen Union. Im Rahmen dieses EU-Flaggschiff-Projekts aus dem FP7-Forschungsprogramm soll sich ein möglichst universelles Referenzmodell für zukünftige IoT-Anwendungen entwickeln. 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 (Bild 1), die sich zum Beispiel durch einen Cloud- beziehungsweise IoT-Service im Internet realisieren lässt. Auf einer solchen IoT-Service-Plattform wird der aktuelle Zustand der Sensoren und Aktoren beziehungsweise 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 Interfaces (API, zum Beispiel REST-API) zugreifen. Ein solches Cloud- beziehungsweise IoT-Service-API muss in der Regel unterschiedliche M2M- und IT-Protokolle sowie plattformunabhängige Datenformate unterstützen und darüber hinaus geeignete Sicherheitsmechanismen anbieten. Die Daten der virtuellen Repräsentanzen und die dazugehörenden APIs bilden den eigentlichen Funktionskern einer IoT- beziehungsweise Industrie-4.0-Anwendung. Über die APIs sind alle externen Komponenten - von der Hardware eines Sensors beziehungsweise Aktors - bis zu den übergeordneten IT-Systemen (SCADA, ERP, CRM, MES, SQL etc.) sowie Smartphone-Apps und Web-Anwendungen in eine IoT-Applikation eingebunden (Bild 2). 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 gehalten. Für die externe Benutzer- beziehungsweise Anwendungssicht kommen als Datenformate zum Beispiel JSON (Javascript Object Notation) oder XML zum Einsatz wie etwa bei den JSON-basierenden Real Time Data Channels (RTDC) von SSV Software Systems. Bei einer IoT-Service-Plattform auf der Basis von RTDC 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 wiederum aus einzelnen Daten-Items zusammensetzen. Limitierungen hinsichtlich der Datenprojekt-, Objekt- und Item-Anzahl existieren lediglich durch die Hardwareressourcen der Server, auf denen eine RTDC-IoT-Service-Plattform läuft. Datennutzungsvielfalt Durch die zentrale Datenhaltung auf der Basis offener IT-Formate (JSON und XML) sowie die entsprechenden APIs existieren weitreichende Datennutzungsmöglichkeiten. Dazu nachfolgend einige Beispiele. Schnittstellen für SCADA, Monitoring und Apps: Visualisierungslösungen und SNMP-Monitoring-Anwendungen 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 Enterprise-IT-Systeme: Die aktuellen Werte aller Datenpunkte lassen sich von der IoT-Service-Plattform aus an übergeordnete IT-Systeme weitergeben. SPS- (speicherprogrammierbare Steuerung) und Prozessdaten aus der Feldebene sind zum Beispiel direkt in SQL-Datenbanken einfügbar. Dadurch lässt sich eine Prozessdatenhistorie in einer Unternehmensdatenbank realisieren, ohne zusätzliche OPC-Server (OPC - OLE for Process Control) dazwischenzuschalten. Datenschnittstellen für Verbundsysteme: Im Zusammenhang mit dem Internet der Dinge und Industrie 4.0 ist oft auch vom "System of Systems" die Rede. Diese Systeme sollen im Vergleich mit bestehenden Lösungen eine deutlich höhere "Intelligenz" aufweisen. Solche Anwendungen beziehen ihre Intelligenz aber wohl in erster Linie aus einer Vielzahl zusätzlicher Sensoren. Die virtuelle Repräsentanz des einen (Sub-)Systems kann dann über APIs die eigenen Sensordaten anderen (Sub-)Systemen zur Verfügung stellen und so ein durchgängig vernetztes Verbundsystem ermöglichen. Echtzeitdaten für Alarmmeldungen: Da die Steuerungs- und Sensordaten bei jeder Änderung mithilfe eines M2M-Protokolls unverzüglich von der Feldebene an die virtuelle Repräsentanz auf der IoT-Service-Plattform übergeben werden, kann der IoT-Service diese hinsichtlich eventueller Alarmkonditionen prüfen. Wenn die Daten bei jeder Änderung auf die gleiche Art und Weise zur Weiterleitung kommen, können diese Prüfungen und die eventuell erforderliche Alarmierung auch beim Datenabonnenten (Subscriber) - zum Beispiel einer Smartphone-App - erfolgen. Application Gateway statt VPN-Router In vielen Fernzugriffslösungen in der Automatisierung kommen keine einfachen VPN-Router, sondern spezielle Application Gateways oder M2M-Gateways zum Einsatz. Solche Systeme sind in der Lage, neben den VPN-Funktionen zusätzlich auch Daten an eine Cloud- beziehungsweise IoT-Service-Plattform zu liefern, um eine virtuelle Repräsentanz mit aktuellen Zustandsdaten zu versorgen. Auf diese Daten kann eine Smartphone-App zugreifen, um einem oder einer Gruppe Service-Mitarbeiter jederzeit den aktuellen Maschinen- beziehungsweise Anlagenzustand anzuzeigen. Wenn für die Kommunikation zwischen IoT-Service und App ein modernes M2M-Message-Protokoll mit entsprechendem Echtzeitverhalten wie MQTT ("Message Queue Telemetry Transport", www.mqtt.org) zum Einsatz kommt, lässt sich die kostenintensive SMS-Alarmierung vollständig durch die Smartphone-App ersetzen. Verantwortlich ist dafür in erster Linie das ereignisgesteuerte Publish/Subscribe-Verhalten von MQTT: Jedes Mal, wenn sich mindestens ein Datenwert in der Anlage verändert hat, übermittelt das Remote Access Gateway (RAG) neue Daten an den IoT-Service. Dieser leitet die geänderten Daten sofort an alle Subscriber - beispielsweise die Smartphone-Apps - weiter. Letztere prüfen, ob eine Alarmkondition vorliegt. Ist dies der Fall, erzeugt die App einen Klingelton beziehungsweise löst den Vibrationsalarm aus. Die Alarmierung bleibt bestehen, bis ein Mitarbeiter per VPN aus der Ferne auf die Maschine beziehungsweise Anlage zugreift und die Alarmierungsursache beseitigt.
Lesen Sie mehr zum Thema
