Why E2E When CAN has CRC?

Having worked with CAN protocol and CAN stack testing nearly two decades ago, we have always been fascinated by how robust CAN is when it comes to error detection. Bit errors, stuff errors, CRC errors, form errors, acknowledgement errors — CAN has a mechanism to detect all of these, along with fault confinement mechanisms such as error passive and bus-off.

So, when we first came across E2E protection in the context of functional safety, we had the question: If CAN already has CRC and several other error detection mechanisms, why is another layer of protection, such as E2E, required for a FuSa application? 

The answer lies in understanding the boundaries within which CAN's error detection mechanisms operate.

To understand how this really works, we will approach the topic as follows:

1. Refresh the basics
   1. What does a CAN frame look like?
   2. What are the layers of a CAN stack?
   3. What are the error detection mechanisms available in CAN protocol?
2. Data flow from the transmitting ECU to the receiving ECU
3. Communication failure mitigation from the transmitting ECU to the receiving ECU
   1. What are the communication failure modes to be covered as per ISO 26262?
   2. Mapping of the communication failure modes to E2E and CAN protocol mechanisms

We think that going deeper into this topic will provide a better understanding of why CAN's existing error detection mechanisms, despite being quite powerful, are insufficient to provide the end-to-end protection required by a FuSa application.

Refreshing the basics

What does a CAN frame look like?

A CAN data frame looks like this:

Part of the frame	Purpose (simplified description, not complete!)
Start of Frame	Indicates the start of a new message to the Rx node
Arbitration Field	Includes Identifier and the RTR bit. Note: 11-bit identifier for classic CAN and 29-bit identifier for extended CAN Since CAN is a broadcast protocol, multiple ECUs may transmit their messages on the CAN bus at the same time. The identifier defines the priority of the CAN messages. Each node transmits each bit of the identifier on the CAN bus. The node that transmits the dominant bits (0) wins arbitration, and the message that wins arbitration is broadcast on the CAN bus. RTR: Remote Transmission Request is a 1-bit value that indicates whether the frame is a data frame or a remote frame.
Control Field	The control field is a 6-bit value consisting of a 4-bit data length code and 2 reserved bits for future extensions.
Data Field	The Data Field is up to 8 bytes and consists of the data to be transferred within a data frame. It contains the data of the signals within the CAN message, what we call the 'Application payload'. When we calculate CRC for a message via E2E, this CRC also gets sent as part of the data field.
CRC Field	This is a 15-bit CRC (0x4599 polynomial) calculated for the entire CAN frame starting from Start of Frame (SOF) through the end of the Data Field
ACK Field	The acknowledgement field contains a 2-bit value: an ACK slot and an ACK delimiter. The ACK slot is recessive (1) during transmission. When the Rx node receives a valid CRC value, it sets the ACK slot to dominant (0) to indicate to the Tx node that the message has been received without loss or corruption.
End of Frame	It is a 7-bit recessive (1) value that indicates to the Rx nodes that the transmitted CAN message has ended.

What are the layers of a CAN stack?

As per CAN Specification v2.0, there are 4 broad layers in a CAN stack.

Layer	Responsibilities of the layer
Application Layer	• Mapping of message ID and signal to memory • Periodicity of the message and signals • Value type and data range of each signal • Message/signal timeout value etc.
Object Layer	• Rx message filtering: identifies which messages are relevant to the node, creates a queue based on priority, and presents it to the application layer • Tx message processing: creates a queue based on priority and presents it to the transfer layer for transmission • Informs the application layer when a transmission is successful or a reception is in progress
Transfer Layer	• Bit timing and synchronization • Message framing • Arbitration • Acknowledgement • Error detection and signaling • Fault confinement
Physical Layer	• Converts the data from the transfer layer into voltage levels (1s and 0s) and transmits it on the CAN bus • Processes the voltage levels (1s and 0s) from the received data

What are the error detection mechanisms available in CAN?

Error detected	Description
Bit Error	A unit that is sending a bit on the bus also monitors the bus. A BIT ERROR is detected if the bit value that is monitored is different from the bit value that is sent.
Stuff Error	A stuff error is detected at the bit time of the 6th consecutive equal bit level in a message field that should be coded using the bit-stuffing method.
CRC Error	A CRC ERROR is detected if the calculated result is not the same as that received in the CRC sequence.
Form Error	A FORM ERROR is detected when a fixed-form bit field contains one or more illegal bits.
Acknowledgement Error	An ACKNOWLEDGMENT ERROR is detected by a transmitter whenever it does not monitor a 'dominant' bit during the ACK SLOT.
Bus-off	A fault-containment state in CAN in which a CAN node disconnects itself from the CAN bus because it has detected too many transmission errors.

The transfer layer is responsible for error detection in CAN.

Data Flow from the Transmitting ECU to the Receiving ECU

The typical data flow from a transmitting ECU to a receiving ECU at the system level is shown below.

The application-layer software sends the payload information to the CAN stack, which is then transmitted over the physical bus. At the receiving end, the CAN stack receives the message from the CAN bus, extracts the payload, and sends it to the application for further processing. E2E (end-to-end protection) is implemented within the application to support the detection and prevention of data failures.

Communication Failure Mitigation from Tx ECU to Rx ECU

What are the communication failure modes to be covered as per ISO 26262?

As per ISO 26262-5, the typical failure modes in serial or parallel communication are:

• Loss of communication
• Peer message corruption
• Message unacceptable delay
• Message loss
• Unintended message repetition
• Incorrect sequencing of messages
• Message insertion
• Message masquerading
• Message incorrect addressing

Mapping of Communication Failure Modes to E2E and CAN Protocol Mechanisms

Now, let's map these communication failure modes to:

• whether they are covered by the native CAN protocol and, if so, which mechanism covers them
• AUTOSAR E2E solutions that cover each failure mode

Communication failure mode	Native CAN detection?	CAN error detection mechanism	E2E solution
Loss of communication	Partly	ACK error Bus-off Transmit error counter Receive error counter	Timeout
Message unacceptable delay	No	-	Timeout
Message loss	Partly	ACK error	Timeout
Unintended message repetition	No	-	Alive counters Sequence counters
Incorrect sequencing of messages	No	-	Alive counters Sequence counters
Message insertion	No	-	Data ID
Message masquerading	Partly	-	Data ID CRC
Message incorrect addressing	No	-	Data ID
Peer Message corruption	Yes	Bit error Stuff error CRC error Form error	CRC

Conclusion

CAN protocol-level fault detection mechanisms are robust and protect the network against nodes that exhibit protocol-level transmission errors. However, they cannot verify whether the application data being transmitted is fresh, correctly sequenced, or semantically correct, because they only look at the frame and not the payload. Hence, E2E solutions are needed to verify data correctness end-to-end, and to detect errors that are injected at the application level which CAN's mechanisms cannot see.

We will wrap this article up with an interesting follow-up question — If CAN stack and Application is developed as ASIL, do we still need E2E?