Technische Artikel

Entwicklung und Test elektronischer Karosseriesysteme bei Jaguar

Von Rich Humphrey, Jaguar Cars und Alexandros Mouzakitis, Jaguar Cars


jaguarmain_w.jpg

Eine gut aufgeführte Karosserieelektronik (Electronic Body System, EBS) ist ein wichtiger Faktor für die Akzeptanz eines Automobils, denn Funktionen wie Beleuchtung, Scheibenreinigung und Zentralverriegelung fallen dem Kunden als erstes ins Auge. Ein hervorragend konstruiertes Schließsystem wird ihn zwar nicht überzeugen, ein bestimmtes Auto zu kaufen; ein schlecht konstruiertes wird ihn aber sicherlich abschrecken, sich in Zukunft wieder für die entsprechende Marke zu entscheiden.

Intuitive, logische und klar strukturierte EBS-Systeme unterstreichen zwar den Eindruck, ein hochwertiges Fahrzeug vor sich zu haben, sind aber zunehmend schwerer zu entwickeln. Immer mehr Steuerfunktionen sind aus Komfortgründen automatisiert, wobei die Steuerelemente immer weiter verteilt werden, um weniger Verkabelung zu benötigen und so mehr freien Innenraum zu gewinnen.

Der konventionelle Entwicklungsansatz bei Jaguar geriet durch diese Anforderungen immer weiter unter Druck und es wurde für die Entwickler zunehmend schwierig, EBS-Systeme rechtzeitig fertig zu stellen. Die Lösung war ein automatisiertes virtuelles Integrations- und Testlabor.

Der konventionelle Entwicklungsprozess bei Jaguar

Im ersten Schritt der Entwicklung einer EBS-Software bei Jaguar formulieren üblicherweise die Systemingenieure die Anforderungen und geben diese als schriftliche Spezifikation an ihre Zulieferer weiter, die die Module als Hardware und Software entwickeln. Nachdem der Zulieferer ein Modul gegen diese Spezifikation getestet hat, übergibt er das fertige Modul an Jaguar, wo es dann von Ingenieuren zunächst auf einem „Breadboard“ (Versuchsmodell) und dann in einem Prototypenfahrzeug getestet wird.

Dieser Ansatz beinhaltet drei grundlegende Probleme:
  • Schriftliche Spezifikationen sind unvollständig und können fehlinterpretiert werden.
  • Aussagekräftige Systemtests können erst spät im Projektverlauf beginnen.
  • Die Systemtests sind komplex und extrem arbeitsaufwändig.

Während man sich des ersten Problems allgemein in Entwicklungsabteilungen bewusst ist, werden die beiden anderen Probleme dagegen zum großen Teil durch die prinzipiellen Grenzen des Breadboard-Ansatzes verursacht.

Grenzen von Breadboards

Auf einem Breadboard (Abb. 1) werden sämtliche elektrischen Module, Sensoren, Schalter und Stellglieder des Fahrzeugs zusammengefasst und mit dem Serien-Kabelbaum miteinander verbunden.

Dieser Ansatz hat einige grundlegende Mängel. Erstens kann man erst mit aussagekräftigen Tests beginnen, wenn sämtliche Komponenten und der Kabelbaum verfügbar sind. (Der Kabelbaum wird meistens zuletzt fertig, oft erst zwei Wochen vor dem Bau des ersten Prototypen.) Zweitens müssen alle Tests manuell mit den echten Schaltern, Sensoren und Aktuatoren durchgeführt werden. Drittens ist es schwierig, das Systemverhalten unter Fehlerbedingungen, beispielsweise einer durchgebrannten Sicherung oder eines Kurzschlusses, zu testen, weil man jeden einzelnen Fehler mühsam einbauen muss. Und schließlich geben Breadboard-Tests nur das Verhalten unter statischen Bedingungen wieder. Systeme, die ihr Verhalten während der Fahrt verändern, wie eine automatische Türverriegelung beim Anfahren, können so nur schwer getestet werden.

Gerade gegen Ende des Entwicklungszyklus bedeuten diese Probleme eine hohe Belastung für die Ingenieure. Mängel in den schriftlichen Spezifikationen werden daher meist erst kurz vor dem Bau des Prototypen entdeckt. Von diesem Moment an hinken die Ingenieure ständig hinterher und kämpfen sich durch zahllose Softwarefehler und die wochenlange, ermüdende manuelle Verifikation.

jaguarfig1_w.jpg
Abb. 1: Ein konventionelles Breadboard. Zum Vergrößern auf das Bild klicken.

Einführung von Model-Based Design

Die Simulation and Control Group von Jaguar Cars ist dafür verantwortlich, den Einsatz Modell-basierter Entwicklungs- und Testmethoden für Software in sämtlichen elektrotechnischen Abteilungen von Jaguar und Land Rover voranzutreiben und zu unterstützen. Bei Jaguar hatte man sich bis dahin hauptsächlich auf Anwendungen im Chassis- und Antriebsstrangbereich konzentriert, insbesondere auf Hardware-in-the-Loop-Tests.

Ab März 2003 wurde die Unterstützung des Model-Based Design bei Jaguar auch auf den EBS-Bereich ausgedehnt. Das Herzstück der Methodik ist das ‘EBS Virtual Integration and Test Automation Laboratory’ (EBS-VITAL). Mit dem EBS-VITAL (Abb. 2), der simulationsgestützten Version des traditionellen Breadboards, können die Ingenieure die EBS-Software bereits in einem sehr frühen Entwicklungsstadium automatisch testen.

