Autoren: Felix Martin, Maximilian Hempe und Michael Deubzer, Timing-Architects Embedded Systems GmbH<\/p>\n
In der Automobilbranche ist ein stetig wachsender Bedarf an immer komplexeren eingebetteten Systemen getrieben von innovativen Funktionen gegeben. Auch in Zukunft wird die Anzahl neuer Funktionen, die vollst\u00e4ndig durch Software umgesetzt werden steigen, insbesondere f\u00fcr die Themen ADAS, Connected Cars, automatisches Fahren und Mobility Services. Dieser Bedarf wird durch performantere eingebettete Systeme gedeckt, welche Multi- und Many-Core-Controller enthalten und zunehmend auch in den klassischen Fahrzeugdom\u00e4nen eingesetzt werden. Diese Fallstudie ist in der klassischen Dom\u00e4ne Lenkung angesiedelt, jedoch l\u00e4sst sie sich auch auf andere klassische Dom\u00e4nen \u00fcbertragen.<\/strong><\/p>\n Sicherheitskritische Funktionen in diesen Bereichen unterliegen hohen Echtzeitanforderungen, um Menschenleben nicht durch Fehlfunktion zu gef\u00e4hrden. Aus diesem Grund ist ein Nachweis der Performance und des Timings der Funktionen notwendig und durch ISO 26262 gefordert. Mit der steigenden Komplexit\u00e4t der Funktionen und der Systeme w\u00e4chst der Bedarf an Automatisierung und Abstraktion, der sich in neuen und erweiterten Tools widerspiegelt.<\/p>\n Als Nachweismethoden des Zeitverhaltens spielt neben der Simulation und statischen Analysen das Tracing eine wichtige Rolle. Durch Tracing kann das dynamische Verhalten von zeitkritischen Applikationen detailliert aufgezeichnet und validiert werden. In dieser Arbeit werden Tracing-Methoden betrachtet und miteinander verglichen, mit dem Ziel, eine optimale L\u00f6sung mit dem Anspruch, sehr hohe Messtiefe, Messbreite und Messl\u00e4nge bei minimaler Messabweichung zur Verf\u00fcgung zu stellen. Bestehende Ans\u00e4tze werden hierzu kombiniert und eine Auswahl empfehlenswerter Werkzeuge getroffen.<\/p>\n In Echtzeitsystemen h\u00e4ngt korrektes Systemverhalten nicht nur von der Richtigkeit der berechneten Daten und den daraus abgeleiteten Entscheidungen ab, sondern auch davon, wann diese Daten vorliegen und die entsprechenden Entscheidungen getroffen werden. Die Zeit, die eine Funktion einhalten muss, um korrekt zu funktionieren, wird in informalen Zeitanforderungen definiert. Insbesondere in sicherheitskritischen Dom\u00e4nen wie der Automobilindustrie m\u00fcssen diese Anforderungen eingehalten werden, um das Gef\u00e4hrdungspotential f\u00fcr Mensch und Umwelt zu minimieren [1]. Die Verwendung von Multi-Core-Prozessoren erschwert die Thematik, aus dem Grund, dass das Zeitverhalten durch den simultanen Zugriff verschiedener Softwarekomponenten auf Speicher und Peripherie negativ beeinflusst wird [2].<\/p>\n Echtzeitanforderungen auf den verschiedenen Ebenen in sicherheitskritischen Systemen werden w\u00e4hrend des gesamten Entwicklungsprozesses f\u00fcr jeden Release gepr\u00fcft [3]\u00a0[4] . Mittels Tracing k\u00f6nnen Zeitpunkte der Ausf\u00fchrung von Funktionen und Zugriffe auf Daten aufgezeichnet werden, um das korrekte Zeitverhalten der Funktionen auswerten zu k\u00f6nnen. In dieser Arbeit wird gezeigt, welche Schritte unter Abw\u00e4gung der Kosten und Nutzen empfehlenswert sind, um einen solchen Prozess in der Praxis aufzusetzen. Nach kurzer Einf\u00fchrung der Grundlagen zur Echtzeitbetrachtung und Tracing sowie einer Gegen\u00fcberstellung der heute bestehenden Tracing-Methoden werden im Folgenden die konkreten Schritte diskutiert, wie ein empfehlenswerter Trace-Prozess zur Pr\u00fcfung von zeitkritischen Funktionen gestaltet werden sollte. In diese Bewertung und Empfehlung flie\u00dft gesammelte Erfahrung aus einem realen Projekt eines Lenksystems ein.<\/p>\n Die meist informalen Zeitanforderungen in bestehenden Projekten m\u00fcssen zur weiteren automatisierten Verarbeitung in eine formale Beschreibung \u00fcbersetzt werden. Hierzu ist ein Datenmodell w\u00fcnschenswert, welches sich an aktuelle Standards in der Automobilindustrie anlehnt. Eine M\u00f6glichkeit daf\u00fcr sind die AUTOSAR Timing Extensions [3], deren Ansatz im Folgenden betrachtet wird. F\u00fcr die Wahl der Tracemethodik, mit m\u00f6glichst hoher Messtiefe, Messbreite und Messl\u00e4nge bei minimalem Messfehler, werden zun\u00e4chst Trace-Techniken betrachtet und gegen\u00fcbergestellt. Als Format f\u00fcr die Aufzeichnung der Traces ist in diesem Fall das im AMALTHEA-Standard-spezifizierte offene BTF-Format gew\u00e4hlt worden, da es eine vollst\u00e4ndige Unterst\u00fctzung f\u00fcr Multi-Core- und Multiprozessor-Traces bietet [4]. F\u00fcr die Auswertung von Traces gibt es verschiedene L\u00f6sungen. Der letzte Abschnitt dieser Sektion erl\u00e4utert die grunds\u00e4tzliche Funktionsweise solcher Werkzeuge. In dieser Methodik hat sich der TA Inspector von Timing-Architects als beste Wahl erwiesen, da sowohl Profiling sowie automatische Auswertung und Wiederverwendung von formalisierten Zeitanforderungen m\u00f6glich sind [5].<\/p>\n Zeitanforderungen sind auf verschiedenen Abstraktionsebenen, wie z.B. der System-, ECU-, und Softwareebene, definiert. Auf allen Ebenen ist die Auswertung des Echtzeitverhaltens von Interesse. Auf der Softwareebene befinden sich Speicherzugriffe und ausgef\u00fchrte Instruktionen. Erstere k\u00f6nnen Lese- oder Schreibzugriffe auf eine Variable oder auf ein Hardwareregister sein. Letztere bezeichnen die Ausf\u00fchrung eines CPU-Befehls. Im Gegensatz dazu befinden sich auf der ECU-Ebene Teile der Applikationssoftware, wie z.B. Softwarekomponenten und Runnables, sowie Teile der RTE und Middleware wie unteranderem Tasks und Kommunikationsinterfaces.<\/p>\n Alle Arten von Zustands\u00e4nderungen im System werden als Event bezeichnet und m\u00fcssen f\u00fcr die Echtzeitanalyse mit einem Zeitstempel annotiert sein. Zeitanforderungen k\u00f6nnen f\u00fcr die Perioden zwischen zwei oder mehreren unterschiedliche Events definiert werden. Ein Beispiel aus der gegebenen Dom\u00e4ne ist das Lesen und Verarbeiten des Signals\u00a0Drehmoment<\/em>\u00a0des Drehmomentsensors und Berechnung des Sollmoments f\u00fcr den Motor einer elektromechanischen Lenkung. Hier sind beobachtbare Events das Lesen und Schreiben der Signale\u00a0Sensordrehmoment<\/em>\u00a0und\u00a0Motorsollmoment<\/em>\u00a0und die Ausf\u00fchrung bzw. die Statuswechsel der Funktionen\u00a0Verarbeitung<\/em>\u00a0und\u00a0Sollmomentberechnung<\/em>. Diese vier Events m\u00fcssen in einer kausalen Kette innerhalb einer maximalen Zeit auftreten, oder das System muss rechtzeitig innerhalb einer sicherheitskritischen Fehlertoleranzzeit reagieren und damit die Gef\u00e4hrdung von Menschenleben verhindern.<\/p>\n Abbildung 1 (siehe\u00a0PDF<\/a>) zeigt die Definition einer Wirkkette \u00fcber verschiedene Steuerger\u00e4te. Die Events sind in diesem Beispiel auf die Kommunikationsschnittstellen der beteiligten Softwarekomponenten definiert. Zeitanforderungen lassen sich f\u00fcr die Wirkkette als Ganzes oder f\u00fcr einzelne Segmente definieren.<\/p>\n Um die definierten Zeitanforderungen auszuwerten, ist es notwendig, einen Trace aufzuzeichnen. Ein Trace ist eine Liste von Events mit dem jeweiligen Zeitstempel, zu dem das Event aufgetreten ist. Um die Auswertung aller Anforderungen zu erm\u00f6glichen, m\u00fcssen alle Events, die mit Anforderungen in Verbindung stehen, im Trace enthalten sein. F\u00fcr die Aufzeichnung von Traces gibt es nach Ferrari drei unterschiedliche M\u00f6glichkeiten: softwarebasiertes, hybrides und hardwarebasiertes Tracing [6].<\/p>\n Softwarebasiertes Tracing erlaubt das Aufzeichnen von Traces ohne dedizierter Hardware. Stattdessen werden f\u00fcr die Analyse relevante Events instrumentiert. F\u00fcr das Hinzuf\u00fcgen der Instrumentierung gibt es verschiedene Strategien. Eine Methode ist das Instrumentieren im Source Code an den Stellen, an denen die relevanten Events stattfinden. Die zweite M\u00f6glichkeit ist es, Hooks zu verwenden, die vom Betriebssystem bereitgestellt werden. Falls der Source Code nicht verf\u00fcgbar ist, kann die Instrumentierung auch direkt zum Binary der Software hinzugef\u00fcgt werden. Beim softwarebasiertem Tracing kann der Trace auf zwei Arten f\u00fcr die Auswertung bereitgestellt werden. Die erste Option ist, die Daten zur Laufzeit im Speicher auf dem Steuerger\u00e4t abzulegen und nachtr\u00e4glich auszulesen. Alternativ dazu k\u00f6nnen die Daten auch in Echtzeit \u00fcber eine Schnittstelle, zum Beispiel CAN, von der ECU transportiert werden [7].<\/p>\n Im Gegensatz zum softwarebasiertem Tracing ist beim hardwarebasiertem Tracing a priori keine Instrumentierung notwendig. Stattdessen werden die relevanten Events \u00fcber einen dedizierten Hardwarebaustein (Emulation Device) und ein entsprechendes Interface direkt ausgelesen. Mit diesem Ansatz ist es m\u00f6glich, sowohl Speicherzugriffe via Data-Tracing, als auch ausgef\u00fchrte Instruktionen via Program-Flow-Tracing aufzuzeichnen [6]. Dazu hat der dedizierte Hardwarebaustein Zugriff auf die Kerne und die Speicherbusse des Prozessors. Die detektierten Events werden mit Zeitstempeln versehen und \u00fcber das Trace-Interface gesendet.<\/p>\n Hybrides Tracing bezeichnet Ans\u00e4tze, die software- und hardwarebasiertes Tracing kombinieren. Beispielsweise k\u00f6nnen Betriebssystem-Hooks dazu verwendet werden, Events in den Speicher zu schreiben, die f\u00fcr die Auswertung relevant sind. Diese Nachrichten k\u00f6nnen im darauffolgenden \u00fcber existierende Datenschnittstellen wie CAN ausgelesen werden.<\/p>\n Grunds\u00e4tzlich ist softwarebasiertes Tracing einfacher aufzusetzen, da keine dedizierte Hardware notwendig ist. Im Gegensatz dazu erfordert hardwarebasiertes Tracing ein Emulation Device und spezielle Trace-Hardware. Der Vorteil von hardwarebasiertem Tracing ist daf\u00fcr eine signifikant gr\u00f6\u00dfere Bandbreite, die es erlaubt, l\u00e4ngere Traces mit einer gr\u00f6\u00dferen Anzahl an Objekten und mehr Messtiefe aufzuzeichnen. Gerade die Anzahl der Objekte und die Trace-L\u00e4nge sind bei softwarebasierten oder hybriden Ans\u00e4tzen ohne dediziertes Trace-Interface aufgrund des verf\u00fcgbaren Speichers und der limitierten Bandbreiten klassischer Datenschnittstellen eingeschr\u00e4nkt.<\/p>\n Unabh\u00e4ngig von der gew\u00e4hlten Trace-Technik ist das Ergebnis ein Trace, der die Auswertung der Zeitanforderungen erm\u00f6glicht. Die Auswertung erfolgt in zwei Schritten: Im ersten Schritt werden alle Metriken berechnet, die f\u00fcr die Validierung der Anforderungen relevant sind. Im zweiten Schritt werden die berechneten Metriken mit den Anforderungen verglichen. Das Ergebnis ist eine Liste von Anforderungen zusammen mit der Information, in wie vielen F\u00e4llen diese jeweils verletzt wurden. Die unterste Zeile in Abbildung 2 (siehe\u00a0PDF<\/a>) zeigt die graphische Darstellung der Ergebnisse einer Anforderungsanalyse im TA Inspector. Nach dem Ampelprinzip kann der Nutzer erkennen, welche Anforderungen verletzt wurden.<\/p>\n In dieser Sektion wird genauer beschrieben, welche Schritte notwendig sind, um die Zeitanforderungen und das komplette dynamische Verhalten f\u00fcr ein Steuerger\u00e4t in der Automobilindustrie zu \u00fcberwachen. Das Referenzsystem ist ein Lenksystem eines gro\u00dfen deutschen OEMs. Der erste Abschnitt geht auf die Auswahl der richtigen Trace-Technik ein und welche Fragestellungen sich beim Umsetzen von hardwarebasiertem Tracing ergeben haben. Anschlie\u00dfend wird beschrieben, wie der Trace in das BTF-Format konvertiert werden kann. Der letzte Abschnitt zeigt, in welcher Form die erzeugten Daten zur weiteren Analyse aufbereitet werden k\u00f6nnen.<\/p>\n Bevor ein Prozess zum Tracing aufgesetzt werden kann, sollte definiert werden, welche Anforderungen an die generierten Traces gestellt werden. F\u00fcr das Lenkungssteuerger\u00e4t sollen neben Tasks und ISRs auch Runnables und Zugriffe auf bestimmte Signale aufgezeichnet werden. Zus\u00e4tzlich ist die Aufzeichnung von Traces \u00fcber mehrere Sekunden notwendig, um verschiedene Bewegungsmuster der Lenkung abzudecken, zum Beispiel die Bewegung von einem Lenkanschlag zum anderen. Beide Anforderungen kombiniert erfordern zwingend einen hardwarebasierten Traceansatz. Das Zwischenspeichern von Tracedaten f\u00fcr nahezu 300 Runnables ist eine Aufgabe, die ein reiner Software-Trace nicht leisten kann.<\/p>\n F\u00fcr hardwarebasiertes Tracing ist ein dedizierter Tracebaustein auf dem Prozessor zwingend erforderlich. Der f\u00fcr das Steuerger\u00e4t eingesetzte Prozessor ist ein NXP Leopard (MPC5643L). Ein Blick in das Datenblatt zeigt, dass der Prozessor Data- und Program-Flow-Tracing entsprechend des NEXUS-Standards zur Verf\u00fcgung stellt [8]. Ersteres kann in dem Datenblatt unter data trace messaging (DTM), letzteres unter branch trace messaging (BTM) gefunden werden [9]. Damit ist die erste Voraussetzung erf\u00fcllt.<\/p>\n Nun m\u00fcssen die aufgezeichneten Daten vom Prozessor transportiert werden. In Abh\u00e4ngigkeit vom verwendeten Package hat der Leopard entweder vier oder 12 message data out (mdo) pins, \u00fcber welche die Events vom Chip gesendet werden k\u00f6nnen. Die hier verwendete Version des Geh\u00e4uses bietet vier Ausgangspins, was die maximale Tracebandbreite einschr\u00e4nkt. Ein gr\u00f6\u00dferes Problem ist, dass die NEXUS-Pins nicht auf eine Buchse des Steuerger\u00e4ts geroutet sind. Dadurch gibt es keine M\u00f6glichkeit, die Tracedaten abzugreifen.<\/p>\n Es gibt unterschiedliche M\u00f6glichkeiten, dieses Problem zu l\u00f6sen, zwei davon werden im Folgenden diskutiert. Der Lieferant des Boards kann dazu beauftragt werden, das Platinenlayout zu \u00e4ndern, so dass die vier Pins zu einer Buchse f\u00fchren. Das ist aber keine L\u00f6sung, die kurzfristig umsetzbar ist. Au\u00dferdem w\u00e4re das Interface auf dem Board aufgrund der Verbauung im Geh\u00e4use nicht zug\u00e4nglich.<\/p>\n Die zweite L\u00f6sung ist die Verwendung eines Emulation Boards [10]. Dabei emuliert ein Leopard-Prozessor auf dem Board mit BGA257 Package (also dem gr\u00f6\u00dferen Package, das ein 12-Pin Nexus-Interface hat) den eigentlichen Prozessor des Steuerger\u00e4tes. Damit k\u00f6nnen zwei Probleme gel\u00f6st werden: Erstens wird die Limitierung des vier Pin-Interfaces umgangen. Zweitens ist das Nexus-Interface \u00fcber das Emulation Board nach au\u00dfen gef\u00fchrt. Somit sind keine weiteren \u00c4nderungen am Steuerger\u00e4t selbst notwendig.<\/p>\n Um das Emulation Board mit dem Steuerger\u00e4t zu verbinden, muss der existierende Prozessor mit QFP100 Package abgel\u00f6tet werden. Anschlie\u00dfend wird ein L\u00f6tsockel an der gleichen Stelle angebracht. Dieser Sockel kann nun dazu verwendet werden, das Emulation Board an die ECU anzustecken. Um das zu erm\u00f6glichen, wurde ein Loch in das Geh\u00e4use der ECU geschnitten. Dieser Aufbau hat das gleiche Verhalten wie die ECU im urspr\u00fcnglichen Zustand mit dem Vorteil, dass das 12-Pin Nexus-Interface zum Tracing zur Verf\u00fcgung steht.<\/p>\n Mit dem Nexus-Interface ist es nun m\u00f6glich, Traces aufzuzeichnen. Zur Echtzeitanalyse m\u00fcssen diese in das BTF-Format transformiert werden. Die Objekte, die in diesem Projekt analysiert werden sollen, sind Tasks, ISRs, Runnables und ausgew\u00e4hlte Variablenzugriffe. In OSEK-Betriebssystemen k\u00f6nnen Tasks und ISRs \u00fcber Data-Tracing aufgezeichnet werden. Variablenzugriffe werden ebenfalls \u00fcber Data-Tracing abgebildet. Runnable-Events sind Funktionsaufrufe, welche mittels Program-Flow-Tracing registriert werden k\u00f6nnen.<\/p>\n Bei der Implementierung der Transformation auf diese Weise ergaben sich jedoch Schwierigkeiten. Erstens wird das \u00b5C\/OS Betriebssystem von Micrium verwendet, welches nicht OSEK-konform ist [11]. Entsprechend ist der \u00fcbliche Task-Trace Ansatz \u00fcber das OSEK Task State Array nicht anwendbar. Ein weiteres Problem ist, dass die ISRs der OSEK-Kategorie Eins entsprechen. Das Betriebssystem bekommt also nicht mit, wann ISRs ausgef\u00fchrt werden und kann diese Information folglich nicht in tracebaren Datenstrukturen ablegen. Um mit dieser Einschr\u00e4nkung umzugehen, kann ein Program-Flow-Trace auch f\u00fcr die ISRs verwendet werden. Dies ist jedoch aufgrund der dritten Limitierung nicht m\u00f6glich. Zur Zeit der Durchf\u00fchrung dieses Projekts unterst\u00fctzte iSYSTEM noch kein vollst\u00e4ndiges Multi-core Profiling. Damit ist die Verwendung des Program-Flow-Traces f\u00fcr mehrere Kerne nicht m\u00f6glich. Da die simultane Analyse beider Kerne obligatorisch ist, kann das Program-Flow-Tracing nicht verwendet werden und damit k\u00f6nnen auch Runnable und ISR Events nicht direkt aufgezeichnet werden.<\/p>\n Letztendlich ist es daher notwendig, trotz des Emulation Adapters einen hybriden Traceansatz zu verwenden. Dieser sieht vor, Runnable und ISR Information via Instrumentierung aufzuzeichnen. Die Voraussetzungen daf\u00fcr sind zum einen, dass der Source Code f\u00fcr die Instrumentierung zur Verf\u00fcgung steht. Zum anderen darf der Einfluss der Instrumentierung die Laufzeiteigenschaften der Software nicht signifikant verf\u00e4lschen. Der erste Punkt ist erf\u00fcllt, und der zweite Punkt muss aufgrund fehlender Alternativen vorerst in Kauf genommen werden.<\/p>\n Die Instrumentierung selbst wird nach dem folgenden Schema durchgef\u00fchrt: Zuerst wird f\u00fcr alle ISRs und Runnables die f\u00fcr die Analyse von Interesse sind eine ID vergeben. Dann wird der Source Code nach den Aufrufen der Runnables und den ISR Definitionen durchsucht. Wird der Aufruf eines relevanten Runnables gefunden, wird vor und nach dem Runnable die entsprechende ID in eine dedizierte Variable gelegt. Zus\u00e4tzlich wird nach dem Aufruf ein zus\u00e4tzliches Bit gesetzt, das dazu reserviert ist zu indizieren, ob ein Start oder eine Terminierung vorliegt. \u00c4hnlich ist das Vorgehen f\u00fcr die ISRs, mit der Ausnahme, dass die Instrumentierung im Kontext der ISR selbst hinzugef\u00fcgt wird. Damit ist das Aufzeichnen von Runnable und ISR Events m\u00f6glich, indem die dedizierte Variable per Data-Tracing beobachtet wird. Das Gleiche gilt f\u00fcr die Zugriffe auf bestimmte andere Variablen, die von Interesse sind. In diesem Fall ist das zum Beispiel die System-State-Variable, die den momentanen Zustand, in dem sich das System befindet, anzeigt.<\/p>\n Zuletzt muss untersucht werden, wie die Taskzust\u00e4nde rekonstruiert werden k\u00f6nnen. Dazu ist ein genauerer Blick auf das Betriebssystem notwendig. Dabei f\u00e4llt auf, dass ein Array von Taskkontextbl\u00f6cken (OSTCBTbl<\/em>) existiert. Jeder dieser Bl\u00f6cke wird vom Betriebssystem dazu verwendet, verschiedene Informationen, wie Adresse des Taskstacks, Gr\u00f6\u00dfe des Taskstacks, Priorit\u00e4t und auch Zustand der Task, zu speichern. Au\u00dferdem gibt es eine Variable, die eine Referenz auf den Kontextblick der momentan laufenden Task enth\u00e4lt (OSTCBCur<\/em>). In OSEK-Betriebssystemen w\u00fcrde der Zustand im Taskkontextblick ausreichen, um die Events f\u00fcr eine Task zu rekonstruieren. Im Falle von \u00b5C\/OS gibt es aber keine separaten Zust\u00e4nde f\u00fcr\u00a0Ready<\/em>\u00a0und\u00a0Running<\/em>. Stattdessen werden diese im Zustand\u00a0Runnable<\/em>\u00a0zusammengefasst, \u00e4hnlich wie im Taskzustandsmodell von Linux. Daraus ergibt sich, dass es zus\u00e4tzlich notwendig ist, die Variable\u00a0OSTCBCur<\/em>\u00a0zu tracen, um die Unterscheidung zwischen Ready und Running zu treffen.<\/p>\n Mit diesem Wissen ist es nun m\u00f6glich, den kompletten Trace nach BTF zu konvertieren. Dazu werden per Data-Tracing Schreibzugriffe auf die dedizierte Variable f\u00fcr die ISRs und Runnables, das komplette Taskkontextblockarray und die Variable OSTCBCur aufgezeichnet. Der exportierte Datentrace ist dann ein CSV, der folgende Felder enth\u00e4lt: Zeitstempel, Adresse der geschriebenen Variable, Wert, der geschrieben wurde, und Kern, von dem der Zugriff erfolgt ist. Zus\u00e4tzlich zum Trace selbst sind noch die Zuordnungen von IDs zu Runnables und ISRs, von Adressen zu Variablen-Namen und von Taskzustandsvariablenadressen zu Tasknamen notwendig. Ersteres wird bei der Instrumentierung erstellt. Die anderen beiden Punkte k\u00f6nnen mit dem Debugger ausgelesen werden.<\/p>\n Der letzte Schritt ist die Auswertung des Traces im BTF-Format mit dem TA Inspector. Neben den bereits diskutierten Metriken, die sich auf die Zeit zwischen zwei oder mehreren Events beziehen, werden auch Metriken berechnet, welche nicht die Einheit Zeit haben, aber f\u00fcr die Analyse von Bedeutung sind. Beispiele daf\u00fcr sind die Anzahl der Unterbrechungen einer Taskinstanz, die Last, die von einer ISR auf einen bestimmten Kern verursacht wird, und die Anzahl der multiplen Taskaktivierungen. Der TA Inspector ist in der Lage, all diese Metriken zu berechnen.<\/p>\n Auf der anderen Seite sind nicht immer alle Metriken interessant, die w\u00e4hrend der Analyse des Traces berechnet werden. Aus diesem Grund unterst\u00fctzt die TA Tool Suite die automatisierte Erstellung von Reports in verschiedenen Formaten. Die darin enthaltenen Metriken und Anforderungen k\u00f6nnen frei konfiguriert werden. Die Reporterstellung ist in verschiedenen Formaten wie HTML, LaTeX und XML m\u00f6glich. Sowohl die Auswertung an sich als auch die Reporterstellung ist via Konsolenschnittstelle bedienbar. Somit l\u00e4sst sich die Reporterstellung komplett automatisiert ausf\u00fchren.<\/p>\n Ist der Prozess zur tracebasierten Echtzeitanalyse implementiert, m\u00fcssen die erzeugten Daten verwendet werden, um die Robustheit der zeitkritischen Funktionen permanent zu \u00fcberwachen und zu verbessern. F\u00fcr das Lenksystem konnten die Evaluierungsergebnisse f\u00fcr die folgenden Use-Cases verwendet werden:<\/p>\n Die Lenkung im Fahrzeug ist ein sicherheitskritisches Bauteil mit der Einstufung ASIL D nach ISO 26262 [12]. Aus diesem Grund ist auf Systemebene nach der Norm das korrekte Echtzeitverhalten durch festgelegte Methodiken nachzuweisen, insbesondere f\u00fcr Safety-Umf\u00e4nge des Systems. Auf Systemlevel ist es das Ziel, die korrekte funktionale Performance und die Fehlerfreiheit von Sicherheitsmechanismen festzustellen. Die Norm definiert hierzu im Abschnitt 8.4ff zum einen Performance Tests, welche zum Timing- und Schedulingnachweis auf Systemlevel anzuwenden sind, und zum anderen Resource Usage Tests, um Speichergr\u00f6\u00dfen und Laufzeit von Runnables auf festgelegte Budgets und damit die Robustheit und Verf\u00fcgbarkeit des Systems sicherzustellen.<\/p>\n Aus diesem Grund ist ein wichtiges Gesch\u00e4ftsziel der Lenkungsentwicklung die vollst\u00e4ndige Nachweisf\u00fchrung der Echtzeitf\u00e4higkeit: der Nachweis, dass Timing-Anforderungen, wie Wirkketten im System vom Sensor bis Aktor, nach Spezifikation in der korrekten Zeit funktionieren und maximale Ausf\u00fchrungszeiten von Funktionen und maximale Datenalter von Signalen eingehalten werden.<\/p>\n Beispielsweise muss sichergestellt werden, dass bei einer elektromechanischen Lenkung das Handmoment \u00fcber einen Drehmomentsensor \u00fcber die Vorverarbeitung der Basis-Software, der Berechnung von Kundenfunktionalit\u00e4t in Applikationen bis hin zur Momentstellung am Motor rechtzeitig innerhalb der sicherheitskritischen Anforderungen geschieht. Fehlertoleranzzeiten dienen dabei der rechtzeitigen Reaktion auf Signalfehler, inkorrekte Verarbeitung der Signale, fehlerhafte Applikation oder fehlerhaftem Momentstellen am Motor, welche durch \u00dcberwachungsfunktionen sichergestellt werden. Zum Nachweis der Einhaltung dieser Fehlertoleranzzeiten je nach Sicherheitsziel wird ebenfalls die hier gezeigte Methodik herangezogen.<\/p>\n Zus\u00e4tzliche Budgetierung des Gesamtsystems bei verteilter SW-Entwicklung wird vorgenommen, um das Gesamtsystem zu partitionieren, um so der Basis-Software, der Applikation und gegebenenfalls weiteren Parteien die notwendigen Ressourcen zuzuteilen. Weiterhin werden in SW-Feinspezifikationen detaillierte Ressourcenbudgets auf Unit-Ebene festgelegt. Diese Budgets zur Partitionierung von Integrationsanteilen und der Units werden gepr\u00fcft durch Resource Usage Tests, welche auf Systemebene f\u00fcr jeden Release anhand von Worst-Case-Timing-Szenarien \u2013 auch Stresstests genannt \u2013 durchgef\u00fchrt werden.<\/p>\n Als zus\u00e4tzliches Gesch\u00e4ftsziel ist die Performancebewertung und -optimierung zu nennen, bei der das System auf Ressourcenengp\u00e4sse und Top-Verbraucher analysiert wird und m\u00f6gliche Laufzeitoptimierungen erkannt werden. Hierzu ist die Auswertung von HW-Traces ein wichtiges Mittel, um im Gesamtsystemkontext bewerten zu k\u00f6nnen, welche Timing-Probleme vorliegen. Beispielsweise lassen sich Worstcases durch Scheduling-Effekte erkl\u00e4ren. Analysen wie die Interference-Analyse unterst\u00fctzen dabei, diese Effekte zu erkennen.<\/p>\n F\u00fcr die Ziele des Timing-Nachweises und der Analyse werden System-, Bauteil- und SW-Anforderungen an das Zeitverhalten in formale maschinenlesbare Timing-Requirements und Constraints \u00fcbersetzt. Das Ziel in diesem Verarbeitungsschritt ist es, eine automatisierte Auswertung der Timing-Anforderungen auf den aufgezeichneten Traces durch Toolunterst\u00fctzung durchf\u00fchren zu k\u00f6nnen. Komfortabel hierzu ist die Funktion in der TA Tool Suite, die es dem Timing-Analysten erm\u00f6glicht, formalisierte Timing-Requirements\/Constraints nicht nur tabellarisch, sondern auch graphisch zu definieren und sie in zuk\u00fcnftigen Tests einfach wiederzuverwenden. Eine Regressionsteststrategie ist damit m\u00f6glich. In der hier vorliegenden Fallstudie wurden die in der Tabelle 1 genannten Timing-Requirements\/-Constraints verwendet, um die im Projekt gegebenen Timing-Anforderungen zu formalisieren.<\/p>\n Zus\u00e4tzlich zu diesen Timing-Requirements\/-Constraints werden Metriken zur Analyse des dynamischen Verhaltens des Systems aus den aufgezeichneten BTF-Traces analysiert. Tabelle 2 zeigt die hier verwendeten Metriken.<\/p>\nEinleitung<\/h2>\n
Grundlagen Echtzeitanalyse und Tracing<\/h2>\n
Zeitanforderungen<\/h2>\n
Tracing<\/h2>\n
Werkzeuggest\u00fctzte Traceauswertung<\/h2>\n
Tracebasierte Echtzeitanalyse in der Praxis<\/h2>\n
Tracing<\/h2>\n
Transformation<\/h2>\n
Auswertung<\/h2>\n
Vorteile tracebasierter Echtzeitanalyse<\/h2>\n
\n