Zoom ins WAGO-Werk – Partner-Ökosystem ermöglicht prädiktive Wartung einer Materialverteilungsanlage

Hallo Jan und Jürgen! Wo erreiche ich euch gerade?

Jürgen

Mir geht es nach dem wunderschönen Herbstwochenende sehr gut und ich freue mich, wieder dabei zu sein.

Jan

Ich bin bei uns im Büro bei Päpinghausen bei Minden. Das ist nicht direkt im Headquarter, sondern nebenan. Nach der Light + Build Messe bin ich noch leicht erkältet, aber es wird schon besser.

Wie war die Light + Build bei euch? Ich habe das Ganze bei LinkedIn sehr verfolgt.

Jan

Die Messe war sehr gut. Wir hatten sehr spannende Gespräche und viele Besucher; trotz vierjähriger Pause.

Jürgen

Ich war nicht selbst da; bei uns war eine andere Unit vertreten. Ich kann von meinen Kollegen nur die Begeisterung wiedergeben.

Wir werden uns höchstwahrscheinlich auf der SPS 2023 in Nürnberg wieder sehen; vielleicht sieht man dort das ein oder andere bekannte Gesicht.

Jürgen, du warst bereits in Folge 51 bei uns. Damals mit Matthias Morath von der Firma »Liebherr«; deswegen könnte man dich fast schon als alten „Podcast-Hasen“ bezeichnen; danke für dein heutiges Update. Du bist Partner-Manager bei WAGO, was sind hier deine Aufgaben und was hat sich seit dem letzten Podcast bei dir geändert?

Jürgen

Ich bin schon viele Jahre bei WAGO für den Vertrieb der Automatisierungstechnik im industriellen Umfeld tätig. Seit 5 Jahren bin ich bei uns im Business Development tätig, und eine meiner Aufgaben ist das IoT und Partner-Management. Wir haben dieses Management, um überhaupt ganzheitliche Lösungen, oder auch End-to-End-Lösungen für unsere Kunden anbieten zu können. In diesem IoT-Umfeld ist es schwer, als einzelne Firma ein Komplettpaket anzubieten. Die einen haben die Expertise bei dem Schaltschrank, die anderen haben die Expertise in der Cloud und die nächsten in einem Zusammenführen dieser Expertisen. Daher haben wir das WAGO-IoT-Partnernetzwerk.

Seitdem wir uns das letzte Mal gesprochen haben, hat sich dieses Netzwerk sehr stark entwickelt. Auch viele Anwendungen und Features, die wir damals besprachen, haben sich weiterentwickelt.

Jan, was ist deine Rolle bei WAGO?

Jan

Ich bin bei WAGO als Produkt- und Projektmanager für den Bereich Analytics in der Business Unit »Solution« tätig. Die Business Unit »Solution« realisiert Lösungen, wie man so schön sagt, vom Sensor, bis in die Cloud. Das heißt, über unser I/O-System können die Daten angebunden werden, lokal auf leistungsfähigen Edge-Geräten, aber auch in der Cloud verarbeitet werden. Dort können die Daten dann dem Kunden einen Mehrwert bieten.

Im Bereich Analytics geht es immer darum, aus den Daten noch mehr herauszuholen. Das kann mit Visualisierung anfangen und mit künstlicher Intelligenz weitergehen. Das machen wir branchenübergreifend für die Bereiche »Industrie«, aber auch »Gebäude« und »Utilities«.

WAGO ist im IoT-Segment bekannt für Verbindungs- und Automatisierungstechnik; jetzt auch im Bereich IoT und Cloud. Jürgen, wie sieht eure Technik bei der IoT aus und was bietet ihr hier an?

Jürgen

Seitdem wir Ende der 90er Jahre mit der Automatisierungstechnik gestartet sind – Remote I/Os, Steuerung, etc –, haben wir uns konsequent in Richtung IoT hinentwickelt. Wir haben in den frühen 2000er Jahren entsprechende Steuerungen mit einem Linux-Betriebssystem gestartet. Dieses hat sich durch die verschiedenen Patches und Add-Ons dahin entwickelt und die Möglichkeit gegeben, perfekte Kommunikation zu On-Premise-IT-Systemen zu realisieren, und natürlich auch in die Cloud.

Was hier nicht fehlen darf, ist das Thema Security. Gerade mit dem Linux-Betriebssystem unserer verschiedenen Steuerungsvarianten, können wir das Thema IoT sehr gut realisieren.

