Autonomy compute: a data centre problem inside a car
An automated driving computer runs several neural networks on multiple sensor streams, every frame, with a hard deadline — inside a sealed box with no fan, over a fifteen-year life, in temperatures from freezing to baking. The constraints are what make it difficult, not the arithmetic.
In one sentence
Autonomy compute is the in-vehicle computing platform that runs perception, prediction and planning models on sensor data in real time, under automotive power, thermal, reliability and functional-safety constraints.
The workload resembles data-centre inference in kind and differs in every constraint. It cannot be batched, because there is one vehicle and one moment. It has a hard deadline: an answer after the deadline is a failure, not a slow success. And the power budget is tens to low hundreds of watts, dissipated without a fan in a sealed enclosure.
On top of that sits the safety requirement. A system trusted with control must detect its own faults and reach a safe state when it cannot function — which typically means redundant computing paths and continuous self-checking rather than a single fast processor.
How it works
Why latency matters more than throughput
The metric is end-to-end time from photon to actuator, including sensor capture, transfer, inference, fusion, planning and control. The worst case matters, not the average: a system that is fast almost always and occasionally slow is unsafe, so the platform is specified for guaranteed timing rather than peak performance.
The automotive envelope
Silicon must be qualified for automotive temperature ranges and reliability targets over a decade and a half, which restricts process choices and adds years to a chip programme. Cooling is passive and the power budget is constrained by the vehicle's electrical system. These are the reasons an in-vehicle computer trails data-centre hardware by generations.
Redundancy and safe states
Functional safety requires that a failure be detected and handled. That means duplicated computing paths, cross-checking between them, and a defined degraded behaviour — hand back to the driver, or bring the vehicle to a controlled stop. Designing what happens when the computer fails is as much of the work as making it fast.
What this depends on
Technology dependencies are solved by engineering; supply dependencies are solved by building something, which takes years.
Supply chain
Automotive-qualified accelerators
Purpose-designed silicon qualified for automotive temperature, lifetime and safety requirements.
What each company supplies at this step, and — where a public figure exists — its share of this specific market — with what that share measures, the period it covers and who published it. Some rows also show the company’s own reported revenue for the segment covering this step, which is a different thing: it says how much this business matters to that company, not how much of the market it holds. Not a ranking and not a recommendation.
Supplies vision processors for the cameras and the lower-power end of the compute range.
What would change the picture
Whether in-vehicle compute capability keeps rising or plateaus at what the thermal envelope allows.
Whether centralised vehicle computers replace the many distributed controllers in current cars.
Whether safety certification of learned components becomes a solved regulatory process.
Questions people ask about this
Why not run the models in the cloud?
Because the deadline is measured in tens of milliseconds and the vehicle must work without connectivity. A driving decision cannot wait for a network round trip, and a system that fails when signal drops is not a system that can be trusted with control. Connectivity is used for updates and data collection, not for driving.
Why is automotive silicon behind data-centre silicon?
Qualification and constraints. Automotive parts must survive wide temperature ranges and long lifetimes, meet safety requirements, and run without active cooling in a tight power budget — and qualifying them takes years. The result is a generational lag that is a consequence of the requirements, not of effort.
Each page explains one technology in plain language, states what it depends on, and names companies by what they supply at that step. Company roles are described qualitatively and deliberately carry no market shares, revenue figures or rankings — those change faster than an explainer can, and a stale number is worse than none. Ticker links point at company pages on this site and are provided for reference only.
Nothing here is investment advice, a recommendation, or a forecast. A company named on a page about a technology is not thereby a good investment, and the chokepoints described are structural facts about supply chains rather than predictions about prices. Technology moves; where a page describes something as unresolved or in development, that was true when it was written.
Plutux no es un asesor de inversiones. Los datos de mercado y el análisis generado por IA son solo informativos y educativos, no asesoramiento de inversión. Aviso legal