Evaluierungs-Kits
Richtig wechseln zu AUTOSAR
Fortsetzung des Artikels von Teil 1
Abstraktion fernab der Hardware
AUTOSAR bietet eine standardisierte Definition für ECU-Schnittstellen und ermöglicht es dem Entwickler, standardisierte, wiederverwendbare Software-Schichten und -Komponenten, die in verschiedenen Automobil-Steuergeräten vorhanden sein müssen, zu spezifizieren. Da der Standard Hardware-unabhängig ist, lässt sich eine klare Linie zwischen der Anwendungs-Software und der Hardware-Plattform ziehen. Der Anwendungsentwickler kann die Details der individuellen Fahrzeugfunktionen in der Anwendungs-Software spezifizieren, ohne dass er sich um die darunter liegenden Software Services und Hardware-Schnittstellen kümmern muss. In der Vergangenheit waren Software und Hardware sehr eng integriert, was die Portabilität und Wiederverwendung behinderte (Bild 1).
Jobangebote+ passend zum Thema
Die Abstraktion des Designs von Hardware-Entscheidungen eröffnet dem Fahrzeughersteller die Freiheit für ein Top-down-Design auf Basis der erforderlichen Fahrzeugfunktionen. Für dieses Stadium des Designprozesses wurde das Konzept des virtuellen Funktionsbusses (Virtual Function Bus, VFB) eingeführt. Mit dem VFB lassen sich alle Software-Komponenten eines Systems miteinander verbinden und testen (Bild 2).
Durch die Verwendung eines VFB benötigen die Anwendungs-Software-Komponenten (Software Components, SWCs) auch keine Informationen über andere SWCs. Die Software-Komponenten übergeben ihren Output an den unterstützenden VFB, der diese Informationen an die Eingabeports der Zielkomponenten weiterleitet. AUTOSAR definiert die Eingabe- und Ausgabeports ebenso wie das Format für den Informationsaustausch. Dieser abstrahierte Ansatz ermöglicht es, das Zusammenspiel aller Software-Funktionen des Fahrzeugs und die Schnittstellen vor der Definition der zugrunde liegenden Hardware zu validieren. Da alle Funktionen auf einem VFB als Software-Elemente definiert sind, lassen sich Designänderungen viel einfacher durchführen als bei einem herkömmlichen Entwicklungsprozess.
Auf VFB-Ebene ist zwar noch nicht festgelegt, wie die ECUs später im realen Fahrzeug verteilt und miteinander verbunden sein werden, sie ist aber eine hilfreiche Testumgebung für die Architekturentwicklungsphase. So lassen sich etwa bereits Timing-Prüfungen durchführen und Schnittstellen definieren. Sobald der Designer die einzelnen Funktionen entwickelt hat, werden die Funktionen auf spezifische ECUs im System verteilt (Bild 3). AUTOSAR unterstützt diesen sogenannten Mapping-Prozess der Software-Komponenten (SWCs). Eine komplexe ECU kann sehr viele SWCs enthalten, die bei Bedarf hierarchisch organisiert werden.
AUTOSAR Run Time Environment (RTE)
Jede einzelne ECU verfügt über ihre eigene maßgeschneiderte Laufzeitumgebung (Run-Time Environment, RTE), die normalerweise automatisch von den Entwicklungswerkzeugen erstellt wird. Die eigentliche Kommunikation zwischen realen ECUs wird beispielsweise als Teil eines CAN- oder FlexRay-Busses realisiert. Um die von vernetzten AUTOSAR-Komponenten benötigen Kommunikationspfade zu implementieren, wird die RTE von einem Generierungs-Tool konfiguriert. Die RTE ist die Implementierung des VFB und realisiert die Kommunikation zwischen SWCs. Für die Kommunikation zwischen ECUs ist die darunterliegende Basis-Software zuständig. Da der AUTOSAR-Standard sehr viele verschiedene Software-Komponenten unterstützt, muss die RTE-Implementierung die Einschränkungen und Eigenheiten berücksichtigen, die eine breite Palette von SWCs mit sich bringt.
BSW-Schicht und Betriebssystem
Die Basis-Software (BSW) ist eine standardisierte Software, die zwar keine Fahrzeug-Anwendungslogik und ECU-Funktionen enthält, jedoch der über ihr liegenden RTE Hardware-abhängige und Hardware-unabhängige Services zur Verfügung stellt. Beispiele für diese erforderlichen Services sind Zugriffe auf den nichtflüchtigen Speicher (NVRAM-Manager), Managementdienste für die Netzwerkkommunikation, Diagnose-Services und Zustandsmanagement.
Wenn eine in der Anwendungsschicht definierte AUTOSAR-SWC Dienste anfordert, dann ist es die Aufgabe der RTE, diesen Aufruf an die Service-SWC der BSW weiterzuleiten. Die RTE bietet keine Mechanismen, um auf die Dienste einer entfernten ECU zugreifen zu können. Alle Service-Anforderungen müssen auf der lokalen ECU erfüllt werden.
Hardware-Zugriff in AUTOSAR
Die AUTOSAR-Software-Architektur entkoppelt die Anwendungslogik von der Hardware und erleichtert so die Wiederverwendung und Portabilität. Die BSW und das Betriebssystem sind mit der Microcontroller Abstraction Layer (MCAL) verbunden. Diese Schicht bietet wiederum Zugang zu den Komponenten auf den Host-Mikrocontroller. Die MCAL ist für jeden Mikrocontroller spezifisch und gewährt dem Betriebssystem und der BSW Zugang zu Komponenten wie digitale I/Os, Analog-Digital-Wandler sowie FLASH- und EEPROM-Support. Bild 4 zeigt die Beziehung zwischen verschiedenen Hardware- und Software-Schichten in einem AUTOSAR-Steuergerät.
Eine neue Designmethodik
Mit einer Top-down-AUTOSAR-Designmethodik können Automobil-OEMs mit einer vollständigen Beschreibung des gesamten Netzwerks arbeiten. AUTOSAR-Entwicklungswerkzeuge erlauben es, einzelne ECUs zu extrahieren sowie die Konnektivität und Schnittstelleninformationen in AUTOSAR XML (arxml) zu definieren. Die Schnittstellendefinition kann dann für weitere Präzisierung und Implementierung an einen Tier-1-Zulieferer weitergeleitet werden. Da das Format standardisiert ist, kann dieselbe Information im Rahmen einer Ausschreibung an mehrere Tier-1-Zulieferer weitergegeben werden. Die standardisierte Beschreibung hat den Vorteil, dass sich Mehrdeutigkeiten im Design der ECU-Beschreibung vermeiden lassen. Der AUTOSAR-Standard ist Hardware-unabhängig und deshalb in der Lage, die Vorteile neuer Industrietrends wie Ethernet im Fahrzeug, Fahrzeugnetzwerke mit gemischten Technologien (CAN/FlexRay), heterogene Mehrkernplattformen und Fahrzeug-Gateways-Arrangements zu nutzen.
Einige Unternehmen, einschließlich Mentor Graphics, bieten Evaluierungs-Kits für das AUTOSAR-Design. Diese Kits decken alles vom Architekturdesign bis zur Konfiguration einzelner ECUs ab. Mentor Graphics stellt in diesem Rahmen die VSX Tool Suite sowie ein Evaluierungs-Board mit CAN-, FlexRay-, LIN- und Ethernet-Unterstützung zur Verfügung. Die Tools basieren neben dem eigenen Framework auf Eclipse und nutzen Open Source Tool Chains, um Designs vom Quellcode bis zur Ausführung auf die Evaluierungs-Boards zu bringen. Für einen effizienten Wechsel zu AUTOSAR empfehlen sich zunächst risikoarme Untersuchungen und Testläufe von AUTOSAR statt einer „Big Bang“-Integration, bei der alle ECUs eines Fahrzeugs auf einmal auf die AUTOSAR-Methodik migriert werden. Die erfolgreiche Einführung von AUTOSAR hilft den Unternehmen dann auch, Anforderungen an die funktionale Sicherheit nach ISO 26262 zu erfüllen, da dieser Standard einen wiederholbaren, gut definierten Top-down-Entwicklungsansatz ermöglicht.
Der Autor
| Andrew Patterson |
|---|
| ist Business Development Director bei Mentor Graphics in der Embedded Software Division. Er ist spezialisiert auf den Automobilbereich und arbeitet an Linux-basierten Lösungen für Infotainment. Kombi-Instrumente und AUTOSAR-basierte ECUs. Bevor er zu Mentor kam, arbeitete Patterson über 25 Jahre lang im Bereich Design-Automation. Er hat einen Abschluss als Master in Elektrotechnik und Elektrowissenschaften von der Universität Cambridge, Großbritannien. |
- Richtig wechseln zu AUTOSAR
- Abstraktion fernab der Hardware
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Mentor Automotive
Safety für digitale Kombiinstrumente
Safety und Security
ITK Engineering tritt AUTOSAR bei
Personalie
AUTOSAR ernennt Simon Fürst zum Sprecher
Intensiv-Seminar
AUTOSAR: Von der Theorie zur Praxis
Automotive Software Standardisierung
Viele Hürden für AUTOSAR
Automotive Software Kongress
Von der Virtualisierung bis AUTOSAR
