Industrie-Elektronik
Fit für das Internet der Dinge
Fortsetzung des Artikels von Teil 1
Middleware für MSR-Anwendungen
Um MSR-Verbundanwendungen zu realisieren, ist neben der permanenten Internetverbindung aller Komponenten und der Cloud-Serviceplattformen auf jeden Fall eine geeignete Middleware erforderlich. Sie bildet das eigentliche Backend und somit die Vermittlungs- und Informationsschicht für alle Front-end-Systeme.
Jobangebote+ passend zum Thema
Bild 3 illustriert den Aufbau einer solchen Middleware. Die Frontends werden in diesem Beispiel durch die MSR-Baugruppen, verschiedene Smartphone-Anwendungsprogramme, Visualisierungslösungen für PCs sowie andere Systeme gebildet - zum Beispiel Datenbanken und IT-Anwendungen aus dem MES-/ERP-Umfeld. Alle Frontend-Systeme kommunizieren per HTTP mit der Middleware. Die MSR-Daten werden von dieser Middleware in einer Data Engine gespeichert. Alle Schreib- und Lesezugriffe auf diese Data Engine erfolgen mit Hilfe von REST-Webservices. REST steht für REpresentational State Transfer und ist ein Architekturmodell für Webservices, die mit Hilfe der HTTP-Methoden GET, PUT, POST und DELETE realisiert werden [2].
In einer REST-Architektur wird jedes Objekt bzw. jedes MSR-Datum als Ressource betrachtet, die über einen URI (Uniform Resource Identifier - also der einheitliche Bezeichner, mit dem auch Webseiten adressiert werden) adressiert werden kann. Überträgt man diese Sicht der Dinge auf eine MSR-Baugruppe mit je zwei digitalen Eingängen und Ausgängen, erhält man die URIs der folgenden vier REST-Ressourcen:
- http://msr-baugruppe_1.de/eingang1
- http://msr-baugruppe_1.de/eingang2
- http://msr-baugruppe_1.de/ausgang1
- http://msr-baugruppe_1.de/ausgang2
Mit dieser Methodik lassen sich auch die Modbus-Variablen einer MSR-Baugruppe sehr einfach adressieren. Modbus benutzt einfache Registeradressen, hinter denen sich binäre bzw. analoge Ein-/Ausgänge und andere Datenpunkte verbergen. Diese lassen sich praktisch direkt mit einem URI verknüpfen. Sollen zum Beispiel die Eingangsdaten an den Modbus-Eingaberegistern 30001 und 30002 abgefragt werden, wären die folgenden beiden URIs erforderlich:
- http://msr-baugruppe_2.de/30001
- http://msr-baugruppe_2.de/30002
Um derartige Ressourcen einzeln anzusprechen, nutzt REST die HTTP-Methoden GET, PUT, POST und DELETE (Tabelle). Mit einem HTTP-GET-Request würde man in diesem Beispiel den aktuellen Binärwert eines Eingangs einlesen und mit dem HTTP-PUT-Request den gewünschten Bit-Wert zum betreffenden Ausgang schreiben. POST und DELETE dienen dem Ressourcen-Management und wären in diesem Beispiel ohne Funktion.
| HTTP-Methode | REST-Funktion |
|---|---|
| GET | Daten von einer vorhandenen Ressource lesen |
| PUT | Daten zu einer Ressource schreiben (falls die Ressource noch nicht existiert, wird sie zuvor angelegt) |
| POST | Erzeuge eine neue Ressource |
| DELETE | Lösche eine vorhandene Ressource |
Webservices, die dem REST-Architekturmodell folgen, benutzen lediglich vier unterschiedliche HTTP-Methoden für den Zugriff auf Ressourcen. Alle Ressourcen werden durch eine URI adressiert. Für viele MSR-Anwendungen reicht in der Regel die Implementierung der jeweiligen PUT- und GET-Methoden.
Das „State Transfer“ in REST bedeutet, dass mit jedem HTTP-Request bzw. jeder HTTP-Response jeweils ein kompletter Status - also alle Daten, die einen bestimmten Zustand beschreiben - übertragen wird. Dadurch ergibt sich ein weiteres wichtiges REST-Merkmal: die Zustandslosigkeit. Ein REST-Server oder -Client muss sich zwischen zwei aufeinanderfolgenden Request-Vorgängen nichts merken. Die aus dem Web bekannten „HTTP-Cookies“ sind für REST-Lösungen nicht erforderlich - das bedeutet: Eine MSR-Baugruppe muss Zustände nicht dauerhaft zwischenspeichern. Weiterhin ist ein HTTP-Request bzw. die HTTP-Response an keinen bestimmten Datentyp gebunden. Es können sowohl XML- als auch HTML-, JSON- oder einfache ASCII-Datenwerte übertragen werden. Für Visualisierungs-Frontends im Web bietet die Middleware aus Bild 3 zwei unterschiedliche HTTP-Schnittstellen. Über einen „HTTP(S) UI Server Process“ werden die statischen Webseiten einer Benutzerschnittstelle (UI) bei Bedarf vom Frontend angefordert. Diese wurden zuvor über einen VPN-gesicherten FTP-Upload an die Middleware übergeben.
In diese Webseiten ist wiederum ein JavaScript-Code eingebettet, der per REST periodisch auf die Webschnittstelle der Data Engine zugreift, um die aktuellen MSR-Echtzeitdaten anzufordern. Das Listing zeigt den vollständigen Code für ein zu Bild 3 passendes Beispiel, mit welchem eine Temperatur visualisiert wird.
Security für den Hausgebrauch
Wird heute eine Anlage mit vernetzten MSR-Komponenten erstmalig mit dem Internet verbunden, vergehen nach den Untersuchungen der Sicherheitsfirma Trend Micro nur wenige Stunden bis zum ersten gezielten Angriff aus dem weltweiten Netz. Die Angreifer kommen aus der gesamten Welt und haben offensichtlich das erforderliche Fachwissen für nicht autorisierte Zugriffe auf spezielle MSR-Baugruppen und deren Manipulationen.
Die Motive dieser Hacker sind laut Trend Micro völlig unklar. In einigen Fällen dürfte es sich aus heutiger Sicht aber wohl um NSA-Zugriffe handeln. In den bisher von verschiedenen Medien veröffentlichen vertraulichen Dokumenten findet man deutliche Hinweise darauf, dass dieser Nachrichtendienst eine Datenbank mit den Schwachstellen aller weltweit erreichbaren Computersysteme aufgebaut hat und laufend aktualisiert [3].
Trotz allem trifft man in der MSR-Welt vielfach noch auf den Standpunkt, dass die Daten einer MSR-Anwendung für Außenstehende doch völlig uninteressant seien und deshalb keine besonderen Schutzmaßnahmen ergriffen werden müssten. Dieser Standpunkt trifft heute noch nicht einmal zu, wenn eine Anwendung nur lokal betrieben wird - siehe Stuxnet, hier wurde eine Schad-Software per USB-Stick in das MSR-System eingebracht.
Neben der rechtlich ungeklärten Fragestellung, ob man die genannten SaaS- und PaaS-Angebote mit Servern außerhalb des deutschen Rechtsraums für eine bestimmte MSR- bzw. M2M-Anwendung einsetzen darf, muss auf jeden Fall der Sicherheit deutlich mehr Aufmerksamkeit zuteil werden. Sie sollte bei jedem Projekt ganz oben im Lastenheft stehen. Dabei sollten einige Grundregeln beachtet werden:
Lesende Zugriffe auf MSR-Daten, die nicht unter das Bundesdatenschutzgesetz fallen und nicht als besonders vertrauenswürdig eingestuft werden, können per HTTP erfolgen. Hier reicht u.U. eine Authentifizierung per Benutzername/Passwort.
Für Lesezugriffe auf vertrauliche Daten sollte eine SSL/TLS-Verbindung verwendet werden. Es ist auf eine eindeutige Authentifizierung des Leseberechtigten zu achten. Darüber hinaus empfiehlt sich das Signieren der gesamten Daten, um mögliche Verfälschungen zu erkennen.
Alle Schreibzugriffe mit MSR-Daten sollten ausschließlich durch einen VPN-Tunnel oder über eine SSL/TLS-gesicherte Verbindung erfolgen. Die Authentifizierung muss beidseitig über Zertifikate erfolgen, die im Zweifelsfall für ungültig erklärt werden können - das jeweilige Frontend wäre dann von der weiteren Kommunikation mit der Cloud-Serviceplattform bzw. der Middleware ausgeschlossen.
Die Umsetzung dieser Regeln hindert allerdings bestenfalls Gelegenheits-Hacker und gewöhnliche Cyberkriminelle vor Angriffen auf eine MSR-Lösung, wie in Bild 2 dargestellt. Vor Zugriffen und Manipulationen durch die Cyberexperten staatlicher Einrichtungen kann man derartige Anwendungen praktisch nicht schützen. Die aktuelle Berichterstattung und Diskussion über Xkeyscore, Prism und Tempora [3, 4] zeigt mehr oder weniger deutlich, dass sich Stuxnet jederzeit und überall wiederholen kann.
Literatur
[1] US-Marktforschungsunternehmen Harbor Research: www.harborresearch.com
[2] Weitere Informationen zu REST-Webservices findet man unter: http://de.wikipedia.org/wiki/Representational_State_Transfer
[3] Nachrichtenmagazin Der Spiegel: http://www.spiegel.de/netzwelt/netzpolitik/xkeyscore-wie-die-nsa-ueberwachung-funktioniert-a-914187.html
[4] The Guardian: http://www.theguardian.com/world/2013/jul/31/nsa-top-secret-program-online-data
Der Autor
| Stefan Klünder |
|---|
| ist Betriebswirt (staatl. gepr.) und sammelte erste berufliche Erfahrungen in der Bauteiledistribution. Ab 2005 war er internationaler Sales Manager bei der Permalight GmbH, einem Hersteller für bodennahe Leitsysteme. Seit 2013 ist er bei SSV als Sales- und Projektmanager tätig. |
- Fit für das Internet der Dinge
- Middleware für MSR-Anwendungen
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Middleware-Plattform für Embedded Systeme
Die Middleware in der Cloud
Programm online
embedded world Conference 2014
Interview mit Joachim Dressler, Sierra Wireless
M2M als Voraussetzung für Industrie 4.0
ARM TechCon 2013
ARM-CEO Simon Segars beschwört „Garagen-Kultur“ beim Internet der Dinge
Wireless Congress 2013
Das Internet der Dinge ist "Wireless"
