Do you want to see our content in English?

x
x

Predictive Maintenance mit LoRaWAN: Wie Honeywell Industrie-Equipment smart macht

““

Sie sehen gerade einen Platzhalterinhalt von Spotify Player. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf den Button unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.

Weitere Informationen
IoT Use Case Podcast auf Spotify anhören
IoT Use Case Podcast auf Spotify anhören
IoT Use Case Podcast auf anderen Plattformen anhören

In Episode 191 des IoT Use Case Podcasts spricht Gastgeberin Ing. Madeleine Mickeleit mit Martin Kühne, Business Development Manager DACH bei Honeywell. Thema sind industrielle IoT Projekte aus der Praxis mit Fokus auf Condition Monitoring und Predictive Maintenance. Im Mittelpunkt stehen LoRaWAN Sensoren von Honeywell, die Pumpen, Lüfter und anderes rotierendes Equipment überwachen, Ausfälle vermeiden und Wartung planbar machen.

Podcast Zusammenfassung

Predictive Maintenance mit LoRaWAN in der Praxis


Ungeplante Stillstände von Pumpen, Lüftern und Motoren kosten Zeit und Geld. Martin Kühne zeigt, wie Honeywell mit robusten LoRaWAN Sensoren Vibrationen, Akustik und Temperatur erfasst und Anomalien früh erkennt. So lassen sich Zustände kontinuierlich überwachen, Wartungseinsätze gezielt planen und Sicherheitsanforderungen erfüllen.
Die Lösung integriert sich in bestehende Umgebungen. Daten fließen über Gateways und MQTT in Kundensysteme oder vorhandene LoRaWAN Netze. Beispiele reichen von Hallenlüftern in der Teileproduktion bei Mercedes Benz bis zu Kerosinpumpen im Umfeld des Flughafens Frankfurt, wo zustandsbasierte Wartung Tauschzyklen optimiert und Kosten senkt.
Honeywell bringt Erfahrung aus der Prozessleittechnik mit, inklusive Industrietauglichkeit durch IP67, Ex Ausführungen und NAMUR Prüfungen. Für Skalierung sorgen Partner, die vom Sensor bis zur Anbindung an OT und IT unterstützen. Wer rotierendes Equipment betreibt und Produktionsqualität sowie Arbeitssicherheit steigern möchte, erhält einen klaren Fahrplan für den Einstieg in zustandsbasierte Wartung mit IoT. Jetzt reinhören und erfahren, wie Monitoring, Datenintegration und Serviceprozesse zusammenwirken.

Podcast Interview

Hallo, liebe Freunde des IoT. Heute gibt es wieder Praxis pur mit spannenden IoT Projekten und konkreten Umsetzungen. Mit dabei ist die Firma Honeywell. 97.000 Mitarbeitende weltweit in 79 Ländern. Was Honeywell genau mit IoT macht, erfahrt ihr in dieser Folge. Wir sprechen über Use Cases aus der Praxis, unter anderem mit Mercedes Benz. Es geht um Lüfter auf dem Hallendach, warum man das macht und welche Einsparungen möglich sind. Dann haben wir ein Projekt rund um ein Tanklager. Dort geht es um Kerosin für den Flughafen Frankfurt. Zwei Großpumpen sind im Einsatz und wir beleuchten den richtigen Tauschzeitpunkt. Wir gehen kurz auf einen Stahlwerks Case ein, ebenfalls spannend. Die Technologien heute im Fokus sind LoRaWAN und passende Sensoren im Feld. Dafür habe ich Martin Kühne eingeladen. Er ist Business Development Manager DACH für Honeywell-Sensoren. Er kommt aus der Praxis und teilt heute seine Einblicke. Alle Infos zur Umsetzung solcher und ähnlicher Projekte findet ihr wie immer unter www.iotusecase.com und in den Show Notes. Und damit ab ins Podcaststudio.

