AUTOSAR E2E Profile 6 Explained: CRC-32 Protection for CAN FD and Automotive Ethernet

AUTOSAR E2E Profile 6 is the dedicated End-to-End safety communication protocol engineered specifically for SOME/IP (Scalable service-Oriented MiddlewarE over IP) – the primary serialization protocol used in AUTOSAR Ethernet-based service-oriented architectures. As modern vehicles increasingly adopt Automotive Ethernet as their primary high-bandwidth backbone, replacing or complementing traditional CAN and FlexRay networks, AUTOSAR E2E Profile 6 has become one of the most strategically important profiles in the entire E2E library for safety-critical SOME/IP data element communication.

What fundamentally distinguishes AUTOSAR E2E Profile 6 from its close relative Profile 5 is a single, critically important addition to the header: an explicit 16-bit Length field. This one extra byte transforms the AUTOSAR E2E Profile 6 4-byte header – containing a 16-bit CRC (CRC-16-CCITT, polynomial 0x1021), an 8-bit sequence counter, and the 16-bit Length – into a protocol capable of independently detecting message truncation. In SOME/IP Ethernet environments where variable-length payloads, service-oriented fragmentation, and TCP reassembly errors can silently deliver shorter messages than transmitted, the explicit Length field is not a luxury but a safety necessity for automotive functional safety ISO 26262 ASIL D SOME/IP deployments.

This comprehensive guide covers every technical dimension of AUTOSAR E2E Profile 6: the precise AUTOSAR E2E Profile 6 4-byte header layout with configurable Offset, the E2E Profile 6 CRC-16 CCITT length field DataID computation sequence, the SOME/IP integration architecture, protect and check algorithms with full C code, state machine configuration for ASIL D, real-world service-oriented use cases, and a thorough comparison with Profiles 5, 7, and 22.

🔗 Part of the AUTOSAR E2E Master Series on PiEmbSysTech.
Parent page: AUTOSAR E2E Communication Protection: Complete Technical Guide

What is AUTOSAR E2E Profile 6?
History and Background
SOME/IP Architecture Context
E2E Profile 6 in the AUTOSAR Stack
Complete Technical Specifications
The 4-Byte Header – Byte-Level Detail
Header Offset and SOME/IP Integration
CRC-16-CCITT in Profile 6
The Length Field – Why It Matters for SOME/IP
8-bit Sequence Counter
Data ID – Implicit Inclusion in CRC
E2E_P06Protect() – Complete Algorithm
E2E_P06Check() – Complete Algorithm
State Machine Configuration
E2E_P06ConfigType – All Parameters Explained
E2E_P06CheckStatusType – Status Codes
Practical Implementation Guide
SOME/IP Integration Deep-Dive
ISO 26262 Compliance and ASIL D Analysis
Real-World Use Cases
Profile 6 vs Profile 5, Profile 7, Profile 22
Advantages
Limitations and Challenges
Testing and Fault Injection Strategy
Tools and Configuration
Frequently Asked Questions
Conclusion

1. What is AUTOSAR E2E Profile 6?

AUTOSAR E2E Profile 6 is a standardized End-to-End safety communication protocol defined in the AUTOSAR E2E Protocol Specification (PRS_E2EProtocol) and SW-C E2E Library Specification (SWS_E2ELibrary). Introduced in AUTOSAR Release 4.2.1 (2014) alongside Profile 7, it was designed specifically for protecting safety-critical data elements in SOME/IP-based Automotive Ethernet service-oriented communication – a requirement that neither the CAN-focused Profiles 1 and 2 nor the general-purpose Profiles 4 and 5 addressed with the specific semantic richness that SOME/IP communication demands.

AUTOSAR E2E Profile 6 uses four mechanisms working in concert:

CRC-16-CCITT (polynomial 0x1021): 16-bit cyclic redundancy check for data corruption detection
8-bit Sequence Counter (0–255): Incremental counter for detecting lost, repeated, and out-of-sequence messages
16-bit Length field (explicit, transmitted): The actual data length in bytes, providing independent truncation detection
16-bit Data ID (implicit in CRC): A pre-shared identifier incorporated into the CRC computation but not transmitted in the header

The AUTOSAR E2E Profile 6 4-byte header – containing Counter (1 byte), Length (2 bytes Big Endian), and CRC-16 (1 byte… wait – the specific layout is: CRC-16 split as [Byte0=CRC-High], Counter [Byte1], Length-High [Byte2], Length-Low [Byte3] – described in detail in Section 6) – represents a precisely engineered balance between overhead and protection completeness, making it the standard choice for E2E Profile 6 SOME/IP Ethernet communication protection across modern zonal automotive architectures.

📌 Quick Reference – AUTOSAR E2E Profile 6 at a Glance

Profile Identifier	E2E_06 (AUTOSAR Standard Profile)
CRC Algorithm	CRC-16-CCITT, polynomial 0x1021, Start: 0xFFFF, XOR: 0x0000
Counter	8-bit (0–255), all values valid, wraps 255→0
Data ID	16-bit, implicit – NOT transmitted, included in CRC computation
Length Field	16-bit, explicitly transmitted in header (Big Endian). Carries actual data length in bytes including header.
Header Size	4 bytes (1B CRC + 1B Counter + 2B Length)
Header Byte Order	Big Endian for Length (Bytes 2–3); CRC at Byte 0 (1 byte); Counter at Byte 1
Header Offset	Configurable via `Offset` parameter (bits). Typical: 0 or 64 bits (after SOME/IP header)
Maximum Data Length	4096 bytes (32,768 bits)
Primary Use Case	SOME/IP data elements, Automotive Ethernet safety communication
Maximum ASIL	ASIL D (with safety analysis)
CRC Library Function	`Crc_CalculateCRC16()` from AUTOSAR CRC module
Platform Support	AUTOSAR Classic Platform (CP) and Adaptive Platform (AP)
Introduced In	AUTOSAR Release 4.2.1

2. History and Background of AUTOSAR E2E Profile 6

AUTOSAR E2E Profile 6 was introduced in AUTOSAR Release 4.2.1 (2014), a pivotal moment when the automotive industry was transitioning from a purely CAN/FlexRay architecture to Automotive Ethernet as the high-bandwidth network for ADAS, infotainment domain separation, and emerging service-oriented architectures. The SOME/IP protocol had been standardized by AUTOSAR (in the AUTOSAR SOME/IP Protocol Specification) as the serialization and communication protocol for Ethernet-based service interfaces, and safety teams quickly identified that existing E2E profiles were not optimally suited for SOME/IP’s variable-length, service-oriented communication model.

The key insight driving the specification of AUTOSAR E2E Profile 6 was that SOME/IP communication differs fundamentally from CAN or FlexRay in one critical way: payload lengths are inherently variable. A SOME/IP data element may carry different amounts of optional data depending on the application state, and UDP-based SOME/IP does not guarantee delivery of complete messages – partial delivery, retransmission, or gateway truncation can produce shorter payloads at the receiver. The 3-byte Profile 5 header has no mechanism to independently detect this condition; the CRC might or might not catch it depending on the specific data values in the missing bytes.

The solution was to add a 16-bit Length field to the E2E header – transforming the 3-byte Profile 5 header into the AUTOSAR E2E Profile 6 4-byte header. The one extra byte cost is justified by the guarantee: any message truncation that changes the received byte count from the transmitted byte count will be detected with certainty, independently of the CRC result. This makes AUTOSAR E2E Profile 6 a fundamentally more robust protocol than Profile 5 for all scenarios where variable-length data transmission is involved – exactly the SOME/IP Ethernet environment for which it was designed.

3. SOME/IP Architecture Context for AUTOSAR E2E Profile 6

Before diving into the technical details of AUTOSAR E2E Profile 6, understanding how SOME/IP works in the AUTOSAR architecture is essential. SOME/IP (Scalable service-Oriented MiddlewarE over IP) is the serialization and communication protocol used in AUTOSAR service-oriented architectures for Ethernet-based communication. It defines how service interfaces — collections of methods, events, and fields – are serialized into UDP or TCP payloads and routed between service providers (servers) and service consumers (clients) over Automotive Ethernet networks.

SOME/IP Message Structure

A SOME/IP message consists of a fixed 16-byte header (Service ID, Method/Event ID, Length, Client ID, Session ID, Interface Version, Message Type, Return Code) followed by a variable-length payload containing the serialized service data. For E2E Profile 6 SOME/IP Ethernet communication protection, the E2E header is typically placed at the beginning of the SOME/IP payload (Offset = 0 within the payload, which translates to bit Offset = 128 relative to the start of the full UDP datagram if counting from the Ethernet frame, but Offset = 0 relative to the SOME/IP payload itself).

