Deferred Renderingstellt eine Alternative zum traditionellen Forward Rendering dar. Beim Deferred Rendering muss durch die Trennung von Geometrieverarbeitung und Beleuchtungsberechnung während des Zeichnens der Szenengeometrie der Beleuchtung keine Aufmerksamkeit zugewendet werden [Har04, S. 2]. In Abbildung 2 wird der Ablauf des Deferred Shadings skizziert. Die Geometrieverarbeitung findet in der Geometriephase und die Beleuchtungsberechnung in einer separaten Beleuchtungsphase statt. In der Geometriephase werden alle für die Beleuchtungsberechnung notwendigen Daten der 3D-Szene im Geometrie Buffer (kurz: G-Buffer) gesammelt [BS13, S. 443] [Eng13, S. 101] [Ki11, S. 33]. Zu diesen Informationen gehören insbesondere die Position, die Normalen und die diffusen Farben [HH04, S. 7] [Ki11, S.33f.]. Diese Daten in Form von Texturen gespeichert. Die Beleuchtungsberechnung wird abgespalten und mit Hilfe des G-Buffers verzögert (engl. deferred) durchgeführt. Die Geometriedaten werden aus dem G-Buffer gelesen und die Shading-Operationen werden als Post-Prozess ausgeführt [Ki11, S. 33]. Da die Post-Prozess-Berechnungen nur auf den sichtbaren Teil der Szene begrenzt werden, werden keine unnötigen Berechnungen für verdeckte und nicht sichtbare Objekte durchgeführt [KRP11, S. 55] [MB05, S. 167]. 

Die Worst-Case-Laufzeit beträgt beim Deferred Shading O(n). Das Deferred Shading arbeitet für viele Lichtquellen und komplexe Szenen somit weitaus effizienter als das Forward Shading, das im Worst-Case eine Laufzeit von O(n²) aufweist [BS13, S. 443] [Har04, S. 6] [HH04, S. 4].

Bevor ein Fahrerassistenzsystem serienmäßig in Fahrzeugen verbaut wird, muss es getestet werden. Nur so kann eine korrekte Funktionalität sichergestellt werden.Tests in Form von Testfahrten mit realen Fahrzeugen, in denen das Fahrerassistenzsystem verbaut ist, sind aufwendig, kostenintensiv, abhängig von Witterung und Fahrzeugtypen und nur schwer reproduzierbar [Sch10, S. 5]. Für eine solche reale Testfahrt werden Hindernisse, Straßen, weitere Fahrzeuge und bestimmte Witterungsbedingungen benötigt, um eine reale Fahrsituation nachzustellen, die von den Sensoren aufgenommen werden kann [Sch10, S. 5f.]. "Darüber hinaus ist der Test solcher Systeme im öffentlichen Verkehrsraum mit nicht unerheblichen Gefahren verbunden, da eine Fehlfunktion eines Assistenzsystems zu Situationen führen kann,die der menschliche Fahrer nicht mehr beherrschen kann" [Sch10, S. 5]. Dies gilt auch für geübte Testfahrer [Sch10, S. 5]. Um diese Nachteile zu umgehen, wird auf angemessene Testsysteme zurückgegriffen (vgl. Anhang A.1, Frage 7). Ein solches Testsystem greift in den meisten Fällen auf die HIL-Simulation zurück. HIL ist die Abkürzung für Hardware-in-the-Loop und bedeutet, dass reale Hardwarekomponenten in eine simulierte Umgebung eingebunden werden [Sch10, S. 12] [Sch10, S. 75f.]. Abbildung 3 zeigt die Übersicht einer HIL-Simulationsumgebung. Die reale Hardwarekomponente (auch Echtteil genannt), die an die Simulator-Hardware (kurz: Simulator) angeschlossen wird, ist durch den roten Kasten unten rechts dargestellt und kann zum Beispiel ein Fahrerassistenzsystem sein. Der Simulator wird durch die gestrichelte Linie angedeutet. Er enthält Informationen über die Simulation. Unter anderem gehören dazu Informationen über Verkehrsszenarios, die Fahrzeugdynamik und die Sensormodelle (alle durch grüne Rechtecke dargestellt). Die letzte Komponente, die als blauer Kasten dargestellt wird, besteht aus einem oder mehreren Host-PCs, die zur Hardware-Steuerung und zur Visualisierung dienen.

