AUTOSAR E2E Profile 22: The Definitive Technical Guide to SOME/IP Event Safety Communication Protection

AUTOSAR E2E Profile 22 is the purpose-built End-to-End safety communication protocol for SOME/IP events in Automotive Ethernet service-oriented architectures – the event-driven counterpart to Profile 6, which protects SOME/IP data elements. While Profile 6 assumes a continuous sender-receiver data stream where the receiver has been present from the beginning and can build counter history from the first transmission, AUTOSAR E2E Profile 22 is specifically engineered for the fundamentally different communication pattern of SOME/IP events: a publisher that fires notifications when conditions change, and subscribers that can join the event stream at any point in time – including mid-sequence, long after the publisher’s counter has advanced past any value that a newly subscribed receiver could correctly validate without special initialization handling.

This defining behavioral difference – the “late subscriber” problem – is the architectural reason AUTOSAR E2E Profile 22 exists as a separate profile from Profile 6, despite sharing an identical 4-byte header structure. Both profiles use the same AUTOSAR E2E Profile 22 CRC-16 CCITT length DataID scheme: a CRC-16-CCITT polynomial (0x1021) with only the high byte stored in the header, an 8-bit sequence counter, a 16-bit explicit Length field for truncation detection, and a 16-bit DataID implicit in the CRC computation. Where they differ is in how the receiver’s state machine is initialized and how the first received events are handled after a subscriber subscribes to an already-running event stream. For E2E Profile 22 SOME/IP event Ethernet communication, the check function accommodates a configurable number of initial events where the counter is unknown, using the MaxDeltaCounterInit parameter to accept a wider counter delta window during the special INIT phase – preventing false WRONGSEQUENCE errors that would occur if the standard Profile 6 initialization logic was applied to a mid-stream event subscription.

This comprehensive guide covers every dimension of AUTOSAR E2E Profile 22: the precise 4-byte header layout with the E2E Profile 22 late subscriber 4-byte header structure at configurable Offset, the CRC-16 computation with implicit DataID, the SOME/IP event-specific initialization logic that distinguishes it from Profile 6, full protect and check algorithms with C code, real-world deployment patterns for automotive functional safety ISO 26262 ASIL D SOME/IP event interfaces, and a thorough comparison with Profile 6 that demystifies when to choose each.

🔗 Final article in the AUTOSAR E2E Master Series on PiEmbSysTech.
Parent page: AUTOSAR E2E Communication Protection: Complete Technical Guide

Table of Contents

1. What is AUTOSAR E2E Profile 22?

AUTOSAR E2E Profile 22 is defined in the AUTOSAR E2E Protocol Specification (AUTOSAR_PRS_E2EProtocol) and SW-C E2E Library Specification (AUTOSAR_CP_SWS_E2ELibrary) as the event-oriented End-to-End safety communication profile for SOME/IP Automotive Ethernet service architectures, supporting both AUTOSAR Classic Platform (CP) and Adaptive Platform (AP). Introduced alongside Profile 6 in AUTOSAR Release 4.2.1, it uses four protection mechanisms in a compact 4-byte header:

• CRC-16-CCITT (polynomial 0x1021), high byte only: 8 bits of CRC stored in the header (same as Profile 6); full 16-bit CRC computed, only high byte transmitted
• 8-bit Sequence Counter (0x00–0xFF): All 256 values valid, wraps 0xFF→0x00
• 16-bit Explicit Length Field: Total data length including header, Big Endian, for independent truncation detection
• 16-bit DataID (implicit in CRC): Never transmitted; incorporated by appending DataID bytes to the CRC computation

📌 Quick Reference — AUTOSAR E2E Profile 22 at a Glance

Profile Identifier	E2E_22 (AUTOSAR CP + AP)
CRC Algorithm	CRC-16-CCITT, polynomial 0x1021, Start: 0xFFFF, XOR: 0x0000
CRC in Header	1 byte (HIGH byte of 16-bit CRC only) – low byte discarded (same as Profile 6)
Counter	8-bit (0x00–0xFF), all values valid, wraps 0xFF→0x00
Length Field	16-bit, Big Endian, explicitly transmitted – total bytes incl. header
DataID	16-bit, NOT transmitted – implicit in CRC (appended as low byte then high byte)
Header Layout	[CRC-HIGH 1B][Counter 1B][Length-H 1B][Length-L 1B] – 4 bytes total
Header Offset	Configurable (bits, multiple of 8). Common: 0 or 64.
Maximum Data Length	4096 bytes (32,768 bits)
Minimum Data Length	5 bytes (header + 1 byte data)
KEY DIFFERENCE from Profile 6	Event-oriented: MaxDeltaCounterInit handles late subscriber mid-stream join. Profile 6 is for data elements (continuous streams); Profile 22 is for events (conditional notifications).
Platform Support	AUTOSAR CP + AP
Maximum ASIL	ASIL D
CRC Library Function	Crc_CalculateCRC16() – same as Profiles 5 and 6
Introduced In	AUTOSAR Release 4.2.1
Profile Pairing	P02↔P22 (analogous pair; both handle event/list-based DataID scenarios on different networks)

2. SOME/IP Events vs Data Elements: Why Two Profiles Are Needed

Understanding why AUTOSAR E2E Profile 22 exists alongside Profile 6 requires a clear understanding of how SOME/IP differentiates between data elements and events in its service-oriented communication model.

SOME/IP Data Elements (Profile 6 Use Case)

A SOME/IP data element is a persistent value that is continuously available from the service provider. When a consumer subscribes, the provider typically sends an initial value immediately (the “initial event” or “field notification”), and then continues to send updates at regular or change-triggered intervals. The key characteristic is continuity: the consumer expects a steady stream of updates, and the E2E counter should increment predictably from the first received value onward. Profile 6 with its standard INIT→VALID state machine handles this well – after receiving MinOkStateInit consecutive OK messages starting from the initial notification, the state machine transitions to VALID.

SOME/IP Events (Profile 22 Use Case)

A SOME/IP event is a notification that is only sent when something of interest occurs. Examples include: a fault code being set, a threshold being crossed, a vehicle state change, a diagnostic alert, or a safety boundary being reached. Events may be infrequent – seconds, minutes, or even hours apart – and a new subscriber might join the event stream long after the most recent event was published. When this late subscriber receives the first event notification, the event’s counter may be at any value (e.g., 0x87) while the subscriber’s check state was just initialized (expecting counter 0). Under Profile 6’s standard logic, this would produce WRONGSEQUENCE immediately – an incorrect result, since the subscriber has simply missed the earlier events while it was not yet subscribed.

AUTOSAR E2E Profile 22 solves this problem through a specially configured MaxDeltaCounterInit parameter. During the INIT state, the receiver accepts any counter value that falls within MaxDeltaCounterInit of the last received counter (or within the full 0–255 range for the very first event). This means a late subscriber can join an event stream mid-sequence without generating false errors during its initialization phase.

3. The Late Subscriber Problem – Profile 22’s Core Design Purpose

The late subscriber problem is the central engineering challenge that motivated the specification of AUTOSAR E2E Profile 22. It occurs in any publish-subscribe system where the publisher maintains a persistent counter state and new subscribers join an already-running publication stream.