SOME/IP MESSAGE STRUCTURE WITH E2E PROFILE 6 PROTECTION
═══════════════════════════════════════════════════════════

UDP Payload:
  ┌──────────────────────────────────────────────────────────────┐
  │              SOME/IP HEADER (16 bytes, fixed)                │
  │  [Service ID 2B][Method/Event ID 2B][Length 4B]              │
  │  [Client ID 2B][Session ID 2B][I.Version 1B]                 │
  │  [Msg Type 1B][Return Code 1B][Reserved 1B]                  │
  ├──────────────────────────────────────────────────────────────┤
  │              SOME/IP PAYLOAD (variable length)               │
  │                                                              │
  │  ┌────────────────────────────────────────────────────────┐  │
  │  │    E2E PROFILE 6 HEADER (4 bytes, at Offset=0)         │  │
  │  │    [CRC-16 High 1B][Counter 1B][Length High 1B]        │  │
  │  │    [Length Low 1B]                                      │  │
  │  ├────────────────────────────────────────────────────────┤  │
  │  │    SERVICE DATA (variable, safety-critical content)    │  │
  │  │    [Signal 1][Signal 2]...[Signal N]                   │  │
  │  └────────────────────────────────────────────────────────┘  │
  └──────────────────────────────────────────────────────────────┘

Note: E2E Profile 6 Offset is measured from the start of the SOME/IP
      PAYLOAD, not from the start of the SOME/IP message header.
      The AUTOSAR E2E Transformer or Protection Wrapper operates on
      the serialized payload after SOME/IP header generation.

Why Profile 6 Is the Right Fit for SOME/IP

SOME/IP communication is inherently variable-length because service interfaces may include optional parameters, arrays of variable size, or conditional fields that change from transmission to transmission. Unlike CAN FD where the DLC field enforces a fixed payload size, UDP-based SOME/IP can deliver any number of bytes to the application layer. This means truncation detection is a genuine safety concern – a SOME/IP subscriber receiving fewer bytes than the provider transmitted might process incomplete data without knowing it’s incomplete. The explicit Length field in AUTOSAR E2E Profile 6 directly addresses this by providing an independent, CRC-verified record of the intended payload size for every message.

4. AUTOSAR E2E Profile 6 in the AUTOSAR Stack

AUTOSAR E2E Profile 6 is positioned at the application layer, between the ASIL D Software Component and the QM-rated SOME/IP serialization and Ethernet communication stack. Its CRC computation is handled by the AUTOSAR CRC Library (Crc_CalculateCRC16()), the same function used by Profile 5 and Profile 22.

╔═══════════════════════════════════════════════════════════════════════╗
║                    APPLICATION LAYER (ASIL D)                         ║
║  ┌──────────────────────────┐     ┌──────────────────────────────┐    ║
║  │  Service Provider SW-C   │     │  Service Consumer SW-C        │    ║
║  │  (e.g. ADAS Sensor Fusion)│     │  (e.g. Safety Monitor)       │    ║
║  └────────────┬─────────────┘     └────────────┬─────────────────┘    ║
║               │ E2E_P06Protect()               │ E2E_P06Check()       ║
║               ▼                                ▲                      ║
║  ┌─────────────────────────────────────────────────────────────────┐  ║
║  │              E2E LIBRARY — Profile 6  (ASIL D)                  │  ║
║  │  CRC-16-CCITT (0x1021) + 8-bit Counter + 16-bit Length (tx)     │  ║
║  │  + 16-bit DataID (implicit in CRC) — 4-byte header              │  ║
║  └─────────────────────────────────────────────────────────────────┘  ║
╠═══════════════════════════════════════════════════════════════════════╣
║              RTE / ara::com (QM or ASIL D)                            ║
╠═══════════════════════════════════════════════════════════════════════╣
║              BASIC SOFTWARE — SOME/IP / Ethernet Stack (QM)           ║
║  SOME/IP Transformer ──► SOME/IP ──► UDP/TCP ──► Eth Driver           ║
╠═══════════════════════════════════════════════════════════════════════╣
║              Automotive Ethernet (100BASE-T1 / 1000BASE-T1)           ║
╚═══════════════════════════════════════════════════════════════════════╝

