Automakers are reportedly moving away from frequent, smartphone-style over-the-air updates toward fewer, more consequential releases. The easy interpretation is that the industry tried rapid software delivery, hit customer fatigue and reliability problems, and slowed down. There is some truth in that, but it misses the architectural change underneath it.

The industry is not merely reducing update frequency. It is learning that updating a vehicle is a different class of problem than updating a phone. A phone update changes a personal computing device. A vehicle update can alter the behavior of a distributed cyber-physical system that weighs two tonnes, operates at speed, crosses regulatory jurisdictions, and contains software from multiple suppliers across multiple development cycles.

Once OTA moves from infotainment into charging, braking support, energy management, powertrain control, and driver assistance, release cadence stops being a marketing metric. It becomes an output of system safety, configuration control, regulatory evidence, and fleet observability. That is the real reason OTA is maturing.

Frequency was the wrong measure

The first generation of connected-vehicle messaging borrowed heavily from consumer technology. Regular feature drops made the vehicle feel current and gave manufacturers a visible way to demonstrate that software-defined vehicles were more than an engineering presentation. This encouraged a simple comparison: the manufacturer shipping more updates must possess the better software capability. That conclusion only works when the changes are small, isolated, and reversible. It becomes unreliable as software reaches deeper into the vehicle.

A modern vehicle can contain many electronic control units, multiple network domains, several processor architectures, supplier-specific firmware, market-specific calibrations, and different hardware revisions within the same model year. Two vehicles that look identical to their owners may not present the same update target. One may have received a replacement module during service. Another may carry a different battery supplier, sensor package, or regional homologation configuration.

Release frequency therefore says little about the difficulty of the operation. A cosmetic interface update and a coordinated update spanning the battery-management system, charging controller, gateway, and display are both counted as one release, though their validation requirements are radically different. The better question is not how often the manufacturer ships. It is how accurately the manufacturer understands the state of every vehicle before, during, and after deployment.

The hidden constraint is fleet state

OTA is often described as a pipeline: build the software, validate it, upload it to the cloud, and deliver it to the vehicle. That model is incomplete because it treats the fleet as a uniform destination. A production fleet is not uniform. It is a changing population of configurations.

Before sending an update, the manufacturer must resolve a series of dependencies: which hardware part numbers are installed, which firmware versions are active, which previous updates completed successfully, whether there is enough storage, battery charge, and network connectivity, whether the vehicle has a diagnostic condition that should block installation, and whether several control units need to be updated in a defined sequence.

This is why configuration information becomes foundational. ISO 24089:2023 covers software-update engineering at both organizational and vehicle-project levels, including vehicles, systems, electronic control units, infrastructure, and update packages. As of August 2026, ISO has moved a companion document, ISO/PAS 25090, into its final publication stage after progressing through committee and enquiry review. That guidance focuses specifically on determining the relevant vehicle-configuration information for software-update engineering, with formal release expected in the following weeks. The sequence is revealing. The industry can standardize update processes, but those processes still depend on knowing precisely what is being updated.

A weak configuration model turns deployment into probabilistic targeting. A strong one lets the manufacturer establish applicability, dependencies, prerequisites, and expected post-installation state at the individual-vehicle level. That capability is difficult because the vehicle’s digital record must stay synchronized with physical service history: a control unit replaced at a dealership, a supplier firmware variation, or an interrupted earlier update can make the central inventory inaccurate. OTA maturity therefore depends on more than cloud infrastructure. It depends on the integrity of the digital thread connecting engineering, manufacturing, software release, vehicle telemetry, diagnostics, dealers, suppliers, and regulatory records.

Safety changes the deployment model

When an update affects infotainment, a failed installation may produce an inconvenience. When it affects a safety-relevant function, the failure modes are different. The vehicle might become unavailable, a function might degrade, or an interaction between modules might behave differently than in the lab.

The industry addresses this risk through staged deployment. A manufacturer can begin with internal vehicles, move to a limited cohort, observe telemetry, and then expand across the eligible fleet. Ford’s own support material, for example, tells owners that some software releases are phased and will not reach every vehicle at the same time.

Staging, however, is useful only if the manufacturer can detect the right signals. A download completion rate is not enough. The release-control system needs to observe installation failures, diagnostic trouble codes, resets, battery drain, connectivity loss, functional regressions, and changes in customer complaints, distinguishing an update-caused anomaly from the fleet’s normal background noise quickly enough to stop expansion. This creates a closed-loop release process: identify the eligible configuration, validate the update against its dependencies, deploy to a controlled cohort, observe outcomes, then expand, pause, remediate, or recover according to predefined gates.

The hard part is recovery. Consumer software has conditioned people to assume every update can simply be rolled back. In a vehicle, rollback may be constrained by security protections, changed data structures, calibration dependencies, synchronized ECU versions, or an update interrupted before the system returns to a known state. The architecture may require an A/B software partition, a retained recovery image, a protected bootloader, or a dealer intervention path. A rollback claim is meaningful only when it has been designed, validated, and supported for the specific failure mode.

Regulation turns OTA into an operating responsibility

UN Regulation No. 156 formalized the concept of a Software Update Management System. The important word is management. Compliance is not established by proving a vehicle can download a signed package. The manufacturer needs organizational processes for identifying software versions, assessing update effects, protecting delivery, documenting changes, and demonstrating that updates are managed throughout the relevant lifecycle. ISO 24089 reinforces this broader scope by treating update engineering as a responsibility spanning organizations, projects, systems, ECUs, infrastructure, and deployment packages. Cybersecurity adds another layer, since update channels, signing systems, backend services, credentials, and in-vehicle verification mechanisms all become part of the attack surface.

The United States reaches the issue through a different regulatory structure, but the operational consequence is similar. NHTSA defines a recall around an unreasonable safety risk or failure to meet minimum safety standards. Delivering the remedy remotely can improve completion speed and reduce dealer burden, but it does not make the underlying defect less significant. Ford’s February 2026 recall of approximately 4.38 million trucks and SUVs for a trailer-module software defect, remedied through an OTA update, illustrates the scale now possible through software delivery.

That scale cuts both ways. OTA can distribute a correction to millions of vehicles faster than a dealer-only campaign. It can also distribute a defective build at the same scale. The deployment platform is simultaneously a quality tool, a recall channel, and a potential fleet-wide failure amplifier.

Fewer releases can require more engineering

Batching changes into larger releases is not automatically safer. Larger packages create wider regression surfaces and can make fault isolation more difficult. A manufacturer that combines several poorly understood changes has reduced release frequency without improving release quality.

The mature model is risk-based cadence. Small cybersecurity corrections may need to move rapidly. A customer-facing interface change may tolerate a slower schedule. A cross-domain update affecting energy management and driver-assistance behavior may require extensive vehicle-level validation and tightly controlled deployment gates. Cadence should follow change criticality, architectural coupling, detectability, and recoverability. This also changes software organization design: continuous integration can remain fast inside engineering while production deployment stays governed, separating engineering velocity from fleet exposure.

That distinction is where many automotive transformations struggle. Software teams are rewarded for delivery speed, quality teams for defect prevention, dealers for repair completion, and regulators for demonstrable compliance. OTA forces those incentives into one operating system, and if release authority and stop-deployment rights are unclear, the cloud platform cannot compensate.

The new OTA scorecard

The industry needs to retire update count as a headline metric. It measures activity, not control. A more useful scorecard tracks eligible-fleet identification accuracy, installation success by configuration, time to detect an adverse signal, time to stop deployment, the share of vehicles recovered remotely versus requiring dealer intervention, recall remedy completion, and cost per successfully updated vehicle.

These measures expose where the architecture is weak. Poor eligibility accuracy points to configuration management. Slow detection points to telemetry and observability. High dealer recovery rates point to in-vehicle resilience.

The strategic implication

OTA began as a way to keep vehicles fresh after sale. It is becoming the mechanism through which manufacturers maintain, correct, secure, and sometimes materially change vehicles throughout their operating lives. That transition makes restraint a technical capability. The manufacturer must know when a release is ready, which vehicles should receive it, what evidence is sufficient to expand it, and how to recover if its assumptions prove wrong. Shipping less often may be evidence of weakness, but it may also mean the company has stopped confusing visible activity with operational maturity.

The competitive advantage will not belong to the automaker with the busiest release calendar. It will belong to the one that can modify a heterogeneous fleet at scale while preserving safety, regulatory evidence, serviceability, and trust.

Software-defined vehicles were never going to be defined by how much software they received. They will be defined by how well that software is governed after the vehicle leaves the factory.

The open question for every OEM board is this: if a fleet-wide update went wrong tomorrow, could the organization prove, vehicle by vehicle, exactly what changed and why?

All opinions are my own and do not reflect those of my employer.

The automotive industry has spent the past five years treating model quality as the finish line. Better perception stacks, better world models, better foundation models for robotics: the assumption has been that if the intelligence gets good enough, autonomy and physical AI simply arrive. Peter Ludwig, co-founder and CTO of Applied Intuition, argues in a recent piece for a16z that this assumption is backwards.

A billion machines, cars, trucks, tractors, mining haulers, warehouse robots, will become autonomous or intelligent over the next decade. The constraint on that transformation is not the model. It is the engineering system that turns a model into a certified, deployed, monitored piece of software running inside a multi-ton machine. That distinction matters enormously to anyone building or buying software-defined vehicles, and it deserves more attention from automotive and manufacturing leaders than it has gotten.

Two Variables, Not One

Ludwig’s core argument is that deployed physical AI is a function of two variables. The first is model capability, where the industry has poured nearly all its capital and attention over the past several years. The second is what he calls engineering capacity. This covers how requirements become software, how that software gets validated across millions of scenario variations, and how validated systems get deployed, monitored, and improved once they are in the field.

That second variable, he writes, is still largely built for quarterly release cycles and hundred-person integration teams, even as the models sitting on top of it have improved by orders of magnitude. The mismatch between how fast the intelligence moves and how slowly the surrounding organization moves is not a temporary growing pain. It is structural, and it compounds with every new model generation.

This is a useful reframe of a problem every OEM and Tier 1 engineering leader already feels intuitively. A model that scores twenty percent better on a benchmark still has to be integrated with existing software, traced against safety requirements, and validated on hardware before it means anything to a customer. In Ludwig’s telling, that pipeline sets the actual tempo of the program, not the model.

Teams routinely take delivery of a meaningfully better model and then spend two quarters proving it is safe to ship. The frontier intelligence effectively gets throttled down to the speed of the validation process wrapped around it. The implication for competitive strategy is sharp. Frontier models are commoditizing quickly. Two companies with access to the same underlying intelligence will produce wildly different outcomes based entirely on how fast each one can absorb what the model is capable of.

Why Coding Agents Do Not Transfer Directly

A second point in the piece deserves particular attention from manufacturing technology leaders watching the broader agentic AI wave. The productivity gains from coding agents and copilots in software engineering do not automatically extend to physical AI development. That work does not live in documents and code repositories the way most digital agentic work does.

It lives in drive logs, sensor data, simulation runs, hardware-in-the-loop test rigs, requirements databases, and fleet telemetry streaming off real vehicles on real roads and job sites. An agent that has never seen a disengagement event, does not understand why a perception regression matters, and cannot trace a requirement to a specific test case is not a productivity tool in this domain. It is, in Ludwig’s phrase, a liability with a friendly interface.

Building agents that are genuinely useful in physical AI development is itself a frontier intelligence problem, distinct from training a bigger model. Those agents need direct access to the actual tools of the trade, including simulators, data pipelines, and validation systems, through interfaces hardened enough to be trusted with production consequences. They need embedded domain judgment about what validated actually means when the artifact ships inside a multi-ton machine.

Applied Intuition’s response has been to build what it calls Dana, an agentic platform grounded in its own decade of infrastructure across automotive, trucking, mining, agriculture, and defense. Evaluation and governance are built into the platform rather than bolted on afterward. According to Ludwig, the company’s own engineers have built more than a thousand internal apps and agents on Dana. Development cycles have compressed by roughly a factor of twenty, and deployment frequency has moved from once every few weeks to multiple times a day.

The claim worth sitting with is not the speed itself but what the speed unlocks. When the cost of building software drops by an order of magnitude, the set of applications worth building expands by more than an order of magnitude. That includes work that would never have justified months of engineering effort before.

The Safety Argument Gets Inverted

The most counterintuitive part of the piece is the safety argument, and it is the part manufacturing and automotive leaders should read most carefully. It inverts a deeply held instinct in safety-critical engineering. The reflexive position is that automation and safety-critical work do not belong in the same sentence, that moving fast necessarily means accepting more risk on a machine that weighs several tons.

Ludwig argues the opposite. In safety-critical systems, the speed of the feedback loop is itself a safety mechanism. When validation takes weeks, teams test at irregular milestones and defects age quietly in the system for months before anyone notices them. When validation takes minutes, problems surface while they are still cheap to fix, and test coverage expands to orders of magnitude more scenarios than a manual process could ever reach.

Requirements get implemented more accurately under this model because they get verified more often, not less. The slow, careful-looking process that feels safer by instinct is often the one where the most expensive failures are quietly accumulating out of sight. Speed and rigor are not actually opposites in this framing. They are the same feedback loop viewed from two different angles.

The architecture Ludwig proposes draws a clean line rather than removing the line entirely. Automate development, validation, and operations workflows so issues get found and resolved faster. Never automate certification, regulatory sign off, or final engineering judgment. High stakes agents propose, and humans decide.

That is not a temporary accommodation while the models mature. It is, in his framing, the permanent correct architecture, structurally similar to how a well-designed autonomous vehicle operates within a defined operational domain rather than claiming unlimited authority over every driving scenario it might encounter.

A Global Lens

This engineering-system argument does not land the same way in every market, because the world’s major automotive and manufacturing regions carry different legacy constraints into the agentic era. American automakers and autonomous vehicle developers have generally been fastest to adopt agentic tooling and cloud-native development. Many still carry validation and certification processes built for a slower, hardware-first era, which is the exact gap Ludwig describes.

European OEMs and suppliers operate under some of the most rigorous regulatory and functional safety regimes in the world, which gives them a validation discipline other regions lack. That same regulatory weight can turn into the throttle Ludwig warns about if the underlying engineering system never modernizes to match the pace of the models running on top of it.

Chinese automakers have compressed vehicle development cycles dramatically over the past several years and are already operating closer to the fast feedback model Ludwig describes. That speed is itself becoming a competitive threat to slower incumbents elsewhere, independent of whether their underlying models are more or less capable.

Japanese and Korean OEMs and their Tier 1 suppliers have built some of the most disciplined manufacturing quality cultures anywhere, historically treating validation rigor as a competitive strength rather than a bottleneck to engineer around. That instinct is worth preserving even as the tooling underneath it changes, because rigor without speed becomes the exact liability Ludwig is describing rather than the strength it once was.

The common risk across every one of these regions is not unequal access to frontier models. Frontier intelligence is increasingly available to everyone through cloud platforms, partnerships, and open weights, regardless of headquarters location. The risk is that each region’s own legacy organizational patterns, whatever produced them, become the constraint that throttles frontier intelligence down to the speed of the organization built around it.

The Question This Raises

If Ludwig is right that models are becoming commoditized while engineering systems remain the scarce resource, the strategic question for every automotive and manufacturing leader changes. It is no longer which model to license or which vendor has the strongest roadmap on paper. It is whether the organization’s validation, deployment, and monitoring infrastructure can absorb a frontier model’s capability at anything close to the speed the model itself is improving.

For most programs today, the honest answer is no. That gap is not visible in a demo or a benchmark chart. It shows up eighteen months later, in a program timeline that slipped again, in a competitor that shipped three fleet updates while another team was still writing test cases for one.

The more interesting question is what it would take to change that answer inside a specific organization, and who actually owns that problem today. In most companies, no one does, because engineering capacity has never been treated as a strategic asset with its own budget, roadmap, and executive sponsor the way model access has.

All opinions are my own and do not reflect those of my employer.

Volvo’s head of software engineering, Alwin Bakkenes, put it plainly. “The relationship with Google started when we built Android into our cars.” That single fact helped push Volvo to a top Level 5 ranking in S&P Global Mobility’s software defined vehicle readiness index, one of only two European automakers to reach the top tier.

The car is not getting a new feature. It is getting a new architecture, and artificial intelligence sits at the center of every layer of it. The common mistake is treating this as a software upgrade story, a nicer infotainment screen bolted onto the same car. It is not. Every layer of the modern vehicle, from the code down to the battery chemistry, is now being rebuilt around AI, whether the buyer standing in a showroom notices it or not.

Software defined vehicles are projected to grow from 447.55 billion dollars in 2026 to 1.71 trillion dollars by 2035, a 16 percent compound annual growth rate, according to MarketsandMarkets. Like Physical AI, the modern vehicle is best understood as a stack rather than a single product, five layers, each with its own leaders, its own bottlenecks, and its own emerging AI technology, sitting on top of each other inside every new vehicle rolling off the line.

For a hundred years, the car business measured advantage in horsepower, sheet metal, and dealer networks. None of those disappeared, but none of them are where the next decade of differentiation is being decided either. The five layers below, running from AI software down to AI enabled testing, are where that decision is actually being made.

Why The Stack Is Being Rebuilt

Every major automaker is moving through the same transition at once. BMW, Mercedes-Benz, GM, Ford, and Volkswagen are progressively migrating from domain based electronics toward zonal and centralized architecture, while Tesla and Rivian already operate at the fully centralized end of that spectrum. A traditional vehicle carries more than 100 separate electronic control units, each running isolated software, a structure that cannot support AI features, cannot be secured efficiently, and cannot scale without a hardware redesign.

The business model underneath is changing just as fast as the wiring. As controller counts fall toward a handful of high performance AI compute nodes, the revenue Tier 1 suppliers historically earned from standalone hardware is contracting, and growth increasingly depends on software integration and AI enabled safety middleware rather than another box bolted to a harness.

Regulation is quietly forcing the pace too. UN Regulation 155, now in effect across the EU, Japan, and South Korea, requires manufacturers to patch discovered security vulnerabilities throughout a vehicle’s service life without a service visit. A manufacturer that cannot update its software in the field is, under that regulation, no longer compliant, which turns AI ready, updatable architecture from a nice feature into a legal requirement.

Layer One: The Brain

The brain layer is the vehicle’s AI software and the operating system it runs on, and this is where the real competition sits in 2026. Tesla’s centralized architecture remains the benchmark, reducing controller count and enabling seamless updates. Mercedes-Benz built its new CLA on MB.OS, its first vehicle to run its own operating system end to end, while BMW’s Neue Klasse pairs zonal controllers with centralized compute and a new Panoramic iDrive software layer.

General Motors runs Ultifi across multiple brands rather than building a separate stack per nameplate, and Stellantis expanded its STLA Brain architecture, partnering with Applied Intuition to accelerate its AI driven automated driving rollout. Volkswagen Group and Rivian jointly validated a next generation SDV architecture in March 2026 through their RV Tech joint venture, intended to eventually underpin more than 30 million future Volkswagen, Audi, and Scout vehicles.

Underneath the branded names sits a common technical pattern. A vehicle operating system in 2026 typically means AUTOSAR Adaptive middleware managing application lifecycle and hardware abstraction, so an application built for one generation can run on the next without being rewritten. That abstraction layer is arguably the single most consequential piece of software in the stack, because it determines how quickly an automaker can update everything above it.

The business case for owning this layer is straightforward. Whoever owns the operating system owns the ability to sell AI features after the vehicle is already sold, through subscriptions and over the air updates that used to require an entire model year to ship. That recurring revenue is precisely what a traditional vehicle sale never offered.

What is missing is a shared standard. Tesla’s stack, MB.OS, Ultifi, and STLA Brain are each proprietary and largely incompatible, which looks a great deal like the mobile phone industry before a small number of operating systems consolidated the market. Volvo’s Bakkenes has effectively already answered which side of that fight his company chose, building on Google’s Android Automotive rather than a fully proprietary stack, a bet that trades some differentiation for speed.

Layer Two: The Body

The body layer is the physical electrical architecture the brain runs on top of. Domain architecture groups functions by system. Zonal architecture instead organizes compute by physical location, front, rear, left, right, with a central backbone computer coordinating across zones, which is one of the criteria S&P Global Mobility used to rank Volvo above nearly every other automaker in the world.

The shift matters in measurable terms. Moving to zonal or centralized architecture is expected to cut controller count from more than 100 down to fewer than 10 by 2030, while cutting wiring harness length by 30 to 40 percent, lighter, cheaper, and easier to manufacture at scale.

The change is reshaping the supplier base as much as the vehicles themselves. Bosch, Continental, ZF, Aptiv, Valeo, and Forvia Hella, long the largest suppliers of standalone electronic control units, are repositioning as software integration and zonal controller partners, because the standalone ECU business those companies were built on is structurally shrinking.

Ethernet based time sensitive networking and hypervisor isolation let safety critical functions and AI infotainment functions share the same physical hardware without interfering with each other, a separation older, fragmented ECU architectures achieved simply by never putting those functions on the same chip.

Layer Three: The Parts

The parts layer is the AI compute silicon that gives the brain enough processing power to run in real time. Nvidia’s DRIVE Thor delivers roughly 2,000 TOPS of AI processing, twenty times its predecessor Orin, unifying autonomous driving, cockpit AI, and vehicle control on a single chip.

Qualcomm competes in the mass market tier with Snapdragon Ride, where the SA8295P chip, delivering 30 TOPS, has won sockets in BMW, GM, Stellantis, and Renault by prioritizing cost and power efficiency over raw AI performance, a strategy built for the much larger volume of vehicles that will never need Level 4 autonomy.

Mobileye, an Intel company, pursues a different strategy, bundling its EyeQ6 and EyeQ Ultra chips, 34 and 176 TOPS respectively, with proprietary AI perception software and crowdsourced mapping data from an installed base exceeding 100 million vehicles across 40 OEM partnerships. That base is itself a moat, since every vehicle on the road makes Mobileye’s next chip generation smarter.

Underneath the AI focused silicon sit the power chips that rarely make headlines but that every one of these systems depends on. Infineon’s AURIX microcontrollers handle safety critical control, and its new gallium nitride power transistors push efficiency gains that indirectly extend EV range as much as a better battery would.

The dollars involved are large and growing fast. The automotive semiconductor market is projected to reach 80.75 billion dollars by 2031, and the ADAS specific AI chip market alone is set to triple, from 5.38 billion dollars in 2026 to 16.27 billion dollars by 2031.

Layer Four: The Fuel

The fuel layer is the battery, and it remains the single most contested layer in the stack. CATL held its position as the largest EV battery maker in the world through 2025, with 464.7 gigawatt hours of usage, and Chinese manufacturers now hold six of the top ten global spots with a combined 70.4 percent share.

BYD’s second generation Blade Battery, introduced in March 2026, improved energy density by 5 percent and enables a 1,036 kilometer range in the DENZA Z9GT, a figure that would have sounded like a solid state promise only a couple of years ago.

The next real inflection point is solid state chemistry, replacing the liquid electrolyte with a solid one. CATL has already produced prototype cells reaching 500 watt hours per kilogram, and Toyota, Samsung SDI, and BYD are targeting initial small scale production between 2027 and 2028, with broader volume around 2030.

CATL is also pushing sodium ion chemistry, with its Naxtra battery reaching 175 watt hours per kilogram, matching strong lithium iron phosphate performance while cutting lithium dependence entirely. Naxtra cells were the first to pass China’s new EV battery safety standard, and CATL has confirmed large scale use by the end of 2026, well ahead of any solid state timeline.

Layer Five: The Proving Grounds

