Aktuelle Steuergeräte im Auto

Transkript

1 (Bilder: Elektrobit) Software optimal auf mehrere Kerne verteilen Aktuelle Steuergeräte im Auto basieren auf den verschiedensten am Markt verfügbaren Multi-Core-Prozessoren. Dabei stehen die Software-Architekten vor neuen Herausforderungen, denn sie müssen entscheiden, wie die verfügbaren Rechenkerne genutzt werden und welche Software-Funktionen auf welchem Kern laufen. Kriterien für dieses Software- Komponenten-Mapping (SWC) sind neben Datenraten und Datenmenge auch logische Gruppierungen, wie z.b. Speicherpartitionierung, um Ansprüchen der funktionalen Sicherheit zu genügen. Ein ungünstiges Mapping von Software-Komponenten auf Prozessorkerne kann sogar zu einer schlechteren Ressourcennutzung führen als auf einem Single-Core-Prozessor. Um dies zu vermeiden, ist eine gezielte Modellierung des Systems unerlässlich. Da die Komplexität eines Multi-Core-Systems um ein Vielfaches höher ist als die eines Single-Core-Systems, bedarf es hier der Unterstützung durch geeignete Optimierungs-Tools für das Software-Komponenten-Mapping. Damit lässt sich für zwei Kerne üblicherweise eine Leistungssteigerung von 30 bis 60 % erreichen. Eine Verdoppelung der Performance ist in seltenen Fällen auch möglich, dazu müssen die Algorithmen allerdings hochgradig parallelisierbar sein. Für die Hardware von Steuergeräten gilt eine einfache Regel: Multi- Core-Prozessoren sind leistungsstärker als Single-Core-Lösungen. Dagegen kann bei der Software ein ungünstiges Mapping von Komponenten auf Prozessorkernen sogar zu einer schlechteren Ressourcennutzung führen als auf einem Single-Core-Prozessor. Mit der richtigen Vorgehensweise sind aber auch deutliche Leistungssteigerungen möglich. Von Rudolf Grave und Stefan Krämer Multi-Core-Architekturen im Vergleich Aktuell sind mit dem Complex-Driver- Ansatz und der AUTOSAR 4.0 Multicore -Architektur zwei verschiedene Multi-Core-Grundarchitekturen im Einsatz. Der Complex-Driver-Ansatz Dieser ältere und am weitesten verbreitete Ansatz sieht vor, dass die AUTOSAR- Basis-Software (BSW) und einige Software-Komponenten auf einem Prozessorkern laufen (Bild 1). Die anderen Kerne werden als Rechenkerne für Algorithmen genutzt oder um Interrupts mit hohen Zeitanforderungen bezüglich Frequenz und Jitter zu bearbeiten. Diese Variante bietet eine einfache Möglichkeit, die Rechenleistung der zwei Kerne zu nutzen. Der Nachteil dieses Ansatzes ist, dass die AUTOSAR- Software-Komponenten auf einem Kern fixiert sind und eine Core-spezifische Konfiguration erforderlich ist. Somit gehen die Vorteile der AUTOSAR RTE (Runtime Environment) verloren, z.b. einfaches Verschieben einer Software- Komponente. Zudem können Funktionalitäten zwischen den Kernen im Fall einer asymmetrischen Lastverteilung nicht einfach ausgetauscht werden. Daher kommt inzwischen vermehrt eine echte AUTOSAR-Multi-Core-Architektur zum Einsatz. Die AUTOSAR 4.0 Multicore - Architektur Bei dieser Variante verwaltet ein auf AUTOSAR 4.0 basierenden Multi-Core- Betriebssystem (Operating System, OS) die verschiedenen Kerne (Bild 2). Die Software-Komponenten werden OS- Elektronik automotive

