For much of the past decade, Western carmakers viewed mainland China primarily as a market. Increasingly, they are forced to view it as a source of competitive pressure — and, in some respects, a model for industrial change. Nowhere is this more apparent than in the rise of “China Speed”: the ability of mainland Chinese automakers to develop, launch and iterate vehicles at a pace that established American and European manufacturers struggle to match.
The difference is not simply one of faster execution. Mainland Chinese firms have embraced a software-centric approach to vehicle development more completely than many legacy rivals. Cars are treated less as finished products than as platforms that evolve continuously through over-the-air (OTA) updates, feature rollouts and rapid software iteration. Architectures are increasingly centralized, software stacks are more tightly controlled, and organizational structures are often designed around shorter decision cycles and closer hardware-software integration.
For Western OEMs, closing the gap may depend less on replicating Chinese speed outright than on reducing the complexity that slows them down. Standardized OTA infrastructure, common software frameworks and more integrated decision-making are emerging as part of that response.
This interview is the first in a series by S&P Global Mobility, examining how suppliers view the changing competitive landscape across global automotive markets. We begin with Mike Gardner, executive director of the eSync Alliance.
The following is an edited transcript of the conversation.
S&P Global Mobility: Where is the China Speed advantage most visible today from a software-defined vehicle (SDV) and OTA perspective, and what are mainland Chinese OEMs doing differently beyond simply moving faster?
Mike Gardner: The most striking difference is not the pace itself but the philosophy underpinning it. Mainland Chinese OEMs have built their development models around the assumption that a vehicle is never finished. They treat software as a living product, not a deliverable, and their entire supply chain, organizational structure and investment cycle reflect that. The result is new model cycles of 18 to 24 months against an industry norm that is still, in many cases, closer to four years.
From an OTA perspective, what mainland Chinese OEMs have done better than most of their Western counterparts is move earlier and more aggressively toward electrical and electronic architectures that enable meaningful software updates. Brands such as NIO and XPeng have prioritized in-house control over their core software stacks — autonomous driving, digital cockpit, intelligent chassis — and are actively transitioning toward centralized and zonal architectures that decouple software from hardware and simplify update delivery across the vehicle. BYD, through its vertical integration model, has built the kind of end-to-end control over hardware and software that gives it flexibility to push changes at scale. Critically, they have done all of this with far less legacy architecture to unpick than a European OEM carrying decades of distributed electronic control unit (ECU) complexity.
eSync-based OTA was already being deployed in production Chinese vehicles as early as 2019, when FAW became one of the first OEMs in the world to bring an eSync-enabled connected vehicle to market. The scale of the technical challenge this solved was significant: the HongQi HS5 architecture integrated 33 ECUs, 18 systems on a chip (SoCs), 12 operating systems, four bus protocols and multiple security mechanisms, a level of complexity that illustrates exactly why standardized OTA orchestration matters, irrespective of geography.
That does not mean the problem is solved. BYD launched its e-Platform 3.0 in 2021, introducing domain-based architecture and hardware-software decoupling, but it only moved toward the centralized and zonal architecture that most meaningfully supports scalable OTA with its next-generation platform developments from 2024 onward. Several mainland Chinese brands use OTA as much to iterate and fix as to deliver polished features from launch. But the direction of travel is clearer, the organizational appetite for software-first thinking is stronger, and the absence of entrenched legacy systems means the transition is faster. When BYD or NIO wants to push a functional update, whether improved energy recuperation logic, revised driver assistance behavior, or a refined infotainment experience, the architecture increasingly supports that in a way that most European platforms, midcycle, simply cannot match yet.
The other differentiator is vertical integration. Mainland Chinese OEMs are not assembling a patchwork of third-party ECUs and hoping the OTA layer can paper over the joins. They control more of the software stack than most Western OEMs, which means fewer coordination bottlenecks and faster validation. Industry groups such as the eSync Alliance continue to address challenges around interoperability, update orchestration and standardization across increasingly complex supplier ecosystems. Newer mainland Chinese brands, in many cases, have been able to build these systems with fewer historical constraints than long-established OEMs.
How can standardized OTA infrastructure help OEMs accelerate vehicle development and deployment cycles without compromising quality or functionality?
Standardization is the mechanism that makes speed safe. That is the core argument we make as an Alliance, and one that the industry is beginning to take seriously.
The challenge that many established OEMs face is not a shortage of ambition around SDVs. It is that every supplier in their ecosystem may be operating on a different OTA framework, different update file formats, different campaign management protocols and different security validation processes. When you try to orchestrate a multi-ECU update across that landscape, the coordination cost is enormous, the risk surface is wide and the testing burden multiplies.
What the eSync Alliance specification does is establish a common language for OTA — how update packages are structured, how they are delivered, how ECUs validate and apply them and how campaign status is reported back to the OEM. When that is standardized across the supply chain, you eliminate a huge proportion of the bespoke integration work that consumes engineering time and delays deployment. OEMs can qualify the framework once rather than repeatedly testing proprietary implementations from each supplier.
The quality argument is equally important. Standardization does not mean cutting corners — in fact, quite the opposite. A well-designed common framework incorporates robust rollback mechanisms, cryptographic validation, staged rollout controls and audit trails. An OEM using the eSync specification has those capabilities built in. A recurring challenge across large programs is that individual teams, each working to their own delivery window, can make different decisions about the OTA layer and software stack. The intent is to find the fastest path to completion within their remit — but the outcome is often internal fragmentation that slows the organization. Addressing this is not simply a matter of investment or head count; it requires organizational adaptation, embedding software decision-making at the right level of the management hierarchy rather than treating it as subordinate to hardware program governance. The OEMs making the fastest progress have recognized this and are structuring accordingly.
Where OEMs are integrating multiple independently developed OTA implementations across a complex supply chain, consistency cannot be assumed, and inconsistency is where risk resides.
With standardized OTA in place, the task of managing vehicle software updates at scale is significantly simplified.
Agile OEMs across all markets have demonstrated the value of aligning on OTA decision-making at an organization-wide level— treating update infrastructure as a shared asset rather than a program-by-program choice. That internal alignment is increasingly recognized as a prerequisite for competitive SDV development, regardless of an OEM’s location.
The net effect is that OEMs adopting standardized OTA can shorten their software integration cycles, run parallel development tracks across multiple vehicle programs using the same OTA infrastructure and deploy updates with greater confidence. That is how you close the velocity gap without accepting elevated risk.
To what extent does OTA capability allow OEMs to release vehicles earlier and deliver more iterative feature updates post-production, and why is this becoming strategically important?
This is probably the most commercially significant shift that standardized OTA enables, and not enough OEMs across the industry have fully internalized it yet.
The traditional model requires feature completeness at Job One. Everything the vehicle will ever do in its first model year needs to be validated, homologated and locked before the first car hits the showroom. That constraint shapes the entire development process and is one of the primary reasons automotive development cycles have historically been so long.
Robust OTA changes the equation. If you can reliably and securely deliver software updates to a vehicle in the field, you can deliberately decide to release the vehicle when the hardware and core systems are ready and continue developing the software layer afterward. You are no longer shipping a “finished” product — because with OTA, you never truly have to “finish.” You are shipping a capable platform with an ongoing improvement road map, which is exactly how consumer electronics companies have operated for decades.
The strategic importance of this cannot be overstated. First, it allows faster market entry, which matters enormously in competitive segments where being 12 months behind a mainland Chinese rival on launch timing can translate directly into conquest losses. Second, it creates a recurring relationship with the customer. A vehicle that visibly improves over time, which gains new features, refines existing ones, responds to user feedback, etc., builds brand loyalty in a fundamentally different way to one that silently depreciates from the moment it leaves the forecourt.
The Tata Sierra is a case in point. Engineered from the outset as an SDV, the Sierra has OTA update capability and remote diagnostics embedded as core architectural elements rather than retrofit additions, implemented to eSync Alliance specifications by Alliance member Excelfore, in partnership with Tata Motors Passenger Vehicles. It marks the first production deployment of eSync standards on a software-defined internal combustion engine vehicle in India and demonstrates that the benefits of standardized OTA extend well beyond EV platforms and Western markets. When an OEM of Tata Motors’ scale chooses a standards-based approach for a production program, it reinforces the commercial viability of open, interoperable specifications as a foundation for the SDV era.
Third, OTA enables rapid response to regulatory changes, emissions compliance updates and recall remediation without the cost and reputational damage of a physical service visit. For a commercial operator running hundreds of vehicles, this is a material operational benefit.
For all of this to work at the scale and reliability that customers and regulators will demand, you need standardized OTA infrastructure beneath it. Ad hoc solutions do not scale, and they do not provide the auditability that type approval authorities increasingly require.
What are the biggest organizational or technical barriers preventing Western OEMs from adopting more agile, software-centric development models?
There are several, and they compound each other, which is why progress has been slower than the competitive pressure warrants.
The first is organizational culture and structure. Automotive OEMs have been optimized over decades for hardware engineering. The processes, governance structures, functional hierarchies and supplier relationships all evolved around a world where software was a subset of the electronics team's remit. Transitioning to a model where software is the primary product requires not just new skills but a fundamental rewiring of how decisions are made, how teams are structured and how success is measured. That is difficult in a large organization with deep institutional inertia.
The second is the legacy architecture problem. Many vehicles in production are built on distributed ECU architectures where each control unit has its own proprietary software environment and there is no coherent OTA layer spanning the vehicle. Retrofitting standardized OTA onto that architecture is complex, expensive and in some cases not practically achievable. This is why it matters so much to design for OTA from the ground up, which is what we advocate for new programmes.
The third is the supplier ecosystem. European and American OEMs typically rely on a broad network of tier 1 and 2 suppliers which each have their own software stacks and, historically, their own approaches to update management. Getting that ecosystem aligned behind common standards is a significant undertaking. It requires OEM procurement leverage, supplier willingness to invest in new capabilities and an industry-level coordination mechanism.
Finally, there is the question of risk appetite. A software failure in a consumer electronics device is inconvenient. However, a software failure in a safety-critical vehicle system can be life-threatening. The conservatism that drives long validation cycles is not irrational. It reflects real liability exposure. The answer is not to abandon rigor but to build it into the standardized framework so that rigor is the baseline rather than something each OEM must reconstruct from scratch.
As automakers work to close the gap with mainland Chinese competitors, what might a more software-driven and OTA-enabled development process look like over the next three to five years?
The direction of travel is clear, even if the pace of adoption will vary significantly between OEMs and market segments.
The most immediate shift we expect to see is the consolidation of architectures around zonal or centralized domain models, which provide the software-defined foundation that meaningful OTA requires. Several OEMs globally are already in the middle of this transition. As those architectures become standard across new programs, the case for investing in robust, standardized OTA infrastructure becomes both more compelling and more achievable.
Over the next three to five years, I would expect to see standardized OTA specifications, particularly the eSync framework, embedded as a procurement requirement in an increasing proportion of OEM technical specifications. The regulatory environment is moving that way too. OEMs will need demonstrable, documented OTA processes that can withstand regulatory scrutiny. Proprietary or informal approaches will be largely insufficient.
On the development process side, we will see a shift toward what you might call minimum viable vehicle thinking, not as a shortcut but as a deliberate strategy. OEMs will release vehicles with a defined feature set and a published roadmap of software-delivered enhancements. This will require new commercial models around software licensing and feature activation, and it will require honesty with customers about what a vehicle will become as well as what it is today. Consumer expectations are already moving in this direction, particularly in the premium and EV segments.
For the supply chain, the next three to five years should bring greater alignment behind common data formats, update campaign management protocols and cybersecurity standards. That alignment is what the eSync Alliance exists to facilitate. The OEMs that are already engaging with the specification and building it into their new programmes will have a meaningful head start.
What this means competitively is that the gap with mainland Chinese OEMs on pure velocity may not close entirely — they have structural advantages around vertical integration and decision-making speed that will not disappear quickly. But the gap on software capability, update frequency and vehicle improvement over time is completely closeable, and standardized OTA is the principal mechanism for closing it.
