Getting the right balance for ADAS architectures

Find the Latest SoC Solutions
for... Automotive... IoT... Security... Audio... Video

Three different classes of ADAS system processing are needed—edge, zonal and central-with three different profiles.

www.ednasia.com, Sept. 20, 2022 – 

Recent analyst reports reveal expectations that processing for ADAS system and infotainment systems will expand significantly over the next five years. They see advances on multiple fronts, not only in AI but also in general compute, and shifts in how OEMs want to structure electronic content, from edge-based to zonal to central management. A key consideration for any systems builder hoping to benefit from this growth is how to address these diverse auto architecture needs through unified product families.

Yole Développement reports up to 3X growth over the next five years through direct innovation in active safety capabilities and in the digital cockpit. In addition, advances in adjacent technologies and regulation are driving rapid developments in driver and occupant monitoring systems. One question is where this growth is happening – around sensors at the edge, or around central processing in zones, or central processing in the car. Innovation is still prominent at the edge where new entrants can introduce competitive solutions versus slower-moving centralized systems. Conversely, cost, safety and central software control push for more centralization.

Multiple edge processing nodes still need overall central control for safety

Before ADAS systems appeared, the rapid growth of electronics in cars had driven automotive OEMs to rethink how they wanted to distribute those electronics. Edge sensing has now accelerated that demand. The problem in part was the cost and management of data communication, amplified further by smart sensing – heavy wiring consumes a lot of power to transport data from the edge to consolidated processing.

However, sensor fusion must fuse data from multiple sensor perspectives and types which often doesn't fit well at the edge or centrally. We need edge AI for fast recognition and data reduction, but communication and fusion now push some AI to zonal processors. Meanwhile, as we move to smarter cars with some level of autonomy, those processors must consolidate distributed inputs under a driving policy manager. This kind of AI cannot be distributed. It must be handled in a central controller, for safety and for a consolidated perspective.

Clearly, three different classes of ADAS system processing are needed – edge, zonal and central – with three different profiles. Edge AI must continue to be fast and low cost (since there will be many of these around the car), using a single processor delivering up to 5 TOPS. Zonal processors, consolidating input from multiple edge devices must offer a higher level of parallelism and performance, requiring a higher premium multicore implementation running at up to 20 TOPS. Finally, the central driving policy engine must run inferencing against scenario-trained behaviors – and may also need to allow for some level of on-the-fly training. This engine will very likely be a high premium multi-chiplet device, each chiplet a multi-core, supporting up to 200 TOPS or more.

So how should an SoC developer architect a scalable ADAS system?

It is difficult to know yet how revenue opportunities will segment between many low-cost edge devices, with fewer but higher premium zonal devices and perhaps only one high premium central device per car. The smart money seems to be on preparing for opportunities in each segment. Given that, how should SoC product developers architect their solutions?

Training, optimization and infrastructure software represent some of the biggest investments in deploying an ADAS system. Supporting these consistently across a product family then becomes essential to economic success. An edge solution might be tuned for a lighter-weight objective than a zonal or central solution, but it should allow for a dialed-down version of the same core capabilities. This enables a common trained network to be compiled, with different compiler options, and inferred into edge, zonal and central solutions.

Correspondingly, the AI hardware platform should allow for scale-up/down. It should have the same architecture, deployable as a single neural engine or multiple parallel engines, with uniform data traffic control and memory hierarchy optimization, allowing even scale-out to multi-chiplet implementations where needed.

click here to read more...

 Back