2 Bild 1. Complex Driver Approach: AUTOSAR-Basis-Software und Software-Komponenten laufen auf einem einzelnen Kern. _0AVJI_Roither_EK14.pdf;S: 1;Format:(43.74 x mm);26. Jun :00:58 Applikationen zugeordnet, die den Prozessorkernen zugewiesen werden. Die AUTOSAR RTE ist verantwortlich für die Implementierung der Kommunikation zwischen den Kernen. Intra-Core- Kommunikation läuft über Makros, direkte Funktionsaufrufe oder Daten- Queues. Inter-Core-Kommunikation wird über den im Betriebssystem realisierten IOC (Inter-OS-Application Communicator) oder über den leistungsstärkeren, herstellerspezifischen Shared Memory Controller (SMC) abgewickelt. Die AUTOSAR 4.0 Multicore -Variante bietet dem Anwender die volle Multi-Core-Funktionalität mit einfacher Migration einer Software-Komponente von einem Prozessorkern zu einem anderen. Außerdem nutzt sie die Vorteile einer Runtime Environment (RTE) über alle Kerne. Allerdings stehen Software-Architekten und -Integratoren vor der Herausforderung, ein effizientes Mapping der Software-Komponenten auf den Prozessorkernen zu entwickeln. Die Komplexität des Mapping wird steigen beim momentanen Trend, immer mehr Software-Komponenten für z.b. Fahrerassistenzfunktionen auf weniger Steuergeräte mit mehreren Prozessorkernen zu verteilen. Daher bedarf es einer Tool-Unterstützung zu Entwicklung und Validierung des Multi-Core- Systems. Die folgenden Abschnitte zeigen einen solchen Tool-unterstützten Lösungsweg für eine AUTOSAR 4.0 Multicore -Architektur auf. Software-Komponenten-Mapping und Optimierung Bei der Zuweisung von Software-Komponenten zu Prozessorkernen (SWC- Mapping) muss eine leistungsstarke Verteilung gefunden werden. Dabei ist unter anderem zu berücksichtigen, dass die Inter-Core-Kommunikation im Vergleich zu Intra-Core-Kommunikation mehr Prozessorlaufzeit benötigt und daher minimiert werden sollte. Gleichzeitig wird versucht, die Prozessorauslastung gleichmäßig zu verteilen. Diese beiden Ziele stehen teilweise im Konflikt zueinander und müssen daher sorgfältig abgewogen werden. Für diese komplexe Aufgabe werden Optimierungs- Tools verwendet, die, basierend auf Timing-Informationen, das bestmögliche Mapping berechnen können. Die AUTOSAR-Methodologie sieht für diesen Anwendungsfall die Timing Extension vor, um das Zeitverhalten von einzelnen Operationen (SWC Runnable, Intra- und Inter-Core-Kommunikation oder die Laufzeit der Basis-Software- Funktionen) zu spezifizieren und eine Tool-basierte Auswertung und Optimierung zu ermöglichen. Da das Zeitverhalten a priori meist nicht bekannt ist, werden Traces benutzt, um eine Feedback-Schleife zum Zeitmodell zu erzeugen. Timing-Analyse des Systemmodells Um ein detailgetreues Timing-Modell der Software zu erhalten, müssen die Laufzeitinformationen gewonnen werden. Ausgangspunkt ist die durchgängige Beschreibung des Systems mittels eines AUTOSAR-Modells. Dieses enthält zu Beginn jedoch lediglich Informationen zur Architektur (Beschreibung der Software-Komponenten und Schnittstellen), nicht jedoch zum Zeitverhalten der Applikation. Das Zeitverhalten ist jedoch essenziell, um gerade bei Multi- Core-Anwendungen beispielsweise das Zugriffsverhalten auf gemeinsame Speicher zu analysieren und zu optimieren. Bei schlecht abgestimmten Abläufen kann es hier zu einer erheblichen Beeinflussung der Laufzeit kommen, wenn Bild 2. AUTOSAR 4.0 Multicore System: Ein Betriebssystem (OS) und eine RTE (Runtime Environment) sind über mehrere Kerne verteilt. 34 Elektronik automotive

