State of the art
functional safety.
ISO 26262 ROAD VEHICLES
Functional safety (FuSa) provides an automotive safety lifecycle (management, development, production, operation, service, decommissioning) and supports tailoring the necessary activities during these lifecycle phases. It determines an automotive-specific risk-assessment approach to identify Automotive Safety Integrity Levels (ASIL) and uses them to specify applicable requirements to avoid unreasonable residual risks.
SOTIF (SAFETY OF THE INTENDED FUNCTIONALITY)
ISO 21448 defines SOTIF as hazards caused by insufficiency of specifications/performance limitations or misuse. SOTIF must be used together with functional safety.
UL 4600 STANDARD
For safety evaluation of autonomous products; it 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 combines several standards 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 21448 and UL 4600.
Functional safety & SOTIF.
The two standards complement each other yet focus on different causes. ISO 26262 deals with preventing hazards due to malfunctions within a system by requiring mitigations based on severity, controllability, and the exposure SOTIF deals with.
WHAT ARE THE UNKNOWN and HAZARDOUS SCENARIOS (AREA 3) IN SOTIF?
There are 4 scenario categories in the SOTIF standard - hazardous or not hazardous, known or unknown. While known and not hazardous scenarios are considered naturally during development and validation; area 3 - the unknown and hazardous scenarios are the challenge. The goal is 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 becomes associated to area 1 or area 2.
WHAT IS ASIL DECOMPOSITION?
In certain circumstances ASIL can be lowered by applying architectural methods that allow to split the requirements' safety rating into two or more elements of a lower rating 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 much overlap between the two. The concept phase, product development at the system level, product development at the software level, and supporting processes all have a strong relationship to the processes in Automotive SPICE®. Examples 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