⚠️ The Late Subscriber Problem – Concrete Example:
A safety monitor ECU subscribes to a SOME/IP event for “brake system fault notifications” 30 seconds after the vehicle has booted. During those 30 seconds, the brake ECU has published 12 fault-status events (counter has reached 0x0C). When the safety monitor receives the first event (counter=0x0D), its E2E check state machine was just initialized with counter=0x00. Under Profile 6 logic, the delta = 13 would far exceed MaxDeltaCounter (typically 1–3), producing WRONGSEQUENCE and INVALID – falsely indicating a communication fault. Under AUTOSAR E2E Profile 22 with MaxDeltaCounterInit=255, the first received event is accepted regardless of its counter value, and normal sequence monitoring begins from that point.

How Profile 22 Solves the Late Subscriber Problem

The AUTOSAR specification for AUTOSAR E2E Profile 22 introduces a dedicated initialization parameter MaxDeltaCounterInit that applies only during the INIT state. This parameter can be set to 255 (the maximum possible counter delta for an 8-bit counter), meaning that in INIT state, the check function accepts any counter value from a received event as a valid starting point – effectively saying “I don’t know where in the event sequence I am joining, so I’ll accept the first received event’s counter unconditionally.” After MinOkStateInit consecutive events are received with valid CRC, valid Length, and counter deltas within MaxDeltaCounterInit, the state machine transitions to VALID and normal strict counter monitoring (using MaxDeltaCounter) takes over.

This initialization behavior is the single most important difference between AUTOSAR E2E Profile 22 and Profile 6. Everything else – the header layout, the CRC algorithm, the Length field, the DataID handling – is identical between the two profiles. The behavioral difference is entirely in how MaxDeltaCounterInit is intended to be used and what communication pattern each profile is designed for.

4. History and Background of AUTOSAR E2E Profile 22

AUTOSAR E2E Profile 22 was introduced in AUTOSAR Release 4.2.1 alongside Profile 6 (data elements) and Profile 7 (large data). The specification explicitly documents the pairing relationship: Profile 2 and Profile 22 are analogous, just as Profile 1 and Profile 11 are analogous. Profile 2 protects CAN-based safety I-PDUs with its DataIDList[16] mechanism designed for multi-receiver fan-out scenarios; Profile 22 protects SOME/IP Ethernet events with its explicit Length field and late-subscriber initialization designed for multi-subscriber publish-subscribe scenarios.

The design philosophy is that while the physical protection mechanisms (CRC, counter, length, DataID) are the same for Profile 6 and Profile 22, the semantic context of “event” communication required different initialization semantics. AUTOSAR chose to express this difference as a separate profile – rather than a configuration flag within Profile 6 – to make the design intent explicit and to ensure that safety case reviewers and system architects immediately understand the communication pattern from the profile number alone.

5. AUTOSAR E2E Profile 22 in the SOME/IP Event Stack

╔══════════════════════════════════════════════════════════════════════╗
║              APPLICATION LAYER (ASIL D)                              ║
║  ┌──────────────────────────┐   ┌────────────────────────────────┐  ║
║  │  Event Publisher SW-C    │   │  Event Subscriber SW-C         │  ║
║  │  (e.g. Brake ECU)        │   │  (e.g. Safety Monitor)         │  ║
║  │  fires event on change   │   │  can join mid-stream           │  ║
║  └───────────┬──────────────┘   └──────────────┬──────────────── ┘  ║
║              │ E2E_P22Protect()                │ E2E_P22Check()     ║
║              ▼                                 ▲                    ║
║  ┌─────────────────────────────────────────────────────────────── ┐  ║
║  │         E2E LIBRARY — Profile 22 (ASIL D)                      │  ║
║  │  CRC-16-CCITT high byte + 8-bit Counter + 16-bit Length        │  ║
║  │  + 16-bit DataID (implicit) — 4-byte header                    │  ║
║  │  MaxDeltaCounterInit: handles late subscriber mid-stream join  │  ║
║  └────────────────────────────────────────────────────────────────┘  ║
╠══════════════════════════════════════════════════════════════════════╣
║              RTE (CP) / ara::com (AP) — event notification          ║
╠══════════════════════════════════════════════════════════════════════╣
║              SOME/IP over UDP/TCP — Automotive Ethernet              ║
╚══════════════════════════════════════════════════════════════════════╝

Critical architecture note:
  Profile 22 is for SOME/IP EVENTS (conditional, irregular notifications)
  Profile 6  is for SOME/IP DATA ELEMENTS (continuous, persistent values)
  Same header, same CRC — different initialization semantics

6. AUTOSAR E2E Profile 22 – Complete Technical Specifications

Parameter	Value / Description
Profile Identifier	E2E_22
CRC Algorithm	CRC-16-CCITT, polynomial 0x1021 (x¹⁶+x¹²+x⁵+1), Start: 0xFFFF, XOR: 0x0000
CRC in Header	1 byte (HIGH byte only) at Byte[Offset+0]. Low byte of 16-bit CRC discarded.
Counter	8-bit, range 0x00–0xFF. All values valid. Wraps 0xFF→0x00.
Counter Position	Byte[Offset+1]
Length Field	16-bit, Big Endian. Bytes[Offset+2..3]. Total data length including 4-byte header.
DataID	16-bit, NOT transmitted. Implicit in CRC: low byte then high byte appended after buffer during CRC computation.
Header Size	4 bytes — [CRC-HIGH][Counter][Length-H][Length-L]
Header Offset	Configurable (bits, multiple of 8). Relative to SOME/IP payload start.
Maximum Data Length	4096 bytes (32,768 bits)
Minimum Data Length	5 bytes minimum (Offset/8 + 4 + 1 data byte)
Variable-Length Support	Yes — explicit Length field for independent truncation detection
CRC Computation	Over buffer[Offset..end] (CRC byte zeroed) + DataID_low + DataID_high appended
Platform Support	AUTOSAR CP + AP
Maximum ASIL	ASIL D
CRC Library	Crc_CalculateCRC16() — shared with Profiles 5 and 6
Primary Use	SOME/IP events (conditional notifications, irregular intervals, multi-subscriber)
Effective CRC Protection	~2⁻⁸ = 1/256 (8-bit effective CRC, high byte only)
Introduced In	AUTOSAR Release 4.2.1

7. The AUTOSAR E2E Profile 22 4-Byte Header – Byte-Level Detail

The E2E Profile 22 late subscriber 4-byte header structure is byte-for-byte identical to the Profile 6 header. This is intentional – the same protection mechanisms serve both profiles, with the differentiation being entirely in the initialization behavior of the receiver.

AUTOSAR E2E PROFILE 22 — 4-BYTE HEADER STRUCTURE (Offset = 0)
═══════════════════════════════════════════════════════════════════

Byte:  [Offset+0]           [Offset+1]     [Offset+2]    [Offset+3]
       ┌──────────────────┬──────────────┬─────────────┬──────────────┐
