Cummins und Portainer: Modulares IoT für Software Defined Vehicles

In dieser Folge habe ich einen besonderen Gast für euch, das Unternehmen Cummins. Die Branche ist die Fahrzeugherstellung. Sie kommen aus Indiana und sind ein globaler Anbieter von Energiesystemen für Dieselmotoren, elektrifizierte Antriebsstränge und Stromerzeugung. Sie haben ungefähr 70.000 Mitarbeitende, es gibt also viel Expertise und natürlich laufende Projekte im industriellen IoT. Sie arbeiten mit Hunderten von OEMs, und ihre Fahrzeuge sind äußerst konfigurierbar. Deshalb brauchen sie eine modulare Softwarearchitektur. Heute lernen wir, wie sie Konnektivitätsgeräte und Containerarchitekturen nutzen, um ein standardisiertes und modulares Softwaresystem aufzubauen. Wir wollen verstehen, wie sie das umgesetzt haben, welche Hürden ihnen begegnet sind und worauf ihr bei ähnlichen Projekten achten solltet. Wir sprechen auch über die Ergebnisse. Um diese und weitere Fragen aus der Community zu beantworten, habe ich Carlton Bale eingeladen, Director of Software bei Cummins, sowie Martin Brown, Software Architect bei Cummins. Ihr ausgewählter IoT Partner ist Portainer.io, heute vertreten durch Neil Cresswell, CEO und Mitgründer.
Sie sitzen in Auckland in Neuseeland. Wie immer findet ihr die Implementierungsdetails auf iotusecase.com und erfahrt dort mehr über unsere Community. Damit starten wir in diese Episode.

Hallo und herzlich willkommen, Neil, Carlton und Martin. Neil, wie geht es dir heute, wie läuft deine Woche?

Neil

Sehr gut. Ich habe die Woche in Deutschland verbracht, was ich liebe, also ja, sehr gut.

Das freut mich. Bist du normalerweise in Neuseeland oder wo bist du ansässig?

Neil

Ehrlich gesagt habe ich in den letzten vier Jahren die meiste Zeit in Sitz 14A und in Hotels auf der ganzen Welt verbracht. Ich reise etwa 270 Tage im Jahr. Aber seit diesem Jahr lebe ich in Phoenix in Arizona.

Alles klar, cool. Und Carlton, Martin, wie war eure Woche, und wo seid ihr gerade?

Carlton

Es war eine großartige Woche mit Gesprächen mit einigen unserer OEM Partner, und wir werden an dem weiterarbeiten, worüber wir heute sprechen. Ich bin in Carmel in Indiana in den USA.

Und Martin, bist du am selben Ort oder woanders?

Martin

Ziemlich nah dran. Ich bin in Columbus in Indiana, etwa eine bis eineinhalb Stunden von Carlton entfernt.

Verstehe. Okay. Und wo befindet sich euer Unternehmenssitz?

Martin

In Columbus in Indiana.

Columbus, alles klar. Grüße an alle, die jetzt zuhören und heute dabei sind. Vielleicht starten wir mit einer kurzen Vorstellungsrunde. Neil, ich habe dich bereits als CEO und Mitgründer von Portainer vorgestellt. Du hast mehr als 25 Jahre Erfahrung in IT und Cloud Consulting, und du hast Portainer gebaut, um Container Management einfach und zugänglich zu machen. Zu Beginn, wie lange kennst du Carlton und Martin in diesem Projekt, und wie wichtig ist dieses Projekt für Portainer?

Neil

Martin und ich kennen uns seit ganz am Anfang des Projekts. Ich erinnere mich noch an den allerersten Zoom Call mit etwa 20 Leuten, die detaillierte Fragen zum Produkt und seiner Funktionsweise gestellt haben. Ich glaube, ich habe Carlton erst letztes Jahr zum ersten Mal getroffen.
Wie wichtig ist Cummins für Portainer? Ungemein wichtig. Portainer hat sich von einem Rechenzentrumstool zu einem industriellen IoT Tool entwickelt, und dabei nimmt der Skalierungsbedarf drastisch zu. Hunderte oder tausende Geräte in einem Rechenzentrum sind viel, aber in einer IoT-Flotte gilt das als klein – in großen IoT-Projekten spricht man von hunderttausenden oder sogar Millionen Geräten. Die Zusammenarbeit mit Cummins als Co Design Partner, um Portainer auf diesem Niveau zuverlässig und skalierbar zu machen, war für uns äußerst wertvoll.

