Dependability Analysis

Dependability analysis is the process identifying hazards and then proposing methods that reduces the risk of the hazard occurring. Dependability is cate- gorised into hazard analysis and risk analysis. Hazard analysis is the process of recognising hazards that may arise from a system or its environment, doc- umenting their unwanted consequences and analysing their potential causes. Hazard analysis involves using guidelines to identify hazards, their root causes, and possible countermeasures. Risk analysis takes hazard analysis further by identifying the possible consequences of each hazard and their probability of oc- curring. Dependability analysis is being used in the validation of fault-tolerant, e.g., [116, 140, 153, 167, 168]. Figure 2.8 summarises the basic dependability analysis workflow.

CHAPTER

3

System and Faults Models and Target Systems

To be able to perform dependable software validation, the software system model along with fault model considered has to be specified. This chapter describes the software model assumed in the development of the contributions made in this thesis, and the fault models under which they were assessed. This chapter also introduces all target systems together with their associated input set, system failure modes, software system instrumentation procedures and dependability validation techniques used to evaluate and illustrate the approaches presented in this thesis.

3.1

System Model

This thesis considers modular software, i.e., software consisting of a number of discrete software functions called modules, that interact to deliver the requisite functionality. A module is considered as a generalised white-box, having possibly multiple inputs and outputs and whose codebase is available.

Modules communicate with each other in some specified way using different forms of signalling, such as, shared memory, parameter passing etc. A software module performs computations using the inputs received on its input channels to generate outputs, which are then placed on the requisite output channels. At the lowest level, such a module may be a procedure or a function and a process at the highest level. A software consists of such modules that interact via signals.

3.1. SYSTEM MODEL 24

Signals can originate (or end) from hardware or from another module. Such type of software is common place nowadays, and can be seen in many different application areas, such as embedded systems. In this thesis, henceforth, modules is used interchagebly with software systems, unless otherwise specified, and a software system is modelled as anextended control flow graph (extended-CFG).

A control flow graph (CFG) is a representation, using graph notation, of all paths that might be traversed through a program during its execution. In a CFG, a node in the graph represents a sequence of statements called basic block (or block for short), i.e. a straight-line piece of code with branching only allowed at the end. Directed edges are used to represent possible transfer of control. There are, in most presentations, two specially designated blocks: the entry block, through which control enters into the flow graph, and the exit block, through which all control flow exits.

v := 3; w := 5; L1: x := v + w; y := x − v; if(···) goto L2; y := v − w; z := z − 2; if(···) goto L3; L2: w := v + w; z := x − v; if(···) goto L1; L3: v := w + y; w := v − y; (a) Sample Program

† v := 3; w := 5; † L3: v := w + y; w := v − y; † L2: w := v + w; z := x − v; if(···) goto L1; † y := v − w; z := z − 2; if(···) goto L3; † L1: x := v + w; y := x − v; if(···) goto L2; † = header BB1 BB2 BB3 BB4 BB5 (b) Basic Blocks Entry BB1 BB2 BB3 BB4 BB5 Exit (c) CFG Figure 3.1: Example of basic blocks for a dummy program and its corresponding CFG.

The first statement in a basic block is a header, the target of any branch is a header, and the statement following any branch is a header. Thus each basic block is consist of a header at the entry and the ensuing sequence of statements between it and the next header. In a CFG, there exists a directed edge from

3.1. SYSTEM MODEL 25

basic-block1,BB1 to basic-block2,BB2, i.eBB1 −→BB2, if: (i) there exist a branch from the last statement inBB1 to the header of BB2 and/or (ii) BB1 does not end in an unconditional loop and it immediately precedesBB2. There is at most one edge for any given direction between BB1 and BB2, i.e, not more than one edge exists for BB1 −→ BB2. There is an edge From Entry to the initial basic block, there is an edge from each final basic block to Exit. Figure 3.1 shows a sample program code, and an overview of its basic blocks and CFG.

In this thesis, an extended-CFG is obtained from its CFG by ensuring each node does not contain a program variable that is depended upon another program variable within the said node, i.e., no self-loop exists in any given block. In the next section, an extended-CFG is formally defined.