Autor: Peter Gliwa, GLIWA GmbH embedded systems<\/p>\n
Die Ressource „Rechenzeit“ wird in vielen Projekten im Verlauf der Entwicklung knapp. Im Folgenden sollen einige praktische Ans\u00e4tze beleuchtet werden, um in solchen Situationen Steuerger\u00e4tesoftware hinsichtlich der Laufzeit zu optimieren. Zum anderen werden Ma\u00dfnahmen angesprochen, um fr\u00fchzeitig beim Design, bei der Konfiguration und Implementierung Laufzeitprobleme zu verhindern.<\/strong><\/p>\n In den letzten 20 Jahren hat sich mit Blick auf das Timing bei der Entwicklung von Steuerger\u00e4tesoftware viel getan. Wurde das Timing fr\u00fcher meist nur dann explizit betrachtet, wenn es Probleme verursachte, wird dem Timing heute oft systematisch und fr\u00fchzeitig Aufmerksamkeit zuteil. Die Betriebssystemkonfiguration wird beispielsweise nicht einfach vom Vorg\u00e4ngerprojekt \u00fcbernommen und hier und da angepasst. Stattdessen finden eingehende \u00dcberlegungen statt, welche Anforderungen an das Timing existieren und wie diese mit einer geeigneten Betriebssystemkonfiguration, Verteilung von Tasks auf die verschiedenen Kerne eines Multicoreprozessors etc. begegnet werden kann.<\/p>\n Immer \u00f6fter kommen dabei Techniken wie die Schedulingsimulation oder Schedulinganalyse zum Einsatz. Dennoch kommt praktisch jedes Projekt an einen Punkt, bei dem das Verhalten des\u00a0realen<\/em>\u00a0Systems mitunter gravierend vom\u00a0erwarteten<\/em>\u00a0Verhalten \u2013 dem simulierten oder modellierten Timing \u2013 abweicht. Hier hilft nur eine Analyse der realen Systems, falls erforderlich in der realen Umgebung, also im Fahrzeug.<\/p>\n Bevor wir uns den konkreten Timinganalysetechniken zuwenden, soll verdeutlicht werden, dass bei der Timinganalyse grunds\u00e4tzlich zwei Fragen vorangestellt werden sollten. Erstens: in welcher Phase befindet sich das Projekt? M\u00f6gliche Phasen sind „fr\u00fch“ oder „sp\u00e4t“ beziehungsweise „Design“, \u201eImplementierung\u201c oder „Verifikation“, um es mit den Begriffen des V-Modells zu sagen. Zweitens: Auf welcher Abstraktionsebene soll Timinganalyse betrieben werden? M\u00f6glich Ebenen sind „Codeebene“, „Schedulingebene“ oder „Netzwerkebene“. Es l\u00e4sst sich feststellen, dass sich jede Auseinandersetzung mit einem konkreten Timingaspekt in einem Koordinatensystem mit den Achsen „Phase\/Projektlaufzeit“ und „Ebene“ verorten l\u00e4sst. Abbildung\u00a01 (s.\u00a0PDF<\/a>) stellt dies anhand von V-Modellen auf der jeweiligen Ebene dar.<\/p>\n Die gleichen Ebenen finden sich in Abbildung\u00a02 (s.\u00a0PDF<\/a>) unterhalb der Granularit\u00e4tsachse wieder. Dar\u00fcber sind die verschiedenen Timinganalysetechniken aufgetragen; es besteht eine gewisse Zuordnung anhand der horizontalen Position. Die „statische Codeanalyse“ beispielsweise findet auf der Codeebene statt und deckt den Bereich von „Opcode States“ bis hin zu „TASK\/ISR“ ab.<\/p>\n Abbildung\u00a03 (s.\u00a0PDF<\/a>) erg\u00e4nzt die \u00dcbersicht um die Aspekte „Art der Timinganalyse“ und die bereits angesprochene (Projekt-) Phase.<\/p>\n Eine kurze Beschreibung der Funktionsweise der verschiedenen Analysetechniken findet sich auf dem Timingposter [1], dem auch die bisherigen Abbildungen entnommen sind.<\/p>\n Die folgende Liste zeigt Anwendungsf\u00e4lle (Use Cases) f\u00fcr die verschiedenen Timinganalysetechniken auf.<\/p>\n Eine komplette Liste aller Laufzeitoptimierungsans\u00e4tze zu erstellen ist unm\u00f6glich. Daher sollen im Folgenden lediglich ein paar grunds\u00e4tzliche Aspekte behandelt und exemplarisch einige konkrete Ma\u00dfnahmen vorgestellt werden.<\/p>\n Als allgemein g\u00fcltige Regel l\u00e4sst sich festhalten, dass Laufzeitoptimierung immer „top-down“ erfolgen sollte, also von den oberen zu den unteren Ebenen hin. W\u00fcrde man direkt mit der Codeoptimierung beginnen, w\u00fcsste man nicht, ob der betreffende Code \u00fcberhaupt zu einem Zeitpunkt ausgef\u00fchrt wird, an dem das Timing kritisch ist.<\/p>\n Besser ist es, zun\u00e4chst auf der Schedulingebene ein\u00a0gutes Verst\u00e4ndnis<\/em>\u00a0der aktuellen Situation herbeizuf\u00fchren, Optimierungen auf dieser Ebene durchzuf\u00fchren und anschlie\u00dfend mittels Codeoptimierung die verbleibenden „Hotspots“ anzugehen.<\/p>\n Die Bedeutung des\u00a0guten Verst\u00e4ndnisses<\/em>\u00a0wird leider oft untersch\u00e4tzt. In vielen Projekten konnte ich beobachten, wie Integratoren beim Blick auf den ersten heruntergeladenen Trace mit einer gewissen Fassungslosigkeit feststellen mussten, dass sich das System ganz anders verh\u00e4lt, als gedacht und zuvor simuliert.<\/p>\n Die oberste Regel f\u00fcr Laufzeitoptimierung auf der Schedulingebene wird leider oft missachtet, obwohl sie denkbar einfach ist:\u00a0Keep it simple!<\/em><\/p>\n Konkret hei\u00dft das beispielsweise, dass die Betriebssystemkonfiguration m\u00f6glichst einfach gehalten wird. Am besten sollte BCC1 (Basic Conformance Class ohne Mehrfachaktivierungen) zum Einsatz kommen. Leider legen die meisten AUTOSAR RTE-Generatoren die Verwendung von ECC nahe, indem sie eine nicht terminierende ECC-Task anlegen und darin eine zweite Ebene des Schedulings einf\u00fchren: Die RTE-Runnables werden in dieser ECC-Task mittels Events getriggert. Die damit verbundene Komplexit\u00e4t wird von den meisten Projektverantwortlichen nicht mehr \u00fcberblickt, und die Analyse von Timingproblemen wird deutlich erschwert.<\/p>\n Ganz nebenbei l\u00e4sst sich mit der Verwendung von BCC der Stackbedarf signifikant verringern.<\/p>\n Eine weitere Ma\u00dfnahme, um typische Echtzeitprobleme zu vermeiden, den Laufzeitbedarf und gleichzeitig den Stackbedarf weiter zu minimieren ist die Verwendung von kooperativem Multitasking. „Kooperativ“ hei\u00dft hier, dass Taskwechsel nur zu bestimmten Zeitpunkten erfolgen d\u00fcrfen \u2013 sinnvollerweise dann, wenn gerade kein Runnable l\u00e4uft. Die RTE oder vergleichbare Mechanismen stellen dann fest, dass zur Sicherung der Datenkonsistenz keine Kopien der Daten notwendig sind. Ergebnis: Einsparung bei RAM und Laufzeit. Es leuchtet ein, dass dar\u00fcber hinaus der Stackbedarf typischerweise drastisch reduziert wird, da eine Verschachtelung von Runnables nicht mehr m\u00f6glich ist.<\/p>\n Abbildung\u00a04 (s.\u00a0PDF<\/a>) zeigt den Trace eines sehr positiven Beispiels f\u00fcr ein gelungenes Timingdesign: die Aktivlenkung des BMW X5 (e70). Das System ist \u2013 je nach Zustand \u2013 bis \u00fcber 93% ausgelastet, aber niemals \u00fcberlastet. Durch die Optimierungsma\u00dfnahmen konnte ein g\u00fcnstigerer, weniger leistungsf\u00e4higer Prozessor als in der Vorg\u00e4ngergeneration zum Einsatz kommen \u2013 und das bei zus\u00e4tzlicher Funktionalit\u00e4t.<\/p>\n Als Beispiel f\u00fcr die Laufzeitoptimierung auf der Codeebene soll an dieser Stelle die wohlbekannte Funktion memcpy optimiert werden. memcpy kopiert eine definierte Anzahl von Bytes von einem Speicherbereich in einen anderen. Eine Standardimplementierung ist in Abbildung\u00a05 (s.\u00a0PDF<\/a>) ersichtlich.<\/p>\n Wird diese Funktion zum Kopieren von einem Kibibyte (1024 Bytes) auf einem Infineon AURIX TC275 mit 200 MHz Taktfrequenz und unter Verwendung eines TASKING-Compilers verwendet, so ergibt sich f\u00fcr die Default Memory Locations eine minimale CET (core execution time) von 114,395\u00b5s oder\u00a0111,7ns pro Byte<\/strong>. Dies ist der Ausgangspunkt f\u00fcr die nun folgenden Optimierungen. Der generierte Assemblercode ist in Abbildung\u00a06 (s.\u00a0PDF<\/a>) zu sehen.<\/p>\n Im ersten Schritt sollen nun andere Speicherorte verwendet werden. Abbildung\u00a07 (s.\u00a0PDF<\/a>) zeigt einen Auszug aus dem AURIX-Handbuch, dass die Zugriffsdauer auf verschiedene Speicher in Taktzyklen angibt. Ein entscheidender Multicoreaspekt sei an dieser Stelle schon mal erw\u00e4hnt: Die in der Tabelle angegebenen Zahlen gelten f\u00fcr den Fall, dass am Memory-Interface kein Zugriffskonflikt auftritt, also nicht etwas ein anderer Kern gerade mit h\u00f6herer Priorit\u00e4t auf den Speicherbereich zugreift. Im Falle eines Konfliktes kann die Verz\u00f6gerung wesentlich gr\u00f6\u00dfer sein.<\/p>\n Doch auch ohne Konflikte ist der Unterschied zwischen „schnellen“ und „langsamen“ Speichern erheblich. Die Default Memory Locations des Ausgangsstands waren: Cached Flash0 f\u00fcr den Code, LMU RAM f\u00fcr das Ziel der Kopie und Cached Flash0 f\u00fcr die Quelle.<\/p>\n Wird das Ziel nun statt im LMU RAM im Local DSPR0 abgelegt, verringert sich die Kopiergeschwindigkeit auf\u00a0100,6ns pro Byte<\/strong>.<\/p>\n Im n\u00e4chsten Schritt wird dem Compiler per #pragma oder per Compileroption \u2013t0 vorgegeben, bei der Kompilierung m\u00f6glichst schnellen Code zu erzeugen. Der Compiler generiert nun anderen Assemblercode, siehe Abbildung\u00a08 (s.\u00a0PDF<\/a>), unter der Verwendung von prinzipiell erstrebenswerten „post-increment“ Speicherzugriffen und unter der Verwendung von speziellen Befehlen des AURIX Befehlssatzes, in diesem Fall der loop Anweisung.<\/p>\n Der so erzeugte Code l\u00e4uft wesentlich schneller und ben\u00f6tigt nur noch\u00a059,6ns pro Byte<\/strong>.<\/p>\n Abschlie\u00dfend wird der Code von Hand optimiert. In den meisten F\u00e4llen ist dies auf der C-Code-Ebene m\u00f6glich, wobei permanent a) der erzeugte Assemblercode \u00fcberpr\u00fcft werden und b) mittels Messung die tats\u00e4chliche Laufzeit ermittelt werden muss. Im Bereich der Codeoptimierung ist die Verlockung gro\u00df, sich Annahmen und Vermutungen hinzugeben. Selbst die Besten der Besten erleben \u00dcberraschungen und m\u00fcssen sich eingestehen, dass das erwartete Laufzeitverhalten eines Optimierungsansatzes weit entfernt liegt vom realen Verhalten und nur die Messung am realen System dies offenbart.<\/p>\n Vor der eigentlichen manuellen Optimierung ein paar \u00dcberlegungen zu memcpy. Laut Spezifikation kann sie Daten mit der Granularit\u00e4t von einem Byte kopieren. Der AURIX kann als 32bit-Prozessor sehr effizient mit vier Byte gro\u00dfen W\u00f6rtern umgehen. Analysiert man die Datenobjekte einer typischen Anwendung im Automobilbereich, stellt man fest, dass die Gr\u00f6\u00dfe der meisten Datenobjekte einem ganzzahligen Vielfachen von vier entspricht und sie auch vier Byte aligned sind \u2013 also eine Speicheradresse aufweisen, die ebenfalls ein ganzzahliges Vielfaches von vier ist. Die in Abbildung\u00a09 (s.\u00a0PDF<\/a>) dargestellte Implementierung der entscheidenden Bereiche von memcpy macht sich diese Erkenntnisse zu Nutzen und \u00fcberpr\u00fcft, ob Quelle und Ziel vier Byte aligned sind und ob auch die Anzahl der zu kopierenden Bytes ein ganzzahliges Vielfaches von vier ist. Ist dies der Fall, werden immer vier Bytes in einem einzelnen Schleifendurchlauf kopiert.<\/p>\n Diese manuelle Optimierung ergibt zusammen mit allen zuvor genannten Optimierungen einen Laufzeitbedarf von\u00a014,7ns pro Byte<\/strong>. Immerhin eine Laufzeitersparnis von rund\u00a087%<\/strong>\u00a0gegen\u00fcber der Ausgangsversion.<\/p>\n F\u00fcr Multicoresysteme hat es sich bew\u00e4hrt, die Funktionalit\u00e4t so aufzuteilen, dass intensive Berechnungen und die Bearbeitung vieler Interrupts auf verschiedene Kerne aufgeteilt werden. Als Folge werden bei den komplexen Berechnungen Pipeline und Cache besser genutzt, was den Durchsatz erh\u00f6ht.<\/p>\n „Busy-Spinning“ also das Warten eines Kerns auf die Freigabe einer Ressource auf einem anderen Kern, sollte wo\u00a0 immer m\u00f6glich konzeptionell vermieden werden. In vielen F\u00e4llen l\u00e4sst sich der Einsatz von Spin-Locks durch geeignetes Design der Software komplett vermeiden. Bei der Portierung von Singlecore-Software auf Multicore ist das blinde Suchen\/Ersetzen von DisableInterrupts()\/EnableInterrupts() mit GetSpinlock()\/ ReleaseSpinlock() eine schlechte Idee. Der beste Mechanismus zum Schutz von Daten ist der, den man nicht braucht.<\/p>\n Laufzeitoptimierung ist komplex und vielschichtig. Sie kann und sollte auf verschiedenen Ebenen stattfinden: auf der Schedulingebene und auf der Codeebene – und zwar in dieser Reihenfolge, um zu verhindern, dass (Codeoptimierungs-) Aufwand betrieben wird, der die Gesamtsituation gar nicht verbessert.<\/p>\n Voraussetzung f\u00fcr eine zielgerichtete Analyse und Optimierung ist die Kenntnis der verschiedenen Analysetechniken. Nur so kann man f\u00fcr den jeweiligen Anwendungsfall das richtige Werkzeug bem\u00fchen.<\/p>\n Der wichtigste erste Schritt, eine existierende Anwendung auf dem Weg zu einer effizienten und sicheren Software zu bringen, ist das Verst\u00e4ndnis dar\u00fcber, wie sich das System tats\u00e4chlich verh\u00e4lt. Vermutungen und Annahmen sind hier fehl am Platz; der Einblick und die Analyse des realen Systems unter realen Bedingungen (also auch im Fahrzeug) sind entscheidend.<\/p>\n Seit einigen Jahren machen sogenannte C-to-C Compiler von sich reden, die gegebenen C-Code in parallelisierbaren C-Code \u00fcbersetzen sollen. Ich bin diesem Ansatz gegen\u00fcber skeptisch. Meine Vermutung (oder soll ich sagen: „Hoffnung“?) geht eher in die Richtung, dass eine bessere Ausnutzung von Multicore dadurch erzielt werden wird, dass die Codegeneratoren grunds\u00e4tzlich anders arbeiten werden. Zuk\u00fcnftige Generatoren werden es erlauben, aus einem generischen Modell („generisch“ im Sinne von nicht auf Singlecore oder Multicore festgelegt) entweder Code f\u00fcr Singlecore (bzw. Single-thread) oder aber gut parallelisierbaren Code f\u00fcr Multicore zu erzeugen.<\/p>\n [1]\u00a0Timingposter, Peter Gliwa, Februar 2013<\/a><\/p>\n Seit der Gr\u00fcndung 2003 steht Peter Gliwa als gesch\u00e4ftsf\u00fchrender Gesellschafter an der Spitze von GLIWA. \u00dcber viele Jahre hinweg entwickelte er die Timingsuite T1 und ber\u00e4t heute international Kunden in Timingfragen und bei Themen rund um Echtzeitbetriebssysteme. Zuvor war er bei ETAS zun\u00e4chst Entwickler, danach Produktmanager des Echtzeitbetriebssystems ERCOSEK<\/sup>. Zwischen 2001 und 2006 war er dar\u00fcber hinaus als Dozent f\u00fcr das Fach „Mikrocomputertechnik“ t\u00e4tig. Peter Gliwa hat Elektrotechnik an der Berufsakademie Stuttgart studiert.<\/p>\n Internet:\u00a0https:\/\/gliwa.com Beitrag als PDF-Datei downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Embedded- und Echtzeit-Softwareentwicklung.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Embedded- und Echtzeit-Softwareentwicklung steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nLaufzeitanalyse: Welche Technik f\u00fcr welche Situation?<\/h2>\n
\n
\n
\nIndirekte Funktionsaufrufe und Schleifenobergrenzen k\u00f6nnen unter Umst\u00e4nden nicht aufgel\u00f6st und m\u00fcssen manuell „annotiert“ (von Hand erg\u00e4nzt) werden, was fehleranf\u00e4llig ist.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n
\n
\n
\n
\n
\n
\nMan unterscheidet Hardware-basiertes Tracing und Software-basiertes Tracing. Ersteres kann ohne Modifikation der Software auskommen, f\u00fcr letzteres wird die Software instrumentiert, was die Verwendung der serienidentischen Hardware im Fahrzeug erlaubt.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n
\n
\n
\n
Laufzeitoptimierung<\/h2>\n
Laufzeitoptimierung auf der RTOS (Scheduling-) Ebene<\/h2>\n
Laufzeitoptimierung auf der Codeebene<\/h2>\n
Multicore-spezifische Aspekte<\/strong><\/h2>\n
Zusammenfassung, Ausblick<\/h2>\n
Literatur- und Quellenverzeichnis<\/h2>\n
Autor<\/h2>\n
\n<\/a>Email:\u00a0 \u00a0peter.gliwa@gliwa.com<\/p>\n
\nEchtzeit – MicroConsult Trainings & Coachings<\/h2>\n
\nEchtzeit – Fachwissen<\/h2>\n