Autonomous Vehicle Reference Architecture (2026)

An autonomous vehicle reference architecture is the blueprint that tells engineers, suppliers and safety assessors how a self-driving car is wired together — from the lidar housings on the roof to the safety case sitting on a regulator’s desk. By mid-2026, the industry has converged on a recognisable shape: a centralized high-performance compute platform, multi-modal sensor fusion in a bird’s-eye-view feature space, a diverse fallback channel for ASIL D, and a V2X side-channel that augments but never replaces on-board sensing. This post lays that shape out end-to-end, with diagrams, honest trade-offs and a clear statement of where the industry actually is. Spoiler: L4 robotaxis are operating commercially in a handful of geofenced cities, and L2+ ADAS is shipping in mainstream cars, but no consumer car drives itself everywhere yet.

Why a new reference architecture in 2026

The 2018-era architectures don’t survive contact with 2026 requirements. Three things changed at once. First, the perception stack moved from per-sensor neural networks plus late-fusion into a single, end-to-end bird’s-eye-view (BEV) network with multi-modal cross-attention. Second, the compute platform moved from a dozen specialised ECUs into one or two centralized AV SoCs (Nvidia Drive Thor, Mobileye EyeQ Ultra, Qualcomm Snapdragon Ride Flex) reachable over zonal Ethernet. Third, the regulatory bar got real — ISO 21448 SOTIF became table-stakes, UN R157 expanded to higher speeds, and California’s CPUC and CA-DMV now require detailed safety cases.

This isn’t theoretical. Waymo’s sixth-generation platform on Geely Zeekr, Cruise’s relaunch architecture, Mobileye’s Drive surround-vision robotaxi stack, Pony.ai’s Generation 7 and the Apollo Go fleets in Wuhan and Beijing all share this overall shape, even though the details differ. Tesla’s vision-only FSD remains an outlier on the sensor side, although recent Tesla AI Day content suggests internal architectures are converging towards BEV networks too (treat any specific Tesla claim cautiously, since their public statements are aspirational).

The architecture serves three audiences. Engineers need a decomposition into modules with clean interfaces. Programme managers need it to allocate suppliers and budgets. Safety assessors need it to evaluate the safety case against ISO 26262 and ISO 21448. If your reference architecture can’t address all three, it isn’t done.

Sensor stack: cameras, lidar, radar, imaging radar, IMU/GNSS

The 2026 default sensor suite for a Level 4 vehicle is roughly: eight to twelve cameras, one to four lidars, six to eight 4D imaging radars, ten to twelve ultrasonics and an IMU plus dual-antenna RTK GNSS. L2+ consumer vehicles drop the lidar and most of the imaging radars, keeping cameras, classical radars, ultrasonics and a single-antenna GNSS.

Cameras are the highest-resolution sensor and the cheapest. The 2026 default is 8 megapixel automotive imagers with 120 dB high dynamic range, rolling-shutter compensation, and global-shutter variants for the side-look cameras that need to handle motion. Eight to twelve cameras give roughly 360 degrees of overlap. Frame rates are typically 30 fps for surround and 60 fps for front-facing. The hard problems are HDR scenes (tunnel exits, low sun), water on the lens, and the long-tail of corner cases that pure vision cannot resolve unambiguously.

Lidar still matters for L4. The 2026 production options are FMCW lidars from Aeva and FMCW variants from Aurora’s stack, plus the dominant time-of-flight units from Hesai, Innoviz, Luminar and Valeo SCALA 3. Ranges of 200 to 300 metres at 10 percent reflectivity are standard. The case for lidar is direct depth measurement and immunity to camera failure modes (sun glare, exposure transitions). The case against is unit cost (still 500 to 1500 USD for production-grade units), cleaning, and degradation in heavy rain or snow. L4 stacks keep lidar; L2+ stacks have generally not adopted it, with Volvo’s EX90 and Polestar 3 as exceptions.

Imaging radar is the most interesting development since 2022. Classical radar gave you a few Doppler targets per scan. 4D imaging radar (Arbe, Continental ARS540, ZF ProAi, Bosch fifth-generation) gives a dense point cloud with elevation, range, azimuth and Doppler — effectively a radar lidar. Angular resolutions of 0.5 degrees azimuth and 1 degree elevation, ranges to 300 metres, and the ability to see through fog, snow and into the backscatter from leading vehicles make imaging radar the workhorse of redundancy.

