ALLPCB
We discussed the heavy challenges automakers face when developing their own SoCs and the high risk of failure. So why have automakers been relatively successful in developing in-house autonomous driving controllers? As autonomous driving technology advances, many automakers have made steady progress in domain controller R&D and selection. Why have they been effective at replacing Tier 1 suppliers in frontline development? Automaker development teams for components can be grouped into three categories:
- Category 1: Open, white-box design (in-house): Teams covering hardware and software are established to handle the full scope of autonomous driving domain controller design, chip selection, and software test development, then hand production to professional contract manufacturers.
- Category 2: Parallel in-house and external procurement: Decisions balance internal resources and differentiation. Some platforms develop core technologies internally while also using purchasable hardware platforms and middleware, achieving differentiation through in-house application software.
- Category 3: Supplier dependent: Rely on suppliers for hardware, low-level software, and application stacks, focusing on cost control and obtaining necessary technical and software support through partnerships.
Why choose in-house domain controllers?
New software and system architectures are novel for both Tier 1 suppliers and automakers. Because the value of these elements is not easily measured by common metrics, choosing to develop domain controllers in-house can be a cost-control measure. It reduces reliance on external technology and resources and improves collaboration efficiency and flexibility. Early external partnerships are often expensive and introduce significant uncertainty; if a contracted solution fails, responsibility is unclear.
From a cost perspective, SoCs iterate rapidly. If the wrong path is chosen—Mobileye switching to NVIDIA is a typical example—losing control of domain controller planning, design, and component selection can waste a large amount of time and resources. For a large group with multiple brands and market positions, different models have differing requirements. By opening up hardware and software design at the architecture level, automakers can better meet these differentiated requirements and form an integrated solution that aligns with their product lines, increasing flexibility. Equally important is building teams that understand hardware infrastructure standards and can define an autonomous driving platform based on real functional requirements.
Why is it feasible?
In developing in-house autonomous driving domain controllers, automakers essentially take on the traditional Tier 1 responsibilities: selecting a suitable SoC, memory, and interfaces, and determining required compute and data throughput.
- Data services and interfaces: Configure external gigabit and 100 Mbps network ports to ensure data transfer performance. Design low-level and security mechanisms, including hardware and software diagnostics, interface design, PPS time synchronization, and support for VLANs.
- Mechanical design: Enclosure dimensions and mounting design are required. SoC heat dissipation must be addressed through appropriate cooling strategies, such as air cooling with heatsinks or liquid cooling, to ensure controller stability.
- Design verification: Perform environmental validation including high and low temperature tests, vibration, dust resistance, salt fog and shock tests, and ESD testing to ensure reliability. These tasks can be performed by contract manufacturers.
Developing in-house autonomous driving domain controllers is currently a dominant trend. It is generally feasible and already being implemented by some automakers.
Summary
In-house development of autonomous driving domain controllers is a major trend, offering advantages in product flexibility, cost reduction, and technology control. As some Tier 1 suppliers reduce controller costs, later adopters may find mature supplier products a viable alternative.