The proving grounds layer is where every layer above gets AI tested before it reaches a real driver. Nvidia’s Omniverse, combined with Ansys AVxcelerate, builds physically accurate digital twins of real driving environments, simulating camera, radar, and lidar data with enough fidelity to meaningfully close the gap between simulated and real world testing.

Siemens Simcenter Prescan, Hexagon’s VTD, and dSPACE’s autonomous driving toolset serve the same role across other parts of the industry, though most remain proprietary with limited outside access, a real constraint on how much independent researchers can verify.

The payoff is measured in time, not just cost. Hyundai Mobis has reported cutting autonomous driving verification from tens of thousands of hours down to a fraction of that using large scale AI simulation, work that would be prohibitively slow to run entirely on physical test tracks.

The Automotive AI Landscape, Company By Company

Volvo is the case study for the fast follower path. By building on Google’s Android Automotive rather than a from scratch operating system, Bakkenes and his team reached S&P’s top SDV tier while spending years less engineering time than rivals building proprietary stacks.

Tesla remains the centralized architecture benchmark the rest of the industry measures itself against, a position built on starting from a clean sheet years before most legacy automakers began their own transitions. Mercedes-Benz is betting its future lineup on MB.OS, its first fully in house operating system, launched with the new CLA.

General Motors runs Ultifi across its full brand portfolio rather than separate stacks per brand. Stellantis built STLA Brain as its Level 3 automated driving foundation and brought in Applied Intuition to accelerate the rollout across a portfolio spanning more distinct brands than almost any other automaker.

Volkswagen and Rivian are jointly building a shared SDV architecture through RV Tech that will eventually underpin tens of millions of vehicles across Volkswagen, Audi, and Scout, pairing a century old European manufacturer with an American EV startup less than a decade old.

China’s NIO, XPeng, and Li Auto continue to move fastest on integrating AI driven cockpit and driving features directly into their stacks, often shipping to production before Western competitors finish testing, a pace advantage tied as much to regulatory environment as to any underlying technical edge.

What Still Has To Be True

Every layer of this stack is real and shipping today, but none of it is finished. The brain layer is still fragmented across incompatible operating systems, with no industry standard the way Android eventually standardized phones, and it is not obvious which company is positioned to force that consolidation, even a company as far ahead as Volvo.

The body layer’s transition from domain to zonal architecture will not fully complete industry wide until 2030, which means for several years automakers will run fleets that mix old and new electrical architectures simultaneously, a real engineering burden that gets little attention next to the software headlines.

The fuel layer is still waiting on solid state batteries to move from prototype to volume production, a multi year gap that keeps today’s vehicles running on the same lithium chemistry family that has powered EVs for over a decade, even as sodium ion quietly becomes available first.

All opinions are my own and do not reflect those of my employer.

NVIDIA’s own product specifications for its latest Thor-generation AI platforms list power envelopes that can approach 130 watts depending on configuration and workload, a spec sheet figure worth setting beside a fact from neuroscience. The human brain runs on roughly 20 watts, about what a dim incandescent bulb draws, yet at that power level it performs integrated perception, reasoning, motor control, adaptation, and memory formation continuously, a breadth of capability no production AI accelerator integrates within a comparable power envelope. Placing those two numbers beside one another illustrates one of the most important engineering questions facing the future of software-defined vehicles. Those NVIDIA gains enable dramatically more capable autonomous driving systems, but they also add directly to the thermal management burden electric vehicles already carry on hot days.

That gap is not a story about biology being magical. The AI compute race is not being limited by transistors. It is being limited by how far data has to travel between memory and the processors doing the work, and that single distinction is becoming the most consequential architecture question facing every automaker building a software-defined vehicle.

The Scale of the Gap

An adult human brain’s expected metabolic profile runs to roughly 420 kilocalories over 24 hours, converting to an average continuous draw of about 20.4 watts. That number covers everything the brain does at once, including visual processing, motor coordination, language, and memory formation across an estimated 86 billion neurons and 100 trillion synaptic connections. No accelerator on the market comes close to that scope of concurrent function on that power budget.

Independent analysis comparing brains to GPUs directly puts biological compute at roughly 30 times more energy efficient for comparable throughput, close to 10 watts against roughly 300 watts. That gap holds even though modern GPUs sit only one to two orders of magnitude from the thermodynamic limits of digital switching, meaning engineers are not leaving obvious efficiency on the table. They are running into a ceiling imposed by an architectural choice made decades ago.

Purpose-built AI silicon narrows the gap without closing it. Google’s Ironwood TPUs are roughly 30 times more energy efficient than the company’s first TPU generation from 2015, and TPUs broadly deliver 2 to 3 times better performance per watt than contemporary GPUs. TPU v4 alone delivers up to 1.7 times better performance per watt than NVIDIA’s A100. That is real, compounding progress across a decade of chip generations. It still leaves the best production silicon one to two orders of magnitude behind an organ that also runs the rest of the human body at the same time.

The Real Bottleneck Is Not the Transistor

Computer architects have a name for this problem: the memory wall. Transistors have become dramatically faster and more efficient across decades of process shrinks. Memory latency and the energy cost of moving data between memory and compute have improved far more slowly, so increasingly powerful processors spend a growing share of their time waiting for data to arrive rather than operating on it.

The historical arc explains why. For decades, Moore’s Law and Dennard scaling let engineers add transistors and raise clock speed without a proportional rise in power draw. Once Dennard scaling broke down in the mid-2000s, every additional transistor became harder to cool, and clock speeds stopped climbing at the old rate. Compute kept getting cheaper. Moving data did not. The industry’s bottleneck quietly shifted from arithmetic to data movement, and it has stayed there since.

Since the von Neumann architecture became computing’s default blueprint, memory and processing have lived in physically separate locations connected by a bus, and every operation depends on both sides. Industry estimates place the energy cost of fetching a value from off-chip memory at roughly two orders of magnitude higher than performing a single operation on it once it arrives. High bandwidth memory, stacked physically closer to the compute die, exists specifically to shrink that distance. Successive generations of AI silicon have generally made arithmetic relatively cheaper than moving data. Every generation still pays to move the data.

Imagine building a factory where every bolt had to travel across the building before a worker could tighten it. Eventually the workers become so efficient that walking, not tightening, determines the factory’s output. Modern AI accelerators have reached much the same point. Arithmetic has become extraordinarily efficient. Moving data has not.

The Memory Wall

Model scaling makes this worse, not better. As transformer models continue to grow, memory bandwidth increasingly becomes the limiting resource. Larger models move more parameters, more activations, and more intermediate state through memory hierarchies, causing data movement to consume a growing share of overall energy relative to arithmetic itself.

The brain never built this separation in the first place. A synapse is simultaneously the storage element and the compute element. Synaptic strength, set by receptor density and vesicle release probability, is the same physical structure that converts an incoming signal into a graded contribution to the next neuron’s activity. There is no bus and no fetch step, across an estimated 100 trillion synapses operating at once. Layered on top of that, the brain computes sparsely and asynchronously rather than on a fixed clock, so energy is spent roughly in proportion to information actually transmitted rather than on a fixed clock tax paid every cycle.

The industry is already exploring multiple approaches to reducing the cost of data movement. Processing-in-memory architectures bring computation closer to memory. Analog AI accelerators reduce the energy required for inference. Memristor and MRAM research seeks to combine storage and computation more efficiently. Compute Express Link fabrics improve access to shared memory pools, while neuromorphic chips such as Intel’s Loihi and IBM’s TrueNorth collapse memory and compute into the same physical substrate. They are different technologies pursuing the same objective: reducing the energy required to move information.

Where This Lands Inside the Vehicle

This is not an abstract semiconductor debate. DRIVE Thor delivers up to 2,000 FP4 TFLOPS, roughly 1,000 INT8 TOPS depending on precision mode, a leap NVIDIA credits with 3.5 times the efficiency of its predecessor, Jetson AGX Orin. The platform runs autonomy, infotainment, and in-cabin AI on a single centralized module rather than distributing those workloads across the dozens of separate controllers older vehicle architectures relied on.

That consolidation changes the physical shape of the heat problem, not just its size. Distributed ECUs spread a small thermal load across a large area of the chassis. Centralizing that same workload onto one or two modules concentrates it instead, turning what used to be a diffuse background load into a single hotspot that has to be actively managed. Under extreme ambient temperatures, centralized AI compute adds to the shared thermal load managed by the vehicle’s cooling system. The exact impact depends on vehicle architecture, ambient conditions, workload, and cooling strategy, but every additional watt ultimately competes with battery thermal management for finite cooling capacity. The architectural consequence remains the same regardless of the exact percentage. Concentrating compute also concentrates heat.

The consequence does not stop at the chip. Centralized compute raises power density. Higher power density increases cooling demand. Greater cooling demand drives larger radiators, pumps, heat exchangers, and plumbing. Those choices influence vehicle packaging, curb weight, manufacturing cost, and ultimately driving range. Platform architecture decisions made years before production increasingly begin with thermal constraints rather than compute specifications. Semiconductor analysts often stop their analysis at the package. Automotive engineers cannot. They have to design everything the package touches.

The efficiency race between chipmakers is real. Competitors including Qualcomm are explicitly positioning performance per watt, not peak TOPS, as their differentiator, drawing on decades managing thermal limits in smartphone silicon with no active liquid cooling to fall back on. None of it changes the underlying architecture. Every chip in this race is still built on the same separated memory and compute model that keeps the category one to two orders of magnitude less efficient than the brain it is routinely compared to in marketing materials.

From Compute to Cooling

The Cascading Cost of AI Compute

The Japan Counterpoint

Japan’s automotive silicon tradition offers a useful counterpoint to the TOPS-maximalist posture coming out of Silicon Valley’s autonomy roadmaps. Suppliers like Renesas and Denso built their chip design philosophy around decades of ASIL-rated functional safety work, where every design decision survives a formal hazard analysis before reaching a vehicle. Power margin and thermal headroom are first-order constraints from the earliest architecture review, not a tradeoff resolved after a headline performance number is already published.

This distinction matters because thermal design is ultimately an architectural decision, not a downstream fix applied once the silicon roadmap is set. A chip designed around efficiency first places different demands on battery cooling, wiring harnesses, packaging, and functional safety than one optimized primarily for the peak inference throughput printed on a spec sheet. That is a different systems engineering philosophy, not simply a more conservative one.

That posture grew out of necessity as much as philosophy. Japanese OEMs and their Tier 1 suppliers operate in a reliability environment where a field failure carries consequences measured in decades, not quarters, producing a design culture where efficiency and thermal conservatism are inseparable from safety engineering rather than a separate category optimized afterward. Many Silicon Valley AI compute roadmaps have historically emphasized maximum published inference performance, leaving much of the downstream thermal optimization to vehicle integration teams responsible for cooling systems, battery management, and packaging. Both approaches can produce a certified, working vehicle. They start from different assumptions about how far a compute platform’s power budget is allowed to grow before it becomes someone else’s problem, and that difference will shape which chip vendors Japanese OEMs choose as centralized compute becomes the industry default.

The Question the Industry Has Not Answered

Centralized compute simplifies software delivery and reduces controller count, which is why every major platform strategy is converging on it regardless of chip vendor. But concentrating more silicon into fewer, hotter modules pushes automakers toward a problem biology solved through evolution long before engineers were worrying about battery range, thermal management, or software-defined vehicles.

Performance per watt on today’s chip architectures will keep improving, and every vendor has a credible roadmap showing that trend continuing. That trajectory alone will not close a gap measured in orders of magnitude, because it is rooted in the physical separation of memory and compute rather than in transistor quality. The open question for platform architecture teams is whether the industry keeps managing that gap with better cooling and larger battery buffers indefinitely, or whether it eventually adopts architectures that abandon the separated memory and compute model the way the brain already has.

The first generation of software-defined vehicles was built around increasingly powerful processors. The second generation may be remembered for something less glamorous than TOPS counts: not faster arithmetic, but shorter distances between memory and computation. The next winner in automotive AI may not be the company with the fastest accelerator. It may be the company that moves the fewest electrons. For more than seventy years, computer architecture has focused on making processors faster. The next decade may belong to the companies that make memory feel closer to computation.

All opinions are my own and do not reflect those of my employer.

A newly disclosed Linux KVM vulnerability, tracked as CVE-2026-53359 and reported under the name Januscape, lets a malicious guest virtual machine corrupt host kernel memory. The researcher who found it reports that a controlled guest-to-host escape is achievable, not just a crash. For a cloud operations team, that is a serious but familiar kind of event. Patch quickly, restrict the exposed feature, move on.

For a software-defined vehicle team, it is something else entirely. If a hypervisor like KVM sits inside the boundary separating an ASIL D safety function from everything else running on the same compute platform, a guest-to-host escape is not a patching event. It is evidence that the boundary itself cannot be trusted, and no amount of fast remediation changes that underlying fact. The rest of this piece works through why, and what a more defensible architecture actually looks like.

The Bug Behind the Warning

Januscape sits in the shadow MMU path used by KVM’s memory management code on x86 systems, and reporting describes it as a use-after-free issue affecting both Intel and AMD hosts, since the vulnerable code path is shared across KVM’s x86 implementation. Public proof-of-concept code already demonstrates a host crash, and the researcher’s claim of a working escape exploit raises the stakes considerably further. A crash alone would be a reliability problem. An escape is a trust boundary problem, and automotive architects should read those as two very different categories of risk even though they share one CVE number.

The detail that should concern automotive architects most is not the age of the bug. It is where the bug lived. Reporting indicates the path is especially reachable where nested virtualization is exposed, because nested virtualization can force KVM through legacy shadow MMU logic even when hardware-assisted page translation is normally used. That is a rarely exercised, configuration-dependent path, exactly the kind of code a routine safety review is least likely to scrutinize closely, and exactly the kind of code that tends to survive years of otherwise diligent maintenance untouched.

Automotive programs do not consume Linux the way a cloud fleet does. Most pull the kernel and hypervisor components through a curated distribution, often pinned to a specific version for the full lifecycle of a vehicle program, because stability matters more than staying current. That pinning is usually treated as a stability decision. Januscape is a reminder that it is also a security decision, since a pinned kernel does not automatically inherit an upstream fix, and a vulnerability sitting in a rarely touched code path can persist in a shipping vehicle fleet long after the patch already exists elsewhere.

Why Virtualization Became a Safety Question

Virtualization is no longer a convenience layer in modern vehicle architecture. Software-defined vehicles increasingly consolidate workloads that once lived on separate ECUs onto shared high-performance compute platforms. Infotainment, connectivity, diagnostics, ADAS support services, AI workloads, logging, update agents, and safety-related functions may all end up sharing the same silicon, driven by the same cost, weight, and wiring-harness pressures that pushed the industry toward zonal architecture in the first place.

Once that consolidation happens, the hypervisor stops being neutral infrastructure. It becomes part of the safety argument itself, because it is the mechanism deciding what one workload is allowed to do to another. That is a fundamentally different job than the one KVM was built for. Cloud multi-tenancy isolates different customers running roughly comparable workloads. Automotive consolidation isolates workloads of wildly different criticality on the same silicon, where the failure mode of the least trusted workload can be a threat to human life rather than a service-level agreement violation.

Freedom From Interference

Freedom from interference is the concept that allows mixed-criticality software to coexist on shared hardware. A safety-critical function must be protected from corruption, timing disruption, memory interference, resource starvation, or unauthorized influence from lower-criticality software running alongside it. In an ASIL D design, the burden is not to show that interference is unlikely in ordinary use. The burden is to show, with evidence, that the architecture prevents or controls interference to the level the standard requires. Research on automotive mixed-criticality virtualization consistently frames isolation and fault containment as the central certification challenge, not a secondary implementation detail.

Januscape cuts directly through that argument. If a guest can panic the host, availability isolation has failed. If a guest can corrupt host kernel memory, memory isolation has failed. If a guest can potentially execute code on the host, privilege isolation has failed. When the host kernel is responsible for enforcing separation between safety and non-safety domains, the safety boundary has effectively moved from a certifiable separation mechanism into millions of lines of fast-moving general-purpose kernel code, code that nobody on the vehicle program wrote, reviewed line by line, or can realistically freeze.

This is also where ordinary vulnerability management and functional safety diverge. In a typical enterprise risk register, a patched CVE closes the finding. In a safety case built on freedom from interference, the finding closing does not automatically restore the argument, because the argument was never really about this one bug. It was about whether the isolation mechanism as a class can be trusted to hold under conditions nobody has tested yet. Fixing Januscape addresses one instance. It does not address the structural question the instance exposed.

Why Patching Does Not Repair the Safety Case

Patching is necessary, but patching does not repair the safety case by itself. In a certified automotive system, a kernel update is not simply an operational maintenance event. It can require impact analysis, regression testing, updated evidence, and potentially a reassessment of the safety argument that depended on the prior kernel behavior. Suppliers of safety-critical operating systems and hypervisors emphasize the certification burden created by every software modification, precisely because each change can affect a validated safety baseline.

Contrast that with how cloud operators treat a KVM patch. A cloud fleet can roll a kernel update across thousands of hosts in a maintenance window, verify service health, and move on within days. Automotive safety certification was never built around that cadence, and it should not try to adopt it wholesale just because the underlying software came from the cloud world. A vehicle program that treats every KVM security patch as a routine update is quietly accepting an assumption its own safety case never actually earned: that the isolation layer is stable enough not to need re-argued evidence every time it changes.

The Real Certification Trap

Linux KVM has a massive advantage in cloud and enterprise environments because it is flexible, performant, widely tested, and continuously improved. Those are strengths in cloud operations. They become weaknesses the moment the same software sits inside the trusted computing base of an ASIL D system. A safety case wants bounded behavior, small attack surfaces, analyzable interfaces, predictable timing, controlled configuration, and stable evidence. General-purpose KVM was never designed around those constraints. It was designed to support broad virtualization use cases across many CPUs, workloads, devices, memory modes, and performance optimizations, and that breadth is exactly what makes it hard to certify.

Certified separation kernels take the opposite design philosophy on purpose. They favor small, auditable codebases over broad feature support, and they treat every added capability as a cost against certifiability rather than a selling point. That tradeoff looks unattractive on a feature comparison sheet. It looks essential the moment a sixteen-year-old, rarely triggered path in a much larger codebase turns out to be exploitable. The size and feature velocity that make KVM excellent for the cloud are the same properties that make its safety argument nearly impossible to close.

Codebase size is a useful, if blunt, proxy for this difference. A general-purpose Linux kernel with KVM runs into the tens of millions of lines once every driver, subsystem, and architecture-specific path is counted, even though any single vehicle deployment only exercises a fraction of it. Certified separation kernels are built to the opposite target, commonly kept small enough that a dedicated team can plausibly reason about every code path during certification. That gap is not a rounding error. It is close to the entire reason one class of software can produce a defensible safety case and the other struggles to.

None of this means Linux is poorly engineered. It means Linux is optimized for a different goal than certifiability, and the project’s scale and contributor base were never organized around narrowing that footprint. Expecting one piece of software to be simultaneously the most broadly capable hypervisor in the industry and the most narrowly auditable one is asking it to be two different products at once.

A Tokyo Vantage Point

Watching automotive compute strategy from Tokyo across cloud, OEM, and financial infrastructure roles for over three decades, the pattern here is familiar. Japanese OEM and Tier 1 engineering culture has often been criticized for moving slowly on compute consolidation compared to faster-moving software-first entrants elsewhere in the industry. Januscape is a reminder that the caution was never conservatism for its own sake.

It was a rational response to exactly this category of risk, where a component’s cloud pedigree says nothing about its fitness for a certifiable safety boundary. The engineering organizations that insisted on separating safety domains from general-purpose compute long before software-defined vehicle architecture made that separation fashionable were not behind the industry. They were pricing in a risk that the rest of the industry is only now discovering the hard way.

The Layered Answer

A single guest-to-host escape does not prove KVM can never be used in automotive. It proves that any architecture placing KVM inside the ASIL D trusted boundary faces a very steep evidentiary hill. The more realistic architecture keeps Linux and KVM out of the highest-criticality safety path wherever possible, using a certified or certifiable safety hypervisor, separation kernel, safety island, or lockstep controller to enforce the ASIL D boundary instead.

Linux then runs where Linux is strongest: rich applications, connectivity, AI services, diagnostics, data logging, developer ecosystems, and non-safety orchestration. That is not a demotion of Linux. It is a recognition that different layers of the stack are optimized for different things, and that optimizing for developer velocity and optimizing for a defensible safety argument are not the same design goal, even when they end up sharing the same silicon budget.

The uncomfortable part of this architecture is that it costs something. A dedicated safety controller or a certified separation kernel is more constrained, slower to add features to, and more expensive to maintain than a general-purpose hypervisor with a huge open-source community behind it. Those costs are real. They are also the price of an isolation argument that can actually survive scrutiny from a vehicle safety assessor, which is a price most programs will find easier to pay before an incident than after one.

What Comes Next

The industry consolidating vehicle compute now faces a harder question than which hypervisor performs best. It has to decide which workloads are allowed to sit inside the boundary that protects human safety, and which are not. Januscape does not answer that question. It simply made clear how expensive it is to get wrong, and how little warning an architecture gets before that cost comes due.

All opinions are my own and do not reflect those of my employer.

Dr. Wenyang Zhang, a senior staff mechanical design engineer on Tesla’s drive systems team, stood in front of a room of lubricant chemists at F+L Week in Kuala Lumpur in June 2023 and described, in real detail, how Tesla thinks about the fluid inside its gearboxes. What he did not say, and what a patent search later made clear, is that Tesla does not hold a patent on that fluid’s chemistry. Tesla did not invent it in the way most people assume a company invents the thing sitting inside its own product.

That absence is not a gap in the research. It is the actual shape of how fluid engineering works in the auto industry, and it explains more about how EV drivetrains get built than a chemistry patent would have.

Zhang’s presentation, later reported by the trade publication F&L Asia, laid out where the real losses in an EV drive unit come from. Motor losses account for roughly 10 percent of total vehicle energy loss. Gearbox losses account for roughly 4 percent. Inside that smaller gearbox slice, 87 percent of the loss is torque dependent, meaning it comes from the fluid’s formulation chemistry under load, not from how easily the fluid flows. Only 13 percent is viscosity dependent parasitic drag. Pursuing lower viscosity without the engineering to justify it, Zhang said, is extremely risky to go to lower viscosity fluids without knowing where it will fail.

That framing explains a decision that ran against the industry’s direction. KAF I, the gearbox fluid introduced with Tesla’s fourth generation drive units in 2022, is not the thinnest fluid Tesla could have specified. Zhang’s team tested it against a 32 centistoke fluid and a 22 centistoke fluid, both lower viscosity options, and found KAF I traded advantages with each depending on torque and speed. Rather than default to the thinnest option, Tesla ran systematic simulation work and found that a slight, deliberate viscosity increase produced close to a 1 percent gain in vehicle level energy efficiency. Zhang also named two problems still unsolved: electrically induced bearing damage from stray voltage in the motor’s rotor shaft, and bearing creep caused by radial wear on aluminum housings. Tesla is already working with additive partners on a next generation fluid, KAF II.

Who Actually Owns the Chemistry

KAF I is manufactured by SK Lubricants, a South Korean company, not formulated inside Tesla. That is normal, and Tesla’s own patent portfolio shows exactly where the line sits. US Patent 11,125,315, “Electric Drive Unit Cooling Systems and Methods,” filed by Tesla in 2018 and granted in 2021, describes the physical routing of fluid through a drive unit: the manifold geometry, the tray that channels fluid toward the motor windings, the pump architecture that moves it. It says nothing about what chemical additives are in that fluid. Tesla patents the plumbing. The supplier patents the potion running through it.