Hallo Martin, schön, dass du dabei bist. Wie geht es dir und wo erreiche ich dich gerade?

Martin

Hallo Madeleine. Ausnahmsweise bin ich nicht unterwegs. Normalerweise bin ich viel bei Kunden in Deutschland, Österreich und der Schweiz. Diese Woche findet Ende der Woche ein Gastag in München statt. Am Wiesnfest kann ich leider nicht teilnehmen, ich muss wegen anderer Termine zurückfahren. Das wird trotzdem spannend, es geht um LoRaWAN im Gasbereich. Vibration spielt ebenfalls eine Rolle.

Wir nehmen am 23. September auf, es ist also Wiesnzeit in München. Wo bist du normalerweise, hast du einen festen Standort oder bist du immer unterwegs?

Martin

Meistens bin ich unterwegs. Wenn ich zu Hause bin, dann in Karlsruhe. Ich lebe schon immer dort und bin dort fest verankert. Beruflich bewege ich mich weltweit, in früheren Jobs und jetzt für Honeywell in der DACH-Region. Es macht Spaß, bei Kunden vor Ort zu sein und Themen direkt anzugehen und Lösungen zu bieten.

Honeywell hat den Hauptsitz in North Carolina. Du bist speziell für die DACH-Region unterwegs und dort vor allem zum Thema LoRaWAN und die passenden Sensoren. Kann man das so sagen?

Martin

Das kann man genauso sagen. Ich bin einer der weltweiten Spezialisten für das Thema LoRaWAN. Ich habe diese Technologie in Deutschland, Österreich und der Schweiz stark vorangetrieben, weil mir die Technik einfach Spaß macht. Sie ist neu, die Industrie akzeptiert sie zunehmend und treibt sie weiter voran. Das ist genau das Spannende daran. Business Development bedeutet für mich nicht nur Verkauf, sondern das Thema wirklich zu entwickeln und bekannt zu machen. Deshalb auch die Zusammenarbeit mit euch.

Mich freut es total, dass du heute dabei bist. Honeywell kennt man ja schon lange und ich habe eure IoT-Lösungen immer wieder auf dem Schirm gehabt. Aber heute von dir direkt mehr über eure Projekte und euer Angebot zu hören, ist super spannend. Vielleicht kannst du kurz erklären, was sich in den letzten Jahren in eurem Markt getan hat. Ihr seid ja ein riesiger Technologieanbieter mit enormer Ingenieurskraft. Warum legt ihr so viel Fokus auf IoT und digitale Lösungen? Was war der Auslöser?

Martin

Der Hauptgrund ist die vorausschauende Wartung, also Predictive Maintenance. Das Thema wird immer wichtiger. Man möchte wissen, was mit dem Equipment passiert, wann ein Ausfall droht und wann man reagieren muss. So lassen sich Kosten sparen. Besonders teuer in Anlagen ist das Verlegen von Kabeln. Wenn ich kabelgebundene Sensoren habe, muss ich Signalkabel verlegen, was sehr aufwendig und teuer ist. Mit LoRaWAN kann ich das vermeiden. Da muss man keine Kabel mehr verlegen, sondern kann Sensoren flexibel platzieren, einbinden und die Daten über die Cloud abrufen.

Bevor wir auf den Business Case und die Investitionsgründe eurer Kunden eingehen, noch eine Frage. Du hast gerade den Begriff Equipment erwähnt. Habt ihr bestimmte Arten von Equipment im Fokus, die ihr mit euren LoRaWAN-Sensoren adressiert? Wer sind eure typischen Kunden?

Martin

Zielgruppe sind alle Unternehmen, die Pumpen, Ventilatoren, Motoren oder Getriebe einsetzen, also im Prinzip jedes rotierende Equipment. Ich habe die Sensoren sogar zuerst an meiner Kaffeemaschine getestet. Als das Mahlwerk anlief, konnte ich die Vibrationen hören und messen. Das zeigt gut, dass alles, was sich dreht oder vibriert, für unsere Sensoren interessant ist.

