Make or Buy im IIoT: Use Cases skalieren mit einer LoRaWAN-Plattform

Heute im IoT Use Case Podcast: Wenn aus einem LoRaWAN-Netz nicht nur ein Sensor-Projekt, sondern eine skalierbare IoT-Infrastruktur wird. Wir sprechen mit Currenta Conneqtive und akenza über Pumpen, Dampf, Kugellager, Schaufelräder und die berüchtigte Diskussion Make or Buy – also selber bauen oder besser kaufen. Im Kern ist es die Frage: Wann wird aus Sensorik ein belastbarer Betrieb, und warum braucht es dafür mehr als Gateways, Dashboards und ein paar Grenzwerte? Viel Spaß dabei.

Murat, lass uns mal direkt mit einem konkreten Fall anfangen. Was war der Moment, in dem klar wurde, dass ihr nicht nur einen Sensor an einer Pumpe braucht, sondern auch eine wiederverwendbare und skalierbare IoT-Infrastruktur?

Murat

Bei uns im Chempark war klar, als wir gestartet sind, eine Lösung zu finden, wie wir unsere Dampfnetze auf dem ganzen Chempark integrieren können. Da war die verkabelte Lösung, die in eine Leittechnik geht, keine Lösung mehr, die wir nutzen konnten. Da hatten wir uns intern als Systemhaus auf die Suche begeben, wie wir das Problem lösen können, und sind da auf LoRaWAN und 5G-Use-Cases gekommen. Und da begann auch schon die Überlegung: Wo zeigen wir es an, wie können wir es visualisieren – wie immer dann Make or Buy.

Wie wollen wir das machen, aus dem Sensor eine finale Lösung anbieten zu können, end to end? Und da hat sich dann akenza für uns angeboten als Plattform, LoRaWAN und 5G als Medium.

Gerade das Thema Make or Buy ist ja wirklich immer aktuell und für jeden relevant. Das ist ja für jedes größere Thema, Projekt, jede Digitalisierung, auch bis hin zu KI jetzt: Baue ich selber oder kaufe ich es ein? Was waren da die Überlegungen, die Abwägungen, die getroffen wurden?

Murat

Also ich habe in meiner Vergangenheit schon häufiger Make-or-Buy-Decisions gehabt, und ich konnte in der Vergangenheit häufig sehen, wie die Make-Decision war, bis ich bei der Currenta war. Dort haben wir häufig zwei, drei Jahre Vorlauf gebraucht, bis wir angefangen haben, einen Anforderungskatalog zu schreiben, aus dem wir dann eine Entwicklungsabteilung hatten – entweder intern oder extern – und dann wirklich häufig von null auf mit einem UI-Designer, UX-Designer gestartet haben: Wie soll es aussehen, was soll es können, welche Sprachen brauchen wir, welchen Input.

Und ich muss sagen, das war nie die Stärke der Firma gewesen. Und da bin ich umso glücklicher, jetzt die Lösung zu haben mit akenza, wo ich sagen kann: Ich konzentriere mich auf mein Kernbusiness. Das sind die Sensoren, das sind die Use Cases. Damit kann ich Geld verdienen und kann die Arbeit dann bei akenza lassen. Und ich bewege mich sonst mal gerne im Standard, wo ich dann Plug and Play nutzen kann, die ganzen Sensoren schon integriert sind, ich keine Entwickler brauche, die mir in dem Case helfen, sondern häufig auch noch das Support-Team oder das Betriebsteam das dann auch schon teilweise übernehmen kann.

Kannst du noch mal zu euren Anwendungsfällen sprechen? Mit welchen Anwendungsfällen seid ihr gestartet, was läuft jetzt, was steht noch an?

Murat

Wir sind jetzt mit dem Smart Dampf – das ist bei uns der erste Anwendungscase. Der hat den Großteil der Hardware auf dem Shared Medium finanziert. Jetzt gehen wir da raus und haben jetzt Vibrationssensorik im Feld, wo wir Pumpen, Verbrennungsöfen, Brüdenventilatoren und normale Pumpen, die in der Chemie sind, monitoren. Darüber hinaus starten wir jetzt wirklich mit der großen Reihe, einem großen Katalog, wo wir zum Beispiel auch die Gebäude smart machen, zusammen die Thermostate erneuern, die Raumtemperatursensoren einbinden.

Dann als nächste Lösung zum Beispiel die automatische Schmierung, oder Methansensoren mit Honeywell und dergleichen. Also da kann man wirklich, wenn man einmal die Plattform aufgebaut hat, schnell in viele verschiedene Perspektiven skalieren. Oder bei uns ein ganz großer Case: Wir haben relativ viele Brunnen auf dem Gelände, die wir monitoren müssen – nach Erdschluss, nach Deckelöffnungen und Füllständen und dergleichen –, die dann auch mit LoRaWAN im Feld sehr gut funktionieren und einbindbar sind.

