End-to-End Protection: Quick Overview
Modern vehicles contain several Electronic Control Units (ECUs) that communicate with each other to exchange information such as vehicle speed, steering angle, braking requests, and sensor measurements.
These ECUs communicate using automotive networks such as CAN, CAN FD, and Automotive Ethernet. But what happens if the data gets corrupted during transmission? What if a message is lost or an old message is received again? For safety-critical applications, such communication failures can have serious consequences. This is where End-to-End (E2E) Protection comes into the picture.
In this article, we'll understand why E2E protection is needed, how it works, and how AUTOSAR uses different E2E profiles to protect communication between software components.
Why Do We Need End-to-End Protection?
Let's consider a simple example. A vehicle contains two ECUs:
ECU A: Measures vehicle speed.
ECU B: Uses vehicle speed information for a safety-related function.
ECU A periodically sends vehicle speed information to ECU B.
ECU A ECU B
+-------------+ +-------------+
| | | |
| Speed | Speed = 80 | Vehicle |
| Sensor | ------------> | Controller |
| | | |
+-------------+ +-------------+Under normal conditions, ECU B receives the correct speed value. However, communication systems are not always perfect. For example, ECU A sends:
Speed = 80 km/hBut due to corruption somewhere in the communication path, ECU B receives:
Speed = 180 km/hIf ECU B uses this incorrect information without detecting the error, it could affect the vehicle's behavior. Similarly, other problems may occur:
Data corruption: The received data differs from the transmitted data.
Message loss: One or more messages are lost during communication.
Message repetition: Previously transmitted data is received again.
Incorrect sequence: Messages arrive in an unexpected order.
Message masquerading: Data is incorrectly accepted as belonging to another communication source or data stream.
Message delay: Information arrives too late to be useful.
Although communication protocols already provide mechanisms such as CRC and other error-detection features, these mechanisms do not necessarily protect the complete communication path between the application software components.
What Does End-to-End Mean?
Consider the following communication architecture.
ECU A
+-----------------------+
| Application Software |
| |
| Speed Information |
+-----------+-----------+
|
v
+-----------------------+
| Communication Stack |
+-----------+-----------+
|
|
|
v
CAN / Ethernet Channel
|
|
v
+-----------------------+
| Communication Stack |
+-----------+-----------+
|
v
+-----------------------+
| Application Software |
| |
| Speed Consumer |
+-----------------------+
ECU BThe data passes through multiple software and hardware layers before reaching the destination. Errors can occur at different points, including communication buffers, software interfaces, memory, and network transmission.
A CRC provided by a lower communication layer generally protects only the portion of the communication path covered by that layer. E2E protection extends error detection across the communication path between the protected data producer and consumer. It achieves this by adding protection information to the application data before transmission. The receiver uses this information to verify the received data.
How Does E2E Protection Work?
Let's extend our vehicle speed example. Instead of transmitting only the speed value, ECU A also transmits additional protection information. For a simple CRC-and-counter-based profile, the protected data can be visualized as:
+----------------+----------------+----------------+
| Vehicle Speed | Counter | CRC |
+----------------+----------------+----------------+
| 80 km/h | 5 | Calculated CRC |
+----------------+----------------+----------------+Here:
Vehicle Speed: Actual application data.
Counter: Helps the receiver detect unexpected message sequences.
CRC: Helps detect accidental corruption of the protected data.
The sender calculates the CRC according to the configured E2E profile and transmits the protected data. At the receiving end, the E2E mechanism verifies the received information.
SENDER (ECU A)
+----------------------+
| Vehicle Speed = 80 |
+----------+-----------+
|
|
v
+----------------------+
| E2E Protection |
| |
| Add Counter |
| Calculate CRC |
+----------+-----------+
|
|
v
+----------------------+
| Speed + Counter + CRC|
+----------+-----------+
|
|
Communication
|
v
RECEIVER (ECU B)
+----------------------+
| Speed + Counter + CRC|
+----------+-----------+
|
|
v
+----------------------+
| E2E Verification |
| |
| Verify CRC |
| Check Counter |
+----------+-----------+
|
|
v
+----------------------+
| E2E Check Result |
+----------------------+Let's understand how CRC and counter help detect communication errors.
1. Detecting Data Corruption Using CRC
Suppose ECU A wants to transmit:
Speed = 80
Counter = 5The E2E protection mechanism calculates a CRC over the configured protected data and associated profile-specific inputs. For illustration, assume the resulting CRC is 0xA5. The transmitted information becomes:
+-------------+-------------+-------------+
| Speed = 80 | Counter = 5 | CRC = 0xA5 |
+-------------+-------------+-------------+Now assume the speed value gets corrupted during communication. The receiver gets:
+-------------+-------------+-------------+
| Speed = 180 | Counter = 5 | CRC = 0xA5 |
+-------------+-------------+-------------+ECU B recalculates the CRC using the received data. Since the speed value has changed, the calculated CRC will generally differ from the transmitted CRC.
Received CRC = 0xA5
Calculated CRC = Different value
Result: CRC ErrorThe E2E check can therefore detect the corrupted data. Note, CRC is an error-detection mechanism, not an absolute guarantee against every possible corruption pattern. Its effectiveness depends on the CRC algorithm and protected data.
2. Detecting Lost Messages Using a Counter
CRC alone cannot identify all communication problems. For example, what happens if an entire message is lost? Consider a sender transmitting messages with incrementing counter values.
ECU A ECU B
Counter = 1 ----------------> Counter = 1
Counter = 2 ----------------> Counter = 2
Counter = 3 ------X Message Lost
Counter = 4 ----------------> Counter = 4The receiver expects the counter to follow the configured sequence. However, after receiving counter 2, the next received counter is 4. This indicates that a message may have been lost.
Previous Counter = 2
Received Counter = 4
Counter Delta = 2Depending on the E2E profile and configured acceptance limits, this counter jump can be reported as a sequence deviation or as a valid reception with some lost messages. This allows the receiver to distinguish between normal communication and certain communication errors.
3. Detecting Repeated Messages
Consider another scenario.
ECU A ECU B
Counter = 5 ----------------> Counter = 5
Counter = 6 ----------------> Counter = 6
----------------> Counter = 6
(Repeated)The receiver observes the same counter value again. For a profile using a sequence counter, this can indicate repeated data. Notice that the CRC may still be valid because the message content has not changed. Therefore, CRC alone is insufficient to detect this situation. The counter provides additional information about the communication sequence.
AUTOSAR E2E Profiles
AUTOSAR defines different E2E profiles that specify how application data is protected and checked. These profiles define aspects such as:
CRC calculation and placement, where applicable
Counter handling, where applicable
Data identification and protection layout
Profile-specific error-detection behavior
Different profiles support different communication requirements.
Let's look at a simplified example based on AUTOSAR E2E Profile 1.
Example: AUTOSAR E2E Profile 1
Profile 1 is one of the simpler AUTOSAR E2E profiles and is useful for understanding the basic concept. It uses:
An 8-bit CRC
A 4-bit counter
Profile-specific Data ID handling
The Data ID helps associate the protected data with its configured identity and contributes to CRC-based protection against certain masquerading errors. The exact CRC calculation and layout depend on the configured Profile 1 variant. A simplified representation is:
Protected Data
+----------------+----------------+----------------+
| CRC (8 bits) | Counter (4 bits)| Application |
| | | Data |
+----------------+----------------+----------------+This is a conceptual representation. Actual bit and byte positions are configurable and must follow the profile requirements.
Sender Side
Consider an application transmitting vehicle speed periodically.
struct SpeedData
{
uint16_t speed;
uint8_t counter;
uint8_t crc;
};A simplified sender-side sequence looks like:
void SendSpeedData()
{
// Update application data
speedData.speed = ReadVehicleSpeed();
// E2E protection updates the counter
// and calculates the CRC.
ProtectSpeedData(speedData);
// Transmit protected data
Transmit(speedData);
}Here, ProtectSpeedData() is a conceptual wrapper representing the E2E protection operation. In an actual AUTOSAR implementation, the corresponding E2E Profile 1 API, such as E2E_P01Protect(), is used with the appropriate configuration and data buffer.
Receiver Side
The receiver performs the corresponding verification.
void ReceiveSpeedData()
{
SpeedData data = Receive();
// Verify received E2E information
auto result = CheckSpeedData(data);
if (result == E2E_OK)
{
ProcessSpeed(data.speed);
}
else
{
HandleCommunicationError();
}
}Again, this is simplified pseudocode. In a real AUTOSAR system, the E2E check produces profile-specific status information, which must be interpreted according to the configured communication and state-management behavior.
A successful CRC check alone does not necessarily mean that the data should be accepted by the application.
What Happens After an E2E Error Is Detected?
One important point is that E2E protection primarily detects communication errors; it does not automatically correct corrupted data. For example, if ECU B detects an invalid speed message, the application may decide to:
Ignore the received data
Continue using the last valid value, subject to freshness limits
Substitute a configured fallback value
Report a communication fault
Transition to a defined safe state
The appropriate action depends on the safety requirements of the application. For example, a non-critical display function and a safety-critical braking function may react differently to the same communication error.
Does E2E Protection Detect Every Communication Error?
Not necessarily. The detection capability depends on the selected E2E profile, configuration, message pattern, and receiver behavior. For example:
Data corruption: CRC can detect many accidental data modifications.
Lost messages: Counter-based profiles can identify certain missing-message sequences.
Repeated messages: Counter-based profiles can identify repeated counter values.
Incorrect sequence: Counter checks can detect unexpected sequence changes.
Masquerading: Data ID and other profile-specific mechanisms help detect certain forms of incorrect data association.
Message delay: E2E sequence checks alone do not establish an absolute message age. Detecting excessive delays or complete communication loss may require timeout monitoring and other mechanisms.
It is also important to understand that not every AUTOSAR E2E profile uses exactly the same combination of CRC and counter mechanisms.
Summary
End-to-End protection helps detect communication errors between application data producers and consumers.
It complements lower-layer communication protection mechanisms.
CRC helps detect accidental data corruption.
Sequence counters help detect certain lost, repeated, and out-of-sequence messages.
AUTOSAR defines multiple E2E profiles for different communication requirements.
Profile 1 provides a useful starting point for understanding CRC- and counter-based protection.
E2E protection detects errors but does not automatically correct corrupted information.
The receiving application must decide how to handle invalid or unavailable data according to its safety requirements.
In simple terms, E2E protection helps the receiving application determine whether the received information can be trusted from a communication-integrity perspective before using it. This becomes particularly important in modern vehicles, where safety-related software components exchange information across increasingly complex communication architectures.
Comments