A May 2025 patent application from a UK based lubricant chemist, Gareth Moody, shows what a chemistry side patent actually looks like when a supplier files one. Moody’s filing describes an ester additive that lets a formulator dial down a fluid’s traction coefficient without changing its base oil, the same tradeoff Zhang described from the OEM side two years earlier. There is no assignee listed on Moody’s application, and no filing, citation, or licensing link connects it to Tesla. It is simply the same industry wide problem being solved on the supplier side of the fence at roughly the same time Tesla was solving the system side of it.

Lay the two patents side by side and the division is obvious. Tesla’s patent is about geometry: where a hole is drilled, how a tray channels fluid, which surfaces it contacts before draining back to the sump. Moody’s patent is about molecules: which alcohol, which fatty acid, what percentage of the finished blend it needs to be. Neither company could have filed the other’s patent. Tesla does not run a chemistry lab formulating base oils, and a UK additive chemist does not design gearbox castings.

This division is not unique to lubricants. It shows up anywhere an automaker needs a specialized material it cannot economically develop in-house: tire rubber compounds, battery electrolyte formulations, brake pad friction materials. The OEM owns the system the material lives inside. A small set of specialty chemical suppliers, most of them unfamiliar to anyone outside the industry, own the material itself and sell it to whichever automaker specifies it into production.

The same split is quietly forming in humanoid robotics as actuator suppliers scale up. A robot manufacturer will very likely end up owning the actuator housing, the gear ratios, and the motor controller, the entire mechanical architecture. It is unlikely to own the fluid running inside that actuator’s shared gearbox and motor cavity. That fluid will come from the same small set of specialty chemical companies already solving this exact problem for EVs, quietly patenting the chemistry while carmakers patent the plumbing around it.

Zhang’s talk in Kuala Lumpur was never really about a secret Tesla formula. It was a systems engineer explaining how to get the most out of a material his own company does not own. That is a more durable kind of advantage than a chemistry patent would have been anyway. Formulations get replaced every few years as suppliers iterate. The architecture that routes fluid to exactly the right surface at exactly the right pressure is much harder to copy, and it is the one part of this story that actually belongs to Tesla.

All opinions are my own and do not reflect those of my employer.

USMCA was supposed to make North America more predictable. After years of trade uncertainty, the agreement gave automakers and suppliers a defined regional framework for production, sourcing, labor content, steel, aluminum, and tariff qualification. It replaced NAFTA with a more demanding set of rules, especially for automotive, and pushed companies to treat the United States, Mexico, and Canada not as three disconnected markets but as one deeply integrated manufacturing system. For the automotive industry, that was the point. The vehicle assembled in Ontario, Michigan, Coahuila, Kentucky, Puebla, or Tennessee was never really the product of one country. It was the output of a regional production machine.

That machine is now entering a different phase. USMCA is no longer just a trade agreement. It is becoming North America’s automotive firewall against China.

The Agreement Is Still Standing, But the Certainty Is Already Moving

The shift is subtle but important. The formal review of USMCA is about the operation of the agreement, the possible extension of its term, and the future of its rules. Under Article 34.7, the three governments must conduct a joint review at the six-year mark. If all three confirm they want to extend the agreement, USMCA can be extended for another 16-year term. If one party does not confirm extension, the agreement does not immediately disappear, but it enters a cycle of annual reviews and could expire in 2036 if no extension is eventually agreed. CSIS has correctly framed July 1, 2026 not as the date the agreement ends, but as the point where the clock either resets or begins running down.

That distinction matters because the investment problem begins long before the legal expiration date. Automotive programs do not run on political calendars. A new platform, battery supply chain, electronics architecture, powertrain strategy, or regional sourcing plan can take years to design, validate, industrialize, and amortize. Suppliers making decisions about tooling, capacity, localization, and Tier 2 or Tier 3 sourcing cannot wait until 2035 to know whether the current trade architecture will survive. The destabilizing effect comes not from immediate termination, but from uncertainty entering the capital planning cycle. In automotive, uncertainty is not just a mood. It is a cost structure.

The Review Is About More Than Treaty Mechanics

The latest signals suggest that this uncertainty is no longer theoretical. Reuters reported on June 30, 2026 that the United States is expected to formally announce that it will not extend USMCA at the July 1 review, which would begin the decade-long countdown under the agreement’s review mechanism. Reuters also reported that major U.S. demands center on increasing American content in automobiles and restricting Chinese goods from benefiting through the pact. That is the heart of the story. The U.S. is not simply asking whether USMCA works. It is asking whether USMCA is strong enough to prevent North America from becoming a tariff-managed entry point for Chinese industrial capacity.

Automotive is the obvious battleground because it is where trade rules, industrial policy, technology transition, labor politics, and China competition collide. USMCA already contains some of the strictest automotive origin rules of any major trade agreement. Passenger vehicles and light trucks generally need 75 percent regional value content under the net cost method to qualify for preferential treatment, along with requirements around core parts, labor value content, and North American steel and aluminum. Keidanren’s 2026 position paper summarized the automotive requirements as a regional value content threshold of at least 75 percent, qualification of core parts, labor value content, and steel and aluminum purchasing rules.

The Vehicle Has Changed Since the Trade Rules Were Written

Those rules were not academic. They forced automakers and suppliers to restructure supply chains around North American qualification. They also created a compliance architecture around origin calculations, supplier declarations, traceability, and audit readiness. The U.S. International Trade Commission is now conducting a factfinding investigation into USMCA automotive rules of origin and their impact on the U.S. economy, U.S. competitiveness, and the relevance of those rules in light of recent technology changes. The Commission is required to submit reports on automotive rules of origin every two years until 2031, and the current investigation is connected to the 2027 report cycle.

The phrase “recent technology changes” deserves more attention than it gets. The vehicle being governed by USMCA in 2026 is not the same industrial object that policymakers were imagining when NAFTA was negotiated, or even when USMCA entered into force in 2020. The modern vehicle increasingly depends on batteries, semiconductors, sensors, embedded software, cloud connectivity, high-voltage systems, advanced driver assistance, cybersecurity controls, and software-defined architectures. The old automotive sourcing question was where the engine, transmission, chassis, and stamped components came from. The new question is where the value is actually created when the car becomes a rolling compute platform.

China Is Not in the Room, But It Is Shaping the Room

That is where China becomes central, even though China is not at the negotiating table. Chinese automakers, battery companies, electronics suppliers, and industrial technology firms have become increasingly important across the global vehicle supply chain. The concern for Washington is not only finished Chinese vehicles entering the U.S. market directly. It is the possibility that Chinese-origin components, Chinese-backed factories, Chinese battery supply chains, or Chinese vehicle platforms could gain access to the U.S. market through Mexico or Canada while benefiting from the regional trade architecture built for North American integration. Reuters has reported that U.S. policymakers are focused on strengthening rules to prevent Chinese goods and investment from exploiting USMCA channels, including concern about Chinese factories in Mexico.

The firewall metaphor is useful because it captures the emerging function of USMCA. A firewall does not stop all interaction with the outside world. It defines what traffic is trusted, what traffic is inspected, what traffic is blocked, and what traffic requires a higher level of verification. That is what USMCA may become for North American automotive. The agreement is no longer only a mechanism for preferential tariff treatment. It is becoming a rule system for determining which industrial inputs are considered regionally trusted, which are considered strategically exposed, and which may be too connected to non-market industrial capacity to receive the benefits of North American integration.

Mexico Wants Growth Without Becoming the Back Door

Mexico sits at the center of the paradox. Mexico wants to protect export access to the United States because automotive manufacturing is one of the pillars of its industrial economy. At the same time, Mexico wants investment, jobs, supplier development, and a stronger domestic manufacturing base. Chinese automakers and suppliers are attracted to Mexico because it offers manufacturing depth, logistics access, skilled labor, and proximity to the United States. Reuters reported in February 2026 that BYD and Geely were among the bidders for a Nissan-Mercedes-Benz plant in Aguascalientes, while noting that Mexican officials feared Chinese investment could provoke Washington during sensitive North American trade talks.

From Mexico’s perspective, the challenge is to prove that it is not a back door. That means strengthening local content, improving supplier depth, addressing labor concerns, and demonstrating that Mexico’s export platform serves North American integration rather than external circumvention. Reuters reported that Mexico said USMCA-compliant exports would be exempt from a proposed U.S. tariff linked to a forced-labor investigation, and that Mexico’s economy ministry said about 85 percent of Mexican exports to the United States meet USMCA criteria. That is a revealing number because it shows how much of Mexico’s export model now depends on the agreement’s qualification logic.

Canada Wants Tariff Relief Before Treaty Concessions

Canada is in a different position. It is not the primary focus of the China-through-Mexico narrative, but it is deeply exposed to the consequences of U.S. tariff policy and USMCA uncertainty. Reuters reported that Canada expects bilateral agreements with the United States to accompany the USMCA review, while The Wall Street Journal reported that Canada’s ambassador to the United States emphasized tariff relief on steel, aluminum, and automobiles as a more immediate priority than USMCA renewal itself. The Canadian position is therefore less about rewriting the entire treaty on the U.S. timetable and more about reducing the tariff overhang damaging industrial investment.

This is why the three parties are not approaching the review with the same problem statement. The United States wants tighter control over where value is created. Mexico wants to preserve export access while continuing to attract manufacturing investment. Canada wants tariff relief before making treaty concessions. Automakers want predictability because they are trying to plan production networks, battery sourcing, platform allocation, and supplier qualification across long time horizons. Suppliers want transition periods because no one can relocate a complex automotive supply chain by policy announcement. China is not in the room, but increasingly it is the reason the room exists.

Automakers Want the Firewall, But Not the Fire

The auto industry’s position has been clear. Reuters reported in May 2026 that major auto trade groups urged the Trump administration to extend USMCA, arguing that the agreement is crucial for U.S. vehicle production and North American competitiveness. The groups warned against splitting USMCA into separate bilateral arrangements because regulatory divergence would add complexity and weaken regional supply chains. That concern is not self-serving rhetoric alone. It reflects the operational reality of automotive production. Engines, electronics, seats, harnesses, batteries, software components, stamped parts, castings, and finished vehicles move across borders in patterns that do not fit neatly into nationalist storytelling.

The uncomfortable reality is that both sides of the debate have a point. The U.S. is right to ask whether the current rules are sufficient for a world where China is no longer simply an exporter of low-cost goods but a sophisticated competitor in electric vehicles, batteries, robotics, software-enabled manufacturing, connected systems, and industrial scale. The automotive supply chain has changed, and trade rules written around twentieth-century manufacturing categories may not fully capture where strategic value is created. At the same time, the industry is right to warn that too much uncertainty will weaken the very regional base the U.S. says it wants to defend. A firewall that burns down the factory behind it is not a strategy.

The Real Negotiation Is Over Trust

That is the deeper policy tension. If USMCA is used only as a containment tool, it may become less effective as an integration tool. If it is used only as an integration tool, it may fail to answer the strategic challenge posed by China’s industrial expansion. The hard task is to make North America more secure without making it less investable. That means the real negotiation is not simply about tariff preferences. It is about designing rules that distinguish legitimate regional production from circumvention, while still giving companies enough clarity to invest.

For automotive executives, the immediate question is not whether USMCA disappears tomorrow. It does not. The more urgent question is whether the rules that determine qualification, content, labor value, steel and aluminum sourcing, batteries, electronics, and China-linked inputs are about to enter a period of recurring political renegotiation. If they are, then the industry has to treat trade compliance as a strategic architecture problem rather than a legal back-office function. Sourcing, product planning, government affairs, finance, manufacturing strategy, and supplier management now belong in the same room.

The Winners Will Know Their Exposure Before the Rules Change

The companies best positioned for this phase will not be the ones that wait for the final political text. They will be the ones that can model exposure by vehicle platform, supplier tier, component category, country of origin, China-linked dependency, qualification pathway, and tariff scenario. They will know which products remain compliant if thresholds change, which suppliers create hidden exposure, which software or electronics dependencies are strategically sensitive, and which investment decisions require transition protections. They will also understand that compliance documentation is no longer enough. In the next phase, the strategic question will be whether the company can explain why its North American production footprint genuinely creates North American value.

That is where the USMCA debate becomes larger than trade. It becomes a test of whether North America can build a coherent industrial strategy for the software-defined, electrified, geopolitically contested vehicle era. The old assumption was that regional integration itself created resilience. The new assumption is that integration must be defended, measured, and governed against external strategic dependency. That is a very different world from the one NAFTA was built for, and it is even different from the one USMCA originally stabilized.

USMCA Is Changing Function

USMCA is still a trade agreement on paper. In practice, it is becoming a strategic filter for the future of North American automotive production. It will decide which value counts, which supply chains qualify, which investments feel safe, and which foreign industrial strategies are allowed to attach themselves to the regional platform. The paradox is that the agreement designed to stabilize manufacturing may now become the instrument that destabilizes investment planning. But that instability is not accidental. It is the price of trying to turn a trade agreement into an industrial firewall.

The story is not that USMCA is ending. The story is that USMCA is changing function. It was built to organize North American trade. It is now being asked to police North American value creation. For automotive, that may be the most important shift of all.

All opinions are my own and do not reflect those of my employer.

The most important automotive software story of the spring did not come from a demo screen, an investor deck, or a keynote stage. It came from ice.

Rivian and Volkswagen Group Technologies, the joint venture now known as RV Tech, completed winter testing of its production-intent zonal software-defined vehicle architecture in Arjeplog, Sweden. Volkswagen’s announcement framed the program as another milestone in the Rivian-Volkswagen partnership. That is true, but it is also the less interesting version of the story.

The more important version is this: a real-time, safety-relevant chassis function that has spent decades living inside dedicated electronic control units just ran successfully on a zonal architecture designed for over-the-air software updates.

That function was traction control.

That matters because traction control is not a convenience feature. It is not a screen, a route planner, a digital key, or a personalization layer. It is a function that intervenes when tire-road friction disappears and the vehicle has to decide, in real time, how much torque to allow at each driven wheel. It has to do that predictably, under low-friction conditions, while the driver is asking the vehicle to move, turn, accelerate, or recover stability.

For most of the industry’s modern history, the way to make that dependable was to isolate it. Give the function dedicated hardware. Keep the timing path short. Keep the software controlled. Keep the update surface narrow. Keep anything non-essential far away from the loop.

RV Tech just tested a different answer.

It tested a production-intent zonal SDV architecture in winter conditions, with all-wheel drive, traction control, driving performance, hardware-software interaction, and OTA functionality all part of the validation scope. The architecture did not just need to compute. It needed to behave. It needed to behave on snow and ice, where a poor control loop is not hidden by road friction. It needed to behave in a vehicle program intended to become real production architecture, not a one-off technology demonstrator.

That is the achievement. The standard that will eventually define how the industry certifies this kind of architecture is still catching up.

What RV Tech Actually Validated

Volkswagen’s announcement describes a two-phase test program. In Arizona, engineering teams from Volkswagen, Audi, Scout, and RV Tech worked on core software functions and prepared reference vehicles for European winter testing. The program then moved to Arjeplog, Sweden, where the systems were stressed under snow, ice, and extreme winter conditions.

The vehicles were not generic mules. Volkswagen said the reference vehicles included the Volkswagen ID.EVERY1, Audi, and Scout platforms, all equipped with the joint venture’s SDV architecture. The test scope included the interaction between hardware and software for all-wheel drive, traction control, and driving performance. OTA functionality was also validated. Volkswagen said the joint venture and brands conducted hundreds of tests and validation cycles, followed by approval drives in Germany and Sweden with brand development leadership.

That is a compact paragraph in a press release. Technically, it is doing a lot of work.

All-wheel drive and traction control are not isolated marketing bullets. They represent some of the hardest real-time coordination problems in a modern EV. The system must interpret wheel speed, motor torque, vehicle motion, driver demand, and available grip. It must then decide how aggressively to intervene. Too little intervention and the vehicle spins or slides. Too much intervention and the vehicle becomes sluggish, unpredictable, or difficult to control. In a conventional architecture, a dedicated controller or tightly bounded ECU network owned much of that behavior.

A zonal architecture changes the boundary.

Instead of organizing the vehicle around a large number of function-specific ECUs, the architecture consolidates compute and distributes control by physical zones. Local zonal controllers sit closer to sensors and actuators. Higher-level compute coordinates functions that used to live in more isolated boxes. The upside is obvious. Fewer controllers, less wiring, more software reuse, better lifecycle management, faster feature development, and a cleaner path to OTA updates.

The tradeoff is also obvious to anyone who has built safety-relevant systems.

When functions share compute, networks, middleware, operating systems, memory resources, and update mechanisms, the safety case becomes harder. It is no longer enough to prove that a traction control algorithm behaves in isolation. The OEM has to prove that the surrounding platform cannot compromise the function’s timing, data integrity, execution priority, or rollback behavior. It has to prove that an update can be deployed without creating an unreasonable safety risk. It has to prove that mixed-criticality software can coexist without violating freedom from interference.

That is why the RV Tech winter test matters. It is not just a cold-weather drive. It is public evidence that a production-intent SDV architecture can support real-time chassis behavior and OTA-capable software under harsh dynamic conditions.

Why Snow Is a Better Test Than a Stage Demo

Snow and ice are unforgiving because they remove the margin that normal asphalt hides.

On a dry road, a mediocre control loop can sometimes appear competent because tire friction covers up imprecision. On ice, the system has fewer places to hide. Small timing errors, calibration mistakes, sensor interpretation problems, torque delivery inconsistencies, and actuator coordination issues show up faster. A vehicle that feels composed on a test track can become nervous, delayed, or overcorrective when friction collapses.

That is why Arjeplog matters.

Automotive engineers do not go to northern Sweden because it photographs well. They go there because the environment is repeatable in a way that ordinary winter roads are not. Low-friction surfaces, cold starts, snowpack, ice, and dynamic handling scenarios can be exercised over and over again. That repeatability matters when a team is trying to separate a software issue from a calibration issue, a sensor issue from a network issue, or an architecture issue from a vehicle integration issue.

The corporate story is that Volkswagen and Rivian needed to prove the joint venture had momentum. The engineering story is more specific. RV Tech needed to show that the architecture could handle the kind of dynamic vehicle behavior that defines whether an SDV is merely connected or actually roadworthy.

A vehicle that can update infotainment over the air is not an SDV in the meaningful sense. A vehicle that can safely evolve its chassis behavior, driver assistance stack, energy management, diagnostics, and user experience across a shared architecture is much closer to the actual prize.

That is the line RV Tech is trying to cross.

The Real Achievement Is Not OTA. It Is OTA Plus Real-Time Control.

The automotive industry has already proven OTA updates for many categories of vehicle software. Infotainment updates, navigation updates, app updates, user interface changes, battery management refinements, and driver assistance improvements have all moved into the connected-vehicle mainstream. What remains harder is the safety argument around functions that directly influence vehicle motion.

This is where the vocabulary gets sloppy.

People often talk about OTA as if the update channel itself is the breakthrough. It is not. A secure update pipe is table stakes. The harder problem is proving that the software being updated will not undermine a safety-relevant function after deployment. The system needs authentication, encryption, code signing, version control, campaign management, compatibility checks, diagnostic gates, fallback states, rollback capability, and post-update validation. Those are necessary, but still not sufficient.

For a function like traction control, the safety case also has to account for timing, resource contention, actuator coordination, sensor dependencies, degraded modes, and the boundaries between safety-related and non-safety-related software.

That last boundary is where SDV architecture becomes difficult.

In a traditional distributed architecture, a safety-relevant chassis function could be physically and logically isolated. In a centralized or zonal SDV architecture, the system has to recreate isolation through architecture, scheduling, memory protection, safety mechanisms, middleware design, network design, monitoring, and process evidence. The box count goes down, but the assurance burden does not disappear. It moves into the platform.

That is the part many SDV narratives skip.

The reduction in ECUs is not the same thing as a reduction in safety complexity. Often it is the opposite. The complexity becomes less visible because it is no longer spread across dozens of physical boxes. It is concentrated inside software layers, shared compute, communication paths, and update workflows.

RV Tech’s winter validation is meaningful because it suggests the architecture can handle this concentration in real vehicle conditions. But validation is not certification. A successful test program answers the question, “Did it work under these conditions?” A safety case has to answer a harder question: “Why should we believe it will remain acceptably safe across the lifecycle, including after change?”

That is where ISO 26262 enters the story.

ISO 26262 Was Written for a Different Architectural Center of Gravity

ISO 26262 is the core functional safety standard for electrical and electronic systems in road vehicles. The current second edition was published in 2018. That date matters.

In 2018, the industry was already talking about software-defined vehicles, but the production center of gravity was still largely distributed. Domain controllers were emerging. Central compute was discussed. OTA was real in some parts of the market, but it had not yet become the default strategic architecture for legacy OEMs. Zonal architectures were not yet the mainstream reference model for the next generation of vehicle platforms.

The standard reflects that history.

ISO 26262 is powerful because it gives the industry a disciplined way to reason about hazards caused by malfunctioning behavior of safety-related E/E systems. It defines a safety lifecycle. It forces item definition, hazard analysis and risk assessment, safety goals, functional safety concepts, technical safety concepts, hardware and software safety requirements, verification, validation, confirmation measures, and production and operation considerations.

That structure still matters. SDVs do not make functional safety obsolete. They make it more important.

The problem is that SDVs stretch the assumptions around where a function begins and ends. In a zonal architecture, the “item” boundary can become harder to draw. In a mixed-criticality compute platform, ASIL decomposition and freedom from interference become harder to argue. In an OTA-updatable vehicle, the relationship between release, operation, service, and post-production change becomes more dynamic. In a shared software platform used across Volkswagen, Audi, Scout, Porsche, and potentially other brands, the relationship between common architecture and brand-specific function becomes a governance problem as much as an engineering problem.

That is why the next edition of ISO 26262 matters so much.

The third edition work now being discussed is expected to address exactly the categories that RV Tech just placed in public view: SDV architectures, centralized and zonal compute, OTA update safety cases, software process updates, and system-level safety arguments for architectures where multiple vehicle functions share common compute and software foundations.

This is not a minor housekeeping update. It is the standard trying to catch up with the architecture.

The Certification Gap Between Now and the Next Edition

Here is the uncomfortable timing.

RV Tech is already validating the architecture. Volkswagen says the SDV architecture will be deployed in electric vehicles for Western Hemisphere markets. The joint venture is preparing the platform for future production models. Volkswagen Passenger Cars is sending software specialists to RV Tech locations, including Palo Alto, so they can return to Wolfsburg as internal experts. Audi and Porsche are preparing similar training programs.

That is not the behavior of a company treating this as an experiment. That is the behavior of a company preparing to industrialize a platform.

Meanwhile, the functional safety standard most relevant to that platform is still in transition. ISO’s public listing shows the 2018 edition as published and marked to be revised. Industry sources tracking the third edition describe a scope expansion around SDV and OTA safety topics, with some expecting publication later this decade. Other safety-industry commentary has suggested an earlier release window. The exact date is less important than the strategic fact: the architecture is moving faster than the standards framework that will eventually codify how to certify it.

That does not mean RV Tech is unsafe. It does not mean Volkswagen, Audi, Scout, Porsche, or Rivian are acting recklessly. It means they are operating in the normal gap between engineering practice and formalized consensus.

Automotive has lived through this pattern before.

Airbags, electronic stability control, steer-by-wire, automated emergency braking, advanced driver assistance, cybersecurity, and high-voltage EV systems all went through versions of the same cycle. Engineers build. Suppliers validate. OEMs launch. Regulators observe. Standards bodies debate. Certification language catches up after the first wave of implementation has already forced the hard questions into the open.

The difference with SDVs is that the gap is not limited to one feature.

It touches the entire vehicle architecture.

Why Volkswagen Is Training Brand Engineers Inside RV Tech

