So zeichnet der Event Data Recorder die richtigen Daten auf

Was tun, wenn der Zeuge lügt? Geschieht ein Unfall und sind mehrere Parteien beteiligt, so eröffnet sich die Frage nach der Schuld. Wenn es Augenzeugen gibt, kann die Polizei diese befragen. Deren Berichte sind jedoch subjektiv und können falsch sein. Die nationalen Behörden entgegnen dieser Problematik mit der gesetzlichen Festlegung, dass Fahrzeuge mit einem Event Data Recorder (EDR) auszustatten sind. Der EDR hat den Zweck, objektiv Unfalldaten aufzuzeichnen, sodass anschließend eine Unfallrekonstruktion möglich ist und diese zur Klärung der Schuldfrage verwendbar ist. Standardmäßig ist der EDR Teil der Airbag-Control-Unit (ACU), weil sich dadurch bei einem Unfall sowohl der mechanische Schutz sowie Spannungsversorgung als auch Nachlaufzeiten und dabei der Zugriff auf die relevanten Crashdaten einfach realisieren lassen. Wer aber stellt sicher, dass der EDR nicht wie jeder andere „Augenzeuge“ womöglich nur einen Teil der Wahrheit aussagt oder gar falsche Informationen liefert?

Bild 1: Ein Einzelereignis beschreibt einen Unfallhergang, der zeitlich alleinstehend ist. Continental

Um „Falschaussagen“, also fehlerhafte EDR-Aufzeichnungen, zu verhindern, verwendet Continental eine Testmethode, die der funktionalen Komplexität des EDR Rechnung trägt und bereits in der Serienentwicklung Anwendung findet. Sie soll zeigen, inwiefern die einleitende Frage „Was tun, wenn der Zeuge (EDR) lügt?“ für den EDR relevant ist und wie sich diese Fragestellung im EDR widerspiegelt. Das Ziel des Systemtests ist sicherzustellen, dass die im Steuergerät implementierte EDR-Funktionalität jederzeit und unter allen Umständen die richtigen Unfalldaten vollständig und gesetzeskonform aufzeichnet.

Die EDR-Aufzeichnung

Gesetze regeln, welche Daten im Falle eines Unfalls aufzuzeichnen sind und wann eine EDR-Aufzeichnung stattfinden darf. Die vorgestellte Testmethode deckt jenen Teilaspekt des EDR-Testens ab, der die zeitliche Abhängigkeit abbildet, also die Aufzeichnung des Unfallverlaufes an sich. Für den EDR gibt es hierfür drei relevante Kriterien: Den Startzeitpunkt der Aufzeichnung, die Entscheidung, ob die laufende Aufzeichnung zu speichern beziehungsweise zu verwerfen ist und schließlich den Endzeitpunkt der Aufzeichnung. Zum Startzeitpunkt friert der EDR die kontinuierlich gepufferten Daten ein, die sogenannten Pre-Crash-Daten. Anschließend zeichnet der EDR weitere Informationen auf, beispielsweise Zündentscheidungen für das Auslösen von Airbags. Dies entspricht den In- und Post-Crash-Daten. Erfolgt während der Aufzeichnung eine Zündentscheidung, so ist dieses Ereignis zu speichern. Erfolgt keine Zündentscheidung und ist auch die Startbedingung nicht mehr erfüllt beziehungsweise der Endzeitpunkt der Aufzeichnung erreicht, so ist das laufende Ereignis nicht relevant und ist zu verwerfen.

Die Aufzeichnungslänge der Post-Crash-Daten ist gesetzlich definiert und legt damit einen fixen Endzeitpunkt fest. Zusätzlich ist gesetzlich festgelegt, dass bei Speicherung eines EDR-Datensatzes auch eine Information durch den EDR selbst abzulegen ist, ob dieser Datensatz „vollständig aufgezeichnet“ ist oder nicht.

Bild 2: Bei einem Parallelereignis finden mindestens zwei sich überlappende Einzelereignisse statt, und das Mehrfachereignis beschreibt mindestens zwei aufeinander folgende Einzelereignisse, die maximal fünf Sekunden Zeitunterschied haben. Continental

Neben diesen Kriterien gilt es auch die zeitliche Abhängigkeit zu betrachten, das heißt die Kombination von Unfallereignissen. Der EDR unterscheidet dabei zwischen drei verschiedenen Ereignistypen: Einzel-, Parallel- und Mehrfachereignis. Ein Einzelereignis beschreibt einen Unfallhergang, der zeitlich alleinstehend ist (Bild 1).

