Software-Defined Vehicles: Can India Turn Its Software Strength into Automotive Advantage?

Tesla and BYD have already changed what a car can become after it leaves the factory. For India, the Software-Defined Vehicle is more than another technology trend. It could be a strategic opportunity.

Imagine buying a car today and receiving, six months later, a feature that did not exist when the vehicle left the factory. No workshop visit. No new ECU. No rewiring. Just software.

Over-the-air (OTA) updates are not new. Head units and telematics boxes have had them for over a decade. What is new is their reach. In most cars, OTA stopped mainly at the infotainment screen or urgent bug fixes. The functions that define the vehicle (driving, energy, chassis, body) were frozen at Start of Production (SOP) and changed only in a workshop.

Tesla broke that boundary with the 2012 Model S; its owners have lived with whole-vehicle updates since. BYD is taking a different but equally important route: its e-Platform 3.0 consolidates electronics into domain controllers running BYD OS, which decouples hardware from software. Its XUANJI architecture goes further, integrating electrification and intelligence across the whole vehicle.

That is the real distinction. A connected car can be updated, while a software-defined car can radically change its core functions. And India has good reasons to care.

What makes a vehicle “software-defined”?

Cars have run software for decades. A modern car may carry dozens of electronic control units (ECUs), more than a hundred in premium models. However, that alone does not make it a Software-Defined Vehicle (SDV).

In a traditional architecture, software is bound to dedicated hardware. The brake supplier delivers a brake ECU, another delivers the body controller, and a third supplies infotainment. Each box has its own processor, software, signal interfaces, and release cycle, and the CAN signal matrix linking them is frozen at SOP. A function spanning three ECUs means three supplier releases and, usually, a workshop visit.

An SDV breaks the “one function, one box” logic in three ways (see Figure 1).

• Hardware consolidates. First into domain controllers, then into zonal architectures: zone controllers aggregate local sensors, actuators and power distribution, while one or two high-performance computers (HPCs) run the functions, connected over Automotive Ethernet (IEEE 802.3bw/ch).

• Software abstracts. A hypervisor partitions the HPC, service-oriented middleware such as AUTOSAR Adaptive (SOME/IP, DDS) exposes vehicle capabilities as services, and a common data model such as COVESA’s Vehicle Signal Specification lets an application request “vehicle speed” without knowing which ECU provides it. Eclipse SDV aims to make these layers open rather than proprietary.

• The loop closes after production. Connectivity, OTA, and vehicle data feed the next release, under the software update management system that UN R156 makes a condition of type approval.

Figure 1-A. From the early distributed ECUs to the new Zonal/Central compute. The SDV transition is not simply “fewer ECUs”: it separates software from dedicated hardware and moves toward shared compute and common software platforms.

Figure 1-B. Zonal/Central EE Architecture

Tesla proved the vehicle can keep evolving

Tesla’s importance to SDV is not the touchscreen. It is the product lifecycle. The traditional model was roughly: Develop → Manufacture → Sell → Service

The SDV adds a permanent loop:

Develop → Manufacture → Sell → Collect data → Update → Improve → Repeat

SOP is no longer the end of development. A Tesla delivered five years ago does not have the feature set it left the factory with. This is what the customers now expect.

Figure 2. Tesla made continuous improvement through OTA updates a normal customer expectation.

BYD shows the architectural side

BYD illustrates the other half of the shift: which is not the update itself, but the architecture that makes updating cheap. e-Platform 3.0 runs cockpit and body domain controllers on BYD OS, presented as the foundation for continuously evolving vehicle intelligence.

XUANJI goes further than that. BYD describes it as both the “brain” and the “neural network” of the vehicle: consolidating information for central decision-making and applying AI across more than 300 vehicle scenarios, at BYD’s volumes, millions of vehicles a year.

The lesson is that the competition is moving from individual ECUs to the whole-vehicle software architecture, industrialised at scale.

Figure 3. BYD’s XUANJI strategy illustrates the shift from isolated electronic domains toward integrated whole-vehicle intelligence.

India is already moving

India is not starting from zero.

Mahindra calls MAIA, its AI architecture, the foundation of its SDV vision. When it launched the BE 6 SPORTEQ in August 2026, it committed to rolling new software features out to existing BE 6, XEV 9e and XEV 9S owners through phased OTA updates from January 2027.

Tata Motors’ Sierra EV pairs its N.IO SDV platform with built-in 5G through Tata Communications’ MOVE platform: which enables faster OTA updates, real-time remote diagnostics, and provides a backbone for AI-enabled applications.

Ather shows why SDV should not be seen only through the lens of premium cars. Its AtherStack platform has delivered new functions to electric scooters over the air, including interface upgrades, safety features, and voice interaction.

The Ather example proves that India’s SDV opportunity is different.

Why India should think “Frugal SDV”

EVreporter counted more than 2.36 million EV sales in India in 2025 (8.36% of all vehicle sales), and electric two-wheelers made up more than half of them. This market structure changes the economics.

