This is Part 2 of The Uptime Equation. Part 1 showed why vehicle context has to be captured on the vehicle. This part looks at what it costs to do that.
A platform team has a model that predicts failures in a truck’s aftertreatment (emissions-control) system weeks before they happen. The engineering question is settled. The platform question isn’t: where does this model run? If it fits on the gateway or telematics controller already in the truck, it can ship on current programs. If it needs a more capable controller, it waits for the next electrical/electronic (E/E) architecture, and it never reaches the trucks already on the road.
This is a question that comes up with every new data use case, and, in commercial vehicles, the economics behind the answer differ from passenger cars in three ways.
Why the math is different for trucks
Volume. U.S. retail sales of Class 8 trucks were 208,386 in 2025. U.S. new light-vehicle sales were 16.2 million, about 78 times as many. Adding medium-duty and vocational trucks narrows the gap but doesn’t close it. Every dollar of added compute hardware, and every dollar spent integrating and validating a new controller, is spread across a fraction of the units.
Service life. Heavy trucks in the U.S. average 12.1 years of age in operation. Fleets are also keeping trucks longer: ACT Research data reported by FleetOwner puts the average Class 8 truck in fleet service at 6.3 years, the oldest since 2013. New compute hardware, such as a more capable gateway, telematics unit, or ECU, only helps new builds. The installed base keeps the hardware it shipped with for a decade or more, and much of the uptime value described in Part 1 sits in that installed base.
Architecture cycles. E/E architectures in commercial vehicles refresh on multi-year cycles, and many controllers come from suppliers the OEM doesn’t fully control. A use case tied to new compute hardware is tied to that timeline.
Taken together, these three factors raise the stakes on one question: how much of the intelligence a truck needs has to come from new hardware, and how much can come from making better use of the hardware that’s already there? There are two ways to pay for on-vehicle AI. One is to buy capability. The other is to build efficiency.
Path one: buy capability
The case for hardware is real. Centralized and zonal architectures consolidate workloads onto fewer, more powerful controllers and reduce wiring. McKinsey notes that because these controllers need more processing power, they can carry added cost. Commercial vehicle OEMs are heading this way, too. Coretura, the Daimler Truck and Volvo Group joint venture launched in 2025, is building a shared software-defined vehicle platform. It will also specify and procure centralized high-performance controllers for commercial vehicles, with first products in vehicles targeted by the end of the decade.
More capable compute hardware, such as a high-performance central or zonal controller or a dedicated AI accelerator, is the right answer when a workload really needs it: camera perception, ADAS, autonomy, or any case where the value per vehicle over its service life clearly outweighs the added cost at your volume. It also makes sense when a new platform is being designed anyway.
But it has limits. It reaches only new vehicles, on the platform’s timeline. And a bigger controller doesn’t remove the need for efficient software, because every workload on a shared computer competes for the same resources. In McKinsey’s research on edge AI in automotive, 46% of interviewees cited limited system-on-chip resources as a barrier.
Path two: build efficiency
The software path gets more out of the hardware already there. Several techniques are now mature:
- Model compression. Integer quantization makes models about 4x smaller and 3x faster with little accuracy loss. Combining pruning with quantization cut model storage 35x to 49x without affecting accuracy. McKinsey notes that microcontrollers are increasingly capable of running lightweight AI models at the edge.
- On-demand execution. A model can be installed on the vehicle without running all the time. As described in Always-On AI Models Strain Commercial Vehicle Resources, a shared in-vehicle runtime can keep continuous or safety-critical models running and activate others, such as a battery health check during a depot session, only when vehicle conditions call for them.
- Event-triggered collection and on-vehicle compression. The vehicle stores and sends only what’s relevant around an event, instead of streaming everything.
- Virtual sensors. Software can estimate a value from signals already on the vehicle network instead of adding a physical sensor. In one partner case study, a software-only headlight leveling sensor built from CAN signals cut hardware cost by up to $20 per vehicle. Here the software path doesn’t just avoid adding BOM cost, it removes it.
The software path’s biggest advantage in trucks is reach. It can be deployed over the air to vehicles already in service, within the limits of their compute, and on current programs without waiting for the next architecture. That’s the premise behind Fastlane™ Edge, which runs AI models, virtual sensors, and predictive diagnostics on compute resources the vehicle already carries, such as a high-performance gateway, telematics unit, or central computer, without a dedicated AI accelerator. Where trucks don’t have that compute yet, Fastlane™ Copilot adds a high-performance gateway to existing vehicles without changing their production architecture, in prototype and test fleets.
But this has limits, too. Software can’t turn a gateway into a perception computer. It’s bounded by compute headroom, memory, and validation effort, and it carries its own costs in safety, cybersecurity, and lifecycle management.
Treat it as one decision
The mistake is to treat hardware and software as separate budgets. How efficient the software is determines how much hardware you need. A practical sequence for platform teams:
- Optimize first, then size the hardware. Find out what the workload needs after compression and event-triggered design, not before.
- Ask where the value lives. If most of it is in the installed base, the hardware path can’t reach it.
- Compare value against cost at your volume. Weigh the value per vehicle over its service life against the added hardware and integration cost, spread across your actual production numbers.
- Build in headroom where a new architecture is already coming. Plan it on the assumption that efficient software will fill it.
Software has its own bill. Each model added to a truck needs compute, memory, integration work, and validation, and it has to be maintained for the life of the vehicle. Running models only when they’re needed, and sharing one runtime across them, keeps that bill from growing with every new use case.
Once a workload fits on the vehicle, the next question is which work belongs there at all and which belongs in the cloud. That’s coming in Part 3.
The bottom line: Capturing rich vehicle context and running AI on the vehicle costs money, and commercial vehicle OEMs pay that cost across a much smaller production base than passenger car makers. They can pay for it in two ways: add more capable hardware and justify it with the value of the data, or make the software efficient enough to run on compute the vehicle already has. Most will take both approaches. But low volumes, 12-year service lives and long architecture cycles mean OEMs should make software the default: run new workloads on the compute trucks already carry, and add compute hardware only where a workload such as camera perception needs it, or where a new E/E architecture is already being designed.