Industrie-Elektronik
Fit für das Internet der Dinge
Bisher arbeiten die meisten Baugruppen, die steuern, regeln oder Daten aufnehmen autark oder innerhalb isolierter Dateninseln. Das wird sich in Zukunft ändern. Cloud-Anbindung, das Internet der Dinge und alles, was man als »Industrie 4.0« bezeichnet, halten neue Herausforderungen für Entwickler von MSR-Baugruppen bereit. Deshalb sollten solche Baugruppen schon so geplant werden, dass sie zukunftstauglich sind.
Bisher waren MSR-Systeme (Messen-Steuern-Regeln) mehr oder weniger isolierte Dateninseln oder in solche eingebunden. Sie verfügten lediglich über eine lokale Vernetzung, die in erster Linie als E/A-Schnittstelle diente. In zukünftigen Anwendungen werden MSR-Baugruppen verstärkt in globale IP-Netzwerke - typischerweise das Internet - eingebunden, um mit einer Backend-Anwendung, optionalen Frontend-Komponenten und im Internet der Dinge auch global untereinander zu kommunizieren. In einem solchen Anwendungsszenario sind einzelne MSR-Baugruppen direkt, andere über spezielle Gateways mit dem Internet verbunden.
Auf der gegenüberliegenden Seite existiert ein Backend-System, typischerweise ein klassischer Server oder eine Cloud-Serviceplattform. Zum Backend gehören verschiedene Frontend-Komponenten. Hierbei kann es sich um eine einfache Webschnittstelle für den Benutzerzugriff auf das Backend (und somit auf die MSR-Baugruppe) oder aber um Smartphone-Anwendungsprogramme (Apps) handeln. Als Software-Schnittstelle eignen sich REST-Webservices („Representational State Transfer“), die sowohl auf den MSR-Baugruppen als auch auf einem Backend zum Einsatz kommen können. Sie lassen sich mit Hilfe der HTTP-Methoden GET, PUT, POST und DELETE recht einfach implementieren und eignen sich auch, um ein Smartphone-Frontend mit Daten zu versorgen.
Jobangebote+ passend zum Thema
Die M2M-Kommunikation wird erwachsen
Die Experten des US-Marktforschungsunternehmens Harbor Research [1] unterteilen die Evolution der M2M-Kommunikation in drei Phasen (Bild 1). Diese Entwicklungsabschnitte unterscheiden sich in erster Linie durch die Anwendungskomplexität. In der ersten Phase, die weitgehend hinter uns liegt, sind einfache Anwendungen zu finden. Zu dieser Phase gehören Monitoring-Applikationen, 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 Verbundanwendungen, in der wir uns gerade befinden, ist durch Cloud-spezifische (Multipunkt-zu-Multipunkt-) Kommunikation gekennzeichnet. MSR-Baugruppen können nun über die Cloud auch untereinander Daten austauschen und werden zu speziellen Verbundsystemen gekoppelt - zum Beispiel zu Cyber-Physical Systems. Es existieren Schnittstellen zum Internet der Menschen, damit beispielsweise per Webbrowser oder Smartphone-App auf eine M2M-Anwendung und somit auf die MSR-Daten zugegriffen werden kann (Bild 2). Dadurch entstehen Anwendungsplattformen, in denen mensch-liche Nutzer, MSR-Baugruppen und Systeme miteinander verbunden sind.
Ein typisches Anwendungsbeispiel für diese zweite Phase ist die Datenkommunikation im Smart Grid. Hier werden 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 in diese Phase. 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 komplexen Anwendungen wechseln, lässt sich im Moment nur sehr ungenau bestimmen. Unter Umständen ist der Übergang fließend und nicht eindeutig erkennbar. Auf jeden Fall werden dann alle die Systeme, die heute schon als „smart“ bezeichnet werden, im Internet der Dinge untereinander verbunden sein, um bei Bedarf als Datenpunkte für werthaltige Third-Party-Applikationen zu dienen. Treffen die Prognosen der Analysten zu, dann werden 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.
Interoperabilität und offene Schnittstellen
Die einzelnen Phasen enthalten zum Teil völlig unterschiedliche Anforderungen. In der ersten Phase hatten wir es überwiegend mit in sich geschlossenen Anwendungen zu tun. Interoperabilität und offenen Systemschnittstellen, die möglichst auf anerkannten Standards beruhen, 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 Back-end-Kom-po-nen-ten in praktisch jeder Anwendung zum Einsatz kommen bzw. kommen werden. Ob eine Anwendung an eine SaaS- (Software as a Service) oder PaaS-Umgebung (Plattform as a Service) 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 Datenspeichern 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 MSR-Baugruppe wird ein Agent eingebunden, der für die Verbindung zum Service-Portal sorgt. Im Service-Portal stehen die Echtzeit- und Historiendaten der einzelnen Baugruppen für den Zugriff durch andere Anwendungen - zum Beispiel Smart-phone-Apps - zur Verfügung. Bei einer PaaS-Lösung können selbst entwickelte Anwendungen sogar direkt in der Cloud ablaufen.
- 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"
