Suchen

Digital Twins Digitaler Zwilling: weg von Proof of Concepts – hin zum breiten Rollout

Autor / Redakteur: Dr. Christian Kurze* / Sebastian Human

Der digitale Zwilling hat großes Potenzial für industrielle Anwendungen. Von einem breiten Einsatz kann trotzdem noch keine Rede sein. Warum ist das so und wie kann sich das ändern?

Firmen zum Thema

Eine einheitliche Datenplattform hilft ganz enorm beim Einsatz des digitalen Doppelgängers.
Eine einheitliche Datenplattform hilft ganz enorm beim Einsatz des digitalen Doppelgängers.
(Bild: gemeinfrei / Pixabay )

Ein Begriff, der im Bereich IoT derzeit viel diskutiert wird, ist der digitale Zwilling (Digital Twin). In der Theorie scheint dieser Zwilling das digitale Allheilmittel für ein wettbewerbsfähiges Unternehmen mit zukunftsweisenden Produkten zu sein. Wenn dies aber so ist, stellt sich die Frage, warum der digitale Zwilling bis dato in der Praxis noch keine breitere Anwendung gefunden hat. Zwar scheinen – laut einer Studie von Gartner - immer mehr Unternehmen den digitalen Zwilling mit einbeziehen zu wollen, aber in der Realität gilt es einige Herausforderungen zu nehmen.

Zahlreiche verschiedene Daten und Datenquellen vereinen

Das Datenvolumen wie auch die integrative Eigenschaft eines digitalen Zwillings, über Abteilungen und manchmal sogar vertikale Bereiche hinweg zu arbeiten, bringen Herausforderungen mit sich – insbesondere die Heterogenität der Daten und Datenquellen ist hier zu nennen. Denn jede Phase des physischen Produktlebenszyklus kann verschiedenen Abteilungen zugeordnet werden, wodurch unterschiedliche Arten von Daten entstehen, die in der Regel aus nicht-kompatiblen Systemen stammen. Erschwerend kommt hinzu, dass all diese Abteilungen unterschiedliche Standards in Bezug auf das Datenmanagement haben. So schaffen es nur 30 Prozent der relevanten IoT-Projekte laut McKinsey in die Produktion und zum unternehmensweiten Rollout. Ein Grund hierfür liegt oft darin, dass gängige Technologie-Stacks nicht für den Aufbau einer IoT-Lösung geeignet sind.

Operation Technology und Information Technology zusammenführen

Im industriellen Umfeld ergibt sich zudem eine organisatorische Mammutaufgabe, denn die Unterschiede der Operational Technology (OT) im Vergleich zu der Informationstechnologie (IT) kommen einmal mehr durch Projekte wie das (Industrial) IoT ans Licht.

Gerade die OT hat in der Vergangenheit viele unterschiedliche Standards etabliert. Außerdem arbeiten die Teams der OT und IT recht asynchron: Während die OT und die dazugehörige Hardware sich an den Maschinenzyklen orientieren, arbeitet die IT in Iterationszyklen, die deutlich kürzere - beispielsweise vierzehntägige - Sprints beinhalten.

Da der digitale Zwilling auf die Maschinen- und Sensordaten der OT angewiesen ist, muss er somit den Bogen zwischen OT und IT spannen.

IoT-Projekte (Ende)-zu-Ende denken

Beim Stichwort Heterogenität beziehungsweise Interoperabilität der Systeme, muss auch immer das Backend betrachtet werden.

Denn die unterschiedlichen Datensätze, das Zusammenspiel zwischen OT und IT, sowie die benötigte Flexibilität neu aufgesetzter Projekte lassen relationale Datenbankmodelle schnell an ihre Grenzen stoßen.

Bei der Nutzung klassischer relationaler Datenbanken, muss beispielsweise für jeden der Sensoren anfangs eine Modellierung erfolgen und definiert werden, wie das Datenmodell in der IT abgebildet werden soll. Häufig entstehen dadurch extrem lange Prozesse und eine Vielzahl arbeits- und zeitintensiver Proof of Concepts (POCs). Ein POC mag für ein exemplarisches Problem gut anwendbar sein, doch wenn es auf die gesamte Produktion oder auf die weltweiten Werkshallen ausgerollt werden soll, ist die Skalierung einfach zu groß.

