Unity Game Engine- Wieso brauchen wir sie für das Testing?

Sicher – spannende Teilerfolge lassen sich verbuchen. Seien es Kopernikus Automotive mit dem Automated Valet Parking, zu dem ihr hier ein Interview findet, bei deren Tech-Demo auf der IAA Mobility 2021 man immerhin mal tatsächlich unbemannt fahrende Autos zu sehen bekam. Oder ELMO Rent aus Estland, die im ersten Schritt remote und im zweiten Schritt selbständig zum Kunden fahrende Mietfahrzeuge realisieren möchten. Vor allem in letzterem Beispiel zeigt sich auch eines der unübersehbaren Probleme der autonom fahren wollenden Branche auf: Wie entwickeln wir das autonome Fahrzeug? Wie testen wir diese Fahrzeuge, für deren eigenständig fahrendes Konzept unzählige Tests ebenso unzählige Verkehrssituationen simulieren müssen, damit das Fahrzeug lernen kann? Wie setzen wir das um, wenn das Fahren im echten Straßenverkehr doch schlichtweg unmöglich ist? Wie bekommen wir all die Verkehrssituationen, Sensoren, Künstliche Intelligenzen, das Auftreten schwer nachzustellender Situationen, unter einen Hut, der echtes Testing ermöglicht, und somit die Türe öffnet für den Fortschritt? Nicht umsonst ist das Motto der Cognizant Mobility: „Heute entwickeln und testen, was morgen auf der Straße fährt“. Aus diesem Motto ergibt sich ein zwingender Imperativ: Wir müssen testen, und zwar heute, sonst fährt morgen nichts.

Es braucht also Umgebungen, in denen die Automobilbranche testen kann. Umgebungen mit möglichst hohem Realitätsanspruch, mit bis ins kleinste Detail nachstellbaren Szenarios, damit K.I.s lernen können, Daten erfasst und ausgewertet werden können, damit Testing automatisiert werden kann, um vorwärtszukommen, buchstäblich und bildlich gesprochen. Hier kommt – nun endlich – die Unity Game Engine ins Spiel. Nun, genau genommen, diese und weitere Engines, die aus dem Spiele-Sektor hervorgingen und nun in der Lage sind, unsere Probleme zu lösen. Heute konzentrieren wir uns jedoch auf den Bereich der Unity Game Engine, haben dafür fachkundige Spezialisten befragt und präsentieren heute einen spannenden Artikel, der sich mit der Umsetzung von Entwicklungsansprüchen an virtualisierte Lösungen befasst.

Der Einsatz der Unity Game Engine im Testing

Die Automobilbranche stand, wenn es um die Entwicklung autonomer Fahrfunktionen geht, bislang ein wenig im Regen: Bevor etwas auf die Straße kann, muss es getestet werden. Testen müsste man ein Auto, das beispielsweise eine Gefahrensituation erkennen kann und bremsen soll, aber unter möglichst realistischen Bedingungen. Hier präsentiert sich die Unity Game Engine als Lösung: Mit den Erfahrungen der Spieleindustrie erstellen die Entwickler eine Simulationsumgebung. Die hierfür benötigten Daten müssen freilich zuerst gesammelt werden, beispielsweise durch Test-Set-Aufnahmen von echten Straßenverhältnissen. Diese Daten werden erfasst, und in der Folge wird damit ein Modell trainiert. Nach einer Segmentierung und Klassifizierung der Daten wird das Modell weiter evaluiert und mit Parametern gefüttert, so dass ein Unity Modell entstehen kann. Dieses Modell kann in Zusammenarbeit mit Szenario-Designern verfeinert werden, bis es allen Ansprüchen genügt: Wie soll die Umwelt aussehen? Wie viel Verkehr, welche Automodelle, Geschwindigkeiten, Straßenverkehrsordnung, Wetter – die Parameter sind unzählig und sollten im Vorfeld so detailliert wie möglich bestimmt werden; umso realistischer wird das Test-Szenario. Die Vorteile liegen auf der Hand: Alles kann eingepflegt, und, oft wichtiger, auch nachgepflegt werden. Regelrechte „DLC“s (Downloadable Content) sind analog zu den Gepflogenheiten der Spieleindustrie denkbar, die Funktionen, Parameter und Unity-Modelle nachreichen.