The qualification program may be the most strategically revealing detail in Volkswagen’s announcement.

Starting in May, Volkswagen Passenger Cars software specialists were expected to spend several months at RV Tech locations, including Palo Alto, to deepen their knowledge of the joint venture’s architecture and code. Those specialists are supposed to return to Wolfsburg as internal experts and multipliers, helping integrate brand-specific functions into future production models. Audi and Porsche are preparing similar programs.

That sounds like a training footnote. It is not.

A validated architecture that only RV Tech understands is a dependency. A validated architecture that Volkswagen, Audi, Scout, and Porsche engineers can extend, integrate, and certify becomes a platform.

That distinction is critical.

Legacy OEMs do not just need software platforms. They need internal software comprehension. They need enough architectural fluency inside the brands to understand what changes are safe, what changes are risky, what changes require revalidation, and what changes alter the safety case. In the SDV era, the most dangerous dependency is not outsourcing code. It is outsourcing understanding.

This is where many OEM software transformations fail.

They buy or partner their way into a platform, but the safety argument remains brittle because the organization cannot explain the architecture deeply enough. It can operate the software. It can integrate features. It can run tests. But when the safety team asks how a fault propagates, how an update is bounded, how a shared resource is partitioned, or how a brand-specific function inherits platform assumptions, the answers become fragmented.

Volkswagen’s qualification program appears designed to avoid that. The company is not merely taking delivery of an architecture. It is trying to create internal technical ownership around it.

That is exactly what an OEM has to do if it wants to certify SDV safety cases at scale.

The Japanese Angle Nobody Should Ignore

The next edition of ISO 26262 will not be shaped only in Germany, Detroit, or Silicon Valley. The national mirror committee process matters, and Japan matters inside that process.

Japanese OEMs have historically been conservative about safety-relevant changes, especially when those changes affect production vehicles in the field. That conservatism is sometimes mocked by software-first companies as slowness. In safety-critical engineering, it is often something else: organizational memory.

Japan’s automotive engineering culture was built around exhaustive validation, supplier discipline, production quality, and an aversion to uncontrolled field risk. That culture is not naturally comfortable with the idea that a chassis function can change after the vehicle leaves the factory unless the safety argument is extremely clear. What was validated? What changed? What evidence carries over? What must be repeated? What is the rollback state? What is the driver told? What happens if the update interacts with a regional variant, a supplier component, a degraded sensor, or a partial campaign deployment?

Those are not philosophical questions. They are certification questions.

A standard that allows OTA-updatable safety-relevant functions without a globally settled way to argue update safety will make conservative engineering organizations nervous. It should. The answer cannot be to pretend OTA does not exist. It also cannot be to treat every update like a full vehicle recertification event. The industry needs a middle path rigorous enough for safety and practical enough for software-defined products.

That is where the committee work becomes important.

The debate over ISO 26262’s next edition will not be about whether software updates are allowed. The market has already answered that. The debate will be about evidence. What evidence is sufficient? What assumptions can be reused? What must be revalidated? How should mixed-criticality platforms be structured? How should freedom from interference be demonstrated? How should OTA campaigns be bounded? How should safety cases survive continuous change?

Those questions will run through Tokyo as much as through Wolfsburg.

The Real Strategic Question

RV Tech’s winter testing gives Volkswagen something it badly needed: evidence that the joint architecture can work under harsh real-world conditions. It also gives the rest of the industry a useful signal. Zonal SDV architectures are no longer a future concept sitting safely in PowerPoint. They are moving into production-intent validation for functions that influence vehicle dynamics.

That changes the conversation.

The strategic question is no longer whether centralized and zonal architectures can support safety-relevant behavior. The answer is increasingly yes, if engineered correctly.

The harder question is what OEMs can certify, explain, defend, update, and operate over time.

That is the real SDV test.

A working architecture is not enough. A working architecture has to become an auditable architecture. It has to become an architecture that safety teams can reason about, legal teams can defend, regulators can understand, suppliers can integrate with, and brand engineers can extend without breaking the assumptions that made the original safety case valid.

That is why RV Tech’s snow test matters more than the headline suggests.

The architecture worked in the snow. The standard that certifies architectures like it is still being rewritten around the industry’s new reality.

Between now and the next ISO 26262 edition, every OEM building OTA-updatable safety-relevant functions will be working inside that gap. Some will treat it as a compliance problem. The better companies will treat it as an architecture problem.

Because in software-defined vehicles, certification does not begin at the end of development.

It begins with the architecture.

All opinions are my own and do not reflect those of my employer.

There is a moment when steer-by-wire stops sounding like an engineering feature and starts sounding like an act of faith.

You turn the steering wheel, but there is no mechanical column carrying that motion to the front axle. No shaft. No direct physical link. No piece of metal translating your hands into the direction of the tires. The steering wheel becomes an input device, the road wheels become electronically commanded actuators, and the thing connecting the driver to the road is no longer a mechanical path but a safety case.

That is the part most people miss.

Steer-by-wire is usually discussed as a packaging technology, a design enabler, or an ingredient in the software-defined vehicle. It allows cleaner cabins, variable steering ratios, yokes that make more sense, autonomous driving architectures that do not have to work around a steering column, and chassis control strategies that are impossible when the driver’s hands are mechanically coupled to the rack.

But underneath all of that sits a much more uncomfortable question.

When the wire replaces the column, what exactly are you trusting?

Infiniti, Nexteer, and Tesla each answered that question differently. Infiniti trusted software, but kept a mechanical ghost waiting in the shadows. Nexteer removed the mechanical fallback and built the safety case around redundant electronics that could survive faults without giving control back to a column. Tesla went further still, removing both the mechanical backup and the conventional network assumption, then moving trust into a proprietary vehicle nervous system designed around bandwidth, latency, synchronization, and redundancy.

Three companies put steer-by-wire into production vehicles.

They did not agree on what made it safe.

That disagreement matters because it is not really about steering. It is about the next decade of vehicle architecture.

The First Answer Was to Let Software Steer, but Keep Metal Waiting in the Shadows

In 2013, Infiniti put a production car on sale with a steering system that broke one of the oldest assumptions in automotive engineering. Under normal operation, the steering wheel was not mechanically commanding the front wheels. Infiniti’s Direct Adaptive Steering system interpreted driver input electronically and sent steering commands through a control system rather than a traditional mechanical path.

That was a radical idea for a consumer vehicle in 2013.

Infiniti’s safety answer was not to ask the public, regulators, or engineers to trust electronics alone. The system used multiple electronic control units watching one another, but it also retained a clutch-based mechanical backup in the steering column. If the electronic steering path failed or power was disrupted, the clutch could engage and restore a direct physical connection between the steering wheel and the front wheels.

The backup was not the product.

The backup was the argument.

It said that software could steer the car during normal operation, but the final layer of trust still lived in metal. If the electronics failed, the car could fall back to something deeply familiar, something a driver from 1990 would understand immediately. The steering might be degraded, but it would still be steering in the old sense of the word. Hands, column, rack, road wheels.

That made the safety story legible.

A regulator could understand it. A journalist could understand it. A skeptical customer could understand it. Infiniti could say that the system was electronically controlled, but not existentially dependent on electronics. The car had entered the steer-by-wire era while keeping one foot planted in the mechanical past.

The cost of that choice was obvious. Infiniti had to carry the weight, packaging complexity, integration burden, and failure-management logic of two steering systems, one electronic and one mechanical. One existed to deliver the product benefit. The other existed to reassure the system, the regulator, and the customer that the old world had not completely disappeared.

That is why Infiniti’s system feels, in hindsight, like a transitional architecture.

It was genuinely advanced. It was also cautious in exactly the way an early production steer-by-wire system probably had to be. Infiniti did not ask the industry to abandon mechanical trust. It asked the industry to let software steer, as long as metal remained close enough to save it.

The Second Answer Was to Remove the Metal and Make the Electronics Prove Themselves

Twelve years later, Nexteer made a different bet.

In late April 2026, Nexteer put a steer-by-wire system into series production on a Chinese new energy vehicle, certified to ASIL D, the highest functional safety level under ISO 26262. This system did not preserve a mechanical backup as the final line of defense. There was no steering column waiting to reassert itself if the electronic system lost confidence.

The safety case moved inside the electronic architecture.

Nexteer’s system relied on multi-layered redundancy: dual controllers, dual power supplies, multiple communication paths, and redundant actuation capability, with faults handled through rapid detection and automatic handoff. The logic is straightforward but demanding. If one path fails, another path must be able to maintain steering authority. If one controller becomes unreliable, another must continue. If one communication link is compromised, another must preserve command and control. Safety no longer comes from returning to a mechanical past. It comes from making the electronic present fail-operational enough that the mechanical fallback is no longer necessary.

That is a very different philosophy from Infiniti’s.

Infiniti treated electronics as the normal operating layer and mechanics as the ultimate safety layer. Nexteer treated electronics as both. The system had to steer electronically, diagnose electronically, degrade electronically, and survive electronically.

But Nexteer’s choice was not reckless. It was almost conservative in a different dimension.

The company did not make every layer of the architecture novel at the same time. Steer-by-wire already asks the industry to accept a major departure from a century of mechanical steering. Adding an entirely new proprietary communication architecture on top of that would increase the number of new variables that have to be proven safe simultaneously. For a global Tier 1 supplier, that matters.

Nexteer’s approach keeps the safety case closer to patterns the automotive industry already knows how to evaluate. It puts the hard engineering work into redundancy, diagnostics, power architecture, actuator control, and fail-operational behavior. That is not easy. But it is easier to certify, industrialize, and explain than a clean-sheet reinvention of the entire vehicle network.

This is why calling Nexteer’s approach “legacy” misses the point.

A production ASIL D steer-by-wire system without a mechanical backup is not a conservative artifact from the past. It is a current production answer to one of the hardest questions in vehicle control. Nexteer’s bet is not that old architectures are better forever. Its bet is that safety-critical systems should minimize the number of unproven variables introduced at once.

That is not timidity.

That is an engineering philosophy.

The Third Answer Was to Move Trust Into the Vehicle Network Itself

Tesla took the argument somewhere else.

The Cybertruck, which entered production in late 2023, became the most visible production example of steer-by-wire at meaningful volume without a mechanical steering link between the steering wheel and the front axle. Like Nexteer’s system, it does not use a mechanical fallback as the ultimate safety layer. But Tesla also challenged another assumption most of the industry still keeps.

It did not build the steering network around the conventional CAN bus architecture.

Tesla built EtherLoop, a proprietary vehicle network that draws from Ethernet concepts and uses a loop topology designed to carry power and data through a simplified wiring architecture. In Cybertruck, this is part of a broader shift toward zonal controllers and software-defined vehicle architecture, where the vehicle’s wiring, compute, control, diagnostics, and update strategy are treated as one system rather than separate domains stitched together by inherited network assumptions.

That is why Tesla’s steer-by-wire decision is more radical than it first appears.

The company did not simply remove the mechanical backup. It also refused to preserve the old network as the trusted layer underneath the new steering system. Instead, it moved trust into a new vehicle nervous system built around high bandwidth, low latency, time synchronization, fault tolerance, and bidirectional communication paths.

This is the most ambitious safety philosophy of the three.

Infiniti said software can steer, but metal should remain the final fallback. Nexteer said software can steer and electronics can be redundant enough to replace the metal. Tesla said the vehicle network itself has to become part of the safety architecture, because the software-defined vehicle will eventually demand more bandwidth, synchronization, and distributed control than legacy assumptions can comfortably provide.

That is a harder safety case.

There is less institutional history. Fewer engineers have decades of field experience with the exact implementation. Regulators and safety assessors have less accumulated precedent. The company has to prove more of the architecture from first principles, not just in ideal conditions, but under fault, degradation, aging, service error, manufacturing variance, electromagnetic noise, physical damage, and the endless creativity of real-world vehicle use.

But the upside is equally clear.

If the vehicle is becoming a distributed computer with wheels, the network is no longer plumbing. It becomes part of the control system. Steering, braking, power distribution, zonal compute, diagnostics, over-the-air updates, and autonomy all begin to depend on the same architectural foundation. At that point, the question is not whether Ethernet-derived architectures are newer than CAN. The question is whether the old network assumptions can carry the future vehicle without becoming the bottleneck.

Tesla’s answer is no.

That does not make Tesla automatically right. It does make Cybertruck one of the clearest production signals of where this argument is headed.

This Is Not a Fight Between Old CAN and New Ethernet

The lazy version of this story says CAN is legacy and Ethernet is the future.

That framing is too easy, and it is wrong in the way most easy technology narratives are wrong. It confuses direction with inevitability. It assumes newer is better, older is obsolete, and the only question is how quickly the laggards catch up.

That is not what is happening here.

Nexteer is not behind. It put a no-mechanical-backup steer-by-wire system into series production in 2026 with ASIL D functional safety approval. That is not an obsolete architecture. That is a current production safety-critical system from one of the most important steering suppliers in the world. The decision to keep the network safety case closer to familiar automotive patterns is not a failure to modernize. It is a deliberate attempt to reduce certification complexity and isolate the novel part of the system.

Tesla is not automatically ahead simply because it is more radical.

Tesla’s architecture may be more aligned with where software-defined vehicles ultimately need to go. It may remove a real ceiling that the rest of the industry will eventually have to confront. But ambition increases the proof burden. The more novelty you introduce into a safety-critical path, the more you have to demonstrate that the new architecture is not only faster, cleaner, and more elegant, but also safer when things break.

That is the actual fork.

One school of thought says safety assurance comes from minimizing novelty in any single safety-critical system. Use what the industry understands. Keep the failure modes familiar. Add redundancy where it can be tested, modeled, certified, and industrialized. Do not make the network, the actuator, the controller, the power path, and the safety case all novel at the same time.

The other school of thought says safety assurance has to be engineered into the architecture the vehicle will actually need. If the future vehicle requires high-bandwidth, low-latency, software-defined, zonal, updateable, distributed control, then preserving the old network as the sacred safety layer only delays the hard work. Eventually, the safety case has to move into the new architecture.

Both positions are defensible.

They are also incompatible in the long run.

The Steering Decision Is Really an SDV Decision

This is why steer-by-wire matters beyond steering.

It forces an architectural question that many software-defined vehicle programs still avoid. Are you building the safest possible version of the current vehicle architecture, or are you building the safety case for the architecture you know the vehicle will eventually require?

Those are not the same thing.

A company optimizing for certification speed, supplier interoperability, known failure modes, and near-term production execution will be drawn toward Nexteer’s philosophy. Do not introduce more novelty than necessary. Remove the mechanical fallback only when the electronic redundancy is strong enough to satisfy the highest functional safety bar. Keep the safety case understandable to OEMs, regulators, auditors, and manufacturing partners.

That is a rational path.

A company optimizing for deep vertical integration, long-term software control, wiring simplification, zonal architecture, and future bandwidth demands will be drawn toward Tesla’s philosophy. Do not build a safety-critical subsystem around a network assumption that may become obsolete inside the vehicle’s production life. Move determinism, redundancy, synchronization, and control into the network architecture itself.

That is also a rational path.

The danger is pretending the choice is only about protocol speed.

It is not.

It is about organizational appetite for architectural novelty. It is about where the company wants the safety proof to live. It is about whether the vehicle’s most critical control systems should be protected by familiar layers from the past or rebuilt around the nervous system of the future.

That decision will show up first in steering because steering is impossible to fake. If the system fails, the driver knows immediately. The regulator knows immediately. The plaintiff’s lawyer knows immediately. There is no abstract transformation narrative to hide behind when the thing turning the wheels no longer has a mechanical connection to the driver’s hands.

That is why steer-by-wire is such a clean signal.

It strips the software-defined vehicle down to its most uncomfortable premise.

At some point, the machine has to trust the architecture.

The Real Question Is What You Trust After the Column Disappears

Infiniti, Nexteer, and Tesla are often treated as points on a technology timeline.

That is too shallow.

They are better understood as three trust models.

Infiniti represents mechanical trust. The electronics can control the steering, but the mechanical path remains as the final authority if the system loses confidence.

Nexteer represents redundant electronic trust. The mechanical path disappears, but the safety case is built around duplicated controllers, power supplies, communication paths, actuators, diagnostics, and fail-operational behavior that can satisfy the industry’s highest functional safety expectations.

Tesla represents network-architected trust. The mechanical path disappears, the conventional network assumption is challenged, and the vehicle’s communication architecture becomes part of the safety-critical control strategy itself.

That is the real progression.

Not old to new.

Not CAN to Ethernet.

Not legacy supplier to Silicon Valley disruptor.

The progression is from trusting metal, to trusting redundant electronics, to trusting the vehicle network as the nervous system of a software-defined machine.

That is why this argument will not stay confined to steering. It will move into braking, chassis control, power distribution, battery systems, zonal controllers, autonomy stacks, and every other domain where physical motion depends on software command. The more software-defined the vehicle becomes, the more safety assurance has to migrate from mechanical fallback into electronic architecture. The only unresolved question is how quickly, and how much novelty the industry is willing to prove at once.

The steering wheel no longer needs a wire to the wheels.

That part has already been decided.

The harder question is what the industry trusts instead.

Subscribe to AutomotiveCloudWatch at automotivecloudwatch.substack.com for weekly analysis on automotive and manufacturing technology transformation.

All opinions are my own and do not reflect those of my employer.

The obvious question is not “why not QNX?”

The better question is sharper.

Why not run Linux on QNX?

That is a serious architectural option.

QNX exists for exactly this class of problem. It is a safety-certified, real-time operating system with a long history in embedded automotive systems. QNX Hypervisor can run Linux as a guest. That gives system designers a clean pattern: place safety-critical functions in QNX, run Linux in a virtualized domain, and use the hypervisor boundary to isolate Linux from the safety system.

For many automotive systems, that is the right answer.

QNX becomes the trusted base. Linux becomes the rich operating environment. The safety function stays in the certified world. AI, diagnostics, cloud connectivity, infotainment, developer tooling or non-safety orchestration can run in Linux.

If Linux fails, the hypervisor contains the damage.

That is a strong architecture.

But it answers a specific problem.

Running Linux on QNX protects the system from Linux.

It does not automatically make safety-relevant execution inside Linux safe.

That distinction matters.

If Linux is only a lower-criticality guest, QNX Hypervisor is a clean answer. Linux can crash, misbehave or be restarted without compromising the safety function. The safety case remains centered on QNX, the hypervisor configuration, the inter-VM communication path and the safety application.

But if the safety-relevant workload is actually inside Linux, the problem changes.

The perception stack may depend on Linux.

The GPU driver path may depend on Linux.

The AI inference runtime may depend on Linux.

The sensor fusion path may depend on Linux-native drivers.

The robotics middleware may depend on Linux.

The safety-relevant device driver may live in the Linux kernel.

At that point, QNX can still isolate Linux from the rest of the system.

But it cannot, by itself, prevent one Linux kernel subsystem from corrupting another Linux kernel subsystem’s safety-relevant data.

The unsafe interaction is no longer between QNX and Linux.

It is inside the Linux guest.

That is the kernel problem nobody wants to name.

A hypervisor boundary is excellent when the safety boundary sits between operating systems.

It is not enough when the safety boundary runs through Linux itself.

That is why NVIDIA’s work matters.

Not because Linux is a better safety operating system than QNX.

It is not.

Not because QNX is obsolete.

It is not.

NVIDIA’s work matters because the software-defined vehicle, the autonomous machine and the physical AI system are all pulling safety-relevant behavior deeper into Linux-native compute environments.

And the industry needs an honest architecture for that reality.

The Problem Is Architectural, Not Procedural

The vanilla Linux kernel was not designed with functional safety as its primary objective.

That is not a criticism.

Linux was optimized for performance, flexibility, portability, hardware support and a fast development cycle. Those are exactly the reasons automotive, robotics and industrial AI companies want to use it.

But the safety consequence is structural.

Inside the Linux kernel, all processor cores share the same kernel memory map. There are no strong internal boundaries between safety-relevant and non-safety-relevant kernel execution. A kernel thread running on one core can write to memory used by another kernel function, driver or subsystem.

That means one kernel bug can corrupt data relied upon by a safety-critical driver.

Silently.

Without an immediate alarm.

Without a clean boundary that says: this code was not allowed to touch that memory.

The conventional response has been process-based tailoring.

Identify the relevant kernel functions. Map the dependency chain. Demonstrate disciplined engineering practices. Write a safety case showing that the relevant fault modes have been analyzed and controlled.

That approach can help.

But it has a completeness problem.

You cannot easily prove that every relevant fault mode has been identified in a kernel as large, interconnected and fast-moving as Linux. The upstream kernel evolves constantly. Subsystems change. Drivers change. Internal assumptions change.

Trying to exhaustively qualify the full kernel is not only expensive.

It risks becoming infeasible and unsustainable.

The alternative has often been external monitoring.

Place an observer outside the kernel’s reach. Watch for bad behavior. Use a watchdog or monitor to detect when something has gone wrong.

That solves part of the interference problem by stepping outside the system.

But it has its own limitation.

An external monitor can be structurally blind to failure modes inside high-performance kernel execution paths. It can also introduce latency. Some safety functions cannot wait for an outside observer to notice that something went wrong.

For years, the industry has been navigating between two inadequate options.

Try to qualify too much of Linux.

Or monitor Linux from the outside and hope the monitor sees enough.

Neither is a satisfying architecture when Linux is already in the safety-relevant execution path.

The QNX Tradeoff Is About the Safety Boundary

This is where the QNX comparison needs to be precise.

QNX is the clean answer when the safety function can be isolated.

If the safety-critical workload can run in a deterministic environment with controlled interfaces to the rest of the system, QNX gives the safety team a clearer argument. The trusted computing base is smaller. The operating system is designed for this job. The certification path is more mature.

Brake control.

Safety supervision.

Gateway isolation.

Watchdog management.

Actuator control.

Power and mode management.

Fail-operational fallback.

Mixed-criticality separation using a certified hypervisor.

Real-time control loops that do not require Linux-native AI infrastructure.

In those cases, QNX is often the better answer.

The system should not drag Linux into the safety case if the safety function can be cleanly separated from it.

But that is not every modern vehicle or robot architecture.

Linux gives you something QNX is not primarily designed to provide: ecosystem gravity.

GPU acceleration. AI frameworks. High-throughput drivers. Open-source middleware. Robotics tooling. Containers. Cloud-native deployment patterns. Simulation workflows. Observability. A large developer base.

Modern SDV and physical AI architectures increasingly depend on those capabilities.

So the real decision should not start with the operating system.

It should start with the safety boundary.

Can the safety-critical function be kept outside Linux?

If yes, QNX or another certified safety environment is the cleaner answer.

Can Linux be treated as a lower-criticality guest running under a certified hypervisor?

If yes, QNX Hypervisor is a strong pattern.

Is Linux directly involved in the safety-relevant execution path?

If yes, the problem has moved inside Linux.

That is the point where QNX isolation is no longer sufficient by itself.

You may still use QNX.

You may still use a certified hypervisor.

You may still run Linux as a guest.

But if the safety-relevant data, driver behavior or execution path lives inside the Linux kernel environment, then Linux itself needs internal architectural hardening.

That is the space NVIDIA is addressing.

QNX Hypervisor says: isolate Linux from the safety domain.

NVIDIA’s context architecture says: isolate safety-relevant kernel contexts from the rest of Linux.

Those are complementary patterns, not mutually exclusive ones.

This Is Where NVIDIA’s Approach Matters

At the ELISA Workshop in London in June 2026, NVIDIA’s Igor Stoppa laid out why this problem has been so difficult to solve, and what a credible architecture for Linux safety qualification could look like.

The important part is not that NVIDIA is arguing Linux should replace QNX.

