Tab Ausführung¶

Mit dem Tab Ausführung ist es möglich, das Verhalten von ecu.test bei der Ausführung zu beeinflussen.

Zeitverhalten¶

Der Abschnitt Zeitverhalten legt fest aus welcher Quelle ecu.test während der Testausführung die Zeitstempel bezieht. Hierfür stehen die Echtzeit oder die Angabe eines Ports zur Verfügung.

Wird ein Port ausgewählt, so besteht zusätzlich die Möglichkeit zu wählen ob die Simulation in Schritten ausgeführt wird oder aber kontinuierlich laufen soll.

Eine Schrittweise Ausführung lässt die Simulation nur dann fort schreiten wenn explizit im Testfall gewartet wird oder eine entsprechend geeigneter Testschritt ausgeführt wird (Wait-Testschritt, Zeitoptionen oder Diagnose-Testschritt). Sonst befindet sich die Umgebung im Stillstand, was zeitgleiche Zugriffe oder komplexere Untersuchungen eines exakten Zeitpunktes ermöglicht.

Bei kontinuierlicher Ausführung läuft die Simulation ohne Unterbrechung und ecu.test ermittelt vom gewählten Port regelmäßig den aktuellen Zeitstempel um den Testfall mit der Simulation zu synchronisieren.

Mit Wartezeit nach jedem I/O Testschritt ist es möglich, künstliche Verzögerungen in den Testablauf einzufügen.

Details zu den Zeitmodi¶

ecu.test erlaubt die Testfallausführung in verschiedenen Zeitmodi. Der Zeitmodus bestimmt die Zeitquelle, die im Testfall (z.B. von Wait-Testschritten) verwendet wird. Dies kann entweder die lokale Rechneruhr oder aber die Simulationszeit in einem Simulationstool sein. Außerdem legt der Zeitmodus fest, ob die zeitgebende Simulation schrittweise und durch die Testausführung getrieben oder aber kontinuierlich und parallel zur Testausführung abläuft. Die Eigenschaften der verschiedenen Zeitmodi werden im Folgenden erklärt.

Echtzeit¶

Wird der Testfall in Echtzeit ausgeführt, so nimmt ecu.test an, dass alle angesteuerten Werkzeuge auch fähig sind, in Echtzeit zu arbeiten. Es wird in diesem Fall keine Synchronisation der Zeiten in Testfall und in den Tools vorgenommen. Wird ein Wait-Testschritt ausgeführt, wartet ecu.test selbst die angegebene Zeitspanne in Echtzeit, bis der Testfall weitergeführt wird. Dieses Verhalten bietet sich bei Echtzeit-Modellen in einer HiL-Umgebung an, da das Modell mit realitätsnahen Zeitverhalten ausgeführt wird.

In einer MiL- oder SiL-Umgebung kann ein realistisches Zeitverhalten in Echtzeit hingegen häufig nicht realisiert werden. Wenn ecu.test in einer solchen Situation selbst die Zeitspanne wartet, kann es passieren, dass die simulierte Zeit stark davon abweicht.

Wie viel schneller die Simulation im Vergleich zur Echtzeit abläuft, kann für einen konreten Zeitraum über einen Speedup-Faktor beschrieben werden: Dauer in Echtzeit * Speedup-Faktor = Dauer in Simulationszeit.

ecu.test bietet die Möglichkeit, den Testfall statt in Echtzeit in Simulationszeit auszuführen. Hierbei stehen zwei Modi zur Verfügung:

Schrittweise Ausführung in Simulationszeit¶

Ist dieser Modus aktiviert, verwendet ecu.test die Modellzeit der Simulations-Plattform als Zeitbasis für die Testausführung. Das macht den Testfall völlig unabhängig von der Echtzeit und hat zur Folge, dass Testschritte im Testfall keine reale Verzögerung aufweisen. Nur explizit formulierte Verzögerungen werden simuliert. Die Verwendung des Testschritts Wait hat also bspw. zur Folge, dass ecu.test das jeweilige Tool anweist, die angegebene Zeit zu simulieren, anstatt aktiv zu warten. Selbiges gilt für die Zeitoptionen im Lesen Testschritt.

I/O Testschritte haben in diesem Modus keine zeitliche Ausdehnung. Soll diese künstlich hinzugefügt werden, ist dies über die Option Wartezeit nach jedem I/O Testschritt in der Testkonfiguration auf dem Tab Ausführung möglich.

Kontinuierliche Ausführung in Simulationszeit¶

