Classic Platform

Über Classic Platform

Die Architektur der AUTOSAR Classic Platform unterscheidet auf oberster Abstraktionsebene drei Software-Schichten, die auf einem Mikrocontroller ausgeführt werden: Applikationssoftware, Runtime Environment (RTE) und Basic Software (BSW).

• Die Applikationssoftware-Schicht ist weitgehend hardwareunabhängig ausgelegt.
• Die Kommunikation zwischen Softwarekomponenten sowie der Zugriff auf die BSW erfolgen über das RTE.
• Das RTE stellt die vollständige Schnittstelle für Applikationen dar.
• Die BSW ist in drei Hauptschichten sowie komplexe Treiber unterteilt:
  • Services, ECU‑ (Electronic Control Unit) Abstraktion und Mikrocontroller-Abstraktion
• Die Services sind weiter in funktionale Gruppen untergliedert, welche die Infrastruktur für System-, Speicher- und Kommunikationsdienste bereitstellen.

Aktuelles Release 

AUTOSAR Classic Release R25-11

Konzept

Ein zentrales Konzept ist der „Virtual Functional Bus“ (VFB). Dieser entkoppelt die Applikationen von der zugrunde liegenden Infrastruktur. Die Kommunikation erfolgt über dedizierte Ports, was bedeutet, dass die Kommunikationsschnittstellen der Applikationssoftware auf diese Ports abgebildet werden müssen. Der VFB übernimmt sowohl die Kommunikation innerhalb einer einzelnen ECU als auch zwischen verschiedenen ECUs. Aus Sicht der Applikation ist kein detailliertes Wissen über zugrunde liegende Technologien oder Abhängigkeiten erforderlich. Dies unterstützt die hardwareunabhängige Entwicklung und Nutzung von Applikationssoftware.

Die geschichtete Architektur von AUTOSAR stellt alle notwendigen Mechanismen für Software- und Hardwareunabhängigkeit bereit. Sie unterscheidet zwischen drei Hauptsoftwareebenen, die auf einem Mikrocontroller (µC) ausgeführt werden: Applikationsschicht, Runtime Environment (RTE) und Basic Software (BSW).

Die Applikationen aus den verschiedenen Automotive-Domänen binden die Basissoftware über das RTE an.

Neben der Definition von Architektur und Schnittstellen legt AUTOSAR auch eine Methodik fest, die die Konfiguration des gesamten AUTOSAR-Stacks ermöglicht und die Interoperabilität zwischen unterschiedlichen Toolchains verbessert. Dies ist einerseits entscheidend für die Zusammenarbeit innerhalb von Entwicklungsprojekten und trägt andererseits zur Reduzierung der Entwicklungskosten bei.

Architektur

Das grundlegende Konzept der standardisierten ECU-Softwarearchitektur ist die Trennung von hardwareunabhängiger Applikationssoftware und hardwareorientierter Basic Software (BSW) mittels der Software-Abstraktionsschicht RTE (Runtime Environment). Auf der oberen Seite des RTE ermöglicht diese Abstraktionsschicht die Entwicklung OEM-spezifischer und wettbewerbsdifferenzierender Softwareapplikationen. Auf der unteren Seite des RTE unterstützt sie die Standardisierung sowie die OEM-Unabhängigkeit der Basissoftware. Weitere Merkmale der AUTOSAR-Softwarearchitektur sind die Skalierbarkeit der ECU-Software für unterschiedliche Fahrzeuglinien und Varianten, die Möglichkeit zur Verteilung von Applikationen (funktionalen Softwaremodulen) über mehrere ECUs hinweg sowie die Fähigkeit zur Integration von Softwaremodulen aus unterschiedlichen Quellen.

Die Basic Software innerhalb der AUTOSAR-Softwarearchitektur ist weiterhin in die folgenden Schichten unterteilt: Services, ECU-Abstraktion und Mikrocontroller-Abstraktion. Die durch das RTE realisierte Trennung der Applikationsschicht von der Basissoftware umfasst auch die Steuerung des Datenaustauschs zwischen diesen Schichten. Dies bildet die Grundlage für eine komponentenorientierte, hardwareunabhängige Softwarestruktur auf Applikationsebene, wobei Softwarekomponenten (SWCs) als eigenständige Einheiten fungieren. Aufgrund ihrer Hardwareunabhängigkeit können SWCs ohne spezifische Kenntnisse über die eingesetzte oder geplante Hardware entwickelt werden. Darüber hinaus ist es möglich, bestehende SWCs während der Entwicklung flexibel auf unterschiedliche ECUs zu verlagern.

Methodik und Templates

