Plug-and-Play-Lösung für Autosar-Software-Komponenten

Transkript

1 Plug-and-Play-Lösung für Autosar-Software-Komponenten Durch die im Autosar-Standard spezifizierten Schnittstellen kann die Steuergeräteapplikation leichter als bisher aus Komponenten unterschiedlicher Zulieferer zusammengefügt werden. Die Software-Entwicklung wird jedoch dadurch verzögert, dass die einzelnen Komponenten in einem zusätzlichen Schritt zur vollständigen Software zusammengefügt werden müssen. Durch nachladbare Software-Komponenten reduziert sich die Anzahl dieser Gesamtintegrationen, weil man ohne Linken des gesamten Projekts einzelne Software-Komponenten im Flash-Speicher austauschen kann. Vector beschreibt, wie sich dadurch die Software-Entwicklung bei jedem einzelnen Zulieferer beschleunigt. 28

2 autor Alexander Zeeb, M.Sc. ist Software-Entwicklungsingenieur im Bereich Konzeptentwicklung für Embedded Software bei der Vector Informatik GmbH in Stuttgart. Steuergeräte-Software Die Autosar-Steuergeräte-Software ist in drei Bereiche unterteilt: Basis-Software, Runtime Environment und Applikation, ❶. Die Basis-Software (BSW) ist das Grundgerüst, das der Applikation mittels Treibern und Abstraktionsschichten die Ressourcen des Mikrocontrollers zur Verfügung stellt. Das Runtime Environment (RTE) dient als Verbindungsschicht zwischen der Applikation und der Basis-Software. Die RTE abstrahiert die Kommunikation zwischen Applikationsteilen und ermöglicht so transparenten Datenaustausch auch über Steuergerätegrenzen hinaus. Zu diesem Zweck stellt die RTE-Schnittstellen für die Applikation und die Basis-Software bereit. Im Gegensatz zur BSW, deren statische Module unverändert in unterschiedlichen Steuergeräten eingesetzt werden können, ist die RTE für jedes Steuergerät individuell generiert und bietet nur die tatsächlich benötigten Schnittstellen an. Die Applikation besteht aus Software-Komponenten (SWC), welche die Steuergerätefunktion in Form von sogenannten Runn ables umsetzt. Verteilte Software-Entwicklung Die modulare Autosar-Architektur vereinfacht Software-Zulieferern das Spezialisieren auf bestimmte Applikationen und Komponenten, wie Basis-Software, Fahrdynamik-Regelung, Motormanagement etc. Es ist dadurch nicht ungewöhnlich, dass die Software eines Steuergeräts aus den Modulen und Komponenten mehrerer unterschiedlicher Zulieferer besteht. Die einzelnen Teile werden entweder als Quellcode oder bereits kompiliert als Binärdateien geliefert und im Rahmen einer Gesamtintegration beim verantwortlichen Steuergerätehersteller zur kompletten, lauffähigen Steuergeräte-Software zusammengefügt. Dieses Speicherabbild der Steuergeräte-Software erhalten wiederum alle SWC- Zulieferer für die weiteren Entwicklungsschritte. Dieses Vorgehen ist jedoch sehr aufwendig und bremst die Software-Entwicklung. Einerseits muss der Steuergerätehersteller für jede neue Version einer SWC eine aufwendige Gesamtintegration durchführen. Andererseits muss der SWC-Zulieferer auf das Ergebnis der Integration warten, um damit seine Applikation im Zusammenspiel mit der weiteren Steuergeräte-Software zu testen. Gerade in frühen Entwicklungsphasen führen die häufigen Wartezeiten zu einem erheblichen Mehraufwand. 01I Jahrgang Software-Anpassungen nach dem Linken Für die Basis-Software ist in Autosar das Postbuild-Verfahren definiert, damit das Verhalten einiger BSW-Module nach dem Übersetzen und dem Linken angepasst werden kann. Dazu werden für diese Module die Konfigurationsdaten getrennt vom statischen Code im Flash-Speicher abgelegt. So können diese während der Laufzeit ersetzt werden, ohne die Steuergeräte-Software erneut übersetzen und linken zu müssen. Für die SWCs der Applikations-Software definiert der Autosar- Standard kein mit Postbuild vergleichbares Verfahren. Jede Modifikation auch nur einer SWC hat das Übersetzen und das Linken der kompletten Steuergeräte-Software zur Folge. Es gibt aber eine Möglichkeit, die Anzahl der Gesamtintegrationen zu reduzieren. Im Folgenden wird vorgestellt, wie der SWC-Zulieferer einzelne 29

