TL;DR
Edge computing in autonomous vehicles means running perception, sensor fusion and vehicle control on computers inside the car rather than in a data centre. It exists because a self-driving stack has roughly 10 to 50 milliseconds to react, while a cloud round trip costs 100 to 200 milliseconds on its own. The working architecture has three tiers: the in-vehicle edge for anything safety-critical, roadside and mobile-edge servers for shared road context, and the cloud for training and fleet learning. On-vehicle silicon now spans Mobileye EyeQ6 Lite at 5 deep-learning TOPS up to NVIDIA DRIVE Thor at more than 1,000 INT8 TOPS. Regulation shapes the design as much as physics does, because UN Regulation No. 157 obliges the vehicle to stay safe when the network is gone. The real question for an engineering team is never edge versus cloud, it is which workload belongs on which tier, and this guide gives you a rule for deciding.
Key Takeaways
- A cloud round trip costs 100 to 200 ms. The same inference at the edge costs 10 to 20 ms, which fits inside the 10 to 50 ms window an autonomous vehicle actually has to respond.
- Safety-critical loops such as automatic emergency braking need deterministic pipelines of 1 to 10 ms. Only on-vehicle compute can guarantee that.
- The working architecture is three tiers, not two: in-vehicle edge, roadside and multi-access edge computing, and cloud. Each tier has a different latency envelope and a different job.
- Silicon sets every other constraint. NVIDIA DRIVE Orin delivers up to 254 TOPS, DRIVE Thor exceeds 1,000 INT8 TOPS, and Mobileye EyeQ6 High runs 34 deep-learning TOPS on a 7nm process.
- Functional safety is an architecture decision, not a test phase. ISO 26262 ASIL-D is normally met by decomposing one requirement into two independent ASIL B(D) paths that can fail over.
- Argo AI and Cruise both shut down with world-class edge compute already in the vehicle. What ended them was unit economics and operational scale, not latency.
Watch on YouTube
Strengthening Business Intelligence with Cloud Integration
The cloud tier of an autonomous driving stack is an analytics and training platform. This session covers how Kanerika wires cloud integration into a decision layer teams actually use.
Seven Metres of Road, Decided Somewhere Else
A car travelling at 130 km/h, the ceiling UN Regulation No. 157 now permits for an automated lane keeping system, covers just over 36 metres every second. Send a camera frame to a data centre and wait for the verdict, and a 200 millisecond round trip consumes 7.2 metres of tarmac before the vehicle knows what it just saw.
That distance is not an abstraction. It is the difference between a controlled stop and a collision, and it is the whole reason edge computing in autonomous vehicles exists instead of a plain cloud pipeline.
Run the same frame through a computer bolted behind the dashboard and the answer comes back in 10 to 20 milliseconds. The car has moved 36 to 72 centimetres. Everything else in this guide follows from that arithmetic: which chips go in the vehicle, how many watts they are allowed to burn, what the roadside is for, and what the cloud is still genuinely good at.
Why Autonomous Vehicles Cannot Wait for the Cloud
Three separate pressures push compute out of the data centre and into the vehicle. They are usually discussed as one problem. They are not, and a team that conflates them will over-provision in one place and leave a hole in another.
- Data volume. Sensors produce more data per hour than any practical uplink can carry.
- Latency. The control loop has a hard deadline that a network round trip cannot meet.
- Connectivity. The link is not always there, and the vehicle is not allowed to care.
Take volume first. Intel’s then chief executive Brian Krzanich put the figure at approximately 4,000 GB, or 4 terabytes, of data a day per autonomous vehicle, in a paper published on 15 November 2016. The arithmetic is easy to check today. One 8-megapixel camera at 3840 by 2160 pixels, 12 bits per pixel, 30 frames per second, produces about 3 gigabits per second uncompressed.
NVIDIA specifies a 14-camera suite for its DRIVE Hyperion platform, so the raw camera feed alone reaches tens of gigabits per second before a single lidar return or radar sweep is added.
Latency is the harder constraint. Published work on vehicular edge architectures puts the required response time for an autonomous vehicle at 10 to 50 milliseconds, and measures a cloud round trip at 100 to 200 milliseconds against 10 to 20 milliseconds for an edge deployment. A deterministic on-vehicle pipeline runs in 1 to 10 milliseconds, which is what sub-10 ms automatic emergency braking requires.
Connectivity closes the argument. Tunnels, multi-storey car parks, rural gaps and cell handovers all remove the link for seconds at a time. A vehicle that degrades when the network drops cannot be certified, so every function on the critical path has to survive with no uplink at all.
The Sensor-to-Actuation Path: How Edge Computing in Autonomous Vehicles Works
Most explanations of edge computing stop at the idea that processing happens closer to the data. That is true and useless. What an engineering team needs is the six-stage path a photon takes to become a steering command, and the slice of the budget each stage is allowed to spend.
The Six-Stage Pipeline
Capture is the camera, lidar and radar front end, including exposure and readout. Preprocessing rectifies lens distortion, synchronises timestamps across sensors and converts raw frames into the tensor layout the network expects.
Perception is the inference stage: detection, segmentation and classification, usually the largest single line item in the budget. It is where computer vision models earn or lose the rest of the loop.
Fusion merges detections from different modalities into one tracked object list with velocities and covariances attached. Planning turns that list plus the map and the route into a trajectory, and actuation converts the trajectory into torque, brake pressure and steering angle commands on the vehicle bus.
Each stage can be accelerated, quantised or relocated independently, which is what makes the pipeline a design surface rather than a black box.
A Worked Latency Budget
The published envelope is 10 to 50 milliseconds. Below is one worked allocation inside that envelope, at 30 milliseconds end to end. Treat it as a budgeting exercise rather than a vendor specification: the total is what the literature constrains, the split is an engineering choice your own profiling will move.
- Capture, 5 ms. Exposure, readout and transfer onto the compute board.
- Preprocess, 3 ms. Rectification, time alignment, tensor formatting.
- Perceive, 10 ms. Detection and segmentation across the camera set.
- Fuse, 4 ms. Association and tracking across camera, radar and lidar.
- Plan, 5 ms. Trajectory generation and cost evaluation.
- Actuate, 3 ms. Command formation and delivery to the vehicle bus.
Two rules fall out of writing the budget down. First, the number that matters is the worst case rather than the average, because a 99th-percentile spike is what a safety case has to survive. Second, any stage you move off the vehicle inherits the network round trip, so relocating even one 4 ms stage to the cloud turns a 30 ms loop into a 130 ms loop.
Sensor Bandwidth and the Buses That Carry It
Bandwidth decides the physical architecture long before software does. A mechanical lidar returning on the order of a million points a second, several radars, and a dozen or more cameras all have to land on the same compute board within a fixed time window.
That is why modern vehicles run automotive Ethernet rather than CAN for the sensor domain, and why Time-Sensitive Networking and generalised precision time protocol matter. Without hardware timestamping, fusion is merging observations that were never simultaneous.
Compression is not a free answer either. Lossy compression on a camera feed destroys exactly the small, low-contrast detail a distant pedestrian detector depends on, so the raw feed usually has to reach the accelerator intact.
Case Study
26% fewer fleet accidents with predictive AI maintenance
A fleet management provider deployed predictive AI on AWS, cutting accidents by 26% and maintenance costs by 16% while lifting fleet performance by 20%.
Read the Case Study →
The Three Compute Tiers: On-Vehicle, Roadside and Cloud
Edge versus cloud is the wrong framing, and it is the framing most articles on this topic use. A production autonomous driving architecture has three tiers, and the middle one does work neither of the others can.
The in-vehicle tier owns everything on the safety-critical path. It is bounded by watts, thermals and bill of materials, and it must function with no network at all. Nothing that cannot survive a tunnel belongs here.
The roadside tier sits at the base station or in a cabinet at an intersection. It has more compute than a car and a far wider view than any single vehicle, because it can see around the corner the car cannot. It is reachable in 10 to 20 milliseconds, which is fast enough to be useful and too slow to be trusted with braking.
The cloud tier owns everything with no deadline: training, simulation, scenario mining, fleet analytics and software distribution. It has effectively unbounded compute and the worst latency in the system, and those two facts are not in tension because nothing it does is time-critical.
Tier 1: The In-Vehicle Edge
This is the domain controller or central compute unit, increasingly one board replacing dozens of distributed electronic control units. It runs perception, fusion, localisation, prediction, planning and control, plus the safety monitor that watches all of them.
Its defining property is determinism. A cloud service is judged on average throughput; an in-vehicle runtime is judged on whether it has ever missed a deadline, because one missed deadline on the control path is a hazard.
Tier 2: Roadside Units and Multi-Access Edge Computing
Multi-access edge computing is a published standard, not a marketing category. ETSI’s ISG MEC defines the APIs and the service framework for applications running inside the mobile network, close enough to the vehicle to hit the 10 to 20 millisecond band.
The workloads that suit it share a shape: they need a view wider than one vehicle, they help when present, and they must degrade gracefully when absent. Cooperative perception, signal phase and timing, and localised map deltas all qualify.
Tier 3: Does an Autonomous Vehicle Still Need the Cloud?
Training is the obvious one. Model training, revalidation against a regression suite of recorded scenarios, and large-scale simulation all need compute no vehicle will ever carry.
Choosing the deployment model for that tier is a normal enterprise decision about public, private and hybrid cloud, with the added wrinkle that vehicle telemetry is frequently subject to data residency rules.
Edge versus cloud for autonomous driving workloads
| Dimension | In-vehicle edge | Cloud |
|---|
| Round-trip latency | 1 to 10 ms, deterministic | 100 to 200 ms, variable |
| Availability | Works with no network | Requires a live link |
| Compute ceiling | Bounded by watts, thermals and cost per vehicle | Effectively unbounded |
| Data movement | Data stays on the vehicle | Every byte must be uploaded |
| Best-fit workloads | Perception, fusion, planning, control, emergency braking | Training, simulation, scenario mining, fleet analytics |
| Failure behaviour | Degrade to a minimum risk manoeuvre | Feature is simply unavailable |
| Dominant cost | Bill of materials on every unit shipped | GPU hours and data egress |
Kanerika Service
Build the pipelines that feed the model, not just the model
Vehicle telemetry is only useful once it is ingested, governed and joined to everything else. Kanerika’s data engineering practice builds those pipelines end to end.
Explore Data Engineering →
The Silicon: What Actually Runs the Stack in 2026
TOPS is the number every vendor leads with and the least useful one in isolation. Two platforms quoting the same figure can differ by an order of magnitude on a real network, because the headline assumes a precision, a batch size and a utilisation the workload may never reach.
Three numbers matter more when specifying edge computing in autonomous vehicles. TOPS per watt sets the thermal design, worst-case latency under load sets the safety case, and board-level certification decides whether the programme ships at all.
The generational jump is real, though. Announcing DRIVE Thor at GTC on 20 September 2022, NVIDIA founder and chief executive Jensen Huang said: “Advances in accelerated computing and AI are moving at lightspeed. DRIVE Thor is the superhero of centralized compute, with lightning-fast performance to deliver continuously upgradable, safe and secure software-defined supercomputers on wheels.” The same announcement confirmed DRIVE Orin at 254 TOPS as the platform Thor succeeds.
Production autonomous driving compute platforms and their published figures
| Platform | Stated compute | Typical role | Notes |
|---|
| NVIDIA DRIVE AGX Orin | Up to 254 TOPS | Mainstream assisted and automated driving programmes | The volume platform Thor is designed to succeed |
| NVIDIA DRIVE AGX Thor | Over 1,000 INT8 TOPS (2,000 FP4 TFLOPs) | Centralised compute for driving plus the digital cockpit | Transformer inference engine; designed to ISO 26262 and ASPICE |
| NVIDIA DRIVE Hyperion | Two Thor system-on-chips on one board | Reference platform for higher levels of automation | Specified with a 14 HD camera sensor suite |
| Mobileye EyeQ6 Lite | 5 deep-learning TOPS | Entry driver assistance and regulation-driven features | The high-volume replacement for earlier EyeQ generations |
| Mobileye EyeQ6 High | 34 deep-learning TOPS (int8), 7nm | Premium driver assistance and hands-free driving | Two of these form a SuperVision system |
| Mobileye SuperVision, Chauffeur, Drive | Two, more than three, and more than four times EyeQ6 High | Eyes-on, eyes-off and driverless tiers | One hardware ladder sharing a single software stack |
Two corrections are worth stating plainly, because both are repeated constantly. Mobileye publishes the EyeQ6 ladder itself, and it has traded as a separate public company (Nasdaq: MBLY) since October 2022, so describing it as an Intel division is out of date. And Orin is no longer the flagship: NVIDIA now positions Thor at over 1,000 INT8 TOPS with ASIL-D compliance and redundancy.
NVIDIA and Mobileye are not the only names in this tier. Qualcomm’s Snapdragon Ride family competes for the same design wins, and it is the platform most often shortlisted alongside those two when a programme is choosing its centralised compute. The evaluation criteria do not change: sustained throughput per watt inside the enclosure’s thermal limit, worst-case latency under full sensor load, and the certification evidence the safety case will need.
Thermal and Power Budgets, the Constraint Nobody Puts on a Slide
Every TOP delivered is a watt dissipated, and the enclosure is a sealed metal box in a vehicle that parks in direct sun. Automotive qualification grades under AEC-Q100 extend to 125 degrees Celsius ambient for Grade 1 parts, and the compute module has to hold its performance across that whole range.
Thermal throttling is therefore a safety event, not a performance annoyance. A perception stack that drops from 30 frames per second to 18 because the board is hot has silently doubled its reaction distance, and the safety monitor has to detect that and demand a handover or a minimum risk manoeuvre.
This is why robotaxi builds often use liquid cooling and consumer vehicles do not. A robotaxi amortises the cost over a commercial duty cycle, while a passenger car has to hit a bill of materials target on passive cooling. Continuous inference also draws power from the traction battery, which shows up as range on the product specification.
Talk to Kanerika
Pressure-test your edge architecture with our engineers
Bring your latency budget, your sensor list and your connectivity assumptions. We will walk the workload split with you and show you where the design will break.
Book a Meeting →
The Software Layer: Runtimes, Inference and Middleware
Hardware sets the ceiling; the software layer decides how much of it you get. A trained network handed straight to a board typically leaves most of the silicon idle, because the graph was never compiled for that hardware.
That is the job of an inference compiler. NVIDIA TensorRT takes a trained network and produces a hardware-specific engine, fusing layers, selecting kernels and quantising weights so a model meets a fixed per-frame deadline rather than an average throughput target.
Above the accelerator sits the middleware. ROS 2 is the dominant choice for research and prototype stacks, with a publish-subscribe transport and a large ecosystem of perception and planning packages. It is not, on its own, a safety-certified production runtime, and teams that forget that discover it late.
Safety-critical tasks that must hit a hard deadline usually sit on a certified real-time operating system such as BlackBerry QNX rather than on general purpose Linux. The production answer is usually AUTOSAR Adaptive Platform, a service-oriented, POSIX-based architecture built for high-performance automotive compute, sitting alongside Classic AUTOSAR for the hard real-time control units. Together they let one vehicle run mixed-criticality software under a hypervisor without the infotainment domain touching the braking domain.
That partitioning is now a silicon feature rather than a software convention. NVIDIA’s Thor announcement describes multi-instance GPU support that lets the cockpit and the driving stack share one chip while keeping time-critical processes isolated from each other.
If you are surveying the tooling market rather than the architecture, our companion piece on edge AI platforms for real-time analytics covers the vendor options in detail, and our overview of edge AI and the role of cloud computing covers how the two halves are wired together.
V2X and Cooperative Perception
A vehicle can only act on what it can see, and a sensor mounted on a bumper cannot see through a delivery van. Vehicle-to-everything communication exists to remove that limit, and it is the clearest justification for the middle tier of the architecture.
The category splits four ways. Vehicle-to-vehicle carries kinematic state between cars. Vehicle-to-infrastructure carries signal phase, road works and hazard warnings from the roadside. Vehicle-to-network reaches back to central services, and vehicle-to-pedestrian covers vulnerable road users carrying a phone.
Two radio families compete. The 802.11p family, sold as DSRC in the United States and ITS-G5 in Europe, sends messages directly between nodes with no network. Cellular V2X uses the PC5 sidelink defined by 3GPP, first in LTE-V2X and then in 5G NR-V2X, and can fall back to the mobile network when direct range is not enough.
Cooperative perception is the interesting application. Instead of shipping raw sensor data, each vehicle broadcasts a list of the objects it has already detected, with position, velocity and a confidence value. A roadside unit fuses those lists and rebroadcasts a consolidated view, which is how a car learns about a stopped vehicle over the crest of a hill before its own sensors can resolve it.
Shipping object lists rather than pixels is a bandwidth decision. An object list is kilobytes, the camera stream that produced it is gigabits, and no roadside link will carry the second one from every vehicle in range.
Security is the structural risk. A forged V2X message claiming a phantom obstacle is a safety attack, so the standards depend on message signing, a certificate authority and misbehaviour detection that scores implausible claims and revokes the sender.
The honest limitation is penetration. Cooperative perception only helps where enough equipped vehicles and roadside units exist, so no production stack is allowed to depend on it. It is treated as a bonus input that raises confidence, never as a required one.
Functional Safety, Redundancy and Security
ISO 26262 governs functional safety for road vehicles, and its central artefact is the Automotive Safety Integrity Level. Hazards are rated on severity, exposure and controllability, and the result places a function somewhere on a scale from ASIL A to ASIL D.
ASIL D carries the heaviest requirements, and steering, braking and the perception that feeds them usually land there. Meeting it with a single compute path is close to impossible, which is why the standard permits decomposition.
Decomposition splits one ASIL D requirement into two elements at a lower level, commonly two ASIL B(D) paths, on the condition that the two are genuinely independent. Independence is the difficult half: shared power rails, a shared clock source, a shared supplier or a shared software library all reintroduce common-cause failure.
The related distinction is fail-safe versus fail-operational. At SAE Level 2 the driver is the fallback, so failing safe means handing back control. From Level 3 upward the system is the fallback inside its operational design domain, so it has to keep operating long enough to reach a safe state on its own.
In hardware that means dual power rails, dual network paths, diverse sensing modalities so one physical phenomenon cannot blind both channels, and a minimum risk manoeuvre controller able to stop the vehicle on degraded perception. NVIDIA states ASIL-D compliance and redundancy as a platform property for exactly this reason.
Inside the silicon the same principle appears as lockstep cores, error-correcting memory, hardware watchdogs and a safety island that stays alive when the main application processor does not.
Security is now a type-approval matter rather than an internal concern. UN Regulation No. 155 requires a certified cybersecurity management system, and ISO/SAE 21434 is the engineering standard that gets a programme there. NVIDIA’s Thor announcement describes the platform as designed in alignment with ISO 21434 precisely because it is the pathway to UNECE Regulation 155 compliance.
The attack surface is wider than most teams assume. It covers the over-the-air update channel, the vehicle bus, the diagnostic port, the V2X radio, sensor spoofing by projected pattern or laser injection, and extraction of the model weights themselves.
Edge processing is itself an underrated privacy control. Video analysed on the vehicle and discarded never crosses a network, which shrinks the surface data encryption and access controls have to defend in the first place.
Which Workloads Belong on Which Tier: A Decision Framework
Every competitor article describes the three tiers. Almost none of them tells you how to choose. The test below is the one we use on client architectures, and it runs on four inputs: latency tolerance, safety criticality, bandwidth cost and connectivity assumption.
Ask the four questions in order and stop at the first yes. Does the workload have to produce an answer in under 10 milliseconds? Is the vehicle unsafe if the link drops mid-task? Does it need information from vehicles or infrastructure the car cannot see? Can it tolerate minutes of delay with no consequence?
The first two answers send the workload on-vehicle. The third sends it to the roadside or the mobile edge, and the fourth sends it to the cloud. Anything that answers no to all four is a workload nobody has specified properly yet.
The four-question tier test applied to common autonomous driving workloads
| Workload | Latency tolerance | Safety critical | Connectivity assumption | Tier |
|---|
| Object detection and tracking | Under 10 ms | Yes | Must work offline | In-vehicle edge |
| Sensor fusion and localisation | Under 10 ms | Yes | Must work offline | In-vehicle edge |
| Trajectory planning and control | Under 10 ms | Yes | Must work offline | In-vehicle edge |
| Emergency braking decision | Under 10 ms | Yes | Must work offline | In-vehicle edge |
| Cooperative perception from nearby vehicles | 10 to 20 ms | Assistive only | Degrades gracefully | Roadside or MEC |
| Signal phase and timing | 100 ms to seconds | Assistive only | Degrades gracefully | Roadside or MEC |
| HD map delta updates | Seconds to minutes | No | Opportunistic | Roadside or cloud |
| Model training and revalidation | Hours to days | No | Offline batch | Cloud |
| Fleet analytics and scenario mining | Hours | No | Offline batch | Cloud |
| Over-the-air software distribution | Hours | No | Opportunistic | Cloud |
The governing rule is to default to the cheapest tier that still satisfies the hardest constraint. Compute on the vehicle is the most expensive place to put anything, because you pay for it on every unit shipped.
The common failure is the opposite of what people expect. Teams do not push too much to the edge, they push too much to the cloud, because that is where their pipelines and MLOps already live. The connectivity assumption gets inherited silently, and the gap only surfaces in a tunnel during a demo.
Work an example. Adaptive cruise control answers yes to the first question, so it is settled in one step. A construction-zone map update answers no, no, no and yes, so it is a cloud workload on an opportunistic delivery path, and the vehicle must behave correctly if the update never arrives.
How Regulation Actually Constrains the Architecture
Regulation is usually treated as a compliance task that starts after the engineering. In automated driving it is an input to the architecture, because two documents dictate what the vehicle has to be able to do without help.
The first is SAE J3016, the recommended practice that defines driving automation Levels 0 through 5. The architecturally important line is between Level 2, where the human is the fallback, and Level 3, where the system is the fallback inside its operational design domain. That single shift is why Level 3 hardware costs so much more than Level 2 hardware.
The second is UN Regulation No. 157 on Automated Lane Keeping Systems, binding since June 2020 and amended in 2022 to permit operation at up to 130 km/h and to allow automated lane changes. The regulation text is worth reading directly rather than through summaries.
What it demands is architectural. The system has to recognise whether the driver is available, issue a transition demand when it reaches the edge of its domain, execute a minimum risk manoeuvre if the driver does not take over, and record defined events in a data storage system. None of those obligations may depend on a network connection.
It is also no longer accurate to say there are no standards for this space. ETSI publishes the multi-access edge computing specifications, AUTOSAR publishes the Adaptive Platform, SAE publishes J3016, and UNECE publishes R155 and R157. The gap is adoption and mutual recognition, not the absence of documents.
Real-World Deployments in 2026
Three programmes illustrate three different bets about where the compute should sit, and a fourth story explains why two well-funded competitors are no longer in the market at all.
Tesla, Waymo and Baidu Apollo
Tesla runs an in-house inference computer and a camera-led perception stack, with almost everything decided on the vehicle. Fleet data flows back to a central training cluster and improvements return as over-the-air software. It is the purest two-tier architecture: heavy edge, heavy cloud, effectively no middle.
Waymo takes the opposite position on sensing, combining lidar, radar and cameras with detailed prior maps, and operates driverless commercial ride-hailing in several United States cities. Its remote fleet response function is worth understanding correctly: those operators advise a vehicle that has already stopped safely, they do not drive it by wire, because no network is trustworthy enough for that.
Baidu Apollo pairs an open autonomous driving software platform with the Apollo Go robotaxi service in Chinese cities, and has leaned harder on vehicle-to-infrastructure than its Western peers, in a market where coordinated roadside deployment is more achievable.
Case Study
74% less testing time with an AI telemetry synthesizer
A connected-vehicle mobility platform used an AI telemetry synthesizer on AWS and Kubernetes, cutting testing time by 74% and lifting user satisfaction by 32%.
Read the Case Study →
What the AV Shutdowns Teach Enterprise Buyers
Argo AI ceased operations in October 2022 after Ford and Volkswagen halted their investment. On 10 December 2024, General Motors ended development of the Cruise robotaxi after more than 10 billion dollars had gone into the business.
Both companies had excellent in-vehicle compute. Neither failed because a perception loop was too slow. They failed on unit economics and operational scale: the cost of the sensor and compute stack on every vehicle, the ratio of remote support staff to vehicles, and the unglamorous cost of depots, cleaning, charging and recovery.
That is the transferable lesson for anyone funding an edge programme in any industry. Your architecture will be judged on cost per deployed unit and on operational load per incident, not on your inference benchmark.
The practical consequence is a budgeting one. Size the fleet operations layer, the monitoring, the revalidation pipeline and the field-support model before you finalise the compute specification, because those costs recur and the silicon cost does not.
Challenges That Still Block Mass-Market Adoption
The remaining barriers are mostly economic and organisational rather than computational. Five stand out.
- Bill of materials. A redundant, ASIL-D-capable compute and sensor stack costs a multiple of a Level 2 system, and every unit shipped pays it.
- Power and heat. Continuous inference competes with range on an electric vehicle and with packaging in any vehicle.
- Validation. The long tail of rare scenarios cannot be covered by road mileage alone, so simulation and scenario mining become load-bearing, and both need a strong cloud tier.
- Security and liability. Regulation now requires a managed cybersecurity process, and liability for a Level 3 failure sits with the manufacturer rather than the driver.
- Interoperability. V2X has a chicken-and-egg problem, because the benefit arrives only after enough vehicles and roadside units are equipped.
None of these is a reason to wait. They are a reason to be specific about which tier each capability lives on, and to build the cloud and data foundations early, because those are the parts you can get right before the silicon is chosen.
Kanerika Service
From pilot model to a production AI system that holds up
Most edge programmes stall between a working prototype and a governed production deployment. Kanerika’s AI and ML practice is built for that crossing.
Explore AI Services →
Where Edge Computing in Autonomous Vehicles Goes Next
The market forecasts point one way. DataM Intelligence sizes the edge computing for autonomous vehicles market at US$ 9.37 billion in 2025, and projects US$ 58.48 billion by 2035. Directionally that is a decade of steady architectural investment rather than a spike.
The clearest technical trend is consolidation. Vehicles are collapsing dozens of distributed control units into a small number of central compute units, which cuts weight, wiring and supply complexity while making over-the-air updates tractable.
The second is the arrival of transformer-based and increasingly end-to-end driving stacks, which changes the shape of the latency budget. One large model replaces several smaller staged ones, so the perception slice grows, integration overhead shrinks, and the accelerator has to be good at attention rather than convolution.
The third is that energy efficiency becomes the competitive axis. Once every serious platform clears the compute threshold, TOPS per watt is what separates them, because it decides cooling, packaging and range.
Underneath all of it, the vehicle is becoming a software product with a fifteen-year lifecycle. That reframes the cloud tier as a permanent product-engineering obligation rather than a project, which is a very different thing to budget for.
How Kanerika Builds Edge-to-Cloud AI Architecture for Mobility
Kanerika does not build automotive silicon, and any partner who tells you they do is selling something. Our part of edge computing in autonomous vehicles is the half that decides whether the silicon earns its keep: the telemetry contract, the pipelines, the governance, the retraining loop and the decision layer.
For automotive and mobility clients that work follows five stages, and we run them in this order for a reason.
- Tier mapping. Every workload goes through the four-question test above, and the connectivity assumption is written down explicitly. This is the cheapest hour of the programme and the one most often skipped.
- Telemetry contract. We define the schema, the sampling rate and the retention policy at the vehicle, because that decision sets bandwidth and storage cost for the life of the fleet.
- Ingestion and curation. Vehicle data lands through governed, automated pipelines. Our FLIP platform handles the workflow automation and DataOps layer so ingestion is monitored and auditable rather than a set of scheduled scripts.
- Model lifecycle. Training, revalidation against a regression scenario suite, shadow deployment, then staged over-the-air rollout with a tested rollback path.
- Decision layer. Fleet data only pays for itself once someone acts on it. Karl, our data insights agent, sits on the curated warehouse so operations teams get answers without filing a ticket with the analytics team.
On-Demand Webinar
AI-powered digital twins for preventive maintenance
See agentic digital twins built on Microsoft Fabric and Esri ArcGIS detect equipment failures before they happen, the same sensor-to-decision pattern an edge fleet needs.
Watch the Webinar →
The pattern is proven on real mobility work. A connected-vehicle mobility platform used an AI telemetry synthesizer on AWS and Kubernetes and cut testing time by 74% while lifting user satisfaction by 32%.
A fleet management provider deployed predictive AI for fleet maintenance on AWS, reducing accidents by 26% and maintenance costs by 16% while improving fleet performance by 20%. That is predictive maintenance doing the same job the safety monitor does inside a vehicle, one abstraction layer up.
A logistics provider handling high-value shipments combined AI with real-time traffic data and lifted delivery forecast accuracy by 87% while cutting delivery times by 47%.
Three failure patterns come up often enough to name. The first is treating the edge as a smaller cloud, which produces a deployment that works until the link drops. The second is budgeting for training but not revalidation, so the model ages in the field with nobody watching.
The third is letting the telemetry schema drift. Once three vehicle generations emit three incompatible payloads, every downstream automotive analytics question becomes an archaeology project, and the fix is a versioned contract enforced at ingestion rather than a cleanup job.
Our AI for automotive practice and our automated data integration work are the two entry points most mobility programmes start from, depending on whether the immediate problem is a model or a pipeline.
Talk to Kanerika
Map your workloads to the right tier in one session
We will run your workload list through the four-question test, flag the connectivity assumptions nobody wrote down, and give you a tier map you can build against.
Book a Working Session →
Frequently Asked Questions
What is edge computing in autonomous vehicles?
Edge computing in autonomous vehicles means running perception, sensor fusion and vehicle control on computers inside the car rather than in a data centre. It exists because of the arithmetic: a self-driving stack has roughly 10 to 50 milliseconds to react, while a cloud round trip costs 100 to 200 milliseconds on its own. The same inference run on a computer behind the dashboard comes back in 10 to 20 milliseconds, and a deterministic on-vehicle pipeline runs in 1 to 10 milliseconds, which is what sub-10 ms automatic emergency braking requires. The working architecture is three tiers rather than two: the in-vehicle edge for anything safety-critical, roadside and multi-access edge servers for shared road context, and the cloud for training and fleet learning.
Why is edge computing important for self-driving cars?
Three separate pressures push compute into the vehicle, and a team that conflates them will over-provision in one place and leave a hole in another. Volume comes first: Intel’s then chief executive Brian Krzanich put an autonomous vehicle at approximately 4,000 GB of data a day in a paper published in November 2016, and one 8-megapixel camera at 30 frames per second produces about 3 gigabits per second uncompressed before a single lidar return is added. Latency is the harder constraint, because a car at 130 km/h covers just over 36 metres every second, so a 200 millisecond round trip consumes 7.2 metres of tarmac before the vehicle knows what it just saw. Connectivity closes the argument: tunnels, multi-storey car parks, rural gaps and cell handovers remove the link for seconds at a time, and UN Regulation No. 157 obliges the vehicle to stay safe through that, so no function on the critical path may depend on an uplink.
How does edge computing differ from cloud computing in vehicles?
They differ on latency, on availability, and on what each is allowed to be responsible for. The in-vehicle edge answers in 1 to 10 milliseconds deterministically and works with no network at all, while the cloud costs 100 to 200 milliseconds, varies, and needs a live link. That gap decides the split: perception, fusion, planning, control and emergency braking stay on the vehicle, and training, simulation, scenario mining and fleet analytics go to the cloud, because nothing the cloud does is time-critical. Failure behaviour differs too, since the edge degrades to a minimum risk manoeuvre while a cloud outage simply makes a feature unavailable. Any stage you move off the vehicle inherits the network round trip, so relocating even one 4 ms stage turns a 30 ms loop into a 130 ms loop.
What are the main benefits of edge computing in autonomous vehicles?
The first is a control loop that closes inside the deadline: 10 to 20 milliseconds at the edge against 100 to 200 in the cloud, and 1 to 10 milliseconds for the deterministic pipeline that sub-10 ms automatic emergency braking needs. The second is that the vehicle keeps working with no network, which is what UN Regulation No. 157 requires and what a tunnel or a cell handover will test. The third is bandwidth, because sensors produce more data per hour than any practical uplink can carry, so processing on the vehicle and broadcasting object lists of a few kilobytes instead of gigabit camera streams is the only affordable option. The fourth is privacy: video analysed on the vehicle and discarded never crosses a network, which shrinks the surface that encryption and access controls have to defend in the first place.
What challenges does edge computing face in autonomous driving?
The remaining barriers are mostly economic and organisational rather than computational. Bill of materials leads, because a redundant, ASIL-D-capable compute and sensor stack costs a multiple of a Level 2 system and every unit shipped pays it. Power and heat come next, since every TOP delivered is a watt dissipated inside a sealed metal box, AEC-Q100 Grade 1 parts must hold performance to 125 degrees Celsius ambient, and thermal throttling is a safety event rather than a performance annoyance, because a perception stack dropping from 30 to 18 frames per second has silently doubled its reaction distance. Validation is the third, because the long tail of rare scenarios cannot be covered by road mileage alone, so simulation and scenario mining become load-bearing. Security and liability are now type-approval matters under UN Regulation No. 155, and V2X interoperability has a chicken-and-egg problem, because the benefit only arrives once enough vehicles and roadside units are equipped.
Which companies are leading in edge computing for autonomous vehicles?
On silicon, NVIDIA and Mobileye set the range. NVIDIA DRIVE Orin delivers up to 254 TOPS and DRIVE Thor exceeds 1,000 INT8 TOPS with stated ASIL-D compliance and redundancy, while Mobileye spans EyeQ6 Lite at 5 deep-learning TOPS to EyeQ6 High at 34 deep-learning TOPS on a 7nm process. One correction is worth stating plainly, because it is repeated constantly: Mobileye has traded as a separate public company (Nasdaq: MBLY) since October 2022, so describing it as an Intel division is out of date. Among vehicle programmes, Tesla runs an in-house inference computer and a camera-led stack with almost everything decided on the vehicle, Waymo combines lidar, radar and cameras with detailed prior maps and operates driverless commercial ride-hailing in several United States cities, and Baidu Apollo pairs an open software platform with the Apollo Go robotaxi service and has leaned harder on vehicle-to-infrastructure than its Western peers. Treat TOPS as the least useful number in isolation, because TOPS per watt, worst-case latency under load and board-level certification are what decide whether a programme ships.
Will edge computing enable fully driverless cars?
Edge computing is a precondition for driverless operation, not the thing that delivers it. The evidence is direct: Argo AI ceased operations in October 2022, and General Motors ended development of the Cruise robotaxi on 10 December 2024 after more than 10 billion dollars had gone into the business. Both had excellent in-vehicle compute, and neither failed because a perception loop was too slow. They failed on unit economics and operational scale: the cost of the sensor and compute stack on every vehicle, the ratio of remote support staff to vehicles, and the unglamorous cost of depots, cleaning, charging and recovery. Waymo already runs driverless commercial ride-hailing in several United States cities, so the open question is cost per deployed unit and operational load per incident, not latency.
What is roadside edge computing and how does it help autonomous vehicles?
Roadside edge computing places compute in units at the roadside rather than on the vehicle, following the ETSI multi-access edge computing standard. It gives a vehicle perception beyond its own line of sight, for example a hazard around a blind corner that no on-board sensor can see. It sits between the in-vehicle tier and the cloud, so it suits work that is too slow for the cloud but does not have to run in the vehicle itself.
What is the difference between edge computing and edge AI?
Edge computing is the broader idea of processing data close to where it is produced instead of sending it to a data centre. Edge AI is the subset that runs machine learning inference on that local hardware. In an autonomous vehicle the two overlap heavily, because most of the on-board compute budget goes to perception and planning models rather than to ordinary data processing.
Do autonomous vehicles still need the cloud?
Yes, but not for driving decisions. The cloud handles model training, fleet learning across many vehicles, high definition map updates and long term data retention, none of which are time critical. Anything that must complete inside the vehicle response window stays on the vehicle, because a cloud round trip typically costs 100 to 200 milliseconds against an on-board budget measured in single milliseconds.
