ecu.test Release 2025.2

ecu.test lab is a web interface provided by ecu.test to visualize and control the behavior of a test bench, as well as the system under test.

Whether Windows or Linux, local or remote, CAN, XCP, model or multimedia - ecu.test lab runs where you need it and communicates via all interfaces available in ecu.test. Directly based on existing mappings or packages.

Try it now!

Every ecu.test license includes access to the full range of functions offered by ecu.test lab until the end of 2025.

ecu.test user documentation is now also available online. Starting with version 2025.2, all help components from the last four releases will be available. In the future, online help will also be linked directly to ecu.test so that the latest version is always used. You can now also take a quick look at the help without having to install it first.

Take a look at the ecu.test user documentation

In addition, the file structure of the offline help has been modernized. Among other things, file names have been standardized (now English only) and minor structural adjustments have been made.

Please note: Links within the help have changed as a result.

One of the biggest challenges in scenario-based testing is the interaction between test cases and scenarios. With ecu.test 2025.2, we offer a comprehensive workflow for CarMaker that allows you to create and adapt both scenarios and test cases and execute them in your test environment.

The graphic on the right illustrates the interaction between our scenario.architect and ecu.test.

In ecu.test, new scenarios can be created and existing ones adapted. The scenario tree in the environment simulation tab provides new context menu entries for this purpose. When creating or modifying scenarios, scenario.architect opens. In this tool, you can make adjustments or completely redesign scenarios. Once completed, ecu.test takes over artifact handling and ensures that the necessary scenarios are forwarded directly to the environment simulation. The corresponding scenarios are loaded and executed via the test cases.

The added value comes from the coupling of the toolings. Through this integration, scenarios, test cases, and analyses can be developed and executed very quickly, intuitively, and iteratively. Further details can be found in the tutorial in the user documentation.

Please note: The workflow is designed for use with OpenSCENARIO files. The functions are currently available for VTD and now also for CarMaker environment simulations.

ecu.test diagnostics now offers full support for the OBDonUDS standard. Highlights are the symbolic diagnostic service test steps, which you can simply drag and drop into the test case.

Simply activate the OBDonUDS option in the TCF diagnostic settings. After configuration is started, the test steps appear in the diagnostics tab – natively and without the need for a diagnostic database.

The services are available for all diagnostic ports.

• IsoTp over CAN
• FrTp over FlexRay
• DoIP over Ethernet

A new browser extension called Open with ecu.test diff is now available for Chrome, Edge, and Firefox.

As usual, it allows you to compare changes to packages and other artifacts from GitHub and GitLab directly with an installed ecu.test.

Note: Starting with this version, you can open the comparison without a license.

You can add the extension via your browser
(Chrome+Edge, Firefox).

However, browser extensions are often managed by IT and require explicit approval. For easier verification, the extension's source code is open source on (GitHub).

TCF and TBC files can now be managed centrally and are displayed in the Workspace Explorer within the configuration directory. These files can be opened and edited by double-clicking them in the editor or by drag-and-dropping them into the configuration window.

In the configuration change project step, the selection of TBC and TCF files has also been extended: In the dropdown of the respective file, library files can now be selected in addition to local files, which makes the configuration much more flexible. When loading the configuration, the library references are automatically resolved.

The Object API provides new methods for use in the configuration change project step. The existing tutorial has been extended accordingly.

To better distinguish between local and library configuration files, the icons have also been adapted according to the usual scheme and are now displayed in orange and teal, respectively.

Since ecu.test 2024.3, coverage metrics can be generated for test cases in order to systematically analyze the use and validation of packages as part of quality management. This function is particularly useful for identifying unused sections and safeguarding safety-critical libraries - similar to code coverage analyses in software development.

With the current release, this function has now been expanded: the coverage data of several test executions can be consolidated and displayed across the workspace in a clear report. This means there is no longer any need to tediously track coverage information through individual packages in the GUI.

The compact HTML and JSON reports provide a centralized view of test coverage, test gaps and improvement potential - as a basis for sound test planning, targeted maintenance and consistent quality assurance throughout the entire project.

The report is created via a new menu entry in the existing Coverage menu.

An HTML report is then generated and displayed directly in ecu.test. The links to packages are clickable and open the package directly in the tool itself. The HTML file can also be displayed in the browser. The generated JSON file can be used for automated evaluation or data use.

For use cases in which it matters which service consumer uses a service, it is now possible to select the consuming control unit in the mapping items of Ethernet test steps.

When a consumer is selected, the network adapter with the TCP/IP settings of the consuming control unit is automatically configured from the ARXML when the test case is started.

This feature removes the need to create and manually configure a port in the test-bench configuration for each consumer.

For existing test cases or cases where the consumer selection is left empty, the IP configuration in the TBC settings Fallback IP Settings continues to apply.

The new option is only effective in conjunction with the active service port and the TCP/IP network stack integrated in ecu.test.

This extension also affects the connection of the ServiceManager port in dSPACE models. Here, the placeholder consumerNode can now also be used to define a mapping to model variables.