Achieving ISO 26262 Certification With ASIL-Ready IP

What does it take to develop chips that comply with assisted and autonomous driving requirements?


According to an article by McKinsey, “analysts predict revenue growth for advanced driver assistance systems (ADAS) to be up to 29 percent, giving the segment one of the highest growth rates in the automotive and related industries.” This opportunity has invigorated the automotive supply chain to increase their R&D investments for faster product innovations. The focus on innovation is especially paramount in the semiconductor industry as SoC designers try to tackle design challenges and risk of incorporating the latest functionality into their ADAS SoCs. The challenge continues as more automotive technologies are evolving. According to Mary Barra, CEO of GM in a article, “I have no doubt that the automotive industry will change more in the next five to 10 years than it has in the last 50,” she said. “The convergence of connectivity, vehicle electrification, and evolving customer needs demand new solutions.”

ADAS applications like surround view, automatic parking, collision avoidance system, autonomous driving, lane departure warning system with embedded vision, were add-on options that one had to purchase. Today, consumers expect to see ADAS installed in cars as standard features to enhance automotive systems for safety – reduce the number of accidents, injuries and fatalities. For these systems to come together in a timely manner while adhering to a set of stringent automotive functional safety standards, the automotive supply chain, from original equipment manufacturers to semiconductor suppliers including electronic design automation tools and design IP suppliers, must work together to meet all consumer requirements. This article briefly describes today’s automotive ADAS technology trends, and explains the importance of using ASIL Ready ISO 26262 certified IP with automotive safety packages to accelerate SoC development and SoC-level certification.

Semiconductor Technology Trends and Automotive SoC Architecture
The automotive semiconductor technology trend is moving towards widespread usage of sensors. Sensors process a high volume of integrated data which has driven the adoption of 64-bit processing. Other automotive semiconductor technology trends include the use of:

• Ethernet for managing the high data volume including time-sensitive data, and reducing point-to-point wiring
• LPDDR4/4x, operating at data rates of 3200 megabits per second and beyond, for faster DRAM operations in automotive-grade SoCs
• MIPI standards like MIPI Camera Serial Interface and Display Serial Interface for high-performance connectivity in imaging and display applications
• PCI Express for high-reliability chip-to-chip connectivity for 4G radios or the future 5G radios and external SSDs
• 5G and IEEE standards like 802.11p for real-time updates of maps or images to and from the Cloud, and vehicle-to-vehicle or vehicle-to-infrastructure communications
• More advanced manufacturing process technologies from the traditional 90-nanometer (nm), 65-nm and 40-nm to more advanced 16-nm, 14-nm and even 7-nm FinFET processes

Automotive SoCs encompassing the above technologies service a variety of applications in the car. Widely used throughout the car is the traditional architecture that may include over 200 embedded control units manufactured in mature foundry processes. Applications such as power train control, body and chassis control which are powered by this type of SoC architecture do not need much connectivity or processing power. The SoC architecture for connected vehicle and infotainment systems require high-performance connectivity and a more advanced 32 or 64-bit graphics processor to handle up to 12 high-definition video channels. The manufacturing technology in which these SoCs are implemented are in the advanced 28-nm and 16-nm or 14-nm FinFET processes. High-end ADAS SoC architectures are mainly for ISO 26262 safety-critical applications where sensor data must be processed using 64-bits processors with heterogeneous co-processor acceleration like embedded vision processors to offload the host processor. The manufacturing process technology for high-end ADAS SoCs are in the advanced 28-nm and 16-nm, 14-nm or even 7-nm FinFET.

Since high-end ADAS SoCs are mainly for safety-critical applications, they must meet the stringent requirements of the ISO 26262 functional safety standard, which is also applicable to all semiconductor components including design IP that is integrated into the SoC.

ISO 26262 Functional Safety Standard Best Practices
ISO 26262 is an international standard that defines various automotive safety integrity levels (ASILs) – A, B, C and D. ASIL defines the various processes, development efforts and standards that automotive development teams need to implement in order to comply with ISO 26262. A primary focus for automotive SoC development teams is to minimize the susceptibility to random hardware failures by defining the functional requirements, applying rigor to the development process and taking necessary design measures to ensure safety features can mitigate those hardware failures. In addition, apply systematic analysis methods to analyze the status of any component or system throughout the supply chain.

Accredited third-party companies are available to train development teams to ensure full understanding of the ISO 26262 standard and requirements. These companies can also help with reviewing and improving development processes, assessments and certifications. The ISO 26262 certification process must start from the very beginning of development and includes multiple steps to complete the certification process, some of which are detailed below.

Failure Mode Effect and Diagnosis Analysis
Failure mode effect and diagnosis analysis (FMEDA), a report that development teams generate, provides all the information regarding the adherence to ISO 26262 from a functional safety perspective. It is essential that the FMEDA report is concurrently reviewed by design and verification engineers. Fully trained safety managers monitor the development process, milestones and product reviews ensuring all the documentation and traceability is completed throughout the SoC development flow as defined by the standard. These tasks are applied to the entire development process of the SoC block-by-block.

The FMEDA assessment must meet an ASIL assessment. ASIL ratings are not just for evidence of compliance, they also define both design targets and a rating assessments at the end of the development flow. There are four different types of ASILs defined by the ISO 26262 standard: ASIL A (lowest integrity requirements), ASIL B, ASIL C and ASIL D (highest integrity requirements). Let’s go through an example to illustrate a safety-critical product development flow.

Example of A Development Flow
Figure 1 shows a standard development flow of either an IP or SoC. The core architecture and specification goes through RTL design and implementation, and is then verified and validated in hardware and software in the final prototypes.