Field: │ CRC-16[15:8]     │ Counter[7:0] │ Length[15:8]│ Length[7:0]  │
       │ (HIGH byte ONLY) │ (8-bit 0-255)│ (MSB, BE)   │ (LSB, BE)    │
       └──────────────────┴──────────────┴─────────────┴──────────────┘
          ◄── 1 byte ──►   ◄── 1 byte ──► ◄──── 2 bytes Big Endian ──►

Signal data: Bytes [Offset+4] through [TotalLength-1]

KEY POINTS (identical to Profile 6):
  Byte[Offset+0]: CRC-16 HIGH BYTE ONLY. Low byte of CRC-16 is discarded.
                  During CRC computation, this byte is set to 0x00.
  Byte[Offset+1]: Counter (8-bit, 0–255). All values valid. Wraps freely.
  Bytes[Offset+2..3]: Length (16-bit Big Endian) = total bytes including header.
  DataID: NOT in header. Appended to CRC computation as DataID_low then DataID_high.

CRC COMPUTATION SEQUENCE (same as Profile 6):
  1. Set Data[Offset] = 0x00 (zero CRC byte)
  2. Write Counter  → Data[Offset+1]
  3. Write Length   → Data[Offset+2..3] (Big Endian)
  4. CRC16 over Data[Offset..TotalLength-1] (with CRC byte = 0)
  5. Continue CRC16 over DataID_low byte
  6. Continue CRC16 over DataID_high byte
  7. Write HIGH BYTE of result → Data[Offset] (LOW BYTE DISCARDED)

EXAMPLE (Offset=0, DataID=0x3C8B, Counter=73, Length=20):
  Data[0] = 0xXX  (CRC high byte — computed)
  Data[1] = 0x49  (Counter = 73 = 0x49)
  Data[2] = 0x00  (Length MSB: 20 = 0x0014)
  Data[3] = 0x14  (Length LSB)
  Data[4..19] = 16 bytes of SOME/IP event payload data

✅ Profile 22 Header = Profile 6 Header: The 4-byte header of AUTOSAR E2E Profile 22 is byte-for-byte identical to Profile 6. A packet capture showing the SOME/IP payload cannot distinguish whether Profile 6 or Profile 22 was used to protect the data — the differentiation is entirely in the receiver’s state machine initialization parameters. This is why proper SOME/IP service interface documentation must clearly specify which profile protects each service interface, even though the wire format is the same.

8. CRC-16-CCITT High Byte – The Same Algorithm as Profile 6

AUTOSAR E2E Profile 22 CRC-16 CCITT length DataID uses the identical CRC algorithm as Profile 6: CRC-16-CCITT (polynomial 0x1021, Start = 0xFFFF, XOR output = 0x0000), with only the high byte of the 16-bit result stored in the header. The same critical design trade-off applies here as in Profile 6: the effective CRC protection is ~2⁻⁸ (8-bit), not ~2⁻¹⁶. For automotive functional safety ISO 26262 ASIL D SOME/IP event safety arguments, this means the quantitative residual error probability for data corruption must be based on the 8-bit effective CRC, not the full 16-bit CRC.

The CRC computation for AUTOSAR E2E Profile 22 appends the 16-bit DataID bytes after the buffer data – first the DataID low byte, then the DataID high byte – exactly as in Profile 6. This implicit DataID inclusion means that two different SOME/IP event types sharing the same payload structure but protected with different DataIDs will produce different CRCs, providing masquerade protection. The DataID assignment must be unique across all SOME/IP event and data element interfaces that share the same Ethernet network, with the same uniqueness requirements as for Profile 6.

One subtle but important difference worth noting: because SOME/IP events are conditional and irregular, consecutive Profile 22-protected events from the same publisher will have sequentially incrementing counters with potentially large time gaps between them. The CRC computation itself is stateless between events (each protection call is independent) – only the counter is stateful. This means CRC computation for Profile 22 has exactly the same computational cost and properties as for Profile 6 regardless of event frequency.

9. 8-Bit Counter and SOME/IP Event Rate Considerations

The 8-bit counter in AUTOSAR E2E Profile 22 (values 0x00–0xFF, all valid, wraps 0xFF→0x00) increments by 1 for each event publication by the provider. For typical SOME/IP events that fire on condition changes, the counter increment rate is event-rate dependent rather than time-based. A fault event that fires once per vehicle cycle increments the counter 0–3 times per trip. A threshold-crossing event that fires 10 times per second increments the counter at the same rate as a fixed-rate signal.

For event rate analysis, the most important parameters are MaxDeltaCounterInit (for the INIT phase) and MaxDeltaCounter (for the VALID phase). MaxDeltaCounterInit should be set to 255 for applications where the subscriber can join arbitrarily late (the typical case for SOME/IP event subscriptions). MaxDeltaCounter in the VALID phase should be set based on the expected maximum gap between events during normal operation — accounting for the fact that some events may be published at high rate followed by silence, or that a subscriber may temporarily miss events due to network congestion.

10. The 16-Bit Explicit Length Field for SOME/IP Event Truncation Detection

The 16-bit Length field in the E2E Profile 22 late subscriber 4-byte header provides the same independent truncation detection as in Profile 6. For SOME/IP events – which may carry variable-length payloads depending on which fields are included in the event notification – the Length field is particularly important because truncation of an event payload could deliver incomplete fault information or a partial safety status to the subscriber without any indication that data is missing.

The Length field carries the total byte count including the 4-byte E2E header. The receiver validates this against the actual received byte count AND against the configured MinDataLength/MaxDataLength range. Any mismatch between the received byte count and the Length field value produces E2E_P22STATUS_ERROR immediately. This behavior is identical to Profile 6 and is independent of the CRC check and the counter check.

11. DataID – Implicit CRC Inclusion in AUTOSAR E2E Profile 22

The 16-bit DataID in AUTOSAR E2E Profile 22 is implicit – it is never transmitted in the 4-byte header but is always incorporated into the CRC computation by appending the DataID low byte and then the DataID high byte to the CRC computation after the buffer data. This is byte-for-byte the same DataID handling as in Profile 6. The rationale and implications for integration debugging are identical to those described in the Profile 6 article: DataID mismatches appear as persistent CRC errors indistinguishable from data corruption, making explicit DataID verification tests mandatory in the integration test suite.

For SOME/IP event interfaces, the DataID should be unique not just across event interfaces on the same network, but also across event and data element interfaces – since Profile 6 and Profile 22 use the same CRC computation with the DataID, a Profile 22 event and a Profile 6 data element with the same DataID would produce the same CRC for the same payload data, which could create confusion in cross-checking scenarios. Maintaining a vehicle-level DataID registry that assigns unique values to both event and data element interfaces is strongly recommended for large-scale SOME/IP service architectures.

12. E2E_P22Protect() – Complete Algorithm and C Code

Function Signature

Std_ReturnType E2E_P22Protect(
    const E2E_P22ConfigType*   ConfigPtr,
    E2E_P22ProtectStateType*   StatePtr,
    uint8*                     DataPtr,
    uint16                     Length    /* Total data length in bytes */
);

The E2E_P22Protect() function is byte-for-byte algorithmically identical to E2E_P06Protect(). The protection algorithm does not differ between Profile 6 and Profile 22 – both protect SOME/IP payloads with the same CRC-16-CCITT high byte, counter, and Length. The behavioral difference between the two profiles exists exclusively in the check function’s initialization logic.