Ok, das heißt, eure Sensoren fokussieren sich vor allem auf die Aufnahme von Prozessdaten wie Vibrationen, wahrscheinlich in einem bestimmten Bereich. Gibt es noch andere relevante Messgrößen?

Martin

Ja. Wir messen zusätzlich Akustik, der Sensor kann also hören. Wir erfassen die Oberflächentemperatur, was bei Pumpen sehr wertvoll ist. Steigt die Temperatur, läuft etwas heiß, die Schmierung passt nicht mehr, Öl fehlt in den Wälzlagern. Wir messen auch Umgebungstemperatur und Luftfeuchtigkeit. Das ist eher nice to have, nicht immer notwendig. Entscheidend sind die Vibrationen in X, Y und Z, daraus leiten wir über Diagramme wie FTT ab, was mit der Pumpe passiert.

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

Worum ging es in dem Projekt mit den Hallenlüftern auf dem Dach bei Mercedes Benz?

Martin

Das war in einem Werk von Mercedes Benz für die Teileproduktion. Die Halle wird von oben belüftet, im fünften oder sechsten Stock sitzen Lüfter auf dem Dach, die Luft in die Halle blasen. Die Luftqualität muss konstant bleiben, deshalb gibt es in diesen großen Hallen Schnelltore, die schnell öffnen und schließen, damit sich die Luft beim Einfahren eines Gabelstaplers nicht austauscht. Fällt die Belüftung aus, steht die Produktion, weil die Qualitätsvorgaben für die Teile nicht mehr eingehalten werden. Wir haben dort die Rotation und die Geräusche der Lüfter gemessen. So kann man im Büro sofort sehen, wenn sich etwas verändert, denn die Lüfter laufen eigentlich konstant. Wir waren mit einer größeren Mannschaft vor Ort, sind aufs Dach gegangen und haben den Lüfter schon deutlich rappeln gehört. Der wäre uns fast um die Ohren geflogen. Der Maintenance Chef war entsetzt, dass das niemand bemerkt hatte. Wenn so ein Lüfter ausfällt, fällt die Produktion aus, das verursacht enorme Kosten. Vermutlich war dort seit drei Monaten niemand oben und hat nachgesehen. Genau hier helfen wir. Die Verantwortlichen können im Büro sitzen, eine Tasse Kaffee trinken und sehen es sofort. Wenn die Ampel auf Rot springt, wissen sie, an diesem Teil stimmt etwas nicht, ich muss los.

Das kriegen wir in unserer Community auch oft mit. Ungeplante Stillstände sind ein großes Thema, egal ob bei Lagern, Pumpen oder Lüftern. Oft fällt etwas ohne jede Frühwarnung aus. Konntet ihr im Mercedes Fall sagen, woran es lag? Vermutlich hattet ihr die Daten da ja noch nicht, ihr seid erst später mit euren Sensoren reingegangen und habt das System aufgesetzt, um überhaupt Daten zu erfassen, oder?

Martin

Genau. Man muss unterscheiden. Bei einer Pumpe können wir über eine ISO Vorgabe prüfen, ob sie läuft oder nicht. Bei rotierendem Equipment geht es darum, Anomalien zu erkennen. Wenn sich etwas verändert, also Geräusche lauter werden oder Schwingungen zunehmen, deutet das auf ein Problem hin. Ich erkläre das gern mit einem Beispiel. Ich fahre etwa 40.000 Kilometer im Jahr. Wenn es hinten am Auto plötzlich klappert, weiß ich sofort, das Geräusch gehört da nicht hin. Dann fahre ich in die Werkstatt. Genauso funktioniert es mit unseren Sensoren. Der Kunde bekommt eine Meldung, dass etwas am Ventilator auffällig ist, und kann gezielt nachschauen, bevor ein Ausfall passiert.

