Requirements Hierarchy
Functional Safety Requirements (FSR) are derived from Item definition, HARA and Safety goals and are traced back to Safety Goals. Each Safety goal shall have a minimum of one FSR associated with it.
Technical Safety Requirements (TSR) are mainly derived from FSRs. Each FSR shall have a minimum of one TSR associated with it.
The below image provides a hierarchical view of requirements/activities flow from ISO26262 Part 3 – Item definition to Part 5 Hardware Safety Requirements (HSR) and Part 6 Software Safety Requirements. Also visit our YouTube video which explains the flow of Functional Safety requirements.
Difference between FSR and TSR
This table gives the high-level differences between FSR and TSR.
Boundary: FSR vs TSR
Let us take the example of a Cruise control feature to better understand the boundary between FSR and TSR. In the below image, Cruise control feature is represented as an Item and has several Modules interacting with each other such as Cruise control module, User Interaction, Brake Module and Engine Module. Item definition talks about the behavioral expectation of a function at vehicle level. When we define the FSR, the scope of the entire Item definition must be considered as boundary. This is highlighted with Green color dotted line in the image. Each FSR shall specify requirements at Vehicle level and shall be allocated to the Module which implements it.
TSR specifies the requirements at System level. Hence the boundary of TSR is at Module or Systems level. This is highlighted with Orange dotted lines in the image.
Implementation Independent vs Implementation Associated
Requirements that specify the functional behavior without getting into “how” the functionality is implemented are Implementation Independent Requirements. Requirements that specify “how” the functionality is implemented are Implementation associated Requirements.
Let us go back to our Cruise Control example and understand this aspect of requirements better.
FSRs for Functionality
Fault Monitoring and Mitigation
The below FSR format shall be used to define fault monitoring requirements.
FSR 1: “ECU shall be able to detect the XXXX Fault with YYYY time frame”
FSR 2: “ECU shall transition to safe state (item level safe state) within ZZZZ time frame upon confirmation of fault”
Here “XXXX” is any fault that affects Vehicle level Functionality (like malfunction in the data or communication. YYYY is Fault detection time and ZZZZ is fault reaction time. YYYY + ZZZZ should be less than FTTI (Fault tolerant time interval).
FSR must specify a generic requirement to avoid or detect and mitigate failure instead of specifying the solution directly. For example,
- Cruise Control Module shall indicate to the User in case a malfunction is detected
- Cruise Control shall have measures to detect Internal malfunctions (instead of providing solutions like Power supply monitoring, External watchdog etc) within YYYY time frame
TSRs for Functionality
Let’s take “Cruise control module shall indicate to the User in case of malfunction detected” as FSR and derive a TSR framework for the same.
- TSR requirement shall specify the exact CAN interface details
- TSR requirement shall specify the exact criteria for enabling/disabling of the feature
- TSR requirement shall specify the Monitoring correctness and aliveness of the data
- TSR requirement shall specify the Systems level operating modes (for ex. Operating modes shall be based on Ignition status)
- TSR requirement shall specify the debouncing timing for the Hardware related inputs
Fault Monitoring
TSR shall specify the solutions for Fault monitoring aspects that are available at systems level. For example,
- Cruise Control shall implement a safety mechanism to detect faults in the RAM holding the Cruise control data
- Cruise Control shall implement a safety mechanism to detect timing and execution faults of the Cruise control Algorithm
For example, If Memory protection unit is considered as part of system level concept, then TSR shall specify the same. Otherwise, TSR shall allow the freedom to decide the solution at Software design level. Also refer to our article related to TSR for more details.