Complete E2E_P22Protect() C Implementation

/* ==============================================================
 * AUTOSAR E2E Profile 22 Protect — C Implementation
 * Algorithmically identical to E2E_P06Protect()
 * ============================================================== */
Std_ReturnType E2E_P22Protect(
    const E2E_P22ConfigType  *Config,
    E2E_P22ProtectStateType  *State,
    uint8                    *Data,
    uint16                    Length)
{
    uint8  offsetBytes = (uint8)(Config->Offset / 8U);
    uint8  dataID_low  = (uint8)(Config->DataID & 0xFFU);
    uint8  dataID_high = (uint8)((Config->DataID >> 8U) & 0xFFU);
    uint16 crc;

    if ((Config == NULL_PTR) || (State == NULL_PTR) || (Data == NULL_PTR))
        return E2E_E_INPUTERR_NULL;
    if ((Length < (uint16)(Config->MinDataLength / 8U)) ||
        (Length > (uint16)(Config->MaxDataLength / 8U)) ||
        (Length < (uint16)(offsetBytes + 4U)))
        return E2E_E_INPUTERR_WRONG;

    /* Write Counter at Byte[Offset+1] */
    Data[offsetBytes + 1U] = State->Counter;

    /* Write Length (Big Endian) at Bytes[Offset+2..3] */
    Data[offsetBytes + 2U] = (uint8)(Length >> 8U);
    Data[offsetBytes + 3U] = (uint8)(Length & 0xFFU);

    /* Zero CRC byte at Byte[Offset+0] before computation */
    Data[offsetBytes] = 0x00U;

    /* CRC-16-CCITT over data from Offset to end, then DataID bytes */
    crc = Crc_CalculateCRC16(&Data[offsetBytes],
                              (uint32)(Length - (uint16)offsetBytes),
                              0xFFFFU, TRUE);
    crc = Crc_CalculateCRC16(&dataID_low,  1U, crc, FALSE);
    crc = Crc_CalculateCRC16(&dataID_high, 1U, crc, FALSE);

    /* Store ONLY HIGH BYTE of 16-bit CRC result */
    Data[offsetBytes] = (uint8)((crc >> 8U) & 0xFFU);

    /* Increment counter, wrap 255 → 0 */
    State->Counter = (State->Counter == 0xFFU) ? 0x00U : (State->Counter + 1U);

    return E2E_E_OK;
}

13. E2E_P22Check() – The Late Subscriber Logic Explained

The E2E_P22Check() function is where AUTOSAR E2E Profile 22 fundamentally differs from Profile 6. The difference is in the INIT state counter delta evaluation, governed by the MaxDeltaCounterInit parameter.

How the Late Subscriber Initialization Works

/* E2E_P22Check() — Core Counter Evaluation Logic
 *
 * The key difference from Profile 6 is MaxDeltaCounterInit:
 * In INIT state, this can be set to 255 (full 8-bit range),
 * allowing any counter value from the first received event.
 */

uint8  recvCounter   = Data[offsetBytes + 1U];
uint16 recvLength    = ((uint16)Data[offsetBytes+2] << 8) | Data[offsetBytes+3];
uint8  recvCRCHigh   = Data[offsetBytes];

/* Step 1: Length validation */
if (recvLength != Length) { State->Status = E2E_P22STATUS_ERROR; return E2E_E_OK; }
if ((recvLength < Config->MinDataLength/8) ||
    (recvLength > Config->MaxDataLength/8)) {
    State->Status = E2E_P22STATUS_ERROR; return E2E_E_OK;
}

/* Step 2: CRC validation (same as Profile 6) */
/* ... recompute and compare high byte ... */

/* Step 3: Counter Delta Evaluation — THE KEY DIFFERENCE */
uint8 delta;
uint8 maxDelta;

if (State->SMState == E2E_SM_INIT) {
    /* INIT state: use MaxDeltaCounterInit — typically 255 for events */
    maxDelta = Config->MaxDeltaCounterInit;
    delta    = (State->HasFirstCounter == FALSE)
                 ? 0U   /* First event ever: accept unconditionally */
                 : (uint8)(((uint16)recvCounter - State->LastValidCounter + 256U) % 256U);
} else {
    /* VALID/INVALID state: use strict MaxDeltaCounter */
    maxDelta = Config->MaxDeltaCounter;
    delta    = (uint8)(((uint16)recvCounter - State->LastValidCounter + 256U) % 256U);
}

/* Classify the counter delta */
if (delta == 0U) {
    State->Status = E2E_P22STATUS_REPEATED;
} else if (delta <= maxDelta) {
    State->Status = (delta == 1U) ? E2E_P22STATUS_OK : E2E_P22STATUS_OKSOMELOST;
    State->LastValidCounter  = recvCounter;
    State->HasFirstCounter   = TRUE;
} else {
    State->Status = E2E_P22STATUS_WRONGSEQUENCE;
}

Typical MaxDeltaCounterInit Values for SOME/IP Events

Event Pattern	Recommended MaxDeltaCounterInit	Rationale
Safety alerts, fault events – subscriber can join anytime	255	Accept any counter on first reception – full late subscriber support
Periodic events with known startup order	3–10	Subscriber expected to subscribe within a few event cycles of publisher start
High-rate events (>10 Hz) with fixed subscription timing	5–15	Allow for a few events missed between subscription and first receipt
One-time lifecycle events (boot-up, config change)	255	Subscriber may join well after the single initial event was published

Complete Event Subscriber SW-C – Safety Alert Consumer

/* Safety monitor subscribing to SOME/IP brake fault event
 * Publisher fires event when fault detected; subscriber may join late */
void SafetyMonitor_ReceiveBrakeFaultEvent(void)
{
    BrakeFaultEventType rxEvent;
    uint16 rxLength;
    Std_ReturnType ret;

    ret = Rte_Receive_BrakeFaultEvent((uint8*)&rxEvent, &rxLength);
    if (ret != E2E_E_OK) { return; }

    E2E_P22Check(
        &E2E_P22_Config_BrakeFault,  /* MaxDeltaCounterInit=255 for late join */
        &E2E_P22_CheckState_BrakeFault,
        (const uint8*)&rxEvent,
        rxLength
    );

    switch (E2E_P22_CheckState_BrakeFault.Status)
    {
        case E2E_P22STATUS_OK:
            SafetyMonitor_ProcessBrakeFault(&rxEvent);
            break;

        case E2E_P22STATUS_OKSOMELOST:
            /* Some events missed — still process but log gap */
            SafetyMonitor_ProcessBrakeFault(&rxEvent);
            Dem_ReportErrorStatus(SM_E2E_BrakeFault_SomeLost,
                                  DEM_EVENT_STATUS_FAILED);
            break;

        case E2E_P22STATUS_INITIAL:
            /* During INIT after subscription — events being validated */
            /* Do NOT process events in INIT — insufficient confidence */
            break;

        case E2E_P22STATUS_REPEATED:
            /* SOME/IP re-delivered the same event (reliable events) */
            /* Silently discard — not a fault */
            break;

        case E2E_P22STATUS_WRONGSEQUENCE:
            /* Too many events missed consecutively after VALID state */
            Dem_ReportErrorStatus(SM_E2E_BrakeFault_SeqErr,
                                  DEM_EVENT_STATUS_FAILED);
            SafetyMonitor_TriggerFaultMonitorDegradation();
            break;

        case E2E_P22STATUS_ERROR:
        default:
            /* CRC mismatch, Length error, or other integrity failure */
            Dem_ReportErrorStatus(SM_E2E_BrakeFault_Critical,
                                  DEM_EVENT_STATUS_FAILED);
            SafetyMonitor_TriggerFaultMonitorDegradation();
            break;
    }
}

