From Distributed Electronic Control Units toward Centralized Compute Platforms Bringing ADAS and IVI Together in Software-Defined Vehicles

Anbieter zum Thema

Caltest Instruments GmbH

Software-defined vehicles are reshaping automotive E/E architectures. As advanced driver assistance systems, automated driving functions and increasingly sophisticated in-vehicle infotainment systems demand more computing power, vehicle architectures are moving away from distributed electronic control units toward centralized compute platforms.

A key step in the evolution from ECU towards centralized compute platforms is cross-domain fusion: consolidating ADAS and IVI workloads onto a single SoC. This approach can reduce system cost, footprint and complexity while improving resource utilization and software scalability. At the same time, it introduces challenges in mixed criticality, functional safety, power density, reliability and cybersecurity.

From Distributed ECUs to Centralized Computing

Modern vehicle architectures are increasingly based on hierarchical compute structures with edge nodes, zonal controllers and centralized high-performance computers. Within these architectures, ADAS and IVI are among the most compute-intensive domains.

ADAS workloads require continuous real-time perception, sensor fusion and decision-making, often supported by neural-network accelerators and vision pipelines. IVI systems, by contrast, demand strong graphics and multimedia performance as well as increasingly AI-driven human-machine interfaces (figure 1).

Traditionally, these requirements have been addressed by separate SoCs. However, a multi-SoC approach duplicates processing resources and hardware components and increases interconnect complexity. Advances in process technology and heterogeneous integration now make it possible to consolidate CPU clusters, GPUs, neural processing units, image signal processors and other accelerators in a single device.

For automotive systems, this higher level of integration can reduce bill of materials, physical footprint and external high-speed interconnects. It also supports the software-defined vehicle model by enabling greater software reuse, more unified development environments and simpler validation across domains.

The Challenge of Mixed Criticality

The main difficulty in combining ADAS and IVI is that the two domains do not have the same safety requirements. ADAS functions may need to meet requirements up to ASIL D, while IVI applications are typically less safety critical. Under ISO 26262, the system must ensure freedom from interference so that a fault in a non-critical domain cannot affect safety-critical functions.

In distributed architectures, physical separation between controllers helps provide this isolation. In fusion architecture, however, it must be created explicitly within the SoC.

Existing solutions often rely on hypervisors, safety islands and other virtualization techniques. These can provide separation, but may also introduce performance overhead, limit flexibility in resource allocation, increase dependency on specialized software layers and complicate higher levels of functional-safety integration.

Fusion architecture therefore increasingly relies on hardware-enforced isolation. Compute, memory and I/O resources can be divided into fine-grained partitions, with access rights controlled at hardware level and supported by independent safety-monitoring mechanisms. This reduces dependence on software and provides more deterministic behavior for safety-critical workloads.

Region-based Hardware Partitioning

The R-Car Gen 5 SoC family from Renesas illustrates this approach through region-based hardware partitioning. The SoC can be divided into multiple isolated regions, each configured to host a specific workload such as ADAS or IVI. In effect, the device can behave like several virtual SoCs within one physical chip. This model combines integration with strong separation between domains while allowing resources to be assigned according to the needs of each workload (figure 2).

At the same time, some resources should remain shareable. GPUs, NPUs and other accelerators are expensive in terms of die area and power, so duplicating them for every domain would reduce the benefits of fusion. Efficient resource virtualization therefore becomes an important part of the design.

Fusion SoCs can combine spatial isolation, in which resources are partitioned, with temporal isolation, in which access to shared resources is scheduled. This allows ADAS and IVI workloads to use common accelerators without interfering with each other.

Managing Shared Resources with QoS

As more functions share a single SoC, predictable access to memory and interconnect bandwidth becomes critical. Quality of Service mechanisms are required to manage bandwidth allocation and prevent one workload from monopolizing shared resources.

By combining QoS with domain-level identification, critical workloads can receive priority access when necessary. This helps maintain deterministic performance even under heavy load, when multiple domains compete for compute, memory or accelerator resources.

Integration also creates opportunities for more efficient data sharing. In a multi-SoC system, exchanging large volumes of sensor or image data may require external high-speed interfaces. In a fusion SoC, data can be transferred through internal interconnects, reducing latency, system cost and wiring.

This can enable new cross-domain applications. Camera data, for example, may be used by an ADAS perception pipeline while also supporting user-facing cockpit functions.

Power Density, Thermal Management and Reliability

Higher integration concentrates more processing activity in one device. As ADAS and IVI workloads grow, fusion SoCs must deliver high compute performance without creating unacceptable power density or thermal-management requirements.

Therefore, performance-per-watt becomes a central design criterion. Process technology, CPU and accelerator architecture, IP selection and power-domain design must be optimized not only for peak performance, but also for their power profiles. Critical IP blocks may also require dedicated power-isolation domains.

The operating profile of the vehicle is changing as well. Connected vehicles may remain active for over-the-air updates while parked, and infotainment systems may continue operating during charging. These longer mission profiles increase accumulated operating time and place greater reliability and durability demands on the compute platform.

R-Car Gen 5 addresses these requirements through advanced process technology, optimized IP integration and architectural measures intended to support high performance-per-watt and extended automotive mission profiles.

Security in a Cross-domain Platform

Consolidating multiple domains also changes the cybersecurity model. If ADAS and IVI functions share one SoC, a security compromise in one domain must not provide a path into another.

Robust isolation mechanisms are therefore important not only for functional safety, but also for security. Access controls, hardware partitioning and protection of shared resources can help prevent lateral movement between domains and protect sensitive data and safety-critical applications.

A Practical Path toward Cross-domain Computing

Cross-domain ADAS and IVI fusion is becoming an important element of future software-defined vehicle-architectures. Consolidating multiple workloads onto one compute platform can reduce hardware duplication, simplify system design and enable more efficient use of compute resources. The challenge is to achieve these benefits without sacrificing functional safety, determinism, power efficiency, reliability or security. Hardware-based isolation, controlled resource sharing, QoS mechanisms and efficient internal data exchange are central to making fusion practical. (se)

* Roopesh Panthalath, Senior Staff SoC Product Marketing Engineer, HPC, Renesas Electronics

(ID:51011647)