Customer pain points in achieving functional safety Vol. 2

You may encounter various obstacles when you try to develop an automotive ASIC/ASSP (Application Specific Standard Product) that meet the design compliance of the ISO26262 functional safety standard. This blog introduces the flow from Automotive Safety Integrity Level, ASIL determination to safety mechanism specifications creation, and describes the common customer pain points and countermeasures in the flow we often share with our customers.

0. Focus on ISO26262 Part 3 (Concept Phase); Part 4 (Product Development: System Level); and Part 5 (Product Development: Hardware Level)

1. Determine ASIL and create Safety Mechanism specifications

Note, the ASIL level is determined by safety-criticality of the component under development. An automotive ASSP is developed by applying SEooC (Safety Element out of Context) of the ISO26262 standard. It starts with the item definition of an automobile function. Fig. 1 shows the flow and outline of each process from item definition to hardware safety requirement specifications.

(A) Item definition: ISO26262-3 (ISO26262 Part3: same below)
This is the stage of defining the input, output and functions of the component associated with an automobile function.

(B) HARA (Hazard Analysis and Risk Assessment): ISO26262-3
Hazard analysis and risk assessment for the item defined in (A) is performed, and ASIL is determined at this stage based on the evaluation results of HARA: Severity class (S1-S3), Exposure class (E1-E4) and Controllability class (C1-C3).

(C) Functional safety concept: ISO26262-3
Safety measures are taken for failures that infringe on the safety of Intended Functions (IF) of the item defined in (A), and functional safety requirements (FSR) are derived. This is the stage of implementing an architecture-level safety design for the (IF).

(D) Technical safety concept: ISO26262-4
The input / output of the item defined in (A) has expanded to the internal elements at signal level. Based on the results of the functional safety concept, the technical safety concept is carried out at the signal level. And the Technical Safety Requirements (TSR) are derived. At this stage, the signal level specifications related to functional safety are finalized for the ASSP and safety measures are implemented for failures that violate safety for the Intended Functions inside the ASSP at the architecture level.

(E) Hardware safety requirement specifications: ISO26262-5
Based on TSR, safety measures are implemented against the failures of the logic inside ASSP and Hardware Safety Requirements (HSR) are derived. At this stage, specifications of safety mechanism requirements are determined.

It is necessary to carry out the above (A)-(E) consistently based on the standard requirements of ISO26262,and prepare documents as evidence.

2. Pain points and countermeasures in determining ASIL

In an ASSP development, the ASIL is pre-defined at the planning stage based on market research, but as a result of implementing HARA, ASIL may become too strict. In this case, if the development time, circuit scale, and power consumption are increased, it may be impossible to develop the ASSP.

It is easy to overlook, but ISO26262-4 section 6.4.2.5 has a provision that ASIL can be lowered by two levels if certain conditions are met (note, ASIL has four levels with D being the most demanding). It can be used only if the ASIL derived in HARA becomes stricter than the ASIL value at the planning stage. However, in large-scale and high-performance ASSPs, the required ASIL is often ASIL-B, which is an effective method. The application flow for ISO26262-4 6.4.2.5 is shown on Fig. 2.

(A) Item definition:
From the Intended Functions of the ASSP, the functions targeted by ISO26262-4 6.4.2.5 (safety mechanism in automobile system; for example, warning display of airbag system) are extracted. The rationale for the extraction should be clarified.

(B) HARA: Carried out as usual.

(C) Functional safety concept: Carried out as usual.

(D) Technical safety concept:
ASILs for the functions specified in (A) are described in technical safety requirement specifications by lowering by two levels. Be sure to specify the rationale.

(E) Hardware safety requirement specifications: Carried out as usual.

3. Pain points and countermeasures in creating Safety Mechanism specifications

In recent years, automotive digitization has progressed and power shortages have occurred with respect to the electric capacity of batteries. However, when creating hardware safety requirement specifications, the circuit of ASSP is complex, so the safety mechanism by simple duplication must be adopted.  Unfortunately, it often leads to an increase in circuit scale and power consumption, and impairs market competitiveness.

When creating hardware safety requirement specifications, the Intended Functions targeted for safety measures in technical safety concept are divided into more detailed functions. Then, the hardware safety concept is performed to determine the requirement specifications for safety mechanism on the detailed functions, which typically have a smaller circuit scale and lower power consumption versus simple duplication of the overall function.

However, the hardware safety concept should not be clarified as a process and should be implemented as part of the work of deriving the hardware safety requirement specifications. If it is clarified as a process, it will be subject to tailoring (when changing from the standard regulations), the process of safety activities will increase, and the man-hours for functional safety management will also increase.

Countermeasures to overcome these pain points must be implemented consistently with the ISO 26262 requirements. Since it is necessary to understand the essence of ISO26262 requirements and interpret them accurately, only engineers who have FSM / FSE qualifications and have extensive experience in designing and verifying automotive ASSPs can handle them.

For more details, please contact Vtech.