14. State Machine – Differences from Profile 6

AUTOSAR E2E Profile 22 uses the same three-state machine (INIT / VALID / INVALID) as Profile 6. The parameter that makes the behavioral difference is MaxDeltaCounterInit.

State Machine Aspect	Profile 6 (Data Elements)	Profile 22 (Events)
MaxDeltaCounterInit	Typically 2–5 (stream was already running at subscription)	Typically 255 (event can arrive at any counter value)
INIT → VALID transition	After MinOkStateInit OK with standard delta check	After MinOkStateInit OK events with MaxDeltaCounterInit acceptance window
First event processing	Expected to be counter=0 or near-0 (first data update)	Can be any counter value (0–255) — late join expected
MaxDeltaCounter (VALID/INVALID)	Typically 2–3 (fixed publication rate)	Depends on event rate. For rare events: higher value appropriate
VALID → INVALID	After MaxErrorStateValid consecutive errors	Same — but NONEWDATA is more common (events may be rare)

Profile 22 State Machine Configuration Example

/* Profile 22 config — ADAS lane departure warning event, ~1 Hz when active */
static const E2E_P22ConfigType E2E_P22_Config_LaneDeparture = {
    .DataID              = 0x7E3CU,   /* Unique DataID for lane departure event */
    .Offset              = 0U,        /* E2E header at SOME/IP payload start */
    .MinDataLength       = 32U,       /* 4-byte header + 0 min × 8 bits */
    .MaxDataLength       = 1024U,     /* Max 128-byte event payload × 8 bits */
    .MaxDeltaCounterInit = 255U,      /* ★ PROFILE 22 KEY PARAM: accept any counter */
    .MaxDeltaCounter     = 15U,       /* VALID state: allow up to 15 missed events */
                                      /* (at 1Hz, 15 events = 15s — appropriate for */
                                      /*  event that fires only on lane departure)   */
    .MinOkStateInit      = 3U,
    .MaxErrorStateInit   = 3U,
    .MinOkStateValid     = 1U,
    .MaxErrorStateValid  = 3U,
    .MinOkStateInvalid   = 5U,
    .MaxErrorStateInvalid= 0U,
};

15. E2E_P22ConfigType – All Parameters Explained

typedef struct {

    uint16  DataID;           /* 16-bit unique identifier.
                                 NOT transmitted — implicit in CRC only.
                                 Must match between publisher and all subscribers.
                                 Should be unique across all SOME/IP event AND
                                 data element interfaces on the same network. */

    uint16  Offset;           /* Bit offset of E2E header within SOME/IP payload.
                                 Must be multiple of 8. Typically 0 or 64. */

    uint32  MinDataLength;    /* Minimum data length in BITS.
                                 Must be ≥ Offset + 32 bits (4-byte header min). */

    uint32  MaxDataLength;    /* Maximum data length in BITS.
                                 Maximum: 32768 bits (4096 bytes). */

    uint8   MaxDeltaCounterInit;
                             /* ★ KEY PROFILE 22 PARAMETER:
                                Max counter delta accepted in INIT state.
                                Set to 255 for typical SOME/IP events where
                                subscriber may join at any counter value.
                                Set lower (3–15) if subscription timing is
                                tightly controlled relative to provider start. */

    uint8   MaxDeltaCounter;  /* Max counter delta in VALID/INVALID states.
                                 For rare events (<<1Hz): 100–255
                                 For frequent events (10Hz+): 2–5
                                 Must account for maximum expected event gap
                                 during normal operation without signaling error. */

    uint8   MinOkStateInit;
    uint8   MaxErrorStateInit;
    uint8   MinOkStateValid;
    uint8   MaxErrorStateValid;
    uint8   MinOkStateInvalid;
    uint8   MaxErrorStateInvalid;

} E2E_P22ConfigType;

16. E2E_P22CheckStatusType – Status Codes and Meanings

Status Code	Hex	Meaning for SOME/IP Events	Action
E2E_P22STATUS_OK	0x00	CRC high byte correct, DataID valid via CRC, Length valid, counter delta = 1. Event integrity confirmed.	✅ Process event
E2E_P22STATUS_NONEWDATA	0x01	No new SOME/IP event received. Provider may not have fired an event yet – normal for condition-based events.	⚠️ Wait; timeout only if event is expected
E2E_P22STATUS_WRONGSEQUENCE	0x02	CRC OK but counter delta exceeded MaxDeltaCounter in VALID state — too many events missed consecutively.	⚠️ Log DTC; consider degradation
E2E_P22STATUS_ERROR	0x03	CRC high-byte mismatch, DataID wrong via CRC, Length mismatch, or truncation. Event data integrity compromised.	❌ Discard; DTC; safety reaction
E2E_P22STATUS_REPEATED	0x08	Counter delta = 0 – SOME/IP reliable event retransmission or gateway duplicate.	⚠️ Discard silently (normal for reliable events)
E2E_P22STATUS_OKSOMELOST	0x20	CRC OK, Length OK, but counter delta 2–MaxDeltaCounter – some events missed but within tolerance.	⚠️ Process event; log gap DTC
E2E_P22STATUS_INITIAL	0x40	State machine in INIT – subscriber just joined, accumulating MinOkStateInit valid events before VALID.	⚠️ Do not process – await VALID state

17. Practical Implementation Guide for SOME/IP Events

Step 1 – Distinguish Your Interface: Event or Data Element?

Before selecting AUTOSAR E2E Profile 22 or Profile 6, explicitly document whether your SOME/IP interface is an event (conditional, fired on state change or condition, subscriber may join mid-stream) or a data element (persistent, regularly updated, provider sends initial value at subscription time). If the SOME/IP interface carries persistent values that are always current and always sent when a subscriber subscribes, use Profile 6. If the interface fires notifications only when something happens and a late subscriber might miss previous events, use Profile 22.

Step 2 – Set MaxDeltaCounterInit to 255 for Most Event Interfaces

For the majority of SOME/IP safety event interfaces, set MaxDeltaCounterInit = 255. This ensures that when a subscriber joins an already-running event stream, the first received event is accepted at any counter value. The MinOkStateInit events after this first reception validate that the provider is genuinely publishing correct events before transitioning to VALID. Only reduce MaxDeltaCounterInit below 255 when you can guarantee that subscribers always start before or nearly simultaneously with the event publisher.

Step 3 – Choose MaxDeltaCounter Based on Event Rate and Application Tolerance

