EV Safety & Redundancy Hardware

This page covers the autonomy-critical hardware that detects faults, maintains control, or transitions the vehicle to a safe state when sensors, compute, or power paths fail.

Why this layer exists

As human fallback decreases, safety must be enforced by physical redundancy and deterministic supervision hardware.

Core safety design modes

Mode	What it means	Typical fit	Hardware implication
Fail-safe	Transition to a safe state (often a controlled stop) when a fault is detected	ADAS (L2) and early conditional autonomy	Supervision + safe-stop capability; limited redundancy may be acceptable
Fail-operational	Continue operating safely despite certain faults long enough to complete a maneuver or reach a minimal risk condition	Higher autonomy (L4) where human fallback is not assumed	Independent redundant compute, power, sensing, and actuation pathways

Safety & redundancy hardware elements

The items below are organized by where faults occur in the autonomy execution chain: sensing, compute, power, and actuation.

1) Redundant compute paths

Independent compute elements that can supervise or replace each other to prevent unsafe command outputs.

• Dual SoCs (System-on-Chip) or primary SoC plus a safety monitor MCU (Microcontroller Unit)
• Lockstep CPU cores and safety islands inside SoCs
• Independent memory protection (ECC) and watchdog supervision

2) Functional safety MCUs

Deterministic safety controllers used for supervision, cross-checking, and safe-state transitions.

• Lockstep cores
• Error-correcting code (ECC) memory
• Hardware watchdogs and clock/voltage monitors
• ASIL-focused features aligned to ISO 26262

3) Redundant power hardware

Physical power paths that keep autonomy-critical systems alive through faults and transients.

• Independent low-voltage (12 V / 48 V) rails for safety domains
• Dual DC-DC converter paths (where required)
• Brown-out protection and power-good monitoring
• Isolation where necessary to prevent fault propagation

4) Sensor redundancy

Overlapping sensing using multiple sensors and modalities to avoid single-point-of-failure perception loss.

• Modality overlap (e.g., camera + radar for braking decisions)
• Overlapping fields of view from multiple cameras or radars
• Independent sensor power and data paths (where required)

5) Actuation redundancy

Redundant steering and braking pathways to maintain control or execute a controlled stop under faults.

• Steering-by-wire redundancy (dual motors, clutches, redundant sensing)
• Brake-by-wire redundancy (dual pressure sources or redundant actuator paths)
• Redundant command channels to vehicle motion controllers

6) Safety monitoring & isolation hardware

Hardware that detects faults, isolates failing domains, and prevents unsafe propagation.

• Watchdog and supervisor ICs
• Fault detection and isolation ICs
• Galvanic isolation barriers (where required)
• Safety monitors inside SoCs (safety islands)

System mapping

This table maps each safety hardware element to the subsystem it protects and what it enables.

Hardware element	Primary protects	Enables	Common location
Redundant compute paths	Perception/planning compute correctness	Command sanity, continuity under compute faults	Central ADAS/AV compute + safety monitor
Functional safety MCUs	Control integrity and safe-state logic	Deterministic supervision and safe-stop triggers	ADAS domain controller, gateway, or central compute module
Redundant power paths	Compute, steering, braking availability	Fail-operational power continuity	Low-voltage distribution feeding autonomy-critical loads
Sensor redundancy	Perception coverage and confidence	Degraded-mode operation without blind spots	Sensor suite (cameras, radar, LiDAR where used)
Actuation redundancy	Vehicle motion control authority	Controlled stop and continued control under faults	Steering-by-wire and brake-by-wire subsystems
Monitoring & isolation hardware	Fault containment	Prevents fault propagation across domains	Compute modules, power rails, and network safety domains

Relationship to adjacent stacks

This page defines autonomy safety requirements and the hardware patterns used to satisfy them. Adjacent pages implement or interface with these requirements.

• ADAS/AV Hardware Stack: sensors, compute, IVN (In-Vehicle Network), zonal/domain controllers, drive-by-wire interfaces
• HV/LV Electrical: implements power delivery, converters, and actuators that these safety requirements depend on
• Cybersecurity: separate stack (security is not the same as functional safety)

---