BYD’s ascent from a battery manufacturer founded in 1995 to the world’s top new-energy vehicle producer by volume is not, at its core, a story about price competition or government subsidies. It is a story about architectural discipline — the kind that takes thirty years of sequential engineering capability-building across batteries, power semiconductors, electric drivetrains, and software-defined platforms, and converts it into a compounding cost and technology advantage that most incumbents find structurally impossible to replicate.

In 2025, BYD delivered 4.5 million vehicles while operating one of the most sophisticated vertical integration systems in automotive history. Its FinDreams subsidiary ecosystem manufactures roughly 75% of key vehicle components in-house — Blade Battery cells, silicon carbide devices, IGBT modules, wiring harnesses, domain controllers, and increasingly its own AI silicon. This is not supply chain management. It is the structural foundation for a cost floor that allows BYD to offer advanced driver assistance systems as standard equipment on vehicles priced below $10,000.

This blog dissects that advantage across its three technical layers: the hardware E/E architecture evolution culminating in Xuanji 4.0; the three-OS software strategy (BYD OS + Android + QNX) bound by a Type-1 hypervisor; and the AI silicon pyramid powering the God’s Eye ADAS system from Horizon J5 silicon all the way up to BYD’s own 4nm Xuanji A3 chip. I benchmark this against Tesla and Xiaomi, trace the data flywheel generating 150 million km of ADAS training data daily, and close with concrete strategic implications for architects and executives.

Chapter 01:

E/E Architecture — Three Generations of Transformation

The Evolutionary Trajectory

BYD’s electrical and electronic architecture has moved through three architecturally distinct generations. The transitions were not incremental refreshes — each represented a fundamental reorganisation of how software authority is distributed across the vehicle. Understanding the sequence is essential because it explains both where BYD is now and the architectural logic driving its next moves.

Generation 1 (pre-2020): Distributed ECU Era. Forty or more single-purpose electronic control units communicated over CAN and LIN buses. Each ECU performed one function — a pattern indistinguishable from any legacy ICE OEM of the era. Software was locked to hardware. OTA was essentially absent. BYD’s differentiation lived entirely in battery chemistry and powertrain engineering, not electronics.

Generation 2 (2021–2023): Domain Centralisation via e-Platform 3.0. BYD’s first genuine architectural statement. Four domain controllers (Intelligent Power, Vehicle Control, Cockpit, Driving) replaced the sprawl of distributed ECUs. The landmark “8-in-1” electric drive integration (later “12-in-1”) collapsed motor, reducer, on-board charger, BMS, DC-DC converter, VCU, PDU, and charging port into a single assembly. BYD OS was introduced as a hardware-software decoupling layer, enabling full-vehicle OTA for the first time. The company reported a 50% improvement in system response efficiency. This is the platform that underpins the commercial volume driving everything else in this report.

Generation 3 (2024–present): Xuanji Architecture — Central Compute + Zonal Control. Announced in January 2024, Xuanji formalises the “One Brain, Two Terminals, Three Networks, Four Chains” framework. A central computing platform aggregates intelligence from all domains. Zonal gateways replace local domain controllers. Dual Gigabit Ethernet forms the high-speed backbone. In February 2025, Xuanji 2.0 fused the previously separate cockpit, driving, and propulsion domains into a single integrated system — the most direct signal yet that BYD is converging on full centralisation.

The Xuanji Framework: Decoding “One Brain, Two Terminals, Three Networks, Four Chains”

This formulation is precise architectural language. Each element has a specific meaning and engineering implication.

One Brain is the central computing platform — the vehicle’s unified intelligence hub. It hosts the Xuanji A3 SoC (4nm, 700+ TOPS single chip) or, in current production variants, NVIDIA Orin X chips. The brain supports multi-chip configurations through chip decoupling, allowing compute to scale from single-chip to tri-chip arrangements exceeding 2,100 TOPS without architectural redesign. This chip decoupling is strategically significant: it means BYD can upgrade compute performance via silicon swap without changing the vehicle’s software architecture.

Two Terminals refer to the cloud AI (Xuanji Cloud, running DeepSeek R1 and the Xuanji Foundation Model on 150 million km of daily fleet data) and the vehicle-side AI (the in-car inference engine executing real-time perception and planning at microsecond latency). These are not redundant systems — they are coordinated systems with distinct roles. The cloud cycle runs continuously for model improvement; the vehicle cycle executes at deterministic precision for safety-critical functions. BYD calls this the “dual-cycle” architecture — the industry’s first claimed implementation of a coordinated dual-cycle multi-modal AI model across cloud and vehicle terminals.

Three Networks cover the in-vehicle high-speed Ethernet backbone (dual Gigabit Ethernet ring for ADAS sensor data), 5G cellular connectivity (OTA, telematics, V2X), and satellite communication (off-grid connectivity and OTA redundancy). The satellite layer is notable: it positions BYD vehicles for connectivity independence in coverage-sparse regions and gives the OTA pipeline a backup channel for critical safety updates — first demonstrated on the Yangwang U8 off-road variant.

Four Chains — sensing, control, data, and mechanical — describe the functional domains the central brain orchestrates. Sensing aggregates camera, LiDAR, radar, and ultrasonic inputs. Control issues deterministic commands to braking, steering, powertrain, and chassis actuators. Data manages the pipeline from edge processing to cloud training. Mechanical refers to the physical execution layer: the 12-in-1 electric drive, DiSus chassis system, and 800V power architecture.

In-Vehicle Interconnect: From CAN to 10G Ethernet

The network upgrade from CAN to Ethernet is not cosmetic. A CAN bus operates at 1 Mbps maximum. A camera generating 1080p video at 30fps produces roughly 50 Mbps of raw data. A LiDAR adds another 20–100 Mbps. Run twelve cameras and three LiDARs simultaneously, and you need a backbone that can handle 800 Mbps to 2 Gbps continuously — orders of magnitude beyond CAN’s capacity. BYD’s dual Gigabit Ethernet ring solves this problem, giving the central brain the bandwidth headroom for sensor fusion at full resolution.

FinDreams: The Vertical Integration Engine

No analysis of BYD’s architecture is complete without FinDreams — the internal subsidiary group that functions as BYD’s captive Tier-1 supplier. FinDreams is not a procurement strategy. It is an engineering organisation that designs, manufactures, and iterates on components that traditional OEMs source from external partners at commercial markups — and those markups are exactly the cost gap BYD converts into competitive pricing.

FinDreams Battery is the world’s second-largest EV battery manufacturer and produces the Blade Battery using LFP chemistry in a cell-to-pack format that eliminates module-level overhead, reducing weight and lowering production cost by an estimated 15–20% versus equivalent CATL NCM packs. BYD Semiconductor manufactures IGBT modules at generation 4.0/5.0, SiC power devices, and automotive-grade MCUs. When BYD develops its own ADAS chip — the Xuanji A3 at TSMC’s 4nm node — the decision is not a strategic pivot. It is the next sequential step on a decades-long in-house silicon trajectory that began with phone battery protection circuits in the 1990s.

Chapter 02:

Software Architecture — The Three-OS Hybrid Strategy

Why Three Operating Systems?

The question of OS strategy is, in SDV architecture, a defining one. Tesla decided to run a unified Linux-based OS across all vehicle domains — a clean, opinionated choice that enables tight software control but carries significant safety engineering overhead. Xiaomi’s HyperOS takes Android as its foundation and extends it. BYD made a third choice: a deliberate three-OS architecture where each domain runs the environment best suited to its criticality and performance requirements, bound together by a Type-1 hypervisor.

Understanding why requires understanding what BYD is optimising for. BYD is not optimising for software elegance. It is optimising for the ability to deploy ISO 26262-compliant safety functions and rich Android infotainment on shared silicon, at the lowest possible BOM cost, across millions of vehicles at varying price points. The three-OS architecture, for all its apparent complexity, is the pragmatic answer to that constraint set.

BYD OS (Linux kernel with RT extensions) is best understood as a platform abstraction layer rather than a standalone operating system. Introduced with e-Platform 3.0 in 2021, it decouples application software from specific hardware configurations. A feature developed for the Seal can be OTA-deployed to the Seagull without engineering teams accounting for different underlying hardware — BYD OS abstracts those differences. It is also the mechanism enabling ~200 OTA packages per year: without a platform layer managing firmware dependencies, version compatibility, and rollback orchestration across a heterogeneous fleet, that cadence would be logistically impossible.

Android Automotive OS (AAOS) runs the cockpit domain as DiLink — currently at version 5.0. This gives BYD access to the Google Play developer ecosystem, Google Maps, Google Assistant, and a vast pool of developers who need no automotive-specific training to build for the platform. DiLink carries no functional safety responsibility — it is fully isolated from safety-critical domains. It also serves as the primary surface for AI features: the in-vehicle DeepSeek R1 reasoning interface, voice control backed by cloud LLMs, and AI-enhanced navigation all surface through this Android layer.

QNX OS for Safety handles powertrain control, braking, steering, and ADAS execution. QNX’s microkernel architecture enforces hard memory partitioning between software components — the property that makes it suitable for ASIL-D applications where a missed deadline is a safety violation. QNX also provides BYD’s Type-1 hypervisor, which runs directly on host silicon below all guest operating systems, creating isolated virtual machines for Android (cockpit) and Linux (ADAS compute, BYD OS) while maintaining QNX’s own ASIL-D partition for safety-critical functions.

Hypervisor and Domain Virtualisation

BYD’s current production vehicles consolidate multiple operating environments onto a single SoC — a well-established technique in the automotive industry, enabled by a Type-1 (bare-metal) hypervisor. The approach is not novel in concept; hypervisor-based domain isolation has been standard practice in safety-mixed automotive designs since the early 2010s. What is distinctive about BYD’s implementation is the specific combination of guests it manages and the safety boundaries it enforces.

On cockpit-domain SoCs (Qualcomm Snapdragon), the QNX Hypervisor for Safety runs directly on the silicon and hosts two isolated guest environments: Android (DiLink) for the infotainment partition and QNX Neutrino RTOS for the instrument cluster and safety telltales. The hypervisor enforces separation at the hardware level — CPU core affinity, MMU memory isolation, device ownership, I/O virtualisation, and interrupt routing are all managed by the hypervisor, ensuring that a crash or memory leak in the Android guest cannot compromise the QNX safety partition. This is the mechanism that allows BYD to meet ISO 26262 ASIL-D requirements for instrument cluster functions while running a resource-hungry Android stack on the same die.

On ADAS-domain hardware (NVIDIA Orin for DiPilot 300/600), a similar partitioning pattern applies: safety-critical perception and chassis coordination run in a hardened partition, while data logging, model inference experimentation, and connectivity services occupy separate, lower-criticality partitions. The key safety guarantee is that no guest can directly address another guest's memory or preempt a safety-critical interrupt — properties verified through the QNX Hypervisor's ASIL-D tool qualification.

AUTOSAR, SOA, and Standards Posture

BYD’s relationship with industry standards is pragmatic and selective. The company has not publicly committed to comprehensive AUTOSAR Adaptive adoption, and public evidence for specific standards membership (e.g., SOAFEE) is limited and contested across sources. What can be stated with reasonable confidence is the following.

AUTOSAR Classic is almost certainly present in BYD’s powertrain and chassis MCUs. These controllers — handling braking, steering, and motor actuation — use RTOS-style stacks with signal-based communication over CAN-FD, which is precisely the use case AUTOSAR Classic was designed for. BYD’s FinDreams-supplied domain controllers follow patterns common to Chinese Tier-1 suppliers, who routinely deploy Classic Platform BSW on Infineon AURIX or equivalent safety MCUs.

Above the MCU layer, BYD’s middleware is primarily proprietary. BYD OS — introduced with e-Platform 3.0 in 2021 — provides a hardware-abstraction layer across the four domain controllers, exposing standardised internal APIs for the “Four Chains” (sensing, control, data, mechanical). Communication between high-performance domains uses SOME/IP over Ethernet (potentially) as a service transport protocol, consistent with SOA principles but implemented within BYD’s own service registry rather than a standards body framework.

AUTOSAR Adaptive adoption at the HPC level is plausible but not publicly confirmed. Sources diverge: some analyses infer Adaptive-compatible middleware from the presence of QNX and POSIX environments on Orin-class hardware (where suppliers like Elektrobit routinely supply Adaptive stacks); other sources characterise BYD as preferring in-house service layers. The most defensible position is that BYD applies Adaptive-adjacent patterns — POSIX services, dynamic deployment, SOME/IP — without formally branding or certifying against the Adaptive Platform specification.

SOAFEE participation has been cited by some sources and contradicted by others. No official BYD announcement of SOAFEE membership or pilot programme has been publicly verified.

In summary, there is no clear confirmation about BYD directly using AUTOSAR CP or AP. Also, not been actively part of SOFEE or Eclipse SDV.

Central Compute vs. Edge Controller Split

A question that preoccupies most SDV architects: what percentage of a vehicle’s software should run on central compute versus distributed safety-grade MCUs? BYD’s current split — estimated at ~55% central, ~45% edge in 2025 vehicles — reflects the transitional architecture. By 2028, as the vECU migration programme progresses, BYD projects the split reaching approximately 80% central. Safety-critical real-time functions will never fully migrate from dedicated MCUs.

Chapter 03:

ADAS & AI — God’s Eye, Xuanji, and the 150M km Flywheel

The Strategic Context

