SLOA294A June 2020 – April 2024 TPS3851-Q1 , TPS7A16A-Q1
Hardware faults can be either systematic or random in nature, as shown in Figure 2-1. Systematic faults result from an inadequacy in the design, development or manufacturing process and typically stem from gaps in the development process. A silicon bug is a systematic fault because it is detectable during the design verification phase of development. For example, designing a car and specifying that it has square wheels is considered a systematic fault because the car does not work with that shape of wheel. By adhering to a rigorous development process, it is possible to manage and mitigate systematic faults – and even eliminate them completely – by making continuous process improvements.
Conversely, random hardware faults cannot be eliminated. These faults arise from the fact that all electronic systems fail eventually. Consequently, the ability to address random hardware faults is limited to detecting and possibly preventing them. In the case of automotive electrical, electronic and programmable electronic systems, alerting drivers to a problem enables some control over the impact of random hardware faults.
Table 2-1 and Table 2-2 list the acceptable values of random hardware failure metrics associated with each ASIL or SIL value according to the requirements of ISO 26262 and IEC 61508 respectively.
ASIL Level | SPFM | LFM | PMHF (in FIT; Failures in Time) |
---|---|---|---|
ASIL B | ≥90% | ≥60% | ≤100 FIT |
ASIL C | ≥97% | ≥80% | ≤100 FIT |
ASIL D | ≥99% | ≥90% | ≤10 FIT |
SIL Level | SFF | PFH (in FIT; Failures in Time) |
---|---|---|
SIL 2 | ≥90% | ≤1000 FIT |
SIL 3 | ≥99% | ≤10 FIT |
Both IEC 61508 and ISO 26262 exclude systematic failures while calculating random hardware metrics. Consequently, BFR is only applicable to the failure mode distribution and calculation of random hardware metrics.