Approach

As stated above, the largest challenges of trace analysis today are to deal the masses of mes- sages in a trace and to track down complex errors in a highly distributed system. Oftentimes, the location where an error is detected is not necessarily the location where the error really oc- curred. Furthermore, it can be important to see how information spreads from an error source in order to understand dependencies between different errors. However, current analysis techniques are purely message-oriented and provide little insight into correlations and causality within the network. The reason is that traces are merely time-based, list message for message, but do not contain explicit information about cross-correlations in the network (messages contain either in- formation about receiver or sender, not both).

To fill this gap, our basic idea with VisTra was to re-compute dependencies in traces by using dependency specifications. In doing so, we want to provide test engineers with an opportunity to analyze traces from a more functional and dependency oriented perspective and to extend current working practices of going through traces merely message by message. Our rationales for that were twofold. First, we wanted to better support tracking down errors in highly distributed systems and second, we tried to address the challenge of loosely, non-automatically and verbally described errors where a functional-oriented exploration technique might be more suitable than a message-based one. VisTra’s approach for data preparation and exploration is organized in three major steps:

2_{For a detailed description of VisTra’s development process please see [Sed07].}

3_{Portions of this section have been published in [SHS}+_{08] and in [Sed08]. Thus, any use of “we” in this section}

… ECU A ECU B Signal b Signal c FB Signal a’’ Signal c … … Message Specification Dependency Specification (a) Time Signal a’ (Possibly changed) Signal b Possible Changes (b)

Figure 5.3:Schematic representation of the data preparation process in VisTra:(a)Interpretation of the trace and re-computation of functional dependencies both based on specification data. The result is a hierarchical clustered, directed functional graph. Some specified edges (signal com- munication) and/or nodes (FBs) might not appear in a real communication record (gray marked); and(b)filtering redundant signal communication.

1. Re-computing dependencies by combining traces with network specification data (R-6):

As traces currently do not provided any information about dependencies or communication paths, VisTra initially transforms the raw values into a data format that supports this information (cf. Data Transformation step inSection 2.1). To re-compute functional correlations, we use specifi- cation models from earlier development stages (see Balzer et al. [BSN07] for a similar approach). For this purpose, we first interpret trace messages in terms of signals and transporting bus system as it is commonly done by analysis tools. Then however, we additionally map the interpreted traces to the according network specification4. The result is a clustered graph with ECUs as clus- ters, FBs as nodes and directed edges representing a set of temporarily ordered signals exchanged between pairs of functional blocks. Depending on the traces’ size these edges can include thou- sands or even tens of thousands exchanged signals. However, on the other hand there might also be specified edges between two functional blocks that did not exchange any signals during a particular trace recording at all. The same applies for FBs that potentially are inactive during a certain driving/recording situation. We therefore distinguish between the real communication graph (what we compute) and the specified functional/physical network (what is specified). Fig- ure 5.3-a illustrates the process of re-computing dependencies.

2. Pre-filtering traces by excluding redundant communication paths(R-6):

80% of the communication in current in-car networks is cyclic. This means that a majority of signals are sent in certain time intervals regardless if there has been a change in the signal’s value or not. For instance, the window shifting button sends every 10ms a signal indicating whether the button has been pressed (up/down) or not. This design implies that much information is sent redundantly. Our approach harness this fact, analyzes redundancies in signal communication and automatically pre-filters the trace accordingly. Based on engineers’ feedback we learned that it is additionally necessary to retain signals that another signal might have influenced, i. e., signals sent directly after another signal has been received at the FB in question. We therefore use both,

4_{We use the physical specification that also includes parts of the functional specification to derive a functional}

this particular FB as we defined it inSection 4.2.15. The transitive chain provides all reachable predecessors as well as all reachable successors and might be valuable for better understanding real error sources and propagation based on FB dependencies. The visualization we designed provide a platform for browsing FBs along with their transitive chains in order to gain insight into elements which actually influenced and/or have been influenced by FBs (and not which potentially could be influenced as defined in specifications). The design of our visualization is described in more depth in the next section.