Wie können die Daten also wertschöpfend aus verschiedenen Systemen extrahiert, interpretiert und vereinheitlicht werden, die nicht für den Datenaustausch konzipiert wurden?

Eine Schnittstelle mit der nötigen Flexibilität

Zu Beginn müssen die unterschiedlichen Daten konsolidiert und über eine einheitliche Service- und API-Schnittstelle zugänglich gemacht werden, um:

  • die Informationen zu visualisieren,
  • eine Grundlage für Machine Learning und Analytics zu bieten,
  • Aktionen am physischen Asset auszulösen, und
  • die Verfügbarkeit für weitere Informationssysteme, wie ERP, MES und CRM sicherzustellen.

IoT-Projekte beginnen in der Regel mit einem Pilotprojekt, das sich nur auf einige grundlegende Eigenschaften physischer Objekte konzentriert. Wenn diese Attribute abgebildet werden, ist ihre Aufzählung in einer simplen Liste möglich und in einer herkömmlichen Tabelle gut darstellbar. Wenn die Bedürfnisse und Komplexität aber steigen, beispielsweise, wenn neue Sensoren und Geräte hinzugefügt werden, sind verschiedene Eigenschaften und Schemata erforderlich.

Relationale Datenbankmodelle besitzen ein striktes Schema, stoßen jedoch aufgrund ihrer Architektur bei sehr großen Datenmengen an ihre Grenzen. Flexible Datenmodelle wie das dokumentenorientierte Model sind für Big-Data-Anwendungen ausgelegt und können im Nachgang einfach angepasst werden.
Relationale Datenbankmodelle besitzen ein striktes Schema, stoßen jedoch aufgrund ihrer Architektur bei sehr großen Datenmengen an ihre Grenzen. Flexible Datenmodelle wie das dokumentenorientierte Model sind für Big-Data-Anwendungen ausgelegt und können im Nachgang einfach angepasst werden.
(Bild: Mongo DB)

Ein flexibles Dokumentenmodell eignet sich gut für IoT-Daten, da es auf JSON basiert, wodurch die Attribute und Ereignisse der Objekte einfach definiert und gruppiert werden können. Während die Daten in relationalen Datenbanken auf mehrere Tabellen verteilt werden müssen, werden alle Informationen für ein bestimmtes Asset in einem JSON-Dokument dargestellt.

Experten-Tipp: Mehrere Eisen im Feuer

Es ist hilfreich, eine Roadmap des Projekts mit kurzen Entwicklungszyklen sowie einem iterativen Entwicklungsansatz aufzusetzen. Angelehnt an Lean-Start-up-Methoden, müssen sich Unternehmen trauen, eine solide Basis für viele kleinere Projekte aufzubauen. Interessierte Unternehmen müssen mit einer Bandbreite an Ideen experimentieren, um so schnell die Ideen mit dem höchsten Potenzial zu identifizieren und umzusetzen. Eine technische Basis auf erprobter Technologie ist dabei unerlässlich.

Vorteile einer einheitlichen Datenplattform

Big-Data-Anwendungen wie der digitale Zwilling brauchen einheitliche Datenplattformen, die in der Lage sind, mit der Heterogenität der Daten umzugehen: Sie müssen mit den verschiedenen Maschinentypen, aber auch genauso gut mit Graph-Daten oder Zeitreihendaten (Times Series) umgehen können. Vorteilhaft ist dabei insbesondere, dass man keine aufwendigen und langen Entwicklungs- und Modellierungsprozesse benötigt.

Weiterhin stehen out-of-the-box Mechanismen zur Hochverfügbarkeit und horizontalen Skalierbarkeit bereit – beginnend bei wenigen Sensoren im Piloten bis hin zu Tausenden oder Millionen von Devices.

Ein wesentlicher Vorteil einer einheitlichen Plattform ist zudem, dass nur noch eine Technologie erlernt werden muss, die nah an der Produktion, also an der Edge, im Data Center sowie in der Public Cloud funktioniert - und auf mobilen Geräten. In der Praxis sind oft eine Handvoll verschiedener Datenbank-Technologien im Einsatz. Diese müssen alle erlernt und betrieben werden - von der Skalierung der Datenbanken ganz abgesehen. Dies führt zu sehr aufwendigen IT-Strukturen. Das Ergebnis: Die Entwicklung neuer innovativer Funktionen und IT-Projekte wie IoT-Anwendungen werden verlangsamt.