Ultrasonics cover the near-field below five metres for parking, valet and tight manoeuvres. IMU and GNSS provide the absolute pose anchor: a tactical-grade IMU sampled at 200 Hz fused with dual-antenna RTK GNSS gives centimetre-class position outdoors and a few seconds of dead-reckoning through tunnels. Newer architectures also add wheel-speed encoders and steering-angle sensors into the odometry mix to extend dead-reckoning.

The sensor-suite decision is dominated by the operational design domain (ODD). A geofenced robotaxi in San Francisco can afford five lidars; a consumer car sold in 80 countries cannot. The architecture must let you swap sensor configurations without re-deriving the entire perception stack — which is one reason the BEV feature space matters so much.

Perception pipeline: multi-modal fusion, occupancy grids, BEV networks

Modern AV perception fuses every sensor into a single learned representation in bird’s-eye-view space, then runs heads on that representation for detection, tracking, segmentation and freespace. The classical pipeline of per-sensor neural nets feeding a late-fusion tracker is dead in 2026 production stacks for L4, and dying fast in L2+.

The pipeline starts with time synchronisation. Every sensor stream must carry a hardware-grade timestamp, typically via PTP or gPTP over the automotive Ethernet backbone, with millisecond bounded skew. Calibration follows: extrinsics between cameras, lidar and radar are estimated online to correct for thermal drift, settling and minor collisions.

The BEV network ingests image features from each camera, lidar point clouds and radar tensors, lifts them into a shared top-down grid (typical resolution 0.2 metres per cell over a 100-by-100 metre region) and produces a unified feature map. From there, heads predict:

• 3D object detections and tracks for cars, pedestrians, cyclists, motorcycles, large vehicles, debris and animals.
• Lane geometry and road graph including lane centerlines, boundaries, virtual lanes through intersections and stop lines.
• Occupancy grids with flow vectors — every BEV cell gets an occupancy probability and a motion vector, regardless of whether the system can classify what’s there. This is the safety net for unknown objects.
• Semantic segmentation for surface type, driveable area, road markings and traffic-sign classification.

The fusion topology matters. Early fusion (raw lidar voxelised, camera pixels projected into BEV) keeps all the information but is brittle to calibration error. Mid fusion (per-modality encoders with cross-attention) is the 2026 default — it tolerates calibration drift better and lets each modality learn what it’s good at. Late fusion (independent object pipelines, Kalman tracker, JPDA association) survives as a redundancy layer because it’s easier to certify under ISO 26262.

Most production stacks blend all three. Early fusion produces the occupancy grid; mid fusion produces the object and lane heads; late fusion runs as a diverse, simpler safety channel that votes against the main pipeline. The output is a coherent local world model at roughly 10 to 30 Hz, with bounded latency from sensor exposure to world-model timestamp under 100 milliseconds.

Localization and HD-map vs mapless approaches

Localization gives you where you are. In 2026, the industry has split into two camps: HD-map matchers (Waymo, Cruise, Apollo Go, most Chinese robotaxi operators) and mapless or online-mapping stacks (Tesla, Mobileye SuperVision, Wayve, recent Mercedes Drive Pilot updates).

HD-map matching localizes against a centimetre-accurate prior map. Lidar scans and camera features are matched against the map’s vector layer (lane centerlines, stop lines, signs, building corners), and an extended Kalman filter or factor graph fuses the match with IMU, wheel odometry and GNSS. Accuracy is typically 5 to 20 centimetres laterally, which is what’s needed to stay in lane through narrow construction zones. The cost is map production and freshness: a city block changes weekly, and crowd-sourced map updates with change-detection are now a critical part of the architecture.

Mapless stacks build a local online map at run-time from camera and radar features, sometimes anchored by sparse priors like SD-map road graphs from OpenStreetMap. This is what enables operation outside any specific geofence — Mobileye’s Road Experience Management (REM), Wayve’s end-to-end neural driving, and Tesla’s FSD all build a representation of the local lane graph on the fly. Accuracy is lower (often 30 to 50 centimetres laterally) and intersections without clear markings are harder, but the operational scope is global.

In practice, an architecture should support both. A robotaxi-only stack can lock to HD-maps. A consumer car needs to degrade gracefully when the map is stale, missing or simply wrong — the run-time should always fuse the map prior with online-perceived lane geometry and prefer the online evidence when they disagree significantly. The fusion is implemented as a factor graph (GTSAM, Ceres, custom CUDA) producing the 6-DoF pose at 100 to 200 Hz.

A pose covariance is part of the output. Downstream planning treats highly uncertain poses (tunnels, urban canyons, deep snow obscuring markings) as triggers for degraded operation — speed caps, larger safety margins, or transition to the fallback channel.

