Echtzeitverhalten simulieren und validieren
Modell sorgt für gutes Timing
Fortsetzung des Artikels von Teil 1
Modell sorgt für gutes Timing
- Validierung:
Mit der Simulation eines Systems lassen sich viele verschiedene Systemzustände einfach erreichen und testen. Hierbei gilt für die Simulation das Gleiche wie für Testfahrten, »Hardware in the Loop«-Systeme oder automatisierte Modultests.
Je besser der Zustandsraum dabei abgedeckt wird, desto besser ist auch die Testabdeckung. Ob man aber alle möglichen Zustände geprüft, also keine kritische Situation übersehen hat, wird durch ausgiebigeres Simulieren und Testen nur wahrscheinlicher – nicht absolut sicher.
Man betrachtet das System unter Umständen optimistisch. Die Validierung ermittelt mit mathematischen Algorithmen alle best- und schlimmstmöglichen Zustände eines Systems und überprüft für diese Fälle, ob es dann noch die Anforderungen einhält. Da viele Kombinationen von Ein- und Ausgangszuständen eventuell nie erreicht werden, aber in der Validierung abgedeckt sind, ist die Überprüfung hiermit sicher – aber pessimistisch.
Gute Zeiten, schlechte Zeiten
Jobangebote+ passend zum Thema
Für eine Validierung des Echtzeitverhaltens wird das bereits für die Simulation erstellte Modell in »chronVAL« analysiert.
Die Algorithmen ermitteln die Best- und Worst-Case-Ausführungszeiten der Software des Embedded Systems.
Mit diesen Werten lassen sich verschiedene Analysen durchführen. Ein Response-Time-Diagramm stellt die Antwortzeiten einzelner Prozesse über erschiedene Ebenen dar.
Diese Ansicht zeigt Ausschnitte und ganze Wirkketten und stellt deren Ende-zu-Ende-Antwortzeit detailliert dar.
Hängt sie von verschiedenen anderen Prozessen ab, sind diese hierarchisch aufgezeigt. Dies beantwortet die Frage, wann besten- oder schlimmstenfalls das System auf ein Ereignis reagiert (Bild 4). Die Einhaltung von Echtzeitanforderungen ist direkt überprüfbar.
- Ereignisspektralanalyse:
Häufig ist interessant, wie viele Ressourcen noch frei sind und wieviel Performance einzelne Prozesse beanspruchen. Hierfür betrachtet man das Ereignisspektrum im Intervallbereich gemäß der Frage: »Wie viele beziehungsweise welche Ereignisse treten in einem Zeitintervall maximal beziehungsweise minimal auf«?
Daraus lässt sich dann direkt ablesen, welche Systemperformance für ein Intervall verfügbar ist. Jede Komponente kann auf ihre angeforderte Leistung
hin untersucht werden.
In der Kombination liegt die Kraft
Wie bereits erwähnt, kann die Simulation optimistisch sein, gibt aber ein genaues Bild der Ereignisse und Abläufe des Systems wieder. Es lässt sich genau nachvollziehen, welche Prozesse nacheinander oder parallel abliefen und sich dabei gegenseitig beeinflusst haben.
Statistische Auswertungen der Auftretenshäufigkeit von Ereignissen und Ausführungszeiten vermitteln ein Bild des dynamischen Verhaltens über längere Zeit und nicht nur über kurze Messungen. Das dynamische Systemverhalten ist in verschiedenen Zuständen beobachtbar und wird somit transparent.
Die Validierung zeigt sicher auf, welche Best- und Worst-Case-Fälle im System auftreten können. Daraus ergibt sich, welche Antwortzeiten und Performance-Reserven im besten oder ungünstigsten Fall zu erwarten sind. Die Validierung ist zwangsläufig etwas pessimistisch, denn die ungünstigsten, weil längsten Ausführungszeiten aller Prozesse werden mit der höchstmöglichen Aktivierungsrate berücksichtigt – auch wenn diese gegebenenfalls nie gleichzeitig auftreten werden.
Je detaillierter das System modelliert wird, desto geringer wird jedoch der Pessimismus. Hält das Modell eine Echtzeitanforderung nicht ein, gilt es zu beurteilen, ob dieser Fall relevant ist oder praktisch nie auftreten wird. Die Validierung wird diesen Fall zunächst sicher aufzeigen.
Mit Hilfe der Simulation wird der Entwickler die Situation, die zu der Echtzeitverletzung führte, anschließend nachvollziehen und untersuchen. Durch statistische Auswertungen und ein klares Verständnis der Systemzustände lässt sich beurteilen, ob der in der Validierung ermittelte Worst-Case-Fall relevant für das System ist.
Mit der Kombination beider Verfahren können sich die jeweiligen Vorteile ergänzen. So wird gewährleistet, dass der Entwickler das Systemverhalten wohl versteht und dabei auch alle kritischen Situationen berücksichtigt. Dieses Systemverständnis frühzeitig im Entwicklungsprozess zu verbessern, ist für aktuelle und zukünftige, vernetzte Embedded Systeme unabdingbar.
Literatur:
[Aug10] B. Augustin; Integration von bisher eigenständigen Steuergeräten und Funktionen – Herausforderungen eines Kollaborationsprojektes; 2. Fachkongress Echtzeitentwicklung 2010; www.echtzeitkongress.de
[Kra09] T. Kramer, R. Münzenberger; New Functions, New Sensors, New Architectures – How to Cope with the Real-Time Requirements; In proceedings of Advanced Microsystems for Automotive Applications 2009, Berlin; www.amaa.de; ISBN 978-3-642-00744-6
[Wir09] G. Wirrer; Scheduling Simulation for ECS all along the Development Cycle; In proceedings of Fachkongress Echtzeitentwicklung 2009, Munich; www.echtzeitkongress.de
[Wol09] A. Wolfram, M. Makarov, T. Kramer, W. Ramisch, R. Münzenberger; Design of Robust System Architectures for Automotive ECUs; In proceedings of Conquest 2009, Nuremberg; www.isqi.org/conferences/conquest
[*] PREEvision von aquintos; IBM Rational Rhapsody; ESCAPE von Gigatronik
- Modell sorgt für gutes Timing
- Modell sorgt für gutes Timing