Interessierte können sich die Unity Game Engine zunächst also wie eine leere Bühne vorstellen: Im ersten Schritt erstellen Unity Designer mit dem Kunden die Landschaft, so wie sie für das Testing erforderlich ist. Allein dies ist als Startpunkt für erste Tests beinahe alternativlos. In weiteren Schritten lassen sich die Fahrzeugmodelle bis ins letzte Detail einpflegen – jeder Sensor lässt sich berücksichtigen, jede Funktion umsetzen und testen. Dies ermöglicht ein schnelles Identifizieren der für das Testing relevanten Testfälle und macht diese schneller optimierbar. Immerhin ist auch die richtige Frage wichtig, um eine gute Antwort zu erhalten, um es salopp zu formulieren: Je präziser die Anforderung, desto ergebnisreicher der Test. Testcases finden sich schneller, Testdatenbestände lassen sich effektiv bereinigen und last, but not least, kann sich der Triage-Prozess, der Ursachenfindungsprozess, dramatisch verkürzen. Und jeder Tester weiß: Entwicklungszeit ist bares Geld und besonders attraktiv, wenn sie sich verkürzen lässt, ohne qualitative Einbußen zu erfahren.

Beispiele für den Einsatz der Unity Game Engine in der Mobilitätsbranche

Das Testing, ob voll- oder teilautomatisiert (oder, im ungünstigsten Falle, manuell vorgenommen) bringt eines mit sich, und das sind Daten. Diese Daten müssen klassifiziert und evaluiert werden, und das beinhaltet die Fehlersuche. Klassische Kunden der Automobilindustrie benötigen für die Ursachenfindung bei aufgetretenen Fehlern in der Entwicklung im Schnitt 5-10 Tage. Während einfache Fehler schnell gefunden werden können, sind unübliche und kleine (aber dennoch relevante) Fehler oft der vielzitierten Suche nach der Nadel im Heuhaufen nicht unähnlich. Weist ein Fahrzeug einen Fehler auf, stellt sich die Frage, ob es am Fahrzeug liegt, am Programm, oder doch an der Schnittstelle? Auch das Testing autonomer Fahrfunktionen in einer eigens gebauten Unity-Umgebung setzt diesen Schritt voraus – jedoch nur einmalig. Die Fehlerursachen werden eingepflegt, so dass das System nach und nach lernt, und im Lauf der Zeit vorausschauend arbeiten kann. Durch bestimmte Algorithmen wie beispielsweise dem „One Nearest Neighbour“ (der auch in der Medizintechnik bereits erfolgreich von der Cognizant Mobility eingesetzt wurde), lernt das Trainingsmodell nach und nach, Fehler mit ähnlichem Muster zu identifizieren. An dieser Stelle empfehlen wir euch auch unseren Artikel zum Ticketvoranalyse-System „HEIDI“, das von den Data Science Experten rund um Dr. Daniel Isemann bereits seit geraumer Zeit erfolgreich im Einsatz ist.

Neben der Automobilbranche machen sich übrigens auch andere Zweige der Mobilität die Vorteile des Testings in der Unity Game Engine zunutze: Die Flugzeugtechnik ist hier federführend, denn sowohl Ausbildungen von Piloten als auch die gesamte Ausbildung für den Tower und ähnliche Spezialisierungen im Flugbetrieb werden seit Jahren fast vollständig in virtuellen Umgebungen, meist basierend auf der Unity Game Engine, abgewickelt.

Auch in der Automobilbranche macht das Sinn. Nach der Entwicklung riesiger, simulierter Städte ist es nur ein kleiner Schritt, echte Bilder, wie zuvor schon erwähnt aus Testlandschaften (z.B. Kreuzungen oder Straßenabschnitten) in Unity einzupflegen. Aus dem Spiel wird Realität, aus Unterhaltung wird Simulation, in der sich testen lässt. So lässt sich beispielsweise ein im Straßenverkehr aufgenommenes Video entweder direkt in das Unity-System einspielen oder auch über eine Schnittstelle aufnehmen. Der Vorteil scheint auch hier sofort ersichtlich: Die Daten können zunächst gesichtet und angepasst werden, und durch das direkte Aufspielen gibt es keine Verfälschungen mehr. Man verifiziert die Daten – das können auch zum Beispiel Rohdaten von Fahrzeug-Insassen und derem erwünschten Verhalten sein – manipuliert diese nach Wunsch und erfasst die Szenarien, nachdem die Kamera virtualisiert wurde. So bringt das Testing in der Unity Game Engine die Landschaft, das Fahrzeugmodell und den Fahrer zusammen, und komplexeste Test-Szenarien sind möglich, in der nun die gewünschten Daten erfasst werden können.

