 Herzlich willkommen in Blauen Salon. Wir begrüßen euch recht herzlich zu einem Talk von Mephisto, der heute darüber sprechen wird, wie Time Series Daten eine klassische Industrie verändern werden. Denn das Motto der diesjährigen GPN Cheap Alternatives regt dazu an, darüber nachzudenken, wie wir unseren Ressourcenverbrauch minimieren können und wie wir mit bekannten Technologien und dem, was wir haben, unseren CO2-Fußabdruck verringern können. Mephisto arbeitet schon seit 23 Jahren selbstständig in dem Bereich IT und will uns heute was zu Time Series Daten banken und einer klassischen Industrie an Beispiel einer Druckerei erklären. Mit einem herzlichen Applaus begrüßt bitte Mephisto. Hallo, schön, dass ihr da seid. Ich freue mich heute, ich freue mich heute mit euch ein bisschen was über ein Projekt, was mich seit einiger Zeit begleitet, teilen zu können. Es geht um ein Industrieprojekt, welches ich seit seit einigen Jahren betreue und würde vorab ein paar Worte zu mir sagen. Die meisten kennen mich entweder als Mephisto oder aus Bastian oder als Bastian. Mein Heimexface ist die binary-Kittchen in Regensburg, außerdem bin ich noch beim Freifunk irgendwie aktiv und treibt da so bei meinen Unwesen und bin wie die Leer schon gesagt, hat frei beruhige IT-Konsulten seit 23 Jahren. Meist im Security oder im IoT-Umfeld unterwegs, manchmal auch zusammen, das fällt manchmal auch in das gleiche Thema rein. Ansonsten hecke ich ganz gerne rum, tinker mit allen möglichen Dingen und bin leidenschaftlicher Gamer oder lebe mich kreativ gerne mit elektronischer Musik aus. Zum aktuellen Projekt, über das ich gerne berichten würde, was ein guter Showcase ist, wie man traditionelle IT-Monitoring-Toolchains in einem eigentlich nicht dafür gedachten Umfeld einsetzen kann. Es handelt sich um ein Medienunternehmen aus der Region. Dieses Medienunternehmen betreibt unter anderem eine Druckerei, also so richtig mit Papier und so. Und was ist für mich darin interessant? Es ist eine interdisziplinäre Arbeit, man hat mit Maschinenbauern zu tun, mit Elektrikern, man hat mit Klimatechnikern zu tun, Druckluftechnik, Chemie. Es ist halt viel fachfremdendes Wissen, was ich mir irgendwie auf dem Weg aneignen musste und das ist tatsächlich eine schöne Abwechslung zum ansonsten recht einheitlichen IT-Alltag und mir gefällt das. Deswegen hatte ich da Bock drauf und habe das irgendwie vorwärts getrieben und bin halt bis heute da dran. Beim Kunden der Maschinenpark, ich würde ein paar Wochen dazu sagen, ohne zu sehr in die Tiefe zu gehen, das ist halt mehr oder weniger Branchenstandard. Das, was im Moment stand, 2012 ist die Rumpfanlage geliefert worden, aber bis heute eigentlich so als State of the Art in der Branche gilt, sowohl von der Technik, also von der Mechanik, als auch vom Vernetzungsgrad. Diese Symptome, auf die ich später noch eingehe, sind halt, in dem Falle haben wir es halt mit der Druckbranche zu tun, aber sie hat auch mit vielen, oder wir haben dieses Problem in vielen anderen Industrien, sodass es im Grunde so ein bisschen exemplarisch ist. Noch ein kurzer Disclaimer zum Talk. Das Cover von diesem IoT-Projekt nicht alle Aspekte, sondern pickt sich so ein bisschen alles, was mit Energie, Nachhaltigkeit und Umwelt zu tun hat, raus und was wir dort im Himmel auf Energieeinsparung und Verbesserung der Umweltbilanz tun konnten. Also deswegen, das Projekt ist eigentlich noch viel, viel, viel mehr, aber wir gehen jetzt erst mal auf die energierelevanten Dinge ein. Zum Thema Rollen-Offset. Rollen-Offset ist ein Druckverfahren und ich würde da ein kleines bisschen Kontext zu liefern, das wir im weiteren Verlauf wissen, wovon wir reden. Die Anlagen, um die es dort geht, das sind drei Offset-Rotationsmaschinen. Das ist so das größte derzeit verfügbare Format, was man so betreibt in der Branche. Das hat ungefähr drei Meter Bahnbreite, eine so eine Papierrolle wie Teil 7,5 Tonnen. Also viel größer geht es nicht, weil die Infrastruktur, also was ein Lkw so anliefern kann, da ist halt quasi Ende von dem, was man irgendwie wirtschaftlich darstellen kann. Output einer einzelnen Produktionslinie liegt so bei 5 Millionen A4 Seiten pro Stunde umgerechnet, so ein bisschen abhängig von der Drucklegung. Die Produktionsanlage selber von den Abmessungen her, um so eine Idee zu bekommen, wie groß das Ganze ist, sind 150 Meter in der Länge, 35 Meter in der Breite und in diesem Bereich oder in dieser Fläche sind eine ganze Menge Unteraggregate untergebracht. Was das auch ein bisschen komplizierter macht. Wir haben halt meinen Rollenwechsel, also von vorne nach hinten, Druckwerk, trockener, rückbefeuchte Roterschneider, Falzapparat, Rückenheftung, Transportbänder, Kreuzleger, umreifer, Palettierer, Folierer. Tatsächlich gibt es noch eine ganze Menge mehr, aber das sind jetzt sage ich mal die Oberkategorien. Muss man im Grunde nicht kennen, ich muss es halt trotzdem mal erwähnen, damit man so eine Idee bekommt, wie vielfältig das Ganze ist. Sekundär hat man halt in der Peripherie noch eine Menge Versorgungsaggregate und Systeme und Infrastruktur wie Drucklufterzeugung, Fluidmanagement, Kühltechnik, Kühlturme, alles irgendwie Dinge, die viel Energie verbrauchen und an denen es eine ganze Menge Stellschrauben sind, an denen man arbeiten kann, wenn man es denn sieht. Wenn man so eine Anlage bestellt bei einem Hersteller, in dem Fall ist der Hersteller MAN, bzw. MAN Roland, das ist die Drucktochter von MAN, dann bekommt man erst mal eine Rumpfanlage geliefert und das wird dann schon sehr auf den Kunden zu Recht konfiguriert und MAN Roland als Generalunternehmen auch holt dann eine ganze Menge anderer Lieferanten mit an Bord, die jetzt Klimatechnik und so weiter quasi mit liefern. Also man kriegt das Ganze nicht schlüsselfertig als ein diskretes Objekt dahingestellt, was perfekt vernetzt ist, sondern das ist eine sehr zerklüftete Geschichte, um das sozusagen noch ganz kurz, damit wir ein paar visuelle Eindrücke haben, um uns eine Idee zu machen, von was wir in der Fabrik wieder reden, habe ich jetzt einfach mal zwei drei Bilder davon reingepackt, also da sieht man im Grunde die drei Produktionsstraßen, die sind halt quasi jeweils eine dieser Segmenten der Halle entspricht einer Produktionsstraße, das ist das Ganze von hinten, Rollenwechseler, Falzturm, Nachverarbeitung, ja ist halt im Grunde Industry of Big Things, wenn man so will, was wir da treiben. Man ist auf jeden Fall anfangs oder was heißt anfangs zu Projektbeginn, Ende 2017, Anfang 2018, zu mir gekommen und im Zuge der Firmerweiterung bzw. Produktionskapazitätserweiterung sind halt einige Wünsche von der Geschäftsleitung und der technischen Leitung vorgetragen worden. Grundsätzlich ist die Reporting-Situation mit einer wachsenden Maschinenanzahl zunehmend schwierig geworden. Man hat halt nicht ein zentrales System, aus dem man alle Daten rausbekommt, sondern man hat natürlich die Rumpfanlage, die hat ein ganz okayes Reporting, die sagt einem okay, was halt irgendwie gedruckt wurde, wie so grob die Qualität war. Von ein paar Verbrauchsstoffen kann sie einem auch die Konsumtion, also den Verbrauch letzten Endes sagen, aber so ein richtig scharfes Bild ist auch da nicht rausgekommen. Alle Systeme, die irgendwie im Umfeld dessen agieren, die halt mehr als die Hälfte der Energie verbrauchen, die laufen halt quasi unterm Radar, die sind nicht vernünftig auswertbar. Das ist halt sehr, sehr unterschiedlich. Manche schmeißen halt irgendwie am Jobende ein PDF oder so raus. Es gibt Webfrontends mit einem Flash-Plug in, um irgendwie Statistiken rauszulassen. Manchmal gibt es eine CSV-Datei. Also das ist im Grunde unmöglich, das regelmäßig auszuwerten. Also die technische Leitung hat halt lange Zeit, also 15 Jahre lang mit dem, ich würde es nennen, dem Accelsheet From Hell gearbeitet, um so ein bisschen Licht ins Dunkel zu bringen, hat so einmal im Halbjahr so eine Grobauswertung gemacht. Einmal im Halbjahr reicht halt nicht. Wenn was im Job schiefgeht, ich will das wissen, wenn es passiert und nicht irgendwie im halben Jahr später, dann weiß ich okay, da war was scheiße, aber das bringt mir nichts mehr, weil ich nicht mehr agieren kann. Also Accelsheet From Hell ist im Grunde keine vernünftige Controlling-Möglichkeit. Zudem ist der Energieverbrauch immer weiter ausgeufert, also nicht nur im Zuge der Kapazitätserweitung, das ist klar, dass es dann mehr wird, aber auch die eingesetzte Energie pro produzierter Einheit ist irgendwie ein bisschen aus dem Ruder gelaufen. Dort wollte man im Grunde auch einen etwas schärferen Blick haben und ist dann im Grunde auf uns zugekommen und hat halt gefragt, warum wir nicht für die gesamte Produktion und für alle Gewerke, die dort eine Rolle spielen, so nette bunte Dashboards bauen können, die wir im Grunde in der IT seit keine Ahnung, 20 Jahren haben und gut, dann haben wir uns immer mal zusammengesetzt und ein paar Dinge getan. Wir haben uns die Ausgangssituation erst mal angeschaut über ein Dutzend Super-Aggregate, ein hohes Maß an Heterogenität. Bei den Lieferanten, die halt irgendwelche, sei es Kühltechnik, sei es Fördertechnik zur Verfügung stellen, herrschen halt die unterschiedlichsten IT-Philosophien. Es gibt dann irgendwie ein Dutzend Inselnetze, die halt, ich sag mal, in den unterschiedlichsten Pflegezuständen sich befunden haben, die teilweise geschützt, teilweise nicht geschützt waren, teilweise, wir haben halt auch teilweise minus 98 in der Anlage gefunden, weil es dann auch real-time fähig war. Das sind halt alles Dinge, mit denen muss man sich irgendwie auseinandersetzen und an die muss man irgendwie rankommen und das irgendwie in einen, ich nenne es mal Hausstandard bringen. Das heißt, man muss die Idee ist halt, die Daten irgendwie abzuziehen, in ein einheitliches Format zu transportieren, zu transformieren, sodass ich sie, dass ich sie vereinheitlich auf einem vernünftigen Dashboard visualisieren kann und dann in der weiteren Folge auch dort Signale draus extrahieren kann, aber da kommen wir gleich noch zu. Protokolle, was mir so über den Weg gelaufen ist, ist halt OPCUA. Das ist halt so ein bisschen Industriestandard, wird häufig verwendet, gibt es aber auch ungefähr unendlich viele Flavors, in denen man das implementieren kann, in denen man das benutzen kann. Rest-Schnittstellen, wenn es irgendwie gut war, das war ganz okay. Eine Menge ODBCs, um auf ein paar rdbms zuzugreifen, die halt in den Steuerungen verbaut waren, also da gibt es ein paar Postgres-Server, irgendwo ein paar MS SQL Desktop Engines, wenn es halt irgendwie Winder sein musste, ein bisschen unabititlich. Modbus, konnte man haben, hat man halt ein Modbus Gateway installiert, Modbus TCP, wenn es cool war, da musste man da nichts mehr machen. Bagnet gibt es in der Lüftungssteuerung und naja, manche Systeme haben halt überhaupt keine Schnittstelle, da gibt es dann zum Beispiel irgendwie so ein Webservice und intern, da hat man dann halt mit Curl und Python ein HTML Pasa gebaut und holt sich dann da irgendwie die Daten runter, dass man sie irgendwo in der Time Series Datenbank oder generell in irgendeiner Datenbank abspeichern kann und quasi so ein bisschen vom internen Webserver gekratzt hat. Ist halt ein bisschen doof, wenn da irgendwie ein Firmware Update kommt, also wenn es denn kommt und irgendwas ändert sich am Layout, da muss man da quasi immer wieder nacharbeiten, das ist so das Permanente Doing, um das man da nicht rumkommt, dass es muss halt auch permanent gewartet werden und von uns immer mal wieder ein bisschen nach gearbeitet werden. Grundsätzlich bei den Maschinenbauern, also es gibt natürlich die großen Firmen, die haben das Thema IT irgendwie auch ganz gut im Griff und dann gibt es halt so die kleineren Lieferanten, die halt irgendwie kleine, aber essenzielle Gewerke für den, für das gesamte Maschinenkonstrukt liefern. Das ist dann häufig mal gerne so eine One Developer Show, der hat irgendwie seine Software so vor, keine Ahnung, 15 Jahren programmiert und im Grunde seitdem ist da irgendwie nicht sonderlich viel passiert. Da tut man sich halt schwer, wenn man im weiteren Verlauf bei Verhandlungen oder bei Gesprächen, die man über eine Öffnung von Schnittstellen führt, wenn man dort Unterstützung haben will und den dann sagt okay, wir hätten gerne irgendwie, dass uns die Daten auf dem MQTT Broker abwirft, dann im besten Fall erkennt der MQTT, im dümmsten Fall er kennt das halt irgendwie gar nicht, im Grunde ist man dann so ein bisschen auf sich selber gestellt und bekommt dann häufig keine gute Zuarbeit. Grundsätzlich ist es auch schwer gewesen, Daten in Echtzeit aus der Rumpfanlage, also aus allen Aggregaten rauszubekommen, außer aus der Rumpfanlage, da haben wir mit MAN ganz gut kooperieren können und die haben uns dann bestimmte densiometrische Daten auf eine Echtzeit abgeschmissen, also auf ein MQTT Broker geworfen und uns eine Möglichkeit gegeben, auf per ODBC auf deren Postgres-Datenbank zuzugreifen, in der in der ganzen Menge über Verbräuche und so weiter drin steht, aber halt eben nicht, was im gesamten Fabrik bzw. Produktionskontext anfällt. Wie schon gesagt, eine Auswertung über alle Aggregatewahlen mit sehr hohem Aufwand verbunden, manuell will man im Grunde nicht machen und die Reportings waren halt meist auftragsbezogen und erst nach Jobende verfügbar. Eigentlich will ich, wenn eine Qualität oder ein Verbrauch oder irgendein Problem oder eine Sache im Auftrag aus dem Ruder läuft, sofort ein Signal haben und nicht erst, wenn der Job zu Ende ist, weil im Grunde, wenn er produziert wird, da wird so viel Energie und Material aufgewendet, wenn die Produktion halt von zwei Stunden kaputt ist, dann steht da gleich ein sechstelliger Betrag da, deswegen braucht man das Signal irgendwie so schnell wie möglich und diese Möglichkeit wollten wir im Grunde schaffen. Die ersten Projektschritte waren mal die Identifikation und der Datenquellen. Ich habe es ja gerade schon mal gesagt, was man alles hatte, als wir da ein bisschen Archäologie in der Anlage betrieben haben. Dann gab es halt eine Zusammenarbeit mit der Fachabteilung meines Kunden, also Geschäftszeitung, Produktionsleitung, technische Leitung, Instandhaltung und von denen hat man sich dann so die Informationen zum einen, wo bekomme ich wiederum eine weitere Information her, zusammengesucht, was sind meine Ansprechpartner und was braucht ihr denn wirklich, was macht Sinn zu sammeln, weil im Grunde macht es auch nicht Sinn, jeden einzelnen Datenpunkt, den ich irgendwo abgreifen kann, zu sammeln und erst mal irgendwo in einen Data Lake zu schmeißen und dann hinterher einen sehr hohen Aufwand mit der Interpretation dessen zu haben. Also sind wir hingegangen, haben Kontakt mit den Maschinenlieferanten aufgenommen, mit den einzelnen Gewerken, haben Dokumentationen angefordert, die halt häufig nicht vorlagen, weil häufig lagen halt nur die, naja so Betriebsanleitungen, sag ich es jetzt mal und in Betriebnahmeanleitungen vor, aber eben keine tief technische Dokumentation, wo ich jetzt irgendwie Daten mir rausziehen kann. Das war halt auch viel Reverse-Engineering, weil wenn wir überhaupt keine Informationen bekommen haben, hat man halt im Grunde mal, naja, dann hat man einmal so ein Portscan in dieses Foulange gemacht, von diesem jeweiligen Schaltschrank geguckt, was das so antwortet und wenn er irgendwie so ein Webserver war, der die Daten abgeworfen hat, dann hat man zumindest schon mal eine Notlösung gehabt für den Fall, dass man mit dem Lieferanten irgendwie nicht weiterkommt. Wir haben dann irgendwie halt immer eine Zusammenarbeit vorgeschlagen, manche waren da auch so ein bisschen aufgeschlossen, wollten sich selber dort weiter entwickeln und haben auch irgendwie ein bisschen Nachholbedarf dabei sich selber gesehen. Manchmal war es aber auch so, dass man das Gefühl hatte, dass man ihnen die Butter vom Brot nimmt und sie sich so ein bisschen ertappt gefühlt haben, dass sie jetzt einfach zehn Jahre gepennt haben und jetzt quasi der Kunde ankommt und irgendwie deutlich modernere Dinge fordert und haben will. Das ist dann schon so ein bisschen Psychologie oder gehälfte der Zeit war psychologische Arbeit irgendwie mit den Leuten, die Leute zu motivieren, irgendwie mitzugehen und den Mehrwert für sie selber zu sehen. Ich meine, das was sie bei uns lernen oder mitlernen konnten, konnten sie aber anderen Kunden irgendwo verwenden, aber das war dann auch immer so ein bisschen eine Frage des Mindsets. Ich meine, wenn da halt irgendwie die Softwareabteilung von Maschinenbauer irgendwie seit 15 Jahren die Hände in den Schoß legt, dann tut man sich ja halt schwer solche verkrusteten Zufriedenheiten aufzubrechen, um das mal so zu sagen. Gut, dann sind wir hingegangen, haben mal eine Datenstruktur modelliert, das heißt Objektstrukturen, die alle Metriken, die irgendwie im Prozess, im Produktionsprozess eine Rolle spielen, berücksichtigen und abbilden und gleichzeitig auch eine gewisse Erweiterbarkeit zur Verfügung stellen. Also letztendlich war es dann halt in der Jason-Struktur, die wir dann auf MQTT-Broken abwerfen und ein bisschen vereinheitlichen, komme ich gleich noch zu dem zweiten Schema, worauf wir uns da geeinigt haben und das war dann auch relativ schnell festgezelt. Dann haben wir die Softwarekomponenten ausgewählt. Ja, dann gab es halt noch die Frage Security, also da hatten wir auch so unsere Learnings viel in unserer Engineering-Phase und Testphase. Macht Security gleich von Grund auf, schmeißt alles in separates Foul an, wenn es darum geht, wenn man irgendwo Krypto anwenden kann auf einer MQTT-Verbindung oder so was, am besten gleich machen. Wenn man ein kleinen, also TLS-Zertifikator oder eine vernünftige Authentifizierung verwenden kann, gleich machen. Weil hinterher, wenn man das Ganze mal in Produktion hat, das dann nochmal auszutauschen, da ist man dann halt auch manchmal, also man hat manchmal andere Dinge zu tun und schiebt das dann so zwei, drei, vier Jahre vor sich hin, am besten gleich machen. Ansonsten mussten die Flows entwickelt werden zur Metrik-Transformation, das heißt man hat die Daten abgegriffen von einer Quelle oder hat sie irgendwie gepusht bekommen im besten Fall und musste sie dann mit ein bisschen Customcode eben in das Format zwingen, indem wir sie haben wollten. Manchmal musste noch ein bisschen was pre-calculated, also vorberechnet werden, das hält sich aber dann in Grenzen und nach hinten raus, also in Ausgabeseite mussten halt die Datenbankabfragen, also die Infoxabfragen, mittlerweile Flux-Lunkvarys entwickelt werden, was irgendwie so ein bisschen Zeit war, weil man da halt auch eine Menge Logik drin unterbringen kann und dann schlussendlich so ein bisschen der angenehmere Teil, das Zusammenklicken der Grafana-Dashboards, damit halt auch alles schön bunt wird und man dann halt endlich das hat, was man halt in der Vorkette oder wofür man in der Vorkette gearbeitet hat. Was haben wir für ein Technic-Stack verwendet, das ist im Grunde sehr IT-mäßig, das benutzen wir keine Ahnung bei uns in der IT-Operation seit 20 Jahren oder seit 10 Jahren. Infox.deb als Time-Series-Datenmangel angefangen mit 1x und Infox.ql mittlerweile weiterentwickelt auf Infox.deb v2 und die meisten Queries sind dann jetzt auch schon in Flux lang portiert, für textuelle Informationen, also das ist gar nicht mehr so mega viel, das sind halt irgendwie Status-Meldungen, Log-Meldungen, haben wir einen Grey-Log und einen hinten angeschlossenes Elasticsearch, bzw. mittlerweile Open-Search laufen, wo man dann so ein bisschen nach Korrelationen von bestimmten Log-Meldungen zu Entwicklung von numerischen Werten sich ein paar Insights schaffen kann oder besorgen kann. Gründe für Infox war im Grunde, erst einmal schaut okay, schmeißen wir uns irgendwie eine SQL oder so was rein, aber so richtig für die zu erwartene Menge an Datenpunkten, das skaliert halt nicht so schön. Infox haben wir getestet, irgendwie es auf dem Single-CPU-Server mit ein bisschen NVMe, also man hat irgendwie 500.000 Matrix pro Sekunde, die wir problemlos schreiben konnten, das war deutlich mehr als das, was wir irgendwie erwartet haben, wir haben halt so mit 1.500 Matrix pro Sekunde gerechnet, also war das im Grunde der Datastore der Wahl und unabhängig davon, der komprimiert wahnsinnig gut, das heißt, wir haben jetzt seit 2018 und wir haben infinite retention ungefähr 800 Gigabyte an Daten und wenn alle Systeme laufen, kommen wir im Moment so auf 15.000 Datenpunkte pro Sekunde, komprimiert mega gut und skaliert für unseren Einsatzzweck ideal. Textuell Information habe ich gerade schon gesagt, ist Elastic Search, mittlerweile Open Search und so als zum Metrik-Transformation benutzen wir Node Red, weil da kann man sich relativ easy die Inflows, die Transformation der Sachen zusammenklicken und anfangs hatten wir das alles in Python Scripts, hatten ein Verzeichnis voll, 15 Custom Python Scripts, das skaliert halt irgendwie nicht, wenn man andere Leute daran arbeiten will, das ist nicht schick und dann haben wir das irgendwann umgestellt und haben halt irgendwie über Node Red uns diese Flows gebaut und das Ganze da halt mit JavaScript Code transformiert. Also ich zeige gleich das Schema. Messaging Protocol ist NQTT, das heißt, wir haben NQTT Broker im Einsatz, läuft halt super stabil und wir haben da halt den Vorteil, wenn wir irgendwann nochmal mit irgendeiner Third-Party-Applikation Daten abgreifen wollen, müssen wir das nicht aus dem Time-Chase-Storm machen, sondern wenn wir es live haben wollen, können wir uns die Daten einfach über den NQTT Broker holen. Visualisierung, schon gesagt, ist Grafana, also immer in den aktuellsten Versionen, das funktioniert irgendwie wunderbar und als Lock Extractor vor Open Search benutzen wir aktuell Greylock 4, genau. Das ist jetzt mal so das Komponentendiagramm. Die meisten Sachen kommen eben gepult in 10 Sekunden Intervallen, damit bald auch die liefernden Systeme irgendwie nicht DDOS'n. Textuelle Informationen aus einer Postgres meistens laufen auch in Node Red Flow rein, kommen in Greylock, werden da geteckt und landen in Open Search. Aus der Rumpfanlage, das ist Pekom PMI, das ist von M1 Roland, die Prozessleittechnik, da kommen eine ganze Menge Performance-Metriken und Events mit numerischem Charakter. Da kommen wir über Postgres und ODBC dran, das kommt in Node Red rein. GridWiz Energy, darüber haben wir das gesamte Energiemenagement angebunden, das ist aus so ein bisschen Bronzchenstandard. Das heißt, das fragt für uns eine ganze Menge an Energieben, also an einer, das fragt für uns die sehr feingliedrige Energiemesstechnik in der gesamten Fabrik ab, sodass wir halt sehr gut identifizieren können, wo der meiste Energieaufwand entsteht oder wo sich Verbräuche abnormal erhöhen, also das kann halt defekter Antrieb oder was was ich sein, das landet halt erstmal alles in GridWiz und da frage ich es quasi über eine Rest-AP ab, kommt auch in Node Red rein und auf unseren MQT Tableoka. Dann gibt es noch eine Bronzchenlösung des ERP-Systems, das ist auch nicht schön, das nennt sich Chroma, es gibt wohl Gründe, warum man das in der Branche verwendet, ist halt eigentlich irgendwie so eine klassische Windows kleinen Server Anwendung. Oracle Datenmodell mit tausend Tabellen, wirklich unhandliches Ding, aber da bekommen wir halt noch eine Menge an Planinformationen raus, die wir im Grunde auch haben wollen, um sie, um Insights daraus zu generieren, um sie halt mit Produktionsdaten zu aggregieren. Da kommen wir dann später noch zu. Oracle OCI auch in Node Red rein, auf unseren MQT Tableoka ins Telegraph in Influx.de. Zum Qualitätsmanagement, es gibt eine densiometrische Qualitätskontrolle, da haben wir mit Manrolan zusammengearbeitet, dass sie uns die ganzen Dinge per MQT Tableoka direkt auf unserem Broker schmeißen, sodass wir die Werte als Change of Value bekommen, das heißt in dem Moment, in dem eine traversierende Kamera auf der Druckbahn eine Messung macht, in dem Moment landet das tatsächlich bei uns auf dem MQT Tableoka, also Real Time, also mehr Real Time geht quasi nicht. Können wir dann, müssen wir dann im Grunde noch so ein bisschen zwischentransformieren, machen wir auch in Node Red, schmeißen uns wieder auf dem MQT Tableoka, landet dann in unserem Standardformat im Telegraph, der dann auch noch als Metrikbuffer agiert. Das heißt, wenn wir mal den Influx Server neu starten müssen, werden die Sachen für eine gewisse Zeit dort gepuffert und gehen nicht verloren. Das erleichtert uns so ein bisschen die Serveradministration und dann von Telegraftern im Datenbank Server. Genau, das haben wir da unten noch. In der Nachverarbeitung gibt es zwei Roboterzellen von ABB. Da haben wir Zugriff auf den OPCU-A-Broker bekommen, über den wir Betriebszustände der Roboterzellen, also das betrifft eine ganze Menge Energieverbräuche, Drucklüffverbräuche etc. abfragen können. Auch auf MQTT haben wir eine Schnittstelle geschrieben, OPCU-A-Broker MQTT, auch auf unserer Node Red wieder ein MQTT Telegraph Influx DB. Das hat sich irgendwie so ganz gut angeboten. Gut, dann kommen wir mal zum ersten Beispiel, was uns das für Insights gegeben hat, ein Beispiel für die Energieverschwendung. Es hat sich herausgestellt oder die Einblicke, die wir über die Visualisierung dieser ganzen Daten bekommen haben, die hat vorher nie jemand sich verinnerlicht. Das hat man nicht gesehen. Es gab keine Energieauswertung, man hat das eben nicht greifbar gehabt. Ein Beispiel dafür ist, in produktionsfreien Zeiten hat man früher im Grunde nichts heruntergefahren. Diese Fabrik, diese Produktionslinie ist immer durchgelaufen. Da hat man gesagt, okay, das müssen wir nicht machen, wir haben jetzt hier, also da gibt es zum Beispiel diesen Trockner. Das ist halt irgendwie so ein 50 Meter langes Arrigat, wir haben Gas betrieben. Hat man gesagt, ja, der Verbrauch, am Wochenende nur Gas für keine Ahnung, 300 Euro oder so was. Hat aber völlig außer Acht gelassen, dass sobald der Trockner läuft, die Kühltürme laufen. Und je nach Wetterlage, so im Schnitt braucht der 300 KW. Wenn ich das jetzt mal hochrechne, bin ich da gelandet, bei 10.800 Kilowattstunden pro Woche sind 561 Megawattstunden im Jahr, mal drei Produktionslinien sind 1.600 Megawattstunden im Jahr, sind 731 Tonnen CO2 oder eine halbe Million Euro. Also im Grunde waren das so die lowhanging Foods, die man irgendwie sofort ernten konnte, die man sofort gesehen hat, wo im Grunde alle die Hände über dem Kopf zusammengeschlagen haben. Es gab natürlich ein paar Argumente und Gegner, die haben gesagt, okay, wir machen das seit 1801 so, wir machen das auch in Zukunft so, das ist ja alles kein Problem und wenn wir Systeme runterfahren, dann fahren sie nicht wieder vernünftig an. Oder wir haben dann Probleme, den Betrieb wieder neu zu starten. Das ist so ein bisschen wie ein schlecht gewartetes Linux-System, welches nicht gut fest ist. Klar kann man natürlich immer laufen lassen und wenn es dann irgendwann mal trotzdem gebudet wird, hat man halt ein riesen Problem. Ich finde, dass man irgendwie für eine halbe Million Euro im Jahr dieses Problem irgendwie adressieren kann und das ganze startfähig machen kann. Hat man dann auch gemacht, macht man jetzt mittlerweile seit vier Jahren so, ist auch irgendwie kein Problem gewesen auf einmal. Wir haben halt in Grafana dann ein einfaches Regelwerk definiert, was dann so geht, okay, wenn im ERP-System keine Produktion geplant ist für die nächsten acht Stunden und seit zwei Stunden Anlagenstillstand ist und der aktuell gelahene Job bei 100 Prozent ist, um so ein bisschen auszuschließen, dass wir gerade in der technischen Störung sind, setzt seine Teams Nachricht an den Produktionsleiter ab, trockener aus, Druckluftsegmenten schließen, sekundär Aggregate in Standby. Das ist im Grunde der einzige Trick gewesen, um die Energieeinsparung, die ich jetzt gerade mal so ein bisschen skizziert habe, was ein Teil des Ganzen ist, zu realisieren. Und ich finde das irgendwie tatsächlich relativ breathtaking, dass man das einfach jahrelang irgendwie so mitgenommen hat und mit ein paar wenigen Änderungen der Verhaltensmuster oder der Verhaltensweisen und ein bisschen Visibility dort einfach Dinge fundamental ändern konnte. Ein weiterer Aspekt oder eine weitere interessante Sache, die sich ergeben hat, im Zuge dessen, dass Daten auf einmal sichtbar waren, dass halt im Grunde auch die Geschäftsleitungen auf Ihren Grafana Dashboards Dinge aus allen Datenquellen sehen konnte, war, dass es eigentlich niemals eine vernünftige Business Number Validation gegeben hat. Beispiel dafür sind, es gibt, also Farbe wird in der Druckerei halt relativ viel verbraucht und irgendwann war man auf der Suche nach 400 Tonnen Farbe. Im Jahr 2018 sind 400 Tonnen mehr an Farbe gekauft worden, als irgendwo in der Nachkalkulation auf Aufträgen drauf waren. Okay, dann haben wir irgendwie mal geschaut, wie kann das sein? Also die Druckanlage meldet hat normalerweise schon, wie viel Farbe irgendwie verdruckt wurde. Da wir jetzt aber an mehreren Stellen einen bestimmten Wert nehmen, gab es dort Abweichungen und letztlich das, was als Siloentnahme gemessen wurde, hat nicht im Ansatz mit dem übereingestimmt, was die Druckwerke dann zurückgegeben haben. Hat sich im Grunde rausgestellt, dass diese volumetrischen Farbmengenmesser an den Druckwerken einfach mit der Zeit degradieren über die Jahre durch die mechanische Belastung, weniger Messimpulse liefern und somit dann halt immer weniger Farbe und also quasi Verbrauchsmaterial auf den Aufträgen drauf steht und somit da wiederum in der in der Kalkulation halt vorn und hinten nichts stimmt. Also haben wir das irgendwie angegangen, haben wir das irgendwie normiert, haben halt Korrekturkurven geschrieben und das ein bisschen abgeglichen mit dem, was die Wiegezellen der Farbsilos hergeben über einen längeren Zeitraum und sind jetzt noch mal ein paar Prozent Abweichungen statt vorher 35 Prozent Abweichungen. Also genau das waren irgendwie 3.600 Tonnen, Gesamtbeschaft davon waren 400 Tonnen nicht abgerechnet. Ja, fand die Geschäftszeitung dann auch ganz okay, dass man das mal irgendwie so ein bisschen aufgedeckt hat. Generell sind halt relativ viele Verbrauchsstoffe auch gerne irgendwie so ein bisschen nach Bauchgefühl geschätzt worden. Das ist halt irgendwie so ein bisschen Magic, das muss man halt auch so ein bisschen aufberechen und demystifizieren, aber sobald man halt irgendwie einfach handfest belastbare Werte hat und das halt mit Daten belegen kann, gibt es halt auch nichts mehr hin und her zu diskutieren. In der Folge dieser Ungenauigkeiten war halt eine, in der Branche mittlerweile obligatorische, ein obligatorisches Umweltmanagement auch ehemals nicht möglich. Also das ist halt dieses Umweltmanagement System, was bei energieintensiven Industrien derzeit gefordert ist und was man implementieren sollte, ging nicht. Jetzt haben wir im Grunde die Datenbasis dafür, dass wir das tun können. Ich würde jetzt mal ein paar Dashboards zeigen, um einfach ein bisschen das mit Dingen zu dokumentieren oder her zu zeigen, wie das Ganze dann aussieht. Ein paar Sachen sind halt weggepixelt. Das ist jetzt so ein Plant-Overview mit den drei Produktionslinien. Ich sehe halt die Geschwindigkeit. Ich sehe die Geschwindigkeit im Verlauf, kann halt genau sagen oder kann halt einen besseren Einblick, wie häufig Störungen sind, sehe hier unten schon mal einen groben Überblick über Qualitätsparameter, also über KPI's, die das Qualitätsmanagement betreffen. Wie gut ich meinem Druckstandard bin, der eigentlich gefordert ist. Auch wenn wir jetzt auf diese Qualitätsfrage nicht im Detail eingehen, das ist zum Beispiel dieses, das Silo Dashboard, wo ich halt recht genau sehen kann, wie viel angeliefert wurde, wie viel entnommen wurde und diese Werte dann halt wieder nehmen kann und mit den anderen Messwerten zum gleichen Consumable vergleichen kann. Generell stolpert man halt häufig darüber, dass man einen Messwert für eine bestimmte Sache hat. Den greift man an drei Stellen in der Anlage ab und hat dreimal unterschiedliche Werte. Das ist eine ganze Menge Zeit, die dafür drauf gegangen ist, zu identifizieren. Was ist denn jetzt wirklich wahr? Was ist der richtige Wert? Und das muss man im Grunde einmal machen, um da genau was sagen zu können. Bei diesen Sachen oder bei diesem Prozess kommen so viele Ungereimtheiten auf, dass man häufig auch Leuten auf die Füße tritt, weil einfach Missstände, die jetzt seit sehr langer Zeit geherrscht haben, irgendwie offensichtlich wären. Weswegen unser Projekt auch nicht immer Freunde gefunden hat. Also eine Sache ist halt, dass man durch die Herstellung von Transparenz fühlen sich die Leute überwacht. Das heißt, man kann halt nichts mehr verstecken und irgendwie muss man dann erklären, warum das eigentlich eine gute Sache ist, warum es eine gute Sache ist, dass man zum Beispiel feststellen kann, dass in einer bestimmten Schicht mit einer bestimmten Maschinenbesatzung bestimmte Fehlerhäufigkeiten auftreten. Dann kann man die Leute halt auf eine Nachschulung schicken, dann wird es quasi besser. Das aber zu vermitteln ist halt erfordert ein bisschen Feingefühl. Jetzt müssen dann andere Leute machen. Aktuell in der Entwicklung eine interessante Sache ist das Thema Müllvermeidung. Da muss ich ein kleines bisschen zu ausholen. Druckanlagen, Rotationsdruckanlagen haben Waschzügel. Das heißt, in der Zeit wird alle drei bis vier Rollen, werden die Gummitücher gewaschen, damit das Druckbild konstant bleibt, damit es keine zu harte Tonwärtszone mehr gibt. Bronzchenstandard ist, dass man das in fixen Zyklen macht abhängig vom Papier, also vom Material, was man verwendet, von der Farbe und vom Silikon, was man verwendet. Häufig hat sich aber durch Messungen, die wir gemacht haben, herausgestellt, dass man deutlich länger ohne ein Waschzyklus fahren kann, als man müsste, weil man deutlich länger im Standard wäre. Das sieht man hier irgendwie ganz gut. Grüner Bereich ist in Ordnung. Das darüber sind die densiometrischen Werte, also die Tonwärtszunahme in den verschiedenen Farbspektren, also das ist jetzt zum Beispiel Cian Magenta Gelb 50 auf der oberen Papierseite. Das heißt, darüber können wir jetzt ein Signal generieren oder eine Empfehlung generieren, die es der Maschinbesatzung ermöglicht, über diesen Zeitraum bei einem Langläufer hinauszudrucken. Waschzyklus bedeutet halt immer, in dem Moment werden die Druckzylinder aufgefahren. Das, was an Papier durch die Anlage fährt, geht in den Müll. Das ist Makulatur, so nennt sich das. Und das wollen wir halt idealerweise verhindern, einmal, weil es weniger Geld kostet, weil es umwelten weniger belastet, weil die Maschine halt auch in der Zwischenzeit läuft. Dann läuft dieser Waschzyklus ungefähr 60 Sekunden, die Zylinder fahren wieder zu und dann geht das Ganze weiter. Wenn wir diese Zyklen halt reduzieren können, können wir halt einfach eine ganze Menge Müll sparen. Und das ist jetzt gerade so ein bisschen das aktuelle Projekt, was schon, ich sag mal, advance ist und nicht mehr so zu den low hängigen Flutszelt, was wir gerade umsetzen und wo wir ein bisschen mit Forecasting arbeiten, um das zu automatisieren. Also aktuell gibt es nur eine Empfehlung, die generiert wird, die halt dem Drucker auf einem Dashboard sagt, okay, du wirst wahrscheinlich noch vier Rollen fahren können, ohne ein Waschzyklus machen zu können. Idealerweise kann man diesen Loop irgendwann schließen und das automatisieren. Gut, kommen wir mal zu den Projektkosten. Was hat das Ganze irgendwie gekostet? Wir haben Compute Hardware angeschafft, ein Proxmox Cluster, fünf Notes, ein bisschen hyperkonvergentes Zeug, Allflash hat 60.000 gekostet. Dann gab es eine Menge an, das war der größere Teil, Lizenzkosten, was wir an Maschinenhersteller zahlen mussten, um geöffnete Schnittstellen zu bekommen. Dann musste ich hier mal an Modbus Gateway her, das war halt irgendwie so klein Kram, was sich irgendwie geleppert hat, so zum Anfang waren das irgendwie 150k, mittlerweile ist es wahrscheinlich ein kleines bisschen mehr. Im Vergleich zu dem, was wir allerdings gespart haben, sind es alles sehr, sehr überschaubare Kosten. Die laufenden Kosten, wenn ich jetzt immer den Stromverbrauch vom Cluster nehme, das sind so 10,5 Megawatt Stunden im Jahr, sind ungefähr bei 30 Cent gerechnet, 3.000 Euro im Jahr oder 4,5 Tonnen CO2. Das ist natürlich etwas, was auf der Solseite steht, was wir irgendwie investieren müssen. Auf der haben Seite steht allerdings folgendes, das sind jetzt Werte, die wir über die Jahre 2019 bis 2022 ermittelt haben. 2018 habe ich jetzt mal weggelassen, weil da haben wir noch, also da war das ganz im Grunde erst in der Research Phase, würde ich sagen. 2019 waren dann die Dinge schon in Effekt. Stromverbrauch absolut 2019, 14.200 Megawatt Stunden konnten wir senken auf 10.700 Megawatt Stunden. Diese Werte sind, by the way, auch PV bereinigt. Das heißt, das, was an PV-Eigenerzeugung im Unternehmen passiert, ist da schon rausgerechnet. Ersparen ist 3,5 Gigawatt Stunden oder 1.500 Tonnen CO2 oder 1 Million Euro, 1,5 Millionen Euro. Das ist dann die Zahl, mit der man die Geschäftszeitung am ehesten auch dazu überzeugen kann, dort ordentlich Entwicklerressourcen reinzustecken. Das sind jetzt halt absolute Werte. Das haben wir auch mal relativiert zu den, also in Relation gesetzt, über die E-Mass-Relationswerte. Bronzenstandard dafür sind 1016 Seitenbögen A4 gedruckt. Das heißt, der Energieeinsatz für 1.000, also für 1.000 Exemplare 16 Seiten A4 betrug 2019 7,9 Kilowatt Stunden. Mittlerweile sind wir nur noch bei 4,6 Kilowatt Stunden. Also das hat sich da schon ganz ordentlich rentiert. Also die Hälfte davon von dieser Einsparung alleine ist hentrockner, wenn ihr mehr als 3, 4 Stunden steht, einfach runterzufahren. Also natürlich muss man danach wieder ungefähr eine Stunde hochfahren, aber wenn man das um ein bisschen abschätzen und planen kann, geht das schon. Gasverbrauch konnte reduziert werden von 8,6 Millionen Kilowatt Stunden auf 6,1 Millionen Kilowatt Stunden. Einsparung hier 1.500, also knapp 1.600 von CO2 oder 116.000 Euro. Ich habe da drunter noch die Berechnungsgrundlagen geschrieben, also wie sich das in CO2 umsetzt. Gasverbrauch relativ reduziert von 5 Kilowatt Stunden pro 1.000 Exemplare 16 Seiten auf 2,63 Kilowatt Stunden pro 1.000 Exemplare 16 Seiten. Durch die Waschzyklusgeschichte konnten wir die Makulatur oder generell durch eine bessere Möglichkeit der Fehleranalyse. Das sind halt, da gibt es noch eine ganze Menge weiterer Insights, die sich die wir gewinnen konnten. Auf jeden Fall konnte die Makulatur deutlich reduziert werden von 9.500 auf 7.700 Tonnen. Das sind dann nochmal 1.800 Tonnen weniger Papiermüll, die im Grunde angefallen sind in der Produktion pro Jahr. Gesamt komme ich da dann auf knapp 5.000 Tonnen CO2, die wir im Jahr sparen konnten oder 1,2 Millionen Euro. Und ja, das war im Grunde ein erstaunliches Ergebnis. Also wir haben halt über die Jahre dahin entwickelt. Wir waren diese Zahlen relativ lange nicht klar, weil gut, wir haben halt die Tools zur Verfügung gestellt, aber die Auswertung dessen, was das Ganze wirklich gebracht hat, die haben wir uns dann in den letzten, im letzten Jahr mal angeschaut oder die habe ich mal im letzten Jahr mal angeschaut und da waren wir dann relativ, relativ baff, dass es ganze doch sehr, sehr signifikante Auswirkungen hat. Und deswegen hatte ich die Idee, diese Erfahrung heute mit euch zu teilen. Genau, damit bin ich auch schon am Ende und würde das Q&A eröffnen, wenn es Fragen gibt. Vielen Dank für deinen Talk. Aufgrund der Zeit und des nächsten Talks, würde ich sagen, das Q&A würden wir überspringen. Eventuell möchtest du uns sagen, wo wir dich auf der GPN finden können, wenn wir mit dir über das Thema sprechen möchten? Ja, also wahrscheinlich irgendwo bei der Bar, bei der Martequelle oder beim Knock oder so, genau. Alles klar. Vielen Dank. Dankeschön.