Expert Breakdown: Validating Freedom from Interference (FFI) between QM and ASIL-D
Architecture: Classic AUTOSAR R22-11, zero-heap design with static allocation only. No dynamic memory (MISRA Rule 21.3 compliant). Spatial isolation enforced via MPU regions per OS-Application. Temporal isolation via OsTaskExecutionBudget and timing protection. Communication via IOC with E2E Profile P11.
HSM Enforcement: Evita Full HSM, FW 3.1. SHE+ key isolation, secure boot verification chain, and hardware firewall. QM domain has no physical access to ASIL-D NVM, keys, or secure RAM. All crypto services routed through CSM -> Crypto Driver -> HSM. HSM acts as safety guardian, not just crypto accelerator.
HIL Validation: dSPACE SCALEXIO HIL. Fault injection campaign: 1000+ tests including pointer corruption, stack overflow, and MPU violation attempts from QM tasks. Result: 100% containment. No ASIL-D data corruption, no timing overrun. Measured safe-state transition: 8.7µs (FTTI Requirement: <10µs).
Conclusion: Full FFI achieved per ISO 26262-6 Annex D. Zero interference on memory, timing, and data exchange. Architecture ready for ASIL-D product audit.
Top comments (1)
Great breakdown! For those asking about the validation setup:
The 8.7µs safe-state was not a simulation, it was live HIL telemetry from dSPACE SCALEXIO (see dashboard screenshot). Zero-heap is key here - when heap = 0 / 128 MB, you eliminate fragmentation as a failure mode per ISO 26262-6 Annex D.
Hardest part wasn't MPU, it was proving FFI on timing: OsTaskExecutionBudget + HSM firewall ensures QM entertainment domain (right side of diagram) can never starve the ASIL-D BITE core.
Happy to share sanitized MPU linker script or IOC E2E config if anyone is auditing similar architecture. What FTTI are you targeting in your project?