Bei einem Parallelereignis finden mindestens zwei sich überlappende Einzelereignisse statt und das Mehrfachereignis beschreibt mindestens zwei aufeinander folgende Einzelereignisse, die maximal fünf Sekunden Zeitunterschied haben (Bild 2). Die Wichtigkeit der verschiedenen Ereignistypen liegt darin begründet, dass der EDR ein jeweils unterschiedliches Aufnahme- und Speicherverhalten pro Ereignistyp hat.

Herausforderung im Test des Event Data Recorder

Bild 3: Ein zu vermeidender Worst Case des EDR wäre, dass dieser ausschließlich solche Ereignisse aufzeichnet, die eigentlich zu verwerfen sind, und jene Ereignisse mit einer Zündentscheidung dann nicht mehr aufzeichnen kann, weil der Speicher bereits voll ist Continental

Die zu betrachtende Komplexität für den EDR ist, dass dieser jeden theoretisch möglichen Unfallverlauf aufzeichnen können muss – ganz gleich, welcher Ereignistyp stattfindet oder wie viele vorhergehende Ereignisse stattgefunden haben, die zum Beispiel die Startbedingung erfüllten, anschließend aber zu verwerfen waren. Erfolgt ein Unfall, bei dem ein Airbag oder Rückhaltemittel zündet, ist dieses Ereignis im EDR zuverlässig, vollständig und nicht überschreibbar zu speichern.

Ein zu vermeidender Worst Case des EDR wäre, dass dieser ausschließlich solche Ereignisse aufzeichnet, die eigentlich zu verwerfen sind, und jene Ereignisse mit einer Zündentscheidung dann nicht mehr aufzeichnen kann, weil der Speicher bereits voll ist (Bild 3). Hervorzuheben ist: Es gibt keine Möglichkeit, „den“ Worst Case zu definieren, denn die unendlichen Möglichkeiten an Unfallkombinationen lassen sich nicht auf „den einen Fall“ reduzieren. In Kombination mit Parallel- und Mehrfachereignissen vergrößert sich die Unfalldynamik und deren Aufzeichnung beliebig komplex. Daraus ergibt sich die anfangs aufgeführte Fragestellung, ob der EDR „nur einen Teil der Wahrheit aussagt oder gar falsche Informationen liefert“. Im Rahmen der Entwicklung gilt es abzusichern, dass dieser Fall nicht eintritt. Für den Systemtest bedeutet dies, dass es zum Erreichen der maximalen Testabdeckung nötig ist, den EDR theoretisch mit allen im realen Straßenverkehr möglichen Unfallverläufen zu verifizieren. Da dies jedoch nicht umsetzbar ist, gilt es ein geeignetes Testende-Kriterium zu formulieren.

Testmethode

Bild 4: Definition der Testeingangsdaten durch Transformation der EDR-Aufzeichnung. Continental

Der Versuch, die vollständige Dynamik der realen Unfallhergänge als Testeingangsdaten bereitzustellen, ist bereits von Beginn an zum Scheitern verurteilt. Es gibt eine unendliche Anzahl an Kombinationen. Allein aus Zeitgründen ist dies in der Serienentwicklung nicht zu realisieren. Um sich dennoch der vollständigen Dynamik maximal anzunähern, erfolgt die Umsetzung dahingehend, gewünschte Zielzustände eigenständig zu formulieren. Diese Definition erfolgt direkt im Ausgabeformat des Systems, dem EDR-Datensatz. Mithilfe geeigneter Methoden, zum Beispiel Computational- Intelligence oder auch Partikelschwarm-Optimierung, lassen sich ausgehend von einem definierten Zielzustand iterativ Eingangsgrößen generieren, wobei eine Korrelation von Zielzustand und Eingangsgröße nötig ist.

Diese Methode generiert automatisch stochastische Testeingangsgrößen, die sich von einem definierten Zielzustand der Funktion ableiten lassen. Damit wird das Problem von der Definition der Eingangsgrößen transformiert zur Definition der funktionalen Zielzustände. Da diese Zielzustände durch gesetzliche Anforderungen definiert und begrenzt sind, lässt sich hieraus ein geeignetes, messbares und dadurch realistisches Testende-Kriterium definieren (Bild 4).

Anwendung der Testmethode für den Event Data Recorder

Die genannte Testmethode kommt direkt beim HiL-Test zum Einsatz. Um eine möglichst maximale Testabdeckung in der verfügbaren Zeit zu erreichen und die Testdurchführung reproduzierbar zu machen, besteht das Ziel darin, die Testdurchführung inklusive Auswertung bis zum maximalen Grad zu automatisieren.

Bild 5: Für das Starten des Systemtests ist ein Minimum an Parametern zu definieren. Vorgegebene Informationen über mögliche Crashtypen (Front, Seite, Heck…) und EDR-Ereignistypen (Einzel-, Parallel- oder Mehrfachereignis) dienen als Eingangsparameter und starten den Test Continental

