Functional Safety

Abstract

Functional safety is a subset of system safety in which active measures are sought to ensure the safety of a system. Typically, functional safety deals with the definition and assessment of a safety subsystem implementing safety functions. Safety functions are used to detect errors or other anomalies in the system operation and act by bringing the system to the safe state in which harm or damage can no longer occur (e.g., cutting off the power, applying brakes). This chapter introduces the main concepts and architectures in the field of functional safety, with the correct positioning of the equipment under control (EUC), EUC control system, safety-related system, and the safety functions and key principles upon which they operate. Important early insights into how safety-related system is evaluated and its safety integrity proven are also given, by introducing the requirements for systematic safety integrity as well as for the safety integrity against random system failures.

Appendices

Exercise 5

Follow-up on the considerations for the electric scooter created during the exercises at 1, 2 and 3, and based on the identified hazards, extends the requirements specification with the safety requirements (which are derived from/related to corresponding functional requirements describing functions which exhibit hazards) and derive several technical safety requirements for each of the safety requirements, defining in more detail specific requirements of the safety function which shall fulfill the safety requirements. Specifically pay attention to what the safety function shall do, freedom from interference, requirements for the safe state, response time, and the required safety integrity level (SIL), expressed according to a standard of choice.

Your Tasks for the Exercise

• Remember the electric scooter requirements from your exercise in Chaps. 1 and 2, and the identified early hazards in Chap. 3.

• Select one hazard from Chap. 3 and identify a system function that exhibits the selected hazard and the corresponding functional requirement.

• Define a top-level safety requirement that would describe the active safety measure (safety function) which would be needed to prevent the hazard; make sure the traceability from the safety requirement to the functional requirement is kept.

• Derive several technical safety requirements from the safety requirement, providing more details on the specific requirements from the safety function, considering the abovementioned aspects (monitoring and intervention means, behavior around the safe state, freedom from interference, response time, safety integrity level required).

• Update the system requirements specification (SRS) accordingly and be ready to discuss.

• Make sure to use FuSa terminology around your items correctly!

To-Do List

• Perform the exercise individually or with your peers. One can share the screen and keep notes, all contribute.

• Create presentables (e.g., reworked requirements table based on a template from Chap. 2).

• Discuss your solution and share it with others.

Note: Digital files for this exercise are available at sfs5.ex.nit-institute.com.

Exercise 5 Sample Solutions

See several exemplary solutions to the exercise:

Solution 1

Review Comments by the Instructor

• Make sure to unify the terminology in your requirements, once you start talking about the SRS (which is the “break control system” probably in your case, or you should name it something else so that is clearly disambiguated from ECS). Currently, you are using “break control system” and “system” interchangeably which may cause confusion.

• You have correlated ASIL-A with failure rates 10⁻⁵–10⁻⁶ as per IEC-61508, although this is just based on probability, whereas ASIL level needs controllability, exposure, and severity, and IEC needs probability and severity. Make sure to be able to argue this correlation and not to make too blunt assumptions. However, in ISO 26262 in the HW chapter, there is actually a prescription with regard to failure rates of hardware which can be correlated to ASIL levels (ASIL A being at approx. 1000 FIT – 10⁻⁶). However, this is when determining whether your hardware is SIL compliant, and not vice versa (you should perform formal HARA instead!).

• Nomenclature-wise, technical safety requirement is denoted as TSR, whereas nontechnical safety requirements at this level can be also noted as QSR (quality safety requirement), for example, for SIL.

Solution 2

Review Comments by the Instructor

• Requirements definition is usually one field composed of all the required aspects. Currently, you have split it into Description and Intervention, which can be done while brainstorming, but the final SRS shall be made in a standard requirements specification format.

• One note: in case you have a very high-level safety requirement (e.g., Folding shall not happen during driving) which is not prescribing any measure, this is usually called safety goal (SG) and placed at the same level as HLRs.

• Make sure to address freedom from interference aspects as well.

• ASIL levels are inherited by TSRs from the SRs, based on, e.g., PHI. It is strange to have different ASIL levels at this point. It seems you have started to prematurely think about the implementation and ASIL allocation to functional blocks or perhaps even ASIL decomposition (what is possible in theory but here not convincingly performed).

Solution 3

Review Comments by the Instructor

• It is not obvious where the SR_001 was derived from. It is fine for the exercise but usually, it is related to the FR or derived from HLR based on PHI. The definition of the safety function seems sane.

• Aspects such as freedom from interference and SIL allocation to requirements need to be also provided.

Solution 4

Review Comments by the Instructor

• It seems you have added TRs with the intention to enhance the quality of the overall functions (as additional quality requirements) rather than prescribing the safety function what was the goal of the exercise.

• Safety function addressing SF_101 shall probably be able to detect (by MONITORING) whether the braking was unintentional (by, e.g., pressure sensor on the handle or similar method) and then performing INTERVENTION (e.g., by signaling the malfunction and entering the safe state – the question is what it could be if we need to prevent the braking – what probably should not be done).

• It is good to detail EUC/ECS, etc. for the exercise, but, e.g., safe state requires to use of the braking system as a remedy, whereas the braking system itself is the cause of the problem in the first place. Safety function, therefore, needs to provide freedom from interference, by finding an alternative way to brake (having, e.g., redundant/additional braking system – e.g., another mechanical brake).

Key Recap Questions

In this chapter, you have been analyzing the prescription of active safety measures (safety functions). Now, with regard to the system you discussed:

• Think up a safety function.

• Which safety requirement/safety goal does it address?

• How the safe state is defined?

• What is the safety integrity level of the function?

• Discuss freedom from interference!

• Can you make your system fail-operational?

Self-assessment

Now take the time to self-assess your knowledge by taking the quiz below. Each listed statement is either correct or incorrect. Please mark your answer and then check in the key at the end of the book.

• 1. Safety functions always address hazards exhibited by the functions of EUC, but not the functions of ECS.

• 2. Safety functions execute on top of the safety-related system (SRS) which can be made an integral part of the ECS only if the freedom from interference is provided.

• 3. A safe state is a state in which a system induces no harm or damage, and in which all system functions are always turned off.

• 4. The safety function shall monitor the system only for dangerous failures of its functions.

• 5. In case SRS fails, the system is immediately considered unsafe.

• 6. The electronic control unit within SRS shall always comply with the safety integrity level determined from the risk category of the hazard which is actuated by a dangerous failure of an EUC function.

• 7. A safety function operating in an on-demand mode can be made of less reliable components than the equivalent safety function operating in a continuous mode.

• 8. Safety integrity level is among the most important requirements for the safety function.

• 9. Methods of implementation of the safety function (e.g., system engineering processes, software development techniques) shall always be at the highest possible quality according to the standard regardless of the SIL allocated to that safety function.

• 10. Hazard A is identified, with risk evaluated according to ISO 26262 as ASIL C. The function of the system exhibiting this hazard then always needs to be reworked so that it satisfies the requirements for ASIL C according to the standard.

Self-assessment Key

• 1. False

• 2. True

• 3. False

• 4. False

• 5. True

• 6. True

• 7. True

• 8. True

• 9. False

• 10. False