Lifetime Monitoring: KNF & b.telligent digitalisieren Testprozesse

Die heutige Folge führt uns nach Freiburg im Breisgau zu KNF. Bei KNF dreht sich alles um Pumpen – ihre Entwicklung und Produktion. Doch eines ist klar: Pumpen herzustellen allein reicht heute nicht mehr aus. Die Anforderungen der Kunden haben sich weiterentwickelt – insbesondere was Daten angeht. Und genau darin liegt der eigentliche Mehrwert.
Aber: Welche Daten sind das konkret? Und wie startet ein etabliertes Unternehmen wie KNF seine IoT-Reise? Wie sieht die technische Umsetzung aus? Kommen Azure IoT Edge, der IoT Hub oder andere Technologien zum Einsatz?
Und natürlich meine Lieblingsfrage: Welche konkreten Use Cases stehen dahinter?
All diese Fragen klären wir heute – gemeinsam mit Soroush Khandouzi, Cloud Solution Engineer bei KNF, und Florian Stein, Domain Lead für Cloud Transformation und Data Infrastructure bei b.telligent. b.telligent ist Umsetzungspartner in diesem Projekt.
Wie immer könnt ihr euch auf wertvolle Best Practices für eure eigenen Projekte freuen. Wir sprechen auch über Herausforderungen, Learnings und darüber, was ihr konkret für euren Kontext mitnehmen könnt.
Alle Infos zu diesem Projekt und weiteren Umsetzungen findet ihr auf iotusecase.com und in den Show Notes.
Und damit: Viel Spaß – wir starten direkt in die Folge.

Hallo Florian, hallo Soroush – schön, dass ihr da seid. Florian, ich fange mit dir an: Wie geht’s dir heute, und von wo bist du zugeschaltet?

Florian

Mir geht’s gut, danke für die Einladung. Ich freue mich, wieder beim IoT Use Case Podcast dabei zu sein. Ich bin heute im Büro in München – ich bin heute Morgen mit dem Fahrrad hergefahren, das hat etwa eine halbe Stunde gedauert.

Schön! Es ist toll, wenn man Sport und Arbeitsweg so kombinieren kann.

Florian

Genau. man kommt an und ist direkt erfrischt und startklar.

Übrigens: Ich habe nochmal nachgeschaut – die letzte Folge mit dir war Nummer 130 mit der MARTIN GmbH.
Wer jetzt gerade zuhört: Abonniert gerne den Podcast und hört auch mal in diese Episode rein – sie lohnt sich. schön, dass ihr da seid. Soroush, wie geht’s dir heute und von wo bist du zugeschaltet?

Soroush

Hallo und vielen Dank, dass ich beim IoT Use Case Podcast dabei sein darf. Mir geht’s gut – ich arbeite heute im Homeoffice und genieße das sonnige Wetter hier in Freiburg, im Süden Deutschlands. Perfektes Wetter fürs Wochenende.

Schöne Grüße nach Freiburg – und natürlich auch an alle Kolleginnen und Kollegen, die gerade zuhören. Schön, dass ihr dabei seid!
Soroush, du bist Cloud Solution Engineer bei KNF. Dein Background liegt in den Bereichen KI, Cloud-Architektur und Data Science.
Ich würde sagen, deine Mission ist es, manuelle Prozesse in smarte und skalierbare Lösungen zu überführen – und so dein Unternehmen und andere dabei zu unterstützen, datengetriebene Innovationen umzusetzen. Bei KNF leitest du unter anderem die digitale Transformation im Bereich Pumpentests – darüber sprechen wir gleich noch im Detail.

Aber zum Einstieg: Was begeistert dich persönlich an neuen Technologien in der Cloud und im Produktionsumfeld? Und gibt es Learnings, die du anderen mit auf den Weg geben würdest, die sich auf eine ähnliche Reise begeben?

Soroush

Ich habe im Bachelor Wirtschaftsingenieurwesen studiert. Schon damals habe ich gemerkt, dass ich mich sehr für Digitalisierung interessiere. Ich wollte verstehen, wie man die Zeit reduzieren kann, die Menschen für sich wiederholende Tätigkeiten im Alltag aufwenden – und da hat meine Reise begonnen.
Ich bin vor zwei Jahren zu KNF gekommen. Davor habe ich bei verschiedenen Unternehmen gearbeitet. Ursprünglich komme ich aus dem Iran, habe dann in Italien gelebt und gearbeitet, bevor ich nach Deutschland gekommen bin. Das Wissen aus dem Studium habe ich mitgenommen und hier weiterentwickelt.
Mein Fokus liegt weiterhin auf Digitalisierung. Ich bin einfach fasziniert davon, Wege zu finden, wie man manuelle Prozesse effizienter gestalten kann. Mein Ziel ist es, Menschen mehr Raum für kreative und innovative Arbeit zu geben – statt sich ständig mit repetitiven Aufgaben beschäftigen zu müssen.

