Produktdigitalisierung für OEMs: komplexe Feldprodukte modular entwickeln

Heute im IoT Use Case Podcast: Wie man IoT-Lösungen in Maschinen und Fahrzeugen im Feld Realität werden lässt. Das heißt insbesondere dort, wo sogenannte OEMs, also Originalhersteller von Geräten wie Zügen oder Landmaschinen, digitale Funktionen sicher und nachhaltig in ihre Produkte bringen wollen.
Zu Gast haben wir Tobias Maier, CEO der ML!PA Consulting GmbH, sowie Mirko Spitalny, Teamlead Hardware Development bei ML!PA. Unser Gespräch zeigt: Wenn Maschinenhersteller ihre Geräte im Feld vernetzen, stoßen sie immer wieder auf die drei gleichen, wirklich harten Probleme. Wer diese Hürden beherrscht, schafft robuste IoT-Produkte, und wir besprechen, wie das geht.
Viel Spaß beim Zuhören.

Hallo und herzlich willkommen zum IoT Use Case Podcast mit eurem Podcast-Cohost Dr. Peter Schopf. Heute geht es nicht um Shopfloor-Optimierung, also um Fabriken. Wir sprechen über digitalisierte Produkte. Als Gäste haben wir Mirko und Tobias. Mirko, stell dich doch mal vor: Wo sitzt du heute? Was treibt dich um? Was hast du heute so gemacht?

Mirko

Hallo Peter. Ich bin heute bei uns im Büro. Mein Tag hat angefangen wie die meisten meiner Arbeitstage: mit einem Meeting mit meinem Team, in dem wir kurz die aktuellen Themen besprechen, Aufgaben verteilen, Schwierigkeiten lösen und sicherstellen, dass jeder weiß, was am Tag ansteht. Ich arbeite seit 2021 bei ML!PA und war vorher ungefähr zehn Jahre im Bereich Luft- und Raumfahrt in der Forschung tätig. Bei ML!PA habe ich zunächst beim Thema Datenauswertung angesetzt. Dann hat sich herauskristallisiert, dass wir auch weiter Richtung Hardware gehen. Dort habe ich meine Fähigkeiten ausgebaut. Aktuell bin ich Team Lead im Hardware Development und leite ein Team aus Ingenieuren mit ganz unterschiedlichen Fähigkeiten.
Das ist sehr spannend, weil man daran sieht, was alles benötigt wird, um ein erfolgreiches IoT-Device zu bauen. Es geht vom klassischen Engineering bis in sehr digitale Welten hinein. Das ist jeden Tag eine neue Herausforderung und macht mir sehr viel Freude.

Das hört sich sehr spannend an. Da freue ich mich darauf, da ein bisschen tiefer einzusteigen. Dann haben wir noch einen Gast: Tobias, zu dir. Was hast du denn heute getan?

Tobias