Prediction and planning stack

Prediction estimates what every agent in the world model will do in the next 3 to 8 seconds. Planning decides what the ego vehicle will do over the same horizon. Together, they are where most of the open research problems live in 2026, and they account for the majority of disengagements in real operations.

Prediction runs per-agent trajectory forecasting conditioned on the scene context. The 2026 default is a Transformer-based multi-modal predictor that outputs a small set of candidate trajectories per agent (typically 3 to 6 modes) with associated probabilities. Joint prediction across interacting agents (e.g. a four-way unprotected left) is increasingly being modelled as a single joint distribution rather than independent per-agent predictions. Waymo’s MultiPath++ and the DESIRE/SceneTransformer lineage are well-known reference points.

Behaviour planning sits above motion planning and decides discrete actions: change lane, yield, pass parked truck, creep into intersection, follow leader. The 2026 production approach is a hybrid of learned policy proposals (an imitation-learned policy network proposes candidate manoeuvres) and explicit rule-based filters that enforce the rules of the road, ODD constraints and safety envelopes. Pure end-to-end neural driving (Wayve, some Tesla approaches) is in pilot deployment but most safety cases still require an explicit behaviour layer.

Motion planning turns the chosen behaviour into a feasible spatio-temporal trajectory. Sampling-based planners (lattice planners, RRT* variants) and optimisation-based planners (sequential quadratic programming, MPC) coexist. The trajectory respects vehicle dynamics, comfort constraints (jerk and lateral acceleration limits) and a safety buffer around every predicted agent trajectory. Replanning runs at 10 to 20 Hz.

The output is a smooth reference trajectory, handed to a low-level lateral and longitudinal controller. Controllers are usually a layered MPC (longitudinal) plus a feedback-feedforward steering controller (lateral). At this layer, the actuator and tyre models matter, and physics-based simulation is the dominant validation tool.

Where planning gets hard: unprotected lefts, double-parked vehicles in narrow streets, four-way stops with pedestrians, construction zones with hand-signalling workers, and aggressive merges in mixed traffic. These are not solved problems and they are the reason L4 deployments are still geofenced.

Safety architecture: ASIL D redundancy, runtime monitor, MRC

The safety architecture is what separates a demo from a deployable AV. The 2026 reference safety architecture has three pillars: a primary AV channel rated for ASIL D, a diverse fallback channel sufficient to reach a minimum risk condition (MRC), and a runtime safety monitor that decides when to switch.

The primary channel is the full stack: all sensors, the BEV perception network, full prediction and planning, drive-by-wire commands. It targets ASIL D for the hazardous events ISO 26262 identifies — loss of vehicle control, unintended acceleration or braking, loss of steering authority. The decomposition often uses ASIL D(A,B) decomposition: an ASIL B perception with an ASIL B independent safety monitor combining into an ASIL D claim.

The fallback channel is diverse by design. It runs on a separate SoC (often a smaller ASIL D-rated MCU plus a modest accelerator), with a separate power rail, separate wiring, a separate sensor subset (typically the front imaging radars and a subset of cameras, deliberately not lidar) and a conservative planner. Its only behaviours are brake-to-stop, decelerate-and-pull-over, or continue lane-keeping at reduced speed. It is not a second AV stack; it is the thing that can safely stop the car when the primary fails.

The runtime safety monitor is the most under-discussed component in public AV literature. It runs plausibility checks against the primary channel’s outputs (object trajectories within physical limits, freshness of every sensor, lockstep voting between dual cores, monotonicity checks on speed and acceleration), SOTIF triggers per ISO 21448 (sensor degradation, out-of-distribution scene classification, weather above ODD limits), and health monitoring (CPU and GPU utilization, thermal, memory ECC). On any persistent trigger, it raises a fault to the safety arbiter.

The safety arbiter is hardware lockstep where possible (Infineon Aurix TC4x, NXP S32Z series are common choices). It votes between the primary channel’s planned trajectory and the fallback channel’s conservative trajectory. Under nominal conditions, the primary wins. On detected fault, the arbiter hands control to the fallback to execute an MRC. The MRC for an L4 robotaxi might be a controlled pull-over to the shoulder; for an L2+ vehicle it’s a hand-back to the human driver with a 4 to 10 second transition window — and increasingly, regulators require the L2+ system to perform an MRC itself if the human doesn’t take over.