Key design properties:
  • Length field: transmitted IN header (unlike Profile 5's no-length approach)
  • DataID: NOT transmitted (implicit — included in CRC computation only)
  • CRC covers: header (Length+Counter zeroed CRC) + payload + DataID bytes
  • Independence from Ethernet HW CRC guaranteed (0x1021 ≠ IEEE 802.3 CRC-32)

5. AUTOSAR E2E Profile 6 – Complete Technical Specifications

Parameter	Value / Description
Profile Identifier	E2E_06
CRC Algorithm	CRC-16-CCITT, polynomial 0x1021 (x¹⁶+x¹²+x⁵+1)
CRC Start Value	0xFFFF
CRC XOR Output Value	0x0000
CRC Field Size	8 bits (only HIGH byte of CRC-16 – see Section 6 for important detail)
Counter Field	8-bit (0–255), at header Byte[Offset+1]. All values valid, wraps 255→0.
Length Field	16-bit Big Endian at header Bytes[Offset+2..Offset+3]. Contains actual total data length in bytes (including 4-byte header). Explicitly transmitted.
Data ID	16-bit. NOT transmitted in header. Incorporated implicitly in CRC computation (low byte then high byte, appended after signal data).
Header Total Size	4 bytes — [CRC(1B)][Counter(1B)][Length-High(1B)][Length-Low(1B)]
Header Byte Order	Big Endian for Length field (Bytes 2–3 of header). CRC is 1 byte (no endian issue). Counter is 1 byte.
Header Offset	Configurable via `Offset` (bits, multiple of 8). Commonly 0 (start of SOME/IP payload) or 64 (after 8-byte protocol sub-header).
CRC Computation Scope	From Byte[Offset] to end of data (with CRC byte zeroed) + DataID low byte + DataID high byte (appended)
Minimum Data Length	5 bytes (4-byte header + 1 byte signal data minimum)
Maximum Data Length	4096 bytes (32,768 bits)
Variable-Length Support	Yes — explicit Length field in header enables independent truncation detection for variable-length SOME/IP payloads
Primary Bus / Protocol	SOME/IP over Automotive Ethernet (UDP or TCP), service-oriented communication
Platform Support	AUTOSAR Classic Platform (CP) and Adaptive Platform (AP)
Maximum ASIL Rating	ASIL D
CRC Library Function	`Crc_CalculateCRC16()` – same as Profile 5 and Profile 22
Introduced In	AUTOSAR Release 4.2.1

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

The AUTOSAR E2E Profile 6 4-byte header has a specific and important layout that every implementer must understand precisely. A common misconception is that the CRC-16 occupies 2 bytes in the header – it does not. AUTOSAR E2E Profile 6 transmits only the high byte of the 16-bit CRC in the header at Byte[Offset]. The CRC is still computed as a full 16-bit value, but only its high byte (most significant byte) is stored and transmitted. This design decision keeps the header at 4 bytes while still providing meaningful CRC protection.

⚠️ Critical Implementation Note: In AUTOSAR E2E Profile 6, only the HIGH byte (bits 15-8) of the computed 16-bit CRC is stored in the header. The low byte is discarded. This is a frequently misunderstood aspect of Profile 6 that causes integration failures when engineers assume a full 2-byte CRC is in the header.

E2E PROFILE 6 — 4-BYTE HEADER STRUCTURE (Big Endian, Offset = 0)
═══════════════════════════════════════════════════════════════════

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

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

IMPORTANT DETAILS:
  Byte[Offset+0]: CRC HIGH BYTE ONLY (bits 15–8 of the 16-bit CRC result)
                  The LOW byte of the 16-bit CRC is NOT transmitted.
                  During computation, Byte[Offset+0] is set to 0x00.

  Byte[Offset+1]: Counter (8-bit, 0–255). Written before CRC computation.

  Bytes[Offset+2..3]: Length (16-bit Big Endian).
                      = total bytes in the data element including 4-byte header.
                      E.g., if signal data = 20 bytes, Length = 24 = 0x0018.

  DataID (16-bit): NOT in header. Appended to CRC computation:
                   CRC_final = CRC16(header+data) continued over [DataID_low, DataID_high]

CRC COMPUTATION SEQUENCE:
  1. Data[Offset+0] = 0x00 (CRC byte zeroed)
  2. Write Counter  → Data[Offset+1]
  3. Write Length   → Data[Offset+2..3] (Big Endian)
  4. CRC16 over Data[Offset..DataLength-1] (with CRC byte = 0x00)
  5. Continue CRC16 over DataID_low, then DataID_high
  6. Write result HIGH BYTE → Data[Offset+0]  (LOW BYTE DISCARDED)

EXAMPLE (Offset=0, DataID=0xABCD, Counter=15, 28-byte total):
  Data[0] = 0xXX    (CRC high byte — computed)
  Data[1] = 0x0F    (Counter = 15)
  Data[2] = 0x00    (Length MSB: 28 = 0x001C)
  Data[3] = 0x1C    (Length LSB)
  Data[4..27] = 24 bytes of SOME/IP service signal data

Why Only the High Byte of CRC-16?

The decision to store only the high byte of the 16-bit CRC in the AUTOSAR E2E Profile 6 4-byte header is a deliberate space optimization. The available 4 bytes are allocated as: 1 byte CRC, 1 byte Counter, 2 bytes Length. Storing the full 16-bit CRC would require 5 bytes total – increasing header overhead from 4 to 5 bytes. By storing only the CRC high byte, the header remains at 4 bytes while providing an effective 8-bit CRC for data corruption detection, supplemented by the 16-bit Length field for truncation detection and the 8-bit counter for sequence protection. This is a carefully balanced engineering trade-off specific to the SOME/IP Ethernet context where variable-length data and truncation detection are the primary safety concerns.

7. Header Offset and SOME/IP Integration in AUTOSAR E2E Profile 6

The configurable Offset parameter is one of the most important practical aspects of AUTOSAR E2E Profile 6 deployment in SOME/IP architectures. The Offset specifies where the AUTOSAR E2E Profile 6 4-byte header begins within the data element buffer, measured in bits from the start of the buffer.

Common Offset Configurations for SOME/IP

Offset	Header Position	Use Case
0 bits	Header at start of data element	E2E protection applied to the full SOME/IP payload from the first byte onward. Most common for dedicated safety service interfaces.
64 bits (8 bytes)	Header starts at Byte 8	When an 8-byte application-level sub-header (e.g., timestamp, sequence ID, protocol version) precedes the E2E-protected data domain.
32 bits (4 bytes)	Header starts at Byte 4	Compact application headers or when 4 bytes of routing/type information precede the E2E domain.
Custom (N×8 bits)	Header at byte N	Legacy SOME/IP service definitions where existing fields occupy the early payload bytes before the E2E safety domain.

Note that the Offset in AUTOSAR E2E Profile 6 is relative to the start of the data element buffer as seen by the E2E Library — not relative to the start of the Ethernet frame or the UDP datagram. The SOME/IP 16-byte message header is handled by the SOME/IP transformer layer before the E2E layer ever sees the data. The E2E Library receives and operates on the SOME/IP payload only, so Offset=0 means the E2E header starts at the very beginning of the SOME/IP payload content.

SOME/IP Offset Example (Offset = 64 bits)

/* SOME/IP payload structure with Profile 6, Offset = 64 bits (8 bytes) */

SOME/IP Payload (received by E2E Library):
  Byte[0..7]  = Service-level sub-header (not in E2E CRC scope)
  Byte[8]     = CRC-16 HIGH BYTE          ← E2E Profile 6 header start
  Byte[9]     = Counter
  Byte[10]    = Length HIGH BYTE
  Byte[11]    = Length LOW BYTE           ← E2E Profile 6 header end
  Byte[12..N] = Service signal data       ← E2E CRC covers Bytes 8..N + DataID

CRC computation covers: Bytes[8..N] + DataID_low + DataID_high
Bytes[0..7] are outside the E2E protection scope.

8. CRC-16-CCITT in AUTOSAR E2E Profile 6

AUTOSAR E2E Profile 6 uses the same CRC-16-CCITT polynomial (0x1021) as Profile 5 and Profile 22 – computed with start value 0xFFFF and XOR output value 0x0000. The key difference from Profile 5 is that only the high byte of the 16-bit result is stored in the header. This makes the effective CRC protection equivalent to an 8-bit CRC from a data corruption detection standpoint, but the Length field provides an additional, independent protection layer for truncation.

CRC-16 Result – Full vs. High-Byte Only

Profile 5: stores full 16-bit CRC result in header (2 bytes in header)
           Residual error rate: ~1/65,536

Profile 6: stores only HIGH 8 bits of 16-bit CRC result (1 byte in header)
           Effective CRC residual for data corruption: ~1/256 (similar to 8-bit CRC)
           BUT: Length field adds independent truncation detection
           Combined residual: much stronger than 8-bit CRC alone

Understanding this trade-off is critical for automotive functional safety ISO 26262 ASIL D SOME/IP safety analysis. When arguing the residual error rate for a Profile 6-protected SOME/IP data element, the safety case must account for the effective 8-bit CRC protection against corruption (not 16-bit), the 8-bit counter for sequence protection, and the 16-bit Length field for truncation detection. The combined protection from these independent mechanisms must be shown to meet the ASIL D residual error probability requirement for the specific SOME/IP network.

9. The Length Field – Why It Is Critical for SOME/IP Safety

The 16-bit Length field in the AUTOSAR E2E Profile 6 4-byte header is the defining feature that separates Profile 6 from Profile 5 and makes it specifically suited for E2E Profile 6 SOME/IP Ethernet communication protection. This field contains the total number of bytes in the data element, including the 4-byte E2E header itself.

Truncation Fault Scenarios in SOME/IP

In SOME/IP Ethernet environments, message truncation can occur in several realistic ways:

UDP fragmentation: UDP datagrams can be fragmented by IP routers. If the fragment assembly at the receiver times out or fails, only a partial payload is delivered to the application layer.
TCP stream errors: TCP byte streams can be corrupted at segment boundaries. A SW bug in the TCP de-serializer may deliver fewer bytes than received to the SOME/IP layer above.
SOME/IP gateway truncation: A protocol translation gateway (e.g., CAN to SOME/IP) may have buffer constraints that silently truncate payloads exceeding its buffer size.
Optional field omission: A service provider might incorrectly omit optional fields from a SOME/IP payload, delivering a shorter message than the consumer expects.
Memory allocation failures: A DMA or memory allocation error in the Ethernet driver may cause the receive buffer to be shorter than the received payload, truncating the data silently.

How Length Field Detection Works

/* Sender: always write actual total length into header */
uint16 totalLength = (uint16)(Config->MinDataLength / 8U);
/* For variable-length: totalLength = actual bytes in this transmission */
Data[Offset + 2] = (uint8)(totalLength >> 8U);   /* High byte */
Data[Offset + 3] = (uint8)(totalLength & 0xFFU); /* Low byte */

/* Receiver: validate length on every reception */
uint16 recvLength = ((uint16)Data[Offset+2] << 8) | Data[Offset+3];

/* Check 1: length within configured range */
if ((recvLength < Config->MinDataLength/8) || (recvLength > Config->MaxDataLength/8)) {
    State->Status = E2E_P06STATUS_ERROR;  /* Length out of range */
}

/* Check 2: length matches actual received bytes */
if (recvLength != actualReceivedBytes) {
    State->Status = E2E_P06STATUS_ERROR;  /* Truncation detected! */
}

The explicit Length field in AUTOSAR E2E Profile 6 provides a guarantee that Profile 5 cannot offer: even if the CRC-16 (high byte only) fails to detect a specific truncation pattern, the Length comparison will catch it definitively. These two detection mechanisms are independent – the Length field is NOT included in the CRC computation as a protected field in the same way as signal data (it IS covered by the CRC since it’s part of the buffer, but as an independent comparison it provides an additional check layer).

10. 8-bit Sequence Counter in AUTOSAR E2E Profile 6

The 8-bit counter in AUTOSAR E2E Profile 6 (values 0x00–0xFF, all valid) is located at Byte[Offset+1]. Its behavior is identical to the counters in Profiles 4 and 5: increments by 1 per transmission, wraps from 0xFF to 0x00, with no reserved invalid value. The counter enables detection of lost messages (delta > MaxDeltaCounter), repeated messages (delta = 0), and wrong sequence (delta exceeds configured limit).

For typical SOME/IP data element transmission rates of 10–100ms, the 8-bit counter provides strong sequence protection – wrapping only every 256 transmissions (2.56–25.6 seconds). For slow-rate service data updated at 1000ms, the counter wraps every 256 seconds (~4.3 minutes), providing excellent protection against replay attacks even at low update rates common in service-oriented architectures.

11. Data ID – Implicit CRC Inclusion in AUTOSAR E2E Profile 6

Like Profile 5, the 16-bit Data ID in AUTOSAR E2E Profile 6 is incorporated implicitly into the CRC computation and is never transmitted in the AUTOSAR E2E Profile 6 4-byte header. The Data ID provides protection against masquerade – a SOME/IP message from a different service provider being accepted as valid by the consumer’s E2E check.

The CRC computation for E2E Profile 6 CRC-16 CCITT length field DataID follows this exact sequence:

/* Profile 6 CRC computation sequence */

uint8  dataID_low  = (uint8)(Config->DataID & 0xFFU);
uint8  dataID_high = (uint8)((Config->DataID >> 8U) & 0xFFU);

/* Zero the CRC byte at Offset */
Data[Offset] = 0x00U;

/* Step 1: CRC16 over ALL data bytes from Offset to end (CRC byte = 0x00) */
uint16 crc = Crc_CalculateCRC16(
    &Data[Offset],                     /* Start from E2E header */
    (uint32)(Length - Offset/8),       /* All bytes including header+payload */
    0xFFFFU,                           /* Start value */
    TRUE                               /* First call */
);

/* Step 2: Extend CRC over DataID bytes (implicit inclusion) */
crc = Crc_CalculateCRC16(&dataID_low,  1U, crc, FALSE);
crc = Crc_CalculateCRC16(&dataID_high, 1U, crc, FALSE);

/* Step 3: Write only the HIGH BYTE of CRC into header */
Data[Offset] = (uint8)((crc >> 8U) & 0xFFU);   /* HIGH BYTE ONLY */
/* The low byte (crc & 0xFF) is DISCARDED in Profile 6 */

12. E2E_P06Protect() – Complete Algorithm

Function Signature

Std_ReturnType E2E_P06Protect(
    const E2E_P06ConfigType*   ConfigPtr,
    E2E_P06ProtectStateType*   StatePtr,
    uint8*                     DataPtr,
    uint16                     Length    /* Total data length in bytes */
);

Algorithm Steps

Input validation: NULL checks; Length within [MinDataLength/8, MaxDataLength/8] and ≥ (Offset/8 + 4)
Write Counter at Byte[Offset/8 + 1]:Data[offsetBytes + 1U] = State->Counter;
Write Length at Bytes[Offset/8+2..3] (Big Endian):Data[offsetBytes + 2U] = (uint8)(Length >> 8U); Data[offsetBytes + 3U] = (uint8)(Length & 0xFFU);
Zero CRC byte at Byte[Offset/8]:Data[offsetBytes] = 0x00U;
Compute CRC-16-CCITT and extend over DataID:uint16 crc = Crc_CalculateCRC16(&Data[offsetBytes], (uint32)(Length – offsetBytes), 0xFFFFU, TRUE); crc = Crc_CalculateCRC16(&dataID_low, 1U, crc, FALSE); crc = Crc_CalculateCRC16(&dataID_high, 1U, crc, FALSE);
Write ONLY HIGH BYTE of CRC result:Data[offsetBytes] = (uint8)((crc >> 8U) & 0xFFU); /* HIGH BYTE ONLY */
Increment Counter:State->Counter = (State->Counter == 0xFFU) ? 0x00U : (State->Counter + 1U);
Return E2E_E_OK

Complete E2E_P06Protect() C Implementation

/* AUTOSAR E2E Profile 6 Protect - Complete C Implementation */
Std_ReturnType E2E_P06Protect(
    const E2E_P06ConfigType  *Config,
    E2E_P06ProtectStateType  *State,
    uint8                    *Data,
    uint16                    Length)
{
    uint8  offsetBytes;
    uint16 crc;
    uint8  dataID_low, dataID_high;

    /* Validate inputs */
    if ((Config == NULL_PTR) || (State == NULL_PTR) || (Data == NULL_PTR)) {
        return E2E_E_INPUTERR_NULL;
    }

    offsetBytes = (uint8)(Config->Offset / 8U);

    if ((Length < (uint16)(Config->MinDataLength / 8U)) ||
        (Length > (uint16)(Config->MaxDataLength / 8U)) ||
        (Length < (uint16)(offsetBytes + 4U))) {
        return E2E_E_INPUTERR_WRONG;
    }

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

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

    /* Step 3: Zero CRC byte at Byte[Offset+0] */
    Data[offsetBytes] = 0x00U;

    /* Step 4: Prepare DataID bytes */
    dataID_low  = (uint8)(Config->DataID & 0xFFU);
    dataID_high = (uint8)((Config->DataID >> 8U) & 0xFFU);

    /* Step 5: CRC-16-CCITT over data from Offset to end, then DataID */
    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);

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

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

    return E2E_E_OK;
}

