Digital Twins und Continous Simulation mit dem Unity SystemGraph

Mit der Unity Industrial Collection bietet Unity diverse Tools, SDKs und Schnittstellen an, die industrienahen Nutzern helfen soll, Echtzeit- VR- oder AR-Anwendung nach den Maßstäben von Industrieunternehmen zu entwickeln. Ein Teil dieser Industrial Collection stellen der Unity System Graph sowie das dazugehörige SensorSDK dar. Ich habe mir beide angeschaut, um sie in Hinblick auf die Tauglichkeit für Simulationen sowie Emulation und die Erstellung von Digital Twins zu überprüfen und abschließend einschätzen zu können, was sich mit diesen Tools realisieren lässt. Wie der SystemGraph funktioniert, für wen er sich eignet und welche Rolle die SensorSDK dabei spielt, erfahrt ihr in diesem Beitrag zum Unity SystemGraph.
Was ist der Unity System Graph?
In erster Linie handelt es sich bei Unitys System Graph um eine Art visuellen Editor, der uns hilft, Systeme und Digital Twins aller Art zu entwickeln. Damit setzt sich auch hier ein Trend fort, den verschiedene Creator-Tools seit einigen Jahren gehen. Visual Scripting und Nodebasierte Editoren senken die Barrieren für Anwender und ermöglichen einen Zugriff auf Systeme von Nutzer*innen, die selbst keine Programmierkenntnisse haben. Wie auch der Shader Graph oder der VFX Graph in Unity, basiert der SystemGraph auf Graphview – einer Schnittstelle zur Erstellung visueller Systeme.
Für wen eignet sich der Unity SystemGraph?
Angesprochen werden hier ganz klar industrienahe Nutzer*innen und Ingenieur*innen. Laut Unity selbst richtet sich der SystemGraph an Sensor-Hersteller*innen, Entwickler*innen robotischer Systeme, IOT-System-Entwickler*innen sowie Ingenieur*innen für autonomes Fahren und die Entwickler*innen von Fahrzeugsystemen. Diese Angabe legen zwei klare Anwendungsszenarien nahe. Zum einen können Systeme hier vor dem Bau ausgiebig getestet werden und zum anderen lassen sich beispielsweise für IOT-Entwickler*innen Systeme schaffen, die realistische Daten erzeugen und mit deren Hilfe sich Software-Systeme entwickeln und ausgiebig testen lassen. Das ist insbesondere für Bereiche wie Forschung und Entwicklung spannend, die mitunter Lösungen für Hardware und Systeme entwickeln, die so noch nicht existieren.
Dabei ist vor Allem das Zusammenspiel mit der SensorSDK besonders. Denn hier sind Nodes für den SystemGraph bereits implementiert, die physikalisch korrekte Sensorik ermöglichen. Das kann insbesondere für Themen der Robotik oder des autonomen Fahrens von großem Nutzen sein. Die entsprechenden Software-Systeme, die hier zum Einsatz kommen, verarbeiten häufig auf stark verrauschten Sensordaten, um Beispielsweise Positionen oder Zustände von Systemen zu ermitteln. Mit der SensorSDK lassen sich die dafür nötigen Sensoren einfach emulieren.
Wie installiere ich den Unity SystemGraph?
Sowohl der SystemGraph, als auch die SensorSDK sind über den Unity Package Manager (UPM) als Unity Packages verfügbar. Dementsprechend ist auch Installation des SystemGraphs nicht sonderlich kompliziert. Will man dazu allerdings die SensorSDK verwenden, ergeben sich ein paar Komplikationen. Es gibt hier noch ein paar Ungereimheiten im Zusammenspiel der Package-Versionen und der Unity-Versionen. Daran merkt man, dass es sich bei beiden Packages noch um Preview Packages handelt. Das ist für Unity-Anfänger*innen mitunter eine echte Hürde. Mit etwas Know-How und entsprechenden Unity-Kenntnissen, lässt sich das Problem aber lösen.
Falls ihr noch keine Kenntnisse in Unity habt oder einer weiterführende Beratung für die Unity-Engine braucht, schaut mal bei unserer Unity Engine Beratung vorbei.
Wie erstelle ich einen neuen Unity SystemGraph?
Um den SystemGraph zu benutzen, müsst ihr zuerst ein SystemGraph-Asset erzeugt. Im Asset Browser der Game Engine, wird dieses über einen Rechtsklick und dann Create > System > System Graph erstellt. Öffnet ihr dieses Asset, öffnet sich ein neues Editor-Fenster, in dem ihr später den SystemGraph bearbeiten könnt. Um das SystemGraph-Asset nun in der Szene zu platzieren, wird im Inspector ein Empty Game Object erstellt. Diesem wird über Add Component das im SystemGraph-Package enthaltene Script System Graph Component hinzugefügt. Dieses enthält wiederum ein Feld mit dem Namen „System Graph Asset“. In diesem platziert ihr das zuvor erstellte System Graph Asset.
Überblick über den SystemGraph
Bevor wir uns den SystemGraph an einem konkreten Beispiel anschauen, ist es sinnvoll, dessen wichtigsten Funktionen und Komponenten zu kennen. Falls ihr genauer nachlesen wollt, könnt ihr das in der Dokumentation des Packages tun. Ihr findet sie hier.
Properties erstellen
Mit Properties könnt ihr Daten an den SystemGraph übergeben und diese dann innerhalb des Graphen benutzen. Angelegt werden diese mit ihren entsprechenden Datentypen im Properties-Fenster in der linken oberen Ecke des SystemGraph-Editors. Von dort aus könnt ihr sie dann in den Graphen ziehen. Sie sind in erster Linie dazu gedacht, um über den Inspector in Unity Parameter für ein System zu definieren. Wollt ihr beispielsweise die Auflösung einer emulierten Kamera oder deren Brennweite verstellen, könnt ihr das einfach über den Inspector machen und müsst nicht umständlich in den Graphen gehen.
Properties lassen sich auch direkt in einem Node-Script erzeugen und werden dann automatisch im Properties-Fenster im SystemGraph-Editor angezeigt. Wie das funktioniert, lest ihr hier.
Nodes erstellen
Im SystemGraph-Editor selbst können Nodes erstellt werden – sie stellen die Grundbausteine des Unity SystemGraph dar und können miteinander verbunden werden. Hierfür genügt ein Rechtsklick auf die leere Arbeitsfläche. Zur Auswahl stehen nun die Möglichkeit, einen schon bestehenden Node einzufügen, oder einen neuen Node zu erstellen. Bestehende Nodes befinden sich beispielsweise im SensorSDK-Package. Dort sind verschiedene Sensoren, Motoren sowie Controller für Sensoren enthalten, die einfach im SystemGraph verwendet werden können.
Um eigene Nodes zu erstellen, genügt ein Klick auf Create Node Script. Hier vergebt ihr einen Kategorie- sowie einen Script-Namen. Unter ersterem werden die Nodes dann im Editor gebündelt und ihr findet sie wenn ihr auf Create Node klickt.
Es öffnet sich ein Node-Script. Hier könnt ihr dann euren neuen Node definieren. Der Aufbau sieht dabei folgendermaßen aus: Ihr definiert Inputs, Outputs und Bindings. Hier könnt ihr festlegen, welche Daten in euren Node hinein und welche hinaus gehen. Über Bindings schafft ihr Referenzen auf Game Objects in eurer Unity Szene. Das lässt sich zwar auch über Properties realisieren, es wird aber empfohlen Bindings zu verwenden.
Nodes können in zwei Modi laufen. Sind sie unter Node Tick auf Asynchronous gestellt, sind sie nicht mit der Clock eures Systems verbunden und die Funktion OnTick wird nicht aufgerufen. Ihr könnt euch beispielsweise auf die Änderung einer Variable registrieren und so die Logik einer asynchronen Node ausführen. Sind sie wie in dem zu sehenden Beispiel auf Synchronous gestellt, wird jeden Zeitschritt OnTick aufgerufen. Den Zeitschritt stellt ihr im Scheduler des SystemGraphs in Hertz ein. Dieser Scheduler läuft dabei unabhängig von Unitys normaler GameLoop.
SystemGraph Bindings erstellen
Mit Bindings lassen sich Objekte aus der Szene im SystemGraph verwenden. So können beispielsweise Daten, der Transform eines Objekts oder darauf liegende Scripte und andere Components referenziert werden. Um ein Binding zu nutzen, muss dieses erst registriert werden. Das geschieht wie im folgenden Beispiel zu sehen:
Aufbaue des Beispielsystems
Da wir nun die grundlegenden Konzepte des SystemGraphs erläutert haben, schauen wir uns das Tool nochmal in Der Praxis an. Hierfür habe ich ein kleines Demo-Projekt entwickelt. Ziel war es, das Bycicle Kinematic Front Wheel Modell eines Fahrzeugs zu implementieren. Dazu findet ihr hier mehr Informationen. Zum groben Verständnis hier eine kleine Grafik, die das Modell anschaulich darstellt:
Um dieses Modell mithilfe des SystemGraphs zu implementieren, brauchte ich die folgenden Komponenten:
- Vehicle Controller
- Steering
- Engine
- KinematicBycicleModel
- BycicleStateViewer
All diese Komponenten stellen verschiedene Nodes mit unterschiedlichen In- und Ouputs und verschiedenen Modi dar. In der SystemGraph Ansicht sieht das ganze schlussendlich dann so aus:
Und hier zeigt sich klar die Stärke von Unitys SystemGraph. Denn diese Übersicht verstehen auch „Nicht-Programmierer“. Sie könnten jetzt beispielsweise die KinematicBycicleModel-Node mit einer anderen Node austauschen und so ein anderes Fahrzeugmodell testen, ohne in den Code gucken zu müssen. Lasst uns gemeinsam einmal die Nodes durchgehen, die in der Abbildung zu sehen sind.
VehicleController
Der VehicleController ist eine synchroner Node und gibt einfach jeden Tick die aktuelle Zeit des Systems weiter.
Engine
Die Engine-Node bekommt über das Binding _boundAccelerationControl eine Info darüber, wie die aktuelle Beschleunigung des Fahrzeugs ist. Diese kann durch Nutzer*innen über einen Tastendruck erhöht werden oder könnte alternativ von einem intelligenten System berechnet werden. Mithilfe einer Zustandstransferfunktion und dem Zeitunterschied zum letzten Durchlauf wird nun berechnet, wie sich die Beschleunigung auf die Geschwindigkeit ausgewirkt haben muss. Der Output der Node gibt diese Geschwindigkeit an die Node KinematicBycicleModel weiter.
Steering
Ähnlich aufgebaut ist auch die Steering-Node. Nur mit dem Unterschied, dass sie eine Änderungsrate des Lenkungs-Winkel bekommt und daraus die Stellung des Vorderrads berechnet. Sowohl Engine- als auch Steering-Node werden dabei vom VehicleController angesteuert. Dieser ist auf NodeTick.Synchronous gestellt und gibt jeden Durchlauf die aktuelle Zeit mit. Engine und Steering haben sich mit einer Callback-Funktion auf das ChangeEvent des Inputs currentTime registriert und führen so jeden Zeitschritt ihren Code aus.
KinematicBycicleModel
Diese Node ist dafür zuständig, den Folgezustand eines Systems anhand der verstrichenen Zeit und gewissen Input Daten zu berechnen. Sie bekommt als Input die aktuelle Zeit, die Geschwindigkeit des Fahrzeugs sowie die aktuelle Ausrichtung des Vorderrads. Eine Zustandstransferfunktion berechnet hier aus diesen Informationen und dem vorherigen Zustand den nächsten Zustand. Dieser wird über den Output der Node an die BycicleStateViewer-Node weitergegeben. Die KinematicBycicleModel-Node ist ebenfalls auf das ChangeEvent der currentTime registriert und führt den Zustandstransfer somit jeden Tick der VehicleController Node durch.
BycicleStateViewer Node
Mit vier Bindings ist die BycicleStateViewer-Node die am stärksten mit der Szene verbundene Node. Sie enthält Bindings auf Control-Skripte für das Komplette Fahrrad, das Vorderrad und einen Controler für einen LineRenderer sowie eine Textausgabe. Sie bekommt als Input den Zustand des Systems und passt Position und Rotation der einzelnen Komponenten entsprechend an. Zudem aktualisiert sie die Text-Komponente, die den Zustand des Fahrzeugs numerisch ausgibt und aktualisiert den LineRenderer, der den Pfad des Fahrzeugs darstellt.
Das Ganze sieht dann so aus:
Fazit: Ein Starkes Tool für detaillierte Emulationen
Der Unity SystemGraph ist auf jeden Fall ein starkes Tool, um komplexe Systeme sehr realitätsnah zu emulieren. Das in diesem Artikel beschriebene Projekt ist eigentlich viel zu simpel, als dass sich die Verwendung des SystemGraphs lohnen würde. Wer also nach einer Möglichkeit sucht, beispielsweise Sensorik oder Robotik wirklich detailliert zu emulieren und vor dem Bau ausgiebig zu testen, der sollte sich das Package auf jeden Fall mal anschauen. Insbesondere die SensorSDK liefert hier wirklich nützliche Nodes, um physikalisch nahezu korrekte Sensorik in das System zu integrieren.
Das Beispielprojekt zeigt außerdem, was der SystemGraph noch möglich macht. So ließen sich jetzt verschiedene Sensoren und neue SystemGraphen in die Szene einbauen. Mithilfe des SystemGraphs, der die Bewegung des Fahrzeugs beschreibt und der Sensoren könnten Entwickler*innen nun beispielsweise an Software-Lösungen arbeiten, die das Fahrzeug autonom um Objekte herum fahren lassen. Das Package eignet sich also nicht bloß zum testen von Systemen, sondern auch als eine Art Sandbox für die Erstellung von damit interagierenden Software-Systemen!
Flexibel einsatzbar dank Unity-Anbindung
Wer aber nach einer Möglichkeit sucht, Systeme lediglich zu simulieren und die physikalischen Mechanismen stark zu abstrahieren, der kann den SystemGraph zwar auf jeden Fall verwenden, ist aber mit anderen Tools mitunter besser beraten. Es gibt Tools, Packages und Bibliotheken, die sogenannte Discrete-Event-Simulations (DES) ermöglichen. Hier ist der Abstraktionsgrad deutlich höher und es kommen statistische Verteilungen zum Einsatz. Der SystemGraph dient in erster Linie der Emulation von Bauteilen. Hier muss wirklich alles selbst eingebaut werden. Wollt ihr beispielsweise den Mechanismus eines Förderbands in eure Simulation einbauen, müsst ihr dessen Logik und Funktion verstehen und selbst implementieren. Aber natürlich lassen sich auch mit Unity Discrete-Event-Simulations implementieren hier ließe sich der SystemGraph dann als einzelne Komponente verbinden. Das macht ihn zu einem so praktischen Tool. Durch die Unity-Integration haben Entwickler*innen hier viele Möglichkeiten – auch eine VR- oder AR-Anbindung ist denkbar.
Aktuelle Beiträge



Artikel kommentieren