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: MongoDB)

Ob Smart Home, Internet of Things (IoT) oder Autonomes Fahren – jede Branche hat spezifische Begriffe für das jeweilige virtuelle Äquivalent, das bei der Optimierung, Visualisierung, Steuerung oder vorausschauenden Wartung aus IT-Perspektive entsteht. Ein Begriff, der im Bereich IoT derzeit viel diskutiert wird, ist der digitale Zwilling (Digital Twin). In der Praxis ist er jedoch noch nicht wirklich angekommen. 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.

Verschiedene Daten und Datenquellen im digitalen Zwilling vereinen

Relationale Datenbankmodelle besitzen ein striktes Schema und stoßen jedoch aufgrund ihrer Architektur bei sehr großen Datenmengen an ihre Grenzen, flexible Datenmodelle wie das dokumentenorientierte Model ist für Big-Data-Anwendungen ausgelegt und kann im Nachgang einfach angepasst werden.

Relationale Datenbankmodelle besitzen ein striktes Schema und stoßen jedoch aufgrund ihrer Architektur bei sehr großen Datenmengen an ihre Grenzen, flexible Datenmodelle wie das dokumentenorientierte Model ist für Big-Data-Anwendungen ausgelegt und kann im Nachgang einfach angepasst werden. MongoDB

Das Datenvolumen wie auch die integrative Eigenschaft eines digitalen Zwillings, über Abteilungen- und manchmal sogar über 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 bzw. Interoperabilität der Systeme, ist auch immer das Backend zu betrachten. 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 es ist zu definieren, 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 lassen sich die Daten also wertschöpfend aus verschiedenen Systemen extrahieren, interpretieren und vereinheitlichen, die nicht für den Datenaustausch konzipiert wurden?

Eine Schnittstelle mit der nötigen Flexibilität

Zu Beginn sind die unterschiedlichen Daten zu konsolidieren und müssen über eine einheitliche Service- und API-Schnittstelle zugänglich sein 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.

Das flexible Dokumentenmodell von MongoDB eignet sich 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.

MongoDBs digitaler Zwilling hilft automobilhersteller

Ein Anwendungsfall eines führenden deutschen Automobilherstellers verdeutlicht, die Implementierung eines digitalen Zwillings mithilfe von MongoDB: In der sehr kurzen Zeitspanne von nur drei Monaten, im Vergleich zu den normalerweise benötigten ein bis drei 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 vier Millionen Fahrzeuge mit mehr als 500 Millionen Komponenten und über 300 Millionen individuellen Konfigurationskombinationen. Der digitale Zwilling ermöglicht eine höhere Service-Zufriedenheit der Fahrzeuge durch ermöglichte vorausschauende Wartung, aber auch die Entschlackung der Produktion oder wertvolle Prognosen für das Qualitätsmanagement.

Die technische Basis war eine Migration einer relationalen DB2 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.

Vorteile einer einheitlichen Datenplattform beim digitalen Zwilling

Big-Data-Anwendungen wie der digitale Zwilling brauchen einheitliche Datenplattformen, die in der Lage sind, mit der Heterogenität der Daten umzugehen: Lösungen wie MongoDB können mit den verschiedenen Maschinentypen, aber auch genauso gut mit Graph-Daten oder Zeitreihendaten (Times Series) umgehen. 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. Mit MongoDB funktioniert ebenso die isolierte, analytische Nutzung von Daten ETL-frei, also ohne das aufwendige transferieren und transformieren von Daten in zusätzliche Systeme. Ebenso lassen sich global verteilte Datenbanken auf Knopfdruck erstellen.

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 – ebenso 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 geschieht verlangsamt.

Nebeneffekt: Backlogs reduzieren

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 lassen sich Entwickler agiler einsetzen und können bei Engpässen flexibler einspringen und aushelfen. Die Anwendungsentwicklung bleibt dadurch sowohl in der Planung als auch in der Umsetzung generell dynamischer.

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.

Fazit

Der breiten Etablierung des IoT muss 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 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.

Dr. Christian Kurze

Principal Solutions Architect bei MongoDB

(na)

Sie möchten gerne weiterlesen?

Unternehmen

MongoDB

Building Two, Number One Ballsbridge
4 Dublin
Ireland