Q1. Could you start by giving us a brief overview of your professional background, particularly focusing on your expertise in the industry?

I have over two decades of experience across automotive electronics, embedded systems, infotainment, E/E architectures, and Software-Defined Vehicle (SDV) platforms. Over the years, I have worked across OEM, Tier-1, and consulting environments, focusing on the intersection of vehicle architecture, software platforms, connected services, and system integration.

A significant part of my work has focused on next-generation E/E architectures, the Android Automotive OS (AAOS), centralized compute platforms, and the evolution from domain-centric to zonal and software-centric vehicle architectures. More recently, my focus has expanded toward AI integration in vehicles, orchestration of distributed intelligence across edge and cloud systems, lifecycle management of AI-enabled vehicle functions, and the operational realities of scaling SDV platforms.

In addition to my industry role, I also work through DPE Labs, where I focus on architecture advisory, embedded systems strategy, and emerging SDV and AI-related topics. My interest rests not only in the technical implementation of these systems, but also in the larger architectural, operational, and lifecycle implications that OEMs and suppliers are beginning to face as vehicles grow increasingly software- and AI-driven.

 

Q2. Many legacy vehicle platforms currently on the road are marketed as 'Software-Defined' but are structurally 'SDV-Lite'. When an OEM tries to scale up a fleet-wide feature rollout over these transitional systems, what unforeseen lifecycle maintenance costs emerge?

Many of today’s vehicle platforms are in a state of transition. While they now support over-the-air updates and software-driven features, they remain limited by legacy E/E architectures that were never intended to handle continuous, fleet-wide software changes.

The highest hidden cost isn’t launching new features but managing fragmented vehicle fleets over time. OEMs soon realize that a mix of hardware versions, supplier-specific middleware, regional software setups, regulatory requirements, and varying computing power combine to create a complex validation challenge.

As vehicle features become more complex, maintaining software is no longer solely individual ECUs—it becomes a wider challenge of coordinating the entire platform. Even minor updates can require thorough checks across infotainment, driver assistance, connectivity, energy systems, and cloud interactions.

Coordinating updates between vehicle software, backend systems, AI, cybersecurity, and app ecosystems is another challenge that’s often overlooked. On many SDV-Lite platforms, these parts were developed separately and were never designed to work together as a single, unified system.

This leads to a long-term maintenance burden, where engineering teams spend considerable resources on compatibility management, rollback procedures, feature gating, and handling regional deployment exceptions, rather than focusing on new customer-facing innovations.

 

Q3. With central compute architectures collapsing multiple domain controllers into 3nm system-on-chips (SoCs), OEMs are facing extreme vendor lock-in. What are some steps that can be taken to mitigate such situations?

Centralized compute architectures bring clear advantages: greater compute power, reduced wiring, smoother coordination across domains, and easier software deployment. But this approach also means OEMs become more reliant on a handful of semiconductor and platform suppliers.

To avoid vendor lock-in, it’s important to keep application software separate from hardware-specific components. If vehicle functions depend too much on a vendor’s proprietary tools, it can make future software changes and migrations much more complicated.

Owning the platform middleware, APIs, and orchestration layers is also critical. Control over the software integration layer above the silicon determines both the pace of innovation and the flexibility to migrate in the future.

OEMs should be wary of chasing only short-term benchmark wins. While vendor-specific optimizations can provide fast results, they often make future system migrations much more expensive and difficult.

It’s just as important for organizations to protect their own architectural know-how. Even if development is outsourced or built on external platforms, OEMs must retain enough internal expertise to weigh trade-offs, keep leverage in negotiations, and avoid becoming dependent on a single technology ecosystem.

The industry is clearly shifting toward a future where the ability to move and update software easily will matter as much as raw computing power.

Q4. The market shift in 2026 has seen a surge in demand for Extended Range Electric Vehicles (EREVs) with small on-board generators. From an architectural perspective, how easily can a software stack and power-management framework built for a pure Battery Electric Vehicle (BEV) platform be adapted to support the hybrid, multi-energy

From a software architecture perspective, many modern BEV platforms already include relatively advanced energy management and vehicle orchestration frameworks that, in theory, can be extended to EREV use cases. However, the practical adaptation effort is often underestimated.

While powertrain specialists would address the detailed control and calibration aspects, the broader software-platform challenge lies in managing the additional operational complexity introduced by multiple energy sources and operating modes.