Das heißt, der Business Case liegt darin, Stillstände zu vermeiden und Wartung effizienter zu machen, denn wenn die Belüftung ausfällt, steht die Anlage, und das kostet.
Das war der Punkt in diesem Projekt. Und dann gibt es das zweite Beispiel mit dem Tanklager für Kerosin.
Ist das ein ähnlicher Use Case oder ein ganz anderer? Was war dort die Herausforderung?

Martin

Das ist eigentlich ein ganz anderer Use Case. In einem Tanklager in der Nähe von Raunheim wird Kerosin über Schiffe angeliefert und zwischengelagert. Von dort aus wird es über zwei große Pipelines zum Frankfurter Flughafen gepumpt. Das sind zwei riesige Pumpen, man kann sich ja vorstellen, wie viel Kerosin dort täglich gebraucht wird. In Frankfurt gibt es ein weiteres Tanklager mit siebzehn riesigen Tanks, die das Kerosin für etwa eine Woche Zwischenlagerung aufnehmen.
In diesem Prozess arbeiten zwei große Pumpen, die das Kerosin fördern. Es gibt eine dritte Pumpe als Ersatz, die regelmäßig instand gesetzt wird und dann im Wechsel eingesetzt wird. Der Austausch erfolgt bislang rein zeitbasiert. Die Instandsetzung einer dieser Pumpen kostet zwischen 100.000 und 150.000 Euro, weil sie sehr groß und komplex sind. Dieser turnusmäßige Wechsel passiert unabhängig vom tatsächlichen Zustand.

Mit unseren Sensoren können wir jetzt den tatsächlichen Zustand überwachen und sagen: Die Pumpe läuft nach einem Jahr noch einwandfrei, du musst sie nicht austauschen. So kann der Wechselzyklus verlängert werden. Oder wir erkennen frühzeitig, wenn sich etwas verändert, und können sagen: Achtung, die Pumpe ist nicht mehr in Ordnung, du musst sie bald austauschen. Das verhindert Ausfälle und spart Kosten. Wenn eine Pumpe ungeplant ausfällt, muss das Kerosin per LKW zum Flughafen transportiert werden. Das ist aufwendig und teuer. Wir ermöglichen also sowohl die Verlängerung der Einsatzdauer als auch eine rechtzeitige Warnung vor Ausfällen.

Ich kann mir vorstellen, dass viele, die hier zuhören, ähnliche Anwendungsfälle haben. Schreibt gern in die Kommentare, welche Use Cases ihr umsetzt und ob es bei euch auch um Wartung und Zustandsüberwachung geht.
Jetzt machen Kunden solche Dinge ja ganz unterschiedlich. Manche gehen manuell vor, steigen aufs Dach oder prüfen Anlagen vor Ort. Wenn du auf die technische Umsetzung schaust, was siehst du bei euren Kunden am häufigsten? Wie setzen sie solche Überwachungen heute um, bevor sie auf eure Lösung kommen? Wird das zum Beispiel über Bluetooth realisiert, oder wie gehen sie technisch vor Welche Herausforderungen siehst du dabei?

Martin

Ja, es gibt tatsächlich noch Methoden, die heute fast schon belächelt werden. Es gibt ein Video, das öffentlich zugänglich ist, in dem eine Kollegin durch eine Anlage läuft und sagt, sie riecht, ob irgendwo Gas austritt. Sie legt die Hand auf eine Pumpe, um zu fühlen, ob sie noch vibriert und richtig läuft. Das ist natürlich veraltet.
Bluetooth wird in manchen Fällen genutzt, aber das ist immer nur eine 1:1-Verbindung, also eine temporäre Messung. Wir setzen ganz klar auf LoRaWAN. Damit kann ich mehrere Sensoren über ein Gateway anbinden und habe eine durchgehende Überwachung rund um die Uhr. So bin ich ständig an der Messung dran, nicht nur einmal jährlich oder punktuell per Handmessung. Das ist der große Vorteil. Wenn ich heute eine Messung mache, die Tür hinter mir schließe und eine Pumpe hört kurz danach auf zu arbeiten, bekomme ich das ohne permanente Messung gar nicht mit.