Hallo, Tobias ist mein Name. Ich bin einer der drei Gründer der ML!PA. Ich habe schon lange mit digitalen Produkten gearbeitet, bevor ich vor zehn Jahren mit zwei Partnern zusammen ML!PA gegründet habe. Mein Hintergrund ist Physik, ich bin dann aber relativ schnell im Bereich Digitaldruck gelandet, vor mittlerweile schon 25 Jahren. Das war damals Hightech, kann man sich heute kaum noch vorstellen. Wir haben damals schon relativ viel im Bereich Produktindividualisierung gemacht, waren eine Zeit lang in der Konzernumstrukturierung und ich muss sagen: Ich bin ein bisschen aufgeregt heute. Ich bin zwar auch im Office, genau wie Mirko, sitze in einem anderen Raum, aber im gleichen Stockwerk. Du machst das ja ständig, Peter, ich mache das eigentlich nie. Ich habe heute Morgen meine Tochter gefragt, was man da so beachten muss, und sie sagte: Das Wichtigste ist die Reichweite. Das war für mich erst mal sehr positiv, weil ich dachte: Reichweite, KPI, damit kannst du was anfangen. Ich habe dann aber auch von ihr erfahren, was ich dafür machen müsste, und sie sagte: Das Einzige, was wirklich funktioniert in deinem Alter, ist True Crime. Für alles andere bist du einfach viel zu alt. Wenn ihr hier heute True Crime erwartet, müssen wir euch enttäuschen. Das können wir heute leider nicht bringen, aber vielleicht ein bisschen über unsere Geschichte und wie wir dazu gekommen sind, digitale Produkte zu entwerfen und darauf basierend irgendwann ein Ökosystem zu schaffen. Vielleicht gehen wir ein bisschen weiter zurück ins Jahr 2015. Wir haben eigentlich mit zwei Dingen angefangen. Einerseits haben wir Preisroboter für Internetseiten gebaut. Das hat mit IoT gar nichts zu tun. Relativ bald nach der Gründung sind wir aber in den Bereich Industrial IoT eingestiegen, damals in erster Linie, wie viele es machen, im Bereich Shopfloor-Optimierung. Das heißt, wir haben Maschinen bei Kunden vernetzt, Datenintegrationssysteme gebaut, waren sehr softwarelastig unterwegs zu der Zeit. Dann haben wir von einem großen Kunden aus Köln, Weltmarktführer im Bereich Energiekettensysteme, eine Anfrage bekommen, ob wir nicht auch mit ihm zusammen ein digitales Produkt bauen wollen. Wir haben gesagt: Das muss ja eigentlich ähnlich gehen wie Shopfloor-Automation. Wir haben aber sehr schnell gemerkt: Das ist völlig anders. Denn wenn ich ein digitales Produkt habe, dann ist das beim Kunden, und damit habe ich es nicht mehr im Zugriff. Auf einem Shopfloor kann ich schnell jemanden hinschicken, der etwas macht, und sei es, einen Stecker zu ziehen und wieder reinzustecken oder einen Rechner neu zu booten. All das kann ich beim Produkt nicht. Das Produkt verlässt die Tür und ist meistens nicht mehr adressierbar, es sei denn, man macht das übers Internet. Das ist völlig anders. Wir haben dann einige Produkte entwickelt in der Zeit von 2016 bis 2020 und haben das ein bisschen so gemacht, wie IBM in den 60er-Jahren Computer gebaut hat: Wir haben uns irgendeine Hardware ausgesucht, die wir gut fanden, haben damit Prototypen aufgebaut, kleine Schaltungen gebaut. Dann kam jemand und hat Software dafür entwickelt. Dann haben wir getestet und Erfahrungen gesammelt, haben gemerkt, das passt nicht, und haben es neu gemacht. Das war sehr aufwendig, sehr langsam in der Entwicklung und auch sehr teuer. Meistens gab es auch Probleme, die wir nicht lösen konnten, wo wir dem Kunden sagen mussten: Wir müssen das hier anders machen. Dann kam das Jahr 2020, das ist einigen vielleicht noch in Erinnerung: Corona. Alle unsere Industrieprojekte waren innerhalb von drei Wochen beendet, weil man erst mal schauen musste, was überhaupt passiert. Wir haben uns damals entschlossen, mit den Entwicklerteams, die sich um IoT gekümmert haben, zu sagen: Wir hören jetzt nicht auf damit, weil das irgendwann wiederkommt. Aber denkt bitte das ganze Thema neu, wie ihr IoT für Industriekunden auf der Produktseite machen wollt. Das war der Wendepunkt, wo unsere Produkte anfingen zu funktionieren. Mirko, du kamst ungefähr zu dem Zeitpunkt dazu. Wir haben im Bereich Zugbremssysteme einen großen Kunden, die Firma Knorr-Bremse. Mit denen entwickeln wir den digitalen Güterzug für die Anwendung in Europa. Wir haben als Kunden einen Weltmarktführer im Bereich Zugbremssysteme, und mit dem zusammen haben wir die Entwicklung des digitalen Güterzugs für Europa begonnen.

Mirko

In dieser Corona-Zeit ist die Idee aufgekommen, auch die Modularisierung in den verschiedenen Produkten einzuführen. Das heißt, wir haben auf der Hardware-Seite verschiedene Komponenten, die wir immer wieder verwenden können, was bei neuen Produkten die Entwicklungszeiten reduziert. Gleichzeitig hatten wir bei dem Kunden wieder die klassischen drei Fragen auf dem Güterwaggon: Wo kriege ich meine Energie her? Wie kriege ich meine Daten raus? Und wie mache ich das System robust, um im Feld zu überleben?

Ihr habt jetzt wirklich eine ganze Reihe super interessanter Themen angesprochen. Zufälligerweise Energiekette: Bei dem Schlagwort hatten wir kürzlich eine Aufnahme mit igus und Dercks Gartenbau. Die machen im Gartenbau im industriellen Maßstab sehr viel mit Energieketten. Diese Entwicklung über Corona ist spannend, dass ihr entschieden habt, weiter zu investieren, die Flaute zu nutzen, um mit neuen Produkten an den Markt zu kommen und etwas auszubauen. Das finde ich sehr stark.

