BAUELEMENTE

Die hardware-nahe Seite von Autosar

Autosar ist bei weitem nicht nur für die Software-Firmen ein Thema, sondern auch für die Hardware-Lieferanten. So muss ein Hersteller von Mikrocontrollern beispielsweise für die ENTKOPPLUNG DES MIKROCONTROLLERS VON DER SOFTWARE sorgen. Das ist die Aufgabe des MCAL.

A utosar (AUTomotive Open System ARchitecture) ist eine internatio-nale Gemeinschaft von Auto-

mobilherstellern, Zulieferern, Halbleiter-firmen sowie Software-Lieferanten. Sie alle haben das zentrale Ziel, eine modula-re Software-Architektur zu definieren, welche die Software-Applikationen von der zugrunde liegenden Hardware ent-koppelt. Dabei steht die Wiederverwend-barkeit durch die Kapselung der einzel-nen Funktionalitäten im Fokus.

BMW, Bosch, Continental, DaimlerCh-rysler und VW regten 2002 erste Gesprä-che über gemeinsame Ziele an. 2003 etab-lierten sie eine formale Partnerschaft und erweiterten den Kreis der Mitglieder um weitere namhafte Firmen.

Auch wenn der Beginn der Autosar-Partnerschaft durch deutsche Firmen ge-prägt wurde, liest sich mittlerweile die Mitgliederliste wie ein Who-is-Who der globalen Automotive-Branche. Neben den Automobilherstellern und den klas-sischen Zulieferern finden sich auch Halbleiterhersteller, Software-Häuser und Dienstleister auf der Liste. Inzwi-schen umfasst das Autosar-Konsortium

137 Partnerfirmen (Stand Frühjahr 2008), die sich auf vier Bereiche aufteilen: Core Partners, Premium Members, Associate Members und Development Members.

Neben den neun Core-Partners gibt es 54 Premium-Mitglieder, die sich gemein-sam in Arbeitsgruppen um die Weiterent-wicklung des Standards bemühen und die Spezifikationen erstellen. Den Core-Partnern obliegt außerdem die Verant-wortung bei Organisations- und Verwal-tungsfragen.

Des Weiteren gibt es derzeit 68 Asso-ciate und sechs Development Members, die sich durch ihre Mitgliedschaft ein Recht auf den Einsatz von Autosar er-worben haben und Zugang zu allen frei-gegebenen Dokumenten erhalten.

Die wachsende Zahl der Mitglieder spiegelt die breite Akzeptanz des Stan-dards in der Automotive-Welt wieder und zeigt zugleich eine der Stärken von Autosar.

Die Automobil-Branche hat erkannt, dass ein Umdenken erforderlich ist, um die dramatisch gestiegene Komplexität moderner Fahrzeug-Architekturen zu beherrschen. Diesen Herausforderungen

kann mit der Entwicklung und Standar-disierung einer offenen Systemarchitek-tur in der Automobilindustrie begegnet werden. Um eine möglichst hohe Akzep-tanz zu erreichen, kann die Festlegung eines weltweiten Standards nicht durch einzelne Unternehmen erfolgen. Ein Mo-dell ist notwendig, bei dem so viele Marktteilnehmer wie möglich in die Ar-beit einbezogen werden, um so gemein-sam das Ziel eines starken Standards zu erreichen. Damit alle am Entwicklungs-prozess beteiligten Firmen profitieren, muss jeder Zulieferer seine spezifischen Vorteile nutzen und einbringen.

Neue Herausforderungen Dies beginnt beim Halbleiterhersteller, der durch die Bereitstellung der Treiber-schicht passend zu seinem Mikrocontrol-ler eine Basis für die software-unabhän-gigen Schichten bietet und so eine Ent-kopplung von der Hardware durch stan-dardisierte Funktionen ermöglicht (Mi-crocontroller Abstraction Layer – MCAL). Als ursprünglich reine Hard-ware-Produzenten stellen sich Firmen wie NEC Electronics damit neuen He-

22 AUTOMOBIL-ELEKTRONIK � electronica – Sonderausgabe 2008