Absolut. Ich will ein bisschen herausarbeiten, wie Unternehmen das heute häufig noch machen, wo aber eigentlich Potenzial verschenkt wird. Warum kostet das viele Kunden unnötig Geld, wenn sie nicht auf solche Lösungen setzen? Ich denke an Themen wie Geräteparametrierung oder Skalierung, wenn man tausende Geräte anbinden will. Wo stoßen heutige Technologien an ihre Grenzen und was ist aus deiner Sicht kein Best Practice mehr?

Martin

Wenn ich alle Punkte manuell prüfen muss, brauche ich schlichtweg mehr Personal. Das kann man mit Sensoren automatisieren. Ein Beispiel: Bei einem Kunden wurden die Vibrationen bisher manuell gemessen. Dabei haben sie 1.000 Messstellen identifiziert, die schwer zugänglich sind. Das betrifft auch den Personenschutz. Die Mitarbeitenden mussten Leitern aufstellen, hinaufsteigen und einhändig manuell messen. Mit unseren Sensoren entfällt das. Die Daten werden direkt erfasst und zentral eingesehen.
Ich denke, hier hat ein Umdenken stattgefunden. Fachpersonal ist knapp, und solche Messungen erfordern Know-how. Man muss genau wissen, wo man misst, um Fehler zu erkennen. Das alles kostet Zeit und Geld.

Warum habt ihr euch in solchen Projekten bewusst für LoRaWAN entschieden? Was waren die wichtigsten Entscheidungskriterien?

Martin

Genau. Die Entscheidungskriterien sind im Grunde das, was ich vorhin schon angesprochen habe: der Schutz und die Sicherheit der Mitarbeitenden. Wenn man wie in Ludwigshafen zehntausende Pumpen hat, möchte man sie zuverlässig überwachen, Stichwort Predictive Maintenance. Unsere Vision ist, dass der Sensor künftig selbst erkennt, was an einer Pumpe defekt ist. Wenn also beispielsweise ein Lager kaputt ist, prüft das System automatisch im SAP, ob das Ersatzteil verfügbar ist. Ist es vorhanden, wird eine Meldung an die Instandhaltung geschickt: Bitte hol das Ersatzteil und wechsle es an dieser Pumpe. Das ist die Vision, und ich denke, sie wird 2026 schon Realität sein.

[15:45] Lösungen, Angebote und Services – Ein Blick auf die eingesetzten Technologien

Dann sprechen wir jetzt also konkret über eure LoRaWAN-Sensoren. Ihr habt ja ein komplettes Set an Sensoren, die diese Daten erfassen, und zusätzlich einen Transmitter, der sie überträgt – in bestimmten Intervallen über das LoRaWAN Netzwerk. Ist das so richtig beschrieben? Kannst du erklären, wie das genau funktioniert?

Martin

Ja, Ich habe vor zweieinhalb Jahren mit dem Thema angefangen und gesagt: Wir können nicht nur Sensoren verkaufen, wir müssen auch Kunden unterstützen, die noch kein LoRaWAN-Netzwerk haben. Deshalb arbeiten wir mit Solution Partnern zusammen. Wir können die gesamte Kette abbilden – vom Sensor über das Gateway und den LoRaWAN Network Server bis zur Einspeisung der Daten in ein übergeordnetes System.
Wenn ein Kunde bereits ein LoRaWAN-Netzwerk hat, braucht er nur unseren Sensor. LoRaWAN ist ein offenes System, es gibt eine Payload-Beschreibung, über die man den Sensor einfach integrieren kann. Der Kunde kann die Daten dann selbst einbinden und verarbeiten. Wenn der Kunde kein eigenes LoRaWAN Netz hat, wie im Beispiel des Tanklagers, dann stellen wir eine Lösung bereit, bei der wir die Daten über Gateways einsammeln, mit einer Reichweite von drei bis vier Kilometern, und eine Schnittstelle bereitstellen – beispielsweise MQTT. Darüber können die Daten direkt in das System des Kunden integriert werden.

