Suchen

UML für AUTOSAR Modellierungssprache für die Kfz-Software Entwicklung

Autor / Redakteur: Hans Windpassinger* / Martina Hafner

Alle Beteiligten in der Elektronik/Elektrik-Entwicklung benötigen eine effiziente Möglichkeit zur Kommunikation und Dokumentation ihrer Arbeitsergebnisse: Eine Beschreibungssprache. Vorliegender Beitrag zeigt, dass die Modellierungssprache UML hierfür geeignet ist, sowohl für die frühen Phasen des E/E Systementwurfs als auch für die späteren, von AUTOSAR bestimmten Entwicklungsschritte.

Firmen zum Thema

( Archiv: Vogel Business Media )

Die Entwicklungspartnerschaft AUTOSAR hat neben einer Standard-Plattform und -Architektur für eingebettete Kfz-Software auch wesentliche Teile einer Entwicklungsmethodik hervorgebracht. Diese AUTOSAR Methodology definiert unter anderem, wie Software-, Hardware- und System-Eigenschaften von Kfz-Elektronik beschrieben werden. Festlegungen zur Speicherung dieser Beschreibungen in XML sind Bestandteil von AUTOSAR, ebenso wie auch Vereinbarungen zur graphischen Repräsentation.

Bild 1 zeigt die wesentlichen Elemente der AUTOSAR Methodology. Drei Eingangsgrößen, die sogenannten AUTOSAR Input Descriptions, dokumentieren in ihrer Gesamtheit eine Fahrzeug-E/E Architektur. Diese drei AUTOSAR Input Descriptions sind:

Bildergalerie
  • - Software Component Descriptions,
  • - ECU Ressource Descriptions,
  • - System Constraint Description.

Wie in Bild 1 dargestellt, entsteht aus den Eingangsgrößen die System Configuration Description. Diese beinhaltet die endgültigen Festlegungen der E/E-Architektur eines Fahrzeugs. Von dieser Configuration Description werden dann die Eingangsgrößen pro Steuergerät abgeleitet und weiter bearbeitet. Wir betrachten in diesem Beitrag das Thema „Beschreibungssprachen“.

Beschreibung einer AUTOSAR-Software-Komponente

Wie sieht nun beispielsweise eine Beschreibung einer AUTOSAR-Software-Komponente aus? Eine AUTOSAR Software Component Description beinhaltet unter anderem Angaben zu Kommunikationsverbindungen und zugehörigen Schnittstellen, zum Aufbau und zur inneren Struktur, zum Zeitverhalten und zu benötigten Hardware-Resourcen. Bild 2 zeigt eine gra-phische Darstellung. AUTOSAR hat mit diesen Festlegungen und Spezifikationen etwas geschaffen, welches die Softwareindustrie eine „Domain-Specific Language“ (DSL) nennen würde. Eine DSL ist eine für einen Anwendungsbereich (eine Domaine) und für eine bestimmte Aufgabenstellung ausgelegte, spezifische Beschreibungs-, Modellierungs- und/oder Programmiersprache.

Domain-Specific Language versus UML

Eine nicht domain-spezifische sondern generische Sprache ist die UML, die Unified Modeling Language. Mit der UML können alle Aspekte eines softwareintensiven Systems ausgedrückt werden. Statische Strukturen lassen sich genauso beschreiben wie dynamisches Verhalten. Logische Sichten auf das zu entwickelnde System, als auch dessen physikalischer Aufbau können in UML modelliert werden. Objektorientierte Ansätze, Hierarchisierung, Komponentisierung und andere Konzepte zur systematischen Erstellung einer E/E Architektur lassen sich in UML anwenden.

Diese an sich generische, „universelle“ Sprache UML kann nun aber auch mittels sogenannter Profiles auf ganz spezielle Aufgabengebiete (Domains) ausgerichtet werden. In einem Profile werden neue Modellelemente definiert, die in sich wiederum andere Modellelemente beinhalten oder referenzieren können. Diese neuen Modellelemente, Stereotypes genannt, können „constraints“ besitzen, und damit die UML Sprachcharakteristiken einschränken oder ganz eliminieren, und/oder neue domänenspezifische Charakteristika einführen.

Als Beispiel kann der bayrische Sprachdialekt dienen: Das Bayrische verändert die Aussprache, die Worte, die Ausdrücke und manchmal sogar die Grammatik des Hochdeutschen. So ähnlich ändert ein UML Profile die UML. Mit diesem Profile-Mechanismus kann die UML zu einer graphischen DSL umfunktioniert werden.

Beziehung zwischen UML, DSL und SysML

Die SysML, die Systems Modeling Language, kann als eine von der UML abgeleitete DSL interpretiert werden. SysML addressiert die speziellen Anforderungen des Systems Engineerings. SysML erweitert die UML: Neue Diagrammarten erlauben unter anderem die grafische Darstellung von Anforderungen und deren Abhängigkeiten. Bild 3 skizziert die Beziehung zwischen SysML und UML.

