Die IoT-Landschaft

Cloud, Edge, Embedded... Die Liste der (meist englischen) Fachbegriffe ist lang und die einzelnen Wörter teilweise mehrfach besetzt. In diesem Artikel möchte ich diese Begriffe in den IoT-Kontext setzen, erklären wie brudi diese benutzt und wo wir sie in der IoT-Landschaft antreffen.

Cloud, Edge, Embedded... Die Liste der (meist englischen) Fachbegriffe ist lang und die einzelnen Wörter teilweise mehrfach besetzt. In diesem Artikel möchte ich diese Begriffe in den IoT-Kontext setzen, erklären wie brudi diese benutzt und wo wir sie in der IoT-Landschaft antreffen.

Die Geräteebene

IoT-Geräte haben viele Namen: Sensoren, Maschinen, Apparate, ferngesteuerte Geräte, Aktoren oder Anglizismen wie Gadgets, Smart-Devices oder embedded Systems. Diese Begriffe sind nicht zwingend synonym. Durch ihre Fähigkeit zu kommunizieren, sind aber alle diese Geräte prädestiniert, in das Internet of Things eingebettet zu werden.

Diverse Sensoren und Aktoren (Geräteebene), welche mit einem Gateway (Edge-Ebene) ausserhalb des Bildbereiches physisch verbunden sind.

Ob Knöpfe, Automobile, Roboterarme, Solaranlagen, Thermometer oder digital-signage Bildschirme spielt dabei fast keine Rolle, sie alle können Teil einer innovativen Applikation werden. Sind die Geräte mobil, kommunizieren sie normalerweise mit long-range Funktechnologien wie 4G/5G oder LoRaWan mit der Cloud. Alle stationären Geräte verbinden wir gerne lokal über einen Gateway auf der Edge-Ebene, um von da verwaltet mit der Cloud zu kommunizieren.

Die Edge-Ebene

Der Begriff der Edge (oder zu Deutsch: Kante) ist mehrfach besetzt, weil er mehrere Ränder eines Netzwerks beschreiben kann. Die Kante, welche bei der Edge-Ebene gemeint ist, bezeichnet die Stelle, wo Daten nahe am Entstehungsort zwischengespeichert, cached, aufbereitet, gefiltert und schlussendlich dem Internet of Things zugeführt werden können. Man spricht bei diesen Datenstromverarbeitungen von Edge-Computing, also Computer-Anwendungen, Daten und Dienste, welche weg von zentralen Knoten zu den äusseren Rändern eines Netzwerks hin verlagert wurden. Dabei geht es darum, Datenströme ressourcenschonend und, zumindest teilweise, an Ort und Stelle (z. B. direkt am Endgerät oder innerhalb einer Fabrik) zu verarbeiten. Bei einem Netzwerkausfall werden Daten zwischengespeichert, aber ansonsten profitiert man von den Vorteilen der Cloud.

Ein Gateway auf der Edge-Ebene, der direkt mit den relevanten Geräten einer Maschine verbunden ist. 

IoT-Geräte sind direkt mit der Edge-Hardware, die aufgrund ihrer Funktion als Tor zum Internet auch Gateway genannt wird, verbunden. Das heisst, diese Ebene befindet sich beim Kunden am Entstehungsort der Daten. Ist ein Gerät direkt an das Internet angebunden, beispielsweise mit einem 4G-Modul, so verschiebt sich die Edge: Entweder auf das Gerät, welches mit entsprechender Hardware die Aufgaben des Gateways selbst übernehmen kann. Dieses wird durch diese Erweiterung mit einem Mikroprozessor zu einem "embedded" Gerät.  – Oder aber in den Fog-Layer zu den Fog-Nodes, welche alle Edge-Aufgaben ebenfalls bewältigen können.

IoT & Edge Computing
Brudis helfen Software-Teams und Unternehmen heutige Herausforderungen zukunftssicher zu lösen.

Edge-Computing-fähige Geräte und Gateways reduzieren also entstehungsnah den Netzwerk-Traffic und können bei Verbindungsunterbrüchen die entstehenden Daten durch Zwischenspeicherung vor dem Verlust retten.

Die Fog-Ebene

Die Fog-Ebene (von engl. fog = Nebel) bezeichnet eigentlich das Firmennetzwerk, durch das die IoT-Geräte eine sichere Verbindung zur Cloud herstellen können müssen, um die Daten von der Edge zur Cloud durch alle Sicherheitsebenen weiter zu leiten. Sie kann aber auch eine Reihe leistungsstarker Server umfassen, die sogenannten Fog-Nodes, die Daten vom Edge-Layer entgegennehmen, vorverarbeiten und nur bei Bedarf in die Cloud hochladen.