Zu Smart Dampf hatten wir ja erst kürzlich eine gemeinsame Aufnahme, einen gemeinsamen Podcast. Also wer da ein bisschen mehr davon hören möchte, wie das umgesetzt wurde, mit dem Verantwortlichen für das Dampfnetz, der kann in einer der vorherigen Folgen mal schauen. Da hatten wir eine ganz interessante Diskussion, speziell zu dem Anwendungsfall. Christian, mal zu dir: Wenn man das jetzt so hört, die verschiedenen Anwendungsfälle, die Strukturierung, diese Make-or-Buy-Entscheidung – wie siehst du das aus Plattform-Sicht? Wie betrachtest du Kunden, wie segmentierst du das? Sagst du, das ist mir eigentlich egal, welchen Anwendungsfall du hast, ich mache alles? Oder wo siehst du den Nutzen der Plattform?

Christian

„Ich mache alles“ ist sicherlich das, was ich jedem wünschen würde. Das filtern wir schon im Vorfeld heraus. Wir konzentrieren uns natürlich sehr gerne auf unsere Kernkompetenzen, die wir haben. Das ist einmal das Thema Smart Building und das Thema Smart Industry. Und für das Thema Smart Industry bin ich bei akenza zuständig. Und Murat hat es schon angesprochen: Uns ist natürlich immer die Buy-Lösung lieber, als wenn sich jemand hinsetzt und von null anfängt, das aufzubauen.

Es gibt solche Philosophien natürlich, die mögen ihre Berechtigung haben. Natürlich ist es mit uns, wie Murat schon sagte, deutlich schneller. Wir entwickeln seit zehn Jahren an diesem IoT-Stack unserer Plattform, und wir sind auch deutlich günstiger im Vergleich natürlich. Das schließt sich dann ein und ermöglicht den Kunden, sämtliche Messprinzipien, sämtliche Übertragungstechniken, Protokolle, Sensoren, wie es Murat schon nannte, die marktbefindlich sind, anzubinden – völlig horizontal ausgerichtet, ohne herstellerspezifische Bindungen zu haben.

Wo würdest du sagen, ist dann der größte Schmerz, wenn man so etwas selber versucht aufzubauen? Ist das jetzt bei der Gerätevielfalt – also weil es unglaublich viele Sensoren und andere Geräte gibt, die man anschließt –, geht es dann eher um die Skalierung, also Datenfrequenzen, Datenübertragung, einfach von der Masse der Daten, oder auch um das Thema Output, Semantik? Also was ist da das, wo du sagst, da ist der Schmerz oder die Komplexität am größten?

Christian

Das kommt auf den Anwendungsfall an, auf den Kunden, was er umsetzen möchte. Das kann man so nicht verallgemeinern, da gibt es keinen roten Faden. Grundsätzlich ist es so – um auf das Thema LoRaWAN speziell einzugehen –, dass natürlich jedes Gerät in einer spezifischen Plattform erst mal eingebunden werden muss. Sprich, die Dekodierung muss stattfinden. Und diese Dekodierung ist bei uns in der sogenannten Device Type Library schon für weit über 400 Geräte umgesetzt – die üblichen Sensoriken am Markt, LoRaWAN-Geräte, die oft verwendet werden, auch die Geräte der Currenta.

Das bedeutet also, dass der Kunde sich die Geräte verschaffen kann und sie mit einem Klick auf unsere Plattform eingebunden werden können. Das heißt, die Geräte sind schon hinterlegt, sind dekodiert, und dieser Aufwand fällt weg. Und das ist aus meiner Erfahrung nach bei vielen Kunden einer der größten Schmerzen, die Geräte zu dekodieren. Weil es ist quasi wie zu Hause: Man kauft ein Gerät, es liegt auf dem Tisch, und jetzt müsste ich erst mal eine App konfigurieren, und da scheuen sich viele davor. Möchten sie eigentlich gar nicht. Die möchten das mit einem One-Click. Das Ganze soll einfach funktionieren. Und das ist bei uns der Fall.

Das ist natürlich cool, aber auch schwierig, so etwas nachzuhalten mit der Device Library, die ihr dann habt. Vielleicht ganz konkret mal, sagen wir, an den Pumpen: Also welche Sensoren sind da wo verbaut, was erfassen die – und lass uns das mal von der Pumpe, vom Sensor bis hin zur Auswertung Schritt für Schritt durchgehen.

Murat

Gerne. Dann nehme ich einmal das Flusswasserwerk von uns. Dort haben wir große Integralpumpen, die das Rheinwasser entnehmen und dann zu Kühlzwecken oder dergleichen nutzen. Und diese sind Assets, die in sich kritisch sind – natürlich sind sie nicht redundant aufgebaut, aber vom Wert doch so hoch, dass sie schützenswert sind. Wir statten diese gerne proaktiv aus, dass wir auch zwischen den Wartungsintervallen wissen, wie es der Pumpe geht.

Früher waren es die Experten, die durchs Feld gelaufen sind, die einmal gehört haben, wie die Pumpe läuft. Diese Expertise wird immer weniger im Feld, und die können wir dann mit dem IoT-Ansatz kompensieren, wo wir sagen: Wir bringen jetzt zum Beispiel einen TWTG-Sensor an, der Vibrationen messen kann. Den kann man dann an den kritischen Komponenten anbringen, zum Beispiel am Motor, an Kugellagern oder an der Aufnahme.