Das ist großartig. Ich freue mich darauf, mehr darüber zu erfahren, wie ihr das umsetzt, und Portainer im Detail zu erkunden. Um die Runde zu schließen, machen wir mit dir weiter, Martin. Du bist der Lead IoT Software Architect. Dein Hintergrund liegt in Edge Computing, Embedded Systems und Containerisierung, und du warst im Zentrum der Gestaltung der Softwareplattform von Cummins. Würdest du sagen, du bist der leitende Architekt der Lösung, also der Techie in unserem Gespräch, oder wie würdest du deine Rolle beschreiben?

Martin

Ja, ich bin der leitende Architekt für die Anwendungsseite der Software. Wir haben unsere Arbeit in die Anwendungsseite und die Middleware plus das Betriebssystem aufgeteilt. Mein Manager führt die Middleware und das OS und verantwortet die Gesamtlösung, ich habe den Bereich der Anwendungssoftware für das IoT Projekt geleitet.

Perfekt. Und Carlton, du leitest die Entwicklung der nächsten Generation von Software Defined Vehicles. Dein Fokus liegt darauf, sicherzustellen, dass komplexe und hoch konfigurierbare Motoren über Software gesteuert werden können. Würdest du sagen, du bist eher der Visionär, der die Zukunft der Software Defined Vehicles bei Cummins vorantreibt, oder wie würdest du deine Rolle in diesem Projekt beschreiben?

Carlton

Ja, das ist eine sehr gute Beschreibung. Ich habe das Glück, in einer Position zu sein, in der ich mit solchen Ideen kommen kann, zum Beispiel Container auf Edge Geräten auszuführen, und dann mit Martin und anderen zusammenzuarbeiten, um sie Wirklichkeit werden zu lassen. Wir sprechen hier über das Jahr 2019. Die Vision zu entwickeln, wohin es gehen soll, ist der einfache Teil. Die eigentliche Herausforderung ist es, die Einführung voranzutreiben, sobald die Richtung klar ist.

Was sollten wir über das Unternehmen wissen? Ich habe eine kurze Einführung zu Cummins gegeben, aber könntest du uns mehr über euer Kerngeschäft, eure Kunden, eure Produkte erzählen und darüber, was wir über dieses Projekt und das Unternehmen dahinter verstehen sollten?

Carlton

Gern. Der Hintergrund unseres Unternehmens und dieses Projekts liegt im Bereich der Nutzfahrzeuge. Wir arbeiten mit einer großen Zahl von OEMs, mehr als 20, konzentrieren uns aber vor allem auf unsere vier größten. Das Problem war, dass es 2012, als wir die Initiative gestartet haben, keine passenden Optionen der Gerätehersteller gab, um Konnektivitäts und Telematikfunktionen anzubieten. Also mussten wir mit Aftermarket Telematikanbietern zusammenarbeiten und unsere Software für deren spezifische Hardware und Softwareumgebungen schreiben. Am Anfang mit nur zwei Partnern funktionierte das gut, aber in den folgenden Jahren wuchs die Zahl auf 35. Das bedeutete, 35 verschiedene Versionen derselben Edge und Konnektivitätsfunktionen zu pflegen.
Als wir dieses Projekt 2019 gestartet haben, war das Ziel, alles drastisch zu vereinfachen. Wir wollten einen Ansatz nach dem Prinzip write once, run anywhere. Der beste Weg, die Anwendungsschicht von der Betriebssystemschicht zu trennen, waren OCI Container. Also sind wir damals einen mutigen Schritt gegangen, weg von unserer Legacy Embedded Architektur und den proprietären Telematikgeräten hin zu einem modulareren Setup, bei dem die Anwendung in einem OCI Container läuft und die Anwendungsinterfaces klar definiert sind. Wir konnten erfolgreich zeigen, dass diese Betriebsweise tragfähig ist, und haben gesehen, dass derselbe Ansatz auch außerhalb unseres Unternehmens in der Branche Anklang findet.

Okay, nur um das Schlüsselwort zu klären, wenn du von OCI sprechst, meinst du die Open Container Initiative, richtig?

Carlton

Genau. Es geht um die Open Container Initiative, einen Zusammenschluss von Unternehmen, die Standards dafür definieren, wie Software containerisiert und in einer abstrahierten Umgebung betrieben werden kann. In der Cloud ist das sehr verbreitet. Für Edge Anwendungen war es weniger üblich, besonders im Automotive Umfeld, das neue Technologien langsamer übernimmt.

Okay. Du hast eure OEMs erwähnt. Hast du Beispiele, die das greifbarer machen?

Carlton
Gern. PACCAR DAF ist einer unserer größten OEMs. Ich denke, jeder kennt Daimler Trucks mit Präsenz in Europa und den USA sowie die TRATON GROUP mit Scania und International Trucks.

Verstehe. Du hast Konnektivität und Telematikfunktionen und den Pflegeaufwand erwähnt. Es gab also viel Wartungsarbeit.

Carlton

