The term Safety Case is used in the automotive industry and railway industry (EN50129). The following article focuses on the automotive industry. Project experience shows that the achievement of a proven functionally safe system is complex and extensive. This is particularly true if the development of a product is spread over several companies. I will discuss the key factors to achieve the safety case objectives named in ISO26262.

Contents and objective of the safety case according to ISO26262

The ISO26262 specifies in part 10 in chapter 5.3.1 the following:
The purpose of a safety case is to provide a clear, comprehensive and defensible argument, supported by evidence, that an item is free from unreasonable risk when operated in an intended context.
The guidance given here focuses on the scope of ISO 26262.
There are three principal elements of a safety case, namely:

• the safety goals and related safety requirements
• the safety argument; and
• the ISO 26262 series of standards work products (i.e. the evidence)

Challenges when creating the required data

The main challenge lies in the complexity of the safety case. As shown in the picture, very different (plans, specifications, reports, etc.) and many work products are required. The necessary work products also arise at very different stages in a project. Often at least two companies (customer and supplier) are involved in the creation of the data.

Despite various available ALM/PLM tools it is impossible to manage all information of an ISO26262 safety case in one tool. Therefore, another challenge, is the coordination of different tool interfaces so that a comprehensible safety case can be created.

Tips for good, comprehensible safety cases

The key element for a good safety case is project management. One of the most important tasks of a Functional Safety Manager is to manage the project proactively and with anticipation. Such management is expressed in compact but clear plans (safety plan, test strategy plan, etc.). An essential element of the plans is the traceability to the individual work products of ISO26262. A few pages (approx. 3 – 5) show how and where the project fulfilled ISO26262.

This compact traceability allows you to keep track of the project at all times.

Another essential point is traceability on and between system/SW/HW level. The main artifacts are requirements, architecture, the source code, the hardware schematic and the tests. Here it is particularly important to develop practicable strategies for tool interfaces. A traceability between two artifacts, which are managed in different tools (e.g. architecture and requirements), requires some experience.

If you then manage to find an approach how to continuously add artifacts to the existing safety case, then you are on a very good way to develop a comprehensible, good and understandable safety case.

Related HEICON Blog posts

• Requirement and Test Traceability – Any added value?
• How many level of Software requirements are necessary and useful?
• Good safety development process – What is it?
• Management aspects of testing

Are you ready for a functional safety workshop, to identify improvement potentials in your development process? Send a mail to: info[at]heicon-ulm.de or call +49 (0) 7353 981 781.