CRA-konformes Update- und Device-Management: selbst bauen oder einkaufen?

Madeleine:

Hallo liebe Freunde des IoT und willkommen im IoT Use Case Podcast, euer Kanal für die Umsetzung von IoT in der Praxis. Ich bin euer Host, Madeleine Mickeleit, studierte Maschinenbauingenieurin, und diese Folge möchte ich euch wirklich allen ans Herz legen, vor allem denen, die Hersteller in der EU sind, und allen, die mit den Herstellern arbeiten oder bei ihnen einkaufen. Denn seit September 2026 gilt etwas, das viele auf dem Schirm haben, noch nicht alle: der Cyber Resilience Act, kurz CRA.

Darüber sprechen wir heute, aber es heißt für euch vor allem ganz praktisch: Ihr müsst die Software eurer Geräte auch nach dem Verkauf einfach aktuell und sicher halten im Feld, auch bei vielen Geräten über Jahre. Und genau darum geht es heute: wie man dieses Update und Device Management löst und wie ich eben diese Geräte im Feld pflege, ohne bei jedem Gerät irgendwie einzeln vorbeizufahren. Im Endeffekt klären wir heute drei Dinge: Was muss ich tun? Wie mache ich das jetzt? Und worauf muss ich aufpassen, wo meine Kosten richtig explodieren können?

Dazu machen wir heute auch eine spannende Business-Case-Return-on-Investment-Rechnung auf, gehen aber auch in die technische Umsetzung, und wir beantworten natürlich die Community-Fragen, die mich erreicht haben. Ja, und dazu habe ich zwei spannende Gäste mit dabei. Wer das ist, das erfahrt ihr jetzt. Alle Infos zur Umsetzung solcher und ähnlicher Projekte findet ihr wie immer unter www.iotusecase.com und in den Show Notes. Let's go!

Hallo lieber Yves, hallo Marvin. Wie geht's denn euch heute? Yves, ich fang mal bei dir an.

Yves:

Hi, mir geht's gut. Ich bin sehr froh, dass ich hier sein kann, da es mein erster Podcast ist, den ich mache. Und ich bin mal gespannt, wie wir hier so durchkommen.

Madeleine:

Wie wir durchkommen. Ja, sehr schön. Wo erreiche ich dich gerade? Wo bist du?

Yves:

Ja, ich bin im Homeoffice in Nierstein, in der Nähe von Mainz, und nicht weit von unserer Firma entfernt, die ist in Mainz positioniert.

Madeleine:

Okay, cool. Ja, dann viele Grüße aus Mainz, aus der Region Frankfurt, und für alle, die jetzt zuhören. Genau, also du bist ja Diplom-Ingenieur und seit vielen Jahren bei der PHYTEC Messtechnik GmbH, heute als Head of Product Management. Vielleicht können wir mal ganz kurz zu deiner Motivation sprechen: Was macht es so spannend, hier in der Produktentwicklung bei euch zu arbeiten? Hast du da ein persönliches Interesse dran oder auch eine persönliche Motivation? Was hält dich in diesem Bereich?

Yves:

Na ja gut, als Ingenieur bin ich natürlich begeistert von Technologie, mache privat natürlich auch viel in dem Bereich und finde das immer wieder spannend, wie sich die Technologie weiterentwickelt. Jetzt revolutionäre Dinge wie KI und ja auch IoT davor waren immer Bewegungen, die mich natürlich begeistert haben. Und dann als Ingenieur sucht man nach Lösungen für Probleme, und Probleme haben wir immer, und die Lösungen, die fallen einem dann schon irgendwie ein, wenn man guckt, was man für Werkzeug –

Madeleine:

Fallen dann ein. Ja, schön. Das ist doch toll. Vielleicht zur PHYTEC: Für die, die euch noch nicht kennen – du hast ja gerade gesagt, ihr kommt aus Mainz. Ihr liefert so Embedded-Module mit Prozessor und allem drum herum, was da irgendwie zu einem lauffähigen System gehört. Wenn ich es so richtig verstanden habe, bauen eure Kunden daraus ja ihr Endsystem, und dein Team verantwortet im Endeffekt alles, was irgendwie dann für attraktive Produkte gebraucht wird, inklusive Software und jetzt eben auch solche Themen wie, aufkommend, Cyber Resilience Act. Du bist aber jetzt hier als Experte auch für Security-Pflege-Management dieser vernetzten Geräte ja unterwegs.

Kannst du mal so ein bisschen beschreiben: Embedded-Module? Für mich ist das immer so – ja, ich sage immer so blöd: Du hast ja eine Platine, und dann ist es im Endeffekt bestückt mit bestimmten Dingen, und das ist ja ein Modul, was dann [vermutlich: „bestimmte“] Aufgaben übernimmt in einem größeren Gerät oder System. Kannst du mal so ein bisschen beschreiben, wie hier so euer Markt ist – habe ich das gerade richtig gesagt? Und wer sind eure Kunden? Das würde mich nochmal interessieren zu Beginn.

Yves:

Die Idee von so einem Modul, also so einen Prozessor, damals noch Mikroprozessoren, auf so eine Platine zu setzen und da die Peripherie drum herum zu machen, ist im Prinzip vor über 30 Jahren vom Gründer der Firma gekommen. Zu sagen: Na ja, wenn man so ein Design macht von so einem Mikroprozessorsystem oder so einem Embedded-System, dann braucht man immer ein gewisses Set an Komponenten, die miteinander zusammenspielen. Das Design ist relativ komplex, und warum kapselt man das nicht auf so einem Modul?

Und sagt: Wenn ich den Prozessor habe, brauche ich auch Speicher dran, und zum Beispiel RAM-Interface, da sind die sehr schnell, das heißt, das Routing ist komplex. Und so einen gewissen Satz an Peripherie braucht eigentlich immer jeder, [vermutlich: „meinetwegen Ethernet-PHY“] und so was. Und dann werden die Signale von diesem Modul im Prinzip so runtergeführt und werden dann nutzbar auf einer Platine, die man selber designen kann – oder wir machen das auch für die Kunden –, wo dann die einzelnen Features von dem Prozessor tatsächlich dann physikalisch noch endausgebaut werden, sodass dann die entsprechenden Schnittstellen da sind. Und das ist so die Grundidee von so einem Modul.

Und das Ganze ist halt so generisch, dass die Zielmärkte beliebig sind. Also es kann ein Fahrkartenautomat am Bahnhof sein oder so was mit Display und Tastatur oder Touch und Druckwerk für Quittungen, oder es kann auch einfach ein Medizingerät sein, Ultraschall oder was auch immer – überall, wo irgendwie gesteuert und geregelt werden muss. Wir haben sehr viele Kunden auch in der Industrie, also in der produzierenden Industrie, Automatisierung und solche Sachen. Es ist alles möglich mit diesen –

Madeleine:

Also branchenquerbeet, was ihr da auch habt. Und jetzt mal die Frage: Was habt ihr denn mit IoT zu tun? Weil im Endeffekt könnte man ja sagen, okay, euer Gerät wird ja quasi verbaut. Wie du schon sagst, es ist dann ein Fahrkartenautomat oder irgendwie so ein Medizingerät. Wo kommt jetzt hier IoT zum Tragen bei euch? Oder sagen wir mal: das Vernetzen des Geräts oder des Prozessors.

Yves:

Oft sind die Geräte ja vernetzt. Es gibt ja mittlerweile kaum noch Geräte, die nicht vernetzt sind. Kann man sich beliebig vorstellen: Selbst der Fahrkartenautomat wird irgendwann mal seine Geldwertdaten irgendwo hinschicken wollen, weil nicht jeder auch immer, wie du sagst, mit dem Turnschuh-Update irgendwo da dran gehen will mit dem USB-Stick und die Geldwertdaten auslesen will. Zum Beispiel auch – wir haben sehr viele Kunden mit EV-Charging-Stationen oder so was, die werden ja auch ferngesteuert. Und da ist natürlich auch wichtig, dass eine sichere Verbindung besteht.

Madeleine:

Ja, okay. Ja, ich meinte halt auch, weil man könnte ja sagen: Klar, dass der Fahrkartenautomat vernetzt wird. Ja, aber was habt ihr damit zu tun als Embedded-Modulhersteller? Weißt du, was ich meine? Weil ihr quasi das Modul [vermutlich: „liefert“]. Man könnte ja sagen, da hört es dann auf. Weißt du, was ich meine?