[07:52] Herausforderungen, Potenziale und Status quo – So sieht der Use Case in der Praxis aus

Ihr habt gerade diese drei Probleme angesprochen. Fabriken haben auch eine ganze Reihe anderer Probleme, aber gerade im Kontext OEMs, also Unternehmen, die eigene Produkte unter eigener Marke herstellen, ist das relevant. Wir hatten euer Beispiel Knorr-Bremse aus der Bahnindustrie, die Bremsen für Züge herstellen. Diese drei Probleme würden mich noch mal interessieren. Mirko, was waren die drei genau, und wie seid ihr das angegangen? Habt ihr da eigene Produkte dafür, und was sind die Komplikationen drumherum?

Mirko

Das Problem ist, dass wir mit einem System konfrontiert sind, das nicht immer mit Energie versorgt ist. Wir müssen trotzdem sicherstellen, dass sich dieses System in der Cloud anmelden kann, dass es Daten bereitstellen kann, etwa zur Position: Wo bin ich? Welchen Zustand habe ich gerade? Gleichzeitig sind die Zeiten, in denen es keine externe Energieversorgung gibt, nicht vorherzusehen. Das heißt, wir brauchen ein System, das energieautark ist und Energy aus der Umgebung gewinnen kann. Wir haben uns in dem Fall für Solarzellen und Batteriebetrieb entschieden. Das Datenaussenden ist bei diesen Systemen auch eine besondere Herausforderung, was den letzten Punkt, die Ruggedization des Produkts, mit beinhaltet. Also: Wo kann ich an einem Güterwaggon eine Antenne anbringen, ohne dass sie mir im Betrieb gleich abreißt?

Und gerade die Datenübertragung ist dabei ein wichtiger Punkt. Der Güterwaggon hat ja Energie. Gleichzeitig ist dort Sensorik an der Bremse verbaut, die nicht direkt Energie vom Zug abgreifen kann.

Mirko

Beim Güterwaggon ist die spezielle Herausforderung, dass er keine Energie hat. Die werden nur mit Druckluft beaufschlagt, um die Bremsen zu lösen. Ansonsten ist das System im Prinzip ein Klotz Stahl. Von dem wollen wir aber Daten haben. Das ist die große Herausforderung. Deswegen muss das energieautark funktionieren, wie auf einer einsamen Insel. Die einzige Energiequelle, die wir da richtig anzapfen können, ist die Sonne, um die Batterien nachzuladen. Wir hatten auch Ideen über den Fahrtwind mit kleinen Turbinen oder aus der Druckluftleitung etwas zu nehmen. Das ist entweder mechanisch zu kompliziert, zu unzuverlässig, oder die Energiemengen haben nicht gereicht. Das ist auch ein klassisches Startproblem: Der Kunde kommt mit einer Idee und wir müssen erst mal schauen, was machbar ist. Das sind oft viele kleine Vorstudien, die dazu führen, dass man sich auf die tatsächlichen Anforderungen einspielt und sagt: So machen wir es, und wir bauen den ersten Prototypen jetzt auf, basierend auf diesen Überlegungen.

Super. Energy können wir abhaken, verstanden. Solar habt ihr gewählt, und das muss man je Einsatz entsprechend analysieren, was möglich ist. Man kann das übertragen: auf Bagger, auf Autos, auf OEM-Themen allgemein, also Flotten im Feld, Baumaschinen jeder Art. Hier haben wir das Beispiel Bremsen an Zügen ganz konkret. Wie habt ihr denn die Datenübertragung gelöst?

Tobias

