Safety and Security Analysis using CakES

The framework presented in Section6.3has been used to produce a safety visualization called Cake metaphor for safety analysis of Em- bedded Systems (CakES) [223] that was designed to assist software engineers in the safety and security of embedded systems. This visu- alization system consists of multiple applications that visualize the physical model, the minimal cutsets, and the basic events of the fault

tree. Our framework facilitates interaction amongst these different applications, allowing the user to have different levels of focus and context simultaneously. Figure6.6 shows a real-time screen shot of these applications interacting with one another.

A brief introduction to these safety analysis topics is listed below with references for further readings:

• Fault Trees (FTs) are tools in system safety, reliability, and avail- ability studies [224].

• Basic Events (BEs) are the lowest-level influence factors in the FT and they are represented as the leaves. The hazard that is examined in the fault tree is called the top event which is at its root [225]. • Minimal Cut Sets (MCSs) are the unique combinations of BEs that

can cause the top event to occur [226].

Multiple Applications

The CakES configuration utilizes four distinct applications, referred to as views henceforth, that are interconnected through our framework. These views are are as follows:

Menu View The menu (see Figure6.7a) functions as the primary interface between the other applications displayed on the Tiled- Wall. It allows the user to switch the virtual focus between these different views. Additionally, it displays vital statistical data about the selected MCS: size, probability, and details of its BEs. Further, the user may reorganize the MCSs in the Cake View according to his preferred criteria by using either the sliders or radio buttons provided.

BEs View The BEs View (see Figure6.7b) is directly related to the Model and Cake Views. In this view, the hardware components related to the BEs within the selected MCS in the Cake View are displayed in more detail. Currently, there are no interaction mechanisms in this view.

Figure 6.6. Case Study 1: eCITY Tiled-W all configuration

(a) Menu View (b) BEs View

Figure 6.7. CakES: Menu and BE Views

Model View This view is employed to exhibit the physical parts of the Robust Autonomous Vehicle for Off-road Navigation (RAVON) model as shown in Figure6.8a. The model depicted is of the Robot RAVON, further details can be found on the AG Robotersysteme website12_.

The TileRenderer application drives this view as it is to be dis- played both on a stereo monitor as well as on the larger area of a Tiled-Wall. Interaction mechanisms that allow the user to explore the model further are: zooming, rotation, translation, and adding a spotlight. Further, it utilizes the framework by registering for an MCS_SELECTION, so that once an MCS is selected in the Cake View appropriate data is received. As a consequence of this data exchange, the RAVON model is rendered transparent and the relevant BEs are rendered opaque (see Figure6.8b).

12_{AG Robotersysteme: Ravon (http://agrosy.informatik.uni-kl.de/}

(a) Before (no MCS selected)

(b) After (MCS selected)

Cake View This view uses a Cake metaphor [223] to visualize the MCSs, their probabilities, and their BEs. A text file containing information about the BE distribution is generated using the ESSaRel tool13_{and used in the initial formation of the Cake.}

The Cake consists of three separate levels depicted by red, yel- low, and blue cylinders. Each cylinder represents an MCS and within each MCS there are a certain number of BEs. These three levels correspond to a range of fault probabilities that may also be adjusted via the Menu sliders. Further, each level uses satura- tion to distinguish between probabilities that lie in the same range. The user is provided interaction mechanisms quite similar to the Model View. In addition the concept of Virtual Picking was developed to handle virtual interactions within this view, as there was no real focus available - the user interacts through remote devices that send relevant data through our framework. Virtual Picking is accomplished by tracking relative mouse movements, drawing a ray through the current mouse position and the far clipping plane, and selecting the intersecting shape. When invoked, it makes an MCS transparent and one can see the BEs within. Information regarding the selected MCS and its BEs are then sent to the other views interested in them through the Dispatcher mechanism.

Hardware Configurations

For the CakES visualization, two different configurations were em- ployed. The first is a two-monitor single-PC solution, while the second is a nine-monitor five-PC tiled solution.

Desktop This configuration was built mainly for development pur- poses and its physical layout is depicted in Figure6.10a. A stereo monitor was used to display the physical parts of the RAVON model as shown in Figure 6.8. On the other hand, a standard monitor was used to tile the Menu, BEs, and Cake Views next to each other as shown in Figure6.9.

13_{Background information — ESSaRel (http://www.essarel.de/}

Figure 6.9. CakES: Desktop Views

Tiled-Wall A 3x3 Tiled-Wall with five computers was implemented as depicted in Figure6.10b. This image is based on the ‘schematic view on a typical 3x3 tiled display’ figure presented by Deller et al. [201], it is modified to incorporate our dispatcher framework. Further, there is an upper and a lower seperation of the Tiled-Wall: • The upper six displays are managed by TileRenderer - it uses three PCs for this task, where one of them acts as the Master- PC and controls the other two Slave-PCs via the network. • The lower three displays are controlled by the remaining two

PCs. One of them runs the Dispatcher framework and displays the Menu View on the lower-left screen of the Tiled-Wall. The other is used to visualize the BEs and Cake Views on the remaining two screens.

All the above-mentioned views are controlled by the same in- put devices, that are physically connected to the Master-PC of the TileRenderer. This configuration allows the Master-PC to process input events locally when the Model View application has the virtual

Input Device PC 1 TileRenderer Thread Model View Input Processing Stereo Display Standard Display PC 1 Other Threads Dispatcher Cake View BE View Menu View Virtual Input Processing

(a) Config. 1. Desktop

Model View Input Device Anyscreen Master PC Node 2 Input Processing Display Node 1 Display Display Display Display Display

Anyscreen Slave PC 2 Node 2 Node 1 PC 1 Dispatcher Menu View Virtual Input Processing PC 2 Cake View BE View Virtual Input Processing Display Display Display

Anyscreen Slave PC 1

Node 2 Node 1

(b) Config. 2. Tiled-Wall

focus. On the other hand, it forwards input data via the network to PC1 and PC2 when one of those two applications has the virtual focus. A real-time screen shot of the tiled-display was presented earlier in Figure6.6.

6.4.2 Software Measurement Analysis using VIMETRIK