Yves:

Ja, nee, aber das ist grundsätzlich eigentlich auch nicht unsere Philosophie. Wir sagen zwar, der Kern ist immer gleich, und das skaliert natürlich auch, und wir können das sehr günstig produzieren im Verhältnis oder entwickeln im Verhältnis zu jemandem, der das in kleinen Stückzahlen macht. Machen wir das halt für viele Kunden. Aber wir können dadurch natürlich auch noch mehr Wert generieren obendrauf. Das heißt, wir haben ein Betriebssystem, was dort drauf ist. Jetzt für den CRA ist das Betriebssystem dann auch entsprechend gepflegt mit Schwachstellenmanagement, also CVE-Monitoring, und entsprechend dann auch LTS-Streams, also kontinuierlich gepflegte Softwarestände, die man im Feld immer wieder ausrollen kann, um Vulnerabilities zu reduzieren oder loszuwerden.

Ja, und wir gucken im Prinzip immer: Was brauchen viele Kunden, und wo können wir irgendwo Vorleistungen generieren? Also das fängt mit dem Modul an, da ist immer der gleiche Kern, aber auch in der Software ist das gleich gedacht. Also jeder braucht ein Betriebssystem, ein Linux, und das Betriebssystem muss im Prinzip gewisse Grundfunktionen haben und Spezialfunktionen. Das ist dann individuell, kundenspezifisch, da können wir nicht für alle immer alles fertig machen, was geht.

Madeleine:

Mehrwerte generieren, und eben du hast es angesprochen: also ein CVE-Monitoring, auch die Softwarestände, die kontrolliert werden müssen. Ich glaube, da sprechen wir gleich zu, und Marvin, da kommt ja ihr ins Spiel und auch du persönlich in diesem Projekt. Vielleicht ganz kurz zu dir, Marvin. Marvin König, heute du, glaube ich, ne? Ja, genau, du bist COO bei der ML!PA, kommst hier aus der Wirtschaftsinformatik, du bist mit einem dualen Studium bei der Telekom gestartet, warst hier schon auch im Studium in der IT-Beratung unterwegs und bist seit 2018 bei der ML!PA, heute als stellvertretender Geschäftsführer. Verantwortest strategisch den Produktbereich – für welchen genau, da kommen wir gleich zu. Kannst du mal so ein bisschen was noch ausführen zu dir, deiner Rolle und ja auch zu ML!PA ganz kurz, damit man auch gerade das Zusammenspiel jetzt versteht, wie ihr jetzt mit der PHYTEC hier arbeitet als Kunde?

Marvin:

Wie du richtig gesagt hast, habe ich einen Hintergrund in der Wirtschaftsinformatik und habe im Endeffekt meinen Werdegang hier bei der ML!PA auch genauso begonnen. Das heißt, erst mal sehr viel im Projektgeschäft gearbeitet. Wir kommen traditionell mehr aus dem Projektgeschäft, haben also cross-funktional IoT-Lösungen entwickelt. Das bedeutet wirklich Hardware-Entwicklung hier bei uns, Embedded-Entwicklung, aber auch Cloud-Programmierung. Also wir haben für unsere Kunden wirklich versucht, das komplette Produkt Ende zu Ende abbilden zu können.

Und bei Kunden sprechen wir da zum Beispiel von dem Bahnsektor als einem Bereich, aber auch vom Baumaschinensektor, von der Bauindustrie generell, wo wir Lösungen gemeinsam mit unseren Kunden entwickelt haben. Und dabei haben wir im Laufe der Zeit einfach mehr und mehr, sage ich mal, Module entwickelt für wiederkehrende Probleme. Also versucht, diese Probleme, diese Lösungen dafür zu standardisieren und dann für unsere Kunden einzusetzen.

Madeleine:

Ganz kurz nur zur Einordnung vielleicht für die, die euch noch nicht kennen. Also ML!PA, ihr habt ja im Namen auch den – ML!PA Consulting GmbH. Würdest du euch jetzt hier auch klassisch als – also genau, das Wort Consulting geht jetzt erst mal sehr stark in Beratung. Ihr macht aber ja sehr viel mehr. Also ihr seid ja auch Systemintegrator beziehungsweise bietet hier individuell auch Hilfe an, habt aber auch eigene Produkte. Kannst du mal so ganz kurz auch nochmal die Firma einordnen, nur für die, die euch jetzt noch nicht kennen, dass sie das kurz einmal auf dem Schirm haben?

Marvin:

Genau, das ist unser Werdegang. Wir sind historisch stärker und stärker gewachsen. Wir kommen klassisch viel aus dem Consultingbereich. Wir sind aber mehr und mehr zu einer Produkt-Company geworden, die wir auch mittlerweile sind. Und das, wie gerade so ein bisschen angeschlossen: aus unseren Projekterfahrungen Probleme standardisiert und mittlerweile, wie du es eingangs gesagt hast, auch in ein Device Lifecycle Management System sozusagen gebunden, was sich dann um Over-the-Air-Updates, was sich um Device Monitoring, Observability, aber auch das Thema Asset Management sozusagen kümmert und die Geräte zentral für unsere Kunden verwalten kann.

Madeleine:

Ihr habt ja jetzt gemeinsam auch an einem Projekt hier gearbeitet, wo raus ja sogar – oder wo auch ein Produkt von euch genutzt wurde. Dazu kommen wir gleich. Könnt ihr mal ganz kurz beschreiben, was dieses gemeinsame Projekt jetzt war? Ihr habt ja jetzt schon beide den gemeinsamen Nenner, CRA, auch genannt. Wie habt ihr euch kennengelernt? Wie habt ihr gestartet?

Yves:

Ja, also wir waren eigentlich auf der Suche nach einer Lösung als Standardlösung. Wie gesagt, wir gucken ja immer, dass wir Lösungen haben für Probleme, die viele Kunden haben. Und der eine ist halt eben das Updaten – Updaten des Geräts, genau. Und wir hatten im Prinzip schon Update-Mechanismen auch in unseren BSP integriert, also so einen Client – RAUC heißt der –, der dafür sorgt, dass das System sicher upgedatet werden kann mit zwei, also mit einer Fallback-Partition, falls was schiefgeht. Und das ist bei uns immer gepflegt im BSP. Ja, aber wir hatten halt keine richtige Gegenstelle, um jetzt zentral irgendwo viele Geräte zu steuern.

Und wir haben uns da natürlich viele Lösungen angeguckt. Es gibt ja auch viele fertige Lösungen. Meistens ist es aber so eine Friss-oder-stirb-Lösung. Das heißt, da kriegt man halt was hingesetzt, einen Server, da sieht man seine Geräte, und dann muss man halt schauen, wie man das verwendet in seinem Use Case. Ich habe aber über die Jahre festgestellt, bei der Suche und auch bei den Gesprächen mit den Kunden, dass die Kunden immer unterschiedliche Settings haben. Also es gibt immer Kunden, die dann eigene Infrastruktur schon haben, zu einem gewissen Teil, und das würden sie gerne anbinden.

Es gibt auch Kunden, die mehrere Projekte in ihrer Firma haben, aber nicht immer PHYTEC-Hardware nehmen, sondern auch selbst entwickeln oder von anderen Modulherstellern. Und deswegen wollten wir halt auch nicht selber irgendeine Lösung bauen, weil dann wäre das so ein Vendor-Lock-in gewesen. Das wollten wir alles nicht. Wir wollten das irgendwie offen haben. Deswegen haben wir einen Partner gesucht. Von den Features her war natürlich die Lösung L-IoT von ML!PA an der Stelle wirklich überzeugend. Das war ziemlich krass, was die da schon alles haben, besonders im Asset Management und so. Da sind die sehr detailliert unterwegs gewesen.

Und der Vorteil ist gewesen für uns, dass ML!PA halt eben auch ein Dienstleister ist, der Anpassungen machen kann. Und das hat sehr gut zu dieser Erkenntnis gepasst, dass die Kunden oft eine Individualanpassung noch brauchen, in gewissem Maß. Also Standardprodukt, ja, aber dann bitte im Detail noch so ein bisschen angepasst. Und das ist halt aus unserer Sicht wichtig und bestätigt sich jetzt auch in der Zusammenarbeit, dass das der richtige Weg zu sein scheint.