Es ist erst einmal so, dass wir hier eine sicherheitskritische Applikation haben, denn wir führen einen sogenannten Bremstest durch. Der wird heute manuell durchgeführt. Das funktioniert so: Der Lokführer zieht die Bremsen an, läuft an der einen Seite des Zuges entlang, testet die Anzahl der Bremsen, die angezogen sind, vermerkt die auf einem Blatt Papier, geht auf der anderen Seite zurück und macht das Gleiche. Anschließend löst er die Bremsen und schaut, dass alle Bremsen wieder gelöst sind. Dass alle Bremsen festgezogen sind, muss nicht sein. Es reicht, wenn eine gewisse Anzahl von Bremsen festgezogen ist, weil er anhand dieser Anzahl und des Gewichts des Zuges seinen Bremsweg ausrechnen kann. Anhand dieses Bremsweges kann er seine Maximalgeschwindigkeit bestimmen. Es muss sicher sein, dass er, wenn er ein Vorsignal sieht, bis zum Hauptsignal zum Stehen kommt. So ein Test dauert, wenn der Lokführer schnell unterwegs ist, 90 Minuten. In dieser Zeit ist das Gleis blockiert. Was wir jetzt machen, zusammen mit dem Hersteller, ist, dass wir einen digitalen Bremstest etablieren. Das heißt, statt dass ein Mensch dort entlangläuft, macht das eine Elektronik. Ziel ist, diesen Bremstest innerhalb von vier Minuten abzuschließen. Andererseits ist es eine sicherheitskritische Anwendung. Es gibt Safety Integrity Level, die verschiedene Sicherheitslevel definieren. In dem Fall ist es SIL Level 2. Das ist schon relativ anspruchsvoll. Da gehen gewisse Dinge nicht. Was zum Beispiel nicht geht, ist eine direkte Cloud-Verbindung. Ich brauche also eine Vernetzung von Waggon zu Waggon. Das ist gar nicht so einfach, weil relativ viel Metall im Spiel ist, und es muss auch eine sichere Funkverbindung sein. Sie darf nicht unterbrechen, sonst funktioniert der Bremstest nicht. Wir haben zwei Vernetzungen. Wir haben eine Funkvernetzung von Waggon zu Waggon. Da benutzen wir eine Eigenentwicklung aus unserem Haus, aus unserem IoT-Baukasten, wie wir ihn nennen. Wir haben verschiedene funktionale Module, die wir in der Vergangenheit erprobt haben. Wenn wir eine Anwendung haben, können wir ein Modul aus diesem Baukasten nehmen und schauen, ob es passt. Wir müssen aber keine Software und keine Hardware von Grund auf entwickeln, weil wir das schon getan haben. In dem Fall haben wir uns für ein sogenanntes ISM-Netz im Sub-Gigahertz-Bereich entschieden, mit dem wir von Waggon zu Waggon bis in die Lokomotive funken. Das ist die sogenannte Zugvernetzung. Die muss immer funktionieren, damit ich den Bremstest machen kann. Den muss ich auch machen können, wenn der Zug zum Beispiel in einem Tunnel steht und die einzelnen Waggons überhaupt keine LTE-Verbindung haben, um eine Cloud-Kommunikation aufzubauen. Darüber hinaus haben wir die Anforderung, dass so ein Waggon für Firmware-Upgrades, Positionsübermittlungen und andere Dinge auch in der Cloud zur Verfügung steht. Dafür haben wir ein klassisches LTE-Modem in den Waggons. Das wird aber nur zeitweise benutzt, weil LTE relativ energiehungrig ist. Wenn ich mit Solarzellen arbeite, kann ich das nicht dauerhaft tun. Es ist trotzdem wichtig, diese Verbindung zu haben, weil der Hersteller so einen Waggon im Schnitt alle sieben Jahre sieht. Wenn ich innerhalb dieser sieben Jahre etwas machen will, ist er irgendwo in Europa unterwegs. Wir haben sogenannte Pioneer-Trains, also Züge, die vorab fahren, um diese Technologie auszuprobieren.

Mirko

Das Gute ist: Einer steht in Berlin-Spandau, nicht weit von uns entfernt. Man fährt eine Dreiviertelstunde mit dem Auto hin und kommt an seine Hardware ran. Aber wenn man dann davorsteht, sieht man: Was ich das letzte Mal festgeschraubt habe, ist mit zwei Zentimetern Sand bedeckt, und die Schrauben sehen ganz anders aus, als ich sie dagelassen habe. Das ist ein klassischer Engineering-Fall: Man überlegt sich schnell eine Lösung. Wir haben jetzt kleine 3D-gedruckte Abdeckkappen, die wir immer draufmachen, damit wir schneller rankommen. Dann muss man es nicht mit Druckluft freiblasen und hat weniger Probleme. Das Schöne ist, dass die Entwicklung super schnell weitergeht. Man kommt dran, man kann eine neue Iteration der Hardware schnell zum Kunden bringen. Wir haben die erste Stufe neulich erfolgreich abgeschlossen, mit einem Bremstest, bei dem sowohl der Kunde, der Hersteller, als auch der Carrier dabei waren. Das ist immer ein aufregender Moment und natürlich ein großes Erfolgserlebnis. Man sieht: Es hat geklappt. Es funktioniert so, wie sie sich das vorgestellt haben.