Super. Du hast vorher auch bei Bosch gearbeitet, richtig? Das habe ich gerade auf deinem LinkedIn-Profil gesehen.

Soroush

Ja, bei Bosch in Italien.

Cool. Schön, dass du da bist – vor allem wegen deiner praktischen Perspektive.
Florian, um deine Rolle nochmal zusammenzufassen: Du bist Domain Lead für Cloud Transformation und Data Infrastructure bei b.telligent. Du bringst Erfahrung aus vielen Industrieprojekten mit und bist Experte für skalierbare Cloud-Architekturen sowie IoT-Datenplattformen über verschiedenste Technologien hinweg.
Was fasziniert dich persönlich an der Kombination aus Cloud, IoT und Dateninfrastruktur? Und wo siehst du den größten Impact?

Florian

Den größten Impact sehe ich darin, unsere Kunden auf ihrer Data- und IoT-Reise zu begleiten. Es geht nicht nur darum, einen einzelnen Use Case umzusetzen, sondern immer auch die Gesamtstrategie und die zugrunde liegende Datenplattform im Blick zu behalten.
Unser Ziel ist es, eine Basis zu schaffen, auf der Prozesse automatisiert und kontinuierlich neue Use Cases ergänzt werden können, um so echten Mehrwert aus der gesamten Plattform zu generieren. Wir entwickeln nicht nur Cloud-Lösungen, sondern unterstützen unsere Kunden auch mit Edge-Anwendungen – also dabei, Daten direkt aus dem Shopfloor zu integrieren.
In diesem Projekt mit Soroush zum Beispiel haben wir eine Edge-Anwendung mitentwickelt, um Testdaten aus Prüfständen zu integrieren. Darüber sprechen wir später noch genauer. Aber grundsätzlich ist unser Ziel, die Kunden über die gesamte Reise hinweg zu begleiten.

Und nur zur Einordnung: Du sprichst von b.telligent. Ihr seid als technologieunabhängiges IT-Service- und Beratungsunternehmen bekannt, das sich auf IoT, Analytics, Datenmanagement und Integrationsservices spezialisiert hat.
Du selbst kommst ursprünglich aus dem Bereich Business Intelligence und Data Warehousing. Würdest du sagen, das sind eure Wurzeln, und eure Arbeit hat sich inzwischen mehr in Richtung IoT bzw. IIoT entwickelt?

Florian

Genau. Unsere Wurzeln liegen im Bereich Business Intelligence und Data Warehousing. Als ich vor fünf Jahren zu b.telligent kam, habe ich den Fokus auf IoT und Fertigungsindustrie mitgebracht und diesen Bereich gemeinsam mit dem Team aufgebaut. Es ist schön zu sehen, was wir in den letzten fünf Jahren mit verschiedenen Kunden und Use Cases erreicht haben.
Heute verstehen wir uns eher als Data-Platform-Beratung. Es geht längst nicht mehr nur um Business Intelligence – wir decken inzwischen die gesamte Kette ab.

Das ist definitiv etwas, worauf ihr stolz sein könnt. Liebe Grüße auch an das gesamte b.telligent-Team, das vielleicht gerade zuhört.
Was ihr außerdem betont: Eure Kunden werden befähigt, ihre Systeme selbst zu betreiben. Ihr seid beide echte IT-Experten und unterstützt eure Kunden nicht nur beim Verständnis ihrer Daten, sondern auch dabei, ihre Architektur und Edge-Komponenten eigenständig zu nutzen. Ihr agiert also wirklich als Partner auf Augenhöhe.

Florian

Genau. Einer unserer Leitgedanken ist: Den Kunden so zu befähigen, dass er uns irgendwann nicht mehr braucht.

Kommen wir nun zu dem Grund, warum ihr beide heute hier seid. Wie ist eure Zusammenarbeit überhaupt entstanden?

Soroush