In der Vergangenheit ja. Wir hatten 35 verschiedene Versionen unserer Software. Künftig stellen wir unseren Partnern einen OCI Container bereit. Sie spielen ihn auf ihr Konnektivitätsgerät. Das löst für alle viele Probleme. Wir brauchen nicht mehr mehrere Versionen unserer Software, und unsere OEM Partner müssen sich nicht mehr mit so vielen unterschiedlichen Lieferanten abstimmen, die jeweils andere Softwarepakete bereitstellen.

Verstehe. Das ist wohl auch der Punkt, an dem der Business Case ins Spiel kommt. Wir sprechen gleich darüber. Kannst du uns noch einmal an den Anfang des Projekts mitnehmen? Worum ging es bei dem Projekt, und wie kam die Partnerschaft zwischen Cummins und Portainer zustande?

Martin

Ja, wie Carlton erwähnt hat, er hatte die Vision, OCI Containertechnologie auf diesen Geräten einzusetzen. Ich hatte das Glück, ausgewählt zu werden, die Architektur dafür zu leiten. Vor etwa fünf Jahren, als wir entschieden haben, diese Software und Technologie zu nutzen, schien es, als wären alle notwendigen Bausteine schon vorhanden, standardisierte Containerpakete, standardisierte Formate, Cloud Container Registries sowie lokale Container Orchestrierung und Ausführung. Aber wir haben eine große Lücke entdeckt, wir hatten keine Möglichkeit, Container auf den Geräten aus der Ferne zu orchestrieren. Sobald diese Geräte gefertigt sind, wollen wir sie physisch nicht mehr anfassen.
Ich habe einen Proof of Concept und einen Testlauf mit Portainer gezeigt. Deren Lösung hat fast jeden unserer Punkte erfüllt. Damit war die Technologie die naheliegende Wahl. Obendrein war es so, dass andere Anbieter eher zurückhaltend waren. Sie sagten Dinge wie, hier ist das Produkt, es gibt eine Open Source Version zum Testen, und wenn ihr es kommerziell nutzen wollt, kommt später wieder. Neil und sein Team waren dagegen von Anfang an engagiert. Sie haben sich verhalten, als wären sie Teil unseres Teams, und mit uns an der Lösung gearbeitet, noch bevor es eine offizielle Vereinbarung gab. Das machte sie zur klaren Wahl.

Neil

Am Anfang wussten sowohl Cummins als auch Portainer nicht vollständig, was wir nicht wussten. Wir wussten beide, dass wir Anwendungscontainer für Telematik und andere Software einsetzen wollten, aber die Frage war, wie. Sobald ein Gerät draußen im Feld ist, es wieder physisch zu berühren, ist wie ein Produktrückruf. Das ist teuer und zeitaufwendig. Also lautete die Herausforderung, wie stellst du sicher, dass du eine Maschine nie wieder anfassen musst? Wie stellst du sicher, dass ein Anwendungsupdate niemals fehlschlägt und vollständig atomar ist? Das war eine spannende Aufgabe, und wir waren begeistert, mit Cummins tief einzusteigen, um gemeinsam die Zukunft zu bauen.

Verstehe. Und da kommt ihr mit Portainer.io ins Spiel, ihr ermöglicht mit eurer Technologie Over the Air Updates in standardisierter Form. So wird der Prozess für OEMs schneller, sicherer und skalierbarer.

Neil

Es gab eine lange Liste an Idealen und eine lange Liste an Einschränkungen. Es ist leicht zu sagen, man will Over the Air Updates, die atomar sind, ohne weitere Grenzen. In der Realität hatten wir Grenzen bei Bandbreite, Datentransfer und Stromversorgung. Die meisten dieser Punkte waren tatsächlich vorhanden. Wir hatten Herausforderungen von beiden Seiten. Wie lieferst du eine sehr funktionsreiche Lösung, und wie betreibst du sie in einer stark eingeschränkten Umgebung mit Sicherheits, Netzwerk und Gerätebeschränkungen?

Bevor wir darauf eingehen, wie ihr das gelöst habt und über Best Practices sprechen, Carlton, kannst du die Hauptziele zusammenfassen, als ihr dieses Projekt gestartet habt? Was war dir wichtig, und was musste passieren, damit ihr das als Erfolg bezeichnen konntet?

Carlton

