Taking a closer look: Software Safety Analysis – Part 2

In the first part of this blog (Software Safety Analysis Part 1) we looked at requirements management and traceability as key activities in the reliable implementation of software projects. In this part of the blog we look at the importance of a qualitative overview of a system and then at the techniques that best lend themselves to software analysis.

Qualitative System Overview

Ultimately the goal of the analysis is to identify the potential weaknesses in the system, the impact they could have in terms of safety. A top down approach such as a Fault Tree Analysis (FTA) or System Theoretic Accident Model and Processes (STAMP) can give an overview of the system and where the holes in the safety arguments may lie. The nature of these malfunctions can be hardware, software, usability, mechanical or other factors that impact the intended function of the system. Estimating the different factors quantitatively is extremely difficult. The probability of failure of software for example cannot really be estimated and hence why standards such as IEC 62304 suggest the probability be taken as 100%.

Once the potential holes in the safety arguments have been identified, the role the software plays in these potential malfunctions can then be analysed in more detail.

Software Analysis Techniques

Numerous techniques are utilized in software analysis the pros and cons of some are discussed below:

1. Hazards and Operability Analysis (HAZOP)

HAZOPs lend themselves well to the analysis of software, although more specifically a systems analysis method. As a technique it does not purely focus on failures but can also analyse more complex events. This is an important feature as we should not become fixated with the causes of failures, more the impact they can have on the system. The negative here is the time required to generate the analysis. ISO 26262 part 6 introduces the concept of using HAZOP in Annex E, but without actually referring to it as a HAZOP. It is more a recommendation on using guide words.

2. Failure Modes and Effects Analysis (FMEA)

Probably the best-known analysis technique and widely used across industries. Very much a bottom up approach, starting with the identification of malfunctions and assessing the impact they have further up throughout the code.

The down side is as a technique it is good at analysing individual failures, but becomes far more labour intensive for complex systems.

3. Event Trees Analysis (ETA)

Event trees are arguably the quickest technique to implement and are relatively easily understood, the down side of even trees is the determination of the percentage split between successes and failure branches.

4. Fault Trees Analysis (FTA)

The question then arises why not continue to use FTAs for the software analysis? The main draw back in using fault trees for pure software analysis is as the complexity of the software increases the sheer number of items that could contribute to a failure, greatly increases the complexity.

Ultimately the success of any analysis will depend on those contributing to the activity. Very important is to ensure the correct team is in place to analyse the potential weaknesses in the system design, equally so getting the right people round the table for the software analysis is important. Seldom are they the same people.

In summary analyse at both system and software level, choose a technique that suits your working patterns and ensure you engage the appropriate people for the analysis activities.

By Alastair Walker, Consultant