So werden aus Daten Informationen

Ganz zu Beginn eines Prozesses, der im eventuellen Aufbau einer Big-Data-Architektur oder der Entwicklung einer KI Anwendung mündet,  stellen sich Fragen in Hinblick auf Effizienz, Qualität, Stabilität oder Verlässlichkeit. Fragen wie

• Wie kann ich meinen Ausschuss reduzieren?
• Wie kann ich Stillstands-Zeiten reduzieren?
• Wie kann ich mein Prozessfenster vergrössern und damit die Stabilität?

führen zu

• Welche Prozessparameter beeinflussen meine Bauteilqualität?
• Ist mein Prozess stabil, sind meine Prozessfenster valide?
• Gibt es Anzeichen für Abnützung bei Komponenten einer Maschine?
• Wie wirken sich Variationen und Phasenschwankungen in meinem Rohmaterial auf das Endprodukt aus?

Ob kontinuierlicher oder diskreter Fertigungsprozess, ob Maschinenhersteller oder Kunststoffverarbeiter – diese beispielhaften Fragestellungen sind überall zu finden.

Falls der geneigte Leser glauben möchte, dass die Antwort auf die obigen Fragen ist: „Daten – wir brauchen Daten und lernen daraus die Antworten!“ müssen wir ihn an dieser Stelle zunächst enttäuschen. Vielleicht haben manche schon die leidvolle Erfahrung gemacht, dass das Sammeln einer auch noch so großen Datenmenge und das anschließende blinde Analysieren derselben in den seltensten Fällen erfolgreich ist.

Der erste Schritt ist immer die Analyse des Problems, und dies funktioniert je nach Fragestellung am besten in interdisziplinären Teams. Der Maschinenbauer, der Steuerungstechniker, der Prozessingenieur und der Anwendungstechniker im Team mit einem Datenanalysten können die vorhandene Fragestellung differenziert und aus verschiedenen Blickwinkeln betrachten. Ein weiterer Meilenstein ist bereits erreicht, wenn man jene Daten, die das Expertenteam als relevant erachtet, sammeln und persistieren kann. Ein Meilenstein deshalb, weil in diesem Fall alle Probleme zum Messprozess (was?, wie?, in welcher Frequenz?) geklärt wurden. Darüber hinaus wurden die Daten mit einer Semantik versehen, validiert, und im optimalen Fall wurden nicht nur die Rohdaten abgelegt, sondern die Daten schon in einem Datenmodell für die Analyse „vorbereitet“. Bewusst haben wir an dieser Stelle die Frage nach der Datenmenge ausgeklammert. Große Datenmengen können auf viele verschiedene Arten entstehen, sei es weil viele verschiedene Parameter gleichzeitig gemessen und gesammelt werden, weil Daten vieler Maschinen abspeichert werden, um vergleichende Analysen zu machen, oder weil die Fragestellung die Aufzeichnung von Daten über einen sehr langen Zeitraum erfordert (oft im Bereich der Predictive Maintainance der Fall). Darüber hinaus wird der Begriff „Big Data“ nicht alleine mit der Datenmenge in Verbindung gebracht, sondern mit den „3V“- Volume, Velocity, Variety. Aus diesem Grund findet man sich im Bereich der IoT auch ohne sehr große Datenmengen sehr schnell in einem „Big Data“-Szenario wieder.

Datenanalyse

Abbildung 2: Die Abbildung zeigt einen Prozeßparamter (Fliesszahl, blau), den Sollwert (schwarz punktierte Linie), das zugehörige Prozeßfenster (grün-strichliert) und einen Ausreisser (vertikale rote Linie).

An dieser Stelle möchten wir den Begriff der “Big Data Value Chain” (Abbildung 1) einführen, auch wenn wir, wie oben beschrieben, die Datenmenge nicht quantifizieren. Die Big Data Value Chain beschreibt vielmehr auch, in welcher Art und Weise Datenanalyseprojekte inkrementell funktionieren können.

Konkretisiert sei dies  anhand eines Beispiels aus dem Spritzgießbereich: In den schussaufgelösten Daten – Prozessdaten, die mit einem Zeitstempel versehen sind und einem Schuss zugeordnet werden können – findet sich ein Ausreisser. Diese Verletzung der überwachten Prozessgrenzen erfolgte, während die Maschine im Automatikmodus betrieben wurde.