Mit wem sprecht ihr beim Kunden typischerweise?

Jürgen

Wir hatten hier einen Wandel. Während wir vorher bei den Projekten rein die Automatisierungstechnik betrafen, mit den Steuerungstechnikern in Kontakt waren, so ist es heute, dass wir zunehmend mit der IT in Kontakt stehen. Auch mit der Produktions-IT, die dann die Netze, die von der Office-IT getrennt sind, mitunter verantworten. So sind wir vom Schaltschrank bis zur IT mit den unterschiedlichen Menschen und Ansprechpartnern im Kontakt. Wir müssen somit auch die unterschiedlichsten Expertisen dahingehend zusammenführen, sodass ein rundes Digitalisierungsprojekt entsteht.

Jan, sprecht ihr auch mit neuen Ansprechpartnern?

Jan

So ein Thema ist eher auf Leitungsebene verankert. Wir haben viel mit der Produktionsleitung zu tun, aber natürlich müssen wir das dennoch im Team behandeln. Wenn vom Management ganz am Anfang zunächst der Use Case geklärt ist und sich das Team darauf commited hat, muss dieses Team eng zusammenarbeiten. Deswegen sind wir hier weiterhin stark im Austausch mit den zuständigen Automatisierungsingenieuren, aber auch den Prozessexperten, um den Prozess weiter zu verbessern.

Man kennt das aus dem IoT-Segment, dass man interdisziplinär in den Teams arbeitet und das Wissen innerhalb der Firma nutzt.

Neben der internen Expertise arbeitet ihr auch mit externen Partnern zusammen, die auch »on-boarded« sind. Wer sind klassische IoT-Partner von euch?

Jürgen

Ja, wir sind offen für neue Partner und das Partnernetzwerk ist sehr heterogen; das ist uns wichtig. Hier haben wir Firmen wie »Actemium«, die ein großes Stack bedienen. Firmen, die eine hohe Security-Expertise haben, zum Beispiel »Rhebo«, die Netzwerkanomalien erkennen können. Oder auch neue Technologien, die bis in die Steuerung gehen, um nicht nur das Thema »Security« abzudecken, sondern auch die Daten über eine Blockchain verifizier- und nachvollziehbar zu halten: Hier haben wir den Partner »UBIRCH«

Die Firma »Rhebo« ist frisch bei uns ins Netzwerk gekommen – Sie gehören zur Landis+Gyr Gruppe, soweit ich weiß – und sind sehr im Bereich Security für Energieverteileranlagen tätig. Schön wie sich euer Partnernetzwerk entwickelt hat!

Welche Use Cases bedient ihr am Markt?

Jürgen

Wir sind in unterschiedlichsten Branchen aktiv; eine davon ist die Gebäudeautomatisierung oder das Marketbuilding im Energiebereich. Gerade was das Stabilisieren der Netze betrifft und die Bereiche Produktion und Vernetzung von Maschinen.

Überall haben wir die unterschiedlichsten Projekte realisiert. Ich gehe zunächst auf ein Shopfloor-Projekt ein, was wir vor acht Wochen gemeinsam auf der Achema präsentiert haben:

Die Firma Actemium und WAGO; hier wurde unser CC100 – eine Kompaktsteuerung von WAGO – vorgestellt, welches auf Linux basiert. Vorhandene Maschinen, sprich Brownfield, wurden vernetzt und digitalisiert und dann entsprechende Anwendungen und Applikationen über die Linux-Technologie über Docker auf die Geräte verteilt, um von der Energietechnik bis hin zu MES-Funktionalitäten zu realisieren. Das alles, um die Arbeitsschritte transparenter zu gestalten.

Habt ihr noch andere Use Cases?

Jürgen

Auf unserer Website findet man eine sehr große Luftzerlegeranlage von Linde, als Referenz, wo dann die WAGO-Hardware die Konnektivität in die Cloud bringt, den Luftverleger monitort, für eine längere Lebensdauer sorgt und auch zur Energieoptimierung beiträgt.

Wer dazu was mehr lesen möchte, findet in den Shownotes weitere Informationen.

Jan, welche Use Cases bedient ihr im Bereich »Analytics«?

Jan

