Das große Ganze im Blick AUTOSAR-Systemsicht konsequent umsetzen

Autosar blickt  im Ganzen  auf die Systemsicht und spielt eine wichtige Rolle in der Digitalisierung.
Autosar blickt im Ganzen auf die Systemsicht und spielt eine wichtige Rolle in der Digitalisierung.

Vor 13 Jahren entstanden, ermöglicht AUTOSAR eine effiziente E/E-Entwicklung. Neben der kontinuierlichen Erweiterung in den letzten Jahren ist das Systemdenken eine tragende Säule des Standards geblieben: Er fokussiert nicht das einzelne Steuergerät, sondern blickt auf das Ganze.

AUTOSAR beschreibt die Elektrik-/Elektronik-Architektur von kompletten Fahrzeugen mit allen Konfigurationsdetails: Software, Topologie, Buskommunikation und steuergerätespezifische Parameter. Dazu wird in der Methodik durchgängig mit Prozessbausteinen gearbeitet, die sich wesentlich in Aktivitäten (Activities) und Arbeitsprodukte (Work Products) gliedern (Bild 1). Durch das Verbinden dieser Prozessbausteine weist die Methodik den Weg vom Erstellen der Systemkonfiguration bis zum Erzeugen einer ausführbaren Datei für ein bestimmtes Steuergerät. Die systemweite Sicht ist im AUTOSAR-Standard fest verankert und prägt die Methodik durchgehend.

Von der Abstraktion zur Software-Komponente

Am Beginn der Methodik steht die Design-Aktivität „Develop an Abstract System Description“. Hier wird die funktionale Architektur eines Fahrzeugs ausführlich beschrieben, ohne auf die technischen Details und die Implementierung einzugehen. Das Ergebnis ist ein abstraktes System, das als Netzwerk von logischen Funktionen sowie deren Schnittstellen und Verbindungen die formale Idee des gesamten Fahrzeugsystems widerspiegelt. Die Vorteile für die weitere Entwicklung liegen auf der Hand: Mit einer abstrakten Beschreibung sind Systemabhängigkeiten und Optimierungsmöglichkeiten wesentlich leichter zu analysieren.

Durch das Verlinken der logischen Funktionen und aller Systembestandteile bleibt das Design stets nachvollziehbar; Logikfehler oder Redundanzen in Funktionen werden früh erkannt und vermieden. Das Erstellen der „Abstract System Description“ ist allerdings nur optional in der AUTOSAR-Methodik vorgesehen und lässt sich bisher auch nur mit wenigen Entwicklungswerkzeugen wirklich durchgängig umsetzen. Der Mehraufwand für diesen Prozessschritt wird jedoch durch einen enormen Effizienzgewinn belohnt: Architekten und Designer erhalten eine ideale Arbeitsgrundlage für die spätere Verteilung und Implementierung von Funktionen auf konkrete Steuergeräte (Bild 2).

Ob mit oder ohne vorherige Abstraktion – das formale, funktionale Design wird in der AUTOSAR-Software-System-Architektur mit dem Konzept des „Virtual Functional Bus“ (VFB) technisch umgesetzt. Die Aktivität „Develop a VFB System Description“ präzisiert darin die Software-Funktionen im Fahrzeug. Das Ergebnis ist das Arbeitsprodukt „Overall VFB System“, ein durch Ports verbundenes System von Software-Komponenten, die über definierte Schnittstellen miteinander kommunizieren. Ob der Informationsaustausch später über einen physischen Bus oder innerhalb eines Steuergeräts stattfindet, spielt hier keine Rolle: Der VFB abstrahiert diese Kommunikation. Die einzelnen Software-Komponenten innerhalb des VFB-Systems werden als „Delivered Atomic Software Component“ (häufig auch: Software Component Description) beschrieben (Bild 3).

Wird in dieser Phase der Entwicklung das Gesamtsystem nicht konsequent im Blick behalten, gibt es später bei der Integration häufig Inkompatibilitäten von Schnittstellen: Hier wurden dann beispielsweise für gleiche Software-Komponenten versehentlich mehrere Schnittstellen definiert – logisch zwar mit gleicher Bedeutung, aber in Form und technischen Details abweichend. Werden diese Fehler erst spät im Entwicklungsprozess entdeckt, sind teure Korrekturmaßnahmen die Folge. Moderne Werkzeuge für die Elektrik-/Elektronik-Entwicklung wie beispielsweise PREEvision beugen hier effektiv vor: Dank einer durchgängigen Verbindung zur „Abstract System Description“ und der Umsetzung des AUTOSAR-VFB-Konzepts im Werkzeug werden Inkonsistenzen und Redundanzen im Design frühzeitig erkannt und vermieden. Idealerweise werden alle Komponenten, Schnittstellen und Datentypen außerdem nur einmal angelegt und in einer zentralen Software-Bibliothek vorgehalten. Sie sind so projektübergreifend verfügbar und lassen sich bei Bedarf wiederverwenden.

