Big Data Analytics – Erfahrungen in der Fertigung

Häufig sind in der Produktion dutzende IT-Systeme verschiedener Hersteller im Einsatz. Diese sind nicht immer gut miteinander vernetzt. Wie kann Datenintegration dennoch erfolgreich sein?

Zu diesen IT-Systemen gehören zum Beispiel SAP Module (Produktionsplanung, Plant Maintenance, MES, usw.), Maschinensteuerungen, Monitoring Systeme oder Datenbanken. Einheitliche Standards zu Dateiaustauschformaten und -protokollen setzen sich erst seit einigen Jahren mit neuen Anlagen langsam durch, während ältere Maschinen häufig nur proprietäre Schnittstellen haben. Lücken und Mängel in der Betriebs- und Maschinendatenerfassung und darauf beruhende Datenqualitätsprobleme gehören zum Shopfloor-Alltag.

Zusätzlich gibt es bei vielen Mittelständlern und auch bei manchen größeren Unternehmen noch kein unternehmensweit umgesetztes Big Data Architekturkonzept. Bisher eingesetzte Business Warehouse Lösungen erfüllen oftmals nicht die Ansprüche hinsichtlich Flexibilität, Datendurchsatz und (Echtzeit-)Performance.

Es ist also nicht verwunderlich, dass auf die Datenintegration schnell der Löwenanteil der Implementierungsarbeit in Big Data oder auch Machine-Learning-Projekten entfallen kann.

Architektur

Eine Lösungsarchitektur sollte also Folgendes ermöglichen:

  • Eine einfache, schnelle und flexible Anbindung von Maschinen, Sensorik und sonstigen IoT-Elementen
  • Echtzeit-Analyse und -Visualisierung von Massendaten
  • Performante Verarbeitung von großen Datenströmen
  • Skalierbarkeit

All dies wird mittlerweile durch kostenpflichtige Tools und Plattformen wie auch durch Open-Source-Lösungen ermöglicht. Out-of-the-box-Lösungen für Datenintegration gibt es, aller Marketing-Versprechen zum Trotz, für die meisten realistischen Einsatzszenarien keine.

Die Kundenanforderungen hinsichtlich Datenvolumen und -durchsatz, Echtzeitrelevanz und Nutzung von Frontend-Business Intelligence Anwendungen wie Qlik Sense oder Power BI haben wir in mehreren Projekten mit einer auf Apache Kafka basierenden Streaming-Architektur umgesetzt. Wie in Bild 1 zu sehen ist, übernimmt Kafka die Datenakquisition, ETL-Prozesse, Streaming Analytics sowie temporäre Datenspeicherung.

NoSQL-Datenbanken wie MongoDB oder Couchbase lassen sich über Standardkonnektoren an Kafka anschließen und stellen die Schnittstelle zum Frontend dar. Solche Dokumentendatenbanken, in denen beliebige Daten zum Beispiel im JSON-Format gespeichert werden können, haben anders als klassische relationale Datenbanken keine starre Datentypbeschränkung und keine vorgegebenen Datenschemata. Insbesondere für Projekte, bei denen spätere Anforderungen schwer abzuschätzen sind und es viele unterschiedliche Datenquellen und -formate gibt, ist diese Flexibilität ein beträchtlicher und kostenrelevanter Vorteil. Hinzu kommt die horizontale Skalierbarkeit: Es können bei Bedarf einfach weitere Server hinzugefügt werden, statt die Hardware eines bestehenden Datenbankservers aufzurüsten zu müssen. Ein Pilotprojekt, bei dem lediglich eine Maschine angebunden wurde, kann somit schnell wachsen, ohne dass die Architektur überdacht und angepasst werden müsste – nahtlos bis hin zu einem globalen Rollout an mehreren Standorten.

Schematische Architekturskizze basierend auf Apache Kafka als Datenbroker und Streaming-Tool

Schematische Architekturskizze basierend auf Apache Kafka als Datenbroker und Streaming-Tool

Analyse

Kernstück der Architektur ist die Einbettung von Machine-Learning-Modellen. Unsere Erfahrung aus mehreren Pilotprojekten zeigt hierbei, dass Standardalgorithmen häufig nicht ausreichen. Algorithmen und Modelle müssen häufig an spezifische Besonderheiten der Fertigungsprozesse beim jeweiligen Kunden angepasst werden, um sinnvolle Ergebnisse zu erzielen.

Werksführungen zu Projektbeginn, regelmäßige Kommunikation und ständige Einbindung der Fachbereiche beim Kunden  wie etwa Werker und Schichtleiter während der gesamten Projektlaufzeit stellen sicher, dass unser Data-Science-Projektteam ein sehr gutes fachliches Verständnis sowohl der Daten und Datenqualität als auch der Prozesse entwickelt. Dies ist für Analytics-Projekte im Shopfloor unerlässlich.

Die Endanwender tragen natürlich nicht nur ihr Domänenwissen bei, sondern werden auch bei der Beurteilung der Prognosequalität stets eingebunden. Prädiktionsmodelle sollten nach dem initialen Deployment kontinuierlich trainiert und verbessert werden, da sie sonst schon nach einigen Monaten auf Grund von Änderungen an Fertigungsprozessen und Datengrundlage an Relevanz und Aussagekraft verlieren. Diese notwendige Aktualität und Flexibilität lässt sich fördern durch eine gelebte DevOps-Philosophie – eine strikte Trennung von Data Engineering, Data Science / Analytics und Operations ist heutzutage kaum mehr sinnvoll.

Fazit

Aus der Informatik kennt man den Ausdruck „Garbage In, Garbage Out“ – unsinnige oder fehlerhafte Eingaben führen zu unsinnigem Output. Das gleiche Prinzip gilt auch in der Datenanalyse: Egal wie komplex und leistungsfähig ein Algorithmus ist, ohne eine zuverlässige Datengrundlage und das Verständnis der zu Grunde liegenden betriebswirtschaftlichen und fertigungstechnischen Prozesse lassen sich keine verwertbaren Ergebnisse erzielen.

Aus diesem Grund sind uns eine enge Zusammenarbeit von Data Scientists und Data Engineers mit Entscheidungsträgern, Endanwendern und Prozessexperten auf Kundenseite in einem agilen, iterativen Arbeitsprozess sehr wichtig.

 

Hinterlassen Sie einen Kommentar

Nach oben