CAN Frame의 Data Field는 최대 8바이트로 제한된다. UDS 진단 서비스가 주고받는 dataRecord처럼 이 한도를 넘는 데이터를 보내려면 여러 CAN 프레임에 걸쳐 나눠 보내야 한다. 이 분할·재조립 절차를 규정하는 프로토콜이 ISO-TP(CAN Transport Protocol)이며, ISO 15765-2로 표준화되어 있다[1].
프레임 유형
ISO-TP는 프레임을 네 가지 유형으로 나눈다 — 데이터가 7바이트 이하로 한 프레임에 다 담기면 Single Frame(SF), 넘치면 첫 프레임인 First Frame(FF)과 이어지는 Consecutive Frame(CF)들로 나뉘며, 수신 측이 송신 속도를 제어하는 Flow Control(FC)이 별도로 오간다. 각 프레임의 유형은 Byte 1 상위 니블에 실리는 N_PCI(Network Protocol Control Information) 값으로 구분된다[1].
SF는 Byte 1 하위 니블의 SF_DL(데이터 길이)로 뒤따르는 데이터 길이를 밝히고, 그만큼(최대 7바이트)을 바로 담는다. FF는 Byte 1 하위 니블과 Byte 2 전체(12비트)를 합친 FF_DL로 전체 데이터 길이를 밝히고 첫 6바이트를 담으며, 나머지는 CF가 Byte 1 하위 니블의 SN(Sequence Number, 0~15를 순환)으로 순서를 표시하며 최대 7바이트씩 이어 나른다[1].
Flow Control
FC는 세 필드로 수신 측의 제어 의도를 표현한다 — Byte 1 하위 니블의 FS(Flow Status), Byte 2의 BS(Block Size), Byte 3의 STmin(Separation Time minimum)이다[1].
FS는 세 가지 값을 쓴다[1]:
| 값 | 이름 | 의미 |
|---|---|---|
| 0 | ContinueToSend(CTS) | 수신 측이 다음 Consecutive Frame들을 받을 준비가 됐다 — 송신 측은 전송을 재개한다 |
| 1 | Wait(WT) | 송신 측은 전송을 멈추고 새 Flow Control을 기다린다 — 이 응답에 실린 BS·STmin 값은 무시된다 |
| 2 | Overflow(OVFLW) | 수신 측 버퍼가 부족해 송신 측이 전송을 중단한다 — First Frame 직후에 오는 Flow Control에서만 허용된다 |
BS는 다음 Flow Control 없이 보낼 수 있는 Consecutive Frame 개수를 정한다 — 0이면 무제한(더 이상 Flow Control 없이 남은 프레임을 전부 보낼 수 있음), 1~255면 그 개수만큼 보낸 뒤 다시 Flow Control을 기다려야 한다. STmin은 연속된 Consecutive Frame 사이에 둬야 할 최소 간격을 인코딩한다[1]:
| 값(Hex) | 의미 |
|---|---|
| 0x00~0x7F | 0~127ms(값 1당 1ms) |
| 0x80~0xF0 | Reserved |
| 0xF1~0xF9 | 100~900us(값 1당 100us) |
| 0xFA~0xFF | Reserved |
다음은 30바이트 데이터를 BS=3, STmin=5ms로 나눠 보내는 예다. FF가 첫 6바이트를 실어 보내면, 수신 측이 FC(BS=3, STmin=5ms)로 응답한다. 송신 측은 이후 CF 세 개를 5ms 이상 간격으로 보내는데, BS로 정한 3개를 채웠으므로 남은 데이터가 있어도 다시 FC를 기다린 뒤에야 마지막 CF를 보낸다.
CF 세 개마다 BS만큼 채워 새 FC를 기다리는 이 주기는, 데이터가 모두 전달될 때까지 반복된다.