BYD’s intelligent driving programme entered 2024 in a position most analysts had underestimated. The company had been publicly criticised for years — including by its own Chairman Wang Chuanfu, who called its software capability “far behind” competitors as recently as 2023. What those critiques missed was the scale of the internal restructuring underway: the merger of the Tianxuan and Tianlang ADAS departments in late 2024, the hiring of Zhou Peng (formerly Baidu) to lead end-to-end large model development in June 2024, the deployment of RMB 1 billion per month in intelligent driving engineering payroll, and the single February 2025 announcement making God’s Eye standard on 21 models.

Understanding BYD’s ADAS strategy requires separating it into three layers: silicon (which chips provide compute, at what cost), algorithm (what software runs on those chips, and who wrote it), and data (how training data is collected, processed, and fed back to improve the system). Each layer has its own partnerships and competitive dynamics.

The God’s Eye Silicon Pyramid

BYD’s ADAS compute is structured as a three-tier pyramid mapping to vehicle price segments. This is not a product lineup decision — it is an architectural expression of cost-optimisation philosophy. Rather than specifying a single high-performance platform for all vehicles (Tesla’s approach), BYD right-sizes silicon to use case and price point while maintaining a common software framework across tiers.

The Xuanji A3 chip deserves special attention. Fabricated at TSMC’s 4nm node, the A3 delivers 700+ TOPS from a single chip — roughly 2.7× the TOPS of a single NVIDIA Orin X. In a tri-chip configuration, the A3 exceeds 2,100 TOPS. The key economic implication: BYD’s cost for tri-chip A3 compute is estimated at approximately one-third the cost of an equivalent NVIDIA Thor solution. This is the mechanism that makes “flagship ADAS economics on mainstream vehicles” architecturally achievable, not just marketable.

^{Caption: BYD Xuanji A3 — 4nm process node (TSMC), 700+ TOPS single chip, 16-core CPU, 3-core NPU optimised for Transformer architectures, ASIL-D certified. Tri-chip configuration exceeds 2,100 TOPS at approximately one-third the cost of the NVIDIA Thor equivalent.}

The Algorithm Layer: In-House, Partnered, and the DiPai JV

BYD’s ADAS algorithm development is housed within the New Automotive Technology Research Institute — one of the largest ADAS engineering concentrations at any single OEM globally, with over 5,000 engineers, including a dedicated core algorithm group.

The algorithm stack is a deliberate hybrid of in-house development and strategic partnerships. BYD’s engineers build the Bird’s Eye View (BEV) perception algorithm — a multi-camera fusion approach constructing a top-down environmental model without requiring LiDAR — and retain the resulting IP. For urban NOA, BYD has partnered with Momenta through the DiPai JV, co-developing the TianShen A and B algorithm tiers. Horizon Robotics provides its SuperDrive full-scenario urban NOA solution for the DiPilot 100 God’s Eye C tier, targeting mass production in September 2025. On the Fangchengbao Bao 5, BYD offers customers a choice between TianShen C (in-house) and Huawei’s Qiankun ADS 3.0 — a pragmatic acknowledgement that best-in-class external capability can serve as a differentiator even without in-house ownership.

The most significant 2025 development: DeepSeek R1 integration, announced February 2025. DeepSeek R1 operates at two levels simultaneously — cloud-level (accelerating the ADAS training pipeline) and vehicle-level (powering cockpit AI reasoning: natural language understanding, implicit intent detection, contextual personalisation). This is not a cosmetic integration — it fundamentally changes what BYD’s vehicles can do with ambiguous voice commands and contextual inference about driver preferences.

The Xuanji AI Dual-Cycle Architecture

What BYD calls “the industry’s first dual-cycle multi-modal AI model” refers to the coordination between the cloud cycle (continuous learning from 150 million km of daily fleet data) and the vehicle cycle (real-time execution at ~8 microsecond decision latency). These are not the same model running in two places — they are two coordinated systems with distinct roles and timescales.

The Data Flywheel: BYD’s Most Durable Advantage

BYD’s fleet of 4.27 million active vehicles generates approximately 150 million km of ADAS training data per day. This figure is not a performance metric — it is a compounding structural advantage. Algorithm iteration efficiency is claimed at 3× the industry average, meaning BYD’s engineers can test and validate a model change against real-world scenarios at three times the speed of a competitor with a smaller fleet. DeepSeek R1 integration accelerates the cloud training pipeline further. Every quarter, the data gap between BYD and smaller fleet competitors grows larger, not smaller.

The fleet data flywheel is arguably BYD’s most durable competitive advantage in autonomous driving — not its silicon partnerships, not its algorithm team size, but the 150 million km of real-world training data generated daily by 4.27 million vehicles.

Chapter 04:

OTA & Connectivity — 200 Updates Per Year at Fleet Scale

Why OTA Cadence Is a Competitive Weapon

Over-the-air update capability is often described as a feature. At BYD’s scale, it is something more structural: the mechanism by which software investment translates into customer-facing value, product deficiencies are corrected before they reach dealerships, and the data flywheel generates feedback loops compressing development cycles. When BYD deploys approximately 200 OTA software packages per year across 4.27 million vehicles spanning dozens of model variants, the engineering challenge is comparable to running a major consumer software platform — except that a failed deployment cannot simply be rolled back with a server-side flag; it must be safely reversed on a safety-critical embedded system in a vehicle that may be mid-journey.

The OTA Technical Architecture

Dual-Bank (A/B) Flash Partitioning is the foundational reliability mechanism. Every vehicle module with OTA capability maintains two firmware banks: Bank A (currently executing) and Bank B (target for the incoming update). When an update is triggered, the system downloads new firmware into Bank B while Bank A continues running without interruption. Once download and cryptographic verification are complete, the bootloader switches the active partition on the next scheduled reboot. If Bank B firmware fails health checks during a post-update validation period, the system automatically reverts to Bank A — a rollback mechanism that makes OTA deployments safe even for powertrain-adjacent domains.

Delta Compression is what makes 200 packages per year economically viable. Rather than transmitting complete firmware images (which for a modern ADAS domain controller can exceed 2 GB), BYD’s OTA infrastructure transmits only the binary differences between current and target firmware versions. This reduces average package size by 70–90%, cutting cellular data costs and enabling updates that would otherwise require hours to complete in minutes. It also makes incremental releases practical: BYD can push a 0.0.1-version sensor calibration fix without bundling it into a full release cycle.

Security Orchestration provides the third pillar. Each vehicle has a unique cryptographic identity provisioned at manufacture. Firmware packages are signed with BYD’s private key before distribution, and the vehicle verifies the signature against a hardware-stored public key in a Hardware Security Module before permitting installation. BYD maintains a revocation mechanism for outdated firmware to prevent rollback attacks exploiting known vulnerabilities. Cloud infrastructure runs on Alibaba Cloud and Huawei enterprise solutions, providing the scale to serve the full fleet simultaneously.

OTA Cadence by Domain

Different vehicle domains have fundamentally different update economics. Infotainment can absorb rapid changes without safety validation overhead. Safety-critical domains require formal re-qualification cycles that constrain cadence regardless of engineering ambition.

Ground-Up Connectivity: The Xuanji Three-Network Stack

BYD’s vehicles are designed as connected from the architecture level, not as vehicles with a connectivity module bolted on. The Xuanji Three Networks (in-vehicle Ethernet, 5G, satellite) are first-class architectural elements, not optional features. The TCU maintains constant communication with BYD’s cloud for real-time diagnostics, OTA management, connected services, and fleet data aggregation.

C-V2X integration enables cooperative adaptive cruise control, intersection collision warning, and emergency vehicle preemption — positioning BYD’s vehicles to leverage China’s expanding roadside RSU infrastructure for perception beyond onboard sensors. As cities deploy more RSU infrastructure, vehicles with C-V2X capability benefit from an expanding sensor network they did not pay for.

Chapter 05:

Vehicle Portfolio — Architecture Across the Brands

How One Architecture Serves $9k to $150k Vehicles

One of the most strategically significant aspects of BYD’s architecture is how it scales across a portfolio spanning from a $9,000 city car to a $150,000 performance SUV. This is achieved not by developing independent architectures for each price segment — it is achieved by designing a scalable platform in which the software framework is common and the hardware configuration is tiered. This is architecturally analogous to how a cloud platform scales across workloads by adjusting the compute tier while keeping the software stack constant.

The Dynasty and Ocean series — BYD’s highest-volume brands in the RMB 80,000–200,000 ($11,000–$28,000) segment — form the commercial heart of the operation and the data flywheel that makes everything else possible. Tens of thousands are delivered daily, each generating ADAS training data that feeds the cloud training pipeline. The Seagull, at under $9,000, is the most aggressive expression of this strategy: God’s Eye C ADAS on Horizon J6M silicon, standard, at a price point where no other manufacturer offers any comparable intelligence capability.

Yangwang — BYD’s ultra-luxury brand — represents the architectural frontier. The U8 SUV and U9 supercar deploy the e4 Platform (quad-motor independent drive), DiPilot 600 with dual NVIDIA Orin X and triple LiDAR, and DiSus-P/X active suspension enabling tank-turn manoeuvres. These are the vehicles in which the Xuanji A3 chip will debut in production.

February 2025 milestone: BYD announced God’s Eye ADAS as standard across 21 of 30 models spanning 4 brands — including the $9,000 Seagull. This made BYD the first automaker globally to offer full highway NOA as standard on a sub-$10,000 vehicle. Target: 40–50% of 2025 sales volume (approximately 2–2.5 million units) equipped with intelligent driving.

Share Vaisakh’s Blog

Chapter 06:

Benchmarks — BYD vs Tesla vs Xiaomi

The SDV Litmus Test

How truly software-defined is BYD? This is not a binary question — “software-defined” is a spectrum, and BYD’s posture differs from Tesla’s and Xiaomi’s in ways reflecting genuinely different strategic choices rather than gaps in capability.

Tesla set the SDV benchmark. Its quasi-centralised HW4.0 architecture, unified Linux OS, fully in-house FSD algorithm, own AI silicon (AI4/AI5), and China OTA cadence of ~16 significant packages per year represent the deepest software-only philosophy in automotive. Tesla’s strength is software purity and control. Its constraint is volume: 2.5× fewer vehicles means a smaller data flywheel.

Xiaomi SU7 (launched 2024) is the cleanest-sheet zonal architecture in production — a single Integrated Central Processor (Snapdragon 8295) connected to three zonal controllers, running HyperOS. Elegant architecture, early data advantage, but no vertical integration depth and a fleet data pool orders of magnitude smaller than BYD’s.

BYD sits between these poles. It exceeds Tesla on vertical integration (75% vs ~45% in-house) and fleet data scale. It significantly exceeds both on OTA cadence. Where it trails Tesla: software architecture purity (three-OS hybrid vs unified Linux) and full-stack algorithm ownership (hybrid partnerships vs fully in-house FSD). The practical implication: BYD’s architecture is better optimised for cost and scale; Tesla’s for software authority and iteration depth.

SDV Dimension-by-Dimension Assessment

OTA Cadence Comparison

Chapter 07:

The Triple-Moat Differentiation Playbook

How BYD Wins: Three Interlocking Moats

BYD’s competitive architecture is built on three interlocking moats — cost, velocity, and data — that form a self-reinforcing flywheel. Each moat strengthens the others: lower costs expand the fleet; a larger fleet generates more data; better data improves the product; a better product commands higher volumes and margins. Understanding this system is essential for any organisation attempting to compete with or respond to BYD’s global expansion.

Moat 1 — Cost: Vertical Integration Chain

From lithium mine to Blade Battery to IGBT/SiC/Xuanji A3 to completed vehicle: 75% parts self-manufactured, eliminating supplier margins at every layer. The Xuanji A3 costs approximately one-third of NVIDIA Thor. BOM cost runs ~20–25% below traditional OEM baselines for core components. This is not a cost programme — it is a structural cost architecture built over thirty years. The result: highway NOA as standard on a $9,000 vehicle, which no competitor — traditional OEM or EV startup — has come close to matching.

Moat 2 — Velocity: Full-Stack Iteration Control

A closed-loop ecosystem — self-developed chip to OS to algorithm to data — means OTA updates require no third-party supplier coordination. New model from concept to production: 12–18 months versus industry average 36–48 months. Approximately 200 OTA packages per year — 12× Tesla China, 25× Toyota. BYD claims software iteration efficiency at 3× the industry average. This velocity comes from architectural ownership: when you control the chip, the OS, the algorithm, and the fleet data pipeline, the feedback loop closes at a fundamentally faster rate than when you depend on external vendors at each layer.

Moat 3 — Data: The 150M km/day Flywheel

4.27 million vehicles generate 150 million km of ADAS training data daily. DeepSeek R1 integration accelerates cloud training. The flywheel compounds continuously: every quarter, BYD’s data advantage over smaller fleet competitors grows larger, not smaller. Latecomers face a widening gap, not a static one. This is the moat that is most difficult to contest without either massive fleet scale (which takes years to build) or a synthetic data strategy capable of substituting for real-world scenario diversity.

BYD does not win on any single technology. It wins because it controls the entire value chain from lithium extraction to software deployment — and uses that control to compress cost, accelerate iteration, and compound data advantage simultaneously.

Subscribe now

Chapter 08:

Architecture Evolution Matrix

How BYD’s Stack Has Changed Across Generations

Chapter 09:

Strategic Implications

For The Architects