ISO 21448 SOTIF is the bigger lift in 2026. It’s no longer enough to show the system is free of malfunctions; you have to argue it is free of unreasonable risk arising from performance limitations of the intended functionality — the long-tail problem. The safety case has to enumerate hazardous scenarios, demonstrate sufficient triggering-condition coverage in real and synthetic data, and show that residual risk is acceptable. This is what the verification and validation pipeline must produce.

Compute platform: centralized SoC vs zonal

The compute platform debate has largely been settled in favour of centralized AV SoCs sitting on top of zonal ECUs.

Centralized AV compute runs on one or two high-performance SoCs. The 2026 options are Nvidia Drive Thor (single-die ~2000 TOPS, GPU + Hopper-class transformers, ARM Neoverse CPUs, Tensor Memory Accelerators), Mobileye EyeQ Ultra (~176 TOPS plus dedicated accelerators), Qualcomm Snapdragon Ride Flex (~700 TOPS), and emerging Chinese SoCs (Horizon Journey 6, Black Sesame A2000). The primary SoC runs the BEV network and full stack; a secondary SoC, often a different vendor’s chip for diversity, runs the fallback channel and parts of the safety monitor.

The software stack is hybrid. AUTOSAR Adaptive runs the safety-critical real-time components, scheduled on the lockstep cores with bounded latency. A real-time Linux variant (PREEMPT_RT, sometimes QNX) runs the AI components in containers, with the GPU and accelerators time-shared via a deterministic scheduler. Communication between components uses DDS (often Cyclone DDS or Fast DDS for ROS 2 compatibility) or SOME/IP — but pinned to specific cores and given bounded latency budgets, not the default ROS 2 networking.

Zonal E/E architecture sits underneath. Four zonal ECUs (front, rear, left, right) gather signals from nearby smart sensors and actuators, run local pre-processing, and forward digested data to the central SoCs over 10 or 25 Gigabit automotive Ethernet with TSN (Time-Sensitive Networking) and PTP. This collapses the wiring harness from kilometres of legacy CAN/LIN harness into hundreds of metres of Ethernet plus short power runs, saves 30 to 50 kg of wiring weight, and enables over-the-air updates to most of the vehicle’s behaviour.

The trade-off: centralized SoCs are easier to update and easier to reason about for safety; zonal Ethernet adds latency budgets that must be controlled. Most 2026 programmes land on a hybrid — centralized for AV functions, zonal for body and chassis, with the legacy CAN-FD and FlexRay buses retained only for the most safety-critical actuator links (steering, brakes) until the actuator ECUs themselves migrate to Ethernet.

For a deeper treatment of the embedded-Linux side of automotive compute, see our industrial robotic systems architecture future 2026 post — many of the same TSN/PTP patterns apply.

V2X integration

V2X is the side-channel that gives the AV stack information it could not otherwise see. In 2026, the deployed flavour is C-V2X Release 16/17 — cellular-vehicle-to-everything — which gives both direct PC5 sidelink (5.9 GHz, infrastructure-free vehicle-to-vehicle and vehicle-to-roadside) and Uu cellular (4G/5G) for cloud-mediated services.

The on-board unit (OBU) handles the radio layer and the V2X message stack (BSM, SPaT, MAP, TIM, CPM in SAE J2735 / ETSI ITS-G5 dialects). It feeds into the AV stack as another sensor channel: cooperative perception messages add detected objects beyond the ego sensors’ field of view, signal-phase-and-timing messages tell the planner when a light will change, and traveller-information messages flag work zones and incidents.

The roadside unit (RSU) is the infrastructure counterpart. Modern RSUs are not passive radios — they host inference for connected infrastructure cameras and lidars, broadcast cooperative perception messages, and act as the protocol bridge between traffic-signal controllers and the C-V2X air interface.

Mobile edge computing (MEC) nodes sit at the edge of the cellular network. They host low-latency cooperative apps: a local digital twin of an intersection, fed by infrastructure sensors and adjacent vehicles, can give the AV a sub-100-ms view around occlusions. The cloud layer hosts the traffic management centre, the HD-map service that streams tiles to vehicles, and fleet operations including OTA updates.

A critical safety principle: V2X augments, but never replaces, on-board sensing. The AV must be able to operate safely without any V2X messages because (a) infrastructure deployment is patchy, (b) V2X messages can be spoofed or jammed, and (c) the cellular link can drop. Most 2026 stacks use V2X for hint-quality information that improves comfort and efficiency, not safety-critical decisions. The exception is signal-phase-and-timing data, which has cryptographic authentication and can be trusted — but even there, the AV’s vision system must independently see the traffic light.