3 SWCs der Applikations-Software direkt im Flash-Speicher austauschen kann und damit den Integrationsaufwand reduziert. Wie ist der Ablauf beim nachladen von SWC? Bei dem Nachladen einer SWC wird die bestehende SWC durch eine aktualisierte Version direkt im Steuergerätespeicher ersetzt, ohne die übrige Steuergeräte-Software durch diesen Vorgang zu beeinträchtigen. Dies erfolgt entweder online auf dem Steuergerät mittels eines Flash-Bootloaders oder offline durch einen entsprechenden HEX-Editor mit anschließender Übertragung ins Steuergerät, ❷. Das Nachladen erfolgt normalerweise durch den SWC-Zulieferer, kann aber auch vom Gesamtintegrator durchgeführt werden. Durch das Einsparen der Gesamtintegration ergeben sich für den Zulieferer kürzere Entwicklungszyklen: Kodieren Nachladen Testen Optimieren, ❸. Der Gesamtintegrator erzeugt initial ein Speicherabbild der kompletten Steuergeräte- Software und stellt es den SWC-Zulieferern zur Verfügung. Die Zulieferer erstellen anschließend lediglich eine neue Version ihrer SWC, laden diese in das Speicherabbild und können direkt mit dem Test ihrer SWC beginnen. Um ein zu starkes Auseinanderdriften der SWC-Versionen zu vermeiden, erzeugt der Gesamtintegrator in regelmäßigen Abständen neue Speicherabbilder mit den jeweils aktuellen Versi o- nen aller SWCs. Einschränkungen, welche SWCs nachgeladen werden können, gibt es nicht. Die Entscheidung darüber muss aber bereits während der Planungsphase des Steuergeräts getroffen werden, da Besonderheiten bei der Implementierung und Speicheraufteilung beachtet werden müssen. ❶ Autosar-Schichtenmodell dies zu gewährleisten, wird der Steuergerätespeicher in mehrere Partitionen unterteilt, die exklusiv den einzelnen SWCs zur Verfügung stehen. Zum Festlegen der Partitionsgrößen wird abgeschätzt wie viel Speicher die einzelnen Runnables der SWC voraussichtlich benötigen. Im ersten Moment vergrößert sich damit der Speicherbedarf ❷ Die nachladbare SWC wird im Speicherabbild freigestellt (oben) und in den Flash-Speicher des Steuergeräts übertragen Speicherreservierung für nachladbare SWCs Bei der heutigen Software-Entwicklung wird in der Gesamtintegration der SWC- Programmcode typischerweise ohne konkrete Vorgaben gelinkt. Bei nachladbaren SWCs muss bereits der SWC-Zulieferer das Linken anhand konkreter Vorgaben durchführen. Sowohl die RTE als auch die SWC erwarten die Schnittstellen des jeweils Anderen an den beim Linken hinterlegten Adressen im Steuergerätespeicher. Um ❸ Durch das Nachladen von SWCs beschleunigt der SWC-Zulieferer seine Software-Entwicklung 30