Bild 1: Wiederverwendbarkeitsmodell

BAUELEMENTE

rausforderungen. Bei der Entwicklung des Toolings sind die Software-Häuser gefragt, denen dadurch eine besonde-re Rolle zukommt, denn die Konfiguration betrifft jede Schicht des Autosar-Modells.

Die Applikationen selber werden von den Tier1 entwickelt. Dies geschieht so-mit im Einklang mit dem fundamentalen Designkonzept von Autosar: Trennung zwischen Applikation und Infrastruktur.

Auf diese Weise wird von allen Glie-dern der Zuliefererkette Know-how im jeweiligen Kompetenzbereich einge-bracht – ein großer Vorteil für alle Markt-eilnehmer, den OEM und schließlich auch für den Endkunden.

Vor- und Nachteile von Autosar Autosar bietet Vorteile durch Standardisie-rung und Modularität, wodurch ein hoher Wiederverwendungswert ermöglicht wird. Eine autosar-konforme Komponen-te lässt sich ohne zeitaufwendige und kos-tenintensive Anpassungen auf eine andere Zielumgebung portieren, was wiederum

Bild 2: Der MCAL von NEC im Autosar-System

Bild 3: Der Ent-wicklungsplan

von Autosar bei NEC

den Entwicklungs- und Testaufwand re-duziert. Qualitativ hochwertige Software ist so wirtschaftlich leichter umzusetzen.

Das durchdachte und ständig verbesser-te Modulkonzept von Autosar wird von Software-Herstellern häufig als Vorteil an-gegeben. Die einzelnen Komponenten ei-ner Autosar-Umgebung kommunizieren über den Virtual Function Bus (VFB) mit-einander. Diese Kommunikationsschnitt-stelle ist spezifiziert und kann somit pro-blemfrei genutzt werden. Module fremder Hersteller können auf diesem Weg ge-meinsam zum Einsatz kommen.

Doch ein neuer Standard beinhaltet auch Nachteile. Die Einführung einer zu-sätzlichen Abstraktionsebene führt bei un-verändertem Funktionsumfang unum-gänglich zu einem höheren Bedarf an Re-chenleistung und Speicherbedarf. Diese Erkenntnis ist nicht neu, und es liegt auf der Hand, dass speziell angepasster Source Code der standardisierten Software in die-sen beiden Punkten immer überlegen ist.

Ob sich dieser Nachteil durch die er-hoffte Kosteneinsparung wieder ausglei-chen lässt, wird sich in den nächsten Wo-chen und Monaten zeigen, wenn die ers-ten Autosar-konform entwickelten Syste-me in Serie gehen. Doch die derzeitige Ent-wicklung auf dem Automotive-Markt spricht eine eindeutige Sprache für den ge-meinsamen Standard. So haben sämtliche Core-Partner bis spätestens 2010 die Ein-führung von Autosar-konformen Produk-ten geplant.

Release 3.0 Autosar ist derzeit ein lebendiger Stan-dard. Die finale Version ist noch nicht er-reicht, und Verbesserungen werden wei-terhin in den Arbeitsgruppen entwickelt.

Seit Ende 2007 ist der Autosar-Stan-dard in der Version „Release 3.0“ verfüg-bar, der in drei Teilbereiche unterteilt wer-den kann: � Basis-Software (BSW) und RTE (Runti-

me Environment).

� Methodologie und Templates. � Funktionsschnittstellen auf Anwen-

dungsebene. Dabei gab es im Vergleich zu der vorher-gehenden Version Release 2.1 in den drei Bereichen folgende Veränderungen und Verbesserungen:

Bei Basissoftware und RTE bietet Re-lease 3.0 jetzt ein Wakeup der ECU bzw. ein Startup des Netzwerks, während gleichzeitig State Manager für die Basis-Software-Module (Basic Software Modu-le) CAN, Flexray und LIN eingeführt wur-den. Parallel dazu wird das generische Netzwerk-Management (Generic-NM) durch ein NM-Gateway ergänzt. Schließ-lich wurden die BSW-Modelle, die SWS-Modelle (SWS: Software-Spezifikation) und die UML-Modelle (UML – Unified-Modeling-Language) verbessert.