Unser oberstes Ziel war es, zu beweisen, dass dieser Ansatz für den Betrieb von Software tragfähig ist. Dafür mussten wir etwas in die Produktion bringen. Wir mussten außerdem pünktlich launchen. Wir hatten einen Programmzeitplan. Intern gab es Bedenken, denn unser Legacy Telematikgerät nutzte einen vollständig proprietären Stack und eine proprietäre Anwendungsplattform auf Java Basis. Wir haben entschieden, den gesamten Stack zu ersetzen, inklusive des Betriebssystems, ihn selbst zu bauen und mit Partnern wie Portainer zusammenzuarbeiten, und trotzdem unsere Zeitpläne einzuhalten. Es gab Skepsis, ob dieses Arbeitspensum machbar ist. Also mussten wir das Konzept beweisen und uns darauf verlassen, dass unsere Partner liefern. Ein interessanter Effekt war, wie wir die Container Orchestrierung über Portainer genutzt haben, um andere Software im Fahrzeug zu steuern. Wir haben gefragt, wie wir das Linux Betriebssystem auf unserem Edge Gerät aktualisieren und wie wir die Software in unseren Steuergeräten aktualisieren. Martin und das Team haben eine neuartige Lösung geschaffen, die einen Orchestrator, der für Container gedacht ist, auch dafür nutzt, den Rest des Fahrzeugs zu aktualisieren.

Verstehe. Die gesamte Vision dahinter ist also, den Wartungsprozess für eure OEMs, Kunden und alle Beteiligten in der Lieferkette zu vereinfachen, richtig?

Carlton

Ganz genau. Wir bedienen zwei Kundengruppen. Die erste sind unsere OEM-Kunden – an sie verkaufen wir unsere Antriebsstränge. Aber letztlich liefern diese OEMs die kompletten Fahrzeuge an Flottenbetreiber, und auch für sie bieten wir Lösungen an, um Einblicke in die Fahrzeugleistung zu erhalten und mögliche Ausfälle zu erkennen. Unser Ziel ist, dass egal über welchen OEM ein Kunde unsere Antriebssysteme nutzt, er immer dieselben Funktionen und dasselbe Nutzungserlebnis bekommt. Um das zu erreichen, müssen wir unsere Software auf einer Vielzahl von Plattformen bereitstellen und sie kontinuierlich auf dem neuesten Stand halten, damit Kunden stets die erwarteten Funktionen haben.

Alles klar. Martin, wie würdest du die technischen Use Cases beschreiben, die ihr in diesem Projekt adressiert?

Martin

Wir haben damit begonnen, Software-Containerisierung zu ermöglichen und sie auf einem eingebetteten Linux-Gerät auszuführen, das direkt am Motor montiert ist. Dieses Linux-Gerät kommuniziert mit unserer Motorsteuerungseinheit. Einer der wichtigsten Anwendungsfälle, wie Neil schon erwähnt hat, ist die Frage, wie wir Software-Updates für diese Linux-Geräte, die draußen im Feld im Einsatz sind, aus der Ferne verwalten.
Ein weiterer zentraler Use Case ist die Aktualisierung der Motorsteuerungseinheit selbst, die zusammen mit dem eingebetteten Linux-Gerät arbeitet. Die Motorsteuerungseinheit hat keine eigene Konnektivität, sie kann also nicht selbstständig ins Internet gehen, um Software-Updates herunterzuladen. Sie ist auf das eingebettete Linux-Gerät angewiesen, das diesen Prozess übernimmt.
Die beiden Haupt-Use-Cases sind also: das Aktualisieren der Telematiksoftware, die auf dem eingebetteten Linux-Gerät läuft und die Geschäftslogik sowie die höherwertigen Funktionen ausführt, und das Aktualisieren der Software der Motorsteuerungseinheit über genau dieses Gerät.
Wie Carlton erwähnt hat, haben wir zu diesem Thema sogar ein Paper auf IP.com veröffentlicht, mit dem Titel „Updating Embedded Linux OS Using OCI Container Technology“.

Okay, sehr gut. Übrigens – ist dieses Paper offiziell? Kann ich es in den Show Notes verlinken, oder ist es ein internes Dokument?

Martin

Ja, es ist offiziell. Es wurde auf IP.com veröffentlicht.

Perfekt. Dann nehme ich den Link in die Show Notes auf, damit alle, die mehr erfahren möchten, dort nachlesen können. Neil, eine Frage kommt mir, wenn ich diese Use Cases höre. Du arbeitest mit vielen verschiedenen Kunden. Sind das typische Anwendungsfälle, die ihr mit der Portainer-Technologie löst, oder war dieses Projekt eher einzigartig?

Neil

Als wir damit begonnen haben, war es völlig einzigartig für Cummins. Sie haben ganz klar eine Vorreiterrolle eingenommen. Inzwischen werden ähnliche Use Cases häufiger, aber damals war Cummins definitiv führend.

Das ist spannend. Wenn man über all diese technischen Aspekte und die Größe des Projekts hört, wird auch klar, dass es eine erhebliche Investition in Technologie war. Carlton, kannst du ein bisschen etwas über den Business Case dahinter erzählen? Vielleicht keine genaue ROI-Berechnung, aber die geschäftlichen Herausforderungen und die Überlegungen, die zu diesem Projekt geführt haben?

