테마
01. CAN 통신 개요와 차량 네트워크
학습 목표
- 차량 제어기(ECU)가 무엇이고 왜 서로 통신해야 하는지 설명할 수 있다.
- 점대점 배선 방식이 차량에서 왜 비효율적인지 이해할 수 있다.
- CAN의 버스형 토폴로지와 브로드캐스트 방식을 구분할 수 있다.
- CAN 메시지 ID와 CAN DB가 협업에서 어떤 역할을 하는지 이해할 수 있다.
- 진단기 하나로 여러 ECU에 접근할 수 있는 구조적 이유를 설명할 수 있다.
전체 구조
1. 차량 안에는 여러 제어기가 있다
오늘날의 자동차에는 엔진, 변속기, 조향, 제동, 에어백, 공조, 램프, 도어, 카메라, 초음파 센서처럼 많은 전자장치가 들어간다.
각 장치를 제어하려면 소프트웨어가 필요하고, 그 소프트웨어가 실행될 작은 컴퓨터가 필요하다.
자동차 업계에서는 이 작은 컴퓨터를 보통 제어기 또는 **ECU(Electronic Control Unit)**라고 부른다.
ECU가 하나만 있다면 통신 문제는 크지 않다.
하지만 실제 차량에는 수십 개의 ECU가 있고, 이들은 서로의 정보를 필요로 한다.
예를 들면 다음과 같다.
| 정보 | 송신 ECU 예시 | 수신 ECU 예시 | 왜 필요한가 |
|---|---|---|---|
| 차량 속도 | 휠 속도 또는 샤시 ECU | 계기판, ADAS, 변속기 ECU | 표시, 제어, 안전 로직에 필요 |
| 배터리 전압 | BMS | 여러 전장 ECU | 전원 상태 판단에 필요 |
| 도어 열림 상태 | 바디 ECU | 계기판, 실내등 제어 ECU | 경고 표시와 편의 기능에 필요 |
| 엔진 RPM | 엔진 ECU | 계기판, 변속기 ECU | 표시와 변속 제어에 필요 |
핵심은 ECU가 각자 독립적으로 일하는 것이 아니라, 차량 전체의 상태를 공유하면서 동작한다는 점이다.
2. 점대점 배선은 금방 한계에 부딪힌다
가장 단순한 통신 방법은 필요한 ECU끼리 선을 직접 연결하는 것이다.
ECU가 두 개라면 선 하나면 충분해 보인다.
문제는 ECU 수가 늘어날 때다.
점대점 방식은 다음 문제가 생긴다.
- ECU가 늘어날수록 전선 수가 급격히 증가한다
- 전선은 부피와 무게를 가지므로 차량 무게와 원가에 영향을 준다
- 커넥터와 핀 수가 늘어나 하드웨어 설계가 어려워진다
- 새 ECU를 추가할 때 기존 ECU의 하드웨어와 소프트웨어를 다시 바꿔야 할 수 있다
- 어떤 선이 어떤 ECU와 연결되는지 관리하기 어려워진다
자동차에서는 무게가 연비, 전비, 원가, 조립성에 직접 연결된다.
그래서 통신 구조도 "잘 보내기"만이 아니라 "배선을 줄이고 확장하기 쉽게 만들기"가 중요하다.
3. CAN은 버스형 토폴로지를 사용한다
CAN(Controller Area Network)은 ECU끼리 통신하기 위해 만들어진 차량 통신 방식이다.
이름 자체가 제어기(Controller)들이 통신하는 네트워크라는 뜻에 가깝다.
CAN의 대표적인 구조적 특징은 버스형 토폴로지다.
버스형 토폴로지에서는 ECU끼리 서로 직접 전부 연결하지 않는다.
대신 가운데 공통선인 CAN Bus를 두고, 각 ECU가 그 버스에 붙는다.
이 구조의 장점은 분명하다.
- ECU를 추가할 때 공통 버스에 연결하면 된다
- 배선이 단순해진다
- ECU 하나를 제거해도 다른 ECU들의 기본 연결 구조가 크게 흔들리지 않는다
- 진단 장비를 버스에 연결하면 여러 ECU와 통신할 수 있다
4. CAN은 브로드캐스트 방식으로 메시지를 보낸다
CAN에서는 어떤 ECU가 메시지를 보내면 그 메시지는 버스에 연결된 모든 ECU에게 전달된다.
이것을 브로드캐스트(Broadcast) 방식이라고 한다.
브로드캐스트는 처음에는 비효율적으로 보일 수 있다.
특정 ECU 하나에게만 보내고 싶은데 모든 ECU가 받기 때문이다.
하지만 차량 개발에서는 이 방식이 오히려 편리하다.
- 어떤 ECU가 같은 정보를 추가로 필요로 해도 송신 ECU를 크게 바꾸지 않아도 된다
- 수신 ECU는 메시지 ID를 보고 필요한 메시지만 골라 쓰면 된다
- 진단기나 계측 장비도 버스에 연결하면 전체 메시지를 관찰할 수 있다
핵심은 보내는 쪽이 목적지를 세밀하게 지정하는 방식이 아니라, 받는 쪽이 필요한 메시지를 선택하는 방식이라는 점이다.
5. 메시지 ID가 메시지의 의미를 구분한다
CAN 메시지에는 "이 메시지가 무엇인지"를 나타내는 ID가 들어간다.
이 ID가 IP 주소처럼 목적지를 나타내는 것은 아니다. CAN 메시지 ID는 주로 메시지의 종류와 우선순위를 나타낸다.
예를 들어 OEM이 다음과 같은 표를 만들었다고 해보자.
| CAN ID | 메시지 이름 | 송신 ECU | 주요 신호 |
|---|---|---|---|
0x123 | BatteryStatus | BMS | 배터리 전압, 충전량, 허용 전류 |
0x134 | EngineStatus | 엔진 ECU | RPM, 냉각수 온도 |
0x154 | AirbagStatus | 에어백 ECU | 에어백 상태, 충돌 감지 상태 |
BMS는 0x123 ID를 가진 메시지에 배터리 상태를 담아 주기적으로 보낸다.
다른 ECU는 이 메시지를 받으면 ID를 확인하고, 자신에게 필요한 정보라면 데이터 영역을 해석한다.
6. CAN DB는 협업을 위한 약속표다
CAN 통신에서는 메시지 ID만으로는 충분하지 않다.
ID가 0x123이라는 사실만 알아서는 데이터 영역의 어느 비트가 배터리 전압이고, 어느 비트가 배터리 충전량인지 알 수 없다.
그래서 차량 프로젝트에서는 보통 CAN DB 또는 Communication Matrix가 필요하다.
CAN DB에는 다음 정보가 들어간다.
| 정보 | 예시 |
|---|---|
| 네트워크에 참여하는 ECU 목록 | BMS, Engine ECU, Cluster ECU |
| 메시지 ID | 0x123, 0x134 |
| 메시지 이름 | BatteryStatus |
| 송신 ECU | BMS |
| 수신 ECU | Cluster, Airbag |
| 주기 | 10ms, 100ms |
| 데이터 길이 | 4byte, 8byte |
| Signal 배치 | start bit, length |
| 물리값 변환 | factor, offset, unit |
CAN DB는 기술적으로 CAN 프로토콜 그 자체는 아니다.
하지만 실제 개발에서는 CAN DB가 없으면 서로 같은 메시지를 같은 의미로 해석할 수 없다.
핵심 직관: CAN 프로토콜은 "어떻게 보낼지"를 정하고, CAN DB는 "무엇을 어떤 의미로 해석할지"를 정한다.
7. 진단 커넥터도 CAN 버스에 붙는다
정비소나 개발실에서 진단기를 차량에 연결하면, 진단기는 차량 내부의 여러 ECU와 통신할 수 있다.
이것이 가능한 이유는 진단 커넥터가 CAN 버스에 연결되어 있기 때문이다.
진단기는 별도의 선을 ECU마다 하나씩 꽂지 않는다.
진단 커넥터를 통해 CAN 버스에 참여하고, 정해진 ID와 데이터 포맷으로 각 ECU에게 요청을 보낸다.
뒤에서 볼 UDS 진단통신은 바로 이 CAN 네트워크 위에서 자주 사용된다.
핵심 정리
- 차량에는 여러 ECU가 있고, ECU들은 서로 상태 정보를 주고받아야 한다.
- ECU끼리 모두 직접 연결하는 점대점 방식은 배선, 무게, 확장성 측면에서 불리하다.
- CAN은 공통 버스에 여러 ECU가 붙는 버스형 토폴로지를 사용한다.
- CAN 메시지는 브로드캐스트 방식으로 전체 네트워크에 전달되고, 수신 ECU가 필요한 메시지만 선택한다.
- CAN ID와 CAN DB는 차량 프로젝트에서 메시지 의미를 공유하는 핵심 약속이다.
- 진단기는 CAN 버스에 붙어 여러 ECU와 통신할 수 있고, 이 구조 위에서 UDS 진단통신이 동작한다.
확인 질문
- 점대점 배선 방식은 ECU가 늘어날 때 어떤 문제가 생기는가?
- CAN에서 메시지를 보내면 왜 모든 ECU가 그 메시지를 받는가?
- CAN ID가 목적지 주소와 다르다는 말은 무슨 뜻인가?
- CAN DB가 없다면 수신 ECU는 어떤 정보를 알 수 없는가?