Neben der Softwarearchitektur hat AUTOSAR einen harmonisierten methodischen Ansatz für die Entwicklung von Automotive-Software eingeführt. Dieser wird maßgeblich durch die Notwendigkeit getrieben, die Zusammenarbeit zwischen den verschiedenen an heutigen Automotive-Projekten beteiligten Parteien zu verbessern.

AUTOSAR stellt Mittel bereit, um alle Aspekte zu spezifizieren, die für die Integration einer Softwarekomponente auf einer ECU sowie für die Integration verschiedener ECUs in die gesamte Netzwerkkommunikation über unterschiedliche Bussysteme hinweg erforderlich sind. Die Methodik definiert die Abhängigkeiten von Aktivitäten zu Arbeitsergebnissen und ist darauf ausgelegt, Aktivitäten, Beschreibungen sowie die Nutzung von Werkzeugen im AUTOSAR-Kontext zu unterstützen.

Die Beschreibungen (.arxml) basieren auf den AUTOSAR Templates, welche das formale Austauschformat (AUTOSAR-Schema) sowie die damit verbundenen semantischen Einschränkungen definieren. Die Beschreibungen dienen dazu, die Informationen zu verwalten, die innerhalb der AUTOSAR-Methodik erzeugt oder verarbeitet werden. Verschiedene Generatoren können diese Informationen nutzen, um die Konfiguration und Generierung des RTE sowie der AUTOSAR-Basissoftware (einschließlich des Betriebssystems) zu unterstützen.

AUTOSAR Classic Platform Workflow Beispiel 

Seit einiger Zeit erreichen uns Anfragen von Partnern, praktische Beispiele für den Einsatz von AUTOSAR bereitzustellen, insbesondere für die Classic Platform. AUTOSAR ist diesem Wunsch nun nachgekommen. Uns ist bewusst, dass auf dem Markt verschiedene Werkzeuge und partnerspezifische Lösungen existieren. Daher verfolgen wir den Ansatz, die von uns bereitgestellten Lösungen möglichst neutral gegenüber diesen spezifischen Ausprägungen zu halten.

Um diese Unabhängigkeit sicherzustellen, evaluieren wir unsere Lösungen mit unterschiedlichen Toolchains. Dabei berücksichtigen wir auch verschiedene Vorgehensweisen in Projekten. Die ursprünglich von AUTOSAR vorgeschlagene Methode ist ein Top‑down-Ansatz, das heißt, ausgehend von einer Fahrzeug-Systembeschreibung wird die Verteilung der Funktionen auf einzelne ECUs im Fahrzeugnetzwerk sowie eine daraus resultierende Kommunikationsmatrix abgeleitet. Uns ist jedoch bewusst, dass dieses Vorgehen in der Praxis nicht immer umsetzbar ist. In einigen Projekten werden einzelne Steuergeräte lediglich auf Basis einer vorhandenen Kommunikationsmatrix sowie manueller Konfigurationseinstellungen definiert.

In unserer ersten Iteration (Iteration 01) für eine derart „möglichst neutrale“ Konfiguration hat AUTOSAR entschieden, die für die Umsetzung des Top‑down-Ansatzes erforderlichen Artefakte bereitzustellen. Diese Artefakte sowie die zugehörigen Beschreibungen stehen auf dieser Seite als ZIP-Datei zur Verfügung. Eine Beschreibung zur Verarbeitung dieser Artefakte innerhalb Ihrer Toolchain finden Sie in der ZIP-Datei unter dem Namen AUTOSAR_CP_TR_WorkflowExample.pdf.

Nach der Validierung der von uns bereitgestellten Systemextrakte können Sie zudem die C-Quellcodes für die Applikationssoftware (ASW) anfordern, um daraus eine HEX-Datei zu erzeugen, die – sofern entsprechend unterstützt – auf Ihrer µC-Zielhardware mit CAN ausgeführt werden kann.

Bitte klicken Sie hier, um die ZIP-Datei herunterzuladen.

Mit dieser Veröffentlichung möchten wir unsere Partner zugleich dazu einladen, gemeinsam die nächste Iteration (Iteration 02) zu gestalten. In der ersten Iteration haben wir lediglich ein sehr einfaches Beispiel mit zwei über einen CAN-Bus verbundenen ECUs realisiert. Für zukünftige Iterationen könnten wir beispielsweise:

1. die Anzahl der Bus-Teilnehmer erhöhen
2. zusätzlich Ethernet-Kommunikation konfigurieren
3. eine Anbindung an eine AUTOSAR Adaptive Platform ECU realisieren
4. oder weitere Erweiterungen basierend auf Ihren Ideen umsetzen

Falls Sie Interesse haben, eine Working Group zu gründen, um gemeinsam an den nächsten Iterationen zu arbeiten, senden Sie bitte eine E-Mail an Martin Lunt.