Automotive (ASIL-D, ISO 26262)
ADAS Central Compute Unit: 500+ Safety Mechanisms zu tracieren & auditable machen
Reale Architektur: Central Computing Unit für L2 Automated Driving mit dedizierter Safety Island, multi-SoC Design, ASIL-D Target
Das versteckte Problem: 500+ Safety Mechanisms — manuell nicht nachweisbar
- Safety Cluster (ASIL-D): Dedicated MCU (TCx) + Safety Island — kann unabhängig Fast Power-Off triggern
- Performance Cluster (ASIL-B): Qualcomm/MediaTek Perception-SoC + AI Extension
- Power Domain Separation: Multi-Layer PMIC (8+ unabhängige Domains)
- Auditor-Frage: „Wie stellen Sie sicher, dass das System ASIL-D-sicher ist, wenn der Performance Cluster komplett ausfällt?"
- Manuelle Antwort: Wochen von Handbuch-Review auf 500+ Seiten Spezifikationen
Der Graph: Automatische Safety-Mechanism-Traceability
- TSR-001: Safety Cluster kann unabhängig Fast Power-Off auslösen
- 500+ ISMs verlinkt: MCU Hardware, PMIC Tree, Software Safety Logic
- Redundanz-Modell: 1oo2D mit diversitären Implementierungen
- Impact-Analyse: „ISM-042 ausgefallen" → Graph zeigt redundanten Backup ISM-043
- FMEA-Coverage: 92.5%, Diagnostische Abdeckung: DC = 99.8%
Safety Goal → Technical Safety Requirement Traceability
SAFETY GOAL (ASIL-D):
"Emergency Stop in <50ms, unabhängig von Performance-Cluster-Fehler"
│ traces_to
▼
TSR-001: "Safety Cluster kann unabhängig Fast Power-Off auslösen"
│ allocated_to (>500 ISMs)
├─▶ MCU Hardware (ISM-1 bis ISM-150) — Brownout, Watchdog, E2E
├─▶ PMIC Tree (ISM-151 bis ISM-350) — TI TPS6594-Q1: 200+ ISMs
└─▶ Software Safety (ISM-351 bis ISM-500) — Timing, Voting, Heartbeat
500+
Safety Mechanisms
<50ms
FTTI
99.8%
Diagnostic Coverage
1h
Audit-Zeit (statt 4 Wochen)