Carlton

Gern. Einer der größten Unterschiede in der Nutzfahrzeugbranche ist, dass sie extrem kostengetrieben ist. Flotten arbeiten mit geringen Margen und suchen nach jeder möglichen Effizienzsteigerung. Die meisten unserer Entscheidungen zielen deshalb auf Kostensenkung ab. Unsere Edge-Software kann entweder die Kraftstoffeffizienz verbessern oder die Betriebszeit erhöhen, sodass die Fahrzeuge länger in Betrieb bleiben. Beides reduziert direkt die Betriebskosten der Flotten.
Wir haben dieses Projekt als Chance zur Kostenreduktion betrachtet. Es war klar, dass die Pflege von 35 verschiedenen Softwareversionen über mehrere Partnerschaften hinweg weder nachhaltig noch wirtschaftlich war. Auch wenn der Aufbau des neuen Software-Stacks eine erhebliche Anfangsinvestition erforderte, war er Teil einer größeren Strategie: Wir wollten einige der von uns entwickelten Schnittstellen als Open Source bereitstellen, damit sie auch von anderen Plattformen übernommen werden können.
Eine der größten Herausforderungen lag intern. Wir mussten das Management davon überzeugen, dass wir auf eine offene Architektur umstellen und trotzdem eine breite Akzeptanz erreichen können. Zum Vergleich: Unsere vorherige proprietäre Plattform war zwei Jahre lang in Produktion und hatte dennoch nicht alle geplanten Funktionen zum Start geliefert. Die Skepsis war also nachvollziehbar. Das Risiko war groß, dass ein Scheitern der neuen Architektur noch schlechter ausgesehen hätte. Zum Glück konnten wir durch Partnerschaften mit Unternehmen wie Portainer und die Integration verschiedener Open-Source-Lösungen in unsere Plattform die Entwicklung beschleunigen, Risiken reduzieren und tatsächlich unseren Produktionszeitplan einhalten.

Okay, verstehe. Neil, wie siehst du das? Möchtest du etwas ergänzen oder erklärt das bereits die Business-Perspektive?

Neil

Ich kann sagen, dass der Zeitdruck enormen Einfluss auf unser Engineering-Team hatte. Wir haben das Produkt ständig weiterentwickelt und verbessert, immer genau so weit, wie Cummins es in der jeweiligen Phase brauchte. Jedes Mal, wenn wir einen Meilenstein erreichten, kamen neue Anforderungen hinzu, die sinnvoll umzusetzen waren. Wir entwickelten also Version für Version weiter, um Schritt zu halten. Wir arbeiteten mit sehr engen Zeitplänen. Es dauerte etwa zwei Jahre, vom ersten Konzept bis zu einer einsatzbereiten Lösung, aber diese zwei Jahre vergingen schnell durch die ständige Iteration.

Gern. Hast du vielleicht ein paar Best Practices? Oder kannst du technische Herausforderungen nennen, auf die ihr in diesem Projekt gestoßen seid?

Neil

Wir mussten eine neue Version unseres Agents entwickeln. Portainer basiert auf einer Server-Agent-Architektur: Der Server übernimmt das Management, während der Agent auf den Geräten läuft und Anweisungen empfängt. Für diesen speziellen Anwendungsfall mussten wir den Agent neu gestalten, um mit Bandbreitenbeschränkungen und Netzwerkausfällen umgehen zu können. Diese Geräte bewegen sich mit hoher Geschwindigkeit auf Autobahnen und verlieren ständig die Mobilfunk- oder Netzwerkverbindung. Wir mussten sicherstellen, dass instabile Konnektivität weder die Zuverlässigkeit des Produkts noch die Softwarebereitstellung oder andere Prozesse beeinträchtigt.
Das war eine zentrale Herausforderung für uns. Zusätzlich gab es extrem strenge Sicherheitsanforderungen – wie man sich vorstellen kann, bei Systemen, die in Fahrzeugen mit Menschen im Einsatz sind. Diese Sicherheitsstandards einzuhalten und gleichzeitig die Zuverlässigkeit zu gewährleisten, war eine große technische Herausforderung.

Das ist wirklich interessant. Viele Zuhörer fragen sich wahrscheinlich auch, wie man das Ganze skaliert – also wie man sicherstellt, dass die Lösung wirklich skaliert, wie du es vorhin erwähnt hast. Ihr habt Hunderte oder sogar Tausende Geräte im Feld, die gleichzeitig verwaltet werden müssen.

Neil