Ein Use Case, den ich heute mitgebracht habe, ist aus unserer eigenen Produktion: Dabei ging es darum, eine Materialverteilungsanlage zu optimieren, die dafür zuständig ist, das Kunststoffgranulat zu den einzelnen Spritzgussmaschinen zu befördern. Auf der anderen Seite haben wir auch viele Kunden im Bereich Maschinenbau, oder auch Use Cases im Gebäude, wo es darum geht, die Vorlauftemperatur zu optimieren, damit man die Heizung möglichst energieeffizient betreibt.

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

Wenn ich mir vorstelle, dass wir bei euch im Werk sind, was genau für Prozesse sind dort? Kannst du das mit den Spritzgussmaschinen genauer erklären?

Jan

Wie man sich vorstellen kann, hat WAGO eine Menge an Spritzgussmaschinen, die Kunststoffteile in unterschiedlichen Farben und Formen fertigt. Dafür wird das Kunststoffgranulat zu den einzelnen Maschinen befördert, wo in einer Materialverteilungsanlage unterschiedlichste Aufträge anlaufen. Diese Maschine wurde zum großen Teil von WAGO selbst mitentwickelt. Die Aufträge sind einfach, welches Granulat, in welcher exakten Ausführung, bei welcher Maschine ankommen muss. Da das zum großen Teil eine Selbstentwicklung war, war der Ehrgeiz der zuständigen Ingenieure hoch, diese Anlage noch weiter zu verbessern.

Was waren hier die Herausforderungen? Zum einen die Wartung eines Filters prädiktiv zu gestalten. Die andere Herausforderung war, Fehlerzustände bei dieser Maschine zu erkennen, bevor sie Probleme im Prozess verursachen, die dann bei der Qualitätskontrolle sichtbar werden.

Was produziert ihr dort genau?

Jan

Das sind die typischen Teile, die man von WAGO kennt. Das kann der Hebel einer Klemme sein oder auch das Gehäuse. Ich weiß nicht welches genaue Teil dahinter produziert wurde; es sind auf jeden Fall Bestandteile unserer Standardpalette.

Wenn ich an eure Produktionsverantwortlichen denke, was sind hier klassische Herausforderungen im Alltag in den einzelnen Use Cases?

Jan

Besondere Herausforderung sind die großen Themen wie KI und Predictive Maintenance. Hier stehen die Verantwortlichen davor und besprechen, jetzt das Thema in der eigenen Produktion zu verankern. Gleichzeitig besteht die Aufgabe die Mitarbeiter der zuständigen Stelle mitzunehmen, und es in den gewohnten Arbeitsablauf zu integrieren. Das haben wir bei diesem Projekt geschafft.

Ihr habt verschiedene Produktionsverantwortliche bei euch, welche unterschiedliche Herausforderungen haben. Was sind nun aber die Herausforderungen der einzelnen Aufträge?

Jan

Vor allem die Effektivität der Anlagen zu erhöhen. Gleichzeitig möchte man, beziehungsweise muss man, sich neuer Technologien bedienen, die Teil einer prädiktiven Wartung sind. Das Ganze muss sich in den Arbeitsalltag der zuständigen Mitarbeiter integrieren können. Wenn man eine prädiktive Reinigung eines Filters in den Arbeitsablauf integrieren möchte, gehört es auch dazu, an das bestehende Wartungsmanagement anzuknöpfen und zu implementieren.

Auch den Mitarbeitern einen konkreten Mehrwert aufzuzeigen, sodass die Lösung mit Freude entgegengenommen werden kann, ist wichtiger und weiterer Bestandteil.

Was sind Arten von Fehlern die typischerweise auftreten und was sind Probleme bei der Filterreinigung?

Jan

Ich fange bei der Filterreinigung an: Die Materialverteilungsanlage transportiert das Kunststoff zu den einzelnen Spritzgussmaschinen. Über eine Drehrohrweiche wird entschieden, zu welcher Spritzgussmaschine das jeweilige Kunststoffgranulat befördert werden soll. Wenn man sich das vorstellt ist das im Prinzip wie ein großer Staubsauger.

Jeder Staubsauger hat einen Filter und dieser muss nach einiger Zeit gereinigt werden, da in diesem Kunststoffgranulat Staubpartikel und anderes Zeug enthalten sind. Nun hängt dieses Wartungsintervall – die Verschmutzung des Filters – stark davon ab, wie die einzelne Charge befördert wurde. So war es schwer, den optimalen Zeitpunkt für diese Filterreinigung zu terminieren.

