Generally not accepted as a virtue, finding faults is of paramount importance when it comes to developing ISO 26262 compliant solutions. Faults, especially in complicated automotive systems, can be a result of multiple causes. For example, if an electronic parking brake (EPB) fails to engage, there would be several reasons behind such failures like actuator fault, power supply issue, control system failure and so on.
Fault Tree Analysis (FTA) is like drawing a big tree structure to figure out all the ways in which such a fault could occur.
The goal of Fault Tree Analysis (FTA) is to ensure that all potential failure modes are identified, and appropriate measures are taken to mitigate them. ISO 26262 standard stresses on the use of FTA to structure the potential causes for a fault. This exercise is performed in an ordered tree structure so that the relationship between the causes can be understood clearly.
What is Fault Tree Analysis in the Context of ISO 26262 Compliance
Fault Tree Analysis (FTA) is a deductive safety analysis method deployed in the process of building safety-critical automotive solutions. At the top of this tree, we have the top-level event—usually a major hazard or violation of a safety goal.
How Does FTA Work?
FTA involves breaking down the system into smaller components and analysing how their failures can propagate.
We use logical operators like AND, OR and more to assemble these components. For example:
- AND: Both Event A and Event B must occur for the system to fail.
- OR: Either Event C or Event D can cause the failure.
- Exclusive OR gate: An event occurs if one of the input conditions is met, not necessarily all.
- Priority AND gate: An event happens only after a specific sequence of conditions.
- Inhibit gate: An event requires specific input events and whatever a conditional event describes.
By combining these events, we create a fault tree that shows all possible paths to system failure.
Simply put, here is the process of fault tree analysis in brief:
- Define the Top Event: Clearly specify the undesired event or failure mode.
- Identify Immediate Causes: Determine the direct causes of the top event.
- Expand the Tree: For each cause, identify further sub-causes and continue until reaching the basic events.
- Analyze Logical Relationships: Use logical gates to connect causes and sub-causes, showing how multiple failures can combine to result in the top event.
- Quantitative Assessment: If quantitative FTA is performed, assign probabilities to the basic events and calculate the overall probability of the top event.
Since, we are set to understand FTA from ISO 26262 standard’s perspective, it is important for us to know,
Why Is FTA Important in ISO 26262 Compliant Development?
ISO 26262 is all about ensuring functional safety in road vehicles, especially those with electrical and electronic systems. Think of it as the rulebook for keeping our cars and trucks safe from digital hiccups.
Fault Tree Analysis is a systematic method for analyzing the potential failure modes of a system. Within ISO 26262, FTA plays a crucial role in:
- Assessing the impact of hardware failures on safety goals.
- Quantifying the Probabilistic Metric for Hardware Failure (PMHF)—a fancy term for the likelihood of hardware-induced hazards.
- Tailoring safety requirements based on Automotive Safety Integrity Levels (ASILs).
The ISO 26262 standard mandates deductive analysis for both ASIL C and ASIL D. FTA, being one of the most widely used methods for deductive analysis, becomes the preferred method.
Here’s an example of fault tree analysis for an ISO 26262 compliant electronic brake ECU:
The main aim of qualitative Fault Tree Analysis (FTA) is to find the tiniest group of events called a “minimal cut set”. When all these events happen together, it leads to the big problem (the top event). Here’s an example of cut set order report derived from the Fault Tree shown above.
S.no | Cutset Order | Cutset | Cut Set ID Description | Probability of failure(Q) |
1 | 2 | [EV1,SM1] | EV1:H-Bridge component random HW failure SM1 :H-Bridge feedback monitoring failure |
1.20E-07 |
2 | 2 | [EV2,SM2] | EV2: H-bridge driver ASIC random HW fault SM2:Motor driver status monitoring by uC |
2.10E-05 |
3 | 2 | [EV3,SM3] | EV3: Microcontroller random HW fault SM3:Microcontroller watchdog monitoring |
7.00E-06 |
4 | 2 | [EV4,SM4] | EV4:Fault in power supply output SM4:Supply voltage monitoring |
1.20E-05 |
Let’s understand the process with the example of electronic parking brake ECU.
Top Event: Unintended Electronic Brake Apply
Any unintended instance of EPB application can cause severe consequences for the vehicle’s occupants. ASIL D has been assigned for the same reason. Unintended EPB application could lead to a sudden and unexpected braking event, causing loss of vehicle control, potential collisions, and significant harm to occupants and other road users.
ASIL D represents the highest level of risk in the ISO 26262 standard, indicating the need for the most stringent safety measures.
As seen in the diagram above, three faults have been identified for unintended EPB application:
The H-Bridge is an electronic circuit that allows a voltage to be applied across a load in either direction. It is used to control the direction of the motor in the EPB. An H-bridge output fault refers to a failure in the output stage of the H-bridge circuit, which is used to control the direction and power of the current flowing to the motor in an Electronic Parking Brake (EPB). The output stage typically consists of transistors or switches that manage the current to the motor.
Fault in H-Bridge Output - The H-Bridge is an electronic circuit that allows a voltage to be applied across a load in either direction. It is used to control the direction of the motor in the EPB. An H-bridge output fault refers to a failure in the output stage of the H-bridge circuit, which is used to control the direction and power of the current flowing to the motor in an Electronic Parking Brake (EPB). The output stage typically consists of transistors or switches that manage the current to the motor.
H-Bridge Component Random Hardware Failure (EV1) - Random hardware failures in the H-Bridge components (transistors, diodes, etc.) can result in unintended motor activation. There are two main causes for such faults:
- Short Circuit: A short circuit within the transistors can cause the motor to be continuously powered, leading to unintended brake application.
- Open Circuit: An open circuit can result in loss of control signals, causing the brake to engage unexpectedly.
Mitigation: Utilization of high-quality, reliable components and incorporating protective features such as fuses and current limiting circuits to prevent damage.
H-Bridge Feedback Monitoring Failure (SM1) - The feedback monitoring system in the H-Bridge provides real-time data about the output status. Failures in this feedback mechanism can lead to incorrect signals being sent to the EPB motor. Two most probable causes that lead to such faults are:
- Sensor Faults: Inaccurate feedback due to sensor malfunction can cause the system to misinterpret the motor's status, engaging the brake unintentionally.
- Signal Integrity: Poor signal integrity due to electromagnetic interference (EMI) can disrupt feedback signals.
Mitigation: Implementation of robust feedback mechanisms with redundant sensors and EMI shielding to ensure accurate monitoring.
-
Fault in H-Bridge Input -A fault in the H-bridge input means the signals controlling the H-bridge are acting up, potentially causing the EPB to engage unexpectedly. Imagine you're driving, and suddenly your car's parking brake activates without warning. This can happen due to signal interference, software glitches, or hardware issues in the control circuits. In our FTA example, we pick up the most widely known causes:
-
Fault in H-Bridge Driver ASIC - The Application-Specific Integrated Circuit (ASIC) driving the H-Bridge controls the power and direction signals to the EPB motor. Faults in the ASIC can result in unintended brake application.
- Logic Errors: Errors in the ASIC logic can send incorrect signals, causing unintended motor activation.
- Power Supply Variations: Inconsistent power supply to the ASIC can lead to malfunction.
Mitigation: Designing the ASIC with robust logic verification and stable power supply systems. Employ techniques like Triple Modular Redundancy (TMR) for critical logic functions.
The fault in H-bridge Driver ASIC can be attributed to two other faults:
H-Bridge Driver ASIC Random Hardware Fault (EV2) - Random hardware faults in the ASIC can cause unexpected behavior in the H-Bridge driver, affecting the EPB motor.
- Thermal Runaway: Overheating can cause the ASIC to fail.
- Electromigration: Prolonged current flow can cause gradual degradation of the ASIC’s conductive pathways.
Mitigation: Ensuring proper thermal management with heat sinks and cooling systems. Also using materials and design techniques to minimize electromigration effects.
Motor Driver Status Monitoring Failure (SM2) - The motor driver’s status monitoring system ensures that the driver is operating correctly. Failures in this system can cause incorrect motor activation.
- Fault Detection Algorithms: Ineffective algorithms may fail to detect and respond to driver faults.
- Signal Processing Errors: Errors in signal processing can misinterpret the motor driver status.
Mitigation: Improving fault detection algorithms and ensuring accurate signal processing with high-resolution ADCs and reliable software.
Fault in Microcontroller - The microcontroller controls the overall EPB system. Faults in the microcontroller can lead to unintended brake application. The faults can vary depending on MCU design and layout, environmental conditions, thermal management, firmware bugs and more. We have included the two most commonly seen faults.
- Firmware Bugs: Software bugs can send incorrect control signals to the EPB system.
- Hardware Malfunctions: Physical faults in the microcontroller can disrupt its operation.
Mitigation: Performing thorough firmware validation and using robust microcontroller designs with built-in error-checking mechanisms.
Microcontroller Random Hardware Fault (EV3) - Random hardware failures in the microcontroller can cause unintended activation of the EPB. A Microcontroller Random Hardware Fault happens when the microcontroller unexpectedly fails due to issues like electrostatic discharge, overheating, or manufacturing defects. Imagine your car's EPB engaging suddenly because the microcontroller is at fault. Here’s two of the most probable causes:
- Electrostatic Discharge (ESD): ESD events can damage microcontroller components.
- Aging Effects: Long-term operation can degrade the microcontroller's performance.
Mitigation: Using ESD protection strategies and choosing microcontrollers with high endurance and reliability ratings can be helpful in mitigation.
-
Microcontroller Watchdog Monitoring Failure (SM3) - The watchdog timer monitors the microcontroller’s operation and resets it if necessary. A microcontroller watchdog monitoring failure happens when the watchdog timer stops responding and fails to detect issues. Picture your car's EPB not engaging because the watchdog didn't catch a microcontroller freeze! Why does it happen?
- Timeout Errors: Incorrectly configured watchdog timers can fail to reset the microcontroller when needed.
- Signal Glitches: Signal disturbances can cause false watchdog resets.
Mitigation: Properly configuring watchdog timers and using debounce circuits to filter out signal glitches is one way for mitigating such faults.
-
Fault in Motor Driver Supply - A Fault in the Motor Driver Supply occurs when the power provided to the motor driver is unstable or fails. During FTA, this fault seems to be emanating from any of the following channels:
-
Fault in Power Supply Output (EV4) - The power supply provides necessary voltage and current to the EPB motor driver. Faults in the power supply can lead to unintended brake application.
- Voltage Spikes: Sudden voltage spikes can cause the motor to engage.
- Power Loss: Complete power loss can cause the brake to engage as a fail-safe.
Mitigation: Using surge protectors and ensuring stable power supply design with backup power sources.
Supply Voltage Monitoring Failure (SM4) - The voltage monitoring system ensures that the motor driver receives the correct voltage. Failures in this system can cause unintended brake application.
- Sensor Accuracy: Inaccurate sensors can misread voltage levels.
- Monitoring Circuit Faults: Faults in the monitoring circuitry can fail to detect voltage anomalies.
Mitigation: Using high-accuracy voltage sensors and designing robust monitoring circuits with redundancy.
-
Conclusion
Fault Tree Analysis (FTA) is essential in achieving ISO 26262 compliance in automotive development. It helps identify and analyse potential failure modes, determine their causes, and calculate the likelihood of undesirable events. This fits into the larger ISO 26262 framework by ensuring every component and system is thoroughly vetted for safety risks.
Together with other safety analyses like FMEA, DFA, FMEDA etc., FTA plays a key role in building safe automotive solutions.