CAN(Controller Area Network) 통신
차량 내에서 호스트 컴퓨터 없이 마이크로 컨트롤러나 장치들이 서로 통신하기 위해 설계된 표준 통신 규격.
- 메시지 기반 프로토콜
→ 데이터를 보낼 때 장치 주소(누가 누구에게 보냄?)를 기준으로 삼지 않고, 메시지 자체의 의미(데이터 내용)를 기준으로 통신하는 방식
→ 차량 뿐만 아니라 산업용 자동화기기나 의료용 장비에서도 사용됨
- non-host 버스 방식의 메시지 기반 네트워크 프로토콜
→ Host 없이 데이터를 보낼 때 장치 주소를 기준으로 삼지 않고, 메시지 자체의 의미를 기준으로 통신하는 방식
→ 1983년 최초로 Bosch社에 의해 개발됨 (HTTP보다 먼저 만들어진 프로토콜)
→ 현재 생산되는 대부분의 자동차에서 사용되고 있음
신호를 주는 방식
CAN 네트워크 선에는 평소에 전류가 잔잔하게 흐르고 있다. 이때 신호를 주는 방식은 두가지
- Recessive (열세/약한 상태) = 숫자 1
- Dominant (우세/강한 상태) = 숫자 0
1단계(SOF 단계) : ECU 3이 신호를 0으로 바꾼다
- 그 순간, ECU 1,2는 해당 신호를 감지하고 각자 내부 시계를 0.000초로 리셋(동기화)한다.
2단계(ID 중재) : ID 비트를 순차적으로 전송
- ECU 1,2는 보낼 데이터가 없으므로 버스를 1상태로 유휴(Idle) 유지
- ECU 3은 자기 데이터의 이름표(ID) 비트를 하나씩 전송
- 해당 ID는 데이터의 종류 식별, 우선순위를 결정하는 역할을 하므로 11비트 전체가 온전히 전송되어야 함
→ 그림의 경우, ECU 3만 데이터를 보내고 싶어하므로, 우위 경쟁이 없다.
- ECU 1, 2는 해당 ID를 보고, 필요 여부를 판단한다.
3단계(데이터 전송) : ECU 3의 데이터를 선에 태워 보낸다.
- 이미 2단계에서 필요 여부를 판단했더라도, 패킷 오류 검사(CRC)를 해야하므로 data를 끝까지 해석한다.
- 해석 후,
- 필요 없다! = 버린다 (필터링 탈락)
- 필요하다! = 해석 및 처리
CAN 통신을 사용하는 이유
배선(와이어)의 대폭적인 감소와 경량화
- CAN 통신이 없을 때: 부품이 늘어날수록 전선 뭉치(하네스)가 두꺼워져 차가 무거워지고 공간을 많이 차지했습니다.
- CAN 통신이 있을 때: 단 2줄의 버스 라인(CAN_H, CAN_L)만 깔아두고, 모든 부품을 이 선에 나란히 연결(공유)합니다. 전선 수가 획기적으로 줄어들어 차량 무게가 가벼워지고 제조 비용도 확 낮아진다.
→ non-host 방식 : Host 없음. 버스 라인에 연결된 모든 장치가 독립적인 지능을 가지고 있어서 우선순위에 따라 데이터를 전송함
- 멀티 마스터 : 버스에 연결된 모든 노드가 언제든 Host 역할을 할 수 있음
- 중재 및 우선순위 : 호스트가 순서를 정해주지 않으므로, 여러 노드가 동시에 데이터를 보낼 때 데이터 자체의 ID(우선순위)를 비교하여 하드웨어적으로 교통정리 함.
- 브로드캐스팅 : 버스 라인 전체에 데이터 전송 → 필요한 노드가 알아서 그 데이터를 가져감(캡쳐-Filtering)
→ host 방식 : 모든 통신 제어권이 중앙의 Host에 집중되어 있음
UDS
ECU와 대화하여 고장 진단 및 설정을 하기 위한 국제 표준 프로토콜. 주로 ECU에 사용되는 진단 통신에 사용된다. 고수준의 프로토콜이므로 데이터 R/W 같은 다양한 기능을 사용할 수 있다.
- 고장 코드 읽기
- 실시간 데이터 읽기
- 소프트에어 업데이트
→ 한 마디로 통합 진단 서비스
UDS 메시지 구조 (국제 표준)
Protocol Control Info (PCI) : 대용량 데이터를 처리하기 위한 제어 정보
→ 메시지가 단일 프레임(single frame)인지, 여러개로 쪼개지는 프레임의 시작(first frame)인지 알려주는 포장지 규격
SID : 진단 데이터의 문법과 알맹이는 무조건 이 형식을 따른다고 규정된 표준
- 이런 행위(서비스)를 할 것이라고 알려주는 식별자
- 요청할 때 SID 값에 +0x40의 값이 해당하는 응답 SID 값입니다
→ 요청 SID 값에 해당하는 응답 값인 RSID가 잘 수신이 되었으면, 통신이 잘 이루어진 것
Sub Function : SID 명령에 세부 옵션을 줄 때 사용
사용할 수도 있고 없을 수도 있음
Request Data : 명령을 수행하는 데 필요한 추가 매개변수
→ 실제 진단 명령의 문법(응용 계층)을 담당
예시) 1. Diagnostic Session Control (SID: 0x10)
진단 세션(모드)을 변경할 때 쓰는 서비스
- Sub-Function 예시:
- 0x01: Default Session (일반 모드)
- 0x02: Programming Session (ECU에 소프트웨어를 새로 구울 때 쓰는 모드)
- 0x03: Extended Diagnostic Session (더 깊은 진단을 할 때 쓰는 모드)
실제 패킷 예시 (Extended 모드로 변경 요청):
- [ 0x10 ] [ 0x03 ]
- 앞의 0x10은 "진단 세션 바꿀게!"(SID)이고, 뒤의 0x03이 "그중에서도 확장 모드로!"(Sub-Function)라는 뜻
padding
: 모든 프레임의 데이터를 합쳐도 8바이트가 안됐을 때 남는 빈 공간을 더미 데이터로 채워 넣도록 규정하는 규칙
+DID : 데이터 식별자
CAN ID : ECU의 물리적 주소/목적지 (송수신)
ISO 15765-4에 의해서 각 ECU에 대한 CAN ID 값이 16진수로 정해져 있음.
→ 7DF(전체 공지) : 주로 모든 ECU에 대한 브로드캐스트 또는 내부적인 기능이나 설정을 통해 ECU로 전달하는 식별자이다.
→ 7E0 ~ 7EF(각 컴퓨터 송신) :
→ 7E0(보통 엔진 ECU) : 진단기가 1번 컴퓨터에게 메시지 보낼 때 쓰는 주소
→ 7E1(보통 변속기 TCU) : 진단기가 2번 컴퓨터에게 메시지 보낼 때 쓰는 주소
→ 7E2(ABS 등) : 진단기가 3번 컴퓨터에게 메시지 보낼 때 쓰는 주소
== 이런 식으로 숫자가 하나씩 올라간다.
→ +0x8( ECU의 응답 주소) :ECU가 진단기에게 답장할 때, 그 주소는 받은 주소에 16진수로 8을 더한 값으로 한다는 규칙
예시)
진단기가 송신할 때 : 7E0
엔진이 답장을 수신할 때 : 7E0 + 8 = 7E9
관련 도구 - can-utils
리눅스에서 CAN 프로토콜을 구현한 SocketCAN 기반 도구.
candump
CAN/UDS 메시지를 수신 받을 수 있는 도구.
→ CAN 네트워크 선에 어떤 데이터들이 오가는지 몰래 도청해서 화면에 그대로 출력해주는 해킹/진단용 프로그램
예제 candump -a vcan0,7E0:7FF
- 노트북에 연결된 여러 개의 통신선(can0, can1, ….) 중에서 타겟선 선택
- -a 옵션으로, can 통신 데이터의 16진수 숫자를 ASCII로 번역해준다
- 추가 옵션 부여
- 7E0만 통과시키고 나머지는 다 차단 (돋보기 역할)
- 7FF는 그 돋보기의 정밀도를 나타내는 비트 격자(마스크) 정보
cansend
CAN/UDS 메시지를 송신할 수 있는 도구
→ 원하는 장비의 ID를 달고, 원하는 데이터를 적어서, 특정 네트워크 선에 강제로 주입하는 프로그램
→ UDS 포맷에 맞춰 SID, DID를 잘 구성하여 송신해야 함.
예제 cansend vcan0 7DF#0322F190 && cansend vcan0 7E0#30000000
- 7DF: 가상 네트워크(vcan0)에 있는 모든 ECU에게 전체 공지 (BroadCast ID)
- 03: 3바이트짜리 명령어를 보낼 것임을 암시
- 22: UDS 명령어 중, 데이터 읽는(Read Data By Identifier) SID
- F1 90: 그중에서도 VIN 번호(차량 고유 주민등록번호)를 읽는 하위 식별 번호(DID)
- 7E0 에 8byte만큼의 데이터를 받음
- 30000000 : Flow Control
→ 데이터가 8byte를 넘을 경우, 나머지 모든 데이터를 수신 받음
**** cansend로 전송한 메시지의 응답을, candump로 확인하며 CAN/UDS 통신 과정을 확인 할 수 있다!!