Echtzeitverhalten simulieren und validieren
Modell sorgt für gutes Timing
Echtzeitmodelle erlauben es, Timing-Aspekte in der Entwicklung gezielt anzugehen. Ihre Simulation verdeutlicht zeitliche Zusammenhänge, über die Validierung lassen sich die Worst- und Best-Case-Situationen absichern. Durch die Kombination beider Verfahren können Entwickler die Grenzen des Echtzeitverhaltens sicher erfassen und die Relevanz kritischer Situationen beurteilen.
Die Echtzeitfähigkeit von Embedded Systemen bestimmt wesentlich, wie sicher und zuverlässig sie ihre Aufgaben erfüllen. Treten Echtzeitfehler auf, sind deren Ursachen schwer zu analysieren. Denn es müssen nicht nur bestimmte Zustände im Gesamtsystem statisch vorliegen, sie müssen auch dynamisch zur richtigen Zeit auftreten, um den Fehler zu provozieren.
Scheinbar funktionale Fehler haben ihren Ursprung häufig in mangelhaftem Echtzeitverhalten. In der Entwicklung war es bislang schwierig, das Echtzeitverhalten sicherzustellen – in frühen Phasen mangels vollständiger Hard- und Software, in späten Phasen auf Grund hoher Komplexität.
Mithilfe des hier vorgestellten modellbasierten Ansatzes lassen sich diese Probleme überwinden, indem Timing-Aspekte in der Entwicklung gezielt adressiert werden. Man muss längst keine Lanze mehr für Modellierung und Simulation brechen. Das bessere Verständnis komplexer Zusammenhänge durch Simulationsmodelle ist in vielen Bereichen der Naturwissenschaften und Ingenieursdisziplinen längst bewiesen.
Was für Bauingenieure und Regelungstechniker, Biologen und Finanzmathematiker alltägliche Praxis ist, bietet auch beim Bestimmen des Echtzeitverhaltens von Embedded Systemen enorme Vorteile. Bildet man das Echtzeitverhalten durch ein Simulationsmodell nach, so sind detaillierte Analysen über lange Zeiträume innerhalb kurzer Zeit möglich.
Im Simulator können vom System beliebig lange Simulationsläufe durchgeführt und verschiedene, komplexe Stimulationsszenarien durchlaufen werden. Grundvoraussetzung dafür ist, dass das Modell das System korrekt darstellt und die dynamischen Abläufe und kausalen Zusammenhänge (Ablaufreihenfolgen, Reaktion auf bestimmte Stimuli, etc.) mit simuliert werden.
Das Echtzeitmodell beschreibt die einzelnen Prozesse (Tasks und ISR) mit ihren Ausführungszeiten auf einer abstrakten Ebene, so lässt sich das Scheduling leicht nachvollziehen. Der Simulator stößt die zeit- und ereignisgesteuerten Vorgänge gemäß dem Scheduling des Betriebssystems an und stellt sie in aussagekräftigen Diagrammen und Statistiken dar.
Ein Vergleich der gemessenen und simulierten Traces gibt dem Entwickler ein Maß, wie gut das Modell mit der Realität übereinstimmt. In der Praxis hat sich gezeigt, dass sich schon mit abstrakten Echtzeitmodellen alle Timing-Probleme eines komplexen Motorsteuergerätes nachvollziehen ließen [Wir09].
Task-Modell beschreibt Echtzeitverhalten
Echtzeitmodelle für die Tool-Suite von Inchron beschreiben den dynamischen Rechenzeitbedarf und den Ablauf des Source-Codes auf dem Target.
Jobangebote+ passend zum Thema
Sie können in C geschrieben werden, um zum einen eine vertraute Notation zu bieten und zum anderen einen fließenden Übergang vom Modell zum realen Quellcode zu ermöglichen (Bild 1). Alternativ kann der Anwender das System in der Oberfläche der Tool-Suite oder in »Rhapsody«, »PREEvision « oder »Escape« [*] modellieren und das Zeitverhalten annotieren.
Dabei nutzen die Modelle die Betriebssystemaufrufe des gewählten Target-RTOS wie z.B. OSEK, das von der Tool-Suite zur Verfügung gestellt wird. Tasks und Interrupt-Serviceroutinen (ISRs) werden mit Standard-Betriebssystem-Notation geschrieben und deren Rechenzeit darin als Verzögerungszeit mit dem Schlüsselwort »DELAY()« annotiert.
Die in DELAY() spezifizierten Ausführungszeiten definiert der Systemarchitekt nach Annahmen oder Vorgaben. Auch aus Vorgängersystemen gemessene Laufzeiten lassen sich für das Modell verwenden. Je weiter die Entwicklung fortschreitet, desto feingranularer werden Ausführungszeiten ermittelt und im Task-Modell eingesetzt.
Abläufe und kausale Zusammenhänge, die zu unterschiedlichen Datenpfaden und damit Ausführungsreihenfolgen beziehungsweise -verzögerungen führen, lassen sich im Task-Modell mit allen Mitteln abbilden, die C bietet.
- Wirkketten:
Die Funktion eines Embedded Systems ist auch mit Hilfe von Wirkketten (engl. Event Chains) beschreibbar. Sie verlaufen von Sensoren und Eingängen über verschiedene Hardware- und Softwarekomponenten zur Applikationssoftware, wo aus den Eingangsdaten und Systemzuständen eine Reaktion des Systems ermittelt wird.
Diese wird wieder über verschiedene Komponenten zu den Aktoren übertragen. Die Ausführungszeit der Wirkkette hängt dabei von vielen Faktoren ab. Zustandsautomaten müssen in definierten Zuständen sein, Eingangswerte in vorgegebenen Bereichen, und all dies zum richtigen Zeitpunkt.
Da viele Wirkketten für verschiedene Funktionen gemeinsam ablaufen, interagieren und interferieren sie häufig. Diese Zusammenhänge statisch zu beschreiben ist bereits eine komplexe Aufgabe. Im dynamischen, zeitlichen Zusammenhang betrachtet, ist eine Beherrschung des Systems nur mit Hilfe von Echtzeitmodellen möglich [Kra09].
Mit Hilfe der Task-Modelle und Wirkketten lassen sich nun die Ablaufdetails der Einzelkomponenten (und damit die verteilte Detailkenntnis jeder Entwicklergruppe) in einem gemeinsamen Simulationsmodell erfassen.
Die Analyse der Wirkketten hilft allen Beteiligten, die Abläufe im Ganzen besser zu verstehen und die Pfade durch das System zu identifizieren, deren Verhalten echtzeitkritisch ist (Bild 2) [Aug10].
- Simulation:
Der Simulator führt das Modell aus und zeichnet dabei alle Ereignisse auf. Diese lassen sich mit verschiedenen Diagrammen übersichtlich darstellen und vielfältig analysieren.
Bild 3 zeigt Beispiele der Ausgaben von »chronSIM«. Das Task-Zustandsdiagramm zeigt Tasks zweier Steuergeräte, die über FlexRay kommunizieren. Da sie asynchron zum Bus sind, kommt es zu Mehrfachverwendung und Verlust von Daten.
Zunächst wird das System in diversen Betriebszuständen mit chronSIM simuliert und die Auswirkung auf das Timing einzelner Tasks und der CPU-Last beobachtet. Gezieltes Variieren der Stimuli und Ausführungszeiten ermöglicht eine Sensitivitätsanalyse.
Sofern die Ausführungszeiten einzelner Funktionsmodule mit eigenem DELAY() innerhalb der Tasks definiert sind, lässt sich sogar untersuchen, wie sich eine Verschiebung von Funktionsblöcken in andere Tasks auf das Zeitverhalten auswirken würde. Eine Architektur mit Hilfe der Echtzeitsimulation zu analysieren ist erheblich zeitsparender als das herkömmliche Vorgehen.
Als Resultat erhält man ein robusteres System und besseres Verständnis des dynamischen Verhaltens [Wol09].
- Modell sorgt für gutes Timing
- Modell sorgt für gutes Timing
