Functional Safety Concept for Self Driving Cars
Introduction to ASIL Decomposition, Safety requirements, ASIL Inheritance and Warning and Degradation concept
Hello and welcome to this Medium article 😃 Let’s emphasize again the ultimate goal of functional safety, avoiding accidents by reducing risk to acceptable levels. First let’s figure out what subsystems actually contain high levels of risk and what’s needed to prevent accidents. Looking at the items architectural design, we’ll figure out which subsystems and elements can be used to meet safety goals. We’ll need to further refine these high level goals into what we call functional safety requirements. And then we’ll allocate each functional safety requirement to its appropriate place in the item architecture. We take all of this information and put it into a document called the functional safety concept. Please take a look at the previous medium articles I wrote about functional safety for cars first.
Functional Safety Requirements
Going back to the lane departure warning example from the previous medium article, let’s derive a couple of functional safety requirements from our first safety goal.
Our malfunction was that the steering wheel warning vibration was too strong. The malfunction led to the safety goal that the oscillating steering torque of a lane departure warning function shall be limited. For the lane departure warning system, it makes sense to define a maximum allowed torque amplitude and a maximum allowed frequency. From the safety goal, we will define two functional safety requirements for the lane warning departure system.
Functional safety requirement one.
The lane keeping items shall ensure that the lane departure oscillating torque amplitude is below max torque amplitude.
Functional safety requirement two.
The lane keeping item shall ensure that the lane departure oscillating torque frequency is below max torque frequency.
Notice again that we use the term shall, because these are requirements. So what have we done so far? We started with a safety goal requiring the vibration to be limited. We looked at the item architecture and came up with two new requirements that would meet our safety goal. We then figured out that the lane assistance item needed to limit the vibration amplitude and vibration frequency.
Allocation of Requirements to Architecture
Our lane departure warning system now has two functional safety requirements. One requirement limits the steering wheel vibration frequency, and the other requirement limits the steering wheel amplitude. Now we have to figure out which part of the lane keeping the item will be responsible for limiting the vibration torque and the amplitude. The lane assistance item has three subsystems, the camera, the display, and the electronic power steering. Let’s take a look at the architectural diagram.
Logically, we could say that both the camera subsystem and electronic steering subsystem could limit the frequency and the amplitude. For instance, we could make a requirement that the camera subsystem can only request a vibrational torque below a maximal threshold. And we could also make a requirement that the power steering system can only output a vibrational torque below the same limit. But we want to reduce the complexity whenever possible. The simpler solution is to only require the power steering to limit the vibration no matter what the camera ask for. Now the only relevant subsystem from a functional safety standpoint is the power steering. For the lane departure warning, the allocation of the requirements to the architecture is straight forward. Only an electronic power steering ECU is involved with limiting the vibration warning. The two functional safety requirements are allocated to the power steering ECU. We will also slightly change the wording in the functional safety rArchitecture Used (Image by author)equirements, whereas before we said the lane keeping item had to limit the vibrational torque, now we’ll be more explicit and say the power steering, ECU, will limit the vibrational torque.
Here are the final safety requirements:
Functional safety requirement 1.
The electronic power steering ECU shall ensure that the lane departure warning oscillating torque amplitude is below max torque amplitude.
Functional safety requirement 2.
The electronic power steering ECU shall ensure that the lane departure warning oscillating torque frequency is below max torque frequency.
Architecture Refinement
Now that we have a better sense of what the system needs to do, we are going to draw all the extra functionality on the architectural diagram. Let’s add more details to the three subsystems.
The car display subsystem will need extra software blocks. One controls a light that tells the driver if the lane keeping item is on or off. A second will control a light telling the driver that the lane departure warning is activated.
The camera subsystem needs two software blocks, as well. One for lane sensing and a separate block to send a torque request to the electronic power steering subsystem.
The electronic power steering subsystem will need three software blocks. The first will sense how much the driver is turning the steering wheel. A second software block will receive the vibrational torque request from the camera subsystem. This is where we will limit the amplitude and frequency to be low max torque amplitude and max torque frequency. The third block will add these torque requests together to output a final torque to the motor that moves the steering wheel.
We have now derived functional safety requirements and allocated those requirements to the architectural diagram.
Functional Safety Requirements and ASIL Inheritance
We need to add ASIL labels to the refined architectural diagram. Otherwise, we won’t know which subsystems and elements require analysis under ISO 26262. The general rule is that functional safety requirements inherit the ASIL directly from the safety goal. From the hazard analysis and risk assessment, the lane departure warning safety goal was that the torque had to be limited. We determined that the safety goal had ASIL C. The two functional safety requirements for the lane departure warning would then inherit the ASIL C. Because we allocated these two functional safety requirements to electronic power steering, the entire subsystem inherits the ASIL C classification. But what about the ASIL of the camera in the car display subsystems?
We said earlier that the only relevant subsystem from the functional safety standpoint was the electronic power steering. We do not have any functional safety requirements for these two subsystems. Therefore, we can mark the camera in the car display as QM. As a reminder, a QM rating stands for quality management. Any part of the architecture where the QM rating is no longer relevant to a functional safety analysis because the risk is already at acceptable levels. Here’s a quick review of what we have accomplished so far.
We derived functional safety requirements from the safety goals, refined the architecture and allocated the functional safety requirements to the architecture and we determine the risk levels for the three subsystems. Next, we’ll see if there are any ways to lower the ASIL for any of our system elements.
ASIL Decomposition
We’ve already said that the electronic power steering subsystem is ASIL C for the lane departure warning functionality. Although ASIL C is not the highest level of risk, ASIL C still does add many extra testing and verification demands not required by a lower ASIL. Is there any way to lower the ASIL for at least some of the architectural elements?
It turns out that there is. It’s called ASIL decomposition. Imagine part of our system is label ASIL D. If we create two completely independent but redundant systems, ISO 26262 actually allows us to label each redundant system ASIL B. This comes from basic probability. If the probability of a malfunction equals 0.8 then the probability that two completely independent redundant systems will fail together is 0.8 times 0.8 which equals 0.64, redundant systems lower risk. What is the benefit of creating independent redundant systems?
ASIL B requires less analysis and testing than ASIL D. For reference, we should label the new Independent Systems ASIL B(D), in recognition that the system was originally ASIL D. What are the most common ASIL decompositions is splitting off a single element into a non-safety relevant and safety relevant part. The non-safety relevant block will be QM. The benefit is that ISO 26262 will only apply to part of the original element. Let’s see how this works. We are going to decompose the lane departure warning software block inside the power steering ECU. We will split the latest system software into two parts. One software element will contain code for normal functional behavior. We will create a separate software element to take care of our functional safety requirements. Let’s look at our system architectural diagram again. The electronic power steering software a block is labeled ASIL C. With ASIL decomposition, the software block that takes care of normal functional behavior now gets a QM(C) label. The software block that takes care of malfunctions inherits the ASIL C. Now we no longer have to apply ISO 26262 to the normal behavior software block. By refining the architecture and determining ASILs, we are figuring out how much risk is in each element and subsystem. Decomposition then allows us to lower the ASIL of some of the architectural elements.
Fault Tolerant Time Interval
Deriving functional safety requirements and allocating those requirements to the system architecture is the main part of a functional safety concept. To finish up the article, we still need to talk about three more attributes of a functional safety requirement. The fault tolerant time interval, the warning and degradation concept, and the verification of validation acceptance criteria. We’ll start with the fault tolerant time interval. We need to define how long the system has to detect and then react to a malfunction. We call this the fault tolerant time interval. Let’s look at our ADS lane departure warning as an example. One concern is that the warning vibration amplitude will be too high. If the amplitude does get too high then a malfunction, also called the fault, has occurred. It will take the system a certain amount of time to detect a malfunction and signals travel through the hardware and the software. This is the diagnostic test interval. Once the system detects the high amplitude, it will take time for the vehicle to turn off the lane departure warning function. This is the fault reaction time.
Once turned off, the lane assistance system has reached a safe state where risk is at acceptable levels. We want the lane assistance system to reach a safe state before an accident has occurred. So there is a buffer between when the system reaches a safe state and when an accident would have occurred. So fault tolerant time interval equals diagnostic test interval plus fault reaction time plus time in safe state before an accident. Each safety requirement receives a fault tolerant time interval. We will say that the lane departure warning system has a fault tolerant time interval of 50 milliseconds. We can use this value for the two functional safety requirements already discussed. This is an example of value we might see in practice but the real world lane departure warning function might have a different value.
Warning and Degradation Concept
For each functional safety requirement, we need to discuss how the driver will be warned of the malfunction. For the lane assistance item malfunctions, we will display a warning on the driver dashboard. If the steering wheel ECU receives a vibrational torque request beyond the allowed maximum, a warning light will turn on. Note that we have added a connection from the power steering ECU to the driver display subsystem. We also need to describe what the vehicle system will do after a malfunction occurs. When a malfunction occurs, the system needs to go to a state with a lower acceptable risk level.
This lower risk level is called a safe state. We have already said that both the lane departure warning function and the lane keeping the system function will turn off when a safety requirement is violated. Turning a system off can generally be considered a safe state with acceptable risk levels. A warning and degradation concept will include how the driver will be alerted when the system has reduced functionality, or is turned off completely, and how the vehicle will transition to and recover from the safe state. The car manual should include information from the warning a degradation concept as well. For the lane keeping assistance function, the manual would probably include a warning that the functionality is not meant for autonomous driving, and the driver maintains responsibility for the safe operation of.
With this, we have come to the end of this article. Thanks for reading this and following along. Hope you loved it! Bundle of thanks for reading it!
My Linkedin :)
