Digitaler Zwilling auf Kubernetes: Simulation und Wartung

TL;DR

• Ein Digital Twin ist eine virtuelle Repraesentation einer physischen Anlage, die in Echtzeit mit Sensordaten synchronisiert wird. Kubernetes liefert die Laufzeitumgebung fuer diese Simulations-Workloads.
• StatefulSets eignen sich fuer persistente Twin-Instanzen, weil jeder Zwilling einen stabilen Zustand und eine eigene Identitaet benoetigt.
• MQTT und OPC-UA verbinden physische Anlagen mit ihren digitalen Zwillingen. Ein Sidecar-Container pro Twin uebernimmt die Protokolluebersetzung.
• GPU-beschleunigte Simulations-Container (FEM, CFD, Physik-Engines) skalieren ueber Kubernetes HPA basierend auf der Anzahl aktiver Simulationen.
• Predictive Maintenance mit Digital Twins senkt ungeplante Stillstaende, weil Verschleissszenarien virtuell durchgespielt werden, bevor sie real eintreten.

Was ist ein Digital Twin

Ein digitaler Zwilling ist mehr als ein 3D-Modell. Es ist eine Software-Repraesentation einer physischen Anlage, die drei Eigenschaften hat:

Echtzeit-Synchronisation. Sensordaten aus der realen Anlage fliessen kontinuierlich in das digitale Modell. Temperatur, Vibration, Drehzahl, Durchfluss -- alles, was messbar ist, wird im Zwilling abgebildet.

Simulationsfaehigkeit. Der Zwilling kann Szenarien durchspielen, die in der realen Anlage nicht getestet werden koennen: Was passiert bei 120 Prozent Auslastung? Wie veraendert sich der Verschleiss bei hoeheren Temperaturen? Wann faellt das Lager aus?

Bidirektionale Kommunikation. Im fortgeschrittenen Stadium kann der Zwilling nicht nur Daten empfangen, sondern auch Steuerungsbefehle an die reale Anlage zuruecksenden (Closed-Loop). Das erfordert allerdings hohe Sicherheitsanforderungen und ist in der Praxis noch selten.

Fuer Fertigungsunternehmen im Mittelstand sind die haeufigsten Use Cases: Predictive Maintenance (Verschleissvorhersage), Prozessoptimierung (Parameter-Tuning ohne Produktionsunterbrechung) und Inbetriebnahme-Simulation (neue Anlagen virtuell testen, bevor sie physisch aufgebaut werden).

Warum Kubernetes fuer Digital Twins

Digital Twins stellen spezifische Anforderungen an die Infrastruktur, die Kubernetes gut abdeckt.

Ein mittelstaendisches Werk mit 50 Maschinen braucht potenziell 50 Digital Twins. Ohne Kubernetes bedeutet das 50 manuelle Server-Konfigurationen. Mit Kubernetes ist es ein StatefulSet mit 50 Replicas.

Architektur: Twin-Plattform auf Kubernetes

Die Architektur einer Digital-Twin-Plattform besteht aus vier Schichten:

Datenerfassung (Edge). OPC-UA-Adapter und MQTT-Publisher auf Edge-Nodes erfassen Sensordaten direkt an der Maschine. Diese Daten fliessen ueber MQTT an den zentralen Cluster. Mehr zur Edge-Architektur unter Kubernetes Edge Computing.

Daten-Ingestion (Cluster). Ein MQTT-Broker (EMQX) empfaengt die Daten. Ein Stream-Processing-Service (z.B. auf Basis von Apache Flink oder einem einfachen Python-Consumer) routet die Daten an die richtigen Twin-Instanzen und schreibt Zeitreihen in TimescaleDB.

Twin-Runtime (Cluster). Jeder Digital Twin laeuft als Pod in einem StatefulSet. Er empfaengt Echtzeit-Daten ueber MQTT, aktualisiert seinen internen Zustand und fuehrt Simulationen durch. Bei rechenintensiven Simulationen (FEM, CFD) werden separate GPU-Pods gestartet.

Visualisierung und API (Cluster). Grafana-Dashboards zeigen den Zustand aller Twins. Eine REST-API erlaubt externen Systemen (MES, ERP) den Zugriff auf Twin-Daten und Simulationsergebnisse.

StatefulSet fuer persistente Twin-Instanzen

