Automatische Multi-Core-Echtzeitvalidierung

Anbieter zum Thema

Zuordnung

In der Einleitung wurde beschrieben wie Anforderungen für Systemobjekte wie Tasks und Signale definiert werden können. Im Gegensatz dazu, beziehen sich Ereignisse die beim hardwarebasierten Tracing aufgezeichnet werden auf Softwareobjekte, also Entitäten die auf Source-Code-Level definiert sind, so wie Variablen und Funktionen.

Um hardwarebasierte Traces für die Validierung von Echzeitanforderungen zu verwenden ist es also notwendig die Traces von Softwarelevel auf Systemlevel zu transformieren, was in Bild 2 (vgl. Bildergalerie) veranschaulicht wird. Dafür müssen die verschiedenen Systemergeignisse den entsprechenden Ereignissen auf Softwarelevel zugeordnet werden. Zur Representation des Traces auf Systemlevel ist außerdem ein geeignets Format wie das Best Trace Format (BTF) [8] notwendig.

Zur Verdeutlichung der Transformation soll das Datatrace-Ereignis von oben verwendet werden. Dieses sagt aus, dass nach 1395220 Nanosekunden der Wert 3 in das erste Feld des Arrays EE_th_status auf den Kern mit der ID 0 geschrieben wurde. Diese Aussage kann für die Evaluierung von Echzeitanforderungen jedoch nicht verwendet werden, da zur Interpretierung des Ereignisses auf Systemlevel zusätzliche Informationen notwendig sind.

Das Betriebssystem Erika Enterprise speichert den Zustand jedes Tasks in einem Feld des EE_th_status Arrays. Das Feld mit dem Index 0 bezieht sich in diesem Beispiel auf den Task T_1MS_0. Abschließend muss noch bekannt sein, dass der Wert 3 dem Taskzustand suspended entspricht. Folglich kann die Aussage des Events umformuliert werden: nach 1395220 Nanosekunden wurde der Task T_1MS_0 auf dem Kern 0 terminiert.

Das OSEK Run Time Interface (ORTI) wurde spezifiert um die Zuordnung von Software- zu Systemobjekten für OSEK konforme Betriebssysteme zu erleichtern. Es ermöglicht beispielweise die Art und Weise, wie das Betriebssystem Taskzustände speichert automatisch zu detektieren. Das bedeutet der Nutzer muss nicht zwingend wissen, dass EE_th_status dafür verwendet wird. Stattdessen kann diese Information aus der ORTI Datei gelesen werden.

Jedoch stellt ORTI nicht zwingendermaßend Informationen für alle Systemobjekte die für die Analyse des Echtzeitverhaltes von Systemen von Interesse sind zur Verfügung. Beispielsweise sind Runnables und Signale nicht durch ORTI abgedeckt. In diesem Fall ist es erforderlich diese Informationen über andere Wege bereitzustellen. Ansonsten ist einen Zuordnung und damit eine Transformation für bestimmte Objekte nicht möglich. Das Instructiontrace-Ereignis aus dem Beispiel von oben repräsentiert den Start der Funktion R_2_1. Nur wenn zum Zeitpunkt der Transformation bekannst ist, dass diese Funktion auf Systemlevel einem Runnable entspricht, kann das korrekte Systemereignis erstellt werden.

Selbst wenn ein Objekttyp – so wie Tasks – von ORTI unterstützt werden, können nicht zwingend alle Ereignisse auf Systemlevel rekonstruiert werden. Beispielsweise definiert BTF für Tasks ein mtalimitexceeded Ereignis das dann eintritt, wenn ein Task aktiviert wird, für den keine weitere Aktivierung erlaubt ist. Über das ORTI lasterror Attribut ist es möglich diese Ereignisse zu erkennen, jedoch ist es nicht möglich herauszufinden, für welchen Task das Ereignis ausgelöst wurde.

In diesem Fall sind zusätzliche Informationen über die Funktionsweise des Betriebssystems notwendig. Erika Enterprise liest die Variable EE_th_rnact um festzustellen ob eine weitere Taskaktivierung erlaubt ist. Falls nicht wird direkt nach dem Lese-Ereignis der entsprechende Fehlercode in lasterror geschrieben. Ist dieses Verhalten bekannt kann trotz fehlender ORTI-Unterstützung das Ereignis rekonstruiert werden.

Entsprechend dieser Beispiele können prinzipiell alle Ereignisse die von BTF spezifiziert sind von Software- auf Systemlevel transformiert werden. Je nachdem welche Anforderungen validiert werden sollen ist mehr oder weniger Detailwissen über die Funktionsweise des Betriebssystems notwendig.

(ID:44202462)