Das hört sich wirklich gut an. Ich hatte auch schon öfter gehört, dass man teilweise, gerade wenn man so viele Assets im Feld hat wie diese Waggons, Waggons verliert. Das kann man sich kaum vorstellen. So klein sind die ja nicht.

Tobias

Da sind auf einmal 40 Tonnen weg.

Genau. Und dann mit IoT zu arbeiten, auch in Kombination mit dem Bremstest, mit dem digitalen Bremstest, finde ich sehr stark und anschaulich. Ihr habt angesprochen, ihr habt einen Baukasten, modular aufgebaut. Wie ist der Baukasten zustande gekommen? Welche Fächer gibt es da, aus denen man greifen kann? Wie habt ihr den strukturiert?

Tobias

Der Baukasten ist ein Bestandteil unseres Ökosystems. Es heißt L.IoT. Dieses Ökosystem kümmert sich um verschiedene Aspekte von industriellem IoT. Grundsätzlich sind wir der Auffassung, dass man das Thema nur erfolgreich behandeln kann, wenn man sowohl auf der Hardware- als auch auf der Softwareseite unterwegs ist. Man kann das schwer voneinander isolieren. Wenn ich auf das Edge Device schaue, also auf das physikalische Device, dann habe ich dort einen eher hardwarelastigen Baukasten. Wenn ich sage, eine der Schwierigkeiten ist es, mit Energie zu haushalten und Energie erst mal zu gewinnen, dann sind dort Technologien drin zum Konvertieren von Energien, zum Beispiel Harvesting aus Solarzellen und aus anderen Technologien. Dort sind Technologien drin zum Speichern von Energien über Batteriesysteme. Bei Batterien ist immer die Frage des Temperaturbereichs. Ich habe auch Batterien, die bei minus 30 Grad noch laden können. Auf der Seite der Funkübertragung habe ich viele Module, die relativ einfach sind, wie BLE, Bluetooth Low Energy. Das wird häufig genutzt, um ein Device mit einem Smartphone zu konfigurieren. Das ist ein typischer Use Case. Ich habe ein Device, das wird installiert, zum Beispiel auf einem Güterwaggon. In Europa gibt es ungefähr 600.000 Güterwaggons. Da muss eine ganze Menge retrofit in bestehende Waggons installiert werden. Dann muss ich das irgendwie konfigurieren. Das mache ich mit einer mobilen App, das mache ich mit BLE auf der Device-Seite. Das kann ich jedes Mal von Grund auf entwickeln. Wenn ich aber die Konnektoren auf der mobilen App und die gesamte Bluetooth-Logik für das Device schon habe, dann nehme ich das bei uns aus dem Baukasten, verbaue es auf der Platine, lade die Software, und der Kunde, der das Ganze sozusagen entwickelt, kann sich auf das konzentrieren, was eigentlich der Inhalt ist: das, was wir Customer Business Application nennen, also die eigentliche Business-Funktion, die ausgeführt wird. Das ist im Prinzip egal, ob es das Beispiel im Güterverkehr ist oder ob man unsere Technologie in Hydraulikbaggern eines führenden deutschen Herstellers findet. Wir sind im Oil-and-Gas-Bereich bei der Raffinerieüberwachung. Da geht es um Unfallverhütung. Es sind ganz verschiedene Areale. Grundsätzlich ist es so: Der Kunde möchte eigentlich immer diese Customer Business Application schreiben, weil das der Mehrwert ist. Er muss aber ein Device entwickeln, Hardware entwickeln, Device-Treiber-Software entwickeln. Er muss es testen, robust machen, produzieren, also in großen Stückzahlen kostengünstig herstellen, weil die Business Cases meistens sehr schmal geschnitten sind. Und er muss das Ganze über den Lebenszyklus verwalten. Genau da greift unser Ökosystem ein. Softwareverteilung an ein Device, sicher: Das hatten wir in jeder Anwendung, und das haben wir generalisiert, in den Baukasten eingebaut und in das Ökosystem eingebaut, sodass Kunden sich wirklich auf die Customer Business Application konzentrieren können. Das heißt: Ich habe hardwarenahe Bausteine, die mir helfen, das Edge-System aufzubauen. Ich habe aber auch Software-Bausteine, die mir helfen, das Gesamtsystem zu warten und über die Zeit zu pflegen.

Das hört sich sehr umfangreich an. Kannst du noch mal die Grenzen aufzeigen? Es ist zwar schön, wenn man sagt, man kann alles, aber wo liegen eure Schwerpunkte, und wo gibt es Grenzen, wo ihr euch abgrenzt? Ich habe verstanden: OEM ist euer Schwerpunkt.

