-
Die Erfindung betrifft ein Verfahren zur Validierung von Softwarefunktionen in einem Fahrerassistenzsystem für Kraftfahrzeuge, mit den Schritten:
- a) aufzeichnen von Eingangsdaten mindestens einer zu testenden Systemgruppe des Fahrerassistenzsystems während eines realen oder simulierten Betriebs mindestens einer vorgeschalteten Systemgruppe, wobei die Eingangsdaten an eine erste Konfiguration der zu testenden Systemgruppe angepasst sind,
- b) einspeisen der aufgezeichneten Daten in die Software der zu testenden Systemgruppe in einer zweiten Konfiguration und simulieren der Funktion dieser Systemgruppe in dieser zweiten Konfiguration, und
- c) vergleichen der bei der Simulation auftretenden Systemreaktionen mit vorgegebenen Sollkriterien.
-
Stand der Technik
-
Ein Fahrerassistenzsystem für Kraftfahrzeuge, beispielsweise ein Abstandsregelsystem, ein automatisches Notbremssystem, ein Spurhaltesystem oder dergleichen, oder auch eine Kombination all dieser Systeme, umfasst sensorische Komponenten wie beispielsweise Radarsensoren, Kameras, etc., aktorische Komponenten für Steuereingriffe in das Antriebssystem, das Bremssystem, die Lenkung, etc. und ein elektronisches Datenverarbeitungssystem mit zugehöriger Software, das die sensorischen Komponenten steuert, Sensordaten verarbeitet und daraus Steuerbefehle für die aktorischen Komponenten generiert.
-
Im Zuge einer fortlaufenden Verbesserung der Fahrerassistenzsysteme und einer Steigerung des Funktionsumfangs und der Leistungsfähigkeit dieser Systeme wird die Software ständig weiterentwickelt, und die weiterentwickelten Softwareversionen müssen dann durch Softwareupdates in die Fahrerassistenzsysteme eingespielt werden. Bevor jedoch eine neue Softwareversion in den Fahrerassistenzsystemen integriert werden kann, ist aus Sicherheitsgründen ein sorgfältige Validierung erforderlich, bei der die Funktionen der neuen Software getestet werden, um zu prüfen, ob die neue Software mindestens die Anforderungen erfüllt, die die alte Software bereits erfüllt hatte, und ob die mit der Änderung der Software angestrebten Verbesserungen wirklich erreicht werden.
-
Grundsätzlich kann eine solche Validierung dadurch erfolgen, dass bei Testfahrten geprüft wird, ob die Systemreaktionen die vorgegebenen Sollkriterien erfüllen. Beispielsweise kann bei einem automatischen Notbremssystem bei der Validierung geprüft werden, ob die Häufigkeit der Fehlauslösungen unterhalb eines bestimmten Schwellenwertes bleibt. Statistisch aussagekräftige Ergebnisse sind auf diese Weise jedoch erst nach sehr vielen gefahrenen Testkilometern zu erhalten, so dass die Validierung der Software durch reale Testfahren sehr aufwändig und kostspielig ist.
-
Es sind deshalb Verfahren der eingangs genannten Art entwickelt worden, bei denen die während einer realen Testfahrt erhaltenen Sensordaten aufgezeichnet werden und diese Daten später dazu benutzt werden, die Testfahrt beim Test einer neuen Softwareversion zu emulieren.
-
Bei den bekannten Verfahren handelt es sich bei den Eingangsdaten generell um die Sensordaten, die vorgeschaltete Systemgruppe ist das Sensorsystem, und die zu testende Systemgruppe ist das Fahrerassistenzsystem als Ganzes, mit Ausnahme der Sensorik und der Aktorik.
-
Die Systemsoftware eines Fahrerassistenzsystems besteht aus einem sehr komplexen Netzwerk von miteinander interagierenden und teilweise auch hierarchisch strukturierten Systemkomponenten und Subkomponenten. Da das Verhalten einer einzelnen Komponente von dem Input abhängig ist, den sie von anderen Systemkomponenten erhält, ist es schwierig, die Funktionen einer einzelnen Komponente isoliert unter realitätsnahen Bedingungen zu testen. Deshalb muss bisher generell die Validierung für die Systemsoftware als Ganzes erfolgen, auch wenn bei dem Update nur eine einzelne Komponente verändert wurde.
-
Auch die Emulation von Testfahrten mittels aufgezeichneter Sensordaten stößt an Grenzen, wenn im Zuge der Weiterentwicklung die Software so stark verändert wurde, dass die Formate der aufgezeichneten Daten nicht mehr mit den Datenformaten kompatibel sind, die die neue Software benötigt. In dem Fall sind bisher wieder aufwändige reale Testfahrten erforderlich.
-
Offenbarung der Erfindung
-
Aufgabe der Erfindung ist es ein Validierungsverfahren anzugeben, das eine effizientere Entwicklung und Validierung der Software ermöglicht.
-
Diese Aufgabe wird erfindungsgemäß dadurch gelöst, dass die in Schritt a) aufgezeichneten Eingangsdaten in einem vordefinierten Datenobjekt, das eine vordefinierte Datenstruktur aufweist, mit Konfigurationsdaten kombiniert werden, die die erste Konfiguration beschreiben, und dass bei der Validierung der Funktionen der Systemgruppe in der zweiten Konfiguration die in Schritt b) eingespeisten Daten aus dem Inhalt des Datenobjekts generiert werden.
-
Da das Datenobjekt nicht nur die aufgezeichneten Daten enthält, sondern auch Information über die bisherige Konfiguration der zu testenden Systemgruppe, und damit implizit oder explizit auch über die in der bisherigen Konfiguration verwendeten Datenformate, ist es möglich, beim Generieren der Eingangsdaten das Format der aufgezeichneten Daten in das von der neuen Konfiguration benötigte Format zu konvertieren.
-
Auf diese Weise wird erreicht, dass die bei aufwändigen Testfahrten erhaltenen Eingangsdaten auch bei radikaleren Veränderungen der Software weiterhin verwertbar bleiben.
-
Die in dem Datenobjekt enthaltenen Konfigurationsdaten müssen sich jedoch nicht nur auf die benötigten Datenformate beziehen, sondern können auch andere Aspekte der Konfiguration betreffen.
-
In einer Ausführungsform der Erfindung wird die Systemsoftware des Fahrerassistenzsystems als Ganzes als ein Netzwerk von miteinander interagierenden Komponenten beschrieben, und die zu testende Systemgruppe kann auch eine aus einer oder mehreren dieser Komponenten bestehende Unterkombination des Gesamtsystems sein. Der Input von anderen Komponenten, die nicht zu der getesteten Systemgruppe gehören, wird dann ebenso emuliert wie die Sensordaten. Die in dem Datenobjekt , im folgenden als Emulationscontainer oder kurz als Container bezeichnet, aufgezeichneten Eingangsdaten bestehen dann nicht oder nicht nur aus den Sensordaten, sondern umfassen auch den Input von anderen Systemkomponenten, die nicht zu der getesteten Systemgruppe gehören. Die ebenfalls in dem Container enthaltenen Konfigurationsdaten spezifizieren dann die Komponenten der zu testenden Systemgruppe, an die diese Daten übergeben werden, sowie ggf. die Beziehungen zwischen diesen Komponenten.
-
So kann beispielsweise während einer realen oder emulierten Testfahrt der gesamte Input, den eine einzelne Systemkomponente erhält, in einem Emulationscontainer aufgezeichnet werden, und wenn dann bei einem Softwareupdate nur die Software dieser einzelnen Systemkomponente verändert wird, so liefert der Emulationscontainer die Eingangsdaten, die es erlauben, diese Komponente isoliert zu validieren. Auf diese Weise ist es möglich, den Validierungsprozess für das Gesamtsystem in eine Kette von Validierungsschritten aufzuteilen, in denen jeweils eine andere Konfiguration von Systemgruppen validiert wird. Die in einem Validierungsschritt erhaltenen Resultate werden dann zusammen mit den Konfigurationsdaten in einem Container gespeichert und dienen im nächsten Schritt dazu, die Eingangsdaten für die in dem nächsten Schritt getestete Systemgruppe zu generieren. Das ermöglicht nicht nur eine größere Effizienz in den Fällen, in denen nur einige oder wenige Komponenten der Software verändert wurden, sondern ermöglicht auch eine schnellere und zielgerichtetere Fehlersuche, weil sich durch die isolierte Validierung verschiedener Systemgruppen die schafhafte Systemgruppe leichter lokalisieren lässt.
-
Im folgenden werden Ausführungsbeispiele anhand der Zeichnung näher erläutert.
-
Es zeigen:
- 1 ein Blockdiagramm, das zwei Schritte eines erfindungsgemäßen Validierungsverfahrens illustriert;
- 2 ein Blockdiagramm für einen Validierungsprozess, bei dem die Leistungen zweier Softwareversionen mittels emulierter Testsituationen miteinander verglichen werden;
- 3 eine Datenstruktur eines Basiscontainers, der dazu dient, emulierte Sensordaten zu generieren;
- 4 eine Datenstruktur eines abgeleiteten Containers, der dazu dient, Eingangsdaten für eine zu testende Systemgruppe aus den Daten eines Basiscontainers oder eines anderen abgeleiteten Containers zu generieren;
- 5 ein Diagramm einer modular aufgebauten Systemsoftware;
- 6 und 7 Diagramme zweier Validierungsschritte für verschiedene Systemgruppen, die jeweils Teil der in 5 gezeigten Systemsoftware sind;
- 8 ein Diagramm, das die Fusion dreier Container zu einem neuen abgeleiteten Container zeigt; und
- 9 und 10 Diagramme zweier weiterer Validierungsschritte.
-
In 1 sind zwei Schritte eines erfindungsgemäßen Validierungsverfahrens gezeigt, mit dem die Funktionen einer Systemgruppe R1 eines Fahrerassistenzsystems eines Kraftfahrzeugs getestet und validiert werden. Bei der Systemgruppe R1 kann es sich beispielsweise um die komplette Software des Fahrerassistenzsystems handeln, die Daten von einem Sensorsystem R0 empfängt. Ein erster Schritt a) des Verfahrens wird während einer Testfahrt mit einem Fahrzeug ausgeführt, in dem das Fahrerassistenzsystem mit der zu testenden Software installiert ist. Während der Fahrt liefert das Sensorsystem R0, beispielsweise ein Radarsensor, seine Sensordaten an die zu testende Systemgruppe R1. Die von der Systemgruppe R1 erzeugten Systemreaktionen, insbesondere Befehle der aktorischen Systemkomponenten des Fahrerassistenzsystems, werden in einem Vergleichsmodul VM mit Sollkriterien S1 verglichen, die das gewünschte Systemverhalten charakterisieren. Die Software gilt als erfolgreich validiert, wenn die von der Systemgruppe R1 gelieferten Systemreaktionen mit dem Sollkriterium übereinstimmen.
-
Die Sensordaten des Sensorsystems R0 werden während der Fahrt auch an ein Datenobjekt übermittelt, das als Basiscontainer BC bezeichnet wird. In diesem Basiscontainer werden die Sensordaten über die gesamte Fahrt hinweg aufgezeichnet und als Eingabedaten ED für einen späteren Validierungsschritt gespeichert. Konfigurationsdaten KD der zu testenden Systemgruppe R1, die die Konfiguration, beispielsweise die Softwareversion, der Systemgruppe R1 kennzeichnen, sind im Basiscontainer BC sind ebenfalls im Basiscontainer BC gespeichert.
-
Die eigentliche Validierung mit Hilfe des Vergleichsmoduls VM muss nicht während der Fahrt stattfinden, sondern kann auch zu einem späteren Zeitpunkt anhand der im Basiscontainer BC gespeicherten Eingabedaten erfolgen.
-
In einem Schritt b) wird die zu testende Systemgruppe R1 erneut validiert, nachdem in einem Software-Update die Systemsoftware verändert worden ist. Für diese erneute Validierung ist jedoch keine neue Testfahrt erforderlich, und das Sensorsystem R0 wird nicht benötigt, da für die Validierung auf die im Basiscontainer BC gespeicherten Eingabedaten ED zurückgegriffen werden kann. In diesem Beispiel soll jedoch angenommen werden, dass die Software der Systemgruppe R1 bei dem Update in einer solchen Weise verändert wurde, dass das Datenformat der Eingabedaten ED nicht mehr mit der Systemsoftware kompatibel ist, so dass die Systemgruppe R1 diese Daten nicht unmittelbar verarbeiten kann. Als einfaches Beispiel kann angenommen werden, dass Zahlenwerte, die einen Teil der Eingabedaten ED bilden, im Basiscontainer BC im Ganzzahlformat gespeichert sind, die Systemgruppe R1 jetzt aber Fließkommazahlen erwartet. Aus diesem Grund werden die Eingabedaten ED in das gewünschte Format konvertiert und als konvertierte Eingabedaten ED' in einem Datenobjekt abgelegt, das als abgeleiteter Container AC bezeichnet wird. Die Konvertierung erfolgt automatisch mit Hilfe eines Konvertierungsmoduls KM, das die Konfigurationsdaten KD für die alte Softwareversion aus dem Basiscontainer BC liest und aus dem abgeleiteten Container AC die Konfigurationsdaten KD' nach dem Update liest, die dort von der Systemgruppe R1 hinterlegt wurden. Auf diese Weise kann die Validierung trotz der Inkompatibilität der Softwareversionen mit Hilfe der Eingabedaten ED vorgenommen werden, die in Schritt a) aufgezeichnet wurden.
-
Die konvertierten Eingabedaten ED' müssen nicht zwingend im abgeleiteten Container AC gespeichert werden, sondern können wahlweise auch vom Konvertierungsmodul KM direkt an die zu testende Systemgruppe R1 übermittelt werden.
-
2 illustriert ein Beispiel eines Validierungsverfahrens, bei dem die Systemreaktionen zweier unterschiedlicher Konfigurationen (Softwareversionen) der Systemgruppe R1 direkt miteinander verglichen werden. Auch dabei wird keine neue Testfahrt ausgeführt, sondern die Testfahrt für die erste Softwareversion wird mit Hilfe der Basiscontainer BC gespeicherten Daten emuliert, und die Testfahrt für die Systemgruppe mit der neuen Softwareversion wird mit Hilfe der Daten emuliert, die im abgeleiteten Container AC gespeichert sind. Die beiden Emulationen laufen parallel, so dass die Systemreaktionen unmittelbar durch das Vergleichsmodul VM verglichen werden können. Auf diese Weise lässt sich feststellen, ob die an der Software vorgenommenen Änderungen irgendwelche unerwünschten Änderungen im Systemverhalten verursacht haben.
-
In 3 ist ein Beispiel für die Datenstruktur des Basiscontainers BC gezeigt. Dieser Container enthält die Eingabedaten, bei denen es sich in diesem Fall um Sensordaten SD des Sensorsystems R0 handelt, sowie die Konfigurationsdaten KD. Diese Konfigurationsdaten spezifizieren insbesondere die Konfiguration (Softwareversion und andere relevante Konfigurationsmerkmale) der zu testenden Systemgruppe. Wahlweise können zusätzlich jedoch auch Konfigurationsdaten gespeichert werden, die sich auf die vorgeschaltete Systemgruppe beziehen, in diesem Fall also auf das Sensorsystem R0.
-
Im gezeigten Beispiel enthält der Basiscontainer BC darüber hinaus noch weitere Daten, die nähere Umstände der Testfahrt beschreiben, bei der die Sensordaten aufgezeichnet wurden, und die für die Validierung relevant sein können. Beispielsweise können diese Daten Einfluss darauf haben, welche Sollkriterien bei der Validierung anzuwenden sind. In dem Fall wird auch das Vergleichsmodul VM auf die Daten im Basiscontainer BC zugreifen.
-
Im gezeigten Beispiel umfassen diese zusätzlichen Daten Metadaten MD, beispielsweise Attribute, die Tunnelfahrten,, die Wetterbedingungen während der Testfahrt und dergleichen charakterisieren, und die sogenannte Ground Truth GT, d.h., Daten, die das reale Geschehen während der Testfahrt wiederspiegeln. Dazu gehören insbesondere Infrastrukturdaten, die etwa in der Form einer digitalen Karte das während der Testfahrt durchfahrene Gelände beschreiben, sowie aufgezeichnete Daten über Eingriffe des menschlichen Fahrers in die Fahrzeugführung.
-
Eine Entwicklungsumgebung für die Softwareentwicklung kann als ein komplexes Netzwerk betrachtet werden, dessen Knoten die einzelnen Komponenten der Systemsoftware, die Vergleichsmodule, Konversionsmodule und Container sind, die über Schnittstellen miteinander kommunizieren.
-
4 zeigt ein Beispiel für eine Datenstruktur des abgeleiteten Containers AC. Dieser abgeleitete Container kann anstelle der Eingabedaten einen Link L/A zu einer Datenquelle enthalten, aus der die Eingabedaten bezogen werden können, ggf. kombiniert mit einem Link zu einem Konversionsmodul oder Adapter für die Anpassung der Datenformate. Im Übrigen ist die Datenstruktur die gleiche wie bei dem Basiscontainer BC (wobei die Inhalte teilweise verschieden sein können).
-
Im folgenden soll anhand der 5 bis 10 ein Beispiel eines Validierungsprozesses für eine Systemsoftware beschrieben werden, die eine Vielzahl von miteinander interagierenden Softwarekomponenten umfasst, die auch unabhängig voneinander validiert werden sollen. Die zu testende Systemgruppe ist in diesem Fall nicht das gesamte Fahrerassistenzsystem, sondern umfasst je nach Validierungsaufgabe unterschiedliche Kombinationen und Konfigurationen der einzelnen Komponenten.
-
In 5 sind als Blockdiagramm die Komponenten des Gesamtsystems dargestellt, das in diesem Beispiel das Sensorsystem R0 sowie neun Komponenten R1 - R9 der Systemsoftware des Fahrerassistenzsystems umfasst. Die Datenflüsse zwischen den verschiedenen Komponenten sind durch Pfeile dargestellt. Man erkennt, dass es in diesem System auch Rückkopplungsschleifen gibt. Beispielsweise wird ein Datenfluss von R1 über R2 zu R3 wieder an R1 zurückgekoppelt. Insgesamt erhält die Komponente R1 Input nicht nur vom Sensorsystem R0, sondern auch von den Komponenten R3 und R8.
-
6 illustriert einen ersten Validierungsschritt, in dem ein abgeleiteter Container AC1 generiert wird, der den Output der Komponente R8 aufzeichnet. Zugleich oder zu einem späteren Zeitpunkt kann geprüft werden, ob dieser Output der Komponente R8 mit den Sollkriterien übereinstimmt. Die Komponente R8 erhält mittelbar oder unmittelbar Input von den Komponenten R1, R2, R3, R4 und R7. Diese Komponenten bilden somit die zu testende Systemgruppe. Die Konfigurationsdaten dieser Systemgruppe geben u.a. an, welche Komponenten beteiligt sind und welche Kommunikationsbeziehungen zwischen ihnen bestehen und an welche Komponente(n) die Eingangsdaten zu übermitteln sind. Im gezeigten Beispiel ist dies die Komponente R1. Der Input für diese Komponente wird in diesem Validierungsschritt durch Emulation mit Hilfe des Basiscontainers BC generiert.
-
7 zeigt einen Emulationsschritt, in dem die getestete Systemgruppe nur aus den Komponenten R1, R2 und R3 besteht. Der Input für die Komponente R1 wird aus den Daten des Basiscontainers BC generiert, und der Output der Komponente R3 wird in einem abgeleiteten Container AC2 abgelegt. Gleichzeitig oder später kann dieser Output validiert werden.
-
Die zeitliche Reihenfolge zwischen den Validierungsschritten in 6 und 7 ist beliebig. In jedem Fall sind nach Ausführung dieser Validierungsschritte drei Container verfügbar, nämlich der Basiscontainer BC und die abgeleiteten Container AC1 und AC2. Wie schematisch in 8 dargestellt ist, werden diese drei Container nun zu einem größeren abgeleiteten Container AC3 fusioniert, der die Daten aller drei Container enthält (oder auf sie verweist).
-
9 zeigt einen nachfolgenden Validierungsschritt, in dem die zu testende Systemgruppe nur aus den Komponenten R1 und R2 besteht. Der Input für die Komponente R1 besteht in diesem Fall jedoch nicht nur aus dem Inhalt des Basiscontainers BC, sondern aus dem Inhalt des fusionierten Containers AC3 und repräsentiert somit den gesamten Input in die Komponente R1 (siehe 5).
-
Der zu validierende Output der in 9 getesteten Systemgruppe ist der Output von R2 und wird in einem neuen abgeleiteten Container AC4 abgelegt.
-
10 illustriert einen weiteren Validierungsschritt, in dem die getestete Systemgruppe aus den Komponenten R3 und R5 besteht. Der Input für die Komponente R3 wird aus dem Inhalt des Containers AC4 generiert und repräsentiert den gesamten Input dieser Komponente (siehe 5), einschließlich des Inputs, der durch die Rückkopplung des Outputs von R3 an R1 und R2 entsteht und in dem Container AC2 abgelegt ist (7). In dem Validierungsschritt gemäß 10 kann der Output der Komponente R5 validiert werden. Wahlweise kann ein weiterer abgeleiteter Container generiert werden, der dann analog zu dem oben beschriebenen Prinzip den Input für die Validierung weiterer Systemgruppen liefert, die die Komponenten R5, R6 und R9 enthalten.
-
Wie 6 zeigt, wird der Container AC1 nicht durch irgendeinen Output der Komponenten R5 und R6 beeinflusst. Ebenso hat der Output der Komponenten R5 und R6 auch keinen Einfluss auf die Inhalte der Container AC2 (7), AC3 (8) und AC4 (9). Wenn nun bei einem Software-Update beispielsweise nur die Komponente R5 verändert wird, so genügt es, den Validierungsschritt gemäß 10 auszuführen und dabei das gesamte Systemverhalten der übrigen Systemkomponenten mit Hilfe des Inhalts des Containers AC4 zu emulieren, da der Inhalt dieses Containers durch die Änderung nicht beeinflusst wurde. Auf diese Weise wird der Emulationsprozess insbesondere in den Fällen vereinfacht, in denen nur einzelne Komponenten des Systems verändert wurden.
-
Wenn nun umgekehrt bei einem Test des Gesamtsystems (Output der Komponente R9 in 5) ein Fehler festgestellt wird, dessen Ursache nicht bekannt ist, so lässt sich dieser Fehler einfacher lokalisieren, indem man beispielsweise zunächst den Validierungsschritt gemäß 6 ausführt. Wenn sich dabei zeigt, dass der Inhalt des Containers AC1 den Sollkriterien entspricht, so deutet dies darauf hin, dass der Fehler eher nicht auf eine Fehlfunktion einer der Komponenten R1 bis R4, R7 und R8 zurückzuführen ist, sondern auf einer Fehlfunktion einer der übrigen Komponenten beruhen dürfte.