Kamerasysteme sind Sensoren, die für die Umsetzung der Erkennensaufgabe genutztwerden [Nen14, S. 14]. Beispiele für kamerabasierte Fahrerassistenzsysteme sind Fahrspur-, Fahrzeug-, Fußgänger- und Verkehrszeichenerkennung [Nen14, S. 14]. Abbildung 4 zeigt die Vorgehensweise eines kamerabasierten ADAS. Zunächst wird mit Hilfe der Kamera ein Bild aufgenommen. Nach der Aufnahme des Bildes ist eine Echtzeitbildverarbeitung notwendig, mit der Objekte erkannt und getrackt werden können. Die Trackingdaten werden anschließend von an ein Regelalgorithmus weitergeleitet, der diese auswertet und ggf. eine Reaktion einleitet (z.B. Notbremsung) indem Steuersignale an angeschlossene Aktuatoren (z.B. Bremse) gesendet werden [Mey12, S. 335]. 

Eine Erschwerung der Erkennungsaufgabe entsteht durch die Lichtbedingungen. Je nach Tageszeit und Wetterbedingung herrschen unterschiedliche Lichtverhältnisse. Es kann zum Beispiel zu starkem Schatten oder veränderter spektraler Strahlung des Sonnenlichts kommen. Auf diese muss bei der Bildverarbeitung reagiert werden [Nen14, S. 31]. Es muss sichergestellt werden, dass solche Veränderungen nicht zu einer Fehlinterpretation führen, bei der zum Beispiel weitere Objekte identifiziert werden.

Bei kamerabasierten ADAS-Tests mit HIL-Simulatoren ist das angeschlossene Echtteil das kamberabasierte Fahrerassistenzsystem. Abbildung 6 zeigt den schematischen Aufbau einer HIL-Simulation zum Testen von kamerabasierten Fahrerassistenzsystemen. Es besteht aus einer echtzeitfähigenSimulator-Hardware (kurz: Simulator; grün) mit angeschlossenem Steuergerät inklusive Kamerasensorik (rot) und einem oder mehreren Host-PCs für die Hardwaresteuerung und das Rendering bzw. die 3D-Visualisierung (blau). Während des Testdurchlaufs wird mit Hilfe eines Host-PCs eine Testszene dargestellt, die vom Simulator mit Hilfe der Kamera aufgenommen und anschließend vom Steuergerät verarbeitet wird. Basierend auf den aufgenommenen Daten berechnet der Simulator Fahrverhalten und Fahrmanöver in Echtzeit, die wiederum über die 3D-Visualisierung ausgegeben werden.

Es ist wichtig, dass die Visualisierung in Echtzeit und mit möglichst geringer Latenz umgesetzt wird, damit die Informationen, die über die Kamera aufgenommen werden, zeitlich exakt mit den anderen Informationen, welche dem System zugeliefert werden,korrelieren [dSP14, S. 48] [NFHS12, S. 14]. Das von der Kamera aufgenommene Bild wird von der IPU verarbeitet und sendet die Trackingdaten der erkannten Objekte wiederum an den Simulator oder an eine ECU, die diese Daten verarbeiten.Falls vorhanden, wird die ECU an den Simulator angeschlossen. Hierdurch wird der Regelkreis geschlossen.Die Visualisierung ist somit ein Teil der Simulation. Folglich bestimmt die Qualität des Renderings die Aussagen über die korrekte Funktionalität des Systems. Über die Visualisierung werden unterschiedliche Umgebungsbedingungen, die in einer echten Fahrsituation gegebenenfalls zu Störfaktoren werden, simuliert.

Ein Beispiel für ein Fahrerassistenzsystem, das Kameradaten verwendet, ist das Bremsassistenzsystem mit Fußgängererkennung. "Zahlreiche Untersuchungen haben ergeben, dass Normalfahrer in Schrecksituationen nur zögerlich bremsen, also die volle Betätigung der Bremse und damit ggf. die erforderliche Bremswirkung erst zeitversetzt einsetzt" [Geb10, S. 94]. Ein Bremsassistenzsystem mit integrierter Fußgängererkennung soll eine solche Verzögerung vorbeugen. Es soll den Fahrer zum einen beim Erkennen von Notsituationen unterstützen und so die Reaktionszeit verkürzen und zum anderen die Stärke der Bremsung in Notsituationen anpassen.