Orchestrating an efficient ISO 26262 fault campaign

Inflation of the Fault State Space

The automotive industry continues to experience massive disruption as new electronic systems supporting electric vehicles, advanced driver assistance system, and autonomous vehicle applications come online. Some estimates predict that by 2030, electronic systems will make up 50% of the bill of materials cost for a vehicle. There is no rest for the weary as automotive IC companies attempt to find their foothold in this key growth market. Veteran automotive semiconductor companies as well as newcomers are continually challenged to deliver innovative products quickly to market while staying on budget. In addition to delivering differentiating capabilities, project teams must also ensure the delivery of safe semiconductors. Specifically, companies must deliver evidence that a product fails safely for lower levels of vehicle autonomy and fails operationally for high levels of autonomy.

ISO 26262 is the state of the art safety standard for both commercial and passenger automobiles, providing guidance on the activities and work products required to demonstrate the achievement of safety. More specifically, ISO 26262 provides specific safety targets for random failures, which are the type of failures that occur during the operational life of a system. Random failures cannot be designed out, so the standard dictates that such failures must not result in the violation of a safety requirement. Most commonly, these failures come in the form of permanent failures, such as stuck-at failures, or transient failures, such as single event upsets.

To verify a semiconductor has implemented a sufficient safety architecture protecting against random failures, project teams must perform safety verification of that safety architecture. A safety architecture is comprised of a set of safety mechanisms (hardware or software) and the necessary higher level processing to ensure the failure is detected and controlled. Safety verification of a safety architecture is similar in concept to traditional functional verification, but rather than identifying functional bugs, the primary objective is to understand whether the safety architecture sufficiently prevents random failures from violating a safety requirement. To complete safety verification, faults are injected and propagated in the design to validate functional correctness of the safety mechanisms and classify each fault. Fault classifications are then used to generate the required safety metrics. The remainder of this paper will detail a methodology and the solutions used to close on a fault injection campaign.