Echtzeit-Tests

Ein Echtzeit-Test ist ein Software-Test, welcher auf einem Echtzeit-System zur Ausführung kommt. Echtzeit-Tests werden vor allem im Bereich der HiL-Tests angewendet, weil hier zwangsläufig ein Echtzeit-System zum Einsatz kommt, auf dem das Umgebungsmodell läuft. Auf diesem Echtzeit-System wird auch der Echtzeit-Test konkurrierend zum Modell ausgeführt. In jedem Modell- bzw. Simulations- Takt wird neben der Modell-Task auch ein oder mehrere Anweisungen des Echtzeit-Tests ausgeführt:

../_images/RTTvsModelTask.png

Der große Vorteil eines Echtzeit-Tests gegenüber eines nicht in Echtzeit ausgeführten Tests ist der, dass in einem Simulationsschritt mehrere Instruktionen ausgeführt werden können, bevor die Modellzeit voranschreitet. Die Anzahl der maximal ausführbaren Testschritte wird dabei durch die Rechenzeit des Modells und der Simulations-Schrittweite begrenzt.

Erstellung von Echtzeit-Tests

Echtzeit-Tests werden in ecu.test als normale Testpackages erstellt und verwendet. Um ein Package in Echtzeit auszuführen, muss dieses lediglich auf spezielle Art referenziert werden. Eine solche Referenz wird „Echtzeit-Referenz“ oder „Parallele Echtzeit-Referenz“ genannt:

../_images/Tutorial_RTT_Referenz.png

Es ist daher möglich, dasselbe Package sowohl in Echtzeit als auch normal auszuführen. Entscheidend ist jeweils nur die Art der Referenz auf das jeweilige Package.

Der Ersteller eines Echtzeit-Tests muss sich bewusst sein, dass die Ausführung des Tests die Echtzeit-Fähigkeit des Umgebungsmodells gefährden kann. In diesem Fall wird der Package-Aufruf in ecu.test mit ERROR bewertet und eine Fehlermeldung ausgegeben.

Um zu verhindern, dass entsprechende Überläufe auftreten muss der Testfall angepasst werden, sodass das Modell öfter Rechenzeit zugeteilt bekommt. Folgende Mittel können hierfür verwendet werden:

  • Warte-Testschritte oder Testschritte mit Zeitoptionen verwenden. (bei jedem Warten im Testfall wird das Modell um die entsprechende Modellzeit berechnet)

  • „nicht-dokumentieren“ bzw. „nicht-dokumentieren-für“ an Container-Testschritten im RTT-Package verwenden. Das Aufbereiten und Versenden der Report-Daten nimmt zusätzliche Rechenzeit auf dem Echtzeit-System in Anspruch, daher kann „nicht-dokumentieren“ (besonders bei Schleifen) eine deutliche Reduktion der Rechenzeit bewirken.

../_images/RTT_WaitForModelProgress.png

Die ersten beiden Testschritte werden im selben Simulations-Schritt ausgeführt. Während des Warte-Testschritts wird die Rechenzeit an das Modell gegeben. Die letzten beiden Testschritte werden dementsprechend wieder im gleichen Simulations-Schritt ausgeführt.

Ausführung von Echtzeit-Tests

ecu.test unterstützt die Ausführung von Echtzeit-Tests mit HiL-Plattformen von dSPACE. Um einen Echtzeit-Test ausführen zu können, muss in der aktiven Testbenchkonfiguration ein Modell-Port für ControlDesk verbunden sein. Hilfe zur Erstellung von Testbench- und Testkonfiguration sind unter Testkonfigurationseditor bzw. Testbenchkonfigurationseditor zu finden.

Die Ausführung von parallelen Echtzeit-Referenzen wird immer vollständig auf das Echtzeit-System verlagert. Bei einer parallelen Referenz verläuft die Ausführung des Echtzeit-Teststrangs vollständig asynchron zum Teststrang des Haupt-Packages. Eine Synchronisierung mit dem Echtzeit-Strang passiert nur am Ende des Testfalls oder beim Zugriff auf Rückgabe-Variablen des RTT Packages.

