Verification

When an initial FMEDA is setup to assess the safety readiness of a IP/SoC, the DC for the safety mechanisms can be estimated based on the achievable values (low, medium, high) defined in ISO 26262:2011-5, Annex D, Tables D.3 through D.9.

For some standard safety mechanisms (e.g., ECC), the DC value can be calculated analytically. This computation is exact only on some parts of the logic; for example, for ECC, the DC is accurate on the data cell but not for the decoder in front of the memory. In that case, there is a range of variability that might not be acceptable for highlevel ASIL targets (ASIL-D) and requires a more accurate investigation of the DC value by fault injection.

In the case of custom hardware or software safety mechanisms (standard test libraries, or STL), fault injection simulation is a technique that can be used for a more accurate verification of the DC value. It can also be used to evaluate the DTI and the fault reaction time (see Table 2), or to confirm a fault effect.

Functional safety verification is performed starting from the standard functional verification setup. A fault injection campaign to evaluate the safety mechanism DC mainly requires a description of the workload to execute the observation points—that is, where to observe the effect of faults—and the detection points—that is, where to observe the reaction of a safety mechanism.

Referring to Figure 7, the observation points are placed on the primary outputs of the CPU Master, while the detection points are placed on the alarms of the comparator. The measured delay between when the fault is observed and when the fault is detected determines the DTI.

The faults can be classified per the effects on the observation and diagnostic points:

– Dangerous detected: The effect of the fault is seen on both observation and diagnostic points. It means the functional output is affected by the injected fault, but the safety mechanism has detected it.

– Dangerous undetected: The effect on the fault is seen on the observation points, but not on the detection points. In other words, the fault affects the functional output and the safety mechanism has not detected it.

– Safe: The fault does not affect the observation point. It is important to note that the fault can be classified as safe only if the workload provides good coverage for functional verification.

When setting up a fault injection campaign, deciding where to inject the faults is critical. In fact, the safety mechanism under evaluation is targeted to a specific failure mode of the circuit; faults should be injected only in the logic belonging to the related failure mode.

Software Tool Confidence Level

As part of the functional safety management to address the systematic errors, the tools used for the development of a safety-critical application needs to be assessed for their confidence level. The tool confidence level (TCL) quantifies the assurance that failures in the software tools can be detected, very much along the same principles that apply to hardware components. The tool confidence level spans TCL1, TCL2, and TCL3, with TCL1 being the highest; tools classified as such do not require additional qualification and can be used in the development of applications with any ASIL. The TCL determination is based on the criteria summarized in ISO 26262-8:2011, Table 3: it consists of evaluating the tool potential impact on safety applications and the tool error detection capabilities. The information about the software tool compliance is part of the safety package developed for products to satisfy the ISO 26262 requirements for functional safety.

Conclusions

The race to achieve self-driving cars and the corresponding growth of electronics content and complexity has stretched the need for sharing the responsibility of guaranteeing functional safety through the supply chain, bridging the gap from car manufacturers/system providers to semiconductor companies and tool providers. This paper introduced the basics of functional safety and presented considerations on how design methodologies are capturing and addressing the new safety metrics through design/implementation and verification. One could envision that design methodologies will further extend to enhance support for safety requirements.