13. E2E_P06Check() – Complete Algorithm

Function Signature

Std_ReturnType E2E_P06Check(
    const E2E_P06ConfigType*  ConfigPtr,
    E2E_P06CheckStateType*    StatePtr,
    const uint8*              DataPtr,
    uint16                    Length    /* Actual received length in bytes */
);

E2E_P06Check() Algorithm Steps

Input validation
NewDataAvailable check – NONEWDATA if false
Read received Counter: recvCounter = Data[Offset/8 + 1]
Read and validate Length field:uint16 recvLength = ((uint16)Data[offsetBytes+2] << 8) | Data[offsetBytes+3]; /* Validation 1: recvLength must match actual received buffer size */ if (recvLength != Length) → ERROR (truncation detected) /* Validation 2: recvLength must be within configured range */ if (recvLength < MinDataLength/8 || recvLength > MaxDataLength/8) → ERROR
Read received CRC high byte: recvCRCHigh = Data[Offset/8]
Recompute CRC: Zero CRC byte, compute CRC16 over buffer + DataID, take high byte only
Compare CRC high bytes: Mismatch → ERROR
Evaluate Counter Delta (same logic as all other profiles)
Update State Machine
Return E2E_E_OK

Complete Receiver SW-C Handling – ADAS Safety Service Consumer

/* Receiver handling for a SOME/IP ADAS object list service data element */
void ADAS_ReceiveObjectList(void)
{
    ADASObjectListType rxData;
    uint16 rxLength;
    Std_ReturnType e2eRet;

    /* Read from RTE — SOME/IP payload with variable-length object list */
    Rte_Read_ADAS_ObjectList_Port((uint8*)&rxData, &rxLength);

    /* Run AUTOSAR E2E Profile 6 check */
    e2eRet = E2E_P06Check(
        &E2E_P06_Config_ObjectList,
        &E2E_P06_CheckState_ObjectList,
        (const uint8*)&rxData,
        rxLength
    );

    switch (E2E_P06_CheckState_ObjectList.Status)
    {
        case E2E_P06STATUS_OK:
            ADAS_ProcessObjectList(&rxData, rxLength);
            break;

        case E2E_P06STATUS_OKSOMELOST:
            /* Data valid, some SOME/IP packets lost — usable with caution */
            ADAS_ProcessObjectList(&rxData, rxLength);
            Dem_ReportErrorStatus(ADAS_E2E_SomeLostDEM, DEM_EVENT_STATUS_FAILED);
            break;

        case E2E_P06STATUS_INITIAL:
            ADAS_ApplySafeDefaultObjectList();
            break;

        case E2E_P06STATUS_REPEATED:
            /* SOME/IP retransmission or gateway replay */
            ADAS_ApplySafeDefaultObjectList();
            Dem_ReportErrorStatus(ADAS_E2E_RepeatedDEM, DEM_EVENT_STATUS_FAILED);
            break;

        case E2E_P06STATUS_WRONGSEQUENCE:
        case E2E_P06STATUS_ERROR:
        default:
            /* CRC high-byte mismatch, wrong DataID, truncation, or counter jump */
            ADAS_ApplySafeDefaultObjectList();
            Dem_ReportErrorStatus(ADAS_E2E_CriticalDEM, DEM_EVENT_STATUS_FAILED);
            ADAS_TriggerSafetyDegradation();
            break;
    }
}

14. State Machine Configuration for AUTOSAR E2E Profile 6

AUTOSAR E2E Profile 6 uses the standard AUTOSAR three-state machine (INIT / VALID / INVALID). For SOME/IP service-oriented communication, state machine thresholds need to account for the potentially variable update rates of service providers – a SOME/IP event may be published at irregular intervals depending on the service state, unlike the fixed-rate CAN signals for which many state machine parameter guidelines were originally developed.