3 durch benötigte Bandbreite gerade beim Tracing auf Runnable-Ebene enorm. Invasiver Trace mittels instrumentiertem Tracing: Beim instrumentierten Tracing werden Tracing-Informationen durch Code-Instrumentierung generiert und über eine frei wählbare Schnittstelle übertragen. Dies ist eine sehr flexible Lösung, die auch im Feld eingesetzt werden kann. Durch den zusätzlichen Code (In strumentierung) wird jedoch das Lauf- NI LabVIEW Platform Unendliche Möglichkeiten, eine Designplattform Datenerfassung und Signalverarbeitung Bild 3. Workflow zur Anreicherung des Systemmodells mit Timing-Informationen aus Trace-Daten. Messgerätesteuerung gleichzeitig auf geteilte Ressourcen wie Speicher oder Peripherie zugegriffen wird. Deshalb muss das Laufzeit- und Zugriffsverhalten der Applikation exakt bestimmt werden und zum Modell z.b. als AUTOSAR Timing Extension hinzugefügt werden. Um das Modell mit diesen Zeitinformationen anzureichern, gibt es verschiedene Lösungsoptionen. Bei vorhandenem Legacy Code können unter anderem durch statische Codeanalyse die Laufzeiten einzelner Funktionen abgeschätzt werden. Jedoch können auf diese Weise keine komplexeren Interaktionen mehrerer paralleler Tasks und deren gegenseitige Beeinflussung adäquat abgebildet werden. Die praktischste Lösung ist daher die Laufzeitmessung auf dem realen Zielsystem mittels Tracing. Tracing-Methoden Um Laufzeitinformationen aus dem Steuergerät zu ermitteln, werden zwei verschiedene Tracing-Methoden verwendet: Nicht-invasiver Trace mittels Hardware Tracing: Hierbei wird die Hardware-Tracing-Funktion spezieller Emulation Devices verwendet. Das reale Zeitverhalten wird durch diese Messung nicht beeinflusst. Jedoch sind die Datenmenge und die da- zeitverhalten beeinflusst. Wird die Instrumentierung bereits im verwendeten Betriebssystemkern integriert, kann im Gegensatz zur Instrumentierung auf Task-Ebene der Einfluss auf die Laufzeit gering gehalten werden (so etwa beim EB tresos Debug & Trace Tool). Workflow zur Anreicherung der Zeitinformationen Die so gewonnenen Timing-Informationen können nun in das AUTOSAR- Systemmodell integriert werden. Der Workflow zur Anreicherung der Zeitinformationen (Timing Extension) und die einzelnen Schritte zum Systemmodell sind in Bild 3 beispielhaft dargestellt. In diesem Anwendungsfall wurden die Multi-Core-Lösungen von Elektrobit (EB) und Timing Architects (TA) eingesetzt. Automatisierung von Prüfund Validierungssystemen Entwicklung von Regel-, Steuer-, und Überwachungssystemen Die Entwicklungsumgebung NI LabVIEW erleichtert Ihnen die Lösung von Problemen, steigert die Produktivität und fördert Innovationen. >> ni.com/labview-platform/d Elektronik automotive National Instruments, NI, ni.com und LabVIEW sind Marken der National Instruments Corporation.