Da haben wir mit dem Ingenieur oder dem Schwingungsexperten die kritischen Bauteile einmal erfasst, die Sensoren angebracht. Dann kommen wir rein mit dem LoRaWAN, weil die Assets sehr häufig bei uns im Werk verteilt sind, auf 11 Quadratkilometern. LoRaWAN ist als Long-Range-Komponente sehr gut, wo wir sagen können: Wir können über lange, weite Strecken kleine Datenmengen – auch eine Vibrationssensorik kann mit kleinen Datenmengen arbeiten – in einer sehr batterieeffizienten Methodik nutzen. Und wir kriegen auch FFT-Analysen aus dem Sensor raus, das ist natürlich etwas aufwendiger, aber die können dann sozusagen aufs Feld, in die Plattform reingesendet werden.

Erklär kurz FFT-Analysen, gerade im Kontext von Schwingungen.

Murat

Ja, FFT-Analyse ist eine Spektrumanalyse. Also wenn wir zeigen, wir gehen über eine Pumpe, die ein Frequenzband hat – alles hat ein Frequenzband. Aber wir gehen von 1 Hertz bis 6.000, 20.000 Hertz und schauen uns dann die Ausschläge an, wie hoch die Amplitude ist. Also wie stark die Schwingung ist in welchem Bereich. Und da können wir rauslesen, wie es der Pumpe geht. Also hochfrequente Schwingungen, Lautstärken haben ein anderes Problem als niederfrequente Schwingungen.

Da, glaube ich, kam auch schon ganz gut raus, dass ja jedes Gerät anders ist. Und das ist ja auch eine große Komplikation, die man da hat bei dem Thema, wie man zum Beispiel Predictive Maintenance macht, weil jede Pumpe in Kombination mit Sensoren so ihre Eigenheiten und Ansprüche hat. Aber da können wir noch mal drauf zurückkommen. Lass uns mal den Weg weiter durchgehen. Also, dann sind die Daten im LoRaWAN, werden über das LoRaWAN übermittelt. Wie habt ihr das aufgebaut, was muss man da beachten?

Murat

Hier auf dem LoRaWAN haben wir eine Outdoor-Antenne, die dann im Werk verbaut ist. Da werden die Daten sozusagen hingesendet. Die können dann über zwei Wege weitergesendet werden: Zum einen natürlich über die Glasfaser, die wir gelegt haben, oder im Backup über 4G, dass sie dann über den Backhaul rausgehen. Von daher in Actility – das ist unser LoRaWAN-Network-Server. Also ich nenne es mal ein bisschen die Drehscheibe der Daten. Da gehen die Daten rein und können dann auch weiter rausgehen.

Und wenn sie dann rausgehen, gehen sie in die IoT-Plattform, akenza, und von dort aus geht es dann weiter.

Wir können hier praktisch direkt an Christian weitergeben. Die Daten kommen jetzt bei euch in der IoT-Plattform an. Was macht ihr damit?

Christian

Also die Daten werden vom Sensor – bei Murat der TWTG-Sensor – quasi generiert. Dann kommen die Rohdaten, die sogenannten, bei uns auf der Plattform an. Das funktioniert, indem wir auf unserer Plattform einen sogenannten Data Flow hinterlegen. Das heißt, wir müssen erst mal wissen: Was für einen Sensor haben wir, über welches Netzwerk? Murat nannte eben Actility. Die Netzwerke – es gibt ja mehrere davon, mehrere Anbieter – sind bei uns direkt als sogenannte Connectivity as a Service hinterlegt.

Welches Netzwerk am Standort des jeweiligen Kunden verfügbar ist oder aufgebaut ist, kann bei uns direkt auf der Plattform gewählt werden. Das heißt, klicke ich das Netzwerk an – LoRaWAN –, wähle ich dann den entsprechenden Netzwerkprovider, LNS, LoRaWAN Network Server, und dann wähle ich das Gerät aus und dann wähle ich den Output aus, sprich in dem Fall zum Beispiel die akenza-Plattform. Und dann habe ich diesen Data Flow, der aus diesen drei Steps besteht, konfiguriert für dieses Gerät. Kann das natürlich auch für weitere Geräte desselben Typs nutzen.

Und dann kommen die Daten – in dem Fall sind es dann Rohdaten dieses TWTG-Sensors – bei uns auf der Plattform an. Zum Beispiel XYZ-Achse, wie Murat schon sagte, Schwingungen, Frequenzbänder, Beschleunigungswerte, Temperaturen etc. Und mit diesen Daten kann der Kunde dann mit unseren entsprechenden Features, die wir anbieten – zum Beispiel ein Dashboard-Feature, das der Kunde nutzen kann und nicht muss –, einen entsprechenden Dashboard aufbauen und sich diese Daten visualisieren, zum Beispiel als Graph. Und das hat auch die Currenta gemacht in dem Fall, die Conneqtive.

Murat

Genau, und was wir dann mit den Daten machen können, wenn die reinkommen: Man kann auch Grenzwerte oder dergleichen oder Trendanalysen fahren lassen und kann daraus dann eine Benachrichtigung an eine E-Mail machen, wo wir zum Beispiel einen Full Service anbieten für die Pumpe. Wir machen die Sensorik, aber auch mit dem Partner von uns die Auswertung, dass, wenn ein Schwingungsbild gerissen wird, dann auch ein Field Service kommen kann, dass man vor Ort einmal händisch nachmisst.

