Nico Peng
← Back to the Physical AI index

Physical AI · Family 4

Road autonomy

The driving system, the vehicle and the operations that turn them into passenger or freight transport.

AS OF 2026-09-02DATED · NON-EXHAUSTIVE

Supply badges: “not assessed” means this report has not established a node-wide supply rating. It does not mean supply is plentiful; product maturity and local constraints are discussed separately.

Family 4 · Road autonomy

Road autonomy

Systems that drive passenger vehicles or freight trucks on public roads. A driving system must be integrated with a suitable vehicle, validated for its intended operation and supported by transport operations. Robotaxis and highway freight share inputs but have different service economics.

The driving system is not the vehicle

Road autonomy combines two products that are easy to collapse into one: the system that perceives the road and decides how to drive, and the vehicle that executes those decisions. Removing the onboard driver also changes the work around the journey—dispatch, inspection, passenger or freight handling, remote assistance and recovery.

This page maps the driverless passenger and freight routes. Driver assistance is adjacent and economically important, but a driver-supervised feature is not an unfinished stage of the same production line. It retains different responsibilities and can succeed as a product without ever becoming a robotaxi. Likewise, a truck operating in a controlled mine does not establish readiness for public roads.

Some developers retain the whole service. Others supply a driving system to vehicle makers and fleet operators. Mobileye Drive is an example of a separately offered system; Nuro describes a licensed Driver within its planned Lucid–Uber robotaxi arrangement. These commercial arrangements justify a distinct driving-system node without implying that the system plugs into any ordinary car. Driver offering → · Licensed-system arrangement →

Useful driving has made industrialization matter more

By May 2025, Waymo reported more than 250,000 paid trips per week. In the same account it described a Magna integration plant, factory validation and more efficient commissioning. The important connection is causal: growing passenger use requires repeatable production of vehicles that are ready for the service, not simply more copies of an AI model. The trip figure is a dated operating disclosure, not today’s fleet size. Trips, manufacturing and commissioning →

Aurora’s July 2026 disclosure makes the distinction visible in freight. Its second-generation system was operating on International LT trucks; Roush had begun the upfit process. A targeted production run-rate and Volvo’s planned 2027 driverless start remained forward-looking. One developer can therefore have a working service and several vehicle-industrialization routes at different stages. Operating fleet versus production plans →

These examples do not establish that vehicle production is the only bottleneck. Software performance, validation, permission, customer demand and operating costs still matter. They do show why redundant vehicle controls, integration and continuing operations deserve as much attention in the map as sensors and AI compute.

The enabling supply chain

A Driver and a vehicle meet before transport can be sold

The upper paths develop and manufacture the driving system. Vehicle supply enters separately on the left. Factory fit and upfit are alternative integration routes; both require vehicle-level validation before the operating chain below.

Product or componentEngineering or productionSupplied outputSupply / processAlternative routeApplication-dependentDevelopment supportMaintenance / support
Each bubble opens its explanation below
A Driver and a vehicle meet before transport can be soldThe upper paths develop and manufacture the driving system. Vehicle supply enters separately on the left. Factory fit and upfit are alternative integration routes; both require vehicle-level validation before the operating chain below.

The map follows driverless passenger and freight service. It does not depict driving-assistance levels as production stages. A Driver may remain captive or be licensed; a vehicle may be owned by its developer, a fleet operator or a customer. Those choices change the contract, not the need for the enabling work.

Key players are selected examples, linked to their relevant products or work—not a market-share ranking. Some activities are performed inside a manufacturer or operator rather than sold separately. “(private)” marks unlisted businesses; listed parent groups are identified separately.

Developing the driving system

Road AI is developed using data and tests, then deployed through a specific sensor and computing configuration. These are related but distinct supplied inputs and activities.

Economic nodes

Road sensing

Supply not assessed

Cameras, radar and lidar provide observations at the ranges and conditions the driving system needs. Mounting, weather exposure, cleaning and calibration matter alongside sensor performance. Different systems use different combinations; the map does not make one sensor mandatory for every architecture.

Key players

  • Mobileye — camera, radar and lidar architecture for Mobileye Drive.
  • Waymo (private) · Alphabet subsidiary — sensor suite developed and integrated for its Driver.

Worth understanding

Mobileye publishes a sample multi-sensor configuration for Drive. A sample configuration is evidence of an implemented architecture, not a universal bill of materials. Sensing configuration →

↑ Back to the map

Onboard compute & control

Supply not assessed

Vehicle computers run perception, planning and control within power, thermal and reliability limits. Supporting electronics handle communications and fault responses. Training infrastructure is upstream development capacity; it is not the computer driving the vehicle on a live trip.

Key players

  • NVIDIA — DRIVE computing in Aurora’s industrialized system.
  • Mobileye — EyeQ-based self-driving compute.

Worth understanding

