Offene vs. proprietäre IoT-Gateways für OEMs

Jeder OEM, der vernetzte Maschinen baut, trifft früh eine architektonische Entscheidung, die sich später nur teuer zurücknehmen lässt: Wem gehört das Gateway? Wählen Sie einen offenen Embedded-Linux-Stack, gehört die Feld-Datenebene Ihnen. Wählen Sie eine geschlossene Plattform, mieten Sie sie zu den Bedingungen des Anbieters, solange das Produkt ausgeliefert wird.

In der Demo sehen beide Wege gleich aus. Sie laufen scharf auseinander, sobald Sie ein Protokoll brauchen, das der Anbieter nie vorgesehen hat, mitten im Programm eine Preisänderung eintrifft oder die Plattform, auf die Sie sich festgelegt haben, ihr Lebensende erreicht. Es geht weniger um einen Funktionsvergleich als um Handlungsspielraum: Wie viel von Ihrem eigenen Produkt kontrollieren Sie wirklich?

Bei einem offenen Gateway gehört die Codebasis Ihnen. Sie besitzen den Quellcode, das Build-System (in der Regel Yocto oder Buildroot) und das Recht, ihn zu forken, zu patchen oder zu auditieren, ohne um Erlaubnis zu fragen. Verlangt ein Kunde im nächsten Quartal eine Sicherheitsprüfung oder einen neuen Feldbus, liefern Sie das nach Ihrem Zeitplan.

Eine proprietäre Plattform lizenziert Ihnen das Nutzungsrecht an Software, die Ihnen nicht gehört. Support, Update-Takt und Roadmap bleiben beim Anbieter. Das ist unproblematisch, solange Ihre Anforderungen mit seinen übereinstimmen. Es wird zum Risiko in dem Moment, in dem er seine Prioritäten verschiebt, die Gebühren pro Gerät erhöht oder übernommen wird und die Produktlinie einstellt, auf der Sie aufgebaut haben.

Industrielle Flotten sind selten einheitlich. Ein OEM fährt J1939 am Antriebsstrang, Modbus an einer Zusatzpumpe und einen proprietären CAN-Dialekt an einem Subsystem eines Drittlieferanten. Ein offener Stack erlaubt es, alle drei zu parsen, in ein gemeinsames Schema zu normalisieren und die Parsing-Logik in einem Firmware-Build zu ändern, den Sie kontrollieren.

Geschlossene Plattformen bieten Konfiguration, nicht Modifikation. Sie erhalten die Optionen, die der Anbieter ausliefern wollte. Das deckt die Standardfälle ab und endet genau dort, wo Ihr Produkt seine Marge verdient: der ungewöhnliche Sensor, die kundenspezifische Diagnose, die Edge-Logik, derentwegen Kunden bei Ihnen kaufen und nicht beim Wettbewerber.

Der sichtbare Preis einer geschlossenen Plattform ist die Lizenz. Die echten Kosten zeigen sich später: Change-Request-Gebühren für Funktionen, die der Anbieter nach seinem Zeitplan baut, Lizenzgebühren pro Gerät, die mit Ihrem Erfolg steigen, und die Migrationsrechnung, wenn die Plattform eingestellt wird. Lock-in ist kein einzelnes Ereignis. Es summiert sich.

Offene Gateways ziehen diese Kosten stattdessen nach vorn. Sie investieren zunächst in Engineering-Kompetenz und pflegen das System dann mit Ihrem eigenen Team. Für ein Produkt, das jahrelang ausgeliefert wird, spricht die Rechnung meist für das Eigentum am Stack. Für einen kurzen Pilot oder ein Team ohne Embedded-Entwickler kann der schlüsselfertige Weg die richtige Wahl sein.

Stellen Sie sich drei Fragen. Wie lange wird dieses Produkt im Feld sein? Wie wahrscheinlich ist es, dass Sie ein Protokoll, eine Integration oder eine Funktion benötigen, die der Anbieter nicht gebaut hat? Und wie strategisch sind die Felddaten für Ihr Geschäft, im Gegensatz zu einem Kästchen, das Sie nur abhaken müssen?

Lange Lebenszyklen, unvorhersehbare Anforderungen und Daten, die Ihre Roadmap bestimmen, sprechen für ein offenes Gateway. Kurze Zeitpläne, Standardanforderungen und ein kleines Team sprechen für eine verwaltete Plattform. Die meisten OEMs, die eine Produktlinie aufbauen statt einen einmaligen Versuch zu fahren, landen bei offen. Der Grund sind selten die Kosten am ersten Tag. Es ist die Kontrolle am tausendsten.