That would be the wrong lesson.

The important part is that NVIDIA is addressing the harder class of systems where Linux cannot be kept outside the safety-relevant compute environment.

The question changes.

Instead of asking, “How do we qualify Linux?” the better question becomes:

“How do we make the parts of Linux that must be safe verifiably safe, without needing to qualify the entire kernel?”

That shift matters.

Because the goal is not to turn the whole Linux kernel into QNX.

The goal is to create protected safety havens inside Linux, narrow the qualification scope and make the safety argument bounded enough to be believable.

That is the architectural move.

Safe Havens Inside the Kernel

The mechanism NVIDIA described is a context architecture layered on top of the processor’s memory management unit.

The kernel maintains multiple memory maps at the same time. Each map can cover the same address-to-physical-page relationships, but with different read and write permissions.

The key idea is simple.

Higher-context memory can be readable by lower-context code, but writable only by code operating in the appropriate context.

In the illustrative model:

CTX00 is the vanilla kernel. No special restrictions.

CTX01 is protected from CTX00. Code running in CTX00 cannot write to CTX01 memory.

CTX02 is protected from both CTX00 and CTX01. Code in either lower context cannot write to CTX02 memory.

If a kernel thread attempts to write to memory outside its allowed context, the MMU generates a hardware fault.

The violation is caught immediately.

There is no window for silent corruption.

This is the core idea behind creating verifiably safe havens inside the Linux kernel.

Not around the kernel.

Inside it.

That distinction is the whole story.

If QNX Hypervisor is the answer when Linux can be treated as an isolated guest, NVIDIA’s approach is an answer for the case where the safety island has to exist inside the Linux environment itself.

What This Solves

The first problem is spatial interference.

This is the core safety issue. Safety-relevant data should not be silently overwritten by non-safety-relevant kernel code.

With context-based protection, lower-context threads cannot write into protected higher-context memory. The boundary is enforced by hardware, not merely by process discipline.

That creates a different safety argument.

It is also similar in spirit to what zonal E/E architecture is doing at the vehicle level.

You do not make every node equally trusted.

You create domains.

You enforce boundaries.

You control how data and authority move between them.

The same principle applies inside the kernel.

The second problem is qualification scope.

A safety-critical device driver may still need to call non-qualified upstream kernel functions. A simple example is printk.

Under a traditional qualification model, calling printk from a qualified context could potentially drag printk into the safety qualification scope. That is exactly the kind of scope expansion that makes Linux qualification so hard.

Under NVIDIA’s context architecture, a compiler plugin can automatically inject transition code.

Before calling printk, the thread drops to CTX00.

Printk runs in the vanilla kernel context.

When the call returns, the thread restores the prior context.

The safety case no longer needs to qualify all of printk.

It needs to qualify the transition logic.

That is a radically smaller problem.

The third problem is memory allocation.

The Linux kernel memory managers are complex state machines. Trying to fully qualify them is unrealistic.

NVIDIA’s approach avoids that trap.

A pool selector routes allocations to context-specific memory pools. An end-to-end vetting monitor validates each allocation before it is released to the requesting thread.

The allocators can remain unqualified.

The qualified component is the vetting logic.

Again, the architectural move is the same.

Do not pretend the whole kernel is safety qualified.

Create a bounded safety mechanism around the part that matters.

The Temporal Problem Still Matters

Most of this architecture addresses spatial interference.

That means preventing unauthorized writes to safety-relevant memory.

But safety is not only about memory corruption.

It is also about time.

Temporal interference occurs when one software element disrupts the timing requirements of another. A safety-relevant process can be starved of CPU time. A watchdog can be pinged on time even while the thing it is supposed to monitor is blocked. A system can appear alive while its safety function is effectively dead.

This is why monitoring still matters.

The monitoring chain NVIDIA describes starts with hardware.

A hardware watchdog acts as the root of safety.

An in-kernel monitor, itself protected from spatial interference by the context architecture, services that watchdog through qualified logic.

The chain then cascades upward.

Kernel components are monitored by the in-kernel monitor. Userspace safety processes are monitored from the kernel. The hardware watchdog provides the final backstop.

The important point is that each layer must use the right semantics for its level.

Simple pinging is not enough when synchronization loss is possible.

A safety process can still ping while being logically stuck.

A driver can still respond while failing to advance the safety-relevant state machine.

A watchdog can still be serviced by the wrong piece of software.

The monitoring chain has to be hardened end to end.

Spatial isolation keeps protected memory safe.

Temporal monitoring keeps protected behavior alive.

Both are required.

The Best-of-Both-Worlds Design

The most interesting part of NVIDIA’s architecture is what it does not require.

It does not require the vanilla Linux kernel to stop being Linux.

The upstream kernel can keep its fast release cadence. Non-safety code can keep moving quickly. Developers do not need to freeze on an aging kernel version just to preserve a certification story.

The safety mechanisms are additive.

The context architecture, compiler plugin, pool selector, allocation vetting monitor and in-kernel safety monitor can be independently qualified without forcing the entire upstream kernel into the same process.

That changes the economics of Linux safety.

What must be qualified is narrow:

The context transition logic.

The allocation vetting monitor.

The in-kernel safety monitor.

The specific drivers or functions that operate in protected contexts.

What can remain outside the qualification scope is much larger:

The scheduler core.

The general memory managers.

Printk.

Networking.

Most upstream kernel functions.

Most of the ordinary Linux ecosystem.

This is the right architectural instinct.

Shrink the safety case until it becomes believable.

Do not widen the safety case until it becomes impossible.

The Mature Architecture Will Often Use Both

The future SDV architecture is unlikely to be pure QNX or pure Linux.

It will be mixed criticality.

QNX may run the safety supervisor, deterministic control functions, watchdog logic, certified hypervisor layer or fail-operational fallback path.

Linux may run perception, planning, AI inference, diagnostics, OTA services, data movement, simulation hooks and developer-facing software infrastructure.

The system-level question is how these worlds are partitioned.

If Linux can be treated as a lower-criticality guest and supervised by QNX, that is attractive.

If Linux can crash without compromising the safety function, the architecture is cleaner.

If Linux can be restarted without losing the safety case, the hypervisor boundary is doing its job.

But if Linux is directly involved in safety-relevant execution, then Linux needs internal hardening as well.

That is the key point.

The decision is not ideological.

It is architectural.

Use QNX when the safety boundary can be cleanly drawn around a certified RTOS or hypervisor environment.

Use QNX Hypervisor when Linux can be isolated as a guest outside the safety-critical path.

Use the NVIDIA-style Linux safety pattern when the safety boundary runs through Linux itself.

The winners will be the companies honest enough to define where the safety boundary really lives.

Why This Matters Beyond NVIDIA

NVIDIA’s interest is obvious.

Drive platforms support safety-relevant ADAS and autonomous driving systems. Jetson, Thor and related compute platforms are moving deeper into robots, machines and physical AI deployments. The software ecosystem around these platforms depends heavily on Linux.

But the architectural question is not proprietary to NVIDIA.

Every OEM building Linux-based zonal compute platforms faces the same problem.

Every Tier 1 delivering a Linux-based middleware stack into a vehicle program faces the same problem.

Every robotics company trying to certify an industrial, medical or autonomous system faces the same problem.

Every factory automation vendor moving from deterministic embedded controllers to AI-enabled edge compute faces the same problem.

The question is always the same.

How much of the Linux stack must be trusted?

How much must be isolated?

How much must be monitored?

How much must be formally qualified?

The ELISA project exists because this is an industry-wide problem. It brings together automotive companies, suppliers, safety experts, tool vendors and Linux contributors around the question of how open source software can be used in safety-relevant systems.

What NVIDIA has added is a concrete architectural pattern.

Do not change the entire Linux development model.

Do not pretend process tailoring alone is enough.

Do not rely only on external monitors.

Build hardware-enforced safe havens inside the kernel.

Then qualify the mechanisms that create, protect and monitor those havens.

That is a meaningful contribution.

The Lesson for the SDV Era

The software-defined vehicle runs on Linux.

Not aspirationally.

Actually.

Linux is already present in production vehicle systems, zonal compute platforms, ADAS domain controllers, OTA managers, vehicle data services and development platforms.

The industry cannot wait for a clean-slate safety operating system to displace Linux from every relevant position.

The integration cost is too high.

The ecosystem cost is too high.

The toolchain cost is too high.

The developer base is too large.

So the question is not whether Linux will be used near safety-relevant workloads.

It will be.

The real question is whether the architecture around Linux is honest enough about the kernel’s limitations.

Process tailoring without architectural hardening has a completeness problem.

External monitoring without spatial isolation has a completeness problem.

A safety case that quietly assumes the kernel is better isolated than it really is has a credibility problem.

QNX remains the clean answer when the safety function can be isolated.

QNX Hypervisor remains the clean answer when Linux can be treated as an isolated guest.

NVIDIA’s Linux pattern is the harder answer for the cases where Linux cannot be kept outside the safety boundary.

That is the kernel problem the industry does not like to name.

NVIDIA just named it.

Now the automotive industry needs to decide whether it is ready to architect around it.

All opinions are my own and do not reflect those of my employer.

Stefan Dorak said it plainly.

“Maybe SDV is already old.”

The BMW Senior Vice President for Connected Company Development was not dismissing software defined vehicles. He was saying something more precise.

For BMW, SDV is no longer an aspiration. It is an operating reality. The company has 24 million connected cars communicating with its backend today. More than 10 million vehicles already receive over the air software updates. Neue Klasse is not the starting line for BMW’s software journey. It is the next step in a transformation that has already been underway for years.

That matters because much of the automotive industry is still treating SDV as the destination.

It is not.

At IAA Mobility 2025, five executives from Google, Arm, Sonatus, BMW, and Accenture spent 43 minutes describing what comes after SDV. What emerged was not a marketing narrative. It was a working map of the architecture decisions, partnership models, toolchains, security assumptions, and compute strategies that will define the next decade of vehicle development.

The conclusion was hard to miss.

SDV is present tense.

AI defined vehicles are the next planning horizon.

SDV and AI are now the same conversation

The panel began as a discussion about software defined vehicles.

It ended as a discussion about artificial intelligence.

That shift was not accidental.

Jeff Chou, CEO and founder of Sonatus, framed the connection directly. “AI is a pillar of SDV. SDV is a pillar of AI and they’re one and the same.”

Dipy from Arm extended the point from a compute architecture perspective. Software defined vehicles create the foundation on which AI defined vehicles can be built. Without that software foundation, AI remains isolated in features, functions, and demonstrations. With it, AI can become part of the vehicle operating model.

That distinction matters.

An OEM that builds a software defined architecture without designing for AI inference from the beginning will face a second rearchitecture cycle almost immediately. It will separate hardware from software, only to discover that its compute model, validation pipeline, data architecture, and runtime environment were not designed for continuous AI deployment.

That is the trap.

The industry cannot afford to treat SDV and AI as sequential programs. SDV is not phase one and AI is not phase two. They are the same architectural investment viewed at different levels of maturity.

The companies that understand this will build platforms. The companies that do not will build expensive transition states.

BMW’s real lesson is governance

BMW’s contribution to the panel was not only about scale. It was about governance.

Stefan Dorak described a practical framework for deciding what BMW builds internally, what it licenses, what it sources from open source, and what it develops with partners. Every module and software component is evaluated through the same lens.

Is it differentiating?

Is it available as open source?

Can it be licensed?

Can it be co-developed with a partner?

Only what remains after that evaluation is built internally.

The BMW user interface, for example, is built in-house because it is a brand differentiator. The same platform can run across BMW, MINI, and Rolls-Royce, while the experience layer changes to match the brand.

That is the obvious part.

The more important point is the scale and fluidity of the decision process. Dorak estimated that BMW made more than 100 individual architecture and sourcing decisions during the Neue Klasse program. Several were reversed over time as market offerings matured.

That is the lesson other OEMs should pay attention to.

The standardization versus differentiation question is not a one-time architecture decision. It is a continuous governance process. It requires organizational muscle, commercial awareness, engineering discipline, and the humility to change course when the ecosystem improves.

The winners in SDV will not be the companies that build everything.

They will be the companies that know exactly what they must own.

The toolchain is where velocity compounds

Steve Basra, Google’s Head of Automotive, made one of the panel’s most important observations.

“What’s the point of having an SDV vehicle if you can only update it once or twice a year? Then it’s not really a software defined vehicle.”

That sentence cuts directly to the heart of the SDV debate.

A vehicle cannot become software defined merely because its architecture diagram separates hardware from software. It becomes software defined when the organization can develop, test, validate, release, monitor, and improve software continuously.

That is why Google Horizon matters.

Built with Accenture, Horizon is an automotive grade, open source, cloud based toolchain designed to let developers collaborate globally, scale build cycles to thousands of instances, and integrate AI across the development pipeline.

The AI layer is not decorative. It is embedded in coding, testing, test script creation, and test automation.

This is where the compounding effect begins.

If AI accelerates each stage of the development loop, the gap between OEMs with cloud native toolchains and OEMs running legacy development infrastructure will widen quickly. Software velocity will no longer be a function of headcount alone. It will become a function of architecture, automation, toolchain maturity, and development loop design.

Accenture cited 10x improvement in specific development steps during work with Google. It also cited potential cost reduction tied to AI in the development pipeline.

Those figures should not be read as generic productivity slogans. They should be read as a warning.

The next divide in automotive software will not be between companies that have OTA and companies that do not.

It will be between companies that can compound software learning every week and companies that still ship software like hardware.

Arm’s thesis is about validation, not just compute

Dipy from Arm made a compute architecture argument that is easy to underestimate.

The value of a consistent architecture from cloud to vehicle endpoint is not only performance. It is development, validation, and deployment efficiency.

When the same Arm IP that runs in the cloud also runs in the vehicle, software can be developed, verified, and validated in cloud environments before it is deployed to the endpoint. The closer the cloud environment is to the vehicle architecture, the lower the friction in the development pipeline.

That has major implications for OEMs evaluating silicon and compute platforms.

Vehicle compute selection is no longer only a vehicle level decision. It is an end to end architecture decision. It affects cloud simulation, virtual validation, software portability, developer productivity, CI/CD design, and the cost of scaling across vehicle lines.

Arm’s SOAFEE initiative, an open source consortium with more than 150 members, is part of that argument. It provides a standardized interface layer at the edge so that software can become more portable and development can become more cloud aligned.

For OEMs, the implication is direct.

Selecting an in-vehicle compute platform without considering cloud side development compatibility is optimizing for the wrong constraint.

The question is not only what runs well in the car.

The question is what allows the entire engineering system to move faster from cloud to endpoint and back again.

The orchestration layer is becoming the real vehicle platform

Jeff Chou’s description of in-vehicle orchestration may have been the clearest articulation of what this layer actually does.

Traditional automotive applications are vertically designed. They are tightly coupled to hardware, network topology, vehicle configuration, and domain specific integration logic. If something changes in the vehicle, the application often has to change with it.

An orchestration platform changes that model.

It creates a horizontal abstraction layer that hides hardware and software topology complexity from the application layer. Applications become more portable across E/E architectures, vehicle models, and hardware configurations.

That sounds technical because it is. But the strategic implication is simple.

OEMs should not force every application team to solve the same infrastructure problems repeatedly.

The orchestration layer provides shared services such as in-vehicle network management, prioritization, failover, cloud connectivity, data access, data processing, authentication, intrusion detection, and runtime environments for deploying AI models.

Once those services exist at the platform layer, application teams can move faster. Differentiation shifts toward the user experience, feature logic, data product, and brand expression rather than the plumbing underneath.

Chou’s analogy to the software defined data center is useful. When software defined data centers emerged, nobody could fully predict the platforms and business models they would enable. Social media, cloud native enterprise platforms, and cryptocurrency were not obvious outcomes from the infrastructure layer itself.

The same may be true for vehicles.

The most valuable applications in 2032 may not exist yet. The job of the orchestration layer is to make room for them.

Cybersecurity is not a finish line

The cybersecurity portion of the panel was refreshingly practical.

The moderator asked whether vehicle cybersecurity could eventually become as taken for granted as seat belts.

Dipy’s answer was the one practitioners already understand.

No.

Not because the industry is failing. Because the attack surface of a software defined vehicle is permanently dynamic.

“As soon as we think we’re secure, there’ll be something else.”

That is the right operating frame.

Connectivity, OTA, software abstraction, third party services, AI runtime environments, and cloud integration all increase the need for continuous security posture management. The solution is not to retreat from software defined architecture. The solution is to treat cybersecurity as a permanent ecosystem discipline.

Dorak added the practical corollary. OEMs should work with specialist security companies rather than trying to build every capability internally.

That is not weakness. It is architecture realism.

The same standardization versus differentiation logic that applies to software modules applies to cybersecurity. Some capabilities must be owned internally. Others should be sourced from companies whose entire business is staying ahead in the cat and mouse game.

In SDV, security is not a gate at the end of development.

It is a continuous capability built into the vehicle platform, toolchain, operating model, and partner ecosystem.

The timeline question has already changed

Near the end, the moderator asked each panelist when software defined vehicles would outnumber traditional vehicles.

The answers differed, but the pattern was clear.

Google argued that the technology is already here. Waymo is already on the road. Personal vehicle SDVs are accelerating quickly.

Sonatus argued that terminology will keep evolving. What matters is not the label but the platform for innovation.

Arm argued that if the definition is software deployable in real time, the industry is already there. BMW and Mercedes are already software defined. The AI defined vehicle is the next step.

BMW pointed to its current reality. More than 10 million OTA capable vehicles. Twenty four million connected vehicles. Neue Klasse as the next step rather than the beginning.

Accenture argued that the capability exists, but realizing the full potential of AI and user centric vehicles will take the next decade.

Read together, the message is clear.

The SDV debate has moved.

The question is no longer whether software defined vehicles are possible. They are already on the road. The question is how quickly OEMs can integrate the AI layer, modernize the toolchain, standardize the platform services, secure the attack surface, and build the partner model required to move at software speed.

SDV is not the end state.

It is the launchpad.

What leaders should take away

The IAA panel offered a simple but uncomfortable message for automotive leaders.

First, SDV and AI cannot be separated. A vehicle architecture that is not designed for AI inference, cloud based validation, continuous learning, and model deployment is already incomplete.

Second, the build versus buy decision must become a living governance process. BMW’s example matters because it shows that differentiation is not a slogan. It is a disciplined set of repeated decisions.

Third, software velocity depends on the toolchain. OTA capability without high frequency development, testing, validation, and release capacity is an incomplete transformation.

Fourth, compute architecture must be evaluated from cloud to endpoint. The vehicle chip decision affects the engineering system, not only the vehicle bill of materials.

Fifth, orchestration is becoming the platform layer that determines how much innovation the vehicle can absorb over time.

Finally, cybersecurity must be treated as a permanent operating model. There is no final secure state. There is only continuous adaptation.

The puck has already moved

Stefan Dorak’s hockey analogy captures the moment.

Skate where the puck is going, not where it is.

In 2025, the puck is no longer SDV.

The puck is AI defined vehicles.

That does not mean SDV is irrelevant. It means SDV is the foundation. The companies still debating whether to become software defined are already late. The companies building cloud native toolchains, AI ready compute platforms, orchestration layers, OTA operating models, and ecosystem governance structures are preparing for the next race.

The panel at IAA did not describe a distant future.

It described the road the industry is already driving.

The question for every OEM and Tier 1 architecture team is no longer whether this transition is coming.

It is how fast they can get there before the window closes.

From Tokyo. Writing at the intersection of automotive architecture, physical AI, and the software defined vehicle transformation across Japan and APJ.

All opinions are my own and do not reflect those of my employer.

Why the Software-Defined Vehicle Is a Waypoint, Not a Destination

The software-defined vehicle was supposed to be the destination.

It is turning out to be a waypoint.

A new category is emerging in architecture discussions across OEMs, Tier 1 suppliers, autonomous vehicle developers, and compute platform providers.

The AI-Defined Vehicle.

Not a vehicle with AI features layered on top.

A vehicle whose E/E architecture, compute platform, software stack, validation processes, and operational model are designed around AI inference, trained behavior, sensor fusion, and continuous model improvement from the beginning.

That distinction matters.

The software-defined vehicle made vehicles programmable.

The AI-Defined Vehicle makes them learnable.

And once learning becomes the primary design constraint, the architecture changes.

What Changes When AI Becomes the Design Constraint

The hardware-centric vehicle was designed around fixed functions.

One controller handled infotainment. Another handled ADAS. Another managed body electronics. Another controlled chassis functions. Software was tightly coupled to hardware, and the architecture mirrored the organizational structures that developed it.

The software-defined vehicle began to break that model. Compute became centralized. Software became increasingly decoupled from hardware. Over-the-air updates became practical. Feature velocity accelerated. Zonal architectures began replacing fragmented domain architectures.

Yet the SDV still assumed that much of the software would remain deterministic.

The AI-Defined Vehicle does not.

AI workloads are model-dependent, latency-sensitive, memory-intensive, and increasingly driven by probabilistic neural network behavior. They require accelerators, memory bandwidth, sensor fusion pipelines, safety isolation mechanisms, cloud feedback loops, and model deployment infrastructure that cannot simply be added later.

These capabilities become part of the architectural foundation.

That means the platform decision often occurs at the silicon level long before a production feature is finalized.

What NVIDIA Thor Actually Represents

NVIDIA DRIVE AGX Thor is not simply a faster automotive processor.

It represents a consolidation thesis.

Thor is designed to bring together workloads that historically required separate compute domains. Cockpit experiences, ADAS functions, autonomous driving capabilities, parking systems, perception pipelines, planning systems, and in-cabin intelligence increasingly converge onto a common AI compute substrate.

The architectural implications are significant.

For OEMs, the decision is not simply about processing performance. It is about whether a compute platform can support future AI workloads, software reuse, model deployment, safety partitioning, sensor fusion, and vehicle evolution over a decade-long lifecycle.

For Tier 1 suppliers, the implications are equally important.

Decades of expertise in cockpit systems, parking systems, ADAS, and body electronics remain valuable. However, future differentiation increasingly depends on combining that domain expertise with AI-native integration capabilities operating on centralized compute platforms.

That is the real strategic bet.

Thor is not merely a semiconductor product.

It is a forcing function for organizational and architectural change.

The Robotaxi Case

The partnership between Nuro, Lucid, and Uber provides a useful glimpse into what an AI-Defined Vehicle ecosystem looks like in practice.

Lucid contributes the vehicle platform and manufacturing capability.

Nuro contributes the autonomous driving system.

Uber contributes the deployment network and demand aggregation platform.

NVIDIA provides the compute foundation through DRIVE AGX Thor and the broader DRIVE Hyperion ecosystem.

This differs fundamentally from the traditional automotive model where OEMs integrated components sourced from Tier 1 suppliers into a finished vehicle.

Instead, value is created through a multi-party capability stack.

The vehicle platform, AI system, compute platform, and deployment network are contributed by different specialists operating within a shared architecture.

This is the emerging supply chain logic of AI-native mobility.

The vehicle is no longer solely a manufactured product.

It increasingly becomes a continuously improving AI system.

Cosmos and the Synthetic Data Challenge

Every autonomous vehicle program eventually encounters the same limitation.

Real-world miles are essential.

They are not sufficient.

Rare edge cases, safety-critical events, and unusual environmental conditions occur infrequently by definition. Waiting for a fleet to naturally encounter every meaningful scenario is not a viable validation strategy.

This is where NVIDIA Cosmos becomes important.

Cosmos is part of NVIDIA’s broader effort to develop world foundation models and synthetic data generation capabilities for physical AI systems. It allows developers to create, test, and validate scenarios that may be rare, dangerous, or prohibitively expensive to capture in the physical world.

