Innovative IoT-Lösungen für Unternehmen

Das Internet der Dinge fördert innovative Lösungen

| Autor / Redakteur: Patrick Steiner * / Advertorial

Patrick Steiner, Senior Enterprise Solution Architect bei Red Hat über Sicherheit beim Datentransfer im Internet der Dinge.
Patrick Steiner, Senior Enterprise Solution Architect bei Red Hat über Sicherheit beim Datentransfer im Internet der Dinge. (Bild: Red Hat)

Für die Business-IT verändert sich durch das Internet der Dinge Vieles. Um die Potenziale zu erschließen bedarf es einer hochskalierbaren und zuverlässigen IT-Infrastruktur. Sie sollte auf standardisierten Komponenten und offenen Protokollen basieren und die drei Schichten Devices, Controller und Datacenter beziehungsweise die Cloud umfassen.

Das Internet der Dinge (Internet of Things, IoT) vernetzt intelligente Geräte aller Art wie mobile Geräte, Sensoren, Maschinen oder Fahrzeuge miteinander und mit der Cloud. Die Analyse der IoT-Daten bietet vielfältige Möglichkeiten für Unternehmen: sie können schnellere Entscheidungen treffen, ihre Geschäftsprozesse optimieren oder auch neue Anwendungen und sogar Geschäftsmodelle entwickeln. Damit verfügt das Internet der Dinge über ein enormes Potenzial in nahezu jeder Branche: Energie, Einzelhandel, Gesundheit, Finanzdienstleistungen, Transport und Fertigung.

Die Bandbreite möglicher neuer Anwendungen ist groß. Sie reicht von intelligenter Gebäudetechnik mit automatisiertem Beleuchtungs- oder Energie-Management über optimierte Lösungen für Inventarisierung, Logistik und Supply Chain Management bis hin intelligenten Fertigungssystemen.

Das Internet der Dinge stellt etwa völlig neue Herausforderungen an die Skalierbarkeit. Der Marktforscher Gartner erwartet, dass 2016 bereits 6,4 Milliarden Geräte über das Internet der Dinge verbunden sein werden. Das entspricht einem Anstieg um 30 Prozent gegenüber 2015. Allein 2016 sollen pro Tag 5,5 Millionen Geräte hinzukommen. Im Jahr 2020 sollen es dann 20,8 Milliarden sein. Ein einziges intelligentes System könnte dann Milliarden von Datenobjekten von Millionen verschiedenen Endpunkten sammeln und analysieren. Damit sind bislang beispiellose Anforderungen an Prozessorleistung, Storage und Netzwerke verbunden.

Die schiere Größe und der öffentliche Charakter des Internets der Dinge bringen jedoch große technische Herausforderungen mit sich. Netzwerk- und System-Architekten müssen die IT-Infrastruktur optimieren, um den höheren Anforderungen des IoT in puncto Skalierbarkeit, Zuverlässigkeit und Sicherheit gerecht zu werden. IoT-basierte Anwendungen und automatisierte Geschäftsprozesse stellen hohe Anforderungen an die Verfügbarkeit des Systems. Viele intelligente Systeme werden für geschäftskritische Anwendungen verwendet, bei denen Ausfallzeiten des Systems zu einer verminderten Produktivität führen.

Die verteilten IoT-Lösungen führen des Weiteren zu großen Sicherheits-Herausforderungen, da die Systeme über das Internet vernetzt sind und Rechenleistung oder Speicher-Ressourcen aus dem Datacenter eines Unternehmens oder aus der Cloud nutzen. Unternehmen müssen daher ihre Sicherheitsarchitektur erweitern, um sich vor Datenverlust, Diebstahl und immer anspruchsvolleren Denial-of-Service-Attacken effizient zu schützen. Dazu gehören umfassende Authentifizierungs-, Autorisierungs- und Auditing-Funktionen. Diese schaffen Vertrauen, regeln den Zugriff auf Ressourcen und gewährleisten die Einhaltung der gesetzlichen Vorschriften und Unternehmensrichtlinien (Compliance). Unternehmen sollten außerdem starke Verschlüsselungsverfahren einsetzen, um ihr geistiges Eigentum und Kundendaten vor Diebstahl zu schützen.

