Datenharmonisierung mit AIoT: Was brauchen KI-Agenten für das Mapping?

Madeleine:

Hallo, Freunde des IoT. Willkommen im Podcast für die Umsetzung von IoT in der Praxis. Ich bin euer Host, Madeleine Mickeleit, studierte Maschinenbauingenieurin. Und heute endlich – viele haben mich das gefragt: Definition AI versus IoT, gehört das zusammen? Wo ist die Abgrenzung auch technisch?

Und wir haben ein neues Buzzword, davon haben vielleicht einige schon mal gehört, einige noch nicht: das Schlagwort AIoT. Heute definieren wir das für euch und wir beantworten dazu vor allem auch ein paar Fragen aus der Community, die mich erreicht haben. Und natürlich wie immer die Praxis im Vordergrund, das heißt, wir erklären das einfach anhand der Umsetzung von anderen Betrieben: Was wird überhaupt schon umgesetzt, was ist vielleicht auch noch ein bisschen Zukunft?

Und heute mit dabei ein Urgestein – ich hoffe, ich darf das so sagen – im IoT: der Dr. Jürgen Krämer. Er ist Unternehmer, CPO, Managing Director der Cumulocity. Viele kennen sie wahrscheinlich auch ehemals Software AG, sprechen wir gleich drüber. Und daher heute ein spannender Fokus zum Thema IoT-Software und wie hier schon AI Einzug findet, welche Use Cases es da gibt und welche ihr auf jeden Fall kennen solltet. Dazu kommen wir jetzt. Alle Infos zur Umsetzung solcher und ähnlicher Projekte findet ihr wie immer unter www.iotusecase.com – und damit würde ich sagen: Let's go!

Und ja, damit herzlich willkommen im Podcaststudio, hier virtuell. Hallo Jürgen, schön, dass du mit dabei bist.

Jürgen:

Vielen Dank, Madeleine, vielen Dank für die Einladung. Ich freue mich, heute dabei zu sein und ein bisschen Licht auf diesen ganzen Bereich AIoT und industrielle KI zu werfen – zumindest auf das, was wir im Markt sehen, was wir bei Kunden sehen und wie Cumulocity sich da entsprechend positioniert. Da haben wir ein bisschen zu reden.

Madeleine:

Sehr schön. Ich freue mich auch schon total. Ich warte schon ewig auf diese Folge und ich glaube, viele da draußen auch. Deswegen schön, dass du da bist. Nur mal kurz: virtuell – wo erreiche ich dich gerade? Bist du in Deutschland oder bist du woanders unterwegs?

Jürgen:

Ich bin in Deutschland, ganz normal im Office, alles gut.

Madeleine:

Okay, euer Office ist wo nochmal, für alle, die jetzt regional zuhören?

Jürgen:

In Düsseldorf. Wir haben mehrere Offices in Deutschland, aber Düsseldorf ist unser Hauptsitz.

Madeleine:

Okay, dann Grüße, Shoutout nach Düsseldorf und natürlich an alle, die jetzt zuhören, wo auch immer ihr gerade seid. Genau, Jürgen, ganz kurz zu dir, für die, die dich noch nicht kennen. Ich habe es angekündigt: CPO, Geschäftsführer der Cumulocity. Ihr seid – lasst mich überlegen – seit 01.01.2025 wieder ein eigenständiges Unternehmen am Markt, ihr habt ein Management Buyout aus der Software AG 2024 gemacht. Ihr seid mit der Cumulocity in mehr als 20 Ländern aktiv, ihr habt über 1.000 Unternehmen, die euch einsetzen. Ich kenne euch schon auch echt lange. Und ich glaube, ihr habt Millionen von Geräten mittlerweile schon angebunden. Vielleicht nur mal ganz kurz zur Einordnung des Unternehmens, damit alle wissen, wo wir hier starten.

Jürgen:

Genau, ist alles richtig. Sind wir auch stolz drauf. Wir sagen, es sind industrielle Geräte. Es gibt auch IoT-Anbieter, die binden mehr Home-Geräte an, nämlich Rasenmäher oder diese Boxen für Netflix und so weiter, da gibt es größere Stückzahlen. Aber wir haben den Fokus auf Industrial IoT. Wenn wir von Geräten reden, sind das Windturbinen, Aufzüge, Kompressoren, Pumpen. Wir haben mehr als 25 Millionen von den Dingern angeschlossen und in Betrieb, über die Plattform. Was schon zeigt, dass wir auch eine Weile am Markt sind und eine Menge Erfahrung haben.

Madeleine:

Ich wollte gerade sagen: Ich glaube, viele arbeiten ja schon mit euch. Die, die es noch nicht tun: Seid gespannt, worüber wir jetzt reden. Ich freue mich auf jeden Fall, dass du auch wieder dabei bist. Wir haben ja schon eine Folge gemacht, ich glaube, die letzte war 2025. Deswegen cool mit dem Update heute. Und es gibt auch eine Folge zum Thema Cyber Resilience Act. Falls euch das interessiert, verlinke ich euch die noch mal in den Shownotes. Da könnt ihr reinhören, wie Cumulocity da unterwegs ist. Heute geht es aber um das Thema KI.

Und vielleicht macht es Sinn, dass wir das Thema ein bisschen einordnen und mal definieren. Ich würde mal aus meiner Brille anfangen und du kannst es vielleicht aus der Praxis ergänzen. Weil es gibt ja verschiedene KI-Typen. Also wir haben dieses klassische Machine Learning. Viele aus dem Data-Science-Bereich, aber auch andere kennen das ja schon seit Jahren – dieses ganze Thema Kamera, Qualitätsüberwachung, auch n.i.O.-Teile in dem ganzen Thema Qualitätsüberwachung. Da gibt es ja schon ewig, Jahrzehnte, das Thema des klassischen Machine Learnings.

Was jetzt eben Einzug erfahren hat, ist dieses ganze Thema generative KI. Ich glaube, viele arbeiten mit ChatGPT, Gemini, Claude und so weiter, wo man jetzt eben auch wirklich mit der AI sprechen kann, sich Dinge erklären lassen kann, Texte zusammenfassen, aber auch richtige Handlungsempfehlungen und Interpretationen bekommen kann. Und dann gibt's die hybride KI, das ist ja so ein bisschen beides zusammen. Das war jetzt immer so ein bisschen mein High-Level-Verständnis von den KIs da draußen, sage ich mal.

Jürgen:

Das ist absolut richtig. Wir unterscheiden auch genau diese beiden Geschmacksrichtungen von KI. Einmal das klassische maschinelle Lernen, was mehr für Analytics eingesetzt wird, wo man auf entsprechenden Maschinendaten Machine-Learning-Modelle trainiert, zum Beispiel für Anomalie-Erkennung oder die verbleibende Nutzungsdauer von Verschleißmaterialien oder zur Objekterkennung auf Bildern. Das ist so der klassische Machine-Learning-Use-Case.

Und dann gibt es natürlich seit einiger Zeit diese agentische KI und die LLMs, also die entsprechenden Wege, wo man dann über natürliche Sprache mit einer KI interagiert und das entsprechend auch nutzt, zum Beispiel um Daten von einer IoT-Plattform anzufragen oder auch um Applikationen zu entwickeln. Da kommen wir noch ein bisschen dazu, weil diese Agenten mittlerweile eine ganze Menge erlauben. Es ist ganz beeindruckend, was da geht.

Und wenn wir über AIoT reden, dann ist es eigentlich die Verschmelzung von KI und IoT. Der Schritt von der klassischen Vernetzung von Maschinen und Anlagen, was wir schon immer gemacht haben – quasi die OT-Welt anzubinden, die Daten über die Edge in die Cloud zu heben – und jetzt der Schritt hin zu vernetzten autonomen Prozessen, die dann auch KI nutzen, um diese Automatisierung und Autonomie ein Stück weit voranzutreiben. Und das versteht man unter AIoT.