• In der deskriptiven Analyse versuchen wir zu verstehen, WAS passiert ist – die Schüsse in der Abbildung wurden als Ausreisser deklariert, da die Fliesszahl in den jeweiligen Zyklen außerhalb des validen Intervalls lag.
• In der diagnostischen Analyse versuchen wir zu verstehen, WARUM etwas passiert ist – bei Betrachtung der Abbildung fällt auf, dass der Zeitabstand zwischen zwei Schüssen vor dem Ausreisser wesentlich länger war als gewöhnlich. Ein Vergleich mit anderen Ausreissern, bei denen die Fliesszahl überschritten wurde, zeigt ein wiederkehrendes Schema (langer Zeitabstand vor Ausreisser). Ein Prozessingenieur kann die Antwort liefern: Die längere Zeit zwischen den Zyklen ändert die rheologischen Eigenschaften der Schmelze (zum Beispiel die Viskosität) mit den beobachteten Auswirkungen.
• In der prädiktiven Analyse versuchen wir ein Vorhersagemodell zu designen – im vorliegenden Beispiel wird der Zusammenhang zwischen dem relativen Anstieg der Zeit zwischen zwei Schüssen und dem relativen Anstieg der Fliesszahl (relativ in Bezug auf die zum Beispiel letzten 10 Schüsse) untersucht. Aus dieser Korrelation lässt sich aus einer relativen Änderung der Zwischenzykluszeit eine ungefähre Änderung der Fliesszahl vorhersagen.
• In der präskriptiven Analyse versuchen wir Methoden zu finden, diesen Effekt zu kompensieren, indem wir diese Prozess-Schwankung ausgleichen. Im vorliegenden Fall kann dies bis zu einem gewissen Grad durch eine Anpassung von Umschaltpunkt und Nachdruckprofil erreicht werden.

Abbildung 3: Theory-guided Data Science Models

Welche Methoden wendet man an, um diese Ergebnisse zu erzielen? Kommt an dieser Stelle die künstliche Intelligenz beziehungsweise das Machine Learning zum Zug? Machine Learning hilft oftmals in der deskriptiven Analyse, in der diagnostischen Analyse hingegen wird eigentlich immer Expertenwissen benötigt. Die Kombination von zum Beispiel Clustermethoden, Regressionen sowie einfachen neuronalen Netzen mit auf Expertenwissen basierender Modellierung bietet einen wesentlichen Mehrwert. Generell sind wir Verfechter des sogenannten «Informed Machine Learning» beziehungsweise des «Physics Guided Machine Learning» bei dem einerseits eine zu kleine Datenbasis für das Training durch zusätzliches Expertenwissen kompensiert werden soll, und andererseits im Unterschied zur rein datengetriebenen Modellierung auch die Gesetze der Physik in die Analyse beziehungsweise Algorithmik einfliessen. Man spricht hier auch von «Theory-guided Data Science Models (TGDS)» (Abbildung 3).

Das gewählte Beispiel lässt sich noch weiter ausbauen. Bis zu diesem Punkt haben wir dem Ganzen weder ein Business Modell noch eine Deployment Strategie hinterlegt. Angenommen, die verlängerten Zykluszeiten stehen damit in Zusammenhang, dass der Bediener der Maschine die Teile nicht immer schnell genug vom Förderband entfernt. Dann kann bereits das Wissen aus Stufe zwei zu einer Auschussreduktion genutzt werden, die sich in Geldwert messen lässt. Es ist dazu nicht notwendig, Algorithmen oder Software zu deployen. Anders verhält es sich, wenn wir Stufe drei betrachten. Hier kann zum Beispiel eine Software deployed werden, die anzeigt mit welcher Wahrscheinlichkeit die Fliesszahl im folgenden Schuss den validen Bereich verlässt. Am komplexesten stellt sich Stufe vier dar – der Kompensationsalgorithmus muss direkt mit der Maschinensteuerung integriert werden. Dies ist sicher die kostspieligste Variante, aber auch jene, die den Ausschuss vollautomatisch reduziert.

Anforderungen an die IT-Achitektur

 Um die Big Data Value Chain ähnlich wie im soeben beschriebenen Beispiel anzuwenden, müssen eine ganze Reihe von Schritten durchgeführt werden:

• Problemstellung verstehen
• Datensammlung
• Datenanalyse und Problemmodellierung
• Entwicklung von Lösungen
• Ausrollen der Lösung

Dazu muss eine zu Grunde liegenden IT-Architektur eine Reihe von Anforderungen erfüllen, wobei nicht die Big Data Komponente (falls überhaupt benötigt) alleine diese Funktionalität bereitstellt. Oftmals wird diese in eine bestehende Systemlandschaft integriert, um alle Key Features abdecken zu können. Die Dimension des Betriebs und die Sicherheit der Lösung wollen wir im vorliegenden Artikel vollständig ausklammern und uns auf Features und die benötigten Softwarelayer konzentrieren.

Um die Daten überhaupt sammeln zu können, muss für die Maschine ein Treiber zur Verfügung stehen, der die Daten abgreifen kann. Diese Daten haben oftmals keine Metainformation und müssen angereichert  (mit einer Semantik versehen) werden. Dies alleine kann bei einem heterogenen Maschinenpark bereits sehr aufwändig sein. Nach dem Sammeln stellt sich die Frage des Datenroutings und der Datenspeicherung. Sollen die Daten in meinem lokalen System persistiert werden? Sollen sie zur Sicherung in eine Cloud? Sollen die Daten an mehrere Endpunkte verteilt werden? Wo können die Daten am besten analysiert werden? Kann eine Verdichtung stattfinden, um Kosten zu sparen?