4 für die Applikation. Dieses gilt aber nur für die Entwicklungszeit. Um den Speicherbedarf zu reduzieren, kann die Partitionierung in der finalen Software für den Serieneinsatz entfallen. Da in der Regel nur komplette Flash- Pages gelöscht werden können, werden im einfachsten Fall für jede SWC eine oder mehrere komplette Flash-Pages reserviert. Falls die SWC jedoch deutlich kleiner als eine Flash-Page ist und die dadurch entstehende Fragmentierung nicht akzeptabel ist, können auch mehrere SWC einer Flash-Page zugeordnet werden. In diesem Fall muss jedoch sicher gestellt sein, dass beim Nachladen der SWC mittels Flash Bootloader oder HEX-Editor der übrige Inhalt der Flash-Page nicht verändert wird. Software-Umgebung zum kompilieren und Linken einer SWC Zum Kompilieren und zum Linken ihrer SWC benötigen die Zulieferer eine Software-Umgebung, die alle Abhängigkeiten der SWC zu den aufgerufenen Schnittstellen auflöst. Bei dieser Umgebung handelt es sich im Idealfall um die komplette lauffähige Steuergeräte-Software inklusive BSW und Applikation, die auch bei der Gesamtintegration verwendet wird. Vom prinzipiellen Vorgehen entspricht diese Variante einer Gesamtintegration, die aber beim SWC-Zulieferer stattfindet. Das Aufsetzen einer solchen Software- Umgebung ist meist mit großem Aufwand verbunden und nicht immer möglich. Daher kann der SWC-Zulieferer alternativ auch eine minimale Umgebung selber erstellen. Diese muss lediglich die von der SWC aufgerufenen Schnittstellen bedienen, ❹. Mit beiden Varianten erhält der SWC- Zulieferer nach dem Kompilieren und dem Linken eine Binärdatei, die neben der SWC den Code der Software-Umgebung enthält. Für das spätere Nachladen einer SWC ist dieser zusätzliche Code irrelevant und wird entfernt. Das Ergebnis ist eine Binärdatei der zu testenden SWC, in der die Sprungziele bereits an den korrekten Speicheradressen abgelegt sind. Wie funktioniert das nachladen von SWCs? ❹ Statt der kompletten Software-Umgebung wird bei nachladbaren SWCs eine minimale Software-Umgebung zum Linken verwendet Nach dem Update einer SWC im Flash- Speicher müssen die in der SWC enthaltenen Runnables weiterhin von der RTE oder anderen Runnables aufgerufen werden können. Bei einer Gesamtintegration ersetzt der Linker die beim Kompilieren in der RTE hinterlegten symbolischen Sprungziele durch die korrekten (realen) Adressen der Runnables innerhalb der nachladbaren SWC. Diese Adressen bleiben beim Nachladen der SWC innerhalb der RTE unverändert. Daher muss garantiert sein, dass die Runnables einer nachladbaren SWC bei jedem Übersetzen und Linken immer an diesen Adressen im Speicher abgelegt werden. Diese Bedingung kann unter anderem durch entsprechende Compiler- und Linker-An wei sungen erfüllt werden, die den einzelnen Runn ables feste manuell zu vergebende Adressen zuweisen. Es ist jedoch sehr wahrscheinlich, dass der Speicherbedarf der Runnables im Laufe der Steuergeräteentwicklung anwächst. Aus diesem Grund wird ein Reservebereich innerhalb der SWC reserviert. Um diese Reserve einzurichten unterteilt der SWC-Zulieferer die SWC mittels Compileranweisungen in einen statischen und einen veränderlichen Bereich. Der statische Bereich beinhaltet den Einsprungbereich in die SWC. Dieser bleibt immer gleich, auch wenn sich die Implementierung der Funktion ändert. Um dies zu erreichen werden die Runnables der SWC modifiziert. Sie enthalten nun nicht mehr den spezifischen Applikations-Code, sondern lediglich einen Funktionsaufruf. Die dabei aufgerufenen sogenannten Runnable-Funktionen befinden sich im veränderlichen Bereich der SWC und beinhalten den eigentlichen, funktionalen Code der Runnables, ❺. Dieser Code darf sich dadurch beliebig ändern, ohne eine Adressverschiebung der Runnables im statischen Bereich zur Folge zu haben. Bei jedem Übersetzen und Linken einer SWC werden die symbolischen Sprungziele der Runnables durch die aktuellen Adressen beziehungsweise Offsets ersetzt. Die tatsächlichen Adressen der Runnable-Funktionen müssen also für die RTE nicht bekannt sein. Aufruf von Port-Interfaces aus einer SWC Analog zum Aufruf der Runnables durch die RTE müssen in der anderen Richtung die Runnable-Funktionen die von der RTE bereitgestellten Port-Interfaces aufrufen können. Wenn der SWC-Zulieferer eine vollständige Software-Umgebung aus der ❺ Durch die Aufteilung der SWC in einen statischen und einen veränderlichen Bereich liegen die Runnables an festen Adressen und können ohne neues Linken von der RTE aufgerufen werden 01I Jahrgang 31