Wenn die Wartung zu früh gemacht wurde, hat der Mitarbeiter eine Tätigkeit verrichtet, welche nicht als glorreich betrachtet wird –möglicherweise hat er die Zeit unnötig investiert. Wenn die Wartung zu spät gemacht wurde, ging die Effektivität der Anlage nach unten, und dementsprechend könnte auch die Fehleranfälligkeit zunehmen.

Unser Ziel haben wir erreicht, indem wir eine Differenzdruckmessung an diesem Filter ausgenutzt haben. Anhand diesen Sensorwertes sind wir sehr gut in der Lage, herauszufinden, wann der optimale Zeitpunkt erreicht ist. Dieses System haben wir auf einem Edge-Computer von WAGO implementiert, da es ein rechenintensiver Vorgang ist. Im Anschluss haben wir über den Edge-Computer die Anbindung an unser SAP-System eingerichtet, welches für das Wartungsmanagement verantwortlich ist.

Man hat praktisch eine Filterreinigung, die eine Menge Zeit und Geld kostet, weil Wartungen nicht optimal geführt werden, wo man noch Effizienzen herausholen kann. Welcher Herkunft sind die Fehler?

Jan

Diese Fehler haben sich auf zwei Hauptquellen beschränkt. Bei den Spritzgussmaschinen gibt es Klappen, wo das Kunststoffgranulat von der Luft getrennt wird. Es ist an der Stelle immer wieder passiert, dass nach Wartungen die Klappen nicht richtig verschlossen wurden. Das war ein mechanisches Problem, welches bisher von keiner Sensorik diktiert wurde. Ein zweites Problem war ein Ventil, das nicht zum passenden Zeitpunkt geschlossen hat.

In beiden Fällen ist ein ähnliches Verhalten aufgetreten: Luft ist in das System gelangt und der Leersaugvorgang konnte nicht so effektiv abgeschlossen werden, wie es nötig gewesen wäre. Das heißt, im schlimmsten Fall war Kunststoffgranulat in den Rohren verblieben, und beim nächsten Fördergang ist dieses Kunststoffgranulat in der falschen Farbe bei der Spritzgussmaschine angekommen.

Das wäre der Worst Case, denn dann kommt am Ende ein falsches Produkt heraus, welches wieder zum Ausschuss kommt.

Jan

Vollkommen richtig! Im schlimmsten Fall wird dieses Problem bei der Qualitätskontrolle bemerkt und „Schrott“ produziert. Für uns war es möglich, die vorhandene Messtechnik auszunutzen und die Druckverläufe so zu analysieren und zu erkennen, dass eine Klappe nicht richtig geschlossen wurde oder das Ventil zum falschen Zeitpunkt schließt. Dann merkt man sofort, wenn das Problem auftritt, DASS es auftritt, und kann im Folgenden darauf reagieren.

Welche Arten von Daten sind hier für euch in dem Case besonders spannend?

Jan

Dieser Druck, der über den Filter abfällt, lässt sich messen, indem man ihn vor und hinter dem Filter misst – praktisch die Differenz. Darüber kann man sehr gut die Verschmutzung des Filters messen und dementsprechend vorhersagen, wann der Filter zu wie viel Prozent verschmutzt ist. Diese Messgröße war ebenfalls für die Erkennung der zu spät schaltenden Ventile und der offenen Klappen hilfreich. Außerdem war die Volumenstrommessung interessant, die hier verbaut wurde, welche wir ebenfalls ausnutzen konnten.

Die Differenzdruckwerte und Volumenstromwerte werden aus den einzelnen verbauten SPS-Systemen kommen. Was sind eure Anforderungen an das Projekt gewesen?

Jan

Die erste Herausforderung war, herauszufinden, welche Daten überhaupt relevant sind. Das haben wir sehr gut mit einem Experten für diese Anlagen geklärt. Dann haben wir identifiziert, ob diese Daten in der Anlage vorliegen, und haben sie herausgeholt.

Des Weiteren war die Anforderung von den Mitarbeitern, dass sich das Ganze in die bestehende Lösung integriert. Das heißt, wir können nicht einfach nur einen Algorithmus liefern, welcher schlichtweg erkennt, wann der Filter gereinigt werden muss, ohne die Informationen an den Mitarbeiter herauszurücken.

