ECU-TEST Release 2021.4

ECU-TEST 2021.4 is based on Python 3.9, while ECU-TEST 2021.3 and earlier versions were delivered with Python 3.7.

There are incompatible changes in Python 3.9, so unadapted code may not be executable. This also applies to Packages, user code and external Python libraries.
Migration help can be found in the following Knowledge Base article.

Using the downstream analysis by TEST-GUIDE, analysis jobs can be distributed to ECU-TEST instances (PC, virtual machine, cloud) regardless of the test bench. As a result, valuable test resources (such as HiL) are not blocked by analysis and the testing rate can be significantly increased. The scope of tests to be carried out can be scaled further by carrying out the analyzes in parallel.

As of ECU-TEST 2021.4, all formats that can be used in Trace analysis are supported, especially ERG (IPG CarMaker) and OSI (ASAM).

Current measurement hardware (such as loggers) use separate measuring heads (so-called probes) to gain access to the individual bus systems of the on-board electrical system. This makes it possible to respond flexibly to the increasing complexity of modern architectures. ECU-TEST has supported the associated Probe Logger Protocol (PLP) for live read access in the test case, recording and offline analysis from PCAPNG traces since several releases.

With the current release 2021.4, it is also possible to analyze log messages that were sent and recorded via PLP according to the DLT protocol (AUTOSAR Diagnostic, Log and Trace).

In addition, a feature flag allows the sample time-stamp to be used for analysis with significantly lower latency. If you are interested in this feature, please contact our Support

Based on the performance improvements in ECU-TEST 2021.3, an optional filter for passive SOME/IP service access has been implemented for the current ECU-TEST version.

When the filter is enabled by calling the LearnBPFilter job, connections that are not relevant for the test case or signal recording are removed to optimize the resources. This allows live processing of input data streams up to the gigabit-range, if necessary.

To summarize, the following results will be achieved with the implementation:

• Data rates of up to 300Mbps can now be processed effectively without filtering
• When the filter is enabled, data streams that need to be analyzed live in the test case are greatly reduced, depending on the use case.
• If PCAPNG recording is used along with the filter, the size of the recording file is reduced, which speeds up the trace analysis.
• The filter used is documented as a recording comment in the PCAPNG file.
• Additional user-specific filter criteria can be parameterized via the job call (for example, to filter video streams)

Note: If the data streams use the Probe Logger Protocol (PLP), the efficient filtering mechanism can be applied only to a limited extent. In this case, a slower fallback mechanism is used for filtering.

With the CAN and FlexRay mini residual bus simulation, it was possible in earlier versions of ECU-TEST itself to describe simple simulation (max. 20 messages, min. 10ms cycle times) in test cases.

The mini residual bus simulation now works for Ethernet as well.

The signal value parameterization of the residual bus simulation can be performed in different ways:

• Simulation of SOME/IP service provider (as Python script)
• Simulation of any Ethernet, TCP and UDP communication (statically as byte sequence or dynamically as Python script)

Thewas already available in previous versions as a prototype and can now be used for production. Since internal interfaces have changed again, existing simulation scripts cannot be reused and have to be re-generated and modified.

ECU-TEST supports the use of data sent by MACSec (IEEE 802.1AE) containing the ICV when passively reading and analyzing PCAP records. All overlying communication protocols (SOME/IP, DLT, etc.) benefit from this.

Encrypted communication is still not supported.

To boot up a FlexRay bus, two cold start nodes are required for the test station setup. With ECU-TEST it was already possible to configure another FlexRay node as a cold start node.

A new feature is the option of activating the second cold start node on one controlle as well. For this purpose, the Both option is additionally available in the test-bench configuration for Vector as cold start response.

Note: The function requires the Advanced license of the Vector XL API.

With the new ECU-TEST version it is possible to test ADAS functions with CarMaker also under Linux. So far, the tests were run only under Windows.

The same range of functions is offered for CarMaker under Linux as under Windows.

CARLA is an open-source simulation software to support the development, training, and validation of autonomous driving systems.

The platform includes the following:

• complete control of both static entities (city layouts, maps, buildings) and dynamic entities (vehicles, passers-by)
• the flexible specification of vehicle sensors
• the setting of various environmental conditions

For ECU-TEST, an initial CARLA connection was established with version 2021.4.

This allows CARLA recordings to be started and stopped directly from ECU-TEST(default test steps; synchronous/asynchronous). The recording file is automatically sent to the trace analysis.

For each vehicle, one sensor of each type is shown in the signal tree (except "Image" sensors, like RGB, Lidar, etc...).

If a sensor is not available during recording, there is no error in ECU-TEST at the time of recording. The signal is simply not included in the recording. If the missing signal has to be analyzed in the trace analysis, then an error will naturally occur

ECU-TEST offers with its test packages the option of editing both the test case specification and the test case implementation.

In many cases, the test case specification should be exported to a test management system or an ALM system.

With ECU-TEST 2021.4 it is now possible to intervene in this export function using project-specific scripts in order to be able to define even more flexibly which aspects of a test package are to be exported to the respective target system.

This makes it possible to always achieve exactly the level of abstraction between test management and test case implementation that best suits the respective project.

For service-based communication with Ethernet or sensor models with OSI, it is often necessary to analyze signals that are part of a list or vector.

In addition to direct index access to the corresponding variables, an expectation can now be set for all elements or at least one element of the structure in the trace analysis. Two options are available for this:

The selection is performed in the calculation step under the Matrix/Vector handling option on the Option card. The expectation on the individual components is configured in the expectation block.

Alternatively, the operations all(), any(), min() and max() can be called in the expression. This is especially useful when you want to save calculated logical signals. Higher dimensional generalizations are also supported.

The diagnostic description file can now be queried to test which diagnostic services are enabled in the respective integration steps and whether they respond as specified. This solution is implemented via the new Diagnostic browser API, which can be used to read all the services and their meta information.

With this information and the option to generate diagnostic test steps via API, diagnostic test cases and entire test suites can now be fully created.