To meet ASIL and ISO 26262 requirements, the tools used in design need to reach a certain standard.
By Swami Venkat and Meirav Nitzan
A modern vehicle can boast as many as 100 million lines of code—that’s more than the Large Hadron Collider (50 million lines) and Facebook (62 million lines). On the hardware side, many of today’s cars have upwards of 100 electronic control units (ECUs) to run various functions. As automotive engineering ingenuity continues to drive further innovation in autonomous driving functionalities, the technology inside our favorite mode of transportation will only become more prevalent and sophisticated. That’s why it’s essential to adhere to automotive functional safety standards to prevent chip or software failures.
There are two potential sources of risk in automotive electronics:
Once a product is built in a certain way, a fault that gets incorporated into it remains for the duration. Systemic faults can be addressed by designing and verifying the system design flawlessly, with tools that won’t introduce bugs and won’t fail to find bugs. As for the random issues, integrating safety mechanisms into the design, such as duplication or application-level checking like cyclic redundancy check (CRC), can be effective.
The measures to comply with functional safety are laid out by the ISO 26262 standard, developed by the International Organization for Standardization (ISO) working in conjunction with the International Electrotechnical Commission (IEC) and released in 2011 (with a second edition released in 2018). In order to have their devices qualified to run inside commercial vehicles, automotive OEMs and suppliers must follow (and document) a functional automotive safety development process that spans from specification through production release. The standard explains in detail what to assess for the safety of the car and how this affects the system and its components including the SoC and IP. The process is based on Automotive Safety Integrity Levels (ASILs), a risk classification system, and the primary objective is to reduce potential hazards caused by electrical and electronic system malfunctions.
ASIL has four different levels, each assigned based on the probability and acceptability of harm. ASIL A is the lowest degree of automotive hazard, while ASIL D is the highest degree and the one that is most relevant to safety-critical applications like advanced driver assistance systems (ADAS), anti-lock brakes, and airbags. Complying with the ASILs involves measuring three specific variables for each electronic component in a vehicle:
Each of these variables is further broken down into more granular sub-classes. After each of these variables and the sub-classifications is analyzed, the findings are combined to determine the required ASIL. The classifications are subject to interpretation as well as context, but the aim of the ASILs is, ultimately, to prevent harm.
It’s not enough that the vehicle’s electronic components comply with the ISO 26262 standard. The tools used to develop the components also must be certified (unless the automaker chooses a different approach to functional safety, such as via built-in redundancy). As noted previously, the tools must execute and verify the design flawlessly. To address this, ISO 26262 has a section that covers tool confidence level (TCL), which is defined by tool impact and tool error detection capabilities. Tools in the TCL1 level do not require qualification, while those in TCL2 and TCL3 do, with ASIL determining the qualification methods that are most recommended.
In other words, the design tools themselves are part of the effort to meet ASIL and, ultimately, ISO 26262 requirements. By addressing these requirements, electronic design automation (EDA) and IP vendors can help automotive engineers meet their functional safety objectives and certification —and even accelerate the timeline and efforts to do so. For example, IP provides ready-to-use building blocks that speed up the design process. Automotive-grade IP that meets the stringent guidelines outlined by ISO 26262 puts engineers that much ahead of the game. Some vendors also offer tools to support ASIL planning, design services and tool features that address “what if?” scenarios, and verification/validation solutions that verify an ASIL level has been met.
Since ISO 26262’s official release, Synopsys has proactively performed ISO 26262-compliance testing and incorporated documentation into our portfolio, which includes:
These solutions are backed by a team of automotive experts who can work with hardware, software, and system design teams to address their challenges holistically.
Meirav Nitzan is a program management director in the Verification Group at Synopsys.
 |
 |
 |
 |
 |
 |
 |  |
All Honda civic from 2006 – 2009 that have the recall for cracked engine blocks. Can, and will poison it’s occupants from inhaling antifreeze fumes while driving.