Jeder Digital Twin braucht eine stabile Identitaet und persistenten Speicher. Ein Deployment mit zufaelligen Pod-Namen ist ungeeignet, weil MQTT-Subscriptions und Datenbank-Zuordnungen an den Twin-Namen gekoppelt sind.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: machine-twin
  namespace: digital-twins
  labels:
    app: machine-twin
spec:
  serviceName: machine-twin-headless
  replicas: 10
  podManagementPolicy: Parallel
  selector:
    matchLabels:
      app: machine-twin
  template:
    metadata:
      labels:
        app: machine-twin
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "9090"
    spec:
      containers:
      - name: twin-engine
        image: registry.internal/twins/twin-engine:3.2.0
        ports:
        - containerPort: 8080
          name: http-api
        - containerPort: 9090
          name: metrics
        env:
        - name: TWIN_ID
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: MQTT_BROKER
          value: "tcp://emqx.messaging.svc.cluster.local:1883"
        - name: MQTT_TOPIC
          value: "factory/machines/$(TWIN_ID)/#"
        - name: TIMESCALEDB_URL
          value: "postgresql://tsdb.databases.svc.cluster.local:5432/twins"
        - name: SIMULATION_MODE
          value: "realtime"
        resources:
          requests:
            cpu: "500m"
            memory: "1Gi"
          limits:
            cpu: "2"
            memory: "4Gi"
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 30
        volumeMounts:
        - name: twin-state
          mountPath: /data/state
        - name: twin-config
          mountPath: /config
          readOnly: true
      volumes:
      - name: twin-config
        configMap:
          name: twin-configurations
  volumeClaimTemplates:
  - metadata:
      name: twin-state
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: local-path
      resources:
        requests:
          storage: 5Gi
---
apiVersion: v1
kind: Service
metadata:
  name: machine-twin-headless
  namespace: digital-twins
spec:
  clusterIP: None
  selector:
    app: machine-twin
  ports:
  - port: 8080
    name: http-api
  - port: 9090
    name: metrics

Zentrale Design-Entscheidungen:

TWIN_ID aus metadata.name. Jeder Pod im StatefulSet hat einen stabilen Namen (machine-twin-0, machine-twin-1, ...). Dieser Name wird als Twin-ID genutzt und bestimmt, welche MQTT-Topics der Twin abonniert. Pod machine-twin-3 hoert auf factory/machines/machine-twin-3/#.

podManagementPolicy: Parallel. Alle Twins starten gleichzeitig, nicht sequenziell. Bei 50 Twins spart das Minuten beim Cluster-Start.

Separater State-Speicher. Jeder Twin hat ein eigenes PersistentVolume fuer seinen Zustand. Bei einem Pod-Neustart bleibt der letzte bekannte Zustand erhalten, und der Twin muss nicht alle historischen Daten erneut verarbeiten. Details zu Storage-Optionen unter Kubernetes Storage.

Echtzeit-Datensynchronisation ueber MQTT

Die Verbindung zwischen physischer Anlage und Digital Twin laeuft ueber MQTT. Jede Maschine publiziert ihre Sensordaten auf einem definierten Topic-Baum:

# Topic-Struktur fuer Maschinendaten
# factory/machines/{twin-id}/sensors/{sensor-type}

# Beispiel: Temperatur-Sensor an Maschine 3
mosquitto_pub -h emqx.messaging.svc.cluster.local \
  -t "factory/machines/machine-twin-3/sensors/temperature" \
  -m '{"value": 72.5, "unit": "celsius", "timestamp": 1707580800}'

# Beispiel: Vibrationsdaten an Maschine 3
mosquitto_pub -h emqx.messaging.svc.cluster.local \
  -t "factory/machines/machine-twin-3/sensors/vibration" \
  -m '{"rms": 2.8, "peak": 8.4, "unit": "mm_s", "timestamp": 1707580800}'

# Twin-Status abfragen
mosquitto_sub -h emqx.messaging.svc.cluster.local \
  -t "factory/twins/machine-twin-3/status"
# Ausgabe: {"state": "healthy", "drift": 0.02, "last_sync": 1707580800}

Ein wichtiger Punkt: Die Latenz zwischen physischer Maschine und Digital Twin sollte unter 500ms liegen, damit der Zwilling den aktuellen Zustand abbildet. Bei MQTT ueber ein lokales Netzwerk ist das kein Problem (typisch 5-20ms). Bei Cloud-Anbindung kann es kritisch werden, weshalb die Twin-Runtime im lokalen Plant-Cluster laufen sollte.