Tobias

Aus unserer Sicht ist es wesentlich komplizierter, ein Produkt zu digitalisieren, als einen Prozess zu digitalisieren. Die Schwierigkeit ist, dass es sehr viel Arbeit ist, so etwas für ein Produkt zu machen. Mit dem Ökosystem ist es teils skalierbar. Alles, was skalierbar, lizenzierbar und vereinfachbar ist, haben wir gemacht. Wir sind noch nicht ganz am Ende, aber das ist der Bereich, wo wir uns sehen. Eine der Schwierigkeiten ist, dass die Lebensdauer eines industriellen IoT-Produkts wesentlich länger ist als die Entwicklung in IoT, Elektronik und Informationstechnologie. Ein Hydraulikbagger hat 20 Jahre Lebensdauer im Feld. Wenn wir 20 Jahre zurückgucken: Was haben wir mit IoT vor 20 Jahren gemacht? Nicht sehr viel. Die Frage ist: Was mache ich in 20 Jahren? Aus unserer Sicht ist wichtig, dass sich das Verwaltungssystem in die Zukunft fortführen kann. So kamen wir zum Beispiel zu der Idee: Wir haben ein Edge Device, da läuft ein Betriebssystem, ein Linux. Ubuntu Core oder Yocto oder Red Hat oder Debian. Das möchte ich vielleicht wechseln, weil ich irgendwann in fünf oder zehn Jahren sage: Die Entwicklung lief anders als prognostiziert. Solche Dinge müssen möglich sein, weil man sonst heute viel zu viel Zeit darauf verwendet zu überlegen, was das ideale Edge-Betriebssystem ist. Da gibt es riesige Diskussionen. Wir sagen: Egal, was es heute ist, morgen ist es etwas anderes, und es ist zu viel Aufwand an der falschen Stelle, sich darauf zu versteifen. Dann gibt es Kunden, die existierende Devices haben. Diese Devices sind vielleicht schon zehn oder fünfzehn Jahre alt. Das sind IoT-Devices, die wurden in einer sehr frühen Phase verbaut. Es gibt Hersteller, die machen das seit 30 oder 40 Jahren. Da ist die Frage: Wie kann ich die mit einer neuen Verwaltungssoftware, mit einem L.IoT-System, dennoch integrieren? Da gibt es häufig Grenzen. Dann müssen wir sagen: Es geht ein Stück weit, aber nicht alles. Wir versuchen so weit wie möglich zu erfassen und möglich zu machen, aber wenn die Hardware oder die Verbindung es nicht hergibt, können wir das auch nicht. Das sind Bereiche, wo wir mit dem Kunden reden müssen und einen Kompromiss finden.

Mirko

Kunden kommen häufig mit komplexen Problemen zu uns oder mit integrierten Lösungen: Temperaturmessung plus Schalterüberwachung plus Ortsbestimmung und dann noch Datenanbindung. Oder sie haben spezielle Rahmenanforderungen, etwa ATEX-Zertifizierung im Raffinerieumfeld, oder besondere Shock-and-Vibration-Anforderungen, auch bei Güterwaggons. Unsere Batterien wurden da sehr starken Härtetests unterzogen. Solche Sachen, wo Off-the-shelf-Lösungen aus dem IoT-Bereich nicht mehr passen.

Ich finde schon beeindruckend, dass ihr diese Breite abdeckt, von Softwarebausteinen bis hin zu Hardware. Hardware wäre noch mal ein Bereich, der mich interessiert. Ihr bietet bis hin zur Serienfertigung von Hardware-Komponenten an. Mirko, kannst du kurz sagen, wie ihr diese Hardware-Journey mit dem Kunden gemeinsam macht?

Mirko

