EV ADAS/AV Compute Architecture

ADAS and AV compute architecture defines how inference workloads, safety supervision, sensor data ingestion, and vehicle control outputs are organized across hardware. Getting this architecture right is the foundational engineering decision in any ADAS program — it determines the safety certification pathway, the sensor suite the platform can support, the OTA upgrade surface, and the long-term software scalability of the platform. The hardware blocks are consistent across platforms; what differs is how they are integrated, sourced, and validated.

For the OEM-to-platform directory (which inference SoC each vehicle brand uses), see: ADAS/AV Compute Platform Directory
For supply chain coverage, see: SDV Systems Supply Chain

Hardware Block Architecture

Every ADAS/AV inference platform is assembled from the same set of hardware blocks. The performance ceiling, power budget, and safety certification outcome all trace back to how these blocks are selected and integrated:

Block	Function	Key Specification	Design Consideration
SoC (CPU + GPU/NPU)	Runs perception, sensor fusion, path planning, and runtime systems simultaneously	TOPS (tera-operations per second); NVIDIA Orin: 254 TOPS; Thor: 2,000 TOPS; HW4: ~200 TOPS	Primary performance driver; automotive-grade process node (7nm-5nm); ASIL-B or ASIL-D safety rating; thermal design power (TDP) sets thermal solution requirement
AI Accelerator (NPU)	High-throughput matrix operations for neural network inference; offloads SoC CPU/GPU	INT8/INT4 TOPS; memory bandwidth determines throughput at large model sizes	Determines real-time model capacity under power constraints; critical bottleneck as perception models grow in parameter count with each generation
Safety Supervision (Safety MCU / Safety Islands)	Monitors compute health, cross-checks outputs, triggers safe-state transitions when faults are detected	ASIL-D required for highest criticality; lockstep CPU cores; separate power domain; watchdog timer	Cannot share power rails or clock domains with main compute; independence is a certification requirement; external safety MCU vs safety islands inside SoC is a key architectural choice
DRAM	Runtime memory for perception pipelines, model weights, and intermediate data	LPDDR5/5X; 8-32 GB typical; bandwidth: 50-200+ GB/s depending on configuration	Capacity and bandwidth can bottleneck perception pipeline throughput independent of SoC TOPS rating; wide memory bus required for data-intensive sensor fusion workloads
Storage (Flash / NVMe)	Maps, firmware, OTA staging, edge-case data logging for training data collection	32GB-1TB depending on data logging requirements; automotive-grade temperature range; write endurance (TBW)	Logging depth is limited by write endurance and thermal stability in automotive environments; OTA update staging requires sufficient free space reserve
Ethernet (Automotive)	Moves high-bandwidth sensor data (cameras, LiDAR) to compute and commands back to actuators	100BASE-T1 (sensor links); 1000BASE-T1 (uplinks); 10GBASE-T1 (L4 backbones); IEEE 802.3bp/ch	Scales with camera count and resolution; L4 systems with 8-12+ cameras need high-speed backbone; time synchronization (gPTP/IEEE 802.1AS) is critical for multi-sensor fusion
Power Delivery	Provides stable voltage rails and handles transient loads from compute and actuators	12V or 48V supply; SoC core rails typically 0.7-1.0V; PMIC manages rail sequencing	Automotive voltage transients (load dump, cranking) must not disturb compute operation; ASIL-rated power monitoring required for safety-critical supply rails
Thermal Solution	Removes heat from SoCs and memory to maintain junction temperature within spec	Air cooling sufficient below ~20W TDP; liquid cooling (cold plate + vehicle coolant loop) for high-end ADAS above 30W	High-end ADAS compute (NVIDIA Orin at 45W; Thor at 60W) can become a primary vehicle thermal load; thermal throttling under sustained load can reduce available TOPS mid-drive

Compute Scale by Autonomy Level

Compute requirements scale non-linearly with autonomy level. The jump from L2 to L4 is not a linear increase in TOPS — it involves qualitative changes in redundancy architecture, safety certification requirements, and sensor suite complexity that drive exponential cost and complexity growth:

Level	Compute Pattern	Redundancy	Networking	Representative Platform
L2 (ADAS)	Single ADAS SoC module; 20-100 TOPS typical; often camera-centric	Fail-safe; driver monitoring required; safety island or external MCU	100BASE-T1 for cameras; CAN/CAN-FD dominant for control; limited Ethernet	Mobileye EyeQ5, Qualcomm Snapdragon Ride (entry), Infineon
L2+ / L3 (Conditional)	Higher-end SoC; 100-500 TOPS; camera + radar + optional LiDAR	More supervision logic; increasing redundancy; driver available for takeover	Ethernet backbone expanding; 1000BASE-T1 for uplinks; gateways bridge legacy buses	NVIDIA DRIVE Orin, Tesla HW4, Mobileye EyeQ6 SuperVision
L4 (High Autonomy)	Multi-SoC or redundant compute modules; 500-2,000+ TOPS; full sensor suite including LiDAR	Fail-operational required; physical compute redundancy; independent power and networking paths	10GBASE-T1 backbone; high-speed Ethernet fabrics; time synchronization critical; sub-ms determinism	NVIDIA DRIVE Thor, Waymo custom silicon, Mobileye EyeQ Ultra, Qualcomm Ride Elite stacked

