CAN 데이터 프레임

1. 프레임의 종류

CAN 버스 위를 오가는 메시지는 목적에 따라 4가지 종류로 나뉜다.

비유로 이해하기

CAN 버스를 무전기 채널이라고 생각해보자.

• 데이터 프레임: "본부, 현재 위치 좌표는 37.5°N, 127.0°E이다." — 실제 정보 전달
• 리모트 프레임: "본부, 현재 온도 데이터 좀 보내달라." — 데이터 요청
• 에러 프레임: "잠깐! 방금 전송에 오류가 있었다!" — 오류 신호
• 오버로드 프레임: "지금 처리 중이다, 잠깐만." — 전송 지연 요청

2. 데이터 프레임 필드 해부

데이터 프레임은 여러 필드로 구성되며, 각각 정해진 역할이 있다.

packet-beta
title CAN Standard Data Frame (2.0A)
0: "SOF"
1-11: "Identifier (11bit)"
12: "RTR"
13: "IDE"
14: "r0"
15-18: "DLC (4bit)"
19-82: "Data (0~64bit)"
83-97: "CRC (15bit)"
98: "CRC Del"
99: "ACK Slot"
100: "ACK Del"
101-107: "EOF (7bit)"

각 필드를 순서대로 살펴보자.

3. Standard(11bit) vs Extended(29bit)

CAN 2.0A는 11bit Identifier를, CAN 2.0B는 29bit Identifier를 사용한다. ISOBUS(ISO 11783)는 29bit Extended ID를 기반으로 한다.

packet-beta
title CAN Extended Data Frame (2.0B) — 29bit ID
0: "SOF"
1-11: "Base ID (11bit)"
12: "SRR"
13: "IDE=1"
14-31: "Extended ID (18bit)"
32: "RTR"
33: "r1"
34: "r0"
35-38: "DLC (4bit)"
39-102: "Data (0~64bit)"
103-117: "CRC (15bit)"
118: "CRC Del"
119: "ACK"
120: "ACK Del"
121-127: "EOF (7bit)"

Standard와 Extended의 차이

Extended 프레임에서 추가된 필드:

• SRR (Substitute Remote Request): Standard 프레임의 RTR 위치에 들어가는 Recessive 비트. Extended 프레임에서 항상 1
• 18bit Extension: Base ID(11bit) 뒤에 붙는 추가 18bit로 총 29bit ID를 구성

프레임의 구조를 알았으니, 이 프레임이 버스 위를 실제로 이동할 때 적용되는 중요한 전송 규칙을 하나 살펴보자.

4. 비트 스터핑(Bit Stuffing)

왜 필요한가?

CAN은 클럭 신호 없이 데이터 신호만으로 통신한다. 수신 노드는 신호의 변화(0→1 또는 1→0)를 감지해 동기화를 유지한다. 그런데 같은 값이 너무 오래 연속되면 동기화 기준점을 잃어버릴 수 있다.

동작 방식

같은 값의 비트가 5개 연속 나타나면, 다음에 반드시 반대 값의 비트를 1개 삽입한다. 이 삽입된 비트를 Stuff Bit이라 한다.

원본 비트열: 1 1 1 1 1 0 0 0 0 0 1
                              ↑
                   5개 연속 1 뒤에 0 삽입됨

스터핑 후:  1 1 1 1 1 [0] 0 0 0 0 0 [1] 1
                       ↑             ↑
                   Stuff Bit      Stuff Bit

수신측 처리: 수신 노드는 5개 연속 비트 뒤에 오는 비트를 자동으로 제거(Destuffing)하여 원래 데이터를 복원한다.

5. DLC와 데이터 길이

DLC(Data Length Code)는 4비트 필드로, 데이터 필드에 실제로 몇 바이트의 데이터가 있는지 알려준다.

이제 프레임의 모든 구성 요소를 알았다. 실제 CAN 로그를 보면서 직접 파싱해보자.

6. 프레임 읽기 실습

실제 CAN 로그에서 자주 보이는 형식을 파싱해보자.

로그 예시

0CF004FE#FF3C320000FFFF00

이 형식은 [CAN ID]#[Data] 구조다.

CRC, ACK, EOF는 어디에?

프레임 구조에는 SOF, CRC, ACK, EOF 등이 있는데 로그에는 ID와 Data만 보인다. 이유는 하드웨어(CAN 컨트롤러)가 자동으로 처리하는 영역과 소프트웨어가 다루는 영역이 나뉘기 때문이다.

CAN 컨트롤러 칩이 프레임을 보낼 때 CRC를 자동 계산해서 붙이고, 받을 때 자동 검증한다. CRC가 틀리면 에러 프레임을 전송하고, 맞으면 ACK를 보낸다. 이 과정이 전부 하드웨어에서 끝나기 때문에, 소프트웨어에는 검증을 통과한 ID + DLC + Data만 올라온다.

0CF004FE#FF3C320000FFFF00
^^^^^^^^ ^^^^^^^^^^^^^^^^
  ID만     Data만

CRC가 틀린 프레임은 애초에 소프트웨어까지 도달하지 않는다. 하드웨어 단에서 폐기된다.

파싱 과정

원본: 0CF004FE#FF3C320000FFFF00
       ↓
CAN ID: 0CF004FE (16진수 8자리 = 29bit Extended ID)
Data  : FF 3C 32 00 00 FF FF 00

CAN ID 분해 (ISOBUS PGN 구조)

0C F0 04 FE  →  이진수로 변환
= 0000 1100  1111 0000  0000 0100  1111 1110

29bit ID (Extended):
  Priority  : 000 (3bit)       → 우선순위 0
  Reserved  : 0 (1bit)
  Data Page : 0 (1bit)
  PGN       : F004 (16진수)    → PGN = 61444 (EEC1, 엔진 속도)
  Source Addr: FE (16진수)     → 소스 주소 254

Data 필드 해석

Data (8바이트): FF 3C 32 00 00 FF FF 00

DLC = 8 (데이터 8바이트)

PGN F004 (EEC1) 기준 해석:
  Byte 0 (FF): Engine Torque Mode — 0xFF = 데이터 없음
  Byte 1 (3C): Driver's Demand Torque — 0x3C = 60 (offset -125 → -65%)
  Byte 2 (32): Actual Engine Torque  — 0x32 = 50 (offset -125 → -75%)
  Byte 3-4 (0000): Engine Speed      — 0x0000 = 0 RPM
  Byte 5 (FF): Source Address — 0xFF = 데이터 없음
  Byte 6 (FF): Engine Demand Torque — 0xFF = 데이터 없음
  Byte 7 (00): Reserved

flowchart LR
    A["CAN 로그<br>0CF004FE#FF3C320000FFFF00"]
    A --> B["CAN ID<br>0x0CF004FE"]
    A --> C["Data<br>FF 3C 32 00 00 FF FF 00"]

    B --> D["Priority: 3<br>(상위 3bit)"]
    B --> E["PGN: 0xF004<br>= EEC1 엔진 속도"]
    B --> F["Source: 0xFE<br>= 주소 254"]

    C --> G["Byte 0-1: 토크 정보"]
    C --> H["Byte 2-3: 엔진 RPM"]
    C --> I["Byte 4-7: 기타"]

다음 챕터

• 다음 : CAN 중재와 우선순위