Build-Systeme für AUTOSAR: Build Action Manifests

Modellgetriebene Entwicklung stellt auch neue Anforderungen an Build-Systeme. Dateiorientierte Lösungen wie make sind nicht flexibel genug. AUTOSAR definiert hierzu die Build Action Manifests.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 2 Min.
Von
  • Andreas Graf
  • Andreas Graf

Die Entwicklung von Steuergerätesoftware erfolgt nicht zuletzt durch die Einführung von AUTOSAR zunehmend modellgetrieben. Das bedingt Änderungen beim Bau der Software: Zu den üblichen Artefakten wie C-, Header- und Objektdateien kommen nun die Modell-Files (.arxml) hinzu. Dabei stoßen Werkzeuge wie make, die dateiorientiert arbeiten, an ihre Grenzen.

Die AUTOSAR-Basis-Software besteht aus vielen verschiedenen Funktionsmodulen, die über die .arxml-Dateien konfiguriert werden. Dabei können die Konfigurationen verschiedener Module in ein und derselben .arxml liegen. Ändern die Entwickler nun die Konfiguration eines einzigen Moduls (wie NVRAM), kann das Build-System anhand des Zeitstempels der Datei nicht entscheiden, welche Teile des Modells geändert wurden, und muss die gesamte Software neu generieren

Zudem modifizieren einige Generatoren-Schritte Teile des Modells automatisch, indem sie zum Beispiel eindeutige IDs für Busnachrichten modifizieren. Um effizient zu arbeiten, muss das Build-System daher mit Artefakten umgehen können, die nicht zwischen den Schritten zu laden und zu speichern sind.

Außerdem soll AUTOSAR die Kombination verschiedener Teil-Stacks der BSW unterschiedlicher Hersteller erlauben. Um die Integration zu vereinfachen, muss auch die Beschreibung der notwendigen Generierungsschritte standardisiert sein. Dies erfolgt bei AUTOSAR über die "Build Action Manifests", die im "Generic Structure Template" beschrieben sind.

Jedes Manifest beschreibt ein oder mehrere Aktionen (BuildAction), für die jeweils wieder angegeben wird, welche Elemente sie lesen, modifizieren und erzeugen. Diese können sein:

  • Eine Referenz auf eine (Teil-) Konfiguration der Basis-Software
  • Eine beliebige Modell-Referenz. Hier ist auch vorgesehen, auf Nicht-AUTOSAR-Modelle zu verweisen. So wäre etwa eine Referenz auf UML- oder EAST-ADL-Modelle möglich.
  • Ein Verweis auf sogenannte Engineering-Objekte. Dies können zum Beispiel Dateidefinitionen sein. Somit ist möglich zu spezifizieren, welche Source-Files eine Build-Aktion erzeugt.

Über die beschriebenen Ein- und Ausgaben können die Abhängigkeiten analysiert und die Schritte in eine Reihenfolge gebracht werden. Beispiele hierzu finden sich in der AUTOSAR-Spezifikation. Eine erste Implementierung liefert die COMASSO-Initiative in dem BSW-Konfigurationstool, das mit COMASSO ausgeliefert wird. Hier ist es möglich, die Manifeste in Eclipse-basierten Editoren zu bearbeiten. Das Build-System analysiert die Manifest-Dateien eines Projekts und bringt sie aufgrund der definierten Abhängigkeiten in die richtige Reihenfolge. Auf Benutzerwunsch können alle oder einzelne Build-Schritte ausgeführt werden. Dies wird auch von der Kommandozeile durch eine Headless-Version unterstützt. ()