Schichtenmodell erfüllt wichtige technische Anforderungen

Intelligente IT-Lösungen, die beispielsweise auf Technologien von Red Hat basieren, erfüllen die Anforderungen der IoT-basierten Systeme an Skalierbarkeit, Zuverlässigkeit und Sicherheit. Die Lösungen basieren auf einem hierarchischen Modell mit Geräte-Schicht (Edge, Device Tier), Steuerungs-Schicht (Controller, Gateway Tier) und Rechenzentrums (Datacenter Tier)- oder Cloud-Schicht. Dabei kommen standardisierte Protokolle und Komponenten zum Einsatz.

Skalierbar, zuverlässig und sicher: Das Schichtenmodell mit Geräte-Ebene (Device Tier), Steuerungs-Ebene (Gateway Tier) und Rechenzentrums (Datacenter Tier)- oder Cloud-Ebene erfüllt alle Anforderungen, die das Internet der Dinge an IT-Lösungen stellt.
Skalierbar, zuverlässig und sicher: Das Schichtenmodell mit Geräte-Ebene (Device Tier), Steuerungs-Ebene (Gateway Tier) und Rechenzentrums (Datacenter Tier)- oder Cloud-Ebene erfüllt alle Anforderungen, die das Internet der Dinge an IT-Lösungen stellt. (Bild: Red Hat)

Die Edge-Ebene umfasst eine Vielzahl von intelligenten Endgeräten. Dazu gehören mobile Geräte, Wearables, Sensoren, Steuerungs- und Regel-Geräte sowie autonome Maschinen und Appliances. Die Kommunikation zwischen den Geräten und den Steuerungs- oder Kontrollpunkten basiert auf Standard-Netzwerkprotokollen, sei es kabelgebunden oder drahtlos. Auch die Weiterleitung der Rohdaten sowie der Austausch der Steuerungsinformationen beruht auf offenen Messaging-Standards.

Zur Kommunikation zwischen Edge und Controller kommt zum Beispiel MQTT (Message Queue Telemetry Transport) zum Einsatz. Es wurde bereits 1999 im Rahmen eines Projektes zur Überwachung einer Ölpipeline von den beiden Unternehmen IBM und Arcom Control Systems entwickelt. Das Protokoll zeichnet sich durch eine hohe Zuverlässigkeit aus und eignet sich für den Einsatz in Mobilfunknetzen und in Netzen mit einer geringen Bandbreite. Eine Implementierung des Protokolls erfordert wenig Programmcode. MQTT wurde 2010 unter einer freien Lizenz veröffentlicht, ist seit 2013 ein OASIS-Standard und hat in der Zwischenzeit den Versionsstand 3.1.1 erreicht.

MQTT ist ein Publish-Subscribe-Protokoll, das auf einer Hub-and-Spoke-Architektur basiert. Dabei kommuniziert der Sender (Producer) einer Nachricht nicht direkt mit einem Empfänger (Consumer), sondern über einen Broker. Durch die Entkopplung beider Seiten kann der Producer, beispielsweise ein Sensor, auch dann Daten übermitteln, wenn kein Empfänger, etwa ein Gateway, online ist. Mehr noch: Der Producer hat keine Kenntnisse darüber, ob es für die Daten einen oder mehrere Consumer gibt. Der Broker agiert als Server für Producer und Consumer, die als Clients beide mit dem Broker verbunden sind. MQTT arbeitet vollständig unabhängig von dem eigentlichen Inhalt der Nachrichten.

Im Unterschied zu einem Client/Server-Protokoll wie HTTP arbeitet MQTT ereignisorientiert. Im erstgenannten Fall fragt der Client beim Server nach, ob neue Nachrichten vorliegen. In einem ereignisorientierten Modell informiert der Broker die Consumer, wenn Daten zu einem bestimmten Topic vorliegen. Allerdings gibt es keine 1:1 Queues wie beim Java Messaging Service.

