Sharing_002_The Functional Safety Mirror

This article is copied from the linkedin which is writen by Abdelrahman Hassan. This sharing is only for technical discussion. 

This series is dedicated for the absolute functional safety beginners, system engineers or software engineers or anyone wants to know about automotive functional safety ISO 26262 standard from ZERO

1- Introduction toFunctional Safety Concept

This article demonstrates the functional safety concept that will set functional safety requirements that will mitigate/prevent hazard occurrence of the SbW electric power steering as per the previous article. We will learn how to specify functional safety requirements as per ISO 26262-3 clause 7. The goal of this clause is to set a frame for detection and handling of the item faults to make the item safe. Thatbeing said, the residual faults that are not manifested at the development stage are the root causes for the hazards at the vehicle level. The following figure shows how these faults cause the hazards at the vehicle level, see figure 1:

Figure 1. Propagation of faults on horizontal interfaces;from code to vehicle

Note:

 Horizontal interfaces: HW /SW Interface (HSI), component interfaces and vehicle interface.

ISO 26262 makes a frame for a product measures for different types of failures:

1. technical     safety measures against random HW: by redundancies and self-test

2. technical     safety measures against systematic system, HW and SW: by defensive     programming and design decisions, etc.

Nevertheless, in functional safety concept, we will only address the mitigation of these failures at the function level.

Yet,  we want to verify the HARA work product before proceeding with the functional safety concept. Why?the HARA including the safety goal shall be verified in accordance with ISO26262-8: 2018, Clause 9, to provide evidence for the correctness of item definition and HARA work product.

2- Concept Phase Verification

The hazard analysis and risk assessment including the safety goal shall be verified to provide evidence forthe:

1. compliance     with the item definition; did you include all item     functions in the HARA analysis, did you concern the boundaries and     interfaces?

2. completeness     of the coverage of the hazardous events; did you cover all     potential hazardous events with the potential failure modes?

3. right     selection for the operational situations; did the OEM see that all     listed situations are logical so that he approved the list?

4. consistency     with the related HARA of other items and; you should be aware of the     external items that interface with your item & make sure that your     selected hazard that interact with the other item is consistent with     yours.

5. consistency     of the safety goal with the assigned ASILs and the corresponding hazardous     events; why? because you are going to build the product on the safety     goal and if it is not targeting the correct hazards, you are going to     build the wrong system.

Sometimes, you don't know the effect of the hazardous scenarios on the selected operational situation, you have toask the OEM to simulate your desired scenarios and give you the results to beadded to the verification report. So the result of the above 5 points to be verified at the HARA shall be documentedin a report which is called Verificationreport of the hazard analysis and risk assessment.

3-Functional Safety Concept

Concept means abstract and that is not allocated to any kind of targets or ECUs and not even implemented yet; we still working on the functional level. That being said, no physical system architecture till now. Let's prepare the following inputs to perform the functional safety concept:

1. item definition of the SbW

2. HARA report; not the     verification one

3. system architecture design     (from an external source; from other team as you shouldn't be biased by     any design decision so that you can detect its weakness), see figure 2.

Figure 2. Item Definition of SbW

Objectives

The objectives of this clause-7 are:

1. to specify degraded functional behavior of the item according to its safety goals

2. to specify constraints suitable and timely detection and control of relevant faults

3. to specify measures to achieve fault tolerance to mitigate the effects of thefaults by the driver or by external measure (other items that can mitigate the hazard)

4. to allocate the functional safety requirements to the system architectural design,or to external measures; and

5. to verify the functional safety concept and specify the safety validation criteria

To comply with the safety goals, the functional safety concept contains safety measures, including safety mechanisms to be implemented on item's elements and specified in the functional safety requirements, see figure 3.

Whatis safety measures?

Set of activities to be followed tomake the architecture safe. These measures shall be stated in the safety concept phase; these measures/ activities include safety mechanisms

Whatis a safety mechanism?

A technique used to achieve a level of safety compliance.

Sometimes measures andmechanisms are used interchangeably.

Figure 3. Safety goal allocation on item's elements via allocation of FSRs

In above table you notice that Safety goal B has common functional safety requirement with Safety goal A.

The functional safety requirements shall be derived from the safety goals, considering the system architecture. At least one functional safety requirement shall be derived from each safety goal.That being said, don't cram FSC with unnecessary requirements and don't feel guilty if your FSC document only have one FSR for the safety goal,so that don't waste time and move forward.

The functional safety requirements shall specify strategies for the nine points, if applicable:

1. fault     avoidance

2. faults     detection

3. transition     to a safe state, and if applicable, from a safe state

4. fault     tolerance

5. driver     warnings to reduce risk exposure (E) time to an acceptable duration

6. driver     warnings to increase controllability ( go to lower C)by the driver

7. the     degradation of the functionality in the presence of a fault and its     interaction with 5) or 7)

8. define fault     handling time to meet Fault Tolerant Time Interval (FTTI)

9. avoidance/     mitigation of a hazardous event due to improper arbitration of multiple     control request generated simultaneously by different functions.

Note:

strategies are the overall planand you need to divide it into tactics, i.e. atomic FSRs to achieve yourstrategy objective.

Each functional safety requirement shall be specified by considering the following 5 constraints, as applicable:

1. operating     modes;
2. fault     tolerant time interval;
3. safe states;
4. emergency     operation time interval; and
5. functional     redundancies (e.g. fault tolerance).

The above statement means to specify each requirement of the nine points with each point of the above 5 constraints, if applicable.

Eventually, we talked about HARA verification and the preparation for the functional safety concept by providing: item definition, HARA report and the system architecture without safety mechanisms. Afterwards, we addressed the ISO 26262 framework of thefunctional safety requirements: what is to be covered & how it should bewritten/constrained.

4-  Reference

[1] Wikipedia

[2] ISO 26262:2018

[3] Google images

[4] The Functional Safety Mirror,  previous issues.

5-  About 功能安全沙龙

功能安全沙龙 is used as  an Wechart Public Account for the technical sharing platform on following topics :

• ISO 26262
  
• SOTIF/ ISO 21448
• Cyber-security/J3061 or ISO-21434
• Powertrain Control of PHEV and EV
• ADAS or ADS or AD vehicles