Digitaler Zwilling für Brückenkrane: Echtzeit-Rendering am Edge

Architektur des Digitalen Zwillings, AAS-Datenmodell, Simulations-Kalibrierung – in diesem Beitrag widmen wir uns der praxisrelevanten Frage: Wie lässt sich der Digitale Zwilling auf einem Industrie-PC flüssig ausführen?

Die 3D-Szene des Digitalen Zwillings für Brückenkrane läuft nicht auf einer High-End-Workstation, sondern auf einem Industrie-PC in der Werkstatt (i5-8500, integrierte Grafikeinheit, 4 GB gemeinsam genutzter Grafikspeicher). Mit dieser Konfiguration lässt sich ein Kranmodell mit 200.000 Dreiecken samt Werkshallen-Umgebung ohne Optimierung nicht flüssig rendern. Gemessen: 12 fps vor der Optimierung, 58 fps danach – diese Differenz von 46 fps ist genau das, worum es in diesem Artikel geht.

Modellreduzierung: Von 500.000 auf 50.000 Dreiecke

Die 3D-Modelle des Brückenkrans im Digitalen Zwilling stammen in der Regel aus CAD-Exporten auf Basis von Konstruktions-Stücklisten oder STEP-Dateien und umfassen schnell 500.000 bis 1.000.000 Dreiecke. Diese Detailgenauigkeit ist für Struktursimulationen sinnvoll, im Web-Browser jedoch eine Katastrophe für das Rendering. Die Reduzierung der Dreiecksanzahl ist daher der erste unverzichtbare Schritt.

1.1 Reduktionsstrategie

Das Kernprinzip der Reduktion lautet „Fläche zuerst" – große ebene Bereiche im Modell (Stegblech des Hauptträgers, Abdeckplatte, Seitenflächen des Kopfträgers) werden durch planare Erkennung zusammengefasst, wobei die Konturkanten erhalten bleiben. Bei gekrümmten Flächen und Schweißnahtbereichen wird die Reduktionsrate hingegen niedriger gehalten, um Verformungen zu vermeiden. Empfohlener Arbeitsablauf: Zuerst mit Planar Decimation die ebenen Bereiche auf die minimale Polygonanzahl reduzieren, anschließend mit Collapse Decimation die restlichen Bereiche nachoptimieren – das Ziel liegt bei maximal 50.000 Polygonen.

1.2 Empfohlene Werkzeuge

• Blender Decimate Modifier: Kostenlos, unterstützt Planar Decimation und Collapse Decimation, Reduktionsrate präzise steuerbar
• Simplygon: Industrielles automatisiertes Reduktionswerkzeug, unterstützt automatische LOD-Kettengenerierung, teuer aber effektiv
• MeshLab: Open Source, geeignet für Stapelverarbeitung

1.3 Reduktionsgrenzen

Weniger Polygone ist nicht automatisch besser. Eine übermäßige Reduktion führt zu sichtbaren Konturverformungen des Modells. Die Faustregel lautet: Nach der Reduktion darf der visuelle Unterschied zwischen reduziertem und Originalmodell im statischen Zustand mit bloßem Auge nicht wahrnehmbar sein. In der Praxis werden Original- und Reduktionsmodell überlagert und halbtransparent verglichen – eine Konturabweichung von weniger als 1 Pixel gilt als akzeptabel.

LOD-Stufenweises Laden

LOD (Level of Detail) ist die ausgereifteste Optimierungsmethode im 3D-Rendering – aus der Nähe Details, aus der Ferne Konturen. In der Digitaler-Zwilling-Umgebung betrachtet der Bediener selten die Schweißnahtdetails eines einzelnen Brückenkrans, sondern beobachtet meist aus der Vogelperspektive den Betriebszustand mehrerer Brückenkräne gleichzeitig.

2.1 LOD-Ebenen-Design

Die LOD-Ebenen werden nach Sichtweite in 4 Stufen unterteilt: LOD0 (detailliert, 0–50 m), LOD1 (mittel, 50–200 m), LOD2 (grob, 200–500 m), LOD3 (Fernansicht, 500 m+). Die Polygonanzahl und Texturauflösung der einzelnen Ebenen sind wie folgt ausgelegt:

2.2 Umschaltstrategie

Ein harter Wechsel der LOD-Stufen (plötzlicher Modellwechsel an der Schwelle) wirkt visuell sprunghaft. Empfohlen wird die Verwendung der LOD-Komponente von three.js mit einem Fade-Übergang oder die Definition eines animierten Schwellenbereichs (z. B. 48–52 m für einen Transparenz-Mix). Zudem sollte die LOD-Erkennung nicht in jedem Frame erfolgen; eine Überprüfung alle 200 ms genügt und entlastet die CPU.

3. Texturkompression

Texturen sind der Hauptverursacher für den Grafikspeicherbedarf. Ein vollständiger PBR-Materialsatz (baseColor + roughness + metallic + normal + AO) benötigt bei unkomprimierten 2048×2048 Pixeln etwa 200 MB Grafikspeicher pro Brückenkran. Bei fünf gleichzeitig angezeigten Brückenkränen ist der Speicher schnell erschöpft.

Empfohlene Lösungen:

• ASTC 6×6: Von ARM entwickelte Texturkompressionsformat mit einem Kompressionsverhältnis von ca. 4:1 bei akzeptablem Qualitätsverlust. Wird von WebGL2 gut unterstützt.
• KTX2 + Basis Universal: Plattformübergreifende Texturkompression, die direkt von der GPU dekomprimiert wird, ohne die CPU zu belasten. Three.js bietet einen fertigen Loader.
• Textur-Downsampling: baseColor mit 1024×1024 ist ausreichend, roughness/metallic mit 512×512, normal mit 1024×1024 und AO mit 256×256.