Das heißt, ihr bindet eure LoRaWAN-Sensoren also auch in bestehende MQTT-Landschaften ein. Wenn ein Kunde kein LoRaWAN-Netz hat oder eine andere Technologie nutzt, arbeitet ihr mit euren Solution Partnern zusammen und unterstützt beim Aufbau.

Martin

Man muss bedenken, Honeywell kommt ursprünglich aus der Prozessleittechnik. Das heißt, wir können die Daten nicht nur in unsere eigenen Systeme einbinden, sondern auch in fremde Systeme integrieren.

Du hast vorhin schon das Thema Anomalieerkennung und Analyse angesprochen. Im IoT ist es ja oft so, dass nicht alle Daten direkt in die Cloud oder ein anderes System geschickt werden, sondern ein Teil schon lokal vorverarbeitet wird. Wie viel Intelligenz steckt in euren Sensoren? Was passiert direkt vor Ort und was wird zentral ausgewertet?

Martin

Unser Sensor ist ein intelligenter Sensor, speziell für Pumpen. Wir brauchen dafür weder ein großes Rechenmodell noch künstliche Intelligenz. Der Sensor muss auch nicht angelernt werden. Wir haben die ISO 10816-3 – das ist der Standard, den jeder kennt, der sich mit Pumpen und Vibrationen beschäftigt – direkt im Sensor implementiert. Wenn wir dem Sensor die Pumpendaten übergeben, auch bei älteren Pumpen, kann er selbst entscheiden, ob sie in Ordnung ist. Das geschieht nach einem Ampelsystem: grün, gelb oder rot. So können wir sofort erkennen, ob ein Problem vorliegt. Wir brauchen also keinen Anlernvorgang und keine Vergleichswerte einer neuen, fehlerfreien Pumpe. Der Sensor kann auch bei bestehenden Anlagen direkt eingesetzt werden und liefert sofort eine Zustandsbewertung.

Ich habe gerade eure Website offen. Die Sensoren heißen Versatilis Transmitter, richtig‘? Ich packe den Link in die Show Notes. Das sind diese kleinen grauen Sensoren. Wie groß ist so ein Teil ungefähr?

Martin

Ich habe gerade einen in der Hand. Er ist kleiner als eine Getränkedose.

Schaut euch das gern an, ich verlinke es in den Show Notes.
Du hast vorhin erwähnt, dass ihr die Daten auch mit SAP verknüpfen könnt. Wenn also erkannt wird, dass etwas defekt ist, könnte der Sensor im Prinzip prüfen, ob das Ersatzteil im SAP-System verfügbar ist, und automatisch eine Meldung an das Maintenance-Team schicken. Wie setzt ihr das um? Läuft das auch über Solution Partner oder wie funktioniert diese Schnittstelle zwischen OT und IT?

Martin

Wir reden hier natürlich noch über eine Vision. Der Sensor wird aktuell erst in diese Richtung weiterentwickelt. Deshalb habe ich gesagt, dass wir bis 2026 eventuell noch eine kleine Hardwareanpassung vornehmen müssen. Aber man merkt, dass sich die Branche gerade stark verändert, vor allem in der Industrie und im chemischen Bereich. Die Unternehmen denken um und fragen sich, wie sie Systeme besser verknüpfen und echten Mehrwert daraus ziehen können. Wir waren letzte Woche auf der MEORGA MSR-Messe in Ludwigshafen – eine kleine, aber sehr industrielle und spezialisierte Messe. Viele sind auf uns zugekommen, weil sie erkannt haben, dass man in diese Richtung wirklich etwas bewegen kann und konkrete Vorteile erzielt.