Ganz am Anfang steht die Idee und die Anforderung vom Kunden und der Blick in unsere Toolbox, gemeinsam mit dem Kunden: Welche Elemente haben wir schon? Wenn wir einen Großteil davon abdecken können, wissen wir, dass die Entwicklung sehr schnell vorangehen wird. Wir scheuen aber auch nicht davor zurück, neue Sachen zu integrieren, mit dem Hintergrund, dass Entwicklungszeit und Kosten damit verbunden sind. Das ist der Startpunkt, an dem dann in meinem Team die verschiedenen Bereiche zusammenarbeiten. Es gibt klassisches Engineering: analoge Schaltungsentwicklung, die man immer hat. Man muss eine Betriebsspannung bereitstellen, man hat vielleicht analoge Eingänge, um die man sich kümmern muss. Dann die digitale Seite: Prozessorauswahl, digitale Schaltungstechnik, und das Thema Daten raussenden. Wir haben immer Antennen, die man nach bestem Wissen und Gewissen auslegt. Der spannende Moment ist, wenn wir zum ersten Prototyp kommen und anfangen, unsere Tests darauf zu machen: Welche Reichweiten erreichen wir? Wo kann man nachjustieren? Wir haben Equipment, um Antennen zu messen. Und dann: Wie funktioniert es wirklich im Feld? Viele Vortests können wir selbst durchführen. Am Ende kommt immer noch ein Schritt, dass es zu einem zertifizierten Prüfinstitut geht, oder unsere Kunden haben selbst Prüfstände und Versuchsstände. Im Bahnbereich ist der Shaker-Test für mich immer ein sehr beeindruckender Test. Die Normen geben klar vor: Ihr müsst diese Beschleunigungswerte über so viele Zyklen und Zeitabläufe durchlaufen, und die Hardware muss durchgeschüttelt werden und darf nicht ausfallen. Man sitzt dann gespannt daneben, häufig beim Kunden, und schaut: Kommen die Daten noch rein? Kommen die Daten noch rein? Das ist ein toller Moment zu sehen, wie das Produkt hart getestet wird. Das sind Anforderungen, die oft ausschließen, dass man einfach Hardware nimmt, die schon im Markt existiert. Diese Fülle an Anforderungen in einem Packaging und gleichzeitig diese rauen Umgebungen und Normen, die eingehalten werden müssen: Dass das aus einer Hand kommt und bereitgestellt wird.

Was mich dringend interessieren würde: das Geschäftsmodell dahinter. Ihr baut mit dem Kunden die Hardware und auch die Softwarepakete. Was ihr nicht macht, wie ich verstanden habe: Software as a Service, wo viele versuchen, den Kunden in ein Login zu kriegen, sodass er regelmäßig zahlt, Monthly Recurring Revenue und Ähnliches. Tobias, wie ist euer Geschäftsmodell? Wie geht ihr das an?

Tobias

Wir machen das aus Kundenperspektive am Wert der Assets fest. Wenn wir zum Beispiel einen Hydraulikbagger nehmen: Da sind wir verbaut, da gibt es unsere Technologie, da gibt es einen Hersteller, der mehrere tausend dieser Hydraulikbagger baut, und die sind 20 Jahre im Feld. 20 Jahre ist ein normaler Zeitraum. Ein Güterwaggon ist auch 40 Jahre im Feld. Die Anzahl dieser Geräte im Feld ist das, was wir den Asset Value nennen. Ich habe eine Flotte im Feld und die hat einen gewissen Wert. Dieser Wert ist häufig im ein-, teilweise auch im zweistelligen Milliardenbereich. Wenn ich jetzt sage, ich muss dieses Produkt digitalisieren und mit neuen Features ausrüsten, dann ist der digitale Betrieb ein großes Risiko. Eine Sache darf nicht passieren: Nach zehn Jahren darf das nicht ausfallen, wenn es für 20 Jahre Betrieb ausgelegt ist. Hier sind wir an einem Punkt, wo klassische SaaS-Provider das nicht liefern können, weil sie nicht sagen können: Wir bieten unseren Service für 20 Jahre an. In 20 Jahren machen die vielleicht etwas völlig anderes. Das heißt, die digitale Eigenständigkeit des Kunden ist sehr wichtig. Das bezieht sich auf den Betrieb der Systeme, aber auch auf politische Rahmenverhältnisse. Wenn ich ein digitales Produkt habe und es erzeugt digitalen Mehrwert, den ich für Produktentwicklung oder Kundenservices nutze, möchte ich sicherstellen, dass diese Daten bei mir bleiben. Eine gewisse Skepsis gegenüber außereuropäischen Anbietern ist angebracht. Das ändert sich auch politisch. Vor drei, vier, fünf Jahren hätten wir vielleicht gesagt: Amerika, das ist eine Bank, da kann man alles machen. Mittlerweile denken einige anders darüber. Politische Systeme ändern sich, Technologien ändern sich, und die wirtschaftliche Ausrichtung der Anbieter ändert sich. Wenn ich das alles zusammenzähle, bleibt für einen Kunden mit Assets mit hohem Wert und einer Verpflichtung gegenüber seinen Kunden eigentlich keine Alternative, als das Ganze selbst zu betreiben. L.IoT ist kein SaaS-System. Man kann das als SaaS benutzen, um auszuprobieren, wie es funktioniert, oder in der frühen Produktentwicklung, wenn man es einfach halten möchte. Aber es gibt den Punkt, wo Werte dahinterstehen, die damit gesteuert werden. Dann muss ich sagen: Ich brauche das selbst. Wir verstehen das und unterstützen es. Wir versuchen unsere Kunden nicht mit Mietmodellen oder Software as a Service in Abhängigkeiten zu zwängen. Darin unterscheiden wir uns von vielen Marktmitbegleitern. Wir sagen: Der Kunde muss Datensouveränität und Systemsouveränität haben. Was wir machen, ist natürlich Softwarewartung und Service, wenn es Fragen gibt. Aber grundsätzlich muss ein Kunde in der Lage sein, dieses System selbst zu betreiben. Denn die digitale Zukunft ist auch ein Teil der digitalen Souveränität. Und wenn ich ein System oder ein Produkt digital entwickle, muss ich morgen noch Eigentümer der Intellectual Property des Produktes bleiben. Das wollen wir sicherstellen.

