Digital Twin in der Fertigung: AWS IoT TwinMaker

Warum Digital Twins jetzt relevant sind

Fertigungsunternehmen kämpfen mit einem strukturellen Problem: Die Menge an Produktionsdaten wächst schneller als die Fähigkeit, sie zu verstehen. Sensoren, SPS-Ausgaben, MES-Logs und Qualitätsmessdaten liegen in getrennten Systemen — ohne räumlichen Kontext und ohne Verbindung zum physischen Anlagenzustand. Ein Maschinenbediener sieht Schwingungswerte in einem Dashboard, aber keine Visualisierung, welche Komponente betroffen ist. Ein Instandhalter bekommt einen Alarm, ohne zu wissen, ob das Problem an Linie 3, Spindel 7 oder einem vorgelagerten Aggregat liegt.

Gleichzeitig schärft die EU die regulatorischen Anforderungen: Die Maschinenverordnung (EU) 2023/1230, die ab Januar 2027 verbindlich gilt, fordert digitale Betriebsanleitungen und Risikoanalysen auf Basis aktueller Betriebsdaten. DSGVO-Anforderungen stellen sicher, dass Produktionsdaten, die personenbezogene Informationen enthalten können (z. B. Schichtproduktionsdaten mit Rückschluss auf Personen), datenschutzkonform verarbeitet werden müssen. Digital Twins sind kein Nice-to-have mehr — sie werden zum regulatorischen Compliance-Werkzeug.

AWS IoT TwinMaker, seit 2021 allgemein verfügbar, adressiert dieses Spannungsfeld. Statt eines monolithischen CAE-Systems bietet TwinMaker einen offenen Integrationslayer: bestehende Daten bleiben in ihren Quellsystemen, TwinMaker fügt räumlichen Kontext und eine einheitliche Abfrageebene hinzu. Das Ergebnis ist ein lebender Digitaler Zwilling, der den Ist-Zustand der Fabrik in Echtzeit widerspiegelt.

Begriffsklärung: Digital Twin, Digital Shadow und Co.

Die Begriffe rund um Digital Twins werden in der Industrie häufig unscharf verwendet. Für eine präzise Architekturentscheidung ist die Unterscheidung wichtig:

Digital Model

Ein statisches digitales Abbild eines physischen Objekts — typischerweise ein CAD-Modell oder ein BIM-Modell. Es gibt keinen automatischen Datenaustausch zwischen Modell und physischem Objekt. Änderungen am realen Objekt müssen manuell eingepflegt werden. Digital Models sind der Ausgangspunkt jedes Digital-Twin-Projekts.

Digital Shadow

Ein Digital Shadow empfängt automatisch Daten vom physischen Objekt — beispielsweise Sensordaten oder Zustandsmeldungen — bildet sie aber nur passiv ab. Der Shadow kann den physischen Prozess nicht steuern oder direkt beeinflussen. Typischer Anwendungsfall: Monitoring-Dashboards, die Maschinenzustände visualisieren.

Digital Twin

Ein vollständiger Digital Twin hat einen bidirektionalen Datenaustausch: Er empfängt Zustandsdaten vom physischen Objekt und kann auch Steuerbefehle zurückschicken. Zusätzlich ermöglicht er Simulationen — also Vorhersagen über das Verhalten des physischen Objekts unter veränderten Bedingungen, ohne in den Betrieb einzugreifen. AWS IoT TwinMaker ist darauf ausgelegt, Digital Shadows zunächst einfach umzusetzen und schrittweise zu vollständigen Digital Twins auszubauen.

Entity-Component-Modell

Das Datenmodell, das AWS IoT TwinMaker verwendet, um physische Objekte zu repräsentieren. Eine Entity ist ein digitales Abbild eines physischen Objekts (z. B. eine Pumpe, eine Produktionslinie, eine ganze Fabrik). Eine Component ist eine definierte Datenverbindung zu einer Entität — zum Beispiel eine Verbindung zu AWS IoT SiteWise, einem Timestream-Datensatz oder einer Lambda-Funktion. Mehrere Komponenten können auf eine Entität referenzieren und unterschiedliche Datendimensionen abbilden.

Scene Composer

