ecu.test steht neben Windows ab sofort auch unter Linux mit vollständiger grafischer Benutzeroberfläche zur Verfügung. Tests können damit direkt in der gewohnten Linux-Umgebung erstellt, ausgeführt und ausgewertet werden, ohne den Umweg über Windows für Anpassungen an Tests und Konfigurationen gehen zu müssen.
Die neue ecu.test Linux GUI nutzt Ubuntu 24.04 und vereinfacht zusammen mit dem ecu.test Linux Runner die Entwicklung und Absicherung moderner SDVs.
So lässt sich die vorhandene Linux-Infrastruktur effizienter nutzen, und es eröffnen sich neue Anwendungsfälle – bis hin zu remote betriebenen, im Browser gestreamten Systemen.
ecu.test Release 2026.1
Highlights auf einen Blick
ecu.test Linux GUI
CAN-FD Timing Helper
Das neue Utility CAN-FD Timing Helper vereinfacht die Testbenchkonfiguration für CAN-FD-fähige Bushardware.
Auf Basis der parametrierten Bitraten, Sample Points und der Oszillator-Frequenz werden die fehlenden Parameter – Synchronization-Jump und die Zeitsegmente – automatisch ermittelt und visualisiert.
Die manuelle Parametrierung in der Testbenchkonfiguration mit abweichenden Werten ist optional weiterhin möglich, aber nicht mehr zwingend erforderlich. Zusätzlich können einmal ermittelte Werte per Knopfdruck vollständig kopiert und auf anderen Ports eingefügt werden.
Auf Basis der parametrierten Bitraten, Sample Points und der Oszillator-Frequenz werden die fehlenden Parameter – Synchronization-Jump und die Zeitsegmente – automatisch ermittelt und visualisiert.
Die manuelle Parametrierung in der Testbenchkonfiguration mit abweichenden Werten ist optional weiterhin möglich, aber nicht mehr zwingend erforderlich. Zusätzlich können einmal ermittelte Werte per Knopfdruck vollständig kopiert und auf anderen Ports eingefügt werden.
Paralleler Toolstart
Der Betrieb der Testinfrastruktur ist mit hohen Kosten verbunden. Zeiten in denen die Testbench und deren Tools konfiguriert werden, müssen von der kostbaren Testzeit abgezogen werden und tragen, wenngleich der Konfigurationsstart nötig ist, nicht zu den eigentlichen Tests bei.
Insbesondere bei umfangreichen Testbenchkonfigurationen (TBC), mit vielen Tools, kann sich der Start der Konfiguration hinziehen. Die Aufstartzeit eines Tools hängt dabei stark von den benötigten Konfigurationsschritten, dem Umfang der Konfiguration und der individuellen Implementierung des Tools und dessen API ab.
Bisher wurden jegliche Tools in einer TBC sequenziell gestartet. Mit ecu.test 2026.1 werden die Tools nun parallel gestartet, was substanzielle Zeitersparnisse mit sich bringt. Die individuell gesetzte Aufstartpriorität jedes Tools wird dabei weiterhin beachtet.
Insbesondere bei umfangreichen Testbenchkonfigurationen (TBC), mit vielen Tools, kann sich der Start der Konfiguration hinziehen. Die Aufstartzeit eines Tools hängt dabei stark von den benötigten Konfigurationsschritten, dem Umfang der Konfiguration und der individuellen Implementierung des Tools und dessen API ab.
Bisher wurden jegliche Tools in einer TBC sequenziell gestartet. Mit ecu.test 2026.1 werden die Tools nun parallel gestartet, was substanzielle Zeitersparnisse mit sich bringt. Die individuell gesetzte Aufstartpriorität jedes Tools wird dabei weiterhin beachtet.
ecu.test code ab sofort auf pypi.org
ecu.test code wird ab diesem Release über den Python Package Index PyPI bereitgestellt. Sofern PyPI erreichbar ist, erfolgt die Installation ab sofort ganz einfach via:
- pip install ecutest_code
Package-Ausführung für ecu.test code
Für bestimmte Aufgaben sind evtl. schon vorhandene Hilfspackages im Einsatz, oder die Teilaufgabe lässt sich prägnanter als Package implementieren.
Ab sofort können in ecu.test code Packages, die bestimmte Einschränkungen einhalten, aufgerufen werden. Dabei können Parameter übergeben und Rückgabewerte ausgelesen werden. Außerdem kann die Bewertung der Package-Ausführung (SUCCESS, FAILED, etc.) abgefragt werden.
Selbstverständlich können Package-Aufrufe auch mit Zugriffen auf Testgrößen kombiniert werden.
Ab sofort können in ecu.test code Packages, die bestimmte Einschränkungen einhalten, aufgerufen werden. Dabei können Parameter übergeben und Rückgabewerte ausgelesen werden. Außerdem kann die Bewertung der Package-Ausführung (SUCCESS, FAILED, etc.) abgefragt werden.
Selbstverständlich können Package-Aufrufe auch mit Zugriffen auf Testgrößen kombiniert werden.
CheckResponse erleichtert Zeitprüfungen in der Traceanalyse
Innerhalb der Traceanalyse war es bisher schwierig, die Prüfung typischer zeitlicher Zusammenhänge zwischen zwei Signalen ohne Verwendung von Traceschrittvorlagen zu modellieren.
Für Berechnungsschritte und Triggerblöcke steht nun die Funktion CheckResponse zur Verfügung. Sie vereinfacht die zeitliche Prüfung deutlich, indem nur zwei Signale und ein timeout-Parameter angegeben werden. Ist der Wert des ersten Signals zu einem Zeitpunkt wahr, prüft CheckResponse, dass innerhalb der Zeit timeout auch das zweite Signal wahr wird.
Gute Praxis ist es, für das erste Signal eine Edge-Funktion anzugeben, da meist der Zustandswechsel eines Signals als Aktivierungsbedingung dient:
Durch einen optionalen Parameter useHoldValue lassen sich auch spezielle Fälle abdecken, bei denen das zweite Signal selten abgetastet wird und sich eventuell schon vor dem Aktivierungszeitpunkt im gewünschten Zustand befunden hat.
Für Berechnungsschritte und Triggerblöcke steht nun die Funktion CheckResponse zur Verfügung. Sie vereinfacht die zeitliche Prüfung deutlich, indem nur zwei Signale und ein timeout-Parameter angegeben werden. Ist der Wert des ersten Signals zu einem Zeitpunkt wahr, prüft CheckResponse, dass innerhalb der Zeit timeout auch das zweite Signal wahr wird.
Gute Praxis ist es, für das erste Signal eine Edge-Funktion anzugeben, da meist der Zustandswechsel eines Signals als Aktivierungsbedingung dient:
- CheckResponse(RisingEdge(Sig1), Sig2 == 1, 0.5)
Durch einen optionalen Parameter useHoldValue lassen sich auch spezielle Fälle abdecken, bei denen das zweite Signal selten abgetastet wird und sich eventuell schon vor dem Aktivierungszeitpunkt im gewünschten Zustand befunden hat.