Consumer müssen für ein oder mehrere Topics angemeldet werden und werden daher auch als Subscriber bezeichnet. In einem Topic werden Nachrichten zu einem bestimmten Thema zusammengefasst. Das können beispielsweise die durch einen Sensor gemessenen Temperaturen oder die Gesundheitsdaten nicht stationärer Patienten sein.

Das MQTT-Protokoll bietet drei Quality-of-Service (QoS)-Stufen. Auf der untersten Stufe ist gewährleistet, dass die Nachricht höchstens einmal (At Most Once) zugestellt wird. Ein Producer kennzeichnet in diesem Fall eine Publish-Nachricht mit der QoS-Stufe 0. Da sich der Sender nicht weiter um die Nachricht kümmert, wird diese schnelle und ressourcenschonende Form von Message Exchange auch als „Fire and Forget“ bezeichnet. Hier gibt es keine Garantie, dass die Nachricht auch tatsächlich ankommt. Anders ausgedrückt: Es kann zu Nachrichtenverlusten kommen, die jedoch nicht weiter ins Gewicht fallen, wenn kurz nach einem verlorengegangenen schon der nächste Wert übermittelt wird.

Mit Connected Devices lassen sich beispielsweise auch Gesundheitsdaten wie Herzschlag, Blutdruck, Atemfrequenz oder Blutzucker von Patienten überwachen.
Mit Connected Devices lassen sich beispielsweise auch Gesundheitsdaten wie Herzschlag, Blutdruck, Atemfrequenz oder Blutzucker von Patienten überwachen. (Bild: Red Hat)

Auf der nächsten QoS-Stufe wird sichergestellt, dass die Nachricht mindestens einmal (At Least Once) beim Consumer eintrifft. Dies bedeutet aber auch, dass eine Nachricht mehrmals zugestellt werden kann. Der Producer speichert dazu die Nachricht in einer Datei und sie steht dann im Notfall für eine erneute Übertragung bereit. Der Producer versendet eine Publish-Nachricht mit einem Packet Identifier an den Consumer. Er bestätigt den Erhalt mit einem Paket, das denselben Packet Identifier enthält. Hat der Producer dieses Paket noch nicht erhalten, kann er die ursprüngliche Nachricht – inklusive Packet Identifier und Inhalt – beliebig oft an den Consumer versenden. Nach dem Empfang einer Nachricht mit dem bereits übermittelten Packet Identifier gilt eine erneute Übermittlung mit diesem als neue Nachricht.

Auf der höchsten QoS-Stufe ist gewährleistet, dass Duplikate ausgeschlossen sind und die Nachrichten genau einmal (Exactly Once) zugestellt werden. Damit diese Garantie auch eingehalten werden kann, gibt es eine zweistufige Bestätigung. Der Consumer antwortet auf den Erhalt einer Nachricht mit einem Empfangspaket. Daraufhin verschickt der Producer ein weiteres Paket, auf das wiederum der Consumer antwortet.

Controller leiten Daten ins Datacenter oder in die Cloud weiter

Die Controller-Ebene fungiert als Bindeglied zwischen den Geräten und dem Rechenzentrum beziehungsweise der Cloud. Sie sammelt und speichert Gerätedaten und leitet sie beispielsweise via Java Messaging Service an das Rechenzentrum weiter; umgekehrt vermittelt sie Steuerungsinformationen an die Geräte – alles auf Basis offener Messaging-Standards. Darüber hinaus dient sie als Zwischenspeicher für Daten, die für die taktische Analyse oder regulatorische Anforderungen benötigt werden.

Eine Alternative zum beschriebenen Drei-Schichten-Modell bildet ein Zwei-Schichten-Modell, in dem die Geräte direkt mit den Rechenzentren oder der Cloud verbunden sind. Dieses Modell eignet sich sehr gut für Consumer-Anwendungen, die weniger Bandbreite und keine Gateway-Ebene für die Verteilung von Workloads benötigen.

* Patrick Steiner ist Senior Enterprise Solution Architect bei Red Hat.

Kommentare werden geladen....

Kommentar zu diesem Artikel abgeben

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44096917 / Advertorials)