Let’s look at how Functional Safety – ISO26262 implementation makes a system safe against malfunctions

A typical automotive product development life cycle starts with vehicle level concept development, system design, hardware, and software design, implementation and ends with verification and validation of each phase of development.

At each stage of this product development maturity, one must carry out safety analysis activities to identify loopholes or dependencies that may lead to a hazardous situation or violate a safety requirement derived in the previous phase of the development cycle.

Figure 1: Product Development Life Cycle

Setting Safety Goals

Let us consider that we are developing the ADAS feature ‘Highway Assist (HWA)’. At the concept stage of development, we analyze the HWA system based on vehicle level function failures e.g., loss of vehicle deceleration /braking function. These vehicle level function failures in combination with different driving conditions can lead to multiple hazardous situations with varying degrees of severity.

The ISO 26262 standard provides a guideline to assess severity (Severity Classes) of all situations and also provides a safety rating system (ASIL). Engineers must use a combination of Severity Classes and ASIL ratings mentioned in Fig 2 and Fig 3 below, to develop appropriate ‘Safety Goals’. For instance, in the above-mentioned example ‘loss of vehicle deceleration for Highway assist, the safety goal will be to avoid ‘unintended deceleration.’

Figure 2 : Guidelines to asses severity of a hazardous situation

The ASIL Levels – Automotive Safety Integrity Levels

Figure 3: ASIL Classification

Identifying possible malfunctions

At the next stage of the analysis, we check different possibilities of malfunctions that may cause unintended deceleration.

Based on preliminary architecture (Fig 4) a Fault Tree Analysis -FTA (Fig 5) is carried out to identify possible root causes contributing to violation of the safety goal i.e., unintended deceleration

Figure 4: HWA Preliminary Architecture

Figure 5: Partial sample of Fault Tree Analysis on preliminary architecture for SG- “Avoid unintended deceleration of the vehicle”

Thus, based on the derived safety goals engineers analyze the preliminary architecture to identify all dependencies which can trigger a safety goal violation and derive ‘functional safety requirements’ and ‘functional safety concept.’

Below are two examples of Functional Safety Requirements (FSR)

• FSR – 1: Wheel Speed Sensor Fault must be detected,
• FSR- 2: HWA System must notify driver to take control of the vehicle on occurrence of Wheel Speed Sensor Fault in a designated time (1 Sec)

Building Safety Requirements

Safety requirements are requirements addressing what the system must perform to detect a
fault, and what actions the system should perform on fault detection; so that the subsequent
hazard can be timely avoided.

Safety requirements ensure that on detection of a fault the system transitions to a safe state
before the hazard occurs. All these safety requirements from fault detection to fault handling to
timely transitioning to a safe state and required updates in the current
concept/architecture/design form a safety concept.

Hence at each level of product development maturity, we identify dependencies violating the
safety goal or former development stage safety requirement to create a respective level of safety
requirements and safety concepts.

Like Fault Tree Analysis (FTA), we also use other safety analysis methodologies like Failure
Mode and Effects Analysis (FMEA), and Dependent Failure Analysis (DFA) for more detailed
analysis at subsequent product development stages.

The three kinds of safety requirements are showcased in Figure 6 below

Figure 6: Three kinds of safety requirements

The Functional Safety Standard ISO 26262 also provides additional guidelines for components being developed out of context and the Fail-Safe Operation Concept

Safety Element out of Context (SEooC):

One of the challenges for organizations that specialize in developing software components is that they need to develop safety compliant software components without any system context for e.g. while developing software components like AUTOSAR/ Middleware or Operating systems the software development team may not know in which ADAS/AD application or system their software component will be used. For such software development situations some system context assumptions must be made during development to comply with safety standards. The ISO26262 Functional Safety standard provides guidelines for such an approach under Safety Element out of Context (SEooC)

Fail Safe Operational Concept:

For ADAS vehicles up to Level 3, there is a human driver present and once a failure is detected the human driver can be asked to take control of the vehicle to bring the vehicle to a safe stop.

But in higher levels of autonomy i.e., Level 3+ or Level 4/5 there may be no human driver to take control of the vehicle in case of a failure. In such scenarios, the system must be capable to detect and operate the vehicle with a minimum risk motion and stop the vehicle at a safe position.

These aspects of safety are analyzed and designed using the Fail Safe Operational concept. In this process, one must perform Dependent failure analysis, freedom from interference analysis, and develop a redundant system to ensure operation of the vehicle even in a critical malfunction situation i.e. the system must have redundancy by means of a secondary camera or the use of other sensors (Radar/Lidar) to bring the vehicle to a safe state (park to the side)

In summary at every development stage from concept, system, hardware, and software respective stage verification and validation of the safety requirements and its implementation is performed. This ensures that development at each stage complies with safety requirements and processes helping develop a safe robust product.

At KPIT, our safety experts implement a stringent process for all aspects of Functional Safety from the beginning of the product development process. The team works with our global clients to help create Dependable Software for ADAS/ AD vehicles. functional safety activities.