By Ron DiGiuseppe, Product Marketing Manager, Synopsys
By Ron DiGiuseppe, Product Marketing Manager, Synopsys
The adoption of new automotive Advanced Driver Assistance System (ADAS) applications has significantly impacted the system architecture of the latest generation of cars. Traditionally, the electronic control units (ECUs) for individual ADAS applications have been placed throughout the car: the forward collision avoidance ECU located in the windshield, park assist ultrasonic sensors, and the processor in the rear. ECUs integrate the multiple ADAS applications into centralized domains to combine multiple ADAS functions. The new class of integrated domain controller ECUs utilize data transferred from the car’s remote sensors such as cameras, LIDARs, radar, ultrasonic, and other sensors to the integrated domain controller for processing by a high performance ADAS system-on-chip (SoC). The integrated ADAS domain controller SoC requires higher computing performance while consuming less power and requiring smaller footprints.
The increased functionality of integrated ADAS domain controller impacts the ADAS SoC architecture in the ECU including the SoC-level automotive certification which remains a mandatory requirement for designers. Moreover, the IP in the integrated ADAS domain controller SoC must also meet the highest Automotive Safety Integrity Levels (ASILs), must be designed and tested for grade 1 and 2 temperatures, and must fully adhere to the automotive quality management process. In addition, to meet the power and performance requirements of the new integrated ADAS domain controller SoC architecture, designers are moving to more stringent process technologies, such as FinFETs, making it even more important to use automotive-certified IP in advanced foundry processes.
This article highlights the new integrated automotive ADAS domain controller SoC architecture, and describes how designers can accelerate their SoC-level certification and time-to-production with automotive-certified IP.
A Shift to Integrated ADAS Domain Controller SoC Architectures
According to the August 2016 Traffic Safety Facts Research Note by the National Highway Traffic Safety Administration (NHTSA), “the nation lost 35,092 people in crashes on U.S. roadways during 2015, a 7.2% increase which is the largest increase in nearly 50 years.” It was analyzed that about 94% of those accidents were caused by human error, and the rest by the environment and mechanical failures. The opportunity to reduce car accidents is making automotive ADAS even more critical. Automatic emergency braking, pedestrian detection, surround view, park assist, driver drowsiness detection, and gaze detection are among the many ADAS applications that assist drivers with safety-critical functionalities to reduce car accidents. Figure 1 shows an integrated ADAS domain controller SoC with a centralized ECU where data from numerous sensors travels to a central ECU and is then processed via an ADAS processor.
Figure 1: Data from sensors travel to a central ECU and processed via a vision processor
The trend towards the new integrated ADAS domain controller SoC architecture is evident in numerous new public product announcements from companies like Delphi Automotive (now Aptiv) and Audi. According to the article “Delphi: Industry Must Go Digital or Die” by James M. Amend of WardsAuto: “Delphi Automotive sees a day very soon when a vehicle’s traditional architecture no longer will be able to handle the computing demands of heightened connectivity and, ultimately, fully autonomous driving, but the supplier thinks it has a solution and wants to be the leading integrator of the technology.” In the article, Glen De Vos, senior vice president and chief technology officer at Delphi says, “We have to start thinking of the car as a digital platform, and it is a very different way to think about the car.” According to audi.com, “now for the first time, a central driver assistance controller (zFAS) permanently forms a comprehensive image of the surroundings from the sensor data – for a wide range of assistance functions. This is created by complementary sensor systems, plus redundant data fusion in the zFAS and the radar control unit.”
High volumes of data is driving the adoption of 64-bit processors for automotive ADAS applications. The shift from a distributed architecture to a more centralized ECU is more prevalent, and since the ECUs are integrated, the ADAS SoCs are becoming very complex, requiring the latest semiconductor features, semiconductor process technologies, along with other technologies for ADAS domain controller SoCs:
Safety-critical applications are significantly increasing the adoption of ADAS SoCs. However, it is required that the ADAS SoC along with all semiconductor components including the IP that is integrated into the SoC meet the ISO 26262 functional safety standard.
Meeting ISO 26262 Functional Safety Standard Requirements
ISO 26262 is a standard that defines the impacts of failures in automotive systems at four different Automotive Safety Integrity Levels (ASILs): A, B, C, and D; ASIL D is the highest level of functional safety. The ISO 26262 standard defines all the processes, development efforts, and standards that automotive development organizations must implement and comply with when developing products for safety-critical systems. A key objective of ISO 26262 standard is to minimize the susceptibility to all types of random hardware failures, including permanent failures or transient failures, by:
Industry-accredited inspection companies, such as SGS-TUV Saar, are available to audit products and processes for compliance and certification of ISO 26262.
The ISO 26262 certification process includes multiple steps, policies, and reports and must start from the very beginning of product development. For example, the 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. Created by design and verification engineers, the report is a critical component of an ASIL assessment, not just for evidence of compliance but also for design targets and a rating assessment at the end of the development flow. Designated safety managers, separate from the development organization, who are fully trained to monitor the development process, milestones and product reviews, ensure all the documentation and traceability is completed throughout the SoC development flow as defined by the standard. The FMEDA report also includes a summary of the safety features, their development, and verification. It clearly documents the safety features contained in the products and how these products react to the random faults that are injected into them. The FMEDA report is mandatory and is given to all parties involved in the product review process.
How ISO 26262 Certification is Implemented
A standard SoC or IP product development flow starts with register-transfer level (RTL) design, which is then implemented, verified, and validated in hardware and software in the final prototypes. An ISO 26262 compliant development adds additional steps over the standard design process including at the very start when defining a core architecture and specification. Designers define a safety plan that includes safety features and goals. The product team and safety manager reviews the safety plan and strategy to achieve the designated functional safety for the end application. It is important to conduct a failure analysis by injecting faults to assess the safety level and the system’s reaction to those faults. The FMEDA shows a fault injection analysis for both permanent and transient faults to assess the impact. The analysis and assessments are clearly documented in the FMEDA report as part of the ISO 26262 certification process along with the safety manuals. This entire process is shown in Figure 2.
Figure 2: An example of a standard SoC or IP design with additional ISO 26262 certification steps and requirements
The safety manual in the ISO 26262 certification process defines the safety features in the product, which is critical to the operation of the product. The standard provides some guidelines as to the effectiveness of safety features that can detect possible failures. Safety features for IP product design fall into three categories: protection mechanisms, replication, and various.
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. In addition to meeting ISO 26262 functional safety requirements, integrated ADAS domain controller SoC development teams and the rest of the supply chain, including the design IP provider, must adhere to automotive reliability and quality requirements.
To meet the automotive reliability standard as defined by the automotive industry, automotive SoCs and IP must be designed and tested to meet very low defect densities which is measured by defects parts per million (dppm). The automotive industry has a requirement for less than one dppm, encouraging designers to set a goal of zero defects per million throughout the automotive product lifetime of 15 years. Meeting temperature grade is another reliability requirement. For ADAS, the highest level of operating temperature is Grade 1 which requires up to 125 degrees Celsius ambient or 150 degrees Celsius junction temperatures. Each company within the automotive supply chain has a proprietary temperature mission profile to which they design and test their products. SoC and IP designers who are developing products for the different ADAS applications take the temperature mission profiles into account during the development process. Different requirements such as electromigration, transistor aging, and transistor self-heating must be considered against the temperature mission profile for the different devices.