State	Meaning	Safe for Application Use?	Key Transitions
INIT	Post-initialization. No reliable reception history. Service not yet subscribed or first data not yet received.	❌ No	→ VALID after MinOkStateInit OK receptions → INVALID after MaxErrorStateInit consecutive errors
VALID	SOME/IP service healthy. CRC, Length, counter all consistently passing.	✅ Yes	→ INVALID after MaxErrorStateValid consecutive errors
INVALID	SOME/IP service communication degraded. Safety function must use safe defaults.	❌ No	→ VALID after MinOkStateInvalid consecutive OK receptions

SOME/IP-Specific State Machine Considerations

In SOME/IP service-oriented communication, a service consumer may subscribe to a provider that publishes events at irregular rates based on system state (e.g., object detection events only when objects are present). The MaxDeltaCounter setting must accommodate this variability: if a service publishes at irregular intervals with counter gaps that legitimately exceed 1, MaxDeltaCounter should be set to the maximum expected legitimate counter gap rather than the strict value of 1 used for fixed-rate CAN signals.

/* Profile 6 state machine config for ADAS object list, variable-rate SOME/IP */
static const E2E_P06ConfigType E2E_P06_Config_ObjectList = {
    .DataID              = 0x4F2AU,  /* Unique OEM DataID for ADAS object list */
    .Offset              = 0U,       /* E2E header at start of SOME/IP payload */
    .MinDataLength       = 32U,      /* 4 bytes min (header only) × 8 — at least 4 bytes */
    .MaxDataLength       = 4096U,    /* Up to 512-byte object list × 8 bits */
    .MaxDeltaCounterInit = 3U,       /* INIT: allow up to counter+3 (variable rate) */
    .MaxDeltaCounter     = 3U,       /* VALID: up to 3 skipped publications tolerated */
    .MinOkStateInit      = 3U,       /* 3 consecutive OK to leave INIT */
    .MaxErrorStateInit   = 3U,       /* 3 errors in INIT → INVALID */
    .MinOkStateValid     = 1U,       /* 1 OK to stay VALID */
    .MaxErrorStateValid  = 3U,       /* 3 consecutive errors → INVALID */
    .MinOkStateInvalid   = 5U,       /* 5 OK to recover from INVALID */
    .MaxErrorStateInvalid= 0U,       /* Stay INVALID */
};

15. E2E_P06ConfigType – All Parameters Explained

typedef struct {

    uint16  DataID;           /* 16-bit unique identifier for this SOME/IP data element.
                                 NOT transmitted in header — implicit in CRC only.
                                 Unique per SOME/IP service interface data element.
                                 Must match exactly on sender and all receivers. */

    uint16  Offset;           /* Bit offset of E2E header start within data element.
                                 Must be multiple of 8 (byte-aligned).
                                 Relative to start of SOME/IP payload (not SOME/IP hdr).
                                 0: header at payload start
                                 64: header after first 8 bytes
                                 Range: 0 to (MinDataLength - 32) bits */

    uint32  MinDataLength;    /* Minimum allowed data length in BITS.
                                 Must be ≥ Offset + 32 bits (4-byte header min).
                                 For variable-length SOME/IP: minimum expected payload. */

    uint32  MaxDataLength;    /* Maximum allowed data length in BITS.
                                 Maximum: 32768 bits (4096 bytes).
                                 For fixed-length: MinDataLength == MaxDataLength. */

    uint8   MaxDeltaCounterInit;   /* Max counter delta in INIT state */
    uint8   MaxDeltaCounter;       /* Max counter delta in VALID/INVALID.
                                      For variable-rate SOME/IP events: 2–5.
                                      For fixed-rate: 1. */
    uint8   MinOkStateInit;
    uint8   MaxErrorStateInit;
    uint8   MinOkStateValid;
    uint8   MaxErrorStateValid;
    uint8   MinOkStateInvalid;
    uint8   MaxErrorStateInvalid;

} E2E_P06ConfigType;

16. E2E_P06CheckStatusType – Status Codes and Meanings

Status Code	Hex	Meaning	Application Action
`E2E_P06STATUS_OK`	0x00	CRC high-byte matched, DataID correct (via CRC), Length valid, counter delta = 1.	✅ Use data
`E2E_P06STATUS_NONEWDATA`	0x01	No new SOME/IP data available. Service may not have published yet or timeout occurred.	⚠️ Apply safe default if timeout exceeded
`E2E_P06STATUS_WRONGSEQUENCE`	0x02	CRC OK but counter delta exceeded MaxDeltaCounter (too many SOME/IP packets lost).	⚠️ Apply safe default; log DTC
`E2E_P06STATUS_ERROR`	0x03	CRC high-byte mismatch, wrong DataID, Length mismatch, or truncation detected.	❌ Discard; safe default; DTC; safety reaction
`E2E_P06STATUS_REPEATED`	0x08	CRC OK, Length OK, but counter delta = 0 (SOME/IP packet replayed or gateway duplicate).	⚠️ Discard as stale; DTC
`E2E_P06STATUS_OKSOMELOST`	0x20	CRC OK, Length OK, counter delta between 2 and MaxDeltaCounter.	⚠️ Use data; log SOME/IP packet-loss DTC
`E2E_P06STATUS_INITIAL`	0x40	State machine in INIT – service subscription just established or ECU reset.	⚠️ Do not use data yet

17. Practical Implementation Guide for AUTOSAR E2E Profile 6

Implementing AUTOSAR E2E Profile 6 correctly in a production SOME/IP project requires attention to several Profile 6-specific considerations beyond the standard E2E integration workflow.

Step 1 – Understand the CRC High-Byte-Only Design

Before writing a single line of code, ensure all team members working on the AUTOSAR E2E Profile 6 integration understand that only the high byte of the CRC-16 result is stored and transmitted. This is the single most common cause of integration failures specific to Profile 6. Verify this by examining the generated E2E Library code or the AUTOSAR Protocol Specification tables for Profile 6 explicitly.

Step 2 – Enable CRC-16 in the Crc Module

Enable CrcCrc16 in the AUTOSAR Crc module configuration. The Crc_CalculateCRC16() function is shared with Profiles 5 and 22 — one enablement serves all three. Without this, the linker will fail with an unresolved symbol for the E2E Library.

Step 3 – Configure MinDataLength and MaxDataLength for Variable-Length SOME/IP

For SOME/IP data elements with variable-length payloads, set MinDataLength to the minimum expected total payload size (header + minimum signal data) × 8 bits, and MaxDataLength to the maximum expected total size × 8 bits. The Length field in each transmitted message will carry the actual size for that specific transmission, and the receiver will validate it against both the configured range and the actual received buffer size.

Step 4 – Set the Correct Offset for Your SOME/IP Layout

Determine whether the AUTOSAR E2E Profile 6 4-byte header should be placed at the start of the SOME/IP payload (Offset = 0) or after any application-level sub-headers. The Offset value must match exactly between the SOME/IP service provider (sender) and all consumers (receivers). A single byte difference in the Offset configuration will cause persistent CRC failures.

Step 5 – DataID Assignment and Management

Assign a unique 16-bit DataID to each SOME/IP data element protected by AUTOSAR E2E Profile 6. Since the DataID is never transmitted, mismatches are not visible in SOME/IP traffic traces. Include DataID verification as an explicit integration test — verify E2E status transitions to OK (not persistent ERROR) at service bring-up.

Step 6 — State Initialization Before Service Subscription

/* Initialize E2E Profile 6 states when SOME/IP service is initialized */
void ADAS_ObjectListService_Init(void)
{
    /* Provider side */
    E2E_P06ProtectInit(&E2E_P06_ProtectState_ObjectList);

    /* Consumer side */
    E2E_P06CheckInit(&E2E_P06_CheckState_ObjectList);
    /* State = INIT — will transition to VALID after MinOkStateInit receptions */
}

18. SOME/IP Integration Deep-Dive for AUTOSAR E2E Profile 6

Integrating AUTOSAR E2E Profile 6 with SOME/IP service-oriented communication has several unique aspects compared to CAN or FlexRay E2E deployments. This section addresses the most important integration considerations specific to E2E Profile 6 SOME/IP Ethernet communication protection.

E2E Transformer vs. Manual Integration