Abbildung 4: Softwarelayer einer Big Data/Analytics Architektur (Bildquelle: alle TIG)

Bei der Verarbeitung der Daten muss unterschieden werden, zwischen der ersten initialen Analyse, die zur Problemfindung und Lösungsentwicklung notwendig ist, der zyklisch wiederkehrenden Analyse durch bestehende Algorithmen (Batch Job), sowie der kontinuierlichen Analyse durch bestehende Algorithmen (Streaming Analytics). Zum Beispiel wird eine Verschleißmessung einmal täglich automatisiert durchgeführt und in einem täglich laufenden Batch Job analysiert, um den Grad des Verschleißes zu überwachen. Bei einer Spritzgießmaschine wird jeder Zyklus auf seine Stabilität analysiert, bei einem Extrusionsprozess werden Messgrößen kontinuierlich analysiert – ein klassisches Beispiel für Streaming Analytics. Als Faustregel gilt: je höher die Frequenz der Analyse, desto näher am Ort des Geschehens sollte sie statt finden. Dies kann soweit führen, dass die Analyse zu einer Korrektur führt, die einen unmittelbaren Eingriff in die Steuerung notwendig macht. Damit verschwimmen auch die Grenzen zwischen analysierendem System und steuerndem System.

Hier wird deutlich, dass die Vielzahl an Anwendungen und Möglichkeiten, die sich durch die Digitalisierung ergeben,  auch flexible Architekturen für die Umsetzung bedingen.Generell sollten im Bereich Datenanalyse/Big Data flexible Architekturen bevorzugt werden, die sowohl „on premise“ als auch in der Cloud umgesetzt werden können (auch hybride Systeme können sich als vorteilhaft erweisen). Im Prinzip findet man meist eine über Layer beschriebene Architektur vor, die gängige Big Data Architekturen, wie zum Beispiel eine Lambda Architektur, abbilden können. Einzelne Komponenten, aus denen sich eine solche Architektur zusammen setzt, können bis in den Edge/Fog Bereich eingesetzt werden.

Der Interface Layer ist für die Datenschnittstellen und für jede Kommunikation sowohl mit den lösungseigenen Modulen als auch mit Drittsystemen verantwortlich. Um größtmögliche Flexibilität zu gewährleisten, können die einzelnen Datenschnittstellen in Containern laufen. (Operating-Sytem-Level-Virtualization). Ein weiteres Tool wird  für den ETL (Extract-Transform-Load) Prozess und die Datenlogistik benötigt.

Für die Verarbeitung von Datenströmen kommt eine Datenpipeline zum Einsatz. Charakteristisch dafür sind die Skalierbarkeit sowie die Replikationsfähigkeit und damit Ausfallsicherheit. Die eigentliche Verarbeitung von Daten kann auf zwei Ebenen basieren – der Echtzeitverarbeitung und dem sogenannten Batch-Processing. Bei der Echtzeitverarbeitung werden die Daten bereits direkt aus dem Interface Layer heraus verarbeitet, während für das Batch Processing die Daten aus dem Storage Layer geholt werden.

Der Storage Layer ist sowohl als Data Lake als auch als Data Hub ausgelegt, d.h. es werden nicht nur transformierte Daten gespeichert, sondern auch die Originaldaten. Dazu werden verschiedene Storage Tiers verwendet. Zeitseriendaten werden in einem OLAP (Online Analytical Processing) Store persistiert, Strukturdaten in einer nicht relationalen verteilten Datenbank. Die Originaldaten werden z.B. auf einem HDFS (Hadoop File System) persistiert. Bei kleineren Datenmengen können angepasst an die Anforderungen auch relationale Datenbanken zum Einsatz kommen.

Zuerst «die tiefhängenden Früchte ernten»

Fazit: Um erfolgreich Projekte im Bereich Datenanalyse und künstliche Intelligenz durchzuführen bedarf es eines durchdachten Konzepts und oftmals auch eines erfahrenen Partners. Das Wichtigste ist, mit einfachen Fragestellungen zu beginnen, und so die „tiefhängenden Früchte zu ernten“. Im Zuge dieser Projekte kann Schritt für Schritt entlang der Big Data Value Chain der Aufbau der benötigten Infrastruktur und Kompetenz auf technischer und analytischer Ebene erfolgen, um dann auch komplexere Probleme in Angriff zu nehmen. Die Erfahrungen der Autoren ist, dass besonders interdisziplinäre Teams und die Kombination von Modellierung, Simulation und Machine Learning, Stichwort „Physics Based Machine Learning“, die größten Erfolgsaussichten haben. Es ist ratsam,  bei der Umsetzung auch auf flexible Konzepte bezüglich der Infrastruktur zu setzen, damit die Lösung auch mit zukünftigen Anforderungen mitwachsen kann.

Kontakt

TIG – Technische Informationssysteme, Rankweil, Österreich

office@tig.at