Nach der Optimierung sinkt der Grafikspeicherbedarf pro Brückenkran von 200 MB auf 45 MB.

4. Occlusion Culling

In einer Digitaler-Zwilling-Szene ist mindestens die Hälfte der Objekte aus der aktuellen Kameraperspektive nicht sichtbar – die Wand dahinter, Säulen auf der anderen Seite oder die von Hauptträgern verdeckte Laufkatze. Alle Objekte an die GPU zu übergeben, ist reine Verschwendung.

Three.js bietet kein integriertes Occlusion Culling; dies muss selbst implementiert oder über eine Drittanbieter-Bibliothek gelöst werden:

• Portals: Die Werkshalle wird in mehrere Räume/Regionen unterteilt. Objekte in einer Region werden nur gerendert, wenn die Region sichtbar ist. Geeignet für Szenen mit fester Hallenstruktur.
• Hardware Occlusion Queries: Verwendung von WebGL2s EXT_disjoint_timer_query oder Occlusion Query zur Erkennung der Sichtbarkeit von Objekten. Hohe Genauigkeit, aber eine Frame-Verzögerung; geeignet für große, statische Objekte.
• Frustum Culling: Standardmäßig in Three.js aktiviert, rendert nur Objekte innerhalb des Sichtkegels. Dies ist die Basis, reicht aber nicht aus – Objekte im Sichtkegel können dennoch von anderen Objekten verdeckt werden.

In der Praxis wird die Portals-Lösung empfohlen. Die Werkshalle wird entlang der Spannweite in mehrere Zonen unterteilt. Jeder Brückenkran gehört nur zu seiner aktuellen Zone plus den angrenzenden Zonen. Befindet sich der Bediener in Zone A, werden die Brückenkräne in Zone B und C nicht gerendert, sondern nur der Datenstatus als Text aktualisiert.

5. Datenübertragung optimieren

Rendering ist nicht nur eine Frontend-Aufgabe – wie, wie viel und wie schnell Daten vom Backend zum Frontend übertragen werden, beeinflusst die Erfahrung direkt.

5.1 Inkrementelle Updates

Die Betriebsdaten des Brückenkrans werden alle 100 ms aktualisiert, aber 95 % der Datenpunkte sind identisch mit dem vorherigen Frame (z. B. ändern sich Nennlast und Spannweite als technische Parameter nie). Eine vollständige Übertragung verschwendet Bandbreite und CPU-Zeit für die Analyse.

Lösung: Das Backend überträgt nur geänderte Attribute. Bei jeder Übertragung wird eine Bitmap verwendet, um zu markieren, welche Attribute sich geändert haben. Das Frontend aktualisiert nur die 3D-Objektzustände, die den geänderten Attributen entsprechen. In der Praxis sinkt die Bandbreite von 50 KB/s auf 8 KB/s pro Brückenkran.

5.2 Datenkompression

• JSON + gzip: Kompressionsverhältnis ca. 6:1
• JSON + Brotli (nativ in Chrome/Firefox unterstützt): Kompressionsverhältnis ca. 8:1, Dekomprimierung geringfügig langsamer als gzip, aber akzeptabel
• Protocol Buffers (empfohlen): Binäre Kodierung, nur 1/5 der Größe von JSON, 10x schnellere Parsing-Geschwindigkeit. Mit der vorhandenen protobuf.js-Bibliothek ist die Integration in Three.js problemlos.

5.3 WebSocket vs. SSE

• WebSocket: Vollduplex, geringste Latenz, ideal für Echtzeit-Datenströme.
• SSE (Server-Sent Events): Einweg-Push, nativ vom Browser unterstützt, mit integriertem Wiederverbindungsmechanismus.
• Empfehlung: WebSocket mit automatischer Wiederverbindung (Heartbeat-Intervall 15 s). Bei instabilem Netzwerk als Fallback auf SSE.

6. Rendering-Thread optimieren

Das Hauptziel der Rendering-Thread-Optimierung ist es, die Datenverarbeitung vom Haupt-Thread zu entkoppeln:

Hardware-Empfehlungen für den Einsatz

Optimierung der Edge-Rendering-Leistung

Die Standard-Industrie-PC-Konfiguration der meisten Werke liegt zwischen „Einsteiger" und „Standard". Nach vollständiger Umsetzung des oben beschriebenen Optimierungskonzepts steigt die durchschnittliche Bildrate für fünf Brückenkrane mit der i5-8500-Integrierten-GPU von 12 fps auf 58 fps. Bei nur ein bis zwei Brückenkränen vor Ort ist die Einsteigerkonfiguration völlig ausreichend.

Fazit: Drei Kernprinzipien für flüssige Digital-Twin-Darstellung

Edge-Rendering-Optimierung ist keine Zauberei – es geht um drei Dinge: weniger Daten übertragen, weniger Modelle zeichnen, GPU besser nutzen. Durch die Reduzierung der Übertragungsbandbreite pro Brückenkran von 50 KB/s auf 8 KB/s, der Polygonanzahl von 500.000 auf 50.000 und des Speicherverbrauchs von 1,8 GB auf 480 MB läuft der Digitale Zwilling mit 60 fps auf dem Industrie-PC.

Damit ist die Serie zum Digitalen Zwilling vorerst abgeschlossen. Vier Artikel haben die vier zentralen technischen Kernbereiche der Implementierung abgedeckt: Architekturdesign, Datenmodell, Simulationskalibrierung und Rendering-Optimierung. Sobald neue technische Erkenntnisse vorliegen, wird die Serie fortgesetzt.

Häufige Fragen zur Rendering-Optimierung