Functional Safety is not a new concept, but it is taking on new importance within the automotive market due to increased electronics and advanced features like ADAS (Advance Driver Assistance System). This is sparked by the need to be certain that electronic systems are going to function as we intended them to, without malfunction.
Functional safety means that potentially dangerous conditions are detected, activating preventive or corrective mechanisms to stop or mitigate the hazardous event. Functional safety, defined by ISO 26262, aims to reduce the risk of software and electronics to a very low level that society finds acceptable Let's look into these concepts in more detail.
What is Functional Safety
Functional Safety is an intrinsic property of a system that performs in a way that does not present an unreasonable risk of injury to the operator or bystander. As per ISO26262 functional safety is defined as 'Absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems'. It does not address hazards related to electric shock, fire, smoke, heat, radiation, and similar hazards unless directly caused by the malfunctioning behavior of a safety-related E/E system.
We all know safety is a very important factor and we also know that providing 100% safety is not possible in all scenarios or use cases. Let's try to understand the functional safety concept with the help of railroad crossing. In the below image, we can see a side the crossing system is inherently accident-prone and does not guarantee reasonable safety. Whereas the image on the right shows by adding functional safety measures to the railroad cross, we can achieve an acceptable level of safety.
With a brief understanding of the Functional Safety concept, let's jump into understating ISO 26262 standard.
Overview of ISO 26262:2018
ISO 26262 is an adaptation of IEC 61508 for the automotive industry. It deals with the functional safety aspect of E/E systems in passenger vehicles whose weight is less than 3.5 tonnes. Which means it deals with passenger vehicles as opposed to trucks and commercial buses. It covers the management and technical aspects of the complete safety development lifecycle.
The below image contains different parts of the ISO 26262 standard. The initial release of ISO26262:2011 had 10 parts. In the initial version, no clear guidelines for semiconductors and cybersecurity were not being focused on as these issues weren't a big concern in 2011. In the second version of ISO26262:2018 part 11 has been added for 'Guidelines on the application of ISO26262 to semiconductor' and Part 12 has been added for 'Adaption of ISO 26262 for motorcycles". The V watermark that you see in the below image is for example development V model inside ISO 26262 and the standard does not place any restriction on other methodologies. The overshoots of V signify that those different parts are connected.
Part 1: Vocabulary
Part 1 defines the vocabulary to achieve a common language and interpretation of the content in the other parts. Here you’ll hear terms such as hazard analysis and risk assessment, safe state, and freedom from interference for the very first time. Below are a few definitions of a few terms for reference.
Hazard – Potential source of harm caused by malfunctioning behavior of the system
Harm – Physical injury or damage to the health of the person
Risk – Combination of the probability of occurrence of the harm and the severity of the harm
Malfunctioning behavior – Failure of unintended behavior of an item
ASIL- Automotive Safety Integrity Level - Level to specify the system’s necessary requirement of safety measures to apply to avoid an unreasonable risk
Freedom from Interference - Absence of cascading failures between two or more elements that could lead to violation of Safety requirements
Item – System or combination of systems to which ISO 26262 to applied, that implements a function or part of a function at the vehicle level
Part 2: Management of functional safety
Part 2 addresses the management of functional safety. According to ISO 26262, to achieve functional safety, you need to work in a structured and controlled manner. Not only do you need to have a trained safety manager but you need to train all the engineers to cultivate safety work culture. Usually, the safety manager is in charge of planning and controlling the safety activities. Apart from this you also need to create a "safety case" that includes artifacts, traceability metrics, etc. which ensures your system is safe.
Part 3: Concept phase
Part 3 to part 7 of the ISO 26262 standard guides different phases and technical disciplines. It ranges from the early concept phase to the post-decommission of the vehicle. As mentioned earlier this part follows the V-shape of the system development lifecycle.
Part 3 is called the concept phase and this is the early stage of vehicle and feature development. Usually, this is performed by the vehicle manufacturer aka OEM. Development starts with defining the scope which is called the item in ISO 26262. Then comes the "Hazard Analysis and Risk Assessment (HARA)". With the HARA you can judge the risk to human life when your item is faulty. Based on risk we define a set of so-called "safety goals" for the item. These goals are high-level safety requirements to be met. They all get an “Automotive Safety Integrity Level”: ASIL A, ASIL B, ASIL C, or ASIL D, similar to the Safety Integrity Level(SIL) in IEC 61508. We classify items to ASIL D when the risk is highest. Take the adaptive cruise control for instance or the airbag control unit. These items would typically be assigned ASIL D. An electric window lift where we just risk pinching our fingers would probably be ASIL A.
What follows now is that functional safety goals must be addressed during system development. At the vehicle level, based on safety goals, a "functional safety concept" and "functional safety requirements" are developed, which describe how to detect faulty situations and what should be the response to mitigate or avoid those faults.
Part 4: Product development at the system level
The functional safety concept is usually developed by the OEM and then the various suppliers come into play with the system development on the next level (part 4). Typically, the suppliers create a “technical safety concept” for their area of responsibility, which includes “technical safety requirements”. “Safety mechanisms” implement these safety requirements. Depending upon technical safety requirements OEM develops a mechanism to detect and/or correct faults either at the hardware level or at the software level.
Parts 5 and 6: Product development at the hardware and software level
From system or item-level requirements, we need to implement those into hardware and software levels. For example, from system-level technical safety requirements, we need to derive software safety requirements i.e. how those safety goals are implemented at the software level. In part 6 there are different methods are prescribed which are denoted as 'Recommended', 'Highly Recommended', or 'Optional' as per ASIL level. Different testing methods for different phases of development are enlisted to ensure software safety concepts are implemented correctly and required artifacts and traceability matrices are established.
We will discuss part 6 in more detail, especially the verification and validation part in our next article. What you require on the system level has to be implemented on the hardware and software level. These are parts 5 and 6 of ISO 26262. Detail your safety requirements for both engineering domains hardware and software development. Remember the V-model: don’t forget to consider testing on all levels. Test and validate the safety mechanisms and the functioning of your safety concept at the system and vehicle level before you switch on the assembly line. You must therefore note that ISO 26262 contains several requirements and methods that influence the usual development process at the system, hardware, and software level in detail.
Part 7: Production, operation, service, and decommissioning
Our responsibility doesn’t end with the end of the development phase. That’s why we come to part 7, Production, operation, service, and decommissioning. It is often necessary to check that the electronics have been produced and installed safely. Repairs in workshops must not pose a safety risk. Part 7 discusses these things in great length.
Part 8: Supporting processes
Part 8 is labeled "Supporting processes". In this section different no. of topics are taken from various stages of the lifecycle. For example configuration management, tool qualification, etc.
Part 9: ASIL-oriented and safety-oriented analyses
Part 9 contains a safety analysis that needs to be carried out while developing and this serves as an accurate source of understanding the cause and effects of faults and ensuring the design is correct.
Part 10: Guidelines on ISO 26262
Part 10 of the standard contains additional explanations for a better understanding of the standard. This part is just informative but helpful if you are not familiar with the standard.
Part 11: Guidelines on the application of ISO 26262 to semiconductors
Part 11 gives very detailed guidelines on the use of semiconductors and microcontrollers in safety-related systems.
Part 12: Adaption of ISO 26262 for motorcycles
Part 12 has been added especially for motorcycles. It essentially contains information on how the hazard analysis and risk assessment is sensibly carried out for bikes as a minor risk for a vehicle can lead to hazardous risk in the case of a motorcycle.
Above was a very brief introduction to the ISO 26262 standard. For detailed information please refer to https://www.iso.org. Do share your views on the above summary and let me know which topic you would like to know more about in the comment section.
Comments