Entwicklung von Mikrocontroller-Treibern für die AUTOSAR-Architektur Steuergeräte optimal nutzen

Leistungsfähige Steuergeräte im Automobil erfordern Mikrocontroller, die auf Systemanforderungen optimiert sind und den Software-Standard AUTOSAR flexibel umsetzen. Dabei dürfen sich Software-Standardisierung und die Ausnutzung von Mikrocontroller-Innovationen gegenseitig nicht ausschließen. Ziel ist daher die Entwicklung von AUTOSAR-MCAL-Treibern, die ein Maximum an Hardware-Funktionen innerhalb von AUTOSAR unterstützen, ergänzt durch komplexe Treiber für nicht standardisierte Peripherie.

Entwicklung von Mikrocontroller-Treibern für die AUTOSAR-Architektur

Leistungsfähige Steuergeräte im Automobil erfordern Mikrocontroller, die auf Systemanforderungen optimiert sind und den Software-Standard AUTOSAR flexibel umsetzen. Dabei dürfen sich Software-Standardisierung und die Ausnutzung von Mikrocontroller-Innovationen gegenseitig nicht ausschließen. Ziel ist daher die Entwicklung von AUTOSAR-MCAL-Treibern, die ein Maximum an Hardware-Funktionen innerhalb von AUTOSAR unterstützen, ergänzt durch komplexe Treiber für nicht standardisierte Peripherie.

Für die optimale Nutzung eines Mikrocontrollers werden vom Halbleiterhersteller entsprechende Software-Treiber mitgeliefert. Entscheidend für die Leistungsfähigkeit des Gesamtsystems ist das Zusammenspiel von Mikrocontroller-Peripherie und Treibern, die auf AUTOSAR-Software-APIs aufbauen. Mikrocontroller-Bausteine wie die 32-bit-Familie TriCore oder die Familien XC2200 und XC2300 beinhalten Baugruppen, deren Funktionen die Interrupt-Belastung reduzieren und die Flexibilität der Hardware erhöhen. Beispiele hierfür sind universelle serielle Kommunikationsmodule (USIC), die wahlweise als SPI, LIN, I2C oder UART-Schnittstelle konfiguriert werden, und die im Folgenden beschriebenen Zeitgeber-Module mit frei programmierbaren Zellen, die verschiedenste PWM-Signaltypen, Input-Capture-Kanäle sowie Timer-Funktionen bereitstellen.

Um die Ziele von AUTOSAR, die Trennung der Applikations-Software von Basismodulen, zu verwirklichen, wird die Fahrzeugelektronik abstrahiert und in mehrere Schichten (Layer) unterteilt. Die Verbindung zum Mikrocontroller stellt die so genannte Mikrocontroller-Abstraktionsschicht (Mikrocontroller Abstraction Layer, MCAL) dar, welche die Peripherie und Funktionen des Mikrocontrollers abbildet. Sie definiert Schnittstellen für Speicher, I/O-Treiber und deren Kommunikationsverbindungen. In dieser Schicht können auch Leistungsmerkmale softwaremäßig nachgebildet werden, die der Mikrocontroller selbst nicht zur Verfügung stellt.

Für den MCAL gilt es zunächst, die Fähigkeiten des Mikrocontrollers optimal zu nutzen. Zusätzlich fordert der Anwender, dass alle Hardware-Funktionen durch Software unterstützt werden. Funktionen, die durch AUTOSAR-Treiber nicht realisierbar sind, werden über komplexe Treiber implementiert.

Die flexible Hardware erfordert eine intelligente Software-Konfiguration, die nicht benötigte Funktionen abschaltet. Dies ist notwendig, da die Anforderungen an die Software-Komplexität und die Laufzeit in verschiedenen Applikationen beispielsweise im Komfort- oder Powertrain-Bereich weit auseinander liegen. Mehrfach genutzte Hardware-Funktionen beziehungsweise Abhängigkeiten der Parameter in verschiedenen MCAL-Treibern werden über ein Konfigurations-Tool verwaltet und Konflikte angezeigt. Änderungen der Konfigurationsdaten nach dem Build-Prozess erlauben die Nutzung der MCAL-Treiber in unterschiedlichen Anwendungsfällen, ohne den Code zu verändern.

zurück zur Übersicht

Aus Sicht eines Anwendungsentwicklers besteht ein AUTOSAR-Steuergerät aus Software-Komponenten, die über so genannte Ports miteinander kommunizieren (Bild). Auch die oberste Schicht der Basis-Software erscheint dem Entwickler als eine Reihe von Software-Komponenten. Die interne Funktionsweise des Betriebssystems bleibt ihm weitestgehend verborgen. Gemäß den AUTOSAR-Regeln für Software-Komponenten verwendet der Entwickler niemals irgendwelche API-Funktionen der einzelnen Module direkt oder greift direkt auf Funktionen oder Variablen anderer Komponenten zu, sondern verwendet stets die jeweiligen Ports mit ihren definierten Schnittstellen. Der gesamte Datenaustausch inklusive ggf. nötiger Typkonversionen wird durch RTE-Funktionen gekapselt. Es spielt dabei keine Rolle, ob der Datenaustausch innerhalb desselben Steuergerätes erfolgt und damit einfach auf Variablen oder Funktionen im Speicher des Steuergerätes zugegriffen wird, oder ob sich die Komponente in einem anderen Steuergerät befindet. In diesem Fall kommuniziert das RTE über ein Bussystem mit dem anderen Steuergerät und überträgt die Daten mit Hilfe von Netzwerkbotschaften bzw. ruft die gewünschten Funktionen im anderen Steuergerät über Remote Procedure Calls auf. Diese abstrakten Mechanismen für den Datenaustausch und die Ablaufsteuerung werden mit Generierungswerkzeugen mehr oder weniger automatisch in entsprechende API-Aufrufe abgebildet.