leanbi
17/01/2024

Blog: Braucht Industrie 4.0 ein Data Warehouse oder ein Lakehouse? (Teil 2)

Die in Teil 1 dieses Artikels erläuterten Grundlagen bieten die Basis für erfolgreiche Industrie 4.0 Projekte. In Teil 2 möchten wir nun erläutern, wie diese Grundlagen in der Praxis umgesetzt werden können.

 

 

«Bottom up», «Top Down» oder wie hält man Projektaufwände gering?

Als langjähriger Partner von Industrie 2025 haben wir mitgeholfen die Arbeitsgruppe «Smart Data» aufzubauen, haben viele Industrie 4.0 Use Cases im Use-Case Finder der Industrie2025 beigesteuert und sind nun auch im Praxiszirkel Smart Factory involviert. Wir sind als Datenspezialist LeanBI und nun als Substring bei vielen Umsetzungen mit dabei, nicht nur im industriellen Bereich. Schaut man sich die spannenden 49 Use Cases im Use-Case Finder an, kann man zusammengefasst schliessen, dass:

  • die beschrieben User Cases im Zusammenhang Industrie 4.0 recht unterschiedlich sind,
  • und damit auch die Priorisierung der Unternehmung bezüglich Industrie 4.0 individuell gefasst wird,
  • und die Form der Umsetzung und die IT-Architekturen auf unterschiedlicher Basis erfolgt.
  • was aber nicht bedeutet, dass auf einer längerfristigen Industrie 4.0-Roadmap nicht auch viele Überschneidungen über die Firmen hinweg vorliegen.

Viele Use Cases sind bei schweizerischen Produktionsfirmen erst am Entstehen. Neue Maschinen liefern typischerweise sehr viel mehr Daten und sehen auch standardisierte Schnittstellen vor. Normal ist aber auch, dass Logistik und Produktion weiterhin Maschinen umfassen, die mehrere Jahrzehnte alt sind. Diese Produktionen lassen sich durch datengetriebenen Retrofit (Retrofit 4.0) aufrüsten, was einen Bruchteil einer neuen Maschine kostet. Neue Anwendungen wie Lyra/Moonstone von unserem Partner GradeSens kommen auf den Markt und vereinfachen den Retrofit 4.0. Trotzdem müssen aber die Daten übergeordnet zusammengeführt werden.

Wir sehen es als richtigen Weg an, die Umsetzungen von Industrie 4.0 Projekte auf der Basis von einzelnen Use Cases auszuführen. Aber was ist richtig? «Bottom up», indem jeder Use-Case separat als technisches Projekt umgesetzt wird, oder ein «Top Down» Ansatz, indem zuerst eine Daten-Gesamtarchitektur aufgebaut wird, auf welcher sich dann alle Use Cases umsetzen lassen. Die Wahrheit liegt wie so oft dazwischen. Ein reiner Top Down Ansatz ist nicht zu empfehlen, da sich Technologie rund um Datenverarbeitung und KI weiterhin rasant entwickelt. Aufwand und Zeit beim Aufsetzen einer Gesamtarchitektur weist ein hohes Verlustrisiko auf. Wir empfehlen die Erstellung eines Big Pictures einer Datenarchitektur die mindestens 4 bis 5 Jahre Bestand hat. Diese Architektur sollte so flexibel gehalten sein, dass sich einzelne Bausteine ohne Komplikationen ersetzen lassen. Auf diesem Big Picture wird dann der erste Use Case umgesetzt und damit Erfahrungen gesammelt. Ein erster Use Case sollte eine kurze Durchlaufzeit von wenigen Monaten haben. Sollten für einen zweiten Use Case Adaptionen notwendig sein, dann sind diese im Allgemeinen nicht kostenintensiv. Die gemeinsame Datenarchitektur mehrerer Use Cases hat so eine gute Basis, hat aber gleichzeitig auch die Möglichkeit zu wachsen.

 

Was macht Daten-Architekturen rund um IIoT und Lakehouses erfolgreich?

