Signal processing with trace steps¶

Trace steps assume the essential tasks of signal processing. Beyond pure signal evaluation, trace steps can also carry out signal calculations. In that way additional signals can be made available to other trace steps used in the same trace analysis. That results in trace analyses in modular shape and allows reusing them in part. For example, it is possible, on the basis of an existing signal, to calculate first a smoothed variant of that signal, and a second trace step can carry out a test evaluation of the smoothed signal.

It is demonstrated in an example how a trace step “Calculate_CarSpeed” (5) calculates a speed signal “CarSpeed_calculated” (4) from two generic input signals “EngSpeed” (1) and “Gear” (3), and that speed signal is plotted together with the measured speed “CarSpeed” (2) by a second trace step “PyPlotSignals” (6):

In order to output calculated signal values from Python-based trace steps, there is the method dataContainer.EmitSignal. Details about that topic can be found in the sections Creating event-based trace step templates and Reference Python-based trace step templates.

On-the-fly signal calculation¶

It is important to know that calculated signals are not saved and need not to be saved. If a signal is calculated in an episode by a trace step, it is automatically available to all trace steps of the same episode as a possible input signal. That kind of signal calculation is very efficient as it needs no storage space, neither on the hard disk nor in the main memory.

It is assumed that the time stamps of different signals are compatible. That does not mean they have to be identical, but merely that they can be placed down on a common time axis. To assure this may require a synchronization to be put in prior to a trace analysis (see Section Synchronization of traces).

Thus there is a unique time axis for the trace analysis along which the analysis is carried out. That time axis is passed through exactly one time per episode. The points observed on the time axis result from the time stamps of all signals, and it can be distinguished for each point in time which signals then really supply a measured value.

It applies to calculated signals in the same way as to the original signals that they represent a sequence of time-stamp-marked measured values.

Trace steps carrying out a signal calculation do not only have an influence on calculated signal values but also on the corresponding time stamps. So the calculating trace step is responsible for arranging the calculated measured values on the common time axis of all signals. For on-the-fly signal calculation to work correctly, the following considerations have to be taken into account:

As the time axis is run through exactly one time per episode, a signal calculation can be made at any point in time t . It is important that signal values calculated at the point in time t can have time stamps of their own (possibly differing from t). That provides the possibility of calculating signal values for the point in time t itself, for the future and also for the past (relative to t). It is important for the principle of on-the-fly signal calculation that calculated signals that continue to be used by other trace steps within the same episode are calculated exclusively at the present point in time or for the future, relative to t. Signals calculated for the past cannot be used in the same episode. trace.check stores these signals on hard disk. Thus, they will be available in later episodes.