Schon vor diesem Projekt hatte KNF mit b.telligent bei einem Business-Intelligence-Projekt zusammengearbeitet – mit sehr guten Ergebnissen.
Damals haben wir einen Proof of Concept gestartet für das, was wir heute LTM-Projekt nennen – also „Lifetime Monitoring“. Als wir beschlossen, daraus ein MVP zu entwickeln, haben wir uns an Florian und das Team gewandt. Uns war klar, dass ihre Expertise sehr wertvoll ist – und gleichzeitig unsere eigene Engineering-Kompetenz erweitert.
Gemeinsam wollten wir die Digitalisierung bei KNF weiter vorantreiben.

Lass uns ein bisschen über KNF sprechen, denn nicht alle kennen das Unternehmen. Ihr seid ein wichtiger Akteur, aber zum Kontext: KNF ist ein weltweit tätiges, familiengeführtes Unternehmen mit Sitz in Deutschland, das auf die Entwicklung, Konstruktion und Herstellung von Pumpen spezialisiert ist. Stimmt das so?

Soroush

Die KNF Holding AG hat ihren Hauptsitz heute in der Schweiz, aber alles begann vor 78 oder 79 Jahren in Freiburg als Familienunternehmen.
Wir sind in vielen Branchen aktiv, bezeichnen uns aber oft als „Hidden Champion“, weil viele Menschen uns nicht direkt kennen – unsere Pumpen aber im Hintergrund überall im Einsatz sind.
Unsere Produkte findet man überall: von Tiefsee-U-Booten bis zur Internationalen Raumstation. Deshalb bezeichnen wir uns als Hidden Champion. Wir unterstützen viele andere Industrien mit unserer Technologie.
Unser Firmenslogan lautet: „Together we innovate, together we keep the world in flow.“ Unsere Pumpen tragen dazu bei, dass dies möglich ist.

Kannst du noch etwas über eure Kundschaft erzählen? Du hast verschiedene Szenarien angesprochen, in denen eure Pumpen zum Einsatz kommen. Bedient ihr bestimmte Kundensegmente oder wirklich alle Branchen?

Soroush

Tatsächlich sind wir in allen Branchen unterwegs – von der Medizintechnik und Laboranwendungen über Universitäten bis hin zur Schifffahrt. Zum Beispiel werden unsere Pumpen in Schiffsschornsteinen eingesetzt, um Emissionen zu reduzieren.
Was KNF besonders macht, ist unsere Fähigkeit, unsere Pumpen individuell anzupassen. Wir arbeiten eng mit unseren Kunden zusammen, um ihre Anforderungen zu verstehen und maßgeschneiderte Lösungen zu entwickeln.
Überall dort, wo Gas- oder Flüssigkeitspumpen gebraucht werden, können sich unsere Kunden an uns wenden – und wir finden eine passende Lösung.

Lass uns über das konkrete Projekt sprechen. Ich würde sagen, es handelt sich um ein IIoT-Projekt. Was sind die Hauptziele? Könnt ihr beide kurz erklären, worum es geht?

Soroush

Klar. Ich erkläre zuerst, was LTM für uns bedeutet. Das steht für „Lifetime Monitoring“. Die Idee ist, unsere Pumpen über ihre gesamte Lebensdauer hinweg zu überwachen – das können vier, fünf, manchmal sogar acht oder neun Jahre sein – um zu verstehen, was in dieser Zeit mit ihnen passiert.
Wir schaffen Testumgebungen, die die Einsatzbedingungen beim Kunden nachbilden, und beobachten dann, wie sich die Pumpenkomponenten verhalten.
Bevor wir mit dem IoT-Projekt begonnen haben, wurde die Datenerfassung manuell durchgeführt – manchmal täglich, manchmal wöchentlich, je nach Projekt. Ein Techniker musste zum Standort gehen und die Daten erfassen.
Da wir ein globales Unternehmen mit vier Produktionsstandorten sind – zwei in der Schweiz, einer in Deutschland und einer in den USA – waren die Daten sehr verteilt. Jeder Standort hatte sein eigenes System, ein zentrales gab es nicht. Das bedeutete: Es gab keine einzelne „Quelle der Wahrheit“.
Dieses Projekt wurde gestartet, weil wir dringend eine einheitliche und zentrale Datenbasis brauchten. Wir mussten in der Lage sein, Daten standortübergreifend zu übertragen und darauf zuzugreifen – für künftige Projekte und für tiefere Analysen.

Und wenn du sagst, ihr beobachtet Komponenten – kannst du da ein Beispiel geben? Um welche Komponenten geht es konkret und welche Daten interessieren euch?