Skalierung ist schwierig. Die größte Herausforderung ist die Parallelität. Wenn du hundert Geräte hast und Befehle sendest, kannst du die Zeitpunkte zufällig variieren, um Netzüberlastungen oder Kollisionen zu vermeiden. Die Wahrscheinlichkeit, dass mehrere Geräte genau gleichzeitig reagieren, ist gering. Wenn du aber hunderttausend Geräte hast, steigt die Wahrscheinlichkeit gleichzeitiger Aktionen enorm. Dann stellt sich die Frage, wie man Datenbank-Schreibvorgänge und Sperrmechanismen handhabt, wenn viele Geräte gleichzeitig aktiv sind.
Als Cummins immer mehr Geräte ausrollte, wuchs diese Herausforderung stetig. Wir mussten mehrere Elemente unserer internen Architektur neu gestalten, um IoT-Deployments in dieser Größenordnung zu unterstützen. Der Vorteil war, dass diese Verbesserungen das gesamte Produkt robuster gemacht haben – nicht nur für Cummins, sondern für alle unsere Kunden. Portainer ist jetzt wesentlich besser in der Lage, Parallelität und großflächige Deployments zu bewältigen.

Richtig. Und von Cummins’ Seite – habt ihr dazu praktische Anmerkungen? Würdest du dem zustimmen, oder gibt es noch weitere Aspekte, die du ergänzen würdest?

Martin

Die Skalierbarkeit von Portainer wirkt sich direkt auf unsere Geräte aus, denn wenn Portainer nicht skaliert, kann es unsere Geräte nicht verwalten. Portainer hat den Anspruch, vollständig atomar zu sein, also so, dass bei einem Problem die Ursache nicht bei Portainer liegt.
Sobald Portainer die Software-Updates versendet hat, liegt der Rest bei uns. Wir wollen, dass unsere Software sich automatisch von Fehlern oder Updateproblemen erholen kann.
Das bringt eine zusätzliche Komplexitätsebene mit sich, denn wenn man Software entwickelt, ohne die Hardware mitzudenken, treten solche Probleme nicht auf. Aber wenn Sicherheit, Hardware und Fernzugriff zusammenspielen, muss man sicherstellen, dass man die Geräte weiterhin erreichen und Updates einspielen kann. Wenn das gelingt, ist jedes Problem im Grunde lösbar – auch aus der Ferne.

Verstehe. Neil oder Carlton, welches Produkt von Portainer verwendet ihr hier genau? Wie stellt Portainer sicher, dass die Lösung nicht nur auf einem einzelnen Gerät funktioniert, sondern auch effizient auf Tausende Fahrzeuge und verschiedene OEMs skaliert? Was steckt technisch dahinter, und wie funktioniert die Lösung konkret?

Neil

Portainer hat zwei Hauptprodukte: unsere Open-Source-Version und unsere kommerzielle Version. Das Open-Source-Produkt ist für Experimente gedacht und wird von der Community unterstützt. Es wird zwar von uns entwickelt und gepflegt, richtet sich aber eher an die Community als an den Unternehmenseinsatz.
Das kommerzielle Produkt heißt Portainer Business. Es bietet ein deutlich höheres Maß an Qualitätssicherung, Tests und Sicherheitskonformität – also alles, was für professionelles Enterprise-Software-Management nötig ist. Portainer Business ist die Server-Komponente, und dazu kommen sogenannte Agents, kleine Software-Module, die auf den Geräten im Feld laufen – in diesem Fall auf den Antriebssträngen. Diese Agents ermöglichen eine sichere Kommunikation zwischen dem Portainer-Management-Server und den Geräten. Sie stellen sicher, dass die Software korrekt ausgerollt und ausgeführt wird, und senden gleichzeitig Status- und Zustandsinformationen zurück, um den Server aktuell zu halten.

Cool. Und wenn du über die Community sprichst – hast du KPIs, wie groß sie ist oder wie viele Menschen sie nutzen, um ein Gefühl für die Dimension zu bekommen?

Neil

Das wird immer schwieriger zu messen. Wir haben zwar einige Analysefunktionen im Produkt integriert, aber die meisten Nutzer deaktivieren sie. Basierend auf den aktiven Installationen greifen derzeit rund 1,4 Millionen Nutzer jeden Monat auf die Portainer Community Edition zu. Insgesamt gab es über die gesamte Laufzeit hinweg etwa 3,4 Milliarden Downloads. Die Community ist also ziemlich groß. In der kostenpflichtigen Enterprise-Version erfassen wir keinerlei Nutzungsdaten, weil unsere Kunden vollständige Privatsphäre erwarten und in geschützten Netzwerken arbeiten.

Verstehe. Zum Abschluss: Warum habt ihr euch letztlich für Portainer entschieden, und welche Ergebnisse habt ihr bisher erzielt? Kannst du etwas zu den bisherigen Ergebnissen sagen und wo die Reise als Nächstes hingeht?