Madeleine:

Kannst du mal ganz kurz sagen, wie viele Geräte das typischerweise so sind, nur dass man mal eine Hausnummer hat? Also wenn du jetzt von Fahrkartenautomaten sprichst, das sind ja viele. Wie viele Geräte sind da im Feld?

Yves:

Ja, also erst mal muss man klarstellen: Wir machen keine Updates bei den Kunden, sondern unsere Kunden machen hier das Endgerät, und die managen dann die Updates typischerweise bei den Kunden oder übergeben den Kunden die Möglichkeit, die Updates zu managen. Ja, Stückzahlen sind so typischerweise – bei uns liegt der Sweet Spot so bei 5.000 bis 10.000 Geräten pro Jahr. Also wir haben auch Kunden, die nur 100 Stück abnehmen oder so, die wären bei uns auch glücklich. Aber es gibt auch sehr große Kunden, die dann über 50.000 Stück im Jahr abnehmen.

Madeleine:

Interessant. Ja, stelle ich mir herausfordernd vor, eben diese ganzen Geräte wirklich dann auch aktualisiert zu halten. Vielleicht können wir gleich über die Herausforderungen – und du hast jetzt auch von Anpassungen gesprochen – da noch mal ein bisschen drüber sprechen, was eure Kunden da genau für Anforderungen haben. Jetzt hast du L-IoT ins Spiel gebracht, vielleicht hat das der eine oder andere noch nicht gehört. Ich glaube, Marvin, das wird ja Elliot gesprochen, oder? L-IoT – das ist ein Produkt, was ihr sozusagen ins Leben gerufen habt. Ist das richtig?

Okay, das heißt, für alle, die mehr erfahren wollen: Ich packe euch das mal in die Show Notes schon mal vorab, dann könnt ihr da auch später noch mal nachlesen. Ich packe euch den Link zu dem Produkt mal rein. Also das ist jetzt im Endeffekt ein Produkt, das dieses Update und Device Management löst. Kann man das so sagen?

Marvin:

Das kann man genauso sagen. Im Endeffekt löst es genau diesen Punkt. Und wie der Yves schon angedeutet hat: Es gibt zwar auch Lösungen im Feld, die unsere Kunden auch einsetzen, womit sie Geräte updaten, wie zum Beispiel RAUC als eine Technologie. Was oftmals unterschätzt wird von den Kunden als zusätzlicher Aufwand, ist, dass es ein ganzes Management darum herum braucht. Man braucht im Endeffekt Staged Rollouts. Das heißt, man möchte kontrollieren, auf welchen Geräten Updates ausgerollt werden sollen. Man braucht da Erfolgskriterien, um dann weiterhin die nächsten 20, 30 Prozent der Geräte upzudaten.

Man möchte Rollbacks geben und vielleicht durchführen können, wenn etwas schiefgeht, on-site, lokal. Man hat verschiedene Betriebsmodi. Unter Umständen dürfen Updates gar nicht durchgeführt werden, wenn das Gerät gerade im operativen Einsatz ist et cetera. Das heißt, was wir einfach bei unseren Kunden dann gemerkt haben: dass es da in den Logiken eine relativ starke Komplexität gibt, die durch Software, jetzt gerade im Open-Source-Bereich, die es am Markt gibt, nicht abgedeckt werden kann.

Das heißt, darauf haben wir uns fokussiert: Lösungen im Open-Source-Bereich, die es gegebenenfalls gibt, die Kunden auch einsetzen, bei uns mitzuintegrieren, aber die ganzen Logiken dahinter – um halt wirklich sicherzustellen, dass die Geräte nicht ausfallen, um stückweise Updates durchzuführen –, diese in einer Verwaltungsoberfläche bereitzustellen.

Madeleine:

Das ist super spannend, was du jetzt gerade sagst, weil das ist ja auch im Endeffekt das, wo dann für Hersteller das Geld liegt, wenn ich das selber machen muss. Also ich kann mir vorstellen, dass die Aufwände da ja extrem hoch werden, wenn ich da hunderte, tausende Geräte sogar irgendwie selbst managen muss. Und du hast jetzt RAUC angesprochen, das ist ja so ein Open-Source-Update-Werkzeug für Linux-Geräte. Ich fand jetzt den Punkt spannend, den du gerade gesagt hast, mit diesen ganzen Dingen: Update darf nicht durchgeführt werden, wenn ein bestimmter Fall eintritt.

Wir haben über CVE-Monitoring gesprochen, Softwarestände und so weiter. Könnt ihr mir sagen, was muss man denn eigentlich als Hersteller alles auf dem Schirm haben, jetzt vielleicht auch im Rahmen des CRA? Genau. Und was passiert eigentlich, wenn ich das nicht mache? Also was verliere ich da an Zeit, an Geld? Können wir da noch mal ein bisschen drüber sprechen? Das würde mich jetzt mal interessieren, was da eure Erfahrungen sind.

Marvin:

Gerade in Bezug auf den CRA ist es ja im Endeffekt eine Verpflichtung, die Software nicht nur bei der Einführung, also nicht nur bei der Produkteinführung sozusagen aktuell zu haben, sondern im gesamten Lebenszyklus des Produkts. Und dieser Produktlebenszyklus ist mindestens fünf Jahre oder halt, wie der Hersteller es definiert für seine Kunden, also gegebenenfalls auch länger. Gerade bei unseren klassischen Kunden, Güterverkehr, Baumaschinen, ist die Lebenszeit eines Assets zehn Jahre oder deutlich mehr unter Umständen.

Und der Cyber Resilience Act sagt im Endeffekt, dass man die Software über diese Lebenszeit pflegen muss, und das bedeutet: Gibt es eine Schwachstelle dafür, muss die sozusagen behandelt und gepflegt werden. Das heißt, ich muss diese Schwachstelle im Feld patchen, und dafür ist ein System wie ein Device Lifecycle Management einfach essenziell. Zusätzlich dazu, dass wir generell auch innovativer sein müssen, richtig? Also es ist nicht nur so, dass wir die Compliance als ein Thema haben, sondern es geht auch mehr und mehr dahin, dass ich Richtung einer Software Defined Machine oder Software Defined Anything im Endeffekt gehe.

Sodass es weniger und weniger mechanische Steuerung im Endeffekt gibt und es aber mehr und mehr dazu geht, per Software zu steuern, elektronisch zu steuern, und ich damit auch so ein bisschen Flexibilität einfach im Feld brauche, nachträglich zusätzliche Funktionen auf eine Maschine auszurollen, für Assistenzsysteme et cetera.

Madeleine:

Ja, genau. Vielleicht kurz zum Cyber Resilience Act: Ich packe euch das nochmal in die Show Notes, die offizielle Verordnung der EU. Dort sind auch nochmal die ganzen Timelines. Du hast es ja gerade gesagt, es gibt die Meldepflicht seit dem 11.9. diesen Jahres. Meldepflicht für aktiv ausgenutzte Schwachstellen, wie du das gesagt hattest, und auch für – ich glaube, die definieren das so als schwere Vorfälle –, wo dann auch genau das gemeldet werden muss. Und es gibt noch eine zweite Deadline, die ist zum 11.12.2027, wo wirklich die vollen Pflichten wie CE-Kennzeichnung, Konformitätsbewertung für alle Produkte gelten, die dann auch in den Verkehr kommen.

Wenn ihr da mehr zu erfahren wollt: Ich habe eine ganze Folge dazu gemacht, das ist die Folge 222. Gerne mal reinhören, 222, oder abonniert den Podcast und hört euch das später an. Da ist das auch noch mal im Detail ausformuliert. Jetzt hattest du gerade gesagt, innovativer werden. Kannst du das nochmal erklären: Warum ist das relevant für jetzt Kunden wie PHYTEC, aber auch andere, die ihr jetzt auch gemeinsam habt? Warum ist es wichtig, hier innovativ auch zu werden und diese digitalen Daten zu haben?

Marvin:

Yves hat es ja auch schon angesprochen. Wir erleben, glaube ich, gerade alle insgesamt eine relativ starke Revolution auch mit der künstlichen Intelligenz und den Large Language Models, die jetzt draußen sind, nur als ein Aspekt. Und wir nehmen einfach wahr, dass sich digitale Produkte noch mal schneller entwickeln aktuell als noch vor 10, 20 Jahren. Digitale, also IT-Produkte haben sich schon immer relativ schnell entwickelt, wenn man so in die Vergangenheit schaut.