Aus UML kann wie gezeigt eine DSL entstehen. Ein DSL UML Profile verbindet dann die domain-spezifische Welt mit der universellen UML-Welt. Dieses Prinzip wurde auch von AUTOSAR angewandt: Es wurde ein „AUTOSAR UML Profile“ innerhalb der AUTOSAR-Entwicklungspartnerschaft erstellt, welches heute zu den offiziellen Dokumenten des AUTOSAR-Standards zählt. In diesem Profil werden einzelne AUTOSAR-Modellelemente auf die Sprachelemente von UML abgebildet. Diese Abbildung nutzt die bereits genannten Stereotypen und die genannten Constraints. Das AUTOSAR UML Profile ermöglicht es damit, die AUTOSAR Input Descriptions auf Basis der Sprache UML zu beschreiben.

Auf Basis von UML steht nun für die frühen Phasen der E/E Entwicklung SysML zur Verfügung. Für die späteren Phasen im E/E Entwicklungsprozess dient das AUTOSAR UML Profile.

Entwurf der E/E-Architektur mit SysML

In SysML kann der Entwurf einer E/E Architektur vorgenommen werden. Die logische und physikalische Struktur des Boardnetzes wird in verschiedenen Detaillierungsgraden beschrieben. Struktur und Verhalten werden spezifiziert. Mit der gezeigten UML-Erweiterbarkeit lassen sich viele relevante Informationen zu E/E-Architekturentwürfen hinzufügen: Angaben zu Hardwarekosten, Verfügbarkeit, Speichergrößen, Rechnerkapazitäten, Entwicklungsaufwände, Datendurchsatz und vieles mehr sind möglich, um damit Architekturbewertungen vornehmen zu können. Diese Erweiterungen können auch als firmen- oder projektspezifische DSL verstanden werden.

Wenn der Punkt einer endgültigen Architektur erreicht und damit die Software- und Hardwarekomponenten bestimmt sind, lässt sich das AUTOSAR UML Profile auf das Modell anwenden. Das heisst, dass die AUTOSAR Input Descriptions erzeugt werden. Aufgrund der gemeinsamen Wurzel UML sind automatische Transformationen und Verifikationen von SysML zu UML zu AUTOSAR und zurück möglich.

Damit ist ein Weg von SysML bis zu den AUTOSAR Input Descriptions beschrieben.

UML-Werkzeuge für DSL und AUTOSAR

Bei vielen Experten in der Automobilbranche entstand früh die Einschätzung, dass Software- und Systeme Entwicklungswerkzeuge notwendig sind, um die AUTOSAR Methodology erfolgreich umzusetzen. Mit dem aufgezeigten Ansatz, UML sowohl als Sprachbasis für Systementwurf als auch für AUTOSAR und darüber hinaus für firmenspezifische Spracherweiterungen zu verwenden, liegt es nahe, in der praktischen Umsetzung auch ein UML-Werkzeug für alle diese UML Ausprägungen in den verschiedenen Entwicklungsphasen zu verwenden.

Ein entsprechendes UML-Werkzeug für DSLs, und damit für AUTOSAR erweiterbar, ist der Rational Systems Developer (RSD) von IBM. Er gehört zur neuesten Generation der IBM UML Werkzeuge. Diese basieren vollständig auf Eclipse. Zahlreiche Funktionen in RSD wie zum Beispiel für das Management von Modellen, Modell-Transformationen oder Codegenerierung, helfen Teams C, C++ und Java Anwendungen für eingebettete Systeme zu entwickeln.“

IBM Rational arbeitet mit Unternehmen der Automobilbranche an RSD add-ons, um die domain-specific language AUTOSAR mit Hilfe des AUTOSAR UML Profile zu realisieren. Die Kombination von SysML, UML und AUTOSAR in einem Werkzeug ist ideal, weil damit beide Welten nahtlos ineinander fließen: Systementwurf, Architektur, Bewertung und Dokumentation auf der einen Seite, und andererseits die AUTOSAR Input Descriptions.

UML und Werkzeuge allgemein

UML entstand in der zweiten Hälfte der 90er-Jahre: Unter der Führung der „Drei Amigos“, James Rumbaugh, Grady Booch und Ivar Jacobson, drei Mitarbeiter der Firma Rational Software, entwickelte sich eine „vereinheitlichte“, nicht proprietäre Beschreibungssprache. Diese wurde in dem internationalen Konsortium der UML Partners 1996 vervollständigt, und zur Standardisierung der OMG (Object Management Group) übergeben. Die aktuelle Version seit Anfang 2007 ist Version 2.1.1. Die OMG verfügt über eine Reihe von Standard UML Profiles, beispielsweise das UML Profile for Schedulability, Performance and Time, das UML Profile for System on a Chip (SOC) oder das UML Testing Profile. Das AUTOSAR UML Profile ist Eigentum der AUTOSAR-Entwicklungspartnerschaft. Eine Liste von UML-Werkzeugen ist in dem OMG UML Directory http://uml-directory.omg.org/. Bekannte Toolanbieter für UML sind Telelogic, Artisan Software Tools, Sparx Systems und IBM.

*Hans Windpassinger ist im Bereich Embedded Systems Lifecycle Management der IBM in München tätig. Kontakt: hans.windpassinger@de.ibm.com

(ID:224572)