Skalierbare VR-Trainingssimulatoren entwickeln: Architekturleitfaden für Enterprise Learning

VR-Trainingsprojekte scheitern oft auf vorhersehbare Weise. Ein Team entwickelt einen Prototyp für ein Brandschutzszenario in Unity, demonstriert ihn auf einer Quest 3 und stößt dann auf Probleme, als das LMS-Team nach dem Datenformat des Headsets fragt. Sechs Wochen später existiert zwar ein funktionierendes Szenario, aber die LMS-Integration ist fehlerhaft. Die Architekturentscheidungen, die dies verhindert hätten, wurden nicht getroffen, da das Projekt mit der Demo und nicht mit der Datenpipeline begann.

Dieser Artikel erklärt, wie man einen VR-Trainingssimulator entwickelt, der auch bei wachsenden Inhaltsbibliotheken, Backend-Integrationen und steigenden Teilnehmerzahlen wartungsfreundlich bleibt. Der Fokus liegt auf VR-Training für Unternehmen: Backend-Integration, LMS-Anbindung, skalierbare Unity-Projektstruktur und VR-Anwendungsarchitektur für langfristige Wartbarkeit.

Die richtige Engine für die Entwicklung von VR-Trainingssoftware wählen

Jedes Entwicklungsprojekt für VR-Trainingssoftware beginnt mit derselben grundlegenden Entscheidung: Die Auswahl der Engine und der Headset-Plattform muss getroffen werden, bevor andere Architekturentscheidungen folgen. Diese frühen Festlegungen beeinflussen den gesamten Entwicklungsprozess mit Unity für VR-Anwendungen. Ein späterer Wechsel der Engine oder Hardwareplattform ist während des Projekts mit erheblichem Aufwand verbunden und daher in der Praxis meist keine realistische Option.

Im Enterprise-Umfeld ist Unity heute die Standardwahl für die Entwicklung von VR-Trainingssimulatoren. Dafür sprechen unter anderem folgende Gründe:

• Gute Unterstützung für Standalone-Headsets
• Eine ausgereifte OpenXR-Implementierung
• Ein größerer Pool an C#-Entwicklern als bei Unreal

Wenn jedoch fotorealistische Darstellungen zwingend erforderlich sind, ist Unreal Engine ebenfalls eine sinnvolle Wahl. Allerdings gestaltet sich der Aufbau und die langfristige Besetzung von Unreal-Teams über mehrere Jahre meist schwieriger. Dieser Faktor gewinnt insbesondere dann an Bedeutung, wenn Unternehmen ihre Trainingsbibliothek kontinuierlich um neue Szenarien erweitern möchten.

Für Standalone-VR-Headsets gilt die Meta Quest 3 derzeit als die bevorzugte Plattform im Enterprise-Bereich. Sie benötigt keinen angeschlossenen PC, lässt sich mit Meta for Work vergleichsweise einfach verwalten und erreicht bei gut optimierten Projekten problemlos flüssige 72 Hz.

Innerhalb von Unity ist die Universal Render Pipeline (URP) die sinnvollste Wahl für Standalone-Headsets. Sie wurde speziell für mobile GPUs entwickelt und unterstützt Fixed Foveated Rendering. Dabei werden die Randbereiche des Sichtfelds mit einer geringeren Auflösung gerendert, wodurch die GPU entlastet wird, ohne die wahrgenommene Bildqualität wesentlich zu beeinträchtigen.

Die High Definition Render Pipeline (HDRP) bietet zwar eine deutlich höhere grafische Qualität, wurde jedoch in erster Linie für leistungsstarke Desktop-GPUs entwickelt. Ihre Rendering-Architektur und ihr Funktionsumfang sind nicht für die tile-basierte mobile GPU-Architektur von Standalone-Headsets wie der Meta Quest ausgelegt. Deshalb ist URP die praktischere Wahl für Enterprise-VR-Projekte.