Hier steckt sicherlich auch die Herausforderung der Branche: Die erheblichen Datenmengen, die sich ergeben. Hier fährt kein Testfahrzeug über eine mit Sensoren ausgestattete Teststrecke, in der die Zeit gestoppt wird. In der simulierten, virtuellen Umgebung können Testfälle zu Tausenden durchgeführt werden, automatisierte Tests können beliebig oft laufen, parallel oder nacheinander, und durch ein trainiertes K.I.-Modell laufend angepasst werden. Daraus ergeben sich große Datenmengen („Big Data“), die verifiziert werden müssen. Die Tests müssen möglichst komplett automatisiert ablaufen, Repositorien wollen gebaut werden. Es ist beinahe Ironie, dass die größte Herausforderung unserer Zeit für das autonome Fahren kein Mangel, sondern ein Überschuss an Daten ist. Diese Daten auszuwerten und für den realen Straßeneinsatz zu optimieren, ist einer der wichtigsten Schritte.

Unity Game Engine und ihre Daten – Was ist möglich, was sind die Gefahren?

Eines der Probleme des Testings autonomer Fahrfunktionen, ob innerhalb oder außerhalb der Unity Game Engine, ist die fehlende Norm. Es gibt bis dato keine bestehenden, reellen Maßgaben, da es keine flächendeckende Kooperation der OEMs gibt, und viele Situationen sich nicht einfach bestimmen und katalogisieren lassen. Viele autonome Fahrfunktionen könnten bereits getestet werden, jedoch möchten viele Hersteller ihre eigenen Daten nicht herausgeben, auch nicht an kooperierende Marktbegleiter. Ein nötiger Schritt wird daher der Einsatz des Gesetzgebers und dessen Helfern wie dem TÜV sein.

Sicher, Referenz-Szenarien gibt es teilweise schon, wie zum Beispiel die großen Übungsgelände der DEKRA, die Autos autonom ohne Fehler fahren lassen und deren Daten virtualisieren. Alle Sensoren des Fahrzeugs, deren Daten aufgenommen werden müssen, können so ins Modell übertragen werden, nachdem das entsprechende Testfahrzeug eine Stunde fährt, alle Daten aufnimmt und das an die Unity-Schnittstelle sendet. So lassen sich technische Aspekte problemlos testen. Aber wie testen wir Sonderszenarien? Das klassische Beispiel, nicht nur beim autonomen Fahren, sondern allgemein beim Thema Künstliche Intelligenz, ist sicherlich jenes des autonomen Fahrzeugs, das in einer Gefahrensituation die Entscheidung treffen muss, ob eine alte Dame oder ein kleines Kind überfahren werden soll, da nur links oder rechts möglich ist. Wer entscheidet das und legt für derlei Situationen eine Referenz fest?

Auch muss jedes autonom fahrende Vehikel irgendwann manuell gesteuert werden – ein komplettes End-To-End-Fahren im komplett autonomen Fluss ist mehr als nur Zukunftsmusik. Was geschieht nun also, wenn der Fahrer in 30 Sekunden eingreifen muss, sein Zustand dies aber nicht zulässt, weil der Fahrer eingeschlafen ist oder das Bewusstsein verloren hat?

Dies sind Szenarien, die ohne eine virtuelle Umsetzung von Testszenarien in Game Engines nicht lösbar sind, da sie im realen Fall nicht getestet werden können. Soziologen sagen sicherlich „aus ethischen Gründen“, rein rechnerisch kommen diese Situationen indes gar nicht oft genug im realen Leben vor, um eine Relevanz für ein statistisches Test-Szenario haben zu können. Hier liefern die Datensammlungen der simulierten Umgebungen die nötige Vorarbeit und die Test-Gelegenheit für Szenarios, die sich im wahren Leben nicht testen lassen – auf die autonom fahrende Fahrzeuge aber zwingend vorbereitet sein müssen.

Was macht die Cognizant Mobility zum verlässlichen Partner im automatisierten Testing in der Unity Game Engine?