jaguarfig2_w.jpg
Abb. 2: Topologie des EBS-VITAL. Zum Vergrößern auf das Bild klicken.

Automatisierte Tests mit EBS-VITAL

Im EBS-VITAL sind sämtliche Steuermodule des EBS mit einem speziellen, von dSPACE entwickelten Echtzeitsimulator (Real-Time Simulator, RTS) verbunden. Das Team kann damit Simulink-Modelle der EBS-Sensoren und -Stellglieder und sogar einfache Modelle der Antriebs- und Entertainment-Systeme des Fahrzeugs in Echtzeit simulieren. Die Module sind über einen einfachen Kabelbaum, der alle Modul-I/Os direkt mit dem RTS verbindet, an das EBS-VITAL angeschlossen.

Der frühzeitige Aufbau von Modellen erhöht ganz erheblich die Chance, Probleme im System­entwurf oder fehlerhafte Modulspezifikationen zu entdecken.

Das EBS-VITAL hat im Vergleich mit konventionellen Breadboards viele Vorteile. Der gesamte Testplan für die Sicherheitssoftware kann in 36 Stunden abgearbeitet werden (in der Regel über das Wochenende). Dazu kommen zwei Personentage für die Auswertung. Von Hand durchgeführt würden diese Tests über vier Personenwochen dauern. Die Tests können jetzt viel früher anfangen, weil die Verkabelung des EBS-VITAL nicht so kompakt sein muss wie der echte Kabelbaum. Noch nicht fertige Module lassen sich außerdem in der Simulation durch Simulink-Modelle ersetzen.

Dynamische Funktionen können auf einfache Weise durch simulierte Probefahrten getestet werden. Das EBS-VITAL vereinfacht außerdem das Testen des Systemverhaltens in Fehler- und Grenzsituationen: Die Sensor- und Aktuatormodelle sind zu diesem Zweck leicht modifizierbar und der gesamte RTS-I/O ist mit einem Fehlergenerator verbunden, wodurch jederzeit Fehlerszenarien in die automatischen Tests eingebaut werden können.

Einer der größten Vorteile des EBS- VITAL besteht darin, dass sich Funktionen auch spät im Projektverlauf verändern lassen. Die Ingenieure können die Modulmodelle einfach durch Modelle mit neuer Funktionalität ersetzen und dann nicht nur das veränderte Modul, sondern sämtliche Systemfunktionen automatisch gründlich neu testen. Auf diese Weise können unerwartete Nebenwirkungen einer Modifikation aufgedeckt und behoben werden, bevor Zulieferer die Software verändern. Der Zeit- und Kostenaufwand für den Einbau neuer Funktionen ist damit drastisch gesunken.

Entwicklung in völlig neuem Gewand

Die Tests mit dem EBS-VITAL und Model-Based Design bestehen aus drei Phasen:

In Phase eins werden alle EBS-Module durch Simulink- und Stateflow-Modelle ersetzt, die die Systemanforderungen widerspiegeln. Die Modul-Zulieferer entwickeln die Hardware und Software anhand dieser Modelle und testen das Modul gegen die Spezifikation.

Phase zwei beginnt, sobald ein Modul fertig ist. In dieser Phase ist das EBS-VITAL eine Mischung aus echten Modulen und Modellen.

Sobald das letzte Modul fertig ist, beginnt Phase drei. Das EBS-VITAL enthält dann nur noch echte EBS-Module.

In der Praxis werden nur selten alle Steuer­module des EBS durch Modelle ersetzt. Die Mehrzahl der Systeme bei Jaguar enthält mindestens ein Modul aus einem früheren Projekt. Die Erstellung eines Modells dafür macht dann wenig Sinn. Stattdessen wird möglichst bald die echte Hardware eingebaut. Das EBS-VITAL geht dann sofort in die Hybrid-Phase zwei über.

Fazit

Wenn man bereits in einem führen Entwicklungsstadium Modelle erstellt, erhöht das deutlich die Chance, Probleme im System­­entwurf oder fehlerhafte Modulspezifikationen zu entdecken. Anhand der Modelle können die Ingenieure am Anfang eines Programms Entscheidungsträgern die neuen Funktionen demonstrieren und erhalten so frühzeitig ein Feedback, das Änderungen in letzter Minute vermeiden hilft. Einige Modelle wurden sogar so detailliert ausgearbeitet, dass die Software für das Modul daraus problemlos mit dem Stateflow Coder automatisch generiert werden konnte.

Neben seinen vielen Vorteilen ist Model-Based Design aber auch mit neuen Herausforderungen verbunden. Die Erstellung der Modelle aller Module ist relativ aufwändig. Wenn ein Modell-basiertes Projekt parallel mit konventionellen Projekten betrieben wird, die besonders gegen Ende des Programms enorme Ressourcen beanspruchen, kann das Probleme bereiten. Außerdem brauchen Systemingenieure mit wenig Programmiererfahrung Zeit und Unterstützung, um Kompetenz im Umgang mit Simulink und Stateflow zu entwickeln und Modelle erstellen zu können, aus denen automatisch Produktionscode erzeugt werden kann.

Glücklicherweise sind dies Hürden, die mit jedem neuen Projekt niedriger werden, und der Nutzen, den die Einführung von Model-Based Design mit sich bringt, übertrifft unserer Meinung nach alle dazu nötigen Investitionen bei weitem.

Veröffentlicht 2006 - 91419v00

Eingesetzte Produkte

Weitere Informationen

Artikel für ähnliche Einsatzgebiete anzeigen

Artikel für verwandte Branchen anzeigen