4 Das auf diese Weise erstellte Systemmodell kann jetzt zur Analyse, beispielsweise zur Task-Interference-Analyse (Bild 4), verwendet werden. Die Abbildung zeigt, zu welcher Zeit Tasks aktiviert oder verdrängt werden oder Abhängigkeiten zueinander haben (roter Bereich). Nach erfolgter Analyse ist die Optimierung der Software die Hauptaufgabe, auf die im nächsten Abschnitt eingegangen wird. Optimierung des Systems Bild 4. Task-Interference-Analyse mit dem TA Simulator: Die Abbildung zeigt, zu welcher Zeit Tasks aktiviert oder verdrängt werden oder Abhängigkeiten zueinander haben (roter Bereich). EB tresos Studio ist ein AUTOSAR-Konfigurations-Tool, welches zur Codegenerierung der Basis-Software, des Betriebssystems und der RTE verwendet wird. Die TA Tool Suite besteht aus drei Modulen: Der TA Inspector bereitet der Laufzeitinformation aus Traces zu Analyse auf und kann ein Zeitmodell anhand des Trace erstellen. Der TA Simulator ermöglicht die Simulation eines Modells und bietet verschiedene Analysemöglichkeiten wie z.b. die Task-Interference-Analyse in Bild 4. Der TA Optimizer kann das vorhandene Modell anhand konfigurierbarer Parameter und Constraints optimieren und eine verbesserte Konfiguration erstellen. Folgende Arbeitsschritte sind zur Gewinnung eines optimierten System- Modells erforderlich (vgl. Bild 3): 1. Im AUTOSAR-Konfigurations-Tool EB tresos Studio wird die Multi-Core- Target-Applikation erstellt. 2. Das erzeugte Firmware Image wird auf das Target-System geflasht. 3. Zur Gewinnung des Trace wird das System unter realen Bedingungen stimuliert und der Trace durch ein Tracing Tool aufgezeichnet. _0D7IZ_Spirig_NEU SHEK 21.pdf;S: 1;Format:(45.00 x mm);23. Oct :55:19 Celsi Strip Thermoetikette registriert Maximalwerte durch Dauerschwärzung. Bereich von C Kostenloser Versand ab Bestellwert EUR 200 (verzollt, exkl. MwSt) GRATIS Musterset von celsi@spirig.com 4. Daraufhin wird der erstellte Trace in die Timing Architects Tool Suite importiert. 5. Bereits jetzt können Analysen und Laufzeit-Metrik-Berechnungen mittels des TA Inspector durchgeführt werden. 6. Durch das Importieren der AUTO- SAR-ECU-Beschreibung (Beschreibung der Software-Komponenten sowie AUTOSAR-Basis-Software-Beschreibung) in die TA Tool Suite sind nun weitere Analysen wie die Überprüfung von Requirements oder die Bestimmung von Event Chains möglich. 7. Im nächsten Schritt werden die gewonnen Laufzeiten für einzelne Tasks und Runnables mit dem aus AUTOSAR importierten Modell zusammengeführt. 8. Das mit Laufzeitinformationen angereicherte Modell kann nun mittels Simulation analysiert werden. 9. Die mit Laufzeitinformationen vervollständigte AUTOSAR-Systembeschreibung wird exportiert (AU- TOSAR-XML-Format). 10. Das auf diese Weise generierte Modell dient als Grundlage, um das System z.b. hinsichtlich des Timing- Verhaltens zu optimieren (siehe nächster Absatz Optimierung des Systems ). 11. Abschließend kann die optimierte Systembeschreibung wieder nach AUTOSAR exportiert werden und steht für den weiteren Entwicklungszyklus zur Verfügung. Um das durch die Laufzeitinformationen vervollständigte Systemmodell zu optimieren, stehen folgende Möglichkeiten der Adaption zur Verfügung: Mapping der Software-Komponenten auf Prozessorkerne mit dem Ziel, die laufzeitintensive Inter- Core-Kommunikation zu reduzieren. Zuweisung von Runnables zu Tasks, um ungünstige Kommunikationsmechanismen in der RTE-Generierung zu vermeiden. Hier gilt der Grundsatz, dass Runnables mit ähnlichen Triggerbedingungen wie z.b. RTE Timing Events gruppiert werden sollten, um weniger Tasks und Events im Betriebssystem verwalten zu müssen. Aufrufsequenz von Runnables anpassen. Task-Prioritäten und Eigenschaften modifizieren. Tasks mit kleiner Laufzeit können häufig als nicht unterbrechbar konfiguriert werden, damit weniger Scheduling Overhead im Betriebssystem erzeugt wird. Offset periodischer Tasks mit dem Ziel, ein zeitlich organisiertes Scheduling zu erhalten, um die Anzahl der Unterbrechungen zu reduzieren. Dabei wird das Modell hinsichtlich bestimmter Metriken, wie z.b. der Inter- Core-Kommunikationsrate, der Lastverteilung, der Antwortzeiten oder des Synchronisations-Overhead durch den TA Optimizer optimiert. Randbedingungen, wie Speicherpartitionierung in sicherheitsrelevanten Systemen, können durch Design-Restriktionen modelliert werden. Bild 5 zeigt die Ergebnisse einer Optimierung anhand eines Spider Chart (links) oder als Balkendiagramm. Somit kann der Integrator die Vor- und Nachteile verschiedener Konfigurationen vergleichen und anhand der Steuer- 36 Elektronik automotive