Im Teilbereich Methodologie liefert das Release 3.0 die Spezifikation der Templates für die Beschreibung von BSW-Modulen, die Verbesserung des Meta-Modells und der entsprechenden Templates. Auch die Abstimmung des System-Templates auf die Konfigurationsparameter der elektri-schen Steuergeräte wurde verbessert.

Desweiteren gab es bei den Funktions-schnittstellen auf Anwendungsebene mit Release 3.0 Änderungen, zu denen auch die Harmonisierung eines gemeinsamen bereichsübergreifenden Master-Tables für sämtliche Anwendungsbereiche ein-schließlich der Daten-Strukturen gehört. Neu sind die klärende Dokumente für die Automotive-Bereiche Body und Comfort, Powertrain und Chassis. Auch die XML-Spezifikation (eXtensible Mark-up-Language) ist als standardisierte Funk-tionsschnittstelle ein Thema des Release 3.0.

Release 4.0 wird Sicherheitsfunktionen in die Autosar-Architektur einbauen und Hilfestellung geben, um die Entwicklung sicherheitsrelevanter Funktionen zu er-leichtern. Die Veröffentlichung dieser Ver-sion ist für Ende 2008 geplant.

Neue Herausforderung angenommen Der Halbleiterhersteller NEC Electronics ist seit März 2004 Premium Member im Au-tosar-Konsortium, seitdem in diversen Ar-beitsgruppen aktiv und somit an der Wei-terentwicklung des Standards beteiligt. Als Hardware-Hersteller obliegt NEC Electro-nics nach dem Autosar-Prinzip die Ent-kopplung des Mikrocontrollers von der Software durch die Entwicklung eines Mi-krocontroller Abstraction Layer (MCAL). Die hierfür nötige Treiberschicht wird nach Gesichtspunkten der höchsten Qualitäts-stufen implementiert.

Die erste Version eines MCAL wurde im Februar 2007 für die Fx3-Serie fertig ge-stellt. Im Sommer 2007 wurde dann das Portfolio durch den PHO3 (PhoenixFS) er-weitert. Sowohl die SPAL-Treiber, als auch die CAN-, LIN- und später auch die Flex-ray-Module wurden konform zu Autosar Release 2.0 entwickelt.

Durch eine enge Kooperation mit den führenden Software-Häusern wurden komplette SW-Stack-Lösungen erarbeitet, die durch passendes Tooling komplettiert werden. Enge Zusammenarbeit mit Tier1-Kunden hat dazu beigetragen, dass die Software kontinuierlich verbessert werden konnte.

Seit Anfang dieses Jahres sind die MCAL-Versionen für Fx3 und PHO3 als Autosar Release 2.1 erhältlich. Beide Ver-sionen sind bzw. werden in die Tool-Um-gebungen und den SW-Stack von Vector und Elektrobit integriert. Die Produktpa-lette wird ständig erweitert. Neben bereits umgesetzten Autosar-Lösungen für Rx3 und Cargate M (CAG4-M) stehen auch Implementierungen nach Autosar R3.0 an, die im Herbst 2008 veröffentlicht wer-den. Selbstverständlich wird auch die neue Microcontroller-Familie (Xx4-Generati-on) mit einem MCAL unterstützt..

NEC Electronics zeigt mit diesen Aktivi-täten ein klares Bekenntnis zum Autosar-Standard und folgt damit einem deutli-chen Trend in der Automobilbranche. Autosar ist ein Automotive-Standard auf dem Weg zur Serienreife und wird durch seine breite Unterstützung eine hohe Ak-zeptanz finden.

infoDIRECT www.all-electronics.de Link zu NEC: 319AELeS08

24 AUTOMOBIL-ELEKTRONIK � electronica – Sonderausgabe 2008

BAUELEMENTE

Dipl.-Ing. Christian Renner ar-beitet seit 2007 bei NEC Electro-nics in der Autosar-Gruppe.