Mobileye’s EyeQ-based system and Aurora’s announced NVIDIA hardware partnership illustrate different supplied compute routes. Onboard system → · Hardware development partnership →

↑ Back to the map

Road data & maps

Supply not assessed

Driving examples, road geometry, interventions and unusual events support training and evaluation. Maps can also provide information used during operation. Their production and update processes differ by system and operating area; no single merchant mapping product is assumed here.

Key players

  • Mobileye — REM mapping and road-data products.
  • TomTom — RoadCheck road and operating-domain information.
  • Waymo (private) · Alphabet subsidiary — internal Driver perception and road knowledge.

Worth understanding

Mobileye describes crowdsourced road information within its architecture. Other developers may perform this work internally. Mapping role →

↑ Back to the map

Simulation & scenarios

Supply not assessed

Simulation lets developers evaluate interactions, replay situations and test candidate changes without exposing road users to every experiment. Scenario design and correlation with real-world behaviour determine its usefulness. A simulated pass is evidence for a test case, not blanket proof of safe deployment.

Key players

  • Applied Intuition (private) — driving simulation and validation tools.
  • dSPACE (private) — automotive simulation and hardware-in-the-loop testing.
  • Waymo (private) · Alphabet subsidiary — Waymax simulation research and tooling.

Worth understanding

Waymo’s Waymax is a published research example of data-driven multi-agent driving simulation. Simulation research →

↑ Back to the map

Driver engineering

Supply not assessed

The developer combines sensing, learned models, planning, control and fallback behaviour into a driving capability. It specifies the conditions in which that capability is intended to operate and maintains evidence about performance. The software cannot be judged independently of the sensors, vehicle interfaces and operating assumptions it uses.

Key players

  • Waymo (private) · Alphabet subsidiary — internal self-driving system development.
  • Aurora — Aurora Driver development.
  • Mobileye — Drive system engineering for vehicle partners.
↑ Back to the map

Driver hardware manufacture

Supply not assessed

Manufacture turns the sensor and computing design into repeatable hardware assemblies, with installation interfaces, calibration and test. The hardware may be produced by a contract manufacturer while the driving-system developer retains the software and system design.

Key players

Worth understanding

Aurora’s announced industrialization partnership distinguishes its future production hardware from the AI development work. Its stated 2027 production timing remains a plan. Industrialization route →

↑ Back to the map

Driving system / Driver

Supply not assessed

This is the integrated hardware-and-software capability offered for incorporation into a vehicle. It can cross a commercial boundary as a licence or system supply, or remain internal to an operator. It is not yet a passenger trip or a complete freight operation.

Key players

  • Aurora — Aurora Driver for autonomous trucking.
  • Mobileye — Mobileye Drive supplied into partner vehicles.
  • Nuro (private) — Driver technology for the Lucid–Uber programme.
  • Waymo (private) · Alphabet subsidiary — Driver integrated into its own service fleet.

Worth understanding

Nuro’s arrangement identifies a licensed Driver; Aurora’s July 2026 release described negotiations for its future subscription model. A marketed or planned arrangement should not be read as a completed fleet rollout. Licensed Driver → · Commercial-model status →

↑ Back to the map

Putting it in a suitable vehicle

Factory fit and upfit are alternatives. Neither removes the need to validate the whole installed configuration.

Economic nodes

Vehicle platform

Supply not assessed

The vehicle supplies the structure, propulsion, braking, steering and passenger or freight capacity. Autonomy does not require every vehicle to use the same energy source. A passenger vehicle and a heavy truck retain very different load, duty-cycle and service requirements.

Key players

  • Volvo — truck platform designed for autonomous integration.
  • Lucid — vehicle platform for the Nuro–Uber robotaxi programme.
↑ Back to the map

Redundant vehicle interfaces

Supply not assessed

Interfaces and supporting power, braking and steering systems allow the Driver to command the vehicle and respond to faults. The required redundancy is designed and validated at system level; it is not achieved simply by duplicating every component.

Key players

  • Volvo — redundant truck interfaces developed for Aurora integration.
  • Aurora — Driver-side integration with the vehicle’s redundant systems.

Worth understanding

Volvo describes additional redundant systems in its autonomous tractor. This grounds an enabling supply role without establishing a single industry-wide limiting component. Autonomous-vehicle architecture →

↑ Back to the map

Factory-fit integration

Supply not assessed

An OEM can incorporate the driving system and required interfaces into its vehicle-production process. This makes platform design, production quality and the software–vehicle interface a joint engineering task. Nuro describes hardware integration on Lucid’s production line for their planned robotaxi route. Factory-fit plan →

Key players

↑ Back to the map

Vehicle upfit

Supply not assessed

An upfitter equips a compatible vehicle with the Driver, redundant interfaces and supporting systems. The conversion must be engineered and tested; using an existing vehicle does not carry its original assurance unchanged into a new driverless configuration.