Leider stösst nicht nur das (durch Edge-Computing gelöste) Problem vom Datendurchsatz bei gross angelegten IoT-Architekturen an seine Grenzen. Ein weiteres Problem ist die Latenz. Die zentralisierte Datenverarbeitung ist in jedem Fall durch die langen Übertragungswege mit einer Zeitverzögerung verbunden. Endgeräte, Sensoren oder Gateways müssen stets den Server in der Cloud ansprechen, um miteinander zu kommunizieren und sowohl die externe Verarbeitung der Anfrage, als auch die Antwort abwarten. Zum Problem werden Latenzzeiten dieser Art beispielsweise bei IoT-gestützten Fertigungsprozessen, bei denen eine Informationsverarbeitung in Echtzeit sichergestellt werden muss, damit Maschinen unmittelbar auf Vorfälle reagieren können.

Fog-Nodes können durch lokale Verarbeitung Realtime-Anwendungen ermöglichen und allfällige Befehle selbst dann an die IoT-Geräte verteilen, wenn das Netzwerk zur Cloud unterbrochen ist. Eine Fog-Node ist ebenfalls physisch im Firmennetzwerk und unterscheidet sich vom Edge-Computer durch ihre Funktion als erste Zentralstelle für die Edge-Geräte, welche so das Latenzproblem beheben kann. Der Vorteil besteht also darin, dass Fog-Nodes die Daten verschiedener Geräte zentral erhalten und so in Echtzeit und nahe am Geschehen automatisierte Entscheidungen fällen und Steuerungsbefehle an die Geräte senden kann - sogar bei unterbrochener Verbindung in die Cloud.

Falls mehrere Maschinen mit kurzen Antwortzeiten auf Echtzeitdaten reagieren müssen, wie in grossen Produktionsstrassen, kommt das Fogging auf einem lokalen Server zum Einsatz. Das Cloud-Computing dient dann nur noch zur Aufbereitung und Speicherung historischer Daten und der Kontrolle von Entscheidungen auf der Fog-Ebene.

Dieses sogenannte Fogging (Fog-Computing) als zusätzlicher Zentralrechner neben der Cloud versuchen wir zu vermeiden, um die Vorteile einer skalierbaren und agilen Cloud zu bewahren. Die Kostenersparnis durch Fogging bei der Nutzung von Fremdnetzen (Netzbetreiber lassen sich den schnellen Upload in die Cloud teuer bezahlen), werden durch den erhöhten Wartungsbedarf der Fog-Nodes egalisiert. Trotzdem: Bei einigen Anwendungen wie Produktionslinien oder selbst fahrenden Autos – wo dutzende Sensoren Millionen von Datenpunkten jede Sekunde generieren – kann nicht immer auf die Antwort von der Cloud gewartet werden. In diesen Fällen würden auch wir zugunsten eines Fogging-Modells beraten.

brudi Cloud-Software Architektur
Eine grundlegende Architektur inklusive Cloud- und Betriebstrategieberatung ermöglicht das aufgleisen skalierbarer Projekte und Modernisierungen sowie Performanceoptimierungen in bestehenden Systemen.

In anderen Worten: Für die meisten Anwendungen und Maschinen reichen Edge-Gateways, die physisch mit allen IoT-Devices verbunden sind. Geht es aber beispielsweise um ganze Produktionsstrassen, wo mehrere Maschinen aufeinander abgestimmt arbeiten müssen, sind zentrale Fog-Nodes die richtige Wahl.

Die Cloud-Ebene

Grundsätzlich präferieren wir aber IoT-Architekturen mit einem Hybrid aus Edge-Computing (filtering, caching) und Cloud-Computing (Processing, command distribution), um alle Vorteile der skalierbaren Ressourcen zu erhalten und von der integrierten Sicherheit der Cloudinfrastruktur zu profitieren. Um nicht trotzdem ständig Latenzprobleme zu haben, gibt es auch in der Cloud sogenannte Edge-Nodes. Diese sind als Microservice gestaltet und können so auch Daten annehmen und mit den Geräten kommunizieren, wenn andere Teile der Applikation gerade nicht funktionieren.

Microservices einfach nutzen mit der brudi Platform
In diesem Artikel geben wir einen kleinen Einblick in die Funktionsweise von Microservices und wie die brudi Platform helfen kann, den Wechsel von Projekten zu Microservice-Architektur mit fortlaufender Entwicklung und Auslieferung zu stemmen.

Von da an sind die Daten im Cluster verfügbar und stehen für jegliche Anwendung, die brudi entwickeln soll, bereit. Mit brudi IoT können alle Geräte mit geeigneter Konfiguration aus der Cloud verwaltet und angesteuert werden.

IoT und Edge-Computing Projekte mit brudi realisieren
In diesem Artikel zeigt brudi, wie du Live-IoT-Daten zur Bearbeitung oder Überwachung schnell in einer universellen Applikation benutzen kannst.

Disclaimer: Fast alle dieser Begriffe sind nicht standardisiert und haben deshalb keine universelle Definition. (Beispielsweise nach IEEE oder ISO). Dieser Artikel ist deshalb als Glossar zu verstehen.

brudi Logo