Diese Entscheidung sollte bereits bei der Einrichtung des Projekts getroffen werden, da ein Wechsel der Render-Pipeline während der Entwicklung mit erheblichem Aufwand verbunden ist.

Unity-Projektarchitektur: Eine skalierbare Architektur für VR-Trainingssoftware

Bei einem monolithischen Unity-Projekt im Enterprise-Trainingsumfeld treten die größten Probleme meist nicht dann auf, wenn die Anwendung nicht mehr funktioniert. Sie entstehen jedes Mal, wenn Inhalte aktualisiert werden müssen. In einem gut konzipierten System sollte die Korrektur einer einzelnen Schrittbeschreibung in einem Sicherheitstrainingsszenario nicht dazu führen, dass Szenendateien geändert werden müssen und dadurch Regressionen in anderen Modulen entstehen.

Diese Modularität bildet die Grundlage einer skalierbaren Architektur für Enterprise-VR-Trainingssoftware. Sie ermöglicht die Weiterentwicklung von Trainingsszenarien, Integrationen und Analysefunktionen, ohne dass das gesamte Projekt umstrukturiert werden muss.

Für größere Projekte hat sich eine Modul-pro-Szenario-Struktur mit einem gemeinsam genutzten Runtime-Kern als besonders bewährt:

Assets/
_Core/
   XRRig/
   ScenarioManager/
   AnalyticsClient/
   UIFramework/
Modules/
   FireSafety/
     Scenes/
     Prefabs/
     ScriptableObjects/
   EquipmentInspection/
StreamingAssets/
   Configs/

Standalone-Headsets können eigenständige Trainingsszenarien auch ohne Backend ausführen. In produktiven Deployments werden jedoch in der Regel eine zentrale Konfiguration, Multi-User-Koordination, xAPI-Pufferung, Analytics-Aggregation und Authentifizierungsdienste benötigt. Dafür reichen oft einige wenige Endpoints in einem .NET– oder Node.js-Service aus:

Für cloud-native Deployments kommen häufig eine containerisierte .NET- oder Node.js-API, eine verwaltete relationale Datenbank und Object Storage für Konfigurationspakete zum Einsatz.

Die Übertragung von xAPI-Statements an den LRS sollte asynchron erfolgen. Das Headset sendet Statements an einen Backend-Service, der sowohl als Authentifizierungsproxy als auch als Pufferungsschicht dient, bevor er sie nach einem eigenen Zeitplan an den LRS weiterleitet. Dieser Ansatz hält LRS-Zugangsdaten aus der Anwendung heraus, zentralisiert die Authentifizierung und entkoppelt den Abschluss einer Trainingseinheit von der Verfügbarkeit des LRS. Das ist besonders wichtig, wenn Enterprise-Plattformen Wartungsfenster oder Rate Limits haben. Ein Lernender sollte keinen fehlgeschlagenen Session-Datensatz erhalten, nur weil der LRS während der Trainingseinheit nicht verfügbar war.

LMS-Integration: SCORM vs. xAPI

{
"actor": { "account": { "name": "user123" } },
"verb": { "id": "http://adlnet.gov/expapi/verbs/completed" },
"object": { "id": "urn:scenario:forklift-inspection" },
"result": {
  "score": { "scaled": 0.82 },
  "extensions": {
    "time_to_first_hazard_ms": 47200,
    "checklist_items_skipped": 1
  }
}
}
​

Diese Statements werden an einen Learning Record Store (LRS) übertragen, nicht direkt an das LMS. Der LRS speichert die rohen xAPI-Datensätze. Das LMS erhält zusammengefasste Daten entweder aus dem LRS oder vom Backend-Aggregator. cmi5 erweitert xAPI, indem es standardisiert, wie ein LMS externe Lernanwendungen startet, die Identität der Lernenden verwaltet und LRS-Verbindungsdaten austauscht. Es ist daher eine starke Wahl, wenn LMS-Interoperabilität Priorität hat.