Soroush

Ja, ein gutes Beispiel sind Membranpumpen. Diese Pumpen haben Membranen, die mit der Zeit verschleißen können. Oft merken wir das aber erst, wenn die Pumpe bereits ausgefallen ist. Wenn wir sie dann auseinandernehmen, sehen wir zwar, dass die Membran beschädigt war – aber nicht, wann oder warum das passiert ist.
Deshalb haben wir angefangen, Umgebungsdaten zu erfassen – also Strom, Druck, Luftfeuchtigkeit und Temperatur – um die Bedingungen besser zu verstehen.
Früher wurde das alles manuell gemacht. Die Techniker haben die Werte in Excel oder teils in SQL-Datenbanken eingetragen, aber alles händisch. Auch die Betriebsstunden wurden mitprotokolliert.
Diese Daten haben uns geholfen, die Lebensdauer unserer Pumpen besser zu verstehen und Ausfallmuster zu erkennen. Zum Beispiel konnten wir sehen, ob sich durch eine Änderung im Produktionsprozess häufiger Ausfälle im Feld ergeben haben.

Verstanden. Und wenn wir über die Daten sprechen, die ihr erfasst – sind das hochfrequente Daten oder eher eine Messung pro Stunde?

Soroush

Aktuell erfassen wir die Daten bei normalen Bedingungen mit etwa 100 Hz – also 100 Datenpunkten pro Sekunde.
Außerdem haben wir eine Funktion entwickelt, die wir „Burst Mode“ nennen. Dabei läuft die Pumpe einmal am Tag für 10 Minuten mit 10 kHz. So können wir sehr hochfrequente Daten erfassen, etwa um Geräusche oder Vibrationen genauer zu analysieren.

Spannend. Auf den Burst Mode komme ich gleich nochmal zurück. Aber vorher noch eine Frage: Da ihr ein globales Unternehmen mit mehreren Standorten seid – ist eure Infrastruktur aktuell noch fragmentiert oder wie kann man sich euer System vorstellen?

Soroush

Seit dem Aufkommen des Internets arbeiten wir kontinuierlich daran, unsere Standorte besser zu vernetzen. Dieses Projekt ist ein weiterer Schritt in diese Richtung.
Wie ich vorhin erwähnt habe, haben wir auch beim vorherigen BI-Projekt mit b.telligent schon in diese Richtung gearbeitet.
Unser Ziel ist es, die Integration innerhalb des Unternehmens weiter auszubauen. Wir haben vier Hauptproduktionsstandorte und über 20 weitere Niederlassungen weltweit, meist als Vertriebszentren.

Verstanden, Florian, eine Frage an dich: Du kennst viele ähnliche Projekte. Wie ordnest du dieses hier ein – insbesondere in Bezug auf fragmentierte Systeme an mehreren Standorten? Ist das aus deiner Sicht typisch?

Florian

Die meisten Herausforderungen in diesem Projekt sind ziemlich typisch. Viele Unternehmen haben isolierte Systeme an verschiedenen Standorten und wollen ihre Daten zusammenführen, um zum Beispiel Produktionsmengen oder Testergebnisse vergleichen zu können.
Das sehen wir häufig – der Bedarf, Daten zu zentralisieren, um standortübergreifende Vergleiche zu ermöglichen.
Was dieses Projekt allerdings besonders gemacht hat, war das technische Setup – vor allem die spezifischen Geräte, die wir anbinden mussten, und wie Soroush bereits erwähnt hat, der sogenannte Burst Mode. Das war tatsächlich etwas Einzigartiges.

Was genau ist der Burst Mode? Ich muss jetzt mal nachfragen – worum geht es da genau?

Florian

Ich versuch’s mal zu erklären, und Soroush kann gern ergänzen: In unserer IoT-Anwendung – die auch ein Webinterface für die Techniker umfasst – gibt es die Möglichkeit, ein Zeitfenster für hochauflösende Datenerfassung zu planen.
Einmal pro Tag zeichnet das System dann Daten mit deutlich höherer Frequenz für einen bestimmten Zeitraum auf. So können die Nutzer tief in die Details einsteigen und das Verhalten genauer analysieren.

Verstehe – es geht also um die Verwaltung und Analyse hochfrequenter Daten.

Soroush