Das visuelle Frontend von AWS IoT TwinMaker: ein 3D-Viewer auf Basis des Amazon Managed Grafana-Dashboards, in dem 3D-Modelle (im Format glTF/GLB) mit Entitäten und deren Echtzeitdaten verknüpft werden. Operatoren sehen so nicht nur Zahlenwerte, sondern können im räumlichen Modell navigieren, auf einzelne Komponenten klicken und sofort die zugehörigen Sensordaten abrufen.

AWS IoT TwinMaker Architektur im Überblick

AWS IoT TwinMaker ist kein monolithisches System, sondern ein Integrationslayer mit klar definierten Schnittstellen. Die Kernarchitektur besteht aus drei Ebenen:

Ein zentrales Designprinzip: TwinMaker kopiert keine Daten. Die Rohdaten bleiben in ihren Quellsystemen (IoT SiteWise, Timestream, S3). TwinMaker fügt eine semantische Abfrageebene darüber — den Knowledge Graph — der beschreibt, welche Entität mit welchen Datenquellen verbunden ist und wie Entitäten miteinander in Beziehung stehen (z. B. Pumpe ist Teil von Kühlkreislauf, der Teil von Produktionslinie 2 ist). Diese Trennung macht TwinMaker besonders für Brownfield-Umgebungen geeignet, wo Daten schon in verschiedenen Systemen vorhanden sind.

TwinMaker Workspace und Knowledge Graph

