Automotive Electronics Entwicklung von Automotive-Systemen unter AUTOSAR

Redakteur: Dipl.-Ing. (FH) Thomas Kuther

Um den Standard AUTOSAR im Produktentstehungsprozess von Automotive Electronics effektiv einsetzen zu können, muss es in die bestehenden Entwicklungsprozesse integriert werden. Wie das geht, erfahren Sie in diesem Artikel.

Anbieter zum Thema

Bild 2: Abhängigkeiten zwischen Varianzpunkten - eine Abbildung bringt Features mit Modell- oder Code-Elementen „unter einen Hut“ (Bild: . (Bild: Fraunhofer ISST))
Bild 2: Abhängigkeiten zwischen Varianzpunkten - eine Abbildung bringt Features mit Modell- oder Code-Elementen „unter einen Hut“ (Bild: . (Bild: Fraunhofer ISST))

Ziel von AUTOSAR ist die Modularisierung der Software im Auto. Die Anwendungssoftware wird von der Steuergeräte-Hardware und dem Netzwerk unabhängig, so dass die Funktionen einfach auf das Netzwerk verteilt und in verschiedenen Kontexten wiederverwendet werden können. Die Implementierung besteht nicht mehr im Schreiben von Code, sondern das System wird aus Beschreibung der Software, der Steuergeräte- und Netzwerkressourcen sowie der Verteilung der Software generiert.

Zwischen Standardisierung und Integration

Mit AUTOSAR werden Lösungen beschrieben. Der Standard definiert ein Austauschformat, das in erster Linie von Werkzeugen gelesen und für den Systemgenerierungsprozess verwendet wird. Damit ist klar, dass es im Entwicklungsprozess Schritte vor AUTOSAR geben muss. Außerdem sind Dokumente und Modelle kein Selbstzweck, sondern ein Mittel um sicherzustellen, dass die gewünschten Systemeigenschaften erzielt werden. Dazu werden Operationen und Werkzeuge benötigt, die aus den dokumentierten Anforderungen oder Entwurfsentscheidungen Bewertungen ableiten.

Für die weitere Entwicklung von AUTOSAR steht hier eine Grundsatzentscheidung an. Soll AUTOSAR nach und nach das Dokumentenformat für die anderen Prozessschritte standardisieren, oder soll sich AUTOSAR in die bestehende Methoden- und Werkzeuglandschaft integrieren, indem es Schnittstellen zu anderen Formaten definiert?

Das Verhalten der Funktion steht im Vordergrund

Die Entwicklung von Funktionen beginnt mit einer Vorstellung von ihrem Verhalten, AUTOSAR-Beschreibungen fokussieren hingegen fast ausschließlich auf die statische Struktur der Softwarekomponenten. Verhalten wird erst durch C-Code-Fragmente auf einer sehr tiefen Detaillierungsebene beschrieben.

Diese Fokussierung entspricht dem Aufbau von Programmiersprachen, in denen Schnittstellen statische Strukturinformationen liefern, das Verhalten aber ausschließlich in der Implementierung festgelegt ist. Zur Beschreibung von Funktionsentwürfen oder funktionalen Anforderungen ist dies ungeeignet. Anders sieht es aus bei Modellierungssprachen wie UML oder Architekturbeschreibungssprachen. Sie ermöglichen eine integrierte Beschreibung von Struktur und Verhalten, mit der die Vorstellung von der Funktion in ein formales Modell überführt werden kann (Bild 1).

Für die weitere Entwicklung von AUTOSAR kann entweder AUTOSAR für die Funktionsentwicklung tauglich gemacht werden, indem Mittel zur abstrakten Beschreibung von Verhalten integriert werden, oder AUTOSAR definiert eine Schnittstelle zu Modellierungswerkzeugen, mit denen eine integrierte Beschreibung von Struktur und Verhalten auf jedem Abstraktionsniveau möglich ist und in eine AUTOSAR-Beschreibung überführt werden kann.