BYD’s Xuanji platform demonstrates that a three-OS hybrid with a Type-1 hypervisor is viable at mass production scale. QNX + Android + Linux on shared SoC silicon — with AUTOSAR Classic at the safety edge and Adaptive AUTOSAR emerging in the central domain — is the pragmatic architectural path for any OEM balancing ISO 26262 compliance with rich software experience. The vECU migration strategy (body/comfort 2026, powertrain auxiliary 2028) offers a concrete sequencing model that manages certification risk while progressing toward centralisation.

Do not conflate OTA frequency with software quality. BYD’s 200 packages per year works because of delta compression, staged rollout, and dual-bank flash — not despite safety standards. The security and reliability infrastructure enabling that cadence is as sophisticated as the update frequency it enables.

The interconnect lesson is also worth absorbing: the move from CAN to 10G Ethernet is not a luxury upgrade for premium vehicles. It is an architectural prerequisite for any ADAS system running more than two or three cameras simultaneously. If your platform architecture still relies on CAN as its primary sensor backbone, the sensor fusion capability you can offer is fundamentally constrained — regardless of how capable your central compute silicon is.

For The Technology Leaders

BYD’s silicon strategy reveals the strategic value of chip design capability even without fab ownership. The Xuanji A3 (TSMC 4nm, BYD-designed) delivers competitive TOPS at approximately one-third the cost of equivalent external solutions because hardware-software co-design removes the third-party vendor markup and allows the chip’s architecture to be optimised specifically for BYD’s software workloads. If your SDV platform has a long-term dependency on NVIDIA or Qualcomm for all compute, evaluate whether that dependency represents a strategic cost bottleneck — particularly as those vendors serve many competing customers simultaneously.

BYD’s 5,000-person ADAS engineering investment is not a cost centre to be explained — it is the mechanism by which 150 million km per day of data translates into product differentiation. The data flywheel only generates value if there is an engineering organisation capable of converting raw data into improved algorithms at sufficient speed. The engineering headcount and the fleet scale are not independent investments; they are two halves of a single system.

For C-Suite Executives

BYD competes on three dimensions simultaneously — cost, velocity, and data — in a self-reinforcing flywheel that grows more powerful each year as the fleet expands. Any organisation entering a market where BYD competes must identify which moat it can meaningfully contest on a five-year horizon.

The cost moat is nearly impossible to replicate without decades of supply chain capital and institutional knowledge. The velocity moat is achievable with a cloud-native software organisation and a platform architecture that reduces dependency on external vendor coordination. The data moat requires either comparable fleet scale (years away for any new entrant) or a credible synthetic data strategy capable of substituting for real-world scenario diversity.

The most defensible positions against BYD are deep regional software differentiation, superior regulatory positioning in markets where BYD’s compliance timeline is less mature (particularly European GDPR, functional safety homologation timescales, and local cybersecurity regulation), and premium brand equity commanding margins BYD’s cost structure cannot yet serve at its highest engineering ambition.

Conclusion: The Architecture Behind the Numbers

BYD’s architecture is not accidental. It is the outcome of a consistent, three-decade philosophy: own the technology stack rather than assemble it from external suppliers. That choice required patient capital deployment across battery chemistry, power electronics, semiconductor fabrication, vehicle platform engineering, and now AI software — each layer building on the previous, each creating cost and capability advantages that compound over time.

The resulting competitive position — cost moat, velocity moat, data moat — is structurally difficult to contest on a five-year horizon precisely because the assets creating each moat were accumulated sequentially. You cannot buy thirty years of in-house IGBT manufacturing experience. You cannot instantly build a fleet data flywheel generating 150 million km per day. You cannot compress a twelve-month vehicle development cycle without first solving the software architecture, the platform standardisation, and the supplier integration that make it possible.

What BYD has built is not a technology company that makes cars, in the Elon Musk sense of that phrase. It is something more unusual: a manufacturing company that has successfully internalised the technology stack at every level of the value chain, and is now using that integration to deliver software-defined vehicle capability at a price point the rest of the industry cannot yet explain, let alone match.

Sources: BYD Dream Day 2024 · BYD Intelligent Strategy Conference February 2025 · NVIDIA DRIVE Orin specifications · Horizon Robotics public disclosures · 36Kr · DeepSeek integration announcements · BYD Annual Reports 2023–2024 · Kimi AI research · DeepSeek analysis · Qwen analysis · Grok analysis · Z-AI analysis · Perplexity analysis · Gemini analysis.

Note: Due to limited publicly verifiable data, certain technical sections of this analysis rely on logical deductions and industry assumptions.

I do not ask this rhetorically. I ask it because I live inside the answer every day, leading the Connected Cars Platform at Tata Motors — one of the world’s largest and most complex automotive programmes. And my honest view, after years of building this infrastructure, is that the industry has a clarity problem. We are solving for the wrong constraint.

What follows is not a product review or a conference recap. It is a set of theses — things I believe the industry needs to confront honestly — drawn from the real experience of building a DevSecOps backbone for one of India's most ambitious SDV programmes, using JFrog as its foundation.

THESIS ONE

The SDV’s hardest problem is not software. It is provenance.

When people talk about the Software Defined Vehicle, the conversation usually gravitates towards the glamorous end: AI-assisted driving, personalised in-cabin experiences, remote diagnostics. These are real and important. But they are downstream of a problem the industry is less eager to discuss.

A modern vehicle programme at scale involves somewhere between 50 and 150 electronic control units, each running firmware from a different source. Some is written in-house. Most arrives from a Tier-1 supplier as a compiled binary — a black box the OEM did not write, cannot read, but is legally and morally responsible for.

This is not an edge case. This is the automotive software supply chain. And it has an uncomfortable implication: you cannot have a Software Defined Vehicle strategy without a software supply chain strategy. The two are the same problem.

THE TATA MOTORS REALITY

At Tata Motors, our Connected Cars Platform integrates software artifacts from over 15 partner organisations alongside our own internally developed code. Every piece — whether written by our engineers in Pune or delivered as a binary from a Tier-1 partner — must be provable, traceable, and compliant before it reaches a vehicle.

JFrog Artifactory became the single source of truth for this entire ecosystem. Not because it was the most convenient tool, but because the alternative — fragmented repositories, manual handoffs, tribal knowledge about what version of what binary went into which build — was a liability we could not afford.

The insight here is not about tooling. It is about the organisational admission that the supply chain is the product. The vehicle that a customer drives is, in software terms, the aggregate output of dozens of development organisations who will never meet each other. The OEM's job is to make that aggregate trustworthy. Centrally. At every release.

THESIS TWO

Speed and safety are not a tradeoff. Refusing to resolve the tension is the failure mode.

The received wisdom in automotive engineering is that safety and speed exist in opposition. Move fast, and you cut corners. Move carefully; you fall behind. This framing is seductive because it feels honest. In practice, it is the rationalisation of organisations that have not yet invested in resolving the tension.

Subscribe now

Here is what I have learned building continuous delivery infrastructure for software that goes into moving vehicles: the organisations that treat speed and trust as opposing forces are the ones that have not automated trust.

When every artefact in your pipeline is automatically scanned for vulnerabilities the moment it lands in your repository, when SBOM generation is a pipeline output rather than a programme-end deliverable, when partner binaries are governed by the same policy engine as your own code — you have not slowed down. You have made speed safe.

At Tata Motors, our CI/CD infrastructure runs across more than 200pipelines. Engineers across multiple sites commit code continuously. The release cadence we are working towards would have been considered reckless by automotive standards a decade ago. It is only viable because the trust layer is automated, not manual.

What follows is not a product review or a conference recap. It is a set of theses — things I believe the industry needs to confront honestly — drawn from the real experience of building a DevSecOps backbone for one of India's most ambitious SDV programmes, using JFrog as its foundation.

THESIS THREE

Regulation is not arriving. It has arrived. And it is a gift, if you read it correctly.

UNECE R155 and R156 — and their Indian equivalents AIS 189 and 190 — have fundamentally changed the compliance conversation in automotive. These regulations mandate cybersecurity management systems and software update management systems as conditions of vehicle homologation. They are not advisory. They are not aspirational. They are prerequisites for putting a car on the road.

I want to make an argument that runs against the grain of how most OEMs are approaching this: these regulations are not a burden. They are a blueprint.

Read UNECE R155 carefully and you will find a detailed specification for exactly the kind of traceability, vulnerability management, and incident response capability that a mature DevSecOps organisation needs to build anyway. The regulation did not invent a new requirement. It codified a best practice that software-forward organisations were already pursuing.

THE ARCHITECTURAL IMPLICATION

CSMS compliance under R155 requires end-to-end cyber posture from component sourcing through in-life updates. SUMS compliance under R156 requires governed, auditable update processes with traceable delivery chains.

Both of these are properties of a well-designed DevSecOps pipeline — not additional governance layers bolted on top. JFrog’s traceability, attestation, and policy controls made our regulatory readiness a consequence of good engineering, not a separate compliance programme.’

The OEMs that will struggle with R155/R156 are the ones that treat it as a legal question rather than an engineering question. The ones that build the right infrastructure — a single source of truth for artefacts, automated security scanning, governed OTA delivery pipelines — will find that compliance is a byproduct, not a project.

THESIS FOUR

The OTA update is the product. Which means the pipeline is the factory.

There is a mental model shift that every automotive organisation needs to make, and many have not made it yet. In the traditional world, the product is the vehicle. Once it leaves the factory, it is complete. The software-defined vehicle breaks this model permanently.

The vehicle that a customer drives today is not the vehicle they will drive in six months. It will have new features, patched vulnerabilities, updated maps, refined ADAS behaviour — all delivered over the air, long after the hardware left the assembly line. The product is not the car. The product is the car-plus-its-update-history. And that update history is generated by a software delivery pipeline.

This is a profound shift in what it means to manufacture a vehicle. It means that the factory does not stop when the car ships. The pipeline is a continuous factory, running twenty-four hours a day, producing software updates that are, in a meaningful sense, new versions of the product.

At Tata Motors, the architecture reflects this. Approved and scanned builds flow from JFrog Artifactory into our OTA update infrastructure, and from there to the vehicle — integrated with our automotive PLM systems so that engineering changes are traceable all the way through. The pipeline is the factory. And like any factory, it must be reliable, auditable, and safe.

Share Vaisakh’s Blog

THESIS FIVE

The engineering culture gap is wider than the technology gap.

I want to end with the thesis that is hardest to quantify and most consequential to get right. The SDV transition is, at its heart, a culture transition. And most of the technology vendors selling into this space have an incentive not to tell you that.

The technology for building software-defined vehicles exists today. The CI/CD tooling, the artefact management systems, the security scanning platforms, the OTA infrastructure — it is all available, mature, and proven at scale. What is not available off the shelf is an organisation that knows how to use it.

Automotive engineering cultures were built around hardware-first thinking: long design cycles, waterfall programme management, quality gates that assume the product is immutable once it ships. Importing software delivery practices into this culture is not a tooling challenge. It is a change management challenge of the first order.

1. The single source of truth is a cultural commitment before it is a technical one. You can deploy Artifactory in an afternoon. Getting 15 partner organisations and multiple internal teams to actually use it — and only it — takes months of alignment work.

2. Security scanning at the pipeline level requires a shift in who owns security. In most automotive programmes, cybersecurity is a function at the end of the programme. In an SDV programme, it must be a property of every build — which means it must be owned by the engineers doing the building.

3. OTA as a product capability requires a different relationship with the customer. Customers who experience a vehicle as a static, physical product will react differently to software updates than customers who understand their car as a platform. Managing this expectation is as important as managing the software.

4. The partner ecosystem is both the biggest risk and the biggest opportunity. The OEMs that learn to govern their Tier-1 software supply chains — to scan, attest, and govern partner binaries at scale — will have a structural advantage that is very hard for competitors to replicate quickly.

The Race Worth Running

The SDV era does not reward the organisations that move first. It rewards the ones who move with the deepest foundations.

Speed without provenance is a liability. Features without governance are debt. And a pipeline without trust is just complexity with better branding.

Build the invisible layer right — the single source of truth, the automated security posture, the governed delivery chain — and everything above it accelerates. Get it wrong, and every layer you add makes the problem harder to fix, not easier.

The technology exists. The regulations are written. The supply chain is ready to be governed.

The only question left is whether your organisation is.

Share Vaisakh’s Blog

In the software-defined vehicle (SDV) era, in-vehicle APIs have become the hidden engine behind innovation, modularity, and speed. These interfaces unlock vehicle functionality as reusable services, enabling automakers to transform vehicles from static machines into dynamic software platforms.

1. From Signals to Services: The Rise of Vehicle APIs

Historically, vehicle software was tightly coupled to hardware—custom integrations were needed for every new feature. With APIs, developers now access vehicle functions (e.g., speed, lighting, HVAC) through standardised commands, drastically reducing complexity.

• APIs bring modularity, enabling rapid feature additions.

• OEMs can standardise interfaces across models and tiers.

• A common abstraction reduces cross-team friction in software development.

This shift parallels the smartphone ecosystem, where unified APIs enabled a massive developer ecosystem and software innovation [11].

2. Anatomy of In-Vehicle APIs

In-vehicle APIs are layered to support different roles within vehicle architecture:

• Application APIs: High-level user-facing interfaces like seat control or ADAS configuration.

• Middleware APIs: Handle routing, pub-sub communication, and service discovery across domains.

• Transport APIs: Provide reliable, deterministic communication using SOME/IP, DDS, or custom transports.