Für das Starten des Systemtests ist ein Minimum an Parametern zu definieren. Vorgegebene Informationen über mögliche Crashtypen (Front, Seite, Heck etc.) und EDR-Ereignistypen (Einzel-, Parallel- oder Mehrfachereignis) dienen als Eingangsparameter und starten den Test (Bild 5). Ob im zeitlichen Verlauf nicht aufzeichnungsrelevante Ereignisse stattfinden sollen, lässt sich zusätzlich definieren. Diese Informationen spannen einen Suchraum für die Eingangsgrößen auf. In dieser Testmethode wird entweder per Zufallsverfahren oder durch den Tester jeder dieser Eingangsparameter festgelegt und anschließend der Systemtest inklusive Auswertung gestartet. Die Vorgabe per Zufallsverfahren soll keineswegs dem Tester die Kompetenz absprechen. Vielmehr liegt die Problematik in der menschlichen Komponente. Ein Tester kann aufgrund von Erfahrung und Wissen spezifische Testeingangsdaten zügig definieren. Um sich jedoch der vollständigen Dynamik der realen Welt anzunähern, reicht weder die menschliche Leistungsfähigkeit noch wäre es effizient, dies zu versuchen.

Die Auswertung ist in zwei Aspekten zu unterscheiden. Erstens, die Überprüfung auf formale Korrektheit des gespeicherten EDR-Datensatzes, das heißt komplett unabhängig von der inhaltlichen Überprüfung der Aufzeichnung. Dieser Formalismus umfasst unter anderem die Anzahl der belegten EDR-Einträge sowie die Vollständigkeit der Datenaufzeichnung. Zweitens, die Prüfung auf vollständige und korrekte inhaltliche Aufzeichnung. Hierfür kommt zusätzlich ein Simulationsmodell zum Einsatz, das den EDR idealisiert abbildet. Dieses Modell erhält als Eingangsgrößen ebenfalls die automatisiert generierten Eingangsgrößen und liefert als Ergebnis einen zu erwartenden EDR-Datensatz.

Insgesamt wird somit der vom real getesteten System aufgezeichnete EDR-Datensatz sowohl auf formale Korrektheit überprüft als auch zeitgleich inhaltlich ausgewertet. Diese kombinierte Auswertung gilt es keineswegs zu vernachlässigen. Ein inhaltlich korrekt aufgezeichneter EDR-Datensatz, der den Unfallhergang vollständig aufgezeichnet hat, könnte fälschlicherweise durch systeminterne Vorgänge als unvollständig gekennzeichnet sein. In diesem Fall wäre es für eine Unfallrekonstruktion schwierig bis gar unmöglich, im Nachhinein zu unterscheiden, ob tatsächlich die Aufzeichnung unvollständig war oder ob systeminterne Vorgänge dies bewirkt haben und die Aufzeichnung an sich verlässlich ist.

Vorteile der Testmethode des EDR

Das Konzept dieser Testmethode erlaubt es, basierend auf der Korrelation von System-Eingangsdaten und EDR-Ausgabedaten, beliebige Daten miteinander zu kombinieren. Der Vorteil liegt darin, dass es lediglich nötig ist, die Korrelation selbst herzustellen. Die Anwendung eines geeigneten Werkzeugs wie zum Beispiel genetische Algorithmen (als Bestandteil von Computational-Intelligence) ermöglicht anschließend die automatisierte Generierung von Eingangsdaten für den Systemtest. Die Kombination mit einem Simulationsmodell bietet zusätzlich die vollautomatisierte Durchführung und Auswertung verschiedener Teilaspekte des Testens des EDRs in einem Schritt. Somit ist diese Testmethode einerseits robust gegenüber funktionalen Änderungen, andererseits zugleich flexibel hinsichtlich funktionalen Erweiterungen.

Fazit

Die einleitende Frage „Was tun, wenn der Zeuge lügt?“ ist im Rahmen der Software-Entwicklung in zwei Schritten zu beantworten. Zuerst gilt es, die „Lüge“ zu identifizieren und das heißt, dass der Test nach Fehlerwirkungen des Systems sucht. Bei Abweichungen startet eine entsprechende Fehlerkorrektur.

Die vorgestellte Testmethode ermöglicht es, automatisiert nach Fehlern zu suchen und die Suchräume, nämlich die Unfallhergänge, beliebig und automatisiert zu verändern. Zugleich identifiziert sie eine etwaige Fehlerwirkung. Diese Methode liefert eine wesentliche höhere Testabdeckung als herkömmliche Testfallentwicklungsmethoden, was zu einer Steigerung der Software-Qualität führt und der hohen Relevanz des EDR Rechnung trägt.

(aok)

(aok)