Sehr spannend. Gibt es Best Practices aus solchen Projekten? Wie legt man beispielsweise den richtigen Zeitpunkt für einen Pumpentausch fest? Der Business Case ist ja klar, aber der eigentliche Prozess liegt oft beim Kunden. Wie bestimmt ihr gemeinsam in einer Partnerschaft diesen Zeitpunkt?

Martin

Ich sage immer, der Zeitpunkt ist eigentlich immer falsch, wenn man die Sensoren noch nicht installiert hat. Solange keine kontinuierliche Überwachung läuft, kann man auch nichts rechtzeitig erkennen. Wir hatten einen Kunden, der gerade Testgeräte im Einsatz hatte. Er wollte das Konzept prüfen, und genau in dieser Zeit ist ihm eine Pumpe ausgefallen, an der kein Sensor installiert war. Hätten wir den Sensor dort gehabt, hätten wir den Ausfall vorher erkannt. Der Punkt ist also: Es ist immer zu spät, wenn man erst nach einem Schaden über die Einführung nachdenkt.

Und wenn die Sensoren dann installiert sind – nehmen wir an, ich habe das Set über MQTT im LoRaWAN Netz eingebunden – wie bestimmt ihr dann den optimalen Zeitpunkt für den Austausch? Arbeitet ihr da mit Solution Partnern und euren Kunden zusammen? Ihr habt ja das technische Know-how über eure Sensoren und ihre Grenzen. Bringt ihr dieses Wissen aktiv ein oder übernimmt das der Kunde komplett selbst?

Martin

Ja, das bringen wir natürlich mit ein. Wobei man sagen muss, dass große Unternehmen oft eigene Vibrationsspezialisten haben. Die können Frequenzbänder analysieren und genau bestimmen, auf welcher Frequenz ein Problem auftritt. Wenn sie Peaks sehen, wissen sie, ob es sich um ein inneres oder äußeres Kugellager handelt, ob es falsch oder einseitig geschmiert ist oder ob ein anderes Bauteil betroffen ist. Das sind echte Spezialisten vor Ort. Trotzdem bieten wir zusätzlich Software an, die diese Analysen unterstützen kann. Für viele Kunden reicht aber schon die einfache Ampellogik unseres Sensors – grün, gelb, rot. Wenn die Anzeige auf Rot springt, weiß man, dass man vor Ort nachsehen muss, was los ist.

[22:32] Übertragbarkeit, Skalierung und nächste Schritte – So könnt ihr diesen Use Case nutzen

Gibt es aus deinen Projekten Best Practices, bei denen du sagst, darauf sollte man unbedingt achten – sei es in der Umsetzung oder technisch? Gibt es etwas, wo Unternehmen heute unnötig Geld ausgeben, obwohl es einfacher ginge?

Martin

Einfach Geld ausgeben klingt immer gut, aber im Grunde ist Best Practice überall dort, wo sich etwas dreht und wo ein Ausfall Stillstand bedeutet oder teuer wird. Wenn eine Pumpe ausfällt und die Produktion steht oder ein Bauteil unbrauchbar wird, weil es nicht mehr richtig geformt wurde, dann kostet das enorm. Wer so einen Fall einmal erlebt hat, weiß, wie schnell sich Sensoren lohnen. Wenn ich einen einzigen solchen Ausfall verhindern kann, kann ich mir auch hundert Sensoren anschaffen.

Und die rechnen sich sofort. Also mehr Fokus auf die entscheidenden Use Cases, dort wo im Prozess wirklich Geld verloren geht. Dann rechnet sich so eine Lösung schnell.
Vielen Dank, Martin, für die spannenden Einblicke und dass wir in ein paar eurer Projekte reinschauen durften. Ich verlinke alles in den Show Notes, auch die Projekte, die wir bereits auf unserer Plattform vorgestellt haben. Und vielleicht zum Abschluss: Was dürfen wir künftig noch von euch erwarten? Sowohl projektseitig als auch bei Honeywell allgemein. Gibt es etwas Neues, das du schon verraten kannst?