The Vehicle Abstraction Layer (VAL) is the key enabler here—it provides developers a consistent way to read/write vehicle signals and trigger behaviours [3]. VAL is getting modernised with more platforms & protocol-agnostic names and strategies.

3. Welcome Experience: Coordinated by APIs

Here’s how a basic driver welcome sequence becomes trivial with in-vehicle APIs:

vehicle_api.set(”Vehicle.Cabin.Lights.Dome.IsOn”, True)
vehicle_api.set(”Vehicle.Cabin.Seat.Row1.DriverSide.Position”, “profile_2”)
vehicle_api.set(”Vehicle.Cabin.HVAC.Temperature”, 22.0)

• A single function call replaces layers of signal decoding.

• Easy orchestration of multi-domain actions.

• Scalable across car models due to abstraction.

Modern API based approaches enable feature implementation to be shrunk to less than 8 weeks from a traditional 24-week timeline. This makes nimble feature roll-out to the user, enhancing the vehicle ownership experience.

4. Automotive API Standards: VSS, CAAM, AUTOSAR

To enable cross-OEM standardisation, various bodies have proposed structured data and interface specifications:

• COVESA VSS: Defines a hierarchical structure for vehicle signals like Vehicle.Speed and Cabin.Seat.Position. [1][2]

• CAAM (China Association of Automobile Manufacturers): Defines over 290 atomic APIs for functions across body, powertrain, and comfort domains. [10]

• AUTOSAR API Gateway: Bridges VSS-style abstraction with legacy embedded platforms. [9]

5. Ecosystem Implementations: KUKSA, VISS, AUTOSAR

Turning standards into running code, several implementations support real-world API usage:

• KUKSA.VAL: gRPC broker with support for VSS-compliant data access and pub-sub streaming [3].

• VISS: REST/WebSocket API for accessing vehicle data over web-friendly protocols [1].

• AUTOSAR Adaptive: Defines standardised service definitions and APIs in ARXML format [9].

6. The Diagnostic Layer: Service-Oriented Vehicle Diagnostics (SOVD)

As vehicles add containers and microservices, legacy diagnostic protocols (like UDS) fall short.

SOVD, standardised by ASAM, enables:

• REST-like access over HTTP for diagnostics.

• OAuth2-based secure access control.

• Dynamic discovery of new diagnostic endpoints.

For example, an OTA diagnostic system can request:

GET /vehicle/diagnostics/faults

And receive structured JSON data without needing ECU-specific UDS commands.

SOVD supports in-car, remote, and hybrid diagnostic models and can bridge UDS for backward compatibility [14].

7. Real-World SDV Companies & API Strategies

Tesla

• Offers over 80 API endpoints to control and query vehicle systems [4][5].

• Recently launched monetised Fleet API [4].

• Uses streaming architectures for real-time updates.

These are primarily REST-based APIs & SDK for developers outside the car. The assumption is that they have equivalent in-car APIs. Tesla might also have a large API set, which is only accessible to internal developers.

BYD

• DiLink OS allows deep in-car app integrations [6].

• D++ platform (semi-open) exposes infotainment APIs via Android SDK [6].

• Limited openness beyond the Chinese ecosystem.

Xiaomi

• HyperOS spans phones, smart homes, and cars [7].

• Prioritises unified software experience across the user ecosystem.

• Leverages API thinking from its IoT products.

Huawei

• Supplies smart cockpit platforms and an autonomous stack to partners [7].

• Emphasises API-based platform delivery, not end-customer ownership.

Changan

• SDA platform with over 500 atomic and 200 scenario APIs [9].

• Designed around Global SOA with reusable service buses and real-time cross-domain middleware.

  Thanks for reading Vaisakh’s Blog! Subscribe for free to receive new posts and support my work.

8. Business Benefits of API-Centric Design

Direct Impact

• 30%+ gain in development velocity due to reuse and modularity [9].

  • One API tested. validated & released once, can be reused for multiple applications & use cases.

• ~14 months to market vs 3-5 years for traditional vehicles [9].

• Reduced recall costs with software-based issue resolution [11].

Strategic Value

• Supports OTA services and subscription features.

• Opens path to third-party developer ecosystems.

• Enhances data monetisation strategies (usage-based insurance, fleet ops, etc.) [11].

Modern SDV automakers make every capability in the car an API. These abstracted APIs enable to delivery of complex functions to the customers.

9. API Thinking vs. Legacy Thinking

API-thinking is more than a technical design choice—it is a mindset shift in how we conceive and deliver vehicle functionality. Instead of designing monolithic, hardware-bound features, engineers break down vehicle capabilities into reusable, discoverable, and composable services. This allows teams to think in terms of contracts rather than implementations: as long as the API remains consistent, underlying systems can evolve independently.

For business leaders, API-thinking means faster innovation cycles, cleaner integration with partners, and a foundation for new revenue models such as feature subscriptions and developer ecosystems. In practice, it turns vehicles into living platforms—capable of adapting and growing throughout their lifecycle, just like smartphones and cloud systems.

Share

10. Open Source Ecosystem: Accelerators and Friction

Key Projects

• Eclipse KUKSA: VSS runtime stack [3].

• Velocitas: App SDKs for SDVs [3].

• uProtocol: Messaging layer between vehicle domains [13].

• SOAFEE: Edge-cloud blueprint for microservices on vehicle HPC [12].

Challenges

• Licensing models (e.g., Eclipse vs. GPL).

• OEM reluctance to open sensitive IP.

• Integration complexity with legacy toolchains [13].

Open source remains a strategic enabler for agile SDV development, especially as software-defined control becomes the dominant value layer.

11. What’s Ahead: Interoperability and Governance

• Push from COVESA, CAAM, and AUTOSAR for harmonised APIs [1][10].

• ISO/SAE groups exploring API safety and certification pathways [14].

• Edge compute orchestrators (like Eclipse Ankaios) are expanding to support multi-runtime SDV stacks [13].

Conventional OEMs struggle to think about software-first or API-first, as they are culturally mechanical & efficient in creating brittle one-to-one interfaces. A full thought process change is imminent to achieve SDV and an API-first approach. This is a similar moment when modern software moved from a monolith to microservices.

References

1. COVESA Vehicle Signal Specification – https://covesa.github.io/vehicle_signal_specification/

2. Intellias: Vehicle Signal Specification – https://intellias.com/vehicle-signal-specification/

3. Eclipse KUKSA Databroker – https://github.com/eclipse-kuksa/kuksa-databroker

4. Tesla API Developer Guide – https://www.linkedin.com/pulse/tesla-opens-its-api-high-octane-move-marketers-exnovation-n9ztc

5. Shankar Kumarasamy: Tesla API Documentation – https://shankarkumarasamy.blog/2023/11/23/tesla-developer-api-guide-developing-third-party-apps-part-2/

6. Wikipedia: BYD Automotive OS – https://en.wikipedia.org/wiki/BYD_Auto

7. ResearchInChina: Xiaomi HyperOS Overview – http://www.researchinchina.com/Htmls/Report/2024/73953.html

8. Business Standard: Huawei Smart Driving Strategy – https://www.business-standard.com/world-news/here-s-why-huawei-s-expansion-in-smart-driving-stirs-competition-scrutiny-125042300138_1.html

9. ResearchInChina: SDV Middleware Platforms – https://www.marketresearch.com/Research-in-China-v3266/Software-Defined-Vehicles-SOA-Middleware-40596367/

10. CAAM Automotive Open Standards – http://en.caam.org.cn/Index/show/catid/22/id/1565.html

11. TietoEVRY: Automotive API Adoption – https://www.tietoevry.com/en/blog/2025/10/introduction-automotive-api/

12. Arm SOAFEE Overview – https://www.arm.com/company/success-library/made-possible/soafee

13. Eclipse uProtocol GitHub – https://github.com/eclipse-uprotocol

14. IEEE: SOVD Implementation Framework – https://ieeexplore.ieee.org/document/10620563/

Subscribe now

In the race towards smart mobility & Software Defined Vehicles, over-the-air (OTA) software updates have become both a blessing and a curse for carmakers. OTA allows automakers to fix software bugs, recall vehicles, and add dazzling new features —all without requiring the owner to visit a dealership. But, as multiple recent headlines demonstrate, even leaders like Tesla, Volkswagen, and Ford are discovering that botched OTA implementations can bring steep and sometimes invisible costs. Let’s unpack the real-world ROI, accident case studies, and lessons hidden behind the hype.

2. The Dual Promise of OTA: Huge Cost Savings, Faster Fixes

2.1. Quantifying the Upside

OTA updates can cut recall costs by up to 70% compared to physical recalls. Traditionally, an automotive recall costs anywhere from $500 to $2,000 per vehicle, with mass recalls quickly reaching billions in direct costs.

If deployed correctly:

• OTA updates cost: about $15/vehicle (vs. $300–$2,000 for physical recall)

• Time to fix: 2–3 days (vs. 45+ days for physical repair)

• Customer satisfaction: 85% (OTA) vs. 40% (physical recall)
  By 2028, the US auto market alone is projected to save $1.5 billion/year with OTA-enabled recalls. Globally, the OTA market will grow from $5.2 billion (2025) to $25 billion by 2035.

2.2. High Stakes: When OTA Goes Wrong

While the benefits are significant, failures are costly. With modern vehicles running over 100 Electronic Control Units (ECUs) and millions of lines of code, a simple mistake can cascade across entire fleets (see Table 1).

Real-World Examples (2020–2025)

Tesla

• Phantom Braking Recall (2021): OTA bug in Full Self-Driving beta send false collision warnings to 12,000 vehicles. Tesla halted the update, issued a corrective OTA within a day. Despite agility, the incident triggered a formal NHTSA recall and negative press.

• Battery Range Throttling Lawsuit: A 2019 OTA update capped the battery range of 1,743 Teslas for safety, angering users. Result: $1.5 million legal settlement (& lost trust) for Tesla.

• Record Recalls (2022): 19 recall campaigns covering 3.8M vehicles. 12/19 issues fixed via OTA – but the public’s perception of “constant recalls” stings brand value.

Volkswagen Group

• ID.3, ID.4, and Porsche Taycan Glitches: Lapses in OTA readiness meant many cars in 2020–2023 were physically recalled for software faults. Porsche recalled 43,000 Taycans in 2021 for a bug that could not be fixed OTA; costly and embarrassing for a premium brand.

• CARIAD Crisis (2022): Delayed software led to the CEO shakeup, billions lost in R&D, and stock stagnation.

Ford & GM

• Ford Mustang Mach-E (2022): Battery contactor flaw issued as OTA “patch.” Regulators later questioned the effectiveness, highlighting OTA’s “good enough” tradeoffs. Ford was fined $165 million in a separate recall for slow compliance.

• GM Bolt EV Fires (2021): Hardware recalls for battery fires cost $1.8B, and OTA update temporarily limited charging.

Share Vaisakh’s Blog

2.3. The Hidden Costs

3. Beyond the Direct Dollar: Brand, Legal & Reputation Fallout

1. Legal Liability & Settlements: Tesla’s $1.5M for battery throttling, Volvo fined $130M for recall delays.

2. Stock Market Penalty: NIO’s battery-fire recall (2019) cost 80% market value drop in months. VW, Ford, and others have seen temporary dips following major recall news.

3. Reputation Damage: Brand loyalty suffers after failed OTAs — studies show customers avoid brands with recent recall histories.

4. Management Distraction: Software crises diverted R&D from innovation to crisis management.

3.1. Why OTA Still Fails: The Technical Reality

• Complex Architectures: Cars now have dozens of ECUs. One update bug can “brick” the whole car.

• Connectivity Risks: Failed OTA downloads leave vehicles in limbo. BMW, Polestar, VW, and Rivian have all had incidents of “bricked” or immobilised vehicles.

• Calibration for Safety Systems: Updating ADAS, brake, or steering software needs real-world validation; labs miss edge cases.

• Cybersecurity: Jeep hack (2015) led to 1.4M vehicle recall. A compromised OTA pipeline could have catastrophic results.

• Legacy Architecture: OEMs like VW required dealership fixes for what should have been OTA updates, due to old platforms.

3.2. Lessons Learned & Where the Industry is Headed

1. OTA Execution = Survival: By 2025, automakers lacking robust OTA lose up to $900M/year in avoidable recall costs.

2. Investment in Quality Assurance: Carmakers are building "Software SWAT teams" and digital twins to test updates virtually. Software validation is now as critical as crash tests.

3. Regulation is Coming: NHTSA and China are building new regulatory frameworks to govern vehicle OTA and software recalls (2022–2025). In addition, regulations like the UN.ECE R155 & R156 are for cybersecurity compliance and software update management.

4. Market is Growing Fast: By 2035, almost all new cars will support OTA; annual industry savings and revenue potential will be massive.

4. Conclusion

OTA updates are not an optional feature; they are now core to the automaker's business model. But the digital tightrope is real: a single failed update can cost millions, tank a stock price, and sink customer trust overnight. The revealed ROI story is this: OTA delivers huge savings and agility, but only for automakers that invest deeply in engineering, security, and crisis readiness. As vehicle software complexity explodes, OTA’s winners will dominate the automotive landscape—while those that fumble may face existential risk.

It is essential to implement systems & critical processes around OTA. Especially while rolling out updates for safety-critical systems. While we say the cars are mobile phones on wheels, they are no less than a robot. Which could cause danger to humans inside & outside. Along with update failure, an improper OTA could enable wrong software, configuration and security for vehicles.