Ich glaube, das ist wirklich auch einer der naheliegendsten und direktesten Anwendungsfälle: Grenzwerte zu ziehen und dass man darüber lernt, welche Grenzen akzeptabel sind und welche nicht. Aber das ist also der erste Schritt, und dann geht es ja weiter, bis hin zu Predictive Maintenance, KI-Modellen, also klassische Machine-Learning-Modelle zu trainieren. Seid ihr schon auch in die Richtung gegangen, und wo steht ihr da?

Murat

Ich würde erst mal sagen, der Bread-and-Butter-Ansatz, wo man sagt, wir arbeiten mit Grenzwerten, kann schon wirklich einen Großteil abdecken, wo wir sagen: 95 Prozent der Probleme kriegen wir so gelöst. Wir haben natürlich jetzt auch Schwingungsbilder – zum Beispiel an der Kühlung, wo wir unsere Schwingungsexperten haben. Der Anton macht dann auch Machine-Learning-Modelle für komplexe Schwingungsbilder, wo man Anlagen hat, die auf demselben Fundament arbeiten, die sich gegenseitig stören können, dass man da dann optimale Settings hat, wie man diese ansteuern muss.

Also wie stark der eine Kompressor arbeitet, dann der andere, wie stark die Ventilatoren arbeiten in dem Zusammenhang, dass man eine gesamtheitliche Optimierung hat. Das ist aber natürlich etwas komplexer, dann sind wir auch schon wieder in einem Ingenieursprojekt und etwas raus aus dem Plug-and-Play-Geschäft.

Ja, ich glaube, diese dezidierten Modelle, das ist einfach nach wie vor bei jedem Einsatz komplex, und das braucht eine entsprechende Expertise. Toll, dass ihr dann den Anton da habt, das ist dann schon immer ein Asset.

Murat

Genau, wir können im schlechtesten Fall in Claude Code sagen: Bitte programmier uns ein Machine-Learning-Programm für die Anlage – und dann nach zwei Minuten kommt da was raus.

Genau, da ist die generative KI noch nicht so weit. Christian, jetzt noch mal zu der Device Type Library, um das für mich und für die Hörerinnen und Hörer ein bisschen greifbarer zu machen. Jetzt kann man um Geräte herum ja noch viel mehr machen, bis hin zu: Ja, wann fällt das Gerät aus? Also man kann ja ganz viele Metainformationen theoretisch mitgeben. Wo hört ihr sozusagen bei der Device Type Library auf? Also das ist schon sehr gut, wenn man die Semantik der einzelnen Geräte versteht. Kannst du das ein bisschen beschreiben? Geht es da maßgeblich ums Anmelden im Netzwerk, geht es schon ums Verständnis der Daten, die da erfasst werden?

Christian

Korrekt. Es gibt natürlich Sensoren, die können beispielsweise nur Druck messen, sonst können sie gar nichts, oder nur Temperatur. Dann gibt es auch Sensoriken wie TWTG, die machen Vibration, Ultraschall. Es gibt noch weitere Sensoren, die sind hybrid, die machen noch Temperatur. Es gibt viele verschiedene Faktoren, also auch Werte, die von einem Sensor über das LoRaWAN-Protokoll geschickt werden. Und die werden entsprechend alle dekodiert auf der Plattform. Und wie ich schon sagte, das „dann fällt der Sensor aus“ im Sinne von: Wie lange hält die Batterie? So interpretiere ich das jetzt mal. Das kann man bei uns entsprechend anzeigen lassen. Also wie ist der Batteriezustand, wie ist aktuell die Netzwerkqualität?

Man kennt dieses typische Handy-Symbol mit diesen Balken oben, was man vom Handy hat. Kann man bei uns auch anzeigen lassen. Wie ist der Spreading Factor von dem Gerät? Das heißt, wie ist die Empfangsqualität etc. etc. Das sind alles Möglichkeiten, die wir auf dieser Device Type Library schon quasi integriert anbieten.

Wenn das Gerät ausgewählt wird und bei uns in die Plattform eingebunden wird, dann gibt der Kunde quasi nur noch die Grunddaten ein, die ich benötige, also quasi eine Device ID und einen Key. Dann ist das Gerät eindeutig identifiziert und sendet die Daten auf unsere Plattform. Alles Weitere kann er dann nach seinen Vorstellungen konfigurieren. Also die sogenannten Spalten, was ich eben sagte – Batteriestand, Empfangsqualität, Spreading Factor und und und – kann der Kunde konfigurieren, wie er möchte. Aber es ist grundsätzlich bei uns hinterlegt.

Super. Du hast ja auch gesagt, ihr seid da sehr technologieagnostisch, also Sensoren von allen möglichen Herstellern und so. Zwei Sachen, die ich gerne verstehen würde. Zum einen: Wie baut ihr diese Library weiter aus? Also was ist da der Trigger? Geht ihr in den Markt und sucht nach weiteren Sensoren, die noch nicht drin sind? Oder reagiert ihr immer auf Kundenanfragen? Oder kommen vielleicht sogar die Lieferanten selber zu euch und sagen: Hey, guck mal, wir haben einen neuen Sensor, baut den mal bitte mit ein? Also dieser Block.