Ich persönlich nehme wahr, dass sich diese Entwicklung noch mal beschleunigt und gleichzeitig der Wettbewerb aus Asien, aber auch aus Amerika einfach deutlich stärker wird. Und man daher im Endeffekt einfach mitziehen muss, wenn wir hier noch wettbewerbsfähig bleiben wollen. Und dazu gehört, viele digitale Produkte im Feld ausrollen zu können. Ich glaube, die technischen Herausforderungen sind viel gelöst, gerade auch im IoT-Bereich. Viele technische Standards haben sich etabliert. Für viele Problemstellungen, die wir noch vor zehn Jahren hatten, gibt es mittlerweile Lösungen. Und es geht jetzt wirklich darum, Lösungen im Feld auszurollen auf eine skalierbare Art und Weise.

Madeleine:

Ja, gerade wenn man so viele Geräte hat, wie es jetzt hier gerade angesprochen wurde. Yves, meine Frage: Du hattest vorhin jetzt eben verschiedene Sachen auch angesprochen, auch mit dem CVE-Monitoring und so weiter, und hast jetzt gesagt, es sind Anpassungen oder Wünsche von euren Kunden auch da. Kannst du mal so ein bisschen beschreiben, welche Informationen da entstehen, und gerade auch, wenn ihr so ein Produkt entwickelt, was da eben auch, ja, ich sag mal, so Datenpunkte sind, Informationen, die für euren Kunden dann noch relevant sind?

Yves:

Ja gut, also grundsätzlich muss man es, glaube ich, ein bisschen teilen zwischen den Nutzdaten, die die Applikation ausmachen, also die tatsächlichen Daten, die ich aus der Applikation heraus übertragen will – wie bei dem Fahrkartenautomat, dass ich halt Geldwertdaten übertragen will oder Fahrplaninformationen oder so was. Und dann aber auch die Systemmanagement-Daten, und das sind ja dann eher interne Informationen, die dazu dienen, die Geräte miteinander zu identifizieren, miteinander zu vernetzen, zu pflegen.

Das fängt schon an bei Softwareständen. Man muss ja irgendwie auch wissen, welches Gerät hat welchen Softwarestand, damit man dann auch entscheiden kann: Muss das jetzt upgedatet werden oder nicht, und welche Vulnerabilities hat denn jetzt dieses eine Gerät mit diesem Softwarestand? Und man muss auch klären: Kompatibilität. Ich habe vielleicht gewisse Hardware-Versionsstände, die bestimmte Softwareversionsstände benötigen, die speziell dafür sind. Und in der nächsten Generation ist die Software gar nicht mehr kompatibel zu der Hardware. Das muss irgendwie alles gemanagt werden.

Und das ist halt ein Riesen-Overhead, den man da irgendwann hat. Das unterschätzt man. Man denkt am Anfang: Ich hab ein Gerät, Software, das [vermutlich: „kriege“] ich schon irgendwie zusammen. Und dann kommt das Produktmanagement und sagt: Ich will aber eine Variante X mit kleinerem Display. Und was weiß ich? Kommt eine Bauteilabkündigung? Dann brauch ich dann plötzlich einen neuen Prozessor, der ein ganz anderes Kompilat braucht. Und dann habe ich unterschiedlichste Varianten und Gruppen von Geräten, die ich irgendwie verwalten muss.

Und ich glaube, das sind wahrscheinlich so die Daten, die du jetzt meintest. Also diese Verwaltungsdaten – zusätzlich zu den [vermutlich: „applikationsspezifischen“] Nutzdaten halt eben auch noch mal ein Overhead an Management.

Madeleine:

Ja, das heißt, es geht euch vor allem um diese Systemmanagement-Daten, Verwaltungsdaten, die da gemanagt werden müssen. Warum habt ihr das nicht selber gebaut? Richtig blöde Frage. Ihr hättet doch sagen können: Na ja, wir nehmen jetzt ein paar Leute hier intern zusammen und setzen uns da dran. Was war so der Grund, wo ihr gesagt habt, wir holen uns ML!PA eigentlich ins Boot? Wo entstehen da eigentlich die Aufwände? Und warum habt ihr gesagt, ihr macht es nicht selber?

Yves:

Na ja, also wir sind ein produzierendes Unternehmen, und wir haben eben so diesen Skalierungsgedanken, das muss man sagen. Wir versuchen, ein Produkt zu generieren und damit viele Kunden zu bedienen. Wir machen natürlich auch kundenspezifische Entwicklungen, aber das muss immer im Verhältnis stehen. Wir müssen ja auch unsere Produktion auslasten, weil das ist im Prinzip unser Kerngeschäft, Hardware zu produzieren. Und zu viel Individualimplementierung ist dann natürlich schwierig. Das hat ein gewisses Maß, natürlich pro Projekt, aber dann irgendwann sagen wir: Nee, jetzt müssen wir nochmal bei unseren Leisten bleiben.

Und deswegen haben wir gesagt: Okay, wir brauchen einen Partner, der halt individualisieren kann. Und wie ich schon erzählt habe: Jetzt guckt man sich solche Individualinfrastrukturen von Geräten an. Das kann ja auch sein, dass ich ein Gateway habe und darunter zum Beispiel ganz viele kleinere IoT-Devices, MCUs oder so, die Sensoren dann direkt ansteuern oder so was. Das sehr komplexes Asset Management generiert, und das muss man ja irgendwie mit dem Kunden jetzt lösen. Und so tief wollten wir da jetzt auch nicht einsteigen.

Deswegen haben wir gesagt: Okay, wir brauchen einen Partner, der diese Individualisierungsarbeit dann auch leisten kann, aber schon – und das ist das Tolle – ein Kernprodukt, ein Standardprodukt hat, was grundsätzlich erst mal alle Grundfunktionen besitzt, die man so typischerweise braucht fürs IoT-Update- und Device Management.

Madeleine:

Ja, also dieses L-IoT, Elliot, wie ihr gesagt habt, das ist sozusagen die Grundlage, wo ihr dann gesagt habt: Hey, das macht Sinn, das einzukaufen sozusagen.

Yves:

Genau. Und wir haben dann unsere eigene Plattform draus gemacht mit unserer Philosophie.

Madeleine:

Also der phyHUB, du hattest es jetzt gerade genannt. phyHUB – „phy“ von PHYTEC und „Hub“ von Hub.

Yves:

„Phy“ ja von PHYTEC, genau. Und das „Hub“ ist im Prinzip – der Name soll das schon so ein bisschen beschreiben. Es soll ein Ecosystem sein für [vermutlich: „PHYTEC-Kunden“]. Also das soll nicht nur ein plain Update und Device Management sein, sondern es soll auch unsere ganzen Dienstleistungen, die wir so anbieten für die Pflege von Produkten, irgendwo beherbergen. Das heißt, alle Ergebnisse, die aus den Dienstleistungen entstehen, zum Beispiel neue Software-Releases und das CVE-Monitoring.

Und auch das CVE-Monitoring, was wir schon für unser Kernbetriebssystem CRA-konform für den Kunden vorbereiten, soll dort sichtbar werden. Sodass der Kunde im Prinzip dann die Vulnerability sieht zu seinem Produkt und auch gleichzeitig: Was hat denn die PHYTEC da für neue Softwareversionen schon generiert, die eventuell das Problem beheben, was gerade im Feld vorhanden ist durch die Version, die da gerade im Feld aufgespielt ist? Das wird also wie so eine Art Management-System, wo man eine sehr gute Übersicht hat: Was gibt es, und was für Probleme habe ich?

Madeleine:

Ja, macht Sinn. Habt ihr da so eine Art Return-on-Invest-Rechnung mal gemacht? Weil ich kann mir vorstellen, es gibt viele da draußen, die das vielleicht auch noch gerade überlegen: Baue ich das jetzt selber? Oder die sind vielleicht da dran. Könnt ihr sagen, wie viele Personenjahre in dieser Plattform stecken? Sorry, ein bisschen provokante Frage, weiß nicht, ob ihr das könnt. Und vielleicht auch die Aussage treffen: Wie viel Zeit würde denn ein Hersteller brauchen, realistisch, um hier wirklich einen vergleichbaren Eigenbau zu machen? Habt ihr da Infos zu? Ja, gerne.