For AUTOSAR Classic Platform R4.2.1 and later, the E2E Transformer (E2EXf) can be configured to automatically handle Profile 6 protection for SOME/IP-serialized data elements. The transformer intercepts the SOME/IP payload in the transformer chain, applies E2E protection transparently, and passes the protected payload to the SOME/IP communication stack. This approach eliminates the need for manual E2E Protection Wrapper code and ensures correct integration with the AUTOSAR transformer architecture.

For older releases or when using direct SOME/IP API calls, manual Protection Wrapper functions of the form E2EPW_Write_<ServiceInterface>_<DataElement>() and E2EPW_Read_<ServiceInterface>_<DataElement>() must be implemented, calling E2E_P06Protect() and E2E_P06Check() respectively.

Session ID and Counter Interaction

SOME/IP messages include a Session ID field in the SOME/IP header (a 16-bit value incremented per request). This is NOT the same as the E2E counter. The SOME/IP Session ID is managed by the SOME/IP protocol layer and serves a different purpose (request-response matching). The AUTOSAR E2E Profile 6 counter is an independent 8-bit value managed by the E2E Library, incremented per data element transmission regardless of the SOME/IP Session ID. Engineers must not confuse or conflate these two counters in their integration design.

Service Discovery and INIT State Handling

When a SOME/IP service consumer subscribes to a provider (via SOME/IP Service Discovery), the first few SOME/IP event notifications received may arrive while the E2E state machine is in INIT. The consumer application must NOT use data while in INIT state. A recommended pattern is to delay safety function activation until the E2E state machine has transitioned to VALID (after MinOkStateInit consecutive OK receptions), and to implement a subscription timeout that declares a service unavailable if VALID is not reached within a configured time after subscription.

Re-subscription After Provider Restart

If the SOME/IP service provider restarts (ECU reset, software reset), its E2E counter resets to 0. The consumer’s state machine will detect the counter discontinuity (large negative delta or wrap-around) and may transition to INVALID temporarily. The consumer must call E2E_P06CheckInit() to reset its state machine and restart the INIT sequence, or configure MaxDeltaCounter large enough to accommodate the counter jump when the provider restarts.

19. ISO 26262 Compliance and ASIL D Analysis for AUTOSAR E2E Profile 6

AUTOSAR E2E Profile 6 is designed to satisfy automotive functional safety ISO 26262 ASIL D SOME/IP communication requirements, with the understanding that its effective CRC protection is based on the high byte of the 16-bit CRC result only.

Safety Coverage Summary

Fault Type	Detection Mechanism	Coverage
Data corruption	CRC-16 high byte (effective 8-bit CRC protection)	~1/256 residual for random errors
Message truncation	Explicit Length field comparison (independent of CRC)	Near-zero (direct byte count comparison)
Message loss	Counter delta evaluation	Near-zero
Message repetition	Counter delta = 0 → REPEATED	Near-zero
Message delay/timeout	Counter freeze + NONEWDATA	Application-dependent
Masquerade	Implicit DataID in CRC (effective 8-bit coverage)	~1/256 residual
Wrong sequence	Counter delta > MaxDeltaCounter → WRONGSEQUENCE	Near-zero

Key Consideration: CRC High-Byte Means 8-bit Effective CRC

For automotive functional safety ISO 26262 ASIL D SOME/IP safety arguments, the safety analysis must use the effective 8-bit residual error rate (~1/256) for data corruption, not the full 16-bit CRC residual (~1/65,536). The high-byte-only storage reduces the CRC’s discrimination power from 65,536 possible values to 256 possible values. For ASIL D, this means the quantitative safety analysis must demonstrate that the system’s message transmission frequency × 1/256 × hardware fault rate falls below the ASIL D PMHF budget limit.

Importantly, the explicit Length field provides independent protection against one of the most critical SOME/IP fault modes (truncation) with near-zero residual – this complements the CRC-based coverage and strengthens the overall safety argument despite the reduced CRC effectiveness.

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

AUTOSAR E2E Profile 6 is deployed across safety-critical SOME/IP service interfaces in modern zonal and domain-based vehicle E/E architectures.

ADAS Object Detection Service – Perception Layer

An ADAS perception ECU running camera or radar object detection publishes fused object lists via a SOME/IP event service to the vehicle’s central domain controller. Each transmission contains a variable number of detected objects (0 to N) serialized as a SOME/IP payload. E2E Profile 6 SOME/IP Ethernet communication protection on this interface ensures that the domain controller’s path planning function only processes object data that has been verified for integrity (no corruption), completeness (no truncation via explicit Length check), and freshness (counter-based sequence verification). This is a textbook ASIL C–D safety interface where Profile 6 is the canonical choice.

Electronic Power Steering (EPS) – Service-Oriented Architecture

In next-generation vehicles using AUTOSAR Adaptive Platform for high-performance ECUs, the EPS controller may expose its torque sensor data as an ara::com service consumed by multiple higher-level controllers (driver assistance, autonomous driving, stability control). AUTOSAR E2E Profile 6 protects each SOME/IP event publication of the steering torque data element with CRC corruption detection, Length-based truncation detection, and counter-based sequence verification – satisfying the ASIL D requirement for EPS torque data integrity.

Vehicle-Level Safety Monitor – Status Aggregation

A central safety monitor ECU subscribes to SOME/IP safety status services from multiple domain controllers – chassis, powertrain, ADAS, body — and aggregates their health status for system-level functional safety supervision. Each status service uses AUTOSAR E2E Profile 6 to ensure the safety monitor receives genuine, uncorrupted status updates from each domain. The variable-length nature of aggregated status messages (different domains report different numbers of status fields) makes the explicit Length field particularly valuable.

Configuration Data Distribution – OTA and Boot-time

Safety-relevant configuration data (calibration parameters for adaptive cruise control, functional limits for by-wire systems, safety threshold tables) distributed via SOME/IP during boot-up or over-the-air update sequences benefits from AUTOSAR E2E Profile 6 protection. The Length field ensures that partially received configuration blocks – possible during network boot contention – are detected before the safety function uses incomplete calibration data.

21. AUTOSAR E2E Profile 6 vs Profile 5, Profile 7, Profile 22

Criterion	Profile 5	Profile 6	Profile 7	Profile 22
CRC Width	16-bit (full)	16-bit (high byte only = 8-bit effective)	64-bit	16-bit (full)
Header Size	3 bytes	4 bytes	12 bytes	4 bytes
Length Field	No	Yes (16-bit, explicit)	Yes (32-bit)	Yes (16-bit, explicit)
Counter Width	8-bit	8-bit	32-bit	8-bit
Data ID	Implicit in CRC	Implicit in CRC	Explicit (transmitted)	Implicit in CRC
Max Data Length	4096 bytes	4096 bytes	4 MB	4096 bytes
Variable-Length	Yes (no length check)	Yes (with explicit length check)	Yes	Yes (with explicit length check)
Primary Use	CAN FD, generic Ethernet	SOME/IP data elements	Large Ethernet data	SOME/IP events
CRC Residual Error	~1/65,536	~1/256 (high byte only)	~2⁻⁶⁴	~1/65,536
Truncation Detection	No (probabilistic)	Yes (guaranteed)	Yes	Yes

When to Choose Profile 6 vs Profile 22

Both AUTOSAR E2E Profile 6 and Profile 22 have the same 4-byte header structure (CRC high byte, Counter, Length 2 bytes) and use the same CRC algorithm. The key difference is their intended communication pattern:

Profile 6: Designed for data elements – persistent values in sender-receiver communication where the receiver reads the latest value. The counter increments on every data update and the receiver validates it as a continuous sequence.
Profile 22: Designed for events – notifications that are only valid at the moment of transmission. Special initialization logic handles the case where a subscriber joins an event stream mid-way through the counter sequence, without treating the first received messages as errors due to counter discontinuity.

For SOME/IP interfaces exchanging persistent data element values (sensor readings, vehicle state, configuration), use AUTOSAR E2E Profile 6. For SOME/IP event notifications (conditional alerts, threshold crossings, status changes), use Profile 22.

22. Advantages of AUTOSAR E2E Profile 6

1. Purpose-Built for SOME/IP: AUTOSAR E2E Profile 6 was specifically engineered for SOME/IP’s variable-length service-oriented communication model. Every design choice – the explicit Length field, the configurable Offset for placement after SOME/IP sub-headers, the 8-bit counter suitable for service publication rates – directly addresses the unique characteristics of Ethernet-based automotive service interfaces.

2. Explicit Length Field Guarantees Truncation Detection: The 16-bit Length field in the AUTOSAR E2E Profile 6 4-byte header provides independent, guaranteed detection of message truncation regardless of CRC outcome. This is the defining advantage over Profile 5 for SOME/IP deployments where variable-length payloads make truncation a credible and practically important fault mode.