Für dSpace Plattformen erzeugt ecu.test für jede Echtzeit-Referenz eine sogenannte Echtzeit-Sequenz auf dem Echtzeit-Rechner. Eine Echtzeit-Sequenz kann als eine ausführbare Routine verstanden werden, welche nach ihrer Erzeugung auf einen Start-Befehl wartet. Die Erzeugung der Echtzeit-Sequenzen erfolgt in der Initialisierungsphase des Haupt-Packages. Dadurch wird gewährleistet, dass während der Testfallausführung keine Rechenzeit unnötig vergeudet wird. Es ist möglich ein und dieselbe Echtzeit-Referenz mehrfach auszuführen. Hierbei muss allerdings sichergestellt werden, dass die vorhergehende Sequenz bereits terminiert ist, bevor die jeweils nächste startet. Dies soll durch folgendes Beispiel verdeutlicht werden:

../_images/RTT_LoopReference.png

In dem dargestellten Beispiel wird ein Package innerhalb einer Schleife 10 mal über eine parallele Echtzeit-Referenz ausgeführt. Die Ausführung dieses Packages wird zu einem Fehler führen, denn es wird versucht, die zugehörige Echtzeit-Sequenz ein zweites Mal zu starten, obwohl die erste Ausführung noch nicht beendet ist. Die Verwendung einer synchronen Referenz würde diesen Fehler beheben.

Buszugriff

ecu.test unterstützt in Echtzeit-Packages den Zugriff auf modellbasierte Bus-Ports. Zu beachten ist, dass Bustestschritte vor der Ausführung in entsprechende Modelltestschritte übersetzt werden. Im resultierenden Testreport werden dann statt des urspünglichen Bustestschritt ein oder mehrere Modelltestschritte aufgelistet.

Voraussetzungen

Um mit ecu.test Echtzeit-Tests unter Linux ausführen zu können, muss auf dem ecu.test-Rechner eine Java Runtime Environment 17 oder höher installiert sein. Für Windows ist die JRE-17 bereits in der ecu.test-Installation enthalten. Des Weiteren muss auf dem Tool-Host-Rechner eine entsprechende Lizenz zum Ausführen von Echtzeit-Tests bereitgestellt worden sein.

ecu.test unterstützt die Ausführung von Echtzeit-Tests aktuell nur auf HiL-Plattformen von dSPACE. Um einen Echtzeit-Test ausführen zu können, muss in der aktiven Testbenchkonfiguration ein Modell-Port für ControlDesk verbunden sein. Jedoch werden ab dSpace ControlDesk 2024-B Echtzeit-Tests nicht mehr unterstützt. Hilfe zur Erstellung von Testbench- und Testkonfiguration sind unter Testkonfigurationseditor bzw. Testbenchkonfigurationseditor zu finden.

Einschränkungen

Folgende Einschränken existieren derzeit für die Ausführung von Echtzeit-Tests mit ecu.test:

  • In Echtzeit-Packages dürfen nicht alle verfügbaren Testschritte verwendet werden, die in ecu.test angeboten werden. Folgende Testschritte werden unterstützt:

    • Verzweigungen (If-Then-Else)

    • Schleifen

    • Blöcke

    • Warte-Testschritte

    • Berechungen (ohne Zeitoptionen)

    • Kommentare (werden zwar unterstützt, aber nicht ausgewertet)

    • Modell-Lesen und -Schreiben (die Verwendung von Zeitoptionen beim Lesen ist möglich)

    • Bus-Lesen und -Schreiben (es muss sich um modellbasierte Buszugriffe handeln)

    • Multi-Check (mit Zeitoptionen)

    • Return

  • Es dürfen nur numerische und String Testfall-Variablen verwendet werden.

  • In Echtzeit-Packages dürfen keine anderen Packages referenziert werden.

  • „nicht-dokumentieren“ bzw. „nicht-dokumentieren-für“ funktioniert nur für (Container-) Testschritte innerhalb des RTT-Packages und verhindert nicht die Rückgabe des Resultats in übergeordnete Packages.