Marvin:

Vielleicht auch noch ein Aspekt vorher ergänzend zu dem, was Yves gerade gesagt hat. Ein weiterer Punkt – und das ist, glaube ich, auch bei euren Zuhörern entsprechend auch so – ist der Vendor-Lock-in. Das heißt, wenn eine Firma wie PHYTEC zum Beispiel – das war auch ein Gedankengang – jetzt mit einer IoT-Lösung oder mit einem Device Lifecycle Management an den Markt kommt, wird die gegebenenfalls nicht von Kunden akzeptiert, weil man dann auch diese Angst hat, man ist an einen Lieferanten gebunden. Das hatten wir mit unserem Kunden übrigens genauso. Unsere Kunden, wo wir das System zum ersten Mal eingesetzt haben, zum Beispiel Knorr-Bremse als einer unserer Kunden – auch die hatten diese Bedenken des Vendor-Lock-ins, und das haben ganz, ganz viele Industriekunden.

Madeleine:

Vendor-Lock-in wäre ja, dass das Gerät auf eine Plattform sozusagen eingerichtet ist, also Schlüssel, Zertifikat. Genau.

Marvin:

Ja, ganz genau. Dass es da diese Anbieterabhängigkeit gibt und man sein Gerät vielleicht nicht so einfach daraus hinausbekommt. Und das war uns auch wichtig, das so ein bisschen zu adressieren. Und deswegen kann der Kunde ja zum Beispiel auch bei PHYTEC mit phyHUB mitwachsen sozusagen. Das heißt, er kann erst mal auf das Angebot von phyHUB aufspringen, dort eine Software-Maintenance nehmen, aber auch die Plattform sozusagen als SaaS-Lösung benutzen, kann dann aber später auch dazu übergehen, sozusagen selber zu hosten, um da die Abhängigkeit zu verringern. Das heißt, wir stellen das Produkt auch als Softwarelösung zur Verfügung.

Yves:

Ja, das Gleiche ist bei uns im Prinzip mit den Dienstleistungen. Also man kann das dazunehmen, dass man sich die Software von uns pflegen lässt, das ganze Betriebssystem bis in die Applikationsebene rein. Aber man kann auch irgendwann sagen, wenn man mal Ressourcen aufgebaut hat, dass man das selber übernimmt. Und da sind wir, glaube ich, wieder beim Eingang deiner Frage: Return on Invest und Aufwand für so eine Plattform. Marvin, vielleicht kannst du gleich nochmal sagen, was die Entwicklung von dem ganzen System so als Basissystem bedeutet hat.

Ich kann nur sagen, von unserer Seite aus: Wenn man so ein IoT-Gerät mit Linux-, Yocto-basierendem Betriebssystem pflegen will, da braucht man schon jede Menge Infrastruktur. Das CVE-Monitoring und CVE-Management muss man irgendwie haben. Irgendwie muss ja die Software erst mal gescannt werden. Da gibt es ja öffentliche Datenbanken, die die ganzen Vulnerabilities, die so public geworden sind, auch darstellen und beschreiben.

Und dann braucht man ein Toolset, was im Endeffekt dann sinnvoll die eigene Konfiguration scannt. Da gibt es einfache Tools, die scannen einfach alles, die gucken: Du hast Linux-Version XY, na ja gut, dann gebe ich dir mal alle CVEs. Aber da wird zum Beispiel nicht beachtet, dass ich bestimmte Libraries oder Treiber überhaupt nicht in meinem Linux einkompiliert habe und auch in meinem Kernel, in der Kernel-Config gar nicht drin habe. Und dann kriege ich dann plötzlich Millionen von CVEs ausgeschwuppt, die für mich überhaupt nicht relevant sind. Ich muss das alles rauspicken.

Das heißt, ich muss mir erst mal ein Toolset – und das war so unsere Erfahrung, was du sagst, das Learning. Das war so unsere Erfahrung, zu sagen: Wow, okay, ich brauche jetzt erst mal ein Toolset, um dieses Scannen richtig zu machen, dass ich nicht erschlagen werde von unnötigen Informationen. Und auch KI generiert unheimlich viele Informationen, die teilweise zu viel sind. Also das Toolset ist sehr relevant. Da haben wir mal locker zwei, drei Mannjahre nur in dieses Toolset für CVE-Monitoring reingesteckt, und Software-Pflege kommt dann noch dazu.

Also wenn wir jetzt Software-Pflege machen für den Kunden individuell oder auch für unsere Standardprodukte so als Kernsoftware-Pflege, da braucht man eine Testinfrastruktur, wo man Nightly Builds baut und immer durchtestet. Die ganzen Testroutinen zu generieren, ist echt nicht einfach, dass die auch wirklich sinnvoll testen. Du musst die Ergebnisse auswerten. Du musst jede Nacht die Patches ziehen. Dann gibt es Konflikte mit den Update-Patches gegen irgendwelche Vendor-Patches, die auch noch vorhanden sind.

Ja, wenn du mal die Infrastruktur hast, brauchst du dann mal locker ein, zwei Softwareentwickler, die wirklich tief in einem Linux-Thema drinstecken, die dann kontinuierlich diese BSP-Pflege und diese ganzen Konflikte irgendwie immer bearbeiten und auflösen können und auch die CVEs bewerten können und sagen können: Okay, das ist kritisch für mein Produkt oder nicht.

Madeleine:

Ja, genau, da hört es ja nicht auf, weil man muss es ja dann auch noch dem Kunden bereitstellen, oder da gibt es ja dann auch noch vom Asset Management, aber auch vom Rechte- und Rollensystem etwas, was entwickelt werden muss, könnte ich mir vorstellen.

Yves:

Ja gut, das kann [vermutlich: „L-IoT“].

Marvin:

Genau, [vermutlich: „das hast du angesprochen“]. Da kommt die Komplexität rein, weil es im Endeffekt nicht nur um das Device geht, was verwaltet werden muss, sondern die Devices sind auch an physikalische Assets gebunden. Das heißt, man muss die Asset-Seite abbilden. Dort gibt es Hierarchiestufen, dort müssen Attribute verwaltet werden. Relativ komplexes Rollen- und Berechtigungsmanagement gegebenenfalls – richtig angesprochen –, weil man einfach dann individuell teilweise auf einzelnen Devices Aktionen ausführen möchte oder das so beschränken möchte, dass nur auf einzelnen Devices Aktionen ausgeführt werden können.

Und was auch ein komplexes Thema ist – das ganze Thema, was Kunden auch oftmals unterschätzen: Ownership-Transfer. Also wem gehört eigentlich das Gerät, wem gehört das physikalische Asset, wie können dann Eigentümer gewechselt werden, und was passiert auch mit den Daten dann historisch, die bereits existiert sind?

Madeleine:

Kannst du Ownership-Transfer noch mal ganz kurz erklären, was das bedeutet?

Marvin:

Es geht einfach darum: Zum Beispiel im Laufe des Lebenszyklus kann ein Gerät den Eigentümer schrittweise ändern. Es wird vielleicht erst mal produziert, wird in der Produktion vorbereitet, hat dort erst mal den Hersteller sozusagen als Eigentümer, wird dann an einen Supplier übergeben und wird dann vielleicht an einen Endkunden übergeben. Das heißt, es wechselt den Eigentümer im Laufe der Auslieferung gegebenenfalls mehrere Male, je nachdem, wie lange die Supply Chain ist oder auch wie die Kundenkonstellationen sind.

Madeleine:

Also am Ende an so einen Fahrkartenautomatenhersteller sozusagen, und dann gibt es noch Zwischenstufen zum Beispiel.

Marvin:

Absolut. Vielleicht gibt es auch einen Eigentümer – in ganz vielen Szenarien gibt es einen Eigentümer zum Beispiel des Fahrkartenautomaten, der vom eigentlichen Betreiber ein anderer sein mag. Das heißt, da sind wir dann auch im Szenario, wo es zwei verschiedene Parteien gibt, die aber jeweils ein Interesse oder eine Verantwortlichkeit für das Gerät, für den Fahrkartenautomaten haben. Und diese Logiken, diese Abhängigkeiten sozusagen zu beachten, ist eine der Komplexitäten im Endeffekt dabei.

Yves:

Ich habe auch noch ein schönes Beispiel dafür. Wir haben zum Beispiel einen Kunden, der Notstrombeleuchtungen in öffentlichen Gebäuden und so was macht. Das sind auch vernetzte Systeme, das heißt, die Lichtanlagen für die Fluchtweglichter und so was, die sind alle vernetzt. Wir nennen das Hausmeister-Update. Man will jetzt nicht als Hersteller von diesen Lichtanlagen da einfach mal ein Update ausführen, sondern man weiß ja gar nicht: Welche Situation ist es gerade vor Ort? Ist es gerade kritisch? Oder bei Medizingeräten will man auch nicht einfach ein Update machen, wenn gerade die OP im Gange ist.

Und in dem Fall ist es auch so, dass im Prinzip der Hausmeister gewisse Minimalrechte haben muss. Im Prinzip kriegt er das Update angedient, und er ist derjenige, der vor Ort dann den Knopf drückt und sagt: So, jetzt updaten, weil jetzt ist es okay. Jetzt sind die Türen verriegelt, es ist keiner mehr da. Ich habe eine sichere Situation. Jetzt kann ich mal dieses Update fahren, wo eventuell das System für eine kurze Zeit nicht verfügbar ist. Und das sind auch so Individualimplementierungen, die natürlich dann irgendwann – L-IoT hat da schon auch Lösungen generiert, die dann irgendwann standardisiert schon anbietbar sind, aber das muss immer wieder so ein bisschen angepasst werden.

Madeleine:

Na ja, ja, okay. Ja, Aufwände sind so Wahnsinn, und auch es klingt krass komplex. Also wenn ich so was selber machen wollen würde, das ist, wie du schon sagst, dann ja ein paar Mann-, Personenjahre, sag ich mal. Habt ihr da trotzdem jetzt nochmal nachgehakt? Sorry, wenn ich da ein bisschen dranbleibe. So eine Return-on-Invest-Rechnung für den Kunden oder auch, ich weiß nicht, Marvin, ob ihr da was habt, was den Aufbau, Personentage pro Jahr, Kostensatz, was auch immer betrifft? Habt ihr das mal durchgerechnet?

Marvin:

Ich kann vielleicht von unseren Aufwänden für die Produktentwicklung sprechen und das so ein bisschen darstellen. Es ist tatsächlich so, dass wir an L-IoT, an dem Produkt, jetzt über mehrere Jahre weg, also vier, fünf Jahre, entwickelt haben, in verschiedenen Stufen. Erst mal viele einzelne Module – was ich eingangs auch so ein bisschen hergeleitet hatte –, viel über die Projekte versucht zu standardisieren und das in Module einfließen zu lassen. Und dann aber intensiv [unverständlich] drei Jahre Produktentwicklung, wirklich das dann in ein Produkt zu gießen und als eine Lösung sozusagen verfügbar zu machen. Das heißt, das ist schon auch ein stärkeres Investment hier von unserer Seite.

Madeleine:

Ja, stark. Ja, okay. Und dann habt ihr ja verschiedenste Kunden auch. Übrigens, falls ihr den Podcast noch nicht abonniert habt, macht das gerne, weil mit Knorr-Bremse kommt auch demnächst eine Folge. Die sind auch bei uns im Netzwerk vertreten. Das ist eigentlich eine ganz coole Überleitung, weil das auch angesprochen ist – ja, auch euer Kunde. Und wenn ihr da Interesse am Austausch habt: Wir haben immer einmal im Monat zwei Runden, so eine Tech-Runde zum Beispiel. Und da geht es auch um den Austausch nur unter Anwendern. Also kommt da gerne rein.

Übrigens, ich würde dich auch noch einladen, wenn du möchtest. Da sind die ganzen auch technischen Leiter, Leiterinnen dabei aus den ganzen Projekten, die sich genau damit beschäftigen und sich da austauschen. Kommt da einfach rein, pack ich euch in die Show Notes. Weil das ist ein Riesenthema, alle haben, glaube ich, die gleichen Herausforderungen. Und da mal drüber zu sprechen, wie das gelöst wurde – da herzliche Einladung an euch, kommt da gerne rein. Das findet dann wieder einmal im Monat statt. Pack ich euch in die Show Notes.

Genau, jetzt aber zu dem Lösungsteil nochmal ganz kurz. Ihr habt ja – oder Yves, du hast ja gesagt, ihr habt euch dann für ML!PA entschieden, gerade weil das Asset Management auch schon da war und eben dieses Ganze, was ihr jetzt angesprochen habt, gelöst wurde. Was ist jetzt das Ergebnis? Also du hattest auch vorhin gesprochen von „für den Nutzer dann sichtbar werden“, irgendwie visuell. Also was sieht jetzt euer Kunde, und was ist jetzt das Endergebnis, was ihr jetzt hier gebaut habt?

Yves:

Im Prinzip haben wir auf dieser Device-Management-Plattform, L-IoT, jetzt die Schnittstellen sehr offen, also da gibt es eine [vermutlich: „API“]. Und wir haben einerseits mit ML!PA zusammen noch eine CVE-Monitoring-Oberfläche mit eingebaut. Das ist basierend auf Dependency-Track. Und damit können wir im Prinzip dann die CVEs sehen und monitoren. Und diese Scans, die kommen dann von uns. Man kann auch selber scannen, wenn man will, und das dann visualisieren.

Es ist im Prinzip ja nur eine SBOM, die da generiert werden muss, beziehungsweise ein VEX-File, das dann die Informationen beinhaltet über CVEs, beziehungsweise aber auch bei dem VEX-File dann den Triage-Prozess, also die Entscheidung: Wie habe ich das Problem dann gelöst oder wie will ich es lösen? Und diese Informationen kommen dann im Prinzip in die Plattform rein und werden dann in Verbindung gesetzt mit Softwareständen, die ich zur Verfügung habe, und eben den Informationen von den Produkten.

Was wir gemacht haben, ist: Wir produzieren bei uns und können dann im Endeffekt in der Produktion – wir haben so eine Secure Area, wo wir dann auch Zertifikate und Keys aufspielen können oder auch Encryption aktivieren können für sichere Kommunikation. Und da können wir optional phyHUB schon aktivieren im Produkt. Und wenn der Kunde dann das Produkt das erste Mal hochfährt, dann poppt das in seiner phyHUB-Instanz auf als Gerät sichtbar, und dann kann er die Verwaltung [vermutlich: „anfangen“].

Also typischerweise macht er erst mal so ein Grundupdate, weil man weiß ja nicht, was für einen Grundsoftware-Auslieferzustand das hat. Meistens gibt es ja dann schon einen neueren. Und dann bringt man es ins Feld, und dann kann man es im Feld im Prinzip monitoren, und das ist dann schon alles eingerichtet. Und wie gesagt, man kann dann auch die CVEs selber managen. Und der Vorteil ist, weil das System so offen ist: Wenn der Kunde jetzt selber schon zum Beispiel auch ein Ticketing-System hat und sagt: Okay, ich habe hier in der Plattform CVEs, die ich sehe, und jetzt will ich das irgendwie als Aufgabe meinem Team geben, dass das behoben wird oder eine Lösung gefunden wird – dann kann ich im Prinzip ein Ticketing-System anbinden, was schon in der Firma vorhanden ist, und kann dann die Tickets daraus automatisch generieren und kann auch sehen: Ist das erledigt oder nicht?

Also es ist sehr flexibel. Man kann jetzt von uns die Lösung nehmen, man kann aber auch selber, wenn man schon Infrastruktur hat – auch Build-Infrastruktur, um BSPs zu generieren, um das Betriebssystem zu kompilieren, ist meistens oder oft auch im Haus vorhanden. Dann kann man, statt von uns die Images zu nehmen, auch die Images selber im Prinzip in die Plattform reinbringen. Das ist so die Grundidee: möglichst flexibel zu sein und trotzdem immer einen Überblick zu generieren und alles zu haben, was man eigentlich braucht, um Geräte zu managen.

Madeleine:

Sehr schön. Das heißt, da habt ihr dann auch gelöst, diese Zusammenhänge und auch die verschiedensten Lösungsmöglichkeiten wirklich schnell zu erkennen, weil du hattest ja vorhin angesprochen, es werden ganz viele – also wenn man es nicht so macht – viele unnötige Informationen, das ist sehr komplex, das Thema Ownership-Transfer muss gelöst werden und so weiter. Also das habt ihr jetzt sozusagen alles in einem Produkt. Ihr habt – also L-IoT habt ihr als White-Label-Produkt genutzt, das heißt, Kunden von euch nutzen den phyHUB, und das ist sozusagen so, wie ihr dann eben auch diese Komplexität abgebildet habt in diesem Produkt. Das ist alles in einem sozusagen.

