How to Build a Software Defined Vehicle (SDV) in 3 Steps

Step 1: Select the Right Communication Protocols

Begin by defining your data flow. The choice of protocols is not just technical — it’s a strategic cost and supply decision that locks in your architecture for years.

Classic automotive protocols (CAN, LIN, FlexRay):

• Optimized for low BOM cost – Ideal for high-volume, price-sensitive components
• Early binding – Hardware and software tightly coupled at design time
• Slow & expensive change management – ECU firmware updates require physical access or complex gateways
• Volume drives ROI – The higher the production volume, the more cost-effective they become

Reality check: Even Tesla uses LIN for commodity functions like window motors, seat adjusters, and HVAC flaps. Why? Because no project — not even the highest-volume ones — can afford to reinvent every sensor, actuator, and ECU. The ecosystem of certified, automotive-grade, low-cost parts is built around these legacy protocols.

Modern internet protocols (Ethernet, MQTT, HTTP/HTTPS):

• High bandwidth & flexibility – Essential for ADAS, infotainment, OTA updates
• Late binding – Software can evolve independently of hardware
• Fast, low-cost updates – Over-the-air, cloud-native deployment
• Future-proof – Enables new revenue streams (features on demand)

Our conditional recommendation:

• Entry & mid-range vehicles – Use classic protocols at the edge (sensors, actuators) and Ethernet backbone for central compute. Keep LIN/CAN for cost-critical nodes.
• Premium & fleet vehicles – Push modern protocols to the edge where possible (e.g., IP-based cameras, radar), but accept LIN/CAN for commodity availability.
• All segments – Never eliminate classic protocols entirely. They are the only way to source reliable, low-cost, globally available components at scale.

Next: Map your chosen protocols to physical zones and HPCs (Step 2). Use Ethernet as the high-speed backbone between HPCs, and run CAN/LIN as spurs into cost-sensitive zones. This hybrid approach delivers SDV flexibility without sacrificing BOM or supply chain reality.

View Full Protocol Comparison

Step 2: Choose High-Performance Compute Hardware

Central compute is the brain of your SDV. But how many HPCs do you need, and for what? This decision depends on your vehicle segment and feature ambition.

Define your HPC strategy by use case and market tier:

• Digital Cockpit – Infotainment, UI, connectivity
• ADAS / Autonomy – Sensor fusion, AI, real-time safety
• Body & Comfort – Zone control (windows, HVAC, lighting)
• Telematics / OTA – Secure gateway, cloud sync

Our conditional recommendation:

• Entry-level vehicles – 1 HPC for all domains with degraded performance (e.g., basic infotainment, L2 ADAS). Use a mid-tier chip like Qualcomm Snapdragon Ride or NVIDIA Orin NX.
• Mid-range vehicles – 2 HPCs: one for Cockpit + Telematics, one for ADAS.
• High-end / Premium vehicles – 3 dedicated HPCs:
  • Cockpit HPC for advanced UI and connectivity
  • ADAS HPC with high TOPS and redundancy
  • Body Zone HPC for distributed control

Top chip options include NVIDIA Orin (ADAS), Qualcomm Snapdragon Ride (ADAS/cockpit), and Intel Mobileye (vision). Evaluate based on TOPS, power, and regional availability.

Geopolitical Risks – The Dual-Use Dilemma: All automotive HPCs are classified as dual-use goods, with military and civilian applications, making them prime targets in global trade tensions. These chips are predominantly supplied by U.S.-based companies (NVIDIA, Qualcomm, Intel), with critical manufacturing in Taiwan and South Korea, creating a narrow chokepoint vulnerable to disruption.

The U.S. and China — the two dominant powers in this space — wield HPC supply as a strategic asset in trade negotiations, not just against each other but also toward third parties like the EU and emerging markets. U.S. export controls, expanded in 2025 under the CHIPS Act and BIS rules, restrict advanced chips to China, forcing downgraded versions (e.g., NVIDIA's H20) and causing billions in lost revenue for suppliers. In retaliation, China has imposed rare earth export bans and antitrust probes on Qualcomm, escalating the cycle.

Impact on your SDV project: Expect supply shortages, forced chip substitutions, and compliance costs. Diversify suppliers early, stockpile compliant variants, and model scenarios for U.S.-China tariffs or EU alignment with U.S. controls. By 2027, China's "Made in China 2025" push may yield domestic alternatives, but quality and scalability remain unproven.

Next: Build your zonal E/E architecture around these HPCs. Group ECUs into physical zones (front, rear, left, right) and connect them via the high-bandwidth Ethernet backbone defined in Step 1. This enables over-the-air updates, reduces wiring, and supports SDV scalability.

View Full HPC Comparison

Step 3: Pick the Right Operating System

Your OS is the central nervous system of the SDV. It must unify modern and legacy protocols, bridge HPCs and commodity ECUs, and enable seamless OTA updates — all while maintaining real-time safety and cost control.

Core challenge: The OS cannot run everywhere. You’ll have a central SDV OS domain (HPCs, high-bandwidth links) and a commodity edge domain (CAN/LIN or future Ethernet-based ECUs). The OS must:

• Orchestrate the unified architecture across HPCs via Ethernet/MQTT
• Expose APIs for software-defined features (ADAS, infotainment)
• Integrate edge nodes via gateways, protocol translation, and workarounds
• Push updates to both domains — OTA to HPCs, service-only to ECUs

Define your OS scope by domain and strategy:

• Central SDV Domain – HPCs running full OS stack (real-time kernel, middleware, apps)
• Edge Commodity Domain – ECUs with minimal firmware (CAN/LIN today, 10BASE-T1S + RCP in future)
• Gateway Layer – Bridges protocols, translates data, handles fallbacks

Our conditional recommendation:

• Cost-driven & high-volume vehicles –
  • Central OS: Android Automotive or AGL on 1–2 HPCs
  • Edge: Retain CAN/LIN for commodity ECUs (cheapest, most available)
  • Gateways: Dedicated CAN-Ethernet bridges with fallback logic
  • Workarounds: OS emulates missing features via virtual nodes
• Future-proof & premium vehicles –
  • Central OS: QNX or in-house RTOS on 3 HPCs (safety-critical)
  • Edge: Migrate to 10BASE-T1S + RCP for Ethernet-only ECUs (hardware-only, no firmware)
  • Gateways: Integrated into zone controllers with redundancy
  • Workarounds: OS includes full protocol stacks and remote command abstraction
• All segments –
  • Legacy elimination is a budget & timeline decision — not a technical one
  • Design the OS as the integration layer — flexible enough for CAN today, RCP tomorrow
  • Plan for hybrid updates: OTA for HPCs, service bay or RCP for edge

Top options include Android Automotive (open, app ecosystem), QNX (safety-certified), and Automotive Grade Linux (AGL) (customizable). In-house builds offer control but explode costs.

Next: Deploy your OS across the zonal E/E architecture defined in Step 2. Run the full stack on HPCs, use lightweight agents or RCP on gateways, and maintain edge compatibility via protocol abstraction. This future-ready model supports full SDV evolution — from hybrid to Ethernet-native — without supply chain disruption.

View Full OS Comparison