Unsere Erfahrung zeigt, dass im industriellen Umfeld viele Firmen einen Best of Breed Ansatz wählen. Manchmal wird auch ein reiner Open Source Ansatz gewünscht. Es gibt auch jene Unternehmungen, die einen einzelnen Produktanbieter also eine Suite wie Microsoft, Google, Amazon, SAP, usw. auserkoren haben und so über Jahre hinweg Software grösstenteils aus einer Hand beziehen. Beide Ansätze «Best of Breed» und «Software Suite» führen schon jahrzehntelang zum Erfolg. Der Best of Breed Ansatz hat den Vorteil, dass die neuesten und besten Entwicklungen am Markt in die Architektur aufgenommen werden, andererseits ist etwas mehr Aufwand bei der Integration der einzelnen Tools vorzusehen. Heutzutage sind jedoch Integrationsprobleme sehr viel kleiner als noch vor vielen Jahren. Beim «Best of Breed» Ansatz ist die Lieferantenbeziehung einfacher, da gewöhnlich von wenigen Ansprechpartnern ausgegangen wird.

Wir setzen bei unseren Umsetzungen stark auf Open Source, trotzdem ist zu berücksichtigen, dass Open Source nicht gleichbedeutend mit «Gratis» ist. «Managed Services» machen Sinn, wobei Open Source bei ausgewachsenen Anbieterlösungen meistens ein Einsteigerangebot bietet. Über die letzten 30 Jahre habe ich auch schon häufiger erlebt, dass besonders grössere Open Source Lösungen mit der Zeit in ein Lizenzmodell wechseln. Dann kann es sogar richtig teuer werden. Also ist etwas Vorsicht bei der Auswahl von Open Source geboten.

Die hier besprochene Architektur der Abb.5 zeigen sowohl den «Best of Breed» Ansatzes als auch im Falle einer Suite den Microsoft Ansatz, der in der Schweiz häufig Anwendung findet. Auch bei Microsoft ist es nicht eine Gesamtlösung, sondern die Kombination unterschiedlichster Software-Services. Zu berücksichtigen ist auch, dass die aufgezeigten Produkte den Stand 2024 widerspiegeln. Auch bei uns als Daten-Umsetzer ist die Produktauswahl mit der Technologieentwicklung mittelfristig im Fluss. Als nächstes einige Kommentare zur Abb.5:

 

Datenarchitektur

Abb.5: Daten-Architektur im industriellen Umfeld mit typischen Software-Vertretern

 

Datenquellen und IIoT

Die Datenquellen auf dem Shopfloor (Produktionsebene) sind die Steuerungen (SPS) und übergeordneten SCADA Systeme. Neue Industriesysteme haben als Schnittstelle standardisiert OPC-UA an welchem diverse Open Source Message Broker (wie bspw. Rabbit MQ) auf der Basis des MQTT-Protokolls problemlos andocken können. Auf der Basis von MQTT lassen sich Daten in Form von Datenpaketen sicher verschicken. Schnittstellen älteren Typs wie Profibus, die Weiterentwicklung Profinet sowie andere Industrieprotokolle können in der Anbindung etwas komplizierter sein. Kommerzielle Plattformen wie bspw. die Schweizer IoT-Plattformanbieter Stemys weisen Konnektoren auf, die auch hier ein Anschliessen einfach machen. Möchte man grosse Datenmengen streamen, dann lässt sich die Open Source Lösung NATS einsetzen – sehr beliebt ist auch Apache KAFKA , besonders bei grösseren Unternehmen. Azure IoT ist ein Produkt, welches dann verwendet wird, wenn eine Firma eine Microsoft-(Cloud)-Strategie verfolgt. Azure IoT kann an OPC-UA andocken, Daten streamen oder Daten als Pakete verschicken.

Wie die Automatisierungspyramide von Abb.3 in Teil 1 zeigt, reichen die Daten vom Shopfloor nicht aus, um OEE oder OPE auszuführen. Die Anbindung von ERP oder weiterer Systeme wie Wartungs-Software oder MES kann via Meltano (open Source ELT) oder im Microsoft Umfeld via Azure Data Factory geschehen. Letzteres bietet auch eine einfache Analytics-Plattform inkl. Daten-Orchestrierung an.

 

Lakehouse