Was ich ergänzen kann: Wie der Name schon sagt, lassen wir die Pumpe in diesem Modus mit sehr hoher Frequenz laufen – bis zu 10.000 Umdrehungen – und beobachten, wie sie sich dabei verhält, insbesondere wenn sie an ihre Leistungsgrenze kommt.
Manchmal hilft uns das, kritisches Verhalten von Bauteilen zu erfassen – das ist aber nicht der Hauptzweck.
Ziel ist es, die Betriebsgrenzen unserer Pumpen besser zu verstehen. Ein Beispiel: Wir lassen die Pumpe für zehn Minuten bei hoher Frequenz laufen, um zu sehen, wie sie unter Belastung performt und wo ihre zuverlässigen Schwellenwerte liegen.

Verstanden, Jetzt interessiert mich der Prozess vor dem Projektstart: Wie lief das Pumpen-Testing früher ab – und warum war das so zeitaufwendig, wie du es vorhin erwähnt hast?

Soroush

Vor diesem Projekt hatten wir bereits Testräume, in denen wir die Pumpen aufbauten, um Daten zu sammeln. Wir ließen die Pumpen unter normalen Betriebsbedingungen laufen und begannen damit, Parameter wie Temperatur, Luftfeuchtigkeit, Strom, Druck, Durchfluss und andere zu erfassen.
Früher musste jedoch ein Techniker oder Ingenieur persönlich in den Testraum gehen und die Werte an jeder einzelnen Pumpe ablesen. Das war extrem zeitaufwendig.
Zum Vergleich: Heute testen wir über 1.500 Pumpen parallel. Stell dir vor, eine Person müsste täglich für jede einzelne dieser Pumpen Strom, Durchfluss, Druck, Temperatur und Luftfeuchtigkeit – inklusive Eingangs- und Ausgangsdruck – manuell ablesen.
Früher hatten wir nie so viele Pumpen gleichzeitig im Test. Durch dieses Projekt können wir heute über 1.500 Pumpen täglich automatisiert testen.

Das ist beeindruckend. Und da wir gerade über den Business Case sprechen – jede Investition in Technologie muss natürlich auch gerechtfertigt sein. Viele Unternehmen müssen den Return on Investment (ROI) bewerten, was oft eine Herausforderung ist.
Gibt es neben dem, was du gerade beschrieben hast, noch weitere Einblicke in typische Verluste oder Ineffizienzen – etwa in Bezug auf Zeit oder Ressourcen? Wartungszeiten sind da ja oft ein großes Thema, oder?

Soroush

Eines unserer Hauptprobleme war, dass wir nicht wussten, wann eine Pumpe ausfällt – oder warum.
Mit dem neuen Setup können wir beides adressieren. Es ist zwar schwierig, den exakten ROI zu beziffern, aber der Mehrwert ist definitiv da. Zum Beispiel erhalten unsere Test- und Entwicklungsingenieure heute sehr präzise Daten nahezu in Echtzeit – mit Übertragungsverzögerungen von unter 100 Millisekunden.
Dieses Setup hat auch neue Möglichkeiten eröffnet. Das derzeit beliebteste Schlagwort ist ja „KI“ – und wir nutzen die Daten tatsächlich für KI-gestützte Entwicklungen, etwa in Richtung Predictive Maintenance.

Also auf der einen Seite gibt es den Business- und Prozessaspekt – manuelle Tests und Dokumentation. Wenn jemand täglich ein bis zwei Stunden damit verbringt, Tausende Pumpen zu testen, ist das ein enormer Zeitaufwand.
Auf der anderen Seite entgeht einem auch die Chance auf Dinge wie vorausschauende Wartung oder smarte Services. Ich weiß nicht, wie weit ihr damit schon seid – aber sobald die Daten verfügbar sind, könnten sie ja auch für erweiterte Kundenservices genutzt werden.
Würdest du sagen, man kann das in Prozessvorteile und zukünftige Geschäftschancen aufteilen?

Soroush

Ja, genau. Und das System unterstützt parallel auch unseren Produktionsprozess. Es ermöglicht schnellere Entscheidungen und eine zügigere Bewertung von neu entwickelten Produkten.

Das ist stark. Dann kommt noch die technologische Seite dazu – also der Umgang mit verteilten Systemen an unterschiedlichen Standorten, das Management hochfrequenter Daten, Engpässe in den Engineering-Workflows. Das beeinflusst ja direkt die Produktentwicklung und führt zu Verzögerungen, oder? Das wäre dann eher der technische Teil des Business Cases.

Soroush

