Automotive Functional Safety

Read More

State of the art
functional safety.

ISO 26262 Road Vehicles

ISO 26262 Road Vehicles - functional safety provides an automotive safety lifecycle (management, development, production, operation, service, decommissioning) and supports tailoring the necessary activities during these lifecycle phases. Determines an automotive-specific risk-based approach to identify Automotive Safety Integrity Levels (ASIL) and uses them to specify applicable requirements so as to avoid unreasonable residual risks.

SOTIF stands for Safety Of The Intended Functionality.

ISO/PAS 21448 defines SOTIF as hazards caused by insufficiency of specifications/performance limitations or misuse. SOTIF must be used together with functional safety (FuSa).

UL 4600 Standard

UL 4600 Standard for safety evaluation of autonomous products - provides additional requirements and guidelines to make a safety case for autonomous vehicles. The standard looks at three elements: Goals, Argumentation and Evidence. State of the art functional safety in automotive considers several standards working together to deliver complete risk assessments for complex mechatronic products.

iProcess helps with guidance throughout the process of implementing and becoming compliant with ISO 26262 and ISO/PAS 21448 and UL 4600.

Functional safety & SOTIF.

The two standards are complementing each other with focus on different causes. ISO 26262 deals with preventing hazards due to malfunctions within a system by requiring mitigations based on severity, controllability and exposure SOTIF deals with hazards resulting from functional insufficiencies of the intended functionality or by reasonably foreseeable misuse by persons

What are the unknown unsafe scenarios (Area 3) in SOTIF?

There are 4 different scenario categories in the SOTIF standard. They can be safe or unsafe, known or unknown. While known scenarios will be considered naturally during development and validation, area 3, the unknown unsafe scenarios are the challenge. The goal has to be to minimize the scenarios in area 3 by increasing the number of known scenarios. By definition, as soon as a scenario becomes part of the product development and validation, it is no longer unknown, and therefore associated to area 1 or area 2.

What is ASIL decomposition?

Under certain circumstances the ASIL can be lowered by applying architectural methods that allow to split the safety rating of the requirements into two or more elements of a lower rating, for example using redundancy. However it is not enough to simply decompose an element into two sub-elements with a lower ASIL, a convincing argument that these sub-elements can safely co-exist must be made.

For example, an ASIL D requirement can be broken down into two ASIL B (D) elements. The original ASIL must be kept in parenthesis and the new ASIL will be pronounced ASIL B of D.

The relationship between ISO 26262 and ASPICEĀ®?

There is a lot of overlapping between the two. Concept phase, product development at the system level, product development at the software level, and supporting processes have a strong relationship to the processes in Automotive SPICEĀ®. Example of process mapping at the software level:

ISO 26262- 6-5

Initiation of the product development at the software level
<--> ASPICE SWE.1 Software requirements analysis

ISO 26262- 6-7

Software architectural design
<--> ASPICE SWE.2 Software architectural design

ISO 26262- 6-8

Software unit design and implementation
<--> ASPICE SWE.3 Software detailed design and unit construction

ISO 26262- 6-9

Software unit testing
<--> ASPICE SWE.4 Software unit verification

ISO 26262- 6-10

Software integration and testing
<--> ASPICE SWE.5 Software integration and integration test

ISO 26262- 6-11

Verification of software safety requirements
<--> ASPICE SWE.6 Software qualification test

How can we Help?