Das heißt, da sind beide Arten von KI entsprechend drin: die klassische KI, das maschinelle Lernen, als auch die neuen Ansätze im Bereich generativer KI und agentischer KI. Da können wir jetzt vielleicht ein bisschen auf Beispiele eingehen. Aber dieses AIoT bringt einfach AI und IoT zusammen, und IoT ist eine Voraussetzung, weil man braucht ja erst mal die Daten, sonst kann man da oben drauf schlecht analysieren.

Madeleine:

Exakt. Würdest du eigentlich sagen, dass AIoT auch immer gleichzusetzen ist mit Live-Daten aus solchen Geräten und Maschinen? Weil ich habe mich gefragt: Viele Kunden haben ja ganz unterschiedliche Projekte. Teilweise habe ich die Daten irgendwo in einem größeren Data Lake liegen, teilweise greife ich wirklich direkt von oben durchgestochen auf das Gerät zu. Sind das immer Live-Daten oder sind es auch manchmal einfach historische Daten, die irgendwo in einer Datenbank liegen? Würdest du immer von Live-Daten sprechen?

Jürgen:

Diese klassischen Machine-Learning-Modelle trainiert man natürlich auf historischen Daten. Du hast völlig recht: Viele Kunden harmonisieren ihre Datenlandschaft heutzutage in Data Lakes. Und eine wichtige Datenquelle sind natürlich die IoT-Daten. Aber da gibt es auch eine ganze Menge an Daten in einem Unternehmen, betriebswirtschaftliche Daten und so weiter, die natürlich auch in den Data Lakes sind.

Was wir aber jetzt in letzter Zeit sehen, ist, dass die Daten in so einem Data Lake oder einem Lakehouse immer frischer werden. Und wir haben jetzt auch eine neue Komponente in unserem DataHub 2.0, und die erlaubt es quasi, die Daten von der Maschine in maximal fünf Minuten in den Data Lake zu bekommen. Und da hast du dann deine klassischen Analysen drauf. Ich meine, in der Vergangenheit war das so ein BI-Tool, was da drauf ist, wie ein Power BI. Heutzutage sind das natürlich dann auch Machine-Learning-Modelle – da hat jemand dann so ein Jupyter Notebook oder Python und arbeitet auf den Daten. Oder ganz modern: Mittlerweile greifen auch Agenten auf die aggregierten Daten zu und auch auf den Kontext und versuchen dann, entsprechende Geschäftsprozesse zu optimieren. Auch das ist möglich.

Und wie gesagt, das ist spannend zu sehen, weil in der Vergangenheit war das immer so klassisch getrennt: alles, was realtime ist, operativ – und dann hast du diese historischen Daten in deinem Data Lake, und die sind meistens ziemlich alt, ein paar Tage oder Wochen. Das verschwindet. Mittlerweile sind wir runter auf fünf Minuten als maximale Grenze. Eigentlich bist du unter fünf Minuten, hast innerhalb von ein, zwei Minuten deine Daten im Lakehouse. Das heißt, du hast mehr oder weniger immer frische Daten für deine KI-Agenten und Anwendungen zur Verfügung.

Madeleine:

Frische Daten finde ich gut, weil es sind ja dann keine Live-Daten oder Daten in Echtzeit, sondern es sind eben einfach die Daten, mit denen man arbeitet. Es kommt ja dann immer auf den Use Case drauf an, was ich damit am Ende mache.

Jürgen:

Klar, natürlich, richtig. Und du hast natürlich auch immer noch diese Edge-Dimension. Also wir sind auch superstark im Bereich Streaming Analytics und Live. Und wenn du jetzt zum Beispiel von einer Wärmebildkamera entsprechende Images gelabelt reinbekommst und musst halt auf der Edge relativ schnell eine Entscheidung treffen, ob da eine Überhitzung ist oder eine Anomalie auftritt, um eine Warnung oder einen Alarm entsprechend zu erzeugen – dann macht man das natürlich mit einem Streaming Analytics und lässt nicht erst die Daten in die Cloud laufen und guckt, was da passiert.

Sondern man muss je nach Use Case schauen: Muss ich das auf der Edge machen, brauche ich da wirklich so ein Streaming Analytics, weil ich möglichst zeitnah dran sein will, oder reichen mir ein paar Minuten? Für viele Applikationen sind ein paar Minuten völlig ausreichend.

Madeleine:

Vollkommen. Jetzt bist du ja schon mittendrin in den Use Cases. Ich würde auch total gerne später noch mal über die verschiedenen Agenten sprechen, und ich weiß, das ist hier auch stark in diesem ganzen Thema Datenharmonisierung – da geht vieles einfacher mit KI, ich glaube, da sprechen wir heute noch drüber. Vielleicht, bevor wir da reingehen: Lass uns doch mal so ein Projekt aus eurem Pool rausfischen. Ihr habt ja so viele verschiedene Kunden. Falls es überhaupt schon eins gibt, wo das in der Praxis stattfindet – einfach, um die Praxis als Bottom Line für unsere Diskussion zu haben. Hast du da irgendein Projekt, worüber wir sprechen dürfen?

Jürgen:

Ja, ich habe natürlich vorher drüber nachgedacht und ich habe zwei Projekte mitgebracht. Die passen noch nicht so perfekt auf diese agentische KI, aber sie haben beide den Flavour drin, sodass man erkennen kann, wo die Reise hingeht. Weil viele Unternehmen – muss man einfach auch sagen – schauen sich das Thema an, die sind im Prototypenstatus, und das ist auch klar.

Ein Beispiel, was ich hier habe, ist das Thema Vision AI, und das ist mehr so die klassische KI. Da haben wir mit der SAP zusammengearbeitet. Die SAP nutzt Cumulocity in einer Business-Applikation namens Asset Performance Management, APM. Da ist Cumulocity im Bauch drin, um die entsprechende Konnektivität an Brownfield- und Greenfield-Maschinenanlagen herzustellen, die Daten reinzuholen. Dann werden die Daten auf das SAP-Asset-Modell gemappt. Das geht alles out of the box, das kriegt der Kunde gar nicht mit. Dann werden entsprechend – wie der Name schon sagt, Performance Management, also quasi Predictive Maintenance – verschiedene KPIs auf diesen Daten berechnet und dann auch entsprechende Aktionen eingeleitet, wie zum Beispiel, dass ein Techniker informiert wird, wenn ein entsprechendes Problem mit einer Maschine vorliegt oder eine Wartung fällig ist.

Und ein Use Case, den ich heute vorstelle, das ist ein Anwendungsfall im Bereich der visuellen Inspektion von Industrieanlagen, wo eine Wärmebildkamera genutzt wird. Da arbeiten wir zum Beispiel mit Sony zusammen, aber das kann natürlich auch ein anderer Hersteller sein. Die Wärmebildkamera ist dann an ein Gateway angeschlossen – kann ein Raspberry Pi sein –, der dann in dem Fall über unser thin-edge.io die Daten in die Cloud liefert.

Madeleine:

Ein Produkt von euch, sprechen wir noch drüber?

Jürgen:

Da ist ein KI-Modell, das jetzt diese Wärmebilder analysiert, und zwar direkt auf der Edge. Das ist wirklich auf thin-edge.io superleichtgewichtig. Was man machen will, ist natürlich, ungewöhnliche Überhitzungen in Echtzeit zu erkennen. So eine Wärmebildkamera kann man sich vorstellen wie Farbverläufe von tiefrot über gelb, orange und so weiter, damit man sich visualisieren kann, was ich da meine. Und das KI-Modell macht so ein Labeling, guckt sich das an und schaut dann: Wie heiß ist denn jetzt dieser Gegenstand, der gemessen wird? Und wenn eine kritische Temperatur überschritten wird, schickt das System die Erkennungsdaten automatisch über Cumulocity an das SAP Asset Performance Management, sodass das Instandhaltungsteam darauf reagieren kann.

Und was wir da machen: Wir trainieren quasi – je nachdem, was es für ein Use Case ist. Das können Wärmebilder von einem Motor sein, von einem Lager, von einem Schaltschrank, kommt drauf an. Oder auch im Bereich Qualitätskontrolle gibt es Füge- und Schweißprozesse, bei Laserschweißen oder Kunststoffschweißen oder Verkleben, wo man dann wirklich solche Vision AI einsetzt, um Temperaturprofile der Naht mitzumessen. Oder auch bei Gas- und Flüssigkeitsleckagen gibt es Infrarotstrahlung, die absorbiert wird. Und da macht es Sinn, mit so einem Vision-AI-Ansatz darauf anzusetzen.