Ja, genau. Heute können wir Erkenntnisse unserer Ingenieurteams aus den USA und Deutschland gemeinsam nutzen. Wenn zum Beispiel bei einem bestimmten Pumpentyp eine Anomalie erkannt wird, kann diese Information direkt ins System und in die Testprotokolle übernommen werden.
Früher – als die Daten noch fragmentiert waren – musste alles mühsam manuell erklärt werden: Was wurde getestet, was ist passiert, was war das Ergebnis und warum. Jetzt sprechen wir standortübergreifend eine gemeinsame Sprache.

Verstanden. Florian, ich nehme an, das kommt dir bekannt vor – so ein Business Case findet sich doch sicher in vielen eurer Projekte, oder?

Florian

Ja, absolut. Ein wichtiger Punkt ist: Viele Prozesse waren früher manuell. Ingenieure und Techniker mussten extra in die Testräume gehen, nur um Pumpen ein- oder auszuschalten.
Diese Funktion haben wir jetzt in die Anwendung integriert. Sie können die Pumpen nun direkt von ihrem normalen Arbeitsplatz aus steuern. Sie müssen ihre Arbeit also nicht mehr unterbrechen, um vor Ort an den Pumpen etwas zu machen. Das bringt einen erheblichen Effizienzgewinn.

Das kann ich mir gut vorstellen – vor allem in extremeren Umgebungen. Wenn eine Pumpe zum Beispiel unter Wasser installiert ist, braucht man für die Wartung vielleicht ein ganzes Taucherteam. Allein dieser Gedanke zeigt schon, wie wertvoll eine Fernsteuerung sein kann.
Soroush, du hast dich also entschieden, mit Florian und seinem Team zu arbeiten. Was hat aus deiner Sicht den Ausschlag gegeben? Gab es etwas Konkretes, das dich überzeugt hat, dass b.telligent der richtige Partner ist?

Soroush

Als ich zum Projekt dazugestoßen bin, lief die Zusammenarbeit bereits. Aber in den ersten Monaten habe ich schnell gemerkt, dass Florian und sein Team schon an ähnlichen Projekten gearbeitet hatten.
Ein Punkt, der für uns besonders war, war die Individualisierung der Datenerfassung – wir nennen unser Setup DAC, also Data Acquisition Devices. Wir nutzen Komponenten wie NI und MCC, die sehr spezifisch für unsere Anforderungen sind.
Dieser Teil war einzigartig für unser Projekt, aber ich konnte sehen, dass das Team bereits Erfahrung mit ähnlichen Architekturen in anderen Unternehmen hatte. Sie wussten, wo potenzielle Probleme auftreten können, und wie man sie vermeidet. Das hat die Zusammenarbeit sehr wertvoll gemacht.
Da ich erst später ins Projekt kam, kann Florian vielleicht noch etwas ergänzen.

Florian

Schon beim allerersten Gespräch – damals mit ihrem Vorgesetzten – hatte ich das Gefühl, dass wir auf einer Wellenlänge sind. Die Kommunikation war von Anfang an einfach und natürlich, wir haben uns sofort verstanden.
Das ist für mich etwas, das IoT-Projekte von klassischen BI-Projekten unterscheidet. Im IoT-Bereich haben viele einen persönlichen Bezug zum Thema. Viele nutzen selbst Smart-Home-Geräte oder fahren Elektroautos – dadurch laufen die Gespräche auf einer anderen Ebene.
Wir haben unseren Ansatz schnell mit einem Proof of Concept validiert. Und als wir gesehen haben, dass es funktioniert, haben wir beschlossen, nicht nur diesen einen Use Case umzusetzen, sondern direkt eine skalierbare Grundlage zu schaffen. Die Idee war, damit auch künftige Use Cases ermöglichen zu können. Das war eine wichtige Entscheidung ganz zu Beginn.
Als Soroush dazukam, war das super. Schon im ersten Gespräch war er begeistert vom Projekt. Wir haben ihn eingearbeitet, und jetzt haben wir wöchentliche Treffen, bei denen wir die aktuellen Schritte und bevorstehenden Anwendungsfälle besprechen.
Was ich besonders schätze: Unsere Rolle als Berater ist es nicht, alles selbst zu machen. Unser Fokus liegt darauf, das KNF-Team so zu befähigen, dass es eigene Lösungen aufbauen und skalieren kann.

