E2E Protection Library - AUTOSAR Expert

E2E Profile P01: CRC8 for ASIL-B PDUs

P01 Field	Value	Purpose
CRC polynomial	0x1D (CRC-8/SAE-J1850-Zero)	Single-bit and burst error detection; sufficient for ASIL-B
DataID	16-bit, included in CRC	Prevents wrong-routing errors (wrong sender, wrong receiver, wrong signal)
Counter	4-bit (0–14, 15 = not used)	Detects stale or repeated data; counter must increment each Send() call
Header overhead	1 byte (CRC) + nibble (counter)	Packed into first byte of PDU; 1-byte total overhead for ≤32 byte PDUs
Max PDU size	32 bytes	P01 not suitable for larger PDUs — use P04

CE2E_P01_Usage.c

/* Sender side: protect before writing to COM signal buffer */
E2E_P01ConfigType p01Cfg = {
    .DataLength  = 16,      /* PDU length in bits */
    .DataID      = 0x1A2B,  /* unique per signal */
    .CounterInit = 0x0,
    .MaxDeltaCounterInit = 1,
};
E2E_P01StateType senderState;
E2E_P01ProtectInit(&senderState);

uint8 txData[2];
(void)Rte_IRead_SpeedSafety_SpeedIn(&speedVal);
txData[0] = (uint8)(speedVal >> 8);
txData[1] = (uint8)(speedVal & 0xFF);
/* E2E_P01Protect appends CRC+counter to txData[0] (in-place) */
E2E_P01Protect(&p01Cfg, &senderState, txData, sizeof(txData));
(void)Rte_IWrite_SpeedOut_SpeedPDU(txData);

E2E Profile P04: CRC32 for ASIL-D PDUs

P04 Field	Value	Purpose
CRC polynomial	CRC-32P4 (0xF4ACFB13)	Detects up to 5-bit burst errors; ASIL-D capable
DataID	32-bit	Larger namespace; prevents wrong routing in complex systems
Counter	8-bit (0–255)	256-value counter; wrap-around after 256 cycles — application must handle gracefully
Length field	16-bit, in header	Detects truncated PDUs
Header overhead	4 bytes (CRC32 + counter + length + DataID MSB)	Added as prefix to data payload
Max PDU size	4096 bytes	Suitable for large data structures (calibration tables, diagnostic payloads)

CE2E_P04_Usage.c

/* E2E P04: wrap torque command before sending to EPS actuator */
static E2E_P04StateType rxState = {0};
static E2E_P04ConfigType p04Cfg = {
    .DataLength  = 64,       /* 8 bytes payload in bits */
    .DataID      = 0x00001A3BUL,
    .Offset      = 0,        /* header at byte 0 */
    .MaxDeltaCounter = 1,
    .MinOkStateInit  = 1,
    .MaxErrorStateInit = 7,
};

/* Receiver: check after Rte_IRead */
TorqueCmd_t rxCmd;
uint8 rawBuf[8];
(void)Rte_IRead_EPSCtrl_TorqueCmdIn(rawBuf);
E2E_P04CheckStatusType checkResult;
E2E_P04Check(&p04Cfg, &rxState, rawBuf, sizeof(rawBuf));
checkResult = E2E_P04GetLastStatus(&rxState);

if (checkResult == E2E_P04STATUS_OK ||
    checkResult == E2E_P04STATUS_OKSOMELOST) {
    /* Data valid — extract payload */
    memcpy(&rxCmd, rawBuf + E2E_P04_HEADER_SIZE, sizeof(rxCmd));
    ApplyTorqueCmd(&rxCmd);
} else {
    /* E2E failure — enter safe output state */
    ApplySafeTorqueOutput();
}

Integration with COM Signal Path

E2E in Signal Path (SWC wrapper pattern)

  Sender SWC
    ├── E2E_P04Protect(&cfg, &state, txBuf, len)    ← add CRC+counter
    └── Rte_IWrite_TorqueCmdOut_Buf(txBuf)          ← write to COM port

  COM → PduR → CanIf → CAN bus

  Receiver SWC
    ├── Rte_IRead_TorqueCmdIn_Buf(rxBuf)            ← read from COM port
    ├── E2E_P04Check(&cfg, &state, rxBuf, len)      ← verify CRC+counter
    └── if status OK: extract payload; else: safe state

  Note: E2E transformers are placed in SWC wrappers,
        NOT inside BSW COM — this is the AUTOSAR CP pattern for CP R4.x

💡 E2E Transformer vs SWC Wrapper

AUTOSAR R4.2+ introduced E2E Transformers that can be invoked automatically by the COM module. However, in practice most CP R4.x projects implement E2E as explicit SWC-wrapper calls (E2E_P04Protect/E2E_P04Check) because transformer configuration adds ARXML complexity and limits debuggability. Both approaches are standards-compliant — check your project's BSW integration spec for the mandated approach.

E2E State Machine & FIM Integration

E2E State	Condition	Action
VALID	CRC OK, counter sequential	Normal operation — pass data to downstream function
WRONGSEQUENCE	Counter skipped > MaxDeltaCounter	May indicate lost PDU — increment lost counter; function continues with stale data
ERROR	CRC mismatch	Data corrupt — FIM inhibits downstream function; SWC applies safe output
INITIAL	First receive after init	Function uses initialisation value until first valid PDU arrives
REPEATED	Counter identical to previous	Sender not updating — treat as stale, apply timeout logic

CE2E_FIM_Integration.c

/* E2E ERROR state drives FIM inhibition via DEM event */
if (checkResult == E2E_P04STATUS_ERROR) {
    e2eErrorCount++;
    if (e2eErrorCount >= E2E_ERROR_THRESHOLD) {
        /* Report to DEM → FIM inhibits EPS function */
        Dem_ReportErrorStatus(DEM_EVENT_E2E_TORQUE_ERROR,
                              DEM_EVENT_STATUS_FAILED);
        e2eErrorCount = 0;
    }
    ApplySafeTorqueOutput();
} else {
    /* Clear DEM event on recovery */
    if (e2eErrorCount > 0) {
        Dem_ReportErrorStatus(DEM_EVENT_E2E_TORQUE_ERROR,
                              DEM_EVENT_STATUS_PASSED);
        e2eErrorCount = 0;
    }
}

Summary

E2E protection covers all three ISO 26262 communication fault models: data corruption (CRC), stale/repeated data (counter), and wrong routing (DataID). Profile P01 is sufficient for ASIL-B short PDUs; Profile P04 is required for ASIL-D. The E2E state machine must be wired to DEM events and FIM inhibition — an E2E ERROR without a safety response is not a valid ISO 26262 implementation.

🔬 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.