So, OTA shall be designed & implemented with the same care as a safety system..!

5. References

1. How OTA updates reduce automotive recalls: A cost-saving strategy for software-defined vehicles, Mender.io (2024), Link

2. OTA updates to fix recalled cars will save OEMs $1.5B, ABI Research (2023), Link

3. Automotive Over-The-Air (OTA) Updates Market - 2035, Future Market Insights (2025), Link

4. Automotive Over-the-Air (OTA) Updates Market Revenue and Growth (2025), Maia Research, Link

5. Tesla, Electrek, Reuters, and NHTSA regulatory releases (2020–2024)

6. Volkswagen Group, Porsche, Ford, GM software recall and financial disclosure reports (2020–2025)

7. NIO 2019 investor guidance, Bloomberg (2019)

8. Polestar, Jeep, Rivian software recall and cybersecurity incidents (2020–2024)

9. China OTA regulations, Reuters (2024), Link

10. Recall cost and satisfaction survey, Accenture, KPIT (2025)

11. Recall Masters 2024 Automotive Recall Report, Recall Masters (2025), Link

12. “The Hidden Costs: When OTA Goes Wrong,” (2025)

13. Market and recall cost trend data, eSync Alliance

14. “Software-Related Recalls and the Auto Industry’s Ongoing Evolution.” WardsAuto (2024), Link

    ---

Share Vaisakh’s Blog

In March 2024 Xiaomi’s debut sedan, the SU7, briefly overtook Tesla’s Model 3 in Chinese monthly sales. Fifteen months later the SUV follow-up, the YU7, racked up ≈240 000 locked orders in its first 18 hours, triggering delivery waits of up to 60 weeks. Behind that stampede sits a strategy familiar to smartphone fans: squeeze margins on hardware, over-deliver on specs, and rely on software updates and ecosystem lock-in to create lifetime value.

Xiaomi’s bet is that the next big consumer device is the car—and that winning the software-defined vehicle (SDV) race matters more than owning a century of mechanical know-how. This article dives into the technology, AI methods, manufacturing tricks, and ecosystem play that power that wager.

2. Xiaomi’s SDV Blueprint

2.1. Compute & E/E architecture

Xiaomi adopted a semi-centralised architecture: one “brain” plus zonal nodes rather than dozens of siloed ECUs.

2.2. Spec-sheet duel: Xiaomi vs Tesla vs Rivian

3. HyperOS & the Living-Room-to-Car Continuum

HyperOS unifies Xiaomi phones, TVs, wearables and now cars:

• Miaoxiang Desktop lets users swipe an app or video from their phone to the 16·1″ 3K centre display.

• Ultra-wideband keys, Action-Button shortcuts and CarPlay mean that even iPhone owners—52 % of early YU7 customers—feel at home.

• The vehicle appears as just another node in the Mi Home app, so firmware pushes, parts diagnostics and over-the-air features unlock re-use of Xiaomi’s existing CI/CD cloud.

4. AI Everywhere: From Code to Road to Factory

4.1. Product AI

• End-to-end driving model – Bird’s-Eye-View + Transformer + Occupancy network trained on 10 million real-world clips drives Xiaomi Pilot’s city NOA.

• Weekly “scene mining” pipeline – fleet and smartphone cameras feed a data lake where auto-labelling discovers edge cases nightly.

• In-cabin AI – Large-language-model voice assistant runs at the edge, pulling context from the calendar, Mi Home sensors and navigation to answer queries like “Set AC to match my living-room temperature”.

• Predictive maintenance – Onboard models forecast inverter and battery health, scheduling service proactively.

  Share Vaisakh’s Blog

4.2. AI-Assisted Development

• Simulation-first validation: 200+ virtual cities in NVIDIA Omniverse drive 40 × real-time miles; real-road release gates are triggered only after synthetic miles hit coverage thresholds.

• AI-driven CAD: generative design tools iterate suspension knuckles and casting ribs, shaving grams before reaching the die.

• Factory vision AI: defect-detection nets inspect welds and paint in milliseconds, feeding back into SPC dashboards.

Xiaomi backs this with ¥4.7 billion smart-driving R&D funding and >1000 specialist engineers (3000 across the broader AI Lab).

5. Manufacturing Edge: HyperCasting & Vertical Integration

Two Haitian presses rated at 9100t cast each rear under-body in a single shot—bigger than Tesla’s 9000t machines. The process merges 72 parts, eliminating 840 welds and trimming the weight by 17 %. Integrated cell-to-body packs slide into the skateboard, while in-house “Titan” alloy halves heat-treat time. The goal is smartphone-like iteration: Xiaomi claims body-frame cycle time is ≈120 s, enabling faster tack-ons of mid-cycle hardware refreshes.

6. Smart-Driving Progress & Pitfalls

Highway Navigate-on-Autopilot shipped day one; city NOA (Navigate on Autopilot) is rolling out to ten pilot cities with expansion promised to 100 by year-end.

A sobering moment came on 29 March 2025 when a standard-trim SU7 (no LiDAR) crashed, killing three occupants. Regulators reacted by banning the advertising terms “smart/autonomous driving”, insisting that over-the-air upgrades pass safety audits. Xiaomi’s counter-measure: equip every YU7—base included—with the full sensor suite and tighten DMS attention checks.

7. Lessons for Legacy Automakers

1. Centralise compute and decentralise interfaces. One Thor box plus zonal nodes out-innovates 80 domain ECUs.

2. Cast early, cast big. Die-casting is the physical pre-requisite for OTA-friendly modularity—and you can’t retrofit it later.

3. Treat the car as a node. HyperOS shows that phones, TVs and cars can share UI concepts, data pipes and cloud CICD.

4. Ship, learn, iterate. Weekly cockpit patches turn owners into beta partners and compress feedback cycles from months to hours.

5. Language matters. Overselling autonomy erodes trust; precise feature labels keep regulators and users aligned.

8. Conclusion

Xiaomi’s first fifteen months in the EV arena read like a software start-up’s blitz-scale playbook applied to hardware:

• Ecosystem pull: 600M existing device users step into a car that already knows their apps and preferences.

• Vertical integration where it counts: HyperCasting slashes BOM cost, while in-house motors and Titan alloy safeguard IP and margins.

• AI-first culture: a 3000-strong lab trains giant perception networks and designs components, blurring code and hardware.

• Value attack: By coupling 800V packs, LiDAR and adaptive air suspension with smartphone-like pricing, Xiaomi forces incumbents to justify every yuan of premium.

The combination is hard to copy piecemeal. Legacy brands can buy LiDARs; they cannot overnight replicate Xiaomi’s cloud-CI, cross-device OS, or AI data factory. That moat—more than the headline 0-to-100 time—explains why a phone company now commands year-long order books and why every traditional OEM’s SDV roadmap suddenly looks slow.

References

1. New Atlas – “240000 orders in 18 hours after YU7 launch” (27 Jun 2025). (newatlas.com)

2. WIRED – “Xiaomi YU7 is an SUV-sized middle finger to Tesla” (01 Jul 2025). (wired.com)

3. CNEVPost – “Xiaomi EV tech launch: live updates” (28 Dec 2023) – Thor/Orin, ¥4.7 bn R&D, HyperCasting. (cnevpost.com)

4. Gasgoo – “Xiaomi committed to investing ¥4.7 bn in intelligent driving” (09 Dec 2024). (autonews.gasgoo.com)

5. Reuters – “China bans ‘smart’ and ‘autonomous’ terms in vehicle ads after Xiaomi crash” (17 Apr 2025). (reuters.com)

6. CarNewsChina – “First fatal accident involving Xiaomi SU7” (01 Apr 2025). (carnewschina.com)

7. GizmoChina – “Over half of SU7 buyers use iPhones; HyperOS deep Apple integration” (27 Jun 2025). (gizmochina.com)

8. Reddit r/SelfDrivingCars – “Xiaomi YU7 launches with standard LiDAR, NVIDIA Thor 700 TOPS” (Jun 2025). (reddit.com)

9. LinkedIn Pulse – “Xiaomi 9 100-ton HyperCasting press surpasses Tesla’s Gigapress” (02 May 2024). (linkedin.com)

10. CNEVPost – “Tesla updates Model Y in China: 554 km CLTC range” (01 Oct 2023). (cnevpost.com)

Subscribe now

The Rivian R2 platform is more than just another electric vehicle—it represents a fundamental shift toward true Software‑Defined Vehicles (SDVs). By rethinking the electrical/electronic (E/E) architecture from the ground up, consolidating compute into a handful of powerful nodes, and placing software at the centre of vehicle design, Rivian has achieved dramatic reductions in complexity, cost, and weight, while enabling continuous over‑the‑air (OTA) innovation. In this blog, we explore the key pillars of R2’s Gen 2 architecture: its zonal ECU layout; the software abstractions that make it work; the tangible cost and weight savings; and how Volkswagen’s strategic partnership validates this approach.

2. Superior Software‑Defined Vehicle

Rivian’s R2 embodies the SDV ideal: software is the primary vehicle differentiator, and the hardware is merely a flexible execution layer. By consolidating functions onto powerful zonal and central controllers, Rivian can push focused OTA updates without new physical modules—streamlining feature rollouts and bug fixes alike.

Video demonstrating Software Release and Feature updates. (Source: rivian.com)

• Software‑First Philosophy

  • Features delivered via OTA updates, with hardware engineered to support growing software demands

  • Modular software layers enable rapid addition of new capabilities (e.g., camping mode, pet comfort)

• High‑Performance, Centralized Compute

  • Seven ECUs (down from 17 in Gen 1 vehicles and ~40–150 in legacy cars)

  • Shared hardware resources allow multiple functions to run on the same node

• Vertical Integration & Agility

  • In‑house hardware and software development, mirroring Tesla’s strategy

  • Gen 1→Gen 2 migration completed in ~2 years on the same software stack

3. Gen 2 E/E Architecture

3.1. Overview

By moving to a zonal layout, Rivian drastically simplifies the vehicle’s wiring harness and provides a data-centre-like network fabric under the skin. Each zone controller is a general‑purpose computer managing all devices in its region, while four central ECUs handle high‑level domains: autonomy, infotainment, vehicle access, and powertrain.

• Zonal vs. Domain‑Based

  • Domain‑based (Gen 1, many legacy vehicles): ECUs grouped by function (e.g., body, chassis, infotainment)

  • Zonal (Gen 2 R2): ECUs organized by location—West (left), East (right), South (rear)—plus four central units

• Ethernet‑Centric Network

  • Replaced ≈1.6 miles of copper wiring with multi‑gigabit Automotive Ethernet

  • Unified in‑vehicle LAN carries sensor data, commands, and diagnostics in real time

• Scalable, Modular Topology

  • New sensors or actuators plug into a zone and join the network, no dedicated ECU required

3.2. Zonal ECU Design: Engineering Simplicity

Rivian collapsed dozens of dedicated modules—window motors, mirror controllers, lighting modules, door ECUs—into just three zonal controllers. This clean‑sheet design not only slashed material and labour costs but also improved reliability (fewer connectors to corrode or break) and serviceability (faults are confined to one zone rather than a mile‑long harness).

Table 1. “Magnificent Seven” ECUs

• Consolidation Benefits

  • Removed ~500 parts (ECUs, connectors, harness segments)

  • Cut ≈44 lbs of wiring and harness weight

  • Eliminated physical fuses in favour of MOSFET‑based “virtual fuses”

• Streamlined Assembly

  • Fewer harness variants, more factory automation

  • Reduced assembly time and error points

• Reliability & Serviceability

  • Shorter, simpler wiring reduces failure opportunities

  • Zone ECUs localize faults, speeding diagnostics

4. Software: Managing and Abstracting Complexity

Rivian’s software is the “central nervous system” knitting together the simplified hardware. By rewriting and optimising code for zonal consolidation, rather than porting legacy supplier stacks—they achieved a lean, cohesive platform. Event choreography (e.g., emergency braking sequence) is handled seamlessly over the Ethernet backbone, with each ECU executing its piece in milliseconds.

• Unified Software Platform

  • End‑to‑end in‑house stack, from firmware to cloud APIs

  • Shared services (e.g., window control, lighting service) across ECUs

• Service‑Oriented Architecture

  • Abstracts hardware details, enabling high‑level features to orchestrate multiple zones

  • Facilitates coordinated behaviours (e.g., AEB triggers lights, seatbelts, screens)

• OS Diversity for Fit‑for‑Purpose

  • Linux/Android for infotainment and autonomy nodes

  • RTOS/AUTOSAR for zonal and powertrain ECUS with real‑time constraints

5. Rivian Gen2 vs. Legacy Architectures

The leap in consolidation is staggering: compared to a typical premium sedan with dozens of ECUs, R2’s seven controllers manage every function from propulsion to infotainment. Shorter, simpler wiring not only cuts weight but also reduces hand‑built harness complexity—a major bottleneck for traditional OEMs.

• ECU Count: 7 (R2) vs. 17 (Gen 1) vs. 40–150 (legacy)

• Wiring Harness: 1.6 miles removed in R2, enabling lighter, more reliable builds

• Factory Automation: Simplified harnesses allow for greater use of robotics and faster assembly

• Fragmentation: Legacy cars often have siloed subsystems—R2 offers a unified experience

6. E/E Driven Cost Efficiencies of Gen 2