Und was wir machen: Wir trainieren dann über den historischen Daten, also über den Daten im Lakehouse. Da hat man ja normalerweise entsprechend Langzeitdaten über die letzten Quartale. Das heißt, da wird das Modell trainiert.

Madeleine:

Ich wollte gerade fragen, woher die Trainingsdaten kommen.

Jürgen:

Genau, da werden die entsprechend trainiert. Und was wir dann machen: Das Modell, das da trainiert ist, das nehmen wir und bringen das wirklich ans Gerät ran. Entweder direkt aufs Gerät oder auf dieses thin-edge.io, also nah ans Gerät, sodass wir dann die Bilddaten da im Streaming Analytics mit auswerten. Das nennt sich dann Inferencing. Das heißt, du nimmst dann die Messdaten, also das Labeling von thin-edge.io, das geht dann ins Streaming Analytics rein, dann werden gewisse Parameter gecheckt. Und wenn dann der Schwellwert überschritten ist, wird ein entsprechendes Event generiert, das dann hoch in die Plattform geht.

Madeleine:

Okay, ganz kurz zwei Zwischenfragen. Also für die Leute, die jetzt thin-edge.io noch nie gehört haben, vielleicht weil sie noch nicht mit euch arbeiten: Vielleicht kannst du das ganz kurz einordnen. Und was heißt genau „aufs Gerät zurück"? Also dann auf die Wärmebildkamera, auf ein Edge-Device – oder ist die Wärmebildkamera das Edge-Device? Das sind noch mal kurz zwei Zwischenfragen.

Jürgen:

Genau, also thin-edge.io ist unser Open-Source-Framework, um Daten von einem Gateway, von einer PLC und so weiter einfach in die Cloud zu kriegen. Da ist so ein Broker drin, also nach unten ist man relativ flexibel, was die ganze Datenanbindung, Protokolle und Unterstützung angeht. Und dann ist da ein Messaging Broker drin, der die Daten mehr oder weniger nimmt und in Cumulocity hochschickt. Der kann aber auch in andere Clouds hochschicken. Also das ist ein Open-Source-Framework, das ist nicht auf Cumulocity zugeschnitten, funktioniert natürlich perfekt mit Cumulocity, kann aber auch die Daten in Azure oder AWS ablegen.

Madeleine:

Okay, also so ein IT/OT-Integrationslayer sozusagen. Macht die Datenerfassung, gibt sie weiter.

Jürgen:

Genau, so eine Brücke quasi von einem Gateway, von der PLC – eine Brücke in die Cloud. Das war die erste Frage. Und die andere Frage, was ich mit Action meine: Das kommt immer ein bisschen drauf an, was da im Use Case verwendet wird. Wenn diese Kamera mächtig genug ist, das Modell auszuführen … Und so ein Raspberry Pi – da gibt es so ein Kameraplugin, wo man die Kamera wirklich einfach nur anstöpselt, und dann läuft das ganze Ding, dieses Modell und das Inferencing, auf diesem Raspberry Pi. Also es kommt immer drauf an. Manchmal hat man auch so einen Retrofit, und dann läuft es eher auf dem Gateway. Das muss man sich genau anschauen, wie das gemacht ist. Aber ja, ich wollte nur sagen: Der Footprint, der dafür gebraucht wird, ist klein. Also es sind wirklich ein paar Gigabyte RAM, nicht mehr. Da braucht man nicht sehr viel für.

Und was man dann macht, ist – das nennt sich technisch ML Ops. Das heißt, ich bekomme ja ständig wieder neue Daten von meinen Maschinen rein, die gehen dann in meinen Data Lake, dann lerne ich das Modell wieder. Also ich habe einen kontinuierlichen Verbesserungsprozess: neue Daten, ich trainiere mein Modell, kriege eine bessere Version vom Modell, und die bringe ich dann mit dem Deploy entsprechend wieder runter auf die Edge. Und das unterstützt Cumulocity auch out of the box. Das machen wir klassisch über unsere Device-Management-Funktionen. Ein Machine-Learning-Modell ist einfach eine Software mit einer neueren Version. So ist es implementiert.

Madeleine:

Cool. Und in diesem Use Case bleibt die KI ja auch auf der Empfehlungsebene für die Personen, die das eben entsprechend wissen müssen. Es macht keine autonomen Eingriffe zurück, oder? Also dass man jetzt sagt … das wäre ja dann vielleicht auch das Thema, worüber wir heute sprechen, AIoT. Sorry, habe ich schon was vorweggenommen.

Jürgen:

Ja, das ist jetzt der zweite Schritt, genau. Und das ist auch das Spannende. Also in dem Moment generiert dieses klassische Machine Learning … Ich habe da ja auch normalerweise relativ hochfrequente Daten, ich kriege ja alle Sekunden oder mehrfach pro Sekunde neue Daten. Da möchte ich kein LLM drauf anwenden, da würden meine Token explodieren. Das heißt, da nehme ich klassisches Machine Learning. Und dann generieren wir diese Events, also zum Beispiel eine Anomalie: Die Temperatur ist zu hoch, das Ding ist leuchtend rot. Das ist der Event. Dann weiß ich: Die Kamera hat jetzt so ein Event festgestellt, zu dem Zeitpunkt.

Und was ich jetzt mache: Das gebe ich entsprechend in einen KI-Agenten rein. Also jetzt kommt ein LLM, und das macht dann eine Root-Cause-Analyse, weil es weiß: Die Kamera sitzt an diesem Motor, in dieser Anlage, hier in der Fabrik. Und das ist vielleicht noch weiterer Kontext: Es ist eine Pumpe oder ein Motor von der und der Firma et cetera, ich habe da einen Wartungsvertrag oder nicht et cetera. Und dieser Kontext, der wird dann vom LLM mitinterpretiert.

Und dann könnte das LLM – und da haben wir auch schon Prototypen, aber das ist noch nicht produktiv – dann gibt das LLM einen Hinweis an den Anwender und sagt: Hey, vermutlich hast du hier ein Problem, das scheint die Ursache zu sein, hier ist mein Vorschlag für die Behebung von dem Problem. Und dann kann der Fachanwender sagen: Verstehe ich, machen wir so. Oder: Nee, du liegst völlig falsch, wir machen es anders. Es ist immer noch ein Mensch, der das entscheidet.

Madeleine:

Okay, das heißt, wir haben quasi den klassischen ML-Ansatz, dann haben wir das Large Language Model, also das ist die nächste Stufe. Und AIoT wäre dann ja noch mal eins drauf, zu sagen: Ein Gerät oder eine Maschine würde vielleicht auch selber entscheiden. Da reden wir aber über die Zukunft, noch fünf Jahre entfernt wahrscheinlich, oder?

Jürgen:

Ja, genau. Technisch ist es möglich, das muss ich schon sagen. Technisch ist es möglich. Wir bauen auch gerade in Cumulocity relativ starke Auditierungs- und Freigabemechanismen ein, weil da ist natürlich ganz wichtig, dass man klar abchecken kann: Hat so ein KI-Agent eine Empfehlung gemacht und hat der Nutzer die entsprechend geprüft und freigegeben?

In Zukunft, klar, wenn man über diesen Trend industrielle KI spricht, hört man oft auch so was wie Zero Touch Industries oder Dark Factory. Das hast du wahrscheinlich auch schon mal gehört, wo dann wirklich alles autonom läuft. Und dann möchte man ja hin in diese autonomen Betriebsprozesse. Aber das ist noch eine ganze Weile. Also bevor wir hier im Blindflug eine Fabrik steuern, das wird noch eine Weile dauern.

