ISO 26262 Part 3.7: Functional safety concept (FSC) - Detailed Explanation (Part 1/3)

ISO 26262 Part 3.7: Functional safety concept (FSC) - Detailed Explanation (Part 1/3)

Introduction:

• This blog tries to explain the clauses in Functional Safety Concepts (FSC) and Functional Safety Requirements (FSR) in detail. 
• The reader can easily compile the various necessary sections of the blog to derive at a template for the FSR/FSC work product. 
• In order to save the readers from the ordeal of going through a long blog, this blog has been divided into 4 Parts based on the clauses and their categories. All the clauses in ISO 26262-3:2017(E) for FSC can be grouped into following categories based upon their applicability.

ISO 26262-3:2017(E) Clauses	Applicability/ Categories	Covered in which part of this Blog?	Blog Link
-	Introduction	ISO 26262 Part 3.7: Functional safety concept - Detailed Explanation (Part 1/3)	EmbeddedInEmbedded: ISO 26262 Part 3.7: Functional safety concept (FSC...
-	Sample Safety Goals for Antilock Braking System (ABS)
7.4.1, 7.4.2.1 ~7.4.2.7	Functional Safety Requirements derivation
-	Sample Functional Safety Requirements for Antilock Braking System (ABS) Item
7.4.2.8 ~7.4.2.10 7.4.3	Functional Safety Concepts derivation	ISO 26262 Part 3.7: Functional safety concept  - Detailed Explanation  (Part 2/3)	EmbeddedInEmbedded: ISO 26262 Part 3.7: Functional safety concept (FSC...
-	Sample Functional Safety Concepts for Antilock Braking System (ABS) Item
7.4.4	Verification of the Functional Safety Concept	ISO 26262 Part 3.7: Functional safety concept  - Detailed Explanation  (Part 3/3)

* References are mentioned in the last part.

Sample Safety Goals for Antilock Braking System (ABS) Item:

• Taking the item identified in the previous blog for "Anti Lock Braking System", the following Safety Goals (SG) are presumed for further analysis.
• Blog: EmbeddedInEmbedded: ISO 26262 Part 3.5: Item Definition
• * - Currently the below ASIL levels are assumed. detailed analysis in terms of Hazard Analysis and Risk Assessment (HARA)

SG ID	SG Description	ASIL *
SG1	The ABS module shall prevent locking of the wheel.	D
SG2	The ABS module shall prevent any unintended actuation	D
SG3	The ABS module shall be able to detect malfunction which will prevent it from acting.	D

Functional Safety Requirements (FSR):

• FSR shall be derived from the Safety Goal.
• The FSR shall be attributable to a module derived during the Item Diagram/ Preliminary Architecture Diagram.
• The FSR define the functional part of the implementation. Technical details like how to do it is not mentioned here. For example, if the vehicle speed is being shared between ECU at FSR/FSC level whether this is done through CAN or LIN or SPI is not decided. This is decided during the Technical Safety Requirements (TSR)/ Technical Safety Concepts (TSC).

How to derive Functional Safety Requirements (FSRs)

ISO 26262-3:2017(E) – Clause 7.4.2.1, 7.4.2.2, 7.4.2.5 :
*** Please refer this clause from originally procured licensed copy of ISO26262 Part 3*** 

• Derived from Safety Goals.
• Requirements related to Faults, Safe State, Timing, Warning and Degradation etc.
• Requirements related to Driver Actions.

Requirements related to Faults, Safe State, Timing, Warning and Degradation etc.

ISO 26262-3:2017(E) – Clause 7.4.2.3:
*** Please refer this clause from originally procured licensed copy of ISO26262 Part 3*** 

Each FSR should be derived from the Safety Goal so that following requirements are covered.

a) fault avoidance:

• The Fault should not take place in the first case. This is the basic purpose of the Safety Goal and why the safety life cycle is being followed.
• For example: In case of ABS system is assumed as an Item, the Locking of the wheels (considered as the Fault) should be avoided. This is the primary function of the Item is to avoid locking of the wheels.

b) fault detection and control of faults or the resulting malfunctioning behavior:

• The Fault should be detected and if necessary employ correct control mechanism in order to avoid any safety goal violation.
• For example: In order to avoid the Locking of the wheel, the Item should be able to detect the locking well before time and try to prevent locking and its resulting malfunctioning behavior.

c) transitioning to a safe state, and if applicable, from a safe stated) fault tolerance

• Safe state is defined as an operating mode in case of failure of an Item without an unreasonable level of risk. 
• Different safety goals may have same or different safe states based upon there targeted functionality. Hence different FSRs tagged to these Safety Goals have different safe states.
• The FTTI (Fault Tolerant Time Interval) is associated with every safety goal. The sum of Fault Detection Time (TFD) and Fault Reaction Time (TFR) for the Safety Goal should be well within the FTTI specified for the goal. i.e. (TFD + TFR < FTTI). If this is not satisfied then Safety Goal is violated.
• The time difference between FTTI and (TFD + TFR) is spent by the Item in the Safe State.
• Please refer the Blog for more details of FTTI.  iso-26262-warning-and-degradation
• The below diagram explains the above points.

