ELEKTRONIK matische Darstellung des ange reicherten Software- © Carl Hanser Verlag GmbH & Co.KG, München, www.hanser-automotive.de; Nicht zur Verfügung in Intranet- u.Internet-Angeboten oder elektron. Verteilern Bild 1: Sche Entwicklungs- Ressourcen-Management für zukünftige Fahrzeugelektronik Künftig wird es viele Steuergeräte geben, die Software-Anteile aus mehreren Fahrzeugfunktionen enthalten, die von diversen Lieferanten entwickelt werden. Damit wird der bislang erfolgreiche Ansatz, bei denen es immer Experten gab, die „von Natur aus“ einen Gesamtüberblick über das Steuergerät hatten, kaum mehr umsetzbar sein, vor allem für die querschneidenden Aspekte wie Safety, Security und Timing. Vielmehr ist der Software-Integrationsverantwortliche künftig darauf angewiesen sowohl auf eine geeignete Informationsbasis zugreifen zu können, in der die relevanten Anforderungen zusammenlaufen, als auch daraus systematisch Entwurfsentscheidungen abzuleiten [1]. In diesem Artikel befassen sich die Autoren mit Ressourcen und Echtzeit-Aspekten. E chtzeitanforderungen auf Systemebene umfassen vor allem physikalische Größen wie Kräfte, Drehmomente, Drücke, Temperaturen oder Winkelgeschwindigkeiten, die je nach Funktion spezifischen zeitlichen Verläu- 28 HANSER automotive 10 / 2015 fen folgen müssen. Die Software muss nun so schnell arbeiten, dass diese Anforderungen eingehalten werden, was vor allem von den verfügbaren und optimal genutzten Ressourcen abhängt, allen voran die CPU-Kapazität, möglicher- weise verteilt auf unterschiedliche Kerne in einem Multicoresystem. Eine systematische Ressourcenplanung umfasst drei Phasen (siehe Bild 1, aus [2]): WW Erstellen eines Timing-Referenz modells als Planungsgrundlage, © Carl Hanser Verlag, München Bilder: Symtavision Prozesses [2]. ELEKTRONIK durch Messung und Modell- Updates, WW Ressourcen-Prognose mittels Simulation und Analyse. Ressourcenschätzung und Timing-Referenzmodell Zu Projektbeginn wird ein grobes Ressourcenmodell erstellt, das die vorhandene CPU-Kapazität auf die Funktionsgruppen aufteilt (blauer Anteil in Bild 1). Der Software-Integrationsverantwortliche kann zunächst die 100% verfügbare CPU-Zeit auf Applikationssoftware (ASW), Basissoftware (BSW), Ressourcen-Freischnitte für sonstige Software (z. B. eine Kundenfunktion) sowie Reserven aufteilen. Zusammen mit den Zykluszeiten der Module entsteht ein erstes Timing-Modell, das Tasks (optional auch Runnables) mit ihren Events und erwarteten Ausführungszeiten enthält; es gilt: CPU-Auslastung = Ausführungszeit/Zykluszeit. Dieses TimingModell kann dann gegen die bekannten Timing-Anforderungen abgeglichen werden, um größere Diskrepanzen vorab zu identifizieren. Messung und Soll-Ist Abgleich Im Verlauf der Software-Entwicklung werden dann zu geeigneten Zeitpunkten die tatsächlichen Ressourcen-Verbräuche und Zeitverhalten gemessen. Hierzu gibt es mittels der existierenden Prüfplätze verschiedene Möglichkeiten: WW Unit-Tests/PiL (Processor-in-theLoop)-Tests: Durch eine Zeitmessung des Testvorgangs kann die Netto-Ausführungszeit der Einzelfunktion bestimmt werden. WW Integrationstest mit Trace-Erfassung: Durch Aufnahme von Scheduling-Events im Gesamtsystem können Netto- und auch Brutto-Laufzeiten der Tasks sowie weitere TimingEigenschaften erfasst werden. Entweder durch Code-Instrumentierung (Aufnahme von Zeitstempeln im internen RAM zum späteren Auslesen per Debugger oder XCP), mit speziellen „Emulation Device“ per Nexus-Class-2-Trace oder künftig mit optimierten CPU-Schnittstellen www.hanser-automotive.de für Tracing [3]. Trace-Analysewerkzeuge verarbeiten die aufgenommenen Traces und extrahieren daraus die relevanten Timing-Parameter. So kann das tatsächliche Laufzeitverhalten der Implementierung („Ist“) kontinuierlich erfasst und unmittelbar mit dem Referenz-Timing-Modell („Soll“) verglichen werden; siehe grüne Bereiche in Bild 2. Benötigt die Implementierung weniger Ressourcen als erwartet, so hat man Ressourcen „gespart“. Überschreitungen der geplanten Ausführungszeiten führen zur Nachbesserung des Referenzmodells und Erhöhung des Budgets für diese Teilfunktion. Zudem können gezielte Maßnahmen zur Optimierung bzw. Fehlerbehebung ausgewählt und im nächsten Release umgesetzt werden (siehe grüne Anteile in Bild 1). Ressourcen-Prognose mittels Simulation und Analyse Ausgehend von dem Timing-Referenzmodell sind auch Prognosen der zukünftigen Auslastung möglich. Das ist vor allem für die Planung von größeren Änderungen relevant, z. B. Änderungen am Schedule, Integration einer Kundenfunktion, Umstieg auf einen Multi-CoreProzessor. Nach dem klassischen Vorgehen würden die Änderungen zunächst in der Steuergerätesoftware umgesetzt, eventuelle Ressourcenengpässe beim nächsten Integrationstest erkannt und erst in den darauffolgenden Release-Zyklen optimiert (oder zurückgenommen). Aufgrund der damit verbundenen hohen Kosten ist es wünschenswert, diese Auswirkungen frühzeitig vorherzusagen und zu optimieren und damit die Zahl der Entwicklungszyklen klein zu halten. Für diese Vorhersage bietet das Timing-Analysewerkzeug SymTA/S Möglichkeiten zur Scheduling-Simulation und Worst-Case-Scheduling-Analyse. Für den Prozess vorteilhaft liegt das benötigte Timing-Referenzmodell bereits vor, mit Laufzeiten, Schedule, Zykluszeiten und Prioritäten. Die wichtigsten Anwendungsfälle sind (siehe rote Bereiche in Bild 1): WW Plausibilisierung des initialen Timing-Referenz-Modells, © Carl Hanser Verlag GmbH & Co.KG, München, www.hanser-automotive.de; Nicht zur Verfügung in Intranet- u.Internet-Angeboten oder elektron. Verteilern WW Kontinuierlicher Soll-Ist-Vergleich 21.-23. Oktober 2015 Technologie- und Anwenderkongress Jetzt anmelden: ni.com/vip » ©2014 National Instruments. All rights reserved. National Instruments, NI, and ni.com are trademarks of National Instruments. Other product and company names listed are trademarks or trade names of their respective companies. 22438 ELEKTRONIK © Carl Hanser Verlag GmbH & Co.KG, München, www.hanser-automotive.de; Nicht zur Verfügung in Intranet- u.Internet-Angeboten oder elektron. Verteilern Prognostizieren zukünftiger RessourcenAuslastungen und Schedule-Verhalten bei Architekturänderungen. Diese können leicht im Timing-Modell umgesetzt und simuliert werden, und zwar zu einem Zeitpunkt, zu dem das (zukünftige) System zum Testen noch gar nicht vorliegt. So lassen sich die Ressourcenauslastung und das Scheduling verschiedener Optionen zunächst im Modell simulieren, um dann daraus die optimale Lösung auswählen, mit einer deutlichen Reduzierung des Integra tionsrisikos. Die Gantt-Diagramme in Bild 3 zeigen den Vergleich eines gemessenen Traces mit einem simulierten Szenario [2]. Derart detaillierte Analysen sind sonst nur durch Tests möglich. Die Simulation liefert die Ergebnisse vorab, und zwar in derselben Form wie die Messungen. Bild 2: Soll-Ist-Vergleich zwischen Timing-Referenzmodell (Soll) und tatsächlich gemessenem Laufzeitverhalten (Ist). WW Exploration und Optimierung von Architektur-Änderungen, WW Zusätzliche Absicherung von Timing-Corner-Cases. Plausibilisierung des initialen Timing-ReferenzModells Zusätzliche Absicherung von Timing Corner-Cases samt leicht verständlich und können mit den schon bekannten Mitteln betrachtet, ausgewertet und mit den Anforderungen verglichen werden. Damit wird vor allem die grundsätzliche Machbarkeit des gewähltem Schedule, der TaskAufteilung und der Ressourcen-Planung überprüfbar. Schon vor den ersten Tests und Mes- Exploration und sungen kann das Timing-Referenz- Optimierung von Modell simuliert werden; quasi als virtu- Architektur-Änderungen elle Integration. Die Simulationsergebnisse liegen wie im Test als Traces vor, Der zweite (und für die SW-Entwickso sind Vorgehen und Ergebnisse insge lung wichtigste) Anwendungsfall ist das Bild 3: Vergleich des gemessenes Zeitverhaltens (oben) mit dem simulierten Zeitverhalten desselben Systems mit einer zusätz lichen Kunden funktion (un Der beschriebene Vorhersage-Ansatz kann auch dazu genutzt werden, sogenannter Worst-Casemittels Scheduling-Analysen die Testabdeckung in Bezug auf das Laufzeitverhalten und den Ressourcenverbrauch nachträglich virtuell zu erhöhen. Solche Worst-Case-Scheduling-Analysen berechnen zusätzliche realistische Randfälle, die nur schwer testbar sind und werden insbesondere für sicherheitsrelevante Funktionen, z. B. im Bereich der Fahrwerksregelungen und Lenkung, schon seit längerer Zeit eingesetzt. ten) [2]. 30 HANSER automotive 10 / 2015 © Carl Hanser Verlag, München ELEKTRONIK © Carl Hanser Verlag GmbH & Co.KG, München, www.hanser-automotive.de; Nicht zur Verfügung in Intranet- u.Internet-Angeboten oder elektron. Verteilern WW b) Umstieg auf Multi-Core-System Bild 4: Potenzialanalyse durch Ressourcenvorhersage über die nächsten drei mit zusätzlichem Rechenkern (erhöht Hardware und Migrationskosten), und WW c) Festhalten an der Single-Core- Lösung, aber Optimierung der Software und der Software-Architektur, vor allem durch Ausnutzen zusätz licher Freiheitsgrade (z. B. Schedulingund Compiler-Anpassung), die im Rahmen der System-Timing- Anforderungen existieren. Die drei Optionen wurden ausführlich simuliert, vor allem die Scheduling- und Laufzeitoptimierungen nach Option c). Bild 4 zeigt die qualitativen Ergebnisse der Exploration. Die bestehende Plattform nach a) kann für die nächsten Releases weitergenutzt werden. Parallel sollten Architekturoptimierungen (vor allem für die Module ASW 2 und BSW) nach c) begonnen werden, bevor der Ressourcenbedarf in Release n+3 zu stark steigt. Ein Multi-Core-Umstieg nach b) ist aktuell nicht notwendig, aber für ein Folgeprojekt nochmals im Detail zu untersuchen. W (oe) Releasezyklen für drei Architektur-Alternativen. »» www.symtavision.com Fazit System entwicklung ist ein nächster Schritt, der bei Volkswagen und Audi Die Budgetierung und Messung von derzeit im Konzern-Strategieprojekt Laufzeitdaten inklusive Soll-Ist- „PETRA – Process Enhancements for Vergleich sind elementare Schritte für Timing Requirements and Analysis“ eine solide Ressourcen-Überwachung. vorangetrieben wird. Zudem bilden sie den idealen Startpunkt für eine systematische Ressour- Case Study cen-Prognose, vor allem bei der Kon4 zeigt die beispielhafte Zusamzeption und Optimierung von kosten Bild intensiven architekturellen Änderungen menfassung einer umfangreicheren Pound erleichtern den Einsatz von tenzialanalyse einer bestehenden Plattentsprechenden Timing-Analyse-Werk- form durch Beantwortung zweier Kernzeugen. Der Nutzen für die Steuer fragen: Wie stark wird der Ressourcengeräteentwicklung liegt vor allem in der verbrauch innerhalb der nächsten SoftReduzierung des Integrationsrisikos ware-Releases noch steigen und aufgrund von Ressourcenengpässen. welche Maßnahmen müssen ergriffen Gleichzeitig steigt das Verständnis für werden, um Engpässen kostenoptidie internen, oft komplexen Abläufe im miert entgegenzuwirken? Dazu wurden zunächst die zusätz lichen Laufzeiten Steuergerät. Die Autoren haben gute Erfahrun- der noch geplanten Funktionshübe und gen mit dieser Art des Ressourcen- Software-Updates abgeschätzt und in Management gemacht und empfehlen das Timing-Modell virtuell integriert. die genannten Methoden jedem Steuer Dann wurden verschiedene Architekturgeräteprojektleiter und Software Varianten als Timing-Modell abgeleitet: integrator, am besten kontinuierlich und WW a) unveränderte Nutzung der bestehenden Single-Core-Lösung (Idealparallel zum Zeitstrahl der SoftwareSzenario, aber eventuell nicht durchEntwicklung. Die engere Einbeziehung führbar), von Echtzeitanforderungen aus der www.hanser-automotive.de Referenzen: [1] A. Schulze, S. Richter, T. Flämig, K. Schmidt, D. Marx, H. Christlbauer, K. Richter, S. Schliecker, C. Ficek, „Ressourcen-Management-Prozesse für zukünftige Fahrzeug-Elektronik“, VDI C ongress „Electronics in the Vehicle – ELIV“, 2015, Baden-Baden, Germany [2] “Resource 2015 Planning in ECU Software Development”, White Paper, Symtavision, 2015 [3]K. Schmidt, J. Harnisch, D. Marx, A. Mayer, „Timing Analysis and Tracing Concepts for ECU Development“, SAE Technical Paper 2014-01-0190, 2014, doi:10.4271/2014-010190. Dr. Karsten Schmidt arbeitet bei der Audi Electronics Venture GmbH in Gaimersheim. Dr. Andreas Schulze arbeitet bei der Volkswagen AG in Braunschweig. Dr. Kai Richter ist Chief Technical Officer bei der Symtavision GmbH in Braunschweig. HANSER automotive 10 / 2015 31