테마
05. CAN 에러 처리와 CAN FD
학습 목표
- CAN Controller가 감지하는 주요 에러 종류를 설명할 수 있다.
- TEC와 REC가 Error State 전이에 어떻게 쓰이는지 이해할 수 있다.
- Error Active, Error Passive, Bus-Off 상태의 차이를 구분할 수 있다.
- Bus-Off가 발생했을 때 소프트웨어가 왜 개입해야 하는지 설명할 수 있다.
- Classical CAN과 CAN FD의 핵심 차이를 이해할 수 있다.
전체 구조
1. CAN은 에러 감지와 격리까지 포함한다
CAN 통신은 단순히 메시지를 보내는 규칙만 제공하지 않는다.
통신 중 에러를 감지하고, 문제가 반복되는 노드가 전체 네트워크를 망치지 않도록 상태를 관리하는 메커니즘도 포함한다.
이 메커니즘의 상당 부분은 MCU 내부의 CAN Controller가 처리한다.
소프트웨어 개발자는 모든 비트 수준 에러를 직접 구현하지는 않지만, 현재 컨트롤러 상태와 Bus-Off 발생은 반드시 알아야 한다.
2. 주요 에러 종류
CAN Controller는 여러 종류의 에러를 감지한다.
| 에러 | 의미 |
|---|---|
| Bit Error | 자신이 출력한 비트와 실제 버스에서 읽은 비트가 기대와 다를 때 |
| Stuff Error | 같은 비트 값이 허용 규칙을 넘어 연속될 때 |
| CRC Error | 수신자가 계산한 CRC와 메시지의 CRC가 맞지 않을 때 |
| Acknowledge Error | 송신자가 ACK를 기대했는데 아무도 ACK하지 않을 때 |
| Form Error | 메시지의 고정 포맷 영역이 규칙을 어길 때 |
이 에러들은 대부분 CAN Controller가 하드웨어 수준에서 감지한다.
개발자는 에러 발생 시 컨트롤러 상태, 인터럽트, 진단 로깅, 복구 정책을 어떻게 처리할지 결정한다.
3. Bit Stuffing은 연속 비트를 제한한다
CAN에는 같은 비트 값이 너무 오래 연속되지 않도록 하는 규칙이 있다.
예를 들어 같은 값이 5번 연속되면 반대 값을 하나 끼워 넣는 방식으로 신호 동기화를 돕는다.
이 규칙을 어긴 패턴이 버스에서 감지되면 Stuff Error로 판단된다. 즉 정상적인 Stuffing 적용 구간에서는 같은 값 5개 뒤에 반대 Stuff Bit가 나와야 하므로, 예외 구간을 제외하고 같은 값이 6개 이상 이어지면 규칙 위반으로 본다.
Bit Stuffing은 단순 암기 항목이 아니다.
Active Error Frame이 같은 Dominant 비트를 연속으로 내보내 네트워크 전체가 에러를 감지하게 만드는 원리와도 연결된다.
4. TEC와 REC는 에러 이력을 수치화한다
CAN Controller는 에러가 발생할 때마다 내부 카운터를 조정한다.
| 카운터 | 의미 |
|---|---|
| TEC | Transmit Error Counter, 송신 중 에러와 관련 |
| REC | Receive Error Counter, 수신 중 에러와 관련 |
에러가 발생하면 카운터가 증가하고, 정상 송수신이 이어지면 감소한다.
카운터 값이 일정 기준을 넘으면 Controller의 상태가 바뀐다.
이 구조의 목적은 단순하다.
- 일시적인 노이즈 한 번으로 ECU를 바로 격리하지 않는다
- 반복적으로 문제를 일으키는 ECU는 점점 네트워크 영향력을 줄인다
- 심각한 경우 Bus-Off로 버스 참여를 중단한다
5. Error Active는 적극적으로 에러를 알린다
정상적인 CAN Controller는 보통 Error Active 상태에서 동작한다.
이 상태에서 에러를 감지하면 Active Error Frame을 보내 네트워크 전체에 에러 상황을 알린다.
Active Error Frame은 Dominant 비트를 연속으로 내보내 다른 ECU들도 규칙 위반을 감지하게 만든다.
그 결과 현재 메시지는 실패한 것으로 처리되고 재전송이 일어난다.
이 방식은 빠르게 오류를 전파한다는 장점이 있지만, 문제가 많은 ECU가 계속 Active Error Frame을 보내면 네트워크 전체를 방해할 수 있다.
6. Error Passive는 영향력을 낮춘 상태다
에러가 반복되어 카운터가 커지면 Controller는 Error Passive 상태가 된다.
이 상태에서도 통신에 참여할 수 있지만, 에러를 알리는 힘이 약해진다.
Error Passive 상태의 노드는 Passive Error Frame을 사용한다.
Recessive 비트 중심이므로 다른 정상 송신을 강하게 깨뜨리지 못한다.
또한 Error Passive 노드는 메시지 송신에서도 일부 지연을 받을 수 있다.
의도는 분명하다. 에러를 자주 내는 노드가 네트워크 전체 품질을 해치지 않도록 우선순위를 낮추는 것이다.
7. Bus-Off는 네트워크에서 빠지는 상태다
에러가 더 심해지면 Controller는 Bus-Off 상태가 된다.
Bus-Off 상태에서는 메시지를 송신하거나 수신하지 못한다.
Bus-Off가 중요한 이유는 다음과 같다.
- 단순 통신 실패가 아니라 CAN Controller가 버스 참여를 중단한 상태다
- 하드웨어가 자동으로 완전 복구하지 않을 수 있다
- 소프트웨어가 Controller를 재초기화하거나 복구 시퀀스를 수행해야 할 수 있다
- 안전 관련 기능에서는 Bus-Off 동안 기능 제한이나 DTC 기록이 필요할 수 있다
실무에서는 Bus-Off 발생 시 다음을 확인한다.
- 어떤 네트워크에서 발생했는가?
- 발생 직전 어떤 에러 카운터가 증가했는가?
- 배선, 종단저항, 트랜시버 모드, Baud Rate가 맞는가?
- 재시도 간격과 최대 재시도 횟수는 사양과 맞는가?
- DTC나 로그를 남겨야 하는가?
8. ACK Error는 수신자가 없을 때도 발생할 수 있다
CAN 메시지를 송신하면 송신자는 누군가가 ACK를 해주기를 기대한다.
정상적으로 수신한 ECU가 있으면 ACK Slot에서 Dominant를 내보내 메시지를 잘 받았음을 알린다.
그런데 개발실에서 ECU 하나와 장비 없이 단독으로 테스트하면, 메시지를 받을 노드가 없을 수 있다.
이 경우 실제 데이터가 나빠서가 아니라 ACK를 해줄 수신자가 없어서 ACK Error가 반복될 수 있다.
따라서 ACK Error를 볼 때는 "메시지 내용이 틀렸다"로 바로 결론 내리지 말고, 실제 버스에 ACK 가능한 수신 노드가 있는지 확인해야 한다.
9. CAN FD는 데이터 영역을 확장한다
Classical CAN은 한 메시지의 데이터 영역이 최대 8바이트다.
시대가 지나며 차량에서 주고받는 데이터가 늘어나자 이 제약은 점점 커졌다.
CAN FD(Flexible Data-rate)는 이 문제를 완화한다.
| 항목 | Classical CAN | CAN FD |
|---|---|---|
| 데이터 영역 | 최대 8바이트 | 최대 64바이트 |
| 전송 속도 | 메시지 전체가 같은 속도 | Arbitration 구간과 Data 구간 속도 분리 가능 |
| 호환성 | 기존 CAN | 네트워크와 장비 지원 확인 필요 |
| DLC 의미 | 0~8이 길이와 대응 | 9~15는 비선형 길이로 매핑 |
CAN FD에서 DLC 9~15는 다음 실제 데이터 길이를 뜻한다.
| DLC | 0~8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 |
|---|---|---|---|---|---|---|---|---|
| 데이터 길이(byte) | 0~8 | 12 | 16 | 20 | 24 | 32 | 48 | 64 |
CAN FD는 메시지 포맷이 기존 CAN과 비슷하지만 완전히 같은 것은 아니다.
트랜시버, Controller, 장비, DB, 네트워크 설계가 모두 CAN FD를 지원해야 한다.
10. Low Speed CAN과 다른 변형들
CAN에는 High Speed CAN만 있는 것이 아니다.
Low Speed CAN, Fault Tolerant CAN처럼 특정 목적에 맞춘 변형도 있다.
Low Speed CAN은 속도는 낮지만 특정 선이 끊어져도 통신을 이어갈 수 있도록 설계된 계열이 있다.
반면 현대 차량의 많은 제어 네트워크와 일반적인 개발 강의에서는 High Speed CAN을 기준으로 설명하는 경우가 많다.
실무에서는 "CAN을 쓴다"는 말만으로 충분하지 않다.
- 어떤 CAN 종류인가?
- Baud Rate는 얼마인가?
- CAN FD를 쓰는가?
- 트랜시버와 장비가 지원하는가?
- 종단저항과 배선 조건은 어떻게 되어 있는가?
이 질문을 프로젝트 사양에서 확인해야 한다.
핵심 정리
- CAN Controller는 Bit, Stuff, CRC, ACK, Form Error 같은 여러 에러를 감지한다.
- TEC와 REC는 에러 이력을 수치화하고 Error State 전이에 사용된다.
- Error Active는 강하게 에러를 알리고, Error Passive는 네트워크 영향력을 줄인다.
- Bus-Off는 Controller가 버스 참여를 중단한 상태이므로 소프트웨어 복구 정책이 필요하다.
- CAN FD는 데이터 영역을 최대 64바이트로 확장하고 데이터 구간 속도도 높일 수 있지만 전체 네트워크 지원을 확인해야 한다.
확인 질문
- Error Active와 Error Passive의 가장 큰 차이는 무엇인가?
- Bus-Off 상태가 되면 소프트웨어는 어떤 처리를 고려해야 하는가?
- ACK Error가 반드시 데이터 오류를 의미하지 않는 이유는 무엇인가?
- CAN FD를 적용할 때 Controller만 지원하면 충분하지 않은 이유는 무엇인가?