5 Bibliotheken sowie das Scheduling der einzelnen Runnables. Die Toolchain der einzelnen Zulieferer muss abgestimmt werden, um Inkompatibilitäten aufgrund von unterschiedlichen Compiler-Versionen und -Optionen zu verhindern. Ausblick ❻ Den Runnables wird beim Aufruf ein Instance Handle übergeben; damit haben die Runnable-Funktionen Zugriff auf die Port Interfaces der RTE Gesamtintegration mit BSW und RTE einsetzt (vgl. Kapitel Software-Umgebung zum Kompilieren und Linken einer SWC ), sind keine weiteren Maßnahmen erforderlich, weil alle Sprungziele zum Link-Zeitpunkt bekannt sind. Wird jedoch eine minimale Software- Umgebung eingesetzt, befinden sich die Port-Interfaces der RTE beim Erstellen der SWC an anderen Adressen als bei der Gesamtintegration. Als Folge davon werden beim Linken der SWC falsche Adressen hinterlegt. Damit der Aufruf von Port-Interfaces aus SWCs korrekt funktioniert, werden bei nachladbaren SWCs zwei Autosar-Features genutzt: Object Code und Multiple Instantiation. Bei dieser Kombination übergibt die RTE jedem Runnable zur Laufzeit das sogenannte Instance Handle als Übergabeparameter. Dieses Handle zeigt auf eine Indirektionsstruktur der RTE, die sogenannte Component Data Structure, ❻. In dieser Struktur sind die Adressen aller Port Interfaces der SWC hinterlegt. Die SWC muss also die Adressen der RTE Port Interfaces nicht kennen. Die Component Data Structure ist in der Contract Phase Header Datei jeder SWC beschrieben. Randbedingungen für das Nachladen einer SWC Damit SWCs wie hier beschrieben ausgetauscht werden können, müssen einige Randbedingungen eingehalten werden: Durch den Austausch einer SWC können keine Port Interfaces hinzugefügt oder entfernt werden. Allerdings können bei der RTE-Generierung für zu - künftige Erweiterungen schon zusätzliche Port-Interfaces zugewiesen werden, die erst später verwendet werden. Die Anzahl der Runnables dürfen sich innerhalb einer SWC nicht ändern, da die RTE alle Runnables aufrufen kann die zum Zeitpunkt der RTE-Generierung bekannt sind. Entfallen Runnables während der Entwicklung oder kommen neue hinzu, muss auch die RTE entsprechend angepasst und eine Gesamtintegration durchgeführt werden. Bereits während der Planungsphase muss festgelegt werden, welche Anforderungen die einzelnen SWCs an das Steuergerät stellen. Dies betrifft einerseits Hardware-Ressourcen aber auch zusätzlich benötigte mathematische Das hier vorgestellte Anwendungsbeispiel mit mehreren SWC-Zulieferern und einem Gesamtintegrator ist nicht der einzig denkbare Anwendungsfall. Nachladbare SWCs können auch das Bypassing von SWCs vereinfachen, indem die für das Bypassing nötige Instrumentierung komfortabel durch eine nachladbare SWC auf das Steuergerät gebracht werden kann. Soll die SWC dann tatsächlich auf dem Steuergerät getestet werden, kann die Instrumentierung wieder durch die nicht-instrumentierte SWC ersetzt werden. Nachladbare SWCs stellen somit ein mächtiges Werkzeug dar, dass die Entwicklung von Steuergeräte-Software un - terstützen und beschleunigen kann. Bisher muss die Vorbereitung einer SWC und das Speicher-Mapping noch manuell durchgeführt werden. Es ist aber geplant diese Verfahren weitgehend durch Konfiguration zu automatisieren. Download des beitrags read the english e-magazine order your test issue now: SAM-service@springer.com 32