Yves:

Ja, es ist im Prinzip noch mal größer gedacht. Also jetzt nicht nur als Update- und Device-Management-Plattform, sondern den kompletten Prozess vom Generieren der Software bis zum Monitoring. Das ist im Prinzip das komplette Management von einem Gerät, was sich da jetzt weiterentwickelt hat, zusammen mit ML!PA. Das heißt, wir sind da aus der Praxis gekommen und haben gesagt: Hier, [vermutlich: „das ist eine“] coole Basis. Aber wir haben für unsere Produkte, dass man das ganzheitlich lösen kann, noch ein paar Features mehr. Und die haben wir jetzt gemeinsam implementiert und damit L-IoT oder phyHUB halt eben noch mal umfangreicher gemacht.

Madeleine:

Das heißt ja, wenn ihr Hersteller seid und Interesse habt, checkt das auf jeden Fall mal aus. Ich pack's euch in die Show Notes. Und wenn ihr – ich korrigiere mich – wenn ihr Kunde seid von PHYTEC, gibt es eben da auch den Bereich der neuen Lösung, des phyHUBs. Checkt das auch mal aus, pack ich euch auch in die Show Notes. Das könnt ihr euch einfach mal anschauen. Und ich denke, ihr seid ja auch offen für Gespräche. Oder wenn man da jetzt Rückfragen hat oder einfach auch sagt: Hey, ich will einfach nur mal so sprechen, wie habt ihr das gemacht? Dann denke ich, seid ihr da auch ansprechbar.

Yves:

Ja, machen wir sowieso. Meistens bringt das sowieso sehr viel, auch wenn jetzt da keine Business-Relation daraus entsteht. Ich als Produktmanager höre immer gerne, was die anderen auch machen, und dann kann man sich austauschen. Dann ist das eher so was, und das bringt dann trotzdem beiden was. Also da muss man nicht scheu sein. Man kann sich auch einfach melden, und wir reden über die Probleme, die man halt so hat in dem Bereich.

Madeleine:

Okay, dann packe ich auch Kontakte in die Show Notes, und wie gesagt, wer Lust hat: Unser Anwenderkreis ist einmal im Monat da, auch gerne reinkommen. Genau, und da können wir dann auch nochmal in den Austausch gehen. Jetzt kommen wir zu den angesprochenen Learnings abschließend für heute. Habt ihr denn irgendwelche operativen Learnings, Fallstricke, wo ihr sagt: Hey, das könnt ihr teilen? Irgendwas, wo ihr sagt, das würden wir sofort wieder machen oder das würden wir nie wieder so machen? Oder gibt es irgendwas im Projekt, was vielleicht ein Frühwarnsignal ist, wo ihr sagt: Hey, passt auf!

Marvin:

Generell kann man, glaube ich, sagen, dass man wirklich den Aufwand unterschätzt. Das kann Yves vielleicht auch von seiner Seite oder von ihrer Seite aussprechen. Es ist wirklich so, dass man erstens sehr, sehr viel im Feld lernt. Also das ist vielleicht ein Learning, was ich mitgeben würde, was auch Yves gerade angesprochen hat: frühzeitig im Feld verproben, frühzeitig auch mit Kunden, mit Partnern sprechen. Da haben wir auch mit PHYTEC wirklich einen guten Partner, über den wir auch viel mitnehmen und unsere Lösung weiterentwickeln können zu den angesprochenen Punkten.

Viel im Feld verproben, weil man dann einfach viel mitnimmt, was die Lösung im Endeffekt können muss, was es für Herausforderungen gibt, und dann diese zügig versuchen umzusetzen oder dann einfach mitzunehmen und dann die Umsetzung mit reinzugeben. Man kann viel in der Theorie entwickeln, aber in der Praxis – es ist dann so, ganz allgemein gesprochen, muss ich jetzt sagen – in der Praxis trifft man dann trotzdem sehr viele Edge Cases, die man am Anfang gar nicht bedenkt.

Yves:

Würde ich mich anschließen. Wir hatten ja auch mal initial den Gedanken, das selber zu machen und zu implementieren, und haben dann auch irgendwann schon auf der Theorie-Ebene gemerkt: Okay, das wird echt komplex. Man unterschätzt das, glaube ich. Im Detail ist dann doch der Teufel begraben. Und was für uns jetzt nochmal Learnings waren oder für mich auch überhaupt beim Reinarbeiten in diese Thematik, ist, dass man flexibel sein muss, dass man nicht so eine Friss-oder-stirb-Lösung generieren kann und meinen kann, da kommt jeder mit klar.

Dafür sind die Probleme zu individuell, besonders im Embedded-Bereich. Ich meine, Embedded lebt davon, dass es flexibel ist, dass es individuell ist, dass es halt eben nicht von der Stange ist. Sonst nehme ich einen Industrie-PC, der ist fertig, und das war's. Sondern ich habe ja im Prinzip Geräte, die ganz, ganz spezifische Use Cases haben, ganz spezielle Schnittstellen. Und genauso vielfältig sind eben auch die Businesslogiken und Applikationen dahinter. Und da braucht man diese Flexibilität.

Und ein wichtiges Learning von unserer Seite aus war auch, dass man eben gucken muss, dass es kein Vendor-Lock-in ist. Dass die Kunden immer noch die Freiheit haben, und auch die Freiheit haben, selber sich weiterzuentwickeln und zu sagen: Nee, jetzt initial mit dem CRA, das überrumpelt mich jetzt alles. Ich habe nicht die Kapazitäten, um hier Software zu pflegen wie verrückt. Dann nehme ich jetzt erst mal eine PHYTEC, die mir da hilft, und später baue ich mir dann vielleicht die Ressourcen auf und sage: Gut, dann löse ich mich von diesem Softwarepflegeangebot von der PHYTEC, aber ich benutze immer noch meine Plattform weiter, die ich mal genommen habe und die auch gut funktioniert. Diese Flexibilität, die muss man, glaube ich, haben – oder auch, dass man die Plattform selber hosten kann und auch unabhängig ist.

Madeleine:

Na ja, habt ihr auch was, wo ihr sagt, würdet ihr auf gar keinen Fall wieder so machen?

Yves:

Was uns wichtig ist – und das haben wir im Prinzip auch in der Zusammenarbeit mit ML!PA geklärt –, ist, dass wir auch die Rechte an dem System haben. Das heißt, wir haben da auch eine gewisse Sicherheit für unsere Kunden, dass wir sicherstellen können: Die phyHUB-Plattform hat Bestand und ist über die PHYTEC abgesichert. Das war uns sehr wichtig. Da haben wir in der Vergangenheit gelernt, dass das ganz wichtig ist, weil dieser Markt schon auch schwierig ist. Man muss dann schon schauen, ob man eine stabile Lösung hat, die einem nicht wegbricht. Foundries.io zum Beispiel wurde von Qualcomm aufgekauft, und schwupp war das Thema erledigt. Viele, die auf Foundries.io unterwegs waren, die gucken jetzt in die Röhre.

Madeleine:

Und für eure Kunden scheint es ja auch wieder wichtig zu sein, die das ja auch wieder eigenständig nutzen wollen, hattest du vorhin gesagt. Das heißt, das ist ja auch wiederum wichtig.

Marvin:

Absolut. Also definitiv auch ein sehr frühes Learning an der Stelle, das auch wir früh in unserer Zusammenarbeit auch mit Knorr unter anderem gemerkt haben. Aber eigentlich mit jedem Kunden, mit dem man spricht: Wirklich diese Abhängigkeit, die will man sich nicht geben. Gerade aus dem Punkt, den ich auch am Anfang gesagt habe: Die Assets leben dann doch 10 bis 15 Jahre. Man kommt gegebenenfalls gar nicht so einfach ran, oder halt nur mit erheblichem Kostenaufwand, wenn wirklich jemand vor Ort hinfahren muss, die Geräte dann manuell auf eine andere Plattform oder die Software, eine neue Software aufzuspielen. Und daher ist dieser Punkt Abhängigkeit für eigentlich alle Kunden sehr relevant.

