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
SoC (CPU + GPU/NPU)	Perception, fusion, planning, runtime	Orin 254 TOPS; Thor 2,000 TOPS; HW4 ~200 TOPS
AI Accelerator (NPU)	Neural network inference	INT8/INT4 TOPS; memory bandwidth
Safety Supervision (Safety MCU / Safety Islands)	Health monitoring; safe-state trigger	ASIL-D; lockstep cores; watchdog
DRAM	Runtime memory for pipelines and weights	LPDDR5/5X; 8-32 GB; 50-200+ GB/s
Storage (Flash / NVMe)	Maps, firmware, OTA, edge-case logging	32GB-1TB; write endurance (TBW)
Ethernet (Automotive)	Sensor data to compute; commands to actuators	100BASE-T1, 1000BASE-T1, 10GBASE-T1
Power Delivery	Stable rails; transient handling	12V or 48V; 0.7-1.0V core rails
Thermal Solution	Holds junction temperature in spec	Air below ~20W; liquid above 30W

Hardware Block Notes

SoC (CPU + GPU/NPU): Runs perception, sensor fusion, path planning and runtime systems simultaneously, rated in TOPS (tera-operations per second). The primary performance driver, built on an automotive-grade process node (7nm-5nm) with an ASIL-B or ASIL-D safety rating; thermal design power (TDP) sets the thermal solution requirement.
AI Accelerator (NPU): High-throughput matrix operations for neural network inference that offload the SoC CPU/GPU; memory bandwidth determines throughput at large model sizes. Determines real-time model capacity under power constraints and becomes a critical bottleneck as perception models grow in parameter count with each generation.
Safety Supervision (Safety MCU / Safety Islands): Monitors compute health, cross-checks outputs and triggers safe-state transitions when faults are detected; ASIL-D is required for highest criticality, with lockstep CPU cores, a separate power domain and a watchdog timer. It cannot share power rails or clock domains with main compute, because independence is a certification requirement; an external safety MCU vs safety islands inside the SoC is a key architectural choice.
DRAM: Runtime memory for perception pipelines, model weights and intermediate data, with bandwidth depending on configuration. Capacity and bandwidth can bottleneck perception pipeline throughput independent of the SoC TOPS rating; a wide memory bus is required for data-intensive sensor fusion workloads.
Storage (Flash / NVMe): Holds maps, firmware, OTA staging and edge-case data logging for training data collection; capacity depends on logging requirements, with an automotive-grade temperature range. Logging depth is limited by write endurance and thermal stability, and OTA update staging requires a sufficient free space reserve.
Ethernet (Automotive): Moves high-bandwidth camera and LiDAR data to compute and commands back to actuators: 100BASE-T1 for sensor links, 1000BASE-T1 for uplinks and 10GBASE-T1 for L4 backbones (IEEE 802.3bp/ch). Scales with camera count and resolution; L4 systems with 8-12+ cameras need a high-speed backbone, and 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; SoC core rails are typically 0.7-1.0V and a PMIC manages rail sequencing. Automotive voltage transients (load dump, cranking) must not disturb compute operation, and ASIL-rated power monitoring is required for safety-critical supply rails.
Thermal Solution: Removes heat from SoCs and memory; air cooling is sufficient below ~20W TDP, and high-end ADAS above 30W needs liquid cooling (cold plate + vehicle coolant loop). High-end compute (NVIDIA Orin at 45W; Thor at 60W) can become a primary vehicle thermal load, and 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

EV ADAS/AV Compute Architecture