By trading many low‑end ECUs for a handful of powerful ones, Rivian capitalised on chip-economies of scale. Eliminating physical fuses, multiple harness variants, and redundant modules yielded thousands of dollars in per‑vehicle savings, crucial for hitting a ~$45k R2 starting price while

• Production Savings: ≈20% lower electronics BOM cost

• Material Cost: ≈35% reduction in wiring/electronics assembly costs

• Weight Reduction: ~20kg saved, translating to range or battery‑pack savings

• Software Economics: One platform vs. many codebases—fewer engineering hours and warranty claims.

7. Conclusion

Rivian R2’s Gen 2 architecture is a blueprint for the next generation of vehicles: minimal hardware footprint, maximal software flexibility, and a network‑centric design that fosters continuous innovation. By consolidating dozens of modules into seven versatile ECUs and embedding a unified software platform, Rivian achieved unparalleled cost, weight, and complexity reductions—earning industry validation from partners like Volkswagen. As automakers worldwide embrace SDVs, Rivian’s R2 stands out as the new reference design for how to build truly software‑driven, future‑ready vehicles.

References

1. Rivian 2024 Investor Day Presentation Slides. Link

2. InsideEVs, Why ‘Zonal Architectures’ Are The Next Big Thing In EV Design, 2024. Link

3. Fast Company, The Rivian R1 is getting a major under‑the‑hood redesign, 2024. Link

4. Popular Science, How Rivian reduced electrical wiring by 1.6 miles and 44 pounds, 2024. Link

5. Design News, New Tech, Longer Range, and Lower Prices Keep Rivian in the Game, 2024. Link

6. Charged EVs, At Rivian’s Electrical Hardware Lab, Sandy Munro checks out the new GEN2 architecture, 2024. Link

7. Counterpoint Research, Volkswagen Invests $5 Billion in Rivian, Forms Joint Venture, 2024.Link

8. S&P Global Mobility, BriefCASE: Legacy to leapfrog? How the Rivian deal propels Volkswagen forward in the SDV race, 2024.Link

This blog is edited and enhanced with Chatgpt o4-mini & Research supported by Chatgpt o3

1. Introduction

Software-defined vehicles (SDVs) are redefining how cars are designed, built, and upgraded. While hardware and mechanical components remain important in an SDV, the software determines critical capabilities—from infotainment and connectivity to advanced driver-assistance systems (ADAS) and autonomous functionalities. This software-centric approach allows vehicle manufacturers to deliver over-the-air (OTA) updates, quickly patch security vulnerabilities, and introduce new features without requiring a physical recall.

However, for legacy automakers such as Volkswagen, Nissan, Ford, GM, and Toyota—entities that have thrived on traditional mechanical engineering for decades—the shift to software-driven development has proven challenging. Their reliance on existing supply chains, siloed organizational structures, and outdated electronic/electrical (E/E) architectures often leads to a practice best described as “duct taping.” In essence, they layer new software features on top of ageing systems, introducing short-term fixes rather than genuinely rebuilding vehicles from the ground up.

Faced with formidable competition from Tesla, BYD, Rivian, NIO, and Xiaomi, these legacy Original Equipment Manufacturers (OEMs) must transform profoundly or risk losing their existence in a rapidly evolving market. Below, we explore their cultural, leadership, and technical challenges, as well as lessons from software-native players and the potential future of those who fail to adapt.2. The Traditional Mindset and Fear of Change

2.1 Hardware-First vs. Software-First Mentality

Historically, automakers have excelled at mechanical engineering. Their success metrics have revolved around producing durable, reliable vehicles at scale. Software was treated as peripheral—an add-on to enhance infotainment or basic engine control units (ECUs). However, modern vehicles depend on integrated, continuously updated software platforms.

• Cultural Inertia: Deeply entrenched mechanical engineering expertise can overshadow the necessity for software innovation, stifling efforts to adopt contemporary software development lifecycles.

• Fear of Experimentation: Unlike tech companies, which embrace rapid prototyping and iterative improvements (even if it means risking early bugs), legacy OEMs often fear that any software glitch could erode brand image.

2.2 Openness and Agile Culture

A culture of openness and agility is vital for software development. In Silicon Valley, for instance, teams expect to fail fast, learn, and pivot quickly. This approach is at odds with traditional automotive practices, which rely on multi-year development cycles.

• Long Product Cycles vs. Rapid Iteration: Tesla can push a feature update over the air in a matter of weeks, whereas legacy OEMs typically lock in vehicle features years before launch.

• Siloed Mindsets: Cross-disciplinary collaboration—software engineers working closely with mechanical and electrical teams—is often hampered by rigid departmental boundaries.

Subscribe now

3. Leadership Challenges in Legacy OEMs

3.1 Lack of Technical Expertise at the Top

Many decision-makers in traditional automakers rose through ranks focused on mechanical engineering, manufacturing, or business administration. Software expertise is a relatively new requirement at the C-suite level, creating a leadership gap:

• Strategic Blind Spots: Without deep software backgrounds, leaders may underinvest in critical capabilities like cloud computing, cybersecurity, and AI-driven systems.

• Resource Allocation: Budgets could disproportionately favor physical infrastructure or legacy technologies over modern software platforms and developer tools.

3.2 Slow & Inflexible Decision-Making

Automotive giants often have hierarchical structures where decisions must be approved at multiple levels:

• Bureaucratic Delays: Approvals for new software features or architectural changes can take months, slowing the pace at which innovative ideas reach customers.

• Missed Market Opportunities: By the time an advanced feature rolls out, software-native rivals may have iterated two or three times, refining user experiences based on real-world data.

Share

4. Agility Concerns: Rigid Processes & Siloed Departments

4.1 Legacy Organizational Structures

Legacy OEMs typically manage separate divisions for powertrain, body and chassis, and electrical systems. Software is often considered an add-on to these core domains. While this structure worked well for mechanical engineering, it hinders integration in an era where software needs to be seamlessly embedded from day one.

• Complex Approval Chains: A software patch might require sign-offs from hardware, safety, legal, and branding teams.

• Insufficient Collaboration: Without cross-functional communication, software teams may lack critical insights into mechanical or electrical constraints.

4.2 The Cost of Siloes

Siloes inhibit shared learning and collaboration across departments:

• Duplicative Efforts: Different teams may develop overlapping software solutions, leading to inefficiency and inconsistent user experiences.

• Delayed Time-to-Market: Every step in the production pipeline faces bottlenecks, resulting in extended development cycles that prevent swift responses to market demands.

5. Technical Debt: Fragmented Architectures & Vehicle E/E Systems

5.1 Legacy Systems and Codebases

Many legacy carmakers rely on vehicle architectures with numerous ECUs—sometimes exceeding 100 per vehicle—each running specialized software for functions like transmission control, infotainment, or ADAS.

• Integration Hurdles: Getting these ECUs to communicate seamlessly and handle OTA updates is no small feat, especially when codebases were never designed for connected car features.

• Maintenance & Security Risks: Patching old systems can introduce new bugs or vulnerabilities, creating a growing backlog of technical debt.

5.2 Patching vs. Ground-Up Redesign

Rather than fully redesigning vehicles around centralized computing, many OEMs “duct tape” new functionality onto legacy platforms:

• Middleware Layers: Projects like Volkswagen’s Cariad or GM’s Ultifi attempt to unify disparate systems via a software layer, but it’s a workaround rather than a true rebuild.

• Performance Bottlenecks: Extra software layers can cause latency and degrade the real-time performance required for advanced autonomy or complex driver-assistance functions.

5.3 Overlooking Developer Experience

Legacy OEMs may focus on adding feature after feature (increasing lines of code) without investing in developer tooling, testing automation, and code quality:

• Complex Toolchains: A lack of modern DevOps practices slows down release cycles and reduces code quality.

• Talent Retention: Skilled software engineers often prefer companies with streamlined processes and modern tech stacks, making legacy OEMs less attractive to employers.

Share Vaisakh’s Blog

6. The Need for a Paradigm Shift: Ditching the Duct Tape

6.1 Lessons from Tesla, Rivian, BYD, Xiaomi, and Others

1. Centralized Computing: Tesla’s decision to house most vehicle intelligence on a central processing unit means simpler integration of new features.

2. OTA as a Core Capability: Rivian and Tesla demonstrate that continuous, seamless updates can delight users and refine vehicle performance.

3. Vertical Integration: BYD’s approach (from batteries to in-house software) reduces supplier dependency and accelerates innovation.

4. Rapid Iteration: Startups like NIO and Xiaomi rely on agile frameworks, enabling them to pivot faster than their legacy counterparts.

6.2 What Legacy OEMs Must Do to Truly Transition

• Organizational Redesign: Break down siloes, merge hardware and software teams, and adopt a product-focused rather than function-focused structure.

• Leadership Overhaul: Appoint leaders with strong software backgrounds, giving them the autonomy and budget to drive transformation.

• Invest in Centralized E/E Architectures: Embrace zonal architectures or single powerful CPUs to unify and simplify vehicle systems.

• Prioritize Developer Experience: Adopt modern DevOps practices, code quality checks, and agile workflows. This not only accelerates feature releases but attracts top engineering talent.

7. Conclusion: Who Will Survive the Transition?

7.1 Duct Tape vs. True Transformation

The metaphor of “duct taping” highlights how legacy OEMs are glueing new software elements onto outdated systems in an attempt to keep pace. While it may offer short-term fixes, it fails to address the root cause: a foundational mismatch between hardware-centric designs and the demands of modern software.

7.2 Market Dynamics and Potential Consolidation

As consumers increasingly value software capabilities—smart cockpit features, ADAS, and OTA updates—automakers that cannot pivot may lose market share to software-native rivals. Some possible outcomes:

• Consolidations: Struggling OEMs might merge to pool resources, or tech giants could acquire iconic brands for their manufacturing capabilities.

• Niche Survival: Certain legacy automakers might carve out specialized niches, focusing on performance or luxury while outsourcing critical software components.

7.3 Final Thoughts

The software will ultimately redefine the automotive world. While mechanical excellence remains crucial, it is no longer sufficient for leadership in a connected, autonomous future. Those who abandon duct tape fixes and embrace a ground-up, software-first paradigm stand the best chance of thriving.

8. References

1. Volkswagen's Software Delays and Leadership Changes

   • Volkswagen Delays Key EV Project as Tesla Challenge Stumbles. Bloomberg, November 17, 2022. Link

   • Porsches Postponed by Buggy Software Cost VW's CEO His Job. Bloomberg, July 25, 2022. Link

2. GM's Ultifi Platform

   • GM reveals 'Ultifi' platform in bid to become leader in software-led vehicles. CNBC, September 30, 2021. Link

3. Toyota's Investments in AI and Software

   • Toyota Invests $400 Million in Chinese Self-Driving Startup Pony.ai. Car and Driver, February 27, 2020. Link

   • Toyota's Technology Chief Lays Out a Path to Selling Millions of EVs. Bloomberg, June 12, 2023. Link

4. McKinsey on the Future of Automotive Software

   • Rewiring Car Electronics and Software Architecture for the 'Roaring 2020s'. McKinsey & Company, August 4, 2021. Link

   • The Big Shift: Moving Commercial Vehicle OEMs to Centralized E/E and Software. McKinsey & Company, September 23, 2024. Link

5. Tesla's Software-Defined Approach

   • Tesla can change so much with over-the-air updates that it's .... The Verge, June 2, 2018. Link

   • Tesla recalls 362,758 vehicles equipped with Full Self-Driving beta .... The Verge, February 16, 2023. Link

6. NIO's Advancements in Self-Driving Technology

   • Nio, Mobileye partner on self-driving consumer passenger cars in .... Reuters, November 5, 2019. Link

   • China's Nio launches smartphone developed to use with its electric .... Reuters, September 21, 2023. Link

7. Rivian's Software Strategy

   • 2025 Rivian R1T Concentrates on Inner Beauty. Car and Driver, June 15, 2024. Link

8. BYD's Integrated Battery-EV Approach

   • When Will America Get Its $25,000 Electric Car?. Bloomberg, June 17, 2024. Link

For decades, the automotive industry has been driven by a hardware-first approach, designing vehicles around mechanical and electrical systems before integrating software as an afterthought. However, the emergence of Software-Defined Vehicles (SDVs) demands a fundamental shift: thinking software first and hardware later. This evolution is not solely about new technologies; it requires a complete reimagining of how vehicles are conceptualized, built, and updated.

Rethinking Automotive Development: Software as the Starting Point

A software-first approach begins by defining a vehicle’s capabilities in terms of software architecture, connectivity, and intelligence. Rather than designing hardware first and then shoehorning software into it, forward-thinking automakers envision the user experience, services, and functionalities and then design hardware to support these software-driven goals.

How to Think Software First?

1. Define the Digital Experience First

A crucial initial step is to ask: What should the vehicle experience feel like for the end user? From the moment someone steps into the car, the software defines everything from the infotainment interface to personalized AI-driven cockpit settings. By establishing these digital touchpoints early, manufacturers can ensure that the hardware aligns with the user’s interactive journey.

Example: Tesla fundamentally rethought the cabin experience by centring it around a large touchscreen display. Instead of creating a dashboard and adding a screen later, they let software-driven design guide the interior layout. This approach not only looks modern but allows for feature-on-the-Fly updates that expand and refine infotainment and vehicle controls over time.

2. Prioritize Software Scalability Over Fixed Hardware Constraints

