Hands-On: ASIL-D ECU Configuration - AUTOSAR Expert

MPU Setup: ASIL-D OsApplication with Wild-Pointer Test

Configuration Step	Parameter	Value
OsApplication type	TRUSTED	FALSE (non-trusted — MPU enforced)
Code region	OsApplicationMemoryRegion, ACCESS=RX	__EPS_CODE_START__ to __EPS_CODE_END__
.data region	OsApplicationMemoryRegion, ACCESS=RW	__EPS_DATA_START__, SIZE=0x400
Stack region	OsApplicationMemoryRegion, ACCESS=RW	__EPS_STACK_START__, SIZE=0x800
Stack guard	OsApplicationMemoryRegion, ACCESS=NONE	__EPS_STACK_GUARD__, SIZE=0x20
OsProtectionHook action	PRO_TERMINATEAPPL_RESTART	EPS OsApp restarted; DEM event logged

CMPU_WildPointer_Test.c

/* Test procedure: inject wild pointer from QM task */
/* Run in development build with OsProtectionHook instrumented */
void Test_Spatial_FFI(void) {
    volatile uint32* ptr = (volatile uint32*)EPS_DATA_REGION_ADDR;
    *ptr = 0xDEAD; /* MPU FAULT expected here */
}
/* Pass criteria:
   1. OsProtectionHook called with E_OS_PROTECTION_MEMORY
   2. EPS OsApp restarted (PRO_TERMINATEAPPL_RESTART)
   3. DEM event DEM_EVENT_MPU_FAULT confirmed via $19 02
   4. Task_SafetyCtrl_10ms continues running (verify via TRACE32 timeline) */

WdgM Alive Supervision: Simulate 3 Consecutive Misses

CWdgM_AliveTest.c

/* Test: stop CheckpointReached for 3 consecutive WdgM cycles */
/* Simulate runnable stall without crashing ECU */
static uint8 suppressCheckpoint = 0;

FUNC(void, EPS_CODE) EPS_Control_Runnable(void)
{
    /* ... safety computation ... */

    /* Test hook: suppress checkpoint on demand */
    if (suppressCheckpoint == 0) {
        WdgM_CheckpointReached(WDGM_SE_EPS, WDGM_CP_EPS_ALIVE);
    }
}

/* From test harness: set suppressCheckpoint = 1 for 3 cycles */
/* Expected sequence:
   Cycle 1 miss: WdgM alive counter = 1 (below threshold)
   Cycle 2 miss: WdgM alive counter = 2
   Cycle 3 miss: WdgM SE_EPS transitions to FAILED
   → WdgM_MainFunction stops calling WdgIf_SetTriggerCondition(ON_STATE)
   → Hardware watchdog expires (configured 500ms)
   → System reset captured in TRACE32 power-loss trace */

E2E Profile 4: Single Bit-Flip Injection Test

CE2E_BitFlip_Test.c

/* Test harness: inject single bit-flip into E2E-protected PDU */
/* Verified in SIL (software-in-loop) test environment */

void Test_E2E_BitFlip(void)
{
    uint8 txBuf[12]; /* 4-byte E2E header + 8-byte payload */
    uint8 rxBuf[12];

    /* 1. Build valid E2E-protected PDU */
    TorqueCmd_t cmd = {.torque = 1500, .direction = FORWARD};
    E2E_P04Protect(&p04Cfg, &senderState, txBuf, sizeof(txBuf));

    /* 2. Inject single bit-flip in byte 5 (payload CRC coverage) */
    memcpy(rxBuf, txBuf, sizeof(rxBuf));
    rxBuf[5] ^= 0x01; /* flip bit 0 */

    /* 3. Receiver checks: */
    E2E_P04Check(&p04Cfg, &rxState, rxBuf, sizeof(rxBuf));
    E2E_P04CheckStatusType status = E2E_P04GetLastStatus(&rxState);

    /* Pass criteria: status == E2E_P04STATUS_ERROR */
    assert(status == E2E_P04STATUS_ERROR);

    /* 4. Verify downstream: SWC applies safe torque output (0 Nm) */
    assert(GetCurrentTorqueOutput() == 0);
    /* 5. DEM event confirmed via $19 02 */
}