Schon in der Physik-Vorlesung lernt man, dass es nur eine Variable gibt – Sicherheit. Wer keine Sicherheit für seine Daten hat, kann nichts beweisen. Das gilt mehr denn je für das Testing autonomer Fahrfunktionen, auch, nein, gerade in virtuellen Umgebungen. Der erste Schritt erfolgreichen Testings ist daher immer die hundertprozentige Datenvalidierung. Vollständigkeit, Widerspruchsfreiheit, Zuverlässigkeit der Testfälle – dies sind elementare Bausteine erfolgreicher Testing-Projekte, die fehlerfrei, voll dokumentiert, immer gleich und wiederholbar aufgesetzt sind. Es gibt, anders als in der Schulaufgabe in Mathe, im Testing keine Punkte für „Folgefehler“: Findet ein Strukturbruch statt, steigt die Fehlerwahrscheinlichkeit, und mit ihr die Zahl schlechter Ergebnisse.

Erfahrungen im sorgsamen Umgang mit Daten und hocheffizientem Testing hat die Cognizant Mobility allemal. In Zusammenarbeit mit BMW arbeitet das Unternehmen seit Jahren mit ECU, einem Tool zur Steuerung von Testabläufen, hergestellt vom Unternehmen Tracetronic. Ein Test, beispielsweise ob ein Fahrer bremst oder beschleunigt, kann für jeden gewünschten Vorgang erstellt werden. Diese Testfälle lassen sich hintereinander schalten, und die Dateien lassen sich stets wiederverwenden, auch in virtuellen Umgebungen. So konnte die Cognizant Mobility sich schon vor geraumer Zeit für die Arbeit mit der Unity Game Engine qualifizieren. Auch im Bereich des K.I.-basierten Testings werden sich Synergien weiterentwickeln. Beispielsweise ist eine Funktion denkbar, die geeignete Testfälle auswählt, die Fehler eingrenzt (und ähnliche Fehler findet), oder die sogar nach einem Fehler in der Software einen eigenen Testfall schreiben könnte, damit dieser künftig besser getestet werden kann. Das geht bis zur kompletten Fehleranalyse durch die K.I., die in der Theorie Schlüsse ziehen könnte, ohne dass ein Repository (also eine Bibliothek) nötig wäre. Herrliche Zukunftsmusik, indes, denkbar, umsetzbar.

Der Vorteil liegt auch hier auf der Hand, zieht sich wie ein roter Faden durch den gesamten Artikel: Daten lassen sich erheben von Testfällen, die nicht länger auf reale Szenarien angewiesen sind, in denen Tests kaum, nicht oder zumindest nicht störungsfrei möglich sind. Diese Daten gehen in die Terrabyte, Petabyte gar, die aufgrund ihrer schieren Masse auch jeden Fehler vorkommen lassen, der nur denkbar ist: Umso wichtiger die gründliche und fehlerfreie Validierung aller Daten, um den Testfall effizient und aussagefähig zu gestalten. Was geschieht, wenn dies nicht der Fall ist oder nicht alle Eventualitäten berücksichtigt werden, waren die tragischen Unfälle der Firma Boeing. Dort wurden die Systeme natürlich gemäß der FAA-Vorgaben getestet, andernfalls wäre keine Zulassung erfolgt. Indes wurde der Fall eines kaputten Sensors nicht eingeplant, so dass weder im Testing noch im realen Geschehen eine Rettung aus dieser Situation möglich war. Wird im autonomen Fahrzeug der Fall „Großmutter oder Kind?“ nicht getestet, kann das Fahrzeug im reellen Einsatz nicht entscheiden und überfährt im schlimmsten Falle beide Passanten. An diese Fälle muss zwingend gedacht werden, und hierzu ist ein Partner erforderlich, der nicht nur über die Kompetenz auf Entwicklungsseite verfügt, sondern der im Bereich Testing weitreichende Erfahrungen besitzt und in der Automobilbranche verwurzelt ist. Gerne könnt ihr uns über unser Kontaktformular unter diesem Link jederzeit für erste Infos kontaktieren, oder auch unseren Newsletter abonnieren, um bei neuen Entwicklungen immer am Ball zu bleiben.

Die Cognizant Mobility arbeitet im Bereich des Testings autonomer Fahrfunktionen, auch in der Unity Game Engine, bereits seit vielen Jahren mit hochrangigen Kunden aus vielen Branchen zusammen. Darunter sind medizinische Player (die wir aus Datenschutzgründen an dieser Stelle leider nicht nennen dürfen) und Größen aus dem Automobilbereich von BMW bis Audi, von VW bis Aston Martin. Wir arbeiten im Bereich Connected Home, der Abnahme von Sensortechnik und natürlich der Forschung im Bereich autonomes Fahren.