For commercial vehicle manufacturers such as TRATON and other organizations pursuing autonomous trucking on NVIDIA DRIVE Hyperion, this is not a research capability.

It is increasingly becoming a production requirement.

Highway autonomy introduces countless edge cases involving weather conditions, construction zones, emergency vehicles, degraded lane markings, tire debris, and unpredictable driver behavior.

No physical fleet can collect every scenario at the scale required for rapid deployment.

Synthetic data provides a mechanism for closing that gap.

The question facing the industry is no longer whether synthetic data will be used.

It will.

The real question is how regulators, OEMs, insurers, safety auditors, and autonomous driving developers define the boundary between synthetic training, simulation-based validation, closed-course testing, supervised road testing, and real-world deployment.

That boundary may become one of the most consequential debates in autonomous mobility.

Why Autonomous Trucks Deserve Serious Attention

One of the more ambitious claims emerging from the autonomous vehicle sector is that autonomous trucks could represent the most important transportation innovation since the diesel engine.

At first glance, that sounds exaggerated.

A closer examination suggests otherwise.

The diesel engine did not simply improve freight transportation. It transformed logistics economics. It expanded road freight, enabled just-in-time manufacturing, and fundamentally altered how supply chains operated.

Autonomous trucking has the potential to produce similar second-order effects.

Driver availability constraints influence route planning today. Hours-of-service regulations determine utilization rates. Labor shortages affect freight capacity. Long-haul economics are fundamentally tied to human operating limits.

Autonomy changes those assumptions.

If safety performance and regulatory approval are achieved, vehicle utilization can increase substantially. Freight scheduling becomes more flexible. Asset productivity improves. Logistics networks begin optimizing around machine availability rather than driver availability.

The data layer becomes equally important.

Autonomous truck fleets continuously collect information about road conditions, weather, infrastructure quality, traffic patterns, operational anomalies, and safety events.

That dataset becomes a strategic asset in its own right.

The freight industry is not merely another deployment target for autonomous technology.

It may become the highest-leverage proof point for the AI-Defined Vehicle thesis.

What This Means for OEM Architecture Teams

The multimodal transportation environment is not a future scenario.

It already exists.

Human-driven vehicles, assisted-driving vehicles, semi-autonomous vehicles, robotaxis, autonomous delivery systems, autonomous trucks, and eventually privately owned Level 4 vehicles will share infrastructure for decades.

The transition will be uneven.

Architecture teams are therefore not designing for a single operational model.

They are designing for an extended period of mixed autonomy.

A vehicle program entering development today may launch in 2028 or 2029. The compute platform selected now will determine whether that vehicle can support future AI workloads or whether it requires another hardware cycle to remain competitive.

That is the architectural decision many organizations continue to underestimate.

Compute platforms can no longer be selected solely against current feature requirements.

They must be selected against future inference requirements, model deployment strategies, sensor fusion scalability, safety isolation needs, and autonomy expansion potential.

The first generation of SDV programs focused heavily on feature velocity.

That was appropriate for the challenges of the time.

The next generation must focus on learning velocity.

The winners will not simply deliver more software updates.

They will build architectures that allow vehicles, cloud platforms, simulation environments, and AI models to evolve together.

FAQ

What is an AI-Defined Vehicle?

An AI-Defined Vehicle is a vehicle whose E/E architecture, compute platform, and software stack are designed around AI inference as a primary design constraint. It extends the software-defined vehicle concept by making neural network behavior, sensor fusion, natural language interaction, and continuous model improvement core architectural requirements.

How is an AI-Defined Vehicle different from a Software-Defined Vehicle?

A software-defined vehicle is programmable. An AI-Defined Vehicle is learnable. SDVs focus on software flexibility and faster updates. ADVs focus on AI workloads, model deployment, synthetic validation, and continuous improvement through learning systems.

Why does NVIDIA DRIVE Hyperion matter?

DRIVE Hyperion provides an integrated hardware and software reference architecture that helps OEMs, Tier 1 suppliers, and autonomous driving developers deploy AI-native vehicle systems more efficiently. It serves as an integration platform for compute, sensors, perception systems, and autonomous driving capabilities.

Why does NVIDIA Cosmos matter?

Cosmos helps developers generate and validate rare or dangerous scenarios that may never be encountered at sufficient scale in real-world testing. It expands the ability of autonomous vehicle developers to improve safety validation and training coverage.

What does this shift mean for Tier 1 suppliers?

Tier 1 suppliers must combine traditional domain expertise with AI-native integration capabilities. Future competitive advantage will increasingly come from the ability to integrate AI systems, centralized compute architectures, and software-defined functionality into scalable vehicle platforms.

The Architecture Decision That Cannot Be Deferred

The vehicle programs being architected today will reach customers in 2028 and 2029.

The compute platforms selected for those programs will determine whether those vehicles can participate fully in the emerging AI-Defined Vehicle ecosystem or whether they require another major hardware transition to remain relevant.

That is not primarily a software decision.

It is a silicon and architecture decision being made today in product planning meetings across the industry.

The OEMs and Tier 1 suppliers that recognize the AI-Defined Vehicle as an architectural substrate will make fundamentally different decisions from those that view it as merely another software feature set.

The diesel engine did not improve the steam-powered truck.

It replaced the underlying design logic.

The AI-Defined Vehicle may ultimately do the same to the Software-Defined Vehicle.

All opinions are my own and do not reflect those of my employer.

The last piece I wrote started with a provocation.

The incumbents have the moat. Legacy automotive OEMs, with a century of manufacturing discipline, factory-floor physical data, and supply chain depth, hold structural advantages in the physical AI era that no startup can replicate quickly. The framing was broad and deliberate. The incumbents, plural, hold the moat.

That argument left a question sitting on the table.

If the incumbents hold the moat broadly, who among them is actually building the largest physical AI dataset right now? Is the moat evenly distributed across the field, or is one organization compounding faster than everyone else? And when you pull in the purpose-built players like Waymo and Baidu alongside the OEMs, who actually owns the biggest data flywheel?

That is the question this piece tries to answer. Carefully. With the data. And with a ranking at the end that may surprise you in a couple of places.

How to Measure a Moat

Before judging anyone, the scoring system needs to be explicit. Raw miles accumulated is the number everyone quotes. It is also the least complete measure available.

Five dimensions actually determine how durable a physical AI data moat is.

Data Volume is the daily accumulation rate, not just the cumulative total. A fleet generating 100 million miles (160 million kilometers) per day with an accelerating trajectory is more valuable than one that hit a large cumulative number years ago and plateaued. Velocity matters more than history.

Data Quality distinguishes supervised driving, where a human sits ready to intervene, from fully unsupervised autonomous deployment, where the system lives or dies on its own decisions. A single unsupervised mile in a dense city teaches the model something a hundred supervised highway miles cannot. Quality and quantity are not interchangeable.

Geographic Diversity reflects a hard reality of 2026: data collected in Shenzhen does not transfer cleanly to Stuttgart, San Francisco, or Tokyo. Road geometry, regulatory frameworks, traffic culture, edge-case distributions, weather patterns, and infrastructure standards differ enough that a geographically concentrated dataset trains a geographically limited system.

Training Infrastructure Control asks who owns the pipeline end to end. An organization that controls its own compute, chip design, vehicle platform, and model retraining loop can iterate in days. One that depends on third-party GPU availability, external cloud training, or licensed model components is structurally slower and more exposed.

Scope and Cross-Domain Transfer is the most forward-looking dimension. A company whose driving data also trains humanoid robot manipulation is building a compounding advantage. The physical world has physical laws that generalize. An organization operating at the intersection of vehicle autonomy and factory robotics is not collecting two datasets. It is collecting one dataset that improves two products simultaneously.

Each company in this analysis is scored across all five dimensions on a 1-to-10 scale. The radar is not flattering to everyone. That is the point.

The Contenders

Tesla: The Current Champion

Tesla is where any honest analysis has to start. Not because the narrative demands it, but because the data does.

The FSD fleet crossed 10 billion cumulative supervised miles (16 billion kilometers) on May 4, 2026. The daily accumulation rate hit 28.8 million miles (46 million kilometers), a 71 percent acceleration over four months. That trajectory is the most important number in this analysis, not the cumulative total. Tesla is not just ahead. It is pulling away from itself.

The geographic distribution is genuinely global. Four million FSD-enabled vehicles operate across North America, Europe, Asia, and beyond. No other organization in this analysis collects driving data at scale on three continents simultaneously.

The training architecture is where Tesla’s structural advantage becomes hard to replicate. Cortex at Giga Texas runs FSD and Optimus training on overlapping pipelines. Improvements in vehicle autonomy feed robot dexterity. Factory floor robot data feeds driving model edge-case resolution. That closed loop between a 10-billion-mile vehicle fleet and 1,000-plus humanoid robots in live manufacturing is not a product feature. It is an architectural decision that compounds silently every day.

The Achilles heel is deployment proof. Ten billion supervised miles is a training asset. The Robotaxi fleet operating commercially in Texas sits at approximately 42 unsupervised vehicles. The gap between the data advantage and the product it has produced is the central tension in the Tesla physical AI story.

Scorecard: Volume 9 | Quality 7 | Geo Diversity 10 | Infra Control 10 | Cross-Domain 9 | Total: 45/50

BYD: The Volume Shock

Here is the number that should stop you cold.

BYD’s fleet of 3.15 million vehicles equipped with its God’s Eye assisted driving system generates up to 124 million miles (200 million kilometers) of driving data per day. Tesla generates approximately 28.8 million miles (46 million kilometers) per day. BYD is generating more than four times Tesla’s daily data volume.

That figure is not widely discussed outside China. It should be the first thing every physical AI analyst talks about.

The architecture of that advantage is as important as the number itself. God’s Eye was deployed across BYD’s entire model lineup, from the entry-level Seagull hatchback at approximately $9,700 to premium vehicles at $27,700. That price range matters. Driving data from a $10,000 city car navigating dense urban alleys in Chongqing captures scenarios that no premium fleet dataset touches. The breadth is not accidental. It is the result of a deliberate decision to democratize ADAS and generate maximum scenario diversity across maximum fleet scale.

In late May 2026, BYD assumed full financial liability for accidents caused by its urban navigation system. That is not marketing. A company that accepts uncapped legal exposure for a system’s behavior in live traffic is making a statement about what the data has produced.

The limitation is geographic and it is significant. Nearly all of BYD’s dataset is Chinese road environment data. BYD’s international sales are growing, but as a fraction of its 3-plus million domestic ADAS-equipped vehicles, the global footprint remains thin. A model trained on Chinese roads is a model optimized for Chinese roads. That constraint does not disappear with scale.

Scorecard: Volume 10| Quality 6 | Geo Diversity 3 | Infra Control 6 | Cross-Domain 4 | Total: 29/50

Huawei Qiankun: The Invisible Hand

Huawei does not build cars. That is exactly what makes it dangerous.

The Qiankun ADS system crossed 10 billion kilometers (6.2 billion miles) of cumulative assisted driving data on April 19, 2026. In April alone, users covered 565 million miles (910 million kilometers) of assisted driving, with 94.8 percent of monthly active users engaging the system. The installed fleet reached 1.7 million vehicles, with Huawei targeting 3 million installations across 80 vehicle models by end of 2026. The 2026 R&D budget for Qiankun is 18 billion yuan ($2.5 billion), which Huawei states exceeds the combined autonomous driving R&D spend of all other major domestic Chinese ADS suppliers.

None of that is the interesting part.

The interesting part is the partner list: BYD, Dongfeng, FAW, Changan, GAC, BAIC, Audi, Toyota, SAIC-GM-Wuling. Every vehicle across those brands that carries Qiankun feeds data back into the same training pipeline. Huawei is not collecting data from one fleet. It is aggregating data from eight or more fleets simultaneously. That multi-OEM compounding has no structural equivalent anywhere else in the world.

Think about what that means architecturally. A BYD Seagull in Chengdu, a FAW Hongqi in Beijing, an Audi in Shanghai, and a Toyota in Osaka are all contributing training data to the same model. No single OEM partner sees the aggregate. Only Huawei does.

The geopolitical complication is real and unresolved. Qiankun data is concentrated in China. Huawei’s export restrictions limit its ability to expand this architecture into Western markets. The partner list includes Audi and Toyota, but the operational scale of those partnerships outside China is minimal compared to the domestic fleet. That wall is structural, not temporary.

Scorecard: Volume 8 | Quality 6 | Geo Diversity 3 | Infra Control 8 | Cross-Domain 5 | Total: 30/50

Waymo: The Quality Standard

Two hundred million fully autonomous miles (320 million kilometers) on public roads as of February 2026. Approximately 2,500 vehicles. Five U.S. cities. Over 500,000 weekly rides. Every mile logged without a safety driver.

The number looks modest next to Tesla or BYD. The context makes it anything but.

Waymo’s data is qualitatively different from every other dataset in this analysis. Supervised ADAS data, regardless of volume, is data collected under conditions where a human is available to intervene. Waymo’s data is collected under conditions where the system is the only decision-maker, in live commercial service, with real passengers, in real urban environments, facing real consequences.

San Francisco is not an easy test environment. Neither is Los Angeles. The combination of those two cities, plus Phoenix, Austin, and Atlanta generates edge cases that no geofenced test track or simulation produces on demand.

Waymo also maintains a simulation program of 20 billion miles calibrated directly to its real-world deployment environments. Every real-world edge case encountered in San Francisco can generate millions of synthetic variants in simulation. That is a multiplier on 200 million real miles, not a substitute for them.

The limitation is volume and geography. Two hundred million autonomous miles is a fraction of Tesla’s 10 billion supervised miles. The entire dataset is United States only. European road law, Japanese driving culture, and Chinese urban density are not represented.

Scorecard: Volume 5 | Quality 10 | Geo Diversity 4 | Infra Control 8 | Cross-Domain 3 | Total: 30/50

Baidu Apollo Go: China’s Autonomous Proof of Concept

Apollo Go crossed 20 million cumulative rides and 118 million fully driverless miles (190 million kilometers) in February 2026. The fleet operates commercially across 20-plus cities in China, with live international operations in South Korea and Dubai, and European expansion in progress via Uber and Lyft.

The safety claim is the boldest in the industry: one airbag deployment per 7.5 million driverless miles (12 million kilometers). Baidu frames this as exceeding Waymo’s comparable metric. Independent verification is unavailable, but the operating environment makes the claim at least plausible. Wuhan, Shenzhen, Beijing, and Shanghai are not gentle testing grounds.

Apollo Go matters for a reason beyond its own fleet. It is proof that a fully driverless commercial robotaxi can operate at real scale in Chinese urban environments. The question is whether it translates beyond China’s regulatory environment into markets where Waymo and Tesla are competing.

Scorecard: Volume 5 | Quality 9 | Geo Diversity 4 | Infra Control 6 | Cross-Domain 3 | Total: 27/50

GM: The Sleeping Giant Waking Up

GM customers crossed 1 billion cumulative hands-free Super Cruise miles (1.6 billion kilometers) in late April 2026. That number is generated by approximately 750,000 vehicles across 23 models. The OnStar connected vehicle platform has been running for 30 years and connects the entire GM fleet to a data infrastructure that no startup built yesterday can replicate.

Super Cruise data includes pickup trucks, full-size SUVs, luxury sedans, and electric vehicles across price points from $35,000 to $130,000. The variety of vehicle dynamics, load conditions, and driving behaviors in that dataset is genuinely diverse in ways that a single-model fleet is not.

Eyes-off driving is targeting the Cadillac Escalade IQ in 2028. GM is conducting supervised next-generation autonomy testing on public roads in California and Michigan with over 200 test vehicles today. The roadmap is real. The gap to Tesla is also real.

Scorecard: Volume 5 | Quality 5 | Geo Diversity 6 | Infra Control 5 | Cross-Domain 4 | Total: 25/50

Hyundai Motor Group: The Assembled Puzzle

Hyundai’s position in mid-2026 is best described as a serious physical AI program that has not yet produced a measurable dataset to disclose.

The pieces are genuinely compelling. The NVIDIA DRIVE Hyperion partnership announced in March 2026 deploys a group-wide data collection and AI training architecture across Hyundai and Kia fleet vehicles. Motional is targeting fully driverless Level 4 robotaxi service in Las Vegas by end of 2026. The NVIDIA Blackwell AI Factory, announced November 2025, provides training compute at a relevant scale. And the Boston Dynamics acquisition gives Hyundai a humanoid robotics program that could build a vehicle-to-robot data bridge analogous to Tesla’s FSD-Optimus pipeline.

In theory. The bridge has not been built. The data volume has not been disclosed. The Motional Las Vegas service has not yet launched. Hyundai is assembling the right pieces. It has not yet demonstrated that the picture they form is coherent.

Scorecard: Volume 3 | Quality 4 | Geo Diversity 7 | Infra Control 6 | Cross-Domain 5 | Total: 25/50

The Verdict

Set them side by side and the picture clarifies.

Tesla leads among individual organizations, and it is not particularly close. It is the only company scoring high across all five dimensions simultaneously. The global data diversity, owned infrastructure from chip to compute to vehicle, the shared FSD-Optimus training architecture, and a daily accumulation rate that is still accelerating point to a structural position that is genuinely difficult to displace quickly.

The gap between Tesla’s data advantage and its autonomous product at scale remains the central tension. Ten billion supervised training miles and a small commercial Robotaxi fleet are not yet reconciled. That gap is where the competitive story lives.

BYD shocks on volume and almost nothing else. Generating more than four times Tesla’s daily data output is an extraordinary achievement. The geographic wall is the counterweight that contains it. If BYD’s international expansion reaches the point where its ADAS fleet in Europe, Southeast Asia, Latin America, and other markets approaches domestic Chinese scale, volume leadership becomes a global moat. That is a 2028 or 2029 story, not a 2026 one.

Huawei is the answer to a question few analysts are asking. A non-OEM inserted into the data pipelines of multiple manufacturers is building a compound asset that no single OEM can match structurally. The geopolitical ceiling is real, and it is unlikely to disappear soon.

Waymo holds the quality crown. Two hundred million unsupervised autonomous miles beats ten billion supervised miles on one critical dimension. Proof that the system can operate without a human. That is the dimension regulators care about most. It is also the dimension that produces revenue today.

Yet the most important conclusion from this analysis is not that Tesla is winning.

It is that the Physical AI race is increasingly becoming a contest between Tesla and the broader automotive ecosystem.

Tesla possesses the strongest individual moat. The industry possesses the strongest collective moat.

Across hundreds of millions of vehicles, thousands of factories, millions of industrial robots, global supply chains, embedded sensors, dealer networks, logistics operations, and manufacturing systems, the automotive ecosystem is generating physical-world data at a scale that no single company can replicate. The challenge is not access to data. The challenge is converting that data into learning loops.

That distinction matters.

Data sitting in organizational silos is not a moat. Data flowing through a closed-loop learning system is.

Tesla has already built that loop.

The rest of the industry is still assembling it.

The Next 36 Months

Three variables will determine whether these rankings hold.

Geopolitical Data Portability

The China wall separating BYD and Huawei datasets from the rest of the world remains the largest uncertainty in this analysis.

If regulatory harmonization creates pathways for cross-border model development and data sharing, the rankings could change dramatically. If the wall hardens further, those datasets may continue growing domestically while remaining structurally constrained internationally.

Scale alone does not create a global moat. Transferability does.

Unsupervised Deployment Proof

Tesla possesses one of the largest supervised driving datasets ever assembled.

Waymo possesses one of the largest commercially deployed autonomous datasets ever assembled.

Those are not the same thing.

The next phase of the race is not about collecting more supervised miles. It is about proving that those miles translate into systems capable of operating safely without human intervention at meaningful commercial scale.

Whoever achieves dense deployment across multiple major cities first establishes a proof point that no training dataset can substitute for.

The Robotics Bridge

This may ultimately become the most important variable of all.

The organization that successfully closes the loop between vehicle learning and robotic learning gains a compounding advantage that extends beyond transportation.

Driving teaches prediction.

Manufacturing teaches manipulation.

Robotics requires both.

Tesla has openly declared its intention to create a shared learning architecture between vehicles and humanoid robots.

Hyundai possesses many of the pieces through Hyundai Motor Group, Boston Dynamics, Motional, NVIDIA partnerships, and its global manufacturing footprint.

Toyota, Honda, and several Chinese manufacturers possess pieces of the puzzle as well.

The question is no longer whether a vehicle-to-robot learning bridge is possible.

The question is who builds it first at scale.

Final Thought

The data moat wars are not over.

They are barely entering their second act.

Tesla holds the strongest individual position today.

But the broader automotive ecosystem may hold the larger strategic asset.

The future of Physical AI will not be determined by who possesses the most data.

It will be determined by who learns from it fastest.

And that race has only just begun.

All opinions are my own and do not reflect those of my employer.

Jensen Huang declared it at CES in January. The ChatGPT moment for physical AI is here. What he did not say, but the data makes clear, is who is positioned to benefit most.

Not the robotics startups. Not the hyperscalers. Not the AI labs.

The organizations sitting on the deepest structural advantage in the physical AI transition are the same ones most analysts have spent five years writing obituaries for. The automotive OEMs.

This is not a sentimental argument. It is an architectural one.

What Physical AI Actually Requires

Physical AI is not a software problem dressed in hardware. It is a fundamentally different category of challenge than large language models, code generation, or even autonomous driving perception. A physical AI system must perceive the world through sensors, build a model of that world, make a decision under real-world latency and safety constraints, and then execute a physical action. It fails in ways that are costly, visible, and sometimes dangerous.

Training a physical AI system requires three things that are extraordinarily expensive to assemble from scratch.

First, data at physical scale. Not tokens scraped from the internet. Sensor readings, force feedback, spatial geometry, and task outcomes collected in real environments, across real variation, over real time. NVIDIA’s Rev Lebaredian put it precisely at GTC 2026: “For robotics, compute is data. The real world is unpredictable, and we cannot capture enough human-scale data from demonstration.” The physical AI data flywheel spins only when you have the physical infrastructure to generate it.

Second, simulation infrastructure grounded in physics. Sim-to-real transfer, the process of training a robot in a digital environment and deploying it in the physical world, works only when the simulation is accurate enough that the model does not fall apart the moment it encounters real friction, lighting variation, or surface irregularity. That fidelity requires deep knowledge of the exact physical environments where deployment will occur.

Third, deployment infrastructure at scale. A physical AI model that runs in a research lab is worth nothing. Value accrues only when it operates on real production lines, in real vehicles, at the volume and reliability demanded by industrial deployment. FANUC reported a 31% year-over-year increase in AI-related robotic system orders in fiscal year 2025. Automotive EV transition programs drove that surge. According to MarketsandMarkets, the AI perception and software segment of the Physical AI market is projected to reach approximately $15.24 billion by 2032, growing at a CAGR of 47.2%. Broader forecasts that include robotics, autonomous systems, deployment infrastructure, and industrial ecosystems project a market measured in the hundreds of billions, and potentially over a trillion dollars within the next decade. Regardless of methodology, the direction is unmistakable. Physical AI is emerging as one of the fastest-growing technology markets of the next decade. The companies that ultimately capture that value will not necessarily be the ones that build the best models in isolation. They will be the organizations capable of deploying those models at scale in complex physical environments.

Automotive OEMs control all three inputs. Most other industries do not.

A Century of Physical Environment Data

The most underappreciated asset an automotive OEM holds in the physical AI race is not its factories. It is the accumulated knowledge of what happens inside them.

Toyota’s Georgetown, Kentucky facility has been running since 1988. BMW’s Spartanburg plant since 1994. The HMGMA Metaplant in Georgia since 2024. Each of these facilities represents not just square footage but decades of production process data, failure modes, ergonomic constraints, and quality specifications embedded in the physical workflow.