Hier ist es wichtig, eine Anknüpfung an das bestehende Wartungsmanagement zu schaffen. Zum einen muss der Algorithmus sich melden, wann die nächste Wartung dran ist und den zyklischen Vorgang ersetzen. Und auf der anderen Seite ist es wichtig, wenn eine Wartung abgeschlossen ist, dass das vom Algorithmus wahrgenommen werden kann und dieser sich automatisch resettet. Diese Konnektivität zu allen Systemen ist hier sehr wichtig.

Das Gute bei euch ist, dass es All-in-One-gelöst ist. Ihr habt es selber geschaffen UND habt das nötige Partner-Ökosystem, um dieses Projekt umzusetzen.

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

Ich würde gerne wissen, wie eure gemeinsame Lösung aussieht. Im ersten Schritt: Wie funktioniert bei euch die Datenaufnahme?

Jan

Das Wichtigste an der Stelle ist, dass die Anlage durch eine WAGO-Hardware gesteuert wurde. Deshalb war es, verglichen zu anderen Produkten, welche nicht aus eigener Produktion stammen, sehr einfach an die Daten zu kommen. Wir haben hier die Möglichkeit ausgenutzt, einzelne Datenpunkte aus unserer SPS über OPC UA freizugeben. Dann haben wir auf unserem Edge-Computer, welcher für die Datenauswertung und die weitere Konnektivität genutzt wurde, einen OPC UA Client installiert.

Dieser hat die Daten zum einen in Empfang genommen, einmal in einer Datenbank gespeichert, worauf später über ein Dashboard zugegriffen werden konnte. Auf der anderen Seite hat der Client die Daten an unterschiedliche Algorithmen weitergeleitet, die den prädiktiven Wartungszeitpunkt errechnet haben, aber auch für die Mustererkennung der Fehler zuständig waren und diese Informationen wieder zurückgeschickt haben.

Darüber hinaus gab es eine Konnektivität nach oben an das Wartungsmanagement. Diese funktionierte wieder über OPC UA, wo wir die SAP Plant Connectivity ausgenutzt haben, aber natürlich auch in die Steuerung eingegriffen und Informationen zurückgesendet haben, wenn Fehler erkannt wurden. Dann konnte eine Warnung an den Bediener weitergeleitet werden, sodass dieser genauer nach dem Problem schauen konnte.

Wie fertigt ihr die Datenverarbeitung ab? Übernimmt das ein Partner für euch?

Jan

Die Datenverarbeitung übernehmen wir selber, weil wir gemerkt haben, dass die größte Herausforderung ist, das Problem auf den Punkt zu bringen und daraufhin den geeigneten Algorithmus auszuwählen. Die KI mit dem Algorithmus ist nicht schwer zu realisieren. Schwieriger ist es, das Problem auf den Punkt zu bringen, und zu wissen, wie man dieses Problem lösen kann.

Da wir in engem Austausch mit den Kunden sind, steht dieses genaue Beziffern des Problems an oberster Stelle und kann von keinem Partner abgenommen werden. Machine-Learning-Angebote gibt es in der heutigen Open-Source-Welt zur Genüge, sodass man sehr gute Algorithmen frei zur Verfügung hat.

Jürgen

Ich glaube, dass das ein ganz wesentlicher Punkt beider IoT-Projekte ist; denn die Technik ist einfach zu realisieren. Natürlich hängt das von der Expertise ab. Aber es ist ungeheuer wichtig, dass diese unterschiedlichen Experten zusammenarbeiten. Einmal bei der Datenerfassung. Vor allem wichtig ist jedoch derjenige, der den Prozess sehr gut kennt, sodass man in einem Team arbeitet; dann wird die Technik zum Selbstläufer.

Hinzu kommt, dass jeder Kunde andere Anforderungen und Ausprägungen hat. Hier kommt wieder das Partner-Ökosystem zustande: Wenn ein Kunde andere Ausprägungen hat, bedient ihr euch an einem Pool an Expertisen von Partnern, die das Ganze mit Wissen füttern können, oder?

Jürgen

In unterschiedlichsten Bereichen! Was Jan gerade schon skizziert hat, war, dass der Instandhalter über ein SAP-System die Informationen bekommt. Wir sind keine SAP-Experten; von daher macht es nur Sinn, sich der Expertisen aus dem Ökosystem zu bedienen.