Im zweiten Kapitel von Teil 1 wurde schon ein kurzer Abriss über die von uns verwendeten Lakehouse Anbieter gemacht. Die heutigen Lakehouse Lösungen sind cloudbasierte Gesamtlösungen, die automatisiert skalieren. Das bedeutet, man muss sich um die unterliegende Hardware nicht kümmern und zusätzliche Ressourcen werden nach Belastung der Plattform zu- oder weggeschaltet. Die Cloud-Lösungen bieten auch Hand bei der Automatisierungen der Datenprozesse und in der Erstellung von Datapipelines sowie Datenstrukturen. Die Lösungen weisen darüber hinaus auch Schnittstellen zu Datenvisualisierungstools auf und sind mit diesen fliessend integriert. Die Auswahl der richtigen und einer nachhaltig kostengünstigen Plattformlösung geschieht idealerweise in Workshops auf der Basis zukünftiger Use Cases.

 

Orchestrierung

Lösungen wie Github können nicht nur die Versionierung der Codes steuern, die «Continous Integration» sicherstellen, sondern können heutzutage auch den gesamten Datenaufbereitungs-Prozess steuern. Von uns genutzte Orchestrierungslösung sind beispielsweise die Open Source-Lösung Apache Airflow oder Azure Data Factory, welches innerhalb der Microsoft-Welt integriert ist.

 

Data Transformation und Künstliche Intelligenz

LLMs (Large Language Models) haben die Welt im Jahr 2023 euphorisiert, die Künstliche Intelligenz ist von neuem aufgewacht. Natürlich wird es in den kommenden Jahren auf LLM viele Anwendungen geben, im Bereich Industrie 4.0 werden LLM-Lösungen aber nicht ausreichen.

Neben den LLM bieten Software-Anbieter im Bereich Industrie 4.0 Modellumsetzungen an, die meistens eher generisch aufgesetzt sind. Unsere eigenen Machine Learning Modelle von LeanPredict wenden wir seit bald 10 Jahren an und sind in diesem Bereich projekterprobt. Unsere Modelle sind klein und flexibel und können direkt in die Umsetzung der Industrie 4.0 Anwendungen einbezogen werden. Wir sehen es als Kundenvorteil an, dass wir LeanPredict nicht als Produkt verkaufen, sondern es als Softwarecode in den Projekten für eine schnellere Umsetzung nutzen. Es entsteht damit für Kunden keine Abhängigkeit zu einem weiteren Provider, also auch nicht zur Substring selbst. Die Modelle können sowohl in der Cloud als auch vor Ort als Edge Lösung in der Produktion laufen. Wie Abb. 6 zeigt, haben wir LeanPredict nach Anwendungsfällen in der Produktion strukturiert. Damit können Unternehmen bspw. Qualitätseinbussen am Produkt erkennen oder ein Alarming auf Schäden oder auch Energieproblemen einrichten. LeanPredict ist damit ein Beschleuniger unserer Industrie 4.0 Projekte.

 

LeanPredict Overview

Abb.6: LeanPredict als Komponente der Daten-Architektur

 

Data Visualization

Die Visualisierung und die Datenanalytik sind Schlüsselfaktoren der Daten-Architektur. Damit gute Entscheidungen getroffen werden können, müssen die Daten verständlich und klar visualisiert werden. Ein von uns genutztes Visualisierungs-Tool ist das Open Source Produkt Apache Superset für einfache und schnelle Visualisierungen. Es gibt sehr viele BI Tools am Markt, aber im KMU-Bereich wird in der Schweiz häufig Power BI von Microsoft und Tableau eingesetzt. Deshalb und weil wir in Projekten damit erfolgreich waren, haben wir bei Substring auf diese beiden BI-Tools Kompetenzen aufgebaut.

 

 

 

Somit beenden wir hier unsere Ausführungen zum Thema Daten-Architektur im Umfeld Industrie 4.0, ohne näher auf das wichtige Thema Security eingegangen zu sein. Sehr gerne besprechen wir auch das Thema Security oder all die obigen Themen direkt. Kommen Sie dazu gerne auf uns zu.

 

Laden Sie hier Teil 1 und Teil 2 dieses Artikels als handliches PDF herunter

Marc Tesch
Letzte Artikel von Marc Tesch (Alle anzeigen)