Startseite > Automotive > Software + Tools > Komfortable Konfiguration von AUTOSAR-Steuergeräten

Entwicklungsprozesse

Komfortable Konfiguration von AUTOSAR-Steuergeräten

8. September 2014, 14:04 Uhr | Von Matthias Wernicke

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Ableiten von Parametern

Die Konfiguration der Kommunikationsmodule für CAN, LIN, FlexRay oder Ethernet muss zu der vom OEM stammenden Systembeschreibung passen. AUTOSAR sieht hierfür vor, dass eine Basiskonfiguration (Base EcuC) der Module aus einem ECU-spezifischen Extrakt der Systembeschreibung (System Extract) abgeleitet wird.

Jobangebote+ passend zum Thema

Regional Key Account (m/w/d) für Elektronische Bauteile

KOA Europe GmbH, Dägeling

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

In der Praxis sieht die Situation allerdings etwas komplizierter aus (Bild 3): AUTOSAR hat ein Standardformat für die Systembeschreibungen definiert. Neben diesem Format setzen die OEMs aber auch die traditionellen Formate DBC, LDF und FIBEX ein. Außerdem verwendet der Tier 1 möglicherweise eigene Systembeschreibungen, etwa für private CAN-Busse innerhalb des Steuergerätes oder für LIN-Busse zur Anbindung von Sensoren.

Das Software-Werkzeug muss also alle möglichen Arten von Eingangsdaten erkennen, durch geeignetes Vorverarbeiten die traditionellen Formate konvertieren und ECU-spezifische Extrakte erzeugen. Auch das Zusammenfügen von mehreren separaten Systembeschreibungen zu einer gemeinsamen Beschreibung muss möglich sein. Erst dann kann das Generieren der Base EcuC starten.

Ähnliches gilt für die Diagnosemodule: Die Konfiguration der Module muss zur ODX-Spezifikation des Steuergerätes passen. Daher muss auch die ODX-Datei in die Base EcuC einfließen.

Manchmal hat der Tier 1 eine Standardkonfiguration für seine Projekte, die direkt im EcuC-Format vorliegt. Auch diese Konfigurationsanteile sollten im Base EcuC enthalten sein. Die vom Werkzeug zum Überprüfen der Konfiguration benötigten BSWMD-Dateien können aus verschiedenen Quellen stammen: Sie werden entweder vom TIER2-BSW zur Verfügung gestellt oder zum Beispiel vom Mikrocontroller-Hersteller passend zu den MCAL-Modulen geliefert.

Die SWCs schließlich können im System Extract enthalten sein, den der Automobilhersteller seinen Zulieferern zur Verfügung stellt. Gemäß der AUTOSAR-4-Methode wird aus dem System Extract zunächst ein ECU Extract erzeugt, der eine flache Sicht auf die SWCs darstellt. Anschließend wird der ECU Extract um weitere SWCs erweitert, die zum Beispiel externe Zulieferer (TIER2-SWC) bereitstellen. Auf Basis des ECU Extract und der Base EcuC erstellt der Steuergeräteentwickler die Gesamtkonfiguration der BSW und der Laufzeitumgebung (Runtime Environment, RTE). Das Werkzeug sollte hierbei diejenigen Parameter, die aus dem Base EcuC übernommen worden sind, als schreibgeschützt darstellen, um Abweichungen vom System Extract zu vermeiden.

Projekt-Update

Während der Projektlaufzeit erhält der Entwickler immer wieder Updates der Eingangsdaten. Typischerweise kommen diese Updates zu verschiedenen Zeitpunkten und unterschiedlich oft. Der OEM verteilt neue Systembeschreibungen passend zu den jeweiligen Meilensteinen der Fahrzeugentwicklung, während die Diagnosebeschreibung in der Regel wesentlich häufiger aktualisiert wird. Oft liegt nur eine kurze Zeitspanne zwischen dem Erhalt der Systembeschreibung und dem Abgabetermin. Ein Werkzeug muss daher in der Lage sein, die Konfiguration möglichst automatisch mit den neuen Eingangsdaten zu aktualisieren. Durch ein Projekt-Update wird dabei ein neues Base EcuC erzeugt und die eigentliche Konfiguration damit abgeglichen.