In VALID state, MaxDeltaCounter determines how many consecutive missed events are tolerated before WRONGSEQUENCE. For safety-critical events where missing even one event in a sequence is significant (e.g., a fault event that should immediately trigger a safety reaction), set MaxDeltaCounter = 1–3. For informational safety events where occasional misses are acceptable within a broader monitoring strategy, higher values (10–50) may be appropriate. For very rare events (fired once per vehicle cycle), very high values (100+) prevent false WRONGSEQUENCE after normal long event-free periods.

Step 4 – Initialize State at Service Subscription Time

/* Called when SOME/IP service subscription is established */
void BrakeFaultService_Subscribe(void)
{
    /* Provider side — initialize protect state */
    E2E_P22ProtectInit(&E2E_P22_ProtectState_BrakeFault);

    /* Subscriber side — initialize check state */
    E2E_P22CheckInit(&E2E_P22_CheckState_BrakeFault);
    /* Status = E2E_P22STATUS_INITIAL
       MaxDeltaCounterInit = 255 will accept first event at ANY counter */

    /* Safety monitor remains in degraded mode until MinOkStateInit=3
       consecutive OK events received from the brake ECU */
}

/* Called when SOME/IP service subscription is lost */
void BrakeFaultService_Unsubscribe(void)
{
    /* Re-initialize on next subscription to reset counter history */
    E2E_P22CheckInit(&E2E_P22_CheckState_BrakeFault);
}

18. AUTOSAR E2E Profile 22 vs Profile 6 – The Definitive Decision Guide

This is the single most important section for any SOME/IP safety architect: when to use AUTOSAR E2E Profile 22 versus Profile 6. The answer is straightforward once the communication semantic is clear – but many projects discover their interface is classified incorrectly only during integration testing when late subscriber scenarios cause unexpected WRONGSEQUENCE errors.

Decision Factor	→ Use Profile 6	→ Use Profile 22
Communication pattern	Data element: persistent value, regularly updated, always current. Initial value sent at subscription.	Event: conditional notification, fired on state/condition change. Subscriber may miss events.
Can subscriber join mid-stream?	No – subscriber joins at start, receives initial value immediately.	Yes – subscriber may subscribe after many events have already fired.
Publication frequency	Regular, fixed-rate or change-triggered with guaranteed initial publication.	Irregular, condition-based. May not fire for long periods.
NONEWDATA interpretation	Unusual – data should be regularly updated. Long NONEWDATA = fault.	Normal – event not fired when condition not met. NONEWDATA expected.
MaxDeltaCounterInit	Typically 2–5 (stream just started, subscriber joins early).	Typically 255 (subscriber may join at any point in counter sequence).
Examples	Steering torque values, vehicle speed, battery voltage, radar object list, ADAS sensor fusion output	Fault alerts, threshold crossings, door state changes, safety mode activations, diagnostic notifications

🎯 Simple Decision Rule: Ask “Can this SOME/IP interface fire zero events during normal operation for an extended period while a subscriber is already subscribed?” If yes, use AUTOSAR E2E Profile 22. If no (the interface always sends data at subscription and continues regularly), use Profile 6.

19. ISO 26262 ASIL D Analysis for SOME/IP Event Safety

The automotive functional safety ISO 26262 ASIL D SOME/IP event safety argument for AUTOSAR E2E Profile 22 must account for the same effective 8-bit CRC limitation as Profile 6 (CRC high byte only), but with additional consideration for the event-driven communication pattern’s unique failure modes.

Safety Coverage Matrix

Fault Type	Detection Mechanism	Coverage
Event data corruption	CRC-16 high byte (effective 8-bit)	~2⁻⁸ residual for random errors
Event payload truncation	Explicit Length field comparison (independent)	Near-zero (direct byte count comparison)
Event loss (missed notification)	Counter delta evaluation in VALID state	Configurable per MaxDeltaCounter
Event repetition/replay	Counter delta = 0 → REPEATED	Near-zero
Masquerade (wrong event type)	Implicit DataID in CRC	~2⁻⁸ residual
Late subscriber false errors	MaxDeltaCounterInit = 255 in INIT state	Prevents false WRONGSEQUENCE on join
Event timeout	NONEWDATA + application-level timeout	Application-dependent

ASIL D Consideration: Event-Specific Safety Analysis

For automotive functional safety ISO 26262 ASIL D SOME/IP event safety cases, two additional failure mode analyses are required beyond the standard E2E coverage arguments:

• Missing event failure mode: In a safety-critical event-driven system, the failure to receive an event that was sent (OKSOMELOST or WRONGSEQUENCE status) may be more critical than in a data-element system, because events carry transient state information that cannot be reconstructed from a later reception. The safety case must specify the maximum tolerated event miss rate for each ASIL D event interface and verify that the MaxDeltaCounter configuration enforces this limit.
• Late subscriber initialization safety gap: During the INIT phase after subscription (before MinOkStateInit OK events), the safety function should not use events – but the “window” during which this constraint applies must be bounded in the safety case. If MinOkStateInit = 3 at MaxDeltaCounterInit = 255, the subscriber enters VALID after 3 successfully validated events regardless of the counter history. The maximum time before VALID depends on the event publication rate, which must be analyzed per interface.

20. Real-World Use Cases for AUTOSAR E2E Profile 22

Brake System Fault Notification Service

A brake ECU detects an ASIL D fault condition (e.g., hydraulic pressure sensor fault, brake-by-wire actuator fault) and publishes a SOME/IP safety fault event to all subscribed safety monitors, HMI controllers, and OBD diagnostic services. The event fires immediately on fault detection, not at a fixed rate. A telematics ECU that boots late and subscribes 30 seconds after vehicle startup must be able to receive the next fault event (whenever it occurs) without false sequence errors. AUTOSAR E2E Profile 22 with MaxDeltaCounterInit=255 ensures this late-subscribing ECU can join the event stream cleanly and receive the next genuine fault event with full E2E protection verification.

ADAS Safety Mode Activation Event

An ADAS controller publishes a SOME/IP event notifying consumers when it transitions between safety operating modes (normal/degraded/failure). This event fires on state transitions, which may occur once per drive cycle or multiple times during complex scenarios. A domain controller that subscribes after the ADAS controller has already transitioned to degraded mode needs to receive the event notification correctly. E2E Profile 22 SOME/IP event Ethernet communication protection with MaxDeltaCounterInit=255 ensures the domain controller’s safety monitor accepts the first received mode-change event at whatever counter value the ADAS controller has reached, then monitors subsequent events with strict counter validation.

Battery Management System Threshold Event

An EV Battery Management System (BMS) publishes SOME/IP events when battery parameters cross safety thresholds: overtemperature, undervoltage, overcurrent, cell imbalance. Each threshold event is independent and may occur infrequently during normal operation or rapidly during fault conditions. The AUTOSAR E2E Profile 22 CRC-16 CCITT length DataID protection on each threshold event type ensures that the vehicle’s safety reaction system (SRS) only acts on integrity-verified event notifications, preventing false safety reactions from corrupted SOME/IP event packets. MaxDeltaCounter for rapid-fire fault events (temperature runaway) should be set high (20–50) to accommodate multiple threshold events in rapid succession.

Diagnostic Trouble Code (DTC) Storage Event