Martin

Ja, ich kann erklären, warum wir uns für Portainer entschieden haben – und vielleicht kann Carlton gleich etwas zu den Ergebnissen sagen, weil er das Gesamtbild besser kennt. Wie ich schon erwähnt habe, war unsere Entscheidung von der Technologie und den Menschen dahinter geprägt. Technologisch hat Portainer genau das getan, was wir brauchten. Neil hat gesagt, dass es anfangs noch einige Lücken gab, aber auf einer höheren Ebene war die Software genau das, was wir gesucht hatten, sobald wir sie getestet haben.
Es war anfangs gar nicht so einfach zu wissen, was wir tatsächlich brauchen, weil wir noch gar nicht wussten, was technisch möglich war. Wir wollten keine Zeit damit verbringen, alles selbst zu entwerfen. Deshalb haben wir mehrere Lösungen getestet, die versprachen, OCI-Container auf Edge-Geräten remote zu verwalten. Sobald wir Portainer ausprobiert hatten, war klar, dass die Lösung passte. Wir haben die Auswahl schnell auf zwei Optionen eingegrenzt – und nach den Gesprächen mit Neil und seinem Team war eindeutig, dass Portainer die richtige Wahl war.

Carlton

Was die Ergebnisse betrifft: Es ist natürlich viel überzeugender, Partnern ein laufendes System in der Produktion zu zeigen, statt eine PowerPoint-Präsentation und das Versprechen, dass es funktionieren wird. Ein erfolgreicher Produktionsstart, das Erreichen der geplanten Skalierung und die Wiederverwendbarkeit der Software, die wir anstrebten, zeigen, dass diese offene Lösung tatsächlich tragfähig ist.
Wir sehen jetzt eine deutliche Verbreitung von OCI-Containern in der gesamten Branche – als Standardansatz, um Software auf unterschiedlichen Hardwareplattformen auszurollen. Außerdem bringen wir unsere Erfahrungen und Entwicklungen in die Eclipse Software Defined Vehicle Working Group ein, wo wir Schnittstellen, APIs und Transportmechanismen als Open Source bereitstellen. Damit entsteht ein breiteres Ökosystem, das über den Bereich der Nutzfahrzeuge hinausgeht.

Und da du dieses Ökosystem erwähnt hast: Ihr arbeitet also nicht nur mit Portainer, sondern auch mit anderen Partnern zusammen. Gehört es zu eurer Strategie, künftig noch enger mit OEMs und weiteren Partnern zu kooperieren?

Carlton

Ja, auf jeden Fall. Wir verfolgen zwei parallele Ansätze. Der erste ist die offene Zusammenarbeit mit anderen Unternehmen wie Bosch, ETAS, Elektrobit und Allison Transmission, um diese Fähigkeiten gemeinsam im Open-Source-Ansatz zu entwickeln und ihre Reife zu demonstrieren, während sie sich weiterentwickeln. Einige unserer OEM-Partner schließen sich dieser offenen Initiative bereits an.
Der zweite Ansatz ist die direkte Zusammenarbeit mit OEM-Kunden bei konkreten Implementierungen. Das umfasst Beratung bei der Einführung der neuen Technologie, das Teilen unserer Erfahrungen und die Unterstützung bei der Integration und dem Betrieb unserer OCI- oder Docker-basierten Container auf deren Geräten.

Das klingt nach einer starken Vision für die Zukunft. Das führt mich zur letzten Frage für unsere heutige Session: Wenn du in die nächsten vier oder fünf Jahre blickst, was erwartest du für dieses Projekt?

Carlton

Natürlich haben wir laufende Implementierungspläne mit unseren OEM-Partnern, die sich mit der Einführung neuer Produkte weiter ausdehnen werden. Was die breitere Zusammenarbeit betrifft, so arbeiten wir, wie bereits erwähnt, über die Eclipse Software Defined Vehicle Group und COVESA, die Connected Vehicle Alliance.
Wir arbeiten an Projekten wie uProtocol und S-CORE mit, die Methoden entwickeln, damit Anwendungen nahtlos über alle verschiedenen Bereiche eines Fahrzeugs hinweg miteinander kommunizieren können. Wir tragen nicht nur zu diesen Projekten bei, sondern übernehmen die Technologien auch selbst für Tests und später für den Produktionseinsatz.
Das Ziel ist der Aufbau einer gemeinsamen IoT-Infrastruktur, also eines Frameworks, das nicht einem einzelnen Unternehmen gehört, sondern branchenweit nutzbar ist. Dadurch können wir den Fokus von der Infrastruktur auf die Anwendungen verlagern, die darauf laufen – denn dort entsteht der eigentliche Kundennutzen. In den nächsten Jahren wird die Branche also vom Aufbau der Grundlagen hin zur Wertschöpfung durch Anwendungen und Services auf dieser gemeinsamen Basis übergehen.