Aber was passiert bei Fehlern in der Systembeschreibung? Selbst nach Klärung der Probleme mit dem OEM ist eine korrigierte Systembeschreibung meistens nicht sofort verfügbar. In solchen Fällen möchte der Steuergeräteentwickler manche der abgeleiteten Parameter bewusst ignorieren und mit einem anderen Wert überschreiben. So kann er den Fehler direkt in der ECU-Konfiguration beheben. Weil eine solche Abweichung immer kritisch ist, sollte der Steuergeräteentwickler über sein Werkzeug den Zustand explizit auf „user-defined“ setzen können. Solange der Parameter in diesem Zustand ist, darf das Werkzeug dessen Wert auch bei einem erneuten Update nicht überschreiben. Erst wenn der Steuergeräteentwickler den Status „user-defined“ zurücknimmt, fällt der Parameter auf den abgeleiteten Wert zurück. Auch bei der Abstimmung zwischen dem Steuergeräteentwickler und dem OEM hilft das Werkzeug, zum Beispiel indem es einen Report über die überschriebenen Parameter erzeugt.

Merge-Funktion für paralleles Arbeiten mit mehreren Entwicklern

Selbst in kleineren Steuergeräte-Projekten arbeiten immer mehrere Entwickler gleichzeitig am Projekt. Wenn die Zuständigkeiten klar getrennt sind – beispielsweise „Kollege xy ist immer für das Betriebssystem verantwortlich“ –, lassen sich parallele Änderungen am gleichen Modul oder an der gleichen Software-Komponente vermeiden.

Typisch ist allerdings eher eine Arbeitsweise, bei der die Entwickler parallel jeweils eine Steuergeräte-Funktion entwickeln, die sich vertikal durch alle Architekturschichten der Steuergeräte-Software durchzieht (Bild 4).

Zu Zeiten der manuellen C-Codierung hat der Integrator die unterschiedlichen Stände anschließend textuell zusammengefügt. Mit AUTOSAR bedeutet das allerdings, dass der Integrator XML-Dateien im AUTOSAR-Format zusammenfügen muss, die viele Megabytes groß sein können.

Mit herkömmlichen XML-Werkzeugen lässt sich eine AUTOSAR-Konfiguration praktisch nicht vergleichen oder zusammenfügen. Die Struktur der Datei und die vielen Referenzen innerhalb der Datei sind dazu viel zu kompliziert.

Hier hilft nur ein AUTOSAR-Werkzeug, das die Unterschiede in der AUTOSAR-Konfiguration übersichtlich darstellt und Merge-Optionen anbietet (Bild 5). Idealerweise kann der Anwender die Unterschiede direkt in den Komfort-Editoren betrachten, mit denen er auch die Konfiguration erstellt hat. So fühlt er sich zu Hause und muss sich nicht erst mühsam in eine andere Darstellung der Daten einarbeiten.

Trotzdem gilt die Devise: Je weniger Änderungen zusammenzufügen sind, desto besser. Massive Änderungen an der Konfiguration entstehen zum Beispiel durch ein Projekt-Update auf eine neue Kommunikations-Matrix (K-Matrix). Daher empfiehlt sich folgende Vorgehensweise: Ausgehend von einem Integrations-Meilenstein MS0 entwickeln die Feature-Entwickler jeweils auf einem eigenen Zweig (Bild 6).

Die Zweige werden nacheinander im Hauptzweig zusammengefügt – eventuell auch in mehreren Zwischenschritten (MS1 bis MS3). Erst dann führt der Integrator ein Projekt-Update auf eine neue K-Matrix durch (MS4). Danach lassen sich neue Zweige ziehen und Funktionen passend zur neuen K-Matrix entwickeln. Das Ganze kann durch ein Konfigurationsmanagement-System (CM) unterstützt werden, das auch die Implementierungsdateien der SWCs verwaltet.

Verfügbare Werkzeuge

Das Werkzeug DaVinci Configurator Pro von Vector Informatik ermöglicht die beschriebene Arbeitsweise. In der kommenden Version lassen sich mit dem DaVinci Configurator Pro zudem Konfigurationsvarianten erstellen, die dynamisch im Steuergerät umgeschaltet werden – sogenannte Post-Build-Selectable-Varianten. Auch hierbei gilt es, die verfügbaren AUTOSAR-Konzepte geschickt in Werkzeug-Funktionen umzusetzen. Damit erhält der Entwickler weitere wertvolle Unterstützung für die Entwicklung von AUTOSAR-Projekten.

Der Autor

Dipl.-Ing. (FH) Matthias Wernicke
war nach Abschluss seines Studiums der Industrieelektronik an der FH Ulm zunächst vier Jahre im Daimler-Forschungszentrum in Ulm tätig. Seit Anfang 2000 arbeitet er bei Vector Informatik in Stuttgart an der Entwicklung von Methoden und Werkzeugen für den Entwurf verteilter Elektronikfunktionen im Kfz. Er ist heute für das Produkt-Management der DaVinci-AUTOSAR-Werkzeuge verantwortlich.