Funktionaler Softwaretest für aktive Fahrerassistenzsysteme mittels parametrierter Szenario-Simulation

Im vorliegenden Beitrag wird das Testen der Embedded Software von umfelderfassenden aktiven Fahrerassistenzsystemen mit Hilfe einer bilderzeugenden Sensorstimulation fur Hardware-in-the-Loop Testsysteme vorgestellt. Dies ermoglicht quantitative Aussagen zur Erreichen von Qualitatszielen fur funktionale Tests mit hoher Testtiefe und –breite. Generierung und Aufbau der relevanten Test-Szenarien wird erlautert. 1 Software im Automobil Moderne Fahrzeuge beinhalten eine Fulle an Software-Komponenten. Diese sind ublicherweise als Embedded Software in Steuergeraten oder vernetzt in Steuergerateverbunden implementiert (vgl. Abb. 1). Steuergerate (SG), wie beispielsweise das Motor-SG, die Dachbedieneinheit, das Kombi-Instrument oder multifunktionale „Sensor-Aktor-Module“ kombinieren also Hardware (Sensoren, Aktoren) mit Funktionen, die in Form von Software realisiert sind (vgl. Abb. 2). Dabei sind haufig Echtzeitbedingungen zu erfullen, um die korrekte Funktion (z.B. eines Airbagsteuergerats) sicher zu stellen. Aktuelle Oberklassefahrzeuge haben uber 80 verschiedene uber Busleitungen vernetzte Steuergerate. Aber nicht nur die Anzahl, auch die Komplexitat ihrer Funktionen und damit der ablaufenden Software steigert sich kontinuierlich. Grunde dafur sind wachsende Kundenerwartungen, erhohte Anforderungen z.B. an Sicherheitsstandards, und auch neue technische Moglichkeiten. [Gr05, Ch09] Embedded Software im Automotive Bereich steht unter dem besonderen Druck, besonders hohe Anforderungen an die Zuverlassigkeit wahrend eines ganzen Autolebens lang, und das unter allen Temperaturund Klimabedingungen und Nutzungsverhalten. Die standige Interaktion der Software mit den anderen Verkehrsteilnehmern und besonders mit Menschen in ihrer Umgebung legen den benotigten hohen Qualitatsund Sicherheitsstandard fest. Dazu kommen vielfaltige verschiedene rechtliche Rahmenbedingungen, die Notwendigkeit einer einfachen Wartbarkeit, das Zusammenspiel von Hardund Software sowie vieler Zulieferer fur die einzelnen Elektronik-Komponenten sowie die Notwendigkeit von Ausfallsicherheit und Notlaufkonzepten selbst im Fehlerfall. Abb. 1: Steuergerate und Datenbusse der Daimler C-Klasse (Baureihe 204). Automotive Software ist also durch hohe Komplexitat, komfortund sicherheitsrelevante fahrzeugspezifische Funktionen und daraus resultierend hochste Anforderungen an die Softwarequalitat gekennzeichnet. [Li02] 1.1 Aktive Fahrerassistenzsysteme Steuergerate beinhalten Funktionen zur Entlastung des Fahrers, sei es durch Informationen, Warnungen oder aktive Unterstutzung. Erst seit wenigen Jahren gibt es die so genannten Fahrerassistenzsysteme (FAS). Aktive Fahrerassistenzsysteme (engl. Advanced Driver Assistance Systems, ADAS) unterstutzen dabei teilweise sogar durch aktive autonome Eingriffe. Beispiele hierfur sind Einparkund Spurhalteassistenten, Fusgangerund Verkehrszeichenerkennung. Diese Systeme greifen im Notfall selbstandig durch Lenken oder (Not-) Bremsen direkt in die Langsoder Querregelung des Fahrzeuges ein. Die Umfelderfassung durch Sensoren wie Radar, Video oder Ultraschall ist dabei der ubliche Weg, um den Algorithmen Informationen zur Situationsanalyse und –bewertung zu verschaffen. Als Sensordatenfusion bezeichnet man dabei das Vorgehen, immer mehrere Datenquellen redundant zu nutzen, um die Richtigkeit einer Entscheidung genauer abzusichern. Erst wenn Radar-Echos und Videobild unabhangig zum gleichen Analyse-Ergebnis fuhren, darf das Fahrzeug darauf aktiv reagieren. Abb. 2: Technischer Aufbau eines Steuergerats als ruckgekoppeltes System [Mu07]. Die Sicherheit aller Verkehrsteilnehmer ist das hochste Ziel bei der Entwicklung derart aktiv eingreifenden Funktionen. An die Software dieser Systeme werden aufgrund ihrer moglichen autonomen Aktionen besonders hohe Anforderungen gestellt. Neben einer sorgfaltigen und professionellen Softwareentwicklung ist daher auch das Testen der Softwarequalitat ein wichtiger Schritt auf dem Weg zum Serieneinsatz eines mit diesen Helfern ausgestatteten Fahrzeugs. 1.2 Heutige Vorgehensweise beim Softwaretest von ADAS Derzeit wird Software und deren Funktionalitat in Fahrerassistenzsystemen vielfach durch Testfahrten [ZS08] und einfache Sensorstimulationen getestet. Testfahrten bieten den Vorteil, die reale Umgebung des Einsatzbereichs unter vielfaltigsten Bedingungen als „Testdaten“ einzubinden. Damit einher geht der Nachteil, durch viele gefahrenen Kilometer zwar die Anzahl der gepruften Situationen („Use Cases“) zu erhohen, jedoch lasst sich das Testen damit nicht allumfassend abdecken. Systematik, Automatisierbarkeit, Reproduzierbarkeit und Beeinflussbarkeit der Umgebung sind kaum gegeben, zudem sind aus Sicherheitsgrunden viele Testfalle nicht durchfuhrbar. Bei Kamerasystemen kann zum Beispiel das Einspielen von zuvor wahrend realer Fahrten aufgezeichneter Sensordaten (z.B. Radaroder Videodaten) in ein Testobjekt im Labor das Testspektrum erweitern und zu umfassenderen und teilweise genaueren Testergebnissen fuhren. So konnen ohne Gefahr und mit beliebigen Wiederholungen vorher aufgenommene und nach Situationen (z.B. Tunnelfahrt, Landstrase, Fusgangeruberweg) klassifizierte Video-Dateien erneut wiedergegeben und damit abgefahren werden. Jedoch zeigen sich auch hier zwei Nachteile: Zum einen bleibt eine Reaktion der Funktion (z.B. Notbremsung) ohne Reaktion auf die Sensoren (das Fahrzeug im Video fahrt weiter). Zum anderen ist eine Sensordatenfusion nur dann moglich, wenn alle Sensordaten gleichzeitig in der Realitat aufgenommen wurden – oder z.B. manuell in einem Videoobjekt markiert wurden, um daraus kunstlich Radarechos zu errechnen. Eine Aussage uber den Reifegrad und die Erreichung der Qualitatsziele ist mit beiden Vorgehen nur eingeschrankt und hochstens qualitativ moglich. Auch wenn beide Verfahren ihre Berechtigung haben, so ist doch eine weitere Optimierung der Testverfahren wunschenswert.