Demystifying EDA Support For ISO 26262 Tool Qualification

My new, mid-size car is equipped with many advanced driver-assistance systems. To be honest, it’s taking me time to get used to some of them, as, for example, lane-centering assist that seamlessly takes control of my steering wheel. However, I cannot wait to get my hands off a fully autonomous vehicle and be able to take a nap while 7nm chips run machine learning and other artificial intelligence algorithms do the driving for me.

Over the last decade, these applications have propelled automotive electronics into the cutting-edge club once reserved for high-end smartphones and beyond. Unlike smartphone screens, though, the steering system must definitely not freeze while I am sleeping, even if unavoidable random hardware failures occur.

The ISO 26262 functional safety standard is crucial to develop complex electronic systems that provide the level of safety required by modern automotive applications.

ISO 26262 tool qualification
Safety standards must be rigorous and ISO 26262 most certainly is. Engineers use numerous software tools and there is no doubt that these tools may introduce or fail to detect errors in hardware designs. ISO 26262 does not overlook this possibility, and part 8 section 11, titled “Confidence in the use of software tools,” aims to reduce the risk of undetected tool malfunctions.

The first step is to determine the required tool confidence level (TCL), which in turn depends on tool impact (TI) and tool error detection (TD) capabilities (see Fig. 1). Most tools have impact TI2 as they can either introduce or fail to detect errors. TD indicates the confidence that tool errors will be prevented or detected. For a given TI and TD, TCL can be uniquely determined as shown in Fig. 1. For example, if tool impact is TI2 and tool error detection is TD1 (high confidence), the required confidence level is TCL1. It is worth noting that TI, TD and the resulting TCL depend on the specific use case of a tool within a project.

Figure 1: The ISO 26262 tool classification and qualification are comprehensive to meet adequate tool confidence level.

TCL1 tools do not require qualification. TCL2 and TCL3 tools require additional tool qualification activities that may be complex and time consuming. The standard recommends an appropriate combination of the tool qualification methods listed in Fig. 2. Each method is either recommended (“+” sign), or highly recommended (“++” sign), depending on the TCL and the automotive safety integrity level (ASIL) of the application.

Figure 2: Recommended tool qualification methods of the ISO 26262 standard depend on a structure set by TCL and ASIL.

TD3 is not the low confidence level in error detection
Many papers and EDA marketing pieces refer to TD3 as the “low” confidence level in tool error detection. In fact, TD3 is the “other,” thus neither high nor medium level. TD3 is a simple, safe choice, while a TD1 claim needs to be strongly supported with arguments and evidence.

For example, additional redundant tools or effort-intensive reviews of tool results could support the claim of high confidence that potential tool errors would not go undetected. Claiming TD1 for a tool on its own often is unfeasible. Some EDA vendors get around this by promoting TD1 strategies based on the use of a monolithic tool chain.

TCL1 is not the highest tool confidence level
Another overused, misleading statement is that TCL1 is the highest TCL. While the standard defines TD1 as the high-confidence level in tool error detection, at no point does it refer to TCL1 as the highest TCL.

In fact, I would claim that TCL1 is the lowest possible required TCL. If a development process has sophisticated (and likely expensive) tool error detection measures in place that support a TD1 claim, which in turn leads to a TCL1 classification, there is little required confidence in the tool itself.

The point is that potential tool errors will be either prevented or detected.

On the other hand, if one claims TD3, then there is a strong need to carefully qualify the tool and give evidence that there is little chance that it will malfunction in the first place. Engineers developing hardware for the stringiest safety applications (ASIL D) must use tool qualification methods that demonstrate high confidence that TCL2 or TCL3 tools will not malfunction.

A paper from Mirko Conrad, formerly of MathWorks, refers to TCL1 as the “lowest possible TCL.”

Third-party safety certificates are not all the same
EDA vendors may offer specific documentation and additional evidence to reduce tool safety compliance efforts. They often engage with third-party organizations that perform independent assessments and grant safety certificates.

Certifications can cover individual tools or tool chains. The assessment may involve the review of documentation and other artifacts that support TCL1 claims. For other TCL levels, the assessment may be much deeper and include an evaluation of the tool development process, a review of the tool validation and testing infrastructure and even a factory inspection. Safety certificates are a key component of vendor-provided tool qualification kits (TQKs). A high-quality TQK enables engineers to claim adequate tool qualification, even for TCL3 tools and ASIL D applications, with minimal effort and without being tied to a specific vendor’s tool chain.

TÜV SÜD is an accredited global testing, inspection and certification provider that grants different types of safety certificates and related stamps. A TÜV SÜD webinar explains the implications of different certification stamps and gives advice on how to find the right software tools for functional safety projects.

Monolithic tool chains are suboptimal
Diversity brings robustness. For example, it is not unusual that some hardware design code compiles perfectly fine on a set of tools from the same EDA vendor. As soon as one tries to compile the same code on a tool from a different vendor, however, some issues worth looking at come up. Further, most CAD groups would rather not be locked to a single EDA vendor.

Finally, no EDA vendor has the best solution to all problems. Monolithic, single-vendor tool chains defy all three principles. Claiming TCL1 for a monolithic tool chain may seem to be a shortcut to ISO 26262 compliance, but it is in fact a weak, risky approach.

Conclusion
Establishing an efficient, ISO 26262-compliant development flow is challenging. EDA vendors must provide dedicated, interoperable solutions with clear information on the type of tool qualification support they include.

To learn more about ISO 26262 tool qualification and high-quality TQKs, visit onespin.com/tuv.