Um die Ziele zu erreichen, sind zahlreiche, hochkomplexe Aufgaben zu lösen. Eine besondere Herausforderung dürfte dabei die Sicherheit und Interoperabilität der horizontalen Vernetzungsebene bilden. Mit der bisherigen Vorgehensweise und dem Motto \’Security follows function\‘ sowie überwiegend hersteller- und branchenspezifischen Vernetzungsstandards kommen wir nicht weiter. Bevor sich Maschinen, Bauteile und Werkstücke in Industrie-4.0-Anwendungen selbst organisieren, müssen zunächst einmal die technischen Voraussetzungen geschaffen werden. Zur Standortbestimmung eignet sich der Blick in die Welt der M2M (Machine-to-Machine)-Kommunikation.
Stand der Dinge in der M2M-Welt
Die Experten des US-Marktforschungsunternehmens Harbor Research unterteilen die Evolution der M2M-Kommunikation in drei Phasen. Diese Entwicklungsabschnitte differenzieren sich in erster Linie durch die Anwendungskomplexität. In der ersten Phase, die zumindest hinsichtlich der Neuinstallationen weitestgehend hinter uns liegt, sind die Simple Applications (Einfache Anwendungen) zu finden. Zunächst einmal lassen sich die unzähligen Monitoring-Applikationen dieser Phase zuordnen. Dazu gehören Lösungen für Gebäude, Maschinen, Anlagen und Systeme, die bei bestimmten Ereignissen automatisch Messwerte, Störungs- oder Zustandsmeldungen an eine Leitwarte oder ein Monitoringportal übermitteln. Auch das inzwischen recht verbreitete Tracking & Tracing, also die automatische Sendungsverfolgung in der Logistik mit Hilfe von GSM-Funknetzen sowie die existierenden Telematiklösungen fallen in die erste M2M-Anwendungsphase. Kennzeichnend für diese einfachen Anwendungen sind Punkt-zu-Punkt-Kommunikationsbeziehungen. Die zweite Phase der Compound Applications (Verbundanwendungen), in der wir uns gerade befinden, ist in erster Linie durch Cloud-spezifische (Multipunkt-zu-Multipunkt-) Kommunikationsarchitekturen gekennzeichnet. M2M-Devices können nun über die Cloud zum einen auch untereinander Daten austauschen und werden zum anderen zu speziellen Verbundsystemen gekoppelt – z.B. zu cyberphysikalischen Systemen (Cyber-Physical Systems). Darüber hinaus existieren Schnittstellen zum Internet der Menschen, damit beispielsweise per Webbrowser oder Smartphone App auf eine M2M-Anwendung zugegriffen werden kann. Dadurch entstehen Anwendungsplattformen, in denen menschliche Nutzer, Devices und Systeme miteinander verbunden sind. Ein typisches Anwendungsbeispiel für die zweite Phase ist die Datenkommunikation im Smart Grid. Hier werden z.B. durch datentechnische Verbundsysteme virtuelle Kraftwerke geschaffen, in denen die Erzeugung und der Verbrauch unter Einbeziehung der Preise an der Strombörse automatisch angepasst werden. Auch die zukünftige Umsetzung der Industrie 4.0-Ideen und Konzepte fällt aus Sicht der M2M-Kommunikation weitestgehend in diese Phase. Hochentwickelte Condition-Monitoring-Systeme mit Schnittstellen zu Serviceunternehmen und Ersatzteildatenbanken gehören ebenfalls in die Kategorie der M2M-Verbundsysteme. Wann wir von der zweiten in die dritte Phase der Complex Application (Komplexe Anwendungen) wechseln, lässt sich im Moment nur sehr ungenau bestimmen. Unter Umständen ist der Übergang sogar fließend und nicht eindeutig erkennbar. Auf jeden Fall werden dann all die Systeme, die heute schon – teilweise zu Unrecht – als \’Smart\‘ bezeichnet werden, im Internet der Dinge untereinander verbunden sein, um bei Bedarf als Datenpunkte für werthaltige Third-Party-Applikationen zu dienen. Ein Meilenstein für diese Phase könnten Smart-City-Applikationen darstellen, wie sie von IBM unter dem Oberbegriff \’Smarter Planet\‘ und von Siemens mit \’Stadt der Zukunft Smart City\‘ beschrieben werden. Treffen die Prognosen der Analysten zu, werden dann im Durchschnitt für jeden Erdenbewohner ca. sieben bis acht vernetzte Datenpunkte im Internet miteinander kommunizieren. Spätestens in dieser Evolutionsphase verlagert sich der Schwerpunkt allerdings eindeutig von der M2M-Kommunikation zum Internet der Dinge (Internet of Things = IoT).
SaaS und PaaS: Die Cloud schafft Interoperabilität
Die einzelnen Phasen beinhalten zum Teil völlig unterschiedliche Anforderungen. In der ersten Phase hatten wir es überwiegend mit in sich geschlossenen Anwendungen zu tun. Interoperabilität und offene Systemschnittstellen, die möglichst auf anerkannten Standards basieren, wurde kein besonders hoher Stellenwert eingeräumt, da praktisch jede Anwendung von Grund auf neu entwickelt wurde. Aus diesem Grund ist es wohl auch nicht weiter verwunderlich, dass sich die M2M-Welt bis heute nicht auf allgemeingültige Standards verständigt hat. Für die gegenwärtige Phase der Verbundanwendungen ist Interoperabilität – neben der Sicherheit – das entscheidende Kriterium. In der Praxis wird die Interoperabilitätsforderung in erster Linie durch Cloud-Services umgesetzt, die als Backend-Komponenten in praktisch jeder Anwendung zum Einsatz kommen, bzw. kommen werden. Ob eine Anwendung an eine SaaS (Software as a Service)- oder PaaS (Plattform as a Service)-Umgebung gekoppelt wird, hängt von den individuellen Anforderungen ab. Den ständig wachsenden Stellenwert derartiger Cloud-Serviceplattformen für neue M2M-Applikationen kann man daran erkennen, dass immer mehr Anbieter mit entsprechenden Geschäftsmodellen und zum Teil erheblichen finanziellen Ressourcen am Markt auftauchen. Neben der Infrastruktur zum Daten speichern und Device Management, bieten diese Serviceplattformen vor allem die unbedingt erforderliche Interoperabilität durch APIs (Application Programming Interfaces) und offene Systemschnittstellen. Die Anwendungsarchitektur ist bei allen SaaS-/PaaS-Anbietern für M2M-Anwendungen nahezu identisch. In die Firmware einer M2M-Device wird ein Agent eingebunden, der für die Verbindung zum Service Portal sorgt. Im Service Portal stehen die Echtzeit- und Historiendaten der einzelnen Devices für den Zugriff durch andere Anwendungen – z.B. Smartphone Apps – zur Verfügung. Bei einer PaaS-Lösung können selbst entwickelte Anwendungen sogar direkt in der Cloud ablaufen. Bei praktisch allen Serviceplattformen fällt auf, dass die Interoperabilität in der Regel mithilfe REST (Representational State Transfer)-basierter Webservices geschaffen wird. REST-Spezifikationen stellen aber lediglich ein Architekturmodell dar. Sie sind kein universeller Interoperabilitätsstandard für M2M-Daten und gewährleisten somit auch keinen Verbund aus verschiedenen Service Portalen. REST spezifiziert leider auch keine allgemeingültigen Datenmodelle. Es existiert daher lediglich eine vertikale Interoperabilität auf Protokollebene. Mit anderen Worten: Die REST-Schnittstellen für M2M-Devices, Smartphone Apps und andere Frontends müssen jeweils in Abhängigkeit vom jeweiligen Cloud-Service implementiert werden. Hier existiert sicherlich noch erheblicher Handlungsbedarf, damit sich der Markt entsprechend entwickeln kann. Es ist nicht anzunehmen, dass sich die unterschiedlichen Plattformbetreiber in Zukunft auf eine einheitliche M2M- oder IoT-REST-Schnittstelle einigen werden. Letztendlich stehen sie mit zum Teil völlig identischen Geschäftsmodellen im Wettbewerb untereinander und wollen über ihre Subscriber-Konzepte möglichst viele Devices und Anwender dauerhaft an sich binden.
Security by Design
Neben der rechtlich ungeklärten Fragestellung, ob man die zuvor genannten SaaS- und PaaS-Angebote mit Servern außerhalb des deutschen Rechtsraums für jede M2M-Anwendung einsetzen darf, muss auf jeden Fall der Sicherheit deutlich mehr Aufmerksamkeit zu Teil werden. Einfache Anwendungen der ersten Phase sind praktisch gar nicht oder nur unzureichend geschützt. Da kann es schon einmal vorkommen, dass man die Sicherheitslücken der eigenen Lösung in einem Nachrichtenmagazin nachlesen kann [1]. Wird heute eine Anlage mit vernetzten Automatisierungskomponenten 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 besitzen offensichtlich das erforderliche Fachwissen für nicht autorisierte Zugriffe auf spezielle Automatisierungsbaugruppen und deren Manipulationen. Die Motive dieser Hacker sind laut Trend Micro völlig unklar. Man darf aber vermuten, dass teilweise sogar hochentwickelte Organisationen hinter diesen Angriffen stecken, die mögliche Angriffsziele für zukünftige Cyberattacken ausspähen.
