Managing the evolving architecture of integrated ADAS controllers
Designers need to understand how the architecture of electronic control units used to implement ADAS in vehicles is changing.
The architecture of the electronic control units (ECUs) used to implement advanced driver assistance systems (ADAS) in vehicles is changing.
ADAS applications use many types of sensors, including cameras, medium and long-range radar, ultrasonic, and LIDAR. Data from these sensors is used to enable ADAS functions such as parking assistance, automatic emergency breaking, pedestrian detection, surround view, and even drowsiness and gaze detection.
Current ADAS architectures distribute sensors and their related processors throughout the vehicle. For example, the forward collision-avoidance ECU module is located in the windshield, but the blind spot ultrasonic sensors and related ADAS processor may be located in the side mirrors or other distributed locations.
Figure 1 Domain controllers for ADAS (Source: Ian Riches, Strategy Analytics)
This is changing, as automotive system architects integrate multiple applications into ADAS ECUs that serve multiple functions. The approach has many benefits and implications for the implementation of these ECUs.
Figure 2 Integrated domain controllers for ADAS (Source: Ian Riches, Strategy Analytics)
For example, Delphi offers a multi-domain controller that performs multiple ADAS functions using front radar, cameras, LIDAR, rear and side radars.
Audi has introduced its zFAS centralized ADAS module, which integrates an Infineon Aurix integrated circuit, an FPGA from Altera for sensor fusion, an NVIDIA GPU to do the image processing for parking, and a MobilEye image processor to handle pedestrian detection and automatic emergency braking.
The shift to centralized ADAS architectures demands greater device integration and higher performance. For example, at CES this January, NVIDIA announced its Xavier processor, built on a 12-nm finFET process, which is meant to be used in pairs to enable Level 5 vehicle autonomy.
A generic centralised ADAS domain controller architecture
Here’s a block diagram of a generic ADAS processor.
Figure 3 A generic centralised ADAS domain controller architecture (Source: Synopsys)
It has a 32bit or 64bit host processor, a separate accelerator to handle vision processing, and many interfaces, including Ethernet audio/video bridging (AVB) or Ethernet time sensitive networking (TSN). External memory is commonly implemented using LPDDR4 or LPDDR4x DRAM running at 3200Mbit/s or higher, with upcoming controller architectures targeting denser memories such emerging LPDDR5 spec.
High-performance PCI Express 3.0 or 4.0 is becoming popular in these SoCs to support processor-to-processor communication.
MIPI connects imaging and other forms of sensors. Centralized ADAS controllers are also implementing custom datapaths to handle the heavy computational requirements of radar signal processing and sensor fusion.
Security is important to ADAS controllers, and is usually implemented in both hardware and software. Centralized controllers are also being used to manage sensor fusion, with the computationally intensive work of integrating many forms of sensor data being handled by sensor subsystems.
Combining multiple ADAS applications using a single SoC drives greater integration, and hence a migration to more advanced manufacturing process nodes, as we see from the NVIDIA announcement.
Safety-critical applications, such as ADAS, require compliance to the ISO 26262 functional safety standard, which adds to the complexity of the design and implementation process.
ISO 26262 functional safety
The ISO 26262 functional safety standard’s purpose is to minimise the impact of transient or permanent random hardware failures.
The standard defines the processes with which development organizations have to comply when developing products that go into safety-critical systems. Implementing ISO 26262 requires teams to create and apply a safety culture. This might include defining new policies and development processes, and hiring safety managers with specific responsibilities for safety processes and possibly advanced training in automotive functional safety.
ISO 26262 also demands a lot of documentation, to show how the team has planned the development and verification of safety features. This documentation includes a safety manual that is provided to all stakeholders. It describes both the safety features of the products, and how those products will react to certain types of faults. The documentation also includes a failure modes, effects and diagnosis analysis (FMEDA), which outlines how the product will react to random faults.
Part of the ISO 26262 compliance process is to define the functional safety requirements of the product under various types of failures, and then implement safety features to minimize the impact of those failures. In turn, the effectiveness of those safety features in mitigating such failures must be assessed.
Accredited inspection companies have emerged to audit products and development flows and certify compliance with the ISO 26262 standard. One of these inspection companies is SGS-TUV Saar.
ISO 26262’s impact on development teams
Implementing ISO 26262 effectively means adding a parallel safety development flow to the standard product design flow.
Figure 4 Integrating ISO26262 compliance into the development flow (Source: Synopsys)
The left hand side of Figure 4 shows how ISO 26262 compliance adds steps to the development flow, including the definition of a safety plan, safety requirements, and safety goals. The next steps include a failure-in-time analysis, and finally the definition and implementation of hardware safety features. During the verification process, ISO 26262 compliance demands fault injection and coverage analysis, to simulate the impact of injected faults and so to assess how a system reacts to such faults and thus what safety level it offers. The process also demands the creation of an FMEDA report, and a safety manual, and, in Synopsys’ case, certification with an inspection and auditing company such as SGS-TUV Saar.
Building ISO 26262 hardware
Developers can use a variety of techniques to make their designs safer. ISO 26262 outlines some of these, including hardware redundancy, error checking and correction (ECC) codes on memories, self test, and timeout monitors. Synopsys has done its own analysis of the effectiveness of various hardware safety features for automotive applications that require functional safety for safety-critical systems, and recommends strategies such as using byte parity on datapaths, ECC on memory reads and writes, duplicating and then comparing the outputs of key modules, and creating dedicated interrupts for signalling errors.
Synopsys is using ISO 26262 strategies to develop some of its key IP solutions, such Ethernet, LPDDR, USB, PCI Express, MIPI, processors, embedded memories, test and NVM.
For example, the ISO 26262 features of Synopsys’ LPDDR controller are meant to ensure that data can be read from, and written to memory reliably. This has meant adding features such as inline ECC and datapath protection; critical registers protection on the command and address paths; and similar protections on the configuration status register.
Synopsys’ Ethernet Quality of Service (QoS) controller IP, which supports the AVB and TSN standards, has been given ECC support on all its closely coupled RAMs; protection on external interfaces, configuration registers, and internal datapath; and timeout monitoring on its finite state machines. Adding the protections described above to the Ethernet QoS controller is vital to ensuring that the Ethernet gateways and ports in ADAS processors have the safety features to enable ISO 26262 compliance.
Synopsys’ ARC EM processor, for example, can form the heart of a ‘safety island’, in which two EM cores work side by side on a system bus, with a safety monitor block comparing their output and signalling any discrepancy between the two. Such a safety island is likely to have ECC and parity on its memory interfaces and buffers, programmable watchdog timers, and optional memory protection units.
This block, in turn, can be used in an ISO 26262 compliant subsystem. See an example in Figure 5.
Figure 5 Example of adding ISO 26262 features to a memory controller (Source: Synopsys)
Figure 5: A subsystem composed of ISO26262 compliant building blocks ((Source: Synopsys)
The subsystem includes the ‘safety island’ processor core previously described, ECC and parity support for memories, DSP and processor IP blocks, interfaces and memory. The safety island can manage the interaction of all these blocks through a dedicated safety bus.
Synopsys’ Star Memory System and Star Hierarchical System can be used to implement the memory, test and repair, and IP integration so that the safety island can reach, monitor and protect all the functions on the ADAS processor.
Conclusion
It’s important to meet the requirements of the ISO 26262 standard when building safety critical systems such as ADAS controllers. However, as the architecture of vehicle systems evolves to use more integrated ECUs, ISO 26262 compliance becomes more complex. Using IP blocks with features and rigorous processes necessary to meet the requirements of the standard and are ISO 26262 compliant should make it simpler to create these complex integrated ADAS controllers. .
Find out more
Find out more about Synopsys’ range of automotive IP here.
Author
Ron DiGiuseppe is senior strategic marketing manager at Synopsys responsible for automotive segment marketing for DesignWare IP solutions for ADAS, functional safety, connected vehicle and infotainment, and MCU applications.
DiGiuseppe brings more than 18 years of semiconductor experience to Synopsys. Prior to joining Synopsys, he held a range of management positions at Xilinx for automotive connectivity IP products, as well as engineering development and management roles for companies including Oki Semiconductor, NEC and Raytheon.