CAN Error Detection: Types of Undetected Errors
* Question
What are the five types of errors not included in CAN’s error detection mechanism?
* Answer
In the Controller Area Network (CAN) protocol, error detection and fault confinement are fundamental features that ensure high reliability in data communication.
However, not all possible errors are detected or managed by the CAN protocol itself.
According to the CAN standard (ISO 11898), there are five types of errors that are not included in CAN’s error-detection mechanism — meaning they are outside the scope of CAN’s internal error-handling system.
Background: CAN Error Detection Overview
Before listing the excluded errors, here’s a quick recap of the five types of errors CAN does detect internally:
- Bit Error
- Stuff Error
- CRC Error
- Form Error
- Acknowledgment (ACK) Error
These are handled through error flags, automatic retransmissions, and error counters to maintain bus integrity.
Five Types of Errors Not Included in CAN
The following five error types are not detected or managed by the CAN protocol itself:
No. | Error Type | Description |
1. Node Internal Error | Errors inside the CAN controller or MCU (e.g., logic failure, CPU fault, or memory corruption) are not detected by CAN’s protocol-level mechanisms. |
|
2. Synchronization Error | Timing mismatches or clock drift between nodes that are within tolerance limits may not be detected by CAN if the bit timing remains valid. |
|
3. Local Hardware Error | Physical layer issues at a single node (e.g., transceiver malfunction, voltage instability, or short within the node) may not be recognized by other nodes or the protocol. |
|
4. Application-Layer Error | CAN only ensures data frame integrity — it does not verify the meaning or correctness of the transmitted data (e.g., wrong sensor value or incorrect control logic). |
|
5. Protocol Implementation Error | Errors caused by incorrect CAN controller firmware or software implementation (e.g., wrong error handling or timing parameters) are beyond the scope of CAN’s built-in error detection. |
|
Explanation
- Node Internal Error:
CAN handles transmission and reception logic, but it cannot detect microcontroller failuresor internal circuit malfunctions.
These must be handled by system-level diagnostics or watchdog mechanisms. - Synchronization Error:
CAN synchronization uses edge sampling and resynchronization, but minor clock deviations within the tolerance limit are not treated as errors.
Large deviations can cause bit errors, but those are detected only after they violate the bit timing rules. - Local Hardware Error:
A single node may experience physical faults(e.g., damaged transceiver or open circuit) that isolate it.
CAN cannot distinguish between a hardware defect and a normal “bus idle” condition. - Application-Layer Error:
CAN only guarantees the integrity of the frame (via CRC), not the semantic validityof the message content.
For example, if a temperature sensor sends a physically impossible reading, the CAN layer will still consider the message valid. - Protocol Implementation Error:
If a CAN controller’s design or firmware does not correctly implement the ISO 11898 protocol, CAN’s built-in mechanisms cannot detect such errors.
These are typically caught during system testing or compliance validation.
Summary Table
Included in CAN Error Detection | Not Included in CAN Error Detection |
Bit Error | Node Internal Error |
Stuff Error | Synchronization Error |
CRC Error | Local Hardware Error |
Form Error | Application-Layer Error |
ACK Error | Protocol Implementation Error |
Summary
In short, CAN provides robust frame-level error detection but does not cover device-internal, physical-layer, or application-level faults.
The five types of errors not included in CAN are:
- Node internal error
- Synchronization error
- Local hardware error
- Application-layer error
- Protocol implementation error