Deswegen ist dieser Ansatz – Human in the Loop heißt das dann technisch – denke ich der geeignete, wo dann ein KI-Agent genutzt wird, um einfach eine Menge Recherchearbeit zu machen. Der guckt dann in den Logfiles, bereitet das alles auf für jemanden, der dann ein Fachexperte ist, und der kann dann drauf gucken und prüft das. Aber der Mensch trifft immer noch die Entscheidung, ob jetzt da irgendwas gestoppt wird oder ersetzt wird und so weiter.

Madeleine:

Genau, das ist auch wichtig. Ich glaube, wenn du das jetzt schon so beschreibst, bei vielen gehen ja auch schon die Alarmglocken los, was solche Themen angeht, weil das ja auch securityseitig einfach ein Riesenthema ist. Ich weiß auch bei uns in der Community: Die stellen sich gerade im Bereich Security neu auf. Da ist ganz viel Ausbauarbeit, die gerade gemacht wird, bevor man so was auch angeht. Und man muss ja auch ein bisschen abgrenzen: Was ist da jetzt Hype und was ist Zukunft? Aber umso schöner zu sehen, dass es solche Projekte eben schon gibt und wie es dann entsprechend funktioniert.

Jürgen:

Ich hatte aber noch ein Beispiel dabei, das zweite. Da machen wir wirklich autonome Aktionen.

Madeleine:

Eine Frage noch, bevor ich es vergesse: Du hast von Tokens gesprochen. Um die Leute ein bisschen abzuholen, die da vielleicht nicht so tief drin sind – kannst du mal erklären, wann brauche ich denn einen Token und wann kostet mich das Geld? Ich kann mir vorstellen, viele, die jetzt in die ersten Piloten gestartet sind, müssen das Ganze ja verstehen, die rechnen vielleicht auch einen Business Case. Kannst du mal erklären, wann kostet die KI mich hier eigentlich richtig Geld und wo muss ich aufpassen?

Jürgen:

Klar, das kennen wahrscheinlich viele auch aus dem privaten Umfeld. Da hat man wahrscheinlich auch so einen Gemini oder einen Anthropic im Einsatz, und da muss man auch verschiedene Pläne bezahlen, je nachdem, was man damit macht.

Und in Cumulocity ist das Ganze so aufgesetzt – weil wir finden es sehr wichtig, und auch unsere Kunden spiegeln uns das zurück: Die möchten natürlich die Kontrolle über ihre Daten haben und auch über ihre KI-Modelle. Weil da steckt eine Menge IP drin, also Intellectual Property. Und was man natürlich vermeiden möchte, ist, dass jetzt irgendein Hersteller anfängt, an den Betriebsdaten von so einem Maschinenpark oder einer Industrieanlage seine Modelle zu trainieren und sich dann entsprechend über dieses Domänenwissen entsprechendes IP aufzubauen, das er vielleicht an andere Kunden verkauft. Das ist so die Gefahr auch.

Da spielen wir auch sehr sauber. Ich meine, wir sind einer der größten europäischen Hersteller, und für uns sind Datensicherheit und diese Themen Governance und Vertrauen sehr wichtig. Das können wir supergut verstehen, und da möchten wir uns auch differenzieren von anderen Anbietern. Deswegen kann man in Cumulocity quasi das LLM konfigurieren. Also wenn man heute in Cumulocity reingeht, gibt es so eine Komponente, die heißt Agent Manager. Da kann ich dann meine AI Agents aufsetzen und konfigurieren, also welche Daten die zugreifen dürfen und so weiter. Und ich muss da auch mein LLM einstellen. Das heißt, da kann natürlich ein Unternehmen sagen: Ich setze unternehmensweit auf Anthropic oder auf Gemini oder was auch immer. Das hat aber die IT im Griff und steuert die IT. Und dann wird dieses LLM genommen, auch für die Agenten in Cumulocity, entsprechend als Plattform für die Agenten.

Und das ist für die IT immer sehr schön, weil dann haben sie das alles in ihrem vordefinierten, sauberen Rahmen. Da gibt es keine Schatten-IT, wo irgendwelche Leute da was aufmachen und Daten laufen weg. Und das ist sehr, sehr wichtig.

Und in dem Beispiel, was wir mit der Wärmepumpe hatten, diese Events: Sobald dann dieses LLM, also dieses Large Language Model, anfängt, Recherchen zu machen über die Root-Cause-Analyse – warum ist denn jetzt diese hohe Hitzeentwicklung aufgetreten? –, da geht natürlich dann so ein KI-Modell ran und fragt irgendwelche APIs ab: vergangene Daten von der Maschine, vielleicht den Kontext über unseren Digital Twin Manager. Da kann es sehen: Die Pumpe oder der Motor, der sitzt in der und der Linie, in der und der Anlage, in dem und dem Werk, der wurde zuletzt da und da gewartet. Und das sind natürlich alles API-Anfragen und MCP-Anfragen – also Model Context Protocol ist ein anderer Begriff –, wo die Agenten dann letztlich diesen Kontext abgreifen. Und immer wenn sie das tun und auswerten, verbrennen die Token. Das ist so die Metrik, die die LLMs verwenden. Und das kostet Geld.

Madeleine:

Das heißt, wenn ich sozusagen meine KI-Funktion intern in den Werken ausrollen möchte, sollte ich mir auch Gedanken machen, wie diese Architektur wahrscheinlich aussieht. Oder wie ich dann diesen … also diesen Agent Manager, den ihr schon habt – ich weiß nicht, ob viele Betriebe sich den gerade selber bauen. Das ist ja genau euer Case, zu sagen: Hey, guckt euch das mal an. Aber da sollte ich wahrscheinlich höllisch aufpassen, wie ich das aufsetze, weil das kann ja auch schnell mal richtig Geld kosten, wenn ich das nicht mitdenke, oder?

Jürgen:

Genau. Und vor allem muss man halt auch aus einer Security-Brille das Ganze durchdenken: Welche Agenten haben Zugriff auf welche Daten, und wo werden die Modelle überhaupt trainiert? Laufen die in irgendeinen amerikanischen Hyperscaler rein, den ich nicht kontrollieren kann, oder bleiben die bei mir? Solche Fragen muss man sich stellen.

Madeleine:

Genau. Und auch: Welche Daten gebe ich dann zum Beispiel einem Hersteller, weil es halt Sinn macht? Du hast jetzt das Wärmebildkamera-Beispiel genannt – teile ich die mit dem Wärmebildkamera-Hersteller oder eben nicht? Also das muss man sich ja dann auch fragen: Wann macht es Sinn, vielleicht auch das mit einem Hersteller zu teilen, vielleicht bei größeren Anlagen?

Jürgen:

Auch das Teilen von Daten, ja. Und die Agenten … ich meine, die Applikationen entwickeln sich ja immer mehr Richtung Agenten. Das muss man ja auch noch mal sehen, so als Transformation: In der Vergangenheit waren die Anwendungen eher SaaS-Anwendungen, also viele User Interfaces, wo dann Fachanwender geklickt haben und ihre Regeln definiert haben, und da hatte ich meine Dashboards. Das ändert sich jetzt alles, auch durch die KI, sodass ich in Zukunft nicht mehr nur menschliche Anwender habe, die meine UIs nutzen, sondern immer mehr – vermutlich in Zukunft sogar überwiegend – Agenten, die meine APIs und MCPs abfragen.

Ich denke, das Cockpit oder die UIs werden nicht ganz verschwinden. Also ein bisschen was braucht man, glaube ich, schon, um die wichtigsten Betriebsprozesse auch mit KPIs zu visualisieren und zu überwachen. Aber es wird sich ganz, ganz stark Richtung Agenten als Hauptnutzer von so einer AIoT-Plattform verschieben.

Madeleine:

Interessant. Übrigens, wenn ihr jetzt zuhört und sagt: Ey, wir arbeiten gerade an so einem Projekt oder wir wollen so ein Projekt umsetzen – Jürgen, ich würde deine Kontakte auf jeden Fall mal in die Shownotes packen. Schaut euch mal an, was Cumulocity da gemacht hat.

