ecu.test Release 2024.3

Keywords can be used to specify test cases that are universally interchangeable because they all use the same “language”. A list of keywords defines a common, cross-role language, making it easier to specify and implement tests. With this 2024.3 release, there are two key enhancements that enable keyword-based testing:

• Evaluation of the return values of library packages with time options
• Intuitive naming of library packages in test cases

Example: Keyword = SeatBelt

The figure on the right shows the definition of the expected value 1 for the statusSeatBelt. After the library package has executed the stimulation for Fasten SeatBelt or Unfasten SeatBelt, the status of the corresponding signal is displayed in a detailed test report and can be evaluated.

• SUCCESS: all return values correspond to their expected values
• FAILED: at least one return value does not meet the expectations

Note: You can define several return values in your library and evaluate them in the calling package.

The various time options can be used to link the expected values of the library to time conditions. The library package is executed as often as necessary until the expectation is fulfilled or the time option has expired.

By parameterizing the package mappings, the library package calls are displayed much more dynamically in the test case and in the test report. The combination of package name, transfer parameters, and mapping name makes this possible.

The SeatBelt example with two parameters and a generic mapping for the status is used to illustrate this. The figure shows the defined parameters.

• action: Fasten or unfasten seat belt selection
• position: Selection of the seat in the vehicle

To define the keyword, the mapping for the parameterization of transfer parameters and test variables has been extended.

The call syntax for the Seatbelt library package is shown in the figure as an example of how to access the library interfaces using the Parameter and Mapping placeholders:

${Parameter.action} ${Parameter.position} Seatbelt and check ${Mapping.SeatStatusSignal}

When you drag such a library package into the test case, the transfer values are resolved and the keyword actions are displayed accordingly. Reading and interpreting a test case is therefore much easier.

During setup and commissioning of real or virtual test benches, the need for manual testing or debugging arises regularly. In particular, test bench engineers and integrators want to be able to monitor and analyze the network traffic of Ethernet and classic buses live. With version 2024.3, ecu.test offers all users the option of using the free and established network analyzer software Wireshark for this purpose.

The trace.xplorer included in ecu.test allows additional capture interfaces to be added in Wireshark to log Ethernet, CAN and CAN-FD via the widely used Vector XL Driver Library with this tool. For Ethernet, the Vector SIL Kit is also supported. Setting up these interfaces can be done very easily via a dialog in trace.xplorer.

This solution provides deep insights into bus virtualizations and allows quick diagnostics and correction of problems at new or existing test benches. Using this feature requires a trace.xplorer license and, if necessary, a suitable Vector XL-compatible measurement box.

ecu.test is available as a runner for various target systems in order to cope with scaling application areas, especially in virtual testing in SiL environments or the trace analysis.
This version without a graphical user interface can be installed via an ecu.test-deb package under Ubuntu 20.04 and Ubuntu 22.04. In order to be able to build container images based on Ubuntu yourself, corresponding Dockerfiles are also available in addition to the deb package.

Similarly, you can still use the ecu.test installer to create a Windows-based image.

With the 2024.3 release, we are now also providing a ready-to-run ecu.test image for the first time, which can be used in container environments and controlled remotely via REST API.

Are the capabilities of a runner are not enough for you and you also want to be able to edit ecu.test artifacts under Linux? The graphical user interface for Linux is available as an ALPHA version. If you are interested, please contact us at support@tracetronic.com. We will be pleased to provide you with this version.

When working in large workspaces, the question often arises as to which packages are actually used and to what extent. If library packages are included that actually have to be extensively verified, you are faced with the challenge of how to ensure quality here.

ecu.test now offers the option of creating and integrating coverage metrics for test cases within the framework of quality management (QM) and the Automotive Safety Integrity Level (ASIL). These metrics are essential for creating detailed test resp. test case coverage reports. They help to identify ‘dead’ test sections so that the maintenance and quality assurance of packages and the entire workspace can be improved. They also enable user libraries and library workspaces to be covered, similar to code coverage in programming languages.

After the revised project report still had to be activated manually in ecu.test 2024.2, it is now active by default.

At file level, project-based information is stored in a .prf file, while package results are stored in individual .trf files.

The Report Viewer and the Report API continue providing the well-established uniform access to all information.