Safety Supervision & Command Integrity

Safety supervision is the hardware layer that prevents unsafe commands from propagating to actuators when compute faults occur. It is not optional — it is a fundamental requirement of ISO 26262 functional safety certification for any ADAS function that can affect vehicle motion.

Two architectural approaches are used in practice:

Safety islands inside the SoC - dedicated ASIL-D logic within the main compute chip; monitors the primary compute cores; can trigger safe state without an external device; simpler integration but the safety logic shares the same silicon die as the potentially faulting compute — which is why ISO 26262 requires independence analysis
External safety MCU - an independent microcontroller (Infineon AURIX, Renesas RH850, TI TMS570) that monitors the primary SoC health via watchdog, heartbeat, and output cross-check; communicates over an independent channel (SPI, CAN); triggers safe state by cutting actuator enable signals; stronger independence than safety island alone; preferred for highest ASIL-D claims at system level

Independent power rails and watchdog circuits are required regardless of approach — the supervision system must remain operational through the same voltage transients and power faults that might cause the main compute to fault. A safety supervisor that fails silently alongside the compute it is monitoring provides no protection.

Data Logging & The OTA Training Loop

Modern ADAS platforms are not just perception systems — they are data collection systems. Even when full autonomous driving is not deployed, vehicles log edge-case scenarios, near-miss events, and perception failures for upload to cloud training infrastructure. This "shadow mode" data collection is how Tesla's FSD, Waymo, and Mobileye continuously improve their models without additional labeled data collection campaigns.

The data logging architecture has direct implications for storage sizing, write endurance requirements, and vehicle networking:

Trigger-based logging - vehicle logs high-resolution sensor data around specific trigger events (unexpected braking, near-object detection, system disagreement); efficient storage use; Tesla's fleet learning operates this way

Continuous logging - records all sensor data continuously; maximizes training data density but requires much larger storage and higher write endurance; used by some L4 development programs

Upload path - logged data uploads via cellular (4G/5G) or Wi-Fi at depot; upload bandwidth and data plan cost are real operational constraints at fleet scale; compressed pre-processed logs are preferred over raw sensor streams

Privacy compliance - GDPR (EU), CCPA (California) and emerging state laws apply to exterior camera data; anonymization (face blurring, license plate masking) must occur before upload or storage in some jurisdictions

IVN Networking - Connecting Sensors to Compute

The in-vehicle network (IVN) is how sensor data reaches compute and how compute decisions reach actuators. ADAS platform choice and the IVN architecture are tightly coupled — the compute platform's Ethernet port count and speed determines which sensor configurations are physically possible.

100BASE-T1 - standard automotive Ethernet for individual camera links; single twisted pair; 100 Mbps; IEEE 802.3bw; sufficient for 2-4 MP camera at compressed video rates
1000BASE-T1 - 1 Gbps on single twisted pair; IEEE 802.3bp; uplinks from sensors to zonal controllers and from controllers to central compute
10GBASE-T1 - 10 Gbps; IEEE 802.3ch; L4 systems with multiple high-resolution cameras and LiDAR point cloud streams; backbone interconnects in central compute architectures
Time Synchronization (gPTP) - IEEE 802.1AS generalized precision time protocol; sub-microsecond synchronization across sensors and compute; critical for multi-camera fusion where frame timestamps must align to prevent ghosting in object detection
Gateway to legacy buses - CAN, CAN-FD, and LIN remain in use for body, powertrain, and chassis control; domain controllers and zonal controllers bridge Ethernet ADAS data to legacy bus control signals

Power and thermal constraints

Compute capability is limited by the vehicle power and thermal envelope.

• Power: low-voltage rails (12 V or 48 V) must support sustained compute draw plus transient loads
• Thermal: air cooling may be sufficient at lower compute levels; liquid cooling is used in higher-end designs
• Reliability: automotive temperature ranges and vibration drive packaging and connector requirements

Supply Chain Notes

ADAS/AV compute is a high-value concentration point in the vehicle BOM.

• Automotive-grade SoCs and accelerators: constrained by advanced semiconductor nodes and packaging
• DRAM and flash: capacity and bandwidth trends track sensor content
• Ethernet switches and PHYs: required for high-rate sensor ingestion and zonal backbones
• Thermal hardware: cold plates, heat sinks, and thermal interface materials scale with compute
• Functional safety components: safety MCUs and safety islands are key differentiators

Related Coverage

Directories: ADAS/AV Compute Platform Directory (OEM mapping) | Full ADAS/AV Tech Stack

Supply Chain: SDV Systems Supply Chain | Vehicle Networking & Communications

Autonomy: Autonomous Vehicles | Enabling Technologies | Autonomy in Robots

Sister Site: SemiconductorX - Tesla FSD Silicon