Migration from event-based to optimized execution¶

To achieve significant performance improvements in analysis execution a new parallel and efficient processing mechanic has been developed since ecu.test 7.0. The introduction of 64 bit architecture made it possible to neglect the event-based execution mechanics that was until then necessary to process larger quantities of signal data. Instead of providing each signal event individually to a processing routine whole arrays of data are processed. Using Numpy and optimized C code resulted in significant improvements in execution time. Note that those improvements depend on a variety of factors, such as structure of the trace analysis, usage of internal functions, trace data formats, number of measurement points and number of trigger ranges. Since ecu.test 8.0, the optimized execution mode covers the complete trace analysis functionality, which is why the old event-based execution mode has been removed.

The optimized execution differs in some aspects from the event-based execution. The following summary aims at easing migration to the new execution mode and documents intentional resp. necessary changes in behaviour.

Rounding of floating-point values

For expressions of trigger blocks and calculations the following must be noted: The usage of NumPy and its data types for the fast calculation can lead to minimal differing floating-point values in difference to the evaluation with pure Python. When comparing two floating-point values directly for equalness it is recommended to specify a numerical expectation for calculations instead or to check that the difference of the two values is less than a certain epsilon.

This phenomenon can also lead to minor deviations in the internal functions.

Access to calculated signals in subsequent episodes

In the event-based execution the calculation of a signal and access to it in a subsequent episode led to the creation of a CSV file in which the signal data was stored. This file could be found in the report folder.

The optimized execution mode comes with the so called signal cache, which is enabled by default and makes forwarding signal data between episodes far more efficient. The signal cache can, however, be disabled, if a CSV file is explicitly required. To do so, adjust the setting Options ‣ Settings ‣ Analysis execution ‣ Cache signals.

See settings Trace analysis.

Special signal values (None)

In the event-based execution signal data was kept in a hold-buffer. If multiple signals with differing start points were analyzed, timestamps existed where not all signals had a value. In the event-based execution those gaps were filled with the special signal value None. This behaviour was a source of multiple problems. For example the expression None < 0 is evaluated to True and None + 1 results in a NoneType error in Python 2.

The optimized execution will not evaluate at such points and resulting subranges will be evaluated with NONE and the comment “Expectation never checked”.

The following examples of start trigger conditions illustrate this difference:

Optional and empty signals

If a calculation checks a signal that has no samples the configured option for empty ranges is applied.

The usage of a potentially empty signal in an expression with additional signals should always be grouped in a trigger block with the mentioned HasValue() function. This is especially important for optional signals which are handled like empty signals if they are not present.

Assertion¶

In contrast to the event-based analysis execution the result of an assertion is always based on the end result of the analysis element to check. In the event-based execution the current result of a trigger block that had not been triggered was reevaluated.

If an assertion is containing a trigger block, the trigger ranges will be shown with their actual result in the detail report (meaning without revaluation by the assertion) in optimized execution mode. The event-based execution mode will show the accumulated result including the assertion instead. Though the overall result will always be correct.

Evaluation points of an expression

In the event-based mode all signals of all trace steps in one episode were evaluated on a common merged time axis. Especially when calculating signals this could result in multiple formally independent calculation steps to influence each other unintended. So a calculation that checks a single high sampled signal could lead to other trace steps being called more frequently which was not desired.

In contrast to that behaviour only the signals of one expression determine the evaluation points in the optimized execution. It should be taken into account that the start and stop trigger condition (if provided) of a trigger block are always evaluated together.

Data types of signals

Signals, which delivered values of the type int in the event-based execution mode, partially deliver values of the type float (e.g. FrameID) in the optimized execution mode. If the changed data type causes problems, a manual type conversion, e.g. int(Signal) can help.

Evaluation of partial expressions without signal reference

Partial expressions without signal reference (also function calls) are only evaluated once in the optimized execution mode. In event-based mode, such partial expressions were evaluated again at each event. Thus, in the expression api.Math.RandomValue(0.5, 0.5, 0.5) * Signal` the RandomValue function is evaluated only once.

Differences in internal functions

In the case of internal functions, there are differences especially in edge cases (e.g. signals with only one sample) and at the beginning and end of an evaluated range. Under certain conditions, slight deviations could be detected in the following functions: Value, Static, HoseAbsolute/HoseRelative, Edge/RisingEdge/FallingEdge, CheckTiming/CheckAlive. Only the most important differences are explained below.

In the optimized execution mode, the Hose functions also consider the hold value at the start of the time window for the time tolerance. In event-based mode, only samples in the time window are considered. In addition, the Hose functions supply INCONCLUSIVE before the start of the signal or after the end of the signal. In event-based execution mode, the expression was evaluated with FAILED if one of the signals has no value at the beginning. At the end, depending on which signal has no value, it was evaluated with FAILED or not evaluated at all.

In event-based execution mode, the Edge functions were only evaluated from the second sample onwards. In the optimized execution mode, the evaluation starts with the first sample and the result for this timestamp is False.