Carlos Enrique Hernández Ibarra bio photo

Carlos Enrique Hernández Ibarra

Passionated Software Engineer with experience in the Automotive Industry. Interested in the state of the art of design, development, and test of technology based on C/C++, Autosar, and Matlab/Simulink. Nevertheless, always with an open mind to new technologies, industries and solutions.

Email LinkedIn Github

Autosar E2E

Introduction

E2E, an integral component of the Autosar stack, plays a crucial role in managing various mechanisms for safety-critical software components. Its primary purpose is to detect and mitigate issues, particularly focusing on systematic failures, low-level communication layers, and hardware failures. E2E safeguards against a range of failures, including:

  • Messages being lost during transmission or due to the unavailability of the communication channel.
  • Delayed message delivery.
  • Improper insertion of messages.
  • Unintended duplication of messages.
  • Corruption of messages.

E2E protection is essential for detecting these failures during runtime execution and triggering specific recovery mechanisms. The methods for safeguarding E2E integrity depend on the chosen E2E profiles, with the primary mechanisms being:

  • CRC (Cyclic Redundancy Check), which involves generating a numeric value based on the content of the message. This value is used to detect any corruption or alteration of messages during transmission.
  • Message counter. In the context of periodic message communication, this counter keeps track of the sequence of messages being transmitted. It helps detect any undesired duplication of messages, ensuring that each message is received only once and in the expected order.
  • On the reception side, another significant E2E protection mechanism is the use of a timer. This timer is employed to determine if a message has been lost and not communicated within a specific time frame. If the expected message does not arrive within the defined timeframe, it triggers actions to handle the situation, such as error reporting or retransmission requests.
  • An ‘Alive Counter’ is used. This counter increments with each transmission request, and its value is verified on the reception side to ensure correct increments.
  • A unique DataID being used to verify the identity of each transmitted safety-relevant data element.
  • A message type distinguishing between request and responses in case of E2E protection for functions.
  • A message result distinguising between of normal returns and errors in each case of E2E communication protection for methods.
  • Timeout comunication for the receiver.
  • Timeout for acknowledge of the sender.

Message counter

The counter is initialized in the first request of transmission of a data element with cero and it is incremented by 1 for each transmission request. The counter is checked by the receptor, when evaluating the counter of the received data versus the previously received data. More specifically the counter can detect.

  • If there is no new data when initializing the E2E supervisor function.
  • If no new data was received after the initialization of the receptor.
  • If the counter is incremented by one between messages, then it is correct.
  • If the counter is incremented by more than one but it is still on the defined boundaries.
  • If the counter is incremented by more than one but outside of the defined boundaries.

Timeout

  • Timeout is determined by the E2E library to evaluate the counter by a non-blocking read from the Sw component. Timeout is reported for the E2E library by the caller through E2E_PxxCheckStatusType and its use is to avoid jitter in the bus and it is not used to detect the delay of the messages caused by this jitter.

E2E Profiles

E2E profiles encompass a combination of protection mechanisms, message formats, and parameter configurations.

E2E Profile 2

E2E Profile 2 is designed to detect critical safety failure modes but lacks the capability to identify delayed messages. E2E Profile 2 is expected to incorporate the following mechanisms:

  • Counter. 4 bits communicated explicitly, increment for each request from the sender side. The counter is incremented in each call of the transmission request E2E_P02Protect().
  • DataID. 8 bits not being sent explicitly.
  • DataID + CRC. To detect incorrect addressing and mask.
  • Safety Code. 8 bits explictly send as CRC.
  • Timeout monitoring. Timeout is determined for the E2E supervision to evaluate the counter by a non-blocking read from the receiver.

Autosar E2E mechanism

In the Autosar specification, two primary components are dedicated to E2E (End-to-End) protection:

  • Protection Wrapper.
  • Transformer Solution.

These mechanisms are selected in a project based on the customer requirements or the profile to use.

Protection Wrapper

  • E2E Protection Wrapper (E2E PW) extends the standard interfaces of Sender/Receiver (Rte_Read and Rte_Write) by introducing Rte_E2EPW_Read and Rte_E2EPW_Write. To enable this functionality, the E2E and CRC libraries must be included as project references. E2E PW operates exclusively with conventional I-PDUs. When E2E is necessary for transmission, E2E PW incorporates a counter and CRC, sending the resulting data to RTE. The counter and CRC’s placement is contingent on the client’s profile and specification. For message reception requiring E2E, E2E PW receives the message, validates it through CRC and counter processing, and only passes valid data to the message, along with returning a status indicator.

Autosar E2E was published on and last modified on .