Verstehe.
Florian, kannst du uns die aktuelle Lösung erklären, die ihr für KNF umgesetzt habt? Was genau wurde entwickelt, was war bereits vorhanden und welche Technologien kommen zum Einsatz? Danach gehe ich auf die Fragen aus der Community ein.

Florian

Klar. Was dieses Projekt besonders gemacht hat, ist, dass wir zunächst die gesamte Cloud-Grundlage aufgebaut haben. Dazu gehörte auch die Automatisierung des Rollouts der Cloud-Infrastruktur – sowohl für diesen konkreten Use Case als auch für zukünftige Anwendungsfälle.

Das, was ihr als „Cloud Foundation“ bezeichnet. Im Grunde also der gesamte Technologie-Stack und die Infrastruktur, die man dafür braucht, richtig?

Florian

Genau. Wir nutzen Terraform, um den Rollout der Infrastruktur über Deployment-Pipelines zu automatisieren. Außerdem haben wir das Rahmenwerk und GitOps-Prozesse rund um den Azure-IoT-Stack aufgesetzt.
Das umfasst unter anderem das Ausrollen von Azure IoT Edge-Anwendungen in die Edge-Umgebung – also direkt in die Nähe der Pumpen –, wo die DAC-Anwendungen (Data Acquisition Controller) laufen. Diese Edge-Umgebungen erfassen die Daten und senden sie in die Cloud. Falls die Internetverbindung mal ausfällt, können sie die Daten auch lokal puffern.

Wie verbindet ihr bestehende Anlagen – also Brownfield-Umgebungen – mit dieser modernen Cloud-Infrastruktur? Verwendet ihr MQTT, OPC UA oder andere Protokolle, um die Geräte anzubinden?

Florian

Der LTM-Use-Case ist etwas speziell. Wie bereits erwähnt, nutzen wir eigens entwickelte DAC-Controller. Wir haben eine Python-basierte Softwarebibliothek auf Basis der Azure IoT SDKs gebaut, die die Daten vom Edge in den IoT Hub sendet.
In diesem Fall nutzen wir MCC- und NI-Boards, um die Daten lokal zu erfassen. Das Edge-Device sendet diese Daten mithilfe des Azure IoT SDK in die Cloud, wo sie in einer Time-Series-Datenbank – konkret Azure Data Explorer – gespeichert werden.
Die Daten werden dann über Grafana visualisiert, sodass Ingenieure sie tiefgehend analysieren und überwachen können.
Bei anderen Use Cases bei KNF – wie Soroush bereits erwähnt hat – kommen auch MQTT-Broker zum Einsatz, um Daten in Azure zu übertragen. Die Architektur wird also immer an die spezifischen Anforderungen angepasst.

Ich nehme an, das hängt stark vom Kunden und der bereits vorhandenen Systemlandschaft ab.
Für alle, die an einem ähnlichen Projekt arbeiten und sich über Best Practices austauschen möchten: Ich packe die LinkedIn-Profile und Kontaktdaten von Florian und Soroush in die Show Notes. Ihr könnt die beiden gerne kontaktieren und euren Use Case oder technische Anforderungen besprechen.
Es zeigt sich: Die Konnektivität ist stark abhängig von den eingesetzten Geräten und den Zielen des Projekts.
Und nochmal zurück zum Thema Fehlererkennung: Ihr habt vorhin erwähnt, dass es nicht nur darum geht, wann ein Fehler auftritt, sondern auch warum. Wie löst ihr das technologisch?

Florian

Unser Hauptziel war es, Daten nahezu in Echtzeit zu erfassen – mit Frequenzen im Bereich von mehreren Hundert Hertz, teils sogar noch höher. Diese Daten werden in eine Zeitreihendatenbank übertragen, wo Ingenieure sie mithilfe von Grafana-Dashboards analysieren können.
Diese Dashboards zeigen alle relevanten Sensordaten an, ermöglichen die Überwachung von Schwellenwerten und das Erkennen von Anomalien. Die Ingenieure können gezielt in die Daten eintauchen, bestimmte Auffälligkeiten markieren und Kommentare hinzufügen.
Das Setup erlaubt es auch, eine langfristige Dokumentation zu erstellen. Beispielsweise können während Langzeittests Auffälligkeiten gekennzeichnet und über einen längeren Zeitraum nachverfolgt werden. All diese Informationen lassen sich später für Automatisierungen oder als Input für Data-Science- oder KI-Modelle nutzen.

Das ergibt Sinn. Soroush, möchtest du noch etwas aus der Praxisperspektive ergänzen? Wie arbeitest du oder dein Team konkret mit dem System?