Und wir haben bei uns auch einen Anwenderkreis – wollte ich kurz als Einladung aussprechen. Wenn ihr sagt: Ey, ich will mich erst mal mit anderen dazu austauschen, wie machen die das? – kommt einfach rein. Wir haben da einen monatlichen Termin, nur unter Anwendern. Da könnt ihr auch einfach mal vorbeischauen. Ich packe es euch alles in die Shownotes, oder schaut auf iotusecase.com. Und auch die Seite von Cumulocity packe ich euch mit rein. Guckt da mal vorbei, weil es ist wirklich spannend und einfach auch ein schöner Hebel, so was vielleicht nicht selber zu entwickeln – oder auch meines Erachtens mal zu hinterfragen: Was habe ich denn gerade, ist das skalierbar für eben solche AI-Use-Cases? Sorry, Jürgen, gerne noch ergänzen.

Jürgen:

Du kannst auch gerne den Link in die SAP Community noch reinpacken. Dieses Vision-AI-Beispiel ist dokumentiert, auch supertechnisch – also für Leute, die gern tief gehen und genau sehen wollen, wo die Daten fließen, wie die entsprechenden Modelle deployed werden. Da kann ich einen Link bereitstellen, wo ihr das noch mal superdetailliert nachlesen könnt.

Madeleine:

Auch gut, stimmt. Okay, bevor wir jetzt in das Thema weitere Agenten und Use Cases kommen – weil wir wollen gleich noch beantworten: Wie geht denn Datenharmonisierung vielleicht auch? Also es gibt ja ganz viele, die jetzt auch ziemlich viel manuelle Arbeit reinstecken in solche Datenharmonisierungsthemen. Darüber würde ich gleich noch sprechen. Aber du hast noch ein zweites Beispiel, da wollte ich dich jetzt nicht unterbrechen.

Jürgen:

Ja, wo es um Autonomie geht und autonome Betriebsabläufe. Wir hatten ja gerade ein bisschen über die Vorsicht gesprochen, den Agenten die volle Kontrolle zu geben und alles autonom ablaufen zu lassen. Aber es gibt Kunden von uns, die haben – auch wenn es nur kleine Teile sind – komplett automatisiert. Und Enercon ist da ein super Beispiel.

Also Enercon, ganz kurz im Hintergrund: Enercon entwickelt, produziert und vertreibt Onshore-Windenergieanlagen, die man in Deutschland ja an vielen Stellen auch sehen kann. Die machen das aber auch weltweit, also die haben auch Anlagen in Alaska und sogar am Südpol oder in der Antarktis. Und mehr als 30.000 Windturbinen weltweit. Und das ist ein Riesenkunde von uns natürlich und auch eine wahnsinnige Datenmenge: Da kommen von diesen 30.000 Windturbinen pro Sekunde 500.000 Datenpunkte an. 500.000 Datenpunkte pro Sekunde – das sind 43 Milliarden Datenpunkte pro Tag, die da in die Plattform reinlaufen.

Madeleine:

Mein Gott, und das von so einer Anlage. Da ist ja keine große Infrastruktur, die stehen ja irgendwo mitten im Nirgendwo auch, wahrscheinlich.

Jürgen:

Genau. Und das läuft dann alles in ein entsprechendes Lakehouse rein, aber auch durch Cumulocity durch. Wenn man mal so guckt: Eine Ausfallzeit, wenn so eine Turbine einen Tag ausfällt, kostet im Schnitt 8.000 Euro. Und jetzt hat Enercon dann so ein Remote-Service-Team – das sind mehrere hundert Leute, die arbeiten im Schichtbetrieb und die stellen quasi 24/7 sicher, dass die Anlagen laufen, dass, wenn was ist, erst mal versucht wird, das Ganze remote zu lösen. Wenn nicht, muss jemand vor Ort gehen, das wird aber dann teuer.

Ich meine, den Betrieb kann man sich so vorstellen: Die haben mehrere hunderttausend eingehende Service Calls im Jahr, mehrere Millionen SCADA-Alarme und so weiter. Also es ist eine riesen Plattform, die da läuft. Und die Automatisierung von Arbeitsabläufen ist da essenziell, um einfach Geld zu sparen.

Und was die gemacht haben: Die haben für den Remote-Service-Nutzer – also die Leute, die an diesem Bildschirm sitzen und den Betrieb überwachen – … die haben wir in die Lage versetzt, tägliche Routineaufgaben zu vereinfachen, mit unserem Analytics Builder. Das ist so ein Self-Service-Tool, wo sie analytische Modelle entsprechend abbilden können, ohne dass sie coden müssen. Und da hatten wir einen spannenden Use Case, wo die entsprechend eine Turbine neu starten, basierend auf einem klar spezifizierten Muster. Bisher war es so: Da kam ein Ticket an, und dann hat wirklich ein Mensch geprüft: Sind die und die Parameter erfüllt, passt das alles? Wenn das so war, hat er einen Button gedrückt, und dann wurde die Turbine neu gestartet. Und das war halt ein deterministisches Muster.

Und das haben wir jetzt quasi in diesem Analytics Builder abgebildet. Und jetzt überprüft quasi die Maschine, ob die Parameter und Bedingungen gegeben sind. Und wenn das der Fall ist, stößt die Maschine über Cumulocity einen Reset von der Windturbine an. Und das ist so eine automatisierte Remote-Aktion. Das ist in dem Fall nicht KI. Da ist keine Wahrscheinlichkeit dahinter oder irgendwelche Interpretationsspielräume, das ist klassisches Abprüfen von einer Menge von Parametern. Und wenn alle Konditionen und Parameter gegeben sind, dann macht er es. Aber trotzdem ein cooles Beispiel: Damit konnten die circa 40 Prozent ihrer Turbinen-Restarts automatisieren, und das ist eine Einsparung im mehrstelligen Millionenbereich.

Da sieht man aber, welche Power … deswegen habe ich das Beispiel mitgebracht. Das ist jetzt keine angewandte KI in dem Sinn, aber man sieht, welche Power in dieser Automatisierung steckt. Deswegen glaube ich, man muss halt Stück für Stück dahin gehen. Und wenn man sich dem annähert, kann da wirklich eine Menge Mehrwert geschaffen werden. Von daher denke ich, dass diese Richtung industrielle KI, vernetzte, automatisierte Betriebsabläufe schon die richtige ist. Man muss halt nur sicherstellen, dass alles nachvollziehbar und sauber funktioniert.

Madeleine:

Total. Ich meine, als Unternehmen muss man auch erst mal eine Entscheidung treffen, dass man den Menschen, der das ja bislang gemacht hat, überhaupt erst mal … also dass man das jetzt automatisiert. Das ist ja schon ein mutiger Schritt erst mal. Und wenn man den Business Case aber sieht, macht das ja total Sinn, dass dieser Mensch sich auch anderen Aufgaben wieder widmen kann, weil das ja ein wiederkehrendes Problem war.

Und ist auch interessant – ich denke mal, viele da draußen müssen ja auch erst mal diesen Use Case finden, wo man sich, ich sage mal, noch traut, auch diesen Weg zu gehen. Das macht ihr wahrscheinlich nicht in jedem Use Case, da muss man ja auch höllisch aufpassen. Aber es gibt eben diese Use Cases, wo es eben Sinn macht. Finde ich spannend.

Jürgen:

Genau, so ist es. Man fängt erst mal mit Rand-Use-Cases an, wo es, wenn es mal schief geht, dann nicht gleich katastrophal ist. Ist ja auch logisch.

Madeleine:

Siehst du bei solchen Use Cases einen Schwerpunkt in den Branchensegmenten? Also ihr seid ja auch vertikal unterwegs, ihr habt verschiedenste Kunden in allen Branchen. Gibt es da irgendwo Use Cases, die eben auch basierend auf oder gekoppelt mit AI schon funktionieren, wo du sagst, da gibt es einen Schwerpunkt? Kristallisiert sich da mittlerweile was raus, oder ist es noch total schwer zu sagen?

Jürgen:

Ich glaube, in diesem Bereich Distributed Energy Resources, also Energie, Utilities, da ist gerade schon eine Menge Musik drin. Da ist die Innovationsgeschwindigkeit relativ hoch.