For the full V2X architecture stack with deployment patterns and standards, see our connected vehicle V2X reference architecture 2026 post.

Trade-offs and gotchas

Every architecture choice in this post has been simplified. The real trade-offs are messier.

Sensor cost vs ODD coverage. A lidar-equipped L4 stack costs 20 000 to 60 000 USD in sensors alone. That works for a 24/7-utilized robotaxi but not a consumer car. L2+ vendors are aggressively betting that camera + 4D imaging radar can cover enough of the ODD; L4 vendors are betting it cannot.

HD-map staleness. Every L4 deployment has been bitten by stale maps. Construction starts overnight, the map says lane 2 is open, the lidar says it’s coned off — the run-time has to trust the lidar, not the map. Architectures must let the online perception override the map prior with a calibrated confidence test, not a hard rule.

SOTIF coverage is fundamentally probabilistic. You cannot prove your perception network handles every out-of-distribution scene. The safety case rests on a statistical argument over miles driven, scenario coverage in simulation and on-road, and a residual-risk argument. Regulators are getting comfortable with this in geofenced robotaxi contexts; in consumer L3 the bar is higher.

Latency budgets compound. The 100 ms sensor-to-actuation budget is broken down across sensors (~20 ms), Ethernet plus pre-processing (~10 ms), perception (~40 ms), planning (~20 ms), control plus drive-by-wire (~10 ms). Slip on any one and the comfort metric falls off a cliff. Most architectures run a latency-budget tracker in production telemetry.

Hardware-software lifecycle mismatch. A vehicle programme spans 5 to 7 years from SoC selection to production, and the vehicle is on the road for another 10. Your 2026 architecture has to keep updating its neural networks through 2036+. OTA infrastructure, model versioning, A/B rollback, regression testing on captured field data — all are first-class architecture concerns, not afterthoughts.

Diversity is expensive. True ASIL D diversity means different silicon vendors, different perception algorithms, separate sensor wiring and power, separately certified toolchains. Many programmes try to claim diversity from the same vendor with different cores — that is increasingly being challenged by safety assessors.

Thermal and power are real constraints. A Drive Thor or Snapdragon Ride Flex SoC at full load draws 200 to 500 W. That’s a noticeable chunk of the EV’s 12 kW HVAC and propulsion budget, and the SoC plus its cooling loop add cost, weight and a failure mode. Compute budgets are not bottomless.

Practical recommendations

For teams designing a 2026-era AV architecture, the patterns that consistently work:

1. Start from the operational design domain, not the sensor BOM. Define exactly where, when and under what conditions the system operates. Every architectural choice should be justified against the ODD. A geofenced robotaxi and a consumer-car L2+ system have the same blocks but different sizing.

2. Pick the BEV feature space as your perception interface early. Make every downstream component (prediction, planning, monitoring) consume from BEV features and outputs, not raw sensor streams. This lets you swap or add sensors without rewriting the world model.

3. Design the fallback channel before the primary. It is the easier engineering problem and the one regulators care about most. If you can’t articulate the MRC trajectory for every failure mode, you don’t have an architecture, you have a hope.

4. Treat the safety monitor as a separate engineering discipline. It needs its own team, its own data set of triggers, its own simulator, and its own safety case. Bolting it on near production is the most common reason programmes slip.

5. Plan the OTA stack on day one. Neural networks improve monthly; vehicles live for a decade. The architecture must support shadow-mode evaluation of new networks in fleet, staged rollouts, and immediate rollback. That implies model versioning, telemetry, and a regulatory-grade audit trail.

6. Pin the latency budget early and measure it in production. Every component must publish input and output timestamps with hardware grade, and the latency budget must be checked in CI plus on the road.

7. Use V2X for comfort, not safety, until the deployment is dense enough. Plan for V2X benefits but architect as if V2X is absent. This matches the regulatory bar.

8. Validate end-to-end in simulation plus on-road, with a coverage argument. No one number proves safety. The argument is: scenario coverage from real driving plus catalogued edge cases plus synthetic generation, with a residual-risk argument. Build the tooling for this from the start.

For ROS 2-based prototyping of these patterns at smaller scale, our ROS 2 Jazzy on Jetson Orin warehouse robotics tutorial 2026 walks through the deterministic-DDS, time-sync and zonal-Ethernet patterns on lower-cost hardware. For the broader automotive IoT picture beyond AVs, see IoT use cases in automotive industry architecture 2026.

FAQ

What level of autonomy is actually deployed in 2026?

