Vendor Lock-In im Industrial IoT vermeiden

Lock-in entsteht selten durch eine einzige Entscheidung. Er häuft sich an. Ein Gateway-Anbieter liefert ein geschlossenes Firmware-Image aus, sodass Ihre Daten das Gerät nur über seine Cloud verlassen. Die Cloud berechnet zunächst pro angeschlossenem Asset, dann pro Nachricht, dann pro API-Aufruf. Nach zwei Jahren ist das Protokoll auf der Leitung nirgends dokumentiert, die Gerätezertifikate stammen vom Anbieter und das Datenmodell ist genau das, was sein Portal gerade exportiert. Ein Wechsel bedeutet jetzt, jede Maschine im Feld neu zu instrumentieren.

Die Kosten tauchen an Stellen auf, die der Einkauf nicht eingeplant hat: Lizenzgebühren pro Gerät, die mit Ihrer Flotte wachsen, nicht mit Ihrer Marge. Firmware, die Sie nicht patchen können, wenn eine Schwachstelle bekannt wird. Eine Roadmap, die Sie nicht steuern. Stellt der Anbieter eine Produktlinie ein oder wird er übernommen, erbt Ihr Bestand diese Entscheidung. Nichts davon ist hypothetisch. Es ist die vorhersehbare Folge davon, die Ebene zwischen Ihren Maschinen und Ihren Geschäftssystemen jemand anderem zu überlassen.

Der entscheidendste Schritt ist, die Software zu besitzen, die auf dem Edge-Gerät läuft. Ein Gateway auf Basis von Embedded Linux (ein Yocto-Image, das Sie aus dem Quellcode neu bauen können) bringt die Datenerfassung, die Protokoll-Parser und die Upload-Pipeline unter Ihre Kontrolle. Sie halten die Root-Zugangsdaten. Sie signieren Ihre eigene Firmware. Ändert sich ein Feldbus oder fragt ein Kunde ein neues Signal an, bearbeiten Sie Code und spielen ein OTA-Update aus, statt einen Feature-Wunsch einzureichen und auf ein Release des Anbieters zu warten.

Das ist kein Plädoyer für eine Eigenentwicklung von Grund auf. Die Bausteine sind ausgereift und offen: der Linux-Kernel, ein CAN-Stack über SocketCAN, libmodbus für serielles und TCP-Modbus, ein MQTT-Client wie Eclipse Mosquitto für den Uplink. Entscheidend ist, dass die Integration Ihnen gehört, im eigenen Repository versioniert und ohne Anruf bei Dritten reproduzierbar ist. Ein System, das Sie neu bauen können, ist ein System, das Sie verschieben können.

Interoperabilität entscheidet sich an der Protokollgrenze. Auf der Maschinenseite sind die Feldbusse bereits Standards: J1939 über CAN am Antriebsstrang oder an der Hydraulik, Modbus RTU an einer Zusatzpumpe oder einem Frequenzumrichter, OPC-UA dort, wo eine moderne SPS einen strukturierten Adressraum bereitstellt. Lesen Sie diese direkt aus. Sobald Sie dazwischen ein anbieterspezifisches Binärprotokoll akzeptieren, haben Sie die Übersetzungsebene aus der Hand gegeben, und die Übersetzungsebene ist die Fessel.

Der Uplink verdient dieselbe Disziplin. MQTT mit Store-and-forward-Pufferung transportiert Telemetrie zu jedem Broker, der das Protokoll spricht: heute zu Ihrem eigenen Mosquitto-Cluster, morgen zu einem Managed Broker, ohne dass das Gerät davon etwas merkt. Halten Sie die Nutzlast in einem offenen, dokumentierten Schema (JSON oder eine veröffentlichte Protobuf-Definition), damit ein zweiter Abnehmer sie ohne Reverse Engineering lesen kann. Wenn jede Schnittstelle auf dem Pfad ein veröffentlichter Standard ist, wird der Austausch einer Komponente zur Konfigurationsänderung, nicht zum Projekt.

Technische Offenheit nützt wenig, wenn der Vertrag das Arbeitsergebnis dem Anbieter zuweist. Für einen OEM, der vernetzte Anlagen ausliefert, ist die Embedded-Software Teil des Produkts, und der Vertrag sollte das festhalten: Quellcode, Build-Skripte, Hardware-Schaltpläne und Signaturschlüssel werden an Sie übergeben, mit einer Lizenz, die Ihnen erlaubt, sie innerhalb Ihres Produkts zu ändern und weiterzugeben. Alles darunter hinterlässt eine Abhängigkeit, die kein Architekturdiagramm beseitigt.

Eigentum verändert auch die Ökonomie. Gehört der Gateway-Code Ihnen, gibt es keine Lizenz pro Asset, die mit der Flotte wächst, und kein kostenpflichtiges Tor je Funktion zwischen Ihnen und Ihrer eigenen Roadmap. Sie können den Code für eine neue Produktlinie forken, ihn einem anderen Integrator übergeben oder ihn vollständig ins Haus holen. Der Vermögenswert in Ihrer Bilanz ist das System, nicht ein widerrufliches Nutzungsrecht an fremdem Eigentum.

Eine herstellerneutrale Architektur ist bewusst modular, mit sauberen Schnittstellen zwischen Erfassung, Transport, Speicherung und Darstellung. Das Gateway sollte nicht wissen müssen, mit welchem Broker es spricht. Der Broker sollte nicht wissen müssen, welche Datenbank abonniert. Die Datenbank sollte nicht wissen müssen, welches Dashboard sie abfragt. Jede Grenze ist eine veröffentlichte Schnittstelle, sodass eine Änderung auf einer Seite nicht durch den Rest kaskadiert.

Diese Trennung macht Migration überlebbar. Tauschen Sie die Zeitreihen-Datenbank, und die Gateways publizieren weiter. Wechseln Sie von einer Cloud zur nächsten, und die Feldgeräte bemerken es nie, weil sie auf einen Hostnamen und ein Topic zielen, nicht auf einen proprietären Endpunkt. Diese Disziplin kostet anfangs etwas mehr Entwurfsaufwand. Sie verschafft Ihnen die Option, Ihre Meinung über die gesamte Lebensdauer der Installation zu ändern, die bei Industriehardware in Jahrzehnten gemessen wird, nicht in Release-Zyklen.

Setzt man die Teile zusammen, ist das Ergebnis unspektakulär, und genau das ist der Punkt: offene Linux-Gateways unter Ihrer Kontrolle, direkt ausgelesene Standard-Feldprotokolle, MQTT zu einem offenen Broker, eine offene Zeitreihen-Datenbank und eine Dashboard-Ebene, die mit dokumentierten APIs spricht. Keine einzelne Komponente ist unersetzlich, und das Datenmodell gehört Ihnen, vom Sensor bis zur Abfrage. Das ist ein System, das Sie zu Ihren Bedingungen betreiben, erweitern und migrieren können.

Genau nach diesem Prinzip baut Melqart Systems. Wir liefern offene Systeme, keine proprietären Black Boxes, und jedes Projekt endet damit, dass Quellcode, Schaltpläne und Zugangsdaten in Ihren Händen liegen. Mehr: herstellerneutrale Router & Gateways und sicherer Fernzugriff für OT.