Im Manufacturing gibt es natürlich auch erste Anwendungsfälle, da sind wir auch mit einigen Kunden dran. Aber unser Fokus ist jetzt nicht so stark auf dem Shopfloor, sondern wir sind ja mehr … wenn es darum geht, verteilte große Flotten anzuschließen, sind wir stärker als in so einem einzelnen Shopfloor-Automatisierungs-Use-Case. Von daher: im Medizintechnikbereich, Defense haben wir auch derzeit einiges, wobei Defense natürlich sehr konservativ ist. Da kommt es dann wieder mehr darauf an, dass wir in der Lage sind, in der Sovereign Cloud zu deployen.

Auch im Bereich Medizintechnik ist der Schwerpunkt derzeit weniger auf einer agentischen KI, sondern immer mehr noch im Bereich OT/IT-Anbindung, Security, Zertifizierungen und die Daten überhaupt erst mal greifbar zu machen. Das ist ja der wichtige Schritt. Es ist ja toll, wenn man oben dann die AI-Agenten hat, die dann zusammenarbeiten und das weiter automatisieren. Der Knackpunkt ist ja erst mal: Ohne eine sichere, angeschlossene Flotte brauchen wir gar nicht anfangen. Das ist der erste Schritt. Wenn die Flotte nicht sicher angeschlossen ist, kann man schon aufhören. Dann geht es um die Datenaufbereitung. Wenn ich schlechte Daten in meine KI gebe, kommt auch nur Mist raus.

Madeleine:

Genau. Ich würde gerne zum Ende noch mal … du fängst ja jetzt auch schon an, hier richtige Ratschläge mitzugeben und dein Wissen preiszugeben. Vielleicht können wir zum Ende das noch mal ein bisschen zusammenfassen, was so deine Abschlussratschläge wären für Firmen, die da unterwegs sind.

Ich habe noch eine vorherige Frage, um vielleicht auch das zusammenzufassen, was wir gerade besprochen haben. Also du hast ja jetzt verschiedenste Use Cases auch auf dieser AI-Seite genannt. Kriegen wir so die Top-5-Use-Cases zusammen, wo du sagst: Hey, das sind eigentlich so die Use Cases, die jetzt schon funktionieren? Einfach auch, um das für sich als Betrieb mal bewerten zu können: Können wir da was machen, haben wir da schon was gemacht? Können wir die mal zusammenfassen?

Jürgen:

Da würde ich aus einer Cumulocity-Sicht fast in so eine Richtung horizontaler Anwendungsfälle gehen. Natürlich haben wir jetzt zum Beispiel die Vision AI, oder jetzt auch im Bereich Energy und Utilities gibt es natürlich auch wirklich domänenspezifische Use Cases. Aber wir haben ja eine AIoT-Plattform, und da haben wir gesagt: Was können wir denn unseren Kunden an die Hand geben?

Und da ist ein ganz spannender Use Case diese Datenharmonisierung – hast du ja auch schon mal kurz angesprochen. Das ist so ein ganz altes IoT-Problem. IoT ist ja superheterogen, ich habe unterschiedlichste Protokolle, alte, superalte Geräte, aber auch ganz neue, und ich muss mit diesem Zoo an Geräten und Protokollen einfach leben und muss diese Daten nutzbar machen. Und da haben wir jetzt KI drauf losgelassen.

Und zwar haben wir einen – das heißt technisch Expert Agent, also eine KI-gestützte Komponente in Cumulocity. Und was die macht: Die liest quasi so einen Moment von Live-Daten auf einem eingehenden Datenstrom mit, also einem Messaging-Kanal, guckt sich die Rohdaten an und schlägt dann dem Anwender vor, wie die ins Cumulocity-Format überführt werden.

Und das war in der Vergangenheit immer – wenn es jetzt nicht gerade so ein neues Protokoll ist wie OPC UA oder MQTT – immer mit Coding verbunden. Und weil das Payload ja auch oft unterschiedlich ist, da musstest du immer mit einem Menschen Hand anlegen, bis die Daten sauber in Cumulocity drin waren. Das hat jede Plattform, das ist jetzt nicht Cumulocity-spezifisch: Ich habe verschiedenste Daten, die hier ankommen, und die muss ich erst mal greifbar machen. Und das macht mittlerweile ein Agent.

Madeleine:

Genau, nur dass ich es verstehe: Das heißt, in dem Beispiel, was du vorhin genannt hattest, Wärmebildkamera – wäre das sozusagen eine Wärmebildkamera oder mehrere, die vielleicht in einer Halle vernetzt sind, und dann gibt es noch andere, die eben in einem anderen Werk stehen. Und diese Benennung, also diese Zuordnung, die hat man ja vielfach auch manuell gemacht, dass man sagt: Das ist der Datenpunkt, der heißt so und so, das ist jetzt vielleicht ein Temperatursensor. Dieses Naming oder diese – wie sagt man – Datenpunktbenennung, das ist das, was vorher manuell war?

Jürgen:

Genau. Die Datenpunktbenennung ist eins, die Einheiten sind das andere. Und wie wird es überhaupt übertragen, wenn ich jetzt so ein Image habe? Wie stelle ich das Image dar? Das macht man ja dann mal als Vektor, damit ich für verschiedene Spalten dann Sachen reinschreibe. Und das kann ja jeder Hersteller, der macht das wieder anders. Und damit muss man halt zurechtkommen.

Und wir haben das jetzt in der Praxis mit verschiedenen Formaten getestet: natürlich mit OPC UA, Modbus, aber auch LoRaWAN, Protobuf, CBOR, Sparkplug, JSON und so weiter. Und das Coole ist wirklich: Das funktioniert erstaunlich gut. Wir haben dann in diesem Produkt – dann schlägt er quasi so eine Smart Function vor, ein JavaScript, wie er die Eingangsdaten jetzt ins Cumulocity-Format überführt, und erlaubt auch gleichzeitig das Debugging, also das Testen. Und das spart einem erstaunlich viel Arbeit bei der Entwicklung. Und das ist so ein Anwendungsbeispiel, wo wir ein altes Problem im IoT, wo man immer Hand anlegen musste, über einen KI-Agenten revolutionieren und automatisieren.

Madeleine:

Interessant. Ist es eigentlich auch so, wenn es zum Beispiel um den Rollout von Edge-Devices geht? Also wenn ich jetzt zum Beispiel mehrere Edge-Devices habe – ich habe da jetzt gerade eine Anfrage bei uns im Netzwerk vorliegen –, da muss man ja verschiedene Konfigurationen auch vornehmen. Gibt es diese Möglichkeit auch für Edge-Devices, dass ich sage, ich kann vielleicht die Konfiguration automatisch einspielen, wenn ich so ein neues Edge-Device habe? Also nur mal was anderes.

Jürgen:

Ja, da sind wir dran. Das ist aktuell bei uns in der R&D ein heißes Thema, kann ich dir sagen, Madeleine. So ein Software-Rollout-Agent ist auf unserer Agenda, der ist jetzt noch nicht im Preview drin. Ich meine, Cumulocity kann das heute auch schon: Du kannst da Device-Profile definieren und wir unterstützen Bulk-Updates. Aber es ist halt immer manuell, da muss immer jemand klicken, und dann läuft im Hintergrund ein Prozess, der dann auch natürlich trackt: War es erfolgreich oder müssen wir es noch mal probieren?

Und das wollen wir halt mit einem Agenten automatisieren, sodass du einfach sagen kannst: Hier ist eine neue Softwareversion, bitte deploy mir die auf alle Geräte von dem und dem Typ in Europa oder in China. Und dann macht er das im Hintergrund automatisch und gibt dir Bescheid, ob es geklappt hat oder ob irgendwo Probleme sind. Und da sind wir dran, absolut.

Madeleine:

Okay. Genau, das meintest du: erst Datenharmonisierung, wie du es gerade genannt hast, da geht es zum Beispiel um das Mapping der Daten, jetzt zum Beispiel von einem Sensor ausgehend. Oder in ein Asset Management hinein, sozusagen dieses Onboarding. Kann man das so sagen?

Jürgen:

Genau. Was das überhaupt für ein Messpunkt ist: Ist das ein Temperatursensor oder ein Drucksensor, ist die Einheit Celsius oder Fahrenheit? In dem einen Werk heißt der Sensor Hugo, in dem anderen Werk heißt der Sensor Willi. Die Benamung da draußen, die ist ja nicht einheitlich. Die kann man ja auf der PLC sehr flexibel setzen, und das wird auch leider ausgenutzt.

Madeleine:

Genau. Wahnsinn. Ich habe ja auch schon so viele Folgen zum Thema Verwaltungsschale und so weiter gemacht, was es da nicht für Ansätze gibt.

Jürgen:

Ja, oder das ganze Thema Unified Namespace, kurz UNS. Genau, da ist ja genau das auch drin.

Madeleine:

Spannendes Thema. Also wenn ihr daran interessiert seid, folgt einfach dem Podcast, da gibt's eine Menge zu dem Thema.

Jürgen:

Der andere coole Use Case ist natürlich diese AI-unterstützte Entwicklung. Du kannst heute in Cumulocity … früher hatten wir natürlich auch so ein Cockpit, wo du wirklich deine Dashboards zusammenklicken konntest, da hast du gesagt: Hier hätte ich gerne einen Line Chart, hier hätte ich gerne so eine Ampel und hier hätte ich gerne, was weiß ich, so einen Speedometer oder so was. Und das kannst du heute alles über den Agenten machen. Du sagst ihm einfach: Baue mir ein Dashboard für den Anwendungsfall, hab das und das drauf. Und der weiß dann, welche Datenpunkte er von Cumulocity greift, wie er die andockt, und baut dir das Dashboard fertig. Musst du nicht mehr coden oder klicken, macht der Agent für dich. Das sind so typische Anwendungsfälle, die funktionieren halt überall, in allen Domänen.

Madeleine:

Das ist cool, genau, das ist auch so ein typischer Use Case. Das heißt, wir haben jetzt quasi: Harmonisierung ist der eine Use Case, wo es ja auch Agenten für gibt. Dann haben wir die AI-unterstützte Entwicklung. Hast du noch drei andere? Oder wir haben ja auch schon darüber gesprochen, was es noch für welche gibt. Vielleicht kriegen wir auch drei zusammen.

Jürgen:

Ja, an dem Rollout Agent sind wir entsprechend auch noch dran. Wir sind auch dran zum Beispiel im Bereich IT/OT-Security. Durch die AI – der Nachteil ist, die findet schneller Vulnerabilities. Hast du ja auch mitbekommen, sicherlich, was da passiert ist: Teilweise haben die Agenten ja wirklich Sicherheitslöcher gefunden, viel schneller, als es sich die Menschen gewünscht hätten. Das Gute ist aber: Du kannst auch solche Agenten einsetzen, um schnell wieder Sicherheitslöcher zu stopfen. Sodass man sich auch in dem ganzen Bereich IT/OT-Security so einen Expert Agent vorstellen kann, der einfach sicherstellt, dass seine Flotte immer auf aktuellstem Stand ist, dass die Vulnerabilities getestet werden und so weiter. Also da gibt es verschiedenste Ideen, die wir über Expert Agents in Cumulocity noch haben.

Das Spannende, aber auch ein wichtiger Bereich ist auch, die Daten von Cumulocity externen Agenten zusammenzustellen. Cumulocity ist eine tolle Plattform, aber wir wissen: Für diese Geschäftsabläufe sind wir nur einer von vielen Playern, eines von vielen Systemen, die da angebunden werden müssen. Das heißt, da gibt es auch externe Agenten, die auf die Daten zugreifen müssen. Und da sind wir auch stark am Investieren, wie wir einen starken MCP-Server bereitstellen können, sodass auch ein Joule Agent oder ein anderer externer Agent von einem Kunden Daten von Cumulocity mit dem Kontext abgreifen kann.

Weil der Kontext ist das Wichtige. Rohdaten allein, das ist einfach nur Rauschen, wenn du willst, das bringt nichts. Du musst wissen: Das ist ein Temperatursensor, der misst in Celsius, der sitzt an der und der Maschine, in der und der Halle. Ohne den Kontext bist du quasi verloren. Deswegen ist es so wichtig, diesen Kontext bereitzustellen, und das geschieht in Cumulocity über diesen Digital Twin Manager und dann über den MCP-Server.

Madeleine:

Okay, cool. Und ihr habt ja auch bei euch ein entsprechendes Netzwerk, weil du jetzt auch externe Datenquellen oder Ansatzpunkte angesprochen hast, die da verbunden werden müssen. Da habt ihr ja auch ein riesen Ökosystem. Das heißt, ihr arbeitet aber trotzdem auch immer noch mit Partnern zusammen. Wenn es in spezifische Use Cases reingeht, kann ich mir das konnektieren, wie ich es brauche. SAP hast du ja auch genannt als Partner, wahrscheinlich gibt es da viele verschiedene.

Jürgen:

Ja, mit Microsoft an dem OT/IT-Security-Thema, SAP – ganz, ganz strategischer Partner für uns, wo wir dann die Daten auch in die Business Data Cloud ablegen und oben kommt dann die SAP Business AI mit dem Joule drauf, sodass wir quasi die SAP-Agenten auch füttern können.

Und da ist auch der ganz entscheidende Teil, dass diese rohen Maschinendaten ohne Kontext nutzlos sind. Das heißt, du musst immer die Lücke zwischen OT-Daten und Unternehmenskontext schließen. Und das geschieht in der Zusammenarbeit mit SAP relativ schön, weil wir da die SAP-Asset-Modelle direkt mit dem Cumulocity Digital Twin Manager in Verbindung setzen. Weil die OT-Welt, also die Realität, sagen wir es mal so, die sieht immer anders aus als so ein logisches Modell im ERP. Und was wir machen: Wir verlinken das in der Plattform, und dadurch sehen dann die Agenten die logische Welt, wie das Asset dargestellt ist, und wir haben unten die Komplexität – die Daten kommen aus dem Historian, die Daten kommen über den LoRa-Sensor rein und so weiter. Darum kümmert sich Cumulocity.

Und mit diesem Kontext, dann kann der Agent wirklich was machen. Der versteht ja, was er da überhaupt machen soll. Ansonsten macht er einfach nur wilde Anfragen auf den APIs, fängt an zu halluzinieren und verbrennt eine Menge Token. Und das ist vielleicht auch so ein Learning: dass diese Kontextschicht, dieser Semantic Layer, wie wir das auch im Englischen nennen – da spielt die Musik. Und die ist domänenspezifisch. Deswegen brauchen wir auch domänenspezifische Partner. Weil diese Semantikschicht sieht natürlich im Bereich Produktion anders aus als im Bereich Energie und Utilities. Ist ja auch völlig klar.

Madeleine:

Hast du mal ein Beispiel, wie diese Kontextschicht in der Praxis aussieht? Also nur, dass man es greifen kann. Ein Beispiel vielleicht mit dieser Wärmebildkamera – kannst du das so anwenden?

Jürgen:

Ja, also was ich mit Semantic Layer meine: Das sind wirklich die Metadaten von den Datenpunkten. Das ist ein Temperatursensor in Celsius. Das ist ein Drucksensor. Hier ist eine Wärmebildkamera, die liefert dir Bilder in dem und dem Format. Das ist das eine. Dann hast du aber auch die Asset-Hierarchien und Relationships. Du weißt genau, wo der Sensor verbaut ist. Weil: Wo soll der KI-Agent das denn herwissen? Der sieht natürlich dann irgendwelche Messwerte, ist erst mal komisch, und die ändern sich über die Zeit. Also ohne Kontext ist der mehr oder weniger hilflos.

Aber wenn er weiß: Der Sensor sitzt in der Komponente, in der Maschine, in dem Werk – und der andere Sensor sitzt direkt daneben. Oder nimm das Windturbinen-Beispiel: Das sind zwei Windturbinen im gleichen Windpark. Das ist so ein Kontext. Oder auch die Produktdokumentation mit den ganzen Fehlermeldungen: Wenn jetzt eine Fehlermeldung von einer Pumpe kommt, 4711 – was heißt das? Aber wenn ich allein schon weiß, die Pumpe macht gerade einen Fehler, hier ist die Dokumentation – der Agent liest das Handbuch. Der Mitarbeiter vielleicht nicht so gern, aber der Agent liest das, der findet das raus. Das meine ich mit Kontextschicht. Das musst du abbilden und zugreifbar machen.