• For example: 
• Consider the first Safety Goal (SG) for ABS i.e. “SG1: The ABS module shall prevent locking of the wheel.”. In this SG, the ABS Item shall detect the locking of the wheels and react to prevent the locking of wheels within the FTTI and transit to the Safe State of “Wheel not locked” (Normal Function).
• Consider the second Safety Goal for ABS i.e. “SG2: The ABS module shall prevent any unintended actuation.”. In this SG, the ABS Item shall prevent any unintended activation of the ABS functionality. The ABS Item should detect and prevent unintended activation within FTTI. Here also the Safe State is “Wheel not locked” (Normal Function).
• But for the third Safety Goal for ABS i.e. “SG3: The ABS module shall be able to detect malfunction which will prevent it from acting.”. In this SG, ABS should detect a malfunctioning ABS module and shut it down without affecting the normal functioning of the brake. Hence the Safe State should be “ABS Turned Off”.

e)the degradation of the functionality in the presence of a fault and its interaction with f) or g); EXAMPLE Maintaining the vehicle in a limp-home mode until the ignition has been switched from "on" to "off".

• In case the ABS is deactivated, then the normal brake should be active. Here we can consider the “Normal Braking” as a degraded functionality from the Safety Goal point of view (Though it is an absolute necessity).

f)driver warnings needed to reduce the risk exposure time to an acceptable duration
g)driver warnings needed to increase the controllability by the driver (e.g. engine malfunction indicator lamp, ABS fault warning lamp)

• The FSRs should also cover requirements related to driver warning, which enables the driver to take informed decision effectively.
• For Example: For ABS Item, in case of the Safety Goal “SG3: The ABS module shall be able to detect malfunction which will prevent it from acting.”. If the malfunction is detected, then the ABS warning light is enabled in the dashboard for the driver.
• In case driver is aware that the ABS is not active, he/she can try to avoid going into such a situation. In case the driver has to go to such situation, he/she should not depend upon the ABS system and take control manually. 

h)how timing requirements at the vehicle level are met, i.e. how the fault tolerant time interval shall be met by defining a fault handling time interval; and

• FSR definitions should have time requirements like FTTI. 

i)avoidance or mitigation of a hazardous event due to improper arbitration of multiple control requests generated simultaneously by different functions.

• If we consider the below 2 Safety Goals
• “SG1: The ABS module shall prevent locking of the wheel.”.
• “SG3: The ABS module shall be able to detect malfunction which will prevent it from acting.”
• The FSR should be clear that in case SG3 is violated, then SG1 should not be attempted. Both of these should be independent functions and arbitration should be pre-decided.

ISO 26262-3:2017(E) – Clause 7.4.2.6:
*** Please refer this clause from originally procured licensed copy of ISO26262 Part 3*** 

The FSR should also define requirements (if applicable) related to the Emergency Operations.

• The Emergency Operations define the actions that needs to be taken in case the safe state is not achieved within the FTTI.

Requirements related to Driver Actions:

ISO 26262-3:2017(E) – Clause 7.4.2.7:
*** Please refer this clause from originally procured licensed copy of ISO26262 Part 3*** 

• If some assumptions are considered where the driver (or any other person) has to take some action to avoid violation of the safety goal, then these should be mentioned in the requirements.
• The FSR should also include these actions and control/methods available with the driver (or any other person).
• The various warning and degradation concepts can be covered here.

Properties Functional Safety Requirements (FSRs):

ISO 26262-3:2017(E) – Clause 7.4.2.4:
*** Please refer this clause from originally procured licensed copy of ISO26262 Part 3*** 

• The following properties are applicable to each FSR (if applicable).

Sample Functional Safety Requirements for Antilock Braking System (ABS) Item:

Notes:

#1 – Assuming the ABS is activated 15 times per second to avoid any lock situation. Hence the full cycle of Fault detection (Locking) and Fault Reaction (ABS activation) occurs approximately (1000msec/15 = 66.6 msec). That can be divided as Fault detection (Locking) – 30 msec and Fault Reaction (ABS activation) – 30 msec. So that (30 msec + 30 msec) < 66.6 msec.

#2 – These values may vary based upon OEM requirements and on road analysis.

#3 – The BCM is assumed to be main ECU which shall relay the failure status to Driver after receiving from ABS. (ABS -> BCM -> Driver Dash board). The appropriate choice of ECU shall be done by OEM.

#4 – It is assumed that the ABS failure LED on the dashboard shall be active within 100msec of ABS module failure detection.

FSR ID	FSR Description
FSR_1	The ABS module shall use the -      brake on/off activation signal -      wheel speed signal for engaging and disengaging the ABS functionality. The ABS should be activated only brake is pressed and if the speed is more than 15mph#2.
FSR_2	The ABS module shall receive the brake on/off activation signal.
FSR_3	The ABS module shall be able to detect the 4-wheel speed signal from the 4-wheel speed sensors.
FSR_4	The ABS module shall be able to detect the deceleration in any of the 4-wheels. It shall also be able to detect any imminent wheel lock up scenario.
FSR_5	In case of imminent wheel lock up scenario, then action shall be taken to prevent lock up.
FSR_6	The ABS module shall have mechanism to detect if any error is present in brake activation signal every time it is received.
FSR_7	The ABS module shall have mechanism to detect if any error is present in 4-wheel speed signal every time it is received.
FSR_8	The ABS module shall execute the diagnostics test sequence after ignition and determine any error present.
FSR_9	In case of any failure detected, the ABS module shall disengage the ABS and notify the BCM#3.
FSR_10	In case of any error detection arising of any of the failure, the ABS module shall shut down and shall not affect normal braking of the vehicle.

Abbreviations:

Acronym	Description
Mph	Miles per Hour
Msec	Milliseconds
FSR	Functional Safety Requirements
BCM	Body Control Module
ABS	Antilock Braking System
TSR	Technical Safety Requirements
TSC	Technical Safety Concepts
FTTI	Fault Tolerant Time Interval

(...Continued in Next Part)