Nebeneffekt: Backlogs reduzieren

Referenzarchitektur einer Datenplattform wie MongoDB: Eine einheitliche Datenplattform funktioniert idealerweise über die Edge-Geräte, im Datencenter, in der Public Cloud sowie auf mobilen Geräten.
Referenzarchitektur einer Datenplattform wie MongoDB: Eine einheitliche Datenplattform funktioniert idealerweise über die Edge-Geräte, im Datencenter, in der Public Cloud sowie auf mobilen Geräten.
(Bild: Mongo DB)

Eine einheitliche Technologie verhindert die Bildung eines Feature-Rückstaus: Unternehmen, die mit unterschiedlichen Datenbanken arbeiten, haben öfter das Problem, nicht schnell genug zu entwickeln. Dank einer einheitlichen Technologie können Entwickler agiler eingesetzt werden und bei Engpässen flexibler einspringen und aushelfen. Die Anwendungsentwicklung bleibt dadurch sowohl in der Planung als auch in der Umsetzung generell dynamischer.

Fazit

Dem Thema IoT wird eine große Zukunft vorausgesagt. Dem muss allerdings ein performantes Datenbank-Setup vorangehen. Der erste Schritt hierbei ist die Wahl einer einheitlichen Lösung für das heterogene Umfeld der Industrie-Daten, denn die Umsetzung und der Betrieb eines digitalen Zwillings wird dadurch enorm vereinfacht.

Doch auch die richtige Strategie und Technologie sollte im Vorfeld gut geplant sein und das Business-Ziel des IoT-Projektes muss im Auge behalten werden. Beabsichtigt man zum Beispiel eine Serviceoptimierung, eine bessere Produktverfügbarkeit, neue IoT-basierte Produkte und Services wie Echtzeit-Apps oder etwa die Prozessoptimierungen entlang der Wertschöpfungskette?

Ohne klares Ziel und ohne die Top-Down-Planung verfehlen viele Initiativen ihr Rollout. Ist das Backend oder das Management nicht auf eine Technologieanwendung wie den digitalen Zwilling ausgerichtet, so können später kostspielige und ressourcenaufwendige Anpassungen anstehen – oder mindestens genauso schlimm, der Proof of Concept bleibt auf der Strecke.

Ein Beispiel aus dem Bereich der Automobilbranche

Ein Anwendungsfall eines führenden deutschen Automobilherstellers verdeutlicht, die Implementierung eines digitalen Zwillings mithilfe von Mongo DB:
In der sehr kurzen Zeitspanne von nur 3 Monaten, im Vergleich zu den normalerweise benötigten 1-3 Jahren, war es möglich, eine Digital Twin-Plattform für Autoteile und die dazugehörige Ausstattung neu aufzusetzen. Alle Bauteile und Ausstattungsmerkmale aus jahrzehntelanger Firmenhistorie wurden in einem digitalen Zwilling abgebildet. Das sind fast 4 Millionen Fahrzeuge mit mehr als 500 Millionen Komponenten und über 300 Millionen individuellen Konfigurationskombinationen. Der digitale Zwilling ermöglicht eine höhere Service-Zufriedenheit durch vorausschauende Wartung, aber auch die Entschlackung der Produktion sowie wertvolle Prognosen für das Qualitätsmanagement.

Die technische Basis war eine Migration einer relationalen Datenbank zu MongoDB Atlas, dem globalen Cloud-Datenbankdienst. Für den Cloud-Einsatz musste zunächst ein sauberes Betriebsmodell aufgesetzt werden. Insgesamt hat das MongoDB-Team dabei geholfen, 18 verschiedene IT-Prozesse zu vereinfachen und anzupassen.

Ein weiterer digitaler Zwilling, der ebenfalls auf der Mongo DB Datenplattform betrieben wird, wurde für die Sparte der Elektroautos realisiert.

* Dr. Christian Kurze ist Experte für Datenmanagement und Datenintegration und arbeitet als Principal Solutions Architect bei MongoDB.

(ID:46943325)