IoT-Plattform: vernetzte Produkte im Feld anbinden, verwalten, auswerten

Eine IoT-Plattform ist die Software, über die ein Hersteller seine vernetzten Produkte im Feld anbindet, verwaltet und auswertet. Sie nimmt Messwerte und Meldungen der Geräte entgegen, verteilt Updates und gibt Daten an Service, Kundenportal und ERP weiter. Der Nutzen entsteht dort, wo aus einer Gerätemeldung eine Handlung wird.

Aus welchen Schichten eine IoT-Plattform besteht

• Gerät und Gateway. Die Steuerung des Produkts oder ein zusätzliches Modul, das Werte liest und über Mobilfunk oder das Netz des Kunden sendet.
• Verbindung und Identität. Jedes Gerät meldet sich mit einer eindeutigen Identität an, meist über ein Zertifikat. Übertragen wird häufig per MQTT, einem schlanken Protokoll für viele kleine Nachrichten.
• Geräteverwaltung. Welches Gerät mit welcher Firmware-Version bei welchem Kunden steht, ob es erreichbar ist, welche Konfiguration gilt.
• Datenhaltung und Regeln. Zeitreihen der Messwerte, Ereignisse, Schwellen und Regeln, die bei Auffälligkeiten einen Vorgang auslösen.
• Anwendungen. Übersichten für den Service, Ansichten im Kundenportal, Schnittstellen zu CRM und ERP.

Die Schichten müssen nicht aus einer Hand kommen. Wichtig ist, dass die Übergänge offen beschrieben sind, damit sich ein Baustein später tauschen lässt, ohne die Geräte im Feld neu aufzusetzen.

Das Gerät beim Kunden: Netz, Anmeldung, Updates

Ein Hersteller betreibt seine Geräte in fremden Netzen. Die IT des Kunden öffnet ungern eingehende Verbindungen, und das zu Recht. Bewährt hat sich, dass das Gerät die Verbindung selbst nach außen aufbaut, verschlüsselt und nur zu festgelegten Adressen. Wo das Kundennetz nicht zur Verfügung steht, bleibt Mobilfunk.

Schwieriger als die erste Verbindung ist der Betrieb über Jahre. Zertifikate laufen ab, Geräte werden weiterverkauft, Steuerungen getauscht. Die Plattform braucht einen Weg, Geräte bei Fertigung oder Inbetriebnahme sicher zu registrieren und später wieder abzumelden. Firmware-Updates aus der Ferne sparen Einsätze, verlangen aber gestaffelte Auslieferung, Prüfung der Signatur und einen Rückweg, falls ein Update scheitert. Ein Gerät, das danach nicht mehr startet, steht beim Kunden und nicht im Labor.

Von der Gerätemeldung zum Serviceeinsatz

Für den After-Sales zählt, was aus den Daten folgt. Eine Störmeldung kann direkt einen Servicefall mit Gerät, Baustand und letzten Messwerten anlegen; der Techniker sieht vor der Anfahrt, was los ist, und nimmt das passende Teil mit. Lässt sich die Ursache aus der Ferne beheben, übernimmt die Fernwartung. Betriebsstunden und Zyklen fließen in das Wartungsmanagement und machen aus festen Intervallen nutzungsabhängige.

Ob eine Meldung einen Einsatz auslöst, entscheidet eine Regel, die der Service pflegt. Zu scharf eingestellte Schwellen erzeugen Fehlalarme, die bald niemand mehr liest; zu weiche lassen die Störung erst beim Kunden auffallen.

Data Act und Cyber Resilience Act

Zwei EU-Verordnungen betreffen vernetzte Produkte unmittelbar. Der Data Act, Verordnung (EU) 2023/2854, gibt Nutzern vernetzter Produkte einen Anspruch auf Zugang zu den Daten, die bei der Nutzung ihres Produkts entstehen, und erlaubt ihnen, diese Daten an Dritte weitergeben zu lassen, etwa an einen unabhängigen Servicebetrieb. Vor Vertragsschluss ist offenzulegen, welche Daten anfallen. Für die Plattform heißt das: Datenexport und Freigaben gehören in die Architektur.

Der Cyber Resilience Act, Verordnung (EU) 2024/2847, stellt Anforderungen an die Cybersicherheit von Produkten mit digitalen Elementen. Hersteller müssen Schwachstellen behandeln, während eines Unterstützungszeitraums Sicherheitsupdates bereitstellen und aktiv ausgenutzte Schwachstellen melden. Eine Updatefunktion, die Geräte verlässlich erreicht, wird damit vom Komfort zur Voraussetzung. Welche Pflichten ab wann für ein bestimmtes Produkt gelten, ist im Einzelfall zu prüfen.

Standardplattform oder eigene IoT-Plattform

Drei Wege sind verbreitet: IoT-Dienste der großen Cloud-Anbieter als Baukasten, fertige Industrieplattformen mit eigener Oberfläche und ein Aufbau aus offenen Komponenten wie einem MQTT-Broker und einer Zeitreihendatenbank. Die Wahl hängt weniger von Funktionslisten ab als von vier Fragen:

• Wie viele Gerätetypen kommen zusammen, und wie unterschiedlich sind sie?
• Wer verfügt über die Daten, und wie kommen alle Geräte wieder heraus, falls der Anbieter gewechselt wird?
• Wie entwickeln sich die laufenden Kosten je Gerät und je Nachricht über die Lebensdauer des Produkts, die oft länger ist als die eines Cloud-Dienstes?
• Wie tief reicht die Anbindung an ERP, CRM und Kundenportal, die ohnehin individuell bleibt?

Zwei Fehler kehren wieder. Das Projekt beginnt mit bunten Kurven, zu denen es keinen Folgeprozess gibt, und bleibt ein Vorzeigeobjekt. Oder Geräte gehen ohne Updateweg in den Markt, weil der Pilot klein war – und lassen sich später nur mit einer Anfahrt nachrüsten.

Wie wir vernetzte Produkte anbinden

Wir beginnen beim Servicefall, nicht beim Sensor: Welche Meldung soll welche Handlung auslösen, und welche Daten braucht der Techniker dafür? Daraus ergeben sich Messwerte, Übertragungsweg und die Wahl der Bausteine. Die erste Lieferung verbindet eine Baureihe mit einem echten Folgeprozess, etwa dem automatisch angelegten Servicefall; Geräteidentität und Updateweg gehören von Anfang an dazu. Umgesetzt wird das als Softwareentwicklung mit Abnahmekriterien je Etappe. Dieselbe Geräteakte kann später auch den digitalen Produktpass speisen.