CAN 통신 기초 — 신입을 위한 입문

셀 밸런싱까지 BMS가 팩 안에서 하는 일을 봤다. 이번엔 BMS가 바깥 세상과 대화하는 방법, CAN 통신이다. 충전기·디스플레이·상위 제어기와 셀 전압·온도·상태를 주고받는 통로가 거의 다 CAN이다.

1. CAN이란, 왜 쓰나

CAN(Controller Area Network)은 자동차에서 출발한 차량용 통신 버스다. 여러 장치를 2가닥 선 하나에 매달아 통신하게 만든다.

CAN이 임베디드·배터리 분야에서 표준처럼 쓰이는 이유는 이렇다.

• 선이 적다: 장치가 늘어도 2선만 늘려 잇는다. 배선이 단순하다.
• 잡음에 강하다: 차동 방식이라 전기 노이즈가 심한 환경(모터·인버터 옆)에서도 잘 버틴다.
• 멀티마스터: 주인이 따로 없다. 아무 노드나 보낼 수 있고, 충돌은 우선순위로 정리한다.
• 메시지 기반: 특정 장치 주소가 아니라 메시지 ID로 통신한다. “누구에게"가 아니라 “무슨 내용"으로 구분한다.

2. 물리 계층 — 2선 차동

CAN은 CAN_H와 CAN_L 두 선의 전압 차로 신호를 만든다.

• recessive(1): 두 선이 모두 약 2.5V로 붙어 있다(전압 차 ≈ 0).
• dominant(0): CAN_H는 올라가고 CAN_L은 내려가 두 선이 벌어진다(전압 차 ≈ 2V).

왜 굳이 두 선의 차를 볼까. 노이즈는 보통 두 선에 똑같이 실린다. 그러면 두 선의 차이는 그대로 유지되므로, 잡음이 상쇄된다. 이것이 차동 방식이 강한 이유다.

물리 계층에서 꼭 기억할 것이 하나 있다. 버스 양 끝에 120Ω 종단저항을 넣어야 한다. 이게 없으면 신호가 반사돼 통신이 깨진다. 신입이 가장 자주 빠뜨리는 부분이다.

3. 프레임 구조

CAN은 데이터를 프레임(frame) 단위로 주고받는다. 표준 데이터 프레임은 이렇게 생겼다.

핵심만 보면 된다.

• ID(식별자): 이 메시지가 무엇인지 가리킨다. 표준은 11비트, 확장은 29비트.
• 데이터: 실제 내용. 한 프레임에 최대 8바이트. 셀 전압 몇 개나 온도·상태 비트를 여기 담는다.
• CRC: 오류 검출용. 받은 쪽이 데이터가 깨졌는지 확인한다.
• ACK: 누군가 제대로 받았다는 응답. 그래서 노드가 최소 2개는 있어야 통신이 성립한다.

ID가 “주소"가 아니라 “메시지 종류"라는 점이 CAN의 특징이다. 한 노드가 보낸 프레임은 버스의 모든 노드가 듣고, 각자 필요한 ID만 골라 받는다.

4. 우선순위 — 아비트레이션

멀티마스터라 두 노드가 동시에 보낼 수 있다. 그럼 충돌은 어떻게 정리할까. CAN은 **아비트레이션(arbitration)**으로 데이터를 깨뜨리지 않고 우선순위를 가린다.

원리는 단순하다.

• 두 노드가 ID를 비트 단위로 동시에 내보낸다.
• 한 노드가 0(dominant)을 보내고 다른 노드가 1(recessive)을 보내면, 버스는 0이 된다(dominant가 이긴다).
• 1을 보낸 노드는 버스가 0으로 바뀐 걸 보고 “내가 졌다"며 물러난다. 송신을 멈춘다.
• 결과적으로 ID 숫자가 작은 메시지가 우선순위가 높다.

중요한 건, 충돌이 일어나도 데이터가 깨지지 않는다는 점이다. 이긴 메시지는 그대로 계속 전송되고, 진 노드는 다음 기회에 다시 보낸다. 그래서 긴급한 메시지(보호·경고)에 낮은 ID를 주는 게 설계의 기본이다.

5. 비트레이트와 버스 길이

CAN은 모든 노드가 **같은 비트레이트(속도)**로 맞춰야 통신이 된다. 하나라도 다르면 전혀 안 된다.

자주 쓰는 속도와 대략적인 버스 길이 한계는 이렇다.

속도가 빠를수록 버스를 짧게 가져가야 한다. BMS·충전 시스템에서는 보통 250k 또는 500kbps를 많이 쓴다.

6. BMS에서의 CAN

BMS는 CAN으로 주로 이런 것들을 내보낸다.

• 셀별·팩 전압, 팩 전류
• 온도, SOC·SOH 추정값
• 보호 상태·경고 플래그(과전압·과전류·과온도 등)
• 컨택터(릴레이) 상태

반대로 상위 제어기나 충전기로부터 충전 허용 전류·전압 한계, 명령 등을 받는다.

실무에서는 이 메시지들을 매번 직접 정의하기보다, 상위 규약을 얹어 쓰는 경우가 많다.

• CANopen: 산업·로봇·배터리에서 널리 쓰는 규약. SDO/PDO로 파라미터를 주고받는다.
• J1939: 상용차 표준. 29비트 확장 ID 기반.

규약을 쓰면 메시지 ID·데이터 배치를 표준에 맞춰 정의할 수 있어 호환성이 좋아진다.

7. 실전 디버깅 체크리스트

CAN이 안 될 때 신입이 순서대로 볼 것.

1. 종단저항: 버스 양 끝에 120Ω이 있는가. 전원을 끄고 두 선 사이 저항을 재면 약 60Ω(120Ω 둘이 병렬)이 나와야 한다.
2. 비트레이트: 모든 노드가 같은 속도인가. 하나만 달라도 전부 안 된다.
3. 배선 극성: CAN_H와 CAN_L이 바뀌지 않았는가.
4. 공통 GND: 차동이라도 노드들이 같은 기준 전위(공통 그라운드)를 공유해야 한다.
5. 노드 수: 혼자선 ACK를 못 받는다. 최소 2개 노드가 살아 있어야 한다.
6. ID 충돌·우선순위: 긴급 메시지가 낮은 ID를 갖는지 확인한다.

이 여섯 개만 짚어도 CAN 문제의 대부분이 잡힌다.

마치며

CAN 통신의 핵심을 한 줄로 줄이면 이렇다.

2선 차동 버스 위에서, 메시지 ID로 내용을 구분하고 우선순위를 가린다.

선이 적고 잡음에 강하며, 충돌해도 데이터가 깨지지 않는다. 이 세 가지 덕분에 CAN은 BMS가 바깥과 대화하는 기본 통로로 자리 잡았다.

여기까지 오면 셀 하나(데이터시트)에서 팩(밸런싱), 그리고 바깥과의 통신(CAN)까지 한 줄로 이어진다. 입문 단계에서 이 그림을 손에 쥐면, 실무에서 마주치는 대부분의 배터리·BMS 작업이 낯설지 않을 것이다.