Fig. 1: Hardware design and verification flow in a commercial product development flow.

An ISO 26262 development is applied to the development flow at the very start when defining a core architecture and specification, as seen in figure 2. This assures the SoC or IP is designed with the required functional safety as defined by the standard.

Fig. 2: An ISO 26262 development is applied to the development flow assuring the SoC or IP is designed with the required functional safety standard.

Depending on the target ADAS application, the architects and designers define safety plans to help manage and guide the execution of safety activities, as shown in figure 3. The safety manger reviews the safety plan and strategy that the development teams are implementing to achieve the designated functional safety for the end consumer application. Safety plans help verify the development flow meets the safety goals, implements the different safety features specified in the safety plan, and measures the impact of any possible product failures and its reaction to those failures in terms of functional safety.

The entire process up to this point is documented and delivered as Work Products, and it includes key milestones, resources, different implementation processes to meet functional safety requirements, etc.

Fig. 3: The architects and designers define safety plans to help manage and guide the execution of safety activities.

FMEDA is a critical step of the safety flow and summarizes the ASIL level for the target application. It is a detailed report encompassing various steps and analysis, as shown in figure 4. For example, FMEDA must show a fault injection analysis for both permanent and transient faults so the impact can be assessed. It looks at all the various failure and distribution modes to understand how the product will behave if a failure occurs and what sort of diagnostics the product implements to identify and communicate those failures to the system.

Fig. 4: FMEDA, a detailed report with various steps and analysis, defines the ASIL level for the target application.

The ISO 26262 standard provides guidelines to help mitigate possible failure modes and how to implement safety features to help counter the impact of the failure modes. The standard defines the safety features by looking at the possible failures based on the different SoC architectures. These failure assessments analysis also apply to IP that is integrated into the SoC. The different mitigation functions and their effectiveness recommended by the standard is shown in table 1.

Table 1: Different mitigation functions and their effectiveness as defined by the standard.

As per the standard’s recommendation, performing full hardware redundancy is the most effective means of providing safety mechanisms which is used in some ASIL D-level systems. Other mechanisms in order of effectiveness are:

• High: configuration register test, EDC on memory, combination of timeout monitoring, frame counter & information redundancy
• Medium: multi-bit hardware redundancy, timeout monitoring, frame counter, information redundancy
• Low: parity bit per word

For example, failure on a data path and maybe a drop of a pixel is a failure, but if there’s a failure in a configuration register that directs the product into a different operating mode, it is a significant failure. So protecting the configuration registers is particularly important in terms of implementing safety mechanisms.

Now the impact of the designated safety features can be defined in the FMEDA report. Safety features fall into three categories:

• “Protection mechanisms” such as protecting the interface between the various products like IP in the SoC architecture, having a right point of protection of elastic buffers, parity protection on the data path and configuration registers, and error correction code protection for both writes and reads.
• “Replication” is another safety feature category that includes duplicating or triplicating key modules and using voting logic to ensure redundancy.
• “Various” includes parity checks for all of the state registers, single cycle pulse validity, various dedicated interrupts, and hot state machine protection for bad states.

The process to meet ISO 26262 functional safety certification is stringent from creating the FMEDA report, designating a safety plan that defines safety features for the target ASIL, to employing a safety manager and documenting and reviewing every milestone with all the stakeholders. A quick glimpse of the process was highlighted in this section.

Additional Automotive Requirements
In addition to meeting ISO 26262 functional safety requirements, automotive SoC development teams and the rest of the supply chain must adhere to automotive reliability and quality requirements.

Any product, including IP, for an automotive application needs to meet the automotive reliability requirement as defined by AEC-Q100. Automotive reliability is measured in terms of parts-per-million failure rates under different operating modes at much higher temperatures compared to consumer products. For this reason, SoC and IP designers designate their own propriety temperature profiles under which products are designed and tested, based on the target application. In case of IP, providers must make sure the IP meets the reliability targets and how the temperature might affect the transistor or electromigration analysis. IP providers must work closely with the foundries to make sure that any automotive rules and addendums are applied to the IP design.

Any product development in the automotive supply chain has to meet the automotive quality management requirements. In addition to having quality manuals and compliance reports, a design, failure mode, effective analysis (DFMEA) report is required and delivered to all stakeholders stating the SoC and its components meet the automotive quality management requirements of the automotive supply chain.

Automotive SoCs and its semiconductor components like IP must adhere to several stringent automotive requirements for functional safety, reliability and quality. With respect to functional safety, the automotive supply chain must adhere to the requirements of the ISO 26262 functional safety standard to achieve certification and accelerate automotive SoC design. The detailed certification process starts early in the development phase and includes multiple steps that are documented and reported to all stakeholders. FMEDA, generated by the development teams, is a report that indicates a product’s ASIL level, safety features and effectiveness. A safety manager is authorized to review the report with all stakeholders at each level of product design and milestone. Both design and verification engineers should be part of the development teams.

Automotive reliability and quality management are also key requirements that SoC designers and IP providers must meet. All parts in the SoC must perform to the high-reliability levels at varying temperatures as defined by AEC-Q100. Quality manuals and reports, compliance reports and a DFMEA report must be shared with all stakeholders to show quality as defined by the automotive quality management.

For more information on how to achieve ISO 26262 certification with ASIL ready IP, click here.


Joe says:

Hi Ron

I have an question, so after the product is ‘certified’, if there is a change to a safety feature, does a registrar need to come back and re-certify the product for every change? Do you need to communicate to the registrar?

Leave a Reply

(Note: This name will be displayed publicly)