An OBD-II compliance service publishes SOME/IP events when new DTCs are stored or cleared. The diagnostic tester (either in-vehicle or external via DoIP) subscribes to these events at arbitrary times – including after many DTCs have been stored. AUTOSAR E2E Profile 22 with MaxDeltaCounterInit=255 allows any diagnostic subscriber to join the DTC event stream at any point without false sequence errors, while ensuring that each received DTC event is integrity-verified against corruption and masquerade from other SOME/IP event types.

21. Advantages of AUTOSAR E2E Profile 22

1. First-Class Late Subscriber Support: The MaxDeltaCounterInit=255 capability makes AUTOSAR E2E Profile 22 the only AUTOSAR E2E profile with native, specification-defined support for the late subscriber use case. This directly addresses a real and common SOME/IP deployment scenario that would otherwise require application-level workarounds to Profile 6.

2. Identical Wire Format to Profile 6 – No Extra Overhead: The E2E Profile 22 late subscriber 4-byte header is byte-for-byte identical to the Profile 6 header. Using Profile 22 instead of Profile 6 for event interfaces incurs zero additional overhead on the SOME/IP network.

3. Explicit Truncation Detection via Length Field: The 16-bit explicit Length field provides independent truncation detection for variable-length event payloads – critical for SOME/IP events whose payload size may vary depending on the event type or the number of included fields.

4. Shared CRC Library with Profiles 5 and 6: The Crc_CalculateCRC16() function is shared across Profiles 5, 6, and 22. ECUs using all three profiles need only one CRC-16 enablement in the CRC module configuration.

5. CP and AP Support: AUTOSAR E2E Profile 22 is supported on both Classic and Adaptive platforms, making it applicable to hybrid architectures where safety-critical SOME/IP events may originate from CP nodes and be consumed by AP nodes or vice versa.

6. Clear Design Intent – Improves System Documentation Quality: The existence of a dedicated Profile 22 distinct from Profile 6 forces system architects to explicitly classify each SOME/IP interface as either an event or a data element — a classification that has implications for initialization behavior, timeout monitoring, and safety analysis. This enforced clarity improves the overall quality of SOME/IP service interface documentation.

22. Limitations and Challenges

1. Same Effective 8-bit CRC Limitation as Profile 6: The CRC high-byte-only storage results in ~2⁻⁸ effective CRC protection for data corruption. For high-transmission-rate event streams where the absolute PMHF contribution of the CRC residual must be quantified, this limitation requires careful analysis in the ISO 26262 safety case.

2. MaxDeltaCounter Tuning for Irregular Events: Setting MaxDeltaCounter appropriately for SOME/IP events with highly variable publication rates is non-trivial. If set too low, normal periods of event silence followed by rapid bursts produce false WRONGSEQUENCE errors. If set too high, genuine communication faults (long counter jumps) go undetected. Per-interface analysis of the maximum legitimate event gap during normal operation is required.

3. INIT Phase Safety Gap: During the INIT phase (before MinOkStateInit OK events), the safety function must not use received events. For SOME/IP events that fire rarely, the time to reach VALID state after subscription could be significant – requiring the safety architecture to specify and bound the maximum allowed INIT duration before declaring a service fault.

4. DataID Implicit – Same Debugging Challenge as Profile 6: DataID mismatches between publisher and subscriber appear as persistent CRC errors, making them difficult to distinguish from genuine data corruption without explicit DataID verification testing. The same debugging approach (explicit test cases that verify CRC transitions from persistent ERROR to OK when DataID is corrected) applies as for Profile 6.

23. Testing and Fault Injection Strategy for AUTOSAR E2E Profile 22

Test ID	Fault Injected	Expected Status	Expected Action
TC-P22-001	Single bit flip in event payload byte 5	E2E_P22STATUS_ERROR (CRC high-byte mismatch)	Discard; DTC
TC-P22-002	Corrupt CRC high byte (Byte[Offset])	E2E_P22STATUS_ERROR	Discard; DTC
TC-P22-003	Truncate 10 bytes from 30-byte event payload	E2E_P22STATUS_ERROR (recvLength=20 ≠ header Length=30)	Discard; DTC
TC-P22-004	Late subscriber joins stream at counter=87	E2E_P22STATUS_INITIAL × MinOkStateInit, then OK (MaxDeltaCounterInit=255)	Hold safety reaction until VALID
TC-P22-005	Miss 1 event (delta=2, MaxDeltaCounter=5)	E2E_P22STATUS_OKSOMELOST	Process event; log DTC
TC-P22-006	Miss 10 events (delta=11 > MaxDeltaCounter=5)	E2E_P22STATUS_WRONGSEQUENCE	Log DTC; safety analysis
TC-P22-007	SOME/IP reliable event retransmission (counter=same)	E2E_P22STATUS_REPEATED	Discard silently
TC-P22-008	No event for 60 seconds (condition not met)	E2E_P22STATUS_NONEWDATA	Normal — no DTC unless timeout required
TC-P22-009	Wrong DataID on subscriber (misconfiguration)	E2E_P22STATUS_ERROR (CRC mismatch)	Persistent ERROR → INVALID
TC-P22-010	Publisher restarts — counter resets to 0	WRONGSEQUENCE → INVALID → recovery after CheckInit	Call CheckInit on detected restart
TC-P22-011	3 consecutive errors → INVALID → 5 OK → VALID	INVALID then VALID recovery	Safe default during INVALID
TC-P22-012	Counter wrap-around 0xFF → 0x00 (delta=1)	E2E_P22STATUS_OK	Process event normally
TC-P22-013	Late subscriber joins at counter=0xFF (wrap edge)	E2E_P22STATUS_INITIAL → OK after MinOkStateInit	MaxDeltaCounterInit=255 accepts this
TC-P22-014	Profile 6 sender, Profile 22 receiver (same DataID)	E2E_P22STATUS_OK (wire format identical — transparent)	Integration test: verify no cross-profile errors

⚠️ TC-P22-014 Important Note: Because Profile 6 and Profile 22 have an identical wire format, a Profile 22 check function will successfully verify a Profile 6-protected payload and vice versa (given the same DataID and Offset). This is expected behavior — the profiles are not differentiated at the wire level. The differentiation is purely in initialization logic.

24. Tools and Toolchain Support

Vector DaVinci Developer / Network Architect: Full AUTOSAR E2E Profile 22 configuration support with DataID, Offset, MaxDeltaCounterInit, MaxDeltaCounter, MinDataLength/MaxDataLength parameters. The key differentiator in toolchain configuration from Profile 6 is ensuring MaxDeltaCounterInit is set to 255 (not the small value typically defaulted for Profile 6). Vector CANoe with Ethernet/SOME/IP plugins can capture and display Profile 22-protected event payloads — the header decoding is identical to Profile 6 since the wire format is the same.

ETAS AUTOSAR AP / RTA-BSW: Both CP and AP toolchains support AUTOSAR E2E Profile 22 configuration. For AP manifest-based configuration, the MaxDeltaCounterInit parameter must be explicitly set for each event interface. A common mistake in AP deployment is reusing a Profile 6 configuration template for an event interface, resulting in a low MaxDeltaCounterInit value that causes false WRONGSEQUENCE errors when subscribers join late.

