Software safety analysis – part 1

A hot topic for many years has been the definition of the best safety (risk) analysis technique for analysing potential software malfunctions. Like many discussions of this nature there is no clear answer and the decision is often application and complexity dependent.

There have been many papers and books written on the subject of software safety analysis. Ultimately, there are several key points to consider when improving the robustness of a system or product. These activities begin at system/product level and then subsequently feed to the next hierarchal level down – the software level:

• Define qualitatively the structure and operation of the system or product
• Ensure requirements are clearly defined, i.e. are not ambiguous are uniquely identified, traceable and verifiable
• Identify hazardous situations and the associated severity and system/product level
• Identify failures external to the system/product that could impact the software
• Consider both static and dynamic analyses

Requirements management

There is little doubt that most issues that result in a system or product causing a hazardous situation are traceable to incomplete or erroneous requirements. This is a problem that is seen across industries, and at different requirements levels. One of the benefits that Automotive SPICE® can bring in the automotive sector is the focus on requirement completeness and traceability. Using a Fault Tree such as the one below supports the analysis of requirements.

From the definition of product or system analysis and the associated hazardous situations, the analysis at software level can commence but what strategy should one adopt? The techniques commonly listed in standards such as ISO 26262, ISO 14971 and IEC 62304 include:

• Fault tree analysis (FTA)
• Event tree analysis (ETA)
• Failure modes and effects analysis (FMEA)
• Hazard and Operability Analysis (HAZOP)

Two other techniques that are highly popular are:

• System Theoretic Process Analysis (STPA)
• Preliminary hazard analysis (PHA)

Avoiding hazard checklists

For the analysis techniques listed above, identifying the hazardous situations is a key first step. International standards such as ISO 14971 (ISO/TR 24971) publish lists of potential hazardous situations, which can be a good idea to get you started. However, no two systems are the same just as use cases differ between products. Following checklists can often result in a lack of rigour in the analysis, that would potentially identify new hazardous. Or it can result in overlooking the operation, use environment or intended use of the system or product.

Ultimately the activity needs to start with analysis driven by subject matter experts and this is where PHA can prove their weight in gold. The outcomes of the PHA can then trace down into the next level below where the software safety analysis gets going.

The next step for organisations and the team carrying out the software safety analysis is to choose the best method. The complexity of the product will play a big part in this choice, but often the choice is based on techniques teams are familiar with and where they feel most comfortable working. Many companies use FMEAs on a daily basis, and this becomes the automatic method of choice, but it may not be the ideal selection for all products.

In the second part of this blog we will look at the different analysis techniques FTAs, ETAs, HAZOPs FMEAs and STPA and at the pros and cons associate with each of them. We will also consider the project complexity and the role it plays in the method selection decision. (You can find the article here.)

By Alastair Walker, Consultant