Martin

Ich kann auf jeden Fall aus dem Nähkästchen plaudern. Man muss wissen, dass Honeywell diese Sensoren selbst entwickelt – teils in der Schweiz, teils in Indien. Wir bauen sie also komplett selbst und sind damit Hersteller. Dadurch sind unsere Sensoren auch wirklich industrietauglich. Sie haben alle Ex-Ausführungen weltweit, sämtliche Zulassungen und die Schutzklasse IP67. Unser Sensor für die Chemie ist NAMUR-geprüft, was in etwa einer TÜV-Zertifizierung entspricht. Große Chemieunternehmen haben Zugriff auf diese Prüfberichte und können genau sehen, wie gut unser Sensor getestet wurde und wie präzise er arbeitet.
Wir haben eine lange Roadmap mit neuen Entwicklungen. Schon jetzt gibt es einen fertigen Methansensor, der Methan misst. Das ist aktuell besonders interessant, weil die EU ein neues Emissionsgesetz zur Methanreduzierung eingeführt hat. Gasbetreiber müssen künftig ihre Lecks regelmäßig messen. Da die Gasverteilerstationen oft kilometerweit auseinanderliegen, ist LoRaWAN hier ideal. Wir können die Daten zuverlässig übertragen und sofort erkennen, wenn ein Leck entsteht.
Der nächste Sensor auf unserer Roadmap ist ein Inline-Drucksensor mit LoRaWAN-Anbindung. Ich habe ihn bereits im Testeinsatz. Er wird Ende dieses Jahres auf den Markt kommen und bis zu 375 bar messen können. Ein großes Chemiewerk plant, ihn zur Überwachung seiner Wasser-, Dampf- und Druckleitungen zu nutzen. Dort werden Ein- und Ausgänge im Betrieb, Temperatur und Druck gemessen. Druck und Temperatur zu erzeugen kostet viel Energie. Wenn man sie an bestimmten Punkten um ein paar Grad oder Bar reduzieren kann, spart man in der Produktion bereits erhebliche Kosten.

Wenn jetzt jemand zuhört und denkt, er hat ähnliche Anwendungsfälle – kann man einfach mit dir Kontakt aufnehmen, um sich dazu auszutauschen? Soll ich deinen Kontakt in den Show Notes verlinken?

Martin

Absolut. Mein Standardspruch am Ende jeder Präsentation lautet: Es gibt für alles eine Lösung – und die heißt Martin Kühne.

Perfekt. Martin Kühne findet ihr auf LinkedIn und in den Show Notes. Schaut gern mal rein. Vielen Dank, dass du heute dabei warst. Es war super, dass wir so konkrete Projekte und euer Angebot durchgehen konnten. Man versteht sehr gut, welchen Mehrwert ihr bietet und wie das Ganze bei den Kunden umgesetzt wird. Das letzte Wort geht an dich.

Martin

Vielen Dank, Madeleine. Es hat mir viel Spaß gemacht. Ich rede immer wieder gern über unsere LoRaWAN-Sensoren, weil man bei Kundengesprächen so viele neue Ideen bekommt. Da entstehen ständig neue Use Cases – vom Filterrüttler bis hin zu Anwendungen, an die vorher niemand gedacht hat. Sobald die Kunden verstehen, was unser Sensor kann, fallen ihnen sofort Einsatzmöglichkeiten ein. Dann geht es an die Umsetzung, an die Kontaktaufnahme mit mir – und los geht’s.

Und damit wünsche ich euch eine schöne Restwoche. Macht’s gut.

Martin

Ciao.

Ciao.

Questions? Contact Madeleine Mickeleit

Ing. Madeleine Mickeleit

Mrs. IoT✌️Gründerin der IIoT Use Case GmbH | IoT Business Development | Welche Use Cases funktionieren – und WIE? Fokus auf Praxis! #TechBusiness #Mehrwert