Modelle sind kein Selbstzweck. Sie ermöglichen – meist auf Basis von Messungen – spezifische Bewertungsoperationen, die Informationen des Modells interpretieren und Aussagen darüber treffen, ob die gewünschten Produkt- oder Prozesseigenschaften erfüllt werden. Mit der Funktionspunktmetrik etwa können mittels abstrakter Informationen aus dem frühen Prozess der erwartete Entwicklungsaufwand und der erwartete Softwareumfang abgeschätzt werden, ohne den Entwicklungsprozess über Gebühr zu belasten. Echtzeitbewertungen wiederum benötigen zusätzliche Informationen über die Kommunikationsinfrastruktur und die Verteilung der Funktionen auf die Steuergeräte. Durch geeignete Modelle können die Informationen erfasst und für mittlerweile sehr präzise Aussagen über die Antwortzeiten des Systems genutzt werden. Die Architekturbeschreibungssprache EAST-ADL2 wiederum ist vor allem in Hinblick auf die Bewertung von Sicherheitsaspekten entworfen worden. Entsprechende Informationen werden im Modell erfasst und mit den Anforderungen verglichen. Ob auch mit AUTOSAR-Modellen alle Informationen für alle möglichen Bewertungen bereit stehen, lässt sich so allgemein nicht sagen. Für die weitere AUTOSAR-Entwicklung stellt sich aber wieder die Frage, ob AUTOSAR immer mehr erweitert werden soll, um möglichst viele Bewertungen zuzulassen, oder ob die Interaktion mit anderen Bewertungswerkzeugen vorangetrieben werden soll.

Variantenmanagement in AUTOSAR 4.0

Innerhalb eines Kfz-Entwicklungsprozesses wird die Software für alle Varianten des Fahrzeugs gleichzeitig entwickelt. Die Entwicklungsmethode muss den Umgang mit den Varianten von Anfang an unterstützen. Die Darstellung von Varianz in Softwarekomponenten ist seit Version 4.0 auch in AUTOSAR möglich. Modellelemente können mit Formeln versehen werden, die beschreiben, in welcher Systemvariante dieses Modellelement relevant ist. Die Schwierigkeit wird dabei deutlich: Die Abhängigkeiten zwischen den Varianzpunkten, die sich typischerweise an mehreren Stellen im Modell bzw. Code finden, sind nicht repräsentiert und daher schwer zu verstehen; Änderungen sind mit einem großen Risiko behaftet.

Aus der Software-Produktlinientechnik ist das Mittel bekannt, mit dem diese Abhängigkeiten abstrakt repräsentiert und verwaltet werden können: Ein Featuremodell stellt die Charakteristika der Systemvarianten abstrakt dar. Durch eine Abbildung werden Features mit Modell- oder Code-Elementen verbunden (Bild 2).

Bild 2: Abhängigkeiten zwischen Varianzpunkten - eine Abbildung bringt Features mit Modell- oder Code-Elementen „unter einen Hut“ (Bild: . (Bild: Fraunhofer ISST))
Bild 2: Abhängigkeiten zwischen Varianzpunkten - eine Abbildung bringt Features mit Modell- oder Code-Elementen „unter einen Hut“ (Bild: . (Bild: Fraunhofer ISST))

Effizienter Entwicklungsprozess zwischen zwei Extremen

Werden Features und Feature-Abbildungen in der nächsten Version zu AUTOSAR-Elementen oder werden Werkzeuge, die heute schon mit Featuremodellen und Variantenmanagement umgehen können, in eine durchgängige Methode integriert, in der AUTOSAR ein Baustein ist?

Mit AUTOSAR lassen sich Lösungsbausteine beschreiben und daraus Systeme generieren. Um von den Verbesserungen wirklich zu profitieren, ist der ermöglichte Fortschritt in den Gesamtprozess zu integrieren.

Einerseits ist die Erweiterung der AUTOSAR-Konzepte mit jeder neuen Version möglich, so dass nach und nach alle anderen Prozessschritte in AUTOSAR aufgenommen werden. Eine andere Möglichkeit ist die Integration von AUTOSAR in die bestehenden Werkzeug- und Methodenlandschaften, die einen nahtlosen Wechsel von AUTOSAR- zu Nicht-AUTOSAR-konformen Modellen und Methoden ermöglicht.

Keine dieser beiden Möglichkeiten aber ist die einzig richtige: Vielmehr sollten die diskutierten Beispiele – Funktionsentwicklung, Bewertungsoperationen und Variantenmanagement – unterschiedlich behandelt werden.

Artikelfiles und Artikellinks

(ID:23463320)