Madeleine:

Ja, sehr schön. Zum letzten Punkt für heute würde mich jetzt noch mal interessieren: Wo seht ihr die Plattform jetzt in Zukunft? Also wenn wir jetzt mal Glaskugel fünf Jahre weiterschauen: Wo, denkt ihr, steht die Plattform, was kommt da noch? Wie seht ihr den Markt? Habt ihr da noch Gedanken zu, was da in Zukunft auf euch zukommt?

Marvin:

Im Endeffekt ist der aktuell größte Treiber ganz klar der Cyber Resilience Act. Das heißt, aktuell bewegt die Kunden, die Geräte verwalten zu können über den gesamten Lebenszyklus, um dann Sicherheitsupdates et cetera einzuspielen. Der Punkt Innovationsfähigkeit, nachträglich auch neue Funktionen softwaretechnisch auf die Geräte einzuspielen, ist aktuell von dem, was wir wahrnehmen, noch nicht so der ganz große Aspekt.

Ich glaube aber – oder wir glauben aber –, das wird sich in den nächsten Jahren, also wenn du da fünf Jahre sprichst, das wird sich in den nächsten fünf Jahren ändern. Das heißt, das wird ein wichtiger Aspekt werden, dass wirklich alles mehr softwaregesteuert wird und man neue Funktionen dann nachträglich freischalten will oder halt übertragen will. Auch wenn es viel um den Bereich KI geht: Ich denke, wir werden auch mehr lokale KI-Anwendungen dann auf den Geräten zukünftig sehen. Selbstverständlich in der Robotik, aber auch in anderen Applikationen.

Und dann wird es noch viel wichtiger im Endeffekt, die Geräte zu monitoren und Anpassungen an der Erkennung, am Modell per Software aussteuern zu können. Und wo wir einfach als Firma mit L-IoT so ein bisschen unterstützen wollen, ist das Thema Compliance zum einen, aber Innovationsfähigkeit und Skalierung zum anderen. Das heißt, da sehen wir auch so ein bisschen den Shift in den nächsten fünf Jahren, dass es von doch sehr begrenzten IoT-Anwendungen – so von einem Prototypen in einer Produktionshalle vielleicht – zu einer Ausrollung über den gesamten Betrieb geht. Einfach um schneller produzieren zu können, um effizienter zu werden und effizient zu bleiben.

Yves:

Also ich glaube, durch die Weiterentwicklung von KI und auch besonders KI on the Edge wird Datentransfer sehr viel mehr reduziert. Also ich werde weniger in der Cloud KI machen und mehr on the Edge. Aber damit werden die Edge Devices natürlich relevanter. Und um auch die Edge Devices natürlich immer up to date zu halten, müssen Modelle ausgetauscht werden und Software-Updates gemacht werden.

Durch die KI ist die Halbwertszeit von Softwareständen noch mal zusätzlich zum CRA, zu den Anforderungen vom CRA, noch mal zusätzlich geringer geworden. Die Entwicklungszyklen sind so viel schneller. Ich kann so viel mehr generieren an neuem Code und Verbesserungen. Man sieht ja, von einem Jahr aufs nächste ist die Entwicklung von KI-Fähigkeiten, von Large Language Models, so was von gewachsen. Und das wird sich natürlich auch immer mehr auf Edge Devices auswirken.

Auch da gibt es im Hardware-Bereich – das sehen wir jetzt bei unseren Prozessoren – überall schon KI-IPs mit drin, die im Prinzip auch beschleunigt Modelle ausführen können, und solche Sachen. Oder auch Zusatzchips, die außen angeflanscht werden, die dann schon richtig Leistung haben. Und die müssen im Prinzip weiter gefüttert werden mit den neuesten Modellen und Optimierungen. Man ist da ressourcenmäßig natürlich in dieser Embedded-Hardware immer limitiert, deswegen versucht man auch immer zu optimieren.

Und ich glaube, der Fortschritt wird da einfach unheimlich viel bringen. Aber jetzt kommen wir wieder auf den Punkt zurück: Ich muss im Endeffekt immer in Kontakt bleiben mit meinem Edge Device und muss im Prinzip da ständig kommunizieren und updaten, um da auch wettbewerbsfähig mit meinen Produkten zu bleiben.

Madeleine:

Umso besser, dass ihr da jetzt eine skalierbare Lösung auch für die Zukunft geschaffen habt, wo ihr darauf aufbauen könnt. Gerade wenn man in Richtung Skalierung denkt und eben, was du jetzt sagst, was da neue Anforderungen sind, die da vielleicht in Zukunft auch noch kommen. Äußerst spannend. Ich würde für heute damit die Session schließen. Danke, Yves, auch für deine Zeit hier, dass du dabei bist, und Marvin für deine Zeit auch, dass ihr euer Projekt hier vorgestellt habt. Ich fand es wirklich spannend. Wir haben wirklich ganz konkret von Kundenanforderungen über Cyber Resilience Act über die technische Lösung gesprochen, fand ich super spannend. Auch gerade eure Learnings jetzt zum Ende noch mal.

Und zum Thema AIoT oder Neuschlagwort, Thema KI, gehe ich jetzt mal nicht tiefer drauf ein. Vielleicht machen wir noch mal eine Folge, ich weiß nicht, noch mal ein Update in ein paar Jahren oder was. Gucken wir noch mal drauf. Fände ich spannend. Mir hat es großen Spaß gemacht heute. Wer mehr zum Thema AI noch mal erfahren will: Ich habe eine Folge gemacht, das ist die [vermutlich: „224“]. Da habe ich mit dem CPO, dem Partner von uns, mit dem Jürgen gesprochen. Die haben für Asset Management so eine Art Datenharmonisierung, Lösungen, oder bauen sie jetzt. Und da ging es halt drum: Was brauchen die KI-Agenten hier für das Mapping, dass man halt auch neue Geräte in so ein Asset Management anbinden kann? Falls euch das interessiert, hört da noch mal rein. Aber ich würde erst mal das letzte Wort hiermit an euch übergeben von meiner Seite aus. Vielen Dank, dass ihr heute mit dabei wart.

Yves:

Vielen Dank auch. Und du hast das auch sehr professionell gemacht. Und die letzte Folge, die 224, die du gerade genannt hast – das klang so, als hättest du das jetzt aus dem Kopf gemacht. Das ist schon sehr beeindruckend.

Madeleine:

Ich habe gespickt, muss ich sagen. Ich habe unsere Website hier, iotusecase.com, gerade offen und bin auf Podcast und habe nur mal geschaut, weil mir das jetzt gekommen ist. Als ihr das gesagt habt, habe ich nur kurz nachgeguckt. Vieles hab ich auch im Kopf.

Yves:

Ja, aber toll, [vermutlich: „du hast“] uns echt super durch das Interview geführt, und ich finde auch ganz toll, was da jetzt bei rausgekommen ist. Und ich glaube, es gibt den Zuhörern auch so ein grobes Bild, ein bisschen, teilweise sogar ins Detail, mit welchen Herausforderungen man da so arbeitet, wenn man so Geräte vernetzt und dann CRA-konform das Ganze hinkriegen möchte. Ja, mir hat es jetzt ziemlich viel Spaß gemacht, und ja, ich würde auf jeden Fall gerne mal wieder, besonders das Thema [vermutlich: „KI on the Edge“] – da könnten wir auch ein bisschen was zu erzählen. Wir haben da auch ein Team, die sich damit auseinandersetzen. Könnten wir auf jeden Fall machen. Ansonsten vielen Dank, dass ihr zugehört habt, und Madeleine, dass du uns so toll geführt hast.

Marvin:

Absolut, kann ich mich nur anschließen. Vielen Dank, Madeleine. Gut durchgeführt, und mir hat es auch viel Spaß gemacht. Ich finde es auch immer gut – die Partnerschaft mit PHYTEC, die wir jetzt neu angehen –, dass wir uns hier so austauschen konnten und das auch mal ein bisschen gemeinsam vorstellen konnten. Wir arbeiten auch wirklich sehr gern zusammen. Ich freue mich auf jeden Fall auch auf einen zukünftigen Austausch.

Madeleine:

Sehr schön. Dann macht's gut, und damit würde ich sagen: eine schöne Restwoche für euch. Tschüss.

Yves:

Danke, ciao.