3. Minimal Header Overhead for Variable-Length SOME/IP: At 4 bytes, the AUTOSAR E2E Profile 6 4-byte header adds minimal overhead to SOME/IP payloads that typically range from tens to hundreds of bytes. For a 100-byte SOME/IP payload, the 4-byte header is just 4% overhead – acceptable for all SOME/IP bandwidth budgets.

4. CP and AP Platform Support: AUTOSAR E2E Profile 6 is supported on both Classic Platform and Adaptive Platform, making it the appropriate choice for safety-critical SOME/IP interfaces in hybrid CP+AP architectures and pure AP systems using ara::com.

5. Same CRC Library Function as Profile 5 and 22: The shared use of Crc_CalculateCRC16() across Profiles 5, 6, and 22 means a single CRC enablement in the Crc module configuration serves all three profiles simultaneously, reducing configuration complexity for ECUs using multiple SOME/IP E2E profiles.

6. Aligned with AUTOSAR SOME/IP Service-Oriented Safety Architecture: AUTOSAR E2E Profile 6 is the profile cited in AUTOSAR’s own SOME/IP communication safety guidelines for data element protection. Using it ensures alignment with the AUTOSAR-recommended safety architecture for Ethernet-based vehicle networks.

23. Limitations and Challenges of AUTOSAR E2E Profile 6

1. Reduced CRC Protection (High Byte Only): The most significant technical limitation of AUTOSAR E2E Profile 6 is that storing only the high byte of the CRC-16 result reduces the effective CRC discrimination from 1/65,536 to 1/256. For ASIL D safety cases, this means the quantitative residual error rate argument is weaker than for Profile 5 or Profile 22. Projects with very stringent ASIL D CRC requirements may need to use Profile 7 instead, accepting the larger 12-byte header overhead.

2. SOME/IP Session ID / E2E Counter Confusion: Developers new to SOME/IP often confuse the SOME/IP Session ID (in the SOME/IP header, managed by the SOME/IP protocol layer) with the E2E counter (in the AUTOSAR E2E Profile 6 4-byte header, managed by the E2E Library). These are completely independent mechanisms. Incorrect handling of this distinction can lead to false E2E counter errors or failure to detect genuine sequence violations.

3. Variable-Rate SOME/IP Events Require Careful MaxDeltaCounter Tuning: Unlike fixed-rate CAN signals where MaxDeltaCounter = 1 is correct for most deployments, SOME/IP services may publish data at irregular intervals (event-driven, state-dependent). Setting MaxDeltaCounter too low causes false WRONGSEQUENCE errors; setting it too high reduces sequence protection strength. Each SOME/IP data element may require individual MaxDeltaCounter analysis based on its publication pattern.

4. DataID Implicit – Integration Debugging Harder: Like Profile 5, the implicit DataID in AUTOSAR E2E Profile 6 is invisible in SOME/IP traffic traces. DataID configuration mismatches appear as persistent CRC errors indistinguishable from data corruption. Robust integration testing with explicit DataID verification scenarios is mandatory.

24. Testing and Fault Injection Strategy for AUTOSAR E2E Profile 6

Test ID	Fault Injected	Expected Status	Expected Reaction
TC-P6-001	Single bit flip in signal data	E2E_P06STATUS_ERROR (CRC high-byte mismatch)	Safe default; DTC
TC-P6-002	Flip CRC byte in header	E2E_P06STATUS_ERROR	Safe default
TC-P6-003	Truncate last 10 bytes of 100-byte SOME/IP payload	E2E_P06STATUS_ERROR (recvLength=90 ≠ header Length=100)	Safe default; DTC
TC-P6-004	Tamper Length field (+5 bytes, CRC not updated)	E2E_P06STATUS_ERROR (CRC mismatch due to tampered Length)	Safe default
TC-P6-005	Drop 1 SOME/IP packet	E2E_P06STATUS_OKSOMELOST (delta=2)	Use data; log DTC
TC-P6-006	Drop 4 consecutive SOME/IP packets (delta=5 > MaxDelta=3)	E2E_P06STATUS_WRONGSEQUENCE	Safe default; DTC
TC-P6-007	Replay same SOME/IP event twice	E2E_P06STATUS_REPEATED	Discard; DTC
TC-P6-008	Service provider stops (SOME/IP subscription timeout)	E2E_P06STATUS_NONEWDATA	Safe default; timeout DTC
TC-P6-009	Wrong DataID on receiver (misconfiguration)	E2E_P06STATUS_ERROR (CRC high-byte mismatch)	Persistent ERROR → INVALID
TC-P6-010	Service provider restart (counter reset to 0)	E2E_P06STATUS_WRONGSEQUENCE then recovery	INVALID → VALID after MinOkStateInvalid OK
TC-P6-011	Offset misconfigured (+4 bytes on receiver)	E2E_P06STATUS_ERROR (reads wrong bytes as header)	Persistent ERROR → INVALID
TC-P6-012	Variable-length payload sent with correct Length field	E2E_P06STATUS_OK (if CRC and counter correct)	Use data (variable length correctly handled)
TC-P6-013	3+ errors → INVALID → 5 OK → VALID recovery	INVALID → VALID after MinOkStateInvalid=5 OK	Safe default during INVALID; normal after VALID
TC-P6-014	SOME/IP service consumer subscribes mid-stream (INIT state)	E2E_P06STATUS_INITIAL then → VALID	Safe default until MinOkStateInit OK received

25. Tools and Configuration for AUTOSAR E2E Profile 6

Vector DaVinci Developer / Network Architect: Full AUTOSAR E2E Profile 6 support with SOME/IP service interface configuration, DataID assignment, Offset setting, MinDataLength/MaxDataLength for variable-length payloads, and E2E Transformer configuration for automatic SOME/IP payload protection. CANoe with Ethernet analysis and AUTOSAR E2E decoding plugin can display the 4-byte Profile 6 header in captured SOME/IP traffic – showing CRC high byte, counter, and Length fields.

ETAS RTA-CAR / EB tresos: Configuration toolchains with AUTOSAR E2E Profile 6 support for the E2E module and E2E Transformer. The Crc module must have CrcCrc16 enabled. ETAS RTE documentation covers SOME/IP transformer integration with E2E Profile 6 for variable-length data element protection.

Vector CANoe with SOME/IP Plugin: Decodes SOME/IP traffic including E2E Profile 6 headers in the payload. Displays Counter, Length, and CRC bytes at the configured Offset. Supports fault injection by modifying specific bytes in the SOME/IP payload — useful for executing TC-P6-001 through TC-P6-014 test cases in a hardware-in-the-loop environment.

Wireshark with SOME/IP Dissector: The Wireshark SOME/IP dissector (available from AUTOSAR tooling partners) can parse SOME/IP messages and display the E2E Profile 6 header fields at the configured Offset. Useful for developer workstation debugging when working with Automotive Ethernet PCap captures.

AUTOSAR Adaptive Platform (ara::com) Tools: For AP deployments using AUTOSAR E2E Profile 6 in ara::com service-oriented communication, tools from ETAS AUTOSAR AP, Vector Adaptive MICROSAR, and EB corbos AP provide SOME/IP binding configuration with E2E Profile 6 support. The E2E configuration for AP follows the same DataID, Offset, MinDataLength/MaxDataLength parameters as CP, but is expressed in the AP manifest format.

26. Frequently Asked Questions About AUTOSAR E2E Profile 6

Q1: Why does AUTOSAR E2E Profile 6 only store the high byte of the CRC-16 result?

The AUTOSAR E2E Profile 6 4-byte header is constrained to exactly 4 bytes: 1 byte CRC, 1 byte Counter, 2 bytes Length. Storing the full 16-bit CRC would require 2 bytes for CRC alone, pushing the header to 5 bytes. The specification authors made the design trade-off of storing only the CRC high byte to maintain the 4-byte header while still providing corruption detection, on the basis that the explicit Length field independently handles the most critical SOME/IP fault mode (truncation). The effective 8-bit CRC protection (~1/256 residual) was deemed acceptable given the Length field’s independent contribution to the overall fault coverage.

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

Both AUTOSAR E2E Profile 6 and Profile 22 have identical header structures (4 bytes: CRC high byte, Counter, Length 2B) and use the same CRC-16-CCITT algorithm. The difference is in their intended communication semantics. Profile 6 is designed for persistent data elements where the receiver reads the latest value in a continuous data stream — the counter is expected to increment steadily. Profile 22 is designed for events where a subscriber may join mid-stream and must handle the first received messages (with unknown counter history) without treating them as sequence errors. Profile 22’s initialization logic accommodates late subscription, while Profile 6 uses the standard initialization that expects counter history from the first valid reception.