Und dann, das kann vielleicht danach kommen, genau diese Technologieagnostik auch auf andere Bereiche bezogen. Wo seht ihr vielleicht auch Unterschiede – hängt natürlich immer vom Anwendungsfall ab, wirst du sicherlich sagen –, aber vielleicht kannst du da auch schon ein bisschen was zu Unterschieden auf verschiedenen Levels sagen. Zum Beispiel LoRaWAN: Du hast ein paar Alternativen angesprochen. Was sind denn da die Alternativen, und wie betrachtet ihr die? Weil ihr werdet ja wahrscheinlich verschiedene von diesen Technologien auch nutzen.

Christian

Sowohl als auch: Es kommen Hersteller auf uns zu und möchten mit uns eine Partnerschaft eingehen. Wir haben diese Partnerschaften auch auf unserer Homepage dargestellt, mit welchen Herstellern wir kooperieren. Das heißt, die Geräte der Hersteller werden dann Stück für Stück in die Library aufgenommen. Dann gibt es natürlich Kundenprojekte, die ein spezielles Gerät sehr, sehr stark nutzen. Natürlich wird dieses Gerät dann von uns als Leistung eingebunden für dieses Kundenprojekt. Das heißt, einmal eingebunden, ist es drin, kann von allen anderen auch genutzt werden.

Und natürlich schauen wir auch am Markt, was ist denn „what's hot and what's not“, wie man so schön sagt. Man sieht, das ist ein Gerät, was uns auch in anderen Use Cases, die wir vielleicht gar nicht betreuen, sehr häufig begegnet. Dann nehmen wir das hin und wieder auch gerne bei uns in die Library auf. Das ist von diesen drei Faktoren eben abhängig.

Und die andere Frage, die du gestellt hast, zur Alternative zu LoRaWAN: Es gibt noch das Protokoll mioty zum Beispiel. Es gibt auch hybride Gateways, die beides können, also LoRaWAN und mioty verarbeiten, das heißt, ich kann ein Hybridnetzwerk aufbauen. Ich möchte jetzt ungern auf die Vor- und Nachteile der Technologien eingehen, das würde den Rahmen sprengen. Dann gibt es die Thematik NB-IoT, also Narrowband IoT, und die LTE-M-Technologie. Das bedeutet also, je nach Anwendungsfall, wo befinde ich mich:

Im Feld nutze ich eine entsprechende Technologie. Bin ich in einer großen Site, in einem Chempark wie bei der Currenta, kann ich möglichst viele Gateways aufstellen, habe ein sehr engmaschiges Netz und nutze gerne mal LoRaWAN-Sensoren. Wenn ich aber sehr, sehr weite Flächen abdecken muss, ich bin irgendwo in einem Waldgebiet, ich habe keinen Strom dort liegen, ich kann schlecht Gateways aufstellen, dann nutze ich eben einen batteriegetriebenen Sensor, der direkt eine LTE-Karte integriert hat, also eine SIM-Karte, und nutze dann die Technologie LTE, um die Daten direkt über LTE an den Server, akenza, zu schicken.

Und jetzt, Murat: Wenn man das implementieren will – habe ich das richtig verstanden, ihr macht so das Komplettpaket? Jetzt habt ihr das bei euch im Chempark selber zum Einsatz gebracht, und jetzt, dadurch dass ihr euch dieses Wissen aufgebaut habt, stellt ihr das jetzt auch anderen zur Verfügung als so eine Paketlösung sozusagen. Kannst du mal beschreiben, was der Kern der Lösung ist – auch vielleicht die Abgrenzung: Was macht ihr und was macht ihr nicht?

Murat

Unsere Stärke liegt wirklich im Systemhausgedanken, wo wir sagen: Wir bringen die Expertise und Partnerschaften von den Herstellern mit, für Sensorik bis hin zur Auswertung und Visualisierung für den Kunden, oder sogar den Betrieb und den Austausch der Motoren. Wir haben auch einen Partner, Tectrion, der dann die Schwingungsanalyse nutzt, um vor Ort Befunde zu machen oder einen Austausch der Pumpe zu machen. Wir können den ganzen Service anbieten.

Wir haben jetzt die Wasserzähler, die wir bei uns in den Werken versuchen, sukzessive auf LoRaWAN umzubauen, um die Fahrten im Chempark zur Auslesung zu reduzieren. Dann hat man natürlich den Schmerz, sozusagen den Decoder richtig zu konfigurieren. Das würden wir auch mitbringen – auch mit den Herstellern als Partnern, wo man sagt: Wir haben den Sensor, den wollen wir so auslesen. Dann muss man doch einiges an E-Mails back and forth machen, wenn der Sensor nicht gerade bei akenza implementiert ist. Wenn er da drin ist, geht das Plug and Play per einem Klick.

Was eine Riesenhilfe ist, weil das schon mal eine Woche oder zwei an Projektzeit dauern kann, diese Absprachen einfach zu machen. Dann rollen wir das Produkt aus, die Sensoren rein, und können sie dann ins gewünschte System zum Beispiel des Kunden reinbringen. Das gewünschte System bei uns ist eine Verrechnungsplattform. Deswegen macht es weniger Sinn, das auf einer IoT-Plattform zu visualisieren, sondern es muss nur verrechnet werden. Dann bringen wir das aus der akenza direkt in die Plattform rein, im gewünschten Format, dass der Ingestor funktioniert – per MQTT oder OPC UA oder per CSV, die im richtigen Ordner abgespeichert wird und dann von dem Programm konsumiert wird.