Sicherlich – nicht alles davon ist hochkomplex, doch ist eine wichtige Erkenntnis, dass der erste Schritt nicht nur nötig ist, um sich zu bewegen, sondern auch um Erfahrung zu sammeln: Wer nicht weiß, was Statik ist, kann keine Brücke bauen, oder anders gesagt: Wer keine Erfahrung im Bereich Connected Home besitzt, wird sich auch mit Sensoren im Fahrzeug schwertun. Es fängt immer mit einem Sensor an, die Komplexität folgt aus der Anzahl der Sensoren – Connected Car ist am Ende die Königsdisziplin, in der viele praktische Tools rangieren, jedoch wenige Anbieter von Lösungen präsent sind. Der vielzitierte „Fool with a Tool“, der auf dem Holzweg ist, doch weiter hämmert, ist auch im autonomen Testing vorhanden, und um eines vorwegzunehmen: Oft sind das Pioniere, die man in der Branche dringend braucht. Irgendwann jedoch müssen Lösungen her, die ohne Standards nicht funktionieren und die von Testing-Experten vordefiniert werden müssen. Zu wissen, dass das Auto die Straße entlang muss, reicht nicht immer. Was für eine Straße haben wir vor uns? Was für ein Belag? Was für ein Wetter? Was passiert, wenn jemand Nägel auf die Straße schüttet? Nur mit der nötigen Erfahrung lassen sich die richtigen Fragen stellen.

Science Fiction: Werden wir Fahrzeuge, bis sie selbst fahren, von der Couch aus steuern?

Es klingt unglaublich verlockend – bis das autonome End-to-End-Fahren Wirklichkeit ist, lassen sich Fahrzeuge doch trotzdem via Remote steuern, und bei etwaig auftretenden Unwägbarkeiten sorgen virtuelle und umfangreiche Testing-Verfahren für die nötige Sicherheit. Steuere ich also vom Handy aus meinen LKW ins Zentrallager, und wenn jemand auf die Straße läuft, bremst der Laster automatisch? Klingt großartig!

Ein schönes und praktisches Beispiel dafür, dass nicht alles Zukunftsmusik ist, ist die „intelligente Achse“, die von Daimler im Bereich der Nutzfahrzeuge entwickelt wird und lange erforscht wurde. Das Konzept dahinter ist einfach: 10 LKWs werden mit einer intelligenten Software sowie einer elektronischen Achse ausgestattet und gekoppelt. Nur im ersten Fahrzeug sitzt ein Fahrer, der sein Fahrzeug steuert. Ihm fahren die anderen neun LKWs hinterher und machen, was der Leitwagen macht. Es ist also nur ein Steuergerät pro 10 Lastwagen nötig, eine Automatisierung ist schnell und effizient erreicht und wird die Straßen in naher Zukunft erreichen können. In einem nächsten Schritt könnte überlegt werden, ob ein Fahrer erforderlich ist oder, ähnlich dem eingangs erwähnten „ELMO Rent“ Konzept, eine Remote Steuerung denkbar ist.

Ähnliche Beispiele betreffen die Steuerung von Drohnen im Verbund, bei denen ebenfalls eine „Leitdrohne“ vorgibt, was die übrigen Geräte im Verbund nachahmen – eine erste Vision der komplett vernetzten Straße, in der alle Fahrzeuge zum gleichen Zeitpunkt identisch beschleunigen und rote Ampeln, sofern überhaupt noch notwendig, keine Nadelöhre in der Rush Hour mehr darstellen. Mit Voranschreiten der Virtualisierung, mit unbegrenzter Vernetzung (5G, 6G) und zeitverzugsloser Signalübermittlung werden Dinge möglich, die aktuell noch nach Science Fiction klingen, dies aber nicht bleiben werden.

Das automatisierte Testing solcher Funktionen in virtuellen Umgebungen ist dafür eine großartige, und zugleich unverzichtbare Vorstufe: Ohne Tests in simulierten Realitäten wird es nicht möglich sein, diese Visionen auf die Straße zu bringen. Deshalb arbeitet und forscht die Cognizant Mobility weiterhin in diesem Bereich und fordert euch auf, auf uns zuzukommen und mit uns gemeinsam ein Stück der virtuellen Straße entlangzugehen, ein Stücken in Richtung Zukunft zu schlendern, indem wir machen, was wir können: Gemeinsam entwickeln und testen, was morgen auf der Straße fährt.

Und wenn es bis dahin eine Runde „Landwirtschaftssimulator“ ist, sind wir natürlich auch dabei.