Q3: How does E2E Profile 6 handle variable-length SOME/IP payloads?

AUTOSAR E2E Profile 6 handles variable-length payloads through the explicit Length field in the header. For each transmission, the sender writes the actual total byte count (including the 4-byte E2E header) into the Length field. The receiver validates this value against the configured MinDataLength/MaxDataLength range AND compares it to the actual number of bytes received. If the received byte count does not match the Length field value, an ERROR is reported immediately – providing guaranteed truncation detection. The CRC computation also covers the actual transmitted bytes, ensuring that different-length messages produce different CRC values when the content differs.

Q4: Should I use AUTOSAR E2E Profile 6 or Profile 5 for my SOME/IP Ethernet interface?

For SOME/IP Ethernet interfaces, AUTOSAR E2E Profile 6 is the recommended choice over Profile 5 for three reasons: (1) explicit Length field provides guaranteed truncation detection – critical for variable-length SOME/IP payloads; (2) it is specifically designed for SOME/IP data element communication patterns and is cited in AUTOSAR SOME/IP safety guidelines; (3) the 1-byte additional overhead (4 bytes vs Profile 5’s 3 bytes) is negligible for typical SOME/IP payload sizes. Only choose Profile 5 over Profile 6 when SOME/IP compliance is not required (e.g., plain UDP Ethernet payloads without SOME/IP semantics) and minimum header overhead is the priority.

Q5: Can AUTOSAR E2E Profile 6 be used with both UDP and TCP based SOME/IP?

Yes. AUTOSAR E2E Profile 6 operates at the SOME/IP payload level, independent of the underlying transport protocol (UDP or TCP). Whether SOME/IP runs over UDP (for unreliable event notifications) or TCP (for reliable client-server communication), the E2E protection is applied to the same SOME/IP payload content. The explicit Length field is particularly valuable for UDP-based SOME/IP where delivery is not guaranteed and partial delivery is a realistic fault mode. For TCP-based SOME/IP, TCP’s reliable delivery makes truncation less likely at the network level, but application-level truncation bugs (buffer allocation errors, serialization bugs) are still possible and caught by the Length field.

Q6: What happens when a SOME/IP service provider restarts and its E2E counter resets to 0?

When a service provider restarts, its E2E counter resets to 0 (from E2E_P06ProtectInit()). The consumer’s state machine will see a large counter delta (from the last received value to 0) that exceeds MaxDeltaCounter, triggering E2E_P06STATUS_WRONGSEQUENCE and ultimately transitioning to INVALID. To handle this gracefully, the consumer should call E2E_P06CheckInit() when it receives notification (via SOME/IP Service Discovery) that the service has restarted — resetting its state machine to INIT and allowing normal re-initialization from the provider’s new counter sequence starting at 0.

27. Conclusion

AUTOSAR E2E Profile 6 is the purpose-built safety communication protocol for SOME/IP-based Automotive Ethernet service-oriented architectures. Its AUTOSAR E2E Profile 6 4-byte header – containing the CRC-16 high byte, an 8-bit counter, and the critically important explicit 16-bit Length field – provides a precisely balanced protection scheme that addresses the unique fault landscape of SOME/IP communication: variable-length payloads susceptible to truncation, UDP transport with no delivery guarantee, service-oriented event patterns with variable publication rates, and the stringent requirements of automotive functional safety ISO 26262 ASIL D SOME/IP safety cases.

Understanding the key design trade-offs of AUTOSAR E2E Profile 6 – the CRC high-byte-only storage that results in effective 8-bit CRC coverage, the implicit DataID that provides masquerade protection without header overhead, and the explicit Length field that provides guaranteed truncation detection independent of CRC – is essential for writing defensible E2E Profile 6 SOME/IP Ethernet communication protection safety arguments for ASIL D systems.

As automotive architectures continue evolving toward software-defined vehicles with Ethernet-dominant communication fabrics and AUTOSAR Adaptive Platform service meshes, mastery of AUTOSAR E2E Profile 6 will only become more critical for automotive embedded systems engineers and functional safety specialists worldwide.

📚 AUTOSAR E2E Profile Series – Continue Learning:

⬆️ Parent: AUTOSAR E2E Communication Protection: Complete Technical Guide
⬅️ Previous: AUTOSAR E2E Profile 5: CRC-16 for CAN FD and Ethernet
➡️ Next: AUTOSAR E2E Profile 7: 64-bit CRC for Large Ethernet Data (up to 4MB)
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 11: Compact Protection for LIN
Profile 22: SOME/IP Event Protection

Discover more from PiEmbSysTech - Embedded Systems & VLSI Lab

Subscribe to get the latest posts sent to your email.

AUTOSAR E2E Profile 6 Explained: CRC-32 Protection for CAN FD and Automotive Ethernet

Table of Contents

1. What is AUTOSAR E2E Profile 6?

2. History and Background of AUTOSAR E2E Profile 6

3. SOME/IP Architecture Context for AUTOSAR E2E Profile 6

SOME/IP Message Structure

Why Profile 6 Is the Right Fit for SOME/IP

4. AUTOSAR E2E Profile 6 in the AUTOSAR Stack

5. AUTOSAR E2E Profile 6 – Complete Technical Specifications

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

Why Only the High Byte of CRC-16?

7. Header Offset and SOME/IP Integration in AUTOSAR E2E Profile 6

Common Offset Configurations for SOME/IP

SOME/IP Offset Example (Offset = 64 bits)

8. CRC-16-CCITT in AUTOSAR E2E Profile 6

CRC-16 Result – Full vs. High-Byte Only

9. The Length Field – Why It Is Critical for SOME/IP Safety

Truncation Fault Scenarios in SOME/IP

How Length Field Detection Works

10. 8-bit Sequence Counter in AUTOSAR E2E Profile 6

11. Data ID – Implicit CRC Inclusion in AUTOSAR E2E Profile 6

12. E2E_P06Protect() – Complete Algorithm

Function Signature

Algorithm Steps

Complete E2E_P06Protect() C Implementation

13. E2E_P06Check() – Complete Algorithm

Function Signature

E2E_P06Check() Algorithm Steps

Complete Receiver SW-C Handling – ADAS Safety Service Consumer

14. State Machine Configuration for AUTOSAR E2E Profile 6

SOME/IP-Specific State Machine Considerations

15. E2E_P06ConfigType – All Parameters Explained

16. E2E_P06CheckStatusType – Status Codes and Meanings

17. Practical Implementation Guide for AUTOSAR E2E Profile 6

Step 1 – Understand the CRC High-Byte-Only Design

Step 2 – Enable CRC-16 in the Crc Module

Step 3 – Configure MinDataLength and MaxDataLength for Variable-Length SOME/IP

Step 4 – Set the Correct Offset for Your SOME/IP Layout

Step 5 – DataID Assignment and Management

Step 6 — State Initialization Before Service Subscription

18. SOME/IP Integration Deep-Dive for AUTOSAR E2E Profile 6

E2E Transformer vs. Manual Integration

Session ID and Counter Interaction

Service Discovery and INIT State Handling

Re-subscription After Provider Restart

19. ISO 26262 Compliance and ASIL D Analysis for AUTOSAR E2E Profile 6

Safety Coverage Summary

Key Consideration: CRC High-Byte Means 8-bit Effective CRC

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

ADAS Object Detection Service – Perception Layer

Electronic Power Steering (EPS) – Service-Oriented Architecture

Vehicle-Level Safety Monitor – Status Aggregation

Configuration Data Distribution – OTA and Boot-time

21. AUTOSAR E2E Profile 6 vs Profile 5, Profile 7, Profile 22

When to Choose Profile 6 vs Profile 22

22. Advantages of AUTOSAR E2E Profile 6

23. Limitations and Challenges of AUTOSAR E2E Profile 6

24. Testing and Fault Injection Strategy for AUTOSAR E2E Profile 6

25. Tools and Configuration for AUTOSAR E2E Profile 6

26. Frequently Asked Questions About AUTOSAR E2E Profile 6

27. Conclusion

Related

Discover more from PiEmbSysTech - Embedded Systems & VLSI Lab

Equivalent Technical Articles

Leave a ReplyCancel reply

fdhfghfgh

Discover more from PiEmbSysTech - Embedded Systems & VLSI Lab