CAN(Controller Area Network): 차량 안에서 ECU가 대화하는 방법

자동차 한 대 안에는 수십 개의 ECU(Electronic Control Unit)가 있고, 이들이 호스트 컴퓨터 없이도 서로 대화해야 한다. CAN(Controller Area Network)은 이 문제를 메시지 지향 브로드캐스트 버스로 풀어낸 산업 표준이다. ISO 11898을 기반으로 실시간성, 신뢰성, 배선 비용 절감을 동시에 달성한다.

메시지가 오가는 방식

모든 노드는 같은 버스에 접속해 있고, 식별자(ID) 기반 프레임을 수신 필터링해 처리한다. 충돌 회피는 CSMA/CR(Carrier Sense Multiple Access with Collision Resolution) 방식으로, 지배(dominant, 0)와 열림(recessive, 1) 비트를 유선-AND로 중재해 충돌 없이 우선순위를 정한다.

표준은 두 종류다. Classical CAN은 11비트 또는 29비트 ID에 최대 8바이트 페이로드를 쓰고, CAN FD(Flexible Data-rate)는 최대 64바이트 페이로드에 데이터 구간을 가속한다. 프레임은 SOF → 중재필드(ID, RTR) → 제어필드 → 데이터 → CRC → ACK → EOF 순으로 구성되며, 데이터·원격·에러·오버로드 네 종류 프레임을 지원한다. 물리 계층은 차동 신호(CAN_H/CAN_L)를 쓰고 120Ω 종단저항을 양단에 적용하는데, 비트레이트와 배선 길이 사이에는 트레이드오프가 있다.

실시간성과 신뢰성을 만드는 구조

물리 계층은 트위스트 페어 기반 차동 전송으로 EMC 내성과 장거리 전송이 용이하다. 대략 1 Mbps 기준으로는 수십 m, 125 kbps 기준으로는 수백 m 수준까지 설계할 수 있다. 버스 톱올로지가 권장되며 종단 120Ω은 두 지점에만 적용하고 스텁 길이는 최소화해야 한다.

우선순위 중재는 낮은 ID가 높은 우선순위를 갖는 구조다. 비트 단위 중재이기 때문에 충돌 없이 고우선 프레임이 선점되고, 최악지연을 미리 산정할 수 있어 하드 실시간 제어에 적합하다. 버스 점유율을 설계 단계에서 관리하면 지연 상한을 보장할 수 있다.

오류는 CRC, 포맷, 비트 스터핑, ACK 등 다중 방식으로 검출하고 에러 프레임으로 즉시 재전송을 유도한다. 에러 카운터를 기반으로 error-active → error-passive → bus-off 순서로 상태를 전이시켜 결함 노드를 버스에서 격리한다. 상위 규격으로는 ISO-TP(프레임 분할·재조립), UDS(진단, ISO 14229), J1939, CANopen이 결합되고, DBC/ARXML로 신호를 매핑하고 AUTOSAR COM/PDUR로 소프트웨어 계층을 나눈다. SocketCAN, PCAN, Vector 같은 툴체인과 OBD-II 기반 진단·로깅이 생태계를 뒷받침한다.

⤢✕

실제로 어디에 쓰이는가

파워트레인·샤시 제어에서는 엔진·변속기·ABS·ESP 사이에 토크·휠속·회전수 신호를 공유하며 보통 500 kbps~1 Mbps 구간에서 운용한다. 바디·편의 시스템은 BCM·조명·도어·HVAC 제어에 저속 CAN(125 kbps)을 쓰거나 LIN과 게이트웨이로 연계한다. 진단·생산·정비 영역에서는 UDS·ISO-TP로 DTC를 읽고 ECU를 플래싱하며 공장 EOL 테스트를 수행한다. 상용차·산업기계는 J1939·CANopen 기반으로 파워 유닛과 작업기를 제어하고, AGV·로보틱스 같은 비자동차 영역으로도 쓰임새가 넓어지고 있다.

설계·운영에서 지켜야 할 것들

물리 계층에서는 종단 저항 120Ω을 두 지점에, 스텁(분기) 길이는 0.3m 이하로 권장한다. 분할 종단(split termination)이나 공통 모드 초크로 EMC를 개선할 수 있다. 비트레이트와 배선 길이는 트레이드오프 관계라, 1 Mbps에서는 총 길이 수십 m, 250 kbps에서는 수백 m 수준으로 설계된다.

