Enabling Integrated ADAS Domain Controllers With Automotive IP

Traditionally, the electronic control units (ECUs) for individual Advanced Driver Assistance System (ADAS) applications have been placed throughout the car. The latest automotive architecture will integrate ECUs for 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, and ultrasonic to the integrated domain controller for processing by a high performance ADAS system-on-chip (SoC). The increased functionality of an 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.

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, it is important to use automotive-certified IP in advanced foundry processes, since designers are moving to more stringent process technologies, such as FinFETs.

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:

• Ethernet manages the high data volume including time-sensitive data, and reduces point-to-point wiring
• LPDDR4/4x operates at data rates of up to 3200 megabits per second and beyond, which speeds up the DRAM operations in automotive-grade SoCs
• MIPI standards like MIPI Camera Serial Interface and Display Serial Interface provide high-performance connectivity in imaging and display applications
• PCI Express has high-reliability processor-to-processor connectivity for 4G radios or the future 5G radios and external SSDs
• 5G and IEEE standards, like 802.11p, help provide real-time updates of maps or images to and from the Cloud, and vehicle-to-vehicle or vehicle-to-infrastructure communications
• Security protocols in hardware and software for data protection to and from connectivity via USB, WiFi or Bluetooth
• Sensor and control subsystems offloads the host processor and fuses sensor data to manage the different type of sensor data provided by the sensors
• 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

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 are 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 the ISO 26262 standard is to minimize the susceptibility to all types of random hardware failures, including permanent failures or transient failures, by:

• Defining the functional safety requirements when developing products
• Applying rigor to the development process
• Defining a safety culture
• Implementing safety features to minimize the impact of hardware failures
• Assessing and analyzing the impact of the safety features to ensure mitigation of hardware failures

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 flow 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.

• Protection mechanisms, such as protecting the interface between the IP in the SoC architecture with 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 a 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. 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.

Summary
The trend is shifting from distributed ADAS electronic controller units (ECUs) to a more integrated ADAS domain controllers with centralized ECUs. Due to a high volume of data, the new integrated domain controllers require higher computing performance, lower power consumption and small densities. The adoption of 64-bit processors to handle the high volume of data requires the latest semiconductor features, semiconductor process technologies, and other technologies like IP.

Since integrated ADAS SoCs are mainly used for safety-critical applications, designers must comply with the ISO 26262 functional safety standard. This also applies to the automotive IP that is integrated into the ADAS SoC. Designers can accelerate their SoC-level certification with automotive-certified IP that has gone through the required certification process and is deemed certified by an accredited third-party company, like SGS-TUV Saar.

Synopsys offers a portfolio of automotive-certified IP that are ASIL Ready ISO 26262 certified, designed, tested for grade 1 and 2 temperatures, and fully adhere to the automotive quality management process. For information, view the DesignWare IP for automotive SoC web page.