Perfekt. Und für alle, die zuhören: Ich füge alle Links in die Show Notes ein – zu den genannten Initiativen, Arbeitsgruppen und weiterführenden Informationen. Wenn es für euch in Ordnung ist, Carlton, Martin und Neil, würde ich außerdem eure LinkedIn-Profile verlinken. So können sich alle, die an ähnlichen Projekten arbeiten oder sich über Ansätze austauschen möchten, direkt mit euch vernetzen. Ist das in Ordnung?

Carlton

Das wäre großartig.

Neil

Ja, auf jeden Fall.

Martin

Ja, klar.

Super. Dann, Neil, geht die letzte Frage an dich: Was können wir in Zukunft von Portainer.io erwarten? Wie sehen eure nächsten fünf Jahre aus?

Neil

Nun, wir entwickeln im Grunde ständig weiter. Softwareprojekte sind nie wirklich abgeschlossen – es gibt immer etwas Neues, das verbessert oder ergänzt werden kann. Skalierung bleibt dabei ein zentrales Thema. Momentan können wir die Anforderungen von Cummins gut erfüllen, aber langfristig wollen wir das Zehnfache erreichen. Unser Ziel ist eine Architektur, die auch bei Millionen von Geräten zuverlässig und sicher funktioniert. Dafür untersuchen wir gerade die Container-Runtimes, die am Edge eingesetzt werden, und wie wir sie für noch mehr Skalierbarkeit und Stabilität optimieren können.
Historisch wurde am Edge Docker verwendet, in jüngerer Zeit Podman, und mittlerweile taucht auch Kubernetes in Edge-Umgebungen auf. Mit der Entwicklung des Ökosystems stellt sich die Frage, wie das in der Praxis wirklich aussieht. Kubernetes wurde ursprünglich für Rechenzentren konzipiert, nicht für sehr kleine, ressourcenbeschränkte Geräte. Die Herausforderung ist also: Wie kann man es in diesem Kontext zuverlässig einsetzen?
Wir haben bereits ein Projekt namens KubeSolo.io gestartet. Es ist unser erster Ansatz, Kubernetes auf kleine Geräte zu bringen – weiterhin Kubernetes, aber angepasst an ressourcenbeschränkte Umgebungen. Außerdem arbeiten wir daran, die Portainer-Benutzeroberfläche für die eigentlichen Endnutzer zu vereinfachen. Im Fall von Cummins sind das interne Business-User, die Software einfach bereitstellen und sicherstellen wollen, dass sie läuft. Momentan zeigt die Oberfläche noch zu viele technische Details. Daher entwickeln wir eine fokussiertere Version, die besser auf die Bedürfnisse dieser Nutzer zugeschnitten ist.

Das klingt großartig. Vielleicht können wir in einem Jahr eine weitere Episode planen, um ein Update zu diesen Entwicklungen zu bekommen. Es passiert offensichtlich viel und noch mehr steht bevor. Für den Moment möchte ich mich ganz herzlich für diese Session bedanken. Vielen Dank, dass ihr heute dabei wart, und damit überlasse ich euch das Schlusswort.

Neil

Wenn man an den Beginn dieses Projekts zurückdenkt, war es beeindruckend, wie viel Weitsicht und Vision nötig waren, um eine Technologie, die damals noch neu in Rechenzentren war, an den Edge, also in Fahrzeuge, zu bringen. Für ein Unternehmen wie Cummins war es schon bemerkenswert, überhaupt über so eine Idee nachzudenken. Und für die beteiligten Personen war es auch ein persönlicher Schritt – Vertrauen zu haben und an das Potenzial dieser Technologie zu glauben. Respekt an Cummins. Ihr habt mit dieser Vision wirklich unsere Aufmerksamkeit gewonnen, und alles, was wir als Unternehmen tun können, um euch zu unterstützen, habt ihr sicher. Das war ein mutiger Schritt.

Martin

Ja, und es ist schön, dich wiederzusehen, Neil. Wir arbeiten nun schon seit fünf Jahren immer wieder zusammen, und Portainer ist diesen Schritt gemeinsam mit uns gegangen. Ihr habt uns geholfen, diese Lösung zu entwickeln, und wir freuen uns darauf, die Zusammenarbeit mit dir und deinem Team fortzusetzen.

Neil

Vielen Dank für die Gelegenheit.

Carlton

Vielen Dank.

Danke für diese Session und euch allen eine gute restliche Woche. Tschüss!

Martin
Tschüss!