Final Production Readiness Audit

Audit Item	Verification Method	Pass Criteria
DET = FALSE in all modules	CI shell script grep on GENDATA/	Zero DevErrorDetect = TRUE occurrences
OsProtectionHook call count	TRACE32 breakpoint counter in soak test (30 min)	Zero OsProtectionHook calls under nominal load
DEM DTC for E2E fault	UDS $19 02 after E2E bit-flip injection	DTC C00010 confirmed; status byte 0x08
WdgM reset verified	TRACE32 power-loss trace during alive miss test	System reset within 500ms of 3rd missed checkpoint
Stack watermarks	TRACE32 TASK.STACK.LIST after stress test	All tasks below 80% stack usage
ROM budget	Map file parser in CI	BSW partition ≤ 64KB; SWC ≤ 32KB

Summary

The ASIL-D ECU configuration hands-on session validates the complete safety stack: MPU spatial isolation, WdgM temporal supervision with hardware watchdog reset, and E2E P04 communication protection with fault injection. All three mechanisms must be tested on target hardware — SIL-only testing is insufficient for ISO 26262 ASIL-D evidence.

🔬 Deep Dive — Core Concepts Expanded

This section builds on the foundational concepts covered above with additional technical depth, edge cases, and configuration nuances that separate competent engineers from experts. When working on production ECU projects, the details covered here are the ones most commonly responsible for integration delays and late-phase defects.

Key principles to reinforce:

Configuration over coding: In AUTOSAR and automotive middleware environments, correctness is largely determined by ARXML configuration, not application code. A correctly implemented algorithm can produce wrong results due to a single misconfigured parameter.
Traceability as a first-class concern: Every configuration decision should be traceable to a requirement, safety goal, or architecture decision. Undocumented configuration choices are a common source of regression defects when ECUs are updated.
Cross-module dependencies: In tightly integrated automotive software stacks, changing one module's configuration often requires corresponding updates in dependent modules. Always perform a dependency impact analysis before submitting configuration changes.

🏭 How This Topic Appears in Production Projects

Project integration phase: The concepts covered in this lesson are most commonly encountered during ECU integration testing — when multiple software components from different teams are combined for the first time. Issues that were invisible in unit tests frequently surface at this stage.
Supplier/OEM interface: This is a topic that frequently appears in technical discussions between Tier-1 ECU suppliers and OEM system integrators. Engineers who can speak fluently about these details earn credibility and are often brought into critical design review meetings.
Automotive tool ecosystem: Vector CANoe/CANalyzer, dSPACE tools, and ETAS INCA are the standard tools used to validate and measure the correct behaviour of the systems described in this lesson. Familiarity with these tools alongside the conceptual knowledge dramatically accelerates debugging in real projects.

⚠️ Common Mistakes and How to Avoid Them

Assuming default configuration is correct: Automotive software tools ship with default configurations that are designed to compile and link, not to meet project-specific requirements. Every configuration parameter needs to be consciously set. 'It compiled' is not the same as 'it is correctly configured'.
Skipping documentation of configuration rationale: In a 3-year ECU project with team turnover, undocumented configuration choices become tribal knowledge that disappears when engineers leave. Document why a parameter is set to a specific value, not just what it is set to.
Testing only the happy path: Automotive ECUs must behave correctly under fault conditions, voltage variations, and communication errors. Always test the error handling paths as rigorously as the nominal operation. Many production escapes originate in untested error branches.
Version mismatches between teams: In a multi-team project, the BSW team, SWC team, and system integration team may use different versions of the same ARXML file. Version management of all ARXML files in a shared repository is mandatory, not optional.

📊 Industry Note

Engineers who master both the theoretical concepts and the practical toolchain skills covered in this course are among the most sought-after professionals in the automotive software industry. The combination of AUTOSAR standards knowledge, safety engineering understanding, and hands-on configuration experience commands premium salaries at OEMs and Tier-1 suppliers globally.