Madeleine:

Klar. Und mit SAP habt ihr natürlich eine fantastische Partnerschaft. Aber wie du sagst, es gibt verschiedenste Domänen, da braucht man natürlich einfach verschiedenste Partner, die das dann abbilden und wo man eben diese Kontextschicht dann bilden kann. Macht ihr das mit Kunden eigentlich auch selber, dass ihr da beratend reingeht und sagt, wir helfen euch, diesen Kontext aufzubauen? Oder machen das dann Systemintegratoren und Partner?

Jürgen:

Absolut. In manchen Branchen kennen wir uns sicherlich sehr gut aus, zum Beispiel jetzt in der DER, Distributed Energy Resources, da sind wir seit vielen Jahren mit Kunden erfolgreich unterwegs. Oder auch im Bereich Medizintechnik haben wir sehr tiefe Erfahrungen aufgebaut, da machen wir das selbst. Aber auch da gibt es wieder Projekte, wo wir selbst – Cumulocity – mit Professional Services und einem Partner an der Seite unterwegs sind. Während wir uns in anderen Bereichen primär auf den Partner verlassen, weil die halt die Branchenerfahrung haben.

Wenn es um autonome Geschäftsabläufe oder die Optimierung von Geschäftsabläufen geht, dann brauchst du einen Partner, der das kann. Und Cumulocity würde – ich nehme jetzt mal kein Blatt vor den Mund: Wenn wir bei Daimler in Sindelfingen in ein Werk gehen und sagen, wir optimieren euer OEE um 3 Prozent – das glaubt uns keiner. Ich meine, wenn wir unten über Anbindung sprechen, das glaubt man uns vielleicht schon noch. Aber jetzt reinzugehen und zu sagen: Hört uns mal zu, wir schieben euer OEE 3 Prozent oder 5 Prozent hoch – da sind wir nicht glaubwürdig. Mit einem Partner schon. Wir sind aber ein Technologielieferant. Die Technologie hat sich jetzt entwickelt, wir haben jetzt einen größeren Werkzeugbaukasten, wo IoT-Werkzeuge drin sind und noch ein paar AI-Werkzeuge.

Madeleine:

Stark. Cool. Dann vielleicht die letzte Frage für heute – ich habe es eben schon angeteasert, das Thema Ratschläge. Ich meine, viele arbeiten jetzt an den Projekten, sie überlegen: Was muss ich machen? Hast du da mal etwas aus dem Nähkästchen zu plaudern, wo du sagst: Leute, da müsst ihr echt aufpassen, da kann man richtig Zeit und Geld verbrennen? Ein bisschen was hast du schon angesprochen. Oder auch, wo man einfach höllisch aufpassen muss – kannst du da mal ein bisschen was zu erzählen für die Leute da draußen?

Jürgen:

Klar, also vielleicht so ein, zwei Sachen. Zum einen: Diese Kontextschicht, die ist superwichtig, weil über so eine Kontextschicht verstehen die Agenten die wesentlichen Zusammenhänge erst und können dann gescheite Ergebnisse liefern. Und wenn man das nicht nutzt, verbrennt man eine Menge Token und riskiert Halluzinationen. Das kann man sich sparen. Man muss halt wirklich drüber nachdenken: Wie kann der Agent das verstehen? Und das liegt in diesem Semantic Layer. Das ist Nummer eins.

Das Zweite ist dieses ganze AI-assisted Development oder umgangssprachlich auch Vibe Coding. Das geschieht derzeit sehr oft, und da muss man aufpassen, dass sich nicht so eine Schatten-IT bildet, sage ich mal so. Man kann da superschnell Fortschritte machen, aber man muss sich gerade in unserem Umfeld, Industrial IoT, bewusst sein, was ich da habe: Das sind geschäftskritische Prozesse, das muss wirklich 24/7 laufen.

Und ich kann vielleicht mal so einen Prototypen mit Vibe Coding oder diesem AI-assisted Development schnell hinstellen. Aber jetzt könnten ja manche auf die Idee kommen: Brauche ich überhaupt noch so eine Plattform? Kann ich doch alles schnell schreiben, ich sage mal, im Claude Code: Baue mir die Lösung. Das heißt, ich habe das ganze Ding vibe-gecoded. Das braucht dann vielleicht ein paar Millionen Lines of Code. Das Problem ist aber: Ich muss die betreiben. Und da wird es dann schrecklich. Und da muss man höllisch aufpassen. Also für einen reibungslosen Betrieb kann man sich nicht komplett auf so einen Vibe-Coding-Ansatz verlassen.

Deswegen unterscheiden wir drei Layer. Ich habe dieses System of Record – das Ding muss stabil laufen, sicher sein, Governance, Auditierungen drin haben. Da sehen wir Cumulocity. Dann haben wir den Semantic Layer. Da sehen wir auch Cumulocity von den Tools her, aber auch die Partner und die Fachexpertise, die natürlich genau wissen, wie hängen die Dinge zusammen, wie sind die Geschäftsregeln und so weiter. Und obendrauf ist dann der Agentic Layer. Das sind die Agenten, die dann verschiedenste Analysen durchführen und Betriebsabläufe optimieren.

Auf der Applikationsebene oben, da ist dieses AI-assisted Development meiner Meinung nach supergut. Da kann man Entwicklungszeiten verkürzen, kommt wirklich schnell voran. Aber unten auf dem System of Record, da muss man sehr vorsichtig sein, weil da kann man sonst auch eine Menge kaputt machen.

Madeleine:

Ja, glaube ich. Das sind doch schöne Ratschläge. Für alle, die zuhören: Schaut euch das an im Betrieb. Falls ihr Fragen habt, wendet euch an Jürgen, kommt bei uns in den Anwenderkreis, da wird genau zu diesen Themen gesprochen. Und ich fasse euch in den Shownotes auch noch mal die Top-5-AIoT-Use-Cases, die wir jetzt gerade besprochen haben, zusammen. Schaut dann noch mal nach, wir haben auch relativ viel Inhalte, die man noch mal nachlesen kann.

Und von meiner Seite: Jürgen, vielen Dank für deine Zeit heute. Ich fand's mega spannend. Wir haben zwei konkrete Projekte gehabt, wir haben schön definiert, sauber auch mit klassischer KI, generativer KI, Hybrid-KI und wie das Ganze funktioniert mit den Agenten. Und am Ende eben, was wichtig ist. Und von daher kann ich nur Danke sagen und würde damit das letzte Wort an dich richten. Schön, dass du heute mit dabei warst. Und vielleicht haben wir uns ja noch mal in einem Jahr oder so für ein Update – ich meine, wir sind in Kontakt.

Jürgen:

Ja, gerne wieder, immer wieder. Vielen Dank, Madeleine, für die Einladung, dass ich hier heute Gast im Podcast sein durfte. Wer Bock hat, das Ganze schon mal auszuprobieren, kann auf unsere Webseite gehen, da gibt es eine kostenlose Testversion. Die habt ihr in der Minute in der Hand, also ihr kriegt dann einen Mandanten und könnt direkt loslegen.

Und auch wer Lust hat, mal da reinzugucken und vielleicht auch ein bisschen besser zu erkennen, wo wären denn Ansatzpunkte für so eine industrielle KI bei mir im Unternehmen: Ich biete jedem, der den Podcast gehört hat, an, einen kostenlosen Beratertag von Cumulocity zu nutzen. Also kommt gern vorbei, ich zeige euch auch ein paar Demos und wir machen mal ein Brainstorming gemeinsam. Und vielleicht wird ja was draus.

Madeleine:

Das ist ein schönes Angebot. Und damit danke, Jürgen, und noch einen schönen Rest-Tag für dich, schöne Restwoche. Mach's gut, ciao!

Jürgen:

Alles klar. Danke, Madeleine.