When Hyundai’s Robotics Metaplant Application Center opens in 2026, it does so not as a blank-slate research facility. It opens as what Boston Dynamics CEO Robert Playter explicitly calls a “data factory,” designed to build the world’s most complete dataset for training humanoid manufacturing skills. That data factory is seeded with Hyundai’s production knowledge. The robots are not starting from zero. They are inheriting decades of process intelligence.

This matters because the core technical challenge in physical AI training is not model architecture. It is data quality and domain specificity. A robot trained on generic manipulation tasks transfers poorly to the specific geometry of a vehicle body panel, the exact torque requirement of a fastener installation, or the access constraints of an under-vehicle assembly task. The specificity of OEM production data is, itself, a structural moat.

Toyota’s Woven City, which launched in September 2025 on the former grounds of the Higashi-Fuji plant, makes this logic explicit at city scale. The AI Vision Engine Toyota and Woven by Toyota unveiled in April 2026 is a large-scale foundation model designed to understand and respond to real-world conditions across the entire facility in real time. The system draws on inputs from mobility infrastructure, resident behavior, and sensor networks. It is a physical AI training environment, funded and operated by an automaker, that no software company could replicate because no software company operates an instrumented urban-scale mobility environment designed specifically for physical AI experimentation and deployment.

The Autonomous Driving Dividend

There is a transfer of technology underway that most analysts have missed because they are watching the wrong frontier.

The perception, sensor fusion, and edge inference stack that automotive OEMs built for autonomous driving is directly transferable to factory floor physical AI. The computational problem of a vehicle understanding its environment and making real-time decisions is structurally analogous to the problem of a robot understanding a factory floor and executing a precision task. The hardware is different. The physics engine is different. The domain ontology is different. But the architecture is the same.

This means that OEMs who invested heavily in ADAS and autonomous driving over the past decade are not sitting on stranded assets. They are sitting on a trained infrastructure base for physical AI development.

Mobileye’s Professor Amnon Shashua framed the industry evolution at CES 2026 as a progression from L2++ ADAS through consumer autonomous vehicles to robotaxi operations. What he described, without naming it, is a capability stack that compounds across each transition. The same sensor fusion expertise that makes a production vehicle’s ADAS more reliable is the expertise that enables a humanoid robot to navigate a factory floor around human workers.

General Motors announced at GTC March 2025 its adoption of NVIDIA Omniverse to enhance factories and train platforms for material handling, transportation, and precision welding. That announcement came from the same organization that has been running Super Cruise across 750,000 miles of mapped North American highways. The perception and prediction models embedded in Super Cruise are a foundation, not a dead end.

Arm restructured its business units in 2025 to place automotive and humanoid robotics under a single division. That structural decision reflects a technical reality that OEMs are better positioned to exploit than anyone: the silicon and software that powers autonomous driving powers physical AI.

Vertical Integration at Manufacturing Scale

Physical AI does not win on model performance alone. It wins on deployment economics. And deployment economics are determined by manufacturing scale, supply chain integration, and the ability to mass-produce the hardware the AI runs on.

Hyundai’s position in the physical AI race is the most instructive case study available. The group is not simply an early customer of Boston Dynamics. It is the majority shareholder. Hyundai Mobis, the group’s automotive parts affiliate, manufactures the actuators that power Atlas’s joints. Those actuators represent one of the most important and expensive subsystems in a humanoid robot. Hyundai does not just buy physical AI. It manufactures the physical AI supply chain.

Hyundai has stated that it aims to establish scalable production capacity for up to 30,000 robot units annually by 2028. It is an automotive manufacturer applying mass production logic to a new product category. This is exactly the advantage that the automotive industry spent 100 years developing, the discipline of producing complex, precision-engineered, safety-critical physical systems at volume with cost-down curves and yield management. No AI lab, no software company, and very few pure-play robotics firms have access to that institutional knowledge.

Mercedes-Benz’s investment in Apptronik, described internally as a “low double-digit million euro amount,” is the mirror of the Hyundai model from a different angle. Rather than owning the robot manufacturer, Mercedes is applying its manufacturing infrastructure and production process expertise to train the Apollo robot in its Berlin-Marienfelde Digital Factory Campus. The transfer of expertise runs from experienced production workers through teleoperation and augmented reality interfaces into Apollo’s training data. Execution economics, as Nomura’s April 2026 physical AI report observed, will ultimately determine the winners. Manufacturing scale, supply chain integration, and deployment readiness are the criteria. Those criteria describe automotive OEMs, not robotics startups.

The Factory as a Living Lab

The world’s most sophisticated physical AI training environment is not a research lab. It is an automotive factory.

Consider what an automotive production facility actually represents. It is a high-mix, high-variability environment where physical tasks must be performed with sub-millimeter precision, under strict cycle time constraints, in collaboration with human workers, across temperature variation, part variation, and equipment degradation. It is instrumented with decades of quality data. It runs 24 hours a day.

That environment is more demanding, more varied, and more data-rich than any robotics research lab ever built. And every major OEM already owns dozens of them.

BMW Group’s deployment of NVIDIA Omniverse for factory planning, which BMW projects could reduce production planning costs by up to 30%, is not primarily a cost story. The digital twin of a BMW production facility that BMW is building with NVIDIA is simultaneously a training environment for the physical AI systems that will operate inside it. BMW presented this capability at GTC Paris in 2025. The technical integration of BMW’s factory planning applications with OpenUSD and Omniverse means that the digital and physical environments are synchronized, and the data flowing between them feeds both operational optimization and AI model training.

Mercedes-Benz’s Digital Factory Campus in Berlin made this explicit: Apollo robots were not placed in a demonstration environment. They were placed in a production environment, collecting data and performing autonomous operations alongside production workers running actual vehicle manufacturing tasks. The distinction matters. A robot that learns in a research facility transfers poorly to a production environment. A robot that learns in a production environment is production-ready from the start.

Deloitte’s 2026 Manufacturing Industry Outlook projected that physical AI adoption among manufacturers could more than double within two years, rising from 9% to 22% of respondents. The companies best positioned to capture that transition are the ones that already operate at the intersection of complex physical processes and advanced automation. Automotive OEMs are not late entrants to this market. They are, by structural default, its most credible practitioners.

The Bidirectional Flywheel

The most durable competitive advantage in any AI market is a data flywheel: a self-reinforcing cycle where deployment generates data, data improves models, better models expand deployment, and wider deployment generates more data.

Tesla’s autonomous driving program is the canonical example. By Q1 2025, Tesla had accumulated over four billion miles of real-world FSD data from its customer fleet. Every vehicle sold is both a product and a data collection device. The fleet funds its own training infrastructure.

Automotive OEMs are building the manufacturing equivalent of that flywheel, and it runs in both directions simultaneously.

In one direction: the robots deployed on factory floors generate training data that improves the next generation of physical AI models. Hyundai’s RMAC is explicitly designed as the primary reference deployment for Atlas, with the understanding that the training data generated there will inform every subsequent deployment at scale.

In the other direction: the vehicles produced in those factories, as they accumulate ADAS data, autonomous driving miles, and sensor observations across diverse global operating conditions, feed back into the physical AI research stack. The vehicle fleet and the factory robot fleet become co-training infrastructure.

Few organizations control both sides of that flywheel at global industrial scale. Automotive OEMs are among the strongest examples.

The Strategic Implication

The physical AI market is growing at a CAGR of 47.2% through 2032. The industrial robotics segment within it is growing at 56.7%. Automotive OEMs and electronics manufacturers together accounted for over 58% of enterprise physical AI contracts in 2025.

Those numbers suggest a gold rush. The instinct of most observers is to watch the startup ecosystem, the robotics specialists, and the AI labs for the signal on who will win.

The correct observation is that the organizations with the deepest moat in physical AI are the ones that have been operating complex physical systems at scale for decades. They have the production environment data. They have the sensor fusion expertise from autonomous driving. They have the manufacturing scale to produce the hardware at cost. They have the factories to serve as living training labs. And they are building the flywheels.

The automotive industry has spent the past decade being told it is structurally disadvantaged in the software era because software companies think differently, move faster, and do not carry the legacy of hardware-first organizations.

That critique was always partially correct and always incomplete.

In the physical AI era, the advantage inverts. The ability to operate in the real world, build at hardware scale, and generate grounded training data from production environments is not a legacy liability. It is the foundation of a structural moat that late entrants cannot buy their way into.

The incumbents have the moat.

The question is whether they know it.

All opinions are my own and do not reflect those of my employer.

Forty percent of owners received an over-the-air update last year. Only 27 percent said it improved their vehicle. The updates were associated with a 14 percent increase in reported problems. The mechanism sold as the cure is correlating with more complaints, not fewer. For a decade the industry pitched OTA as the feature that would finally bend the depreciation curve. Your car would improve after you bought it, the way your phone does. The 2026 data says the opposite is happening.

The JD Power 2026 U.S. Vehicle Dependability Study, released on February 12, found that long-term dependability has fallen to its worst level since the study was redesigned in 2022. The industry average climbed to 204 problems per 100 vehicles, up two from 2025. The result is built on responses from 33,268 owners of 2023 model-year vehicles after three years of ownership, fielded between December 2024 and November 2025. Lower is better. The number has now moved the wrong way for three consecutive years.

The detail that should stop every software-defined vehicle program is buried under the headline. Fifty-eight percent of owners who received an update noticed no difference at all. The remaining 15 percent noticed something worse. The 2.5 PP100 increase may sound small until you realize it compounds across a connected fleet measured in millions.

The pattern gets worse the more software you add. Premium vehicles, the segment that leaned hardest into software differentiation, performed worse than mass market brands, jumping eight points to 217 PP100. Plug-in hybrids, the most electronically complex powertrain, ranked dead last at 281. Gas-powered vehicles, the least software-defined thing on the lot, were the most dependable at 198. The relationship is uncomfortable for anyone selling a roadmap built on features delivered as code. More software, more problems.

This is not one survey’s noise. The Omdia and Sonatus 2026 SDV Reality Check, fielded across 559 automotive professionals in seven markets in March and April, names what it calls an OTA trust crisis. In that study, vehicle reliability and safety have overtaken cybersecurity as the single biggest barrier to OTA deployment. Two independent studies, built on different respondents and different methods, arrived at the same conclusion in the same quarter.

The root cause is not lazy engineering. It is a borrowed operating model applied to the wrong substrate. Continuous deployment was born in SaaS, where a bad release rolls back in minutes and the blast radius is a browser session. A vehicle fleet is none of those things. It is millions of physical, safety-critical, long-lived assets running heterogeneous silicon that degrades in the field, across climates, duty cycles, and hardware revisions, with no uniform test bench underneath them.

The validation surface is effectively infinite. What passes in the lab meets a combinatorial reality on the road that the lab never modeled. The owner experiences the gap as a defect.

The financial logic that justified all of this is now inverting. OTA was supposed to drive warranty costs down by replacing dealer visits with remote fixes. Instead the update channel is generating new failure modes faster than it retires old ones. A regression shipped to a connected fleet does not stay contained. It becomes a fleet-wide event, and the brands that promised the most improvement are absorbing the steepest reputational cost when the improvement does not arrive.

The industry response so far is more telemetry, not more restraint. JD Power is adding year-round data collection and verified repair data in 2027 to catch issues earlier. Better detection is welcome. It does not touch the deployment culture that ships to the field first and validates afterward. The OEMs that recover their dependability scores will be the ones that treat an OTA release to a safety-critical fleet with the governance discipline of a recall, not the release cadence of an app store.

I spent years inside enterprise software governance before I worked in automotive, and the failure mode is familiar. I have sat in rooms where release velocity was the only metric on the board, where validation was treated as a gate to clear rather than a discipline to maintain. When you industrialize a deployment pipeline without industrializing the validation that sits behind it, you do not get faster quality. You get faster defects. The vehicle is the most demanding deployment target in consumer technology. Right now it is being treated like one of the easiest, and the owners are filing the bug reports three years later.

The strategic question for 2026 is not whether to ship software over the air. That decision is made. The question is whether your release process can earn the trust that the marketing already spent. What would change if your next OTA release required the same sign-off authority as a recall?

All opinions are my own and do not reflect those of my employer.

On May 21, 2026, Waymo suspended robotaxi service across five cities. A software patch pushed two weeks earlier had failed. A Waymo vehicle drove into standing water in flooded Midtown Atlanta and stalled for an hour. Waymo acknowledged it has no permanent fix.

This is Waymo’s third software recall since February 2024. Read that sentence again.

The first recall covered 444 vehicles after two robotaxis in Phoenix independently crashed into the same towed vehicle. The second covered 1,212 vehicles after collisions with parking gates and telephone poles. The current recall affects 3,791 vehicles across every city where Waymo operates commercially.

Each recall sounds like a solvable edge case. Together, they describe a system that cannot reliably handle the real world.

The Sensors Cannot See What Matters

Georgia Tech researchers went on record last week. LiDAR and radar cannot estimate how deep a puddle is. That is not a calibration issue. It is a physics issue. Neither technology was designed to measure flood depth.

Srinivas Peeta, who leads Georgia Tech’s transportation engineering program: Knowing the depth of standing water is a prerequisite for deciding whether to cross it. No current sensor suite in commercial AV operation solves that problem.

Waymo’s vehicles use the most sensor-rich commercial autonomous driving stack in public operation. That is exactly why the failure matters. If the best-equipped fleet in the world cannot solve this, the industry does not have a narrow exception. It has an unsolved problem dressed up as a solved one.

What the Recall Documents Actually Say

The NHTSA recall filing is worth reading carefully. Waymo stated its software may allow a vehicle to slow and then drive into standing water on higher-speed roadways. The interim remedy updated weather-related constraints and vehicle maps. The company said it was still working on a permanent solution.

The Atlanta incident occurred with no flash flood warning in effect. Waymo’s geofencing approach depends partly on formal National Weather Service alerts. Atlanta flooded before those alerts arrived. The gap between data systems and real-world conditions swallowed the patch.

Two active federal investigations into separate Waymo failure modes remain open at NHTSA. One covers a January 2026 incident in which a Waymo vehicle struck a child near a Santa Monica elementary school. On the same day as Atlanta, Waymo separately suspended freeway rides in four cities. Its vehicles struggled in highway construction zones.

The Regulatory Gap Nobody Is Talking About

No federal regulator requires an AV operator to demonstrate flood navigation before launching in a city that floods. Cities being added to Waymo’s expansion map have no standard requiring vehicles to handle local weather conditions. That is a structural gap, not a minor omission.

Houston floods. Atlanta floods. San Antonio floods badly enough that a Waymo vehicle was washed into Salado Creek in April. These are not extraordinary events. They are seasonal realities in the markets Waymo chose for commercial operation.

The absence of weather-condition testing standards is not an oversight that will be quietly fixed. It is a mismatch between the pace of commercial AV deployment and the pace of safety validation framework development. That mismatch will produce more incidents.

What This Means for the Industry

Every AV program watching Waymo’s recall sequence should draw a specific conclusion. The failure is not that Waymo deployed too early in terms of general capability. The failure is simpler. The edge case catalog for extreme weather was incomplete. The markets Waymo chose have regular extreme weather.

For OEMs building toward Level 3 and Level 4 systems, the Waymo flood sequence is a free lesson. Operational design domains that do not explicitly bound weather conditions have an unknown failure surface. That is a liability, not a planning assumption.

The voluntary recall framework was built for hardware defects. A fleet can push a patch to 3,791 vehicles in hours. When that patch fails and no permanent fix exists, the recall framework has run out of tools. Existing frameworks were not designed for it.

Waymo provides more than half a million trips per week. Its injury rate per mile is lower than the average human driver. None of that changes what Atlanta revealed. The most advanced commercial robotaxi fleet in the world pulled its cars off the road. Rain arrived before the warnings did. The question is whether the next recall will arrive before the next flood does.

Which AV program is stress-testing for weather conditions that arrive faster than the warnings?

All opinions are my own and do not reflect those of my employer.

The autonomous driving industry has spent fifteen years arguing about sensor stacks. Lidar versus cameras. Rule-based planners versus learned planners. Waymo’s expensive caution versus Tesla’s lean-and-iterate philosophy. None of those debates are settled. But a quieter fight has been building in the open-source community, and it just got a working group.

The Autoware Foundation announced the formation of a new robotaxi working group focused entirely on end-to-end AI for point-to-point autonomous mobility. The headline partners are TIER IV, Arm, the Technical University of Munich, and Carnegie Mellon University. The licence is Apache 2.0. The ambition is to build a production-grade, globally deployable robotaxi stack that any developer or company can use, modify, and improve without royalties or vendor lock-in.

That is a significant technical and commercial wager. It deserves a serious look at what it means technically, what it actually requires to succeed, and where the real risks sit.

What End-to-End Actually Means Here

The term “end-to-end AI” gets used loosely. In this context it has a precise meaning. A traditional modular autonomous driving stack breaks the problem into discrete pipeline stages: perception, prediction, planning, and control. Each stage has explicit rules and hand-coded interfaces. Engineers can read the code and understand exactly why the car turned left. The tradeoff is brittleness. Edge cases that nobody wrote a rule for cause failures.

End-to-end systems do something different. They take raw sensor data and produce driving commands directly, using a single learned model trained on large datasets. There are no explicit handoff points between perception and planning. The model figures out the relevant representations internally. This is roughly how a vision-language-action model, or VLA, works in autonomous driving contexts. The “vision” component processes camera and sensor streams. The “language” component encodes high-level reasoning. The “action” component outputs steering, throttle, and braking commands.

TIER IV published an end-to-end architecture for Level 4+ autonomy in July 2025 that makes the tradeoffs explicit. Their approach uses diffusion model-based machine learning across a sequence of driving tasks, covering prediction of surrounding objects and generation of vehicle trajectories. Importantly, TIER IV did not abandon rule-based components entirely. They integrated rule-based logic in parallel to preserve interpretability and operational stability. That hybrid structure matters for safety certification, and I will come back to it.

The Autoware Foundation’s new working group is building on that foundation and pushing further. The stated approach involves world foundation models and vision-language-action models, language that aligns with the most current academic research. A paper published in April 2026 on arXiv, titled “Learning Vision-Language-Action World Models for Autonomous Driving,” captures the core problem well. VLA models have achieved notable progress in integrating perception, reasoning, and control within a unified multimodal framework, but they often lack explicit modeling of temporal dynamics and global world consistency. The Autoware approach is trying to solve exactly that gap, building models that can imagine forward in time and reason about what they have imagined.

DeepRoute.ai presented a 40-billion-parameter VLA Foundation Model at NVIDIA GTC in March 2026 that integrates perception, reasoning, and action into a unified architecture. That gives a sense of the computational ambitions the field is chasing. The Autoware version will need to run on production hardware, which brings the silicon question into sharp focus.

Why Arm’s Involvement Changes the Calculus

Arm is not a software company. It is the compute architecture under almost every automotive SoC on the market. Tesla’s FSD chip, NVIDIA’s DRIVE AGX Thor, Qualcomm’s Snapdragon Ride, and Renesas’s R-Car series all build on Arm IP. When Arm joins a working group, the implicit signal is that the software being developed will have a credible path to running on the silicon that actually ships in production vehicles.

Arm launched its Zena Compute Subsystem for Automotive in June 2025, designed to reduce chip engineering effort by roughly 20% per project and accelerate time to market for custom SoCs. The Arm AE processor family is explicitly designed to support functional safety requirements. NVIDIA’s Jetson Thor and DRIVE AGX Thor platforms, both built on Arm Neoverse V3AE CPUs, power some of the most advanced autonomous vehicle platforms currently in testing.

The practical implication for Autoware’s robotaxi effort is significant. Open-source software is only genuinely open if it runs efficiently on accessible hardware. A system that requires custom NVIDIA clusters to train and DRIVE Orin to infer is not really a global open ecosystem. Arm’s participation suggests the working group intends to target silicon-agnostic deployment, which matches the cross-platform design principle in the announcement. That is harder than it sounds. Diffusion models and large VLA architectures have significant inference compute requirements. Making them run well across different SoC families, from Arm-based automotive chips to AMD Instinct GPUs in the training cloud, requires disciplined model design and careful quantization work.

AMD Silo AI signed a collaboration with the Autoware Foundation in December 2025 specifically to accelerate the end-to-end AI model training and deployment pipeline using AMD Instinct and Radeon Pro GPUs with ROCm software. Autoware already has 500+ companies, 30+ vehicle types, and deployments in 20+ countries on its current modular stack. The end-to-end extension needs to inherit that hardware flexibility, not abandon it.

The Academic Layer: TUM and CMU Are Not Window Dressing

Technical University of Munich and Carnegie Mellon University are the two university partners named in the announcement. Their involvement is worth understanding beyond the name recognition.

TUM hosted the Autoware Foundation General Assembly in December 2025 at the FTM Institute of Automotive Technology. Their autonomous vehicle systems lab has been actively contributing to Autoware codebase, including a real-time motion planning module and trajectory forecasting integrations. Professor Johannes Betz, who chairs Autonomous Vehicle Systems at TUM, is directly involved in TIER IV’s European testing program. Under the March 2026 expansion, a Volkswagen T7 Multivan equipped with the new Autoware end-to-end stack is conducting safety evaluations across urban driving scenarios in and around Munich.

CMU’s involvement is grounded in equally concrete work. Professor Raj Rajkumar, the George Westinghouse Professor in Electrical and Computer Engineering, called Autoware a foundational technology for Level 4+ autonomy in the March 2026 TIER IV announcement. CMU is running Hyundai IONIQ 5 robotaxi tests in Pittsburgh urban areas, including routes between Pittsburgh International Airport and the CMU campus. Those routes are not simple. Pittsburgh’s traffic patterns, hill gradients, and weather variability are exactly the kind of diverse conditions that stress-test generalization claims in end-to-end models.

That is the function universities serve here that pure industry labs cannot replicate as easily. Academic partners can publish failure modes. They run independent evaluations. They produce graduate students who understand the system deeply and contribute back to the codebase. The Autoware ecosystem has developed this model across what it calls Centers of Excellence, and the robotaxi working group appears to be following the same structure with higher stakes research partners.

The Safety Architecture Is the Hardest Problem

The announcement uses two terms worth pulling apart: “introspectable driving policies” and “safety guardian.” These are not marketing phrases. They point at one of the most difficult unsolved problems in deployed autonomy.

End-to-end neural networks are opaque by nature. A modular system can be interrogated. You can inspect the output of the perception module, check the planner’s cost function, and trace a decision back to a specific rule. A neural network that goes directly from camera frames to steering commands does not provide that kind of interpretability by default. ISO 26262 and ISO 21434 both assume some degree of functional decomposition. Certification bodies need to understand what a system is doing and why.

TIER IV’s hybrid architecture addresses this partially by keeping rule-based components running in parallel with learned components. The “introspectable driving policy” framing in the Autoware announcement suggests something more ambitious: a model that can explain its own decisions, not just one where a separate rule system can override it. That aligns with the direction NVIDIA’s Alpamayo open-source AV model family is pursuing. Jensen Huang described it as the start of reasoning-capable systems that can think through rare scenarios and explain their driving decisions.

The “safety guardian” concept is architecturally similar to what TIER IV calls a parallel safety system. The learned end-to-end policy proposes actions. A separate, more constrained and formally verifiable system monitors those proposals and can intervene. This is not a new idea. It mirrors the structure used in aviation flight envelope protection systems. The challenge in autonomous driving is defining the intervention boundaries with enough precision to be useful without being so conservative that the guardian overrides the learned policy constantly and destroys the system’s ability to handle complex scenarios.