Die Möglichkeiten dieser Konnektoren unterscheiden sich je nach LMS-Plattform. Deshalb sollte vor der Entscheidung für einen Integrationsansatz geprüft werden, welche xAPI- und cmi5-Unterstützung der jeweilige Anbieter bietet.

Der Integrationsablauf für Standalone-Headsets:

Aus Sicht der Nutzer läuft der Prozess wie folgt ab:

• Zu Beginn verbindet eine Launcher-Seite das LMS mit dem Headset
• Sobald der Lernende die zugewiesene Schulung im LMS-Portal öffnet, wird ein Session-Token erstellt, mit dem das entsprechende Szenario auf dem Headset gestartet wird

Für kleinere Deployments können kurze Codes verwendet werden. In größeren Enterprise-Umgebungen kommen dagegen meist Deep Links, QR-Code-Logins oder SSO-integrierte Start-Workflows zum Einsatz. Die xAPI-Statements übernehmen dabei denselben Session-Kontext, sodass die Ergebnisse dem Profil des jeweiligen Lernenden eindeutig zugeordnet werden können.

Synchronisierung mehrerer Nutzer

Performance-Optimierung für Ihren VR-Trainingssimulator

#if UNITY_EDITOR
using UnityEngine;
using UnityEditor;

[ExecuteInEditMode]
public class DrawCallAudit : MonoBehaviour
{
    void OnGUI()
    {
        int batches = UnityStats.batches;
        GUI.color = batches > 800 ? Color.red : Color.white;
        GUI.Label(
            new Rect(10, 10, 220, 20),
            $"Editor batches: {batches} / ~650 target");
    }
}
#endif

Das Team von Chudovo verwendet dieses minimale, ausschließlich im Editor verfügbare Tool während der Erstellung von Szenen, um Überschreitungen des Rendering-Budgets frühzeitig zu erkennen, bevor sie sich auf das gesamte Projekt auswirken. Es eignet sich gut, um bereits während der Entwicklung eine erste Einschätzung der Performance zu erhalten. Für eine umfassende Leistungsanalyse in URP-basierten Projekten bleiben jedoch der Unity Rendering Debugger und der Unity Profiler die maßgeblichen Werkzeuge.

Sicherheitsaspekte für Enterprise-Deployments

Die Architektur im Überblick

Ein kleines Pilotprojekt benötigt nicht den vollständigen Technologie-Stack. Ein SCORM-Paket, eine APK mit einem einzelnen Trainingsszenario und ein einfaches LMS reichen aus, um das Trainingskonzept zu validieren. Die zusätzliche Architektur wird erst dann erforderlich, wenn das Projekt skaliert. Der Übergang zu einer Enterprise-Architektur gelingt jedoch deutlich einfacher, wenn die Modulstruktur und das xAPI-Schema von Anfang an sauber konzipiert wurden.

Fazit

Die Architektur eines Enterprise-VR-Trainingssimulators ist in erster Linie eine Aufgabe der Systemintegration. Für Rendering und Interaktionen stehen heute ausgereifte Werkzeuge zur Verfügung. Die größere Herausforderung besteht darin, die Datenpipeline sinnvoll zu gestalten. Sitzungsdaten müssen zuverlässig vom Standalone-Headset über das Backend und eine Warteschlange in einen Learning Record Store (LRS) gelangen und anschließend so aufbereitet werden, dass Learning-&-Development-Teams daraus verwertbare Erkenntnisse gewinnen können.

Diese Architekturentscheidungen entsprechen zugleich den Best Practices für die Entwicklung von VR-Trainingssoftware. Sie reduzieren den Aufwand für zukünftige Content-Updates, LMS-Integrationen und die Skalierung von Headset-Flotten. Individuelle VR-Trainingslösungen, die die Datenarchitektur als zentrales Designthema behandeln, schaffen eine belastbare Grundlage für langfristig skalierbare immersive Trainingsplattformen.