Topologie, Design und Standardisierung der Systemkommunikation

Mit der Aktivität „Design System“ werden die im VFB-System definierten Software-Komponenten auf einer Topologie aus Netzwerken und Steuergeräten verteilt. Diese Aufgabe wird in der Regel von Systemarchitekten umgesetzt:

Sie übernehmen entweder die Topologie eines bestehenden Fahrzeugs und erweitern sie bei Bedarf um neue Funktionen oder legen sie von Grund auf neu an. In beiden Fällen definieren sie Bustechnologie – CAN, CAN FD, LIN, FlexRay oder Ethernet – und Hardware-Eigenschaften, ordnen die Software-Komponenten den Steuergeräten zu und analysieren die zu erwartende Kommunikationslast innerhalb des Systems. Ziel ist dabei eine optimale Lastverteilung auf den Bussystemen und Steuergeräten (Bild 4).

Die Kommunikation auf den einzelnen Bussystemen wird im AUTOSAR-Systemdesign durch die Aktivität „Design Communication“ beschrieben. Ein großer Vorteil der AUTOSAR-Methodik im Vergleich zu konventionellen Formaten wie LDF oder DBC:

In der Kommunikationsmatrix können auch Gateways problemlos beschrieben werden. Mit Gateways ist es möglich, Signale und Botschaften transparent von einem Bussystem in ein anderes zu übertragen. Die Route des Signals vom Sender bis zum Empfänger ist dabei stets systemweit nachvollziehbar, unabhängig von der verwendeten Übertragungstechnik (Bild 5).

Transport-Protokoll, Netzwerk-Management und Teilnetze sind weitere durch AUTOSAR standardisierte Features auf der Kommunikationsebene. Mit dem Transport-Protokoll werden große Datenpakete in kleinere segmentiert und so über konventionelle Bussysteme übertragen. Nach der Übertragung werden die Datenpakete vom Empfänger wieder zusammengesetzt. Diese Funktion wird in AUTOSAR über Gateways hinaus unterstützt und hauptsächlich für Diagnosezwecke verwendet, sie ist aber auch für Applikationsdaten verfügbar.

Mit „Network Management“ und „Partial Networks“ werden systemweite Subnetze erzeugt, die Komponenten gesammelt aufwecken, wachhalten oder herunterfahren können, um Energie einzusparen. Dabei erzeugte Network-Management-Konfigurationen können mehrere Kommunikations-Cluster umfassen. Bei Bedarf werden im AUTOSAR-System-Design außerdem weitere Aspekte umgesetzt:

  • Werden große oder sehr komplexe Dateneinheiten übertragen, wird eine Datentransformation (Data Transformation) definiert. Daten auf der Senderseite werden serialisiert und auf der Empfängerseite deserialisiert. Es ist nicht mehr notwendig, komplexe Datentypen auf einzelne Signale zu mappen; die Komplexität der Konfiguration wird reduziert.
  • Arbeiten mehrere Steuergeräte in einem verteilten System in einer bestimmten, eindeutigen Reihenfolge zusammen, ist eine systemweite Zeitsynchronisierung (Global Time Synchronisation) notwendig.
  • Mit Zeitvorgaben (Timing Constraints), Ereignissen (Events), Ereignisketten (Event Chains) und Informationen aus Topologie, Software-Verteilung und Signal-Mappings werden Zeitanforderungen definiert, die vom System erfüllt werden sollen.
  • Systemvarianten eines Fahrzeugs (Variants) werden über Bedingungen (Conditions) und Auflösungszeiten (Binding Time) auf Elementen der Systembeschreibung definiert.
  • Jedes Systemelement kann von Safe¬ty-Informationen referenziert oder mit einem ASIL versehen werden.

Resultat des System-Designs ist das Arbeitsprodukt „System Description“. Es beinhaltet ein komplettes Fahrzeug-Design, das zwischen Organisationen und Entwicklungswerkzeugen im XML-Dateiformat ausgetauscht wird. Die AUTOSAR-Methodik achtet dabei auf unterschiedliche Austauschpunkte und schlägt den passenden Umfang für die jeweilige Datenlieferung vor. Das so erzeugte „Deliverable“ ist dann eine einzelne oder eine Gruppe von AUTOSAR-XML-Dateien.