A pure BEV platform is typically designed around a more predictable energy model centered on battery management, charging behavior, thermal coordination, and electric drivetrain optimization. Once a range extender generator is introduced, additional supervisory logic, state management, thermal interactions, emissions-related considerations, and cross-domain coordination requirements begin to emerge.

This shift affects more than just the powertrain. It also influences connected services, route planning, energy forecasting, charging routines, climate control behavior, and vehicle features built on assumptions suited to pure BEVs.

Architecturally, OEMs with modular platforms, robust abstraction layers, and centralized control are usually better equipped to adapt.

Platforms built for system-level flexibility can adapt to hybrid or multi-energy setups much more smoothly than legacy systems with tight integrations.

 

Q5. In your opinion, what are the primary security and over-the-air (OTA) bandwidth limitations that prevent OEMs from achieving smooth, seamless delivery of high-value post-sale 'Functions-on-Demand' (FoD) across a global multi-market fleet?

Functions-on-Demand is often marketed as a software solution, but in practice, it presents significant operational, security, and lifecycle hurdles.

From a security standpoint, OEMs need to prevent monetizable features from being illegally activated, copied, or tampered with across their fleet. Achieving this demand’s robust identity management, secure boot processes, cryptographic signatures, hardware-based trust anchors, entitlement controls, and ongoing cybersecurity oversight.

At the same time, OTA deployment itself becomes increasingly difficult at fleet scale. Many vehicles operate in regions with inconsistent network quality, varying telecom regulations, or intermittent connectivity. Delivering large software packages reliably across global fleets remains operationally expensive.
Another major issue is version fragmentation. OEMs are no longer managing a single software baseline, but thousands of combinations involving hardware revisions, regional variants, supplier dependencies, optional packages, and differing update histories.

The challenge becomes even greater once AI-enabled features are introduced, as software updates increasingly include models, datasets, and cloud-dependent behaviors rather than static application code alone.

Long-term, the companies that succeed will likely be those that treat OTA and FoD not as isolated features but as continuously orchestrated platform capabilities spanning the vehicle, cloud, cybersecurity, and operational domains.

 
Q6. As sovereign data privacy and localization rules tighten across the US, EU, and China, what is the operational footprint required to run regional connected-vehicle cloud backends?

Connected vehicle platforms are shifting away from centralized cloud models and becoming worldwide, distributed software operations environments.
In reality, OEMs now have to build region-specific backend systems, since data privacy, cybersecurity rules, AI governance, and localization needs vary widely between the US, EU, and China.

This leads to a much larger operational footprint. OEMs often find themselves managing separate cloud systems, local data storage, security and monitoring operations, deployment processes, regulatory compliance, and partnerships in each region.

The challenge is not only technical duplication, but also lifecycle synchronization. Features, APIs, AI services, cybersecurity updates, and backend integrations may evolve at different speeds across regions depending on local regulations and market conditions.

China, in particular, often requires significantly deeper ecosystem localization, including cloud providers, digital services, mapping ecosystems, and AI-related data handling approaches.

As a result, connected vehicle operations increasingly resemble globally distributed software platform businesses rather than traditional automotive IT environments. This has major implications for cost structures, DevOps maturity, supplier ecosystems, and organizational operating models.

 

Q7. If you were an investor looking at companies within the space, what critical question would you pose to their senior management?

A fundamental question to ask is: How sustainable is your technology and platform strategy once your solution moves past the pilot phase and into long-term use?

This question is relevant for OEMs, startups, chipmakers, software providers, AI firms, and smaller suppliers joining the SDV ecosystem.

Plenty of companies can showcase impressive prototypes, AI demonstrations, centralized computing ideas, or individual software-driven features. The real test comes when these solutions have to run reliably across large fleets, different hardware versions, regional regulations, cybersecurity needs, supplier relationships, and shifting software environments.

It’s important to see whether management recognizes the gap between launching an innovation and maintaining a scalable, long-term platform. This means looking at software portability, operational scaling, validation approaches, cloud and edge coordination, ongoing cybersecurity, AI model management, and flexibility for future integration.

In the long run, the companies that will come out ahead in the SDV and AI-driven vehicle space aren’t just those with bold technology demos—they’re the ones that can manage and sustain complexity as the industry continues to evolve.