AUTOSAR
Load Balancing in AUTOSAR-Multicore-Systemen (Teil 2)
Fortsetzung des Artikels von Teil 1
Aufbau
Um flexibel mit unterschiedlichen Verteilungsszenarien experimentieren zu können, wurde die als monolithischer Block vorliegende Software einer Motorsteuerung werkzeuggestützt auf mehrere AUTOSAR-Software-Komponenten (siehe [1]) aufgeteilt. Die Software-Komponenten wurden OS-Applikationen auf unterschiedlichen Rechenkernen zugewiesen und auf einer prototypischen, multicore-fähigen AUTOSAR-Basis-Software und einer Dual-Prozessor-Hardware mit von beiden Prozessoren gemeinsam genutztem RAM zur Ausführung gebracht. Die Hardware-Plattform wurde mit einem in Matlab/Simulink [3] simulierten Streckenmodell integriert. Bild 1 zeigt den Aufbau.
Das "Internal Behavior" der Ausgangs-Software definierte zirka 200 Runnables, die in bestimmter Reihenfolge auf mehrere zyklische bzw. eventgetriggerte Tasks unterschiedlicher Priorität abgebildet waren. Das Scheduling der Tasks war kooperativ, d.h., die Unterbrechbarkeit der Tasks war nur an definierten Punkten möglich. Die Kommunikation zwischen den Runnables wiederum wurde mittels globaler Variablen realisiert. Von verschiedenen Runnables aufgerufene Funktionen arbeiteten sowohl auf übergebenen Parametern als auch auf globalen Variablen. Zu erfüllende zeitliche Anforderungen beschränkten sich darauf, dass es nicht zur Mehrfachaktivierung von Tasks kommen durfte, d.h., alle Runnables eines Tasks mussten in einem Zyklus vollständig abgearbeitet werden. Da die unverteilte, ursprüngliche Software einen der Prozessoren nur zu einem Bruchteil (ca. 6 %) auslastete, wurde das Optimierungsziel gesetzt, ausführbare Einheiten so zu verteilen, dass beide Prozessoren in etwa gleich ausgelastet sind und der Mehraufwand durch Intercore-Kommunikation bzw. Synchronisation durch die Verteilung möglichst gering ist.
Jobangebote+ passend zum Thema
- Load Balancing in AUTOSAR-Multicore-Systemen (Teil 2)
- Aufbau
- Freie Verteilung von Runnables
- "Lost Updates"
- Verteilung von Runnable-Gruppen
- Parallelisierung in einer Barrier-Architektur
- Eingesetzte Heuristik
- Auswertung und Ausblick
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Bedienung/HMI
Near Field Communication zur Interaktion mit dem Fahrzeug
Entwicklung
Produktionsfreigabe von AUTOSAR-Basis-Software
Steuergeräte-Software
Serienerprobter und OSEK/VDX-kompatibler Kommuminkations-Stack
Sicherheit
Erstes adaptives Kurvenlicht für Motorräder vorgestellt
SPS in der Fahrzeugtechnik
Automation trifft Automotive
AUTOSAR
Auf dem Weg zum globalen Standard
Prozess-Management/Software-Entwicklung
AUTOSAR: Method Park und Mecel kooperieren
AUTOSAR
Software-Plattform entspricht HIS-Empfehlung
Entwicklung von Kfz-Software
Wechsel von OSEK zu AUTOSAR
AUTOSAR
Load Balancing in AUTOSAR-Multicore-Systemen (Teil 1)