Two distinct things are deployed at scale. SAE Level 4 robotaxis operate commercially in geofenced areas of San Francisco, Phoenix, Wuhan, Beijing, Shanghai, Austin and a handful of others, with Waymo, Cruise, Pony.ai, Apollo Go, AutoX and WeRide. Level 2+ ADAS — eyes-on, hands-off in defined conditions — ships in mainstream cars from Mercedes, BMW, GM Super Cruise, Ford BlueCruise, Tesla Autopilot, NIO, Xpeng and others. Level 3 (eyes-off in defined conditions) ships in a small number of premium cars with strict ODDs. No consumer car drives itself everywhere.

Is lidar required for a 2026 AV reference architecture?

For an L4 deployment seeking a defendable safety case, the industry answer in 2026 is yes — every commercially operating robotaxi uses lidar. For L2+ consumer ADAS, lidar is not required and most stacks use camera plus 4D imaging radar. Tesla’s vision-only stack remains an outlier. The technical reason: lidar gives direct depth and is failure-mode-independent from cameras, which dramatically simplifies the SOTIF argument for L4 ODDs.

What’s the difference between ISO 26262 and ISO 21448?

ISO 26262 covers functional safety — risk from malfunctions like a stuck bit or a broken wire. ISO 21448 (SOTIF) covers safety of the intended functionality — risk from performance limitations of correctly working software, such as a perception network that fails on an out-of-distribution scene. Both are required for an AV programme. ISO 21448 is the harder one because it concerns the long tail of edge cases, not the design of well-understood components.

Is V2X required for autonomous driving?

No. Every commercially deployed AV in 2026 can operate safely without V2X messages. V2X is an augmentation that improves comfort, fuel economy and intersection handling, but the safety case must close without it because infrastructure coverage is patchy and the air interface can be jammed or spoofed. V2X becomes more important as fleets scale and as cities invest in roadside infrastructure, but it is not on the safety-critical path.

How much compute does a 2026 AV need?

A typical L4 platform allocates 1000 to 2000 TOPS of mixed-precision AI compute across one or two SoCs, plus 100 to 400 conventional CPU cores for the supervisory stack, plus an ASIL D-rated lockstep MCU for the safety arbiter. Power draw is 200 to 500 W under load. L2+ consumer stacks operate at 100 to 400 TOPS on a single SoC. Compute is no longer the bottleneck for production AVs; latency, validation and the long tail of edge cases are.

What about Tesla’s vision-only approach?

Tesla operates the largest fleet of L2 ADAS vehicles and has publicly argued that vision plus large neural networks plus enormous fleet data is sufficient for higher levels of autonomy. Their FSD beta has been deployed to a large number of US drivers as an L2 supervised system. In 2026, no third-party regulator has accepted a vision-only L4 deployment, and Tesla has not published the safety case that would support one. Treat any public Tesla claim about timelines or capability with appropriate scepticism, and follow what is shipping in production rather than what is announced.

Further reading

• SAE J3016 — Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles. The authoritative source for SAE Levels 0-5.
• ISO 26262 (2018) — Road vehicles, functional safety. The reference standard for ASIL decomposition and the V-model for safety-critical software.
• ISO 21448 (2022) — Road vehicles, safety of the intended functionality. The SOTIF standard for long-tail and performance-limitation risks.
• UN R157 — Uniform provisions concerning the approval of vehicles with regard to Automated Lane Keeping Systems. The regulatory baseline for L3 ALKS, now extended beyond highway scenarios.
• Waymo’s safety-case framework white papers (most recent generation, public).
• Cruise relaunch architecture and safety case documents (public summaries).
• Mobileye’s “True Redundancy” and Drive surround-vision technical papers.
• Nvidia Drive Thor product documentation and Hyperion 9 platform overview.
• Tesla AI Day technical content — useful for the BEV-network and occupancy-network architecture, although deployment claims should be hedged.
• The CARLA, NuPlan and Waymo Open Motion Dataset open benchmarks for planning and prediction.
• Internal: connected vehicle V2X reference architecture 2026, industrial robotic systems architecture future 2026, ROS 2 Jazzy on Jetson Orin warehouse robotics tutorial 2026, IoT use cases in automotive industry architecture 2026.

The shape of the autonomous vehicle reference architecture in 2026 is stable. The hard work is no longer in the block diagram; it is in the latency budget, the SOTIF safety case, the long tail of edge cases, and the OTA-driven decade-long evolution that turns a 2026 vehicle into a 2036 one.