Das ist der Punkt, der die Arbeit für alle vereinfacht. Als Closed-Loop-IoT-Anwendung, wenn man hinterher den Instandhaltungsauftrag auf einem mobilen Gerät erhält, ihn ausführt und möglicherweise quittieren kann. Dann ist das ein Use Case, der sich nicht nur finanziell auswirkt, sondern in Gänze den Prozess verbessert.

Jan, wie funktioniert denn die Anbindung in SAP und daran angeschlossen die Datenanalyse?

Jan

Wir haben hier stark mit unserer eigenen Produktions-IT zusammengearbeitet. An der Stelle ein großes Danke an die Abteilung.

Was die Kollegen hier genutzt haben war die SAP Plan Connectivity, die die Möglichkeit bietet, einen OPC-UA-Server bereitzustellen. So ist man nah an der OT-Welt dran. Wir konnten hier ohne Probleme die entsprechende Information bereitstellen in Richtung SAP, wo die Information weitergeleitet und in das entsprechende Wartungssystem eingearbeitet werden konnte. Gleichzeitig konnten wir darüber in Empfang nehmen, wann der Wartungsauftrag quittiert wurde, sodass wir diese Information zurück an den Algorithmus zurückspielen konnten.

Wie funktioniert die Datenanalyse?

Jan

Auch bei der Filterreinigung, in allen Fällen war die Architektur gleich. Auf dieses Problem bezogen haben wir einen Algorithmus entwickelt. Dieser wurde zunächst in Offline-Analysen anhand dieser Daten evaluiert, weiterentwickelt und zur Perfektion gebracht. Danach wird er bei uns in einen Baukasten integriert, der diese Streaming-Daten in Empfang nehmen und verarbeiten kann und die Analyseergebnisse als Datenstream zurückgibt. Das ist ein Prozess, der in fast jedem Projekt wiederkehrend ist.

Das heißt, ihr habt am Ende eine schöne Lösung für euch, wo ihr auf einem Dashboard diese Probleme gelöst habt. Die Königsdisziplin wäre dann, das auf eine Charge zurückführen zu können. Das ist euer Business Case, wo ihr in eurer Produktion bares Geld sparen könnt; praktisch ein Investment.

Hier am Beispiel der Materialverfolgung, kann man das exemplarisch sehr gut nachvollziehen, da man ansonsten selten einen wirklichen Einblick in solche Dinge bekommt.

Ergebnisse, Geschäftsmodelle und Best Practices – So wird der Erfolg gemessen [34:08]

Was ist der Business Case im konkreten Fall? Habt ihr eine Art Return-on-Invest-Rechnung oder etwas in die Richtung?

Jan

Einen wichtigen Punkt hast du bereits angesprochen; es fing alles mit einem Dashboard an. Die Fehler, die bisher aufgetreten sind, die haben die Leute nie erfasst. Es war so, dass die Daten geloggt wurden, aber in CSV-Dateien, und dann mühselig mit Excel analysiert wurden. Hier haben wir in einer Zeit von mehreren Stunden ein Dashboard entwickelt, welches dann den manuellen Vorgang deutlich vereinfacht hat.

Wir haben keine direkte Return-on-Invest-Rechnung aufgemacht. Jedoch wenn man sich diesen vorher beschriebenen Prozess mit Excel vor Augen führt, erkennt man recht schnell, wie viel Zeit das in Anspruch nehmen würde.

Wenn es weitergeht mit der prädiktiven Filterwarnung, dann ist es so, dass wir noch nicht mal die Anzahl der Wartungsvorgänge reduziert haben. Wir haben Wartungsvorgänge einfach zum richtigen Zeitpunkt; das reicht aus, um einen Mehrwert zu erhalten. Die Anlage läuft effizienter. Gleichzeitig haben wir den Arbeitsaufwand nicht erhöht oder verringert, sondern ein besseres System geschaffen.

Hier ist es für die zuständigen Mitarbeiter sehr schwer gewesen, auszurechnen, was der Return on Invest war, da noch andere Maßnahmen getroffen wurden, die nicht mehr rein datengetrieben waren, um die Anlage weiter zu optimieren. Wir haben hier keine Zahl; in jedem Fall war jedoch ein großer Mehrwert für den Gesamtprozess gefunden.

