top of page
Artboard 15-100_edited_edited_edited_edited.png

Why is Safety Case important? Implications for ISO 26262 Compliance

  • Writer: Ramandeep Singh Rajpal
    Ramandeep Singh Rajpal
  • Nov 1, 2024
  • 6 min read

Have you ever wondered how modern vehicles, with their advanced sensors and software algorithms, manage the safety risks that come with such complexity? What measures are in place to ensure safe and reliable performance on the road? With the trend of increasing technological complexity, software content and mechatronics application, the regulatory authorities have tightened their regulations to make the products safe for the public use.


Thus, implementing ISO 26262:2018, the international standard for functional safety in vehicles, is now a key requirement for OEMs and Tier 1 suppliers, guiding the design and development of modern vehicles. The OEMs and their suppliers have to certify their products and document all the development procedures and test results to demonstrate that their products are designed to the acceptable level of safety risk. Thus, the regulatory requirements and product liability concern, drive the need for a safety case document.


Legal Importance of a Safety Case

ISO 26262:2018 defines safety case as “argument that functional safety is achieved for items, or elements, and satisfied by evidence compiled from work products of activities during development”. 

Safety cases are often required as part of a regulatory process, a certificate of safety is granted only when the regulator or certifying agency is satisfied by the argument presented in a safety case. A vehicle safety case provides a structured argument for the safe product development lifecycle of the items or elements of the road vehicle, which makes it eligible to be sold in the market and serves as evidence in the case of a mishap. Before going deeper into the content of the safety case, let’s first understand the inception of it.


Safety Case Inception and Mention in Other Standards

The term safety case is well known in many industries and standards across the globe. It first emerged in the late 1980’s, primarily in industries like nuclear power and aviation, as a structured approach to demonstrating safety through evidence-based arguments. Throughout the 1990s and 2000s, safety cases gained traction globally, spurred by incidents like the Piper Alpha disaster (enactment of Offshore Safety Act 1992 and the making of the offshore installation (safety case) regulation in 1992) and various regulatory developments in various high-risk sectors. This period saw the formalization and standardization of safety case methodologies, integrating them into regulatory frameworks (eg. UK Defence Standard 00-56) to ensure systematic risk management and safety assurance.


Prior to the release of ISO 26262:2011 (1st release of now ISO 26262:2018 Road Vehicle- Functional Safety), the automotive industry followed IEC 61508 for the development of electrical, electronic, and/or programmable electronics (E/E/PE) system in the road vehicles. Many different standards for industries like Process Industry, Railway Industry and Automotive Industry have been derived from IEC 61508. The requirements mentioned in IEC 61508 helped the industries to make their E/E/PE systems functionally safe. It is interesting to mention that the IEC 61508 doesn’t mention about safety case document or the documenting of the safety arguments rather it rests on the assumption that following the prescribed process will generate evidence for safety. Nevertheless, let’s focus more on the requirements mentioned in ISO 26262:2018 and how it guides us to structure our safety case for automotive systems.


ISO26262 Structure and Safety Case

Let's take a moment to outline the structure of ISO 26262:2018. This standard is organized into 12 parts, each addressing specific aspects of functional safety within the automotive industry. Part 1 serves as a "Vocabulary," providing definitions for the terminology used throughout the standard, while Part 2 outlines the management activities necessary for the functional safety development process. Parts 3 to 6 focus on the design, development, and verification activities related to the system, hardware, and software components of road vehicles. Part 7 offers guidance on requirements pertaining to production, operation, service, and decommissioning of safety-related products. Part 8 addresses supporting activities crucial for achieving functional safety objectives.

 

Furthermore, Parts 9, 10, and 11 offer guidance on the application of processes and activities outlined in Parts 3 to 6. Part 11 is dedicated to semiconductor development, providing semiconductor manufacturers with insights on integrating ISO 26262 into their development processes. Lastly, Part 12 is tailored to the development of functional safety systems specifically for motorcycles.

 

