Autoren: Felix Martin, Andreas Sailer, Michael Deubzer, Timing-Architects Embedded Systems GmbH, J\u00fcrgen Mottok, Ostbayerische Technische Hochschule<\/p>\n
Der Trend zum Einsatz von Multi-Core Prozessoren, um den steigenden Leistungsanforderungen in eingebetteten Echtzeitsystemen gerecht zu werden, ist ebenso klar erkennbar wie die damit einhergehenden Herausforderungen hinsichtlich Zeitverhalten, Datenabh\u00e4ngigkeiten, Performanz und Zuverl\u00e4ssigkeit. Dieser Beitrag zeigt am Beispiel des freien Echtzeitbetriebssystems Erika Enterprise einen modellbasierten Ansatz, um die Einhaltung von sicherheitskritischen Echtzeitanforderungen mittels Tracing \u00fcber den kompletten Entwicklungsprozess zu \u00fcberwachen. Ein modellbasierter Entwicklungsansatz erlaubt es bereits in der Planungsphase von Softwareprojekten, die Einhaltung von systemkritischen Anforderungen und Beschr\u00e4nkungen sicherzustellen [1]. Dazu wird ein Modell erstellt, welches das zeitliche Verhalten des Systems beschreibt.<\/p>\n Ein solches Modell besteht aus einem Hardware-, einem Betriebssystem- und einem Anwendungsteil. Der Hardwareteil beschreibt abstrakt das Verhalten des Prozessors, auf dem die finale Applikation durchgef\u00fchrt werden soll. Der Betriebssystemteil modelliert das Verhalten von Serviceroutinen, wie zum Beipsiel die Anzahl an Instruktionen, die f\u00fcr eine Inter-Prozess-Aktivierung notwendig sind. Das Anwendungsmodell bildet die eigentliche Funktionalit\u00e4t der Applikation ab. Echtzeitkritische Softwaresysteme setzen sich aus verschiedenen Tasks zusammen, die wiederum anwendungsspezifische Funktionen, sogenannte Runnables, aufrufen.<\/p>\n Basierend auf einem solchen Modell k\u00f6nnen dann Anforderungen hinsichtlich des geforderten Zeitverhaltens definiert werden. Anforderungen k\u00f6nnen f\u00fcr alle Objekte, die im Anwendungsteil des Modells bestimmt sind, gestellt werden. Ein klassisches Beispiel hierf\u00fcr ist die maximale Reaktionszeit einer Task, also die Zeit von ihrer Aktivierung bis zur Terminierung. Anforderungen an Datenabh\u00e4ngigkeiten k\u00f6nnen in Form von Data-Age-Constraints festgehalten werden [2]. Au\u00dferdem erlauben es sogenannte Ereignisketten, Zeitanforderungen f\u00fcr die Ausf\u00fchrung einer beliebigen Folge von Systemereignissen festzulegen.<\/p>\n Mit Hilfe einer diskreten Event-Simulation ist es nun m\u00f6glich, das Laufzeitverhalten der finalen Applikation basierend auf einer solchen Systembeschreibung zu berechnen. Das Ergebnis ist ein sogenannter Trace – eine Abfolge von Ereignissen, die das Echtzeitverhalten des Systems wiedergeben. Dieser Trace kann nun ausgewertet und mit den definierten Anforderungen verglichen werden, was in Abbildung 1 (siehe\u00a0PDF<\/a>) dargestellt ist. So lassen sich Fehler im Systemdesign fr\u00fch erkennen und beheben.<\/p>\n Auch wenn eine Applikation in die Entwicklungsphase geht, k\u00f6nnen die gestellten Anforderungen weiterhin validiert werden. Dazu ist es notwendig, das Verhalten der Software auf der Zielplattorm aufzuzeichnen – ein Prozess, der als Tracing oder Trace Recording bekannt ist. Der erste Teil dieses Beitrags zeigt die verschiedenen M\u00f6glichkeiten, um Traces von der Hardware aufzuzeichnen. Aufgezeichnete Tasks sind \u00fcblicherweise nicht in diesem Format, das f\u00fcr die Validierung der Echtzeitanforderungen geeignet ist. Aus diesem Grund erl\u00e4utert der zweite Teil, welche Schritte zur \u00dcberf\u00fchrung in ein geeignetes Format notwendig sind. Abschlie\u00dfend wird beschrieben, wie diese Schrite unter Verwendung des Modells automatisiert werden k\u00f6nnen.<\/p>\n Mittels Tracing kann das Verhalten von eingebetteten Systemen von der Hardware aufgezeichnet werden. Wie beim Simulieren ist das Result ein Trace, also eine Serie von Ereignissen, die verschiedene Vorkommnisse im System repr\u00e4sentieren. Nach Ferrari [3] gibt es daf\u00fcr drei prinzipielle M\u00f6glichkeiten: softwarebasiertes, hybrides und hardwarebasiertes Tracing.<\/p>\n Beim softwarebasierten Tracing wird ein spezieller Code zur Applikation hinzugef\u00fcgt. Diese sogenannte Instrumentierung sorgt daf\u00fcr, dass Ereignisse, die zur Analyse des Laufzeitverhaltens von Interesse sind, mit zugeh\u00f6rigem Zeitstempel im Speicher geloggt werden. Nach der Ausf\u00fchrung kann der Trace via Debugger oder serieller Schnittstelle ausgelesen werden. Dieser Ansatz ver\u00e4ndert jedoch das Laufzeitverhalten der Applikation [4]. Dar\u00fcber hinaus ist die maximal m\u00f6gliche Tracedauer durch den verf\u00fcgbaren Speicherplatz auf der Hardware limitiert.<\/p>\n Hybrides Tracing ist ebenso auf die Instrumentierung der Applikation angewiesen und ver\u00e4ndert damit das Laufzeitverhalten. Im Gegensatz zum softwarebasierten Ansatz werden die aufgezeichneten Ereignisse direkt \u00fcber eine dedizierte Schnittstelle zur weiteren Analyse versendet. Dies bedeutet, dass bei ausreichender Bandbreite die maximal m\u00f6gliche Tracedauer nicht vom verf\u00fcgbaren Speicherplatz limitiert wird.<\/p>\n F\u00fcr hardwarebasiertes Tracing, auch bekannt unter dem Begriff „On-Chip-Trace“, ist keine Softwareinstrumentierung notwendig. Stattdessen wird ein eigens daf\u00fcr vorgesehener Bereich auf dem Prozessor dazu verwendet, die Befehlsabarbeitung und die Datentransfers der CPUs aufzuzeichnen. Diese Ereignisse k\u00f6nnen nach nutzerdefinierten Regeln gefiltert werden, um dann \u00fcber ein spezielles Hardware-Trace-Interface vom Chip gesendet zu werden. Wird eine entsprechende Hochleistungsschnittstelle wie das AURORA-Interface verwendet, sind damit Aufzeichnungen von beliebiger L\u00e4nge m\u00f6glich [5].<\/p>\n Hardwarebasiertes Tracing ist die einzige Methode, die eine sinnvolle Validierung von Echtzeitanforderungen auf der Hardware erlaubt. Wie erw\u00e4hnt wurde, ver\u00e4ndern Ans\u00e4tze, die auf Instrumentierung beruhen, das Laufzeitverhalten. Somit kann es besonders bei stark ausgelasteten Applikationen passieren, dass Anforderungen, die normalerweise erf\u00fcllt sind, aufgrund des zus\u00e4tzlichen Rechenaufwands durch die Instrumentierung nicht mehr eingehalten werden. Dar\u00fcber hinaus bedeutet es einen entwicklungstechnischen Mehraufwand, Instrumentierung zur Applikation hinzuzuf\u00fcgen und zu pflegen.<\/p>\n Grunds\u00e4tzlich kann hardwarebasiertes Tracing drei Arten von Traces erzeugen: Instruction-, Daten- und Signal-Traces [6]. Instruction-Traces bestehen aus Befehlen, die von der CPU abgearbeitet wurden. Zusammen mit den Debuginformationen kann daraus der komplette Programmpfad der Applikation rekonstruiert werden. Daten-Traces enthalten Speicherzugriffe der CPUs, also beispielsweise Schreib- und Lesezugriffe auf Variablen der Applikation. Signal-Traces beinhalten Informationen \u00fcber das Verhalten von Peripherals, wie zum Beispiel des Generic Timer Modules (GTM) der Infineon AURIX\u2122<\/span>-Prozessor-Familie.<\/p>\n Das folgende Listing zeigt die textuelle Repr\u00e4sentation eines Datatrace-Ereignisses, exportiert auf dem Tool\u00a0TRACE32\u00a0<\/em>der Lauterbach GmbH [7].<\/p>\n 0.0013952200,EE_th_status[0],“wr-data“,00000003,0<\/p>\n Jedes Ereignis besteht aus f\u00fcnf Feldern. Das erste entspricht dem Zeitstempel, zu dem das Ereignis aufgezeichnet wurde. Die Zeiteinheit ist Sekunden. Das zweite Feld repr\u00e4sentiert die Variable, die von dem Datenzugriff betroffen ist. Das dritte Feld gibt an, ob ein Lese- oder ein Schreibzugriff stattgefunden hat. In diesem Fall handelt es sich um Letzteres („write-data“). Das vierte Feld gibt den Wert an, der in die Variable geschrieben wurde. Das letzte Feld zeigt die ID des Prozessorkerns, auf dem das Ereignis stattgefunden hat.<\/p>\n Das folgende Listing zeigt die textuelle Repr\u00e4sentation eines Instruction-Trace-Ereignisses, ebenso exportiert aus\u00a0TRACE32<\/em>.<\/p>\n +1408860; R_2_1; fstart; 0<\/p>\n Das erste Feld entspricht wieder dem Zeitpunkt, zu dem das Ereignis aufgezeichnet wurde. Diesmal ist die Zeit in Nanosekunden angegeben. Das zweite Feld gibt den Namen des Softwareobjekts an, das von dem Event betroffen ist. Das dritte Feld gibt an, welche Aktion f\u00fcr das Softwareobjekt ausgef\u00fchrt wird, in diesem Fall startet die Funktion\u00a0R_2_1<\/em>. Das letzte Feld repr\u00e4sentiert wieder den Prozessorkern, auf dem das Ereignis stattgefunden hat.<\/p>\n In der Einleitung wurde beschrieben, wie Anforderungen f\u00fcr Systemobjekte, wie Tasks und Signale definiert werden k\u00f6nnen. Im Gegensaz dazu beziehen sich Ereignisse, die beim hardwarebasierten Tracing aufgezeichnet werden, auf Softwareobjekte, also Entit\u00e4ten, die auf Source-Code-Level definiert sind, so wie Variablen und Funktionen.<\/p>\n Um hardwarebasierte Traces f\u00fcr die Validierung von Echtzeitanforderungen zu verwenden, ist es also notwendig, die Traces von Softwarelevel auf Systemlevel zu transformieren, was in Abbildung 2 (siehe\u00a0PDF<\/a>) veranschaulicht wird. Daf\u00fcr m\u00fcssen die verschiedenen Systemereignisse den entsprechenden Ereignissen auf Softwarelevel zugeordnet werden. Zur Repr\u00e4sentation des Traces auf Systemlevel ist au\u00dferdem ein geeignetes Format, wie das Best Trace Format (BTF) [8], notwendig.<\/p>\n Zur Verdeutlichung der Transformation soll das Data-Trace-Ereignis von oben verwendet werden. Dieses sagt aus, dass nach\u00a01395220\u00a0<\/em>Nanosekunden der Wert 3 in das erste Feld des Arrays\u00a0EE_th_status<\/em>\u00a0auf den Kern mit der ID\u00a00<\/em>\u00a0geschrieben wurde. Diese Aussage kann f\u00fcr die Evaluierung von Echtzeitanforderungen jedoch nicht verwendet werden, da zur Interpretierung des Ereignisses auf Systemlevel zus\u00e4tzliche Informationen notwendig sind. Das Erika Enterprise Betriebssystem speichert den Zustand jedes Tasks in einem Feld des\u00a0EE_th_status<\/em>\u00a0Arrays. Das Feld mit dem Index\u00a00<\/em>\u00a0bezieht sich in diesem Beispiel auf den Task\u00a0T_IMS_0<\/em>. Abschlie\u00dfend kann die Aussage des Events umformuliert werden: nach\u00a01395220\u00a0<\/em>Nanosekunden wurde der Task\u00a0T_IMS_0<\/em>\u00a0auf dem Kern\u00a00<\/em>\u00a0terminiert.<\/p>\n Das OSEK Run Time Interface (ORTI) wurde spezifiziert, um die Zuordnung von Software- zu Systemobjekten f\u00fcr OSE-konforme Betriebssysteme zu erleichtern. Es erm\u00f6glicht beispielweise die Art und Weise, wie das Betriebssystem Taskzust\u00e4nde speichert, automatisch zu detektieren. Dass bedeutet, der Nutzer muss nicht zwingend wissen, dass\u00a0EE_th_status<\/em>\u00a0daf\u00fcr verwendet wird. Stattdessen kann diese Information aus der ORTI-Datei gelesen werden.<\/p>\n Jedoch stellt ORTI nicht zwingenderma\u00dfen Informationen f\u00fcr alle Systemobjekte, die f\u00fcr die Analyse des Echtzeitverhaltens von Systemen von Interesse sind, zur Verf\u00fcgung. Beispielsweise sind Runnables und Signale nicht durch ORTI abgedeckt. In diesem Fall ist es erforderlich, diese Informationen \u00fcber andere Wege bereitzustellen. Ansonsten ist eine Zuordnung und damit eine Transformation f\u00fcr bestimmte Objekte nicht m\u00f6glich. Das Instruction-Trace-Ereignis aus dem Beispiel von oben repr\u00e4sentiert den Start der Funktion\u00a0R_2_1<\/em>. Nur wenn zum Zeitpunkt der Transformation bekannt ist, dass diese Funktion auf Systemlevel einem Runnable enspricht, kann das korrekte Systemereignis erstellt werden.<\/p>\n Selbst wenn ein Objekttyp – so wie Tasks – von ORTI unterst\u00fctzt werden, k\u00f6nnen nicht zwingend alle Ereignisse auf Systemlevel rekonstruiert werden. Beispielsweise definiert BTF f\u00fcr Tasks ein\u00a0mtalimitexceeded<\/em>\u00a0Ereignis, das dann eintritt, wenn ein Task aktiviert wird, f\u00fcr den keine weitere Aktivierung erlaubt ist. \u00dcber das ORTI\u00a0lasterror\u00a0<\/em>Attribut ist es m\u00f6glich, diese Ereignisse zu erkennen, jedoch ist es nicht m\u00f6glich herauszufinden, f\u00fcr welchen Task das Ereignis ausgel\u00f6st wurde. In diesem Fall sind zus\u00e4tzliche Informationen \u00fcber die Funktionsweise des Betriebssystems notwendig. Erika Enterprise liest die Variable\u00a0EE_th_<\/em>rnact<\/em>, um festzustellen, ob eine weitere Taskaktivierung erlaubt ist. Falls nicht, wird direkt nach dem Lese-Ereignis der entsprechende Fehlercode in\u00a0lasterror<\/em>\u00a0geschrieben. Ist dieses Verhalten bekannt, kann trotz fehlender ORTI-Unterst\u00fctzung das Ereignis rekonstruiert werden.<\/p>\n Entsprechend dieser Beispiele k\u00f6nnen prinzipiell alle Ereignisse, die von BTF spezifiziet sind, von Software- auf Systemlevel transformiert werden. Je nachdem, welche Anforderungen validiert werden sollen, ist mehr oder weniger Detailwissen \u00fcber die Funktionsweisen des Betriebssystems notwendig.<\/p>\n Wie aus den vorherigen Sektionen hervorgeht, ist eine Anforderungsvalidierung via Tracing nicht trivial. Zuerst muss eine geeignete Trace-Technologie ausgew\u00e4hlt werden, anschlie\u00dfend m\u00fcssen die erzeugten Traces richtig interpretiert werden, um eine Echtzeitanalyse zu erm\u00f6glichen. Ein modellbasierter Entwicklungsansatz kann bei beiden Aufgaben unterst\u00fctzen.<\/p>\n Zur Aufzeichnung eines korrekten Traces ist die korrekte Konfiguration der Trace-Hardware notwendig. Diese ist einerseits vom Prozessor und andererseits vom verwendeten Betriebssystem abh\u00e4ngig. Das oben erw\u00e4hnte Modell des Systems enth\u00e4lt Informationen \u00fcber diese beiden Aspekte. Dies bedeutet, dass basierend auf dem Modell die korrekte Trace-Konfiguration automatisiert erstellt werden kann. Beispielsweise kann der korrekte Prozessortyp aus dem Hardwareteil und die korrekte Konfiguration des Daten-Traces aus dem Betriebssystemteil erstellt werden.<\/p>\n Dar\u00fcber hinaus kann der Applikationscode selbst automatisch aus dem Modell generiert werden. Das bedeutet, sobald ein Modell erstellt ist, kann ein erster Prototyp der Applikation auf realer Hardware getestet werden. Funktionen, die noch nicht implementiert sind, werden dabei durch Funktionsstubs, die Laufzeit entsprechend der Konfiguration im Modell verbrauchen, ersetzt. So bald neue Funktionsteile implementiert sind, werden die entsprechenden Stubs ersetzt. Basierend auf dem Zeitverhalten der realen Funktionen kann das Modell iterativ verbessert werden. Dieses Vorgehen erlaubt einen permanenten Abgleich zwischen Modell und realer Applikation und damit einhergehend eine kontinuierliche \u00dcberwachung der Anforderungen.<\/p>\n Mit einem automatisch generierten Prototyp der Applikation und der entsprechenden Trace-Konfiguration, welche ebenso automatisiert generiert wurde, k\u00f6nnen Hardware-Traces vollst\u00e4ndig automatisiert aufgezeichnet werden. Anschlie\u00dfend muss der Trace auf Systemlevel transformiert werden, um eine Zeitanalyse durchzuf\u00fchren. Ein Teil der daf\u00fcr notwendigen Informationen kann aus dem Modell extrahiert werden. Zum einen kann basierend auf dem Modell entschieden werden, welche Funktionen Runnables sind, zum anderen, welche Variablen Signale sind. Dementsprechend werden Ereignisse f\u00fcr alle Objekte, die f\u00fcr die Echtzeitanalyse von Bedeutung sind, erstellt.<\/p>\n Abschlie\u00dfend wird der erzeugte Trace evaluiert und mit den gestellten Anforderungen verglichen. Basierend auf den Ereignissen kann ein Report erstellt werden, der den momentaren Status der Applikation wiedergibt. Gen\u00fcgt das Zeitverhalten nicht den gestellten Anforderungen, kann dies anhand des Reports festgestellt und das Systemdesign verbessert werden. Nach der Verbesserung wird der Prozess erneut durchlaufen, bis das Systemverhalten den Anforderungen gen\u00fcgt. Abbildung 3 (siehe\u00a0PDF<\/a>) visualisiert dieses Vorgehen.<\/p>\n Ein modellbasierter Entwicklungsansatz erlaubt es, eingebettete Multi-Core-Applikationen bereits in der Designphase hinsichtlich ihres Zeitverhaltens zu untersuchen. Dies ist m\u00f6glich, ohne sich auf einen Prozessor oder ein Betriebssystem festzulegen. Dieser Beitrag zeigt, wie die Anforderungen, die in der Designphase gestellt und via Simulation validiert wurden, auch in der Implementierungsphase weiter \u00fcberwacht werden k\u00f6nnen. Dazu ist es notwendig, das Systemverhalten \u00fcber hardwarebasiertes Tracing aufzuzeichnen und den resultierenden Trace in ein geeignetes Format zu \u00fcbersetzen. Basierend auf einem Modell k\u00f6nnen diese Schritte automatisiert durchgef\u00fchrt werden.<\/p>\n Moderne Multi-Core Prozessoren unterst\u00fctzen drei Arten von Tracing. Im Moment werden nur zwei Arten zur Echtzeitvalidierung genutzt: Daten-Tracing und Instruction-Tracing. Die M\u00f6glichkeit, periphere Hardware, wie Timer Units oder CAN Module, via Signal-Tracing zu tracen, k\u00f6nnte in Zukunft dazu genutzt werden, das Kollektivverhalten von mehreren Prozessoren zu \u00fcberwachen. Das bedeutet, die einzelnen Prozessoren werden nicht isoliert voneinander betrachtet, sondern auch die Kommunikation zwischen den distinktiven Einheiten wird in die Analyse des Echtzeitverhaltens miteinbezogen.<\/p>\n
\n<\/strong><\/p>\nEinleitung<\/h2>\n
Tracing<\/h2>\n
Zuordnung<\/h2>\n
Automatisierung<\/h2>\n
Zusammenfassung und Ausblick<\/h2>\n
Quellenverzeichnis<\/h2>\n