EMOCIONES DESAGRADABLES O NEGATIVAS

While Autobahn3D focused on how a 3d view could be used for showing mechanical behavior, in line with our design consideration DC-3 the initial idea with Car-x-ray was to address the second use case estimated as relevant by engineers, namely using a 3d representation to show communication paths “through” the vehicle. According to automotive analysis engineers, this could especially be useful for diagnosis of errors where possible hardware changes or defects might have an influence on the error appearance (cf. Section 5.1.3). Similar to Autobahn3D, we therefore initially focused on solutions for analysis experts and on visualizing traces (DC-1).

Data In order to show communication paths of traces, first it was necessary to derive this information from traces as it is not explicitly available with them. To do so, we used the approach introduced for VisTra allowing us for translating traces to clustered, directed graphs with bus

(a) (b)

Figure 6.4:Screenshots of Car-x-ray in case study 1:(a)Highlighting the physical path between two FBs with additional flow animation using spheres changing there color from red (source) to blue (sink); and(b)abstract representation of a transitive chain of successor ECUs.

systems as clusters, ECUs as sub-clusters, FBs as nodes and exchanged signals defining edges (cf. Section 5.2.1).

Design As described above, Car-x-ray uses two basic components to visualize this informa- tion, (a) an abstract 2d frame surrounding (b) a semitransparent 3d model of the vehicle. The frame visualizes the data’s hierarchical structure in a similar way as the treemap in VisTra did (cf. Section 5.2.2), however, uses nested, color- and size-coded trapezoids instead of nested rectangles and arranges them along the frame’s borders. We used domain-specific colors for dis- tinguishing the different bus systems and the width of the “FB-leaf-trapezoids” to code number of incoming and outgoing signal communication, i. e., large trapezoids were more communica- tive than small ones. The size of ECU- and bus-trapezoids directly results from the sum of FB-trapezoids. To focus on specific parts of the network, the user also can interactively fold and unfold bus systems. Within this frame, the virtual 3d model is shown, can be navigated by the user, controlled in terms of components transparency and provides an abstracted in-car network similar to the one we used with Autobahn3D.

By selecting a FB trapezoid from the 2d frame the user can initiate a representation of how communication had spread in the network. To do so, s/he defines a FB either to be a source- FB and in doing so highlighting the selected element plus all reachable successors (transitive chain of successors) or to be a sink-FB showing all predecessors respectively along with the selected FB (transitive chain of predecessors). After the user has selected a FB—for instance, a source-FB—the following elements are highlighted: All involved FB trapezoids are highlighted

with all involved elements (cf. Figure 6.4-a). As the described highlighting technique does not necessarily reveal the exact path that the communication took (e. g., is a specific gateway only involved in one path or in several different path), we designed two additional representation techniques for enriching the approach we described. First, we allow the user for initiating an animation by hovering over involved elements. Instead of using one single representative as in the in the early prototypes, we used a stream-like animation of many representatives changing their color from red (source) to blue (sink) in order to indicate the direction of communication flow rather than following a single item over time (DC-4). A second alternative that can be initialized by the user, is the abstract visualization of communication paths via direct arrows between the involved ECUs (cf. Figure 6.4-b). In doing so, all ambiguousness is eliminated at the expense of reduced spatial correlation.

To avoid unnecessary navigation, we also integrated an automatic camera planning strategy that is triggered after a user selects an element (DC-6). Our strategy automatically rotates the 3d model based on minimizing the distance of all involved ECUs to the camera and on avoiding occlusion of involved ECUs. Finally, we added a traditional, hierarchical sortedList Viewand a search, as interacting with the 2d frame where most labels are just shown on mouse over is tedious. Equally to the 2d frame, this view can be used to select source- and sink-FBs.

Evaluation After evaluating the usability with four external testers and fine-tuning the tool thereupon, we conducted a user study with seven domain experts (four analysis experts, one analysis tool developer and two researchers on novel analysis methods), in order to (a) validate our design considerations and (b) to discuss potential domain utility of our approach. We used our typical setup for qualitative “domain-estimation” studies, i. e., we used the dataset we man- ually had prepared, let our participants conduct a set of tasks similar to the one used for early prototypes (understanding correlations and communication), encouraged them to comment their thoughts during conducting the tasks, and subsequently discussed the provided solution in terms of potential domain value. Each study took one hour and we used note taking to track communi- cation and tool usage.

By observing our participants conducting the tasks and by analyzing our think-aloud protocols, we found several indications, that the features we added helped in overcoming the problems of the early prototypes. Mapping communication path to spatial information rather than to animated messages/signals led to a better recognition of correlations and less errors in detecting them. Besides, it was preferred over animation by the subjects who had already participated in the first study, as it “does not impose any additional time costs” (DC-4). While the additional stream

liked very much. Furthermore, we got good feedback to our design decisions of integrating an automatic camera planning strategy (DC-6) and on providing an additional list and search view which was basically used for selecting elements (DC-9). Similar to our previous studies, our participants often stated to“have fun”by using Car-x-ray, and frequently started to encourage the integration of other features that might improve the tool, such as additionally showing bus loads, providing ECU details on demand, and various other features known from their current analysis tools. The strongest point of critique—that we, however, were already aware of before conducting the study due to the reasons described in the previous section—concerned the representation of ECUs and bus systems as positions and wiring paths did not (exactly) map real positions.The abstract representation, however, was not seen as a problem by any participant. This strongly underlines our design consideration “ Real positions, abstracted forms” (DC-8).

In terms of potentially added domain value, most of our participants argued (again) for using such solutions for educating novice users and for communication purposes. However, beyond that several engineers provided us with potential reasons why such a solution might benefit their

own work. One analysis engineer even stated: “[If embedded with current software environ-

ments] this tool would be used in my department straightaway”. Along with the potentials of showing transitive chains in general (cf. results of our studies with VisTra,Section 5.2.3), most importantly the potential to provide a novel perspective on the data showing how information dis- persion directly correlates with its spatial positions in the vehicle was estimated highly valuable (cf. R-2 inSection 5.1.4). Furthermore, two of our participants underlined that they would use the tool for collaborative analysis tasks: “for me the highest value of such a tool would be that I can easily analyze traces together with my colleagues”(cf. R-11 inSection 5.1.4).

In line with our findings from previous studies, however, it is clear that this Car-x-ray in this ap- plication scenario is not yet applicable (and testable) under real circumstances. For a productive application in daily work, overcoming current technical restrictions of embedding mechanical data in analysis tools (cf. Section 6.2.4), format compatibility and automatic connection to real data (3d models and traces, cf. Section 6.2.1), seamless integration with other trace analysis software (cf. R-9 in Section 5.1.4), and a conceptual coordination with these tools (cf. R-4 in

Section 5.1.4) is crucial.