Jeder TwinMaker-Workspace hat einen eingebetteten Knowledge Graph (basierend auf AWS IoT TwinMaker's eigenem Graph-Service). Dieser Graph speichert Entitäten, ihre Eigenschaften und ihre Beziehungen zueinander. Abfragen über den Knowledge Graph erlauben es, kontextübergreifende Fragen zu beantworten: „Welche Pumpen auf Produktionslinie 3 haben in den letzten 24 Stunden eine Temperatur über 85°C gezeigt?" — auch wenn die Temperaturdaten aus SiteWise und die Linienzuordnung aus dem MES-System kommen.

Konnektoren: Datenquellen anbinden ohne Copy

TwinMaker nutzt typisierte Konnektoren, um Komponenten mit Datensystemen zu verbinden. AWS liefert native Konnektoren für AWS IoT SiteWise und Amazon Timestream. Für alle anderen Quellen (SCADA, MES, REST-APIs) werden Lambda-basierte Custom Connectors implementiert — kleine Lambda-Funktionen, die TwinMaker bei Datenabruf aufruft und die Daten in einem standardisierten Format zurückgeben. Diese Architektur erlaubt es, buchstäblich jede Datenquelle anzubinden, die über eine API erreichbar ist.

Datenquellen anbinden: SCADA, MES und CAD

Ein Digital-Twin-Projekt in der Fertigung steht und fällt mit der Qualität der Datenintegration. Die häufigsten Quellsysteme und ihre Anbindungsstrategie auf AWS:

SCADA-Systeme

SCADA-Systeme (z. B. Siemens SIMATIC WinCC, Wonderware, Ignition) sind oft die primäre Quelle für Prozesswerte aus der Produktionslinie. Die bevorzugte Integrationsroute führt über AWS IoT SiteWise: Der SiteWise Edge Gateway kommuniziert per OPC-UA mit dem SCADA-OPC-UA-Server, normalisiert Zeitreihenwerte in das SiteWise Asset-Modell und synchronisiert sie in die Cloud. TwinMaker greift per IoT-SiteWise-Konnektor auf diese strukturierten Daten zu.

Für Legacy-SCADA-Systeme ohne OPC-UA-Unterstützung kann AWS IoT Greengrass mit einem Modbus- oder Profinet-Adapter als Protokollübersetzer eingesetzt werden, bevor Daten in IoT Core und dann in SiteWise fließen.

MES-Systeme

Manufacturing Execution Systems (z. B. SAP ME, Siemens OPCENTER, Tulip) halten Produktionsaufträge, Stückzahlen, Ausschussraten und Schichtdaten. Diese Daten haben typischerweise eine andere Granularität als Sensordaten — Ereignisse statt Zeitreihen. Die Anbindung erfolgt über einen Lambda Custom Connector, der die MES-REST-API abfragt und die Daten in TwinMaker-Properties übersetzt. Alternativ können MES-Events über Amazon EventBridge und eine Lambda-Funktion in Amazon Timestream geschrieben und dann per Timestream-Konnektor in TwinMaker abgefragt werden.

CAD-Modelle und 3D-Szenen

Der Scene Composer von TwinMaker benötigt 3D-Modelle im Format glTF 2.0 / GLB. Typische Quellen sind:

• CAD-Export: Solidworks, CATIA, PTC Creo und Siemens NX können über den JT-Zwischenformat-Workflow in glTF konvertiert werden. Tools wie Autodesk Forge oder Pixyz Studio automatisieren diesen Prozess.
• BIM-Modelle: Für Gebäude und Anlageninfrastruktur eignen sich IFC-zu-glTF-Konverter (z. B. via IfcOpenShell).
• 3D-Scans: Photogrammetrie-Scans (z. B. via Matterport) können in glTF exportiert werden — besonders hilfreich für Bestandsanlagen ohne digitale Pläne.

Die glTF-Dateien werden in Amazon S3 hochgeladen. Der Scene Composer lädt sie von dort und verknüpft einzelne 3D-Objekte per Klick mit TwinMaker-Entitäten.

Phasierter Aufbauplan: Digital Twin in drei Phasen

Ein realistischer Aufbauplan vermeidet den häufigen Fehler, sofort die gesamte Fabrik digitalisieren zu wollen. Storm Reply empfiehlt drei Phasen, die jeweils eigenständigen Mehrwert liefern:

1. Phase 1 — Digital Shadow (4–8 Wochen): Pilotprojekt mit einer einzelnen Produktionslinie oder einem kritischen Asset (z. B. eine Kernmaschine). Ziel: AWS IoT SiteWise mit 20–50 Messpunkten anbinden, erstes TwinMaker Workspace aufsetzen, einfaches 3D-Modell im Scene Composer verknüpfen, Grafana-Dashboard für Bediener aufbauen. Ergebnis: Operatoren sehen den Anlagenzustand erstmals in räumlichem Kontext. ROI: Reduzierte Diagnosezeit bei Störungen (typisch 20–40 % weniger Time-to-Diagnose).
2. Phase 2 — Multi-Asset Twin (8–16 Wochen): Ausweitung auf mehrere Linien und Maschinen. MES-Integration für Auftragsdaten und OEE-Berechnung. Alerting-Regeln im Knowledge Graph (z. B. kaskadierte Alarme: „wenn Pumpe A Alarm, dann auch Linie B überwachen"). Einführung von Anomalieerkennung mit Amazon Lookout for Equipment oder SageMaker Canvas auf SiteWise-Daten. Ergebnis: Proaktive Instandhaltung statt reaktiver Reaktion auf Störungen. ROI: Typische Reduktion ungeplanter Stillstände um 15–30 %.
3. Phase 3 — Simulation und Was-Wäre-Wenn (12–24 Wochen): Aufbau von Simulations-Konnektoren — entweder über AWS SimSpace Weaver (für komplexe physikalische Simulationen) oder über externe Simulationstools (MATLAB Simulink, ANSYS), die per Lambda-Connector eingebunden werden. Ziel: Parameteränderungen virtuell testen (z. B. „Was passiert mit dem Energieverbrauch, wenn wir die Taktrate um 10 % erhöhen?"), bevor sie in der Produktion umgesetzt werden. Ergebnis: Vollständiger Digital Twin mit bidirektionalem Austausch. ROI: Optimierungspotenziale heben ohne Produktionsrisiko.

ROI und Kostenstruktur

Digital-Twin-Projekte sind Investitionen mit messbarem Return. Die relevanten Hebel in der Fertigung:

AWS-Betriebskosten (Orientierungswerte)

Die AWS-Kosten für einen Digital Twin setzen sich zusammen aus:

• AWS IoT SiteWise: Ca. 0,10–0,30 USD pro Asset-Property pro Monat, plus Datenaufnahme pro Nachricht. Eine Anlage mit 200 Messpunkten kostet typischerweise 200–600 USD/Monat.
• AWS IoT TwinMaker: Workspace-Gebühr (10 USD/Monat) plus Entitäten (0,04 USD/Entität/Monat) plus Knowledge-Graph-Anfragen. Bei 500 Entitäten ca. 30–80 USD/Monat für TwinMaker selbst.
• Amazon Managed Grafana: Ca. 9 USD/Editor/Monat, Viewer kostenfrei.
• Amazon S3 und AWS Glue: Abhängig von Datenmenge; typisch unter 100 USD/Monat für eine mittelgroße Anlage.

Gesamtbetriebskosten für Phase 1 (ein Asset, 50 Messpunkte): ca. 500–1.500 USD/Monat. Für eine vollständige Produktionslinie (Phase 2, 300 Messpunkte, 200 Entitäten): ca. 2.000–5.000 USD/Monat. Diese Kosten stehen einem typischen Stundensatz für ungeplante Maschinenstillstände von 5.000–50.000 EUR gegenüber.

Storm Reply Perspektive

Storm Reply ist AWS Premier Consulting Partner mit Spezialisierung auf Industrial IoT und Cloud-native Fertigung. Unsere Erfahrung aus mehreren Digital-Twin-Projekten im DACH-Fertigungssektor zeigt: Der größte Stolperstein ist nicht die Technologie, sondern die Datenstrategie.

Viele Projekte starten mit dem Anspruch, sofort die gesamte Fabrik zu modellieren — und scheitern dann an der Komplexität der Datenquellen. Unser Ansatz: Wir beginnen mit einem Discovery Workshop (2 Tage), in dem wir gemeinsam mit dem Kunden die 3–5 kritischsten Assets identifizieren, die Datenquellen kartieren und eine realistische Architektur skizzieren. Auf dieser Basis erstellen wir einen Festpreis-PoC für Phase 1, der in 6 Wochen messbare Ergebnisse liefert.

Besonders wichtig im deutschen Fertigungskontext: Datenhaltung. AWS Region Frankfurt (eu-central-1) stellt sicher, dass alle Produktionsdaten den EU-Datenschutzanforderungen und der DSGVO entsprechen. Für Unternehmen mit besonderen Anforderungen an lokale Datenhaltung integrieren wir AWS Outposts, sodass sensitive Produktionsdaten die Fabrikhalle nie verlassen müssen.

Regulatorische Anforderungen: Maschinenverordnung und DSGVO

Zwei regulatorische Rahmenwerke sind für Digital-Twin-Projekte in der deutschen Fertigung besonders relevant:

Maschinenverordnung (EU) 2023/1230

Die Maschinenverordnung, die die bisherige Maschinenrichtlinie 2006/42/EG ersetzt und ab Januar 2027 gilt, enthält erstmals Anforderungen an digitale Dokumentation und digitale Anweisungen. Artikel 10 der Verordnung erlaubt digitale Betriebsanleitungen — und macht sie unter bestimmten Bedingungen zur Anforderung. Digital Twins können als zentrales Repository für maschinenspezifische Betriebsdaten, Wartungshistorien und Risikoanalysen dienen und damit die Compliance-Anforderungen der Verordnung unterstützen.

Darüber hinaus fordert die Maschinenverordnung für bestimmte Hochrisiko-Maschinen (Annex I) eine technische Dokumentation auf Basis aktueller Betriebsdaten. Ein Digital Twin, der Betriebsparameter historisch aufzeichnet und visualisiert, kann als Evidenzbasis für diese Anforderung dienen.

DSGVO in der Produktionsumgebung

Produktionsdaten können personenbezogen sein, wenn sie Rückschlüsse auf einzelne Mitarbeiter erlauben — zum Beispiel Schichtleistungsdaten, Bediener-Logins an Maschinen oder Qualitätsdaten, die einer Person zugeordnet werden können. Für die Digital-Twin-Architektur bedeutet das:

• Datensparsamkeit: Nur die Messpunkte erfassen, die für den Zweck notwendig sind. TwinMaker-Properties sollten keine personenbezogenen Attribute ohne Rechtsgrundlage enthalten.
• Zugriffssteuerung: AWS IAM und TwinMaker ermöglichen feingranulare Zugriffsrechte auf Workspace-Ebene, Entitäts-Ebene und Property-Ebene. Schichtdaten können auf Vorgesetzte beschränkt werden.
• Datenresidenz: Alle TwinMaker-Workspaces, SiteWise-Assets und S3-Buckets in der AWS-Region Frankfurt (eu-central-1) stellen sicher, dass Daten die EU nicht verlassen.
• Löschkonzept: S3-Lifecycle-Policies für Rohdaten, SiteWise-Retention-Policies und ein dokumentiertes Datenlöschkonzept nach Art. 17 DSGVO sind einzuplanen.

Vorteile und Herausforderungen im Überblick

Vorteile von AWS IoT TwinMaker in der Fertigung

• Kein Daten-Copy: TwinMaker greift auf Daten in bestehenden Systemen zu — keine aufwändige Datenmigration erforderlich.
• Offenes Ökosystem: Lambda Custom Connectors erlauben die Anbindung beliebiger Datenquellen, unabhängig von Hersteller oder Protokoll.
• Inkrementeller Aufbau: Phase 1 liefert sofort Mehrwert — der vollständige Digital Twin wächst organisch.
• Native AWS-Integration: Direkte Anbindung an SageMaker (ML), Lookout for Equipment (Anomalieerkennung), QuickSight (Reporting) und Step Functions (Prozessautomatisierung).
• Grafana-basierte Visualisierung: Amazon Managed Grafana ist ein bekanntes Open-Source-Tool — geringer Schulungsaufwand für Bediener.

Herausforderungen und Gegenmassnahmen

• Datenverfügbarkeit: Wenn Sensordaten fehlen oder unzuverlässig sind, nützt der beste Twin nichts. Lösung: Datenqualitäts-Assessment vor Projektstart, Investition in Edge-Gateways und Sensor-Upgrades parallel.
• 3D-Modell-Aufwand: CAD-zu-glTF-Konvertierungen sind zeitaufwändig, besonders für Altanlagen ohne digitale Pläne. Lösung: 3D-Scans (Photogrammetrie) als schnelle Alternative, iterativer Aufbau der Szene.
• Organisatorische Akzeptanz: Bediener und Instandhalter müssen das neue Dashboard nutzen wollen. Lösung: Frühe Einbindung der Nutzer, Schulungen, UX-fokussiertes Dashboard-Design.
• Datenschutz bei Schichtdaten: Betriebsrat-Einbindung und DSGVO-Prüfung vor Erfassung personenbezogener Produktionsdaten. Lösung: Datenschutz-Folgenabschätzung (DSFA) nach Art. 35 DSGVO als Projektbestandteil.

Häufig gestellte Fragen (FAQ)

Was ist ein Digital Twin in der Fertigung?

Ein Digital Twin ist ein digitales Abbild einer physischen Anlage, Produktionslinie oder Fabrik, das in Echtzeit mit Live-Sensordaten aktualisiert wird. Im Gegensatz zu statischen CAD-Modellen oder Simulationen bildet der Digital Twin den aktuellen Betriebszustand ab und ermöglicht Analysen, Simulationen und Optimierungen ohne Eingriff in die laufende Produktion.

Wie unterscheidet sich AWS IoT TwinMaker von AWS IoT SiteWise?

AWS IoT SiteWise sammelt und strukturiert Industriezeitreihendaten als Asset-Hierarchie. AWS IoT TwinMaker baut darauf auf und fügt eine räumliche 3D-Ebene hinzu: Entitäten und Komponenten werden mit visuellen Szenen (Grafana-basierte Scene Composer-Ansichten) verknüpft. TwinMaker ist der Visualisierungs- und Integrationslayer, SiteWise die historische Datenbasis.

Welche Datenquellen kann AWS IoT TwinMaker anbinden?

AWS IoT TwinMaker verbindet sich über Konnektoren mit AWS IoT SiteWise (OPC-UA-Daten), Amazon Timestream (Zeitreihendaten), AWS IoT Core, relationalen Datenbanken (via AWS Glue) sowie beliebigen REST-APIs und Lambda-Funktionen. SCADA-Systeme, MES-Plattformen und CAD-Quellen lassen sich über Custom Components integrieren.

Was kostet ein Digital-Twin-Projekt mit AWS IoT TwinMaker?

AWS IoT TwinMaker berechnet nach verarbeiteten Daten und abgefragten Zeitreihenwerten. Ein Pilotprojekt für eine einzelne Produktionslinie ist typischerweise für 3.000–15.000 EUR/Monat an AWS-Betriebskosten umsetzbar. Hinzu kommen einmalige Implementierungskosten für die Modellierung, den 3D-Szenenaufbau und die Datenintegration, die Storm Reply in einem Festpreis-Workshop einschätzt.

Weiterführende Quellen

• AWS IoT TwinMaker — Offizielle Dokumentation
• AWS IoT SiteWise — Offizielle Dokumentation
• Getting Started with AWS IoT TwinMaker (AWS Blog)
• Maschinenverordnung (EU) 2023/1230 — EUR-Lex
• Industry 4.0: OT/IT-Stack auf AWS modernisieren — Cloud Fertigung