GPU-beschleunigte Simulationen

Fuer aufwaendige Simulationen (Finite-Elemente-Methode, Computational Fluid Dynamics, Physik-Simulation) brauchen Digital Twins GPU-Ressourcen. Diese Simulationen laufen nicht permanent, sondern werden bei Bedarf gestartet: wenn ein Ingenieur ein Was-waere-wenn-Szenario durchspielen will oder wenn ein Anomalie-Schwellwert ueberschritten wird.

apiVersion: batch/v1
kind: Job
metadata:
  name: twin-simulation-job
  namespace: digital-twins
  labels:
    twin-id: machine-twin-3
    simulation-type: fem-stress
spec:
  backoffLimit: 2
  activeDeadlineSeconds: 3600
  template:
    spec:
      tolerations:
      - key: "gpu-only"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"
      nodeSelector:
        accelerator: nvidia-a100
      containers:
      - name: fem-solver
        image: registry.internal/twins/fem-solver:1.5.0
        env:
        - name: TWIN_ID
          value: "machine-twin-3"
        - name: SIMULATION_PARAMS
          value: "/config/stress-test-120pct.json"
        - name: OUTPUT_BUCKET
          value: "s3://simulation-results/machine-twin-3/"
        - name: S3_ENDPOINT
          value: "minio.storage.svc.cluster.local:9000"
        resources:
          requests:
            cpu: "4"
            memory: "16Gi"
            nvidia.com/gpu: 1
          limits:
            cpu: "8"
            memory: "32Gi"
            nvidia.com/gpu: 1
        volumeMounts:
        - name: simulation-config
          mountPath: /config
          readOnly: true
      restartPolicy: Never
      volumes:
      - name: simulation-config
        configMap:
          name: simulation-parameters

Die Simulation laeuft als Kubernetes Job, nicht als Deployment. Jobs haben einen definierten Endzustand (Erfolg oder Fehler) und werden nach Abschluss nicht neu gestartet. Das spart GPU-Ressourcen, weil die GPU nur waehrend der eigentlichen Berechnung belegt ist.

Details zum GPU-Cluster-Setup beschreibt der Artikel GPU-Workloads auf Kubernetes.

Predictive Maintenance mit Digital Twins

Der wertvollste Use Case fuer Digital Twins in der Fertigung ist Predictive Maintenance. Der Ablauf:

1. Datensammlung. Der Twin sammelt kontinuierlich Sensordaten und berechnet abgeleitete Metriken (Verschleiss-Index, Anomalie-Score, Trendanalyse).
2. Modellvergleich. Der Twin vergleicht den aktuellen Zustand mit einem physikalischen Modell der Anlage. Abweichungen (Drift) deuten auf Verschleiss hin.
3. Simulation. Bei erkannter Drift wird eine Simulation gestartet: Wie entwickelt sich der Verschleiss in den naechsten 7/14/30 Tagen?
4. Wartungsempfehlung. Basierend auf der Simulation wird eine Wartungsempfehlung generiert, inklusive geschaetztem Ausfallzeitpunkt und empfohlener Massnahme.

Der Vorteil gegenueber klassischer zustandsbasierter Wartung: Der Twin simuliert die Zukunft. Er sagt nicht nur, dass ein Lager verschlissen ist, sondern wann es voraussichtlich ausfallen wird. Das erlaubt eine gezielte Wartungsplanung, die Produktionsunterbrechungen minimiert.

Monitoring: Twin-spezifische Metriken

Neben den Standard-Kubernetes-Metriken (CPU, Memory, Pod-Status) brauchen Digital Twins eigene Metriken:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: digital-twin-alerts
  namespace: digital-twins
spec:
  groups:
  - name: twin-health
    interval: 30s
    rules:
    - alert: TwinSyncLag
      expr: time() - twin_last_data_received_timestamp > 60
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "Twin {{ $labels.twin_id }} hat seit ueber 60s keine Daten empfangen"
    - alert: TwinDriftHigh
      expr: twin_model_drift_score > 0.1
      for: 10m
      labels:
        severity: warning
      annotations:
        summary: "Twin {{ $labels.twin_id }} zeigt hohe Modell-Abweichung"
    - alert: TwinStateCorrupted
      expr: twin_state_checksum_valid == 0
      for: 1m
      labels:
        severity: critical
      annotations:
        summary: "Twin {{ $labels.twin_id }} hat einen inkonsistenten Zustand"

