Erläuterungen am Beispiel einer automatischen Außenlichtsteuerung Diagnoseverifikation in frühen Entwicklungsphasen

Die Firmen dSpace und Daimler AG erstellten im Rahmen eines Gemeinschaftsprojekts eine Umgebung, in der die Diagnosefunktionen eines Systems bereits zu einem sehr frühen Entwicklungszeitpunkt abgesichert werden können. Sie integrierten AUTOSAR-konforme Steuergeräte-Applikationen wie die Lichtsteuerung...

Erläuterungen am Beispiel einer automatischen Außenlichtsteuerung

Die Firmen dSpace und Daimler AG erstellten im Rahmen eines Gemeinschaftsprojekts eine Umgebung, in der die Diagnosefunktionen eines Systems bereits zu einem sehr frühen Entwicklungszeitpunkt abgesichert werden können. Sie integrierten AUTOSAR-konforme Steuergeräte-Applikationen wie die Lichtsteuerung inklusive der nötigen Strecken- und Treibermodelle in eine Systemarchitektur, banden konfigurierte Basis-Software-Module in das System mit ein und generierten die für die Kommunikation notwendige RTE. Außerdem kamen im realen Testprozess verwendete Testvektoren zum Einsatz, um das System offline simulieren zu können.

Elektronische Fehler im Kfz, zum Beispiel ein gebrochenes Kabel oder ein Sensor, der fehlerhafte Daten liefert, sind unvermeidlich. Darauf muss die elektronische Steuerung reagieren. Beispielsweise muss eine automatische Lichtsteuerung, die das Licht bei Dunkelheit aktiviert, dieses auch im Fehlerfall vorsichtshalber einschalten, wenn der Helligkeitssensor defekt ist. Zudem ist eine Anzeige des Fehlers im Display des Autos sinnvoll. Dazu müssen jedoch Diagnosefunktionen vorhanden sein, die einen Fehler entdecken, analysieren und darauf reagieren. Diese Diagnosefunktionen der Steuergeräte müssen im Entwicklungsprozess frühzeitig getestet werden.

Herausforderung: Diagnosetest

Im heutigen Entwicklungsprozess werden oft einzelne Software-Komponenten entwickelt und getestet, danach folgt die Integration und erst zum Schluss kann eine Betrachtung des Gesamtsystems aus Diagnosesicht erfolgen. Somit kann auch der Test der Diagnosefunktionen erst sehr spät im Gesamtsystem durchgeführt werden – oft erst im realen Fahrzeug.

Ein Grund für den späten Test ist die Verteilung der Diagnose über das Gesamtsystem. Sie muss nicht nur Fehler einzelner Komponenten identifizieren, sondern auch funktionale Zusammenhänge eines Systems diagnostizieren, das oft über mehrere Steuergeräte verteilt und durch unterschiedliche Software-Komponenten realisiert ist. Wünschenswert ist es daher, den Entwicklungsprozess dahingehend zu unterstützen, dass bereits frühzeitig ein komplettes System mit mehreren Software-Komponenten aufgebaut werden kann, das eine Analyse und Verifikation der Diagnose ermöglicht. Ziel ist es letztlich, damit schneller und effektiver einen hohen Reifegrad der Diagnosefunktion zu erreichen.