Eine solche Return-on-Invest-Rechnung ist allgemein nicht einfach. Man hat harte Faktoren, auch softe Faktoren, und unter Umständen betrachtet man das Ganze von einer Businessperspektive aus, sodass eine präzise Aussage nur schwer zu treffen ist.

Euch geht es bei WAGO darum, mit Kunden verschiedene Projekte umzusetzen. Über euer Ökosystem habt ihr den Fokus, den Business Impact für euren Kunden nach vorne zu stellen.

Jürgen

Der muss absolut da sein! Nur dann macht die Digitalisierung in diesem Umfeld Sinn. Wenn wir das Wort »Dashboard« hören – hier geht es in vielen Fällen nicht darum, etwas anzuzeigen. Sondern das sind Hilfsmittel, um neue Parameter einzustellen und das System zu optimieren. Der Business Case kommt dann, wenn es eine Closed-Loop-Anwendung gibt.

Ich habe noch ein aktuelles Beispiel für den Return on Invest. Diesen Use Case, über den wir uns heute unterhalten, habe ich letzte Woche noch mit einem Kunden besprochen; er hatte dasselbe Bedürfnis. Wenn ich an die anfangs angesprochenen Verschmutzungsgrade zurückdenke … das kennt der externe Kunde selbst nur zu gut. Wenn man ein zyklisches Reinigungsintervall des Filters hat, dann ist der Filter mal stärker und mal weniger verschmutzt.

Solche Unterschiede – hier vergesse unter anderem ich, aber auch viele andere, »staubzusaugen«, und plötzlich ist der Filter beim nächsten Mal stärker verschmutzt, als er eigentlich sein sollte. Das wirkt sich letztendlich immer auf die Produktionsqualität aus. Durch Digitalisierung des Projektes fallen solche Punkte weg und man reinigt optimiert den Filter.

Das war ein gutes Beispiel für einen Use Case mit konkretem Business Impact, bei dem man weiß, wenn es nicht gereinigt wird, dann entsteht Ausschuss und Geld wird verschwendet, welches man einfach einsparen könnte. Solche Sachen kommen sehr häufig vor; Stichwort: Skalierbarkeit. Entwickelt ihr gerade etwas in diese Richtung?

Jan

Oft ist es so, dass die Probleme zunächst skalierbar scheinen, und plötzlich stellt man fest, dass sehr viele das gleiche Problem haben. Ab diesem Zeitpunkt kann man sich die Gedanken machen, sofern es vertraglich möglich ist, das Ganze als Produkt anzubieten. Ein Beispiel wäre eine PV-Ertragsprognose, wo es darum geht, den Ertrag von Photovoltaikanlagen zu prognostizieren. Das ist Teil unserer Cloud; es kann von jedem unserer Kunden genutzt werden.

Eine weitere, sehr skalierbare Lösung ist, wo es darum ging, die Vorlauftemperaturen von Heizungsanlagen zu optimieren. Auch das ist eine Lösung, die wir in die Breite tragen.

Jürgen, worauf dürfen wir in Zukunft aus deinem Bereich gespannt sein?

Jürgen

Vorweg noch zum Thema Skalierbarkeit: Es gibt tausende Spritzgussmaschinen in Deutschland. Alle haben eine längere oder auch kürzere Materialflussanlage. Allein dieser Bedarf lässt sich skalieren; überall wo Kunststoffgranulat zu finden ist.

Wir ergänzen das durch die unterschiedlichsten Expertisen aus dem IoT-Partnernetzwerk. Sei es SAP, entsprechende Analytics-Möglichkeiten, aber auch die Verifikation; ich hatte die Blockchain kurz angesprochen. Auch das ist ein Mittel, um Produktstatiken, um Qualitätssicherung und Weiteres nachvollziehbar zu verifizieren; in der gesamten Lieferkette!

So lassen sich die unterschiedlichsten Expertisen im WAGO-IoT-Partnernetzwerk nutzen und zu einer individuelle Gesamtlösung zusammenführen.

Ein sehr schönes Schlusswort zu dem Thema! Man erkennt sehr schön den Trend von der klassischen Automatisierung hin zu IoT, Cloud und Ökosystemen.

Vielen Dank für die tiefen Einblicke in das Produktionsgeschehen, das ist nicht selbstverständlich! Wer näher mit euch Kontakt aufnehmen möchte, kann in den Shownotes den Links folgen.<

Vielen Dank und bis zum nächsten Mal!