Die wichtigste Metrik ist TwinSyncLag. Wenn ein Twin keine Daten mehr empfaengt, ist er nicht mehr synchron mit der physischen Anlage und seine Aussagen sind wertlos. Das kann an einem Netzwerkproblem, einem ausgefallenen Sensor oder einem Problem mit dem OPC-UA-Adapter liegen.

Skalierung: Von 10 auf 500 Twins

Ein einzelnes Werk hat typisch 20-100 Maschinen. Ein Konzern mit mehreren Werken kommt schnell auf 500 oder mehr Twins. Die Skalierung bringt spezifische Herausforderungen:

MQTT-Broker-Kapazitaet. 500 Twins mit je 10 Sensoren, die alle 500ms senden, erzeugen 10.000 Messages pro Sekunde. EMQX in einem 3-Node-Cluster verarbeitet das problemlos (EMQX schafft ueber 1 Million Messages pro Sekunde).

Datenbank-Last. 10.000 Inserts pro Sekunde in TimescaleDB erfordern eine saubere Partitionierung (Hypertables nach Zeit und Twin-ID) und ausreichend I/O-Kapazitaet. NVMe-Storage ist empfehlenswert.

Cluster-Groesse. 500 Twins mit je 500m CPU und 1Gi RAM Request benoetigen 250 vCPUs und 500Gi RAM. Das sind ca. 16 Nodes mit je 16 vCPUs und 32Gi RAM. Dazu kommen GPU-Nodes fuer Simulationen.

Fuer Multi-Werk-Szenarien empfiehlt sich eine Hub-and-Spoke-Architektur: Jedes Werk hat seinen eigenen Cluster mit den lokalen Twins, ein zentraler Cluster aggregiert Daten fuer werksuebergreifende Analysen.

Haeufige Fehler bei Digital-Twin-Projekten

Zu detaillierte Modelle zum Start. Ein Digital Twin muss nicht jede Schraube abbilden. Starten Sie mit den 5-10 wichtigsten Sensoren pro Maschine und erweitern Sie schrittweise. Ein einfacher Twin, der zuverlaessig laeuft, ist wertvoller als ein detaillierter Twin, der nie fertig wird.

Kein Datenqualitaets-Monitoring. Sensoren liefern manchmal falsche Werte (Drift, Ausfall, Spike). Ohne Datenqualitaetspruefung fuettert man den Twin mit Muell und bekommt Muell zurueck. Implementieren Sie Plausibilitaetschecks vor der Daten-Ingestion.

Simulation ohne Validierung. Ein Simulationsmodell ist nur so gut wie seine Kalibrierung. Vergleichen Sie Simulationsergebnisse regelmaessig mit realen Messwerten und kalibrieren Sie das Modell nach.

Persistenz vergessen. Wenn ein Twin-Pod neu startet und keinen persistenten Speicher hat, verliert er seinen gesamten Zustand. Das bedeutet Stunden oder Tage an verlorenem Kontext. PersistentVolumes sind Pflicht, nicht optional.

Kostenrahmen fuer ein Digital-Twin-Pilotprojekt

Fazit und naechste Schritte

Digital Twins auf Kubernetes zu betreiben kombiniert zwei Staerken: die Faehigkeit von Kubernetes, zustandsbehaftete Workloads zuverlaessig zu orchestrieren, und die Flexibilitaet, heterogene Workloads (Echtzeit-Datenverarbeitung, Simulation, Visualisierung) auf einer Plattform zu vereinen.

Der empfohlene Einstieg: Waehlen Sie eine kritische Maschine (haeufige Ausfaelle, hohe Stillstandskosten) und bauen Sie fuer diese einen einfachen Twin. Sensordaten ueber MQTT, Zustandsmodell als StatefulSet-Pod, Visualisierung in Grafana. Wenn der Twin zuverlaessig den Maschinenzustand abbildet, fuegen Sie Simulationsfaehigkeit und Predictive Maintenance hinzu.

Weitere Grundlagen zur Kubernetes-Nutzung in der Fertigung beschreibt der Artikel Kubernetes in der Produktion. Zur Industrie-4.0-Referenzarchitektur siehe Kubernetes Industrie 4.0.

Fuer eine gemeinsame Bewertung Ihres Digital-Twin-Vorhabens oder technische Unterstuetzung erreichen Sie uns ueber die Kontaktseite.