AUTOSAR: Das Standard-Modell

Das Standardisierungsgremium AUTOSAR hat es sich zur Aufgabe gemacht, die Standards für eine Reihe von Basisanwendungen und Architekturen im Fahrzeug zu entwickeln. Mit UML und SysML lassen sich standardkonforme Systeme und Komponenten modellbasiert entwickeln.

Das Standardisierungsgremium AUTOSAR hat es sich zur Aufgabe gemacht, die Standards für eine Reihe von Basisanwendungen und Architekturen im Fahrzeug zu entwickeln. Mit UML und SysML lassen sich standardkonforme Systeme und Komponenten modellbasiert entwickeln.

AUTOSAR versteht ein System als eine Menge von Softwarekomponenten (SW-Cs), die miteinander über einen »Virtual Functional Bus« (VFB) kommunizieren und interagieren. Abgebildet werden die SW-Cs auf spezifische Steuergeräte (ECUs, Electronic Control Units), welche über das Netzwerk verteilt sind. Dank einer in Schichten angelegten Architektur lassen sich die SW-Cs auf andere Plattformen übertragen, ohne dadurch die funktionale Integration zu beeinträchtigen. Der Vorteil: AUTOSAR-konforme Komponenten, die sich bewährt haben, lassen sich ohne langwierige und fehleranfällige Anpassungen auf eine andere Zielumgebung portieren.

Der VFB stellt eine Art Kommunikationsprotokoll für den Austausch von Informationen zwischen den SW-Cs dar, die RTE (Run Time Environment) ist die Laufzeitumgebung, in der dieses Kommunikationsprotokoll implementiert ist. Bild 1 zeigt eine schematische Darstellung der wichtigsten AUTOSARElemente.

Beschreibung mit UML/SysML

Der Prozess ist so angelegt, dass er den gesamten Weg der Softwarespezifikation abdeckt, von der höchsten Abstraktionsebene bis hinunter zu den Details, beispielsweise wie einzelne Codefragmente einer Softwarekomponente innerhalb einer ECU ablaufen sollen.

Eine Softwarekomponente kann ein ganzes System, ein Subsystem oder ein einzelnes, nicht weiter zerlegbares Funktionsmodul repräsentieren. Auf dieser »atomaren« Ebene muss die SW-C auf einem einzelnen Steuergerät implementiert werden. Der AUTOSAR-VFB ist so angelegt, dass die Kommunikation von der ausführenden Technik abstrahiert ist, sodass es keine Rolle spielt, ob zwei miteinander kommunizierende SW-Cs auf verschiedenen über den Bus verbundenen ECUs oder auf derselben ECU implementiert sind. Grafische Modelle stellen ein mächtiges Werkzeug für die Beschreibung komplexer Systeme dar, weil sie den »intelligenten« Entwurf von der Implementierung abstrahieren und gleichzeitig das Risiko von Missverständnissen bei der Kommunikation reduzieren. Die Auswahl einer geeigneten Notation sollte berücksichtigen, dass ein Standard grundsätzlich den Austausch und die Wiederverwendung vereinfacht, aber auch, dass es möglich sein sollte, den Standard domänenspezifisch anzupassen.

Mit Hilfe des Internal-Behavior-Diagramms wird nun der Ablauf der einzelnen ausführbaren Elemente innerhalb einer jeden Softwarekomponente spezifiziert. Ein ausführbares Element ist ein Codefragment, ein Algorithmus eine Funktion oder eine Kombination aus diesen Elementen, die sich unabhängig von anderen Elementen ausführen lässt. Ein Triggerereignis startet ein solches Element, beispielsweise ein ablaufender Timer oder ein Schwellwert, der überschritten wird. Diese Rahmenbedingungen und Ausführungsregeln werden im Internal-Behavior-Diagramm definiert, jedoch ohne die interne Implementierung der einzelnen ausführbaren Elemente festzulegen. Bild 3 zeigt dieses Diagramm für eine der »WindowController «-SW-Cs. Unter dem Namen »WindowCtrl_IB« werden die ausführbaren Elemente beschrieben. In diesem Fall gibt es ein ausführbares Element mit dem Namen »R1«. Nun lassen sich die Ereignisse definieren, welche die Ausführung von R1 auslösen, und die Daten, welche über den VFB bzw. die Laufzeitumgebung übermittelt werden.

Auch die Beschreibung der elektrischen Architektur des umgebenden Fahrzeugs findet im AUTOSAR-Prozess statt. Dazu kommt eine Kombination von ECU-Diagramm und Topology- Diagramm zum Einsatz. Diese basieren auf den Klassen- und Objektdiagrammen in UML/SysML, und mit ihnen lassen sich die Steuergeräte, ihre Ports sowie die CAN-, LIN-, FlexRay- oder MOST-Bussysteme beschreiben, über welche die Steuergeräte miteinander verbunden sind. Der letzte Schritt bei der Erstellung eines Systemmodells ist die Definition der Abbildung der Softwarekomponenten auf die Steuergeräte im Topology- Diagramm. Im Systemdiagramm wird für jede SW-C, die im Software-Component-Diagramm beschrieben wurde, festgelegt, auf welchem Steuergerät im umgebenden Fahrzeug (wie im ECU-Diagramm definiert) sie zu implementieren ist. Nachdem diese Zuordnung beschrieben ist, lässt sich die Kommunikationsmatrix herleiten.

In unserem Beispiel wird der Main- Controller der MainECU zugeordnet, und die Softwarekomponenten für die einzelnen Fensterheber den Steuergeräten in den jeweiligen Türen (siehe Bild 4). (mc)