5 Bild 5. Optimierungsergebnisse: Vergleich verschiedener Optimierungszyklen als Spider Chart (links) und Vergleich relativ zur Initialkonfiguration als Balkendiagram (rechts). geräte-anforderungen die passende Optimierung und Verifikation von Multi-Core-Steuergeräten dargestellt wer- auswählen. Ist eine für den Anwendungsfall optimale Lösung gefunden, können die durch Daten entweder intern oder über AUden, bei der alle involvierten Tools die den TA Optimizer vorgenommenen Änderungen wieder zurück in das ursprüngschen. Hierbei wurde insbesondere auf TOSAR-definierte XML-Files austauliche AUTOSAR-Modell exportiert werden. Dieses verbesserte AUTOSAR-Modell TOSAR-Standards Wert gelegt. eine identische Interpretation des AUdient nun als Basis für die Generierung Die offene Tracing-Schnittstelle ermöglicht die Verwendung unterschied- der optimierten Target-Applikation mittels EB tresos Studio. In diesem Closed- licher Tracing-Lösungen. Somit können Loop-Ansatz kann darauffolgend das die Simulation und Optimierung, AUoptimierte System durch Trace-Aufzeichnung und Trace-Auswertung mittels TA tierungen und herstellerspezifische TOSAR-Basis-Software/RTE-Implemen- Inspector verifiziert werden. OS-Timings (z.b. Taskwechselzeiten) sowie Basis-Software-Effekte berücksichtigt werden. Da immer mehr Funk- Anwendungsmöglichkeiten tionalitäten auf Steuergeräten zusammengefasst werden und dadurch Multi- Durch die Zusammenarbeit von Elektrobit und Timing-Architects kann eine Core-Systeme im Automobil Einzug nahtlose Tool-Kette zur Simulation, halten, hilft die nahtlose Tool-Kette, das _0D450_MAXWELL_EKAUTO_11.pdf;S: 1;Format:( x mm);09. Oct :12:31 Zeitverhalten zu verstehen und zu optimieren und dadurch eine bessere Ressourcenausnutzung des Prozessors zu erreichen. Gerade in sicherheitskritischen Anwendungen muss die Dynamik in der Software verstanden werden, um das Systemverhalten zu erklären und zu analysieren und den Anforderungen der funktionalen Sicherheit gerecht zu werden. Durch die Feedback-Schleife werden Fehler im dynamischen Verhalten des Steuergeräts früh erkannt und behoben. Dies führt letztendlich zu einer effizienteren Produktentwicklung und einem hochwertigeren und zuverlässigeren Software-System. ku Dipl.-Ing. Rudolf Grave studierte Elektrotechnik an der TU Hamburg-Harburg. Seit 2005 arbeitet er bei Elektrobit Automotive und betreut AUTO- SAR-Projekte. Der Schwerpunkt liegt dabei auf den Themengebieten Multicore und funktionale Sicherheit. M.Eng., Dipl.-Ing. (FH) Stefan Krämer studierte Elektro- und Mikrosystemtechnik an der Hochschule Regensburg. Seit Juni 2012 ist er bei der Timing-Architects Embedded Systems GmbH tätig. Er entwickelte am Simulations-Kern der TA Tool Suite und unterstützt heute Kundenprojekte bei der Umstellung auf Multicore-Architekturen. Elektronik automotive