Erläuterungen am Beispiel einer automatischen Außenlichtsteuerung

Diagnoseverifikation in frühen Entwicklungsphasen

27. Januar 2009, 9:26 Uhr | Valentin Adam, Heinrich Balzer, Matthias Kohlweyer und Petra Nawratil
Diesen Artikel anhören

Fortsetzung des Artikels von Teil 3

Diagnoseverifikation in frühen Entwicklungsphasen

Diese Prozesse müssen durch Methoden und Werkzeuge unterstützt werden. Mit dem AUTOSAR-Standard [1] ist es möglich, Software-Komponenten und ganze Systemarchitekturen formalisiert darzustellen und so eine eindeutige Beschreibungssprache zu haben. Im Architekturwerkzeug SystemDesk von dSpace kann eine AUTOSAR-Architektur nicht nur modelliert [2], sondern auch simuliert werden [3]. Damit ergibt sich die Möglichkeit, schon früh ein (verteiltes) Gesamtsystem aufzubauen und Tests durchzuführen, die auch die Diagnosefunktionen mit abdecken.

Systemarchitektur der Außenlichtsteuerung

In einem gemeinsamen Projekt mit der Daimler AG untersuchte dSpace beispielhaft, welche Möglichkeiten sich durch einen frühen Test von Diagnosefunktionen ergeben. Die Daimler AG setzt bereits verstärkt auf die modellbasierte Entwicklung mit AUTOSAR, so dass komplette Systemmodelle basierend auf AUTOSAR vorliegen. Als Fallstudie wurde ein System zur automatischen Lichtsteuerung ausgewählt (Bild 1). Ziel war es, ein simulationsfähiges System zu modellieren, das zum Testen der Diagnose eingesetzt werden kann.

Ein zentrales Lichtmodul ist hierbei für die Aktivierung der unterschiedlichen Leuchten des Fahrzeugs zuständig. Seine Eingaben erhält es unter anderem von dem durch den Fahrer zu betätigenden Lichtdrehschalter und von einem Regen-Lichtsensor. Erkennt dieser Sensor eine Regen- oder Dunkelheitssituation, kann das Fahrlicht automatisch aktiviert werden. Neben der zentralen Lichtsteuerungs-Software-Komponente enthält das System Software-Treiber, die auf zwei Steuergeräte verteilt sind – jeweils für die vorderen und die hinteren Lichtmodule. Zusätzlich sind als Streckenmodelle die Modelle der Treiber und der Leuchtmittel integriert.

Entscheidend ist zudem, dass die Zugriffe der Applikations-Software-Komponenten auf die Basis-Software modelliert und später simuliert werden können. Zur Realisierung der Diagnosefunktionen sind insbesondere die beiden Module „Diagnostic Event Manager“ (DEM) und „Diagnostic Communication Manager“ (DCM) als Bestandteil der Basis-Software wichtig. Bei einem von der Applikation entdecktes oder auch durch einen Treiber gemeldetes Fehlverhalten des Systems erfolgt ein Funktionsaufruf an den DEM, wodurch das Fehlverhalten als Status eines vordefinierten Events gesetzt wird. Das Diagnosemodul selbst speichert den zugeordneten Fehler (DTC; Diagnostic Trouble Code) ab. Diese Fehlerspeichereinträge können dann zum Beispiel in einer Werkstatt mit Hilfe eines Testers ausgelesen werden. Dazu nimmt der DCM die Diagnoseanfragen des Werkstatttesters entgegen, sammelt die notwendigen Daten und generiert die Antwort.

89ah0201_af_04.jpg
Bild 1. Grafische Modellierung der Komponenten der Lichtsteuerung (links in roter Farbe) und der dazugehörigen Streckenmodelle (rechts in blauer Farbe).

Nachdem die einzelnen Applikations-Software-Komponenten mit einem AUTOSAR-konformen Verhaltensmodellierungswerkzeug, zum Beispiel TargetLink von dSpace, modelliert sind, wird ihr Code inklusive der AUTOSAR-Software-Komponentenbeschreibung erzeugt. Ist die Systemarchitektur bereits im Vorfeld vorhanden, so müssen lediglich die Implementierungen ergänzt werden. Andernfalls werden die einzelnen Komponenten in SystemDesk zu einer Architektur zusammengeführt. Dabei wird auch der DEM konfiguriert und mit den Applikations-Software-Komponenten verbunden. Für die Simulation kann entweder ein herstellerspezifischer DEM oder ein in SystemDesk selbst konfigurierbarer DEM eingebunden werden. Außerdem wird die Architektur auf die Hardware-Topologie mit mehreren Steuergeräten abgebildet.

In SystemDesk kann letztlich auch die Runtime Environment (RTE) generiert werden, die als Middleware der AUTOSAR-Architektur die Kommunikation zwischen Applikations-Software-Komponenten und Basis-Software-Komponenten realisiert. Zusammen mit dem Applikationscode für die einzelnen Software-Komponenten ist es dann möglich, das Gesamtsystem in SystemDesk zu simulieren.


  1. Diagnoseverifikation in frühen Entwicklungsphasen
  2. Diagnoseverifikation in frühen Entwicklungsphasen
  3. Diagnosetest
  4. Diagnoseverifikation in frühen Entwicklungsphasen

Jetzt kostenfreie Newsletter bestellen!