E2E Protection Overview

Valid data exchange between ECU's is essential to avoid the gnarly effects of communication faults. Learn here about E2E protection

In a noisy environment such as an automotive vehicle, there are a lot of components in play, which cause the communication bus's present within the vehicle to be the possible subject of communication faults, not to mention tampering attempts, which are a rising trend in the world, and automotive is no exception. Thus, ensuring the bits received on the other end of the communication bus are valid is a priority.

For this purpose, Autosar incorporates the concept of E2E (End to End) protection, which contains mechanisms to validate the corrrectness of communication between ECU's. First, let's see what are the most common communication issues and then, we'll look briefly at what E2E adds to the Autosar layered architecture in order to validate the data exchanges. This article will be divided into two parts, where in this first part you get all the theory and in the next one we'll dig deeper into the E2E protection modules in Autosar. One thing to keep in mind, is that the E2E protection can also be used in intra-ECU communication.

There are 3 different types of faults that exists on automotive ECU's:

• Software Faults - Although the Autosar modules from your stack provider and your own modules are tested to a full extent (if not, what are you doing?), a systematic fault can occur. Systematic faults are called this way because they are predictable, they always occur for the same reason, same root cause. Its consequences can have a direct impact in communication, such as interrupting of data transmission and buffer over/underflows. To prevent and handle those failures, methods such as program flow monitoring (which we covered a little bit in our article Watchdog Stack Overview (opens in a new tab)) and E2E supervision.

• Random Hardware Faults - In an automotive environment, it's typical for the components to degrade overtime, causing them to operate in a slightly different way and lead to a random hardware problem. A hardware issue cannot be completely avoided, but it can be detected and the necessary measures can be implemented to deal with the issue at hand, through diagnostics (you can kistart your journey on diagnostics with our articles DEM Overview (opens in a new tab) and UDS Frames and NRC Codes (opens in a new tab)).

• External Infuences - Transient faults can occur due to the external environment a vehicle is subjected to, such as EMI, ESD, humidity, corrosion, temperature and mechanical vibrations.

Now that we know the types of problems our ECU's are subjected to, let's learn about how they propagate into communication faults:

• Repetition of Information - Your information is received more than once.

• Loss of Information - Parts of your communication frame are missing.

• Delay of Information - Your data frames are received later than expected.

• Insertion of Information - Your frame contains more data than what is expected.

• Masquerading - Non-authentic, possibly tampered information is received as valid.

• Incorrect Addressing - Information is accepted from the wrong sender or receiver.

• Incorrect Information Sequence - The information stream sequence is different than expected.

• Data Corruption - Information is corrupted.

• Asymmetric Information - Happens when in 1:N communication, the data received is different throughout the receivers.

• Limited Reception - When the information sent in 1:N communication is only received by some of the receivers.

• Blocking Communication Access - Access to a communication channel is blocked.

So, regarding all these possible communication faults, what does E2E add to handle data safely? It defines a set of E2E profiles, which depending on the profile, the protection mechanisms will be more. We'll talk more about the profiles available in the last part of this article. Let's now look at the data protection mechanisms present on the E2E profiles, which can use a subset of them:

• CRC (Cyclic Redundancy Check)- The obvious, creating and supervising a CRC.

• Sequence Counter - Every transmission request will increment a counter, which the correct incrementation is checked on the receiver side, to detect if a frame was missed, for instance.

• Alive Counter - The same incrementation as the sequence counter, but it's a simpler mechanism, where you check if the value is changed, you do not care if the increment was correct.

• ID's - Every data element sent via a port has an ID associated to it, for every I-PDU group, defined globally within the system.

• Timeout Detection - Checks for receiver communication and sender acknowledgement timeouts.

Lastly, let's talk about the E2E profiles. There are multiple defined in the specification, more than 7, to be precise. Do you need to know all of them by heart? Absolutely not. They are defined by the OEM and it's only our job to obey to them. You can always take a look at the specification for E2E to learn this further, if you need.

Alright, that's all for today! Stay tuned for the next part of this article, where we'll look at E2E in practice, to see how this fits in the Autosar layered architecture. If you don't want to wait, we advise you to take a dive into functional safety, where E2E fits, in our article What is Functional Safety (opens in a new tab).

Author: Micael Coutinho (opens in a new tab)

References:

• Specification of SW-C End-to-End Communication Protection Library - Autosar Specification (opens in a new tab)