Key players

  • Magna — integration of Waymo technology into vehicles.
  • Aurora — truck upfit and fleet introduction work.

Worth understanding

Roush’s work on Aurora’s International LT fleet is a disclosed example of this route. Upfit in operation →

↑ Back to the map

Vehicle validation

Supply not assessed

Validation tests the installed system and supports release for its intended vehicle, software and operating conditions. It includes production checks as well as the evidence needed for deployment. Authorization remains jurisdiction- and use-dependent; it is not a universal purchased input.

Key players

  • Waymo (private) / Magna · Waymo is an Alphabet subsidiary — integrated-vehicle testing before fleet entry.
  • Volvo / Aurora — joint truck safety engineering and validation.
  • dSPACE (private) — test systems used in autonomous-driving development.

Worth understanding

Waymo describes validation and commissioning after installation at its integration plant. Factory-to-service process →

↑ Back to the map

Autonomy-integrated vehicle

Supply not assessed

The output is a vehicle with an installed, validated driving system for a defined use. It may be supplied to a fleet owner or retained by a service provider. The vehicle still needs dispatch, upkeep, passenger or freight handling, and a plan for situations it cannot complete.

Key players

↑ Back to the map

Operating the transport service

Removing the driver changes the labour mix rather than deleting all work around a journey. The operator’s obligations differ from those of the component suppliers.

Economic nodes

Dispatch & transport software

Supply not assessed

Software connects the fleet with bookings or freight jobs, schedules vehicles and records completed work. It also coordinates availability with charging, maintenance and loading. The driving system’s ability to complete a route does not guarantee a commercially useful flow of trips.

Key players

  • Waymo (private) · Alphabet subsidiary — ride matching and fleet dispatch within its service.
  • Uber — ride-demand platform in the Lucid–Nuro programme.
↑ Back to the map

Depot & terminal operations

Supply not assessed

Vehicles need inspection, cleaning, energy replenishment and physical servicing. Freight adds coupling, loading and terminal interfaces; passenger service adds rider readiness and vehicle presentation. These jobs persist even when nobody performs the driving task.

Key players

  • Moove (private) — charging, depot operations and vehicle readiness.
  • Aurora — terminal and trucking-operation development.

Worth understanding

Waymo’s production account distinguishes the integration factory from the local depots that receive vehicles. Fleet deployment process →

↑ Back to the map

Remote assistance

Supply not assessed

A remote team helps resolve situations or supplies additional information. Assistance should not automatically be called remote driving. Waymo describes a process in which the vehicle requests context and retains control of the driving task. Other providers can allocate more direct control to staff.

Key players

  • Waymo (private) · Alphabet subsidiary — Fleet Response assistance for its autonomous vehicles.

Worth understanding

The economic question is the amount and type of human work per vehicle-hour. No universal staffing ratio is assumed here. Operator’s explanation →

↑ Back to the map

Transport operation

Supply not assessed

The operator combines service-ready vehicles with dispatch, depots and exception handling to move people or goods. A robotaxi network and a hub-to-hub freight service have different loading, scheduling and customer obligations even when both purchase a driving system.

Key players

  • Waymo (private) · Alphabet subsidiary — driverless ride-service operation.
  • Moove (private) — vehicle-readiness and fleet-operation services.
  • Aurora — autonomous trucking operations.
↑ Back to the map

Completed rides / freight

Supply not assessed

The customer receives transport. Paid trips, loads and useful operating miles are adoption evidence when their definitions and operating conditions are known. Revenue alone does not establish autonomous-driving margins, and a fleet’s total miles can include testing or human-driven operation.

Key players

  • Waymo (private) · Alphabet subsidiary — completed driverless passenger rides.
  • Aurora — autonomous freight transport.
↑ Back to the map

Software & vehicle support

Supply not assessed

Support maintains hardware, repairs vehicles and manages software changes throughout operation. Changes can require regression testing and updated deployment evidence. This work may be supplied by the vehicle maker, Driver developer and service partners under different obligations.

Key players

  • Moove (private) — inspection, servicing and maintenance of AV fleets.
  • Aurora — continuing Driver development and deployment support.
↑ Back to the map

Autonomy changes the labour mix—and the capital requirement

The promise is more useful vehicle time and less driving labour per trip or load. The offsetting costs include the autonomy hardware, vehicle integration, remote support, depots, maintenance and the unused time between suitable jobs. A well-utilized freight route and a lightly used passenger fleet can have very different economics.

A separately supplied Driver can let another company own and operate the vehicle. That does not tell us in advance which party captures the value: pricing, asset ownership, reliability obligations and service density all matter. Evidence of a licence agreement establishes a commercial interface, not a profitable steady state.

The next meaningful inflections would be demonstrated reductions in installed-system cost, broader validated operation, more repeatable production, and improved useful utilization with disclosed support requirements. A new city announcement alone need not change the shape or economics of this supply chain.