ISO 26262 remains the state of the art standard guiding the development of electronic and electronic systems destined for the automobile. By 2030, some estimate that the BOM of a vehicle will be 50% electronics and electronic components. Regardless, ISO 26262 has solidified itself as the backbone of the safety lifecycle for semiconductor companies. The standard is far reaching, delivering guidance from concept to decommission across OEMs, Systems Integrators and Suppliers. For suppliers, the guidance is focused into three areas:
- Lifecycle Management: The process and governance required within the lifecycle
- Systematic Failures: The activities and work products required to ensure the component operates per the requirements.
- Random Failures: The activities and work products required to ensure the component fails safely when a random failure occurs.
Lately, much of the attention is given to the activities surrounding Lifecycle Management and Random Failures (also known as Random Faults). This is likely due to these two pillars being new challenges for many semiconductor companies moving into the automotive market. However, it is important to not discount the challenges faced within the systematic failures pillar, especially as the exponential growth in IC complexity challenges even the most veteran IC teams in delivering a bug and defect free device. As a recap, systematic failures are failures which are due to design bugs, manufacturing defects, missing functionality, etc…
When viewing these failures over time using the classic bath-tub curve, systematic failures are the failures at T < 0.
ISO 26262-11:2018 provides guidance to companies developing semiconductors and within, details a list of activities to eliminate systematic failures. These are the suggested activities and work products which tie back to the normative requirements found in Part 5 of the standard. The figure below lists just some of the activities recommended by the standard and one of those activities is coding rules and style checks, also commonly referred to as design linting.
The design linting recommendation ties back to the non-negotiable normative requirements found in ISO26262-5:2018 7.4.4. Unfortunately, the standard doesn’t deliver specific guidance on the types of checks required, but it is safe to assume that any check which prevents the escape of a bug or defect should be included in the analysis. During an audit, the Lint reports as well as waivers and the rationale for each waiver must be supplied as evidence that the activity was performed to satisfaction.
Here at Siemens EDA, we provide a head start to customers by offering a built in ISO26262 ruleset and also provide the reports leveraged during audit. This checkset is part of our next generation Questa Lint solution and is a great starting point in ensuring the checks performed align with the intent of the standard. Please refer to the Questa Lint fact sheet for an overview of capabilities.