DEV Community: Mohammed Talal Kadri

[Boost]

Mohammed Talal Kadri — Thu, 17 Sep 2026 02:08:13 +0000

Mohammed Talal Kadri

Sep 16

How to Validate FFI Between QM and ASIL-D in Zero-Heap AUTOSAR + HSM

#architecture #security #systems

1 min read

How to Validate FFI Between QM and ASIL-D in Zero-Heap AUTOSAR + HSM

Mohammed Talal Kadri — Wed, 16 Sep 2026 20:53:30 +0000

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.

ASIL-D Zero-Heap RTOS: 8.7µs CAN-FD Latency with MPU FFI on HIL

Mohammed Talal Kadri — Wed, 16 Sep 2026 19:56:11 +0000

Verifying No Interference in the AUTOSAR Base Without Memory for Electric Vehicles

For a long time, I've been working on a challenge faced by many integrated electronics engineers: how can the absence of interference (FFI) between the QM and ASIL-D bands be proven when everything is running on a memory system with a fixed memory allocation?

This is my approach, which has been practically tested on the electric platform v2.4 (ECM: HV-CTRL-01) using HIL simulation and telemetry data from real instruments.

[Image of telemetry data here - safety band + isolated band diagram + screenshot of telemetry data on a wet track]

The Problem: Most explanations are based on the AUTOSAR system in theory. In practice, if the QM software gets stuck in a single byte of the ASIL-D torque vectoring packet, the system crashes.

The Electronics: Empty heap memory. Everything is fixed. Large storage capacity of up to 256 volumes, and ample storage space of 34.6 volumes. No use of the MALUK function, no fragmentation, and no room for excuses. This is how we achieve a constant O(1).

My architecture:

The system is divided into two domains with hardware-level security measures. The security domain (ASIL-D) uses Dual-Core Lockstep + BITE technology and monitors the core via a memory feed revision loop. The isolated domain (QM) uses a monitoring/broadcasting module.

In between: Comprehensive protection with AUTOSAR technology and CRC-8/16/32 per frame (HV_CTTL, BMS_SLAVE3, INV_CTL, DRV_CTL) + integrated Evita hardware security with a hardware digital fingerprint. ...Triple redundancy outputs: vehicle actuator signals (steering, differential, torque vectoring) + safety/failure status + encrypted services.

Track Verification: Wet μ=0.26

I activated the digital twin using HIL, with 100-second accuracy. I selected a low-friction zone at a speed of 42.6 km/h.

Main Control: Front Axle +15% Torque, Front Axle -18% Torque, Differential Guide 12%/35% Turn Assist.

Result: Deviation Rate -0.42 radians/s, Stability Ratio 0.18-0.22, Target Track: Steady.

Only the element remained a constant vector at 8.7 microseconds (minimum 7.2/maximum 11.4) with a constant voltage vector of 398.2 V and an operating current of 142.5 A.

Therefore, the interference-free system was calibrated according to ISO 26262 and ISO 21434, not through presentations, but through regenerative sensor measurement data.

The Importance of This:

If you are developing platforms for electric vehicles, do not rely on dynamic memory allocation. Use zero memory, assume a fixed allocation, protect each frame with an AUTOSAR E2E CRC, and separate quality management from the ASIL-D security level using a security device (HSM).

I have verified this on real hardware in a HIL environment—not just through simulation. Current test data confirms this: CAN internet latency is 8.7 microseconds, no memory fragments, and stable trajectory on a wet track. For inquiries or litigation, please contact kadritalal38@gmail.com.

Talal Ali | Electric Vehicle Platform, Version 2.4 | HV-CTRL-01