SOME/IP Protocol Analyzers: When analyzing SOME/IP event traffic with E2E Profile 22 protection, tools like Vector CANoe, ETAS INCA, and Wireshark with SOME/IP dissectors can decode the 4-byte E2E header. Because the wire format is identical to Profile 6, the tool simply needs the configured Offset to locate the header. Verifying that the counter in the first received event matches the MaxDeltaCounterInit=255 acceptance logic can be confirmed by injecting a mid-stream event (e.g., counter=100) immediately after a subscriber initialization and verifying that the check transitions to INITIAL rather than WRONGSEQUENCE.

25. Frequently Asked Questions About AUTOSAR E2E Profile 22

Q1: What is the exact difference between AUTOSAR E2E Profile 22 and Profile 6?

The wire format (4-byte header: CRC high byte, Counter, Length MSB, Length LSB) and all protection algorithms are identical between AUTOSAR E2E Profile 22 and Profile 6. The sole difference is the semantic intent and the initialization parameter: Profile 22 is designed for SOME/IP events where subscribers may join mid-stream, and MaxDeltaCounterInit is typically set to 255 to accommodate any counter value at late subscription. Profile 6 is designed for data elements where subscribers receive the initial value immediately after subscribing and the counter history starts from near-zero.

Q2: Can a SOME/IP event publisher using Profile 22 and a data element publisher using Profile 6 have the same DataID?

Technically there is no automatic enforcement preventing the same DataID from being used for both a Profile 22 event and a Profile 6 data element. However, it is strongly recommended to maintain globally unique DataIDs across all SOME/IP safety interfaces in the vehicle, regardless of profile type. If a Profile 22 event and a Profile 6 data element share the same DataID and their payload sizes are similar, a masquerade fault where a data element payload is delivered to an event subscriber would produce a passing CRC check — a safety concern. Unique DataIDs prevent this scenario entirely.

Q3: Should MaxDeltaCounterInit always be 255 for Profile 22?

MaxDeltaCounterInit = 255 is the appropriate choice for the general SOME/IP event late subscriber use case. However, if the subscription timing is tightly controlled – for example, in a cold-start sequence where all ECUs boot simultaneously and the event publisher starts before subscribers by a bounded time – a smaller MaxDeltaCounterInit (e.g., 10–20) provides stronger counter validation during initialization. The trade-off is that with a smaller MaxDeltaCounterInit, if a subscriber ever joins later than expected (due to a slow boot, reset, or service re-subscription), it will experience WRONGSEQUENCE errors during INIT. For safety-critical systems, 255 is the safe choice unless subscription timing can be guaranteed architecturally.

Q4: How long will a Profile 22 subscriber stay in INIT before transitioning to VALID?

The INIT-to-VALID transition requires MinOkStateInit consecutive events with passing CRC, Length, DataID, and counter delta checks (using MaxDeltaCounterInit). With MinOkStateInit=3 and a SOME/IP event that fires at 10Hz when conditions are met, the transition takes approximately 300ms from the first received event. For a rare event that fires only once per fault condition, the transition could take hours or days — because 3 distinct, correctly-validated events must be received. For safety-critical rare-event interfaces, consider whether the INIT phase duration is architecturally acceptable or whether a shorter MinOkStateInit (e.g., 1) combined with a larger MinOkStateInvalid for the recovery path provides a better balance.

Q5: Is there any scenario where Profile 6 should be used instead of Profile 22 for a SOME/IP event?

Yes. If a SOME/IP interface is technically classified as an event in the SOME/IP service definition (using SOME/IP event group and notification mechanism) but behaviorally acts as a data element – meaning the provider always sends the current value immediately when a subscriber subscribes (initial event pattern) and then continues to send regular updates – then Profile 6 with a standard MaxDeltaCounterInit of 2–5 may be more appropriate. The deciding factor is not the SOME/IP primitive type (event vs. field) but the behavioral question: can a subscriber join the event stream mid-sequence and expect to receive the next notification, or will the subscriber always receive an initial notification that resets the counter history?

Q6: What happens if a SOME/IP event publisher that uses Profile 22 reboots while a subscriber is active?

When the publisher reboots, its E2E protect state resets to Counter=0 (after E2E_P22ProtectInit()). The subscriber will receive an event with counter=0 after the publisher resumes, producing a large counter delta from the subscriber’s last received counter. If this delta exceeds MaxDeltaCounter, the subscriber transitions to INVALID. The subscriber should call E2E_P22CheckInit() when it detects the publisher restart (via SOME/IP Service Discovery OfferService message, SOME/IP stop offer followed by re-offer, or any other architecture-level reboot detection mechanism). After CheckInit, the subscriber re-enters INIT with MaxDeltaCounterInit=255, accepts the first post-reboot event regardless of counter, and transitions to VALID after MinOkStateInit consecutive OK events.

26. Conclusion

AUTOSAR E2E Profile 22 completes the SOME/IP safety communication protection picture that Profile 6 began. Where Profile 6 handles persistent data element values in continuous service streams, AUTOSAR E2E Profile 22 handles the event-driven notification pattern that is equally fundamental to SOME/IP service-oriented architectures: the conditional, irregular, potentially rare safety notifications that must be delivered with full integrity protection to all subscribers – even those that joined the event stream long after the first notification was published.

The single mechanism that defines AUTOSAR E2E Profile 22 – the MaxDeltaCounterInit=255 late subscriber initialization – is deceptively simple but architecturally profound. It acknowledges a fundamental reality of publish-subscribe systems: subscribers and publishers do not always start and stop together, and a safety-critical event notification must be usable by any subscriber regardless of when it joined the service. Without AUTOSAR E2E Profile 22, every SOME/IP safety event interface would require application-level workarounds to handle the late subscriber case correctly, with all the added complexity and potential for implementation errors that entails.

The identical wire format with Profile 6 is not a compromise but a deliberate design elegance – it means the AUTOSAR E2E Profile 22 CRC-16 CCITT length DataID protection is as strong as Profile 6 (effective 8-bit CRC plus Length-based truncation detection plus implicit DataID masquerade protection), while adding the event-specific initialization semantics that make it fit for purpose in the E2E Profile 22 SOME/IP event Ethernet communication environment. For all SOME/IP safety event interfaces in your automotive functional safety ISO 26262 ASIL D SOME/IP event architecture – fault alerts, threshold crossings, safety mode transitions, diagnostic notifications – AUTOSAR E2E Profile 22 is the correct, specification-endorsed protection choice.

🎉 AUTOSAR E2E Profile Series – Complete! All 8 Profiles Covered:

• ⬆️ Parent: AUTOSAR E2E Communication Protection: Complete Technical Guide
• ⬅️ Previous: AUTOSAR E2E Profile 11: Compact LIN Safety Communication Protection
• Profile 1: CRC-8-SAE J1850 for CAN
• Profile 2: CRC-8-H2F DataIDList for CAN/FlexRay
• Profile 4: CRC-32 for FlexRay and Ethernet
• Profile 5: CRC-16 for CAN FD and Ethernet
• Profile 6: SOME/IP Data Element Protection
• Profile 7: CRC-64 Large Data Ethernet (up to 4MB)
• Profile 11: Compact LIN Protection