In diesem Modus läuft die Simulation kontinuierlich, ohne unterbrochen zu werden. ecu.test ermittelt derweil die Zeitstempel über einen als Zeitquelle konfigurierten Port. Diese Zeitstempel werden analog zur Echtzeit für explizite Verzögerungen wie Wait verwendet. Alle anderen Aktionen im Testfall werden ebenfalls ausgeführt, während die Simulationszeit voranschreitet. Zu beachten ist, dass die Ausführungszeit einer Berechnung in ecu.test den Ressourcen des PCs und der Echtzeit unterworfen sind, da sie nicht simuliert werden. Das führt zu stark unterschiedlichen Ausführungszeiten für Berechnungen im Report, abhängig von Speedup-Faktor der Simulation.

Fehlerbehandlung¶

Der Abschnitt Fehlerbehandlung konfiguriert das Verhalten bei Auftreten eines Fehlers während der Ausführung. Mit Hilfe der obersten Auswahl kann gewählt werden, ob bei einem ERROR -bewerteten Testschritt mit dem nächsten Testschritt fortgefahren wird oder die Packageausführung abgebrochen werden soll. Im Fall einer Projektausführung wird dann mit dem nachfolgenden Projektschritt fortgesetzt.

Direkt darunter kann ein Package angegeben werden, das nach einem Abbruch oder am Ende eines Testfalls, in dem Fehler aufgetreten sind, ausgeführt werden soll. Nach Ankreuzen der Option kann man im Auswahlfeld festlegen, ob es nur bei Abbruch, auch bei ERROR, oder bereits bei FAILED ausgeführt werden soll. In dem darunterliegenden Textfeld kann man den vollständigen Pfad der auszuführenden Package-Datei entweder eintippen bzw. einfügen, oder über den angrenzenden Button einen Dialog öffnen, über den das Package im Dateisystem gewählt werden kann.

Als Abbruch (der bei entsprechender Konfiguration die Ausführung des Fehlerbehandlungs-Package zur Folge hat) zählt jeder Abbruch der Testausführung, egal ob z.B. durch die o.g. Option Test abbrechen, durch Klick auf den Abbrechen-Button des Ausführungsdialogs, durch einen Abbrechen-Testschritt, durch einen Block mit gesetzter Option Bedingter Testabbruch oder durch einen API-Aufruf.

Für die Ausführung des Fehlerbehandlungs-Package bei ERROR - oder FAILED -Bewertung werden Testschritt-Bewertungen, die durch einen Assertion-Testschritt in eine bessere Bewertung umgewandelt werden, nicht berücksichtigt.

Automatisches Zurücksetzen von Testgrößen¶

Im Abschnitt Automatisches Zurücksetzen von Testgrößen kann ecu.test dazu veranlasst werden, nach jedem durchgeführten Test alle geschriebenen Größen, ggf. erst nach Bestätigung, wieder auf ihre Originalwerte zurückzusetzen.

Wenn der Modus „Nur Testgrößen auf ausgewählten Ports zurücksetzen“ ausgewählt wurde, können die zurückzusetzenden Ports aus einer Liste ausgewählt werden. Zur Auswahl stehen nur Ports, die in der Testkonfiguration verknüpft sind und das Zurücksetzen von Testgrößen unterstützen (Modell-, Bus-, Umgebungs-, und Applikations-Ports).

Globale Pre- und Postcondition¶

Der Abschnitt Globale Pre- und Postcondition ermöglicht es, Packages zu hinterlegen, die bei der Ausführung vor (Precondition) oder nach (Postcondition) jedem Package ausgeführt werden. Der Packagepfad kann relativ zum Packages-Verzeichnis oder absolut angegeben werden.

Existiert im Package bereits eine lokale Pre- oder Postcondition, so wird die globale Precondition als erster Testschritt in die lokale Precondition eingefügt und die globale Postcondition als letzter Testschritt in der lokalen Postcondition. Andernfalls werden die globale Pre- und Postcondition automatisch ergänzt und so auch im Report kenntlich gemacht. Bei der Testfallerstellung werden die globalen Pre- und Postpackages nicht angezeigt. Im Report sind sie einfach an der Zeilennummer PRE, bzw. POST und am Eintrag im Bemerkungsfeld erkennbar.

Hinweis: Das Starten von Aufzeichnungen in der globalen Precondition und das Stoppen von dieser in der globalen Postcondition ist nicht möglich.

Globale Wiederholungseinstellungen¶

Dieser Abschnitt ermöglicht es Wiederholungseinstellungen vorzunehmen, die für alle ausgeführten Projekte gültig sind, außer sie sind in den jeweiligen Projekten lokal überschrieben.

Default-Aufnahmekonfiguration¶

Hier ist es möglich ein Package mit einer Default-Aufnahmekonfiguration anzugeben.