A verification study published in May 2025, conducted by researchers at Japan Advanced Institute of Science and Technology, found that Autoware fails to consistently meet safety standards in high-speed scenarios and sudden cut-in situations, primarily due to inaccurate prediction. That was the modular stack. End-to-end models may handle sudden cut-ins differently because they learn from large behavioral datasets rather than following explicit rules, but the study is a useful reminder that generalization claims require serious empirical validation, not just architectural confidence.

Why Apache 2.0 Is a Strategic Choice, Not Just a Licence

The robotaxi market today is dominated by companies that treat their software stacks as competitive moats. Waymo does not open-source its planning architecture. Cruise did not share its sensor fusion approach. BYD and the Chinese AV incumbents are building national ecosystems with national supply chains. The proprietary model produces fast iteration within organizations and slow diffusion across the industry.

Apache 2.0 breaks that logic. It allows commercial use without requiring derivative works to be open-sourced. A Toyota subsidiary or a Tier 1 supplier can take the Autoware robotaxi stack, modify it for a specific vehicle platform, deploy it commercially, and never publish those modifications. That is a deliberate choice to maximize adoption over contribution. The Autoware Foundation is betting that a large, commercially active user base generates more real-world data, more edge case discovery, and more hardware-specific optimization work than a smaller community of committed open-source contributors.

Neolix Technologies, which deployed more than 15,000 autonomous delivery vehicles globally, joined the Autoware Foundation as a Premium Member in January 2026 specifically to participate in the Low-Speed Autonomy Working Group. BrightDrive demonstrated real-world validation of Autoware end-to-end AI models on production autonomous vehicle platforms operating on public roads in December 2025. These are not prototype experiments. They are early commercial signals that the open-source foundation is reaching escape velocity on production deployments.

The robotaxi working group is targeting a different and harder operational design domain than low-speed logistics. City driving at highway speed, across connecting roads, without predefined operational zones, is several orders of magnitude more complex. But the commercial model is the same. Open the stack, build the community, let commercial deployment fund the data flywheel.

What This Means for the Industry

Japan has a particular stake in this. TIER IV is a Tokyo company. The Autoware Foundation has deep roots in Japan’s automotive and technology ecosystem. TIER IV’s domestic plan involves deploying the new end-to-end stack at 50 locations across Japan starting in early 2026. That is a live fleet running the same codebase that the new working group is extending. Feedback from those deployments will flow directly into the open-source development process.

For Asia-Pacific OEMs and Tier 1 suppliers watching this, the question is positioning. The proprietary AV stack path requires either building from scratch, which is expensive and slow, or licensing from a major player, which creates vendor dependency and competitive exposure. Autoware offers a third option: adopt an open foundation, differentiate on vehicle integration, sensor calibration, domain-specific training data, and fleet operations.

That is the same choice that Android created for mobile handset makers a decade ago. Not every company that adopted Android won. But every company that tried to build a proprietary smartphone OS from scratch, without the network effects of a shared platform, found the economics brutal.

The end-to-end AI layer is where the industry is heading. The Autoware Foundation is building that layer in the open, with serious academic partners, real silicon partnerships, and a commercial adoption model that does not require contributors to give away their differentiation.

The safety problem is real and unsolved. The compute requirements are significant. The regulatory path for Apache 2.0 software in safety-critical vehicles is still being negotiated in most markets. Those are genuine risks, and anyone building a deployment timeline on optimistic assumptions about any of them is making a bet, not a plan.

But the technical direction is correct. And the coalition is real. That puts this effort in a different category from the many open-source autonomy announcements that produced GitHub repositories and not much else.

Watch the CMU and TUM data releases. Watch the TIER IV Japan deployment results. Watch what Arm contributes at the silicon level. Those will tell you whether this is architecture or ambition.

The Autoware Foundation GitHub repository has 11,400 stars and 3,600 forks as of May 2026.

The main repository is available at github.com/autowarefoundation/autoware under Apache 2.0.

All opinions are my own and do not reflect those of my employer.

Mary Barra did not bury the lead. During GM’s Q1 2026 earnings call, she opened with a number that had nothing to do with truck margins or tariff offsets. “Today, nearly 90 percent of the code written by our autonomy team is generated by AI.” She framed it as a badge of honor. The analysts moved on to guidance questions. The automotive engineering community did not.

That figure deserves a long look. Not because it is shocking that AI writes code. Every major software team uses AI coding assistance now. The difference here is the application. GM is not building weather apps or voice assistants. It is building the software stack that will decide whether a Cadillac Escalade IQ, in 2028, can be trusted to keep a driver’s eyes off the road at highway speed. That changes the risk calculus entirely.

What GM Is Actually Betting On

The context matters. GM announced the next-generation Super Cruise system in October 2025 at its GM Forward event in New York. The current Super Cruise is Level 2: hands-free, eyes-on. The new system is targeting Level 3: hands-off, eyes-off. It will debut in 2028 on the Cadillac Escalade IQ. GM has committed to expanding it across ICE and electric vehicles and multiple brands.

The hardware spec combines lidar, radar, and cameras. That combination is deliberate. GM’s executive vice president of global product, Sterling Anderson, was direct about it: cameras alone do not provide enough precision for eyes-off operation. The multi-sensor approach is more expensive and more reliable. It also draws a visible contrast with Tesla’s vision-only philosophy.

The platform enabling all of this is SDV 2.0, GM’s new centralized computing architecture. It bundles powertrain, steering, infotainment, and safety functions on a single high-speed processor. GM’s own figures for the performance leap are striking. The new platform delivers 10 times more over-the-air software update capacity, 1,000 times more bandwidth, and up to 35 times more AI performance for autonomy-related functions compared to the architecture it replaces.

That architecture is also where the 90 percent AI-generated code figure lands. GM is simulating roughly 100 years of human driving every single day in a digital environment to stress-test the code before it touches a public road. Real-world testing in California and Michigan with over 200 test vehicles began in March 2026.

Why 90 Percent Is a Real Question, Not a Headline

The number is legitimate. AI-assisted coding has moved from autocomplete to agentic software engineering with astonishing speed. By 2026, tools like GitHub Copilot operate asynchronously: they read a codebase, write an implementation, run the test suite, diagnose their own failures, iterate, and tag a developer for review only when tests pass. The March 2026 agentic architecture overhaul at GitHub made this practical for enterprise software teams.

For a large autonomy development organization working against a 2028 launch timeline, AI code generation is a rational choice. It accelerates development velocity. It reduces the cost of exploring design alternatives. It makes large-scale simulation-driven iteration feasible in ways that human-only development pipelines cannot match.

The problem is that automotive software is not general enterprise software. It is safety-critical software. And the standards that govern safety-critical automotive software were written for a world of human engineers producing deterministic, traceable, verifiable code.

ISO 26262 is the international functional safety standard for automotive electrical and electronic systems. Its core assumptions are sequential: requirements are complete and unambiguous, software behavior is deterministic, and failures are systematic and traceable to specific code. The standard was designed for a world where engineers write code, can explain every line, and can prove through documentation and testing that the system behaves as specified under all relevant conditions.

AI-generated code does not conform to those assumptions cleanly. A large language model produces code statistically. It generates the most probable implementation given the prompt and the codebase context. It does not reason about edge cases the way a safety engineer does. Research from 2025 found that roughly 40 percent of GitHub Copilot solutions to security-critical coding tasks contained vulnerabilities ranked among the most dangerous software weaknesses by MITRE.

That is not an argument that AI-generated code is necessarily unsafe. The automotive industry is already addressing this through ISO/PAS 8800, which was published specifically to define safety requirements when AI technologies are used in road vehicles. And AI-generated code is not inherently worse than human-written code. The same 2025 research found that in comparative studies, AI tools did not introduce more code vulnerabilities than human developers across most categories.

The argument is about verification. If 90 percent of the code is AI-generated, the human review and validation load on the remaining engineering team does not decrease proportionally. It increases. Every AI-generated function in a safety-critical system needs to be understood, reviewed, tested, and certified by a human engineer who takes responsibility for it. The question GM has not answered publicly is whether its validation pipeline has scaled to match its code generation velocity.

The Simulation Argument

GM’s answer to the verification question is the simulation pipeline. Simulating 100 years of driving per day is a real capability, not a marketing claim. High-fidelity simulation environments running on cloud infrastructure can generate enormous scenario libraries, inject rare events, and test system behavior at a scale no physical test fleet could match.

This is where the Cruise legacy becomes an asset. When GM shut down Cruise’s robotaxi operation in late 2023, it retained the technology and the institutional knowledge. Cruise had accumulated more than five million fully driverless miles of real-world operational data. That data, combined with GM’s 700 million Super Cruise miles without a reported crash attributed to the system, represents a substantial training and validation foundation.

The simulation approach has real limits, though. Scenarios the simulation was not designed to generate cannot be tested. Edge cases that require physical interaction, sensor degradation under specific weather conditions, or failure modes triggered by interactions between physical hardware and software are difficult to replicate faithfully in simulation. The Boeing 737 MAX investigation produced extensive documentation of how simulation-validated software systems can behave differently on physical hardware under conditions the simulation did not anticipate. That comparison is uncomfortable. It is also relevant.

What This Means for the Industry

Every major OEM is running AI-assisted development pipelines. GM is simply the first to say it publicly at this scale, and to frame it as a competitive advantage on an earnings call. Toyota, Volkswagen, Hyundai, and others are running the same AI-assisted development pipelines. Every major Tier 1 supplier is doing it. The Mercedes-Benz CLA, which launched in Q1 2026 in the US, uses NVIDIA’s DRIVE Level 2+ stack. NVIDIA’s approach involves training neural networks on vast datasets and deploying them with a parallel safety monitor. That architecture does not require every function to be hand-coded, but it does require the safety monitor to be formally specified and verified.

The industry is collectively moving toward a model where AI generates code, simulation validates behavior, and human engineers focus on architectural review, safety case construction, and exception handling. That model is not inherently wrong. It may be the only model that produces competitive autonomous driving systems at the pace the market demands.

The honest risk is not the AI. It is the institution. When AI code generation produces a 90 percent utilization rate, the organizational incentive becomes maintaining that productivity. Safety review cycles create friction. Schedule pressure compresses validation timelines. The engineers responsible for catching AI-generated errors are often the same engineers who are being measured on delivery speed.

GM has 600,000 miles of mapped hands-free roads in North America today. The eyes-off system will start on approved highways in states where Level 3 autonomous driving is legal. California and Nevada are the named initial targets. That phased deployment is the correct engineering approach: demonstrate in controlled domains before expanding operational design domains.

The Certification Conversation Nobody Is Having Publicly

The industry needs a public conversation about what certification of AI-generated safety-critical code actually means. ISO/PAS 8800 exists. SOTIF, the Safety Of The Intended Functionality standard, addresses scenarios where system behavior is technically correct but produces unsafe outcomes. These frameworks are necessary and they are evolving.

What they do not yet address clearly is the specific case where the majority of a safety-critical codebase was generated by a non-deterministic model and validated primarily through simulation rather than formal verification. That is a novel situation. It is not covered by existing precedent in aerospace, rail, or nuclear safety engineering, all of which have faced analogous transitions and resolved them through conservative deployment, extensive physical testing, and long regulatory engagement.

Barra’s 90 percent figure should be the opening line of that industry conversation, not just an earnings call statistic. The regulators, the certification bodies, the standards organizations, and the OEMs all need to be in the same room with the same shared understanding of what is being deployed, how it was verified, and what happens when it encounters a scenario the simulation did not generate.

GM is doing serious work. The SDV 2.0 architecture is real engineering. The simulation pipeline is real capability. The 2028 Escalade IQ deployment on approved highways is a reasonable, bounded first step.

The 90 percent number is real. It deserved more than 30 seconds on an earnings call.

All opinions are my own and do not reflect those of my employer.

I spent years inside the automotive industry, though not in the product or engineering teams where these decisions were made. My vantage point was adjacent: technology leadership, infrastructure, corporate functions. Close enough to watch the connectivity wave arrive. Not close enough to have been in the room where the security tradeoffs were decided.

What I can say is that the urgency of this problem was not visible from where I sat. That matters. Because if it was not visible to someone in a senior technology role at a major OEM, it was not visible enough.

I want to start with a number that should unsettle anyone in the automotive industry.

Thirty seconds.

That is how long it took a team of security researchers, in 2024, to take full remote control of any Kia vehicle manufactured since 2013. Not with physical access to the car. Not with specialized hardware. With a license plate number and a laptop. Unlock the doors. Start the engine. Track the vehicle in real time. Access the owner’s name, home address, phone number, and email. All of it. In thirty seconds.

Kia patched it. But the same research team had found identical vulnerabilities, in the same year, in Acura, BMW, Ferrari, Genesis, Honda, Infiniti, Mercedes-Benz, Nissan, and Rolls-Royce. Sam Curry, one of the lead researchers, put it plainly afterward: the same issues keep surfacing, over and over, across the entire industry. He was not talking about Kia. He was talking about an entire industry’s relationship with software security.

The Scale of What Is Actually Happening

Upstream Security published its 2026 Global Automotive and Smart Mobility Cybersecurity Report in February. The numbers document a material escalation.

In 2025, researchers catalogued 494 publicly reported cybersecurity incidents across the automotive and smart mobility ecosystem worldwide. That figure only counts confirmed public disclosures. The actual number is higher. Ransomware incidents more than doubled year over year, accounting for 44% of all reported cases. 92% of all attacks were conducted remotely. 86% required no physical access to the vehicle at all. 67% targeted telematics systems, cloud platforms, and APIs. 68% resulted in data or privacy breaches.

VicOne’s parallel analysis put the total cost of automotive cyberattacks at $22.5 billion in 2024. $20 billion from data leakage. $1.9 billion from system downtime. $538 million directly from ransomware. These are not rounding errors on a balance sheet. They are the measured cost of an industry that built connectivity before it built security.

The attack surface is growing faster than the defenses are. By 2026, 91% of new cars have embedded telematics. A modern software-defined vehicle carries over 100 million lines of code. Every line is a potential entry point. Every API connection is a potential pivot. Every OTA update channel is a potential delivery mechanism for something the owner never agreed to install.

The Ten Things Someone Can Do to Your Connected Car

These are not theoretical. Each one has a documented real-world precedent. I have organized them from the ones that feel abstract to the ones that should make you put down your coffee.

1. They can track where you go, and where you sleep.

   Every connected vehicle generates a continuous GPS record. Where you drive. When you stop. How long. Where you park overnight. This data is collected by the manufacturer and, in numerous documented cases, sold or shared without meaningful disclosure. GM’s OnStar system collected acceleration, braking, and GPS records and sold them to LexisNexis and Verisk, who used them to generate driver risk scores. Insurance companies then raised premiums or cancelled coverage based on data the driver never knew was being collected. The FTC banned GM from this practice for five years in January 2026. The Texas Attorney General sued an insurer for selling 45 million Americans’ driving records. The data is still sitting in those scoring systems.

2. They can take control of the vehicle remotely.

   The 2015 Jeep Cherokee hack by researchers Charlie Miller and Chris Valasek established this was possible. A decade later, at RSAC 2026, the same research community reported it is still possible, across dozens of manufacturers, via more vectors than before. Researchers at Pwn2Own Automotive 2026 disclosed 76 zero-day vulnerabilities and collected $1,047,000 in prize money for successful exploits across multiple manufacturers. The PerfektBlue Bluetooth vulnerability exposed millions of vehicles to remote unlock and engine start without any user interaction.

3. They can hold the car for ransom.

   Ransomware targeting connected vehicles is not theoretical anymore. Attackers lock infotainment systems, disable ignition functions, or threaten to brick critical vehicle controls. Ransomware now accounts for 44% of all automotive cybersecurity incidents. The fastest-growing attack category in the industry targets transportation because transportation cannot wait. A locked truck cannot deliver. A locked taxi fleet cannot operate. The leverage is immediate.

4. They can drain an electric vehicle’s battery remotely.

   Researchers demonstrated this against the Nissan Leaf: unauthorized access to climate controls and seat heating left running continuously depleted the battery, stranding the driver. In an EV, controlling energy consumption is controlling range. Controlling range is controlling whether the vehicle moves at all. EV charging infrastructure adds another vector. VicOne recorded a tripling of EV charging-related incidents in Q1 2026.

   I want to pause here for a moment. I drove a Leaf. Reading this category is not abstract for me.

5. They can spy through your own cameras.

   Modern vehicles have cameras facing inward as well as outward. Driver monitoring systems, designed to detect fatigue or distraction, provide a live feed of the vehicle interior. Researchers found vulnerabilities that enabled remote access to vehicle cameras, including live image capture from inside the car. Australia’s Office of the Australian Information Commissioner launched a formal investigation in 2026 into whether default cabin data storage violates privacy law. In the EU, the legality of in-cabin biometric collection remains contested under GDPR.

6. They can manipulate navigation and location data.

   GPS spoofing is a documented and deployable attack. For commercial fleets, it is more consequential than it sounds. CargoNet reported $111.88 million in cargo theft claims in Q3 2025 alone, with criminals increasingly combining GPS spoofing with stolen telematics credentials to reroute freight to locations where it can be stolen. The vehicle thinks it is where it is supposed to be. The cargo is somewhere else entirely.

7. They can poison your OTA update.

   Over-the-air software updates are how modern vehicles are maintained, improved, and patched. They are also a delivery channel. An attacker who compromises the OTA pipeline can push code to every vehicle in a manufacturer’s fleet simultaneously. This does not require physical access to a single vehicle. It requires access to one backend system. Researchers at Northeastern University disclosed LTE vulnerabilities in Tesla’s Model 3 and Cybertruck in February 2026, enabling communications disruption and denial-of-service attacks via false base station techniques.

8. They can compromise the entire supply chain through one supplier.

   Stellantis lost personal data through a breach of a third-party contractor system in 2025. A Tier-2 supplier’s insecure API becomes the entry point into an OEM’s connected vehicle backend. Auto-ISAC and the ENX Association formalized a partnership in March 2026 specifically to address Tier-2 and Tier-3 supplier readiness, which they explicitly identified as the most critical unresolved gap in automotive cybersecurity.

9. They can use your car as a data broker without telling you.

   This is not hacking. This is the product working as designed. LexisNexis combines driving behavior data with property records, consumer purchase histories, and social media activity to create comprehensive risk profiles. Drivers who believe they signed up for roadside assistance have authorized, buried in terms of service, comprehensive behavioral surveillance that shapes their insurance premiums, credit decisions, and risk classifications. The Mozilla Foundation reviewed every major automaker in 2023 and found every single one failed basic privacy standards.

10. They can use your car to attack someone else.

    A compromised vehicle is a computing asset on wheels. It can participate in distributed denial-of-service attacks. For autonomous vehicles and advanced driver assistance systems, the attack surface includes the physical world: manipulated sensor data can cause a vehicle to respond incorrectly to a real road condition. As AI architectures expand through the SDV stack, they create dynamic attack paths that evolve as the AI adapts. Upstream’s CEO Yoav Levy framed it directly: AI is enabling attackers to move faster, at greater scale, and with more automation, while the industry is still relying on security models built for a far more static world.

Why This Is Not Just a Consumer Problem

70% of consumers told RunSafe Security in 2025 that they are considering buying older, non-connected vehicles specifically to reduce their exposure to cyber risk. That is not nostalgia. That is a rational security calculation made by people who have started to understand what they are actually buying.

In my current role I engage with C-suite executives at OEMs and Tier-1 suppliers across Asia Pacific and Japan. The conversation about cybersecurity investment almost always arrives late in the meeting, after the connectivity roadmap, after the feature announcement, after the partnership announcement. Security is framed as a cost center. It should be framed as a trust center. The moment consumers start choosing analog over connected is the moment the connectivity investment calculates to zero.

UNECE Regulation R155 and ISO/SAE 21434 now mandate that automakers demonstrate active cybersecurity management across the vehicle lifecycle. These are not voluntary standards. For vehicles sold in the EU, Japan, South Korea, and a growing number of other markets, compliance is a market access requirement. The connected vehicle cybersecurity market, currently valued at $3.2 billion, is projected to reach $11.8 billion by 2030.

The Failure Mode That Explains All Ten

Every one of the ten attack categories above shares a common root cause.

The automotive industry built connected features the same way it built physical features: as additions to an existing product, appended at the end of a development cycle with security treated as a compliance checkbox rather than a design constraint. The CAN bus, the internal network that connects every electronic control unit in most vehicles, was designed in the 1980s for reliability and speed. It was not designed with any concept of authentication. A message from the infotainment system looks identical, to the CAN bus, to a message from the braking system. There is no sender verification. There is no message signature. If you get into the network, you can send anything to anything.

Modern vehicles have added security layers on top of this foundation. Firewalls between domains. Secure boot mechanisms. Intrusion detection. But these are security layers placed on top of an architecture that was never designed to be secure. The manufacturers that get this right in the next five years will not be the ones with the biggest security budgets. They will be the ones that treat security as an architectural property of the vehicle from the first line of the specification.

I have sat in enough executive briefings to know what a 70% rejection number means when it appears in consumer research. It means the product has a trust problem. Not a feature problem. Not a pricing problem. A fundamental trust problem that features and pricing cannot solve on their own.

The connected car can be remarkable. The safety systems that connected vehicles enable are genuinely life-saving. Vehicle-to-infrastructure communication, when it works securely, makes roads measurably safer. The data a connected vehicle generates, when handled responsibly, improves the ownership experience in real ways.

But none of that value reaches a driver who does not trust that their vehicle is not watching them, selling data about them, or waiting to be taken over by someone they have never met.

The industry built the product. It has not yet built the trust.

I keep thinking about that 30-second number. Not because it is dramatic. Because it represents a decade of shipping connectivity without shipping the security to protect it. The question I am sitting with right now is not whether the industry can fix this. It can. The question is whether the organizations setting product roadmaps today have decided that security is an architectural requirement or a future line item.

Which is it in yours?

All opinions are my own and do not reflect those of my employer.

I spend most of my time writing about the big questions in automotive transformation. Software-defined vehicles. Supply chain re-architecture. AI adoption on the factory floor. But the questions that stick with me are usually the ones nobody is asking in the room.

The CAN Extended Frame is one of those questions.

Every modern vehicle runs on a Controller Area Network. The ECUs that manage your braking, your steering, your battery, your infotainment, and increasingly your autonomous driving stack all share a single serial bus. There is no central switch. There is no ethernet fabric underneath. There is a wire, and a protocol so elegant that it has survived largely unchanged since Bosch published the original specification in 1986.

The standard CAN frame uses an 11-bit identifier. That gives a vehicle 2,048 unique node addresses. For most of automotive history that was more than enough. Then the ECU count started climbing. Modern premium vehicles carry more than 150 of them. The protocol needed to scale, and it did so with a single architectural decision: extend the identifier field by 18 bits, gated by a single IDE bit that tells every node on the bus which format to expect.

The result was 536 million unique addressable IDs on the same physical wire.

What makes this worth understanding beyond trivia is the arbitration mechanism. When two nodes attempt to transmit at exactly the same moment, neither one crashes, neither backs off to a retry queue, and there is no arbiter deciding who goes first. Each node reads the bus while it writes. The moment a node detects that the bus is carrying a lower value than what it sent, it stops. The lower identifier wins. The losing node waits for the next available frame slot and tries again.

No collision. No master controller. Just deterministic priority resolution at the bit level.

The video below walks through the full sequence: identifier structure, the 11-plus-18 split, the hex representation, and the arbitration mechanism. It is short. It is the first video I have made for this publication, and I would genuinely value your feedback on whether this format adds something that the written analysis does not.

Tell me in the comments what worked and what you would change. I am building this in public and your read matters more than my assumptions about what you want.

Views are my own and do not represent my employer.