M2M-Hotspot
Die drei Phasen der M2M-Evolution
Die M2M-Technologie ist in der zweiten Evolutionsstufe angekommen. Was bedeutet dies für die Technologie-Bausteine und die Kommunikationsbeziehungen? Und welche Hindernisse stehen dem Eintritt in die dritte Evolutionsphase noch im Wege?
Die einzelnen Entwicklungsphasen der M2M-Kommunikation lassen sich über die Anwendungskomplexität differenzieren. Wir befinden uns gegenwärtig in der Phase der Compound Applications (Verbundanwendungen), in der Interoperabilität und offene Systemschnittstellen eine wichtige Rolle spielen.
© SSV Software SystemsDie 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.
Die erste Phase
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 Monitoring-Portal übermitteln. Auch das inzwischen recht verbreitete Tracking & Tracing, also die automatische Sendungsverfolgung in der Logistik mit Hilfe von GSM-Funknetzen sowie die existierenden Telematik-Lösungen fallen in die erste M2M-Anwendungsphase. Kennzeichnend für diese einfachen Anwendungen sind Punkt-zu-Punkt-Kommunikationsbeziehungen.
Die zweite Phase
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 einem auch untereinander Daten austauschen und werden zum anderen zu speziellen Verbundsystemen gekoppelt – zum Beispiel zu 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 zum Beispiel 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 zurzeit überall beschriebenen Industrie-4.0-Ideen und -Konzepte fällt aus Sicht der M2M-Kommunikation weitgehend in diese Phase. Hochentwickelte Condition-Monitoring-Systeme mit Schnittstellen zu Service-Unternehmen und Ersatzteil-Datenbanken gehören ebenso in die Kategorie der M2M-Verbundsysteme.
Die dritte Phase
Wann wir von der zweiten in die dritte Phase der Complex Applications (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 Thrid-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 rund sieben bis acht vernetzte Datenpunkte (siehe „More than 50 billon connected devices“ unter http://tinyurl.com/7fdfg4m) im Internet miteinander kommunizieren. Spätestens in dieser Evolutionsphase verlagert sich der Schwerpunkt allerdings eindeutig von der M2M-Kommunikation zum Internet der Dinge.
Die Cloud schafft Interoperabilität
Die Verbundanwendungen der Gegenwart erfordern hochentwickelte Cloud-Services, die als Backend-System für die einzelnen M2M-Devices, andere (Verbund-)Systeme sowie für die Smartphones und PCs menschlicher Nutzer dienen. Über diese Service-Portale wird letztlich die erforderliche Interoperabilität geschaffen.
© SSV Software SystemsDie 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 beziehungsweise 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. Axeda (http://www.axeda.com), SensorLogic/Gemalto (http://www.sensorlogic.com), deviceWISE/ILS (http://www.devicewise.com) und ThingWorx (http://www.thingworx.com) sind nur einige exemplarische Beispiele. 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 – etwa Smartphone-Apps – zur Verfügung. Bei einer PaaS-Lösung können selbstentwickelte Anwendungen sogar direkt in der Cloud ablaufen.
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 zuteilwerden. Einfache Anwendungen der ersten Phase sind praktisch gar nicht oder nur unzureichend geschützt.
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 Cyber-Attacken ausspähen. Um in diesem Umfeld anspruchsvolle M2M-Anwendungen zu realisieren, wären im Vorfeld zunächst erhebliche Zusatzinvestitionen für Sicherheitskomponenten, Tests und Audits erforderlich. Da ein Höchstmaß an Sicherheit nur im Rahmen spezieller Prozesse zu erreichen ist, fallen darüber hinaus erhebliche Zusatzkosten für den Betrieb derartiger Lösungen an. Es wäre sogar zu prüfen, ob für die M2M-Sicherheit in bestimmten Anwendungen – zum Beispiel für Applikationen im Umfeld kritischer Infrastruktur – nicht sogar staatliche Vorgaben erforderlich wären und wichtige Baugruppen und Systeme nach Common-Criteria-Vorgaben zertifiziert werden müssten (s.a. BMWi- und BSI-Aktivitäten zur Sicherheit im Umfeld der Smart-Metering-Lösungen). Ohne ausreichende Sicherheit könnte die Evolution der M2M-Phasen abrupt unterbrochen werden – Stuxnet darf sich hier nicht wiederholen!
Autor: Klaus-Dieter Walter ist Mitglied der Geschäftsleitung bei SSV Software Systems und gehörte viele Jahre dem Vorstand der M2M Alliance an.