Traditional automotive development often locks in hardware choices at the start, limiting the scope of future software enhancements. In contrast, a software-first philosophy encourages hardware configurations that can be modified or upgraded via software. This flexibility allows vehicles to evolve after rolling off the production line.

Example: Xiaomi Auto’s software-defined parameters enable ongoing improvements to AI features without needing new physical components. By focusing on software scalability, they can continually refine everything from battery management to autonomous driving algorithms.

3. Leverage Cloud and AI for Continuous Development

Viewing the vehicle as a continuously evolving platform is central to software-first thinking. Rather than treating production as the final milestone, automakers can use cloud-based development pipelines and AI-driven analytics to update, enhance, and optimize vehicles long after they’re sold.

Example: NIO taps into real-world driving data to refine features in near real-time. Because their vehicles are connected to the cloud, they can deploy improvements swiftly, from improved battery performance to enhanced driver assistance capabilities.

4. Design Hardware to Serve Software Needs

In a software-first world, hardware becomes a facilitator rather than the focal point. Automakers should design modular computing platforms, reconfigurable sensor arrays, and flexible vehicle electronics to accommodate emerging software requirements.

Example: Tesla’s Full Self-Driving (FSD) capability is underpinned by a specialized neural network chip, developed to handle intensive AI workloads. As Tesla refines its autonomous algorithms through ongoing software enhancements, the hardware foundation remains robust enough to support increasing computational demands.

5. Build for API-Driven Interoperability

A software-first approach means extending the ecosystem beyond the car itself. By building API-driven interoperability, vehicles can seamlessly connect with mobile apps, cloud services, digital assistants, and third-party developers. This open architecture invites ongoing innovation, rather than locking features behind proprietary systems.

Example: Xiaomi Auto provides an open interface for smartphone integration, digital assistants, and ecosystem apps. This allows app developers to build on top of the in-car platform, delivering new functionalities that can be deployed to vehicles at any time.

6. Embrace CI/CD/CT for Faster Iteration and Quality Assurance

Implementing Continuous Integration (CI), Continuous Deployment (CD), and Continuous Testing (CT) is vital to ensure a swift and reliable software development lifecycle. CI streamlines the merging of code changes; CD manages rolling out new features via Feature-on-the-Fly updates; and CT automates testing to maintain quality across different vehicle models.

Example: Tesla’s deployment model relies on rigorous CI/CD pipelines, allowing them to rapidly address issues, add new features, and enhance safety without requiring extensive recalls or in-person visits. The result is a vehicle that grows smarter and more capable over its lifetime.

Share Vaisakh’s Blog

The New Competitive Advantage: Software-First Thinking

Companies clinging to a hardware-first perspective will find themselves at a disadvantage in a world increasingly governed by code. The defining characteristic of tomorrow’s vehicles will be their capacity to adapt, learn, and expand through software refinements. This shift fundamentally changes how value is perceived: horsepower and body styling matter, but intelligent software is what truly sets a modern car apart.

Moving Forward: Embracing Software-First Development

To thrive in this new era, automakers must rewire their approach:

• Start with the digital user experience and design hardware around it.

• Adopt cloud-native platforms and AI to drive ongoing vehicle improvements.

• Invest in flexible hardware architectures that can accommodate future demands.

• Implement CI/CD/CT pipelines for robust, high-velocity software releases.

By prioritizing software-first, hardware-later, automotive manufacturers can ensure their vehicles remain cutting-edge long after they leave the factory. Ultimately, this philosophy will shape the evolution of mobility, transforming cars into continually evolving digital platforms capable of meeting—and exceeding—drivers’ changing expectations.

References:

• Tesla Software-Defined Vehicle Approach: https://www.tesla.com/software-updates

• Xiaomi Auto and Software-Defined Vehicles: https://www.xiaomi.com/auto/software-platform

• NIO Cloud-Connected Vehicles: https://www.nio.com/smart-cloud

• CI/CD/CT in Automotive Software Development: https://www.redhat.com/en/topics/devops/what-is-ci-cd

• Software-Defined Vehicle Trends: https://www.automotiveworld.com/articles/the-rise-of-software-defined-vehicles

1. Introduction

Earlier, we asked the all-important question posed by Sandy Munro—“Why isn’t Tesla selling its software stack to other OEMs?” The short answer: Tesla’s software is so tightly integrated with its own hardware ecosystem that splitting them apart would be like trying to surgically remove a car’s brain and transplant it into a different body. It’s not just about code; it’s about the holistic synergy of sensors, controllers, networks, and even developer tools that Tesla has built from scratch.

Tesla’s dedication to vertical integration means every bolt, wire, chip, and line of code is optimized to work together in harmony. By keeping software development in-house, Tesla ensures:

• Faster iteration and feature rollout.

• Seamless Over-The-Air (OTA) updates.

• A consistent, Tesla-first user experience.

In other words, offering Tesla’s cutting-edge software to another OEM might be as jarring as playing a Nintendo cartridge on an Xbox—fascinating in theory, but nearly impossible in practice.

2. What Has Changed from Pre-Cybertruck to Cybertruck?

From its early Model S and Model X days to the futuristic Cybertruck, Tesla has hinted at or directly revealed significant upgrades to its electronics architecture. Here are some of the big ones:

1. 48V Architecture – Moving away from traditional 12V to a more robust 48V system. (Widely discussed at Investor Day.)

2. EtherLoop – A unique twist on automotive Ethernet, aiming for high-speed, low-latency communication.

3. Wiring System Upgrades – Fewer, thinner, and more efficient wires.

4. Zonal Architecture – Localizing electronic control to different “zones” of the vehicle.

5. 85% In-House Controllers – Eliminating third-party dependencies, maximizing synergy.

These changes serve as the technological backbone of the Cybertruck, ensuring it’s as durable inside as it appears on the outside. While final production details may vary, Tesla’s overall direction is consistently moving towards tighter hardware-software integration and more efficient electrical systems.

3. Let’s Deep Dive into Each Topic

3.1. The 48V System: A Powerhouse Upgrade

Why 48V?

• Reduced Current, Less Heat: Higher voltage means lower current for the same power, lowering heat generation and the risk of wire meltdown (not a fun scenario!).

• Better Efficiency & Weight Savings: Thinner wires can carry the same power, cutting down on weight and boosting range.

• Future-Proof for High-Power Demands: Think advanced computing systems, smart sensors, or possibly other high-power accessories Tesla might integrate.

Trivia: Going from 12V to 48V is like switching from a foot pump to an electric air compressor. Both accomplish the same task, but one does it way faster and more efficiently.

3.2. EtherLoop: The Next Generation of In-Car Communication

What Is EtherLoop?
“EtherLoop” is a term being used by the EV community (including teardown experts like Sandy Munro) to describe Tesla’s evolving automotive Ethernet approach. Traditional automotive communication buses (like CAN) are robust but can be bandwidth-limited. By leveraging an Ethernet-based solution, Tesla aims for higher data throughput and lower latency.

Key Advantages

1. High Bandwidth & Real-Time Data: Autopilot systems, cameras, and sensors can transmit and receive large volumes of data without major bottlenecks.

2. Reduced Latency: Crucial for active safety features and real-time sensor fusion.

3. Improved Debug-Ability: EtherLoop allows deeper diagnostics and faster fault isolation through the single interface. This makes software iteration and real-time troubleshooting much more efficient. Conventionally we need to connect different interfaces (different CAN buses) & time-sync data outside.

Active Road-Noise Cancellation on EtherLoop—What’s the Big Deal?
Picture this: in-cabin noise data from multiple sensors and microphones is captured, then instantaneously sent to a central processor to generate “anti-noise” signals. That information has to loop back to the speakers or actuators just as quickly—all in real time. By leveraging EtherLoop’s high-speed, bi-directional automotive Ethernet design, Tesla can achieve the bandwidth and redundancy needed to ensure data zips back and forth without delays or choke points.

In contrast, traditional automotive buses often lack the speed or capacity for such rapid data exchange, forcing automakers to use specialized hardware (like serializers and deserializers). This not only adds cost and complexity, but also creates more potential failure points. With EtherLoop, Tesla integrates Audio routing directly into its core network architecture, minimizing hardware overhead and delivering a more robust, future-proof solution.

Trivia: Think of a typical automotive data bus like you and your friend talking through paper cups connected by string; EtherLoop is more like FaceTiming on 5G—snappy, flexible, and built for modern demands.

3.3. Wiring System Upgrades

Gone are the days of bulky wiring harnesses snaking around like spaghetti. With a zonal architecture and a 48V backbone, Tesla is expected to reduce wiring length, saving both weight and manufacturing complexity. Each zone of the vehicle (front, mid, rear) would have localized control modules that communicate via EtherLoop, reducing both the thickness and the quantity of wires required.

3.4. Zonal Architecture

Why Zonal?

• Modularity: Upgrades become simpler. Need to swap a sensor in the front zone? Replace just that module or harness.

• Reduced Latency: Data doesn’t have to travel back and forth across the entire car.

Tesla’s approach to zonal architecture streamlines both production and service. It reduces potential failure points, simplifies diagnostics, and can speed up the manufacturing process by assembling the car in distinct “zonal” phases.

3.5. 85% In-House Controllers

If you can own your supply chain, you can own your destiny. By bringing nearly all controllers in-house, Tesla eliminates the typical back-and-forth with external suppliers. This close integration means:

• Over-the-air updates for everything: From your infotainment system to your seat control modules.

• Faster innovation cycles: There’s no middleman in the feedback loop.

• Uniform software style: Across all controllers, reducing software bloat and anomalies.

Share Vaisakh’s Blog

4. Conclusion: The Vertical Integration Masterstroke

The Cybertruck is more than just a rolling slab of stainless steel; it’s a testament to how deeply Tesla integrates its hardware and software. By overhauling the electric system to 48V, introducing the EtherLoop network, and consolidating control under a zonal architecture, Tesla continues to tighten its hold over every facet of the automotive experience.

It’s not that Tesla won’t sell its software to other OEMs—it’s that no other OEM’s hardware is truly prepared for Tesla’s level of integration. It’s akin to trying to run macOS seamlessly on a random PC—it might be theoretically possible but requires an immense amount of custom engineering to make it work flawlessly.

Meanwhile, Tesla’s “software first” philosophy shapes both the product and the ecosystem it is building. From developer tools to over-the-air updates, the entire platform is treated like a living, updatable computer system on wheels. In future blogs, we’ll delve deeper into Software-first, platform and ecosystem approach—so stay tuned!

5. Learnings for Legacy OEMs

1. Prioritize In-House Development: Controlling core systems often yields better agility and innovation.

2. Focus on Synergy: Hardware-software integration ensures a cohesive user experience and faster deployment of new features.

3. Embrace Modular Zonal Designs: Easier maintenance, fewer parts, simpler manufacturing.

4. Adopt a Software-First Mindset: By building a robust ecosystem, OEMs can keep vehicles future-ready and competitive.

5. Streamline Wiring: A higher voltage system and a more centralized network can help eliminate “spaghetti wiring.”

If traditional carmakers take these strategies to heart, they may keep up with Tesla—without feeling like they’re constantly in catch-up mode.

Subscribe now

6. References & Further Reading

1. Digging Deeper on Tesla's Etherloop Wiring System by The Limiting Factor: In-Depth Look at Automotive Architecture (YouTube)

2. Tesla Cybertruck DEEP DIVE with 5 Tesla Executives! by Munro Live: Tesla’s Electronics Evolution (YouTube)

3. Tesla Investor Day 2023 – Event Recording & Slides

4. IEEE Spectrum on Automotive Ethernet – “Automotive Ethernet: The Road to Fast, Secure In-Car Networks”

5. Original Post Inspiration – Inside Tesla’s Brain: Before Cybertruck

Disclaimer: Specific technical details like “EtherLoop” naming, “85% in-house controllers,” and the exact 48V implementation come from Tesla investor presentations, industry teardown analyses, and public speculation. Tesla’s final production versions may have variations.

1. Introduction

Tesla's electronic and electrical (E/E) architecture represents a paradigm shift in automotive technology. By centralizing vehicle computing, Tesla has achieved unparalleled performance, scalability, and cost-effectiveness. Tesla's innovations in Full Self-Driving (FSD) hardware and MCU (Media Control Unit) computing exemplify its approach to software-defined vehicles. These advancements not only enhance vehicle capabilities but also give Tesla a strategic edge, enabling over-the-air updates, rapid iteration, and streamlined production processes.

2. Benefits of Tesla's Architecture and FSD Hardware

Tesla's centralized architecture, embodied in FSD Hardware 4 (HW4), offers numerous advantages:

• Strategic Superiority:
  Tesla's architecture allows for rapid feature deployment and bug fixes through over-the-air updates, reducing recall costs and improving customer satisfaction. The vertical integration of hardware and software creates a seamless ecosystem that is difficult for competitors to replicate.

• Technical Advantages:

  • Centralized High-Performance Computing: Tesla consolidates functions into fewer, more powerful chips, reducing complexity and improving reliability.

  • Reduced ECU Count: Compared to legacy automakers, Tesla uses significantly fewer ECUs, as highlighted in a comparison between the Model Y and competitors like the VW ID.4 and Ford Mach E.

  • Optimized Communication: The adoption of high-speed Ethernet and BroadR-Reach networks enhances data transfer rates and reduces latency.

  • Advanced Safety Systems: The integration of safety-critical systems ensures compliance with ASIL-D standards, safeguarding against failures.