Das bindet auch schön noch die Kette bis zum Schluss, auf was man alles tut. Und da hängt ja einiges über diese verschiedenen Schichten dran an Themen. Genau, gerade im Kontext der Plattformkonfiguration: akenza hat ja so ein bisschen einen No-Code-, Low-Code-Ansatz für die Konfiguration. Kannst du mal sagen, wenn ihr jetzt so ein typisches Kundenprojekt im Blick habt, was macht sozusagen Christian mit akenza, was machst du, Murat, mit Currenta Conneqtive?

Und das bleibt ja noch sozusagen beim Kunden. Also die ganz einfachen Sachen wird er wahrscheinlich machen, auch wollen, dass er eine gewisse Flexibilität hat. Einen Teil macht ihr selber, Murat, auch bei euch in euren eigenen Implementierungen, aber auch als Service für die Kunden. Und dann kommt akenza wahrscheinlich bei den komplexeren Themen.

Murat

Ich kann einmal das Beispiel an der Schwingungsanalyse nehmen. Sagen wir, wir haben jetzt einfach den Kunden A. Der Kunde A möchte gerne im Piloten zehn Sensoren ausgestattet haben. Für zehn Sensoren nutze ich natürlich keine eigene IoT-Plattform. Die würden wir dann über die akenza als mandantenfähiges System zur Verfügung stellen von unserer Seite aus. Und was wir machen würden, wäre: einmal in den Maschinen schauen, welche Sensorik kann man nutzen? Sind die schnell oder langsam drehend? Ist das jetzt ein Rührwerk oder ist es ein schnell drehender Motor? Dann müsste man vielleicht gucken, welchen Sensor man nimmt.

Diesen verbauen wir dann vor Ort mit dem Montage-Team, binden das in ein lokales LoRaWAN-Netzwerk ein, das wir deployen und auch instand halten und warten und betreiben. Die Daten gehen dann sozusagen aus dem lokalen System ins Actility. Von dort aus werden sie dann ins akenza gesendet, und dort können wir dann häufig 30 Tage einmal die Maschinen laufen lassen, dass wir engmaschig die Daten bei uns reinfließen lassen, wo wir sagen: Wir wollen alle 30 Minuten einen Wert haben. Können dann nach 30 Tagen mit dem Kunden zusammen in der Plattform mal schauen, wie die Daten aussehen, und dann die Grenzwerte einmal setzen.

Es gibt natürlich ISO-Grenzwerte, die man direkt nutzen kann, aber meistens ist es für spezifische Anlagen vor Ort dann gut, das noch mal nachzujustieren. Und das würden wir als Expertise mitbringen, wo wir sagen: Wir bringen die Sensorik, die Montage, das Netz und die Plattform mit. Und die Plattform ist sozusagen gehostet und betrieben von akenza.

Sehr gut. Aus meiner Sicht macht das schon sehr viel Sinn, auch wie wir das jetzt beschreiben, von den konkreten Themen. Was mir wichtig ist, glaube ich, noch mal zu betonen: dieses Missverständnis, dass es immer um den einen Anwendungsfall geht, der dann gleich einen Return on Investment von einem halben Jahr braucht. Sondern da geht es darum, auch Infrastruktur wie LoRaWAN aufzubauen, wo man dann, wenn man das mal hat und wenn das funktioniert, ganz viele Anwendungsfälle umsetzen kann. Daher ist das oft so ein bisschen misleading, also ein bisschen ein Missverständnis auch, was da generiert wird, wenn man wirklich über einzelne Anwendungsfälle spricht. Ich würde aber trotzdem die Frage stellen: Habt ihr so einzelne Anwendungsfälle, wo ihr mal drüber reden könnt? Weil so ein Infrastruktur-KPI gibt es wahrscheinlich gar nicht so transparent.

Murat

Wir können sagen, wir haben ein, zwei Use Cases, wo wir einen direkten ROI haben. Weil wir bieten auch häufig die Services als Abonnement an. Wo wir sagen: Wir haben zum Beispiel alte Gebäude auf dem Gelände gleichzeitig, was ja in Deutschland sehr häufig der Fall ist. Da können wir direkt eine Lösung reinbringen, um die Heizkosten zu reduzieren, dass wir eine digitale Einzelraumregelung haben, die Temperaturen messen, die Räume bedarfsgerecht heizen können und so direkt die Kosten einsparen, CO₂ sparen, und häufig ist das weniger als die Kosten, die wir an Energie auch einsparen, sodass der Kunde keine ROI-Zeit direkt hat.

Und wenn dann mit dem Use Case schon das Netz aufgebaut ist, haben wir natürlich das Shared Medium und können dann auf die ganzen weiteren Use Cases expandieren, wo wir sagen: Wir haben die Schwingungssensorik, die wir reinbringen, wir haben die Schmierungsoptimierung, wo dann nicht mehr ein Techniker mit einer Schmierpumpe rumlaufen muss und im Monat verteilungsweise an die Anlagen muss – die Sensorik, die ich gerade beschrieben habe, die Schwingungssensorik oder auch Druck- und Temperaturmessungen, um einmal Sicherheit zu bringen oder den Prozess zu optimieren.

