Automotive (ASIL-D, ISO 26262)
ADAS Central Compute Unit: 500+ Safety Mechanisms traced & auditable
Real architecture: Central Computing Unit for L2 Automated Driving with dedicated Safety Island, multi-SoC design, ASIL-D target
The Hidden Problem: 500+ Safety Mechanisms — Not Verifiable Manually
- Safety Cluster (ASIL-D): Dedicated MCU (TCx) + Safety Island — can independently trigger Fast Power-Off
- Performance Cluster (ASIL-B): Qualcomm/MediaTek Perception-SoC + AI Extension
- Power Domain Separation: Multi-Layer PMIC (8+ independent domains)
- Auditor Question: "How do you ensure the system is ASIL-D safe if the Performance Cluster fails completely?"
- Manual Answer: Weeks of manual review across 500+ pages of specifications
The Graph: Automatic Safety-Mechanism Traceability
- TSR-001: Safety Cluster can independently trigger Fast Power-Off
- 500+ ISMs linked: MCU Hardware, PMIC Tree, Software Safety Logic
- Redundancy Model: 1oo2D with diverse implementations
- Impact Analysis: "ISM-042 failed" → Graph shows redundant backup ISM-043
- FMEA Coverage: 92.5%, Diagnostic Coverage: DC = 99.8%
Safety Goal → Technical Safety Requirement Traceability
SAFETY GOAL (ASIL-D):
"Emergency Stop in <50ms, independent of Performance-Cluster failure"
│ traces_to
▼
TSR-001: "Safety Cluster can independently trigger Fast Power-Off"
│ allocated_to (>500 ISMs)
├─▶ MCU Hardware (ISM-1 to ISM-150) — Brownout, Watchdog, E2E
├─▶ PMIC Tree (ISM-151 to ISM-350) — TI TPS6594-Q1: 200+ ISMs
└─▶ Software Safety (ISM-351 to ISM-500) — Timing, Voting, Heartbeat
500+
Safety Mechanisms
<50ms
FTTI
99.8%
Diagnostic Coverage
1h
Audit Time (vs. 4 weeks)