Soroush

Ja. Wie vorhin schon erwähnt, hatten Florian und sein Team bei b.telligent ein gutes Gespür dafür, welche Herausforderungen auftreten könnten. Zum Beispiel haben wir bereits vor dem Übergang in die Produktion ein cloudbasiertes Alarmsystem implementiert.
Wenn ein Sensor ungewöhnliche Werte erkennt – etwa einen zu hohen oder zu niedrigen Stromverbrauch – löst das System einen Alarm aus. Dann kann ein Techniker oder Ingenieur die Pumpe prüfen, bevor es überhaupt zu einem Ausfall kommt.
Das ist eines von mehreren Beispielen dafür, wie Florian und sein Team potenzielle Probleme früh erkannt und mit uns vorausschauend gelöst haben.

Ganz genau – das System ist also auf mögliche Fehler vorbereitet.

Florian

Ein wichtiger Punkt, den man nicht vergessen darf: Früher blieben viele Fehler schlicht unbemerkt. Techniker hatten oft nicht genug Informationen, um Probleme frühzeitig zu erkennen.
Heute wissen sie dank des Systems genau, wann ein Fehler auftritt, und können gezielt zur betroffenen Pumpe gehen. Die Daten liefern ein klares Signal, das eine schnelle Reaktion ermöglicht.

Genau. Das ist ein schönes Fazit.
Gab es denn unerwartete Ergebnisse oder Mehrwerte im Projekt – also Dinge, die ihr nicht geplant hattet, die sich aber als besonders wertvoll herausgestellt haben?

Soroush

Eines davon war, wie reibungslos sich unsere physischen Geräte mit der Cloud verbinden ließen – und dass wir die Daten tatsächlich in Echtzeit visualisieren konnten.
Das hat ganz neue Projektideen ermöglicht, etwa die direkte Anbindung von Produktionslinien und Testumgebungen an die Cloud. Heute hängt bei uns in den Testräumen ein Fernseher an der Wand, der anzeigt, welche Pumpen gerade laufen – inklusive aktueller Messwerte.
Ein weiterer positiver Nebeneffekt war, dass wir mit diesem Setup auch die Grundlage für KI-Anwendungen geschaffen haben. Anfangs dachten wir vor allem an Predictive Maintenance, doch jetzt nutzen wir die Daten auch zur Fehlerklassifikation. Wir analysieren, wie sich bestimmte Datenänderungen auf spezifische Fehlerarten auswirken – und können dadurch Probleme gezielter vorhersagen.

Florian

Was ich den Hörern noch mitgeben möchte – und das zeigt sich in jedem IoT-Projekt:
Man hat es oft mit einer Vielzahl an Geräten und sehr vielen Datenpunkten zu tun, die in die Cloud fließen.
Es ist deshalb wichtig, die Lösung regelmäßig auch unter finanziellen Aspekten zu betrachten. Manchmal müssen Einstellungen angepasst werden, um Cloud-Kosten zu optimieren. Ein IoT-System ist keine einmalige Installation – man muss es kontinuierlich überwachen und optimieren, vor allem wenn das Datenvolumen wächst.

Ein wertvoller Tipp für alle, die ein ähnliches Projekt planen.
Vielen Dank euch beiden, dass ihr heute im Podcast dabei wart. Ich fand die Einblicke aus der Praxis sehr spannend.
Ich bin gespannt, wie sich das Projekt weiterentwickelt – vielleicht machen wir in einem Jahr ein Update.
Fürs Erste vielen Dank von meiner Seite. Ihr habt das letzte Wort, wenn ihr noch etwas loswerden möchtet.

Florian

Danke für die Einladung. Es war – wie auch beim letzten Mal – sehr schön, über diesen Use Case zu sprechen und unsere Erfahrungen zu teilen.
Wir hoffen, dass das andere Unternehmen inspiriert, selbst IoT-Projekte anzugehen.

Soroush

Auch von meiner Seite vielen Dank, dass ich dabei sein durfte. Es war mir eine Freude, über unser Projekt zu sprechen.
Ein abschließender Tipp für alle: Wenn ihr ein MVP startet, denkt von Anfang an größer. Fokussiert euch nicht nur auf den einen Use Case – plant das Projekt so, dass es skalierbar ist. Das macht den Unterschied.

Ein perfekter Schlusssatz. Danke euch – und eine gute restliche Woche! Tschüss!

Soroush

Tschüss.