Also praktisch Infrastructure as a Service und Software as a Service in Kombination. Dass ihr das als Service anbietet, und durch die Einsparung kann man schon die Infrastruktur abdecken, und dann kann man eben darauf noch weitere Anwendungsfälle zusätzlich bauen. Ich finde, das ist ein schönes Bild, was viele erst mal verstehen müssen: dass man sozusagen auf der Infrastruktur dann immer weiter aufbauen kann und sich das so sukzessive verbessert. Das ist ja sozusagen auch der Plattformgedanke. Christian, hast du noch die eine oder andere Kennzahl und Erkenntnis, die du dazu teilen willst?

Christian

Grundsätzlich, um noch mal auf die andere Eingangsfrage zurückzukommen: „Macht ihr eigentlich alles?“ Also, das Format hier heißt ja IoT Use Case Podcast. Grundsätzlich, wie du sagst, ist richtig: Es können alle Use Cases abgebildet werden. Das kann auch über unsere Plattform natürlich erfolgen. Murat hat vorhin das Wort Datendrehscheibe genannt, in Verbindung mit Actility. So sehen wir uns auch. Wie schon gesagt, wir können alles anbinden, was am Markt verfügbar ist. Ob das Sinn macht, muss natürlich beleuchtet werden, ganz klar. Dementsprechend filtern wir dann auch.

Wir können unendlich skalieren, das ist nicht das Problem. Wir haben auch die entsprechenden Output-Konnektoren, die gingen auch schon kurz in die Richtung vorhin, ich nannte es bei meinem Beispiel des Data Flows. Wir können die akenza-Datenbank nutzen, müssen das aber nicht. Das heißt, die Daten können bei uns dargestellt und auch visualisiert werden. Aber auch, wie Murat schon sagt, es gibt ja auch solche Machine-Learnings. Das heißt, die Daten werden dann per CSV weitergeschickt – das war der Klassiker –, SQL-Datenbanken, Power-BI-Tools, Webhook. Wir haben Cloud-to-Cloud-Kommunikation über eine entsprechende API. Also da gibt es unglaublich viele Möglichkeiten. Natürlich Alarmings: Teams, Slack, Messages, SMS. Das kann alles parallel ausgewählt werden. Dementsprechend sind wir auch agnostisch aufgestellt, horizontal, bei den Output-Konnektoren, wo die Daten dann auch hingehen sollen. Das ist das Erste.

Und der zweite Punkt, das geht auch in die Richtung Zeit: Zeit ist Geld. Und wenn ich jetzt über so eine Open-Desk-Policy beim Unternehmen nachdenke – ich habe ein Bürogebäude mit 500 Büros, und jeder Mitarbeiter kann morgens, wenn er kommt, wählen: Wo arbeite ich denn? Man kennt dieses Modell, jeder Arbeitsplatz ist ziemlich gleich aufgebaut. Und diese Suche nach einem Arbeitsplatz morgens, das verschlingt oft sehr viel Zeit.

Und wenn ich dann über einen sogenannten Sign Screen – man kennt es, man kommt über ein Bürogebäude rein, sehe einen großen Floorplan und ich sehe sofort auf einen Blick, welcher Raum ist grün, also frei, und welcher Raum ist belegt: Die Mitarbeiter sparen sich unglaublich viel Zeit bei der Suche. Man unterschätzt das gerne. Auch das machen wir, sprich, wir bilden dann die Floorplans als 2D-, 3D-Modell ab. Jeder Schreibtisch, jeder Stuhl ist mit dem Sensor entsprechend belegt. Man kann auch vorhandene Bewegungsmelder, Sensoriken nutzen.

Christian

Und das ist so ein Use Case, der gerne unterschätzt wird: diese Zeit, diese Raumsuche und zu sehen, was passiert denn. Und dazu noch in Verbindung – auch wenn ich wieder von Bewegungserkennung spreche –: Wie ist es denn mit den Waschräumen? Müssen sie gereinigt werden, wurden sie überhaupt benutzt heute? Muss ich mein Team da reinschicken? Brauchen sie wieder eine fette Stunde, was zu reinigen, was gar nicht benutzt wurde? Auch solche Themen spielen da eine große Rolle, einfach die Optimierung von Gebäuden. Und das Ganze machen wir jetzt auch natürlich mit der Conneqtive im Chempark.

Ja, spannende Anwendungsfälle, wenn man dann da weiter ausbaut, letztendlich auf Basis von so einem Thema. Wir hatten auch mal über Kugellager gesprochen: Wenn man Kugellager austauscht, gibt man 1.000 Euro aus. Aber wenn man das nicht rechtzeitig tut, dann hat man das Problem mit den Schaufelrädern, und dann muss man halt 10.000 Euro pro Schaufelrad ausgeben und solche Sachen. Ich glaube, das ist besonders, wenn man mehr davon abbilden kann auf Basis einer Infrastruktur, dann ist das immer eine tolle Sache.

Das hat sich ja bei dir jetzt fast zu gut angehört, um wahr zu sein, Christian: Es sind über alle Konnektoren da und alles abgebildet und alles Output. Aber jetzt mal den Blick nach vorne gewendet: Wo wird dann jetzt noch weiter entwickelt und weiter gearbeitet? Ihr werdet ja wahrscheinlich, typisch IT, nie fertig sein und immer so ein bisschen eine Roadmap haben. Also was sind denn die Themen, die ihr jetzt noch in der Plattform zum Beispiel verbessert? Was wird generell bei IoT verbessert?

