AUTOSAR Load Balancing in AUTOSAR-Multicore-Systemen (Teil 2)

Ab Release 4.0 bietet AUTOSAR erstmals eine standardisierte Unterstützung für die verteilte Ausführung von Software auf Embedded- Multicore-Prozessoren. Bei der Verteilung von Software auf Rechenkerne stehen im Vergleich zur Verteilung von Software auf unterschiedliche Steuergeräte oder auch Prozessoren eines einzelnen Steuergerätes wesentlich mehr Freiheitsgrade zur Verfügung, da der Overhead und die Design-Einschränkungen durch Kommunikation geringer sind. Eine Herausforderung besteht darin, diese Freiheitsgrade zu nutzen, um die Rechenleistung von Multicore-Plattformen optimal einzusetzen.

Teil 1 dieses Artikels [9] gab eine Übersicht über multicore-bedingte Erweitungen des AUTOSAR-Standards und stellte einen Experimentalaufbau vor, an Hand dessen Strategien zur Optimierung der Verteilung von Software verglichen werden können. In Teil 2 werden nun drei konkrete Verteilungsstrategien diskutiert, die am Beispiel der Software einer Motorsteuerung in einem praxisnahen SzenaSzSzenario evaluiert wurden.

Das Ziel der Verteilung ausführbarer Einheiten in Echtzeit- Systemen besteht allgemein darin, bei möglichst kostengünstiger Hardware alle Zeitanforderungen der Software-Komponenten in allen möglichen Betriebszuständen zu erfüllen. Schon der Nachweis, dass eine bestimmte Konfiguration alle Echtzeit- Eigenschaften erfüllt, ist schwer zu erbringen (siehe [8]). Daher lässt sich eine optimale Lösung für hinreichend große Systeme nicht effizient berechnen. Die manuelle Optimierung der Verteilung ist dementsprechend sehr zeitintensiv und führt nicht unbedingt zu einer optimalen Nutzung von Ressourcen. Aus diesem Grund wurden in Zusammenarbeit von Infineon, Elektrobit und der BMW CarIT an Hand eines Experimentalaufbaus aus der Domäne Antrieb drei prinzipiell verschiedene Strategien untersucht, mit denen sich die Verteilung ausführbarer Einheiten auf einer Multicore- oder Multiprozessor-Plattform werkzeuggestützt optimieren lässt:

  • Freie Verteilung von Runnables.
  • Verteilung von Runnable-Gruppen: Gruppierung von Runnables, die bisher einem Task zugeordnet waren, entsprechend des Datenflusses.
  • Parallelisierung in einer Barrier-Architektur: Runnables eines bisherigen Tasks werden auf zwei synchron laufende Tasks verteilt.