중재·부하 설계는 신호의 데드라인을 기준으로 ID 우선순위를 정하고, 가장 낮은 우선순위 프레임이 얼마나 오래 블로킹될 수 있는지를 고려해야 한다. 버스 점유율은 30~60%를 목표로 하되, 진단이나 에러가 폭주하는 피크 시나리오까지 포함해 용량을 검증한다.

오류·진단·안전 측면에서는 에러 카운터를 모니터링하고 bus-off 복구 정책(자동/수동)을 정의하며 고장 격리·폴백 모드를 설계한다. 프레임 타임스탬프와 에러 프레임을 로깅하고 DBC를 일관되게 관리해 생산과 현장에서 같은 툴 포맷을 쓰는 것이 좋다.

보안은 CAN이 기본적으로 취약한 지점이다. 인증이나 암호화가 기본 제공되지 않기 때문에 게이트웨이 필터링, 구역 분리, IDS 적용이 필요하다. 상위 계층에서 SecOC 같은 메시지 인증, UDS 접근 제어, 레이트 리밋을 설계해야 하고, OTA 업데이트 시에는 안전 모드로 전환하는 절차가 필요하다. 운영 단계에서는 정기적으로 버스 로드와 에러율을 점검하고, 캡처 파일을 재현 가능한 테스트 케이스로 구축하며, DBC 버전 관리와 신호 변경 임팩트 분석을 자동화하는 것이 권장된다.

이런 설계 원칙이 실제로 만드는 수치도 있다. 포인트-투-포인트 배선 대비 하네스 길이·무게를 3040% 절감할 수 있고, 커넥터·ECU I/O 핀 수도 줄어든다. 1 Mbps·11비트 ID·8바이트 페이로드 기준으로는 프레임 하나가 110130μs 정도에 전송되고, 우선순위 기반으로 지연 상한을 계산하기 쉽다. 최대 수십~100개 이상의 노드를 구성할 수 있어(물리 설계에 따라 다름) 서로 다른 제조사의 ECU 간에도 상호운용이 가능하다.

예시 계산: 프레임 전송 시간

1 Mbps, 11비트 ID, 데이터 8바이트, 표준 스터핑 평균을 포함한다고 가정하면 프레임 길이는 대략 110130비트(상용 툴 계산 기준)이고, 전송 시간은 약 110130μs/프레임이다. 이 조건에서 50% 버스 점유율이면 초당 약 3,800~4,500프레임의 데이터를 처리할 수 있다.

Classical CAN과 CAN FD 비교

구분	성능	확장성	일관성	안정성	운영 편의
Classical CAN (2.0A/B)	1 Mbps, 8B 페이로드	노드 수 많음, 길이 제약 완화(저속)	ID 기반 고정 우선순위	강력한 에러 검출/격리	폭넓은 호환성, 저비용
CAN FD	데이터 구간 2~8 Mbps, 64B 페이로드	동일 배선에서 처리량 증대, 일부 트랜시버 교체 필요	동일 중재, 대용량 신호 집적 유리	CRC 강화(FD 전용), 혼재 설계 주의	대역 효율↑, 진단/로깅 효율↑

SocketCAN으로 바로 확인해보기

Linux kernel 5.x 환경에 can-utils가 설치돼 있다면 물리 인터페이스를 다음처럼 바로 다룰 수 있다.

ip link set can0 type can bitrate 500000
ip link set can0 up
candump can0
cansend can0 123#1122334455667788

실제 하드웨어가 없다면 가상 인터페이스로 대체할 수 있다.

modprobe vcan && ip link add dev vcan0 type vcan && ip link set vcan0 up

Classical CAN이 검증된 안정성과 폭넓은 호환성을 무기로 여전히 쓰이는 한편, CAN FD는 같은 물리 배선 위에서 처리량을 늘려야 하는 상황에서 선택지가 된다. 물리 설계 원칙을 지키고 우선순위·부하를 체계적으로 설계하며 진단·보안 운영 체계를 갖추는 것이 두 표준 모두에 공통으로 요구된다.