Framework zur Entwicklung, Bewertung und Analyse von Computer-Vision-Anwendungen im Kontext umfelderfassender Fahrerassistenzsysteme

Größe: px
Ab Seite anzeigen:

Download "Framework zur Entwicklung, Bewertung und Analyse von Computer-Vision-Anwendungen im Kontext umfelderfassender Fahrerassistenzsysteme"

Transkript

1 Framework zur Entwicklung, Bewertung und Analyse von Computer-Vision-Anwendungen im Kontext umfelderfassender Fahrerassistenzsysteme Dissertation zur Erlangung des Grades eines Doktor-Ingenieurs der Fakultät für Elektrotechnik und Informationstechnik an der Ruhr-Universität Bochum Vorgelegt von Johannes Stallkamp geboren in Georgsmarienhütte 8. Oktober 2014 Berichter: Prof. Dr. Gregor Schöner PD Dr. Rolf Würtz

2 2

3 Inhaltsverzeichnis 1 Einleitung Computer Vision Anwendungsgebiete der Computer Vision Sicherheit im Straßenverkehr Problemstellung Beitrag dieser Arbeit Aufbau dieser Arbeit Fahrerassistenzsysteme Fahraufgabe Fahrprozess Definition des Begriffs Fahrerassistenzsystem Umfelderfassung im Fahrzeug Sensoren zur Umfelderfassung Fazit Evaluierung im Entwicklungsprozess Ziele der Evaluierung Das allgemeine V-Modell V-Modell zur Entwicklung von Fahrerassistenzsystemen Fazit Struktur und Anforderungen der Evaluierung Makromodell zur Systembewertung Bewertungsszenarien Anforderungen an den Evaluierungsprozess Eingabedaten Referenzdaten Bewertungsverfahren Fazit Anforderungen an das Framework Aufgabenübergreifendes Rahmensystem Aufgabenspezifische Anforderungen Nutzerprofile Integration von Algorithmik Erfassung und Bereitstellung der Sensordaten i

4 Inhaltsverzeichnis 5.6 Erzeugung und Bereitstellung der Referenzdaten Integration von Bewertungsverfahren Fazit Die Entwicklungs- und Analyseumgebung ADAF Designziele Modulbasierte Architektur Datenfluss Datenerfassung und -wiedergabe Annotation Integration von Algorithmik Bewertung Gesamtbetrachtung Technische Realisierung Fazit Anwendungsfälle Aufnahme bei hoher Datenrate und Sensordatenfusion Automatisierung der Annotation Evaluierung einer Fahrspurerkennung Machbarkeitsstudie zur Übertragbarkeit von vorhandenen FAS auf Motorräder Exemplarische Realisierung eines Spurhalteassistenten Fazit Erstellung eines Verkehrszeichenbenchmarks Motivation Benchmarkdesign Erstellung des Datensatzes Der Datensatz Verwendung des Datensatzes Fazit Fazit 163 A Lebenslauf 167 ii

5 Abkürzungen ABS Antiblockiersystem ACC Abstandsregeltempomat (Adaptive Cruise Control) ADAF Advanced Development & Analysis Framework ADAS Advanced Driver Assistance System ADASIS Advanced Driver Assistance Systems Interface Specification CAN Controller Area Network. Feldbus CMOS Complementary Metal Oxide Semiconductor CoP Code of Practice CSV Comma-separated Values. Dateiformat CV Computer Vision DAS Driver Assistance System DGPS Differential Global Positioning System ESP Elektronisches Stabilitätsprogramm FAS Fahrerassistenzsystem FIR Ferninfrarot FOT Feldversuch (Field Operational Test) fps Bilder pro Sekunde (frames per second) GPS Global Positioning System GT Ground Truth GTSDB German Traffic Sign Detection Benchmark GTSRB German Traffic Sign Recognition Benchmark HDF Hierarchical Data Format. Dateiformat HOG Histogram of Oriented Gradients iii

6 Inhaltsverzeichnis IJCNN IEEE International Joint Conference on Neural Networks JNI Java Native Interface LCA Spurwechselassistent (Lane Change Assistant) LDW Spurverlassenswarner (Lane Departure Warning) Lidar Light Detection and Ranging LKA Spurhalteassistent (Lane Keeping Assistant) LRR Fernbereichsradar (Long Range Radar) MAE Mittlerer absoluter Fehler (Mean Absolute Error) MMI Mensch-Maschine-Interaktion NIR Nahinfrarot PPM Portable Pixmap. Dateiformat Radar Radio Detection and Ranging RGB Red-Green-Blue. Farbraum RMSE Wurzel des mittleren quadratischen Fehlers (Root Mean Square Error) ROI Region of Interest SIL Software-in-the-loop SRR Nahbereichsradar (Short Range Radar) SUT System unter Test SWIG Simplified Wrapper and Interface Generator ToF Time-of-Flight TRS Traffic Simulation TSR Verkehrszeichenerkennung (Traffic Sign Recognition) USB Universal Serial Bus XML Extended Markup Language. Dateiformat iv

7 Abbildungsverzeichnis 1.1 Visuelle Wahrnehmung scheint für den Menschen sehr einfach zu sein Getötete bei Verkehrsunfällen in Deutschland Der Fahrprozess als primäre Fahraufgabe Fahrzeugumfeld nach Fahrsituationen Assistenzsysteme für Nachtfahrt Spurwechselassistent Lidar-Systeme Mit ToF-Kamera erfasste Szene Videokamera Delphi IFV-200 mit integrierten Assistenzfunktionen Allgemeines V-Modell Iterative Anwendung des V-Modells Angepasstes V-Modell V-Modell zur Entwicklung der Softwareanteile am Gesamtprojekt Makromodell zur Systembewertung Verschiedene Verkehrssituationen Synthetische Verkehrsszenen unterschiedlicher Komplexität Einbettung des Testobjekts in den Testrahmen Beispiel für das Zeitverhalten unterschiedlicher Sensoren Beispielhafte Darstellung der ADAF-Benutzeroberfläche Ein Verarbeitungsplugin mit einem Eingang und vier Ausgängen Interaktive Verknüpfung von Plugins Die Konfiguration der Plugins erfolgt im Fenster Plugin Properties Datenflussgraph im ADAF Abhängigkeitsgraph für die Applikation in Abbildung Serialisierung parallel erfasster Sensordaten in ADAF Verarbeitung von aufgezeichneten Datenpaketen Definition von zwei Annotationsattributen in XML Benutzeroberfläche des globalen Annotationsplugins Benutzeroberfläche des intervallbasierten Annotationsplugins Objektbasierte Annotation mit synchronisierten Sensordaten Plugin als Adapter zwischen ADAF und Algorithmus Wichtige Schnittstellen v

8 Abbildungsverzeichnis 6.15 Verarbeitung von Daten mehrerer Sensoren Einbindung und Konfiguration von Evaluatoren Darstellung von Ergebnissen als Zeitreihendiagramm Darstellung von Ergebnissen als Tabelle Realisierung des Testrahmens in Abbildung 5.1 durch Plugins Automatisierte Annotation Kontrolle und Korrektur der Ergebnisse Visualisierung von Tracks als Trajektorie Visualisierung der detektierten Fahrspur im Kamerabild Plugingraph zur Bewertung der Fahrspurerkennung Zeitreihendiagramm der Spurkrümmung Ergebnisdarstellung mit Result Table Display-Plugin In ADAF geladene Sequenzliste der problematischen Streckenabschnitte BMW K1600 GT mit Aufzeichnungssystem Korrekturrotation des Kamerabildes auf Basis des Rollwinkels Ausschnitt aus dem Plugingraph Durch Windschild verursachte Unschärfen im Randbereich Bewegungsunschärfe durch Vibration des Motorrads in der Dämmerung Regelkreis Fahrer(assistenzsystem) Fahrzeug Umwelt Konkretisierungen des Regelkreises Verarbeitungskette des LKA-Systems Größen zur Bestimmung der Bildzeile abhängig von der Vorausschauweite Grafische Darstellung des Messbereichs und der detektierten Abweichung Vergleich der lateralen Position des Fahrzeugs Vergleich des Lenkwinkels Einige Beispiele Ein Verkehrszeichentrack Aufteilung des Datensatzes Verzeichnisstruktur der Teildatensätze Beispielbilder aus den Videodaten Aufnahmeszenario in ADAF Objektbasierte Annotation von Verkehrszeichen in ADAF Applikationsprofil zur Extraktion der Einzelbilder Verkehrszeichenklassen im GTSRB Relative Klassenhäufigkeiten im Datensatz Datensatz für Runde 1 des GTSRB-Wettbewerbs Konfusionsmatrix auf der Webseite zur Analyse der Ergebnisse Projektion des HOG 1 Trainingsdatensatzes auf die ersten zwei Hauptkomponenten GTSRB-Webseite vi

9 Tabellenverzeichnis 2.1 Eigenschaften von Umfeldsensoren Vergleich von realen und synthetischen Daten Zu unterscheidende Fälle bei der Verwendung mehrerer Sensoren Verfügbare Attributstypen zur Annotation Konfigurationsmöglichkeiten für Annotationattribute Übersicht über die wichtigsten Ereignisse Genauigkeit der Fahrspurerkennung Analyse der Zeitabschnitte ohne Spurschätzung Verwendete Sensorik Erkennungsraten der Verkehrszeichenerkennung für gemeinsam befahrene Streckenabschnitte Verfügbarkeit der Fahrspurerkennung Bewertung des Spurhalteassistenten für z = 15 m vii

10

11 1 Einleitung 1.1 Computer Vision Dem Menschen fällt die Beschreibung eines Bildes in der Regel sehr leicht. Selbst komplexe Hintergründe, teilweise Verdeckungen oder Reflexionen bereiten einem menschlichen Betrachter selten Schwierigkeiten bei der Bestimmung und Abgrenzung einzelner Objekte oder der Interpretation der Gesamtszene (s. Abbildung 1.1). Er kann abgebildete Personen benennen und deren Gesichtsausdruck deuten. Dies mag Marvin Minsky zu der Einschätzung verleitet haben, dass es sich bei der visuellen Wahrnehmung um ein einfaches Problem handelt. Schließen Sie eine Kamera an einen Computer an, und bringen Sie ihn im Laufe des Sommers dazu, zu beschreiben, Abbildung 1.1: Visuelle Wahrnehmung scheint für den Menschen sehr einfach zu sein. Problemlos kann die abgebildete Szene detailliert beschrieben werden: Es handelt sich um eine Innenstadtszene mit mind. acht Fußgängern. Rechts befindet sich ein Schaufenster mit einer Schaufensterpuppe, aber es spiegeln sich auch manche Fußgänger in der Glasscheibe. Der Bereich vor dem Schaufenster ist überdacht. Eine Person außerhalb des Aufnahmebereichs verursacht einen Schattenwurf. Im Hintergrund sind ein Auto, ein Mülleimer, zwei Bäume und eine Straßenlaterne zu erkennen. (Das Bild entstammt dem Datensatz zu [ELV07].) 1

12 1 Einleitung was er sieht. Mit ähnlichen Worten könnte der Gründer der Arbeitsgruppe Künstliche Intelligenz am MIT im Jahr 1966 seinen Studenten Gerald Sussman aufgefordert haben, das Problem der visuellen Wahrnehmung durch Computer zu lösen [Cre93, S. 88]. Es wurde seinerzeit nur als einfache Vorstufe für nachfolgende höhere Prozesse wie Verhaltensplanung oder Schlussfolgern erachtet [Sze11, S. 11]. Die damalige Aufgabenstellung sah vor, innerhalb von zwei Monaten a significant part of a visual system [Pap66, S. 1] zu erstellen. Dieses System sollte in der Lage sein, auf Basis eines Vokabulars bekannter Objekte ebendiese in Bildern zu identifizieren. Ausgehend von einfarbigen geometrischen Figuren sollten im zweiten Teil des Projekts auch schwierigere Gegenstände wie Tassen oder Werkzeuge vor komplexen Hintergründen erkannt werden. Die Tatsache, dass sich letztlich nicht Sussman allein, sondern eine von ihm koordinierte Gruppe von Studenten der Aufgabe widmete 1, mindert den Ehrgeiz dieses Projekts nicht. In den vergangenen knapp 50 Jahren hat sich die Einschätzung der Schwierigkeit dieser Aufgabe jedoch geändert. Um die Fragestellung der visuellen Wahrnehmung durch Computer ist ein großes, stetig wachsendes Forschungsfeld mit zahlreichen Anwendungsgebieten entstanden. Aus heutiger Sicht ist es daher wenig überraschend, dass das Projekt scheiterte und die Aufgabe im vorgegebenen Zeitraum nicht gelöst werden konnte (Sussman in [Cre93, S. 88]: We couldn t. ). Ein umfassender Überblick über die Geschichte der Computer Vision findet sich in [Sze11]. 1.2 Anwendungsgebiete der Computer Vision Methoden der Computer Vision kommen heute in vielen Bereichen zur Anwendung und werden dabei mit einem breiten Spektrum unterschiedlicher Randbedingungen konfrontiert. In industriellen Anwendungen werden sie eingesetzt zur Detektion von Defekten, zur Qualitätskontrolle oder zur Sortierung von Gütern wie Obst oder Postsendungen. Dies stellt einerseits hohe Anforderungen an die Verarbeitungsgeschwindigkeit und Zuverlässigkeit der Erkennung, ermöglicht aber im Gegenzug eine hohe Kontrolle über die Aufnahmesituation (Kameraposition, gleichmäßige Beleuchtung, Hintergrund). In Sicherheitsanwendungen ermöglicht Computer Vision Zugangskontrollen durch die Erkennung von Gesichtern oder Fingerabdrücken. Diese Anwendungen erfordern ebenfalls eine hohe Zuverlässigkeit, um unerlaubten Zutritt zu kritischen Bereichen erfolgreich zu verweigern, gleichzeitig allerdings den Zugang für berechtigte Personen zu garantieren. Zusätzlich müssen Betrugsversuche, z. B. durch Verwendung eines Fotos zum Vortäuschen einer anderen Identität, zuverlässig erkannt werden. Im Sport ermöglichen Computer Vision-Methoden die individuelle Bewegungsanalyse und Trainingsoptimierung, aber auch die Analyse von Teamsportarten wie Fußball. Besondere Herausforderungen stellen hierbei die Erkennung und die Verfolgung einer hohen Anzahl unabhängiger Objekte und Personen dar (Spieler, Schiedsrichter und Ball), was der Lösung von Verdeckungs- und Zuordnungsproblemen bedarf [SSTI14]. 1 In [Pap66] lassen sich 11 Teilnehmer identifizieren. 2

13 1.3 Sicherheit im Straßenverkehr In der medizinischen Bildverarbeitung werden Anomalien auf Basis von bildgebenden Verfahren wie Computertomographie (CT), Magnetresonanztomographie (MRT) oder Ultraschall erkannt. Die Verknüpfung (sog. Registrierung) präoperativ angefertigter, hochauflösender CT- oder MRT-Bilder mit während der Operation erfassbaren Ultraschallbildern ermöglicht eine präzise Lokalisierung und Navigation und unterstützt Chirurgen so während der Operation [DRW12]. Methoden der Computer Vision werden auch zur Mensch-Maschine-Interaktion (MMI) verwendet. Die Erkennung von Gesten oder Körperhaltung wird zur Steuerung von Geräten oder zur Interaktion mit Robotern eingesetzt. Die Detektion von Gesichtern erlaubt beispielsweise während einer Videokonferenz die Verfolgung des Nutzers durch eine schwenkbare Kamera. Mit Hilfe von Gesichtserkennung kann eine alternative Authentifizierung beim Zugriff auf Geräte umgesetzt werden. Die Erkennung des Gesichtsausdrucks erlaubt es z. B. bei Digitalkameras, eine Aufnahme automatisch auszulösen, sobald die Person im Bild lacht. Im Bereich der autonomen Robotik ermöglicht Computer Vision die Navigation und die Manipulation der Umgebung. Serviceroboter nutzen diese Fähigkeiten, um im Haushalt zu helfen oder vor allem ältere Menschen im Alltag zu unterstützen. Rettungsroboter werden in Katastrophensituationen zur Suche nach Opfern eingesetzt. Beim Einsatz autonomer Roboter sind die Umgebungsbedingungen nicht oder nur begrenzt kontrollierbar. Dies betrifft einerseits Aufnahmebedingungen wie die Beleuchtung, vor allem aber den Aufbau und die Komplexität des Umfelds sowie die dazu gehörenden Objekte. Für den Menschen ist es kein Problem, sich in einer neuen Umgebung zu bewegen oder unbekannte Gegenstände zu erkennen und zu greifen. Auch die Klassifizierung eines Gegenstandes ist für Menschen trotz zahlreicher möglicher Erscheinungsformen (z. B. von Stühlen oder Gläsern) in der Regel problemlos möglich. Sie verlassen sich dabei primär auf ihre visuelle Wahrnehmung. Für Computersysteme stellt dies auch bei Verwendung von Computer Vision-Verfahren weiterhin eine große Herausforderung dar. Auch im Straßenverkehr verlässt sich der Mensch auf seine Sehfähigkeiten. Kommt es dabei jedoch zu Wahrnehmungsfehlern, kann daraus resultierendes Fehlverhalten leicht Menschenleben gefährden. Im folgenden Abschnitt wird näher darauf eingegangen, wie Computer Vision zur Erhöhung der Sicherheit im Straßenverkehr beitragen kann und welche Herausforderungen dabei zu bewältigen sind. 1.3 Sicherheit im Straßenverkehr Durch technische Weiterentwicklung des Automobils ist die Zahl der Verletzten und Verkehrstoten in den letzten 30 Jahren trotz steigender Zulassungszahlen kontinuierlich gesunken (s. Abbildung 1.2). Dennoch starben in Deutschland 2010 im Straßenverkehr noch Personen und Personen wurden verletzt [StBA11]. Hauptursache für Unfälle ist der Mensch wurden nur knapp 1 % der Unfälle durch technische Mängel verursacht, jedoch 84 % durch Fahrzeugführer [StBA11]. Dazu zählen unangepasste Geschwindigkeit, fehlerhaftes Abbiegen und unzureichender Abstand zum Vorausfahrenden. Knapp 4 % der Unfälle sind dem Fehlverhalten von Fußgängern 3

14 1 Einleitung Personen Abbildung 1.2: Getötete bei Verkehrsunfällen in Deutschland je zugelassener Kraftfahrzeuge (Daten aus [StBA11]). Anmerkung: Im Jahr nach der Wiedervereinigung (1991) weist die Statistik einmalig einen deutlich geringeren Kfz-Bestand aus, während die Zahl der Getöteten gleichzeitig leicht anstieg. Jahr zuzuschreiben, die übrigen 12 % der Witterung, den Straßenverhältnissen sowie sonstigen Hindernissen wie z. B. Wild auf der Fahrbahn. Auch in diesen Fällen obliegt es dem Fahrer, die Situation zu erkennen und rechtzeitig zu reagieren. Wahrnehmung und Kognition kommen für das Sicherheitsverhalten des Fahrers daher eine zentrale Bedeutung zu [Coh09]. Wahrnehmungsfehler fehlende oder verspätete Wahrnehmung oder Fehlwahrnehmung und daraus resultierendes Verhalten haben großen Anteil an den Unfallursachen [Nag78]. Zusätzlich erhöht der Zeitdruck in kritischen Situationen die Wahrscheinlichkeit für Fehlentscheidungen [Coh09]. Mit Blick auf den demografischen Wandel ist auch zu berücksichtigen, dass die Zahl älterer Verkehrsteilnehmer in Zukunft steigen wird. Gerade ältere Fahrzeugführer über 65 tragen bei Unfallbeteiligung in zwei Drittel der Fälle die Hauptschuld [StBA11]. Auch hier sind Wahrnehmungsfehler sowie reduzierte Reaktionsgeschwindigkeit mitentscheidend [KJ09]. Im Jahr 2001 hat die Europäische Kommission im Weißbuch zur europäischen Verkehrspolitik [Eur01] das Ziel ausgerufen, innerhalb der nächsten zehn Jahre die Zahl der Verkehrstoten ungefähr zu halbieren. Laut der europäischen Unfalldatenbank CARE wurde dieses Ziel erreicht. Die Zahl der Verkehrstoten sank von im Jahr 2000 auf im Jahr 2010 [Eur13]. Im neuen Weißbuch [Eur11] wurde diese Zielsetzung für den Zeitraum bis 2020 bekräftigt (Halbierung im Vergleich zu 2011). Bis 2050 soll die Zahl auf nahe Null reduziert werden. Einen entscheidenden Beitrag zur Erreichung dieser Ziele leistet die Weiterentwicklung der Sicherheitssysteme im Fahrzeug. Systeme der passiven Sicherheit wie z. B. Airbags und Sicherheitsgurte mit Gurtstraffer mindern die Folgen eines Unfalls. Zukünftig spielen verstärkt Systeme der aktiven Sicherheit wie z. B. Fahrerassistenzsysteme eine entscheidende Rolle, da sie helfen, kritische Situationen und Unfälle zu vermeiden. Diese technischen Systeme erfassen und überwachen das Umfeld des Fahrzeugs mit vielfältiger Sensorik und können so den Fahrer unterstützen, warnen und entlasten. Prinzipiell sind sie in der Lage, die Verkehrssituation kontinuierlich zu beobachten. Sie leiden 4

15 1.4 Problemstellung nicht wie ein menschlicher Fahrer unter Übermüdung, Konzentrationsschwächen oder Ablenkung. Je nach Art und Anzahl der verwendeten Sensoren haben sie ein größeres Sichtfeld als der Fahrer. Systeme, die in kritischen Situationen in die Fahrzeugsteuerung eingreifen, können schneller und präziser reagieren als ein menschlicher Fahrer. Voraussetzung für den Erfolg solcher Systeme sind die korrekte Wahrnehmung und Analyse des Umfelds und die richtige Bewertung der Situation. Der Mensch orientiert sich primär visuell. Daher sind auch essenzielle Teile des Straßenverkehrs auf visuelle Wahrnehmung ausgelegt, z. B. kontrastreiche Fahrbahnmarkierungen (in Deutschland standardmäßig weiß, in Baustellenbereichen zur Verdeutlichung der Sonderregelung gelb), hochreflektierende Verkehrsschilder in Signalfarben und klaren geometrischen Formen oder Ampeln. Auch Signalgeber wie Heck- und Bremsleuchten dienen ausschließlich der visuellen Information der folgenden Fahrzeuge. Für die Wahrnehmung des Fahrzeugumfelds und der Verkehrssituation durch technische Systeme kommt daher der Verwendung von Kameras und Methoden der Computer Vision zur Interpretation der Daten eine besondere Bedeutung zu. Sie werten prinzipiell dieselbe Information aus, die auch einem menschlichen Fahrer innerhalb des Sichtfelds zur Verfügung steht. Sie ermöglichen auf Basis eines einzelnen Sensors die Erkennung einer Vielzahl unterschiedlicher Objekte und Elemente und eröffnen so zahlreiche Anwendungsfelder wie Spurverlassenswarnung, Verkehrszeichenerkennung oder Fernlichtassistenz (s. Abschnitt 2.4). Die Verwendung von Computer Vision für Fahrerassistenzsysteme ist herausfordernd, da diese Systeme in der natürlichen Umwelt und unter unkontrollierten Bedingungen operieren müssen [Kom08]. Dies betrifft vor allem die Umweltbedingungen (Witterung und Lichtverhältnisse), aber auch die Konstellation der zu analysierenden Szene. Dazu zählen Art und Beschaffenheit der Straße, die Bebauung oder die Vegetation. Auch auf die Anzahl, Art und Erscheinungsform sowie das Verhalten anderer Verkehrsteilnehmer kann kein Einfluss genommen werden. Diese Komplexität der natürlichen Umwelt führt auch dazu, dass heutige Fahrerassistenzsysteme den Fahrer noch nicht kontinuierlich in jeder Situation unterstützen können. Der Einsatz beschränkt sich auf eng umrissene Einsatzbereiche [Ren09]. Unter Umständen schaltet sich ein System zeitweise ab oder unterdrückt die Systemausgabe, um Fehlwarnungen oder Fehlinformation des Fahrers zu vermeiden. 1.4 Problemstellung Die Entwicklung neuer Fahrerassistenzsysteme wird schrittweise zu einer immer besseren und umfangreicheren Unterstützung des Fahrers führen bis hin zum vollständig autonomen Fahren. Sowohl während als auch nach Abschluss der Entwicklung einer neuen Fahrerassistenzfunktion muss die Zuverlässigkeit des Systems sichergestellt werden. Dazu muss es in Teilen und seiner Gesamtheit ausführlich getestet und bewertet werden. In Anbetracht der Komplexität der natürlichen Umwelt spielt dabei vor allem die Frage der Kontrollierbarkeit und Nachvollziehbarkeit des Entwicklungs- und Bewertungsprozesses eine entscheidende Rolle. 5

16 1 Einleitung Für Fahrerassistenzsysteme ist die Wahrnehmung also die Erfassung und Interpretation des Fahrzeugumfelds von zentraler Bedeutung. Abhängig von der Funktion variiert sowohl die Anzahl als auch die Art der eingesetzten Sensoren. Bei der Erhebung von Testdaten erzeugen datenintensive Sensoren wie Kameras einen großen Speicherbedarf. Die Komplexität und Vielfältigkeit der natürlichen Umwelt bedingt einen hohen Testbedarf für neue Systeme. Um eine ausreichende Abdeckung relevanter Situationen sicherzustellen, sind große Mengen an Testdaten erforderlich. Selbst größte Datenbestände können die Realität dabei nur begrenzt abbilden, weswegen der Definition relevanter Situationen eine besondere Bedeutung zukommt. Die Verwendung von Sensordaten für Test und Bewertung erfordert die Verfügbarkeit von Referenzdaten, die die erwarteten Ergebnisse (z. B. Objektpositionen) repräsentieren. Die Erzeugung dieser Daten (sog. Annotation) ist sehr aufwendig. In Anbetracht der benötigten Menge an Testdaten ist ein effizientes Werkzeug nötig, das diesen Aufwand beherrschbar macht. Neben der umfangreichen Annotation führt die Größe des erforderlichen Datenbestands auch dazu, dass eine vollständige Verarbeitung sehr zeitaufwendig ist. Daher muss sie möglichst effizient erfolgen und idealerweise einen automatisierten Ablauf erlauben. Dennoch ist auch die Möglichkeit des Zugriffs auf einzelne Teile der Datenbasis notwendig, um spezifische Analysen und Tests gezielt durchführen zu können. Bei der Bewertung ist die exakte Reproduzierbarkeit der Ergebnisse ist unverzichtbar. Sie ermöglicht es, frühere Ergebnisse zu überprüfen, Leistungsverbesserungen zu bestimmen und die Ursachen aufgetretener Fehler zu analysieren. Zudem gewährleistet sie die Vergleichbarkeit unterschiedlicher Systeme. Die vorgestellten Probleme führen zu einer hohen Komplexität des Entwicklungs- und Testprozesses. Die Beherrschbarkeit dieser Komplexität erfordert effiziente Entwicklungsund Testwerkzeuge [Win06; Mau09]. Je nach Umfang des Entwicklungsvorhabens verteilen sich die Aufgaben auf eine Vielzahl von Personen in unterschiedlichen Rollen und Teams. Dies erfordert eine gemeinsame Kommunikationsbasis. Die Verwendung individueller Werkzeuge und Datenformate erzeugt eine Kommunikationsbarriere und erschwert den Austausch sowohl von Wissen als auch von Entwicklungsartefakten (z. B. Programmcode, Komponenten, Referenzdaten). Tester benötigen beispielsweise die Einbindung der entwickelten Komponenten sowie der erhobenen Sensor- und Referenzdaten in ihre Testumgebung. Wird dort eine Fehlfunktion festgestellt, muss ein Entwickler in der Lage sein, diesen Fehler zur Analyse der Ursachen zuverlässig reproduzieren zu können. Eine gemeinsame Arbeitsumgebung vereinfacht hier die Kommunikation durch eine gemeinsame Wissensbasis und zentrales Datenmanagement und schafft so die Grundlage für einen effizienten Entwicklungsprozess. Dieser zeichnet sich dadurch aus, dass er doppelten Entwicklungsaufwand vermeidet und auf vorhandene Komponenten zurückgreift. So entstehen sowohl innerhalb eines Entwicklungsvorhabens als auch projektübergreifend Synergieeffekte. Wiederholt benötigte Funktionen lassen sich ohne Mehraufwand wiederverwenden. Dazu zählen z. B. der Daten- und Sensorzugriff oder Softwarebausteine zur Datenverarbeitung oder Visualisierung. Dies ermöglicht eine stetige Verbesserung der vorhandenen Komponenten und reduziert den Gesamtaufwand nicht nur durch Wegfall redundanter Entwicklungs- und Testarbeit, sondern auch durch die Erfahrung 6

17 1.5 Beitrag dieser Arbeit der Nutzer mit bereits bekannten Komponenten. Auch vorhandene Testdaten können ggf. in neuen Projekten weiterverwendet werden. Eine solche Arbeitsumgebung benötigt eine hohe Flexibilität und Anpassbarkeit, um den aufgaben- und problemspezifischen Anforderungen gerecht zu werden. Ferner sind auch die unterschiedlichen technischen Fähigkeiten der Nutzer zu berücksichtigen. Für zukünftige Entwicklungsprojekte sind die genauen Randbedingungen und Anforderungen heute noch nicht absehbar. Daher darf eine solche Arbeitsumgebung kein abgeschlossenes System sein, sondern muss grundlegende Erweiterungsmöglichkeiten bieten. 1.5 Beitrag dieser Arbeit Im Rahmen dieser Arbeit wurde das Softwaresystem Advanced Development & Analysis Framework (ADAF) entwickelt und in Kooperation mit der NISYS GmbH 2 realisiert. Es ermöglicht die effiziente Entwicklung und Evaluierung von sensordatenverarbeitenden Verfahren im Sinne der Problemstellung. Die zugrundeliegenden Anforderungen an das Softwaresystem werden ausgehend vom großen Bewertungsbedarf solcher Verfahren entwickelt. Die Anforderungen werden im Kontext umfelderfassender Fahrerassistenzsysteme unter Berücksichtigung des Entwicklungsprozesses, der daran beteiligten Rollen und der technischen Randbedingungen abgeleitet und diskutiert. Der Schwerpunkt der Betrachtung liegt dabei auf kamerabasierten Assistenzfunktionen. Die modulbasierte Architektur des Softwaresystems bildet die Grundlage zur parallelen Erfassung, Aufzeichnung und Wiedergabe der Daten mehrerer auch unterschiedlicher Sensoren, ihrer Verarbeitung, Visualisierung und Annotation sowie der Bewertung der Verarbeitungsergebnisse. Eine automatisierte Verarbeitung ermöglicht die detaillierte Bewertung von Algorithmen auf umfangreichen Testdatenbeständen. Die hierzu erforderlichen Referenzdaten können über Annotationsmodule effizient erzeugt werden. Zentrales Merkmal von ADAF ist die Nachvollziehbarkeit und Reproduzierbarkeit der Verarbeitung und der Bewertung. Im Fehlerfall ermöglicht ADAF so eine detaillierte Analyse der Ursachen. Diese wird durch zahlreiche Visualisierungsfunktionen zur Darstellung der Sensordaten und (Zwischen-)Ergebnisse unterstützt. Durch Bereitstellung einer umfangreichen Programmierschnittstelle ist das System explizit auf Erweiterung durch neue Funktionalität ausgelegt. Dies betrifft vor allem die Einbindung neuer Sensoren, neuer Algorithmen und Bewertungsverfahren, aber auch zusätzlicher Visualisierungen, Datenformate und Analysemöglichkeiten. Durch Wieder- und Weiterverwendbarkeit vorhandener Module verhindert ADAF redundanten Entwicklungs- und Testaufwand und erzeugt so projekt- und aufgabenübergreifende Synergieeffekte. Die Dokumentation konkreter Beispiele aus der Praxis, die in Kooperation mit der NISYS GmbH durchgeführt wurden, dient der Demonstration der Leistungsfähigkeit und Flexibilität des entwickelten Frameworks. Sie verdeutlichen die Bandbreite der 2 7

18 1 Einleitung aufgabenspezifischen Anforderungen und wie ADAF die effiziente Umsetzung ermöglicht hat. Des Weiteren wurde im Rahmen dieser Arbeit der German Traffic Sign Recognition Benchmark (GTSRB) erstellt, ein umfangreicher Datensatz zur Bewertung von Algorithmen zur Verkehrszeichenerkennung. Die erste Veröffentlichung dieses Datensatzes erfolgte zweistufig in [SSSI11] und [SSSI12]. Er diente als Grundlage für einen vielbeachteten gleichnamigen Wettbewerb zum Vergleich von Klassifikationsverfahren. In der vorliegenden Arbeit liegt der Schwerpunkt der Betrachtung auf dem Benchmarkdesign und der technischen Realisierung, die durch ADAF ermöglicht wurde. Anhand des GTSRB werden vor allem die für die Erstellung eines Datensatzes zu Benchmarkzwecken relevanten Einzelentscheidungen detailliert diskutiert und illustriert. 1.6 Aufbau dieser Arbeit In Kapitel 2 wird ausgehend von der Definition der Fahraufgabe und des Fahrprozesses der Begriff Fahrerassistenzsystem gegenüber anderen technischen Systemen im Fahrzeug abgegrenzt. Die Rolle der Umfeldwahrnehmung wird hervorgehoben und aktuell verfügbare Fahrerassistenzsysteme sowie verwendete Sensortechnologien werden vorgestellt. Der Begriff und die Ziele der Evaluierung werden in Kapitel 3 definiert. Anhand des V-Modells als Vorgehensmodell für Entwicklungsprojekte im Allgemeinen und Fahrerassistenzsysteme im Besonderen wird der Bedarf an Evaluierung im Verlauf des Entwicklungsprozesses erläutert und lokalisiert. In Kapitel 4 erfolgt ausgehend von einem Makromodell zur Systembewertung die Definition von Anforderungen an und von Voraussetzungen für eine erfolgreiche Evaluierung. Darauf aufbauend werden in Kapitel 5 Fragestellungen der technischen Umsetzung dieser Anforderungen in einem Softwaresystem behandelt und Anforderungen für eine effiziente Realisierung erarbeitet. In Kapitel 6 wird die implementierte Entwicklungs- und Analyseumgebung vorgestellt und detailliert aufgezeigt, wie die theoretischen und technischen Anforderungen verwirklicht wurden. Kapitel 7 stellt konkrete Praxisbeispiele vor und beschreibt, wie diese mit Hilfe des in dieser Arbeit entwickelten Softwaresystems effizient realisiert werden konnten. In Kapitel 8 wird die Erstellung eines Benchmarkdatensatzes zur Verkehrszeichenerkennung beschrieben. Dabei werden sowohl die relevanten Designentscheidungen als auch die konkrete technische Realisierung erläutert. Kapitel 9 beschließt die vorliegende Arbeit mit einem Fazit und gibt einen Ausblick auf zukünftige Entwicklungen. 8

19 2 Fahrerassistenzsysteme Im Allgemeinen sind Fahrerassistenzsysteme technische Systeme im Fahrzeug, die den Fahrer bei der Erfüllung der Fahraufgabe unterstützen und entlasten. Bei Betrachtung eines aktuellen Fahrzeugs wird deutlich, dass diese Definition zu einem sehr weit gefassten Begriff Fahrerassistenzsystem führt. Ein Blick auf die historische Entwicklung des Automobils zeigt, dass sie auch viele Systeme einschließt, die heutzutage als Selbstverständlichkeit erachtet werden, wie z. B. den elektrischen Anlasser, Scheibenwischer oder die automatische Blinkerrückstellung [WBM02]. Um zu einem enger gefassten Fahrerassistenzbegriff zu gelangen, sollen im Folgenden zunächst die Aufgaben des Fahrers bei der Fahrzeugführung genauer betrachtet werden. Im Anschluss werden aktuelle Beispiele für Fahrerassistenzsysteme vorgestellt und es wird ein Überblick über die verfügbare Sensorik zur Umfelderfassung gegeben. 2.1 Fahraufgabe Die Fahraufgabe teilt sich nach [Bub02] in drei Unteraufgaben. Die primäre Fahraufgabe umfasst den eigentlichen Fahrprozess, also alle Aktionen der Fahrzeugführung, die erforderlich sind, um unfallfrei vom Start zum Ziel zu gelangen. Sowohl Verkehrsregeln als auch die herrschenden Umweltbedingungen machen weitere Handlungen erforderlich, die zwar von der primären Fahraufgabe abhängig sind, aber nicht dazu dienen, das Fahrzeug auf der Straße zu halten. Diese Handlungen werden der sekundären Fahraufgabe zugerechnet. Dazu gehören die Betätigung von Blinker oder Scheibenwischer oder das Einschalten des Lichts bei Dunkelheit (s. a. [WZB06; Ber09]). Tätigkeiten wie Radio hören oder die Regulierung der Innenraumtemperatur haben keinen direkten Fahrbezug, sondern dienen der Befriedigung individueller Informations- und Komfortbedürfnisse. Dennoch können diese tertiären Fahraufgaben die Sicherheit beeinflussen, da sie ggf. Aufmerksamkeit erfordern. Die resultierende Ablenkung des Fahrers erhöht die Unfallgefahr [YR07]. Auch eine erhöhte Innenraumtemperatur im Sommer wirkt sich negativ auf das Fahrverhalten aus und führt zu einem deutlichen Anstieg des Unfallrisikos. Eine Klimaanlage senkt den Wärmestress des Fahrers und verhindert diesen Anstieg [AB99; MP99]. 2.2 Fahrprozess Der Fahrprozess, also die primäre Fahraufgabe, lässt sich ebenfalls in drei Ebenen gliedern. Das erstmals von [Ber70] vorgestellte Modell unterscheidet drei Stufen. Ursprünglich am Beispiel der Flugzeugführung vorgestellt, lässt es sich auf andere Fahrzeugarten 9

20 2 Fahrerassistenzsysteme Fahrprozess Navigation FestlegungpderpFahrtroutepundpderpZeitpzurpErreichungpdespZiels Zeithorizont Bahnführung Stabilisierung ReaktionpaufplokalepSituationenpundpVerkehr FestlegungpvonpSoll-KurspundpGeschwindigkeit GrundlegendepFahraufgabenp/pFahrzeugbedienungp Regelungp)Ist-zu-Soll-Werten)pPGeschwindigkeit,pSpurhaltungp...ä Priorität Abbildung 2.1: Der Fahrprozess als primäre Fahraufgabe nach Bubb [Bub02] (Abbildung in Anlehnung an [KH10]) übertragen [ALA71; Don78; Bub02]. Die oberste Ebene des in Abbildung 2.1 dargestellten Modells bildet die Navigationsaufgabe. Sie umfasst langfristige Aufgaben wie die allgemeine Routenplanung, um vom Start zum Ziel der Reise zu gelangen. Um dieses Ziel zu erreichen ist eine Folge von Fahrmanövern wie Folgefahren, Überholen oder Abbiegen notwendig. Diese Manöver definieren die Bahnführungsaufgabe, die den mittelfristigen Kurs des Fahrzeugs vorgibt (in der Größenordnung von 200 m). Die unterste Ebene bildet die Stabilisierungsaufgabe. Während der Fahrt ist der Fahrer kontinuierlich für die Längsund Querregelung der Fahrzeugführung verantwortlich. Er muss das Fahrzeug auf der Straße halten und jede Berührung mit stehenden oder sich bewegenden Objekten im Verkehrsraum vermeiden [Bub02, S. 9]. Je niedriger die Stufe, desto höher ist ihre Priorität. Prinzipiell muss die aktuelle Position des Fahrzeugs stets die Ziele aller Ebenen erfüllen. Bei auftretenden Störungen müssen jedoch zunächst die niedrigeren Aufgaben ausgeführt werden, bevor höhere Aufgaben berücksichtigt werden können. Quert plötzlich eine Person oder ein Objekt die geplante Trajektorie des Fahrzeugs, so muss der Fahrer zunächst die sich ergebende Stabilisierungsaufgabe (durch Bremsen und Ausweichen) erfüllen. Das aktuelle Manöver wie z. B. die Geradeausfahrt und auch die Routenplanung bleiben so lange unbeachtet. Erst wenn die Bedürfnisse und Anforderungen der niedrigeren Ebenen erfüllt sind, können Aufgaben der höheren Ebenen berücksichtigt werden. [Ber70] merkt an, dass die Forderungen an den Piloten [hier: Fahrzeugführer] hinsichtlich der Abtastfrequenz oder Grenzfrequenz von der Navigation über die Lenkung [hier: Bahnführung] zur Flugregelung [hier: Stabilisierung] stark an[steigen] [Ber70, S. 356] und dass daher die Automatisierung [dieser Aufgaben] in umgekehrter Richtung voran[schreitet] [Ber70, S. 356]. Diese Entwicklungsrichtung ist auch in der Automobilentwicklung zu beobachten. Das Antiblockiersystem (ABS) zählt als das erste elektronische Fahrerassistenzsystem. Es unterstützt den Fahrer auf der Stabilisierungsebene, indem es den Bremsdruck reguliert, um ein Blockieren der Räder zu verhindern und so die Lenkbarkeit des Fahrzeugs zu erhalten. Geübte Fahrer können einen ähnlichen Effekt bis zu einem gewissen Grad ggf. durch Stotterbremsen erzielen, allerdings nicht in derselben Präzision. Die Verfügbarkeit von ABS stellt diesen Effekt auch weniger geübten Fahrern zur Verfügung und ermöglicht ihnen so eine bessere Kontrolle des Fahrzeugs in Grenzsituationen. 10

21 2.3 Definition des Begriffs Fahrerassistenzsystem Auch andere Systeme auf Stabilisierungsebene wie die Antriebsschlupfregelung (ASR) oder das elektronische Stabilitätsprogramm (ESP) arbeiten vollautomatisch und können vom Fahrer nicht beeinflusst werden. Einerseits sind hier die zeitlichen Anforderungen so hoch, dass der Fahrer diese Aufgaben nicht eigenständig erfüllen kann, andererseits fehlen ihm die technischen Eingriffsmöglichkeiten (z. B. für den durch das ESP erzeugten asymmetrischen Bremseingriff). 2.3 Definition des Begriffs Fahrerassistenzsystem Um zu einer Eingrenzung des Begriffs Fahrerassistenzsystem zu gelangen, soll der Begriff auf Systeme beschränkt werden, die den Fahrer bei der primären Fahraufgabe unterstützen. Dies deckt sich mit der Definition des im Rahmen des RESPONSE 3-Projekts erarbeiteten Code of Practice (CoP) für die Entwicklung und das Design von Fahrerassistenzsystemen [Kna+09]. Aus der Beschreibung des Fahrprozesses wird bereits deutlich, dass die Unterstützung des Fahrers auf vielfältige Art und Weise und auf unterschiedlicher Ebene geschehen kann. Je nach Ausgestaltung der Systeme informieren oder warnen sie den Fahrer und/oder entlasten ihn durch aktive Unterstützung bei der Stabilisierung oder Bahnführung. In jedem Fall bleibt der Fahrer rechtlich immer in der vollen Verantwortung der Fahrzeugführung. Laut dem Wiener Übereinkommen muss er ständig die Kontrolle über sein Fahrzeug haben und in der Lage sein alle ihm obliegenden Fahrbewegungen auszuführen. [Bun77, Art. 13, Abs. 1]. Daher muss ein entsprechender Eingriff grundsätzlich durch den Fahrer übersteuerbar sein. Kein Assistenzsystem übernimmt die primäre Fahraufgabe vollständig. Während im Deutschen nur der Begriff Fahrerassistenzsystem gebräuchlich ist, wird der englische Begriff Driver Assistance System (DAS) in der Regel um den Zusatz Advanced (ADAS) ergänzt. Der CoP definiert ADAS als die Untermenge der Fahrerassistenzsysteme, die folgende Eigenschaften vollständig erfüllen (Eigenübersetzung aus [Kna+09, Annex E, S. 67]): 1. Sie unterstützen den Fahrer bei der primären Fahraufgabe. 2. Sie leisten aktive Unterstützung der Quer- und/oder Längsführung (mit oder ohne Warnung). 3. Sie erfassen und bewerten das Fahrzeugumfeld. 4. Sie basieren auf einer komplexen Signalverarbeitung. 5. Sie erlauben eine direkte Interaktion zwischen Fahrer und System. Kurz, gemäß CoP sind ADAS umfelderfassende, eingreifende Systeme. Das A in ADAS ließe sich daher auch als aktive Fahrerassistenzsysteme ins Deutsche übertragen. Diese Definition schränkt den ursprünglich sehr weit ausgelegten Begriff Fahrerassistenzsystem deutlich ein. Der einleitend erwähnte elektrische Anlasser fällt dadurch heraus, da er den Fahrer nicht bei der primären Fahraufgabe unterstützt. Automatisierte Stabilisierungssysteme wie ABS oder ESP bleiben unberücksichtigt, da sie rein auf fahrzeuginternen 11

22 2 Fahrerassistenzsysteme Messwerten wie Raddrehzahlen beruhen und nicht das Fahrzeugumfeld sensorisch erfassen. Der ADAS-Begriff im CoP schließt allerdings ein System, das kamerabasiert die Geschwindigkeitsbegrenzung erkennt, nur dann ein, wenn eine erkannte Überschreitung auch zu einem Eingriff (Reduzierung der Geschwindigkeit) führt. Ein rein warnendes System ist hier explizit ausgeschlossen. Damit ist die Definition für diese Arbeit, in der der Schwerpunkt auf der Umfelderfassung und der nachfolgenden komplexen Signalverarbeitung liegt, etwas zu eng gefasst. Für die korrekte Informationsverarbeitung der Umfelderfassung ist es unerheblich, wie das Ergebnis der Situationsanalyse (im Beispiel also der erkannten Geschwindigkeitsbegrenzung und ggf. der Überschreitung) weiterverarbeitet wird. Sowohl das warnende als auch das eingreifende System sind auf eine korrekte Wahrnehmung des Umfelds angewiesen. Auch die Art der Interaktion mit dem Fahrer ist für die Betrachtung der Umfelderfassung nicht relevant. Daher soll der ADAS-Begriff etwas weiter gefasst werden als im CoP, indem die Forderungen nach aktiven Eingriffen des Systems (Eigenschaft 2) und nach Interaktion mit dem Fahrer (Eigenschaft 5) fallen gelassen werden. Die Abgrenzung eines ADAS zum DAS liegt somit in der Umfelderfassung und der damit verbundenen komplexen Signalverarbeitung. Die erfassten Daten müssen weiterverarbeitet und nicht nur dem Fahrer angezeigt werden. Dieser ADAS-Begriff steht auch in Einklang mit der wissenschaftlichen Literatur, wo er zwar selten so konkret definiert wird, aber gerade im Bereich der Umfelderfassung verbreitet ist, da diese als Grundlage sowohl für warnende als auch für eingreifende Systeme dient (z. B. [LWV05; Ren09; DKPN09; Ber+10; AVF11; Gri13]). In dieser Form ließe sich das Advanced im englischen Begriff auch als intelligent ins Deutsche übertragen. Die Abkürzung ifas wäre zwar denkbar, ist in der Realität jedoch nicht gebräuchlich. Daher soll in dieser Arbeit der Begriff Fahrerassistenzsystem (FAS) gleichberechtigt mit intelligentes Fahrerassistenzsystem für die Systeme verwendet werden, die den Fahrer durch Erfassung und Interpretation des Fahrzeugumfelds bei der primären Fahraufgabe unterstützen. 2.4 Umfelderfassung im Fahrzeug Die Erfüllung und Unterstützung der primären Fahraufgabe erfordern die Wahrnehmung des Fahrzeugumfelds. 1 Abhängig von der Fahrsituation und dem geplanten Manöver sind unterschiedliche Bereiche des Fahrzeugumfelds relevant. Einige sind exemplarisch in Abbildung 2.2 dargestellt. Im Folgenden werden für die einzelnen Bereiche bereits realisierte und mögliche Assistenzfunktionen vorgestellt. 2 Eine wichtige Rolle spielt das vordere Fahrzeugumfeld. Gegenüber vorausfahrenden Fahrzeugen ist abhängig von der Fahrgeschwindigkeit ein ausreichend großer Sicherheitsabstand einzuhalten, um einen ausreichenden Reaktions- und Bremsweg zu gewährleisten. Der 1998 in Deutschland von Mercedes-Benz eingeführte Abstandsregeltempomat 1 Dies ist unabhängig davon, ob es sich um einen menschlichen Fahrer, ein Assistenzsystem oder ein autonomes Fahrzeug handelt. 2 Die Bezeichnungen der einzelnen Assistenzsysteme können herstellerspezifisch variieren. 12

23 2.4 Umfelderfassung im Fahrzeug Fußgänger Hindernisse Notbremsung Spurhaltung Verkehrszeichen EinhaltungvdesvSicherheitsabstands StopvFvGo Überholen Kollisionsvermeidung Leuchtweitenregulierung Überholen Parken Spurwechsel Abbiegen Rückwärtsfahrt Gespannfahrt Abbiegen Spurwechsel Abbildung 2.2: Fahrzeugumfeld nach Fahrsituationen (in Anlehnung an [Sch05b]) (Adaptive Cruise Control, ACC) [HEG13] stellt eine Weiterentwicklung des Tempomaten 3 dar. Durch Erfassung des vorderen Fahrzeugumfelds durch Radar oder Lidar (s. Abschnitt 2.5) werden Geschwindigkeit und Abstand vorausfahrender Fahrzeuge bestimmt und die eigene Geschwindigkeit ggf. reduziert. Bei freier Fahrbahn wird die vom Fahrer gewählte Zielgeschwindigkeit wieder hergestellt. Fahrzeuggeschwindigkeiten von bis zu 250 km/h erfordern eine hohe Erfassungsweite, die jedoch nur mit kleinem Öffnungswinkel zur Verfügung steht. Neuere Systeme (Mercedes S-Klasse ab 2005, BMW 5er ab 2007 [HEG13]) erfassen mit zusätzlicher Sensorik auch den Nahbereich des Fahrzeugs mit größerer Breite und ermöglichen so die Geschwindigkeitsregelung auch in niedrigen Geschwindigkeitsbereichen bis zum Stillstand [Jun03]. Diese sog. Stop & Go-Funktion ermöglicht den ACC-Einsatz in Stausituationen und im Stadtverkehr und trägt so zur Entlastung des Fahrers bei. Die Erfassung des vorderen Fahrzeugumfelds ermöglicht außerdem die Realisierung von adaptiven Bremsassistenten (BAS). Bei drohender Kollision mit einem sicher erkannten Objekt wird der Fahrer zunächst gewarnt. Eine Vorkonditionierung der Bremsen stellt sicher, dass bei Bremsbetätigung durch den Fahrer sofort der optimale Bremsdruck zur Verfügung steht. Die Umgebungserfassung ermöglicht in diesem Fall eine sog. Zielbremsung. Das bedeutet, dass das Fahrzeug nur so stark abgebremst wird, dass eine Kollision, falls möglich, gerade noch verhindert wird. Dadurch wird nachfolgenden Fahrzeugen der maximal mögliche Anhalteweg gewährt. Reagiert der Fahrer nicht auf die Warnung, führt der Notbremsassistent eine autonome Teilbremsung durch. Reagiert der Fahrer auch dann nicht, führen seit 2009 verfügbare Systeme 0,6 Sekunden vor der Kollision eine vollautomatische Vollbremsung durch. Diese kann den Aufprall zwar u. U. nicht mehr verhindern, seine Stärke jedoch deutlich reduzieren und somit die Schwere der Unfallfolgen mindern [Rei12]. Zur Kollisionswarnung und Notbremsung sind jegliche aktuelle und potenzielle Hindernisse im Fahrbereich zu erkennen. Neben Fahrzeugen (langsamer vorausfahrend, 3 Der Tempomat hält die jeweilige Fahrzeuggeschwindigkeit konstant. Er wird bei einem Bremseingriff des Fahrers automatisch deaktiviert. 13

24 2 Fahrerassistenzsysteme (a) Nachtsichtsystem Night Vision Plus von Bosch mit Fußgängererkennung [Kra09] (b) Adaptiver Fernlichtassistent in der Mercedes S-Klasse [Pud13] Abbildung 2.3: Assistenzsysteme für Nachtfahrt kreuzend, parkend) gehören dazu Fußgänger und Tiere. Problematisch ist hierbei die hohe Variabilität ihrer Erscheinungsform durch Bewegungen und Körpergröße bzw. aufgrund verschiedener Tierarten. Um Hindernisse und den Streckenverlauf auch im Dunkeln gut erkennen zu können, sind zwei unterschiedliche Ansätze verbreitet, die alternativ oder ergänzend verwendet werden: Nachtsichtsysteme und Fernlichtassistenten. Erstere basieren in der Regel auf Infrarot-Kameras. Die ersten Systeme stellten lediglich das erfasste Bild im Kombiinstrument oder der Mittelkonsole dar. Abhängig von der verwendeten Kameratechnologie (s. Abschnitt 2.5.6) heben sich speziell Fußgänger aufgrund der abgestrahlten Wärme stark ab und sind dadurch deutlich zu erkennen. Neuere Systeme integrieren eine Fußgängererkennung, die den Fahrer warnt, falls sich die Person im Gefahrenbereich befindet (s. Abbildung 2.3a). Nachtsichtsysteme erfordern u. U. die Abwendung des Blicks von der Fahrbahn. Adaptive Fernlichtassistenten hingegen ermöglichen eine maximale Ausleuchtung der Strecke im sichtbaren Bereich des Lichtspektrums. Die Detektion vorausfahrender und entgegenkommender Fahrzeuge ermöglicht die Anpassung der Leuchtweite der Scheinwerfer auf ein Maximum, ohne dass der Umgebungsverkehr geblendet wird (blendfreies Dauerfernlicht). In Verbindung mit LED-Matrix-Scheinwerfern ermöglichen diese Systeme eine gezielte Abblendung in Bereichen mit anderen Fahrzeugen (s. Abbildung 2.3b). Außerdem ermöglichen diese Scheinwerfer die gezielte Anstrahlung von Fußgängern, um den Fahrer darauf aufmerksam zu machen, ohne dass er den Blick von der Straße abwenden muss[mey13]. Verkehrszeichen geben die aktuell gültigen Verkehrsregeln vor. Je nach Verkehrssituation und Zustand des Fahrers können einzelne Schilder jedoch leicht übersehen werden. Assistenten zur Verkehrszeichenerkennung (Traffic Sign Recognition, TSR) unterstützen den Fahrer durch Anzeige relevanter Verkehrszeichen im Kombiinstrument. Aktuell kommerziell verfügbare Systeme sind meist auf die Erkennung von Geschwindigkeitsbegrenzungen und deren Aufhebungen beschränkt; u. U. werden zusätzlich auch Einfahrund Überholverbote erkannt. 14

25 2.4 Umfelderfassung im Fahrzeug (a) Überwachung der Nachbarspuren [Sch08] (b) Warnung bei Spurwechsel mit Audi Side Assist [Kri10] Abbildung 2.4: Spurwechselassistent Bei Übermüdung oder Ablenkung des Fahrers besteht die Gefahr, dass das Fahrzeug unabsichtlich die Fahrspur verlässt und somit die eigene Sicherheit wie auch die der Verkehrsteilnehmer in der Umgebung gefährdet. Spurverlassenswarner (Lane Departure Warning, LDW) detektieren kontinuierlich den aktuellen Fahrstreifen anhand der Fahrstreifenmarkierungen und warnen den Fahrer, sobald das Fahrzeug droht, die Markierungen unbeabsichtigt zu überfahren. Spurhalteassistenten (Lane Keeping Assistant, LKA) führen in diesem Fall einen Lenkeingriff durch, der das Fahrzeug in die Spurmitte zurückführt. Fehlen die Markierungen allerdings oder sind sie aufgrund von schneebedeckter Fahrbahn nicht sichtbar, steht die Assistenzfunktion nicht nur Verfügung. Bei Überholvorgängen auf Landstraßen gilt es, die abhängig vom Gegenverkehr zur Verfügung stehende Zeit sowie die abhängig von der Geschwindigkeit des eigenen und vorausfahrenden Fahrzeugs benötigte Zeit abzuschätzen. Ein von der TU Darmstadt in Kooperation mit Continental im Rahmen des PRORETA 2-Projekts entwickelter Überholassistent warnt den Fahrer in mehreren Stufen, falls das Zeitfenster für einen erfolgreichen Abschluss des Überholvorgangs zu klein ist [Pfr09; HMSW10]. Reagiert der Fahrer zunächst nicht, wird das Fahrzeug bis hinter das vorausfahrende Fahrzeug gebremst, um dem Fahrer ein Einscheren und somit den Abbruch des Überholvorgangs zu ermöglichen. Die Erfassung des seitlichen und rückwärtigen Fahrzeugumfelds spielt bei Spurwechseln und Abbiegevorgängen eine wichtige Rolle. Auch bei modernen Rückspiegeln bleibt hier ein unbeobachtbarer Bereich erhalten. Assistenten zur Überwachung des toten Winkels, sog. Blind Spot Detection-Systeme, beobachten diesen Bereich und warnen den Fahrer durch einen optischen Hinweis im Außenspiegel und ggf. zusätzlich akustisch, falls sich ein Fahrzeug oder ein Radfahrer im kritischen Bereich befindet. Die Überwachung des toten Winkels erfolgt beispielsweise bei Volvo mit einer Kamera im Bereich der Außenspiegel [ADA08]. Spurwechselassistenten (Lane Change Assistant, LCA) überwachen einen größeren Bereich hinter dem Fahrzeug bis zu einer Entfernung von m (s. Abbildung 2.4a). Dies ermöglicht Warnungen bei Überholvorgängen und Spurwechseln auf mehrspurigen Straßen. Die Warnung des Fahrers erfolgt ebenfalls optisch im Außenspiegel (s. Abbildung 2.4b). 15

26 2 Fahrerassistenzsysteme Das unmittelbare Fahrzeugumfeld ist in Einparksituationen relevant. Der erste Parkassistent wurde 1995 von Mercedes-Benz in der S-Klasse eingeführt. Hierbei handelte es sich um ein rein informierendes System, das den Fahrer bei zu geringem Abstand optisch und akustisch warnte. Neuere Systeme unterstützen den Fahrer durch Vermessung der Parklücke, Vorgabe der Lenkbewegung oder durch automatische Querführung. Die Längsführung verbleibt vorerst noch beim menschlichen Fahrer. Auch bei Rückwärtsfahrt ist grundsätzlich eine Hinderniserkennung notwendig, aufgrund des niedrigeren Geschwindigkeitsbereichs ist allerdings im Vergleich zur Vorwärtsfahrt nur ein kleinerer Erfassungsbereich von Interesse. Für die Rückwärtsfahrt mit Anhänger überwacht VW mit Trailer Assist den Knickwinkel zwischen Deichsel und Fahrzeug, um durch automatische Querführung den vom Fahrer eingestellten Winkel zu realisieren [Sch13]. 2.5 Sensoren zur Umfelderfassung Zur Wahrnehmung des Fahrzeugumfelds steht eine Vielzahl unterschiedlicher Sensoren zur Verfügung. Ihre individuellen Stärken und Schwächen in Bezug auf den Erfassungsbereich, die Erfassungsgenauigkeit, die Art der erfassbaren Objekte sowie die Betriebsbedingungen (Witterung, Lichtverhältnisse) bestimmen ihre Eignung für einzelne Fahrerassistenzsysteme. Im Folgenden werden die wichtigsten Sensoren kurz vorgestellt Ultraschall Ultraschallsensoren bestimmen Entfernungen, indem sie die Laufzeit einer reflektierten Schallwelle messen. Aufgrund der Temperaturabhängigkeit der Schallwellenausbreitung ist eine entsprechende Kompensation bei der Berechnung des Abstands notwendig. Wegen ihrer begrenzten Reichweite, aber hohen Entfernungsgenauigkeit werden Ultraschallsensoren häufig für Parkassistenzsysteme verwendet. Dazu werden üblicherweise mehrere Sensoren in den Stoßfängern verbaut. Die Abstrahlcharakteristik dieser Ultraschallsensoren weist in der Horizontalen einen sehr breiten, in der Vertikalen einen kleinen Öffnungswinkel auf. Dies verhindert tote Winkel zwischen den einzelnen Sensoren sowie Echos vom Boden [Rei12] Radar Radar (Radio Detection and Ranging) basiert auf der Aussendung gebündelter elektromagnetischer Wellen im Mikrowellenbereich und der Auswertung der von Objekten (sog. Zielen) reflektierten Echos. Durch Ausnutzung des Dopplereffekts ermöglichen Radargeräte die Messung der Relativgeschwindigkeit zwischen Sender und Ziel. Die Modulation des Signals erlaubt die Abstandsmessung. Radar ist unempfindlich gegenüber Witterungseinflüssen wie Regen, Schneefall oder Nebel [Rei12] sowie unabhängig vom Tageslicht. Durch Berücksichtigung unterschiedlicher Relativgeschwindigkeiten, Entfernungen und Horizontalwinkel (Azimut) der detektierten Objekte sind automobile 16

27 2.5 Sensoren zur Umfelderfassung Radarsensoren in der Lage, mehrere Ziele zu unterscheiden (sog. Mehrzielfähigkeit) [Win12]. Aufgrund einer relativ großen Strahlbreite von 2 4 Grad haben Radarmessungen jedoch eine geringe laterale Auflösung und liefern lediglich Punktinformationen. Zusätzlich lassen wechselnde Reflexionsschwerpunkte die gemessenen Objektpositionen stark springen. Durch geeignete Matching- und Trackingverfahren können diese zu eindeutigen Objekten zusammengefasst werden. Die im Automobilbereich verwendeten Radarsensoren arbeiten im Frequenzbereich um 77 GHz (Fernbereichsradar (Long Range Radar, LRR) GHz; Nahbereichsradar (Short Range Radar, SRR) GHz 4 ). Aufgrund der hohen Reichweite wird Radar häufig für ACC-Systeme eingesetzt. Wegen der geringen lateralen Auflösung können vorausfahrende Fahrzeuge jedoch nicht immer der korrekten Spur zugeordnet werden, sodass insbesondere in engen Kurven Fahrzeuge auf benachbarten Fahrspuren irrtümlich einen Bremseingriff verursachen können. Im Jahr 2005 verwendete Mercedes-Benz Nahbereichsradar erstmals auch zur Realisierung des Parkassistenten [HEG13]. Hella und Audi stellten 2008 einen Spurwechselassistenten vor, der anhand von Radar die Nachbarspuren des Fahrzeugs überwacht (s. Abbildung 2.4) [Sch08] Lidar Bei Lidar (Light Detection and Ranging) handelt es sich um ein optisches Verfahren zur Abstandsmessung. Lidarsensoren messen ebenso wie Radarsensoren Laufzeiten elektromagnetischer Wellen. Für Lidar liegen diese jedoch im Bereich von infrarotem, sichtbarem oder ultraviolettem Licht [Ged12]. Die Bestimmung der Relativgeschwindigkeit erfolgt bei Lidar in der Regel über die Differenzierung mehrerer Abstandsmessungen. Prinzipiell ist auch wie bei Radar die Ausnutzung des Dopplereffekts möglich, jedoch erfordert dies eine deutlich aufwendigere und somit teurere Technik [Rei12]. Lidarsensoren unterscheiden sich in der Anzahl der verwendeten Laserstrahlen und darin, ob diese starr (s. Abbildung 2.5a) oder schwenkbar (scannend) sind. Die Schwenkung wird entweder durch Ablenkung der Laserstrahlen mittels beweglicher Spiegel oder durch Rotation der Messeinheit (s. Abbildung 2.5b) erzielt. Letzteres ermöglicht einen sehr großen Erfassungsbereich von bis zu 360 Grad. Dabei ist der vertikale Öffnungswinkel allerdings stark begrenzt, sodass in der Regel nur Objekte in der Messebene erfasst werden können. Eine Ausnahme bilden Systeme der Firma Velodyne Lidar 5, die durch vertikale Anordnung von mehreren Lasern in einem rotierenden Kopf einen vertikalen Erfassungsbereich von bis zu 31 Grad ermöglichen (Velodyne HDL-64E S2.1 [Vel]). Lidar bietet im Vergleich zu Radar eine deutlich höhere Winkelauflösung (0,25 Grad und weniger) und ermöglicht so auch die Erkennung von Objektkonturen. Aufgrund 4 Bis 2013 war übergangsweise auch der Ultra-Wide-Band(UWB)-Bereich um 24 GHz für automobilen Nahbereichsradar freigegeben, um währenddessen die Entwicklung kostengünstiger Radarsensoren für den 77 GHz-Bereich zu ermöglichen [Sch05a]

28 2 Fahrerassistenzsysteme (a) Mehrstrahllidar Hella IDIS [Ged12] (b) Laserscanner Velodyne HDL-64E [Vel07] Abbildung 2.5: Lidar-Systeme (a) Intensitätsbild (b) Farbcodiertes Tiefenbild Abbildung 2.6: Mit ToF-Kamera erfasste Szene (PMD[Vision] CamCube [RPS09]) der Wellenlänge der verwendeten Strahlung ist es im Gegensatz zu Radar jedoch empfindlicher gegenüber Witterungsbedingungen wie Nebel oder Sprühregen, die zu einer deutlichen Dämpfung des Signals führen Time-of-Flight-Kameras Time-of-Flight(ToF)-Kameras (auch Photonen-Misch-Detektor(PMD)-Kameras genannt) vereinen die Entfernungsmessung durch moduliertes Infrarotlicht und die zweidimensionale Erfassung der Umwelt durch einen Bildsensor. Die pixelweise Korrelation der Laufzeitmessung mit der modulierten Lichtquelle erzeugt ein monochromes Intensitätsbild (s. Abbildung 2.6a), für dessen Pixel individuelle Abstandsmessungen verfügbar sind (s. Abbildung 2.6b). Somit ermöglichen die Kameras die Erfassung der Szene in 3D. Sie erfolgt im Gegensatz zu scannenden Verfahren wie Lidar in allen Punkten parallel. Der Sensor erfordert daher keine beweglichen Bauteile. Dies ermöglicht eine sehr schnelle Erzeugung von 3D-Bildern mit bis zu 100 Bildern pro Sekunde [BHLR12]. 18

29 2.5 Sensoren zur Umfelderfassung Durch die direkte Abstandsmessung ist der Rechenaufwand zur Bestimmung der dreidimensionalen Szene im Vergleich zu stereoskopischen Verfahren auf Basis von 2D- Bilddaten stark verringert. Im Gegenzug stellen ToF-Kameras allerdings eine deutlich geringere Auflösung zur Verfügung, da die einzelnen Pixel des Bildsensors für eine ausreichende Empfindlichkeit sehr viel größer sein müssen als bei herkömmlichen Kameras. Aktuelle Sensoren bieten Pixelzahlen im fünf- bis unteren sechsstelligen Bereich [RPS09; BHLR12; IP13] GPS und Kartendaten GPS bezeichnet das amerikanische Navigationssatellitensystem Global Positioning System. Es besteht aus einem Netz von mindestens 24 Satelliten, die aus einer Höhe von km kontinuierlich ihre Position und die aktuelle Uhrzeit senden. Ein Empfänger, der dieses Signal von mindestens vier Satelliten empfängt, kann durch Multilateration seine Position bestimmen. Beim Differential Global Positioning System (DGPS) werden zusätzlich per Funk übertragene Korrekturdaten ortsfester Referenzstationen auf der Erde berücksichtigt, um die Auswirkungen atmosphärischer Störungen auf die Signallaufzeiten zu reduzieren [Gri04]. Dadurch kann die Genauigkeit der Positionsbestimmung deutlich erhöht werden. Ein alternatives Navigationssatellitensysteme ist das russische GLONASS (Global Navigation Satellite System). Auch Europa und China bauen zur Zeit mit Galileo respektive Compass eigene Systeme auf, um die Abhängigkeit vom US-amerikanischen GPS zu verringern. Detaillierte Ausführungen zu allen genannten Systemen finden sich in [DH10]. In Verbindung mit Kartendaten ermöglicht die Lokalisierung über GPS außer der Navigation den Abruf statischer Umfeldinformationen wie Straßenart, Straßenverlauf und Informationen über Kreuzungen und Abzweigungen. Außerdem enthalten die verfügbaren Kartendaten zunehmend detailliertere Informationen wie lokale Geschwindigkeitsbegrenzungen, Überholverbote oder die Anzahl der verfügbaren Fahrstreifen. Fehler während der aufwendigen Datenerhebung sowie dauerhafte Veränderungen (neue Straßen, geänderte Geschwindigkeitsbegrenzungen) machen jedoch eine regelmäßige Aktualisierung der Datenbasis erforderlich. Temporäre Abweichungen, z. B. aufgrund von Baustellen, können nicht ohne Weiteres berücksichtigt werden Videokamera Videokameras erlauben die optische Erfassung des Fahrzeugumfelds. Ein Objektiv bündelt das von Punkten in der realen Welt emittierte oder reflektierte Licht, das anschließend durch einen zweidimensionalen Bildsensor in elektrische Größen umgewandelt wird [SBD09]. Obwohl CCD-Sensoren (Charge Coupled Device) eine höhere Lichtempfindlichkeit bieten, erlangen Sensoren in CMOS-Technik (Complementary Metal Oxide Semiconductor) zunehmende Verbreitung, da sie kostengünstiger zu produzieren sind, weniger Strom verbrauchen und ein gezieltes Auslesen einzelner Pixel und Bildbereiche ermöglichen [SBD09]. Bei beiden Sensortechniken entsteht grundsätzlich ein monochromes 19

30 2 Fahrerassistenzsysteme Abbildung 2.7: Videokamera Delphi IFV-200 mit integrierten Assistenzfunktionen[Del09] Intensitätsbild. Die Erzeugung eines Farbbildes wird durch Verwendung eines Bayer- Filters und eine anschließende Interpolation (sog. Demosaicking) ermöglicht. Details zu dieser Methode finden sich in [Sze11]. Flexibilität weisen Kameras durch wechselbare Objektive mit unterschiedlichen Öffnungswinkeln auf. Für vorausschauende Kameras sind Öffnungswinkel von Grad üblich. Rückfahrkameras verwenden in der Regel Objektive mit sehr großen Öffnungswinkeln von bis zu 180 Grad ( Fischauge ), um eine Erfassung über die volle Fahrzeugbreite auch in geringem Abstand zum Fahrzeug zu gewährleisten. Vorausschauende Kameras werden im Fahrzeug üblicherweise hinter dem Innenspiegel verbaut. Dies gewährleistet, dass der große Aufnahmebereich dem primären Sichtbereich des Fahrers entspricht. Abbildung 2.7 zeigt ein Beispiel für ein entsprechendes Kameramodul. Der Einsatz zusätzlicher Kameras in den Außenspiegeln und im Heck des Fahrzeugs ermöglicht die Realisierung einer Top-View-Funktion, bei der dem Fahrer während des Rangierens die unmittelbare Fahrzeugumgebung aus der Vogelperspektive dargestellt wird. Das über eine Kamera erzielte zweidimensionale Abbild der dreidimensionalen Welt bietet eine hohe laterale Auflösung, sowohl horizontal als auch im Gegensatz zu Radar und Lidar vertikal. Es kann allerdings keine unmittelbare Entfernungsinformation bereitstellen. Die aus der hohen Auflösung resultierende Datenmenge sowie die Komplexität der erfassten Szene führen zu einem hohen Rechenaufwand im Vergleich zu anderer Sensorik. Die Erkennung relevanter Objekte wird durch Beleuchtung und Witterung stark beeinflusst. Zur Realisierung von Nachtsichtsystemen (vgl. Abbildung 2.3) werden Kameras verwendet, die für Infrarotlicht empfindlich sind. Es kommen zwei unterschiedliche Methoden zum Einsatz. Kameras mit Empfindlichkeit für Strahlung im Ferninfrarot(FIR)-Bereich mit einer Wellenlänge von 7 12 µm können die von Objekten emittierte Wärmestrahlung erfassen. Dies führt in der Darstellung zu einem ungewohnten Bildeindruck, da warme Objekte hell erscheinen, kalte Objekte dunkel. Daher sind z. B. Menschen, Tiere oder warme Fahrzeugteile wie Reifen in diesen Bildern gut zu erkennen, während Spurmarkierungen oder Verkehrszeichen fast nicht sichtbar sind [Kno10]. Da Glas für FIR-Strahlung nicht durchlässig ist, müssen diese Kameras im Außenbereich des Fahrzeugs installiert werden. Zur Nutzung von Licht im Nahinfrarot(NIR)-Bereich mit einer Wellenlänge von

31 2.5 Sensoren zur Umfelderfassung 1100 nm ist eine Ausleuchtung der Szene mit entsprechenden Scheinwerfern notwendig, was zu einer geringeren Reichweite im Vergleich zu FIR führt [Rei12]. Aufgrund der Nähe zum sichtbaren Spektrum ist die Reflexion des NIR-Lichts durch Objekte und dadurch auch die resultierende Bilddarstellung ähnlich. Während für FIR spezielle Bildsensoren notwendig sind, erfolgt die Erfassung von NIR mit CMOS-Bildsensoren, die auch im sichtbaren Spektrum empfindlich sind. Dadurch sind auch Spurmarkierungen und Verkehrszeichen deutlich erkennbar. Die Detektion von Objekten erfordert üblicherweise die Segmentierung des Kamerabildes in Vordergrund und Hintergrund. Eine wichtige Rolle spielt hierbei der optische Fluss (s. [Sze11] für eine Einführung). Bewegt sich ein Objekt relativ zur Kamera, wird es in aufeinanderfolgenden Bildern auf unterschiedliche Bildkoordinaten abgebildet. Die Zuordnung der korrespondierenden Pixel zwischen den Bildern erzeugt ein Vektorfeld, das als optischer Fluss bezeichnet wird. Er repräsentiert mangels Eindeutigkeit der Zuordnung eine Schätzung der Bewegung des Objekts. Abhängig davon, ob nur markante Punkte (z. B. Ecken) oder alle Bildpunkte eines Bildes verarbeitet und zugeordnet werden, wird zwischen spärlichem und dichtem optischen Fluss unterschieden. Durch Verwendung von Stereokameras wird die Bestimmung von Entfernungen auch auf Basis von Bildsensoren möglich. Ähnlich dem menschlichen Augenpaar, wird dabei die Szene von zwei nebeneinander positionierten Kameras gleichzeitig erfasst. Durch den horizontalen Versatz ergeben sich zwischen den Bildern eines Bildpaares abhängig von der Entfernung eines erfassten Objekts perspektivische Verschiebungen (Disparität). Je näher das Objekt, umso größer ist die Disparität. Die Daimler AG kombiniert die Erfassung der Szene durch Stereokameras mit der Berechnung des optischen Flusses unter dem Namen 6D-Vision [FRBG05]. Dies ermöglicht die Erstellung von Objekthypothesen anhand der Gruppierung räumlich benachbarter Punkte mit ähnlichen Bewegungsvektoren. Diese Zuordnung kann unabhängig von der Objektklasse erfolgen und erlaubt so auch die Reaktion auf noch teilweise verdeckte Objekte [RFG07]. Da ein großer Teil des Straßenverkehrs auf die visuelle Wahrnehmung ausgelegt ist, sind Videokameras zur Realisierung vieler Fahrerassistenzfunktionen erforderlich. Die Erkennung von Spurmarkierungen, Verkehrszeichen und Ampeln erfordert die optische Erfassung. Während die Bedeutung statischer Verkehrszeichen u. U. anhand der aktuellen Fahrzeugposition und zugehöriger Kartendaten bestimmt werden kann, lassen sich zeitlich variable Informationen wie Wechselverkehrszeichen, temporäre Beschilderungen und Ampeln nur mit Hilfe von Videokameras erfassen. Des Weiteren ermöglichen Kameras die Detektion von Fußgängern und anderen Objekten, die beispielsweise per Radar nicht sichtbar sind Fahrdynamiksensoren Fahrdynamiksensoren dienen nicht der Umgebungserfassung, sondern komplementieren die Umfeldinformationen mit Zustandsinformationen über das eigene Fahrzeug. Diese sind eine weitere essenzielle Eingangsinformation für viele Assistenzsysteme. Dies gilt besonders für intervenierende Systeme, die darüber Feedback über den Eingriff erhal- 21

32 2 Fahrerassistenzsysteme Tabelle 2.1: Eigenschaften von Umfeldsensoren (nach [Sch05b; WGS04]) Ultraschall Radar Lidar ToF GPS + Kamera SRR LRR Mehr- Laser- Karte Video NIR FIR strahl scanner Reichweite in m bel Verfahren aktiv aktiv aktiv aktiv aktiv aktiv passiv passiv aktiv passiv Horizontaler Erfassungsbereich O O + + n. v Vertikaler Erfassungsbereich O + n. v Longitudinale Messgenauigkeit + O O O O O O /O a Laterale Messgenauigkeit O + + O Schlechtwetterverhalten O + + O O O + O Verhalten bei Nacht O + + a Stereokamera + gut/groß/hoch O durchschnittlich schlecht/klein/gering ten, kann aber auch warnende Systeme betreffen (z. B. zur Unterscheidung zwischen beabsichtigtem und unbeabsichtigtem Spurwechsel auf Basis des Lenkradwinkels). Raddrehzahlsensoren ermöglichen die Bestimmung der Radbewegung und Fahrzeuggeschwindigkeit. Gyroskope erfassen einerseits die Drehbewegungen des Fahrzeugs um seine Achsen, andererseits seine Beschleunigung in alle drei Raumrichtungen. Lenkradwinkel- und Bremsdrucksensoren geben Auskunft über den Fahrerwunsch [Mör12]. Die Bereitstellung dieser Informationen erfolgt über das Kommunikationsnetz des Fahrzeugs, das die Sensoren und Steuergeräte miteinander verbindet (in der Regel CAN-Bus [ISO11898], in neueren Modellen (z. B. BMW X5 [Bök08], Audi A8 [Mil08]) mittlerweile auch FlexRay [ISO10681]) Übersicht Tabelle 2.1 fasst die Eigenschaften der vorgestellten Sensoren mit Blick auf die Umfelderfassung zusammen. Die Fahrdynamiksensoren bleiben daher in der Tabelle unberücksichtigt. 2.6 Fazit Die Funktion von Fahrerassistenzsystemen beruht auf der Wahrnehmung des Fahrzeugumfelds. Auch wenn viele aktuelle Fahrerassistenzsysteme eingreifende Komponenten integrieren, um den Fahrer in kritischen Situationen nicht nur zu warnen, sondern auch aktiv unterstützen zu können, so wird dennoch deutlich, dass zur Bestimmung 22

33 2.6 Fazit der Notwendigkeit eines Eingriffs die korrekte Wahrnehmung und Bewertung der Verkehrssituation gewährleistet sein muss. Während Fehlfunktionen warnender Systeme schlimmstenfalls zur Deaktivierung des Systems durch den Fahrer führen, können fehlerhafte Auslösungen aktiver Fahrerassistenzsysteme z. B. ein Bremseingriff eine kritische Situation oder gar einen Unfall erst verursachen. Die vorgestellten Systeme können den Eindruck vermitteln, dass das Problem der Umfelderfassung und Szeneinterpretation bereits weitgehend gelöst ist. Letztendlich handelt es sich allerdings oft noch um Insellösungen, die nur einen begrenzten Einsatzbereich abdecken oder nur unter bestimmten Bedingungen funktionieren. Sowohl die Vielzahl der Sensoren und ihrer spezifischen Eigenschaften als auch das Ziel, immer mehr Teilprobleme der Fahraufgabe bis hin zur Realisierung autonomer Fahrzeuge mit Hilfe technischer Systemen zu lösen, führen zu einer starken Erhöhung der Problemkomplexität. Steigende Anforderungen an die Systeme, sowohl in Bezug auf Leistungsumfang als auch auf Sicherheit und Zuverlässigkeit, erfordern eine systematische Absicherung der verwendeten Verfahren und Systeme. Die Sicherstellung der korrekten Wahrnehmung des Umfelds sowie der angemessenen Bewertung der Verkehrssituation spielt hierfür eine entscheidende Rolle. 23

34

35 3 Evaluierung im Entwicklungsprozess Zunächst werden in diesem Kapitel der Begriff der Evaluierung präzisiert und die ihr zugrunde liegenden Fragestellungen erörtert. Um zu verdeutlichen, in welchen Phasen des Entwicklungsprozesses eine Evaluierung des Systems stattfindet und wer daran beteiligt ist, wird im Anschluss der Entwicklungsprozess für Fahrerassistenzsysteme näher betrachtet. 3.1 Ziele der Evaluierung In der vorliegenden Arbeit bezeichnet Evaluierung den Prozess zur funktionalen Bewertung eines Systems. Dabei wird das System oder die zu untersuchende Teilkomponente als Blackbox betrachtet. Das bedeutet, dass sich die Bewertung auf das beobachtbare Verhalten des Evaluierungsgegenstandes stützt, also auf die in Abhängigkeit von Eingabedaten und Parametrierung erzeugten Systemausgaben. Seine innere Struktur (z. B. Programmlogik, Kontrollfluss) wird nicht mit einbezogen. Auch Fragestellungen der (hardware-) technischen Realisierung und damit verbundene Problemfelder bleiben unberücksichtigt. Bei der Bewertung von Software und somit auch Fahrerassistenzfunktionen sind nach [Boe79] zwei Perspektiven zu unterscheiden: Validierung und Verifizierung. Validierung bezieht sich auf die Prüfung, ob der richtige Lösungsansatz gewählt wurde und das vorliegende System der gestellten Aufgabe gerecht wird. Sie soll die Frage beantworten: Do I build the right product? [Boe79, S. 713]. Ziel der Validierung ist somit die Klärung, ob die Anforderungen korrekt formalisiert wurden und folglich die Spezifikation tatsächlich ein System beschreibt, dass die gewünschte Funktion bereitstellt. Im Gegensatz dazu ist es das Ziel der Verifizierung sicherzustellen, dass das implementierte System die spezifizierten Ergebnisse erzielt. Laut [Boe79] beantwortet sie die Frage: Do I build the product right? [S. 713]. Die Verifizierung stellt also sicher, dass das System die Spezifikation, die formalisierten Anforderungen, erfüllt. Zusätzlich zur Überprüfung der korrekten Realisierung gibt es aber auch Fälle, in denen die Bewertung der Systemleistung aus anderen Gründen notwendig ist. Hierzu zählen die Durchführung von Machbarkeitsstudien oder auch der Vergleich von Systemen oder Verfahren (Benchmarking). 3.2 Das allgemeine V-Modell Wird ein System erst nach Fertigstellung auf korrekte Funktion überprüft, ist eine Behebung von Fehlern sehr aufwendig. Bereits geleistete Arbeit ist teilweise hinfällig und 25

36 3 Evaluierung im Entwicklungsprozess Testspezifikation Abnahme Testspezifikation Lieferung Zerlegung.und.Spezifikation Detaillierungsgrad Systementwurf Testspezifikation T.-S. Anfordungsdefinition Gesamtsystemspezifikation Komponentenentwurf Komponententest Integration.der. Komponenten Systemtest Integration.und.Test Implementierung Zeit Abbildung 3.1: Allgemeines V-Modell muss erneut durchgeführt werden. Stellt sich beispielsweise heraus, dass eine Anforderung fehlerhaft spezifiziert wurde, müssen große Teile des Entwicklungsprozesses erneut durchlaufen werden. Diese Vorgehensweise ist eine Charakteristik des Wasserfallmodells [Roy70], dass einen streng linearen Ablauf von Spezifikation, Implementierung und Test vorsieht. Je früher ein Fehler gefunden wird, umso kostengünstiger kann er behoben werden, da der Korrekturaufwand mit fortschreitendem Entwicklungsstand stark zunimmt [Boe79]. Daher findet das Wasserfallmodell heute nur noch in seltenen Fällen Anwendung. Das allgemeine V-Modell, das 1979 von Boehm vorgestellt wurde [Boe79], ist eine Weiterentwicklung des Wasserfallmodells. Grundsätzlich weiterhin linear im Ablauf der einzelnen Entwicklungsphasen, gestaltet es den Entwicklungsprozess hierarchisch. Dabei wird das System schrittweise in immer kleinere Einheiten zerlegt, die schließlich realisiert werden können. Den immer detaillierter werdenden Spezifikationsphasen werden korrespondierende Test- und Integrationsphasen gegenübergestellt, die im Verlauf der Entwicklung in umgekehrter Reihenfolge durchlaufen werden. Die sich daraus ergebende V-förmige Struktur, die in Abbildung 3.1 abgebildet ist, begründet den Namen des Modells. Der Entwicklungsprozess beginnt oben links mit der Anforderungsdefinition und endet oben rechts mit der Abnahme des fertigen Systems. Im absteigenden Ast des V wird das System schrittweise zerlegt und die Einzelteile jeweils spezifiziert. Der Detaillierungsgrad nimmt von oben nach unten zu. Die Spezifikationen und Anforderungen einer höheren Stufe dienen jeweils als Eingabe und Vorgabe für die folgende Stufe. Gleichzeitig werden auf jeder Stufe Testfälle definiert, die im aufsteigenden Ast zum erfolgreichen Abschluss 26

37 3.2 Das allgemeine V-Modell Reifegrad Reifegrad Einstieg Labormuster Funktionsmuster Vorserienprodukt Serienprodukt Abbildung 3.2: Iterative Anwendung des V-Modells (in Anlehnung an [VDI2206, S. 35]) der Stufe notwendig sind. Sie folgen dem Abstraktionsgrad der jeweiligen Stufe und dienen als Grundlage für die später durchzuführenden Tests. Die frühzeitige Spezifikation der Tests führt zu einer möglichst frühen Erkennung potenzieller Probleme und erlaubt so eine rechtzeitige Korrektur. Erst in der Spitze des V, also auf der untersten und detailliertesten Stufe, findet die Implementierung der einzelnen Module und Komponenten statt. Zu diesem Zeitpunkt sind sowohl das System als auch sämtliche notwendigen Testfälle vollständig spezifiziert. Im aufsteigenden Ast werden die Module und Komponenten nach und nach zusammengeführt und integriert. Die Betrachtung des Systems wird mit jeder Stufe wieder allgemeiner und abstrakter. Die Stufen des aufsteigenden Astes bilden jeweils das Äquivalent zu den Stufen des absteigenden Astes. Auf jeder Stufe werden die zugehörigen Tests durchgeführt. Erst wenn alle Tests einer Stufe erfolgreich abgeschlossen sind, beginnt die Integration auf der nächsthöheren Stufe. Prinzipiell handelt es sich beim V-Modell um ein lineares Modell, d. h. die einzelnen Stufen werden nacheinander abgearbeitet. Eine solch starre Vorgehensweise ist jedoch in der Realität oft problematisch. Zu Beginn des Entwurfsprozesses steht oft noch nicht genügend Erfahrung und Information zur Verfügung, um alle Anforderungen vorab erfassen zu können. Ergebnisse der Tests im rechten Ast können eine Änderung der zugehörigen Spezifikation notwendig machen. Dann müssen alle der Spezifikationsstufe folgenden Schritte erneut durchlaufen werden, um die Änderungen zu propagieren. Alternativ oder zusätzlich ist es auch möglich, das gesamte V-Modell mehrfach zu durchlaufen. Oft entsteht zunächst ein Labormuster, das in weiteren Iterationen des V-Modells zum Serienprodukt entwickelt wird (s. Abbildung 3.2). Eine Weiterentwicklung und Formalisierung des allgemeinen V-Modells ist das unter demselben Namen von der Bundesregierung beauftragte Vorgehensmodell zur Ent- 27

38 3 Evaluierung im Entwicklungsprozess wicklung von IT-Systemen. 1 Es wurde mit dem Ziel entwickelt, das Vorgehen und die Zusammenarbeit von Behörden und Firmen bei gemeinsamen Entwicklungen zu standardisieren [RB08]. Nachdem es ab 1986 zunächst im Bundesministerium für Verteidigung eingesetzt wurde [Hes08], hat sich der Anwendungsbereich in den 1990er Jahren erweitert wurde das V-Modell verbindlicher Standard für zivile und militärische IT-Entwicklungsprojekte des Bundes[RB08; Hes08]. Der Einsatz des Modells beschränkt sich jedoch nicht nur auf Projekte der öffentlichen Hand. Durch die freie Verfügbarkeit des Modells 2 ist sein Einsatz auch in Unternehmen möglich. 3.3 V-Modell zur Entwicklung von Fahrerassistenzsystemen Das V-Modell stellt durch die grundsätzliche Struktur und Definition zentraler Begriffe vor allem einen Rahmen zur Entwicklung von IT-Systemen dar. Die exakte Abfolge und Benennung der einzelnen Stufen ist jedoch nicht strikt vorgegeben. Das Modell sieht explizit eine Anpassung an den Anwendungsfall, sogenanntes Tailoring, vor. Dies spiegelt sich auch in der Benennung der aktuellen Version als V-Modell XT wider, worin der Zusatz XT für extreme Tailoring, steht. Diese Anpassbarkeit an die eigenen Prozesse hat zur Verwendung des V-Modells in der Entwicklung von Fahrerassistenzsystemen beigetragen [Kle+09; Mau09; AFPB11]. Auch die 2011 verabschiedete ISO-Norm 26262, die die funktionale Sicherheit von Elektrik/Elektronik-Systemen (E/E-Systeme) im Fahrzeug und somit auch von FAS regelt, stützt sich im Kern auf einen V-förmigen Entwicklungs- und Absicherungsprozess [ISO26262]. Gleiches gilt für die VDI-Richtlinie 2206 [VDI2206], die Entwicklungsmethodiken für mechatronische Systeme beschreibt, also Systeme, die Mechanik, Elektronik und Informationsverarbeitung vereinen. Im Folgenden sollen die in Abschnitt 3.2 allgemein formulierten Stufen des V-Modells in Bezug auf die FAS-Entwicklung präzisiert werden Anpassung des allgemeinen Modells Ein Fahrerassistenzsystem im Sinne eines serienreifen Produkts besteht nicht allein aus Software, sondern zusätzlich aus Hardware in Form von Sensoren, Steuergeräten und Kommunikationsnetzen. Aufgrund des Entwicklungsumfangs handelt es sich bei der Entwicklung neuer Fahrzeugfunktionen um einen stark arbeitsteiligen Prozess [Rei12, S. 79]. Die Automobilhersteller spezifizieren das System, doch die einzelnen Komponenten werden oft durch eine Vielzahl von Zulieferfirmen realisiert. Der Hersteller ist für die anschließende Systemintegration verantwortlich. Sobald im Rahmen der Spezifikation die Schnittstellen zwischen den verschiedenen Komponenten hinreichend beschrieben sind, kann der Entwicklungsprozess aufgeteilt und können Steuergeräte-Software, Steuergeräte-Hardware und ggf. notwendige Sensorik oder Aktorik unabhängig voneinander entwickelt werden (s. Abbildung 3.3). Jede 1 V-Modell ist eine geschützte Marke der Bundesrepublik Deutschland. 2 freigegeben unter der Apache License, Version

39 3.3 V-Modell zur Entwicklung von Fahrerassistenzsystemen Testfälle Abnahme Akzeptanztest Spezifikation dertlogischen TSystemarchitektur Testfälle Benutzeranforderungen Gesamtfahrzeugintegration Spezifikation derttechnischen Systemarchitektur Testfälle IntegrationTdesT Systems Integrationstest Hardware Software Sensorik/Aktorik Abbildung 3.3: Angepasstes V-Modell(in Anlehnung an [Rei12, S. 73]). Das Teilmodell zur Softwareentwicklung ist in Abbildung 3.4 abgebildet. Spezifikation SW-Architektur Testfälle Integration der SW-Komponenten Spezifikation SW-Komponenten Testfälle Test der SW-Komponenten Design und Implementierung der SW-Komponenten Abbildung 3.4: V-Modell zur Entwicklung der Softwareanteile am Gesamtprojekt (in Anlehnung an [Rei12, S. 73]) einzelne dieser Teilentwicklungen kann wieder mit dem V-Modell modelliert werden. Nach der Fertigstellung werden die Komponenten zusammengeführt und getestet. Die zur Entwicklung der Softwareanteile des Systems notwendigen Stufen sind im Teilmodell in Abbildung 3.4 dargestellt. Die Entwicklung von Fahrzeugkomponenten im Allgemeinen und Fahrerassistenzsystemen im Speziellen ist ein komplexer Prozess, dessen zahlreiche Facetten hier nicht vollständig dargestellt werden können. Im Rahmen dieser Arbeit bleiben daher die Hardwareentwicklung (Steuergeräte, Sensorik, Aktorik) und damit verbundene Fragestellungen unberücksichtigt. 29

40 3 Evaluierung im Entwicklungsprozess Spezifikation Ausgehend von den Benutzeranforderungen wird das System im absteigenden Ast des Modells mit zunehmendem Detaillierungsgrad bis zu den einzelnen Softwarekomponenten spezifiziert. Dazu wird zunächst die gewünschten Funktionalität des Systems definiert. Was soll das System leisten? Welchen Nutzen soll es dem Fahrer bieten? Die Anforderungen beschreiben den Teil des Systems, der für den Benutzer sichtbar bzw. erfahrbar ist. Die oftmals informell in Prosa formulierten Benutzeranforderungen werden in eine formale Struktur überführt. Dies geschieht durch Analyse der Anforderungen und Identifikation von inhaltlich zusammengehörigen Teilen und ihrer Interaktion. Diese lassen sich in einem Blockdiagramm darstellen. Verbindungen zwischen den einzelnen Blöcken modellieren dabei logische Signale und Abhängigkeiten. Die logische Systemarchitektur wird auch als Funktionsarchitektur oder Funktionsnetzwerk [Rei12; SZ13] bezeichnet. Für jede logische Komponente werden die Funktionalität, die Anforderungen und notwendigen Schnittstellen definiert. Die Anforderungen unterteilen sich dabei in funktionale und nicht-funktionale Anforderungen. Erstere beschreiben das Verhalten des Systems sowohl für den Normalfall als auch den Fehlerfall [SZ13], letztere die Randbedingungen, unter denen dieses Verhalten zu erzielen ist. Zu nicht-funktionalen Anforderungen zählen beispielsweise Kostengrenzen, mögliche Größenbeschränkungen oder Einsatzbedingungen (z. B. Versorgungsspannung, Temperaturbereich) [SZ13]. Die Anforderungen beschränken sich dabei nicht nur darauf, welche Eigenschaften das System haben soll, sondern umfassen auch, welche es nicht haben darf. Erst im Rahmen der Spezifikation der technischen Systemarchitektur erfolgt die Auswahl der technischen Komponenten, d. h. der konkreten Sensoren, Aktuatoren, Steuergeräte sowie der zu ihrer Vernetzung einzusetzenden Bussysteme. Dabei erfolgt die Zuordnung der logischen Funktionsblöcke und Signale zu Steuergeräten und Busnachrichten. Für die Spezifikation der Softwarearchitektur (s. Abbildung 3.4)werden die durch Software zu realisierenden Anteile der Gesamtfunktion in funktional zusammengehörige Blöcke unterteilt. Dabei wird einerseits die logische Systemarchitektur berücksichtigt, andererseits auch die technische. Die einzelnen Komponenten werden also so ausgelegt, dass sie sich sowohl eindeutig einem Funktionsblock in der logischen Systemarchitektur als auch einem Steuergerät in der technischen Systemarchitektur zuordnen lassen. Nachdem die Softwarearchitektur und damit die Aufteilung der Software in einzelne Komponenten vollständig ist, werden im nachfolgenden Schritt die einzelnen Softwarekomponenten spezifiziert. Dies umfasst die Definition der zu verwendenden Datenstrukturen (Datenmodell), den Programmablauf (Kontroll- und Datenfluss), sowie die zeitlichen Eigenschaften der Datenverarbeitung [SZ13]. Im Rahmen eines kamerabasierten Fahrerassistenzsystems kann es sich hierbei z. B. um Komponenten zur Merkmalsextraktion oder Objektdetektion handeln. Bereits während der einzelnen Spezifikationsphasen kann es notwendig sein, durch Konzept- und Prototypenimplementierungen die Machbarkeit eines Ansatzes zu demonstrieren oder die Leistungsfähigkeit eines Sensors zu erproben. Je nach Umfang der Untersuchungen kann es sich hierbei um die Entwicklung eines Labormusters handeln, 30

41 3.3 V-Modell zur Entwicklung von Fahrerassistenzsystemen die, wie in Abbildung 3.2 dargestellt, selbst auf Basis des V-Modells durchgeführt wird, oder auch um Tests in kleinerem und ggf. informellem Rahmen, die der Entwickler selbst durchführt. Es werden somit auch außerhalb der expliziten Testphasen des V-Modells Möglichkeiten und Werkzeuge zur Evaluierung benötigt Implementierung Auf der untersten Stufe des V-Modells wird der höchste Grad der Detaillierung erreicht. Hier werden die einzelnen Komponenten in einer konkreten Programmiersprache implementiert. Die Softwarekomponenten werden auf konkrete Funktionen oder Klassen abgebildet. Die im Datenmodell abstrakt spezifizierten Datenstrukturen werden in konkrete Datentypen übersetzt. Grundsätzlich empfiehlt sich eine personelle Aufteilung von Entwicklungs- und Testaufgaben [SL05]. Doch auch bei einer strengen Trennung von Entwicklungs- und Testphasen und Zuweisung der Aufgaben an unterschiedliche Personen oder Teams, besteht auch für die Entwickler der Bedarf, eine implementierte Komponente zu testen: einerseits, um den Entwicklungsfortschritt zu demonstrieren; andererseits, um vor der Freigabe in den Testprozess sicherzustellen, dass die Komponente grundlegende Qualitätsanforderungen erfüllt (Lauffähigkeit, grundsätzlich korrekte Funktion). Sollte sich eine Komponente in den anschließenden Testphasen als fehlerhaft erweisen, benötigt der Entwickler außerdem die notwendigen Analysewerkzeuge, um den Fehler reproduzieren und die Ursache bestimmen zu können Integration und Test Mit der Implementierung ist der linke Ast des Systems vollständig. Im rechten, aufsteigenden Ast folgt nun die schrittweise Integration der einzelnen Komponenten zum Gesamtsystem (zunächst Software, später auch Hardware). Begleitet wird dieser Prozess durch gründliche Tests. Diese Tests folgen in Art und Detaillierung der Abstraktion des Systems auf der entsprechenden Integrationsstufe. Die einzelnen Testfälle wurden bereits während der Spezifikation definiert bzw. können direkt aus der Spezifikation abgeleitet werden. In allen Tests werden die Testgegenstände zunächst isoliert geprüft. Erst nach bestandenem Test werden sie auf der nächsthöheren Stufe integriert. Für die funktionale Bewertung wird der Testgegenstand zur Ausführung gebracht und das von außen beobachtbare Verhalten auf Korrektheit geprüft. Dabei ist zu beachten, dass ein erfolgreicher Test keine Fehlerfreiheit des Systems nachweisen kann. Tests können nur bei Fehlschlagen die Existenz eines Fehlers nachweisen. Durch umfangreiche Testfälle wird jedoch versucht, das Risiko, dass der Testgegenstand fehlerbehaftet ist, ausreichend zu minimieren. Welches Restrisiko akzeptabel ist, hängt dabei vom Anwendungsfall ab. Leitet ein Notbremsassistent beispielsweise auf freier Strecke eine Vollbremsung ein, kann dieses Fehlverhalten selbst zur Unfallursache und somit zur Gefahr für Leib und Leben werden. Für ein Assistenzsystem, dass den Fahrer lediglich über die aktuelle Geschwindigkeitsbegrenzung informiert, aber nicht in den Fahrprozess eingreift, ist die fehlerhafte Erkennung eines Verkehrsschildes weniger kritisch. 31

42 3 Evaluierung im Entwicklungsprozess Fehlgeschlagene Tests machen einen Rücksprung zu einer früheren Stufe des V-Modells erforderlich. Programmierfehler müssen von den Entwicklern behoben werden, u. U. ist jedoch auch die Spezifikation anzupassen oder zu verfeinern, falls sie sich als lückenhaft oder fehlerhaft herausgestellt hat. Anschließend müssen alle nachfolgenden Phasen erneut durchlaufen werden, um die Änderungen zu berücksichtigen. Auch bereits erfolgreich abgeschlossene Tests sind zu wiederholen, um Regressionen, also durch die Änderungen verursachte Fehler, auszuschließen. Entsprechend den Stufen des V-Modells ist zunächst die korrekte Funktion der einzelnen Softwarekomponenten zu prüfen. Hierbei kommen sowohl statische als auch dynamische Verfahren zum Einsatz. Da die Komponenten in der Regel nicht selbständig lauffähig sind, erfordert ihre Ausführung eine Testumgebung. Außerdem benötigt der Tester Möglichkeiten zur Bewertung der Ergebnisse. Der isolierte Test der einzelnen Komponenten soll Fremdeinflüsse bei der Fehlerverursachung ausschließen [SL05]. Mögliche Fehlerwirkungen können so gezielt der jeweiligen Komponente zugeordnet werden und folglich lassen sich ihre Ursachen leichter lokalisieren. Sobald die Softwarekomponenten isoliert funktionsfähig sind, kann ihr Zusammenspiel getestet werden. Hierbei ist eine schrittweise Integration vorteilhaft, da Fehler so frühzeitig entdeckt und schneller lokalisiert werden können. Abhängig von der Komplexität der Software kann sich die Durchführung von Komponenten- und (Software-)Integrationstests überschneiden. Bilden die einzelnen Komponenten eine Verarbeitungskette und bauen aufeinander auf, ist es u. U. schwierig, passende Eingabedaten für den Test der späteren Komponente bereitzustellen. In diesem Fall kann auch eine frühere Komponente zur Erzeugung der Eingabedaten dienen. Nach [SZ13] und [Rei12] ist das Ziel der Integration der Softwarekomponenten die Erzeugung der auf einem Mikroprozessor ausführbaren Gesamtsoftware. Dies ist eine sehr Steuergerät- und hardware-zentrierte Sicht. Eine funktionale Betrachtung des Systems abstrahiert die Zuordnung einer Softwarekomponente zu einem bestimmten Steuergerät und spiegelt die in der logischen Systemarchitektur dargestellte Aufteilung wider. Diese Sichtweise stellt in den Hintergrund, wie die dort spezifizierten Signale zwischen unterschiedlichen Komponenten ausgetauscht werden. Sie nimmt eine Abstraktionsschicht als gegeben an, die diese Kommunikation bereitstellt. Für die einzelnen Komponenten ist diese Kommunikation idealerweise vollständig transparent. Nach Abschluss der Integration der Softwarekomponenten werden die Ergebnisse des aufgeteilten Entwicklungsprozesses zusammengeführt, und die Software wird im Rahmen der Systemintegration erstmalig auf der Zielhardware ausgeführt und die korrekte Funktion überprüft. Aus funktionaler Sicht bedeutet dies vor allem, dass die Software bei gleichen Eingaben dieselben Ergebnisse erzeugt wie auf dem Entwicklungsrechner, dass also die Tatsache, dass die Software auf anderer Hardware ausgeführt wird, das Berechnungsergebnis nicht beeinträchtigt. Externe Komponenten können dabei durch simulierte Komponenten (oft auch als virtuelle Hardware bezeichnet) ersetzt werden. Bei korrekter Funktion können die simulierten Komponenten nach und nach durch reale Hardware ersetzt werden. Ähnlich wie bei der schrittweisen Integration der Software können so auftretende Fehler schneller lokalisiert werden. Des Weiteren verringert das stufenweise Vorgehen die Synchronisierungsanforderungen an parallel laufende 32

43 3.4 Fazit Entwicklungszweige. Bereits fertiggestellte Komponenten können frühzeitig ausgiebig getestet werden, auch wenn andere Komponenten noch nicht zur Verfügung stehen. Nach dem erfolgreichen Systemintegrationstest wird das System ins Fahrzeug integriert, um so die Erprobung des Systems außerhalb des Labors zu ermöglichen. Dadurch erweitert sich der Umfang der möglichen Testszenarien: einerseits durch das stark vergrößerte Spektrum möglicher Eingabedaten; andererseits durch die Möglichkeit, aktive Eingriffe testen zu können. Bei der Abnahme des Systems gilt es zu überprüfen, ob es die initial gestellten Benutzeranforderungen erfüllt. Dabei wird nun das Gesamtsystem als Blackbox betrachtet. Es wird also das Verhalten des Systems geprüft, ohne dessen innere Struktur zu berücksichtigen. Diese Akzeptanztests dienen der Validierung des Systems. Spätestens jetzt muss die Frage beantwortet werden, ob das System den Bedürfnissen und Erwartungen des Benutzers (also letztlich des Käufers) gerecht wird. Während eine Nichterfüllung ggf. bereits in früheren Stufen aufgedeckt und durch Iteration korrigiert werden kann, steht erst in dieser Stufe das tatsächliche, vollständige System zur Verfügung, um diese Frage abschließend zu beantworten. 3.4 Fazit Das V-Modell folgt dem teile-und-herrsche-prinzip. Die hierarchische Zerlegung des Problems und anschließende Integration macht die Komplexität des Gesamtproblems beherrschbar in Bezug auf Spezifikation, Implementierung und Test. Trotz der linearen Grundstruktur des Modells lässt sich eine iterative Entwicklung realisieren. Außerdem erlaubt die Zerlegung einen arbeitsteiligen Prozess. Dies betrifft nicht nur unterschiedliche Personen und Abteilungen innerhalb einer Firma, sondern ermöglicht auch die Auslagerung von Teilentwicklungen zu einem Zulieferer. Durch die Verankerung des Modells in der 2011 eingeführten ISO-Norm [ISO26262] ist es das Standardentwicklungsmodell im Bereich Fahrerassistenzsysteme. Es wurde deutlich, dass sich die Evaluierung eines Systems oder einer Systemkomponente nicht auf den aufsteigenden, integrierenden Zweig des V-Modells und die explizit als Testphasen deklarierten Stufen beschränkt. Die Bewertung des Systems und seiner Komponenten begleitet den vollständigen Entwicklungsprozess. 33

44

45 4 Struktur und Anforderungen der Evaluierung In diesem Kapitel werden die Anforderungen und Voraussetzungen für eine aussagekräftige Evaluierung betrachtet. Dabei geht es zunächst um die Frage, wie der Evaluierungsprozess strukturiert ist und welche Anforderungen er erfüllen muss. Dazu wird ein Modell des Prozesses vorgestellt, aus dem die relevanten Bewertungsszenarien abgeleitet werden. Anschließend wird näher auf die Anforderungen und Rahmenbedingungen bezüglich der benötigten Testdaten eingegangen. Dies umfasst insbesondere die Auswahl relevanter Testszenarien, die Erhebung der notwendigen Sensordaten sowie die Erzeugung korrespondierender Referenzdaten. Zum Abschluss werden allgemeine Anforderungen an die problemspezifisch verwendeten Bewertungsverfahren formuliert, die eine Interpretation und Analyse der Bewertungsergebnisse zulassen. 4.1 Makromodell zur Systembewertung Die Bewertung eines in natürlicher Umgebung eingesetzten Computer Vision-Systems erfordert aufgrund der Komplexität von System und Problemstellung eine Ausführung dieses Systems. Dazu ist es in geeigneter Weise mit relevanten Eingabedaten zu versorgen, und die aus deren Verarbeitung resultierenden Ausgaben sind abhängig von der Zielsetzung zu bewerten. Makroskopisch betrachtet ist die Bewertung eines Systems daher gemäß Abbildung 4.1 schematisch darstellbar. Sie setzt sich zusammen aus den drei Blöcken Daten, System und Bewertung. Block A: Daten repräsentiert die notwendigen Testdaten. Diese bestehen aus Eingabedaten des Systems (z. B. Sensordaten) und zugehörigen Referenzdaten, die das korrekte Ergebnis repräsentieren oder dessen Berechnung ermöglichen. Block B: System repräsentiert das zu bewertende, zu testende System (auch als System unter Test (SUT) bezeichnet). Abhängig von der Betrachtungsebene kann es sich dabei um das Gesamtsystem, ein Teilsystem oder eine einzelne Komponente handeln. Basierend auf A Daten B System C Bewertung Abbildung 4.1: Makromodell zur Systembewertung 35

46 4 Struktur und Anforderungen der Evaluierung den Eingabedaten in Block A generiert das System seiner Funktion entsprechende Ausgaben als beobachtbares Verhalten. Das System wird als Blackbox betrachtet. Der Test berücksichtigt nur die funktionale Ebene, Details der Implementierung werden nicht beachtet. Block C: Bewertung repräsentiert die Bewertung der Systemausgaben durch Berechnung von Gütemaßen. Diese Berechnung erfolgt dabei in der Regel durch Vergleich der Verarbeitungsergebnisse mit den Referenzdaten. Die drei Blöcke sind insofern unabhängig voneinander, dass sie kein Wissen über die innere Struktur, Implementierung oder Realisierung der jeweils anderen Blöcke berücksichtigen. Das Prinzip der Blackbox wird in diesem Modell nicht nur auf das System, sondern jeweils auch auf die Daten und die Bewertung angewendet. Konkret bedeutet dies, dass sowohl die Daten als auch die Bewertung rein problemgetrieben erstellt werden, ohne gezielt Aspekte einer bestimmten Implementierung des Systems zu beachten. Auch für das System gilt, dass es nicht auf bestimmte Eigenschaften eines spezifischen Datensatzes setzen darf, sofern sich diese nicht aus der Problemstellung ableiten lassen (z. B. Rauschverteilung, Sensorartefakte, spezielle Aufnahmesituation). Dennoch sind die Blöcke auch abhängig voneinander in dem Sinne, dass zur Ausführung eines Blocks die Verfügbarkeit der jeweils notwendigen Eingaben durch die vorhergehenden Blöcke sichergestellt sein muss. Für die Bewertung ist es notwendig, dass sowohl die Referenzdaten als auch die Systemergebnisse verfügbar sind, wobei zur Berechnung der Systemausgaben wiederum entsprechende Eingabedaten benötigt werden. Dies impliziert, dass zur Ausführung jedes Blocks auch die Anforderungen der vorherigen Blöcke erfüllt sein müssen. 4.2 Bewertungsszenarien Eine Kombination A i B j C k repräsentiert für beliebige, aber feste i,j,k eine Bewertungskonfiguration im Sinne des obigen Modells. Durch Variation einzelner Blöcke lassen sich unterschiedliche Bewertungsszenarien realisieren. Zur besseren Lesbarkeit wird im Folgenden für die jeweils unveränderten Komponenten auf einen Index verzichtet Variation der Eingabedaten Um die Robustheit und Generalisierungsfähigkeit eines Verfahrens zu überprüfen und problematische Fälle zu identifizieren, ist die Austauschbarkeit der Eingabedaten notwendig. Die Konfiguration A i BC bezeichnet diese Variation der Testdaten, mit denen System B anhand der Gütekriterien C bewertet wird. Dabei können die A i einzelne Testfälle oder -szenarien wie z. B. Autobahn-, Landstraßen- oder Stadtfahrt innerhalb eines Testdatenbestandes repräsentieren, aber auch vollständige, unterschiedliche Testdatenbestände wie z. B. öffentlich verfügbare problemrelevante Datensätze Variation des Systems Innerhalb des Entwicklungsprozesses werden Test- und Bewertungsphasen häufig mehrfach durchlaufen. Nach Änderungen des Entwicklungsgegenstandes, z. B. aufgrund von 36

47 4.3 Anforderungen an den Evaluierungsprozess festgestellten Fehlern oder unzureichender Systemleistung, müssen sowohl fehlgeschlagene als auch erfolgreiche Tests erneut ausgeführt werden, um sicherzustellen, dass der Mangel beseitigt wurde ohne an anderer Stelle neue Fehler zu verursachen (sog. Regressionstests). Im Rahmen der Entwicklung führt jede Änderung oder Ergänzung eines Systems B j zu einem neuen System B j+1. Da sowohl die Eingabedaten als auch die Bewertungsverfahren unverändert bleiben, lässt sich die Weiterentwicklung eines Systems im Modell durch AB j C beschreiben. Die Bewertung unterschiedlicher Systeme B j auf identischen Eingabedaten A auf Basis des Bewertungsprotokolls C ist ebenfalls relevant, um im Rahmen eines Benchmarks die Leistung unterschiedlicher Systeme und Lösungsansätze zu vergleichen Variation der Bewertung Durch Variation von Block C in der Konstellation ABC k lassen sich unterschiedliche Bewertungskriterien und nachträgliche Anpassungen der Spezifikation bezüglich der erforderlichen Systemgüte realisieren, ohne das getestete System oder die Testdaten verändern zu müssen. 4.3 Anforderungen an den Evaluierungsprozess Der Evaluierungsprozess beschreibt den Gesamtablauf der Evaluierung im Rahmen des vorgestellten Makromodells. Er umfasst die gesamte Verarbeitungskette von der Bereitstellung der relevanten Eingabedaten, ihrer Verarbeitung durch das zu bewertende System sowie die anschließende Bewertung der Systemausgaben auf Basis der Referenzdaten. Für die Aussagekraft der erzielten Ergebnisse ist die Erfüllung der folgenden Anforderungen elementar Wiederholbarkeit und Reproduzierbarkeit Sowohl die Ergebnisse einer Evaluierung ABC als auch der Prozess ihrer Erzeugung müssen überprüfbar und nachvollziehbar sein. Um dies zu ermöglichen, muss der Prozess wiederholbar und müssen die Ergebnisse reproduzierbar sein. Werden bei der Bewertung Mängel festgestellt, bilden Wiederholbarkeit und Reproduzierbarkeit die Voraussetzung für eine effiziente Fehlersuche und Ursachenanalyse. Sie gewährleisten, dass ein Fehler unter identischen Bedingungen reproduziert werden kann. Des Weiteren ermöglichen die Wiederholbarkeit und die Reproduzierbarkeit die Interpretation von Ergebnisunterschieden, die durch eine Variation der Daten, des Systems oder der Bewertung verursacht werden können Vergleichbarkeit von Ergebnissen Um die Ergebnisse unterschiedlicher Evaluierungskonfigurationen objektiv vergleichen zu können, ist es notwendig, dass sie unter identischen Bedingungen zustande gekommen sind. Dazu ist die Wiederholbarkeit des Evaluierungsprozesses eine notwendige 37

48 4 Struktur und Anforderungen der Evaluierung Voraussetzung. Sie ermöglicht es, abweichende Ergebnisse den Unterschieden der erzeugenden Evaluierungskonfigurationen zuordnen zu können, und schließt aus, dass diese Abweichungen durch den Evaluierungsprozess selbst hervorgerufen werden. Aus der Reproduzierbarkeit der Ergebnisse innerhalb einer Konfiguration folgt, dass sich bei einer Veränderung abweichende Ergebnisse auf diese Änderung zurückführen lassen. Um Unterschiede der Ergebnisse interpretieren zu können, ist es wichtig, dass sich die Unterschiede der Konfiguration auf einen einzelnen Block (Daten, System oder Bewertung) beschränken. Dazu ist es notwendig, dass die Veränderung oder der Austausch eines Blocks unabhängig von den jeweils anderen beiden Blöcken erfolgt. Dies betrifft sowohl eine Veränderung der Daten als auch des Systems (sowohl inkrementell während der Entwicklung als auch durch vollständigen Austausch durch ein anderes Verfahren in einem Benchmarking-Szenario). Für die Bewertung gilt dies nur in eingeschränktem Maße, sofern die Veränderung nicht strukturell ist, sondern sich auf eine Anpassung von Parametern (z. B. Schwellwerten) beschränkt. Im Rahmen des Benchmarkings, dessen Ziel der objektive Vergleich der Ergebnisse der Bewertung unterschiedlicher Systeme ist, ist es unabdingbar, dass sich die Evaluierungskonfigurationen nur in einem Punkt dem verwendeten Verfahren bzw. System unterscheiden. Die verglichenen Systeme müssen unter identischen Bedingungen bewertet werden, um Unterschiede der Systemleistung eindeutig dem jeweiligen System zuordnen zu können. Es ist entscheidend, dass der Evaluierungsprozess nicht nur methodisch wiederholt wird, sondern dass auch die Eingabedaten identisch sind. Wird System B 1 auf Datensatz A 1 bewertet, System B 2 jedoch auf Datensatz A 2 lassen sich die Ergebnisse auch bei identischem Bewertungsprotokoll C nicht vergleichen, da sich Unterschiede in den Ergebnissen nicht eindeutig den verwendeten Verfahren oder den verwendeten Daten zuordnen lassen. Hierzu ist entweder die Bewertung von B 1 auf Datensatz A 2 oder von B 2 auf Datensatz A 1 notwendig. Dann ermöglicht der Vergleich der Ergebnisse von A 1 B 1 C und A 2 B 1 C sowie von A 1 B 2 C und A 2 B 2 C Rückschlüsse auf den Einfluss der Eingabedaten auf die Systemleistung, der Vergleich von A 1 B 1 C und A 1 B 2 C respektive A 2 B 1 C und A 2 B 2 C Rückschlüsse auf den Einfluss des Verfahrens. Häufig werden bei der Vorstellung einer neuen Methode Ergebnisse auf eigens hierfür erhobenen Daten präsentiert. Dies begrenzt die Aussagekraft dieser Ergebnisse, da sie nicht mit bereits veröffentlichen Resultaten anderer Methoden verglichen werden können. Um die Methoden dennoch in Bezug zueinander setzen zu können, werden die Vergleichsmethoden oft nachimplementiert und ebenfalls auf die neu erhobenen Daten angewendet. Dies kann jedoch in der Regel nur näherungsweise geschehen, da die verfügbaren theoretischen Beschreibungen der Vergleichsmethoden aufgrund der Komplexität der betrachteten Verfahren als Basis häufig unzureichend sind. In der Praxis kommt es auf die jeweiligen Parameterwerte, die genaue Implementierung und u. U. auf nicht oder nur sehr knapp dokumentierte Zusatzschritte wie eine Vorverarbeitung der Eingabedaten an. Daher sollte eine neue Methode soweit möglich nicht nur anhand derselben Bewertungsregeln, sondern auch auf denselben Daten evaluiert werden. Entsprechende Datensätze zwar stehen immer öfter frei zur Verfügung, sind aber häufig nicht so aufbereitet (z. B. in Bezug auf die verfügbare Dokumentation und die verwendeten Datenformate), dass die 38

49 4.4 Eingabedaten Verwendung für andere Personen mit geringem Aufwand möglich ist. Es besteht daher großer Bedarf an öffentlich verfügbaren und detailliert dokumentierten Datensätzen (s. a. [GLSG10]). Idealerweise werden diese unabhängig von einer bestimmten Methode erstellt, um eine implizite Anpassung daran zu vermeiden. 4.4 Eingabedaten Sowohl während der Entwicklung eines Fahrerassistenzsystems als auch zu seiner Bewertung sind Eingabedaten in Form von Sensordaten notwendig. Dabei kann es sich um die Daten eines einzelnen Sensors wie z. B. einer Kamera handeln. Oft werden jedoch Daten mehrerer Sensoren benötigt, um die gewünschte Funktionalität bereitstellen zu können. Dabei kann es sich um gleichartige Sensoren handeln (wie z. B. im Falle eines Top-View-Systems, dass aus den Bildern mehrerer Kameras eine gemeinsame Darstellung erzeugt), oder auch eine Kombination unterschiedlicher Sensormodalitäten. Grundsätzlich sind in Hinblick auf die Herkunft der Eingabedaten zwei Ansätze zu unterscheiden. Sie schließen sich in ihrer Verwendbarkeit jedoch nicht gegenseitig aus, sondern ergänzen sich. Essenziell sind reale Daten, die das spätere Einsatzgebiet des Systems erfassen. Diese werden im Straßenverkehr oder auf Teststrecken mit einem entsprechend ausgestatteten Versuchsträger erfasst. Ergänzend können synthetische, durch Simulationsumgebungen erzeugte Daten verwendet werden, um den Entwicklungsund Absicherungsprozess deutlich zu vereinfachen. Unabhängig von der Art der verwendeten Eingabedaten müssen zunächst relevante Testszenarien identifiziert werden, die in den Eingabedaten repräsentiert sein sollen Definition von Testszenarien Ein Fahrerassistenzsystem soll grundsätzlich in allen Verkehrssituationen korrekt funktionieren. 1 Der Straßenverkehr ist jedoch hochkomplex und hochvariabel. Unterschiedliche Umgebungen (z. B. Stadt, Land, Autobahn), Witterungsbedingungen, Lichtverhältnisse, Tages- und Jahreszeiten, Art und Anzahl anderer Verkehrsteilnehmer sowie deren individuelles Verhalten führen dazu, dass keine Situation exakt einer anderen gleicht (s. Abbildung 4.2). Diese Vielzahl an Einflussfaktoren macht deutlich, dass eine vollständige Erfassung und Tests aller Kombinationen und Möglichkeiten nicht möglich sind. Deshalb müssen relevante Testklassen identifiziert und entsprechende Testszenarien definiert werden. Als Grundlage dienen die in der Spezifikation des Systems formulierten Anforderungen, die beschreiben, unter welchen Bedingungen das System wie funktionieren soll. Dabei ist zu berücksichtigen, dass verschiedene Situationen unterschiedlich häufig auftreten. Gerade kritische Situationen, in denen der Fahrer auf die Unterstützung des Systems angewiesen ist, sind im Vergleich zur Gesamtfahrstrecke bzw. Gesamtfahrzeit selten. Statistisch ereignet sich z. B. auf deutschen Autobahnen nur ein schwerer Unfall pro fünf Millionen gefahrene Kilometer [WW12]. 1 Dazu gehört auch die korrekte Deaktivierung außerhalb des Betriebsbereichs. 39

50 4 Struktur und Anforderungen der Evaluierung Abbildung 4.2: Verschiedene Verkehrssituationen Für ein System zur Fußgängererkennung wäre es z. B. möglich, einen Schwerpunkt auf bebaute Gegenden zu legen, da dort mit größerer Wahrscheinlichkeit Fußgänger zu erwarten sind als z. B. auf Autobahnen. Dadurch können sehr viele unterschiedliche Erscheinungsformen von Fußgängern (in Bezug auf Größe, Kleidung oder Körperhaltung) in vielen unterschiedlichen Situationen erfasst werden. Allerdings ist gerade dann eine Unterstützung durch ein Fahrerassistenzsystem wünschenswert, wenn der Fahrer eine bestimmte Gefahrensituation (wie z. B. Personen auf/an der Autobahn) nicht erwartet. Auch diese Situationen sind daher als Testfälle relevant. Die definierten Testfälle dürfen sich nicht auf Szenarien innerhalb des Betriebsbereiches beschränken, sondern müssen auch Szenarien an den Systemgrenzen abdecken. Dazu zählen auch Negativszenarien, in denen das System korrekterweise nicht auslösen darf. Für die Fußgängererkennung wären dies Streckenabschnitte ohne Fußgänger, um sicherzustellen, dass die Häufigkeit von Fehldetektionen hinreichend klein ist. Da die definierten Testszenarien die Realität nur begrenzt abbilden können, werden am Ende der Entwicklung in der Regel Feldversuche (Field Operational Test, FOT) durchgeführt. Dazu wird eine große Anzahl Fahrzeuge mit dem neuen System ausgestattet und über einen längeren Zeitraum (mehrere Monate) im täglichen Gebrauch verwendet. Auch nach der Markteinführung eines Systems werden weiterhin umfangreiche Feldversuche realisiert, um den Einfluss der Assistenzsysteme auf den Fahrer und das Fahrverhalten zu bestimmen (z. B. eurofot [Ben+12], telefot [WZE12]). So entsteht ein Gesamtfahrvolumen von mehreren Millionen Kilometern. Hier können nur in begrenztem Umfang Daten erhoben werden, da die Gesamtmenge der erfassten Sensordaten insbesondere 40

51 4.4 Eingabedaten bei der Verwendung von Kameras prohibitiv groß wäre. Das System muss zum Zeitpunkt des Feldversuchs bereits sehr ausgereift sein, da notwendige Änderungen hohe Kosten verursachen. Insbesondere für frühere Entwicklungs- und Testphasen steht diese Methode daher nicht zur Verfügung Reale Daten Reale Daten bezeichnen Daten, die mit der tatsächlichen (oder besonders in frühen Entwicklungsstadien mit der späteren vergleichbaren) Sensorik erfasst und dem System zugeführt werden. Ein Versuchsträger wird mit entsprechender Sensorik ausgestattet und im Straßenverkehr bewegt. Das zu erprobende System wird also direkt in der Zielumgebung eingesetzt. Im direkten Einsatz im Straßenverkehr ist die Reproduzierbarkeit nur begrenzt gegeben, da nur eine eingeschränkte Kontrolle über die Verkehrssituation vorliegt. Sollte es bei einem dieser Tests zu einem Fehlverhalten kommen, kann nicht garantiert werden, dass dieser Fehler bei einer Versuchswiederholung reproduziert werden kann. Daher ist prinzipiell eine Aufzeichnung der Daten notwendig. Durch die Komplexität und die Vielzahl der möglichen Verkehrssituationen ist der Umfang solcher Datensammlungen jedoch immer begrenzt und es gilt, eine ausreichende Häufigkeit relevanter Szenarien in der Datenbasis zu gewährleisten (s. Abschnitt 4.4.1). Versuche im Fahrzeug sind sehr kosten- und zeitintensiv. Aufgrund des nötigen Ausstattungsaufwands (Sensorik, Rechenkapazität, Bedieneinheiten) sind der Aufbau und die Wartung eines Versuchsträgers sehr teuer. Hinzu kommen Kosten und Zeit für Umbauten bei Änderungen der technischen Anforderungen sowie hohe Betriebskosten. Folglich stehen entsprechend ausgestattete Versuchsträger nur in begrenzter Anzahl (u. U. nur ein einziger) zur Verfügung. Das bedeutet auch, dass Versuche im Fahrzeug in der Regel auf einen sehr kleinen Personenkreis beschränkt sind. Im Gegensatz dazu können aufgezeichnete Daten von vielen Personen gleichzeitig genutzt werden. Sie machen die Verarbeitung der Daten unabhängig von Zeit und Ort der Aufnahme und ermöglichen so die Arbeit im Labor, wo bessere Arbeitsbedingungen zur Verfügung stehen. Um aufgezeichnete Realdaten zu Auswertungszwecken nutzen zu können, müssen diese in der Regel in einem aufwendigen Nachbearbeitungsprozess um Referenzdaten ergänzt werden (s. folgender Abschnitt 4.5). Dies stellt zusätzlich zu den Betriebskosten des Versuchsträgers einen erheblichen Kostenfaktor dar. Ist die Reproduzierbarkeit von Testergebnissen ein starker Vorteil aufgezeichneter Daten, so führt dies auf der anderen Seite dazu, dass rückgekoppelte Systeme nicht oder nur eingeschränkt zu testen sind. Ein Verfahren zur automatischen Belichtungssteuerung ist z. B. darauf angewiesen, das veränderte Parameter bei der Erfassung weiterer Bilddaten berücksichtigt werden. Dies ist bei aufgezeichneten Daten nicht möglich. Ähnliches gilt auch für eingreifende Systeme, bei denen ein signalisierter Eingriff zu einer Inkonsistenz der vom Algorithmus erwarteten Daten und der tatsächlich verfügbaren Daten führt (z. B. eine geänderte Kameraperspektive nach Lenkeingriff). Diese Einschränkung betrifft aber nur den eingreifenden Teil der Funktion eines Systems. Die Bewertung der Wahrnehmung des Systems, also die im Vorfeld notwendige Verarbeitung der Sensordaten 41

52 4 Struktur und Anforderungen der Evaluierung und die korrekte Erkennung der kritischen Situation inklusive der Signalisierung des Eingriffs ist auch mit aufgezeichneten Daten möglich. Reale Daten bieten den Vorteil, das sie das spätere Einsatzszenario abbilden. Dies gilt sowohl für die Art der Szenarien (Stadt, Land, Autobahn) als auch die Einflüsse von Witterungs- und Lichtverhältnissen oder sensorspezifischen Eigenschaften (Rauschverhalten, Verschmutzung). Da ein System im späteren Praxiseinsatz in einem sehr breiten Spektrum von Umwelteinflüssen und Verkehrssituationen funktionieren soll, ist auch ein entsprechender Umfang an Testdaten und -situationen notwendig, um das korrekte Systemverhalten sicherzustellen und repräsentative Ergebnisse zu erzielen. Testszenarien, die ein bestimmtes Verhalten voraussetzen, lassen sich auf realen Daten oft nicht oder nur mit sehr viel Aufwand durchführen, da die benötigte Konstellation selten vorkommt oder weil sie besonders gefährlich ist (z. B. ein plötzlich ausscherendes Fahrzeug oder ein überraschend auftauchender Fußgänger, der den Fahrweg kreuzt, wie beispielsweise ein Kind mit einem Ball). Um eine ausreichende Häufigkeit seltener Ereignisse in der Datenbasis zu gewährleisten, sind aufwendige, umfangreiche Testfahrten notwendig. Alternativ ist es u. U. möglich, Szenarien mit einer entsprechenden Anzahl eigener Akteure nachzustellen. Für kritische Situationen muss jedoch aus Sicherheitsgründen auf Testpuppen oder Attrappen zurückgegriffen werden Synthetische Daten Im Gegensatz zu realen Daten ist die Verwendung synthetischer Daten sehr viel kostengünstiger. Hierzu wird ein Simulationssystem eingesetzt, dass die benötigten Sensordaten modellbasiert erzeugt. Im Kontext kamerabasierter Assistenzsysteme handelt es sich hierbei in der Regel um eine dreidimensionale Darstellung des Straßenverkehrs in dem sich das Ego-Fahrzeug bewegt und aus dessen Sicht die synthetischen Sensordaten berechnet werden. Die darzustellende Szene unterliegt der vollständigen Kontrolle durch das Simulationssystem. Streckengeometrie, Straßeneigenschaften, Randbebauung, Witterungs- und Beleuchtungssituationen können so genau an die jeweiligen Testanforderungen angepasst werden (s. Abbildung 4.3). Die Simulation der Welt beschränkt sich dabei nicht auf statische Objekte, sondern ermöglicht auch die Integration weiterer Verkehrsteilnehmer und deren individueller Verhalten. Im Gegensatz zu Realdaten lassen sich so verhaltensabhängige und gefährliche Testszenarien wie das im vorherigen Abschnitt angesprochene ausscherende Fahrzeug oder das Kind mit dem Ball leicht und gefahrlos durchführen. Im Simulationssystem lassen sich so auch ohne Gefährdungspotenzial die Systemgrenzen testen. In den angesprochenen Beispielen können dies der Zeitpunkt des kritischen Verhaltens oder die Geschwindigkeit des Ego-Fahrzeugs sein. Die manuelle Erstellung detaillierter Verkehrsszenen ist jedoch sehr aufwendig und deshalb nur für kurze Streckenabschnitte und klar definierte Situationen sinnvoll. Für Tests aller Kombinationen bestimmter Eigenschaften ist sie nicht geeignet. Ein Simulationssystem ermöglicht die vollautomatische Strecken- und Szenengenerierung im Rahmen vorgegebener Parameter, Parameterbereiche oder Parameterkombinationen. So 42

53 4.4 Eingabedaten Abbildung 4.3: Synthetische Verkehrsszenen unterschiedlicher Komplexität (erstellt mit dem Simulationssystem NISYS Traffic Simulation (TRS)) können auf einfache Art und Weise Langzeittests mit hoher Streckenleistung durchgeführt werden. Synthetische Daten reduzieren den Speicherbedarf für Testdaten deutlich, da sie anhand der Parameterkonfiguration reproduzierbar sind und so bei Bedarf neu erzeugt werden können. Die dynamische Generierung der Szene ermöglicht im Gegensatz zu aufgezeichneten Daten die Simulation von Eingriffen in die Quer- und Längsführung des Fahrzeugs. Diese können entweder durch das Assistenzsystem oder durch einen menschlichen Fahrer verursacht werden, der durch geeignete Bedienschnittstellen die Führung des Ego-Fahrzeugs übernimmt. Wird die Neugenerierung der Testdaten im Arbeitsprozess nicht gewünscht oder benötigt (wie z. B. bei Systemen ohne Rückkopplung), so ist es auch möglich, die generierten Daten wie reale Sensordaten als Sequenzen zu speichern. Neben der Erzeugung komplexer Testszenarien kann ein Simulationssystem auch gezielt vereinfachte Szenen darstellen (s. oben links in Abbildung 4.3). Hierbei ist das Ziel dann nicht eine möglichst wirklichkeitsgetreue Darstellung, sondern die gezielte Reduktion störender Einflüsse. Gerade in frühen Entwicklungsstadien oder in Machbarkeitsstudien kann es hilfreich sein, mit stark vereinfachten Szenen zu arbeiten, da so der Fokus zunächst auf die grundsätzliche Funktionsweise des Algorithmus gelegt werden kann, ohne das Sensorrauschen, Bildartefakte oder störende Hintergrundobjekte berücksichtigt werden müssen. Außerdem ermöglicht es die gezielte Analyse systematischer Fehler. Schätzt beispielsweise ein Spurerkennungsalgorithmus die Spurbreite ungenau, so kann dies durch viele Faktoren verursacht werden: z. B. das Rauschverhalten des Sensors, eine fehlerhafte Kalibrierung der Kamera, die Beschaffenheit und Textur der Fahrbahn, die Qualität der Fahrstreifenmarkierungen oder Nickbewegungen des Fahrzeugs. Diese 43

54 4 Struktur und Anforderungen der Evaluierung Tabelle 4.1: Vergleich von realen und synthetischen Daten Eigenschaft Reale Daten Synthetische Daten Kontrolle über Szenario + Realistische Fehler ++ O (Sensorstörungen, Übersteuerung, etc) Kosten der Datenerzeugung ++ Kosten der Referenzdaten ++ Präzision der Referenzdaten ++ Reproduzierbarkeit O + Komplexität des Szenarios ++ O ++ sehr gut + gut O durchschnittlich schlecht Faktoren können in einem Simulationssystem gezielt vermieden werden. Arbeitet der Algorithmus auf den Basisdaten korrekt, können diese Faktoren gezielt nach und nach aktiviert werden. Da im Simulationssystem die Szene mit allen darin enthaltenen Objekten bekannt ist, stehen für alle Elemente der Simulation exakte Referenzdaten (Größe, Position, Zustand, Eigenschaften, s. a. Abschnitt 4.5) zur Verfügung. Dies reduziert den Kostenaufwand gegenüber realen Daten deutlich, da keine manuelle Bearbeitung der Daten nötig ist. Zusätzlich zu präzisen Referenzdaten kann das Simulationssystem ideale (im Sinne von störungsfreie) Sensordaten bereitstellen. Durch Integration von Störungsmodellen können diese bei Bedarf in gewünschter Stärke verrauscht bzw. gestört werden. 2 Auf diese Weise lassen sich mit synthetischen Daten systematische Tests zur Robustheit eines Systems durchführen Vergleich Der Vergleich der Eigenschaften realer und synthetischer Daten in Tabelle 4.1 macht zusammenfassend deutlich, dass die Verwendung realer Daten sehr aufwendig ist (Erfassung, Annotation). Dennoch kann nicht auf sie verzichtet werden, da diese Daten den späteren Einsatzzweck des Systems beschreiben. Grundsätzlich können synthetische Daten reale Daten (sowohl aufgezeichnete als auch während einer Testfahrt erfasste) nicht ersetzen, da sie die Realität nur begrenzt abbilden können. Aus Tabelle 4.1 geht hervor, dass synthetische Daten dennoch viele Vorteile bieten. Daher sind sie ein ein wichtiger, ergänzender Baustein in der Entwicklung und Absicherung moderner Fahrerassistenzsysteme. 2 Dies muss nicht im Simulationssystem selbst geschehen, sondern kann auch nachträglich im Rahmen der (Vor-)Verarbeitung der Daten erfolgen. 44

55 4.5 Referenzdaten 4.5 Referenzdaten Um die Güte eines FAS oder eines Algorithmus allgemein zu bewerten, sind in der Regel Vergleichsdaten notwendig. Diese Daten definieren das erwartete, also das richtige, Ergebnis und werden als Referenzdaten oder Ground Truth(GT)-Daten bezeichnet. Zur Bewertung der Güte eines Algorithmus zur Objektdetektion ist es z. B. nötig zu wissen, an welcher Position im Bild sich tatsächlich ein relevantes Objekt befindet. Nur so lässt sich prüfen, ob der Algorithmus das Objekt findet, ob die geforderte Positionsgenauigkeit erreicht wird, oder ob und wie oft es zu Fehldetektionen kommt. Referenzdaten beziehen sich im Allgemeinen direkt auf die Sensordaten. Sie bieten Antworten auf Fragen wie: Wo befinden sich gesuchte Objekte wie z. B. Verkehrsschilder? Welche Klasse hat ein bestimmtes Objekt (z. B. Art des Schildes)? Welche weiteren für die Bewertung relevanten Eigenschaften weist ein bestimmtes Objekt auf (Befindet sich ein Fahrzeug beispielsweise in derselben Spur wie das eigene? Links oder rechts davon? Quert es?)? Wie viele Spuren hat die Straße? Um welchen Straßentyp handelt es sich (Autobahn, Landstraße, Innenstadt)? Wie sind die Witterungsverhältnisse (Regen, Schnee, Sonne)? Wie ist der Fahrbahnzustand (trocken, nass)? Wie ist die Beschaffenheit des Fahrbahnbelags (Bitumen, Beton, Kopfsteinpflaster)? In welchem Land wurden die Daten aufgezeichnet? Nicht immer ist der Bedarf für Referenzdaten direkt ersichtlich. Angenommen, es solle die Verfügbarkeit eines Algorithmus zur Fahrspurerkennung berechnet werden. Die Verfügbarkeit sei definiert als der Anteil der Zeit, in der das System in der Lage ist, die Spur zu schätzen und aktuelle Fahrspurparameter auszugeben. Auf den ersten Blick scheint diese Berechnung allein von dem Ergebnis des Spurerkennungsalgorithmus und der Zeit abzuhängen. Da die Testdaten auch Szenarien enthalten müssen, für die der Algorithmus nicht ausgelegt ist, lässt sich die Verfügbarkeit des Systems nur dann korrekt bewerten, wenn die korrekte Funktionsweise in der aktuellen Situation überhaupt zu erwarten war. Liegt die Situation außerhalb des spezifizierten Betriebsbereichs, würde ein vermeintlicher Ausfall des Systems während dieser Zeit das Ergebnis verschlechtern und somit verfälschen. Der Umfang der Verfälschung hängt dann von der Größe des Anteils der nicht relevanten Situationen an den Testdaten ab. Für die korrekte Bewertung darf die Verfügbarkeitsbewertung nur in als relevant spezifizierten Szenarien durchgeführt werden. Um die Bewertung auf bestimmte Teilabschnitte oder Bedingungen einschränken zu können, sind also auch in diesem Fall Referenzdaten notwendig. 3 Zur einfacheren Verwaltung des Datenbestandes ist es oft hilfreich wenn zusätzliche Informationen, sog. Metadaten, zur Verfügung stehen. Hierzu können z. B. die verwendete Kamera bzw. die verwendeten Sensoren und deren Firmwareversionen gehören. Auch die Zuordnung zu einem bestimmten Datensatz oder zum Projekt, in dessen Rahmen die Daten erhoben wurden, zählen hierzu. Im Folgenden werden drei Arten der Erzeugung von Referenzdaten betrachtet. 3 Auch die Einteilung der Testdaten in relevante und nicht relevante Situationen definiert bereits Referenzinformationen. 45

56 4 Struktur und Anforderungen der Evaluierung Annotation Der Begriff Annotation bezeichnet die Anreicherung der Datenbasis mit zusätzlichen Informationen. Dazu werden bestimmte Teile der Daten markiert und ihnen Attribute zugewiesen. Wie oben bereits ausgeführt, kann es sich hier um Objektpositionen, Objekteigenschaften oder auch Zeitabschnitte mit bestimmten Eigenschaften wie z. B. einer bestimmten Witterungssituation handeln. Die Annotationen werden in der Regel zentral, z. B. in einer Datenbank, gespeichert. Dies macht die Daten einfach durchsuchbar und ermöglicht so einen gezielten Zugriff auf Teilmengen einer umfangreichen Datenbasis. Die Zuweisung der Attribute erfolgt im Allgemeinen durch geschulte Personen, die die Daten sichten und mit geeigneten Werkzeugen annotieren. Je nach Detaillierungsgrad der Attribute ist dies ein sehr aufwendiger Prozess. Während ein Attribut Land im Idealfall en bloc zugewiesen werden kann, erfordert die Annotation von Zeitabschnitten und Objekten eine vollständige Sichtung der Daten. Gerade die Objektannotation ist besonders zeitintensiv, da hier in jedem einzelnen Bild die Objektposition markiert werden muss. Möglichkeiten der Automatisierung ergeben sich durch den Einsatz von Trackingalgorithmen, die initial manuell markierte Objekte verfolgen. Da sich jedoch auch die Attribute eines Objekts im Laufe der Zeit ändern können (z. B. Verdeckungsgrad, aktuelle Fahrspur eines vorausfahrenden Fahrzeugs), sind diese dennoch in jedem Bild zu überprüfen und ggf. anzupassen. Außerdem ist das Ergebnis des Trackings zu kontrollieren und je nach Genauigkeit manuell zu korrigieren. In manchen Anwendungsgebieten ist es u. U. möglich, den Vorgang weiter zu automatisieren. Liegt beispielsweise bereits ein Algorithmus zur Objektdetektion vor (z. B. eine erste Version des geplanten Verfahrens oder eine alternative Implementierung), kann er zur Generierung der Objektpositionen verwendet werden. Allerdings ist zu betonen, dass diese Daten dennoch nachträglich manuell geprüft und ggf. korrigiert werden müssen, um die Korrektheit und Genauigkeit der so erzeugten Referenzdaten sicherzustellen. Ein solches Verfahren wird im Rahmen der Praxisbeispiele in Abschnitt 7.2 näher beschrieben. Zusätzlich zu den Kosten für die reine Erfassung der Daten (Betriebskosten des Fahrzeugs, Personalkosten, Ausrüstung) ist die Zeitintensität der Annotation ein weiterer Grund für die mangelnde freie Verfügbarkeit umfangreicher Datensätze Referenzsensorik Eine Alternative oder Ergänzung zur manuellen Annotation ist die Verwendung von Referenzsensorik, d. h. zusätzlichen Sensoren, die ergänzende Informationen über die Szene bereitstellen können. Diese Sensorik ist oft aufwendig und kostenintensiv und daher nicht für die Serienproduktion geeignet. Es kann sich dabei einerseits um bessere Versionen der bereits verwendeten Seriensensorik handeln, wie z. B. die Verwendung eines DGPS- anstelle eines einfachen GPS-Systems zur Erlangung einer präziseren Ortsbestimmung. Andererseits kann die Grundsensorik durch andere Sensormodalitäten erweitert werden. So kann z. B. ein Lidarsensor als Referenz für ein Stereokamerasystem dienen, um Entfernungsinformationen bereitzustellen. Je nach Art und Charakteristik der verwendeten Sensorik und der benötigten Infor- 46

57 4.6 Bewertungsverfahren mationen können die Daten der Referenzsensorik direkt als Referenzdaten verwendet werden oder als Grundlage zur Berechnung der entsprechenden Kennzahlen dienen. Diese Berechnung kann entweder direkt während der Evaluierung geschehen oder auch vorab, wenn die erzeugten Referenzdaten analog zu den manuellen Annotationen in einer Datenbank gespeichert werden können Automatische Generierung Wie bereits in Abschnitt erläutert, bietet die Verwendung synthetischer Daten den Vorteil, dass die Referenzdaten automatisch generiert werden können. Das Simulationssystem kann diese präzise anhand des Wissens über die simulierte Szene zur Verfügung stellen. Diese Informationen stehen entweder bereits als Zustand im Rahmen der Simulation zur Verfügung oder können daraus berechnet werden. 4.6 Bewertungsverfahren Die Bewertung eines Systems oder Algorithmus erfolgt auf Basis von Fehler- oder Gütemaßen. Diese werden anhand der Systemausgaben bzw. Algorithmenergebnisse berechnet. In der Regel beruht diese Berechnung auf einem Vergleich der Ergebnisse mit den Referenzdaten, die das gewünschte Ergebnis der Verarbeitung darstellen. Diese müssen üblicherweise in einem separaten Arbeitsgang erstellt werden (s. Abschnitt 4.5) und erfordern daher reproduzierbare Eingabedaten (s. Abschnitt 4.4). Die Auswahl der konkreten Fehler- und Gütemaße ist anwendungs- bzw. problemspezifisch. Sie ist abhängig von der Funktion des jeweiligen Systems und dem Zweck der Auswertung. Im Rahmen der Verifizierung einer Objektdetektion ist es beispielsweise relevant, wie viele Objekte korrekt oder fehlerhaft detektiert werden und wie groß die Fehler in Bezug auf Skalierung, Translation oder Rotation sind. Die Bewertungsverfahren beschränken sich auf das beobachtbare Verhalten einer Komponente oder eines Systems, das anhand der Eingabedaten erzeugt wird. Informationen bezüglich der konkreten Implementierung werden nicht berücksichtigt. Wie für den Gesamtevaluierungsprozess gilt die Reproduzierbarkeit auch für die Bewertungsergebnisse. Nur so sind die Analysierbarkeit von Fehlern und die Durchführbarkeit von Regressionstests nach Änderungen am System gegeben. Wie bereits in Kapitel 3 ausgeführt, ist die Durchführung von Bewertungs- und Testvorgängen auf allen Ebenen des Entwicklungsprozesses notwendig zur Durchführung von Technologie- und Machbarkeitsstudien, für Entwicklertests und zur Qualitätssicherung von der Komponente bis zum vollständigen Softwaresystem. Abhängig von der konkreten Problemstellung erfolgt die Berechnung der Fehler- und Gütemaße auf den Gesamtdaten oder ausgewählten Teilen davon (z. B. auf Streckenabschnitten mit bestimmten Eigenschaften). Zur Analyse und Interpretation der Ergebnisse ist es erforderlich, dass nicht nur Gesamtergebnisse über alle verarbeiteten Daten berechnet und ausgegeben werden, sondern dass die verwendeten Verfahren auch eine Identifikation problematischer Abschnitte 47

58 4 Struktur und Anforderungen der Evaluierung ermöglichen. Auch wenn ein System im Mittel eine bestimmte Fehlerschranke einhält, sind die Ausreißer zu erfassen und zu analysieren. Erreicht beispielsweise eine Fahrspurerkennung im Mittel eine Verfügbarkeit von 90 %, so ist gezielt zu untersuchen, woran die Erkennung in den verbleibenden 10 % scheitert. Handelt es sich z. B. um viele kurze Ausfälle oder wenige über längere Zeiträume? Welcher Teil der Eingabedaten verursacht das Problem? Lassen sich Gemeinsamkeiten dieser Situationen ermitteln? Bleiben relevante Szenarien in der Spezifikation unberücksichtigt? Sind die Referenzdaten fehlerhaft? Die Analyse erfordert die Inspektion der betroffenen Testdaten und Wiederholung der Systemausführung unter Beobachtung. 4.7 Fazit Der Evaluierungsprozess lässt sich in drei Blöcke gliedern. Die Unabhängigkeit dieser Blöcke Daten, System und Bewertung bildet die Grundlage für die Anpassung des Prozesses an unterschiedliche Fragestellungen und Bewertungsszenarien. Die Wiederholbarkeit des Prozesses sowie die Reproduzierbarkeit und Vergleichbarkeit der Ergebnisse sind dabei essenzielle Voraussetzungen für die Aussagekraft der erzielten Ergebnisse. Die Verfügbarkeit aufgezeichneter Sensordaten ist von zentraler Bedeutung für die Erzielung reproduzierbarer Bewertungsergebnisse. Die Komplexität der natürlichen Umgebung erfordert einen umfangreichen Datenbestand. Eine große Datenmenge allein ist allerdings nicht ausreichend, um die Qualität eines Verfahrens bzw. die Leistungsfähigkeit eines Systems bewerten zu können. Anhand der konkreten Problemstellung sind relevante Situationen zu identifizieren und eine hinreichende Präsenz dieser Testszenarien in den Daten zu gewährleisten, um aussagekräftige Ergebnisse zu erhalten. Synthetische Testdaten können die zur Bewertung benötigten Referenzdaten unmittelbar bereitstellen. Für reale Sensordaten müssen sie nachträglich durch manuelle Annotation erstellt werden. Hierbei handelt es sich um einen aufwendigen und in der Regel kostenintensiven Prozess. Als Ergebnis der Evaluierung ist nicht nur von Interesse, ob eine spezifizierte Systemleistung erreicht wurde oder nicht. Vielmehr müssen sowohl die verwendeten Bewertungsverfahren als auch der Gesamtprozess eine Identifikation und Analyse derjenigen Fälle ermöglichen, die die Gesamtleistung beeinträchtigen. 48

59 5 Anforderungen an das Framework Das im Rahmen dieser Arbeit erstellte Softwaresystem soll den im vorherigen Kapitel formulierten Anforderungen an eine Evaluierung gerecht werden. Die dortige Darstellung konzentriert sich auf die inhaltlichen Anforderungen, trifft aber noch keine Aussagen dazu, wie diese konkret umgesetzt werden sollen bzw. können. Im nächsten Schritt müssen diese Anforderungen nun konkretisiert und ergänzt werden, um sie in Anforderungen an das Softwaresystem zu übersetzen. 5.1 Aufgabenübergreifendes Rahmensystem Das in Kapitel 3 beschriebene V-Modell verdeutlicht, dass sehr viele Abteilungen bzw. Rollen an der Entwicklung eines FAS beteiligt sind. Jede dieser Rollen erfüllt andere Aufgaben und beantwortet andere Fragestellungen. Dies führt zu unterschiedlichen Anforderungen an die jeweils eingesetzten Werkzeuge. Das V-Modell bietet den formalen Rahmen des Entwicklungsprozesses. Es definiert nicht, wie die unterschiedlichen Zwischenergebnisse konkret erzeugt werden. Ein auf die jeweilige konkrete Problemstellung zugeschnittenes Werkzeug kann die zugehörigen Anforderungen am besten erfüllen. Problematisch ist dies an den Schnittstellen zu und in Zusammenarbeit mit anderen Stufen der Entwicklung. Wird für jede Anforderung ein eigenes Werkzeug eingesetzt, fehlt u. U. eine gemeinsame Kommunikationsund Verständnisbasis der Beteiligten. Es entstehen Insellösungen für einzelne Aufgabenbereiche. Daten müssen ggf. aufwendig konvertiert werden, um von den verschiedenen Werkzeugen verarbeitet werden zu können. Änderungen an den Daten müssen entsprechend zwischen den Beteiligten synchronisiert werden. Es besteht daher großer Bedarf an Entwicklungswerkzeugen, die eine anforderungsübergreifende Verwendung ermöglichen (vgl. [Mau09]), ohne die bereits sehr hohe Komplexität des Entwicklungs- und Testprozesses durch eine heterogene Werkzeuglandschaft zusätzlich zu erhöhen. Das vorgestellte Softwaresystem soll eine gemeinsame Arbeitsgrundlage über alle Stufen bilden und auf diese Weise eine gemeinsame Wissensbasis der Beteiligten schaffen. Dies erleichtert den Informationsaustausch und stellt eine konsistente Datennutzung sicher. Alle Beteiligten können mit denselben Daten arbeiten, ohne dass zusätzlicher Konvertierungs- oder Synchronisierungsaufwand anfällt. Algorithmen oder Bewertungsmetriken werden aufgabenübergreifend über dieselben Komponenten eingebunden. Dies vermeidet unnötige Fehlerquellen und Testaufwände, die durch duplizierten Code entstehen. Treten während der Tests Fehler auf, lassen sie sich durch die für die Behebung verantwortlichen Personen infolge gemeinsam genutzter Konfigurationen und Daten leichter reproduzieren. 49

60 5 Anforderungen an das Framework Ein flexibler Einsatz des Entwicklungssystems erfordert auch Schnittstellen zu anderen Systemen. Es muss möglich sein, nur einzelne Teile des Softwaresystems im Entwicklungsprozess zu verwenden. Dadurch lässt es sich in eine vorhandene Softwarelandschaft einbetten und ermöglicht einen schrittweisen Migrationsprozess, ohne ihn zu erzwingen. Ein Entwicklungs- und Evaluierungssystem, das die unterschiedlichen Aufgaben innerhalb des Entwicklungsprozesses zusammenführen will, muss zahlreichen, sehr unterschiedlichen Anforderungen und Zielsetzungen gerecht werden. Hinzu kommt, dass viele konkrete Anforderungen problem- bzw. kundenspezifisch 1 sind. Ein allgemeines Entwicklungs- und Evaluierungssystem kann diese Anforderungen nicht vorab im Detail erfüllen nicht nur aufgrund der hohen Anzahl, sondern auch da neue Anwendungsgebiete neue Problemstellungen mit sich bringen, die heute nicht im Detail antizipiert werden können. Das Entwicklungssystem muss also primär ein Framework sein, ein Rahmen, der durch den Nutzer erweitert und so an das jeweilige Problem angepasst werden kann. 5.2 Aufgabenspezifische Anforderungen Wie bereits in der Problemstellung in Abschnitt 1.4 erörtert und durch die Darstellung des Entwicklungsprozesses sowie die Analyse der Anforderungen verdeutlicht, erfordert die Entwicklung und Bewertung neuer Funktionen die Erfüllung zahlreicher Aufgaben. Diese stellen unterschiedliche Anforderungen, denen das Framework gerecht werden muss. Aus den in Kapitel 3 und Kapitel 4 aufgeführten Rahmenbedingungen und Anforderungen lassen sich die folgenden Aufgabengebiete extrahieren Absicherung und Test Nach Fertigstellung der Komponenten oder Integration von Komponenten zum Teiloder Gesamtsystem ist die korrekte Funktion zu überprüfen und die Systemleistung zu bestimmen. Zum Test einer Funktionskomponente oder eines Systems ist Zugriff auf die relevanten Sensor- und Referenzdaten, die zu testende(n) Komponente(n) sowie die spezifizierten Bewertungsverfahren notwendig. Der große Umfang der Testdaten erfordert eine automatisierte Ausführbarkeit der Bewertung [Win06]. Die erzielten Ergebnisse müssen reproduzierbar sein, um ihre Überprüfbarkeit zu gewährleisten und im Fehlerfall eine Ursachenanalyse zu ermöglichen Funktionsentwicklung Auch während der Funktionsentwicklung werden Sensordaten und zugehörige Referenzdaten benötigt, um die Funktion ausführen und testen zu können. Basiert die Funktion auf Methoden des maschinellen Lernens werden Teile der Daten außerdem zum Training 1 Kunde soll hier den Verwender des Entwicklungs- und Evaluierungssystems im Allgemeinen bezeichnen. Es kann sich um eine Firma, eine Forschungsgruppe oder auch eine Einzelperson handeln, die ein Entwicklungsprojekt durchführt. Der Begriff dient der Abgrenzung vom Nutzer, der das Softwaresystem persönlich verwendet, um eine konkrete Aufgabe zu erfüllen. 50

61 5.3 Nutzerprofile des Zielsystems benötigt. Sowohl der Zugriff auf die Daten als auch die Visualisierung der Daten sowie der Algorithmusausgaben sollten dabei minimalen Aufwand verursachen, um nicht abseits der eigentlichen Aufgabenstellung Ressourcen zu binden. Werden durch die Tester Fehlverhalten oder unzureichende Systemleistung berichtet, benötigen die Entwickler Zugriff auf die Testkonfiguration, um den Fehler unter identischen Bedingungen reproduzieren und analysieren zu können Datenakquise Die Erhebung von Testdaten ist von zentraler Bedeutung für jedes Entwicklungsvorhaben. Dies erfordert den Zugriff auf die benötigte Sensorik und Aufzeichnung der Daten in geeigneter Form. Mit Blick auf eine mögliche Arbeitsteilung muss die Erhebung der Sensordaten nach Anleitung auch ohne Spezialwissen (Domänen- oder Programmierkenntnisse) möglich sein. Dies ermöglicht den Einsatz dedizierter Teams, ohne Fachpersonal aus anderen Bereichen zu binden Annotation Auf Basis der Sensordaten sind Referenzdaten zu erstellen, was in vielen Fällen manuell geschehen muss. Abhängig von der zu annotierenden Datenmenge sowohl in Bezug auf die Menge der Sensordaten als auch in Bezug auf Menge und Detailgrad der geforderten Referenzdaten ist u. U. eine große Anzahl Personen nötig, um diese arbeitsintensive Aufgabe in einem vertretbaren Zeitrahmen erfüllen zu können. Daher ist auch hier ähnlich der Datenakquise eine Nutzbarkeit des Werkzeugs ohne Fachwissen essenziell. 5.3 Nutzerprofile Grundsätzlich sind zwei Nutzerprofile für das Framework zu unterscheiden: Anwender vorhandener und Entwickler neuer Funktionalität. Diese Trennung ist unabhängig von der im vorherigen Abschnitt 5.2 vorgenommenen Einteilung nach aufgabenspezifischen Anforderungen. Prinzipiell sind alle Aufgabenbereiche aus beiden Nutzerperspektiven zu betrachten. Die Gewichtung der Nutzerprofile ist allerdings je nach Aufgabenbereich unterschiedlich Anwender Die Anwender nutzen das Framework als Werkzeug und lösen Aufgaben durch Nutzung vorhandener Komponenten. In Bezug auf den Entwicklungsprozess eines neuen Fahrerassistenzsystems bilden sie die eigentliche Zielgruppe des Frameworks. Sie nutzen es, um Daten aufzuzeichnen oder zu annotieren. Sie erstellen Test- und Evaluierungskonfigurationen anhand existierender Komponenten und wenden sie auf vorhandene Daten an. Auch Entwickler neuer Algorithmen sind Anwender, wenn sie die neue Funktionalität innerhalb des Frameworks mit vorhandenen Komponenten kombinieren. 51

62 5 Anforderungen an das Framework A: Daten Testfall11 Testfall12... Testfall1n Testtreiber Stub11 Stub11... Stub1n Platzhalter B: System Testobjekt Daten1+1 Parameter Ergebnisse Testausgaben Vergleich E1Protokoll C: Bewertung Laufzeitumgebung Analysewerkzeuge,1Monitore Abbildung 5.1: Einbettung des Testobjekts in den Testrahmen (in Anlehnung an [SL05, S. 105]). Die Bezeichner A, B und C verweisen auf die Stufen des Makromodells in Abschnitt Entwickler Die Anforderungen an die Entwicklung umfelderfassender FAS sind vielfältig und in weiten Teilen problem- und produktspezifisch. Welche Funktion soll dem Fahrer geboten werden? Welche Sensoren werden dafür verwendet? Welche Annotationen sind für eine Absicherung dieses Systems notwendig? Mit welchen Metriken wird das neue System verifiziert und validiert? Diese Fragen kann nur der Kunde selbst beantworten. Das Framework muss daher bezüglich aller genannten Aufgabenbereiche erweiterbar sein. Diese Erweiterbarkeit darf sich nicht nur auf den Anbieter des Frameworks beschränken, sondern muss auch dem Kunden zur Verfügung stehen. Ziel des Frameworks ist es daher nicht, eine möglichst große Anzahl vorgefertigter Module bereitzustellen, die der Kunde nur zusammenfügen muss bzw. kann, sondern eine flexible, erweiterbare Architektur, die dem Kunden den nötigen Gestaltungsspielraum bei der Entwicklung neuer Produkte bietet. 5.4 Integration von Algorithmik Zur Überprüfung der korrekten Funktion und zur Bewertung der Systemleistung muss das zu testende System zur Ausführung gebracht werden. Einzelne Komponenten und Teilsysteme sind jedoch in der Regel nicht selbständig lauffähig. Das gilt u. U. selbst für das Gesamtsystem, falls es später auf einer anderen Zielplattform als einem PC (z. B. einem Steuergerät) ausgeführt werden soll. Daher ist auf der Testplattform grundsätzlich ein zusätzlicher Programmteil notwendig, der das Testobjekt auf dem Testsystem aufruft. Diese Komponente wird als Testrahmen bezeichnet (s. Abbildung 5.1) und bildet eine Laufzeitumgebung zur Ausführung des Testobjektes. Dieser besteht nach [SL05] aus dem sog. Testtreiber, der die Komponente aufruft, mit Daten versorgt und die Ausgaben 52

63 5.5 Erfassung und Bereitstellung der Sensordaten auf Fehlerwirkungen prüft. In der Laufzeitumgebung stehen von der Komponente aufgerufene, komponentenexterne Schnittstellen als Platzhalter (Stub) zur Verfügung. Mit fortschreitender Integration können die Platzhalter durch funktionsfähige Implementierungen ersetzt werden, womit sie im Rahmen von Integrationstests Teil des untersuchten Testobjekts werden. Dadurch wird ein nahtloser Übergang von Komponenten- zu Integrationstests ermöglicht. Die Ergebnisse sind zu protokollieren, um sie überprüfbar, extern verarbeitbar und archivierbar zu machen. Im abgebildeten Testrahmen lassen sich die im Makromodell erläuterten Blöcke einer Evaluierung identifizieren. Die Testfälle konstituieren sich aus den Daten, sowohl den Eingabedaten als auch den erwarteten Ergebnissen. Sie entsprechen somit Block A im Makromodell. Das Testobjekt ist das System unter Test und entspricht somit Block B. Die Bewertung in Block C findet sich im Testrahmen in Abbildung 5.1 als Vergleich und Protokoll wieder. Um alle in Abschnitt 4.2 geforderten Bewertungsszenarien abbilden zu können, muss die Laufzeitumgebung eine unabhängige Variation der drei Aspekte ermöglichen. Mit der Austauschbarkeit des Testobjektes ist auch die Austauschbarkeit und Erweiterbarkeit der Platzhalter notwendig. Abhängig von der Art der Daten, des Testobjekts und der Bewertung sind auch die Analysewerkzeuge und Visualisierungen (Monitore) aufgabenspezifisch anpassbar zu gestalten. Das Framework darf nicht auf die Einbindung eines fest definierten Testobjekts beschränkt sein. Die Funktionalität soll modular in allen Bereichen (u. a. Erzeugung und Bereitstellung von Eingabe- und Referenzdaten, Bewertungsverfahren, Monitoring, Fehleranalyse) erweiterbar sein. Dies soll eine flexible Anpassung an die jeweilige Problemstellung ermöglichen. Wichtig ist auch, dass das Framework eine Wiederverwendbarkeit der Erweiterungen erlaubt, um sowohl innerhalb eines Entwicklungsprojektes als auch projektübergreifend doppelte Entwicklungs- und Testaufwände zu vermeiden und so Synergieeffekte zu erzeugen. Der durch das Framework selbst verursachte Rechenaufwand während der Verarbeitung soll möglichst gering sein. In rein softwarebasierten Projekten soll es so möglich sein, die Laufzeitumgebung nicht nur für Entwicklungs- und Bewertungszwecke, sondern auch zur produktiven Ausführung des fertigen Systems zu verwenden. 5.5 Erfassung und Bereitstellung der Sensordaten Als Laufzeitumgebung für die Durchführung von Test- und Bewertungsvorhaben muss das Framework in der Lage sein, die benötigten Sensordaten als Eingabedaten zur Verfügung zu stellen. Im Rahmen der Zielsetzung eines gemeinsamen Werkzeugs für die beteiligten Personen schließt dies auch die Aufzeichnung von Sensordaten zur späteren Verwendung mit ein Abstraktion der Sensorik Um als flexibles Entwicklungs- und Analysesystem zur Sensordatenverarbeitung zu dienen, darf das Framework nicht auf einen bestimmten Sensor festgelegt sein. Es muss 53

64 5 Anforderungen an das Framework sowohl die Einbindung verschiedener Ausführungen eines Sensors (z. B. verschiedene Kameramodelle) als auch gänzlich unterschiedlicher Sensormodalitäten (Kamera, GPS, Lidar etc.) ermöglichen. Dabei ist zu berücksichtigen, dass sich die Sensoren in der Frequenz, mit der sie die Daten bereitstellen, im Datenumfang einzelner Messungen als auch in der Art der Daten grundlegend unterscheiden können. Auch wenn sich verwandte Sensoren grundsätzlich in den erfassten Daten ähneln beispielsweise erfassen Kameras ein zweidimensionales Bild, so können sie sich in der konkreten Ausführung deutlich unterscheiden. Eine Time-of-Flight-Kamera kann die Daten beispielsweise als dreidimensionale Punktwolke, ggf. aber auch zusätzlich als zweidimensionales Intensitätsbild ausgeben. Eine Stereokamera kann je nach Ausführung die einzelnen Kamerabilder, das Disparitätsbild oder bereits eine Punktwolke der Szene ausgeben. Daher soll weder eine feste Kategorisierung der unterstützten Sensormodalitäten noch eine feste Zuordnung der durch einen Sensortyp erzeugten Daten vorgegeben werden. Im Gegenteil, das Framework soll in der Lage sein, besondere Eigenschaften einzelner Sensormodelle zu berücksichtigen. Dies betrifft sowohl die Konfigurationsmöglichkeiten, als auch den Zugriff auf nur modellabhängig verfügbare Zusatzinformationen. Für Videokameras kann es sich dabei z. B. um die Belichtungszeit, den Verstärkungsfaktor (Gain) oder interne Zähler handeln. Manche ToF-Kameras wie z. B. die Argos-P100 von Bluetechnix 2 ergänzen die Messung um eine Maske, die die Gültigkeit eines jeden einzelnen Pixels spezifiziert; das Simulationssystem NISYS Traffic Simulation (TRS) [NEI12] stellt für jedes erzeugte Bild die korrespondierenden Referenzdaten für die Szene sowie das Ego-Fahrzeug zur Verfügung. Ist für die Entwicklung eines Systems die Nutzung besonderer Eigenschaften und Stärken eines spezifischen Sensors notwendig, ist eine Beschränkung des Datenmodells auf den kleinsten gemeinsamen Nenner zu restriktiv. Für die Austauschbarkeit der Daten (Block A des Makromodells) ist es zwar nötig, dass dem verarbeitenden System auch nach einem Wechsel des Sensors ein bestimmtes Datenformat bereitgestellt werden kann, jedoch reicht es aus, wenn die erforderliche Form als Teil der Sensordaten zur Verfügung steht oder aus ihnen erzeugt werden kann (z. B. durch Konvertierung oder Fusion mit Daten weiterer Sensoren). Der Verzicht auf eine enge Definition der von Sensoren bereitgestellten Daten und ihrer Formate erfordert außerdem ein leistungsfähiges Dateiformat zur Speicherung der erfassten Daten Parallele Erfassung mehrerer Sensoren Abhängig vom zu lösenden Problem sind Daten eines einzelnen Sensors nicht ausreichend. Daher muss das Framework in der Lage sein, die Daten mehrerer Sensoren zu erfassen, bereitzustellen und aufzuzeichnen. Dies erfordert, dass das Framework in der Lage ist, gleichzeitig Daten zu berücksichtigen, die sich in Frequenz, Datenumfang und Modalität unterscheiden. Abbildung 5.2 zeigt ein Beispiel von vier Sensoren, die mit jeweils unterschiedlicher Frequenz Daten bereitstellen

65 5.5 Erfassung und Bereitstellung der Sensordaten Sensor 1 Sensor 2 Sensor 3 Sensor 4 Abbildung 5.2: Beispiel für das Zeitverhalten unterschiedlicher Sensoren. Jeder Block repräsentiert das Eintreffen einer Sensormessung. Unterschiede im Datenumfang der einzelnen Sensormessungen werden in der Darstellung nicht berücksichtigt. Zeit Um eine Zuordnung der Daten unterschiedlicher Sensoren zueinander zu ermöglichen, ist ein globaler also über alle Sensoren hinweg gültiger Zeitstempel je Sensormessung erforderlich. Die Zeitstempel bilden außerdem die Voraussetzung für eine aufnahmetreue Wiedergabe (s. Abschnitt 5.5.5). Das Framework selbst soll keine Interpretation der Daten vornehmen, sondern sie originalgetreu den verarbeitenden Systemkomponenten zur Verfügung stellen. Dazu muss es in der Lage sein, die jeweiligen Sensordaten einzeln bereitzustellen. Das bedeutet insbesondere, dass das auch hochfrequente Sensormessungen mit geringem Datenumfang (z. B. einzelne CAN-Botschaften 3 ) nicht gruppiert oder anderweitig zusammengefasst, sondern einzeln mit individuellen Zeitstempeln bereitgestellt werden können. Das ist essentiell, um den Entwicklern eine problemspezifische Zusammenführung der Daten zu ermöglichen. Eine allgemeingültige, sensorübergreifende Gruppierung durch das Framework ist nicht möglich, da sich ein Zuordnungsproblem stellt, dass nur im Kontext der konkreten Applikation gelöst werden kann. Zur Verdeutlichung sollen im Folgenden die in Tabelle 5.1 auf der nächsten Seite dargestellten Szenarien mit zwei Sensoren betrachtet werden, die Daten mit unterschiedlicher relativer Frequenz bereitstellen. Sie repräsentieren somit eine Untermenge der in Abbildung 5.2 dargestellten Sensoren. Ein Beispielverfahren benötige die Daten beider Sensoren. Sensor 1 sei o. B. d. A. eine Kamera. Er dient als Bezugspunkt der Betrachtung und wird im Folgenden als Primärsensor bezeichnet, Sensor 2 als Repräsentant weiterer Sensoren als Sekundärsensor. Fall 1 betrachtet den Sachverhalt zweier mit gleicher Frequenz betriebener Sensoren, beispielsweise zweier Kameras in einer Stereokonfiguration. Arbeiten die Sensoren synchron, ist grundsätzlich eine direkte Zuordnung der Sensormessungen zueinander möglich. Selbst bei nur annähernder Synchronität ist eine Zuordnung noch möglich (Fall 1 a). Diese Synchronität ist allerdings nur durch weitere sensorspezifische, in der Regel hardwareseitige, Maßnahmen sicherzustellen, die häufig nicht gegeben sind. Bei einem größeren zeitlichen Versatz zwischen den Messungen der Sensoren wie 3 Über Feldbussysteme wie CAN werden in der Regel Daten mehrerer Sensoren oder Systeme (z. B. verschiedener Fahrdynamiksensoren) erfasst und verteilt. Innerhalb des Frameworks wird ein Feldbus jedoch als Einheit und jede einzelne Nachricht als Sensormessung betrachtet. 55

66 5 Anforderungen an das Framework Tabelle 5.1: Zu unterscheidende Fälle bei der Verwendung mehrerer Sensoren. Sensor 1 ist jeweils der Primärsensor. Sensor 2 repräsentiert zusätzliche Sensoren, deren Daten bei der Verarbeitung der Daten des Primärsensors benötigt werden. Die vorgestellten Fälle lassen sich auf eine beliebige Anzahl Sensoren übertragen. Jeder Block repräsentiert eine Sensormessung. Grün eingefärbte Blöcke demonstrieren mögliche sensorübergreifende Gruppierungen, rote verworfene Sensordaten. Zeit Fall 1 a Gleiche Frequenz, synchron bzw. annähernd synchron Sensor 1 Sensor 2 Fall 1 b Gleiche Frequenz, versetzt Sensor 1 Sensor 2 Sensor 1 Sensor 2 Fall 2 Niedrigere Frequenz als der Primärsensor Sensor 1 Sensor 2 Sensor 1 Sensor 2 Fall 3 Höhere Frequenz als der Primärsensor Sensor 1 Sensor 2 Sensor 1 Sensor 2 Sensor 1 Sensor 2 Sensor 1 Sensor 2 56

67 5.5 Erfassung und Bereitstellung der Sensordaten der in Fall 1 b dargestellten Phasenverschiebung von 50 % ist die Zuordnung nicht mehr eindeutig. Wie groß der zeitliche Versatz zwischen den Daten der unterschiedlichen Sensoren sein darf, damit die Zuordnung noch gültig ist, und welche Auswirkungen und Bedeutung dieser Versatz hat, kann nicht allgemeingültig beantwortet werden. Eine Gruppierung der Daten mit dem Ziel der gleichzeitigen Bereitstellung würde gemäß Fall 1 b dazu führen, dass die Daten erst bereitgestellt werden können, wenn die Daten beider Sensoren verfügbar sind. Dies führt zu einer verspäteten Nutzbarkeit der Daten eines der Sensoren, da zum Zeitpunkt ihrer Verfügbarkeit die Daten des zweiten Sensors noch nicht eingetroffen sind. In Fall 2 ist der Sekundärsensor langsamer als der Primärsensor. Als Beispiel diene hier ein GPS-Empfänger. Werden nur Datenpakete berücksichtigt, die sich einander zuordnen lassen, bleiben Daten des Primärsensors unberücksichtigt. Dies verursacht einen Datenverlust, da ein Teil der Sensordaten nicht zur Verarbeitung zur Verfügung steht. Die Verarbeitungsgeschwindigkeit des Systems wird effektiv auf die Geschwindigkeit des langsamsten Sensors reduziert. Abhängig von der Art der Daten ist u. U. eine Extrapolation möglich, sodass jedem Datenpaket des Primärsensors Daten des Sekundärsensor zugeordnet werden können. Die ist beispielsweise bei einer GPS-Position der Fall, für Bilddaten jedoch in der Regel nicht möglich. Fall 3 betrachtet die umgekehrte Situation. Hier wird der Sekundärsensor mit einer höheren Frequenz als der Primärsensor betrieben. 4 Es könnte sich z. B. um einen Feldbus handeln, über den u. a. die aktuelle Fahrgeschwindigkeit oder der aktuelle Lenkradwinkel verfügbar ist. Werden nur einzelne Daten des Sekundärsensors benötigt, ist es u. U. möglich, zwischen zwei Datenpaketen des Primärsensors empfangene Daten zu ignorieren und nur die Daten zu verwenden, die zeitlich mit den Daten des Primärsensors zusammenfallen. Dadurch wird dieser Fall vergleichbar zu Fall 1 a. Sollen alle Daten des Sekundärsensors berücksichtigt werden, ergeben sich unterschiedliche Möglichkeiten der Gruppierung. Einem Datenpaket des Primärsensors können dann folgende Datenpakete des Sekundärsensors zugeordnet werden: alle bis zum Empfang dieses Datenpaketes noch nicht verarbeiteten Datenpakete, alle Datenpakete, die diesem Datenpaket zeitlich am nächsten empfangen wurden, oder alle bis zum Empfang des nächsten Datenpaketes empfangenen Datenpakete. Die letzten beiden Möglichkeiten erfordern jedoch ähnlich zu Fall 2 eine Verzögerung der Verarbeitung nach Empfang der Primärsensordaten, da zum Zeitpunkt des Empfangs noch nicht alle benötigten Daten vorhanden sind. Alternativ kann es analog zu der in Fall 2 angesprochenen Extrapolation möglich sein, intermediäre Daten zusammenzufassen. Doch auch hier hängt sowohl die Möglichkeit selbst als auch die Wahl des geeigneten Verfahrens von der Interpretation der Daten und ihrem problemspezifischen Verwendungszweck ab und kann daher nicht allgemein gelöst werden. 4 Bei Vertauschbarkeit von Primär- und Sekundärsensor ist dieser Fall grundsätzlich mit Fall 2 identisch. 57

68 5 Anforderungen an das Framework Unabhängig von der Zuordnungsmethode stellt sich in Fall 3 das Problem, dass die Anzahl der gruppierten Sensormessungen nicht der Anzahl der Sensoren entspricht und u. U. variiert. Dies erschwert die Analyse, da für den Benutzer nicht ersichtlich ist, welche und wie viele Daten in einem Schritt verarbeitet werden. In den vorgestellten Fällen wurde für alle Sensorkonfigurationen eine kontinuierliche, gleichbleibende Senderate angenommen. Weitere Fälle umfassen Konfigurationen, in denen Sekundärsensoren nur zeitweise Daten senden, z. B. bei Aktivierung des Blinkers oder Regensensors (ähnlich Sensor 4 in Abbildung 5.2). Die Betrachtung zeigt, auf welch vielfältige Weise jeder Sensormessung des Primärsensors Daten der Sekundärsensoren für eine gemeinsame Verarbeitung zugeordnet werden können. Um nicht der Entwicklung der Applikation vorauszugreifen, muss das Framework daher in der Lage sein, die Daten individuell und zeitgerecht zur Verfügung zu stellen. Es liegt dann in der Verantwortung und im Gestaltungsspielraum des Entwicklers, die Daten problemadäquat aufzubereiten und zu verwenden (z. B. durch Zwischenspeichern, Extrapolieren, Mitteln oder auch Verwerfen) Leistungsfähiges Dateiformat Jede Aufnahme soll eine einzelne Datei erzeugen, die im Folgenden als Sequenz bezeichnet wird. Die Aufzeichnung erfolgt in kontinuierlichen Zeitabschnitten, deren Länge durch den Benutzer bestimmt wird und wenige Minuten bis mehrere Stunden umfassen kann. Die Beschränkung auf eine Datei je Aufnahme vereinfacht die Verwaltung des Datenbestandes, da sie die Konsistenz und Vollständigkeit der aufgezeichneten Daten gewährleistet. Eine Aufteilung auf mehrere Dateien, z. B. eine je Sensor, birgt die Gefahr, dass Teile der Daten verloren gehen (beispielsweise durch unvollständiges Kopieren). Die gleichzeitige Datenerfassung durch mehrere Sensoren erhöht die Anforderungen an das Dateiformat. Ergänzend zu den Anforderungen, die durch eine fehlende Vorgabe fester Sensordefinitionen entstehen (s. Abschnitt 5.5.1), muss es außerdem in der Lage sein, sehr heterogene Daten zu speichern Abstraktion der Datenquelle Die Variation der Daten gemäß dem Makromodell in Abschnitt 4.1 darf sich nicht nur auf die Verwendung unterschiedlicher (Teil-)Datensätze beschränken. Auch wenn die Entwicklung und die Bewertung des Systems prinzipiell anhand aufgezeichneter Daten durchgeführt werden, muss es dennoch möglich sein, das System unter realen Bedingungen zu testen. Das Framework muss es daher erlauben, erfasste Sensordaten nicht nur aufzuzeichnen, sondern auch zur Verarbeitung bereitzustellen. Dabei ist sicherzustellen, dass der Wechsel zwischen aufgezeichneten und direkt erfassten Daten keine Veränderung des Systems (Block B) oder der Bewertung (Block C) erfordert. So wird die Vergleichbarkeit der Ergebnisse sichergestellt. Voraussetzung für eine Bewertung auf Basis direkt erfasster Sensordaten ist, dass die sie entweder auf der Beobachtung des Systemverhaltens statt auf quantitativen Kriterien beruht (Benutzerakzeptanztests) oder 58

69 5.5 Erfassung und Bereitstellung der Sensordaten aber auf automatisch generierte Referenzdaten (z. B. auf Basis von Referenzsensorik) zurückgreifen kann Aufnahmetreue Wiedergabe Während der Wiedergabe der Daten muss sowohl die Reihenfolge der einzelnen Sensormessungen als auch ihr zeitlicher Abstand den Gegebenheiten während der Aufnahme entsprechen. Insbesondere umfasst dies die Monotonie der Zeit, d. h., dass nachfolgende Sensormessungen stets neue Daten repräsentieren. Zum einen stellt dies sicher, dass der Datenstrom also die Sequenz der aufeinanderfolgenden Messungen aller Sensoren grundsätzlich reale Bedingungen und somit die spätere Einsatzumgebung des Systems repräsentiert. Zum anderen ist es insbesondere erforderlich, um während einer Testfahrt beobachtetes Verhalten anhand der dabei aufgezeichneten Daten im Labor reproduzieren zu können Variable Wiedergabegeschwindigkeit Abhängig von der aktuellen Aufgabenstellung im Entwicklungsprozess ist die Wiedergabe aufgezeichneter Daten mit unterschiedlichen Geschwindigkeiten erforderlich. Für die spätere Verwendung muss das System unter Test echtzeitfähig sein. Das bedeutet, dass es in der Lage sein muss, eintreffende Daten mindestens so schnell zu verarbeiten, dass die Verarbeitung bei Eintreffen neuer Daten bereits abgeschlossen ist. Wird eine Kamera z. B. mit einer Bildrate von 25 Hz betrieben, muss die Verarbeitung der Bilddaten innerhalb von 40 ms abgeschlossen sein. Anderenfalls wäre es notwendig, erfasste Daten zu verwerfen, um ein Ansammeln unverarbeiteter Daten und eine daraus resultierende verzögerte Reaktion des Systems zu vermeiden. Unter Berücksichtigung eines Zeitpuffers sollte die Verarbeitung kürzer dauern als der Abstand zweier Sensormessungen. Insbesondere in frühen Entwicklungsphasen ist die Echtzeitfähigkeit des Systems häufig noch nicht gegeben. Daher ist es notwendig, dass die Geschwindigkeit der Datenbereitstellung an die Verarbeitungsgeschwindigkeit angepasst wird. Die Daten dürfen also maximal so schnell bereitgestellt werden, wie das System sie verarbeiten kann. Benötigt die Verarbeitung im genannten Beispiel also 66 ms pro Bild, dürfen nur 15 Bilder pro Sekunde bereitgestellt werden. Wenn auch verzögert, so muss dennoch jedes aufgezeichnete Datum verarbeitet werden. Es darf seitens des Frameworks kein Datum aufgrund von Zeitbeschränkungen verworfen werden. Sobald alle beteiligten Systemkomponenten echtzeitfähig sind, muss das Framework in der Lage sein, die Daten in Originalgeschwindigkeit abzuspielen und zu verarbeiten. Dies erlaubt dem Benutzer die Überprüfung des Systemverhaltens unter Echtzeitbedingungen, die durch eine direkte Verarbeitung erfasster Sensordaten gestellt würden. Wird nur die Verarbeitungsgeschwindigkeit als Kriterium für die Wiedergabegeschwindigkeit herangezogen, so führt das potenziell zur zu frühen Bereitstellung der Folgedaten und somit zu einer zu hohen Wiedergabegeschwindigkeit. Um das zu verhindern, dürfen die Folgedaten jeweils nur mit dem der Aufzeichnung entsprechenden zeitlichen Abstand 59

70 5 Anforderungen an das Framework bereitgestellt werden. Die Geschwindigkeit der Datenbereitstellung muss in diesem Fall also durch die Zeitstempel der Aufzeichnung definiert werden. Mit Blick auf die automatisierte Bewertung anhand großer Datenbestände ist es wichtig, dass die Verarbeitung auch in Überechtzeit erfolgen kann. Das bedeutet, dass die Wiedergabe der Daten in Abhängigkeit der Verarbeitungsgeschwindigkeit und der Lesegeschwindigkeit des Speichermediums mit maximaler Geschwindigkeit erfolgt. In diesem Fall wird also die Frequenz der Datenbereitstellung an die Verarbeitungsgeschwindigkeit gekoppelt, indem eventuell vorhandene Zeitpuffer ignoriert werden und unmittelbar die jeweils nachfolgende Sensormessung bereitgestellt und verarbeitet wird. Auch während der interaktiven Nutzung des Frameworks kann der Benutzer von der Ausführung in Überechtzeit profitieren. Sie erlaubt die schnelle Sichtung von Daten oder die Beobachtung des Systemverhaltens auf längeren Streckenabschnitten. Da die Ausführung in maximaler Geschwindigkeit für einen menschlichen Betrachter u. U. zu schnell ist, sind Zwischenstufen vorzusehen (z. B. doppelte oder vierfache Geschwindigkeit) Wahlfreier Zugriff Für die automatisierte Verarbeitung des Datenbestandes ist in der Regel eine effiziente sequenzielle Wiedergabe ausreichend. Viele der in Abschnitt 5.2 aufgeführten Aufgaben erfordern jedoch eine direkte Interaktion des Benutzers mit dem Framework. Dies macht die Möglichkeit eines wahlfreien Zugriffs auf aufgezeichnete Daten notwendig. Das bedeutet, dass der Benutzer beliebige Sensormessungen in den Daten gezielt anfordern kann. Dies ist insbesondere für die Fehleranalyse und Annotation grundlegend, betrifft aber auch alle anderen Aufgabenbereiche. Für eine selektive Wiedergabe, bei der nur Teilabschnitte der aufgezeichneten Datensequenzen verwendet werden, ist ein unmittelbarer Zugriff auf den gewünschten Startpunkt ebenfalls erforderlich. Die Möglichkeit des wahlfreien Zugriffs ist bereits bei der Wahl des Dateiformats für die Aufzeichnung zu berücksichtigen. 5.6 Erzeugung und Bereitstellung der Referenzdaten Präzise Referenzdaten bilden die Grundlage für eine aussagekräftige Bewertung eines Systems. Ihre Erzeugung gehört daher zu den fundamentalen Aufgaben im Entwicklungsprozess. Die Art und der Umfang der benötigten Referenzdaten sind sowohl von der Art der verwendeten Eingabedaten (und somit auch von der Sensorik) als auch von der konkreten Fragestellung abhängig. Können die Referenzdaten durch einen Referenzsensor zur Verfügung gestellt oder aus dessen Daten erzeugt werden, so ist die Bereitstellung dieser Daten prinzipiell mit der Verarbeitung von Sensordaten und der Bereitstellung von Ergebnissen durch ein zu testendes System vergleichbar. Die Komponente zur Berechnung der Referenzdaten entspricht in diesem Fall dem verarbeitenden, zu testenden System, die Referenzdaten den Verarbeitungsergebnissen. 60

71 5.6 Erzeugung und Bereitstellung der Referenzdaten Viele Attribute lassen sich jedoch nicht ohne weiteres automatisch erfassen und müssen manuell annotiert werden. Dies ist sehr arbeitsaufwendig und erfordert je nach Detailgrad ein Vielfaches der in den Daten erfassten Zeiträume. Besonderes Augenmerk liegt daher auf der Unterstützung der manuellen Annotation (s. Abschnitt 4.5.1) durch das Framework. Dabei steht die Annotation von Bilddaten im Vordergrund Unterschiedliche Ebenen Die zur Bewertung eines Systems benötigten Referenzdaten lassen sich in drei Ebenen mit unterschiedlicher zeitlicher Auflösung gliedern: global (je Sequenz), abschnittsweise, und einzelbild- bzw. objektbasiert. Die Annotation einzelner Objekte ist die detaillierteste, aber auch die aufwendigste Form der Annotation. Hier werden in jeder einzelnen Sensormessung die Positionen und Ausmaße aller relevanten Objekte markiert und diesen Objekten spezifizierte Attribute zugewiesen. Dazu zählen üblicherweise die Objektklasse, aber auch besondere Eigenschaften des Objekts (z. B. Sichtbarkeit bzw. teilweise Verdeckung eines Verkehrszeichens, aktuelle Ampelphase, Farbe eines Fahrzeugs, Status der Bremsleuchten des vorausfahrenden Fahrzeugs). Manche Objekteigenschaften können sich mit der Zeit ändern, sodass die Attribute prinzipiell für jede Sensormessung einzeln zugewiesen bzw. überprüft und ggf. angepasst werden müssen. Je nach Anwendung wird eine objektgenaue Annotation nicht benötigt. Steht z. B. bei der Bewertung eines Spurerkennungssystems nicht die präzise Lokalisierung der Fahrstreifen im Fokus, sondern die Frage, wie gut das System unterschiedliche Arten und Qualitäten von Fahrbahnmarkierungen erkennt, so kann auf die besonders arbeitsintensive Objektannotation verzichtet werden. In diesem Fall sind Fragen wie die folgenden relevant, die ggf. für die linke und die rechte Seite des Fahrstreifens einzeln zu beantworten sind: Ist eine Markierung vorhanden? Um welche Art von Markierung handelt es sich (z. B. Leitlinie, Randlinie)? Ist die Markierung stark verschmutzt oder beschädigt? Hinzu kommen Fragen zum Fahrbahnzustand oder zur Witterung. Die Antworten auf diese Fragen ändern sich nicht von einem Bild zum nächsten, sondern sind in der Regel jeweils für längere Zeitabschnitte gültig. Diese Zeitabschnitte werden bei der intervallbasierten Annotation erfasst. Globale Attribute beziehen sich immer auf eine vollständige Sequenz und sind somit für die Dauer der Aufnahme gültig. Mögliche Ausprägungen sind z. B. die Identifikation des Versuchsträgers und des Fahrers, die verwendete Kamera, der Softwarestand der Kamera oder das Land, in dem die Fahrt stattgefunden hat. Die Benutzeroberfläche des Frameworks soll die semantische Einteilung in die drei Ebenen widerspiegeln. Das Framework muss daher für jede der drei Ebenen eine intuitive 61

72 5 Anforderungen an das Framework und effiziente Möglichkeit zur Erfassung, Visualisierung und Bearbeitung der korrespondierenden Daten bieten. So wird eine zielgerichtete Annotation auf der erforderlichen Detailstufe ermöglicht Frei definierbare Attribute Unabhängig von der Annotationsebene ist es von zentraler Bedeutung, dass die zur Annotation verfügbaren Attribute durch den Benutzer projektspezifisch definiert werden können. Die drei Ebenen müssen dabei individuell konfigurierbar sein, um eine unabhängige Nutzung zu ermöglichen. 5.7 Integration von Bewertungsverfahren Mit der Verfügbarkeit von Eingabedaten und korrespondierenden Referenzdaten sowie der Ausführbarkeit des entwickelten (Teil-)Systems schafft das Framework die Grundlage für die Bewertung Ausführungsszenarien Grundsätzlich stellen sich für die Bewertungsfunktionen des Frameworks zwei Ausführungsszenarien: die automatisierte Bewertung von Testszenarien und die interaktive Nutzung zur Fehleranalyse und Beobachtung des Systemverhaltens. Die Verarbeitung der Gesamtdatenbasis soll nach Abschluss der Konfiguration und Datenauswahl automatisiert erfolgen und keinen Eingriff durch den Anwender benötigen. Für eine effiziente Durchführung ist die Verarbeitung in Überechtzeit (s. Abschnitt 5.5.6) wünschenswert. Außerdem ist eine Protokollierung der Bewertungsergebnisse notwendig, um eine anschließende Begutachtung zu ermöglichen. Das dazu verwendete Dateiformat soll auch eine Weiterverwendung der Ergebnisdaten in externen Werkzeugen erlauben. Zur Prüfung konkreter Fehlerfälle muss das Framework einen gezielten Zugriff auf die Daten (s. Abschnitt 5.5.7) und somit eine Reproduktion (s. Abschnitt 4.3.1) des Fehlers ermöglichen. Zur Analyse ist eine Visualisierung aller relevanten Daten notwendig: Sensordaten, Referenzdaten sowie (Zwischen-)Ergebnisse der Verarbeitung und der Bewertung Identifizierbarkeit kritischer Teildaten Für die Beantwortung der Frage nach der Güte des Systems wird im Allgemeinen der gesamte Testdatenbestand betrachtet. Bei einer umfangreichen Datenbasis, die gemäß Abschnitt auch Situationen an der Grenze bzw. außerhalb des Operationsbereichs des Systems enthält, ist jedoch eine genauere Aufschlüsselung des Ergebnisses notwendig. Erkennt z. B. ein LDW-System in 90 % der Daten die Fahrspur, so stellt sich die Frage nach der Verteilung des Fehlers und letztendlich nach den konkreten Streckenabschnitten, auf denen die Fahrspur nicht korrekt geschätzt wurde oder keine Schätzung verfügbar war. 62

73 5.7 Integration von Bewertungsverfahren Die Bewertungsmechanismen müssen es erlauben, diese Abschnitte zu identifizieren und für eine anschließende Analyse zugreifbar zu machen. In Abhängigkeit von der Fehlerquote und der Größe der Datenbasis kann die Zahl der konkreten Fehlerfälle sehr groß sein und die darauf basierende Identifikation von Fehlerklassen (z. B. regennasse Fahrbahn, beschädigte Spurmarkierung, Baustelle ) erschweren. Daher muss das Bewertungssystem in der Lage sein, Ergebnisse auf Teilmengen der Daten zur Verfügung zu stellen. So lassen sich Partitionen der Daten ermitteln, in denen die Güte von der Gesamtgüte abweicht. Abhängig von den berechneten Kennzahlen und der Fragestellung der Evaluierung sind, ähnlich der Annotation, unterschiedliche Betrachtungsebenen relevant. Im Gegensatz zur Annotation sind diese Ebenen in der Bewertung jedoch nicht unabhängig voneinander. Die Ergebnisse basieren in der Regel auf der Verarbeitung aller einzelnen Sensormessungen. Bewertungsergebnisse auf höheren Ebenen repräsentieren die aggregierten Ergebnisse einzelner Partitionen oder des Gesamtdatenbestands. Die Aufteilung der Datenbasis in einzelne Sequenzen (s. Abschnitt 5.5.3) stellt eine natürliche Partitionierung bereit. Da sich die einzelnen Sequenzen in ihrem konkreten Inhalt den erfassten Situationen unterscheiden, ist davon auszugehen, dass auch die Systemgüte differiert. Ist das Bewertungssystem in der Lage, die Bewertungsergebnisse je Sequenz zu berechnen, lassen sich so Stärken und Schwächen des Systems zur weiteren Analyse eingrenzen Erweiterbarkeit und Wiederverwendbarkeit Während die Gesamtauswahl der zur Bewertung eines Systems verwendeten Verfahren problemspezifisch ist, so handelt es sich im Einzelnen zu großen Teilen um Standardmethoden (z. B. Mittelwert, Varianz, mittlerer Fehler). Daher soll das Framework besonders in Bezug auf die Bewertung eine hohe Wiederverwendbarkeit einmal implementierter Verfahren gewährleisten und eine einfache Kombination vorhandener Methoden erlauben. Sowohl zur Implementierung der Standardmethoden als auch problemspezifischer Bewertungsmethoden muss das Framework eine Erweiterbarkeit vorsehen Harmonisierung von Referenzdaten und Verarbeitungsergebnissen Im Rahmen der Bewertung ist zu berücksichtigen, dass die Referenzdaten und die Verarbeitungsergebnisse u. U. nicht kompatibel sind. Sie können sich insbesondere in den verwendeten Einheiten und Bezugssystemen unterscheiden. Dies ist vor allem dann der Fall, wenn die Erhebung der Daten und die Entwicklung unabhängig voneinander erfolgen, z. B. in einem Benchmark, bei Weiterverwendung vorhandener Daten in einem neuen Projekt oder auch bei Nutzung synthetischer Daten, für die das Simulationssystem die Einheiten und das Bezugssystem definiert. Das Framework muss daher auch einen flexiblen Mechanismus bieten, der die Harmonisierung der Referenz- und Ergebnisdaten ermöglicht. 63

74 5 Anforderungen an das Framework 5.8 Fazit Die zur Evaluierung eines System notwendigen Kernelemente Bereitstellung von Sensordaten, Erzeugung von Referenzdaten, Ausführung des Systems und Bewertung der Ergebnisse sind eng miteinander verzahnt. Das Framework soll diese Elemente in einer gemeinsamen Arbeitsumgebung vereinen, um eine reibungslose Interaktion zwischen unterschiedlichen Arbeitsbereichen und Aufgaben zu ermöglichen. Die Analyse der Anforderungen hat gezeigt, dass die Erfassung und die Bereitstellung der Sensordaten eine zentrale Rolle spielen. Sie sind fundamental für die übrigen Bereiche. Nicht nur die Erzeugung der Referenzdaten hängt von einer effizienten und systematischen Bereitstellung der Sensordaten ab. Der Zugriff auf die Eingabedaten bildet auch die Basis zur Ausführung des Systems und zusammen mit den Referenzdaten zu dessen Bewertung. Dabei muss im Rahmen der Datenerfassung das breite Spektrum an unterschiedlichen Sensortypen, Datenformaten und Frequenzen der Sensormessungen dahingehend abstrahiert werden, dass die spezifischen Anforderungen an die Entwicklung von Algorithmen und die Durchführung von Bewertungen erfüllt werden können. In allen Bereichen ist eine individuelle Anpassbarkeit und Erweiterbarkeit des Frameworks notwendig, um den Anforderungen konkreter Entwicklungsprojekte problemspezifisch gerecht werden zu können. Daher ist eine flexible und erweiterbare Architektur des Frameworks essenziell. 64

75 6 Die Entwicklungs- und Analyseumgebung ADAF Dieses Kapitel stellt die im Rahmen dieser Arbeit entwickelte Entwicklungs- and Analyseumgebung Advanced Development & Analysis Framework (ADAF) vor. Ziel der Entwicklung ist eine gemeinsame Plattform, die den Anforderungen der unterschiedlichen Aufgabengebiete und Nutzerprofile gerecht wird. Die Umgebung bildet ein Framework, dass die Durchführung von Entwicklungs- und Evaluierungsprojekten im Bereich sensordatenverarbeitender Systeme ermöglicht und unterstützt. Es handelt sich um eine modulbasierte Architektur, die vom Nutzer problemspezifisch gestaltet und ergänzt werden kann. Abbildung 6.1 vermittelt einen ersten Eindruck der Benutzeroberfläche von ADAF, die exemplarisch ein System zur Fahrspurerkennung mit Visualisierung der Bild- und Ergebnisdaten zeigt. GPS-Informationen ermöglichen die Darstellung der aktuellen Fahrzeugposition in einem Kartenausschnitt. Neben diesen anwendungsspezifischen Aspekten zeigt die Benutzeroberfläche einige grundlegende Elemente von ADAF. Dazu gehören Abbildung 6.1: Beispielhafte Darstellung der ADAF-Benutzeroberfläche mit einigen geladenen Modulen (Plugins): (1) Plugingraph (2) Diagramme (hier:zeitmessung) (3) Benachrichtigungen und Statusmeldungen (4) Durch ein Plugin bereitgestellte Ergänzung der Benutzeroberfläche (5) 2D-Display zur Anzeige der Bilddaten mit überlagerter Ergebnisvisualisierung (6) Konfigurationseinstellungen der Plugins. 65

76 6 Die Entwicklungs- und Analyseumgebung ADAF die grafische Konfiguration der Verarbeitungskette (Plugingraph), die Messung der Verarbeitungszeit, die Darstellung von Diagrammen, die Ausgabe von Statusmeldungen sowie die Parametrierung der verwendeten Module (sog. Plugins). 6.1 Designziele Zur Erfüllung der in den vorangegangenen beiden Kapiteln erarbeiteten Anforderungen, die an ein Framework zur Entwicklung, Bewertung und Analyse von Computer Vision- Anwendungen gestellt werden, werden die folgenden Designziele für ADAF formuliert: Modularität, Erweiterbarkeit, Flexibilität, Analysierbarkeit und Bedienbarkeit Modularität ADAF soll einen gemeinsamen Rahmen zur Durchführung der in Abschnitt 5.2 genannten Entwicklungsaufgaben bilden. Um dem breiten Anforderungspektrum der einzelnen Aufgaben gerecht werden zu können, soll die Bereitstellung spezifischer Funktionalität nicht durch das Framework selbst erfolgen, sondern durch ergänzbare Module. ADAF soll grundlegende Funktionen bieten, die durch diese Module genutzt werden können (z. B. die Ausgabe von Benachrichtigungen und Statusmeldungen). Die Architektur des Frameworks soll einen Datenaustausch zwischen diesen Modulen ermöglichen, um so ihre effiziente Kombination zu einer leistungsfähigen Verarbeitungskette zu erlauben. Somit soll die genaue Funktionalität vollständig durch die zum jeweiligen Zeitpunkt verwendeten Module bestimmt werden. Dies erlaubt die genaue Anpassung der Arbeitsumgebung an die konkreten Anforderungen der jeweils zu bearbeitenden Aufgabe und somit ein zielgerichtetes Arbeiten. Die Modularität ermöglicht die Wieder- und Weiterverwendung von Teilfunktionen, sowohl zu unterschiedlichen Zeitpunkten im selben Entwicklungsprojekt als auch projektübergreifend, jeweils in wechselnder Kombination mit anderen Modulen. Zum Funktionsumfang von ADAF gehören mehrere vielfältig einsetzbare Plugins (z. B. zur Visualisierung von Daten, zur Datenaufnahme oder zur Annotation). Diese Sammlung erhebt jedoch keinen Anspruch auf Vollständigkeit, da diese aus den genannten Gründen nicht möglich ist Erweiterbarkeit Die genauen Anforderungen und technischen Rahmenbedingungen zukünftiger Systeme sind heute noch nicht absehbar. Neue Sensoren und Sensorkonzepte, neue Verfahren zur Umfelderfassung, aber auch neue gesetzliche Regelungen stellen neue Anforderungen an die Evaluierung dieser Systeme. Zur Erfüllung neuer Aufgaben und Anforderungen müssen neue Module ergänzt werden können. Ein wichtiger Aspekt ist dabei, dass diese Ergänzung kundenseitig durch den Nutzer der Software erfolgen kann, nicht allein durch den Anbieter. Dies ermöglicht dem Nutzer eine genaue Anpassung der Arbeitsumgebung an seine Bedürfnisse. 66

77 6.1 Designziele Die Möglichkeit der Eigenentwicklung neuer Module bietet dem Kunden nicht nur in Bezug auf die Funktion, sondern auch in Bezug auf den Managementprozess Vorteile. Die Ergänzung und Anpassung von Modulen kann dadurch intern erfolgen, je nach Umfang mit sehr geringem Managementaufwand. Für externe Prozesse ist der Aufwand oft ungleich höher. Sie erfordern Angebotseinholung, Kostengenehmigung und zusätzlichen Kommunikationsaufwand. Je nach Umfang der benötigten Funktionalität kann dieser zusätzliche Aufwand an Zeit und Geld leicht den Aufwand für die eigentliche Implementierung übertreffen und diese somit unwirtschaftlich machen. Zusätzlich schützt der modulbasierte Ansatz das geistige Eigentum des Kunden, da es nicht nach außen gegeben werden muss Flexibilität Modularität und Erweiterbarkeit sind zwei Grundbausteine, um den Anforderungen der unterschiedlichen Aufgabenbereiche effektiv und effizient gerecht werden zu können. Dies betrifft die verwendeten Sensoren, Datenformate und eingesetzten Algorithmen ebenso wie die Art und Weise der Bewertung der Systeme. Modularität und Erweiterbarkeit allein sind zur Erfüllung dieser Anforderungen jedoch nicht hinreichend. Das Designziel Flexibilität soll daher insbesondere den Entwicklern von Modulen unter drei Gesichtspunkten die notwendigen Entwurfsfreiheiten gewähren: die Art und der Umfang der verarbeiteten Daten, der Funktionsumfang einzelner Module sowie deren Konfigurierbarkeit. Der erste Aspekt bedeutet, dass ADAF keine Vorgaben machen soll, in welchem Maß Daten zwischen Modulen ausgetauscht werden. ADAF stellt die Infrastruktur für die Weitergabe der Daten bereit, ohne die konkrete Repräsentation der Daten vorzuschreiben. Allein das sendende und das empfangende Modul müssen eine gemeinsame Darstellung verwenden. Dies ermöglicht es dem Modulentwickler, die Daten gemäß der Anforderungen des zu lösenden Problems (nicht des ADAF) geeignet zu repräsentieren. Diese Flexibilität ermöglicht insbesondere auch die Einbindung neuer Sensorarten und -konzepte. Der zweite Aspekt berücksichtigt, dass die Verwendung von ADAF keinen Einfluss darauf nehmen soll, wie ein Problem modularisiert, also in welche Teilprobleme es zerlegt wird. ADAF stellt nur sehr grundlegende Anforderungen an die Art und den Funktionsumfang der einzelnen Module. Die Entscheidung über eine sinnvolle Aufteilung liegt vollständig beim Nutzer. Sie kann abhängig vom jeweiligen Problem, der jeweiligen Entwicklungsphase oder auch der kundenspezifischen Entwicklungsphilosophie anders ausfallen. Der Funktionsumfang eines Moduls soll von einem einzelnen Verarbeitungsschritt (wie z. B. der Merkmalsextraktion) bis zu einem vollständigen Algorithmus (wie z. B. einer Hinderniserkennung als Teilmodul in einem System zur Freiraumerkennung) reichen können. Ferner sollen Module Visualisierungs-, Speicher- oder Kommunikationsfunktionen sowie Hilfsoperationen (z. B. zur Konvertierung oder Vorverarbeitung von Daten) bereitstellen können. Der dritte Aspekt erfasst den Bedarf an unterschiedlichen Konfigurationsoptionen, der sich aus der Flexibilität in der Wahl des Funktionsumfangs eines Moduls ergibt. Er ist 67

78 6 Die Entwicklungs- und Analyseumgebung ADAF beim Design von ADAF ebenfalls zu berücksichtigen Analysierbarkeit Ein fehlgeschlagener Test ist wertvoller als ein erfolgreicher Test, da der erfolgreiche nicht beweisen kann, dass das System fehlerfrei ist, der fehlgeschlagene Test jedoch nachweist, dass das System fehlerbehaftet ist. In diesem Fall muss daher nachgebessert werden. Dazu muss es jedoch möglich sein, die Fehlerursache zu bestimmen. In Abschnitt wurde bereits die Notwendigkeit der Reproduzierbarkeit erläutert. Um nach erfolgreicher Reproduktion des Fehlers, eine systematische Fehleranalyse zu ermöglichen, sollen die Vorgänge im System durch den Benutzer im Einzelnen nachvollziehbar sein. Das System soll während der Verarbeitung an beliebiger Stelle unterbrochen und fortgesetzt werden können, ohne dass dies die Ergebnisse der Datenverarbeitung verfälscht. Es soll möglich sein, Zwischenergebnisse der Verarbeitungsstufen zu visualisieren und zu analysieren. Sämtliche Manipulationen von Daten erfolgen exklusiv durch Plugins. ADAF dient als Plattform zur Ermöglichung dieser Verarbeitung, nimmt aber selbst keine Veränderungen an den Daten vor. So erhält der Nutzer die Möglichkeit, alle Stufen der Verarbeitung zu kontrollieren und nachzuvollziehen Bedienbarkeit Die Vielzahl der Einsatzgebiete für ADAF führt zu einer sehr breiten Nutzerbasis. Durch die verschiedenen Aufgabenbereiche haben die Nutzer ein stark unterschiedliches Fachwissen, aber auch unterschiedliche Erfahrungshorizonte. Dies muss beim Design von ADAF berücksichtigt werden. Die Oberfläche und Bedienung muss klar und intuitiv sein. Die Oberfläche muss sich der jeweiligen Aufgabenstellung anpassen bzw. daran anpassbar sein. Jeder Nutzer muss auf seinem Niveau arbeiten können. Nachdem ADAF für eine bestimmte Aufgabe wie z. B. die Aufnahme von Daten in einer festen Sensorkonstellation oder die Annotation einer vorhandenen Datenbasis konfiguriert wurde, muss es für einen ungeschulten 1 Anwender mit minimalem Aufwand möglich sein, ADAF zur Erfüllung dieser Aufgabe zu verwenden. Die Oberfläche muss daher klar und übersichtlich strukturiert sein und auf die für diese Aufgabe wesentlichen Elemente reduziert werden können. Auf der anderen Seite darf die Benutzerschnittstelle einen erfahrenen Anwender nicht unnötig beschränken. ADAF soll also die realisierbare Komplexität so wenig wie möglich durch äußere Vorgaben begrenzen. Die Grundlage zur Erfüllung dieser Forderung wird bereits durch das Designziel der Modularität erfasst. Da sämtliche spezifische Funktionalität durch Module bereitgestellt wird, kann durch die Auswahl der relevanten Module die Anwendungskomplexität gesteuert werden. Dennoch wird das Designziel Bedienbarkeit explizit formuliert, da die Modularität allein nicht ausreicht, um eine benutzerfreundliche Bedienoberfläche und Nutzerführung zu gewährleisten. Die zugrunde liegende Plattform muss einen gemeinsa- 1 in Bezug auf ADAF 68

79 6.2 Modulbasierte Architektur men Rahmen für die unterschiedlichen Module bereitstellen und eine konsistente und klare Benutzerführung sicherstellen. Ein wichtiger Aspekt ist dabei auch die Integration der verschiedenen Module und die Kombination zu einer Gesamtanwendung bzw. Applikation. Ein übergreifendes Konzept zur Manipulation der modulspezifischen Parameter und zur Verwaltung der so erzeugten Gesamtkonfigurationen ist essenziell. 6.2 Modulbasierte Architektur Entsprechend des Designziels Modularität wird so gut wie sämtliche Funktionalität in ADAF durch eigene Module, sogenannte Plugins, zur Verfügung gestellt. Das betrifft sowohl den Zugriff auf angeschlossene Sensoren, die verarbeitende Algorithmik als auch die Visualisierung. ADAF selbst stellt die grundlegenden Funktionen zur generellen Ablaufsteuerung, Verwaltung und Wiedergabe von aufgezeichneten Sequenzen, Konfigurationsverwaltung und Protokollierung bereit. Diese Dienste können von den Plugins verwendet werden. Durch die modulare Architektur ist ADAF nicht auf eine bestimmte Sensorik bzw. Datenart wie beispielsweise 2D-Kameras und Bilder festgelegt, sondern sehr leicht durch neue Sensoren, Algorithmen und Visualisierungen erweiterbar. Der Funktionsumfang eines Plugins wird durch das Framework nicht beschränkt. Es sind sowohl sehr kleine Helfermodule als auch sehr umfangreiche Verarbeitungsmodule möglich. Aus Sicht des ADAF handelt es sich bei einem Plugin um eine Blackbox, an die nur grundlegende Anforderungen an die zu erfüllenden Schnittstellen gestellt werden (s. Abschnitt 6.6). Das Framework weiß jedoch weder, welche zur Verfügung gestellten Schnittstellen, Dienste und Services das Plugin benötigt oder optional nutzt, noch bei welchen Benachrichtigungen und Ereignissen es aktiv wird. LDW (Lane Departure Warning) Abbildung 6.2: Ein Verarbeitungsplugin mit einem Eingang und vier Ausgängen Ein Plugin (s. Abbildung 6.2) kann beliebige Ein- und Ausgänge definieren, sowohl bzgl. der Anzahl als auch des Datentyps. Diese dienen als Schnittstelle zu anderen Plugins. Jeder Ausgang kann mit beliebig vielen Eingängen anderer Plugins verknüpft werden, aber jeder Eingang kann mit maximal einem Ausgang eines anderen verbunden sein. Diese Verbindungen sind typsicher, d. h., nur Pins des gleichen Datentyps können miteinander verbunden werden. Auf diese Weise werden mögliche Konfigurationsfehler unterbunden. Ein Plugin wird auf zwei Arten in ADAF identifiziert. Der Name des Plugins verweist auf eine konkrete Realisierung einer Funktion (z. B. Lane Departure Warning oder 2D Display). Um mehrere Instanzen desselben Plugins unterscheiden zu können, wird ihnen außerdem 69

80 6 Die Entwicklungs- und Analyseumgebung ADAF ein eindeutiger Bezeichner zugewiesen. Dieser kann vom Nutzer nach Bedarf angepasst werden (z. B. LDW in Abbildung 6.2) Plugintypen ADAF unterscheidet verschiedene Plugintypen. Sie ermöglichen eine zielgerichtete Bereitstellung neuer Funktionalität innerhalb des Frameworks Verarbeitung Diese Plugins sind zentraler Bestandteil der ADAF-Architektur. Verarbeitungsplugins können zur Laufzeit dynamisch geladen und konfiguriert werden. Sie stellen Ein- und Ausgabepins zur Verfügung über die sie mit anderen Plugins verknüpft werden können (s. Abschnitt 6.3.1) Sensoren Sensorplugins sind eine Sonderform der Verarbeitungsplugins, die dem Zugriff auf angeschlossene Sensoren wie z. B. Kameras, GPS-Empfänger oder den Feldbus dienen. Sie sind in der Regel modellspezifisch und verwenden herstellerabhängige Schnittstellen für den Zugriff auf die Hardware. Während des Zugriffs auf verbundene Sensoren werden empfangene Daten durch das Plugin in ein sogenanntes Datenpaket, einen kontinuierlichen Speicherbereich, serialisiert. Dieses Datenpaket wird im ADAF zur Verfügung gestellt und dort verarbeitet (s. Abschnitt 6.3.3). Die Serialisierungsstruktur wird durch ADAF nicht vorgegeben. Dies hat zwei Konsequenzen. Zunächst wird das Sensorplugin zur Interpretation der Daten benötigt. Es muss daher auch in Verarbeitungsszenarien ohne angeschlossene Sensoren verfügbar sein. Sowohl bei der Live-Verarbeitung von Sensordaten als auch bei Verwendung von aufgezeichneten Daten deserialisiert es die Daten und stellt explizite Datentypen wie beispielsweise Bilder oder GPS-Signale über Ausgabe-Pins bereit, sodass diese von nachfolgenden Plugins verwendet werden können. Des Weiteren ermöglicht die Serialisierung die Bereitstellung und Aufzeichnung beliebiger Daten, da allein das Sensorplugin für die Repräsentation verantwortlich ist (s. Abschnitt 6.4.3). Der eigentliche Sensorzugriff wird in einem eigenen Thread ausgeführt. Dieser muss durch den Entwickler des Sensorplugins implementiert werden (Polling), falls er nicht durch die Treibersoftware des Sensors realisiert wird, die bei Verfügbarkeit neuer Daten eine Funktion im Plugincode, eine sog. Callback-Funktion, aufruft. Bei der Verwendung aufwendiger Konfigurationen mit zahlreichen Sensoren ist eine ausreichende Hardwareausstattung zu berücksichtigen. Um auch eine zeitgerechte Verarbeitung hochfrequenter Sensoren (z. B. Feldbus) zu gewährleisten, muss eine ausreichende Anzahl Prozessorkerne zur Verfügung stehen, um die notwendige Ausführungshäufigkeit und -zeit der einzelnen Sensor- und des Verarbeitungsthreads zu gewährleisten. 70

81 6.2 Modulbasierte Architektur Visualisierung Ein Verarbeitungsplugin kann explizit als Visualisierungsplugin konfiguriert werden. Dies ermöglicht ein verbessertes Scheduling (s. Abschnitt 6.3.3), das Visualisierungsplugins erst am Ende der Verarbeitungkette aktiviert. Der Effekt ist primär kosmetischer Natur, da dies den zeitlichen Versatz zwischen den Aktualisierungen unterschiedlicher Visualisierungsplugins minimiert und somit zu einer gleichmäßigeren Darstellung auf der Benutzeroberfläche führt. Dadurch wird die Benutzererfahrung verbessert Dateiformate Diese Plugins ermöglichen es ADAF, unterschiedliche Dateiformate zu lesen. Sie stellen einen Sonderfall im Vergleich zu den übrigen Plugins im ADAF dar, da sie nicht zu den Verarbeitungsplugins zählen und auch nicht auf der Benuzteroberfläche repräsentiert sind. Sie werden bei Start des ADAF automatisch geladen und bei Bedarf verwendet. Die Realisierung von Dateiformaten als Plugins ermöglicht die flexible Erweiterbarkeit des ADAF um weitere Formate. Dadurch kann der Kunde auch bereits vorhandene, mit anderen Systemen aufgezeichnete Daten in ADAF verwenden. So ist er weder an das Dateiformat HDF (s. Abschnitt 6.4.3) gebunden, noch gezwungen, ADAF für die Datenakquise einzusetzen Konfiguration Die Konfiguration der Plugins verteilt sich auf zwei Ebenen: Die Konfiguration der einzelnen Plugins mit ihren individuellen Parametern, sowie die Zusammenstellung mehrerer Plugins zu einer Applikation Applikation Die Gesamtheit der geladenen Plugins und ihrer Verbindungen wird als Applikation bezeichnet. Diese kann zusammen mit den Parametern der einzelnen Plugins als Applikationsprofil gespeichert und geladen werden. Die grafische Darstellung der Verknüpfungen wird als Plugingraph oder Datenflussgraph bezeichnet. Die Ein- und Ausgänge geladener Verarbeitungsplugins können, wie in Abbildung 6.3 dargestellt, auf der Benutzeroberfläche interaktiv miteinander verbunden werden, um so eine Verarbeitungskette zu erzeugen. Diese muss nicht linear sein, sondern kann sich unter Berücksichtigung der oben genannten Verbindungseinschränkungen beliebig verzweigen oder vereinen. Auch unabhängige Teilketten sind möglich. Plugins und Verbindungen können dynamisch hinzugefügt und entfernt werden. Dadurch kann ein Nutzer sehr schnell aus vorhandenen Plugins eine neue Applikation zusammenstellen Plugins Die Konfiguration der einzelnen Plugins erfolgt zentral im Fenster Plugin Properties. Hier werden für alle aktuell geladenen Plugins die verfügbaren Konfigurationsoptionen 71

82 6 Die Entwicklungs- und Analyseumgebung ADAF Abbildung 6.3: Interaktive Verknüpfung von Plugins. Nur typgleiche Pins sind mögliche Ziele einer Verbindung und werden farblich hervorgehoben. Abbildung 6.4: Die Konfiguration der Plugins erfolgt im Fenster Plugin Properties. angezeigt und verwaltet (s. Abbildung 6.4). Plugins können eine beliebige Anzahl Konfigurationsparameter, sog. Properties, zur Verfügung stellen. Zur besseren Übersichtlichkeit können diese hierarchisch gruppiert werden oder abhängig von der Konfiguration anderer Konfigurationsparameter ausgeblendet oder deaktiviert werden. Sämtliche Benutzerinteraktion mit den Properties werden durch ADAF bereitgestellt. Dies ermöglicht eine leichte Manipulation der Parameter, ohne dass der Entwickler des Plugins eine eigene Benutzeroberfläche bereitstellen muss. Außerdem erhöht es die Konsistenz der Bedienung, wenn unterschiedliche Plugins geladen werden. 72

83 6.3 Datenfluss 6.3 Datenfluss Die Verwendung mehrerer Plugins in einer Applikation erfordert eine Definition, wie und wann zwischen welchen Plugins Daten ausgetauscht werden können Struktur des Datenflussgraphen Die Ein- und Ausgabepins verschiedener Plugins können miteinander verbunden werden, um Daten zwischen diesen Plugins auszutauschen. Die Verbindungen zwischen den Plugins sind gerichtet, vom Ausgabepin eines Plugins zum Eingabepin des folgenden Plugins. Dadurch definieren sie einen Datenflussgraphen, in dem jedes Plugin einen Knoten darstellt, jede Verbindung eine Kante. Die Kanten repräsentieren Datenabhängigkeiten zwischen den Plugins. Abbildung 6.5 zeigt beispielhaft den Datenflussgraphen einer Applikation zur Bewertung eines Stereoverfahrens. In der Applikation werden über das TRS Sensor-Plugin vom Simulationssystem NISYS TRS zwei Kamerakanäle sowie die dazugehörigen Referenz- Tiefendaten bereitgestellt. Aus den Tiefeninformationen wird mit Hilfe zweier Disparity from Depth Image-Plugins für jeden Kanal das korrespondierende Disparitätsbild berechnet und anschließend im Determine Occlusion-Plugin die Verdeckungen aus Sicht der linken Kamera bestimmt. Das Ergebnis wird im Evaluation-Plugin mit der Ausgabe des Stereoverfahrens (Stereo DP Plugin) verglichen und Fehlermaße berechnet. Alle Bilddaten (Eingabedaten, Referenzdaten und (Zwischen-)Ergebnisse) werden über 2D-Display- CameraEL (2DEDisplay) CameraER (2DEDisplay) StereoEDP (StereoEDPEPlugin) DepthEL (2DEDisplay) DepthER (2DEDisplay) TRS (TRSESensor) Disp.EfromEDepthEL (DisparityEfromEDepthEImage) DetermineEOcclusion (DetermineEOcclusion) Evaluation (Evaluation) Disparity (2DEDisplay) DisparityEGT (2DEDisplay) Disp.EfromEDepthER (DisparityEfromEDepthEImage) ResultEWriter (ResultEWriter) Abbildung 6.5: Datenflussgraph einer Applikation zur Bewertung eines Stereoverfahrens im ADAF. 73

84 6 Die Entwicklungs- und Analyseumgebung ADAF Plugins angezeigt. Die numerischen Ergebnisse werden durch das Result Writer-Plugin in einer Datei protokolliert. Der Datenfluss zwischen Plugins und somit innerhalb einer Applikation wird grundsätzlich durch die Pinverbindungen definiert. Dabei kann jeder Ausgabepin mit beliebig vielen Eingabepins anderer Plugins verbunden werden (1:n). Jeder Eingangspin kann allerdings maximal mit einem Ausgabepin verbunden sein (1:1), um eine eindeutige Zuordnung des Eingabewerts zu gewährleisten. Die Verbindungen zwischen den Plugins beschreiben zunächst nur, wo Daten weitergeleitet werden. Sie sagen noch nichts über den Zeitpunkt aus, zu dem Daten von einem Ausgabe- an einen Eingabepin weitergeleitet werden. Dieser hängt davon ab, wann ein Plugin aktiviert wird Ereignisgesteuerte Verarbeitung ADAF ist ein ereignisgesteuertes System. Im Gegensatz zu einem zeitgesteuerten System werden Aktivitäten nicht in einem festen Takt sondern durch bestimmte Ereignisse ausgelöst. Das zentrale Ereignis ist die Verfügbarkeit neuer Daten im System, entweder von einem Sensor oder aus einer Sequenz. Weitere Ereignisse umfassen u. a. das Starten und Beenden einer Aufnahme, das Laden und Speichern von Einstellungen sowie das Öffnen einer neuen Sequenz/Datei. Die Aktivierung eines Plugins bedeutet daher die Benachrichtigung über ein Ereignis. Dabei werden grundsätzlich immer alle Plugins über alle Ereignisse informiert. Es liegt in der Verantwortung der einzelnen Plugins, ob ein bestimmtes Ereignis zu einem bestimmten Zeitpunkt für sie relevant ist. Die Reihenfolge der Aktivierung hängt von den Verbindungen der Plugins untereinander ab. Details hierzu finden sich im folgenden Abschnitt Der Vorteil eines ereignisgesteuerten gegenüber einem zeitgesteuerten System liegt in der Reproduzierbarkeit. Eine Folge von Ereignissen kann exakt wiederholt werden. Als Zeitbasis dienen, sofern notwendig, mit den Ereignissen verknüpfte Zeitstempel. Der Einfluss von Änderungen zeitlicher Rahmenbedingungen während der Ausführung kann so auf ein Minimum reduziert werden. Dies ist gerade unter heute üblichen Multitasking- Desktop-Betriebssystemen wichtig, da die zur Verfügung stehenden Ressourcen und somit die Ausführung stark durch andere Programme beeinflusst werden können. Des Weiteren ermöglicht ein ereignisgesteuertes System eine leichtere Interpretation und Nachvollziehbarkeit der Vorgänge. Ein Ereignis entspricht genau einem Verarbeitungsschritt, d. h. einer Ausführung der Verarbeitungskette. Jedes Ereignis markiert einen relevanten Zeitpunkt, zu dem u. U. eine Reaktion oder Verarbeitung notwendig ist. In einem getakteten System ist dies nicht der Fall. Ist der Takt höher als es nennenswerte Ereignisse gibt, kommt es zu zusätzlichem Aufwand, da jeweils geprüft werden muss, ob zu diesem Zeitpunkt tatsächlich relevante Daten vorliegen oder nicht. Ist der Takt niedriger, ergibt sich entweder die Gefahr eines Datenverlustes, wenn Daten nicht rechtzeitig verarbeitet werden, oder es entsteht der Bedarf für einen Datenpuffer. Der allerdings steht der Grundidee der zeitbasierten Verarbeitung entgegen, da die Daten nicht mehr in Bezug zum Takt verarbeitet werden. Durch die ereignisbasierte Auslösung kann die Verarbeitung der Ereignisse bei Bedarf sowohl während der Verarbeitung eines Ereignisses als auch zwischen zwei Ereignissen 74

85 6.3 Datenfluss unterbrochen werden, ohne dass dies die Ergebnisse beeinflusst. Das erleichtert während der Algorithmenentwicklung das Debuggen sowie die Reproduzierbarkeit und Analyse fehlgeschlagener Tests Scheduling Bei Eintritt eines Ereignisses werden alle Plugins unter Berücksichtigung ihrer Abhängigkeiten benachrichtigt. Jedes Ereignis ist global in dem Sinne, das immer alle Plugins benachrichtigt werden, unabhängig von vorhandenen Verbindungen und davon, ob ein Vorgängerplugin tatsächlich neue Daten zur Verfügung gestellt hat. Die Verbindungen zwischen den Plugins definieren allerdings die Reihenfolge in der die Plugins aktiviert werden. Ein Plugin ist bereit zur Ausführung, wenn alle Vorgängerplugins vollständig ausgeführt wurden. Dann stehen potenziell alle Eingangsdaten zur Verfügung. 2 Zur Bestimmung der Ausführungsreihenfolge wird der Plugingraph in einen gerichteten, zyklenfreien Graphen (Directed Acyclic Graph, DAG) überführt. Dieser wird im Folgenden als auch Abhängigkeitsgraph bezeichnet. Jedes Plugin entspricht weiterhin einem Knoten. Zwei Knoten werden durch eine gerichtete Kante verbunden, wenn sie mindestens eine Pinverbindung aufweisen. Rückwärtskanten werden ignoriert. Zusätzlich werden zwei virtuelle Knoten in den Graphen eingefügt, d. h. Knoten, die keinem Plugin entsprechen, sondern der Strukturierung des Graphen dienen. Um einen zusammenhängenden Graphen zu erhalten, wird ein virtueller Knoten mit allen Knoten ohne Eingangskante verbunden und dient als Wurzelknoten. Dieser Knoten wird mit allen Plugins verbunden, die keine Eingabepins haben oder deren sämtliche Eingabespins nicht verbunden sind. Ein weiterer virtueller Knoten wird zwischen Verarbeitungs- und Visualisierungsplugins eingefügt. Beginnend beim Wurzelknoten wird der Graph anschließend topologisch sortiert und jedem Knoten Kosten t zugewiesen, die der Entfernung zum Wurzelknoten entsprechen. Virtuelle Knoten werden bei dieser Berechnung ignoriert. Knoten mit identischen Kosten werden gruppiert. Für die in Abbildung 6.5 dargestellten Applikation ergibt sich der in Abbildung 6.6 dargestellte Abhängigkeitsgraph. Eine Gruppe von Knoten mit identischen Kosten wird als Zeitscheibe bezeichnet. Plugins in einer Zeitscheibe sind gleichberechtigt in Bezug auf die Ausführungsreihenfolge, d. h. ihre Abhängigkeiten sind im gleichen Ausführungsschritt erfüllt. Die Plugins werden in der Reihenfolge der Zeitscheiben aktiviert. Plugins in derselben Zeitscheibe können prinzipiell parallel ausgeführt werden, da sie nicht voneinander abhängen. Aktuell findet jedoch eine sequenzielle Ausführung statt. Erst wenn alle Plugins einer Zeitscheibe ausgeführt wurden, werden bereitgestellte Ausgaben an die Eingänge der folgenden Plugins weitergeleitet. Durch den virtuellen Knoten zwischen Verarbeitungs- und Visualisierungsplugins werden letztere immer der letzten Schedulinggruppe zugewiesen und somit als letztes ausgeführt. Dies dient der in Abschnitt erläuterten Verbesserung der Darstellung 2 Die Ausgabe von Ergebnissen ist für ein Plugin optional. Sie kann von vielen Faktoren abhängen. 75

86 6 Die Entwicklungs- und Analyseumgebung ADAF Camera1L Stereo1DP Camera1R TRS Disp.1from Depth1L Disp.1from Depth1R Determine occlusion Evaluation Result Writer Depth1L Depth1R Disparity Disparity1GT t1=10 t1=11 t1=12 t1=13 t1=14 t1=15 Abbildung 6.6: Abhängigkeitsgraph für die Applikation in Abbildung 6.5. Gepunktete Knoten sind virtuell und werden bei der Kostenberechnung nicht berücksichtigt. Die vertikalen Linien gruppieren Knoten mit identischen Kosten. auf der Benutzeroberfläche. Es besteht die Möglichkeit den Plugingraphen auf der Benutzeroberfläche automatisch gemäß dem Scheduling anzuordnen, sodass die Darstellung der Verarbeitungsreihenfolge entspricht. Plugins innerhalb derselben Zeitscheibe werden übereinander angeordnet, die einzelnen Zeitscheiben von links nach rechts nebeneinander Transparenz der Datenverarbeitung Ein Beispielalgorithmus benötige als primäre Eingabe ein Bild. Für dieses Bild sind zwei fundamentale Eigenschaften zu unterscheiden: die Quelle und der Inhalt. Um bedeutungsvolle Ergebnisse zu erhalten, müssen die Eingabedaten problemrelevant sein und den inhaltlichen Anforderungen des Algorithmus genügen. So benötigen Systeme zur Fahrspurfindung oder Verkehrszeichenerkennung üblicherweise Bilddaten aus der Fahrerperspektive und Fahrspurwechselassistenten Bilddaten rückwärtiger Kameras. Grundsätzlich trägt der Nutzer die Verantwortung für die semantische Bedeutung der Verarbeitung und der verarbeiteten Daten. ADAF stellt die technischen Mittel bereit, dieses Ziel mit unterschiedlichen Methoden und hoher Flexibilität zu erreichen. Für die Verarbeitung eines Bildes ist es irrelevant, aus welcher Quelle dieses Bild stammt. Es hat keinen Einfluss auf die Semantik der Verarbeitung, ob das Bild direkt von einer Kamera stammt und falls ja, von welcher Marke und welchem Modell aus einer gespeicherten Videosequenz oder ob es synthetisch erzeugt wurde. Auf Implementierungsebene werden die Bilddaten als Argument für einen Funktionsaufruf repräsentiert. Innerhalb des Plugingraphen wird dies durch die Verknüpfung von Aus- und Eingabepins erreicht. Für das Plugin ist völlig transparent, aus welcher Quelle die Eingabedaten stammen und welche Verarbeitungsschritte sie bereits durchlaufen haben. Auf die Unterschiede zwischen der direkten Erfassung der Daten durch Sensoren 76

87 6.4 Datenerfassung und -wiedergabe und dem Zugriff auf aufgezeichnete Daten geht der folgende Abschnitt näher ein. 6.4 Datenerfassung und -wiedergabe In Abschnitt 4.4 wurde dargelegt, das Eingabedaten auf unterschiedliche Art und Weise bereitgestellt werden können: durch direkten Sensorzugriff oder durch eine vorhandene Datenbasis. Der vorliegende Abschnitt erläutert die in ADAF realisierten Konzepte zur Erfassung und Aufzeichnung von Sensordaten sowie deren Wiedergabe zu einem späteren Zeitpunkt. Dabei werden die in Abschnitt 5.5 erarbeiteten Anforderungen berücksichtigt Transparenz der Datenbereitstellung Auf den ersten Blick scheinen Aufnahme und spätere Verarbeitung klar trennbar zu sein und somit eine unabhängige Betrachtung legitim. Für einen beliebigen rein videobildbasierten CV-Algorithmus ist es beispielsweise möglich, die Bilddaten mit einer handelsüblichen Digitalkamera aus dem Consumerbereich aufzuzeichnen. Die Verarbeitung der so erstellten Videosequenz erfolgt dann getrennt davon auf dem PC. Dieses Szenario ermöglicht zwar die reproduzierbare Verarbeitung und Bewertung im Labor, beschränkt sie jedoch gleichzeitig auf die so aufgezeichneten Daten. ADAF hebt diese Einschränkung durch die Abstraktion der Datenquelle auf. Die Bereitstellung der Daten erfolgt für die einzelnen Verarbeitungsplugins sowohl bei Erfassung als auch bei Wiedergabe der Daten völlig transparent. Auf diese Weise bleibt die Verarbeitung der Daten durch diese Plugins von der Art der Bereitstellung unberührt. Der Fokus liegt auf den Daten, nicht auf ihrer Herkunft. Dies ermöglicht einerseits die Erprobung eines Systems im Labor und andererseits unter realen Bedingungen, z. B. bei einer Testfahrt, ohne das Applikationsprofil anpassen zu müssen. Dadurch wird sichergestellt, dass auftretende Fehler nicht durch eine fehlerhafte Änderung der Konfiguration hervorgerufen werden Erfassung von Sensordaten Die Erfassung von Sensordaten durch entsprechende Hardware erfolgt in ADAF im sog. Live- oder Capture-Modus. Die erfassten Daten können unmittelbar verarbeitet werden. Hierbei kann es sich um eine vollständige Applikation (z. B. eine Fahrspurerkennung während einer Testfahrt) als auch um ein reines Aufnahmeszenario handeln. 3 Jedes empfangene Datum wird durch den Plugingraphen verarbeitet. Werden Daten von mehreren Sensoren erfasst, so existieren mehrere Sensorthreads parallel. Bei einem direkten Aufruf des Plugingraphen durch die einzelnen Sensorthreads würden diese bzgl. des Zugriffs miteinander konkurrieren. Dies hätte mehrere Konsequenzen. Erstens würde die Verarbeitung des Datums im Sensorthread geschehen und somit in dieser Zeit eine weitere Erfassung von Sensordaten blockieren. Ist die Verarbeitung 3 Da die Aufnahme durch ein Plugin realisiert wurde, handelt es sich im Sinne von ADAF ebenfalls um eine Applikation (s. Abschnitt 6.4.3). 77

88 6 Die Entwicklungs- und Analyseumgebung ADAF Zeitstempel : Thread Abbildung 6.7: Serialisierung parallel erfasster Sensordaten in ADAF. Bei Übergabe der Daten an ADAF erhalten die Datenpakete einen globalen Zeitstempel. Ein separater Thread benachrichtigt die Plugins im Verarbeitungsgraphen über die Verfügbarkeit neuer Daten. im Vergleich zur Sensorfrequenz zu langsam, führt dies zu einem Datenverlust durch verworfene Datenpakete. Dieser Verlust tritt bereits auf Seite der Sensorhardware oder des Treibers auf und kann u. U. nicht durch ADAF erfasst werden. Zweitens erhöht die Möglichkeit des gleichzeitigen Aufrufs die Anforderungen an die Plugin- und Algorithmenentwickler stark, da sie die Zugriffe korrekt synchronisieren und serialisieren müssen. Da die Zugriffe durch die äußere Systemarchitektur von ADAF bedingt wären und nicht aus den Anforderungen des zu entwickelnden Algorihtmus entstehen, widerspricht dies dem Ziel, dass der Entwickler sich auf den Algorithmus selbst statt auf technische Details der umgebenden Komponenten konzentrieren können soll. Drittens ist die konsistente Reihenfolge der Datenpakete nicht garantiert. Durch das Scheduling des Betriebssystems können verschiedene Plugins die einzelnen Datenpakete in anderer Reihenfolge erhalten. Werden z. B. während einer Testfahrt Daten sofort verarbeitet und parallel auch für spätere Überprüfungen aufgezeichnet, so kann in diesem Fall nicht garantiert werden, dass die Reihenfolge der aufgezeichneten Daten der tatsächlichen Reihenfolge während der Verarbeitung entspricht. Dies widerspricht der Anforderung der Reproduzierbarkeit. Des Weiteren erhalten die Daten bei Eintritt in ADAF einen Zeitstempel. Als Abbildung der Realität ist die Monotonie der Zeitstempel wünschenswert. Besteht die Gefahr des Vertauschens der Pakete, kann sie jedoch gegenüber dem Plugin nicht garantiert werden, was zusätzlichen Aufwand für den Plugin-Entwickler verursacht. Um diese Probleme zu umgehen, setzt ADAF auf die in Abbildung 6.7 dargestellte Architektur. Die Verarbeitung der erfassten Daten wird von der eigentlichen Erfassung entkoppelt. Die Aufgabe der Sensorthreads reduziert sich auf die Übernahme der Daten vom Sensor und die Bereitstellung im ADAF. Die Daten werden bei Übergabe an ADAF an zentraler Stelle mit einem aktuellen Zeitstempel versehen und in einen FIFO-Puffer (First In, First Out) eingefügt. Ein separater Verarbeitungsthread entnimmt die Daten aus dem Puffer und aktiviert den Plugingraphen. Auf diese Weise werden die Datenpakete 78

89 6.4 Datenerfassung und -wiedergabe von allen Plugins in derselben Reihenfolge verarbeitet. Gleichzeitig entspricht diese Reihenfolge der Erfassungsreihenfolge. Hierbei ist zu beachten, dass diese sich auf die Erfassung im System, also in ADAF bezieht, nicht auf die physikalische Erfassung durch die Hardware (z. B. die Belichtung des Kamerasensors). Um eine solche externe Erfassungsreihenfolge zu erreichen, müssten bereits in der Sensorik global gültige Zeitstempel gesetzt werden, z. B. durch Kopplung auf Hardwareebene mit einer externen Uhr. Alternativ könnten die Zeitstempel nachträglich im PC korrigiert werden, um die physikalische Erfassungszeit zu berücksichtigen. Hierzu ist jedoch die Kenntnis der Latenzzeiten erforderlich. Diese umfassen im vorliegenden Fall die Dauer der Verarbeitung der Daten im Sensor sowie ihre Übertragung vom Sensor zum PC. Bei Verwendung eines herkömmlichen PCs und Betriebssystems können die Latenzzeiten nur eine Schätzung darstellen, da das Betriebssystem keine Möglichkeiten zur Garantie bereitstellt. Im Anschluss wäre bei beiden Verfahren eine nachträgliche Sortierung der Datenpakete erforderlich, um eine aufsteigende Reihenfolge der Zeitstempel zu gewährleisten. Aus funktioneller Sicht ist die Unterscheidung des Zeitstempel-Zeitpunkts jedoch nachrangig. Wichtiger ist die Sicherstellung einer konsistenten und reproduzierbaren Reihenfolge der Daten. Daher verwendet ADAF zur Bestimmung der Reihenfolge den Zeitpunkt der Verfügbarkeit eines Datums im System. Auf einem Multiprozessorsystem ist es im Prinzip möglich, dass zwei Datenpakete von unterschiedlichen Sensoren zum exakt gleichen Zeitpunkt erfasst werden. Dieser Sonderfall wird durch die vorgeschlagene Architektur unterdrückt. Die explizite Serialisierung der Datenpakete erleichtert die Verarbeitung der Daten im Plugin, da der Entwickler keine gesonderten Synchronisations- und Ausschlussmechanismen verwenden muss, um kritische Abschnitte vor konkurrierenden Zugriffen zu schützen. Ist ein Plugin auf Daten von zwei oder mehr Sensoren angewiesen, liegt es in der Verantwortung des Plugins, die jeweiligen Daten zwischenzuspeichern, bis alle zur Verarbeitung benötigten Informationen verfügbar sind. ADAF macht keine Annahmen über die Daten und deren Verarbeitung durch ein Plugin. Nur das jeweilige Plugin kennt die Bedeutung der Daten und kann eine geeignete Pufferstrategie implementieren. Als Beispiel sei ein LDW-Algorithmus angenommen, der in 2D-Kamerabildern die Fahrbahnmarkierungen detektiert und basierend darauf die aktuelle Fahrspur schätzt. Zusätzlich nutze dieser Algorithmus Fahrzeugzustandsdaten wie den aktuellen Lenkwinkel, Blinkerstatus, und die aktuelle Geschwindigkeit, die über den CAN-Bus bereitgestellt werden. Die Kamera arbeite mit 25 Bildern pro Sekunde, die CAN-Botschaften zu Lenkwinkel und Geschwindigkeit stünden mit 15 Hz zur Verfügung, der Blinkerstatus nur bei Aktivierung des Blinkers. Wird ein Blinkersignal erfasst, wie lange wird es berücksichtigt, um bei einem Spurwechsel in die angezeigte Richtung eine Spurverlassenswarnung zu unterdrücken? Kann der Lenkwinkel direkt im Modell berücksichtigt werden und wenn ja, kann er unabhängig von bildabhängigen Informationen wie der Lage der Fahrspur im Bild berücksichtigt werden oder ist dies nur in der Gesamtheit möglich? Geschieht dieses Update des Modells bei Verfügbarkeit der CAN-Bus-Daten, der Bilddaten oder bei beiden? Werden die jeweils fehlenden Informationen durch veraltete Informationen ergänzt oder werden sie ggf. extrapoliert? Das Beispiel zeigt, dass die Bedeutung und auch 79

90 6 Die Entwicklungs- und Analyseumgebung ADAF die zeitliche Gültigkeit von Informationen nur durch das jeweilige Verfahren bestimmt werden können Aufzeichnung von Sensordaten Die modulbasierte Architektur von ADAF und die oben vorgestellte Erfassung der Sensordaten ermöglichen die Realisierung der Aufnahmefunktion auf Pluginebene. Die Aufnahme von Sensordaten wird also genauso als Applikation realisiert wie ein Spurerkennungssystem oder eine Verkehrszeichenerkennung. Aus Sicht von ADAF unterscheiden sich diese Applikationen nicht. Da die Entwicklung und Pflege leistungsfähiger Dateiformate sehr aufwendig ist, verwendet das realisierte Aufnahmeplugin das von der HDF Group entwickelte, offene Dateiformat HDF 5 (Hierarchical Data Format). Es findet breite Anwendung in vielen Bereichen 4, u. a. auch in Luft- und Raumfahrt (z. B. bei Boeing 5 und der NASA 6 ). HDF 5 ist ein binäres Containerformat, dass die Speicherung beliebiger Datentypen erlaubt. Die Daten können hierarchisch geordnet und gruppiert sowie mit Metadaten ergänzt werden. Die Größe der speicherbaren Daten ist nicht begrenzt. Diese Eigenschaft ist bei der Erhebung von Sensordaten zur Entwicklung und Bewertung von Fahrerassistenzsystemen, insbesondere bei der Verwendung von einer oder mehreren Kameras, von zentraler Bedeutung. Die Realisierung der Aufnahme durch ein Plugin macht auch diese Funktion durch den Nutzer an seine Bedürfnisse anpassbar. Bei Bedarf kann durch Implementierung eigener Plugins in beliebige Dateiformate gespeichert werden. Zusätzlich zur Aufnahme kann das verwendete Applikationsprofil um verarbeitende Plugins ergänzt werden. Dadurch ist es möglich, auch während einer Testfahrt gleichzeitig die Sensordaten für spätere Analysen aufgetretener Fehler zu speichern. Bei dieser Vorgehensweise ist allerdings sicherzustellen, dass die Gesamtverarbeitungszeit der zusätzlichen Plugins den Echtzeitanforderungen des Live-Betriebs gerecht wird. Daher wird besonders in frühen Entwicklungsphasen empfohlen, die Aufzeichnung isoliert durchzuführen, um Beeinträchtigungen durch fehlerbehaftete oder zu langsame Verarbeitungsplugins zu vermeiden. ADAF selbst erforderte keine gesonderte Anpassung, um die Aufnahme zu ermöglichen. Lediglich aus Gründen des Bedienkomforts stellt die Benutzeroberfläche einige Elemente zentral zur Verfügung, sobald mindestens ein Plugin mit Aufnahmefähigkeit geladen ist. Hierzu zählen Bedienelemente zum Starten und Beenden der Aufnahme sowie eine Anzeige der Aufzeichnungsdauer Wiedergabe aufgezeichneter Daten Aufgrund der im vorherigen Abschnitt beschriebenen Architektur, die während der Aufnahme verwendetet wird, gestaltet sich die Wiedergabe deutlich einfacher. Die Datenpakete werden seriell gelesen und in ADAF verarbeitet (s. Abbildung 6.8). Der Zugriff erfolgt

91 6.4 Datenerfassung und -wiedergabe Sequenz (Datei) Zeitstempelprüfung... : Thread Abbildung 6.8: Verarbeitung von aufgezeichneten Datenpaketen. Die Datenpakete werden seriell verarbeitet. Durch Berücksichtigung des Zeitstempels entsprechen Ausführungsreihenfolge und (relative) Verarbeitungszeitpunkte der Situation während der Aufzeichnung. indexbasiert. Standardmäßig erfolgt die Wiedergabe in Originalgeschwindigkeit, soweit die Gesamtverarbeitungszeit der verwendeten Plugins dies zulässt. Dazu wird während der Wiedergabe der Zeitstempel des aktuellen Datenpaketes ausgewertet und die Zielzeit berechnet, also die Zeit, zu der das Paket in einem Capture-Szenario auftreten würde. Erst zu diesem Zeitpunkt wird das Paket zur Verarbeitung freigegeben. Gegebenenfalls wird die Verarbeitung entsprechend lange verzögert. Bei einer zu hohen Verarbeitungsdauer des vorherigen Datenpakets ist die Zielzeit des aktuellen Datenpakets u. U. bereits überschritten. In diesem Fall wird es unverzüglich durch den Plugingraphen verarbeitet. Übliche Ursachen hierfür sind fehlende Echtzeitfähigkeit der geladenen Applikation bzw. zu hohe Frequenz der Daten. Während der unüberwachten, automatisierten Verarbeitung ist eine Wiedergabe in Originalgeschwindigkeit nicht notwendig. Im Gegenteil, eine möglichst hohe Verarbeitungsgeschwindigkeit ist wünschenswert, um große Datenmengen in möglichst kurzer Zeit verarbeiten zu können. Dies ist ein entscheidender Aspekt, wenn mehrere hundert Stunden Datenaufzeichnungen verarbeitet werden sollen. Daher ermöglicht ADAF durch Konfiguration eines Wiedergabemultiplikator die Wiedergabe in erhöhter Geschwindigkeit. Das gewählte Datenformat HDF 5 ermöglicht den in Abschnitt geforderten wahlfreien Zugriff. Dies erlaubt während der Fehleranalyse den direkten Zugriff auf den problematischen Abschnitt. Es erlaubt Tests auf Teilmengen der Daten, bei denen gezielt nur einzelne Streckenabschnitte mit bestimmten Eigenschaften verarbeitet werden. Für die Annotation ist wahlfreier Zugriff zwingend notwendig. Nur durch die Fähigkeit, auf annotierte Objekte gezielt zuzugreifen wird ein flexibler Arbeitsfluss ermöglicht, der außerdem die Kontrolle und Korrektur von Annotationsfehlern erlaubt (s. Abschnitt 6.5). Gruppen von Sequenzen können in sog. Sequenzlisten gespeichert und verwaltet werden. Durch Definition von Start- und End-Indizes ist es auch möglich, die Wiedergabe auf bestimmte Teilabschnitte einer Sequenz zu beschränken. Enthält eine Sequenz Daten unterschiedlicher Sensoren, werden aber nur die Daten 81

92 6 Die Entwicklungs- und Analyseumgebung ADAF eines einzelnen Sensors (z. B. einer Kamera) für die Verarbeitung benötigt, erlaubt ADAF die Einschränkung der Wiedergabe auf diesen Sensor. Dies reduziert die I/O-Last je nach Sequenz bzw. der Anzahl und Art aufgezeichneter Sensoren signifikant, da nur ein Bruchteil der Daten von der Festplatte geladen werden muss. Die Wiedergabe aufgezeichneter Daten beschränkt sich nicht auf solche, die mit Hilfe von ADAF und im HDF 5-Format aufgezeichnet wurden. Durch Implementierung von eigenen Dateiformatsplugins (s. Abschnitt ) können durch den Nutzer weitere Formate in ADAF integriert werden. 6.5 Annotation Die Annotation von Daten ist essenziell zur Erzeugung von Referenzdaten (ground truth). Wie in Abschnitt 4.5 ausgeführt, können Referenzdaten für synthethische Daten in höchster Präzision durch das Simulationssystem zur Verfügung gestellt werden. Für Realdaten lassen sich einige Attribute ggf. aus den Daten selbst gewinnen. GPS-Daten geben z. B. Auskunft über das Land, in dem eine Fahrt durchgeführt wurde. Durch spezielle Zusatzsensorik (z. B. hochgenaues DGPS oder ein auf dem Dach installierter Lidarsensor) oder durch Verwendung präzise vermessener Teststrecken lässt sich dieser Anteil u. U. erhöhen. Dieses Vorgehen ist jedoch einerseits sehr aufwendig, andererseits können damit nicht alle Anwendungsszenarien abgedeckt werden. Für Klassifikationsprobleme ist beispielsweise zusätzlich zur exakten Position und den Ausmaßen eines Objektes im Bild auch die zugehörige Klasse des Objektes, z. B. der konkrete Typ eines Verkehrsschilds, zu erfassen. Daher ist im Allgemeinen eine manuelle Annotation der relevanten Merkmale notwendig. Die Annotationsfunktionalität wird in ADAF wie auch die Aufnahme (s. Abschnitt 6.4.3) durch verschiedene Plugins bereitgestellt. Soweit möglich, wird auf vorhandene Plugins zurückgegriffen. Dazu zählen einerseits grundsätzlich die Sensorplugins und ein Anzeigeplugin (2D Display-Plugin). Je nach Bedarf können weitere Plugins, z. B. für eine Vorverarbeitung oder Aufbereitung der Sensordaten, ergänzt werden Definition der Attribute Welche Attribute zur Evaluierung eines Systems benötigt werden, ist vollständig applikations- und somit auch spezifikationsabhängig. Seitens ADAF bzw. der Annotationsplugins werden daher keine Vorgaben gemacht. Es werden verschiedene Typen von Attributen zur Verfügung gestellt. Der Kunde bzw. Anwender erstellt dann daraus eine Konfiguration, die seinen Ansprüchen genügt. Die Erstellung einer Konfiguration erfolgt in einem XML-Dialekt (Extended Markup Language). Der Wurzelknoten PropertyDefinition enthält eine Liste der Attribute als Abfolge von Property-Einträgen. Das Beispiel in Abbildung 6.9 zeigt die Konfiguration für zwei Attribute. Tabelle 6.1 führt alle zur Auswahl stehenden Attributstypen auf. Für die Definition eines Attributs stehen die in Tabelle 6.2 aufgeführten Parameter zur Verfügung. Typabhängige 82

93 6.5 Annotation <PropertyDefinition> <Property name="fahrzeugtyp" type="exclusiveenumeration" mandatory="yes"> <Values> <Value>Pkw</Value> <Value>Motorrad</Value> <Value>LKW</Value> <Value>Bus</Value> <Value>Sonstiges</Value> </Values> </Property> <Property name="kommentar" type="string" /> <!-- weitere Attributsdefinitionen nach Bedarf --> </PropertyDefinition> Abbildung 6.9: Definition von zwei Annotationsattributen in XML Tabelle 6.1: Verfügbare Attributstypen zur Annotation Typ Number Integer Boolean String ExclusiveEnumeration Wert Fließkommazahl Ganzzahl Wahr/Falsch Zeichenkette Liste von Zeichenketten, aus denen eine ausgewählt werden kann. Tabelle 6.2: Konfigurationsmöglichkeiten für Annotationattribute. Die kursiv gedruckten Felder sind verpflichtend. Die Spalte Art gibt an, ob es sich um ein XML-Attribut (A) oder einen Kindknoten (K) handelt. Name Bedeutung Gültig für Art name Bezeichnung des Attributs alle A type Typ des Attributs alle A mandatory Gibt an, ob dieses Attribut verpflichtend ist alle A default Vorgabe für einen Standardwert des Attributs alle A Minimum Untere Grenze des Wertebereichs Number, Integer K Maximum Obere Grenze des Werteberegichs Number, Integer K Values Liste der möglichen Zeichenketten ExclusiveEnumeration K 83

94 6 Die Entwicklungs- und Analyseumgebung ADAF Parameter sind dabei als XML-Unterknoten modelliert, generische als XML-Attribute. Einige Parameter Name, Typ und bei Aufzählungsattributen auch die Liste der verfügbaren Werte sind obligatorisch, die weiteren sind optional. Der Name eines Attributs muss eindeutig sein, da er zur Speicherung des Attributs in der Datenbank verwendet wird. Zusätzlich dient er zur Anzeige auf der grafischen Benutzeroberfläche. Der Typ des Attributs bestimmt die Eingabemaske. Wenn mandatory aktiviert ist, ist die Zuweisung des Attributs für den Nutzer verpflichtend. Zusätzlich wird das Attribut farblich grün bzw. rot hervorgehoben. Bei Vorgabe eines Standardwerts wird dieser automatisch zugewiesen und kann bei Bedarf vom Nutzer geändert werden. Dies reduziert den Annotationsaufwand, wenn ein Attribut nur in Ausnahmefällen abweicht. Für numerische Attribute kann der Wertebereich durch Definition einer unteren und/oder oberen Grenze beschränkt werden, um so die Eingabe ungültiger Werte zu unterbinden Ebenen der Annotation ADAF unterscheidet prinzipiell die drei in Abschnitt erläuterten Ebenen der Annotation: global, intervallbasiert und objektbasiert. Dabei steigt der notwendige Aufwand von einer Ebene zur nächsten deutlich an. Je nach Situation und Anwendungsfall sind nicht alle Ebenen notwendig. Für jede Annotationsebene steht ein eigenes Plugin zur Verfügung. Für alle Annotationsplugins gilt, dass die verwendete Datenbankstruktur mit der Attributsdefinition übereinstimmen muss. Sie werden in der Regel in Verbindung mit Plugins zur Visualisierung der Sensordaten verwendet, um eine Sichtung der Daten zu ermöglichen Global Die grafische Oberfläche für die globale Annotation besteht aus einer Liste der definierten Attribute, sodass diese komfortabel editiert und gespeichert werden können (s. Abbildung 6.10). Beim Öffnen einer Sequenz werden die Attribute sofern für diese Sequenz bereits vorhanden automatisch aus der Datenbank geladen. Die Konfiguration der Datenbankverbindung sowie die Auswahl einer Attributdefinition erfolgt durch die Konfigurationsoptionen des Plugins (s. Abschnitt ). Abbildung 6.10: Benutzeroberfläche des globalen Annotationsplugins 84

95 6.5 Annotation Abbildung 6.11: Benutzeroberfläche des intervallbasierten Annotationsplugins Intervall Die Benutzeroberfläche zur Intervallannotation bietet ähnlich einer Videobearbeitung einen Zeitstrahl, auf dem die definierten Attribute als einzelne Spuren angelegt sind (s. Abbildung 6.11). Grundsätzlich ist jedem Attribut über die vollständige Sequenz ein Wert zugewiesen. Initial entspricht also jedes Attribut einem Intervall über die gesamte Sequenzlänge. Das Plugin bietet weitreichende Bearbeitungsfunktionen für diese Intervalle. Sie können beliebig geteilt, zusammengeführt oder verschoben werden. Jedem Intervall kann individuell ein Wert für das zugehörige Attribut zugewiesen werden. Zusätzlich zu den Attributen wird die aktuelle Position in der Sequenz durch einen Positionsanzeiger (Cursor) markiert (die rote Linie in Abbildung 6.11). Die Intervallannotation ist mit der Visualisierung der Sensordaten so synchronisiert, dass jeweils die der Cursorposition entsprechenden Sensordaten dargestellt werden. Der Cursor kann durch den Benutzer verschoben werden und erlaubt so gezielte Sprünge innerhalb der Datei (z. B. zum Beginn oder Ende eines annotierten Intervalls) und die interaktive Manipulation der Intervalle (Verschieben von Intervallgrenzen, Aufteilen oder Zusammenführen von Intervallen). Zur Kontrolle der Intervallgrenzen können auch gezielt die Daten eines einzelnen Intervalls wiedergegeben und ggf. verarbeitet werden. Dazu ist der in Abschnitt geforderte wahlfreie Zugriff auf die Eingabedaten fundamental und wird bei Verwendung des Standarddateiformats HDF 5 (s. Abschnitt 6.4.3) von ADAF gewährleistet. Die Konfiguration des Plugins erfolgt analog zur globalen Annotation über die Plugin Properties sowie die relevante Attributsdefinition. Die Attributszuweisungen werden in einer Datenbank gespeichert Objekte Das Plugin zur Objektannotation arbeitet bildbasiert. Es können daher alle Daten annotiert werden, die als Bild repräsentierbar sind. Dazu zählen nicht nur Kamerabilder, sondern beispielsweise auch Projektionen dreidimensionaler Informationen wie z. B. eines Lidar- Scans. Die Annotation von Größe und Position der Objekte erfolgt (auch im letzteren Fall) in Bildkoordinaten. Zum selben Objekt gehörende Markierungen (Region of Interest, ROI) in aufeinanderfolgenden Datenpaketen werden in einem Track zusammengefasst. 85

96 6 Die Entwicklungs- und Analyseumgebung ADAF Das Objektannotationsplugin beschränkt sich auf rechteckige Markierungen. Diese bieten mehrere Vorteile: Sie sind sehr leicht zu erstellen und zu bearbeiten. Ein Benutzer kann sie mit Maus und Tastatur intuitiv erstellen, verschieben oder in der Größe verändern, sodass sie das relevante Objekt präzise markieren. Sie sind leicht und mit konstantem Datenaufwand zu repräsentieren entweder durch zwei Punkte oder durch einen Punkt und die Ausmaße. Beliebige Polygone würden je nach Objekt aus unterschiedlich vielen Punkten bestehen und dadurch die kompakte Speicherung in der Datenbank erschweren. Der markierte Bereich lässt sich als Bildausschnitt gut weiterverarbeiten. Für beliebig geformte Objekte entspricht sie dem umgebenden Rechteck (Bounding Box). Der Umriss eines Objektes kann sich im Trackverlauf durch Perspektivänderungen oder Bewegungen des Objekts (z. B. Fußgänger) ändern. Eine rechteckige Markierung lässt sich in diesem Fall mit sehr wenig Aufwand durch Skalierung und Verschiebung anpassen. Im Gegensatz dazu müssen für ein beliebiges Polygon u. U. einzelen Punkte verschoben, hinzugefügt oder entfernt werden. Die Verwendung der Bounding Box als ROI stellt in der Regel nur eine Annäherung an den echten Umriss eines Objektes dar. In vielen Szenarien werden die echten Umrisse jedoch nicht benötigt oder erweisen sich ggf. sogar als störend. Sollen z. B. für eine Fahrzeugdetektion unterschiedliche Fahrzeugtypen wie Pkw, Lkw oder Motorrad annotiert werden, so unterscheiden sich diese nicht nur zwischen den Klassen, sondern durch verschiedene Marken und Modelle auch innerhalb einer Klasse. Die Annotation der exakten Bauform würde die Dimensionalität des Problems stark erhöhen und somit das Problem unnötig verkomplizieren. In der Praxis haben sich rechteckige Markierungen als praktikabel und ausreichend erwiesen. Damit bilden sie einen sehr guten Kompromiss zwischen der Genauigkeit der Annotation und dem benötigten Aufwand. Abbildung 6.12 zeigt beispielhaft eine objektbasierte Annotation, bei der zur Erhöhung der Annotationsgenauigkeit Bild- und Lidardaten parallel annotiert werden. Je nach Objekt, Szene, Witterungsverhältnissen und verwendeter Sensortechnologie sind die relevanten Objekte unterschiedlich gut zu erkennen. Die Visualisierung und die Annotation sind dabei derart gekoppelt, dass Änderungen der ROI automatisch zwischen beiden Ansichten synchronisiert werden. Die Konfiguration des Objektannotiationsplugins erfolgt analog zur globalen und intervallbasierten Annotation. Weiterhin werden analog zu diesen Plugins beim Öffnen einer Sequenz bereits vorhanden Annotationsdaten automatisch geladen Methoden der Objektannotation Da die objektbasierte Annotation die aufwendigste der drei Betrachtungsebenen ist, soll im Folgenden näher auf deren konkrete Umsetzung eingegangen werden. Grundsätzlich gilt, dass die Annotation in Verbindung mit einem 2D-Display-Plugin zur Anzeige der 86

97 6.5 Annotation Abbildung 6.12: Objektbasierte Annotation von Fahrzeugen mit synchronisierten Sensordaten von Kamera (links) und Lidar (rechts). Oben rechts sind die einzelnen Tracks und die enthaltenen ROIs aufgeführt. Darunter (rechts Mitte) können die Attribute der aktuell ausgewählte ROI bearbeitet werden. Bilddaten erfolgt. Dazu registriert das Annotationsplugin die zur Annotation notwendigen Werkzeuge beim Displayplugin, sodass die Markierung der Objektposition direkt auf Basis der visualisierten Sensordaten erfolgen kann Grundfunktion In der Regel ist ein Objekt nicht nur in einem einzelnen Bild sichtbar, sondern in einer Folge von Bildern. Daher wird zunächst für ein neu zu annotierendes Objekt ein Track erstellt, der alle aufeinander folgenden Annotationen dieses Objekts aufnimmt. Das Objekt wird im Bild mit einem Rechteck als ROI markiert. Dabei wird üblicherweise die Bounding Box des Objektes verwendet. Abhängig von der Applikation und der geplanten Bewertung können auch größere oder kleinere Markierungen relevant sein. Es wird allerdings empfohlen, diese nach Möglichkeit aus der exakten Bounding Box zu berechnen, da sich letztere in der Regel präziser annotieren lässt. Einzelne ROIs können nachträglich beliebig manipuliert werden, sowohl in Größe als auch Position. Dabei wird stets die aktuelle Größe und das Seitenverhältnis angezeigt. Die Steuerung erfolgt dabei kombiniert mit Maus und Tastatur, was eine effiziente, exakte Bearbeitung ermöglicht. Einer neu erstellten ROI werden automatisch die vorgegebenen Attribute zugewiesen, sodass sie anschließend vom Benutzer bearbeitet werden können. Die Annotation erfolgt auf Einzelbildern. Der Benutzer kann schrittweise vorwärts und rückwärts durch die Datensequenz navigieren oder gezielt zu einem bestimmten Index springen. 87

98 6 Die Entwicklungs- und Analyseumgebung ADAF Trackergestützte manuelle Annotation Bewegt sich das annotierte Objekt relativ zur Kamera ändert es seine Größe sowie seine Position von Bild zu Bild. Ob und welche Attribute sich ändern, hängt von der jeweiligen Annotationskonfiguration ab. In der Regel ändern sich nur einzelne Attribute, während der größere Teil gleich bleibt. Die Fahrzeugklasse und Farbe eines vorausfahrenden Fahrzeugs ändern sich nicht, während sich z. B. die Zuordnung zum Fahrstreifen des Aufnahmefahrzeugs durch einen Spurwechsel eines der beiden Fahrzeuge ändern kann. Neben den Attributen ändert sich auch das Aussehen eines Objekts in aufeinanderfolgenden Bildern in der Regel nur begrenzt. Die Copy-on-Click-Funktion vermeidet ein wiederholtes Setzen identischer Attribute sowie die manuelle Markierung des Objekts in jedem Einzelbild. Ausgehend von einer initial erstellten ROI für ein Objekt gemäß des vorherigen Abschnitts, gestaltet sich der Annotationsprozess grundsätzlich wie folgt: 1. Beim Weiterschalten zum nächsten Bild wird automatisch die aktuelle ROI, die zugehörigen Attribute sowie der enthaltene Bildausschnitt kopiert. 2. Durch Mausklick oder Tastendruck fügt der Benutzer diese ROI inklusive der Attribute im aktuellen Bild ein. 3. Ein integriertes Trackingverfahren auf Basis der normalisierten Kreuzkorrelation versucht den Ausschnitt des vorherigen Bildes im aktuellen Bild zu lokalisieren. Dabei können in vielen Fällen durch relative Bewegung zur Kamera verursachte Größenänderungen des Objekts berücksichtigt werden. 4. Position und Größe der eingefügten ROI werden basierend auf dem Trackingergebnis angepasst. 5. Der Benutzer korrigiert eine ungenaue oder fehlerhafte Platzierung der ROI durch intuitive Tastatur- und Mauskommandos. 6. Der Benutzer passt bei Bedarf einzelne Attribute an. Die Schritte werden wiederholt, bis das Objekt vollständig annotiert ist. Dies umfasst üblicherweise den Zeitraum, in dem das Objekt im Bild zu sehen ist, kann aber applikationsabhängig auch variieren. Die schrittweise Annotation aller Einzelbilder gewährleistet eine hohe Qualität und Präzision der erzeugten Referenzdaten. Durch das manuelle Einfügen der ROI in die relevanten Bilder und der direkten Korrekturmöglichkeit ist der Benutzer stets aktiv in den Annotationsprozess involviert. Da die Zahl der zu annotierenden Objekte und Einzelbilder in der Regel sehr groß ist, besteht die Möglichkeit, zwischen den Schritten 1 und 2 mehrere Bilder zu überspringen. Sobald die ROI in das aktuelle Bild eingefügt wird, werden durch lineare Interpolation ROIs für alle übersprungenen Bilder erzeugt. Dabei werden auch nachträgliche Korrekturen durch den Benutzer gemäß Schritt 4 für alle automatisch eingefügten ROIs anteilig 88

99 6.6 Integration von Algorithmik berücksichtigt. Dies führt zu einer deutlichen Effizienzsteigerung des Annotationsprozesses, da die Zahl der zu annotierenden Einzelbilder insbesondere für statische oder sich linear bewegende Objekte deutlich reduziert wird. In Abschnitt 7.2 wird gezeigt, wie mit Hilfe von ADAF ein innovatives Verfahren zur Automatisierung der Objektannotation realisiert werden konnte, welches den benötigten Arbeitsaufwand deutlich reduziert Zugriff auf Annotationsdaten Sämtliche Annotationsdaten werden in einer SQL-Datenbank abgelegt. Innerhalb von ADAF werden die Annotationsdaten beim Öffnen einer Sequenz automatisch durch die entsprechenden Annotationsplugins abgerufen. Während der Wiedergabe und Verarbeitung der Sequenz werden sie anderen Plugins jeweils über einen Ausgabepin zur Verfügung gestellt. Die globalen Daten bleiben konstant und stehen in jedem Verarbeitungsschritt zur Verfügung. Bei intervallbasierten Daten werden für jedes Datenpaket die Annotationen für alle Intervalle ausgegeben, die für diesen Index gültig sind. Dabei werden sie um die Information ergänzt, ob es sich um den Beginn, die Mitte oder das Ende des Intervalls handelt, um nachfolgenden Plugins eine einfachere Behandlung von Intervallgrenzen zu ermöglichen. Für objektbasierte Annotationen werden in jedem Schritt die Informationen zu sämtlichen zu diesem Index annotierten Objekten ausgegeben. Die Datenhaltung in einer SQL-Datenbank ermöglicht den direkten Zugriff auf Annotationsdaten über SQL-Abfragen. Dies ist hilfreich, wenn ADAF nicht für alle Entwicklungsschritte eingesetzt wird, da es die Interoperabilität mit anderen Werkzeugen gewährleistet. 6.6 Integration von Algorithmik Ziel der Modularität von ADAF ist die Möglichkeit, neue Algorithmen und neue Funktionalität mit wenig Aufwand einbinden zu können. Für Neu- und Weiterentwicklungen ermöglicht ADAF den Entwicklern, den Fokus auf den Algorithmus zu richten, da die Bereitstellung der Eingabedaten, die Visualisierung der Ergebnisse und Konfiguration von Parametern durch das Framework oder weitere, bereits vorhandene Plugins erfolgt. Design und Entwicklung des Algorithmus sind dabei unabhängig von ADAF. Ein Plugin dient lediglich als Adapter zwischen der frei definierbaren Schnittstelle des Algorithmus und den Schnittstellen von ADAF (s. Abbildung 6.13). Dies ist wichtig, um die Verwendung ADAF Plugin Algorithmus Abbildung 6.13: Plugin als Adapter zwischen den Schnittstellen von ADAF und Algorithmus 89

100 6 Die Entwicklungs- und Analyseumgebung ADAF ADAF FEreignis Benachrichtigung Plugin E/A-Pins FDaten FDaten Properties FParameter FParameter OptionaleFSchnittstellenFundFDienste Logging Plotting CustomFUI... Algorithmus/Sensor? Abbildung 6.14: Wichtige Schnittstellen von ADAF und Plugin. Gelbe Boxen repräsentieren einzelne Schnittstellen. des Algorithmus nicht auf das Framework zu beschränken, sondern eine unabhängige Nutzung zu ermöglichen. Dazu ist eine von ADAF unabhängige Schnittstelle notwendig. Im Umkehrschluss bedeutet dies, das auf dieselbe Art und Weise bereits implementierte Algorithmen als Plugin in ADAF eingebunden werden können entweder um sie mit Hilfe von ADAF zu bewerten oder um sie mit anderen Algorithmen zu kombinieren und ggf. deren Entwicklung zu vereinfachen. Die Einbindung eigener und die Anpassung vorhandener Funktionalität betrifft alle Anwendungsbereiche. Die Einbindung neuer Sensoren, Dateiformate, Algorithmen, Annotationsverfahren, Bewertungen, Visualisierungen und Aufzeichnungs- und Exportfunktionen erfolgt jeweils über Plugins und bietet so eine hohe Flexibilität bei der Lösung neuer Aufgaben und Probleme Schnittstellen eines Plugins Ein Plugin dient im Regelfall als Adapter zwischen den Schnittstellen von ADAF und einer Funktionsbibliothek (Algorithmus, Sensorzugriff,... ). Ausnahmen betreffen Plugins, die ihre Funktion nur im Rahmen von ADAF und des zugehörigen Entwicklungsbaukastens bereitstellen. In diesem Fall wird die Funktion häufig direkt innerhalb des Plugins implementiert (z. B. zur Visualisierung). Zur Verwendung in ADAF muss ein Verarbeitungsplugin prinzipiell drei Schnittstellen berücksichtigen (s. Abbildung 6.14): zur Ereignisbenachrichtigung, zur Bereitstellung von Ein- und/oder Ausgabepins zur Verbindung mit anderen Plugins sowie zur Bereitstellung von Properties zur Parametrierung. Für alle drei Schnittstellen ist die triviale Implementierung (keine Reaktion auf Ereignisse, keine Eingabe- und/oder Ausgabepins, keine Properties) erlaubt. Über die Benachrichtigungsschnittstelle informiert ADAF das Plugin über eingetretene Ereignisse. Ausführliche Informationen zur Benachrichtigung von Plugins finden sich in Abschnitt Die Eingabe- und Ausgabepins dienen dem Datenaustausch. Über sie stellt ADAF Eingabedaten bereit und nimmt die Ergebnisdaten entgegen. Anhand der Pins ermöglicht 90

101 6.6 Integration von Algorithmik ADAF dem Benutzer die grafische Verknüpfung von Plugins zu einer Verarbeitungskette bzw. Applikation (s. Abschnitt 6.3.1). Sie definieren, woher die Eingabedaten stammen und wie Ergebnisse weiterverarbeitet werden. Die durch die Verbindungen definierten Abhängigkeiten steuern die Benachrichtigungs- und Ausführungsreihenfolge bei Eintritt eines Ereignisses (s. Abschnitt 6.3.3). Die über einen Pin ausgetauschten Datentypen können vom Entwickler frei definiert werden. Dies gewährt dem Entwickler den notwendigen Freiraum, eine auf das zu lösende Problem zugeschnittene Repräsentation der Daten zu verwenden. Dabei kann es sich um Einzelwerte als auch um benutzerdefinierte Kompositdatentypen handeln. Die Verwendung von benutzerdefinierten Datentypen ermöglicht die konsistente Weitergabe zusammengehöriger Daten (z. B. longitudinale und laterale GPS-Position oder Dimensionen, Pixelformat und Rohdaten eines Bildes) und reduziert die Anzahl der benötigten Pins. Dies verringert den nötigen Aufwand sowohl für den Entwickler, der die Pins programmseitig berücksichtigen muss, als auch den Anwender, der eine korrekte Konfiguration der Verbindungen sicherstellen muss. Die reduzierte Anzahl von Pluginverbindungen führt zu einer größeren Übersichtlichkeit und Klarheit des Datenflusses sowie der Abhängigkeiten der Plugins auf der Benutzeroberfläche. Bei der Wahl der Datentypen ist u. U. die Kompatibilität mit anderen Plugins in der Verarbeitungskette zu berücksichtigen, da nur Pins gleichen Datentyps miteinander verbunden werden können. 7 Die Bereitstellung von Properties erlaubt eine dynamische Konfiguration des Plugins bzw. Algorithmus (s. Abschnitt ). Sie werden von ADAF auf der Benutzeroberfläche dargestellt und dienen als Schnittstelle zum Anwender. Vorgenommene Einstellungen können durch ADAF im Rahmen der Konfigurationsverwaltung gespeichert und zu einem späteren Zeitpunkt erneut geladen werden Zugriff auf Funktionalität in ADAF Ein wesentlicher Aspekt beim Entwurf von ADAF ist die zentrale Bereitstellung allgemeiner Funktionalität, die durch die Plugins genutzt werden kann. Hierzu zählen beispielsweise die Ausgabe von Statusmeldungen (Logging), das Zeichnen von Ergebnissen, das Erzeugen von Diagrammen zur Visualisierung von Zeitreihen oder die Bereitstellung pluginspezifischer Bedienelemente auf der grafischen Oberfläche. Zugriff auf diese Funktionen erhalten die Plugins während der Instanziierung durch sog. Dependency Injection [Fow04]. Hierbei wird einem Plugin eine Schnittstelle übergeben, über die es wiederum gewünschte Funktionalität bei ADAF anfragen und dadurch ggf. Zugriff auf die jeweilige spezifische Schnittstelle erlangen kann. Die Verfügbarkeit der Zusatzfunktionen wird jedoch durch ADAF nicht garantiert. Das Plugin muss daher ein mögliches Fehlen berücksichtigen. Beispiele hierfür sind das Unterlassen von Informationsausgaben wie das Zeichnen von Ergebnissen, das Erzeugen von Diagrammen zur Visualisierung von Zeitreihen oder die Ausgabe von Statusmeldungen. Die Optionalität 7 Bei Verwendung von Fremdplugins ist es auch möglich Plugins zur Konvertierung von Datentypen zu verwenden. 91

102 6 Die Entwicklungs- und Analyseumgebung ADAF ermöglicht den Einsatz der Plugins auch in einer potenziell funktionsreduzierten Version von ADAF, z. B. einer nicht-interaktiven Ausführungsversion ohne grafische Oberfläche Reaktion auf Ereignisse Plugins werden durch ADAF über alle eingetretenen Ereignisse benachrichtigt. Ein Ereignis besteht mindestens aus dem Ereignistyp, kann aber abhängig davon weitere Informationen enthalten. Dabei handelt es sich um Metainformationen zum Ereignis. Für das Ereignis NEW_DATA_PACKAGE sind dies u. a. der aktuelle Zeitstempel sowie der absolute und relative Index des aktuellen Datenpakets. Die zu verarbeitenden Daten werden bei Ausführung jedes Ereignisses über die Pinverbindungen zwischen den Plugins weitergereicht und an den Eingabepins des benachrichtigten Plugins zur Verfügung gestellt. Gemäß des in Abschnitt erläuterten Designziels Flexibilität, liegt es in der Verantwortung bzw. Freiheit des Pluginentwicklers, ob und wie auf ein Ereignis reagiert werden soll. ADAF stellt keine Anforderungen, wie ein bestimmtes Ereignis zu verarbeiten ist. Das Framework erhält und benötigt keine Information darüber, welche Ereignisse ein Plugin verarbeitet. Tabelle 6.3 auf der nächsten Seite stellt die wichtigsten Ereignisse kurz vor. Für jedes Ereignis werden verfügbare Eingabedaten die Ausgaben der mit den Eingabepins verbundenen Plugins bereitgestellt, das Plugin benachrichtigt und anschließend gegebenenfalls erzeugte und an den Ausgabepins bereitgestellte Ergebnisse an alle verbundenen Plugins weitergeleitet. Sowohl die Gültigkeit der bereitgestellten Daten als auch der exklusive Zugriff wird für die Dauer der Benachrichtigung und ihrer Verarbeitung garantiert. Das erleichtert die Pluginentwicklung, da Synchronisationsaufwand auf Seite des Plugins entfällt. Diese Garantie bleibt auch bei einer zukünftig möglichen simultanen Benachrichtigung aller Plugins innerhalb einer Zeitscheibe erhalten, da das Scheduling garantiert, dass diese Plugins untereinander unabhängig sind (s. Abschnitt 6.3.3) und keine Daten untereinander austauschen. Da Plugins nicht verpflichtet sind, für jedes verarbeitete Ereignis Ergebnisdaten bereitzustellen, kann ADAF nicht garantieren, dass an den Eingabepins Daten verfügbar sind. Dies zu berücksichtigen liegt in der Verantwortung des Entwicklers. Das Plugin muss selbst prüfen, ob abhängig von dem aktuellen Zustand und der Konfiguration die zur Verarbeitung des Ereignisses notwendigen Daten verfügbar sind und welche Maßnahmen durchzuführen sind, falls dies nicht der Fall ist (z. B. Ignorieren des Ereignisses, Signalisieren eines Fehlers oder Zwischenspeichern der verfügbaren Daten zur späteren Verarbeitung) Verarbeitung von Daten mehrerer Sensoren Nachdem die grundlegenden Aspekte der Datenverarbeitung in ADAF in den vorangegangenen Abschnitten unter verschiedenen Gesichtspunkten betrachtet und erläutert wurden, sollen sie im Folgenden anhand eines Beispiels illustriert werden. Dazu wird zunächst 92

103 6.6 Integration von Algorithmik Tabelle 6.3: Übersicht über die wichtigsten Ereignisse Name NEW_DATA_PACKAGE NEW_DATA_SOURCE END_DATA_SOURCE NEW_PLAYLIST END_PLAYLIST SAVE_SETTINGS LOAD_SETTINGS Description Dieses Ereignis wird ausgelöst, sobald ein neues Datum im System verfügbar ist. Das Datum kann von einem verbundenen Sensor oder aus einer aufgezeichneten Sequenz stammen. Eine neue Sequenz wurde geöffnet. Dieses Ereignis ermöglicht es einem Plugin, notwendige Initialisierungsschritte auszuführen. Die Sequenz wurde vollständig wiedergegeben. Dieses Ereignis ermöglicht eine abschließende Berechnung oder Verarbeitung von Ergebnissen, die sich auf die Gesamtsequenz anstatt auf einzelne Datenpakete beziehen, oder die Durchführung von Aufräumaufgaben (Schließen intern geöffneter Dateien, Speicherfreigabe). Dieses Ereignis ist vergleichbar mit NEW_DATA_SOURCE, bezieht sich allerdings auf eine gesamte Wiedergabeliste. Dieses Ereignis ist vergleichbar mit END_DATA_SOURCE, bezieht sich allerdings auf eine gesamte Wiedergabeliste. Es ermöglicht die Generierung von Gesamtergebnissen über eine umfangreiche Datenbasis oder durch wiederholte Wiedergabe der ganzen Sequenzliste auch iterative Prozesse wie evolutionäre Optimierung oder andere maschinelle Lernverfahren. Aufforderung an das Plugin, alle relevanten Parameter und Konfigurationseinstellungen zu speichern. Aufforderung an das Plugin, die Konfiguration zu laden. das theoretische, in Abbildung 6.15a dargestellte System betrachtet, dass die aktuell gültige Geschwindigkeitsbegrenzung bestimmt und anzeigt. Es gleicht die Ergebnisse einer kamerabasierten Verkehrszeichenerkennung mit positionsabhängigen Informationen aus Kartendaten ab und löst Widersprüche zwischen den beiden Informationsquellen adäquat auf. Der Fahrer wird über eine Anzeige über die aktuell zulässige Höchstgeschwindigkeit informiert. Die beiden verwendeten Sensoren werden mit unterschiedlicher Frequenz betrieben. Während die Kamera 25 Bilder pro Sekunde erfasst, erfolgt die Positionsbestimmung durch den GPS-Sensor lediglich einmal pro Sekunde. Der GPS-Sensor stellt also deutlich seltener Daten zur Verfügung als die Kamera. Somit entspricht die Konfiguration dem in den Anforderungen an das Framework formulierten Fall 2 in Tabelle 5.1 auf Seite 56. Gemäß Abschnitt 6.4 werden die Daten unterschiedlicher Sensoren entsprechend ihres Erfassungszeitpunkts im Framework in eine eindeutige Reihenfolge gebracht und anschlie- 93

104 6 Die Entwicklungs- und Analyseumgebung ADAF Kamera (AVTwGigEwVisionwSensor) TSR (TrafficwSignwRecognition) Geschwindigkeitsbegrenzung (SpeedwLimitwDecision) Anzeige (DashboardDisplay) GPS (GPSwSensor) Karteninformation (MapwAccess) (a) Der Plugingraph repräsentiert ein System zur Anzeige der aktuellen Geschwindigkeitsbegrenzung. Es basiert auf einer Verkehrszeichenerkennung, deren Ergebnisse mit positionsabhängigen Informationen aus Kartendaten kombiniert werden. Kamera (AVT GigE Vision Sensor) TSR (Traffic Sign Recognition) Geschwindigkeitsbegrenzung (Speed Limit Decision) Anzeige (DashboardDisplay) GPS (GPS Sensor) GPS_Filter (GPS Filter) Karteninformation (Map Access) (b) Erweiterung des Systems in (a) um ein Plugin zur Filterung der GPS-Position Abbildung 6.15: Verarbeitung von Daten mehrerer Sensoren ßend nacheinander der Verarbeitung zugeführt. Nachdem sie dem korrespondierenden Sensorplugin zugeordnet wurden, werden die einzelnen Plugins der Verarbeitungskette unter Berücksichtigung des Abhängigkeitsgraphen benachrichtigt. Bei Betrachtung des Systems in Abbildung 6.15a ergeben sich scheinbar zwei getrennte und unabhängige Verarbeitungspfade, die erst im Plugin Geschwindigkeitsbegrenzung zusammengeführt werden: und Kamera TSR Geschwindigkeitsbegrenzung Anzeige GPS Karteninformation Geschwindigkeitsbegrenzung Anzeige. Das Plugin Geschwindigkeitsbegrenzung erhält daher pro Benachrichtigung nur eine der beiden Informationen: entweder das Ergebnis der bildbasierten Verkehrszeichenerkennung oder, sehr viel seltener, die aus den Kartendaten bezogene aktuell zulässige Höchstgeschwindigkeit. Benötigt das von diesem Plugin implementierte Verfahren beide Informationen gleichzeitig, um eine Entscheidung zu treffen, muss es jeweils ein Datum zwischenspeichern. Bei Erhalt des fehlenden Datums können dann beide gemeinsam verarbeitet werden. Aufgrund der unterschiedlichen Sensorfrequenz stammen die Informationen jedoch von unterschiedlichen Zeitpunkten. Bei Verarbeitung eines Kamerabildes ist die letzte erhaltene Karteninformation u. U. bereits eine Sekunde alt. Es liegt in der Verantwortung des Plugins Geschwindigkeitsbegrenzung, die Zeitdifferenzen zwischen den Daten angemessen zu berücksichtigen, z. B. durch Extrapolation früherer Daten. Da es sich bei der aktuell zulässigen Höchstgeschwindigkeit jedoch nicht um eine kontinuierliche Größe handelt, ist dies in diesem Fall nicht ohne Weiteres möglich. Im Gegensatz 94

105 6.6 Integration von Algorithmik zur Karteninformation erlaubt die GPS-Position eine Extrapolation (z. B. mit Hilfe eines Kalman-Filters). Damit das Plugin Geschwindigkeitsbegrenzung diese Extrapolation durchführen kann, müsste es einerseits über einen Pin Zugriff auf die GPS-Position erhalten, andererseits aber auch selbst auf die Kartendaten zugreifen können, um basierend auf der gefilterten GPS-Position die aktuell erlaubte Höchstgeschwindigkeit abzurufen. Das Plugin Karteninformation-Plugin würde dadurch überflüssig. Während ein solcher Entwurf, der die genannte Funktionalität in einem einzelnen Plugin integriert, in ADAF ohne Weiteres möglich ist, widerspricht er dem Anspruch, dass sich der Entwickler eines Plugins auf die konkrete Problemstellung konzentrieren kann. Im vorliegenden Beispiel wäre für das Plugin Geschwindigkeitsbegrenzung zusätzlich zur Bestimmung der aktuell erlaubten Höchstgeschwindigkeit die Filterung der GPS- Position und der Zugriff auf Kartendaten erforderlich. Daher wird die Annahme, dass eine pfadabhängige Benachrichtigung der Plugins ausreichend ist, verworfen. Werden, wie in Abschnitt dargelegt, jeweils alle Plugins der Verarbeitungskette unabhängig vom Ursprung eines Datenpakets benachrichtigt, ermöglicht dies die gewünschte Funktionalität für das Beispielsystem auch unter Beibehaltung der Modularisierung. Die Filterung der GPS-Position wird hierzu in ein eigenes Plugin integriert, welches gemäß Abbildung 6.15b in die Applikation eingebunden wird. Die Plugins werden gemäß {Kamera, GPS} {TSR, GPS_Filter} Karteninformation Geschwindigkeitsbegrenzung Anzeige über das Eintreffen neuer Daten benachrichtigt, wobei {A, B} bedeutet, dass A und B derselben Zeitscheibe (s. Abschnitt 6.3.3) zugeordnet sind, da sie unabhängig voneinander sind. Für jede verfügbare GPS-Messung wird das interne Modell aktualisiert. Handelt es sich beim aktuellen Datenpaket um ein Kamerabild, stellt zwar das GPS Sensor-Plugin keine Daten zur Verfügung, das GPS Filter-Plugin ist jedoch in der Lage anhand des Zeitstempels des Datenpakets die aktuelle GPS-Position zu prädizieren. Dies ermöglicht es dem Kartendaten-Plugin, die korrespondierenden Informationen abzurufen. Dem Plugin Geschwindigkeitsbegrenzung können auf diese Weise im selben Verarbeitungsschritt aktuelle Informationen sowohl der Verkehrszeichenerkennung als auch aus den Kartendaten zur Verfügung gestellt werden. Dadurch kann sich der Entwickler dieses Plugins auf die Methode zur Zusammenführung der Information konzentrieren (z. B. welcher Information im Konfliktfall eher vertraut wird). Die in Abbildung 6.15b dargestellte Konfiguration des Systems ermöglicht zudem einen flexiblen Austausch des Filters sowie der Kartendaten durch die Verwendung alternativer Plugins. Das Plugin Geschwindigkeitsbegrenzung ist unabhängig von Kartendaten, da diese lediglich zur Bereitstellung von Informationen zur aktuell erlaubten Höchstgeschwindigkeit dienen. Dadurch kann das Plugin auch in anderen Applikationen verwendet werden, in denen diese Informationen beispielsweise durch einen alternativen Algorithmus zur Verkehrszeichenerkennung oder ein Simulationssystem bereitgestellt werden. Auch das GPS Filter- und das Kartendaten-Plugin können unabhängig vom betrachteten Beispielsystem weiterverwendet werden. 95

106 6 Die Entwicklungs- und Analyseumgebung ADAF 6.7 Bewertung Gemäß Abschnitt 3.1 beruht die Evaluierung auf der Bewertung der Systemleistung. Sie ermöglicht die Demonstration der Leistungsfähigkeit des verwendeten Verfahrens und den Vergleich mit alternativen Ansätzen. Sie beschränkt sich jedoch nicht auf die Abschlussbzw. vergleichende Bewertung des Gesamtsystems, sondern ist auch ein entwicklungsbegleitender Prozess. Im V-Modell bildet sie das Kernstück des rechten, aufsteigenden Astes, der die Integration von den kleinsten Funktionsblöcken (einzelne Klassen oder Softwaremodule) bis zum vollständigen System beschreibt (s. Abschnitt 3.3.4). Die Bewertung in ADAF erfolgt auf funktionaler Ebene und somit als Blackbox-Test. Die Testfälle basieren auf der Spezifikation der Anforderungen, nicht auf der konkreten Implementierung. Sie prüfen das nach außen sichtbare Verhalten der Applikation bzw. der zu testenden Komponente. Eine Berücksichtigung auf Quellcode-Ebene findet nicht statt. Zur Bestimmung der Codeüberdeckung in Bezug auf Anweisungen, Verzweigungen, Ausführungspfade oder Bedingungen sowie zur statischen Codeanalyse sei auf ein breites Spektrum bestehender freier und kommerzieller Software verwiesen. Die Bewertung eines Systems weist strukturelle Parallelen zur Entwicklung der eigentlichen Applikation auf. Die Gesamtkonfiguration ist problemspezifisch, die einzelnen Komponenten können jedoch sowohl problemspezifisch (z. B. Fahrspurerkennung), domänenspezifisch (z. B. Objekterkennung, Bildverarbeitung) als auch allgemein gültig (z. B. statistische Größen) sein. Die verwendeten Module sollen im Rahmen ihres Anwendungsbereichs wiederverwendbar sein und sich flexibel kombinieren lassen Bewertung durch Plugins Prinzipiell kann die Bewertung anhand von Plugins realisiert werden wie auch bereits die Aufnahme, Annotation und Funktionsentwicklung. In diesem Fall sind zunächst zwei Ansätze zu unterscheiden. Wird die vollständige Bewertung innerhalb eines einzelnen Plugins umgesetzt, so schränkt dies die Wiederverwendbarkeit stark ein, da die konkrete Zusammenstellung der verwendeten Güte- und Fehlermaße sowie die Eingabepins für die entsprechenden Eingangsgrößen applikationsspezifisch sind. Werden alternativ alle Fehler- und Gütemaße als individuelle Plugins implementiert, so ermöglicht dies eine variable Kombination und Verwendbarkeit. Allerdings erhöht sich dadurch je nach Komplexität der Bewertungskonfiguration die Anzahl der Plugins und Verbindungen in der Applikation deutlich. Dies reduziert die Übersichtlichkeit der Bedienoberfläche, insbesondere des Plugingraphen, und verringert den Bedienkomfort. Daher werden die Bewertungsmaße in ADAF zwar als einzelne Module realisiert, allerdings nicht als vollwertige Plugins, sondern als sog. Evaluatoren. Ihre Bedeutung wird im folgenden Abschnitt näher erläutert Bewertung durch Evaluatoren Die zur Bestimmung der Güte verwendeten Maße und Einzelberechnungen basieren auf einem geeigneten Vergleich der Ergebnis- und Referenzdaten und/oder der Bestimmung 96

107 6.7 Bewertung Abbildung 6.16: Einbindung und Konfiguration von Evaluatoren über das Evaluation-Plugin statistischer Eigenschaften dieser Größen (z. B. Mittelwert, Varianz). Sie haben in der Regel eine deutlich geringere Komplexität als das zu bewertende, datenverarbeitende System. Daher kann der Basisaufwand der Implementierung eines Verarbeitungsplugins im Vergleich zum Aufwand der Implementierung der eigentlichen Rechenvorschrift unverhältnismäßig sein. Manche Funktionalität, die für Verarbeitungsplugins verfügbar ist, wird zur Berechnung der Güte- und Fehlermaße nicht benötigt. Hierzu zählen z. B. die Bereitstellung einer eigenen Benutzeroberfläche oder die Visualisierung von Daten. Evaluatoren sind Module, deren Schnittstelle im Gegensatz zu allgemeinen Verarbeitungsplugins spezifisch auf die Bewertung ausgelegt ist. Dadurch wird einerseits die verfügbare Funktionalität beschränkt, gleichzeitig aber der erforderliche Aufwand zur Implementierung reduziert. Evaluatoren können ebenfalls beliebig viele Eingänge und Ergebnisse definieren, sind dabei aber auf die Verwendung eines spezifischen Datentyps, der in Abschnitt näher erläutert wird, beschränkt. Zusätzlich können sie durch Verwendung von Properties Parameter anbieten. Die Einbindung der Evaluatoren in ADAF erfolgt durch das Evaluation-Plugin. Es erlaubt die Verwendung einer beliebigen Anzahl von Evaluatoren und stellt für diese eine einheitliche Konfigurationsoberfläche zur Verfügung (s. Abbildung 6.16). Dort können die Ergebnis- und Referenzdaten den Evaluatoren als Eingabe zugeordnet und relevante Parameter konfiguriert werden. Wie auch Plugins können Evaluatoren dynamisch zur Laufzeit hinzugefügt oder entfernt werden. Evaluatoren innerhalb eines Evaluation-Plugins sind unabhängig voneinander, d. h., es werden keine Abhängigkeiten zwischen ihnen berücksichtigt. Die Kombination von Evaluatoren wird durch Verwendung zusätzlicher Evaluation-Plugins möglich. Auf diese Weise wird die Struktur der Evaluierung auch im Plugingraphen sichtbar während gleichzeitig die Konfiguration einzelner Evaluation-Plugins einfach bleibt. 97

108 6 Die Entwicklungs- und Analyseumgebung ADAF Datentyp für die Bewertung Das Evaluation-Plugin kann nicht für alle Eingänge aller von ihm verwalteten Evaluatoren individuelle Eingabepins bereitstellen. Dies würde die Übersichtlichkeit und Bedienbarkeit in ähnlichem Maße beeinträchtigen, wie die oben angesprochene Umsetzung von Bewertungsmaßen als einzelne Plugins. Verarbeiten mehrere Evaluatoren dasselbe Datum, wäre ein Teil dieser Eingabepins zudem redundant. Des Weiteren ist zu beachten, dass die Zahl der verfügbaren Ergebnis- und Referenzdaten sehr groß sein kann. Abhängig von der Konfiguration ist ihre Verfügbarkeit variabel. Dies würde entweder ein häufiges Hinzufügen und Anpassen der Pinverbindungen nötig machen, oder viele Pinverbindungen erfordern, um alle potenziell verfügbaren Ergebnisse zu berücksichtigen. Daher werden zur Weitergabe und Verarbeitung von Ergebnis- und Referenzdaten für die Bewertung zwei Konventionen eingeführt. 1. Alle relevanten Daten eines Plugins werden in einem Containerformat zusammengefasst und gemeinsam über einen einzelnen Pin ausgegeben. 2. Zur Vereinheitlichung der Anforderungen an die Evaluatoren wird ein gemeinsamer Datentyp namens GenericData für Ergebnis- und Referenzdaten eingeführt. Insbesondere der zweite Punkt entspricht der Anforderung in ADAF, dass Plugins, die Daten miteinander austauschen, kompatible Pins aufweisen müssen. Durch Vorgabe des Datentyps können die Evaluierungsmodule ohne Anpassungen in verschiedenen Projekten verwendet werden. Das zu bewertende System muss die Ergebnisse im entsprechenden Format bereitstellen. Dies stellt keine Einschränkung der bewertbaren Systeme dar, da die Bereitstellung im Rahmen der Integration in ein Plugin erfolgen kann. Die Möglichkeiten zur Bereitstellung weiterer Pins mit anwendungsspezifischen Datentypen werden durch diese Forderung nicht beeinträchtigt. Der Datentyp GenericData besteht aus drei Komponenten: einem eindeutigen Namen, den eigentlichen Ergebnis- oder Referenzdaten (Nutzdaten) und Zusatzinformationen (Metadaten). Die Evaluierung ist so ausgelegt, das sämtliche Ergebnis- und Referenzdaten in der Regel als Einzelwerte verarbeitet werden. Dadurch wird der Zugriff auf einzelne Größen gewährleistet Namensschema Um dem Benutzer eine Interpretation der einzelnen Werte zu ermöglichen, werden die Ergebnis- und Referenzdaten eindeutig bzgl. ihrer Quelle und ihrer Bedeutung benannt. Ein eindeutig benannter Wert wird im folgenden als Variable bezeichnet. Die Benennung folgt dabei dem Schema < Variablenname >::=< Bezeichner der Quelle >. < Bezeichner des Datums >; Für von Plugins bereitgestellte Variablen bezieht sich < Bezeichner der Quelle > auf den eindeutigen Bezeichner des Plugins. Der Bezeichner des Datums muss innerhalb des Plugins ebenfalls eindeutig sein. 98

109 6.7 Bewertung Für Evaluatoren besteht eine zweite Möglichkeit der Benennung. Alternativ zum beschriebenen Schema kann der Name einer Eingabevariable mit einem Zusatz ergänzt werden. So stellt z. B. der Mean and Variance-Evaluator für eine Eingangsvariable Lane- Detection.laneWidth die Ergebnisvariablen LaneDetection.laneWidth.mean und LaneDetection.laneWidth.variance zur Verfügung. Auf diese Weise lassen sich diese Ergebnisse direkt dem relevanten Wert zuordnen, ohne dass der Benutzer manuell eine konsistente Benennung sicherstellen muss. Verwendet ein Evaluator mehr als eine Eingangsvariable, wie z. B. der Mean Error-Evaluator zur Berechnung des mittleren absoluten und quadratischen Fehlers, so wird in der Regel der Name derjenigen Variable verwendet, die das zu bewertende Ergebnis repräsentiert. Der Name der Referenzvariable bleibt in diesem Fall unberücksichtigt. In Abbildung 6.16 ist dies beispielhaft dargestellt. Wird der Bezeichner einer Quelle oder eines Datums nachträglich verändert, so wird diese Änderung automatisch für die Variable übernommen, sodass die Benennung jederzeit konsistent ist Nutzdaten GenericData unterstützt drei Arten von Nutzdaten: Numerische Werte, Zeichenketten, sowie benutzerdefinierte Datentypen. Für numerische Werte bleibt die exakte Repräsentation erhalten, d. h. eine 32-Bit-Ganzzahl bleibt als solche ebenso erhalten wie eine 64-Bit-Fließkommazahl. Bei Bedarf ermöglicht der Datentyp dem Empfänger der Daten (z. B. einem Evaluator) die automatische Konvertierung. 8 Stellt z. B. ein Verarbeitungsplugin ein Ergebnis als Ganzzahl zur Verfügung, während ein Evaluator zur Berechnung des Mittelwerts als Eingabe eine Fließkommazahl benötigt, wird der Wert automatisch konvertiert, ohne dass der Evaluator dies explizit berücksichtigen muss. Dies stellt eine Erweiterung des allgemeinen Datenaustausches zwischen Plugins dar, der die exakte Übereinstimmung von Ausgabe- und Eingabedatentypen erfordert. Je nach Anwendungsfall sind einzelne numerische Werte zur Repräsentation eines Ergebnisses nicht ausreichend. Eine rechteckige ROI besteht z. B. aus mindestens vier Werten: entweder aus den Koordinaten zweier gegenüberliegender Ecken oder den Koordinaten des Mittelpunkts in Verbindung mit einer Breiten- und Höhenangabe. Daher unterstützt auch der Bewertungsdatentyp GenericData analog zu den Pinverbindungen frei vom ausgebenden Plugin definierbare Datentypen und ermöglicht so die Implementierung applikationsspezifischer Evaluatoren, z. B. zur Berechnung der Überdeckung zweier ROIs. Bei der Verwendung benutzerdefinierter Datentypen gilt allerdings die Einschränkung, dass der Empfänger diese explizit unterstützen muss, um sie verwenden zu können. Die vorhandenen Evaluatoren sowie zahlreichen Plugins zur Visualisierung und zum Export von Ergebnisdaten (s. Abschnitt 6.7.6) unterstützen benutzerdefinierte Datentypen nicht. 8 Dies schließt die Konvertierung von numerischen Werten in Zeichenketten mit ein. 99

110 6 Die Entwicklungs- und Analyseumgebung ADAF Metadaten Die Metadaten erlauben die Definition zusätzlicher Informationen über die Nutzdaten. Für numerische Werte kann der gültige Wertebereich definiert werden. Dies ermöglicht beispielsweise dem Plotter-Plugin (s. Abschnitt ) die automatische Skalierung des Diagramms. Repräsentiert der Wert eine Kategorie, wie z. B. eine Objektklasse, so lassen sich auch korrespondierende, menschenlesbare Bezeichner hinterlegen. Diese werden benötigt, um eine Zuordnung konfigurieren zu können, falls sich die Kategoriedefinitionen zu vergleichender Größen unterscheiden. Darauf wird im folgenden Abschnitt näher eingegangen Harmonisierung zu vergleichender Daten Die Evaluierung beruht im Allgemeinen auf dem geeigneten Vergleich von Ergebnis- und Referenzdaten. Dazu müssen die Daten in Einheit und Bezugssystem den Anforderungen des konkreten Evaluators gerecht werden. Für einen direkten Vergleich, z. B. unter Verwendung des Mean Error-Evaluators, müssen Ergebnis- und Referenzdaten dazu in der Regel in Einheit und Bezugssystem übereinstimmen. Ist dies nicht der Fall, ist eine entsprechende Harmonisierung der Daten notwendig (s. Abschnitt 5.7.4). Dabei empfiehlt es sich nach Möglichkeit, die Referenzdaten den Ergebnisdaten anzupassen statt umgekehrt. So wird vermieden, dass sich Fehler einzelner Ergebnisvariablen verstärken oder ausgleichen, wenn die Harmonisierung die Zusammenführung mehrerer Variablen erfordert. Da die Referenzdaten für die Bewertung ebenfalls als GenericData verfügbar sein müssen, eröffnet sich die Möglichkeit, Evaluatoren zur Harmonisierung zu verwenden. Der Basic Expression-Evaluator erlaubt z. B. die Erstellung mathematischer Ausdrücke mit bis zu vier Eingangsvariablen auf Basis der vier Grundrechenarten. Konstanten erlauben die Skalierung oder Verschiebung von Werten. Auch Variablen mit nominaler Skalierung, wie z. B. Objektklassen, lassen sich harmonisieren. Der Translate Categories-Evaluator erlaubt die Übersetzung der Kategorien einer Variable in die der zweiten Variable. Dazu ist es erforderlich, dass beiden Variablen in den Metadaten die möglichen Objektkategorien mit lesbaren Bezeichnern zugewiesen wurden. Diese werden auf der Benutzeroberfläche so dargestellt, dass der Nutzer die Kategorien einander zuordnen kann Auswertungsebenen Ähnlich der Annotation ist auch bei der Evaluierung die Berücksichtigung unterschiedlicher Detailebenen notwendig. Welche Ebenen konkret von einem Evaluator berücksichtigt werden, ist funktionsabhängig. Analog zu den Plugins liegt es in der Entscheidungsfreiheit des Entwicklers, unter welchen Umständen ein Evaluator eine Berechnung durchführt. Er legt fest, welche Eingabedaten erforderlich sind, wie mit nur teilweise verfügbaren Daten umzugehen ist und wann ein oder mehrere Ergebnisse ausgegeben werden. Folgende Detailebenen werden berücksichtigt: 100

111 6.7 Bewertung Pro Datenpaket Ergebnisdaten stehen in vielen Fällen pro Datenpaket zur Verfügung, was auch eine Verarbeitung auf dieser Ebene notwendig macht. Die ausgegebenen Ergebnisse können entweder punktuelle Berechnungen für dieses Datenpaket repräsentieren (wie z. B. der aktuelle Fehler einer Schätzung der Fahrspurbreite) oder den aktuellen Wert einer kontinuierlich berechneten Größe (z. B. Mittelwert). Pro Sequenz Diese Ebene ermöglicht die Ausgabe von aggregierten Ergebnissen nach Verarbeitung einer einzelnen Sequenz (z. B. mittlere Fehler, Anzahl der Fehldetektionen). Auf diese Weise lassen sich nach Abschluss einer automatisierten Bewertung problematische Sequenzen identifizieren. Pro Sequenzliste Die Ergebnisse auf dieser Ebene repräsentieren das Gesamtergebnis nach Verarbeitung aller ausgewählten Sequenzen. Die Ausgabe der Ergebnisse erfolgt in Abhängigkeit der korrespondierenden Plugin- Benachrichtigungen NEW_DATA_PACKAGE, END_DATA_SOURCE respektive END_PLAYLIST. Aggregierende Evaluatoren erhalten bei Beginn einer neuen Sequenz (NEW_DATA_SOURCE) bzw. Neustart der Sequenzliste (NEW_PLAYLIST) eine Benachrichtigung zur Reinitialisierung. Die Ergebnisse der verschiedenen Ebenen lassen sich mit Hilfe des Result Writer-Plugins exportieren (s.abschnitt ) Visualisierung und Weiterverarbeitung von Ergebnisdaten Das Evaluation-Plugin wird durch weitere Plugins ergänzt, die eine Begutachtung der Bewertungsergebnisse während der Verarbeitung sowie den Export zur Weiterverarbeitung in anderen Programmen erlauben. Während der automatisierten Bewertung ist eine Visualisierung in der Regel nicht notwendig. Da sich bei der Verarbeitung großer Datenbestände selbst der geringe zur Visualisierung notwendige Mehraufwand in der Gesamtzeit bemerkbar machen kann, sollte in diesem Fall von einer ausgiebigen Verwendung abgesehen werden. Zur Konfiguration der Evaluierung, zur Reproduktion und Analyse von Fehlern sowie zur interaktiven Kontrolle während der Entwicklung neuer Verfahren sind Darstellungs- und Inspektionsmöglichkeiten jedoch unverzichtbar. Im Folgenden werden die hierzu verfügbaren Plugins kurz vorgestellt Plotting von Zeitreihen Das Plotter-Plugin ermöglicht die Darstellung beliebiger numerischer Ergebnisse als Zeitreihendiagramm. Während jedes Plugin bereits die Möglichkeit hat, über die Plotting- Schnittstelle von ADAF eigene Diagramme zu erzeugen, ermöglicht das Plotter-Plugin eine gezielte Untersuchung relevanter Ergebnisdaten unabhängig vom spezifischen Funktionsumfang eines Plugins. Das Beispiel in Abbildung 6.17 zeigt den Vergleich der vom Assistenzsystem berechneten Kennzahl Lane offset (rot) mit dem korrespondierenden Referenzwert TRS.adapted_offset (grün). 101

112 6 Die Entwicklungs- und Analyseumgebung ADAF Abbildung 6.17: Darstellung von Ergebnissen als Zeitreihendiagramm durch das Plotter-Plugin Abbildung 6.18: Darstellung von Ergebnissen als Tabelle durch das Result Table Display-Plugin. Ergebnisse des letzten Verarbeitungsschritts sind grün markiert, ältere Ergebnisse rot. Variablen, die nicht mehr im System vorhanden sind, werden grau dargestellt Ergebnisanzeige Während die Darstellung von Ergebnissen als Zeitreihendiagramm einen Überblick über die Größenordnung und das zeitliche Verhalten (speziell im Vergleich zu anderen Größen) ermöglicht, ist besonders bei der Analyse auf Datenpaketebene also der manuell ausgelösten schrittweisen Verarbeitung und Beobachtung des Systemverhaltens der genaue Betrag einer Größe von Interesse. Das Result Table Display-Plugin stellt hierzu alle verfügbaren Ergebnisvariablen tabellarisch dar (s. Abbildung 6.18). Da abhängig von der spezifischen Konfiguration nicht in jedem Schritt jede Kennzahl berechnet wird (z. B. da Ergebnis A von Sensor 1 abhängt, Ergebnis B von Sensor 2), werden aktuelle Ergebnisse grün, ältere Ergebnisse rot markiert. Sollten Plugins durch Änderung der Konfiguration manche Variablen nicht weiter bereitstellen, werden diese weiterhin mit dem letzten bekannten Wert angezeigt, jedoch grau markiert. Dies ermöglicht es dem Nutzer, diese ggf. ungewünschte Konsequenz wahrzunehmen und darauf zu reagieren. Die veralteten 102

113 6.8 Gesamtbetrachtung Einträge bleiben temporär bis zum Schließen des Applikationsprofils erhalten. Um eine Überfüllung der grafischen Oberfläche mit veralteten Variablen zu verhindern, hat der Nutzer zudem die Möglichkeit, diese Einträge explizit zu entfernen Export von Ergebnissen Berechnete Ergebnisse können über das Result Writer-Plugin exportiert werden. Dies ermöglicht die Archivierung der Ergebnisse sowie deren Weiterverarbeitung in externen Programmen. Das dabei verwendete Dateiformat Comma-separated Values (CSV) ist weit verbreitet, erzeugt einen geringen Overhead in Erzeugung und Dateiumfang (verglichen z. B. mit XML) und ist auch von Menschen lesbar. Es ist individuell konfigurierbar, welche Ergebnisse exportiert werden sollen. Dabei wird nach den Auswertungsebenen differenziert. Je Sequenz wird eine Datei erzeugt, die die Ergebnisse auf Datenpaketebene inklusive Zeitstempel enthält. Für die gesamte Sequenzliste wird eine Übersichtsdatei erzeugt, die zum einen auf die Einzeldateien verweist, zum anderen die sequenzweisen Ergebnisse enthält Generierung von Sequenzlisten Nach automatischer Durchführung einer Bewertung ist zur Analyse von Fehlern ein gezielter Zugriff auf die entsprechenden Eingabedaten notwendig. Da Sequenzlisten die Definition von Start- und End-Indizes erlauben, ist ADAF in der Lage, einzelne Sequenzabschnitte gezielt wiederzugeben. Mit Hilfe des Plugins Sequence List Generator können anhand der Evaluierungsergebnisse entsprechende Sequenzlisten erzeugt werden. Der Alert-Evaluator erfasst beispielsweise die Grenzen der Intervalle, in denen eine bestimmte Bedingung, wie z. B. das Übertreten einer Fehlergrenze, erfüllt war. Wird das System bei der Fehleranalyse nur auf einem Ausschnitt der Daten ausgeführt, ist ggf. eine Einschwing- oder Initialisierungszeit zu berücksichtigen. Daher erlaubt das Sequence List Generator-Plugin die Erweiterung des Fehlerintervalls nach vorne um die dafür benötigte Länge (Lead-In). Um auch das Ende des problematischen Abschnitts und den Übergang in den gültigen Bereich untersuchen zu können, ist auch hier eine Erweiterung des Intervalls möglich (Lead-Out). Fehlerintervalle, die sich aufgrund des Lead-Ins und Lead-Outs überlappen, werden zu einem Intervall vereint, um so eine ganzheitliche Analyse des betroffenen Sequenzabschnitts zu ermöglichen. Sollen nur Intervalle einer bestimmten Mindestdauer berücksichtigt werden, werden kürzere Intervalle automatisch verworfen. Dadurch kann abhängig vom Anwendungsfall vermieden werden, dass sporadische Grenzwertüberschreitungen kurzer Dauer die Lokalisierung der problematischen Abschnitte erschweren. 6.8 Gesamtbetrachtung Nach der detaillierten Darstellung der Architektur von ADAF sowie der Realisierung der einzelnen Anforderungsbereiche soll der Blick zum Abschluss auf ADAF als Ganzes gerichtet werden. 103

114 6 Die Entwicklungs- und Analyseumgebung ADAF Aus dem Makromodell zur Systembewertung in Abschnitt 4.1 sowie der anschließenden Analyse der Anforderungen geht hervor, dass zur Bewertung eines Systems vier Kernaufgaben zu erfüllen sind. Dazu zählen die Erhebung von Sensordaten, die Erzeugung der korrespondierenden Referenzdaten, die Implementierung des Systems selbst sowie die Realisierung und Durchführung der eigentlichen Bewertung. Wie in den Abschnitten 6.4 bis Abschnitt 6.7 jeweils dargelegt, können diese Aufgaben innerhalb ADAF aufgrund der pluginbasierten Architektur als Applikationen realisiert werden. Dabei ist eine separate Bearbeitung der Aufgaben gemäß der jeweiligen konkreten Anforderungen eines Arbeitsbereichs (s. Abschnitt 5.2) möglich. Durch die gemeinsame Struktur ermöglicht ADAF die Erzeugung von Synergieeffekten, da sie die unmittelbare Verwendbarkeit der jeweiligen Erzeugnisse (Sensor- und Referenzdaten, Verarbeitungsmodule, Konfigurationen etc.) in nachfolgenden Arbeitsschritten und Iterationen ermöglicht. Auch die Zusammenführung der einzelnen Aufgabenbereiche wird dadurch möglich. Das Framework dient allgemein als Laufzeitumgebung für Plugins, unabhängig von ihrer konkreten Funktion. Das heißt, ADAF stellt verfügbare Eingabegrößen zur Verfügung, führt relevante Funktionen des Plugins aus, und nimmt Verarbeitungsergebnisse entgegen. Bei Verwendung mehrerer Plugins gewährleistet ADAF die korrekte Ausführungsreihenfolge gemäß der Datenabhängigkeiten. Durch Zusammenstellung von Plugins kann auch der Testrahmen, der in Abschnitt 5.4 als Laufzeitumgebung zur Bewertung eines Systems gefordert wurde, als Applikation in ADAF realisiert werden. Um dies zu verdeutlichen, werden in Abbildung 6.19 die einzelnen Plugins der bereits in Abschnitt auf Seite 73 vorgestellten Beispielanwendung den korrespondierenden Komponenten des Testrahmens zugeordnet. Die Testdaten definieren den Testfall bzw. die Testfälle. Im vorliegenden Beispiel werden sowohl die Eingabe- als auch die Referenzdaten durch das Simulationssystem TRS bereitgestellt, das in ADAF über ein Sensorplugin angesprochen wird. Daher bestimmt die Konfiguration von TRS den konkreten Testinhalt. Bei Verwendung aufgezeichneter Daten unterstützt ADAF die Bereitstellung der Testfälle durch Wiedergabe von ausgewählten Sequenzen und Sequenzabschnitten durch Definition einer Sequenzliste. Das Stereoverfahren repräsentiert das System unter Test bzw. das Testobjekt. Um das berechnete Disparitätsbild mit Hilfe von Evaluatoren und des Evaluation-Plugins vergleichen bzw. bewerten zu können, müssen auch die Referenzdaten zunächst harmonisiert werden. Anhand der vorliegenden Entfernungsinformationen je Pixel wird das korrespondierende Disparitätsbild 9 berechnet. Die Harmonisierung erfolgt in diesem Beispiel durch Plugins anstelle von Evaluatoren, um die Inspektion der Ergebnisbilder mit Hilfe der 2D-Display-Plugins (Monitore) zu erlauben. Die Protokollierung der Ergebnisse erfolgt durch das Result Writer-Plugin. Die Grundstruktur der Abhängigkeiten und Verarbeitungsreihenfolge entspricht denen des Testrahmens und somit denen des Makromodells. Die geforderte unabhängige Austauschbarkeit der Blöcke Daten, System und Bewertung ist gegeben, da die transparente Verarbeitung einen Wechsel der Datenquelle bzw. eines oder mehrerer Plugins erlaubt. 9 für die linke Kamera 104

115 6.9 Technische Realisierung Im vorliegenden Beispiel wird nur ein einzelnes System bewertet. ADAF ist jedoch nicht darauf beschränkt, sondern erlaubt die parallele Ausführung mehrerer Systeme im selben Verarbeitungsprozess. Dies ermöglicht in Benchmarking-Szenarien unmittelbar eine vergleichende Analyse der Ergebnisse. 6.9 Technische Realisierung Folgende Anforderungen wurden an die technische Realisierung gestellt: Hohe Performanz Hohe Ausführungsgeschwindigkeit und niedriger Speicherverbrauch Objekt-orientierter Entwurf und Programmierung Abstraktion der einzelnen Komponenten, um transparente Verwendung zu ermöglichen Plattformunabhängigkeit Lauffähigkeit unter Windows und Linux Diese Anforderungen werden durch die Verwendung der Programmiersprache C++ erfüllt. Viele Algorithmen im Bereich der Computer Vision und des maschinellen Lernens werden in C++ implementiert und können so ohne weiteres in die Verarbeitung mit ADAF integriert werden. Speziell im Bereich der Fahrerassistenzsysteme erfolgt die CameraEL (2DEDisplay) CameraER (2DEDisplay) Testobjekt StereoEDP (StereoEDPEPlugin) DepthEL (2DEDisplay) DepthER (2DEDisplay) TRS (TRSESensor) Disp.EfromEDepthEL (DisparityEfromEDepthEImage) Disp.EfromEDepthER (DisparityEfromEDepthEImage) Testfälle: Daten (Eingabedaten und Referenzdaten) DetermineEOcclusion (DetermineEOcclusion) Vergleich Evaluation (Evaluation) Disparity (2DEDisplay) DisparityEGT (2DEDisplay) Monitore ResultEWriter (ResultEWriter) Protokoll Abbildung 6.19: Realisierung des Testrahmens in Abbildung 5.1 durch Plugins. Die Zuordnung der Komponenten des Testrahmens (rot) erfolgt am Beispiel der Stereoapplikation aus Abschnitt

116 6 Die Entwicklungs- und Analyseumgebung ADAF Implementierung in der Regel in C. Auch durch Sensorhersteller bereitgestellte Bibliotheken bieten in der Regel eine C-Schnittstelle. Die Verwendung von C++ ermöglicht eine direkte Einbindung dieser Algorithmen und Bibliotheken. Viele Sprachen bieten zwar ebenfalls die Anbindung an C-Bibliotheken, erfordern dafür jedoch in der Regel spezielle Erweiterungen und Arbeitsschritte (z. B. SWIG 10, JNI). C++ ist eine statisch typisierte, kompilierte Sprache. Dies führt zum einen zu einer höheren Ausführungsgeschwindigkeit gegenüber interpretierten Sprachen und ermöglicht zum anderen die frühzeitige Entdeckung von Syntax- oder Typfehlern, die bei interpretierten Sprachen wie Python erst zum Ausführungszeitpunkt sichtbar werden. Des Weiteren bietet C++ eine deterministische Speicherverwaltung. Im Gegensatz zu Programmiersprachen mit einer automatischen Speicherbereinigung (Garbage Collection, GC) wie z. B. Java ermöglicht sie die eindeutige Kontrolle der Lebenszeit von Objekten und der Freigabe damit verbundener Ressourcen. Plugins werden als dynamische Bibliotheken (.dll (Windows) bzw..so (Linux)) realisiert und können somit unabhängig von ADAF entwickelt und zur Laufzeit ge- bzw. entladen werden. Sowohl zur Entwicklung der Plugins als auch von ADAF wurde auf CMake zurückgegriffen. CMake ermöglicht die Verwendung plattformunabhängiger Projektbeschreibungen, aus denen es native Projektdateien für die verwendete Entwicklungsumgebung generiert. Plattformabhängige Funktionalität wie Zugriffe auf das Dateisystem oder die Darstellung der grafischen Benutzeroberfläche werden durch Verwendung der umfangreichen Bibliothekssammlung Boost 11 sowie des Qt Frameworks 12 realisiert Fazit In diesem Kapitel wurde die Entwicklungs- und Analyseumgebung ADAF vorgestellt. Die Erfüllung der in Kapitel 4 und Kapitel 5 formulierten Anforderungen erfolgt in ADAF auf zwei Ebenen: einerseits durch das Framework selbst, anderseits durch die verwendeten Plugins. Das Framework stellt die grundlegenden Funktionen zur Realisierung und Bewertung von sensordatenverarbeitenden Systemen bereit. Dazu zählt die Bereitstellung der Daten (nicht deren Interpretation) sowie die Steuerung der Verarbeitung unter Berücksichtigung zeitlicher Abhängigkeiten. Dadurch gewährleistet ADAF die Wiederholbarkeit der Ausführung und somit die Reproduzierbarkeit von Ergebnissen. Die inhaltliche Interpretation und Berücksichtigung problem- und anwendungsspezifischer Anforderungen erfolgt durch Plugins. Durch Verknüpfung von Plugins zu einem Verarbeitungsgraphen ermöglicht ADAF die Partitionierung eines Problems in kleinere Teile. Dies erlaubt bei geeignetem Pluginentwurf die Wiederverwendung von Plugins in unterschiedlichen Projekten, da nur einzelne Plugins bzw. die konkrete Zusammenstellung und Konfiguration einer Menge von Plugins problemspezifisch sind. Auf diese Weise

117 6.10 Fazit erzeugt die Verwendung von ADAF als gemeinsame Arbeits- und Kommunikationsgrundlage Synergieeffekte, indem es redundanten Aufwand zur Entwicklung, zum Test und zum Erlernen der Bedienung mehrfach implementierter Funktionalität vermeidet. Die flexible und modulare Architektur von ADAF ermöglicht die integrierte Realisierung der Entwicklungsaufgaben Datenaufzeichnung, Annotation, Funktionsentwicklung und Evaluierung als Applikationen. Durch eigene Plugins kann neue Funktionalität ergänzt werden, wobei die modulare Architektur ihre zielgerichtete Entwicklung erlaubt. Die hohe Anpassbarkeit ermöglicht die Einbindung von ADAF in bereits vorhandene Arbeitsumgebungen. Die Teilbereiche sind unabhängig voneinander verwendbar und durch eigene Plugins individuell anpassbar. Dadurch wird auch die Einbettung von ADAF in eine vorhandene Werkzeuglandschaft und somit eine schrittweise Migration zur Verwendung von ADAF ermöglicht. 107

118

119 7 Anwendungsfälle In diesem Kapitel werden die unterschiedlichen Einsatzgebiete des ADAF durch konkrete Anwendungsbeispiele aus der Praxis illustriert. Diese zeigen auf, wie und warum die Verwendung von ADAF Mitarbeitern und Kunden der NISYS GmbH die Realisierung von Projekten ermöglicht hat. Der Schwerpunkt der Betrachtung liegt dabei auf der Verwendung von ADAF als Werkzeug im jeweiligen Problemkontext. Die inhaltliche Interpretation der Projekte und ihrer Ergebnisse ist nicht Teil dieser Arbeit. Die Bandbreite der Beispiele soll dazu dienen, die große Flexibilität des ADAF zu verdeutlichen. 7.1 Aufnahme bei hoher Datenrate und Sensordatenfusion Im Rahmen eines Projektes mit der Adam Opel AG wurde ADAF in der Vorausentwicklung eingesetzt. Ziel dieses Projekts war der Vergleich und die Bewertung unterschiedlicher Informationsquellen für Geschwindigkeitsbegrenzungen. Die verfügbaren Quellen umfassten: das Erkennungsergebnis der intelligenten Fahrzeugkamera OpelEye, das Navigationssystem NaviLink, alternatives, erweitertes Kartenmaterial mit vorausschauender Information (Electronic Horizon) über das ADASIS 1 -Protokoll, Fusion der Informationen aus Kartenmaterial und dem Erkennungsergebnis des OpelEye, manuell annotierte Referenzdaten. Zur Umsetzung dieses Projektes wurden grundsätzlich alle vier Arbeitsbereiche des ADAF eingesetzt: Datenerfassung, Annotation, Einbindung eines Algorithmus (in diesem Fall zur Fusion der Verkehrszeicheninformationen) und Bewertung. Einen Schwerpunkt der Unterstützung bildete jedoch die Aufnahme der Eingabedaten in einer komplexen Sensorkonfiguration. Die Bewertung erfolgte durch kundenseitige Plugins gemäß Abschnitt 6.7.1, da die von ADAF bereitgestellten Module zur Evaluierung (Plugins und Evaluatoren) zu diesem Zeitpunkt noch in einem frühen Entwicklungsstadium standen. 1 Advanced Driver Assistance Systems Interface Specification 109

120 7 Anwendungsfälle Aufnahmesituation Beim Versuchsträger handelte es sich um einen Opel Insignia Sports Tourer, in dem ADAF auf einem Industrie-PC mit zwei Sechs-Kern-Prozessoren als Aufnahmesystem zum Einsatz kam. Zur Datenspeicherung wurde ein externes RAID-5-System (Redundant Array of Independent Disks) verwendet. Diese Konfiguration bot zwei Eigenschaften, die für die Aufnahme im Fahrzeug wesentlich waren: Datenintegrität und Geschwindigkeit. Da die Festplatten im Fahrzeug durch die Vibration erhöhten mechanischen Belastungen ausgesetzt waren, bestand eine gesteigerte Ausfallwahrscheinlichkeit. Durch redundante Datenspeicherung gewährleistete das RAID-System die Datenintegrität auch bei Ausfall einzelner Festplatten. So wurde ein Datenverlust und eine kostenintensive Neuerfassung vermieden. Hohe Schreib- und Lesegeschwindigkeiten waren wichtig, da die Aufnahme der Sensordaten insbesondere durch die Verwendung von Kameras ein hohes Datenvolumen generierte. Dieses musste während der Aufnahme echtzeitfähig gespeichert und im Labor in möglichst kurzer Zeit auf einen zentralen Dateiserver überspielt werden können. Die Aufzeichnungskonfiguration umfasste folgende Sensorik: eine HD-Kamera AVT Prosilica GE1910C zur Aufzeichnung von Referenzdaten mit einer Auflösung von Pixeln und einer Bildrate von 30 fps. Die Kamera war an der Windschutzscheibe im Bereich des Innenspiegels installiert und per Gigabit-Ethernet angeschlossen. ein GPS-Empfänger Navilock NL-402U Receiver, angeschlossen per USB, zur Bereitstellung von Referenz-Positionsinformationen, drei Feldbusse (CAN) des Fahrzeugs mit unterschiedlichen Datenraten (33 kbaud, 125 kbaud und 500 kbaud), angeschlossen per cancard XL (PCI) der Firma Vector Informatik GmbH, ein rechner-interner CAN-Bus für vorausschauende Kartendaten nach ADASIS- Format (500 kbaud). Darüber hinaus war ursprünglich auch die Aufzeichnung der Daten eines ADMA-Systems mit externer GPS-Antenne vorgesehen, das über einen weiteren CAN-Bus (500 kbaud) angebundenen war. Dabei handelte es sich um ein Kreiselsystem der Genesys Elektronik GmbH zur Durchführung von Fahrdynamikmessungen, dass auch einen DGPS-Empfänger zur hochgenauen Positionsbestimmung integriert. Da sich im Rahmen der ersten Experimente jedoch herausgestellt hat, dass die Positionsinformationen des Standard-GPS ausreichend genau sind, wurde auf die weitere Nutzung dieses Sensors verzichtet. Bilddaten wurden nur mit der Referenzkamera aufgezeichnet. Von der fahrzeuginternen Kamera OpelEye wurden nur Metadaten sowie die Ergebnisdaten der Verkehrszeichenerkennung erfasst. Diese waren Teil der über CAN-Bus empfangenen Daten. Die Daten des fahrzeuginternen GPS-Empfängers wurden ebenfalls per CAN-Bus übertragen. Mit dieser Konfiguration wurden 50 Aufnahmen mit einer Gesamtlänge von ca. 100 Stunden aufgezeichnet. Die Gesamtdatenmenge beträgt ca. 62 TB. Bei einer angenommenen Durchschnittsgeschwindigkeit von 50 km/h entspricht dies einer Fahrleistung von 110

121 7.1 Aufnahme bei hoher Datenrate und Sensordatenfusion km. Das verdeutlicht, welche Datenmengen bereits im Rahmen eines Vorentwicklungsprojektes zur Bewertung eines Systems notwendig sind. Im Rahmen einer Serienentwicklung liegt diese Menge um ein Vielfaches höher. Das Szenario verdeutlicht die Wichtigkeit eines effizienten Frameworks, nicht nur in Bezug auf die Verarbeitungsgeschwindigkeit, sondern auch in Bezug auf die Speicherung der Daten und das verwendete Datenformat. Aufgrund der hohen Datenmengen wurden mechanische Laufwerke verwendet, da hier die Kosten pro GB sehr viel niedriger sind als für Solid-State-Festplatten (Solid State Disk, SSDs). Die steigende Verbreitung von SSDs führt jedoch zu stark sinkenden Preisen, sodass sie zukünftig als Alternative für magnetische Festplatten in Frage kommen. Besonders die höheren Datenraten und der Verzicht auf mechanische Bauteile sind dabei besonders vorteilhaft Annotation In diesem Projekt war primär die erkannte bzw. aktuell erlaubte Höchstgeschwindigkeit von Bedeutung, nicht die exakte Erkennung der Position des Verkehrszeichens im Bild. Da diese Information jeweils über einen Zeitabschnitt konstant ist, wurde die Annotation auf Intervallebene durchgeführt (s. Abschnitt ). Eine Geschwindigkeitsbegrenzung gilt erst ab dem entsprechenden Verkehrszeichen. Durch die vorwärtsgerichtete Kamera erfasst das Erkennungssystem das Verkehrszeichen bereits früher (bis zu 50 m). In dem Moment, in dem das Fahrzeug das Schild passiert und die Begrenzung gültig wird, liegt das Verkehrszeichen bereits außerhalb des Erfassungsbereichs. Die Annotation der Bilddaten erfolgte daher jeweils in Bezug auf das sichtbare Verkehrszeichen, nicht die aktuell gültige Geschwindigkeitsbegrenzung. 2 Zusätzlich wurden Informationen zu den Straßenverhältnissen (z. B. Baustelle, Straßenart, Anzahl der Spuren sowie aktuelle Spur des Fahrzeugs), sowie die Wetter- und Lichtverhältnisse annotiert. Sämtliche Annotationen wurden in einer SQL-Datenbank gespeichert Einbindung kundenspezifischer Plugins Sämtliche problemspezifischen Plugins wurden durch den Kunden selbst implementiert und erfolgreich in ADAF eingebunden. Sie umfassten eine Vorverarbeitung der CAN-Daten, die Implementierung eines Algorithmus zur Fusion der Geschwindigkeitsinformationen aus Kamera und Kartendaten, Bewertungsplugins sowie ein eigenes Visualisierungsmodul zur gleichzeitigen Anzeige der aus den unterschiedlichen Quellen stammenden Geschwindigkeitsinformationen Bewertungsszenario Die Bewertung erfolgte zweigeteilt. Ein Teil wurde in ADAF auf Basis der kundenseitig implementierten Plugins durchgeführt. Die Infrastruktur von ADAF ermöglichte dabei den transparenten Zugriff auf die benötigten Sensor-, Annotations- und Ergebnisdaten. 2 Diese ist aus den Bilddaten in der Regel auch nicht ersichtlich. 111

122 7 Anwendungsfälle Die Bewertungsergebnisse wurden in eine SQL-Datenbank exportiert, die außer zu Archivierungszwecken auch als Schnittstelle zu weiteren Bewertungswerkzeugen diente, und so ADAF in die vorhandene Infrastruktur integrierte Fazit Da es sich um ein internes Projekt der Adam Opel AG handelte, kann in der Beschreibung dieses Projektes nicht auf die genauen Details der Algorithmik und die Struktur der Bewertung eingegangen werden. Dennoch zeigt dieses Projekt, wie ADAF erfolgreich ein komplexes Aufzeichnungsszenario bewältigt hat. Der Kunde konnte die Funktionalität von ADAF erfolgreich durch eigene Plugins ergänzen und anpassen. Durch die transparente Bereitstellung und Visualisierung der Daten (Sensor-, Annotations- und Ergebnisdaten) in ADAF war es dem Kunden möglich, sich bei der Entwicklung dieser Plugins auf das jeweilige Teilproblem zu konzentrieren. Arbeitsergebnisse konnten durch Export in eine SQL-Datenbank erfolgreich außerhalb von ADAF weiterverwendet werden. 7.2 Automatisierung der Annotation Wie in Abschnitt 6.5 dargelegt, ist die manuelle Annotation zur Erzeugung von Referenzdaten sehr aufwendig. Dies trifft insbesondere auf die Annotation von Objekten in Bilddaten zu, da hierzu alle Daten auf hoher Detailebene (jedes einzelne Bild) gesichtet werden müssen. Speziell die Festlegung der Region of Interest(ROI)-Position erfordert hohe Präzision. Im Rahmen einer Masterarbeit [Ger11] konnte ein Konzept zur Automatisierung der Annotation erarbeitet und in ADAF als Applikation realisiert und bewertet werden. Dadurch konnte eine Beschleunigung der Annotation erreicht werden, ohne Einbußen der Qualität zu verursachen Konzept Als Grundlage des Verfahrens dient ein Algorithmus, der in der Lage ist, die relevanten Objekte im Bild zu lokalisieren und ggf. zu klassifizieren. Dabei kann es sich um den zu bewertenden Algorithmus selbst, eine frühe Entwicklungsversion davon oder ein alternatives Verfahren zur Erkennung der zu annotierenden Objekte handeln. Insbesondere können Methoden verwendet werden, deren Zeitanforderungen den Einsatz in Echtzeitsystemen nicht erfüllen. Die einzelnen Automatisierungsschritte sind in Abbildung 7.1 auf Seite 114 dargestellt. Zunächst werden mit Hilfe des Algorithmus in einem initialen Durchgang ROIs erzeugt und auch mit den entsprechenden Objektattributen versehen, soweit der Algorithmus diese Daten bereitstellen kann (in der Regel zumindest die Objektklasse). Diese ROIs sind zunächst unabhängig und werden noch nicht in Tracks je Objekt zusammengefasst (Abbildung 7.1a). Zu diesem Zeitpunkt ist es noch unerheblich, wenn relevante Objekte nicht in allen Bildern erfasst werden (z. B. aufgrund geringer Reife des verwendeten 112

123 7.2 Automatisierung der Annotation Algorithmus). 3 Im zweiten Schritt wird jede ROI soweit wie möglich vorwärts und rückwärts in der Sequenz getrackt. Wie weit genau, hängt von der Leistungsfähigkeit und Parametrierung des Trackers sowie der erfassten Situation ab. Alle resultierenden ROIs werden anschließend gemeinsam mit der initialen ROI zu einem Track zusammengefasst. Da ein Objekt in der Regel bereits durch die initiale Verarbeitung in aufeinanderfolgenden Bildern durch mehrere ROIs erfasst wurde, entstehen so für ein Objekt viele überlappende Tracks (Abbildung 7.1b) mit geringen Variationen der einzelnen ROIs. Anhand der zeitlichen und örtlichen Überlappung der Tracks sowie der zugewiesenen Objektklasse werden individuelle Objekte identifiziert und die entsprechend Tracks gruppiert (Abbildung 7.1c). Um einen einzigen Track je Objekt zu erhalten, werden anschließend alle Tracks einer Gruppe vereint, indem bildweise die ROIs gemittelt werden (Abbildung 7.1d) Realisierung in ADAF Auf Basis von ADAF war es möglich, das vorgestellte Konzept effizient und fokussiert umzusetzen. In Abbildung 7.1 ist jeweils auf der rechten Seite eine schematische Darstellung der verwendeten Applikationsprofile zu sehen. Darin ist farblich hervorgehoben, welche Komponenten bereits vorhanden waren und wiederverwendet werden konnten (ggf. mit Anpassungen) und welche mit Hilfe der verfügbaren Programmierschnittstellen neu erstellt und eingebunden wurden. Die abgebildeten Profile enthalten nur die zur Umsetzung des Konzepts unmittelbar relevanten Plugins. Die Visualisierung der Daten erfolgte durch ein bereits vorhandenes 2D Display-Plugin. Die Umsetzung wurde am Beispiel einer Verkehrszeichenerkennung demonstriert. Im ersten Schritt wurden sämtliche lokalisierten und erkannten Verkehrszeichen in der Datenbank gespeichert. Durch die Abstraktion der Datenquelle war es leicht möglich, unterschiedliche Daten für unterschiedliche Bewertungsszenarien zu verwenden. Über bereits vorhandene Sensorplugins erfolgte der Zugriff auf reale Kameradaten respektive von NISYS Traffic Simulation (TRS) erzeugte, synthetische Daten. Im zweiten Schritt wurden die Daten über die vorhandene Datenbankschnittstelle ausgelesen und die ROIs getrackt. Dazu war eine automatische Steuerung von ADAF aus dem Plugin heraus möglich, um gezielt innerhalb der Sequenz zu navigieren. Die Ergebnisse des Trackings wurden ebenfalls über die Datenbankschnittstelle gespeichert. Die Gruppierung und Zusammenführung der Tracks erfolgte allein anhand der Informationen in der Datenbank. Die Sensordaten wurden in diesem Fall nicht benötigt Bewertung Die Bewertung der Qualität der automatisch generierten Annotationen erfolgte anhand synthetischer und realer Daten. Für erstere wurden die Referenzdaten durch das vorhandene Sensorplugin, das die Verbindung zu NISYS TRS verwaltet, automatisch 3 Steht kein Algorithmus zur Verfügung, ist es prinzipiell auch möglich, als Ausgangsbasis vereinzelte ROIs eines Objekts manuell zu annotieren. Dieser Ansatz wurde in [Ger11] jedoch nicht weiter untersucht. 113

124 7 Anwendungsfälle (a) Initial: Unabhängige (Pseudo-)Tracks je automatisch detektierter ROI (b) Jede initiale ROI wird vorwärts und rückwärts in der Sequenz getrackt. (c) Gruppierung der Tracks basierend auf ihren Attributen sowie zeitlicher und örtlicher Überlappung (d) Zusammenfassung der gruppierten (Pseudo-)Tracks zu einem Track je Verkehrszeichen. Die Positionen zeitlich überlappender ROIs werden gemittelt. Abbildung 7.1: Automatisierte Annotation. Links: Konzept. Rechts: Schematische Darstellung der zugehörigen Applikationsprofile. Weiße Elemente wurden im Rahmen dieses Projekts neu implementiert, schraffierte Elemente modifiziert; graue Elemente waren vorhanden und konnten wiederverwendet werden. Abbildungen aus [Ger11]. 114

125 7.2 Automatisierung der Annotation (a) Schematisches Applikationsprofil (b) Benutzeroberfläche Abbildung 7.2: Kontrolle und Korrektur der Ergebnisse bereitgestellt. Für die realen Daten war eine manuelle Annotation notwendig, die gemäß der in Abschnitt erläuterten Grundfunktion durchgeführt wurde. Die Ergebnisse der automatisierten Annotation wurden in Bezug auf die Überlappung der ROIs, das Verhältnis ihrer Fläche sowie die mittleren Fehler der Position in x- und y-richtung bewertet. Für die detaillierten Ergebnisse sei auf [Ger11] verwiesen. Die Evaluierung der Annotationsgenauigkeit erfolgte in ADAF anhand eigens implementierter Plugins. Die in Abschnitt 6.7 vorgestellten Methoden zur Evaluierung befanden sich zum Zeitpunkt dieses Projekts noch in einem frühen Entwicklungsstadium und standen daher noch nicht zur Verfügung Manueller Kontrollaufwand Selbst bei einer hohen Güte des zur initialen Erkennung verwendeten Verfahrens müssen die automatisch erzeugten ROIs abschließend durch den Benutzer kontrolliert und bei Bedarf korrigiert werden, um die für die spätere Nutzbarkeit notwendige Qualität der Referenzdaten sicherzustellen. Hierzu stehen die in Abschnitt beschriebenen Methoden zur objektbasierten Annotation zur Verfügung. Zusätzlich ist es möglich, einzelne ROIs mit Hilfe der Trackingfunktionalität (wahlweise in eine oder beide Richtungen) zu einem Track zu expandieren. Die Korrektur- und Kontrollschritte benötigen daher keine zusätzlichen Plugins, sondern können mit den bereits verfügbaren Annotationswerkzeugen durchgeführt werden. Die automatisch erzeugten Annotationen sind aus funktionaler Sicht völlig mit manuell erzeugten ROIs identisch und können entsprechend visualisiert, manipuliert und korrigiert werden. Abbildung 7.2 zeigt das schematische Applikationsprofil sowie die Benutzeroberfläche zur Nachbearbeitung. Der für die Kontrolle und Korrektur benötigte Zeitaufwand ist laut den Untersuchungen in [Ger11] um Faktor drei kleiner, als der für die vollständig manuelle Annotation benötigte. Die Dauer der automatisiert durchgeführten Annotation wurde in diesem Vergleich nicht berücksichtigt, da sie keine personelle Überwachung während der Ausführung benötigte. 115

126 7 Anwendungsfälle (a) Kamerabild mit drei annotierten Objekten (b) Trajektorien der im linken Bild annotierten Objekte. Im der vergrößerten Ausschnitt ist deutlich eine Unterbrechung des roten Tracks zu erkennen. Abbildung 7.3: Visualisierung von Tracks als Trajektorie [Ger11] Ein Großteil der Annotationsfehler lässt sich bereits auf die initiale Detektion in Schritt 1 (Abbildung 7.1a) zurückführen. Fehlende oder fehlerhaft detektierte Objekte (ausgeprägte Positionsfehler oder falsches Objekt bzw. falscher Bildausschnitt) können den Korrekturaufwand in der Nachbearbeitung deutlich erhöhen. Hier ist eine Zwischenkontrolle nach Abschluss der initialen Detektion zu empfehlen, die mit identischer Konfiguration durchführbar ist. Fehldetektionen können entfernt, ROIs für nicht detektierte Objekte hinzugefügt werden. Für eine Vereinfachung der abschließenden Qualitätskontrolle schlägt [Ger11] eine dreidimensionale Visualisierung der einzelnen Tracks als Trajektorien vor. Anhand vorhandener Plugins zur Visualisierung von 3D-Daten konnte dieser Vorschlag mit geringem Aufwand prototypisch umgesetzt werden. Es war lediglich die Implementierung eines weiteren Plugins notwendig, dass die zweidimensionalen ROI-Positionen (x, y) anhand des zugehörigen Zeitstempels um eine z-koordinate ergänzte. Das Ergebnis ist beispielhaft in Abbildung 7.3 dargestellt Fazit Die durch ADAF bereitgestellte Infrastruktur hat es ermöglicht, innerhalb eines engen Zeitrahmens ein komplexes Konzept zur Automatisierung der Annotation von Objekten zu realisieren und den Nutzen durch eine quantitative Bewertung zu belegen. Durch die Wiederverwendbarkeit vorhandener Plugins für den Datenzugriff, die Verkehrszeichenerkennung, die manuelle Annotation und die Visualisierung von Kameradaten waren elementare Anforderungen bereits zu Projektbeginn erfüllt, sodass der Entwicklungsaufwand vollständig auf die vorliegende Problemstellung fokussiert werden konnte. Die Arbeit zeigt, dass ADAF durch Plugins umfangreich erweitert werden kann. Dies 116

127 7.3 Evaluierung einer Fahrspurerkennung umfasst auch die Automatisierung von Benutzeroperationen und die Steuerung von ADAF durch einzelne Plugins. Durch die modulare Auslegung der Annotation ist auch eine zukünftige Anpassung zielgerichtet möglich. Besonders wichtig ist dies in Bezug auf die Austauschbarkeit des zur initialen Detektion und Klassifikation verwendeten Verfahrens sowie des Trackingalgorithmus. 7.3 Evaluierung einer Fahrspurerkennung Im Folgenden werden die Bewertungsfunktionen des Frameworks anhand der Evaluierung eines Systems zur Fahrspurerkennung demonstriert System unter Test Dieser Abschnitt nutzt einen von der NISYS GmbH entwickelten Algorithmus zur Fahrspurerkennung und -verlassenswarnung. Das System liegt als Gesamtsystem in Form eines einzelnen Plugins zur Integration in ADAF vor. Das System verwendet ein rein bildbasiertes Verfahren. Fahrzeugzustandsdaten wie der aktuelle Lenkwinkel oder die Fahrzeuggeschwindigkeit werden nicht benötigt. Das System integriert mehrere Einzelschritte aus Punktsuche, Modellbildung und Kalman-Filterbasiertem Tracking. Die Erkennung der Fahrspur erfolgt anhand der gradientenbasierten Detektion der Fahrstreifenmarkierungen. Die Fahrspur wird über zwei Polynome 2. Grades modelliert, die die linke und rechte Fahrstreifenbegrenzung beschreiben und deren Parameter durch einen Kalman-Filter prädiziert werden. Die Ausgaben des Systems umfassen u. a. : eine Schätzung der aktuellen Spurbreite, eine Schätzung der Breiten der Fahrstreifenmarkierungen links und rechts, eine Schätzung der aktuellen horizontalen Spurkrümmung, eine Schätzung der normalisierten lateralen Position des Fahrzeugs innerhalb der Fahrspur (Spurablage), die Verfügbarkeit des Systems, also die Gültigkeit der aktuellen Ausgaben (binär), die Verfügbarkeit einer linken bzw. rechten Fahrspurmarkierung Einbindung des Systems in ADAF Das Spurerkennungssystem liegt als C-Bibliothek vor. Zur Einbindung in ADAF wurde diese Bibliothek in ein Plugin eingebunden. Das Plugin dient in erster Linie als Adapter zwischen den Schnittstellen von ADAF und der Bibliothek. Neben der Initialisierung des Algorithmus gewährleistet es vor allem die Weiterleitung der Eingabedaten an die Bibliothek und der Ergebnisse an ADAF. Das Plugin stellt hierzu entsprechende Einund Ausgabepins zur Verfügung. Wird das Plugin über die Verfügbarkeit neuer Daten 117

128 7 Anwendungsfälle Abbildung 7.4: Visualisierung der detektierten Fahrspur im Kamerabild. In gelb ist eine Kalibrierhilfe eingeblendet, die während der Konfiguration der Kameraparameter den daraus resultierenden Horizont und Fluchtpunkt visualisiert und so eine sofortige Überprüfung ermöglicht. informiert, ruft es die Verarbeitungsfunktion des Algorithmus mit diesen Daten auf. Nach Abschluss der Verarbeitung werden die Ergebnisse abgerufen und über Ausgabepins für nachfolgende Plugins bereitgestellt. Da das Spurerkennungssystem intern in Weltkoordinaten rechnet, werden zur Umrechnung zwischen Bild- und Weltkoordinaten die intrinsischen und extrinsischen Parameter der Kamera benötigt. Hierzu stellt das Plugin die nötigen Konfigurationsparameter auf der grafischen Oberfläche von ADAF zur Verfügung. Die direkte Visualisierung von Fluchtpunkt und Horizont im Kamerabild ermöglicht eine sofortige visuelle Kontrolle (s. Abbildung 7.4). Des Weiteren nutzt das Plugin die Möglichkeit, Algorithmenergebnisse grafisch darzustellen und in das Kamerabild einzublenden. Durch die Einbindung des Algorithmus in ein Plugin werden die bereitgestellten Parameter automatisch durch ADAF im Rahmen der Konfigurationsverwaltung gespeichert und wiederhergestellt Testdaten Die Annotation von Fahrspurdaten in Kamerabildern ist sehr aufwendig. Quantitative Attribute wie die Breite der Fahrspur oder der Markierungen sowie die aktuelle Spurkrümmung lassen sich entweder nur ungenau oder nur mit hohem Zusatzaufwand annotieren. Daher wird die vorgestellte Bewertung anhand von synthetischen Daten demonstriert, die mit dem Simulationssystem NISYS TRS generiert werden. Die generierte Teststrecke hat eine Länge von 500 km und wird mit einer konstanten Geschwindigkeit von 140 km/h befahren. Im Abstand von 2 km wechselt die Art des Fahrbahnbelags durch zufällige Auswahl aus zwölf verschiedenen Belägen. Die Textur des Seitenstreifens wechselt ebenfalls in diesem Abstand (drei Varianten). Zur späteren Fehleranalyse werden die Daten aufgezeichnet. 118

129 7.3 Evaluierung einer Fahrspurerkennung Harmonisierung der Referenzdaten Die vom Simulationssystem bereitgestellten Daten (sowohl Sensordaten als auch insbesondere die Referenzdaten) sind im Rahmen der Anwendungsdomäne generisch und nicht auf die Bewertung eines bestimmten Verfahrens ausgerichtet. Umgekehrt wurde auch der Algorithmus nicht in Hinblick auf das Simulationssystem entwickelt und das Ergebnisformat nicht an den dort verfügbaren Referenzdaten ausgerichtet. Daher ist eine Harmonisierung der Größen erforderlich (s. Abschnitt 5.7.4). Zusätzlich stehen manche der benötigten Referenzwerte nur indirekt zur Verfügung. Konkret bezieht sich die vom Fahrspurerkennungsalgorithmus geschätzte Spurbreite ŵ auf den Abstand der Mittelpunkte der linken und rechten Fahrstreifenmarkierung. Im Gegensatz dazu beschreibt die von TRS bereitgestellte Spurbreite w die Breite zwischen den Markierungen. Da auch die Breiten w l und w r der linken bzw. rechten Markierungen verfügbar sind, lässt sich die harmonisierte Spurbreite w = w + w l + w r 2 (7.1) berechnen. Ähnlich ist der Fall bei der Spurablage. Während der Algorithmus die normalisierte Spurablage ô ( 0,5, 0,5] schätzt, stellt TRS den Abstand des Fahrzeugmittelpunktes zur Spurmitte o ( w+w l 2, w+w r 2 ] in Metern zur Verfügung. Die harmonisierte Spurablage o ergibt sich daher durch o = o w. (7.2) Die Harmonisierung erfolgt jeweils auf Basis der Referenzdaten, um eine Fehlerfortpflanzung durch die Ergebnisdaten zu vermeiden. Die Berechnung bzw. Umrechnung notwendiger Größen erfolgt durch Evaluatoren gemäß Abschnitt Bewertung Voraussetzung für eine erfolgreiche Spurverlassenswarnung ist die Detektion der aktuellen Fahrspur. Daher soll im Rahmen dieser Bewertung die Genauigkeit und Verfügbarkeit der Fahrspurschätzung betrachtet werden. Neben globalen Gütemaßen ist das Ziel der Untersuchung die Identifikation problematischer Streckenabschnitte bzw. Streckeneigenschaften. Folgende Größen werden bewertet: Spurbreite ŵ, Spurablage ô, Spurkrümmung ĉ 0. Die Bewertung erfolgt jeweils anhand des mittleren absoluten Fehlers (Mean Absolute Error, MAE), der Wurzel des mittleren quadratischen Fehlers (Root Mean Square Error, RMSE) und der Standardabweichung des Fehlers [MT06; BRB11; TT13]. 119

130 7 Anwendungsfälle e j = ˆx j x j (7.3) MAE = 1 n e j n (7.4) j=1 RMSE = 1 n σ e = 1 n n (e j ) 2 (7.5) j=1 n (e j ē) 2 (7.6) Dabei bezeichnet x j den ggf. harmonisierten Referenzwert der jeweiligen Größe in Bild i, ˆx j den durch den Algorithmus geschätzten Wert, n die Gesamtanzahl der Einzelbilder und ē den mittleren Fehler über alle Bilder. Zusätzlich wird die Verfügbarkeit a bewertet. Sie entspricht dem Anteil der Einzelbilder, in denen eine gültige Spurschätzung vorliegt (gemäß Ausgabe des Algorithmus). a = 1 n a j = 1 j=1 n a j (7.7) j=1 wenn Spurschätzung für Index j gültig 0 sonst Realisierung der Bewertung (7.8) Für die Durchführung der Bewertung in ADAF wurde das in Abbildung 7.5 dargestellte Applikationsprofil erstellt. Darin dient das Sensorplugin TRS der Anbindung des Simulationssystems TRS als Sensordatenquelle. Das Plugin ermöglicht die gezielte Auswahl der von TRS bereitgestellten Daten. Im vorliegenden Beispiel handelt es sich hier um die Bilddaten einer einzelnen Kamera sowie die für die Auswertung notwendigen Referenzdaten (z. B. Spurbreite und Abstand zur Spurmitte). Des Weiteren lässt sich TRS über das Plugin in begrenztem Umfang fernsteuern (Start/Stopp der Datenerzeugung). Das Plugin LaneDepartureWarning implementiert den Spurfindungsalgorithmus (s. Abschnitt 7.3.2). Die Bewertung wird durch die unterschiedlichen Instanzen des Evaluation-Plugins durchgeführt. Preprocess dient zunächst der Harmonisierung der Referenzdaten durch einzelne Evaluatoren gemäß Abschnitt CalculateError enthält Evaluatoren zur Berechnung der Fehlermaße. Daher erhält dieses Plugin sowohl die Ergebnisse der Fahrspurfindung als auch die (umgerechneten) Referenzdaten als Eingabe. CheckError verwendet mehrere Vergleichsevaluatoren, die Grenzwerte für die Fehler überprüfen. Werden diese Grenzwerte überschritten, generieren die Alert-Evaluatoren in Generate- Alerts entsprechende Fehlerintervalle. Durch den Sequence_List_Generator wird aus diesen Fehlerintervallen eine Sequenzliste erzeugt, die nach Abschluss der Bewertung einen 120

131 7.3 Evaluierung einer Fahrspurerkennung TRS ATRSkSensord Preprocess AEvaluationd Data_Package_To_Image_Converter ADatakPackagekTokImagekConverterd Join_Plugin AJoinerd CheckError AEvaluationd LaneDepartureWarning ALanekDeparturekWarningd CalculateError AEvaluationd GenerateAlerts AEvaluationd 2DkDisplay A2DkDisplayd dpmi ADatakPackagekMetakInformationd Abbildung 7.5: Plugingraph zur Bewertung der Fahrspurerkennung Join_Plugin_2 AJoinerd Sequence_List_Generator ASequencekListkGeneratord Result_View_Plugin AResultkTablekDisplayd Result_Writer AResultkWriterd Plot_Plugin APlotterd 121

132 7 Anwendungsfälle LaneDepartureWarning.laneC0h TRS.ego-specialAmbientState-roadC0.adapted :19: :19: Abbildung 7.6: Zeitreihendiagramm der Spurkrümmung. Die Referenzdaten sind in grün, die Ergebnisdaten in rot dargestellt. Abbildung 7.7: Ergebnisdarstellung mit Result Table Display-Plugin gezielten Zugriff auf problematische Streckenabschnitte erlaubt und so eine gezielte Fehleranalyse ermöglicht. ResultWriter dient dem Export der Ergebnisse zur Archivierung und weiteren Analysen mit entsprechenden Programmen. Dabei kann gezielt ausgewählt werden, welche der verfügbaren Ergebnisse exportiert werden sollen. Die Plugins 2D Display, Plot_Plugin und Result_View_Plugin dienen der Visualisierung und werden für die vollautomatische Auswertung nicht benötigt. Während der Konfiguration des Systems und der Fehleranalyse leisten sie jedoch wertvolle Hilfe. 2D Display dient der Darstellung des Kamerabildes sowie der Visualisierung der Kalibrierung und der Ergebnisse der Fahrspurfindung wie in Abbildung 7.4 bereits dargestellt. So ermöglicht es eine einfache visuelle Kontrolle der korrekten Einstellung und Funktion des Systems. Mit Hilfe des Plot_Plugin können Ergebnisse als Zeitreihendiagramm dargestellt werden (s. Abbildung 7.6). Die Darstellung von Ergebnissen und Referenzdaten in einem Diagramm ermöglicht einen Einblick in die zeitliche Struktur eines Fehlers. Im Gegensatz dazu ermöglicht das Result_View_Plugin eine exakte Darstellung der Werte in jedem einzelnen Verarbeitungsschritt (s. Abbildung 7.7). Die verbleibenden Plugins (Joiner, 122

133 7.3 Evaluierung einer Fahrspurerkennung Tabelle 7.1: Genauigkeit der Fahrspurerkennung. Die Verfügbarkeit der Fahrspur beträgt 95,84 %. MAE RMSE σ e Spurbreite (in m) 0,0239 0, ,7805 Spurablage 0, ,1466 0,1410 Spurkrümmung (in m 1 ) 1, , , Abbildung 7.8: In ADAF geladene Sequenzliste der problematischen Streckenabschnitte DataPackageMetaInfo und DataPackageToImageConverter dienen technischen Zwecken (z. B. Konvertierung oder Zusammenführung von Daten aus technischen Gründen) und sind für die Auswertung selbst nicht relevant Ergebnisse In Tabelle 7.1 sind die globalen, über die vollständige Sequenz berechneten Fehlermaße aufgeführt. Der RMSE von 3,542 cm entspricht 0,9 % der echten Spurbreite von 3,93 m. Der Spurfindungsalgorithmus hat in 95,84 % der Strecke gültige Ergebnisse berechnet. Zur Analyse der fehlenden 4,16 % ist eine Untersuchung der Verteilung der Fehler über die Strecke und der betroffenen Streckenabschnitte notwendig. Dazu dient die durch das Sequence List Generator-Plugin erstellte Sequenzliste, die für jedes betroffene Intervall einen Eintrag enthält. Sie kann direkt in ADAF geladen werden und erlaubt dadurch die gezielte Inspektion der problematischen Streckenabschnitte (s. Abbildung 7.8). Die Fehlerintervalle wurden durch das Plugin in beide Richtungen um 75 Bilder erweitert (Lead-In, Lead-Out), um einerseits eine Initialisierung des Spurfindungsalgorithmus zu ermöglichen und andererseits einen Übergang aus bzw. in den Operationsbereich zu gewährleisten. Überlappende Intervalle wurden zusammengefasst, um Streckenabschnitte mit häufigen Unterbrechungen gemeinsam zu erfassen. Dies stellte sicher, dass der 123

134 7 Anwendungsfälle Tabelle 7.2: Analyse der Zeitabschnitte, in denen keine Spurschätzung zur Verfügung steht. In kurzen Abständen aufeinanderfolgende Intervalle wurden zusammengefasst, um den problematischen Streckenabschnitt in seiner Gesamtheit zu erfassen. Anzahl Länge (Median) Bilder Sek. Individuell ,2 Zusammengefasst ,8 Intervallbeginn tatsächlich die Initialisierung des Systems ermöglicht und nicht ebenfalls außerhalb des Operationsbereichs liegt. Die Analyse der Intervalle zeigt Tabelle 7.2. Dabei sind sowohl die individuellen Intervalle aus aufeinanderfolgenden, fehlerhaften Einzelbildern aufgeführt als auch die aufgrund von überlappendem Lead-In und Lead-Out zusammengefassten Intervalle. Für die Längenbetrachtung wurde die Länge des Lead-Ins bzw. Lead-Outs pro Gesamtintervall nicht berücksichtigt Fazit Die vorliegende exemplarische Bewertung eines Systems zur Fahrspurerkennung demonstriert, wie das Framework die Durchführung einer Evaluierung ermöglicht. Es wurde gezeigt, wie anhand mehrerer Instanzen des Evaluation-Plugins eine klar strukturierte Verarbeitungskette zur Bewertung erstellt werden kann. Die Realisierung der Bewertungsmaße als Evaluatoren führt zu einer verbesserten Übersichtlichkeit der Konfiguration, da der Datenfluss in der grafischen Darstellung des Plugingraphen aufgrund der geringeren Pluginanzahl nachvollziehbar bleibt. Durch Verwendung von Evaluatoren ist es außerdem möglich, die Harmonisierung der Referenz- und Ergebnisdaten während der Bewertung durchzuführen, sodass hierzu keine zusätzlichen Schritte im Arbeitsprozess notwendig sind. Die automatisch erzeugte Liste der Sequenzabschnitte, in denen die spezifizierten Fehlergrenzen verletzt wurden, bildet den Einstiegspunkt zur Ursachenanalyse. Damit kann auch in umfangreicheren Datenbeständen als dem in diesem konkreten Anwendungsfall verwendeten gezielt auf die relevanten Teilabschnitte zugegriffen werden. 7.4 Machbarkeitsstudie zur Übertragbarkeit von vorhandenen FAS auf Motorräder Im Rahmen einer von Mitarbeitern der NISYS GmbH durchgeführten Machbarkeitsstudie für die BMW AG wurde die Fragestellung behandelt, ob für Pkw entwickelte Fahrerassistenzsysteme auch auf motorisierten Zweirädern eingesetzt werden können. Dabei wurde untersucht, welche Faktoren die Leistung der Systeme beeinflussen und wie groß die Beeinträchtigung durch fahrzeugspezifische Störungen wie Kurvenneigung und erhöhte Vibration ist. Die Untersuchung erfolgte auf Basis zweier von der NISYS GmbH entwi- 124

135 7.4 Machbarkeitsstudie zur Übertragbarkeit von vorhandenen FAS auf Motorräder ckelter Systeme: einer Verkehrszeichenerkennung für Geschwindigkeitsbegrenzungen sowie der bereits im vorherigen Abschnitt erläuterten Fahrspurerkennung. Die folgende Betrachtung dient der Analyse, wie die in ADAF realisierten Konzepte zu einer effizienten Durchführung der Studie beitragen konnten. Details und Ergebnisse der Studie werden nur soweit diskutiert, wie es zur Veranschaulichung der Problemstellung bzw. der vorgestellten Lösungen notwendig ist Sensorik und Datenaufzeichnung Für die Studie kamen ein Motorrad vom Typ K 1600 GT von BMW sowie ein Pkw zum Einsatz. Die verwendete Sensorik ist in Tabelle 7.3 aufgeführt. Tabelle 7.3: Verwendete Sensorik Sensor Anschluss Motorrad Pkw Kamera IDS ueye UI-5240CP-M Gigabit-Ethernet Objektiv Pentax, Öffnungswinkel: 56 GPS Navilock NL-402U USB Lage interner Lagesensor CAN Die Bild- und Positionssensorik war in beiden Versuchsträgern identisch. Im Motorrad war zusätzlich ein Lagesensor verbaut, dessen Daten über den CAN-Bus zur Verfügung standen. Die Kamera wurde mit einer Auflösung von und einer Bildrate von 25 Hz betrieben. Da weder das TSR- noch das LDW-System Farbinformationen verwenden, wurden die Bilddaten monochrom aufgezeichnet. Die Aufzeichnung der Daten erfolgte unter Verwendung von ADAF. Im Pkw wurde ein 19-Zoll-Industrie-PC der Firma Kontron mit externem RAID-System zur Speicherung der Daten verbaut. Die Kamera wurde mit einem Saugnapf in der Nähe des Innenspiegels an der Windschutzscheibe befestigt. Oberhalb der Mittelkonsole wurde am Armaturenbrett ein 8-Zoll-Display zur Bedienung des Rechners und zur Kontrolle der Aufzeichnung befestigt. Auf dem Motorrad kam als Aufzeichnungssystem ein IP65-zertifiziertes Industrienotebook (fully ruggedized notebook) der Firma Getac zum Einsatz. Dieses wurde im Motorradkoffer installiert wie in Abbildung 7.9 zu sehen. Die Kamera wurde hinter dem Windschild angebracht. Auch hier diente ein 8-Zoll-Display zur Bedienung und Kontrolle des Aufzeichnungssystems. Insgesamt wurden an unterschiedlichen Tagen ca. 12 Stunden Fahrt aufgezeichnet, davon ca. 2 Stunden gleichzeitig mit Auto und Motorrad in Folgefahrt. So konnte gewährleistet werden, dass die Daten bei identischen Witterungsbedingungen aufgezeichnet wurden. Die Synchronisierung von Start und Stopp der Aufzeichnung erfolgte mündlich über Funk. 125

136 7 Anwendungsfälle Abbildung 7.9: BMW K1600 GT mit Aufzeichnungssystem Verkehrszeichenerkennung Zur Bewertung der Leistungsfähigkeit der TSR auf einem Motorrad wurde zunächst die Grundleistung des Systems bei Einsatz im Pkw, also dem ursprünglich spezifizierten Einsatzbereich, bestimmt. Auf dieser Basis erfolgte ein Vergleich der Leistungsfähigkeit des Systems bei Einsatz auf einem Motorrad. Die vorliegende Bewertung basierte auf den Streckenabschnitten, für die Daten beider Fahrzeuge verfügbar waren. Der zeitliche Versatz zwischen den mit dem Pkw und den mit dem Motorrad aufgezeichneten Daten ist mit Blick auf die Gesamtaufnahmedauer vernachlässigbar. Die Daten können als äquivalent und dieselbe Szene beschreibend betrachtet werden. In den aufgezeichneten Daten wurden die Verkehrszeichen zur Geschwindigkeitsbegrenzung mit Hilfe der in Abschnitt 7.2 vorgestellten Automatisierung annotiert. Anschließend erfolgte eine manuelle Kontrolle und Korrektur. Da für den Nutzer des Assistenzsystems nicht die korrekte Erkennung eines Schildes in jedem Einzelbild wichtig ist, sondern die korrekte Integration von Einzelergebnissen zu einer stabilen Gesamtaussage, erfolgte die Bewertung des Systems trackbasiert. Dabei wurde in Track als korrekt erkannt gewertet, wenn das Verkehrszeichen in mindestens der Hälfte der Einzelbilder korrekt detektiert und erkannt wurde. Die Leistung des Systems wurde durch die Anzahl korrekt erkannter Tracks im Vergleich zur Gesamtzahl beschrieben. Die Ergebnisse in Tabelle 7.4 zeigen, dass die Erkennungsrate auf dem Motorrad 126

137 7.4 Machbarkeitsstudie zur Übertragbarkeit von vorhandenen FAS auf Motorräder Tabelle 7.4: Erkennungsraten der Verkehrszeichenerkennung für gemeinsam befahrene Streckenabschnitte Konfiguration Erkennungsrate Pkw 90,40 % Motorrad 62,76 % Motorrad (rotiert) % Abbildung 7.10: Korrekturrotation des Kamerabildes anhand der Messwerte des Rollwinkelsensors. Der blaue Rahmen markiert den Verarbeitungsbereich der Verkehrszeichenerkennung. deutlich geringer ist als im Pkw. Da die Systemkonfiguration identisch war, sind diese Ergebnisse auf die unterschiedlichen Daten zurückzuführen. Ein offenkundiger Unterschied zwischen den Pkw- und den Motorraddaten ergab sich aus der Schräglage des Motorrads bei Kurvenfahrten. Dies führte wegen der fixierten Kameraposition zu rotierten Bildern in Bezug zur Normallage bzw. zum Horizont. Da die TSR auf aufrechte, also unrotierte, Verkehrszeichen ausgelegt ist, waren hierdurch entsprechende Einbußen in der Erkennungsleistung zu erwarten. Daher wurde zur Vorverarbeitung eine Ausgleichsrotation der Bilddaten auf Basis des über CAN verfügbaren Rollwinkels des Motorrads vorgenommen und erst anschließend die Verkehrszeichenerkennung durchgeführt (s. Abbildung 7.10). Abbildung 7.11 zeigt, wie diese Vorverarbeitung aufgrund der modularen Architektur von ADAF durch Einfügung weiterer Plugins in die Verarbeitungskette realisiert werden konnte. Die Ergänzung ist für die bereits vorhandenen Plugins, insbesondere den Kamerasensor und die Verkehrszeichenerkennung, völlig transparent. Abgesehen von der Modifikation der Pinverbindungen sind keine weiteren Anpassungen notwendig. Die übrige Verarbeitungskette entspricht daher exakt der Verarbeitung der nicht rotierten Daten. Für die Vorverarbeitung ist zunächst die Interpretation der CAN-Bus-Nachrichten notwendig, um den Rollwinkel zu erhalten. Dies erfolgt durch das Plugin CAN Bus Decoder. Da das Image Processing Plugin den Rotationswinkel im Bogenmaß erwartet, 127

138 7 Anwendungsfälle ueye_camera_sensor (ueye Camera Sensor) TSR (Traffic Sign Recognition) (a) Die Bilddaten werden direkt von der Verkehrszeichenerkennung verarbeitet. ueye_camera_sensor (ueye Camera Sensor) Rotate_Image (Image Processing Plugin) TSR (Traffic Sign Recognition) Lagesensor_CAN (Vector CAN Bus Sensor) CAN-Bus Decoder (CAN Bus Decoder) Convert_Roll_Angle (Evaluation) (b) Transparente Erweiterung des Plugingraphen in (a) zum Ausgleich der Rotation bei Kurvenfahrt auf Basis der Rollwinkelmessung Abbildung 7.11: Ausschnitt aus dem Plugingraph für die Verarbeitung der Daten (a) ohne und (b) mit Rotationsausgleich. Das Ergebnis der Korrektur ist in Abbildung 7.10 dargestellt wird der in Grad verfügbare Rollwinkel mit Hilfe des Evaluation-Plugins und des Basic Expression-Evaluators umgerechnet. Die Resultate in Tabelle 7.4 zeigen, dass der Rotationsausgleich die Ergebnisse leicht verbessern konnte. Die Erkennungsleistung liegt jedoch weiterhin deutlich unter der Pkw-Leistung, da nur ein Teil der Verkehrszeichen durch die Schräglage betroffen war. Die visuelle Analyse der Fehlersituationen führte zur Identifikation von zwei weiteren Ursachen, die die Erkennungsleistung beeinträchtigen: der Einfluss des Windschilds und die erhöhte Vibration im Vergleich zum Pkw. Die Verkehrsschilder befinden sich in der Regel im linken und rechten Randbereich der Kamerabilder. Durch den Windschild des Motorrads (Krümmung, Material, ggf. Beschädigungen) kommt es in diesen Bereichen zu einer Beeinträchtigung der Bildqualität durch eine erhöhte Unschärfe, die die Klassifikationsleistung beeinträchtigt (s. Abbildung 7.12). In schwierigen Beleuchtungssituationen wie Dämmerung oder Dunkelheit führt die Eigenbewegung der Fahrzeuge durch die erhöhte Belichtungszeit der Kamera zu starker Bewegungsunschärfe. Im Vergleich zum Pkw vibriert das Motorrad allerdings stärker, sodass zusätzlich zur Fahrbewegung eine vertikale Bewegungskomponente hinzukommt (s. Abbildung 7.13). Dadurch treten störende Artefakte früher bzw. stärker auf als beim Pkw und verhindern eine erfolgreiche Klassifikation Fahrspurerkennung Im zweiten Teil der Studie wurde ein Algorithmus zur Fahrspurerkennung bewertet. Das Experiment entspricht konzeptionell der Bewertung der Verkehrszeichenerkennung. Die Grundleistung wird auf Basis der mit dem Pkw aufgezeichneten Daten bestimmt. Zum Vergleich wird das System auf den Motorraddaten einmal direkt und einmal unter Nutzung des Rotationsausgleichs bewertet. Neben den aufgezeichneten Daten konnten 128

139 7.4 Machbarkeitsstudie zur Übertragbarkeit von vorhandenen FAS auf Motorräder (a) Pkw (b) Motorrad Abbildung 7.12: Durch Windschild verursachte Unschärfen im Randbereich des Kamerabildes. Ein roter Rahmen zeigt das Ergebnis der Detektion, der grüne Rahmen eine erfolgreiche Klassifikation. Die Detektion war auf den Motorraddaten trotz Unschärfe im vorliegenden Beispiel erfolgreich, aber die Klassifikation schlug fehl. Abbildung 7.13: Bewegungsunschärfe durch Vibration des Motorrads in der Dämmerung zahlreiche Plugins, insbesondere jene zur Rotation des Bildes, unverändert übernommen werden. Es kommt das in Abschnitt 7.3 vorgestellte System zur Fahrspurerkennung zum Einsatz. Im Gegensatz zur Annotation von Objekten ist die Annotation einer Fahrspur sehr viel aufwendiger. Unter der Annahme, dass das Fahrzeug sich während der gesamten Fahrt auf einer Straße befindet, sind in jedem Einzelbild ein Fahrstreifen bzw. dessen Begrenzungen vorhanden, die zu annotieren wären. Während für viele Objekte die Definition des umgebenden Rechtecks ausreichend ist, erfordern Fahrstreifen eine pixelgenaue Annotation der jeweiligen Begrenzungen. Durch Kurven und Änderungen der Fahrstreifencharakteristika (z. B. Breite) sowie Verdeckungen durch vorausfahrende Fahrzeuge kommt es zu einer kontinuierlichen Veränderung der Form, was eine Anpassung in jedem Einzelbild notwendig macht. Eine Bestimmung quantitativer Eigenschaften wie der 129

140 7 Anwendungsfälle Tabelle 7.5: Verfügbarkeit der Fahrspurerkennung. Die Gesamtverfügbarkeit bezeichnet die Verfügbarkeit einer Fahrspurschätzung. Verfügbarkeit links + rechts bezeichnet den Anteil, in dem sowohl für die linke als auch die rechte Fahrstreifenmarkierung eine als stabil erachtete Schätzung vorlag. Sie ist somit Teil der Gesamtverfügbarkeit. Konfiguration Verfügbarkeit gesamt links & rechts Pkw 88,56 % 44,31 % Mot. 86,52 % 37,63 % Mot. (rot.) 89,28 % 40,00 % Mot. (rot. + stab.) 88,66 % 40,27 % Breite des Fahrstreifens oder der Markierungen, der Krümmung des Fahrstreifens oder der lateralen Position des Fahrzeugs ist nur mit hohem Zusatzaufwand möglich. Aus diesen Gründen wurde auf eine Annotation dieser Werte verzichtet und eine Bewertung auf Basis der Verfügbarkeit einer Fahrspurschätzung durchgeführt. Sie beruht auf der Annahme, dass in jedem Bild sowohl eine linke als auch eine rechte Fahrstreifenmarkierung vorhanden sind und somit vom Algorithmus zu erkennen sind. Die Bewertung betrachtet die Verfügbarkeit dieser Markierungen, ohne die Präzision der Lokalisierung zu berücksichtigen. Während die oben verwendete Verkehrszeichenerkennung zwar die Klassifikationshypothesen über aufeinanderfolgende Bilder stabilisiert, erfolgen Detektion und Klassifikation grundsätzlich einzelbildbasiert. Im Gegensatz dazu arbeitet der Algorithmus zur Fahrspurerkennung sequenzbasiert und ist daher stärker von Unterschieden zwischen aufeinanderfolgenden Bildern betroffen, wie sie insbesondere durch die Vibration des Motorrads hervorgerufen werden. Die Vibration wird in den Bilddaten vor allem durch eine vertikale Änderung der Kameraposition sichtbar. Um diesen Effekt zu reduzieren, wurde zwischen dem Rotationsplugin und der Fahrspurerkennung ein weiteres Plugin in die Verarbeitungskette eingefügt. Dieses bestimmt durch Kreuzkorrelation ausgewählter Bereiche in aufeinanderfolgenden Bildern die vertikale Translation und wendet sie mit negativem Vorzeichen auf das aktuelle Bild an. Dies führt zu einer vertikalen Stabilisierung der Bildfolge. Sowohl die Entwicklung als auch die Tests dieses Plugins wurden durch die Modularität des Frameworks stark vereinfacht. Als Datenquelle wurde NISYS TRS verwendet, der eine Variation der vertikalen Kameraposition und somit die gezielte Generierung von Störungen erlaubt. Anhand der ebenfalls bereitgestellten Referenzdaten konnte das Ergebnis der vertikalen Stabilisierung auch quantitativ überprüft werden. Die Ergebnisse der Untersuchung sind in Tabelle 7.5 aufgeführt. Die Gesamtverfügbarkeit bezeichnet den Anteil der Gesamtdaten, in dem eine Fahrspurschätzung verfügbar war. Diese stützt sich auf die Detektion und Schätzung der linken und rechten Fahrstreifenmarkierungen. Die Spalte links & rechts umfasst den Anteil, zu dem für beide Fahrstreifenbegrenzungen unabhängig voneinander eine stabile Schätzung vorlag. Ist diese nur für eine Seite verfügbar, wird die fehlende Markierung auf Basis der früher 130

141 7.5 Exemplarische Realisierung eines Spurhalteassistenten geschätzten Fahrstreifenbreite extrapoliert. 4 Im Gegensatz zur TSR, zeigen die Ergebnisse, dass die Leistung des Systems auf dem Motorrad mit der im Pkw vergleichbar ist. Die Gesamtverfügbarkeit ist hoch, auch wenn nur in der Hälfte der Fälle beide Fahrstreifenbegrenzungen stabil geschätzt werden können. Für letztere zeigt sich auch ein deutlicherer Unterschied zwischen Pkw und Motorrad, der darauf zurückzuführen ist, dass bei starker Schräglage des Motorrads die kurvenäußere Fahrbahnbegrenzung den vom Algorithmus berücksichtigten Bereich verlässt und daher nicht mehr korrekt detektiert wird. Dieser Effekt konnte auch hier durch den Rotationsausgleich reduziert werden. Die Vermutung, dass eine vertikale Stabilisierung zu einer Verbesserung der Ergebnisse führt konnte dagegen nicht bestätigt werden Fazit Es wurde gezeigt, wie ADAF die effiziente Durchführung einer Machbarkeitsstudie durch Datenaufzeichnung, automatisierte Annotation, Systemausführung und Bewertung ermöglicht hat. Für die Aufnahme der Daten konnte für Pkw und Motorrad die identische Grundkonfiguration verwendet werden. Diese wurde für das Motorrad lediglich um ein weiteres Sensorplugin für den CAN-Bus ergänzt, um auch die Erfassung des Rollwinkels zu ermöglichen. Die Sensordaten konnten ohne Mehraufwand für beide Experimente verwendet werden. Die Bestimmung der Grundleistung konnte für Pkw und Motorrad mit der identischen Konfiguration durchgeführt werden. Der Bewertungsprozess unterschied sich in diesem Fall nur durch die verwendeten Daten. Zur Gewinnung der weiteren Ergebnisse für das Motorrad wurden jeweils die identischen Daten sowie die Bewertungsmaße verwendet, dafür jedoch das System verändert. Diese Veränderung erfolgte nur durch Ergänzung von Plugins, der Algorithmus selbst und seine Parameter blieben unverändert. Dadurch ließen sich die Verbesserungen der Ergebnisse klar den einzelnen Veränderungen der Verarbeitungskette zuordnen. Die Austauschbarkeit der Datenquelle hat es ermöglicht, sowohl das Plugin zur vertikalen Stabilisierung als auch das zum Ausgleich der Rollbewegung anhand von synthetischen Daten zu entwickeln und zu testen. Die Struktur des Datenflussgraphen hat es erlaubt, dass beide anschließend transparent für die weiteren Plugins in die Verarbeitungskette eingefügt werden konnten. 7.5 Exemplarische Realisierung eines Spurhalteassistenten In diesem Abschnitt wird in Verbindung mit dem Simulationssystem TRS exemplarisch ein Spurhalteassistent in ADAF realisiert und bewertet. Dieser wurde im Rahmen eines internen Projekts durch die NISYS GmbH entwickelt. Durch die Verwendung von ADAF 4 Ist keine ausreichend aktuelle Schätzung der Fahrstreifenbreite verfügbar, wird ein Standardwert angenommen. 131

142 7 Anwendungsfälle Warnung, Information Fahrer Fahrzeug Umwelt FAS autonomer Eingriff Längsdynamik Querdynamik Abbildung 7.14: Regelkreis Fahrer(assistenzsystem) Fahrzeug Umwelt war es NISYS möglich, das bereits vorgestellte Fahrspurerkennungssystem durch weitere Plugins zu einem bildbasierten Spurhalteassistenten zu erweitern. Diese Realisierung wird im Folgenden vorgestellt und im Rahmen eines sog. Software-in-the-loop(SIL)- Tests bewertet. Die Bewertung des Systems wurde im Rahmen der vorliegenden Arbeit durchgeführt Problemstellung Ein System zur Spurverlassenswarnung (Lane Departure Warning, LDW) ist zunächst ein rein informierendes System. Es macht den Fahrer auf einen möglichen Fahrfehler das unbeabsichtigte Verlassen der eigenen Fahrspur aufmerksam. Dies kann akustisch, optisch oder haptisch erfolgen. Die notwendige Korrektur des Fahrzeugkurses liegt vollständig in der Verantwortung des Fahrers (s. Abschnitt 2.3). Ungeachtet des Wiener Übereinkommens und der darauf basierenden nationalen Verkehrsvorschriften, gehören Unaufmerksamkeit, Ablenkung und Sekundenschlaf zur Realität des Straßenverkehrs (s. Abschnitt 1.3). Ein aktives Fahrerassistenzsystem kann durch einen kurzen Eingriff die Gefahren für alle Verkehrsteilnehmer deutlich reduzieren. Spurhalteassistenten (Lane Keeping Assistant, LKA) ergänzen die Erkennung der Fahrspur daher mit einer Komponente, die einen automatischen Lenkeingriff durchführt, der das Fahrzeug in der aktuellen Fahrspur hält und so ein unbeabsichtigtes Abdriften in benachbarte Fahrspuren oder gar das Verlassen der Straße verhindert. Sowohl LDW als auch LKA sind zunächst auf eine korrekte Erkennung der eigenen Fahrspur angewiesen. Sie dient als Basis für die Bewertung der aktuellen Fahrsituation durch nachfolgende Algorithmik, die bei Bedarf eine systemabhängige Ausgabe generiert: die Warnung des Fahrers oder die Auslösung eines autonomen Lenkeingriffs Regelkreis Fahrer Fahrzeug Umwelt Fahrer, Fahrerassistenzsystem, Fahrzeug und Umwelt bilden einen geschlossenen Regelkreis (vgl. [Bub02; WBM02]), der in Abbildung 7.14 dargestellt ist. In diesem Regelkreis führt das Assistenzsystem einen Teil der Aufgaben des Fahrers aus: Erfassung der Umwelt 132

143 7.5 Exemplarische Realisierung eines Spurhalteassistenten und Verarbeitung der Daten, Bewertung der aktuellen Situation und Auslösung von Verhalten. Bei einem autonomen System löst die Systemausgabe direkt einen Eingriff in die Fahrzeugführung aus. Hier ersetzt es quasi den Fahrer (der jedoch parallel dieselbe Aufgabe durchführt und dessen Aktionen bei abweichendem Ergebnis vorrangig sind). Bei einem Informationssystem, dass lediglich warnt, stellt die Warnung eine weitere Eingabe in das System Fahrer dar, die zusammen mit den weiteren Sinneswahrnehmungen verarbeitet werden muss. Diese Warnung trägt zur Bewertung der Gesamtsituation bei und kann so die Entscheidung des Fahrers über auszuführendes Verhalten beeinflussen. In einem solchen Fall ist das Assistenzsystem ein ergänzendes Instrument (ähnlich wie der Tachometer) im Regelkreis Fahrer Fahrzeug Umwelt Fahrzeug und Umwelt Für die Bewertung des Assistenzsystems im Regelkreis ist die Verwendung von aufgezeichneten Sequenzen nicht möglich, da diese die Auswirkungen des Lenkeingriffs auf das Fahrzeug und seine Position in der Umwelt nicht widerspiegeln können. Für die Simulation von Fahrzeug und Umwelt wird daher erneut auf das Simulationssystem TRS zurückgegriffen. Die dynamische Generierung der Sensordaten sowie die Möglichkeit, von außen auf das Fahrverhalten Einfluss zu nehmen, ermöglichen eine Simulation des geschlossenen Regelkreises Fahrer(assistenzsystem)-Fahrzeug-Umwelt [NEI12] Realisierung des Fahrer(assistenzsystem)s Der Fahrer ist für die Längs- und Querführung des Fahrzeugs verantwortlich. Wird das Simulationssystem autonom betrieben, erfolgt die Erfüllung dieser Aufgabe durch ein internes Fahrermodell. Dies dient als Vergleichsbasis zur Bewertung des Assistenzsystems. Alternativ kann die Fahrzeugführung auch von außen erfolgen, entweder durch einen menschlichen Fahrer oder in diesem Fall durch ein extern implementiertes Assistenzsystem. Abbildung 7.15 zeigt die Konkretisierungen des Regelkreises Fahrer(assistenzsystem) Fahrzeug Umwelt aus Abbildung 7.14 für beide Szenarien. Aufgabe des Spurhalteassistenten ist die Querführung des Fahrzeugs, um ein unbeabsichtigtes Verlassen des eigenen Fahrstreifens zu verhindern. 5 Die Umsetzung des Fahrerassistenzsystems erfolgt durch mehrere Plugins in ADAF (s. Abbildung 7.16). Zentraler Bestandteil der Verarbeitungskette ist das bereits in Abschnitt 7.3 vorgestellte System zur Fahrspurerkennung (LaneDepartureWarning). Es stellt die Position der Fahrstreifenbegrenzungen in Bildkoordinaten zur Verfügung. Die extrinsischen Kameraparameter werden so gewählt, dass die Kamera lateral genau in der Fahrzeugmitte positioniert ist. Bei Geradeausfahrt in Spurmitte entspricht somit die vertikale Achse in Bildmitte der Spurmitte. Basierend auf der detektierten Fahrspur wird durch das LaneDeviation-Plugin, ebenfalls in Bildkoordinaten, die Abweichung der Fahrzeugposition von der Spurmitte berechnet. Sie dient als Regelgröße für einen nichtlinearen Regler im SigmoidController-Plugin, der 5 Die Längsführung erfolgt in beiden Fällen mit konstanter Geschwindigkeit durch TRS. 133

144 7 Anwendungsfälle TRS ADAF Fahrermodell Lenkwinkel Fahrzeug Umwelt Bewertung (a) Fahrzeugführung durch TRS-internes Fahrermodell ADAF TRS ADAF Lenkwinkel FAS Fahrzeug Umwelt Bewertung Kamerabild (b) Fahrzeugführung durch LKA-System Abbildung 7.15: Konkretisierungen des Regelkreises Fahrer(assistenzsystem) Fahrzeug Umwelt aus Abbildung 7.14 TRS_Sensor (TRSSensor) Lane_Detection (LaneDepartureWarning) Calculate_Deviation (LaneDeviation) Calculate_Steering_Angle (SigmoidController) Send_Steering_Angle (CanBusSender) Abbildung 7.16: Verarbeitungskette des LKA-Systems den zur Rückführung des Fahrzeugs in die Spurmitte benötigten Lenkwinkel bestimmt. Der Regler verwendet zur Signalbegrenzung die sigmoide Übertragungsfunktion Dabei entspricht 1 f ( x) = α 0,5. (7.9) 1 + e β x x = b 2 x r(y) x l (y) 2 (7.10) der Differenz von Bildmitte und Spurmitte, mit b der Breite des Bildes und x l bzw. x r der x-koordinate der linken bzw. rechten Spurmarkierung in Bildzeile y, die sich aus der gewünschten Vorausschauweite des Systems bestimmt. Gemäß Abbildung 7.17 ergibt sich aus für die gesuchte Bildzeile h z = y f h i 2 (7.11) y(z) = h f z + h i 2. (7.12) 134

145 7.5 Exemplarische Realisierung eines Spurhalteassistenten Bildebene h i y z f h Fahrbahnoberfläche Abbildung 7.17: Größen zur Bestimmung der Bildzeile abhängig von der Vorausschauweite anhand des Lochkameramodells (Seitenansicht) f Brennweite der Kamera h i Höhe des Kamerabildes y Bildzeile zur Bestimmung der Spurabweichung h Einbauhöhe der Kamera z gewünschte Vorausschauweite (a) (b) Abbildung 7.18: Grafische Darstellung des Messbereichs und der detektierten Abweichung. Die grüne Linie markiert die Bildmitte, die gelbe vertikale Linie die detektierte Spurmitte (Mittelpunkt zwischen den detektierten Spurmarkierungen). Farbe und Länge des horizontalen Balkens verdeutlichen den Betrag der Abweichung. Zur besseren Sichtbarkeit kleiner Abweichungen entspricht die Länge des Balkens der dreifachen Abweichung. Abbildung 7.18 zeigt die grafische Darstellung des Messbereichs und der gemessenen Abweichung. Die Bestimmung der Parameter α = 0,09 und β = 0,08 erfolgte experimentell. Die interaktiven Parametrierungsmöglichkeiten von ADAF ermöglichten dabei ein effizientes Vorgehen. Abschließend wird der durch den Regler bestimmte Lenkwinkel vom CanBusSender-Plugin über den CAN-Bus an TRS übermittelt Evaluierung Zur Bewertung des Spurhalteassistenten wurde im Rahmen dieser Arbeit die Genauigkeit der bildbasierten Spurführung im Vergleich zur automatischen Spurführung des in TRS 135

146 7 Anwendungsfälle integrierten Fahrermodells untersucht. Beide Verfahren wurden auf einer automatisch generierten Strecke mit einer Länge von km bewertet. Dies entspricht bei einer konstanten Fahrgeschwindigkeit von 90 km/h n = Einzelbildern. Im Gegensatz zur bildbasierten Regelung erfolgt die Bewertung auf Basis der tatsächlichen lateralen Position des Fahrzeugs in der Spur, d. h. der Entfernung der Fahrzeugmitte von der Spurmitte, und somit in Weltkoordinaten. Sie verwendet den bereits in Gleichung (7.5) auf Seite 120 eingeführten RMSE RMSE = 1 n (ˆx j x j ) 2, (7.13) n wobei ˆx j und x j in diesem Fall der erzielten respektive der idealen lateralen Position des Fahrzeugs in der Fahrspur in Bild j entspricht. Als ideal gelte die Spurführung genau dann, wenn sich das Fahrzeug exakt in der Spurmitte befindet. Es gilt also x j = 0. Daher kann der Term x j in Gleichung (7.13) entfallen. Der MAE sowie die Standardabweichung des Fehlers σ e werden analog gemäß den Gleichungen (7.4) und (7.6) berechnet. Gemäß den in Abbildung 7.15 dargestellten Szenarien wird die generierte Teststrecke zweimal verarbeitet. Im ersten Fall erfolgt die Bestimmung des Lenkwinkels und somit die Spurführung automatisch durch das in TRS integrierte Fahrermodell und ADAF wird nur zur Bewertung eingesetzt. Im zweiten Fall erfolgt die Bestimmung des Lenkwinkels durch das vorgestellte LKA-System, dessen Realisierung wie beschrieben durch Plugins in ADAF erfolgt. Die Bewertung wird ebenfalls mit ADAF durchgeführt. Es ist zu hervorzuheben, dass die zur Spurhaltung verwendeten Verfahren TRSinternes Fahrermodell oder LKA-System nur auf Basis des beobachtbaren Verhaltens bewertet werden: der aktuellen lateralen Position des Fahrzeugs in der Fahrspur. Eine Berücksichtigung der inneren Struktur wie z. B. der vorgestellten Verarbeitungskette des LKA-Systems ist nicht notwendig (Blackbox-Test). So wird der Vergleich der zwei Testszenarien möglich, da nur die genannte Größe in beiden Fällen zur Verfügung steht. Da das vorgeschlagene Gütemaß keine direkten Ausgaben des LKA-Systems selbst berücksichtigt (z. B. die in Vorausschauweite berechnete Abweichung in Bildkoordinaten), ist es möglich, die Ausführung des LKA-Systems und die Bewertung auf zwei unabhängige Instanzen von ADAF aufzuteilen und so klar zu trennen. Dies stellt einerseits sicher, dass in beiden Testszenarien das identische Applikationsprofil zur Bewertung verwendet werden kann. Das erhöht die Wartbarkeit und reduziert Fehlerquellen durch abweichende Konfigurationen. Andererseits ermöglicht es eine unabhängige (Weiter-)Entwicklung von System und Bewertung. Es bleibt anzumerken, dass diese Trennung optional ist. Technisch ist es ohne weiteres möglich, die Ausführung des Systems zusammen mit der Bewertung in derselben ADAF-Instanz durchzuführen. Die Ergebnisse der Bewertung sind in Tabelle 7.6 aufgeführt. In der Gesamtbetrachtung zeigt sich, dass das LKA-System dem TRS-internen Fahrermodell bei identischer Vorausschauweite von z = 15 m deutlich überlegen ist. Der RMSE des TRS-Modells liegt über dem 6-fachen des LKA-Systems. Zusätzlich zum RMSE wurden während der Evaluierung die Spurablage sowie der aktuelle Lenkwinkel über das TRS Sensor-Plugin erfasst und während der Verarbeitung in- j=1 136

147 7.5 Exemplarische Realisierung eines Spurhalteassistenten Tabelle 7.6: Bewertung des Spurhalteassistenten für z = 15 m Spurführung MAE (in m) RMSE (in m) σ e (in m) TRS 0,1277 0,1831 0,1830 LKA 0,0222 0,0267 0,0189 Spurablage (in m) Spurablage (in m) 0,5 0,4 0,3 LKA-System TRS-Internes Fahrermodell 0,2 0,1 0-0,1-0,2-0,3-0,4-0, Frameindex 0,2 0,15 0,1 LKA-System TRS-Internes Fahrermodell 0,05 0-0,05-0,1-0,15-0, Frameindex Abbildung 7.19: Vergleich der lateralen Position des Fahrzeugs innerhalb der Fahrspur (Abweichung von der Spurmitte). Die untere Abbildung zeigt einen vergrößerten Ausschnitt des oberen Diagramms. nerhalb von ADAF zur visuellen Kontrolle als Zeitreihendiagramm gezeichnet. Da hierbei jedoch aufgrund der Datenmenge immer nur ein (konfigurierbarer) Ausschnitt über die letzten Werte dargestellt werden konnte, wurden die vollständigen Ergebnisse zusätzlich über das Result Writer-Plugin in eine Datei exportiert. Dies erlaubte weitere Analysen mit geeigneten Anwendungen. Da in Verbindung mit dem verwendeten Simulationssystem nicht beide Ansätze gleichzeitig, sondern nur nacheinander bewertet werden konnten, ermöglichte der Ergebnisexport nachträglich außerdem die vergleichende Analyse. In Abbildung 7.19 ist für einen Ausschnitt der Daten die Spurablage dargestellt. Die Kurven innerhalb des Streckenverlaufs sind durch die größere Spurablage deutlich zu erkennen. Größere Beträge entsprechen Kurven mit kleinerem Kurvenradius. In beiden Fällen verlässt das Fahrzeug die Spurmitte in Richtung Kurveninnenseite. Es zeigen sich zwei deutliche Unterschiede zwischen den beiden Verfahren. Wie bereits durch den 137

148 7 Anwendungsfälle 0,01 Lenkwinkel (in rad) 0, ,005 LKA-System TRS-internes Fahrermodell -0, Frameindex Abbildung 7.20: Vergleich des Lenkwinkels globalen RMSE angedeutet, ist der Fehler innerhalb einer Kurve für das TRS-interne Fahrermodell deutlich größer als für das LKA-System, das selbst in engen Kurven eine fast zentrale Spurführung erreicht. Zum anderen ist auf den geraden Streckenabschnitten zu erkennen, dass das LKA-System einen systematischen Fehler aufweist, da die Spurablage größer als Null ist. Zur genauen Bestimmung dieses Fehlers wurde eine bedingte Auswertung durchgeführt, bei der der RMSE nur für die Bilder berechnet wurde, die eine gerade Strecke repräsentieren, in denen also die Spurkrümmung (Kehrwert des Kurvenradius) Null ist. Diese Auswertung führt zu einem RMSE von 0,0191 m. Abbildung 7.20 zeigt den Lenkwinkel für den in Abbildung 7.19 vergrößerten Ausschnitt. Betragsmäßig ist der Lenkwinkel für beide Systeme gleich. Es ist jedoch zu sehen, dass das TRS-interne Fahrermodell etwas früher auf die Kurve reagiert. Dadurch kommt es zur beobachteten Spurablage in Richtung Kurveninnenseite. Ferner ist zu sehen, dass der durch das LKA-System erzeugte Lenkwinkel oszilliert. Mögliche Ursache hierfür ist die fehlende Subpixelgenauigkeit bei der Ausgabe der Spurmarkierungen, die zur Berechnung der Abweichung dienen. Da die Bewertung in diesem Experiment im Gegensatz zu Abschnitt 7.3 nicht mit aufgezeichneten Daten durchgeführt werden konnten, ist die Ausführungsdauer durch ADAF nicht direkt kontrollierbar. Sie ist durch zwei Faktoren nach oben begrenzt. Einerseits durch die Rate, mit der Bild- und Referenzdaten durch TRS also den Sensor bereitgestellt werden können, andererseits durch die Gesamtverarbeitungszeit je Bild durch die Verarbeitungskette in ADAF. Für die Betrachtung des TRS-internen Fahrermodells werden keine Bilddaten, sondern lediglich die relevanten Zustandsdaten verarbeitet (z. B. Spurablage, Lenkwinkel). ADAF führt nur die Bewertung durch, keine Verarbeitung im Sinne höherer Algorithmik. Durch Verzicht auf die Erzeugung der Bilddaten kann das Experiment daher in 25-facher Echtzeit durchgeführt werden. Die Implementierung des LKA-Systems ist für die Fahrspurfindung auf Erzeugung und Verarbeitung von Bilddaten angewiesen. Außerdem muss der berechnete Lenkwinkel über CAN an das Simulationssystem kommuniziert werden. Hierdurch reduziert sich der Beschleunigungsfaktor auf vier. Die Verarbeitung der Bilddaten hat hieran keinen bzw. nur einen sehr geringen Anteil. Die Fahrspurerkennung benötigt mit ca. 0,5 ms je Bild den größten Anteil. Zusatzaufwand ergibt sich, wenn viele Visualisierungsmodule gleichzeitig aktiv sind (Darstellung des 138

149 7.6 Fazit Bildes inkl. überlagerter Ergebnisse, mehrere Diagramme, Ergebnistabelle). Während der automatisierten Durchführung der Bewertung werden diese allerdings in der Regel nicht benötigt, sodass ihre Verwendung unterbleiben kann. Bei Bedarf, z. B. für eine Zwischenkontrolle, können sie jedoch problemlos vorübergehend eingebunden werden Fazit Es wurde gezeigt, dass ADAF nicht auf die Verarbeitung von Sensordaten und Bewertung der Systemleistung beschränkt ist, sondern auch in einem geschlossenen Regelkreis eingesetzt werden kann. Die Realisierung des LKA-Systems erfolgte durch Erweiterung des LDW-Systems um weitere Plugins. Grundsätzlich ist auch ein Einsatz dieses Systems in einem Testfahrzeug denkbar, da als Eingabesignal nur die Bildinformation notwendig ist und die Ausgaben des Systems auch in der vorgestellten SIL-Konfiguration bereits über CAN-Bus bereitgestellt werden. Erforderlich hierzu ist der Zugriff auf den CAN-Bus des Fahrzeugs und die für einen Lenkeingriff notwendige Aktorik. Die Parametrierung des Regler-Plugins war mittels bereitgestellter Plugin Properties komfortabel möglich. Die Option, die Bewertung in einer eigenen ADAF-Instanz auszuführen und somit die Verwendung des identischen Applikationsprofils für beide Testfälle zu garantieren, vermeidet Fehlerquellen in der Bewertungskonfiguration. Dennoch bleibt diese Vorgehensweise fakultativ und wird durch ADAF nur ermöglicht, aber nicht vorgeschrieben. Die gleichzeitige Ausführung von System und Bewertung innerhalb derselben ADAF-Instanz ist ebenfalls möglich. 7.6 Fazit Die in diesem Kapitel dokumentierten Anwendungsbeispiele aus der Praxis demonstrieren die Leistungsfähigkeit und Flexibilität des entwickelten Frameworks. Sie verdeutlichen wie ADAF die effiziente Umsetzung der großen Bandbreite der aufgabenspezifischen Anforderungen ermöglicht hat. Insbesondere die modulare Architektur sowie die durch das Framework etablierte Abstraktion von Datenfluss und Datenverarbeitung beschleunigen und vereinfachen die Durchführung neuer Projekte. Die Aufnahme von Daten, auch in komplexen Sensorkonfigurationen mit hoher Datenrate, bildet die Grundlage für die Entwicklung und Bewertung von Applikationen. Der durch ADAF bereitgestellte Rahmen und die Wiederverwendbarkeit vorhandener Plugins ermöglichen die effiziente und zielgerichtete Entwicklung neuer Verfahren und Komponenten. Bestehende Konfigurationen können durch zusätzliche Plugins erweitert werden und so die Verarbeitung an neue Fragestellungen angepasst werden. In Verbindung mit NISYS TRS konnte durch Verwendung des Frameworks erfolgreich ein eingreifendes System realisiert und bewertet werden. 139

150

151 8 Erstellung eines Verkehrszeichenbenchmarks In Abschnitt wurde der Bedarf an Benchmarkdatensätzen zur Vergleichbarkeit von Algorithmen und Systemen erläutert. In diesem Kapitel wird die Erstellung eines solchen Datensatzes für das Problem der Verkehrszeichenerkennung beschrieben. Dies umfasst insbesondere die Darlegung der relevanten Designentscheidungen sowie der technischen Realisierung. ADAF wurde im Rahmen dieses Projekts vorrangig zur Datenakquisition und Annotation verwendet. 8.1 Motivation Der Bedarf an öffentlich verfügbaren Benchmarkdatensätzen wird auch dadurch nicht beschränkt, dass je nach Fahrzeugklasse bereits Systeme zur Verkehrszeichenerkennung am Markt erhältlich sind. Die kommerziell verfügbaren Systeme sind in der Regel auf wenige Schilderklassen beschränkt. Üblich ist die Erkennung der aktuellen Geschwindigkeitsbegrenzung sowie teilweise von Überholverboten. Zusatzschilder, die die Gültigkeit der Vorschriftzeichen einschränken können (z. B. bei Nässe oder 22-6 Uhr ) werden je nach System in unterschiedlichem Umfang erkannt. Geschwindigkeitsbegrenzungen machen jedoch nur einen Teil der Verkehrszeichen aus. Daher ist Verkehrszeichenerkennung weiterhin Gegenstand der Forschung. Leider ist es sehr schwer, die berichteten Ergebnisse verschiedener Forschungsgruppen zu vergleichen. Oft werden neue Algorithmen und Ansätze auf eigenen Datensätzen sehr variablen Umfangs getestet und bewertet. Dies verhindert eine Vergleichbarkeit unterschiedlicher Ansätze, da unklar ist, wie die Ergebnisse durch die konkrete Auswahl der Testdaten beeinflusst wurden. Wird der Datensatz nicht öffentlich zur Verfügung gestellt, ist auch eine Reproduktion der Testergebnisse und die Bewertung weiterer Verfahren nicht möglich. Hinzu kommt, dass die unterschiedlichen Ansätze oft auch unterschiedliche Teilbereiche des Problems Verkehrszeichenerkennung bearbeiten. Während manche Systeme die vollständige Aufgabenkette von Detektion, Klassifikation und Tracking bearbeiten, beschränken sich andere Ansätze entweder auf eine der Teilaufgaben oder auf eine Teilmenge der Verkehrszeichen wie z. B. Geschwindigkeitsbegrenzungen. Zum Zeitpunkt der Erstellung dieses Benchmarks waren keine weiteren Datensätze vergleichbaren Umfangs verfügbar. Der vorliegende Benchmark wurde unter dem Namen German Traffic Sign Recognition Benchmark (GTSRB) im Rahmen eines Wettbewerbs während der IEEE International Joint Conference on Neural Networks (IJCNN) 2011 vorgestellt [SSSI11; SSSI12]. 141

152 8 Erstellung eines Verkehrszeichenbenchmarks Zweck des Datensatzes Eine Objekterkennung im allgemeinen und eine Verkehrszeichenerkennung im Speziellen erfordert üblicherweise zunächst die Detektion von möglichen Kandidaten im Bild. Diesen wird anschließend durch Klassifikation eine der möglichen Klassen zugeordnet. Die Klassifikation ist also zentraler Bestandteil einer Verkehrszeichenerkennung. Ziel des Datensatzes ist eine Vergleichsbasis für Algorithmen zur Klassifikation von Verkehrszeichen zu schaffen. Die Teilaufgabe der Detektion wird dabei nicht berücksichtigt. Hierfür wird in [Hou+13] ein dedizierter Datensatz auf Basis derselben Rohdaten zusammengestellt (s. Abschnitt 8.5.3). Eine mögliche Stabilisierung von Klassifikationshypothesen durch zeitliche Integration von Einzelergebnissen aufeinanderfolgender Bilder soll ebenfalls unberücksichtigt bleiben, um den Fokus auf die reine Klassifikationsleistung des Ansatzes zu legen. 8.2 Benchmarkdesign Die Erstellung eines Benchmarkdatensatzes erfordert die Beantwortung zahlreicher Fragestellungen. Wie kann der beabsichtigte Zweck realisiert werden? Welche Daten sind enthalten? Wie ist der Datensatz organisiert? Auf welcher Bewertungsgrundlage werden verschiedene Verfahren verglichen? Diese Entscheidungen steuern den Entwurf und werden im Folgenden diskutiert Entwurfsziele Der Datensatz soll als Referenzdatensatz zum objektiven Vergleich aktueller und zukünftiger Verkehrszeichenerkennungsalgorithmen dienen. Dazu ist eine möglichst hohe Verbreitung des Datensatzes notwendig. Daher soll durch eine möglichst niedrige technische Nutzungshürde eine leichte Integration in vorhandene Prozesse ermöglicht werden. Die Datenformate sind so zu wählen, dass sie durch ein möglichst breites Spektrum von Programmiersprachen und -umgebungen genutzt werden können. Insbesondere sollen keine sprachabhängigen Bibliotheken notwendig sein, um auf die Daten zuzugreifen. Der Zugriff auf Bild- und Referenzdaten soll auch mit grundlegenden Programmierkenntnissen möglich sein. Dies ermöglicht insbesondere die Verwendung des Datensatzes in der Lehre Art des Datensatzes Der Datensatz besteht aus Einzelbildern. Diese enthalten zentral ein einzelnes Verkehrszeichen. Um den Einsatz kanten- und umrissbasierter Verfahren zu ermöglichen, enthalten die Bilder außerdem einen Rand von 10 % der Schildbreite bzw. -höhe (mindestens jedoch 5 Pixel) in jede Richtung. Je nach Entfernung des Schildes während der Aufnahme variieren die Bilder in der Größe. Auf eine Anpassung auf eine feste Größe wird verzichtet, da unterschiedliche Verfahren unterschiedliche Anforderungen an die Dimensionen der 142

153 8.2 Benchmarkdesign Abbildung 8.1: Einige Beispiele Eingangsdaten stellen. Im Bedarfsfall ist eine Anpassung durch den Verwender leicht durchführbar. Die Einzelbilder werden im PPM-Format (Portable Pixmap) gespeichert. Dieses Format zeichnet sich durch seine einfach Dateistruktur und somit generische Verwendbarkeit aus. Der Dateikopf enthält außer einer Formatversion nur die Bildgröße sowie die Farbtiefe als Klartext. Anschließend folgen direkt die einzelnen Pixelwerte in Binärform. Die Referenzdaten (Dateiname, Position und Größe des Schildes im Bild, Klasse des Verkehrsschildes) werden als Textdatei im CSV-Format (Comma-separated Values) bereitgestellt. Die Zuordnung einzelner Bilder zu einem Teildatensatz (Training, Validierung, Test, s. Abschnitt 8.2.5) bzw. zu einzelnen Klassen geschieht durch Verzeichnisse Umfang des Datensatzes Verschiedene Verkehrsschilder kommen mit unterschiedlicher Häufigkeit im Straßenverkehr vor. Dies wird im Datensatz sowohl durch die Anzahl der enthaltenen Klassen als auch durch die stark unterschiedliche Größe der einzelnen Klassen abgebildet. Die Anzahl der enthaltenen Klassen wurde daher vorab nur ungefähr festgelegt. Die letztendlich enthaltenen 43 Klassen entsprechen den 43 häufigsten Verkehrsschildern in den Rohdaten, die in alltäglichen Verkehrssituationen aufgezeichnet wurden (s. Abschnitt 8.3.1). Informationen über Aufstellungsorte bestimmter Verkehrsschilder waren auch bei den Behörden nicht erhältlich. Daher wäre eine gezielte Aufnahme bestimmter Schilderklassen nicht möglich gewesen. Die Zielgröße des Datensatzes wurde auf mindestens Einzelbilder festgesetzt, um den Datensatz auch in Bezug auf die benötigten Ressourcen beim Training anspruchsvoll zu gestalten. 143

154 8 Erstellung eines Verkehrszeichenbenchmarks Abbildung 8.2: Der Track eines Verkehrszeichens. Er enthält mehrere Bilder einer einzelnen Verkehrszeicheninstanz Struktur des Datensatzes Durch die Aufzeichnung von Videosequenzen während der Sensordatenakquisition (s. Abschnitt 8.3.1) entstehen von jeder Instanz eines Verkehrszeichens also eines bestimmten, physischen Schildes mehrere Bilder. Die Anzahl hängt von der Geschwindigkeit ab, mit der das Schild vom Aufnahmefahrzeug passiert wird. Die Gesamtheit der Bilder einer Verkehrszeicheninstanz werden als Track bezeichnet. Um eine Unabhängigkeit der einzelnen Elemente des Datensatzes voneinander zu gewährleisten, soll jede Instanz grundsätzlich nur einmal im gesamten Datensatz vertreten sein. Wenn jedoch von jeder Instanz nur ein einzelnes Bild im Datensatz enthalten sein darf, ist eine sehr große Rohdatenmenge notwendig, um die Zielgröße des Datensatzes zu erreichen. Wie in Abbildung 8.2 zu sehen, kann das Aussehen eines Verkehrszeichens im Trackverlauf stark variieren: große Unterschiede in der Auflösung, partielle Verdeckungen, steigende Bewegungsunschärfe für nähere Verkehrsschilder oder eine Veränderung des Hintergrunds durch Perspektivänderung. Dies ermöglicht einen Kompromiss. Von jeder Instanz werden statt eines einzelnen Bildes mehrere Bilder des Tracks verwendet und somit auch die genannten Variationen erfasst. Die Länge eines Tracks hängt von der Fahrgeschwindigkeit während der Erfassung ab. Um eine Verzerrung durch unterschiedliche Tracklängen zu verhindern, wird je Track eine feste Anzahl Bilder äquidistant gesampelt. Dadurch reduziert sich die Menge der benötigten Rohdaten drastisch bei einer gleichzeitigen Erhöhung der Variation im Datensatz Aufteilung des Datensatzes Der Benchmark selbst, also die vergleichende Bewertung mehrerer Verfahren, wird nur auf einem Teil der Daten, dem Testdatensatz, durchgeführt. Der größere Teil der Daten steht zum Training eines Klassifikators zur Verfügung. Der Testdatensatz repräsentiert 144

155 8.2 Benchmarkdesign Trainingsdaten Validierungsdaten 50 % 25 % Gesamttrainingsdaten 25 % Testdaten Abbildung 8.3: Aufteilung des Datensatzes neue, ungesehene Daten, wie sie dem System auch bei einem späteren Praxiseinsatz begegnen würden. Diese Daten sollen nur einmal je Verfahren genutzt werden. Bei nachfolgenden Änderungen des Algorithmus oder seiner Parameter besteht die Gefahr, dass Verbesserungen der Erkennungsleistung spezifisch für diesen Datensatz sind und sich nicht auf neue Daten übertragen lassen und dort u. U. sogar zu Verschlechterungen führen. Dieser Effekt wird auch als overfitting bezeichnet. Um dies zu verhindern, aber dennoch die Möglichkeit der Parameteroptimierung zu erhalten, ist bei vielen Verfahren eine Aufteilung der Trainingsdaten üblich. Ein Teil wird zum eigentlichen Training verwendet. Der andere Teil dient als Validierungsdatensatz zur Bewertung der aktuellen Konfiguration. Der ursprüngliche Testdatensatz bleibt so für die abschließende Bewertung verfügbar. Da die Klassen in diesem Datensatz unterschiedliche Häufigkeiten aufweisen, muss bei einer Aufteilung sichergestellt werden, dass die einzelnen Teildatensätze eine vergleichbare Verteilung aufweisen. Eine rein zufällige Aufteilung birgt die Gefahr, dass manche Klassen potenziell in einem der Datensätze überrepräsentiert oder gar nicht vorhanden sind. Dies würde die Ergebnisse verfälschen. Des Weiteren muss sichergestellt werden, dass alle Bilder eines Tracks und somit einer Verkehrszeicheninstanz vollständig einem der Datensätze zugewiesen und nicht zwischen den Datensätzen aufgeteilt werden. So wird eine Unabhängigkeit der unterschiedlichen Datensätze voneinander gewährleistet. Der Gesamtdatensatz wird gemäß Abbildung 8.3 partitioniert. Dadurch entstehen folgende Teildatensätze: Training Datensatz für die Entwicklung des Algorithmus und zum Training maschineller Lernverfahren. Der Datensatz ist klassenweise in Verzeichnisse sortiert (s. Abbildung 8.4a). Jedes Verzeichnis enthält eine Datei GT-<Klassen-ID>.csv mit den Referenzdaten für alle Elemente dieser Klasse. Validierung Datensatz zur Parameteranpassung und Vermeidung von overfitting. Die Struktur entspricht der des Trainingsdatensatzes. Sollte ein Verfahren keine Validierungsdaten benötigen, können diese Daten als zusätzliche Trainingsdaten genutzt werden. Test Datensatz zur abschließenden Bewertung des Verfahrens. Im Gegensatz zu den Trainings- und Validierungsdaten sind die Bilder in diesem Datensatz nicht sortiert, sondern track- und klassenübergreifend gemischt und aufsteigend nummeriert (s. Abbildung 8.4b). Dadurch wird eine Nutzung der Trackinformationen durch ein Verfahren unterbunden und eine Einzelbildklassifikation sichergestellt. 145

156 8 Erstellung eines Verkehrszeichenbenchmarks GT csv 00000_00000.ppm 00000_00001.ppm 00000_00002.ppm _00029.ppm 00001_00000.ppm 00001_00001.ppm (a) Training und Validierung ppm ppm ppm... (b) Test Abbildung 8.4: Verzeichnisstruktur der Teildatensätze Bewertungsgrundlage Um einen Vergleich der Ergebnisse unterschiedlicher Ansätze und Verfahren zu ermöglichen, ist zusätzlich zur Verfügbarkeit der Daten auch eine standardisierte Bewertungsmethode notwendig. Der Schwerpunkt des GTSRB liegt auf der korrekten Klassifikation der Einzelbilder. Eine Bewertung der benötigten Ressourcen (Ausführungszeit, Speicherumfang) wird nicht berücksichtigt, da diese stark von der verwendeten Hardware und Programmiersprache abhängen. Des Weiteren sorgen eine konstante Weiterentwicklung der Prozessoren, Rechnerarchitekturen und Compiler dafür, dass solche Messwerte im Moment ihrer Veröffentlichung bereits veraltet sind. Die Bewertung der Klassifikation basiert auf der 0/1-Verlustfunktion. Der Klassifikationsfehler e i bzgl. eines Elements i des Datensatzes D mit echter Klasse x i und geschätzter Klasse ˆx i wird definiert als e i = 1 xi ˆx i 0 sonst. Die Gesamtfehlerrate e(d) auf dem vollständigen Datensatz ergibt sich daher als e(d) = 1 D (8.1) e i. (8.2) Jede Fehlklassifikation geht also mit gleichem Gewicht in die Gesamtfehlerrate ein. Von einer höheren Gewichtung einzelner Klassen wird abgesehen, da alle Verkehrszeichen als gleich wichtig erachtet werden. Eine Gewichtung nach Häufigkeit der Klassen findet nicht statt. Trotz des Umfangs des Datensatzes kann er doch nur eine Stichprobe der Verteilung der Verkehrszeichenhäufigkeiten darstellen. Dabei ist diese nur theoretischer Natur, da eine globale Verteilung nur einen Mittelwert darstellen kann und sich lokal i D 146

157 8.3 Erstellung des Datensatzes Abbildung 8.5: Beispielbilder der aus den Videodaten [Hou+13]. abhängig von der Umgebung (Stadt, Land, Autobahn) starke Abweichungen ergeben. Grundsätzlich müssen alle Verkehrszeichen korrekt erkannt werden, unabhängig von ihrer Häufigkeit und ihrer Klasse. Die Klassifikationsrate c ergibt sich als c(d) = 1 e(d) (8.3) Die auf dem Testdatensatz berechnete Klassifikationsrate dient als Vergleichsbasis im Rahmen des Benchmarks. 8.3 Erstellung des Datensatzes Neben erörterten theoretischen Fragestellungen zu Struktur und Inhalt des Datensatzes ist auch die Frage der technischen Realisierung relevant. Erfassung, Annotation und Selektion relevanter Daten konstituieren umfangreiche Aufgaben. Diese werden im vorliegenden Abschnitt erläutert. Die Verwendung von ADAF ermöglichte eine effiziente Erhebung der Sensor- und Referenzdaten sowie die Erstellung des Rohdatensatzes. Abschließende Schritte zur Organisation des Datensatzes wurden außerhalb von ADAF durchgeführt Aufnahme der Rohdaten Als Grundlage zur Erstellung des GTSRB-Datensatzes wurden im alltäglichen Straßenverkehr Videosequenzen aufgezeichnet. Dazu wurde eine Kamera des Modells Prosilica 1 GC1380H verwendet. Sie wurde in der Nähe des Rückspiegels an der Windschutzscheibe befestigt. Die Kamera wurde mit automatischer Belichtungssteuerung und einer Bildrate von 25 fps betrieben. Die Auflösung betrug Pixel, wobei die Daten als Bayer-Pattern gespeichert werden. Die Kamera wurde per Gigabit-Ethernet angeschlossen. Abbildung 8.5 zeigt einige Beispielaufnahmen. Zusätzlich zu den Bilddaten wurden auch GPS-Daten aufgezeichnet, um die Daten auch später noch örtlich zuordnen zu können. 1 heute: Allied Vision Technologies 147

158 8 Erstellung eines Verkehrszeichenbenchmarks 2D_Display (2DMDisplay) Camera (AVTMGigEMVisionMSensor) HDF_Recorder (HDFMRecorder) GPS_Sensor (GPSMSensor) GPS_Signal_Display (GPSMSignalMDisplay) Map_Display (MapMDisplay) (a) Applikationsprofil für die Aufnahme. (b) ADAF im Betrieb. Abbildung 8.6: Aufnahmeszenario in ADAF Als GPS-Empfänger kam ein per USB angeschlossener Navilock NL-402U Receiver zum Einsatz. In drei Aufnahmeblöcken (März, Oktober und November 2010) wurden insgesamt ca. 10 Stunden Videomaterial aufgezeichnet. Das Material besteht aus Fahrabschnitten unterschiedlicher Länge. Zur Effizienzsteigerung des Akquisitionsprozesses (und vor allem der anschließend notwendigen Annotation, s. Abschnitt 8.3.2) wurde die Aufnahme abhängig von der Präsenz von Verkehrszeichen in der aktuellen Verkehrssituation durch den Beifahrer gezielt aktiviert oder deaktiviert. Dies erhöht die Verkehrszeichendichte in den Rohdaten und vermeidet lange Streckenabschnitte ohne Verkehrszeichen, die für die Aufgabenstellung eines Klassifikationsbenchmarks nicht relevant sind. Die Aktivierung des Aufnahmesystems nach Sicht des Beifahrers ist legitim, da das menschliche Auge die Schilder früher wahrnimmt als sie bei der verfügbaren Kameraauflösung in verwertbarer Auflösung vorliegen würden. Die Aufzeichnung der Daten erfolgte mit einem handelsüblichen Laptop und ADAF mit dem in Abbildung 8.6a abgebildeten Applikationsprofil. Dies enthält je ein Sensorplugin für den Zugriff auf Kamera und GPS-Empfänger sowie das HDF Recorder-Plugin zur Aufzeichnung der Daten auf der Festplatte. Ein 2D Display-Plugin dient zur Darstellung und Kontrolle des Kamerabildes, ein weiteres Plugin zur Visualisierung des GPS-Signals. Die Benutzeroberfläche ist in Abbildung 8.6b dargestellt. Die Datenrate betrug ca. 34 MB/s. Dadurch war eine Speicherung auf der lokalen Laptopfestplatte möglich und es konnte auf eine externe Speicherlösung verzichtet werden Annotation der Daten Die Annotation der Daten erfolgte ebenfalls durch Nutzung von ADAF. Die Daten wurden dabei einerseits global also pro Sequenz und andererseits auf Objektebene jedes einzelne Verkehrszeichen in jedem Einzelbild annotiert. 148

159 8.3 Erstellung des Datensatzes Vorgehen Die Annotation einer Sequenz wurde jeweils auf zwei Personen verteilt. Eine Person annotierte die Daten, eine zweite kontrollierte das Ergebnis. Die zu annotierenden Sequenzen wurden dabei nicht kontingentiert und vorab einzelnen Personen fest zur Bearbeitung zugewiesen. Wer mit der Bearbeitung begann, wählte eine freie Sequenz aus und übernahm sie. Nach Fertigstellung der Annotation wurde sie zur Kontrolle freigegeben. Traten bei der Kontrolle Mängel auf, wurde die Sequenz an die ursprünglich bearbeitende Person zurückgegeben Annotation auf globaler Ebene Zusätzlich zur Speicherung allgemeiner Informationen über die Aufnahmesituation wurden die Attribute auf globaler Ebene zur Verwaltung des Annotationsprozesses verwendet. Folgende Attribute wurden vergeben (In Klammern wird der jeweilige Typ des Attributs angegeben.): LicensePlate (Auswahlliste) Das Kennzeichen des Fahrzeugs mit dem die Aufnahme durchgeführt wurde. Country (Auswahlliste) Das Land in dem die Fahrt durchgeführt wurde. Der aktuelle Datensatz beschränkt sich zwar auf Deutschland, dieses Attribut ermöglicht jedoch bei einer zukünftigen Erweiterung des Datensatzes eine gezielte Auswahl länderspezifischer Verkehrsszenarien. Labeler (Auswahlliste) Der Name der Person, die diese Sequenz annotiert hat. Done (Checkbox) Diese Markierung wird gesetzt, sobald eine Sequenz vollständig annotiert wurde. Checked by (Auswahlliste) Der Name der Person, die die Sequenz geprüft hat. Die Attribute LicensePlate und Country stellen allgemeine Informationen dar, die zwar im Rahmen des GTSRB nicht benötigt wurden, aber dazu dienen, die hier gesammelten Daten zu bereits vorhandenen Daten konsistent zu halten. Die weiteren Attribute dienten zur Steuerung des Annotationsprozesses, der sich wie folgt gestaltete: 1. Die annotierende Person übernimmt eine freie, von niemandem bearbeitete Sequenz, indem sie sich unter dem Attribut Labeler einträgt. 2. Die Person bearbeitet die Sequenz und annotiert sämtliche Verkehrszeichen. 3. Nach Abschluss der Bearbeitung markiert sie die Sequenz mit Done. 4. Die kontrollierende Person übernimmt eine als fertig markiert Sequenz und trägt sich unter Checked by ein. 149

160 8 Erstellung eines Verkehrszeichenbenchmarks 5. Bei Mängeln entfernt sie die Done-Markierung. Dadurch wird die Sequenz an die annotierende Person zurückgegeben. 6. Bei Bemängelung entfernt die annotierende Person den Namen der Kontrollperson und fährt mit Schritt 2 fort, ansonsten mit Schritt 1. Durch dieses Vorgehen ist pro Person immer nur eine Sequenz blockiert, die dann keiner anderen Person zur Bearbeitung zur Verfügung steht. Durch die Stückelung der Akquisitionsfahrt in einzelne Aufzeichnungen von wenigen Minuten Länge betrifft diese Exklusivzuteilung immer nur einen kleinen Teil des Datenbestandes. Dieser Prozess ermöglicht eine sehr flexible Bearbeitung des Datenbestands und eine optimale Nutzung der verfügbaren Personalressourcen. Außerdem wird eine gleichzeitige Bearbeitung von Sequenzen effektiv ausgeschlossen. Zusätzlich zur freien Einteilung der unbearbeiteten Sequenzen ist auch die Aufgabenverteilung von Annotation und Kontrolle flexibel. Bei der Erstellung des GTSRB-Datensatzes waren alle beteiligten Personen sowohl berechtigt zu annotieren als auch von anderen Personen annotierte Sequenzen zu kontrollieren Annotation auf Objektebene Die Annotation auf Objektebene ist der aufwendigste Schritt in der Erstellung des Datensatzes. In jedem einzelnen der ca Einzelbilder muss jedes sichtbare Verkehrszeichen markiert werden. Durch die Markierung eines Objektes im Bild wird seine Größe und Position festgehalten. Aufeinanderfolgende Markierungen des gleichen Objektes werden in einem Track gruppiert. Folgende Attribute wurden für jedes markierte Objekt vergeben: Verkehrszeichentyp (Auswahlliste) Die Bezeichnung des Verkehrszeichens entspricht der Klasse und ist somit das wichtigste Attribut. Sichtbarkeit (Auswahlliste) Dieses Attribut beschreibt, ob das Verkehrszeichen vollständig lesbar oder ggf. teilweise verdeckt oder unlesbar ist. Es wurde vorausschauend annotiert, um bei ausreichender Anzahl verdeckter oder nur teilweise lesbarer Verkehrszeichen für weitergehende Experimente gezielt eine schwierigere Untermenge identifizieren zu können. Relevanz (Auswahlliste) Dieses Attribut beschreibt, ob die Bedeutung des Verkehrszeichens für das eigenen Fahrzeug relevant ist. Wenn ein System zur Verkehrszeichenerkennung entscheiden muss, ob eine bestimmtes Verkehrszeichen vom Fahrer beachtet werden muss oder nicht, ist dieses Attribut für die Bewertung des Systems notwendig. Im Rahmen des GTSRB wurde es nicht ausgewertet. Unvollständig (Checkbox) Hierbei handelt es sich um eine Verwaltungsinformation, um unvollständig annotierte Tracks zu markieren. So sind diese zu einem späteren Zeitpunkt leichter auffindbar. 150

161 8.3 Erstellung des Datensatzes Abbildung 8.7: Objektbasierte Annotation von Verkehrszeichen in ADAF. Manche Attribute sind bezogen auf einen Track konstant, andere können unterschiedliche Werte annehmen. Während sich der Typ eines Verkehrszeichen nicht ändert, kann ein Schild zeitweise ganz oder teilweise verdeckt sein. Der Annotationsprozess auf Objektebene stellt hohe Anforderungen an die Konzentration. Daher werden alle Verkehrszeicheninstanzen in einer Sequenz seriell bearbeitet, auch wenn mehrere Verkehrszeichen gleichzeitig im Bild zu sehen sind. Bedingt durch die Vorwärtsfahrt des Aufnahmefahrzeugs sind die Verkehrszeichen üblicherweise sehr klein, wenn sie das erste Mal sichtbar sind, und werden größer bis das Fahrzeug sie passiert. Durch die initial geringe Auflösung ist es schwierig, den Umriss des Objektes und vor allem den genauen Typ zu bestimmen. Daher wird empfohlen, rückwärts zu annotieren. Dazu wird die Sequenz zwar vorwärts abgespielt, die Annotation beginnt aber jeweils beim letzten Bild, in dem das Verkehrszeichen noch sichtbar ist, anstatt beim ersten, in dem es schon sichtbar ist. Von dort bewegt man sich rückwärts durch die Sequenz bis das Schild in der Entfernung nicht mehr zu erkennen ist bzw. eine minimale Größe von unterschreitet. Anschließend wird die Sequenz wieder bis zum nächsten Verkehrszeichen vorwärts abgespielt. Dieses Vorgehen birgt zwei entscheidende Vorteile. Erstens ist der Typ des Verkehrszeichens kurz bevor das Fahrzeug es passiert gut zu erkennen. Zweitens kann beim erneuten Vorwärtsabspielen nach Abschluss eines Tracks direkt eine Kontrolle erfolgen. Auf diese Weise wurden ca Verkehrszeichenbilder in Tracks 70 verschiedener Klassen annotiert. Die Benutzeroberfläche während der Annotation ist in Abbildung 8.7 dargestellt. 151

162 8 Erstellung eines Verkehrszeichenbenchmarks Bayer2RGB (BayerLToLRGBLPlugin) Display (VideoLDisplay) Camera (GigELLVisionLSensor) ROILAnnotation (ROILLabelingLPlugin) Extract (ImageExtractorPlugin) Abbildung 8.8: Applikationsprofil zur Extraktion der Einzelbilder Extraktion der Einzelbilder Die Annotationen wurden genutzt, um die Einzelbilder der Verkehrszeichen aus den Gesamtbildern zu extrahieren. Dies geschah in einem vollautomatischen Durchlauf durch alle Sequenzen mittels des Applikationsprofils in Abbildung 8.8. Dazu wurden durch das Objektannotationsplugin ROI Labeling Plugin beim Öffnen einer Sequenz automatisch die zugehörigen Annotationsdaten aus der Datenbank geladen. Während der Verarbeitung der Sequenz stellte das Plugin über einen Ausgabepin dem Image Extractor Plugin jeweils die zum aktuellen Bild gehörenden Daten zur Verfügung. Zusätzlich war das Image Extractor Plugin über das Bayer To RGB Plugin mit dem Kamerasensor GigE Vision Sensor verbunden und erhielt so das jeweils aktuelle in den RGB-Farbraum konvertierte Bild. Basierend auf der Annotation extrahierte das Plugin den Bereich des Verkehrszeichens. Dabei wurde ein parametrierbarer Rand um die eigentliche ROI mit eingeschlossen. Die Bezeichnung des Verkehrszeichentyps wurde in eine numerische Klassen-ID übersetzt und das Bild in der nach Klassen sortierten Verzeichnisstruktur als <TrackID>_<laufende_Nummer>.png gespeichert. Gleichzeitig wurden auch die zugehörigen Referenzdaten Dateiname Breite des Bildes Höhe des Bildes Position der linken, oberen Ecke der ROI im Bild Position der rechten, unteren Ecke der ROI im Bild Klassen-ID als CSV-Datei im jeweiligen Klassenverzeichnis abgelegt. Die Extraktion erforderte keinerlei Überwachung. Da der Prozess nicht auf eine Echtzeitdurchführung angewiesen war, konnte er in Überechtzeit ausgeführt werden und benötigt so nur einen Bruchteil der eigentlichen Aufzeichnungslänge von ca. 10 Stunden. 152

163 8.4 Der Datensatz Bereinigung und Aufteilung des Datensatzes Nach der Extraktion aller Verkehrsschilder aus den Videodaten musste der Gesamtbestand noch bereinigt und in die verschiedenen Teildatensätzen aufgeteilt werden. Aufgrund der Verlagerung des Prozesses von Videosequenzen auf Einzelbilder wurde dieser Schritt außerhalb von ADAF skriptgesteuert mit Python durchgeführt. Die Bereinigung entfernte alle Tracks und Klassen für die nicht genügend Daten vorlagen. Für Tracks lag die Grenze bei der Ziellänge von 30 Bildern pro Track. Kürzere Tracks wurden verworfen. Alle Klassen mit weniger als neun Tracks wurden ebenfalls entfernt, um nach der Aufteilung in drei Partitionen sicherzustellen, dass jede Klasse in jeder Partition vorhanden ist und um hier auch noch Spielraum für Variationen im Aussehen des Verkehrszeichens einzuräumen. So konnte selbst für die kleinsten Klassen sichergestellt werden, dass mindestens zwei Tracks in jedem Datensatz enthalten sind. Tracks mit mehr als 30 Bildern wurden äquidistant gesampelt. Abschließend wurden die Klassen, Tracks und Einzelbilder umbenannt, um eine durchgehende Nummerierung zu gewährleisten. Dies ermöglicht es dem Nutzer des Datensatzes, über einfache Zähler auf alle Dateien zuzugreifen, ohne dateisystemspezifische Aufrufe verwenden zu müssen. Zusätzlich wurden die CSV-Dateien mit den Referenzdaten der einzelnen Bilder klassenweise zu einer einzelnen Datei zusammengefasst. Im Testdatensatz wurde die Trackund Klassenzuordnung aufgelöst und alle Bilder aufsteigend in zufälliger Reihenfolge nummeriert. 8.4 Der Datensatz Der Datensatz enthält insgesamt Einzelbilder von unterschiedlichen Verkehrszeichen in 43 Klassen. Abbildung 8.9 zeigt eine Übersicht dieser Klassen. Der Trainingsdatensatz enthält Bilder, der Validierungsdatensatz Bilder und der Testdatensatz Bilder. Dies entspricht 51,45 %, 24,17 % respektive 24,38 % des Gesamtdatensatzes. Die leichten Abweichungen gegenüber der definierten Aufteilung von 50/25/25 für Training/Validierung/Test ergeben sich durch die klassenweise Aufteilung des Datensatzes (s. Abschnitt 8.2.5). Die relative Häufigkeit der einzelnen Klassen ist in Abbildung 8.10 dargestellt und verdeutlicht die starken Unterschiede zwischen den einzelnen Klassen. Die Schilder haben eine Größe von bis Pixel (zzgl. Rand, s. Abschnitt 8.2.2). 8.5 Verwendung des Datensatzes Im Folgenden wird darauf eingegangen, wie der vorliegende Datensatz bzw. die ihm zugrunde liegenden Rohdaten in der Praxis verwendet wurden. 153

164 8 Erstellung eines Verkehrszeichenbenchmarks Abbildung 8.9: Zufällige Repräsentanten der 43 im GTSRB enthaltenen Verkehrszeichenklassen [SSSI12]. Abbildung 8.10: Relative Klassenhäufigkeiten im Datensatz. Die Klassen-ID ergibt sich durch aufsteigende Nummerierung der Verkehrszeichenklassen gemäß Abbildung 8.9 zeilenweise von oben links nach unten rechts [SSSI12]. 154

165 8.5 Verwendung des Datensatzes Trainingsdaten Testdaten unveröffentlicht 50 % 25 % 25 % Abbildung 8.11: Datensatz für Runde 1 des GTSRB-Wettbewerbs. Die Aufteilung entspricht der des Gesamtdatensatzes in Abbildung GTSRB-Wettbewerb Der GTSRB-Datensatz wurde im Vorfeld der IEEE International Joint Conference on Neural Networks (IJCNN) 2011 veröffentlicht [SSSI11; SSSI12]. Er diente als Grundlage des gleichnamigen Wettbewerbs. Gemäß der Struktur des Datensatzes bestand die Aufgabe für die Teilnehmer darin, die Einzelbilder des Testdatensatzes korrekt zu klassifizieren. Üblicherweise werden Wettbewerbe im Vorfeld einer Konferenz durchgeführt, sodass Methoden und erzielte Ergebnisse im Rahmen der Konferenz präsentiert werden können. Im Falle eines Klassifikationswettbewerbs ist es geboten, die GT-Daten des Testdatensatzes, also die wahren Klassen der enthaltenen Verkehrszeichen, zurückzuhalten, um einen fairen Wettbewerb zu garantieren. Da es sich in diesem Fall bei den Testdaten allerdings um Bilddaten handelte, bestand hier grundsätzlich die Möglichkeit, dass Teilnehmer die fehlenden GT-Daten durch manuelles Sortieren selbst erzeugen und sich so einen unerlaubten Vorteil verschaffen, entweder durch Einreichung manipulierter Ergebnisse oder durch Optimierung der Parameter für den Testdatensatz. 2 Wie bereits in Abschnitt erläutert, führt dies jedoch zu einer unerwünschten Überanpassung an den Testdatensatz und somit zu einer schlechteren Generalisierungsfähigkeit auf neuen, ungesehenen Daten. Um diese Gefahr zu unterbinden, wurde der Datensatz in zwei Stufen veröffentlicht und zwei Wettbewerbsrunden durchgeführt. Runde 1 fand im Vorfeld der Konferenz statt. Sie war für Teilnehmer weltweit geöffnet und bildete die Grundlage für die Erstellung der Konferenzbeiträge. Während der Konferenz wurde zur Ermittlung des Siegers Runde 2 des Wettbewerbs durchgeführt. Vor Ort mussten die anwesenden Teilnehmer einen neuen Datensatz klassifizieren. Dadurch bestand keine Möglichkeit, die Testdaten manuell zu klassifizieren und so die Ergebnisse zu manipulieren. In Runde 1 wurden nur die in Abbildung 8.11 aufgeführten Teile bereitgestellt. Zunächst wurden nur die Trainingsdaten veröffentlicht, um eine Vorbereitung der Teilnehmer auf den Wettbewerb zu ermöglichen. Als Testdatensatz wurde der Validierungsdatensatz verwendet, wobei dieser entsprechend der Vorgaben des Testdatensatzes aufbereitet wurde: Die Klassen- und Trackzugehörigkeit wurde aufgelöst und die einzelnen Verkehrszeichenbilder in zufälliger Reihenfolge abgelegt. Dieser Datensatz wurde erst kurz vor Ende von Runde 1 veröffentlicht. So wurde das verfügbare Zeitfenster für eine manuelle Sortierung des umfangreichen Datensatzes stark reduziert. Nach Abschluss von Runde 1 wurden die GT-Daten sowie die sortierten Testdaten (als 2 Im Rahmen des Wettbewerbs durchgeführte Experimente zur menschlichen Erkennungsleistung haben allerdings ergeben, dass auch der Mensch nicht in der Lage ist, alle Bilder korrekt zuzuordnen. Details zu diesen Experimenten finden sich in [SSSI11; SSSI12] 155

166 8 Erstellung eines Verkehrszeichenbenchmarks Validierungsdatensatz) veröffentlicht, um den Teilnehmern eine gezielte Fehleranalyse zu ermöglichen. Trainings- und Validierungsdatensatz standen somit als Gesamttrainingsdaten zur Vorbereitung auf Runde 2 zur Verfügung. Während der Konferenz wurde der eigentliche Testdatensatz veröffentlicht und von anwesenden Teilnehmern vor Ort klassifiziert. Auch hierfür wurden nach Abschluss der Auswertung die GT-Daten bereitgestellt. Die Bereitstellung der Daten und die Durchführung des Wettbewerbs wurde über eine eigene Webseite 3 organisiert. Sie ermöglichte den Teilnehmern die Übermittlung ihrer Ergebnisse, die dann automatisch ausgewertet und nach Klassifikationsrate sortiert veröffentlicht wurden. Dadurch erhielten die Teilnehmer direktes Feedback über ihre Leistung im Vergleich zu anderen Teilnehmern. Die Übermittlung der Ergebnisse wurde gegenüber einer Einreichung des Programmcodes und einer Ausführung auf dem Server bevorzugt, da nur so die Flexibilität der Teilnehmer in der Wahl ihrer Methoden, Programmiersprachen, Hardwareanforderungen und Arbeitsumgebungen gewährleistet werden konnte. Im Anschluss an den Wettbewerb wurden Analysewerkzeuge auf der Webseite freigeschaltet. Neben der Einschränkung der Auswertung auf einzelne Schildergruppen (z. B. Geschwindigkeitsbegrenzungen oder Gefahrzeichen) ist auch die Erstellung einer Konfusionsmatrix möglich (s. Abbildung 8.12). Die Konfusionsmatrix hat die Dimension n n, wobei n der Anzahl der Klassen im Datensatz entspricht. Die Zeilen der Matrix entsprechen den wahren Klassen-IDs, die Spalten den vom Algorithmus erzeugten. Jeder Eintrag a i j, i, j = 1..n, entspricht der Summe der Klassifikationen eines Elements der Klasse i als Element der Klasse j. Einträge abseits der Diagonalen bedeuten somit Fehlklassifikationen. Im Fall einer Klassifikationsrate von c(d) = 1, d. h. einer fehlerfreien Klassifizierung aller Verkehrszeichen, ist die Konfusionsmatrix eine Diagonalmatrix, deren Elemente der Mächtigkeit der einzelnen Klassen entsprechen. Die Konfusionsmatrix erlaubt somit eine Analyse, welche Klassen besonders gut klassifiziert wurden und ob es Häufungen bestimmter Fehler gibt. Die Darstellung auf der Benchmark-Webseite hebt diese abhängig vom Betrag farblich hervor. Im Beispiel in Abbildung 8.12 ist eine Häufung in der linken oberen Ecke zu erkennen. Hierbei handelt es sich um die verschiedenen Geschwindigkeitsbegrenzungen. Da diese untereinander sehr ähnlich sind, war der Algorithmus in diesem Fall nicht in der Lage, alle Verkehrszeichen korrekt zu klassifizieren. In der rechten Abbildung ist die Verwechslung der 50 km/h - Begrenzung mit der 80 km/h -Begrenzung hervorgehoben. Eine Liste der fehlerhaft klassifizierten Bilder ermöglicht weitergehende Analysen. Sowohl die Konfusionsmatrix als auch die fehlerhaft klassifizierten Bilder stehen den Nutzern zum Herunterladen bereit, sodass sie mit eigenen Werkzeugen und Methoden ausgewertet werden können. Im Rahmen des Wettbewerbs wurden zusätzlich zu den Bilddaten auch vorberechnete Merkmale zur Verfügung gestellt. Dies ermöglicht eine breitere Beteiligung, insbesondere von Wissenschaftlern ohne Schwerpunkt in Bildverarbeitung. Des Weiteren ermöglichen auf Basis dieser Merkmale erzeugte Ergebnisse einen Vergleich der Klassifikatoren, da hier keine unterschiedliche Vorverarbeitung der Bilddaten Einfluss nehmen kann

167 8.5 Verwendung des Datensatzes Abbildung 8.12: Konfusionsmatrix auf der Webseite zur Analyse der Ergebnisse. Zeilen repräsentieren die wahren Klassen, Spalten die Klassifikationsergebnisse. Rechts ist ein vergrößerter Ausschnitt zu sehen. Für jede Zelle können Detailinformationen abgerufen werden. Folgende Merkmale wurden bereit gestellt: HOG-Merkmale Die auf Kanten basierenden HOG-Merkmale (Histogram of Oriented Gradients) wurden ursprünglich von [DT05] zur Fußgängerdetektion vorgestellt. Auf Basis der auf Grau- oder Farbbildern berechneten Gradienten werden innerhalb von Zellen aus benachbarten Pixeln lokale Orientierungshistogramme gebildet. Mehrere benachbarte Zellen werden zu einem Block, dem HOG-Deskriptor, zusammengefasst, indem die Histogramme der einzelnen Zellen aneinandergereiht werden. Der Vektor wird normalisiert, um Variationen in Belichtung und Kontrast auszugleichen. Sowohl für die Zellen also auch für die Blöcke gilt, dass sie rechteckig oder kreisförmig sein können. Die Blöcke überschneiden sich üblicherweise, sodass eine Zelle einen Beitrag zu mehreren Deskriptoren leistet, wobei sie jeweils in Bezug auf den jeweiligen Deskriptor normalisiert wird. Es wurden drei unterschiedlich parametrierte Sätze von HOG-Deskriptoren bereit gestellt, die sich in Zellgröße und Anzahl der berücksichtigten Orientierungen unterscheiden. Für alle Deskriptoren wurden die Bilder auf eine feste Größe von Pixel skaliert. Ursprünglich wurden HOG-Merkmale hauptsächlich für Detektionsaufgaben eingesetzt, was einer binären Klassifikationsaugabe entspricht. Nur vereinzelte Arbeiten haben vor Veröffentlichung des GTSRB HOG-Merkmale auch zur (Mehr-Klassen-) Klassifikation eingesetzt (z. B. [GN09]). Da die unterschiedlichen Verkehrszeichen durch ihre äußere Form und innere Ikonographie sehr deutliche Strukturen aufweisen, sind diese Merkmale auch zur Klassifikation geeignet. Abbildung 8.13 zeigt die Projektion des HOG 1 Trainingsdatensatzes auf die ersten zwei Hauptkomponenten. Hier wird ein deutlicher Einfluss der äußeren Form der Verkehrszeichen 157

168 8 Erstellung eines Verkehrszeichenbenchmarks Zweite Hauptomponente Rund Dreieck (nach oben) -4 Dreieck (nach unten) Raute Achteck Erste Hauptkomponente Abbildung 8.13: Projektion des HOG 1 Trainingsdatensatzes auf die ersten zwei Hauptkomponenten [SSSI12] sichtbar. Es zeigt sich eine klare Trennung der einzelnen Formen. Die Rautenform des Verkehrszeichens 306 Vorfahrtstraße liegt genau zwischen den Gefahrzeichen (nach oben gerichtetes Dreieck) und dem Verkehrszeichen 205 Vorfahrt gewähren (nach unten gerichtetes Dreieck). Haar-ähnliche Merkmale Die in [VJ04] zur Gesichtsdetektion vorgestellten Merkmale sind durch die Verwendung von Integralbildern sehr effizient berechenbar. Die Berechnung erfolgt auf Graubildern, die ebenfalls auf eine Größe von Pixel skaliert wurden. Im Rahmen des GTSRB werden fünf Basistypen der Merkmale in unterschiedlichen Größen bereitgestellt. Die Menge der berechneten Haarähnlichen Merkmale ist übervollständig. Daher werden Merkmalsauswahlverfahren wie Boosting verwendet, um geeignete Merkmale auszuwählen. Die Bereitstellung dieser Merkmale soll die Verwendung von Methoden zur Merkmalsselektion im Benchmark ermöglichen. Farbwert-Histogramme Da weder die HOG-Merkmale noch die Haar-ähnlichen Merkmale Farbinformationen beinhalten, werden als Ergänzung Farbwert-Histogramme der einzelnen Bilder bereitgestellt. Diese basieren auf dem Farbwert (Hue) der einzelnen Pixel im HSV-Farbraum (Hue-Saturation-Value). Die Histogramme sind global und enthalten jeweils 256 Einträge. In beiden Runden des Wettbewerbs wurden Baseline-Ergebnisse als Vergleichsbasis zur Verfügung gestellt. Diese wurden anhand der drei HOG-Merkmalssätze berechnet. Verwendet wurden einerseits ein einfacher linearer Klassifikator (LDA), und andererseits zwei k-nächster-nachbar-klassifikatoren (k {1,3}). 158

169 8.5 Verwendung des Datensatzes In Runde 1 beteiligten sich 24 Teams weltweit und stellten 189 Klassifikationsergebnisse zur Auswertung zur Verfügung. Die Zahl der übermittelbaren Ergebnisse pro Team war zunächst nicht beschränkt, um jedem Team die Möglichkeit zu geben, sich mit unterschiedlichen Verfahren am Wettbewerb zu beteiligen. Dies führte zu Missbrauch durch einige wenige Teams, die anhand der veröffentlichten Ergebnisse wiederholt die Parameter ihres Algorithmus angepasst haben. Dies widerspricht der Anforderung, dass der Testdatensatz nur einmalig durch ein Verfahren ausgewertet werden darf, da es sich bei wiederholter Anwendung nicht mehr um unabhängige, ungesehene Daten handelt. Dies führt zu dem bereits angesprochenen Overfitting der Testdaten und somit zu Ergebnissen, die sich durch schlechtere Generalisierung nicht mehr auf neue Daten übertragen lassen. Um dieses Vorgehen zu unterbinden, aber dennoch mehrere Verfahren pro Team zu erlauben, war es daher erforderlich, die Anzahl möglicher Einreichungen auf zehn pro Team zu beschränken. Ursächlich für dieses Problem war die Veröffentlichung der vollständigen Ergebnisliste während der Auswertungsphase in Runde 1. Die Intention der Anzeige lag in einer besseren Sichtbarkeit des Wettbewerbs und sollte den beteiligten Teams eine grundsätzliche Einschätzung der Leistungsfähigkeit ihrer Methode vermitteln absolut und im Vergleich zu anderen Teams. Ein Zurückhalten der Ergebnisse bis nach Abschluss der Auswertungsphase kann dieses Problem allerdings nicht allein lösen, da ein Team dennoch beliebig viele Ergebnisse für eine einzelne, jeweils unterschiedlich parametrierte Methode einreichen könnte. Für zukünftige Wettbewerbe wird daher eine Beschränkung der Einreichungen pro Teilnehmer empfohlen. Um dennoch die Vorteile einer öffentlichen Rangliste während der Auswertung zu erhalten, wird zusätzlich empfohlen, die Rangliste nur auf einem Teil der Testdaten zu bestimmen. Die endgültigen Ergebnisse und Platzierungen werden nach Abschluss des Wettbewerbs auf dem vollständigen oder auf dem zurückgehaltenen Datensatz berechnet. Letztlich bedeutet dies eine weitere Unterteilung des Testdatensatzes. Ein solches Verfahren wird u. a. von der Firma Kaggle Inc. 4 angewendet, die sich auf die Organisation von datengetriebenen Wettbewerben spezialisiert hat und diese im Auftrag durchführt. In Runde 2 beteiligten sich drei Teams aus Runde 1. Die geringe Teilnehmerzahl ist dadurch bedingt, dass die Teilnehmer persönlich auf der IJCNN 2011 anwesend sein mussten. Hier konnte jedes Team nur Ergebnisse für eine Methode einreichen. Diese mussten direkt vor Ort berechnet werden, wodurch potenzielles Overfitting und Manipulationen verhindert wurden Benchmark-Webseite Der GTSRB-Datensatz ist seit Abschluss des IJCNN-Wettbewerbs 2011 dauerhaft auf der Benchmark-Webseite 5 verfügbar. Zusätzlich zur Bereitstellung der Daten bietet die Webseite die Möglichkeit eigene Ergebnisse hochzuladen, sie zu analysieren und mit

170 8 Erstellung eines Verkehrszeichenbenchmarks Abbildung 8.14: Die GTSRB-Webseite erlaubt dauerhaft die Einreichung eigener Ergebnisse und den Vergleich mit anderen Verfahren [SSSI12]. anderen Verfahren zu vergleichen [Pet11]. Veröffentlichte Verfahren können mit Verweis auf den entsprechenden Artikel zur öffentlichen Anzeige freigeschaltet werden (s. Abbildung 8.14) Detektionsbenchmark auf Basis der annotierten Daten Im Rahmen der IJCNN 2013 wurde auf Basis der annotierten Videodaten ein Benchmarkdatensatz zur Detektion von Verkehrszeichen erstellt [Hou+13]. Der Datensatz des German Traffic Sign Detection Benchmark (GTSDB) umfasst 900 Vollbilder mit insgesamt Verkehrszeichen. Er ist ebenfalls auf der Benchmark-Webseite öffentlich verfügbar. An diesem Wettbewerb beteiligten sich 20 Teams weltweit mit insgesamt 123 eingereichten Ergebnissen. 8.6 Fazit Ein objektiver Vergleich unterschiedlicher Systeme und Algorithmen benötigt frei verfügbare Datensätze. Diese müssen vom Umfang her dem Problem angemessen sein. Bei Problemen in natürlichen, unbeschränkten Umgebungen wie dem Straßenverkehr, ist es nicht möglich, alles zu erfassen. Die Bandbreite der möglichen Variationen der Szenen ist dafür zu groß. Daher muss eine problemspezifische Auswahl getroffen werden. Neben der Frage nach dem zu lösenden Problem ist die Frage nach dem Umfang nur eine der vielen wichtigen Fragen, die bei Erstellung eines Benchmarkdatensatzes beantwortet 160

Denkt Ihr Auto mit? Bis zu 50 % weniger schwere Unfälle dank Fahrer-Assistenz- Systemen. www.auto-iq.ch

Denkt Ihr Auto mit? Bis zu 50 % weniger schwere Unfälle dank Fahrer-Assistenz- Systemen. www.auto-iq.ch Denkt Ihr Auto mit? Bis zu 50 % weniger schwere Unfälle dank Fahrer-Assistenz- Systemen. www.auto-iq.ch Fahrer-Assistenz-Systeme Fahrer-Assistenz-Systeme bieten Ihnen viele Vorteile. Elektronisch gesteuerte

Mehr

PRESSMAPPE: eurofot: die acht zu testenden Systeme. www.eurofot ip.eu

PRESSMAPPE: eurofot: die acht zu testenden Systeme. www.eurofot ip.eu PRESSMAPPE: eurofot: die acht zu testenden Systeme www.eurofot ip.eu eurofot: die acht zu testenden Systeme Adaptive Cruise Control Das System Adaptive Cruise Control (ACC) oder Adaptive Geschwindigkeitsregelung

Mehr

Einführung des Automatisierten Fahrens

Einführung des Automatisierten Fahrens Einführung des Automatisierten Fahrens DVR Presseseminar Bonn, 25. November 2014 Dr. Arne Bartels Konzernforschung Einführungs-Szenario für Automatische Fahrfunktionen 2 Teilautomatisiert 1 Assistiert

Mehr

Unfallvermeidungspotentiale der Fahrzeuge erhalten - Beitrag der Sachverständigen zur Vision Zero

Unfallvermeidungspotentiale der Fahrzeuge erhalten - Beitrag der Sachverständigen zur Vision Zero spotentiale der Fahrzeuge erhalten - Beitrag der Sachverständigen zur Vision Zero Dipl.-Ing. Jürgen Bönninger, Geschäftsführer der FSD Fahrzeugsystemdaten GmbH Prof. Dr.-Ing. habil. Klaus O. Rompe, Vors.

Mehr

Produktinformation CANape Option Driver Assistance

Produktinformation CANape Option Driver Assistance Produktinformation CANape Option Driver Assistance Inhaltsverzeichnis 1 Übersicht... 3 1.1 Einführung... 3 1.2 Eigenschaften und Vorteile... 3 1.3 Anwendungsgebiete... 3 1.4 Weiterführende Informationen...

Mehr

WCI BERLIN WILLKOMMEN. www.de 1

WCI BERLIN WILLKOMMEN. www.de 1 WILLKOMMEN WCI BERLIN 2012 HALL BERLIN www.de 1 AKTIVE FAHRSICHERHEIT Auf Basis leistungsfähiger Mobilfunktechnologien REFERENTEN CLEMENS DANNHEIM PROF.-DR. CHRISTIAN ICKING MARKUS MÄDER www.drive-guard.net

Mehr

FAHRZEUGSICHERHEIT 2.0 - VON DER ENTSTEHUNG EINES UNFALLS BIS ZUR RETTUNG. 06.07.2013 KLAUS KOMPASS BMW GROUP LEITER FAHRZEUGSICHERHEIT

FAHRZEUGSICHERHEIT 2.0 - VON DER ENTSTEHUNG EINES UNFALLS BIS ZUR RETTUNG. 06.07.2013 KLAUS KOMPASS BMW GROUP LEITER FAHRZEUGSICHERHEIT FAHRZEUGSICHERHEIT 2.0 - VON DER ENTSTEHUNG EINES UNFALLS BIS ZUR RETTUNG. 06.07.2013 KLAUS KOMPASS BMW GROUP LEITER FAHRZEUGSICHERHEIT 50 JAHRE FAHRZEUGSICHERHEIT. GESAMTHAFTE BETRACHTUNG. normale Fahrt

Mehr

Volvo Car Switzerland AG

Volvo Car Switzerland AG Volvo Car Switzerland AG Pressemitteilung Datum 24. Februar 2015 Drive Me Projekt: Volvo AutoPilot steuert autonom fahrende Autos im normalen Strassenverkehr Ausfallsichere Technik beherrscht komplexe

Mehr

Personenschutz durch optische Raumerfassung

Personenschutz durch optische Raumerfassung Personenschutz durch optische Raumerfassung Für gefährliche Arbeitsumgebungen im klinischen Alltag wie Strahlenschutzbereiche in der Radiologie muss sichergestellt werden, dass das Bedien- und Wartungspersonal

Mehr

Messdaten auswerten und visualisieren 5 Tipps, die passende Darstellungstechnik für ein Messsystem zu finden

Messdaten auswerten und visualisieren 5 Tipps, die passende Darstellungstechnik für ein Messsystem zu finden Messdaten auswerten und visualisieren 5 Tipps, die passende Darstellungstechnik für ein Messsystem zu finden 27.05.13 Autor / Redakteur: Nach Unterlagen von National Instruments / Hendrik Härter Messdaten

Mehr

Mehr Schutz für Fahrzeuginsassen. Erfolge der passiven Sicherheitstechnik. neue Funktionen auf der Basis von CAPS. Dr.

Mehr Schutz für Fahrzeuginsassen. Erfolge der passiven Sicherheitstechnik. neue Funktionen auf der Basis von CAPS. Dr. Juni 2007 RF 70409-d Kl Mehr Schutz für Fahrzeuginsassen Erfolge der passiven Sicherheitstechnik neue Funktionen auf der Basis von CAPS Dr. Michael Strugala Entwicklungsleiter des Produktbereichs Insassenschutz

Mehr

Simulation der SW-Systemzuverlässigkeit in Automatisierungssystemen auf Grundlage von SW-Komponenten

Simulation der SW-Systemzuverlässigkeit in Automatisierungssystemen auf Grundlage von SW-Komponenten Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner Simulation der SW-Systemzuverlässigkeit in Automatisierungssystemen auf Grundlage von SW-Komponenten

Mehr

Anforderungen an die Prüfungsfahrt (Anlage 7 Nr. 2.1.5 FeV)

Anforderungen an die Prüfungsfahrt (Anlage 7 Nr. 2.1.5 FeV) Prüfungsrichtlinie gemäß Annex II Anhang 10 (Stand 28.01.2009) Seite 1 von 6 Anlage 10 zur Prüfungsrichtlinie Anforderungen an die Prüfungsfahrt (Anlage 7 Nr. 2.1.5 FeV) 1. Allgemeine Hinweise Die Prüfungsfahrt

Mehr

EXPLORATION VON GEOSPATIALEN AUTOMOTIVE-DATEN VISUALISIERUNG VON FAHRZEUG-SENSORDATEN

EXPLORATION VON GEOSPATIALEN AUTOMOTIVE-DATEN VISUALISIERUNG VON FAHRZEUG-SENSORDATEN Isabella Eckel, BMW Group Dr. Christian Winkler, mgm technology partners GmbH EXPLORATION VON GEOSPATIALEN AUTOMOTIVE-DATEN VISUALISIERUNG VON FAHRZEUG-SENSORDATEN WISSENSEXTRAKTION AUS FAHRZEUG-SENSORDATEN

Mehr

NUTZUNG VON SMARTPHONES FÜR DIE DOKUMENTATION VON UNFÄLLEN, KRITISCHEN SITUATIONEN UND NORMALFAHRVERHALTEN

NUTZUNG VON SMARTPHONES FÜR DIE DOKUMENTATION VON UNFÄLLEN, KRITISCHEN SITUATIONEN UND NORMALFAHRVERHALTEN NUTZUNG VON SMARTPHONES FÜR DIE DOKUMENTATION VON UNFÄLLEN, KRITISCHEN SITUATIONEN UND NORMALFAHRVERHALTEN Dipl.-Ing. Henrik Liers Verkehrsunfallforschung an der TU Dresden GmbH Dokumentation realer Unfälle

Mehr

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit IT-basierte Erstellung von Nachhaltigkeitsberichten Diplomarbeit zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen Fakultät der Leibniz Universität Hannover vorgelegt von

Mehr

Absicherung von Automotive Software Funktionen

Absicherung von Automotive Software Funktionen GI Themenabend "Automotive" Absicherung von Automotive Software Funktionen 27.02.2013 Jürgen Schüling Überblick Berner & Mattner Gründung: 1979 Mitarbeiter: 400 Umsatz 2011: Standorte: Angebot: Branchen:

Mehr

Visuelle Simulation eines Radiosity Algorithmus und ihre Anwendung in Lernprozessen

Visuelle Simulation eines Radiosity Algorithmus und ihre Anwendung in Lernprozessen Visuelle Simulation eines Radiosity Algorithmus und ihre Anwendung in Lernprozessen Abschlussvortrag zur Diplomarbeit von Jörg Karpf Graphische Datenverarbeitung, Institut für Informatik 3. September 2009

Mehr

Vorlesung Automotive Software Engineering Teil 4 Das Automobil (1-4) Wintersemester 2014/15 TU Darmstadt, FB 18 und FB 20

Vorlesung Automotive Software Engineering Teil 4 Das Automobil (1-4) Wintersemester 2014/15 TU Darmstadt, FB 18 und FB 20 Vorlesung Automotive Software Engineering Teil 4 Das Automobil (1-4) Wintersemester 2014/15 TU Darmstadt, FB 18 und FB 20 Prof. Dr. rer. nat. Bernhard Hohlfeld Bernhard.Hohlfeld@mailbox.tu-dresden.de Technische

Mehr

Kinect Nils Röder, Björn Frömmer

Kinect Nils Röder, Björn Frömmer Kinect Nils Röder, Björn Frömmer Agenda Einleitung Hardware Funktionsweise der Kamera Algorithmus (Pose Recognition, Tracking) Einleitung Was ist Kinect? Eingabegerät (Human Computer Interface) Optisches

Mehr

Aktion Kindersicherer Straßenverkehr Tempo 30 vor Schulen

Aktion Kindersicherer Straßenverkehr Tempo 30 vor Schulen Aktion Kindersicherer Straßenverkehr Tempo 30 vor Schulen Kuratorium für Verkehrssicherheit Projektleitung Angelika Ledineg KURATORIUM FÜR VERKEHRSSICHERHEIT 1 Inhalt 1 Ausgangslage... 3 2 Umsetzung des

Mehr

Analysen sind nur so gut wie die Datenbasis

Analysen sind nur so gut wie die Datenbasis Analysen sind nur so gut wie die Datenbasis Datenaufbereitung und Sicherung der Datenqualität durch den kontextbasierten MIOsoft Ansatz. Daten gelten längst als wichtiger Produktionsfaktor in allen Industriebereichen.

Mehr

Enterprise Social Networking: Ein Framework und ein Fachkonzept für ein Industrieunternehmen

Enterprise Social Networking: Ein Framework und ein Fachkonzept für ein Industrieunternehmen Enterprise Social Networking: Ein Framework und ein Fachkonzept für ein Industrieunternehmen Bachelorarbeit zur Erlangung des akademischen Grades Bachelor auf Science (B.Sc.) im Studiengang Wirtschaftswissenschaft

Mehr

Gefahrlos durch den Verkehr

Gefahrlos durch den Verkehr Story I Fahrerassistenzsysteme 22 Gefahrlos durch den Verkehr Sicherheitsgurte, Knautschzone, Airbag Autos sind in den letzten Jahrzehnten immer sicherer geworden. Mit erfreulichen Auswirkungen: Obwohl

Mehr

Vernetzung von Aktiver und Passiver Sicherheit

Vernetzung von Aktiver und Passiver Sicherheit Institut für Kraftfahrzeuge RWTH Aachen Vernetzung von Aktiver und Passiver Sicherheit + + Gebäude Wüllnerstraße Gebäude Termplergraben 1957 Gebäudeneubau Melaten 1995 Teststrecke Aldenhoven 2010 Gründung

Mehr

Achtung Bahn! VGF-Ratgeber für alle, die in der Stadt unterwegs sind

Achtung Bahn! VGF-Ratgeber für alle, die in der Stadt unterwegs sind Achtung Bahn! VGF-Ratgeber für alle, die in der Stadt unterwegs sind Verehrte Fahrgäste! Verehrte Verkehrsteilnehmer! Wer auf Frankfurts Straßen unterwegs ist, sei es zu Fuß oder mit dem Rad, im Auto oder

Mehr

Reaktive Systeme und synchrones Paradigma

Reaktive Systeme und synchrones Paradigma Sascha Kretzschmann Freie Universität Berlin Reaktive Systeme und synchrones Paradigma Einführung in das Seminar über synchrone Programmiersprachen Worum geht es? INHALT 2 Inhalt 1. Einleitung - Wo befinden

Mehr

Sicher Rad fahren Regeln und Tipps

Sicher Rad fahren Regeln und Tipps Sicher Rad fahren Regeln und Tipps Bernd Zanke Mitglied des Vorstandes ADFC Berlin e.v. pööös Ideale Verhältnisse... pööös 2 ... und tägliche Realität pööös 3 Sicher Rad fahren Warum? Radfahrer können

Mehr

Einführung in die Robotik Regelung. Mohamed Oubbati Institut für Neuroinformatik. Tel.: (+49) 731 / 50 24153 mohamed.oubbati@uni-ulm.de 04. 12.

Einführung in die Robotik Regelung. Mohamed Oubbati Institut für Neuroinformatik. Tel.: (+49) 731 / 50 24153 mohamed.oubbati@uni-ulm.de 04. 12. Einführung in die Robotik Regelung Mohamed Oubbati Institut für Neuroinformatik Tel.: (+49) 731 / 50 24153 mohamed.oubbati@uni-ulm.de 04. 12. 2012 The human is perhaps the most intelligent control system

Mehr

Sicher unterwegs. mit der Badner Bahn

Sicher unterwegs. mit der Badner Bahn Sicher unterwegs mit der Badner Bahn M o d e r n k o m f o r ta b e l s i c h e r Sicherheit braucht aufmerksamkeit Wir leben in einer Zeit, in der Sicherheit eine immer größere Rolle spielt. Dank strengerer

Mehr

Driver Distraction. Lösungen zur Verringerung der Ablenkung des Fahrers. Johannes Angenvoort Garmin Würzburg GmbH

Driver Distraction. Lösungen zur Verringerung der Ablenkung des Fahrers. Johannes Angenvoort Garmin Würzburg GmbH Driver Distraction Lösungen zur Verringerung der Ablenkung des Fahrers Johannes Angenvoort Garmin Würzburg GmbH Inhalt Über Garmin K2 Plattform Smartphone Integration Headup Display (HUD) Advanced Driver

Mehr

Bildauswertung in UAV

Bildauswertung in UAV Bildauswertung in UAV Prof. Dr. Nailja Luth Prof. N. Luth Emden 2014-1 OTH Ost-Bayerische Technische Hochschule Amberg-Weiden Prof. N. Luth Emden 2014-2 Prof. Dr.-Ing. N. Luth: Vorlesung Bildverarbeitung

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

AKTIV-AS Dr. Peter Zahn BMW Group Forschung und Technik Projekte ConnectedDrive

AKTIV-AS Dr. Peter Zahn BMW Group Forschung und Technik Projekte ConnectedDrive Kommunikationsanforderungen des Projekts AKTIV-AS Dr. Peter Zahn BMW Group Forschung und Technik Projekte ConnectedDrive AKTIV-CoCar Workshop 11.6.2007 bei MAN in München AKTIV, BMW Group Forschung und

Mehr

Das Auto der Zukunft. 30. Juni 2011

Das Auto der Zukunft. 30. Juni 2011 Das Auto der Zukunft 30. Juni 2011 1 Inhaltsverzeichnis 1 Physikalische Grundlagen 3 1.1 Kräfte...................................... 3 1.2 Schlupf (λ)................................... 4 2 Aktuelle Fahrassistenzsysteme

Mehr

Was tun, wenn Ihnen Rettungsfahrzeuge im Straßenverkehr begegnen?

Was tun, wenn Ihnen Rettungsfahrzeuge im Straßenverkehr begegnen? Was tun, wenn Ihnen Rettungsfahrzeuge im Straßenverkehr begegnen? Allgemein Wenn Ihnen Feuerwehrfahrzeuge oder Rettungswagen mit eingeschalteter Lautwarnvorrichtung (Martinshorn und Blaulicht) im Straßenverkehr

Mehr

Allgemeine Erläuterungen zum FAHR

Allgemeine Erläuterungen zum FAHR FAHR Fragebogen zur automobilbezogenen Handlungsregulation Ausfüller: Max Mustermann Fakultät für Psychologie c/o Rüdiger Hossiep GAFO 04/979 Universitätsstraße 150 4470 Bochum www.testentwicklung.de Allgemeine

Mehr

SICHER ANS ZIEL UNTERWEGS AUF RADWEGEN

SICHER ANS ZIEL UNTERWEGS AUF RADWEGEN SICHER ANS ZIEL UNTERWEGS AUF RADWEGEN Wir bringen Bayern aufs Rad Kann ich, soll ich, muss ich? Zeichen 237 Radweg (Benutzungspflicht) Ein Radweg darf ausschließlich von Radfahrenden befahren werden und

Mehr

Müdigkeit am Steuer. Wach ans Ziel. bfu Beratungsstelle für Unfallverhütung

Müdigkeit am Steuer. Wach ans Ziel. bfu Beratungsstelle für Unfallverhütung Müdigkeit am Steuer Wach ans Ziel bfu Beratungsstelle für Unfallverhütung Brennen Ihnen beim Autofahren die Augen oder gähnen Sie dauernd? Halten Sie an und machen Sie einen Turboschlaf von 15 Minuten.

Mehr

Mehr Elektronik im Auto: Mehr Sicherheit im Verkehr?

Mehr Elektronik im Auto: Mehr Sicherheit im Verkehr? Mehr Elektronik im Auto: Mehr Sicherheit im Verkehr? Fahrassistenten. Schnittstelle zwischen Mensch und Technik. DEKRA AG Handwerkstrasse 15 70565 Stuttgart Winterthur Versicherungen General Guisan-Strasse

Mehr

6 Architektur-Mittel (WOMIT)

6 Architektur-Mittel (WOMIT) 6 Architektur-Mittel (WOMIT) Abb. 6-1: Positionierung des Kapitels im Ordnungsrahmen. Dieses Kapitel befasst sich mit der WOMIT-Dimension des architektonischen Ordnungsrahmens, indem es grundlegende Konzepte

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

Sicherheit Lehrerinformation

Sicherheit Lehrerinformation Lehrerinformation 1/5 Arbeitsauftrag srelevante Bestandteile des Autos werden gemeinsam besprochen: Airbag, sgurte und Kindersitze werden angeschaut. Ziel Die SuS kennen die svorschriften in und zu einem

Mehr

Lastenheft. Auftraggeber IBR Abteilung ALG

Lastenheft. Auftraggeber IBR Abteilung ALG Lastenheft Auftraggeber IBR Abteilung ALG Versionsübersicht Version Datum Autor Status Kommentar 1.0 9. 2. 2011 Auftraggeber 1.1 1. 4. 2011 Auftraggeber Ergänzung Miniflur, Personenerkennung 1.1.1 6. 4.

Mehr

DATEN - Das Gold des 21. Jahrhunderts? Dr. Oliver Riedel, AUDI AG

DATEN - Das Gold des 21. Jahrhunderts? Dr. Oliver Riedel, AUDI AG DATEN - Das Gold des 21. Jahrhunderts? Dr. Oliver Riedel, AUDI AG Inhalt Globale und unternehmensspezifische Herausforderungen Von Big Data zu Smart Data Herausforderungen und Mehrwert von Smart Data 2

Mehr

Einführung in die Robotik Sensoren. Mohamed Oubbati Institut für Neuroinformatik. Tel.: (+49) 731 / 50 24153 mohamed.oubbati@uni-ulm.de 30. 10.

Einführung in die Robotik Sensoren. Mohamed Oubbati Institut für Neuroinformatik. Tel.: (+49) 731 / 50 24153 mohamed.oubbati@uni-ulm.de 30. 10. Einführung in die Robotik Sensoren Mohamed Oubbati Institut für Neuroinformatik Tel.: (+49) 731 / 50 24153 mohamed.oubbati@uni-ulm.de 30. 10. 2012 Sensoren Was ist ein Sensor? Ein Sensor empfängt ein physikalisches

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

A Glob Al SolUTIoN. O R L D. A G R E A T W

A Glob Al SolUTIoN. O R L D. A G R E A T W A GREAT WORLD. A Global SOLUTION. EURO SKY PARK Satellitenkommunikation für Unternehmen Wir verbinden Standorte Information und Kommunikation sind für Unternehmen heute erfolgsentscheidend. Wie abgelegen

Mehr

HEUTE HABE ICH MEINE PRODUKTION AUTOMATISIERT FRAMOS 2014

HEUTE HABE ICH MEINE PRODUKTION AUTOMATISIERT FRAMOS 2014 HEUTE HABE ICH MEINE PRODUKTION AUTOMATISIERT FRAMOS 2014 04.11.2014 ÜBERBLICK Themen der nächsten 25 Minuten: Ich will automatisieren! Gibt es Fallstricke? Wer hilft mir? 3 Lösungsansätze Fokus Beispiele

Mehr

Fahren Sie schon Sicherheit?

Fahren Sie schon Sicherheit? Fahren Sie schon Sicherheit? Fahren Sie schon Sicherheit? Grußwort Mit gut ausgeleuchteter Straße sicher nach Hause kommen. Schöne Straße, schönes Auto und das Tempolimit immer im Blick. Automatisch bremsen,

Mehr

VCA mit HD so geht s. Abgrenzung - Videoanalyse und Bewegungserkennung

VCA mit HD so geht s. Abgrenzung - Videoanalyse und Bewegungserkennung VCA mit HD so geht s Video Content Analysis (VCA), also die automatisierte Analyse von Videodaten zur Erkennung von Objekten und alarmrelevanten Ereignissen, ist sicherlich eine der anspruchsvollsten Teilaufgaben

Mehr

3D Dentalscanner. AIT Austrian Institute of Technology Safety & Security Department. Manfred Gruber. Head of Business Unit

3D Dentalscanner. AIT Austrian Institute of Technology Safety & Security Department. Manfred Gruber. Head of Business Unit 3D Dentalscanner AIT Austrian Institute of Technology Safety & Security Department Manfred Gruber Head of Business Unit Safe and Autonomous Systems AIT Austrian Institute of Technology Größte außeruniversitäre

Mehr

Telezentrische Meßtechnik

Telezentrische Meßtechnik Telezentrische Meßtechnik Beidseitige Telezentrie - eine Voraussetzung für hochgenaue optische Meßtechnik Autor : Dr. Rolf Wartmann, Bad Kreuznach In den letzten Jahren erlebten die Techniken der berührungslosen,

Mehr

Sicherheit an Bahnübergängen

Sicherheit an Bahnübergängen Fakultät Verkehrswissenschaften Friedrich List Professur für Verkehrssicherungstechnik Sicherheit an Bahnübergängen Dr.-Ing. Eric Schöne Fakultät Verkehrswissenschaften Friedrich List Professur für Verkehrssicherungstechnik

Mehr

Blindennavigation. als Anwendung für Location-based Services. Andreas Hub

Blindennavigation. als Anwendung für Location-based Services. Andreas Hub Blindennavigation als Anwendung für Location-based Services Andreas Hub Motivation? Wo bin ich? Was ist vor mir? Wo ist die Tür? Wo ist der Eingang? Kommen Gefahren? Was ist im Weg? Probleme Orientierung

Mehr

INTELLIGENTE ARBEITSSYSTEME ROBOTIK- UND LOGISTIKANWENDUNGEN

INTELLIGENTE ARBEITSSYSTEME ROBOTIK- UND LOGISTIKANWENDUNGEN INTELLIGENTE ARBEITSSYSTEME ROBOTIK- UND LOGISTIKANWENDUNGEN Das taktile Internet 1. Fraunhofer als Technologiepartner für Intelligente Arbeitssysteme 2. Situationsanalyse und prognose im Logistikraum

Mehr

Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests. Masterarbeit

Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests. Masterarbeit Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests Masterarbeit zur Erlangung des akademischen Grades Master of Science (M.Sc.) im Masterstudiengang Wirtschaftswissenschaft

Mehr

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 378

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 378 DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN Nr. 378 Umsetzung ausgewählter Supply-Chain-Operations-Reference-Metriken durch das

Mehr

VisuellbasierteRobotik StandundPerspektiven einertechnologie. Prof.Dr.G.Sommer. Christian{Albrechts{UniversitatKiel

VisuellbasierteRobotik StandundPerspektiven einertechnologie. Prof.Dr.G.Sommer. Christian{Albrechts{UniversitatKiel VisuellbasierteRobotik StandundPerspektiven einertechnologie Prof.Dr.G.Sommer Dipl.{Inform.J.Bruske Dr.K.Daniilidis Dr.J.Pauli Christian{Albrechts{UniversitatKiel TechnologiestiftungSchleswig{Holstein

Mehr

BMW CONNECTED DRIVE.

BMW CONNECTED DRIVE. BMW ConnectedDrive www.bmw.de Freude am Fahren CD SWM MAS U B / BMW CONNECTED DRIVE. INHALT. BESONDERES ERLEBEN. BMW ConnectedDrive Highlights VIELFALT ENTDECKEN. BMW ConnectedDrive Services & Apps BMW

Mehr

Analyse von Videobildern

Analyse von Videobildern Analyse von Videobildern Fahrerassistenzsysteme Mit Videobildern realisierbar Fernlichtassistent Adaptive Cruise Control (Abstandsregeltempomat) Abbiegeassistent Spurhalteassistent (Lane Departure Warning)

Mehr

Was versteht man unter Softwarequalität?

Was versteht man unter Softwarequalität? Was versteht man unter? ist die Gesamtheit der Merkmale und Merkmalswerte eines Softwareproduktes, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen. Was ist

Mehr

Kapitel 2 Trajektoriendaten und Floating-Car-Daten

Kapitel 2 Trajektoriendaten und Floating-Car-Daten Kapitel 2 Trajektoriendaten und Floating-Car-Daten Miss alles, was sich messen lässt, und mach alles messbar, was sich nicht messen lässt. Galileo Galilei 2.1 Erfassungsmethoden Mit Hilfe von Kameras kann

Mehr

Computer Graphik I (3D) Dateneingabe

Computer Graphik I (3D) Dateneingabe Computer Graphik I (3D) Dateneingabe 1 3D Graphik- Pipeline Anwendung 3D Dateneingabe Repräsenta

Mehr

ES-Projektseminar (SS 2010)

ES-Projektseminar (SS 2010) ES-Projektseminar (SS 2010) Endvortrag Team Car2Car Konstantin Fuchs Tobias Große-Puppendahl Steffen Herbert Sebastian Niederhöfer ES Real-Time Systems Lab Prof. Dr. rer. nat. Andy Schürr Dept. of Electrical

Mehr

KÖNNEN STRASSEN EINEN SCHRITT VORAUS SEIN?

KÖNNEN STRASSEN EINEN SCHRITT VORAUS SEIN? KÖNNEN STRASSEN EINEN SCHRITT VORAUS SEIN? MODELLBASIERTE LÖSUNG FÜR VERKEHRSPROGNOSEN IN ECHTZEIT PTV Optima ist der Schlüssel zu erfolgreichem Verkehrsmanagement. Die modellbasierte Lösung bietet präzise

Mehr

Division Chassis & Safety Driving Safety and Dynamics

Division Chassis & Safety Driving Safety and Dynamics Division Chassis & Safety Driving Safety and Dynamics Die Division Chassis & Safety (C&S) ist eine der fünf Divisionen der Continental AG. Chassis & Safety entwickelt und produziert Produkte und Komponenten

Mehr

Repeatable Benchmarking Mahout

Repeatable Benchmarking Mahout Studienarbeitsexposé Repeatable Benchmarking Mahout Entwicklung eines Lasttest-Rahmenwerkes für Apache Mahout von: Oliver Fischer Institut für Informatik Humbold-Universität zu Berlin Matrikelnummer: 19

Mehr

Vorstellung Diplomarbeit

Vorstellung Diplomarbeit Vorstellung Diplomarbeit Entwurf und Implementierung eines BUS-Moduls für das Automatisierungswerkzeug ECU-TEST engineering software test Gliederung Einleitung Überblick Testautomatisierung Kurzvorstellung

Mehr

Analyse alt- und mittelpaläolithischer Steinartefaktinventare mittels Parallelkoordinatenplots

Analyse alt- und mittelpaläolithischer Steinartefaktinventare mittels Parallelkoordinatenplots Einleitung Analyse alt- und mittelpaläolithischer Steinartefaktinventare mittels Parallelkoordinatenplots von Irmela Herzog Im Rahmen der Herbsttagung der AG DANK (Datenanalyse und Numerische Klassifikation)

Mehr

Tinytag Funk- Datenlogger- Software

Tinytag Funk- Datenlogger- Software Tinytag Funk- Datenlogger- Software Seite: 1 Tinytag Funk- Datenlogger- Software Tinytag Explorer ist die Windows- basierte Software zum Betrieb eines Tinytag Funk- Systems. Die Anwender können ihre Daten

Mehr

6 Fahrsicherheitssysteme

6 Fahrsicherheitssysteme 6 Fahrsicherheitssysteme 6.1 Gliederung von Fahrsicherheitssystemen 6.2 Radschlupf-Regelsysteme 6.3 Fahrdynamik-Regelung 6.1 Gliederung von Fahrsicherheits- Systemen Aktive Sicherheitssysteme Antiblockiersysteme

Mehr

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung Unified Process Eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland Copyright 2000 Hannes Fischer Unified Process Wie wird heute gearbeitet? Der Unified Process

Mehr

Segway. Eine Bewertung des neuartigen Transportmittels durch die Unfallforschung der Versicherer

Segway. Eine Bewertung des neuartigen Transportmittels durch die Unfallforschung der Versicherer Segway Eine Bewertung des neuartigen Transportmittels durch die Unfallforschung der Versicherer 2 Segway Was ist das? Quelle: www.segway.de 3 Segway Was ist das? Zahlen Stand 2005: 15-20.000 Fahrzeuge

Mehr

Scheinaufgabe im Fach Web Engineering

Scheinaufgabe im Fach Web Engineering Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Institut für Verteilte Systeme Scheinaufgabe im Fach Web Engineering Thomas Thüm 07. August 2006 Matrikel: 171046 Lehrveranstaltung: Web

Mehr

Fakultät für Elektrotechnik, Informatik und Mathematik Institut für Informatik Fachgebiet Didaktik der Informatik

Fakultät für Elektrotechnik, Informatik und Mathematik Institut für Informatik Fachgebiet Didaktik der Informatik Fakultät für Elektrotechnik, Informatik und Mathematik Institut für Informatik Fachgebiet Didaktik der Informatik Konzeption und prototypische Implementierung eines Knowledge-Servers mit Adaptern zur Integration

Mehr

Einsatz der Mehrkörpersimulation in Verbindung mit Computertomographie in der Produktentwicklung

Einsatz der Mehrkörpersimulation in Verbindung mit Computertomographie in der Produktentwicklung Einsatz der Mehrkörpersimulation in Verbindung mit Computertomographie in der Produktentwicklung Hintergrund Bei komplexen Baugruppen ergeben sich sehr hohe Anforderungen an die Tolerierung der einzelnen

Mehr

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R Vector Software W H I T E P A P E R Test Automation mit VectorCAST während der gesamten Softwareentwicklung VectorCAST Produktfamilie Die VectorCAST Produktfamilie automatisiert Testaktivitäten über den

Mehr

Computer Augmented Reality

Computer Augmented Reality Computer Augmented Reality Eine Zusammenfassung von Joachim Steinmetz Vorwort: Die folgenden Seiten sollen einen Überblick über den jetzigen Stand im Bereich CAR (Computer Augmented Reality) wiedergeben.

Mehr

Mobile Mapping. Eine Gegenüberstellung unterschiedlicher Verfahren zur Erfassung von Straßendaten. Christian Wever TopScan GmbH wever@topscan.

Mobile Mapping. Eine Gegenüberstellung unterschiedlicher Verfahren zur Erfassung von Straßendaten. Christian Wever TopScan GmbH wever@topscan. Mobile Mapping Eine Gegenüberstellung unterschiedlicher Verfahren zur Erfassung von Straßendaten Christian Wever TopScan GmbH wever@topscan.de TopScan Gesellschaft zur Erfassung topographischer Information

Mehr

DRIVE LIKE A VIRTUAL DEVELOPER Die Poleposition für Ihre Softwareentwicklung

DRIVE LIKE A VIRTUAL DEVELOPER Die Poleposition für Ihre Softwareentwicklung DRIVE LIKE A VIRTUAL DEVELOPER Die Poleposition für Ihre Softwareentwicklung Was für ein Tempo! Das Rad dreht sich rasant schnell: Die heutigen Anforderungen an Softwareentwicklung sind hoch und werden

Mehr

1.2.1 Gestaltpsychologie

1.2.1 Gestaltpsychologie 1.2 Gestaltgesetze 1.2.1 Gestaltpsychologie... 40 1.2.2 Gesetz von der einfachen Gestalt... 41 1.2.3 Gesetz der Nähe... 42 1.2.4 Gesetz der Gleichheit... 43 1.2.5 Gesetz der Geschlossenheit... 44 1.2.6

Mehr

INNOVATION IM DIENSTE VON EFFIZIENZ, SICHERHEIT UND KOMFORT

INNOVATION IM DIENSTE VON EFFIZIENZ, SICHERHEIT UND KOMFORT H I - T E C H N O L O G Y A N D T E L E M A T I C S INNOVATION IM DIENSTE VON EFFIZIENZ, SICHERHEIT UND KOMFORT Aus der Zusammenarbeit von IVECO und Magneti Marelli ist IVECONNECT entstanden, ein exklusives

Mehr

Sensoren für die bedarfsgerechte Kennzeichnung von Windenergieanlagen. Autor: Dr.-Ing. Günter Prokoph WORK Microwave GmbH, Holzkirchen, CTO

Sensoren für die bedarfsgerechte Kennzeichnung von Windenergieanlagen. Autor: Dr.-Ing. Günter Prokoph WORK Microwave GmbH, Holzkirchen, CTO Sensoren für die bedarfsgerechte Kennzeichnung von Windenergieanlagen Autor: Dr.-Ing. Günter Prokoph WORK Microwave GmbH, Holzkirchen, CTO Inhalt: Einleitung/Ausgangssituation Vorschriften und Randbedingungen

Mehr

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Andreas Armbrecht Siemens AG Darmstadt, 01. 02. Dezember 2009 Business Unit Rail Automation Systeme der Eisenbahnautomatisierung

Mehr

Multi-site sicherheitslösungen

Multi-site sicherheitslösungen Multi-site sicherheitslösungen Sehen Sie das Gesamtbild FÜHREND BEI MULTI-SITE- ÜBERWACHUNGSLÖSUNGEN Perimeterschutz Perimeterschutz beginnt an der Grundstücksgrenze, indem Eindringlinge erkannt werden,

Mehr

Gestengesteuerte Visualisierung digitaler Bestandsdaten

Gestengesteuerte Visualisierung digitaler Bestandsdaten Verteidigung der Masterarbeit Gestengesteuerte Visualisierung digitaler Bestandsdaten Mo, 11 NOV 2013 (SLUB Dresden, R0.46) In Kooperation mit der Sächsischen Landes- und Universitätsbibliothek (SLUB)

Mehr

(Thema) Realisierung eines kennzahlenbasierten Steuerungskonzepts für das Change Management. Bachelorarbeit

(Thema) Realisierung eines kennzahlenbasierten Steuerungskonzepts für das Change Management. Bachelorarbeit (Thema) Realisierung eines kennzahlenbasierten Steuerungskonzepts für das Change Management Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft

Mehr

ENT WICKLUNG CAR-TO -X

ENT WICKLUNG CAR-TO -X ENT WICKLUNG CAR-TO -X AUTOR Rolf Dubitzky ist Director Driver Assistance bei Elektrobit in Erlangen. 38 CROWD SENSING Derzeitige Serienfahrzeuge verarbeiten bereits eine große Menge an Informationen.

Mehr

Linear Workflow. Linear Workflow. Version 1.0-2011-10-11

Linear Workflow. Linear Workflow. Version 1.0-2011-10-11 Version 1.0-2011-10-11 Verfahren, Bilder unter Rücksichtnahme ihres Farbprofils und der des Ausgabegeräts zu berechnen (3D), bzw. zu bearbeiten (Compositing), um eine mathematisch und physikalisch korrekte

Mehr

Testautomatisierung. Märchen, Möglichkeiten und praktischer Nutzen. Richard Seidl 21. Januar 2013 TU Dresden. Medizin- und Informationstechnik AG

Testautomatisierung. Märchen, Möglichkeiten und praktischer Nutzen. Richard Seidl 21. Januar 2013 TU Dresden. Medizin- und Informationstechnik AG Medizin- und Informationstechnik AG Testautomatisierung Märchen, Möglichkeiten und praktischer Nutzen Richard Seidl 21. Januar 2013 TU Dresden Kardiologische Funktionsdiagnostik Vitalfunktions-Monitoring

Mehr

Systematisches Testen von Software

Systematisches Testen von Software Programmierung Systematisches Testen von Software Markus Eckstein Systematika Information Systems GmbH Kurfürsten-Anlage 36 69115 Heidelberg markus.eckstein@systematika.com Zusammenfassung Die wichtigsten

Mehr

Vergleich der Anwendbarkeit verschiedener CFD Modelle zur Simulation von Brandereignissen Abgrenzung der Anwendungsgebiete von FDS gegenüber CFX

Vergleich der Anwendbarkeit verschiedener CFD Modelle zur Simulation von Brandereignissen Abgrenzung der Anwendungsgebiete von FDS gegenüber CFX Vergleich der Anwendbarkeit verschiedener CFD Modelle zur Simulation von Brandereignissen Abgrenzung der Anwendungsgebiete von FDS gegenüber CFX Wissenschaftliche Arbeit zur Erlangung des Grades Master

Mehr

Messsystemanalyse (MSA)

Messsystemanalyse (MSA) Messsystemanalyse (MSA) Inhaltsverzeichnis Ursachen & Auswirkungen von Messabweichungen Qualifikations- und Fähigkeitsnachweise Vorteile einer Fähigkeitsuntersuchung Anforderungen an das Messsystem Genauigkeit

Mehr

Fehlersammlung und Fehleranalyse

Fehlersammlung und Fehleranalyse Fehlersammlung und Fehleranalyse Rev. 00, 16.3.2010 1/5 Fehlersammlung und Fehleranalyse Fehleranalyse ist eine notwendige Voraussetzung für Verbesserung und Optimierung des Prozesses. Problem ist, dass

Mehr

Easy-Monitoring Universelle Sensor Kommunikations und Monitoring Plattform

Easy-Monitoring Universelle Sensor Kommunikations und Monitoring Plattform Easy-Monitoring Universelle Sensor Kommunikations und Monitoring Plattform Eberhard Baur Informatik Schützenstraße 24 78315 Radolfzell Germany Tel. +49 (0)7732 9459330 Fax. +49 (0)7732 9459332 Email: mail@eb-i.de

Mehr

3D-Visualisierungswerkzeuge für die Entwicklung und Präsentation von Fahrerassistenzsystemen

3D-Visualisierungswerkzeuge für die Entwicklung und Präsentation von Fahrerassistenzsystemen 3D-Visualisierungswerkzeuge für die Entwicklung und Präsentation von Fahrerassistenzsystemen Jesko Klandt, Dr. Geerd Anders Carmeq GmbH Carnotstr. 4, 10587 Berlin, +49.30.3983537-258 jesko.klandt@carmeq.com,

Mehr

IT-Sicherheit mobiler Applikationen zur Unterstützung von Geschäftsprozessen. Bachelorarbeit

IT-Sicherheit mobiler Applikationen zur Unterstützung von Geschäftsprozessen. Bachelorarbeit IT-Sicherheit mobiler Applikationen zur Unterstützung von Geschäftsprozessen Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft der

Mehr

Wireless LAN. nach IEEE 802.11

Wireless LAN. nach IEEE 802.11 Wireless LAN nach IEEE 802.11 Entstanden im Rahmen der Vorlesung LNWN II im Sommersemester 2002 INHALTSVERZEICHNIS 1 WIRELESS LAN NACH DEM IEEE 802.11 STANDARD 3 1.1 IEEE 802.11 3 1.2 IEEE 802.11B 3 1.3

Mehr

dwh-test data synthesizer Synthetische Testdaten aus Metadaten und SQL-Source-Code

dwh-test data synthesizer Synthetische Testdaten aus Metadaten und SQL-Source-Code - S. 1 Probleme im DWH-Test S. 3 Gefahr im DWH-Test S. 5 Synthetische Testdaten S. 6 Synthetische Testdaten aus Metadaten und SQL-Source-Code S. 7 - Testdaten S. 9 - Testfälle S. 11 - Testdatensätze S.

Mehr