3. Challenges Faced by Legacy Automakers

Legacy automakers often rely on domain-oriented E/E architectures with multiple specialized ECUs, leading to:

• Complexity and Scalability Issues: These architectures struggle to support modern features like ADAS and high-bandwidth infotainment.

• Dependency on Tier-1 Suppliers: This results in slower innovation cycles and fragmented software ecosystems.

• Missed Opportunities for Centralization: Unlike Tesla, these manufacturers retain legacy ECUs, perpetuating inefficiencies and higher costs.

Tesla's centralized approach illustrates the benefits of starting from scratch. Legacy manufacturers must overcome entrenched practices and adopt zone-oriented architectures or risk falling further behind.

Subscribe now

Share Vaisakh’s Blog

Note: The image of Tesla's hardware architecture presented in this blog is a conceptual representation generated using multiple inputs and sources. While every effort has been made to ensure accuracy, it may include approximations or errors due to the speculative nature of some details.

4. Tesla's HW4 Architecture Explained

Tesla's HW4 architecture integrates the following key components:

• FSD Computer:

  • Dual SoCs: Exynos ARM Cortex-A72 paired with SoC 2 and SoC 3(optional) ensure high redundancy and computing power.

  • Safety Systems: A dedicated safety system isolates critical functions, enhancing reliability.

  • Camera Inputs: Utilizing FPD-Link technology, Tesla connects multiple cameras for its full self-driving capabilities.

• MCU Computer:

  • AMD Ryzen Processor: Provides robust processing power for infotainment and vehicle controls.

  • Radeon GPU: Ensures high-quality graphics for displays.

• Communication Networks:

  • High-speed Ethernet links facilitate communication between the FSD computer, gateway, motor controller, and ECUs.

  • CAN and LIN protocols are retained for compatibility with legacy subsystems.

• Modem Integration:

  • A 4G modem, GNSS module, and eSIM enable seamless connectivity for vehicle-to-cloud communication.

This architecture underscores Tesla's emphasis on scalability, reliability, and future-proofing through centralization and high-speed networking.

5. Lessons for Legacy Automakers

Legacy automakers can learn from Tesla's approach by:

• Reducing ECU Count: Consolidating functions into fewer, more powerful controllers.

• Adopting Modern Networks: Transitioning to Ethernet-based communication for faster and more reliable data transfer.

• Embracing Software-Defined Architectures: Building flexible systems capable of over-the-air updates and modular software upgrades.

• Focusing on Vertical Integration: Developing in-house expertise in hardware and software to reduce reliance on suppliers.

Volkswagen's investment in Rivian (earlier in the software development division CARID) and Ford's restructuring efforts indicate a recognition of these imperatives, but significant challenges remain.

6. Conclusion and Future Topics

Tesla's HW4 architecture demonstrates the benefits of centralized computing, reduced complexity, and high-performance networking. While legacy automakers face challenges in transitioning to such architectures, Tesla's approach serves as a roadmap for modernization.

In an upcoming blog, discussions will explore Tesla's 48V Etherloop system and its post-CyberTruck advancements in vertical integration.

7. References

1. Munro, S. et al., "Comparing Tesla, Ford, & VW's Electrical Architectures," 3IS Inc., YouTube.

2. Tesla Autopilot Hardware, Wikipedia, Link.

3. NotATeslaApp, "Tesla’s Hardware 4: Unraveling the Mystery Behind the Most Advanced FSD Computer," Link.

4. "Methodical Approach for Centralization Evaluation of Modern Automotive E/E Architectures," Lucas Mauser et al., PDF.

Your Happy Place, Wherever You Go

The Sierra EV promises freedom — freedom to roam, freedom to connect, and freedom to make every journey your own. Built on the foundation of “Human Experience”, this car embraces you with plush interiors that exude warmth and comfort. The timeless design, with its taut surfacing and muscular proportions, radiates an adventurous spirit that appeals across generations. Whether it's a family weekend escape or a solitary adventure into the wilderness, the Sierra EV is about transforming journeys into moments that resonate with your essence.

Design That Speaks to Your Soul

With its "Empowered White" colour, blistered wheel arches, and a modern, wide stance, the Sierra EV has a presence that is both sophisticated and rugged. The front of the vehicle, with its full-width slim LED Daytime Running Lights (DRL), hints at the future, showcasing cutting-edge technology while maintaining a sense of simplicity and elegance. At the rear, the clamshell tailgate offers easy access, while the uninterrupted taillight emphasizes the car’s cohesive and bold design.

Inside, Tata Motors has pushed the envelope of personalization. Despite its compact exterior dimensions, the Sierra’s interior is surprisingly spacious, thanks to the horizontal design theme and layered aesthetics. Panoramic glazing floods the cabin with natural light, turning it into a bright, energizing space — a true haven that allows passengers to enjoy nature without compromise. Lounge-style rear seats add to the sense of luxury, providing more legroom than you would expect from a car of this size, along with business-class-style reclining for ultimate relaxation.

Designed for Connection and Comfort

The Sierra EV is all about seamless interaction — between the driver, the passengers, and the car itself. The steering wheel embodies this vision with its digital DNA, featuring an illuminated logo and minimalistic controls that let you interact effortlessly. Smart technology is embedded throughout, but it’s never intrusive — the focus is always on providing a clean, clutter-free driving experience. The connected technology elevates inclusiveness, helping everyone on board feel truly at home, and allowing drivers to stay informed without being overwhelmed.

Whether it's the signature panoramic sunroof that creates a sense of open space or the precise craftsmanship that offers warmth and versatility, the Sierra EV aims to connect with you on an emotional level. Every detail has been thought through to ensure that your experience in the Sierra goes beyond transportation — it's about creating memories, capturing the essence of your lifestyle and turning the journey into part of the adventure.

Make Every Drive Uniquely Yours

The Tata Sierra EV is a celebration of life on the move — a space designed around you, for you. It’s where the technology serves the human experience, not vice versa. It's where the line between comfort and adventure blurs, and every journey becomes an expression of who you are. Tata Motors has reimagined personalization, placing human experience at the core, with connected personalization features that seamlessly adapt to individual preferences. Imagine entering your Sierra EV and having the cabin temperature, seat position, and ambient lighting adjust automatically to your liking. The infotainment system recognizes your favourite playlists and offers suggestions based on your recent mood. Even the navigation system can propose routes tailored to your driving habits, whether you prefer scenic views or the quickest path. Personalized profiles allow each family member to experience unique journeys, ensuring the Sierra EV feels just right for everyone, every time. Happy Place..!

Disclaimer: The above content represents a personal opinion.

Buckle up, gearheads, because the automobile is undergoing a revolutionary transformation. We're not talking about sleek new designs or fuel-efficient engines – we're hurtling towards a future where your car is as much software as steel. Enter the realm of Software Defined Vehicles (SDVs), where lines blur between hardware and digital magic.

From Tin Cans to Tech Wizards: The Evolution of Automobiles

For decades, cars were intricate tangles of mechanics and combustion engines. Think gears, pistons, and carburettors – a symphony of physical parts choreographed by the driver. The "evolution" meant bigger engines, smoother transmissions, and maybe a fancy stereo.

But the winds of change are whipping through the industry. Electronics gradually infiltrated, bringing fuel injection, anti-lock brakes, and rudimentary infotainment systems. This was the first tremor, hinting at a seismic shift to come.

Then came the computer revolution. Engines learned to think, adjusting fuel mixtures on the fly. Sensors sprouted like nervous system tendrils, feeding data to onboard computers that monitored everything from emissions to tyre pressure. Driver assistance systems emerged, nudging us towards a future where the car becomes an intelligent partner.

This is where we stand today, at the crossroads of mechanical marvel and digital playground. We're witnessing the birth of SDVs – vehicles where software takes the wheel, transforming them from mere modes of transportation into customizable, connected, and potentially autonomous companions.

The Evolution of the Connected Car: From Hardware Haven to Software Hub

Imagine viewing a car not just as a machine, but as a platform for continuous improvement. This is the essence of the Software-Defined Vehicle (SDV) concept. A recent report by SBD analyzes this evolution through four distinct stages, offering a fascinating glimpse into the future of automobiles.

Vehicle 1.0: The Hardware Haven

Think of the classic car - a mechanical marvel, but with limited electronic control. Features are entirely dependent on the physical hardware, offering little room for updates or customization.

Vehicle 2.0: The Digital Dawn

This stage ushers in the era of infotainment systems and connectivity. Cars become smarter, offering features like navigation and hands-free calling, often connected through 2G or 4G networks. In India, a large portion of vehicles fall into this category, boasting infotainment systems compatible with smartphone mirroring technologies like Android Auto or Apple CarPlay.

Vehicle 3.0: The Updatable (Vehicle 2.5 in India)

Luxury car segments in India are leading the charge towards a slightly more advanced stage. Here, we see the introduction of driver-assistance systems (ADAS) reaching up to SAE Level 2 in some cases. Large infotainment screens become commonplace, capable of running a wider variety of applications and connecting directly to the internet.

However, this stage also highlights the challenges faced by the Indian automotive ecosystem in adopting cutting-edge technologies. For instance, the development of in-house software by Original Equipment Manufacturers (OEMs) and the implementation of domain-specific middleware are still in their early stages. Transitioning to these advancements requires significant investment and a shift in traditional OEM work practices. Developing the necessary skillsets and organizational structures is critical for success. Essentially, moving from a hardware-focused mindset to a software-centric approach, similar to a tech startup, is key.

Vehicle 4.0: The Software Superstar

This stage represents the pinnacle of software-driven value creation. Hardware components become standardized, offering less opportunity for differentiation among OEMs. A good example is suspension tuning, which was once a key area of competition. Today, advancements have led to robust suspension systems across most manufacturers. The true differentiator in Vehicle 4.0 vehicles lies in the software. These Software-Defined Vehicles are paving the way for a new era, led by innovative carmakers like Tesla, BYD, and NIO. Traditional OEMs are racing to catch up, with initiatives like the Volkswagen Group's CARIAD, Ford's investments in software development, and GM's partnerships aimed at building an SDV ecosystem. Further disrupting the landscape are companies like Xiaomi, leveraging their mobile phone and software expertise to enter the car manufacturing space and offer customers cost-effective, technologically advanced vehicles.

The automotive industry is on the cusp of a revolutionary shift. As software takes the wheel, vehicles transform from mere machines into dynamic platforms with the potential for continuous improvement and personalization. Buckle up - the future of driving is about to get exciting!

References:

1. The Software-defined Vehicle report.pdf (sbdautomotive.com)

2. SDV Forecast Research Report (sbdautomotive.com)

This blog is edited with the support of Google Gemini.

Move over, horsepower and chrome! The future of vehicles is paved with lines of code, and the buzzword on everyone's lips is "Software Defined Vehicle" (SDV). But what exactly is an SDV, and how does it differ from the shiny machines we're used to? Buckle up, gearheads, because we're about to take a deep dive into the world of software-powered automobiles.

Defining SDV is a challenge, there are a ton of definitions we can find over the internet. It could be a better approach to talk about SDV characteristics or SDV tech stack, both of them are relatively easy to establish. However, let’s try to create a point of view on the definition of SDV in this blog.

Decoding the Definitions:

There's no single, universally accepted definition of an SDV, but at its core, it refers to a vehicle where software takes the driver's seat. Instead of relying on clunky hardware upgrades, SDVs evolve and improve through software updates, just like your smartphone.

Some definitions emphasize:

• Decoupling hardware and software: Imagine a car where the engine and sensors are one platform, and the driving features, entertainment, and safety systems are a separate, upgradable software layer. That's the SDV dream!

• Continuous evolution: New features and functionalities can be downloaded and installed wirelessly, keeping your car perpetually at the cutting edge. Think self-driving updates, enhanced driver assistance, or even personalized driving profiles via app downloads.

• Connected intelligence: SDVs are woven into the fabric of the smart city, exchanging data with other vehicles, infrastructure, and even pedestrians. Picture your car seamlessly navigating traffic jams or anticipating hazards before you even see them.

More than just fancy software:

So, an SDV isn't just a car with a better infotainment system. It's about unlocking a Pandora's box of possibilities:

• Enhanced safety: Software can refine driver assist features and even take over in critical situations, reducing accidents and saving lives.

• Personalized driving: Imagine a car that adjusts its handling, suspension, and even interior ambience to your preferences. It's like having a personal co-pilot who reads your every mood.

• New business models: Say goodbye to the "buy-and-forget" mentality. SDVs open doors for pay-per-use features, subscription-based upgrades, and even vehicle-sharing models, completely redefining car ownership.

The road ahead:

The SDV revolution is still in its early stages, but the potential is undeniable. While challenges like cybersecurity and infrastructure development remain, the future of the automobile is undeniably software-driven. So, whether you're a tech enthusiast or just a curious driver, keep your eyes peeled for the "SDV" badge – it's the roadmap to a smarter, safer, and more exhilarating driving experience.

References:

1. The Software-defined Vehicle report.pdf (sbdautomotive.com)

2. Rewriting the Rules of Software-Defined Vehicles (BCG)

3. Bosch software-defined vehicle (bosch-mobility.com)

4. Software-Defined Vehicles, Connected Cars, and AI in Cars 2024-2034: Markets, Trends, and Forecasts (IDTechEx)

5. For SDVs, Software Is The Biggest Challenge (semiengineering.com)

This blog is edited with the support of ChatGPT & Bard.