Christian

Das ist eine sehr gute und sehr schwierig zu beantwortende Frage. Ich bin kein Entwickler bei uns im Team, das heißt, ich weiß nicht, was auf der Roadmap steht. Grundsätzlich werden natürlich die Projekte, die reinkommen, im Speziellen beleuchtet: Wie kann ich das Projekt verbessern, was hat der Kunde noch für Anforderungen? Wir haben die Erfahrung gemacht: Kein Kunde ist gleich. Es gibt nicht den roten Faden, dass der Kunde sagt, ich habe einen Sensor, ich habe LoRaWAN, ich möchte die Daten visualisiert haben, und mit dem Budget, das reicht mir.

Jeder Kunde hat irgendwo seine spezielle Anforderung. Er möchte hier eine Änderung, er möchte da eine Änderung. Und das sind so diese rollierenden Themen, die wir ständig auf dem Tisch haben, Anwendungen mit den Kunden zu optimieren. Und wie schon gesagt, da gibt es keinen Königsweg. Es ist einfach so, dass jede Anwendung irgendwo eine Differenzierung zur anderen Anwendung hat. Und daran arbeiten wir täglich. Aber diese Flexibilität bereitzustellen, das ist eben unsere Stärke.

Das heißt, wir fangen nirgendwo bei null an. Wir sind gut aufgestellt, und wir haben die Möglichkeiten bei uns im Portfolio. Und jede Änderung, die reinkommt, jeder Wunsch, kann in sehr kurzer Zeit und sehr schnell umgesetzt werden. Und das auch meistens über den Low- oder No-Code-Ansatz unserer Plattform, vom Kunden aus selbst. Und das ist der Vorteil. Das heißt, Folgekosten, wenn man so möchte, entstehen sehr, sehr wenige. Es sei denn, es ist das super fancy Feature, was der Kunde haben möchte.

Dann müssen wir auch schauen, ob wir es entwickeln können, wie lange es dauert, Angebot machen und so weiter. Aber grundsätzlich geht das alles mit Bordmitteln unserer Plattform, und das ist unser großer Vorteil.

Okay, so, dann, Murat, kannst du da mal ein paar Beispiele nennen, zwei, drei Beispiele, wo du sagst: Hätten wir das früher gewusst, hätten wir das anders gemacht – und machen es jetzt anders in den folgenden Projekten.

Murat

Was wir lernen konnten, ist, häufig doch auf einen Standard zu setzen, den es gibt, dass wir da schneller unterwegs sein können. Häufig sind Anforderungen, die am Anfang als Must-do erscheinen, am Ende vielleicht doch nur Nice-to-have. Also das stellt sich häufiger dann raus, wenn man sagt: Man hat dann im Feld sehr, sehr teure Hardware genutzt und aufgebaut, und am Ende ist das Projekt auch etwas zu groß geraten im Anforderungskatalog. In der Software haben wir bis jetzt noch keine zu großen Probleme gehabt, da sind wir doch relativ glücklich gewesen mit der akenza.

Wie Christian sagte, kann es dann sein, dass mal etwas nachentwickelt werden muss. Da kann man drüber sprechen, da hat man ein Kontingent, dass man da gemeinsam entwickeln kann, um eine Lösung custom zu kriegen. Wenn man zum Beispiel sagt – bei uns der Chempark ist jetzt auch kein 0815-Case von der Firma, sondern wir haben ein großes Areal –, wir können die Karten nehmen, wir können auf der Karte dann visualisieren, welcher Block gerade wie beliefert wird und wie wir das optimieren könnten im finalen Ausbau.

In dem Fall in der IoT-Plattform hatten wir jetzt weniger große Learnings, weil das wirklich out of the box kam, und mehr dann bei der Sensorik und im Feld, wo wir sagen mussten: Da haben wir ein bisschen Lehrgeld gezahlt, weil wir vielleicht doch zu komplex oder zu stark als Ingenieur gedacht haben, wie wir das letzte Quäntchen optimieren können, und da vielleicht etwas pragmatischer sein können.

Pragmatischer Ansatz, das finde ich generell sehr gut. Und da mit euch zusammenzuarbeiten, macht sicherlich auch Sinn. Auch vielleicht den Austausch mit anderen zu wählen: Da haben wir den IoT-Anwenderzirkel in der IoT Use Case Community. Da mit dabei zu sein, glaube ich, ist auch sehr spannend, genau über solche Fälle zu sprechen und über die Probleme zu sprechen und sich da abzugleichen. Ich bin jetzt schon einige Male dabei gewesen. Das sind immer interessante Diskussionen, genau aus diesen ganz konkreten Problemen, die halt bei der Umsetzung von Themen entstehen.

Vielen Dank meinerseits, war ein sehr interessantes Gespräch – dazu, dass ihr jetzt auch nach vorne hin gemeinsam anbietet, unabhängig natürlich voneinander, dann doch auch gemeinsam. Fand ich sehr spannend, weil ihr es eben auch selber zum Einsatz bringt, eben den Chempark unter anderem. Daher vielen Dank, vielen Dank auch an die Zuhörerinnen und Zuhörer, und bis zum nächsten Mal.