A premium SUV can absorb a large SoC (a single chip that packs processor, graphics, and AI accelerators together), gigabit Ethernet, and redundant compute. A mass-market scooter or three-wheeler cannot: its entire electronics budget is a fraction of a premium cockpit.

What does SDV look like at ₹1 lakh instead of ₹25 lakh? We are not looking for a smaller Tesla, but a different design approach which entails:

• Right-sized compute: one capable microcontroller or entry-level SoC, not a 500-TOPS processor.

• Secure, recoverable updates: secure boot, A/B partitions and rollback protection, as specified by Uptane and ISO 24089.

• One vehicle API across the range, so an application written for the scooter also runs on the three-wheeler and the fleet van.

• A BMS that reports cell-level telemetry to the cloud enables battery-health analytics, warranty management, second-life valuation, and fleet uptime for optimal commercial operations.

• A cloud backend built for volume enabling onboarding, diagnostics, update campaigns, fleet services.

In a nutshell, Frugal SDV needs to offer enough computing, connectivity, cybersecurity and software abstraction to enable OTA updates, remote diagnostics, battery intelligence and continuous improvement, without importing the cost structure of a luxury vehicle. This is where India has an advantage.

NASSCOM puts the country’s technology workforce at roughly 5.8 million people in FY2025. India already writes embedded and automotive software for most of the world’s OEMs and Tier-1s through its engineering-services ecosystem. But writing code for someone else’s architecture is the low-margin end of SDV. The real opportunity is to move up the value chain i.e. FROM supplying software components TO owning platforms, middleware, APIs, integration, and intellectual property.

The hard part: who owns the integration layer?

SDV looks simpler on a slide than inside a vehicle.

Suppose three ECUs disappear and their software moves onto one HPC. Suppliers A, B, and C each used to own their hardware and software. Now their code shares one processor, memory, network and operating environment. One question becomes critical (Figure 2):

Figure 4. The shared-compute challenge. Centralising hardware reduces boxes and wiring BUT moves the complexity into software integration.

• Mixed criticality. ASIL-rated vehicle control may share silicon with QM infotainment. Freedom from interference (hypervisor, memory protection, time partitioning) has to be demonstrated under ISO 26262-6.

• Shared resources. CPU, GPU, NPU, memory, Ethernet bandwidth and thermal headroom are finite. No function may starve another, and the budget must hold for every future release.

• Interfaces. If every supplier brings proprietary APIs and data definitions, centralisation simply creates a bigger integration problem in one box.

• Release management. Supplier A updates today, Supplier B next month. Compatibility, dependencies, configuration control, rollback and OTA validation become vehicle-level responsibilities, and under UN R156 and its RxSWIN traceability, type-approval responsibilities.

• Cybersecurity. More connectivity and remote update capability mean a larger attack surface. UN R155 and ISO/SAE 21434 demand a managed process, not a one-time audit. India is laying its own rails: AIS-189 and AIS-190, adapted from R155 and R156, are in the pipeline.

• Validation. Frequent releases make manual vehicle testing impossible to scale. Software-in-the-loop, hardware-in-the-loop, virtual ECUs, automated regression and CI/CD stop being nice-to-have.

Reducing the number of ECUs does not reduce complexity. It moves complexity from hardware and wiring into software and integration.

Ultimately, the OEM owns that problem. It can outsource code, not responsibility for how the complete vehicle behaves. That’s why every serious SDV player is building an in-house software organisation owning architecture, APIs, integration and the release pipeline.

That is also what India’s engineering base could grow into (Figure 5).

Figure 5. India’s SDV opportunity: converting software scale into ownership of higher-value SDV layers.

The opportunity is bigger than developing a cheaper Tesla

The SDV race will be won by companies that can change vehicle functions quickly while keeping the whole system safe, secure, affordable and maintainable, release after release.

Tesla showed the value of continuous evolution. BYD is industrialising hardware (software decoupling at enormous scale). Mahindra, Tata, and Ather show the transition is underway in India.

India now faces a choice. It can remain one of the world’s great sources of automotive software talent, or use that base to own more of the layers that define the vehicle itself. The most interesting Indian SDV may therefore not be a cheaper copy of a premium American or Chinese car. It could be something the world needs: a secure, updateable, cost-efficient software platform that scales from scooter to three-wheeler, passenger EV and commercial fleet. If we solve that, and India will not simply participate in the SDV transition: It could define the software architecture for the next billion mobility users.

About the author

The article is authored by Mamadou Moustapha Ndoye, Consultant – Automotive Technology, Radical Enertech, who brings 25+ years of global automotive engineering experience across VinFast, Stellantis and PSA, with expertise in E/E architecture, EV systems, functional safety and design-to-cost.

Radical Enertech is a technology and techno-commercial consulting firm focused on sustainable energy and mobility, with expertise across EV charging, BESS, renewable energy, smart energy systems and emerging mobility technologies.

Also read: Software-defined vehicles and vehicle configuration management