The safety case in compliance with ISO 26262:2018 (as stated in Part 2, Management of Functional Safety) should meet the following requirements: 

The safety case in compliance with ISO 26262:2018 (as stated in Part 2, Management of Functional Safety) should meet these requirements

Thus, it is clearly stated that the safety case should be a part of the safety plan and it should progressively compile the work products that are generated during the safety lifecycle. The safety case should be prepared for the item/element with ASIL Level A and above. For this purpose, understanding the structure of the safety case is very important.

 

The structure of the safety case document can be based on the three principal constituents as defined in Part 10 Clause 5.3.1 of the standard, which are:

  • Safety Requirements (Safety Goals, Safety objectives of the item or element under development)

  • Safety Arguments

  • Evidence (Work Products of the ISO 26262 series of standards)


The safety argument and the evidence are the crucial constituents of the safety case, as any safety argument without respective evidence is unconvincing. The safety argument communicated in the safety case reports can be through either narrative or graphical text. The narrative text method is one of the common methods for the safety arguments used in many industries. However, graphical method such as Goal Structuring Notation (GSN) method could be used to visually represent the inter-relation of the different constituents of the safety arguments.

 

Two Types of Safety Arguments
Safety Arguments

The collection of evidence as it becomes available is crucial for maintaining the traceability of the requirements in the development lifecycle. For this purpose, the safety case lifecycle should be planned accordingly.  


Safety Case Lifecycle

The Part 10 of ISO 26262:2018 states that the safety case document can be treated as an incremental activity that is integrated with the rest of the development phases of the safety lifecycle.


The planning of incremental activities of the safety case can be a part of the safety plan which allows us to have intermediate versions (preliminary, interim and final) of the safety case. The safety manager can make decisions regarding the intermediary versions of the safety case based on the requirements of the development project, as well as the content of each version.


This is how we can approach different intermediatory versions of the safety case document

  • Preliminary Safety Case: At this stage, the safety case can include the evidence and arguments about the verification of the system design with technical safety requirements.

  • Interim Safety Case: The safety case can be updated with the arguments of hardware and software safety analyses with detailed design of the architecture.

  • Final Safety Case: At this point, the safety case can be updated with all the work products (evidences) available before the development of final functional safety assessment report.


A typical Safety Case Lifecycle
A typical Safety Case Lifecycle

As per the Part 2 Clause 6.4.13.1, the safety case shall be available prior to the release for production of the product under development. This is where the safety case lifecycle ends. If any changes are made to the item/element, then the impact on safety case should be evaluated and updated, if necessary.

 

The ISO 26262 states the safety case as one of the key work products of the safety lifecycle and requires a confirmation review starting with the item/element with ASIL level A and the independence level mention in the Table 1 of Part 2.


Safety Case Confirmation Review

The safety case undergoes the confirmation review after all the evidence and arguments are documented. The Annex C of Part 2 of ISO 26262:2018 provides guidance on the conducting the confirmation review of the safety case.


The goal of the confirmation review as per the ISO 26262:2018 is to evaluate whether the following conditions are met:

  • The argument provided in the safety case is plausible and sufficient to argue functional safety is achieved

  • The referenced work products are available and sufficiently complete so that the achievement of functional safety can be adequately argued.

  • The work products reference in the safety case are traceable; have no contradiction within or between the work products and have no open issues which can violate the safety goals.

 

It is to be noted that evidences generated by the distributed development and evidence from “proven in use” argument can be combined into the safety case which is then subjected to confirmation review.


Partner with QTSI!

Our certified Functional Safety Engineers at QTSI have years of experience in developing the safety case for different industries such as Aerospace, Automotive and Naval as well as assisting in safety certification process as per the respective regulatory authorities.



Comentarios


Ya no es posible comentar esta entrada. Contacta al propietario del sitio para obtener más información.
bottom of page