Startseite > Automotive > Software + Tools > Load Balancing in AUTOSAR-Multicore-Systemen (Teil 1)

AUTOSAR

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

28. April 2010, 9:38 Uhr | Von Dr. Kathrin D. Scheidemann, Michael Knapp und Claus Stellwag

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 2

Multicore-Funktionsumfang in der Praxis

Eine erste Evaluierung der Multicore- Funktionen in praxisnahem Kontext hat gezeigt, dass die vorgeschlagenen Konzepte gut geeignet sind, um SWCs, die bisher auf unterschiedliche Steuergeräte oder verschiedene Prozessoren im gleichen Steuergerät verteilt waren, in eine Multicore-Plattform zu integrieren. Kommunikation, die früher über einen Bus abgewickelt wurde, lässt sich auf Intercore-Kommunikation abbilden, da der neue Kommunikationskanal andere Eigenschaften (Latenzzeit und Durchsatz, aber auch Übertragungssicherheit) aufweist. Solange jedoch in der Implementierung der SWCs diesbezüglich keine Annahmen getroffen wurden, sind diese Änderungen unproblematisch. Im Gegenteil, bei der Verteilung von Software auf die Rechenkerne eines Prozessors gibt es deutlich mehr Freiheitsgrade als bei der Verteilung von Software auf unterschiedliche Steuergeräte. Beispielsweise fallen Einschränkungen durch die Größe des Nachrichtenkatalogs eines dazwischen liegenden Busses weg. Je nach Anforderungen der SWCs könnte allerdings die gemeinsame Nutzung von Basis-Software auf dem "Master"-Core, die auch den Zugriff auf Peripherie steuert, zum begrenzenden Faktor werden.

Auch die Verteilung von SWCs auf unterschiedliche Rechenkerne, die bisher auf einem Prozessor integriert waren, ist im Prinzip für den Anwendungs- Software-Entwickler transparent. Allerdings hat die Praxis gezeigt, dass zwischen SWCs innerhalb eines Steuergerätes häufig synchrone Client- Server-Schnittstellen zum Einsatz kommen, weil diese sich – wenn Client und Server auf dem gleichen Rechenkern liegen – von der RTE sehr effizient realisieren lassen. Liegen Client und Server jedoch nicht auf dem gleichen Kern, kann sich das Zeitverhalten des Systems durch Verteilung drastisch ändern: Die Antwortzeit des Aufrufs, aber auch die Interrupt-Last auf den beteiligten Rechenkernen nehmen zu. Daraus resultieren unter Umständen Einschränkungen bei der Verteilung von SWCs. Daher kann es sinnvoll sein, das eingesetzte Kommunikationsparadigma an den betroffenen Schnittstellen umzustellen.

Im Gegensatz zu Applikations- Software-Komponenten dürfen "Complex Device Drivers" (CDDs) an der RTE vorbei miteinander kommunizieren und sogar direkt auf Funktionen der Basis-Software oder auf Betriebssystemfunktionen zugreifen. Die Kommunikation lässt sich über gemeinsam genutzten Speicher realisieren, für dessen Konsistenz die jeweiligen Software-Entwickler verantwortlich sind. Um gegenseitigen Ausschluss zu realisieren, lassen sich in Single-Core-Systemen beispielsweise OS-Ressourcen verwenden oder Interrupts für einen begrenzten Zeitraum sperren. Allerdings sind beide Mechanismen entsprechend der aktuellen OS-Spezifikation nicht kernübergreifend einsetzbar. Einzige kernübergreifende Möglichkeit, einen exklusiven Zugriff auf einen Speicherbereich zu erlangen, bietet die Verwendung von "Spinlocks", die das OS zur Verfügung stellt. Bei Anforderung des Locks warten Tasks aktiv auf Freigabe des Locks, solange der Lock von einem anderen Task belegt ist. Kommen Spinlocks ohne Einschränkungen oder Zusatzmaßnahmen zum Einsatz, kann dies zu unbeschränkter Prioritäteninversion oder sogar zu Deadlocks führen. Ein Deadlock kann beispielsweise dann entstehen, wenn Tasks, die gerade einen Spinlock halten, durch Tasks höherer Priorität verdrängt werden können, die den gleichen Spinlock benötigen. Um das zu verhindern, lassen sich unter anderem vor der Allokation eines Spinlocks kernlokal alle Interrupts oder zumindest das Scheduling sperren. Es müssen also steuergeräteweit Regeln bei der Verwendung von Spinlocks eingehalten werden.