Sehr spannend, weil das für jeden OEM-Hersteller ein Thema ist, und auch dieser Ausblick und die Anforderungen, das über Jahre und Jahrzehnte zuverlässig im Feld zu halten. Vielen Dank für diese Eindrücke. Habt ihr zum Schluss noch etwas, das ihr den Zuhörerinnen und Zuhörern mitgeben wollt? Was ist aus eurer Sicht wichtig auf so einer Digitalisierungsreise? Was sollte man beachten?

Mirko

Ich habe noch einen Zusatz zu dem, was Tobias gerade gesagt hat. Das gilt nicht nur für die Softwareseite, sondern auch für die Hardwareseite. Diese Strategie fahren wir auch. Wenn der Kunde möchte und wir aus der Entwicklungsphase raus sind und er sagt: Die Serienproduktion stellen wir uns woanders vor oder wir haben ein eigenes Werk, wo wir das machen, dann geben wir nach unseren Vertraglichkeiten auch die Schaltpläne und die komplett entwickelte Hardware heraus, sodass er sie, wenn er möchte, woanders nachbauen kann. Gleichzeitig bieten wir die Serienfertigung auch in-house an. Der Benefit für uns ist: Wir haben das Wissen aus der Entwicklung, das wir in die Serienproduktion mitnehmen können. Wenn es Troubleshooting gibt, sind wir vermutlich schneller als andere.

Sehr gut. Tobias.

Tobias

Nach mittlerweile einer ganzen Reihe Produkte, die wir erfolgreich entwickelt haben, und sicherlich auch einigen, die wir nicht erfolgreich entwickeln konnten, kristallisiert sich für mich heraus: Wenn man die Idee hat, ein Produkt zu digitalisieren, sollte man sich nicht zu sehr von technischen, softwaretechnischen oder hardwaretechnischen Dingen leiten lassen, sondern in erster Linie schauen: Wo kann ich einen Mehrwert bieten? Wo kann ich mein Produkt modernisieren? Wo kann ich es digitalisieren? Man sollte sich dann auf das konzentrieren, was wir Customer Business Application nennen, also auf den Mehrwert. Wir sehen häufig ausschweifende Diskussionen darüber, welches Betriebssystem, welcher Cloud Provider, welche Art, Systeme im Netz zu verwalten, wie man Software transferiert. Ab 2027 gibt es den Cyber Resilience Act, das heißt, Cyber Security bei IoT-Devices wird noch einmal komplexer. Man kann sehr viel Zeit und Geld ausgeben, sich diesen Themen zu widmen. Leider bezahlt das am Ende keiner wirklich. Ein Endkunde, der das Produkt kauft, erwartet, wie bei seinem iOS- oder Android-Smartphone, dass er einfach eine Software lädt und dann läuft das. Das ist die Kundenerwartung. Darauf sollte man sich konzentrieren. Das Schöne ist, dass es mittlerweile Systeme gibt, die einem die Handarbeit, also die gesamte Mechanik, abnehmen. Das ist ein großer Vorteil für Industrial IoT, weil wir uns auf das Wesentliche konzentrieren können und Kunden schnell und effizient ihre digitalen Produkte entwickeln und in den Markt bringen können.

Vielen Dank für diese interessanten Einblicke in IoT und insbesondere dieses flottengestützte IoT. Danke an alle Zuhörerinnen und Zuhörer, dass ihr uns begleitet habt, und bis zum nächsten Mal.