ISO-TP : CAN으로 큰 데이터를 보내는 방법

자동차 통신 프로토콜 5부: ISO-TP – CAN으로 큰 데이터를 보내는 방법

ISO-TP란?

---

들어가며

오늘은 CAN통신에서 데이터를 보내는 방법에 대해 알아볼텐데요
프레임이 긴~~~ (Multi) 데이터를 보내려면 어떻게 해야할까요?
'맞아 ?' -> '응', '아니' 정도의 말만 하다가 이제는 "내 주소는 서울특별시 관악구야"와 같은 긴 말을 하고 싶거든요
그럴 때 사용하는게 ISO-TP라고 비유할 수 있을것 같아요
제가 TP로 인해서 고생을 많이 했던 경험이 있어요
진단기 한테 First Frame을 받고 Flow Control을 응답하지 않아 Second Frame을 송신하지 않았고,
그로 인해 TimeOut되는 현상으로 인해 애를 먹었던 적이 있습니다
hardConding을 하는 과정에서 휴먼에러였죠 ....
위 내용이 이해가 잘 안 가신다면 오늘 공부를 통해 이해하는 시간을 가져보겠습니다.

 

자동차 정비소 진단기가 당신의 차에 연결됐다.

진단기: "엔진 데이터 1000바이트 달라!"

ECU: "어? CAN은 8바이트만 보낼 수 있는데?"

진단기: "1000바이트를 분할해서 보내면 되지!"

ECU: "어떻게? 누가 분할하고 조합해?"

진단기: "ISO-TP가 자동으로 해 줄게"

그리고 자동으로 1000바이트가 전송되었다.

흐름:
1000바이트 데이터
    ↓
ISO-TP가 8바이트씩 분할 (125개 프레임)
    ↓
CAN으로 125번 전송
    ↓
수신 측이 125개를 다시 조합
    ↓
1000바이트 복원

모든 게 투명하게 처리됨!

CAN은 최대 8바이트만 송신 가능하다. 하지만 실무에서는 진단 데이터(1000바이트), 펌웨어 업데이트(10MB), 설정값 백업(수KB)처럼 큰 데이터를 자주 보낸다.

이 문제를 해결하는 게 ISO-TP (ISO 15765-2)다.

이 글에서는:

• CAN의 8바이트 제한과 실무 문제
• ISO-TP의 4가지 프레임 타입
• Segmentation (분할) 과정
• Flow Control (수신자 제어) 신호
• 실무 시나리오와 에러 처리

를 명확하게 설명한다.

---

3분 요약

바쁜 당신을 위한 핵심:

CAN 메시지 = 최대 8바이트 (0~7 인덱스)

ISO-TP = CAN을 이용한 "대용량 데이터 전송 프로토콜"

4가지 프레임 타입:

Single Frame: 8바이트 이하 (분할 필요 없음)
             [PCI 1바이트] [데이터 1~7바이트]

First Frame: 길고 데이터의 첫 부분
            [PCI 2바이트] [데이터 6바이트]
            (총 길이 정보 포함)

Consecutive Frame: 나머지 부분들
                  [PCI 1바이트] [데이터 7바이트]
                  (순서 번호 포함)

Flow Control Frame: 수신자가 "준비됐어?" 신호
                   [PCI 3바이트] [예약 5바이트]

Segmentation 과정:
1000바이트 데이터
    ↓
First Frame (6바이트 데이터)
Consecutive Frame x 142개 (7바이트씩)
    ↓
수신자: "Flow Control 보낼게"
    ↓
송신자: 계속 보냄
    ↓
1000바이트 완성!

Flow Control:
FS (Flow Status): Continue, Wait, Overflow
BS (Block Size): 한 번에 몇 개씩 받을 수 있나
STmin: Frame 사이의 최소 간격

---

CAN의 8바이트 제한

CAN 메시지 구조 복습

CAN 메시지:

SOF (1비트) → ID (11비트) → 제어 필드 → DLC → 데이터 (0~8바이트)

데이터 필드:

바이트 0: 0x??
바이트 1: 0x??
바이트 2: 0x??
바이트 3: 0x??
바이트 4: 0x??
바이트 5: 0x??
바이트 6: 0x??
바이트 7: 0x??

최대 8바이트 = 64비트

DLC (Data Length Code): 0~8 (몇 바이트인지 표시)

8바이트로는 부족한 실무 시나리오

1. 진단 데이터 요청

정비사: "엔진 상태 모든 정보 줘"
ECU: "RPM, 온도, 압력, 토크, 기어, 속도... 다 합치면 50바이트야"

CAN 8바이트로? 불가능!

2. 펌웨어 업데이트

기존: 2MB 펌웨어
CAN으로 전송하면: 2,000,000바이트 / 8 = 250,000번 전송 (?)
너무 오래 걸림!

3. 설정값 백업

사용자 설정: 밝기, 언어, 시트 위치, 거울 각도... = 1KB
CAN 8바이트로: 128번 메시지 필요

이 모든 게 자동으로 처리되려면?
ISO-TP의 도움이 필수!

---

ISO-TP (ISO 15765-2) 개요

정의

ISO-TP : Transport Protocol over CAN

[ Application (UDS) ]
        ↑
[ Transport Protocol (ISO-TP) ]  ← 이게 TP
        ↑
[ CAN ]

CAN은 기본적으로 데이터 최대 8바이트 (Classic CAN 기준)
근데 진단(UDS) 같은 건 20바이트 100바이트 수백 바이트의 데이터가 필요합니다
그럼 그 이상의 데이터는 어떻게 전송해야할까요
잘게 소분해서 통과시키는 겁니다

 

 

ISO-TP는 CAN 버스 위에서 대용량 데이터를 전송하기 위한 전송 계층 프로토콜이다.

ISO/OSI 모델에서의 위치:

계층 구조:

응용 계층 (UDS, 펌웨어 업데이트)
    ↑↓
전송 계층 (ISO-TP)  ← 여기!
    ↑↓
데이터 링크 계층 (CAN)
    ↑↓
물리 계층 (CAN 트랜시버)

ISO-TP의 역할:
- 큰 메시지를 8바이트씩 분할
- 분할된 메시지를 순서대로 전송
- 수신 측에서 다시 조합
- 송수신 제어 (Flow Control)

ISO-TP의 핵심 특징

투명성 (Transparency):
응용 프로그램은 몇 바이트든 보낼 수 있음
ISO-TP가 자동으로 8바이트씩 분할해서 CAN으로 전송

신뢰성:
Flow Control로 수신자의 준비 상태 확인
Timeout으로 전송 실패 감지

단순성:
응용 프로그램: Tp_Transmit(data, 1000) → 1000바이트 전송!
ISO-TP이 모든 복잡성 처리

---

ISO-TP의 4가지 프레임 타입

1. Single Frame (SF)

정의: 8바이트 이하의 데이터

구조:

바이트 0: PCI (Protocol Control Information)
         - 상위 4비트: SF 타입 (0000)
         - 하위 4비트: 데이터 길이 (1~7)

바이트 1~7: 데이터

예시:
데이터: "HI" (2바이트)

바이트 0: 0x02  (SF + 길이 2)
바이트 1: 'H'   (0x48)
바이트 2: 'I'   (0x49)
바이트 3~7: 패딩 또는 미사용

사용 케이스:
8바이트 이하 메시지는 Single Frame으로 한 번에 전송
First Frame 없이 바로 데이터 전송
Flow Control도 불필요

2. First Frame (FF)

정의: 긴 데이터의 시작 (항상 6바이트 데이터 포함)

구조:

바이트 0~1: PCI (2바이트)
           - 상위 4비트: FF 타입 (0001)
           - 하위 12비트: 총 데이터 길이

예: 0x10 0x64 → 길이 100바이트

바이트 2~7: 데이터의 첫 6바이트

예시:
데이터: 1000바이트

바이트 0~1: 0x03 0xE8 (FF + 길이 1000)
           (0x03 = 0000 0011, 상위 4비트 0001 = FF, 하위 12비트 11 1011 0000 = 1000)
바이트 2~7: 처음 6바이트

그 다음은 Consecutive Frame으로 나머지를 보냄

3. Consecutive Frame (CF)

정의: First Frame 이후의 나머지 데이터

구조:

바이트 0: PCI (1바이트)
         - 상위 4비트: CF 타입 (0010)
         - 하위 4비트: 순서 번호 (0~15, 그 다음 0~15, ...)

바이트 1~7: 데이터 7바이트

예시:
1000바이트 데이터를 보낼 때:
First Frame: 6바이트 (남은 데이터: 994바이트)
CF 1: 7바이트 (PCI 0x21) (남은 데이터: 987바이트)
CF 2: 7바이트 (PCI 0x22) (남은 데이터: 980바이트)
...
CF 142: 7바이트 (PCI 0x2E, 순서번호 14) (남은 데이터: 0바이트)

순서 번호:
0x20: 첫 번째 CF (순서번호 0)
0x21: 두 번째 CF (순서번호 1)
...
0x2F: 16번째 CF (순서번호 15)
0x20: 17번째 CF (순서번호 0, 다시 반복)

순서번호가 16 이상이 되면 다시 0부터 시작 (순환)

4. Flow Control Frame (FC)

정의: 수신자가 송신자에게 "준비 상태" 신호

구조:

바이트 0: PCI (1바이트)
         - 상위 4비트: FC 타입 (0011)
         - 하위 4비트: Flow Status (FS)

바이트 1: Block Size (BS)
         - 한 번에 받을 수 있는 Consecutive Frame 개수

바이트 2: Separation Time (STmin)
         - Frame 사이의 최소 시간 (ms)

바이트 3~7: 예약

Flow Status (FS):
0: ContinueToSend (계속 보내도 돼)
1: Wait (좀 기다려, 아직 준비 안 됨)
2: Overflow (너무 많아, 못 받겠어)

예시:
바이트 0: 0x30 (FC + FS=0 ContinueToSend)
바이트 1: 0x00 (BS=0, 제한 없음 - 계속 보내)
바이트 2: 0x00 (STmin=0, Frame 사이 시간 무제한)

다른 예:
바이트 0: 0x31 (FC + FS=1 Wait)
바이트 1: 0x10 (BS=16, 16개씩 쉬어가며 받음)
바이트 2: 0x0A (STmin=10ms, Frame 사이 최소 10ms)

---

ISO-TP Segmentation 과정 (단계별)

예시: 1000바이트 데이터 전송

송신자: "1000바이트 데이터를 보내고 싶어"
수신자: "준비됐어"

Step 1: First Frame 전송
─────────────────────────
송신자가 보낸 CAN 메시지:
CAN ID: 0x641 (송신 ID)
DLC: 8
데이터:
  바이트 0~1: 0x03 0xE8 (FF + 1000바이트)
  바이트 2~7: 첫 6바이트 데이터

수신자가 받은 것:
"아, 1000바이트가 올 거군. 준비해야겠다"
메모리 1000바이트 할당

타이밍: t=0ms

Step 2: 수신자가 Flow Control 보냄
─────────────────────────────────
수신자가 보낸 CAN 메시지:
CAN ID: 0x641 (수신자의 응답 ID, 송신자의 송신 ID와 다를 수 있음)
DLC: 8
데이터:
  바이트 0: 0x30 (FC + FS=0 ContinueToSend)
  바이트 1: 0x00 (BS=0, 제한 없음)
  바이트 2: 0x00 (STmin=0)
  바이트 3~7: 예약

타이밍: t=10ms

Step 3: Consecutive Frame 연속 전송
──────────────────────────────────
송신자가 보내는 CF들:

CF 1: (t=20ms)
  바이트 0: 0x21 (CF + 순서번호 1)
  바이트 1~7: 7바이트 데이터

CF 2: (t=30ms)
  바이트 0: 0x22 (CF + 순서번호 2)
  바이트 1~7: 7바이트 데이터

...

CF 142: (t=1430ms)
  바이트 0: 0x2E (CF + 순서번호 14)
  바이트 1~7: 마지막 6바이트 데이터

(6 + 7*142 = 1000바이트 정확히!)

Step 4: 수신자가 모든 데이터 수신 완료
──────────────────────────────────────
메모리에 1000바이트가 완성됨:
[6바이트 from FF] + [7바이트*142 from CF] = 1000바이트

응용 프로그램:
"ISO-TP 거 다 받았어? 1000바이트 데이터 줄래?"
ISO-TP: "여기 1000바이트!"

전송 완료!

메시지 흐름 요약:
시간      송신자              수신자
──────────────────────────────────
t=0ms    FF 전송 (6바이트)
                          FF 수신
                          ↓
         (수신자 준비)
                          FC 보냄
t=10ms                    (ContinueToSend)
         FC 수신
         ↓
t=20ms   CF 1 (7바이트)
t=30ms   CF 2 (7바이트)
         ...
t=1430ms CF 142 (6바이트)  ← 마지막
                          모든 CF 수신
                          ↓
                          1000바이트 조합 완료

---

Flow Control 상세 설명

Flow Control의 목적

상황: 고성능 송신자가 저성능 수신자에게 데이터를 보냄

송신자: "Consecutive Frame 보낼게! 매 10ms마다!"
수신자: "어? 내 버퍼가 너무 작아서 10ms 간격으로 못 받겠는데?"

해결: Flow Control로 송신 속도 제어

수신자: "정신 차려! 나는 50ms 간격으로만 받을 수 있어!"
송신자: "알겠어, 50ms 간격으로 보낼게"

Flow Control 파라미터

1. Block Size (BS)

정의: Flow Control 없이 연속으로 받을 수 있는 CF 개수

BS = 0: 무제한 (Flow Control 한 번만 보냄)
BS = 10: 10개 CF 받은 후 일시 중지, 또 FC 기다림

예:
BS = 5라면:
CF 1~5: 연속 전송
       수신자가 FC 다시 보냄 (대기 신호)
CF 6~10: 다시 전송
        수신자가 FC 다시 보냄
...

2. Separation Time (STmin)

정의: Consecutive Frame 사이의 최소 간격

STmin = 0: Frame 사이 시간 제한 없음 (최대한 빠르게)
STmin = 10ms: 10ms 간격으로 CF 전송
STmin = 50ms: 50ms 간격으로 CF 전송 (느림)

용도:
느린 임베디드 시스템: STmin = 50ms
고속 시스템: STmin = 0

3. Flow Status (FS)

FS = 0 (ContinueToSend):
  "계속 보내도 돼, 준비됐어"

FS = 1 (Wait):
  "지금 좀 기다려, 아직 준비 안 됐어"
  송신자는 이 FC를 받으면 대기
  수신자가 다시 FS=0 FC를 보낼 때까지

FS = 2 (Overflow):
  "너무 많이 보냈어, 처리 못해!"
  전송 중단 (에러 상황)

Flow Control 예시 (BS와 STmin)

예시 1: 빠른 전송 (제한 없음)

FC: FS=0, BS=0, STmin=0

송신 과정:
t=0ms:     FF 전송
t=10ms:    CF 1, CF 2, CF 3, ... (연속)
t=10.1ms:  CF 4, CF 5, CF 6, ...
t=10.2ms:  ...

결과: 가장 빠른 전송 (최대 1000+ CF/초)


예시 2: 느린 수신자

FC: FS=0, BS=5, STmin=10ms

송신 과정:
t=0ms:     FF 전송
t=10ms:    CF 1 전송
t=20ms:    CF 2 전송
t=30ms:    CF 3 전송
t=40ms:    CF 4 전송
t=50ms:    CF 5 전송
           [대기, 5개 다 받을 때까지]
t=50ms:    수신자가 FC 다시 보냄 (FS=0, BS=5)
t=60ms:    CF 6 전송
t=70ms:    CF 7 전송
           ...

결과: 10ms 간격, 5개씩 쉼

한 사이클:
- 5개 CF 전송: 5 * 10ms = 50ms
- 수신자 처리: 10ms
- 다음 FC 대기: 10ms
- 총: 70ms 사이클


예시 3: Wait 신호 (대기)

FC: FS=1, BS=0, STmin=0 (수신자가 아직 준비 안 됨)

송신 과정:
t=0ms:     FF 전송
t=10ms:    FC 수신 (FS=1 Wait)
           송신자 일시 중지
t=100ms:   FC 다시 수신 (FS=0 ContinueToSend)
           송신자 재개
t=110ms:   CF 1 전송
           ...

결과: 100ms 대기 후 계속 전송

---

실무 시나리오

시나리오 1: 진단기가 ECU 데이터 요청

상황:
- 정비소 진단기가 ECU에 연결
- 엔진 진단 데이터 500바이트 요청
- 통신: CAN ID 0x641 (ECU → 진단기)

Step 1: 진단기가 데이터 요청 (Single Frame)
────────────────────────────────────────
진단기 → ECU

CAN 메시지:
ID: 0x611 (진단기 → ECU)
DLC: 8
데이터:
  바이트 0: 0x02 (SF + 길이 2)
  바이트 1: 0x22 (ReadData 서비스)
  바이트 2: 0xF1 0x86 (EngineSpeed 데이터 ID)
  바이트 3~7: 예약

ECU 수신:
"아, 엔진 속도 데이터 달라고 하네"

Step 2: ECU가 데이터 준비
───────────────────
ECU 메모리에서:
- RPM, 온도, 압력, ... 총 500바이트 준비

Step 3: ECU가 First Frame 전송
────────────────────────────
ECU → 진단기

CAN 메시지:
ID: 0x641 (ECU → 진단기)
DLC: 8
데이터:
  바이트 0~1: 0x01 0xF4 (FF + 길이 500)
  바이트 2~7: 처음 6바이트 (RPM 고/저 바이트 + 온도 등)

진단기 수신:
"아, 500바이트가 올 거군. 메모리 할당해야겠다"

메모리: [6바이트 임시 저장]

Step 4: 진단기가 Flow Control 전송
──────────────────────────────────
진단기 → ECU

CAN 메시지:
ID: 0x611 (진단기 → ECU)
DLC: 8
데이터:
  바이트 0: 0x30 (FC + FS=0 ContinueToSend)
  바이트 1: 0x00 (BS=0, 제한 없음)
  바이트 2: 0x00 (STmin=0)
  바이트 3~7: 예약

ECU 수신:
"좋아, 계속 보낼게!"

Step 5: ECU가 Consecutive Frame 전송
──────────────────────────────────
ECU → 진단기

계산: 500바이트 = 6바이트(FF) + 7*63 + 1바이트(마지막)

CF 1: (t=10ms)
  바이트 0: 0x21 (CF + 순서번호 1)
  바이트 1~7: 7바이트 데이터

CF 2: (t=20ms)
  바이트 0: 0x22 (CF + 순서번호 2)
  바이트 1~7: 7바이트 데이터

...

CF 63: (t=630ms)
  바이트 0: 0x3F (CF + 순서번호 15)
  바이트 1~7: 7바이트 데이터

CF 64: (t=640ms)
  바이트 0: 0x20 (CF + 순서번호 0, 다시 반복 시작)
  바이트 1: 1바이트 데이터 (마지막)
  바이트 2~7: 패딩

Step 6: 진단기가 모든 데이터 수신
───────────────────────────────
메모리:
[6바이트 from FF] + [7*63바이트 from CF 1~63] + [1바이트 from CF 64]
= 6 + 441 + 1 = 448바이트? 아, 계산 다시.

500 = 6 + 7n + m
6 + 7*70 = 6 + 490 = 496
500 = 496 + 4

CF 1~70: 7바이트씩 = 490바이트
마지막 CF 71: 4바이트 데이터 + 4바이트 패딩

Step 7: 데이터 처리
──────
진단기: "500바이트 엔진 데이터 받았다!"
- RPM 2800
- 온도 85도
- 압력 3.0 Bar
- ...

표시: 정비소 모니터에 모든 데이터 표시

타이밍:
t=0ms: FF 전송
t=10ms: FC 수신
t=20ms: CF 1 시작
t=710ms: CF 71 완료 (마지막)
t=720ms: 데이터 처리 완료

총 소요 시간: 720ms

시나리오 2: 펌웨어 업데이트 (대용량)

상황:
- 정비소에서 ECU 펌웨어 업데이트
- 펌웨어 크기: 100KB = 100,000바이트
- CAN 속도: 500kbps (전송 속도 제한)

문제점:
100,000바이트 / 8 = 12,500 CAN 메시지
각 메시지 130μs (CAN 전송 시간)
총 시간: 12,500 * 130μs = 1.625초

아니다, Consecutive Frame 간격도 고려하면:
STmin = 10ms로 설정 시
총 시간: 12,500 * 10ms = 125초 (2분!)

최적화:

Step 1: 송신자가 First Frame 전송
────────────────────────────────
CAN 메시지:
  바이트 0~1: 0x01 0x86 0xA0 (FF + 100,000)
  바이트 2~7: 펌웨어 첫 6바이트

Step 2: 수신자 (ECU)가 Flow Control 응답
──────────────────────────────────────
CAN 메시지:
  바이트 0: 0x30 (FC + FS=0)
  바이트 1: 0x10 (BS=16, 16개씩 쉬어가며)
  바이트 2: 0x05 (STmin=5ms, 빠르게 보내)

송신자: "16개씩 받겠고, 5ms 간격이군"

Step 3: Consecutive Frame 연속 전송
───────────────────────────────────
펌웨어: 6 + 7n
100,000 = 6 + 7n
n = (100,000 - 6) / 7 = 13,998.28 → 13,999개

CF 1~16: 전송
         (수신자가 16개 받을 때까지 기다림)
FC 다시 받음
CF 17~32: 전송
FC 다시 받음
...
CF 13,983~13,999: 전송
(마지막 CF는 일부 패딩)

Step 4: 수신 측 처리
──────────────────
Flash 메모리에 쓰기:
- 각 Consecutive Frame을 받을 때마다 Flash 메모리에 기록
- Flash 쓰기 속도: 초당 100KB (예)
- 100,000바이트 / 100KB = 1초

총 소요 시간:
전송 시간: 13,999 * 5ms (STmin) ≈ 70초
Flash 쓰기: 병렬로 진행 (추가 1초)
= 약 71초 (1분 11초)

최적화 (더 빠르게):
STmin = 0 (제한 없음)
BS = 0 (Flow Control 한 번)

전송 시간: 최대 1KB/ms = 100ms (빠름!)
Flash 쓰기: 1초
= 약 1.1초

하지만 주의:
Flash 쓰기 속도가 느리면 Flow Control로 속도 조절 필수
아니면 ECU 버퍼 오버플로우 → 업데이트 실패!

시나리오 3: Flow Control로 속도 조절

상황:
- 송신자: 고성능 (매 10ms마다 CF 전송 가능)
- 수신자: 저성능 (매 50ms마다만 처리 가능)

문제:
송신자가 50ms 안에 5개 CF를 보냄
하지만 수신자는 첫 번째 CF를 아직 처리 중

결과: 수신자 버퍼 오버플로우 → 데이터 손상!

해결: Flow Control

Step 1: FF 수신 후 수신자가 FC 전송
───────────────────────────────
FC:
  FS=0 (계속 보내도 돼)
  BS=1 (1개씩만 받겠어)
  STmin=50ms (50ms 간격으로)

Step 2: 송신자가 CF 전송
──────────────────────
CF 1: t=0ms
      (수신자가 처리할 때까지 기다림)
      50ms 경과

FC 다시 받음:
  BS=1 (또 1개)

CF 2: t=50ms
      (또 50ms 대기)

CF 3: t=100ms
...

결과:
- 각 CF가 수신자에게 완전히 처리될 시간 제공
- 버퍼 오버플로우 없음
- 안정적인 전송

대신:
- 전송 시간이 길어짐 (CF 개수 * 50ms)
- 하지만 신뢰성이 최우선!

---

에러 처리

에러 상황 1: Timeout (응답 없음)

상황:
송신자가 First Frame을 보냈는데 Flow Control이 안 옴

Step 1: FF 전송
─────────────
t=0ms: FF 전송

Step 2: FC 대기
────────────
t=10ms: FC 아직 안 옴 (수신자가 다운됨?)
t=50ms: FC 아직 안 옴
t=1000ms: Timeout! (보통 1초)

에러 처리:
송신자: "아, 수신자가 응답 없네"
→ ISO-TP 전송 실패 (에러 반환)
→ 응용 프로그램에 알림
→ 재시도하거나 사용자에게 에러 표시

실무:
"통신 오류: 진단기와 연결 불가능"

에러 상황 2: Unexpected Consecutive Frame

상황:
CF의 순서 번호가 예상과 다름

예상:
CF 순서: 1, 2, 3, 4, 5, ...

실제:
CF 1 수신 (OK)
CF 2 수신 (OK)
CF 4 수신 (어? CF 3은?)

에러 처리:
"이상한 순서 번호. 에러!"
→ ISO-TP 중단
→ 송신자가 타임아웃 (다시 FC 대기하다가 1초 후 실패)

해결:
송신자: "아, 데이터 손상됐어. 처음부터 다시!"
→ 전체 재전송

에러 상황 3: Flow Control Overflow

상황:
수신자가 버퍼를 다 찬다

Step 1: FF 전송 후 수신자가 메모리 할당
──────────────────────────────────
"1000바이트 메모리 할당"

Step 2: CF 받음
────────────
CF 1, 2, 3, ... 계속 받음

Step 3: 버퍼가 거의 찬다!
───────────────────
"어? 메모리가 부족해!"

Step 4: FC 다시 받으면
────────────────────
FC:
  FS=2 (Overflow!)
  "이제 못 받겠어!"

송신자 처리:
"아, Overflow. 전송 중단!"
→ 더 이상 CF 보내지 않음
→ ISO-TP 실패

원인:
- 수신자 메모리 부족
- 또는 수신 속도가 너무 느림

해결:
- 더 작은 메시지로 분할
- 또는 수신자 메모리 확장
- 또는 Flow Control로 속도 조절

---

면접 예상 질문

Q1: ISO-TP는 왜 필요한가?

A: CAN 메시지는 최대 8바이트만 전송 가능하다.
   하지만 실무에서는 진단 데이터(수KB), 펌웨어(수MB) 같은
   대용량 데이터를 자주 전송해야 한다.
   ISO-TP는 이런 큰 데이터를 8바이트씩 자동으로 분할해서
   전송하고, 수신 측에서 자동으로 조합해 준다.
   응용 프로그램은 몇 바이트든 투명하게 보낼 수 있다.


Q2: Single Frame과 First Frame의 차이는?

A: Single Frame은 8바이트 이하의 데이터를 한 번에 보낸다.
   First Frame은 8바이트를 초과하는 긴 데이터의 시작을 나타낸다.
   Single Frame은 최대 7바이트 데이터를 가지지만,
   First Frame은 6바이트 데이터만 가진다 (PCI 2바이트 사용).


Q3: Flow Control에서 BS (Block Size)와 STmin의 역할은?

A: BS는 Flow Control 없이 연속으로 받을 수 있는 CF 개수다.
   BS=0이면 무제한, BS=10이면 10개 CF를 받은 후 FC를 다시 기다린다.
   STmin은 CF 사이의 최소 시간 간격이다.
   STmin=0이면 제한 없고, STmin=50ms면 50ms 간격으로 보낸다.
   BS로 버스트(묶음) 제어, STmin으로 개별 프레임 속도 제어.


Q4: Consecutive Frame의 순서 번호는 최대 몇까지?

A: 순서 번호는 0~15 (4비트)다.
   16번째 CF 이후로는 0부터 다시 시작한다 (순환).
   그래서 같은 순서 번호가 반복될 수 있는데,
   이를 통해 순서를 추적한다.
   만약 예상과 다른 순서 번호가 오면 에러로 처리한다.


Q5: Flow Control FS=1 (Wait)는 언제 쓸까?

A: 수신자가 아직 준비되지 않았을 때 사용한다.
   예를 들어, 수신자가 이전 데이터를 처리 중이어서
   새 데이터를 받을 수 없을 때 FS=1로 송신자에게
   "좀 기다려"라는 신호를 보낸다.
   송신자는 FS=0을 받을 때까지 CF를 보내지 않는다.

---

핵심 정리

ISO-TP:

• CAN 위의 전송 계층 프로토콜
• 8바이트 제한을 극복해서 대용량 데이터 전송 가능
• 응용 프로그램에 투명 (크기 제한 없음)

4가지 프레임:

• Single Frame: 8바이트 이하 (한 번에 전송)
• First Frame: 긴 데이터의 시작 (6바이트 데이터 + 총 길이)
• Consecutive Frame: 나머지 데이터 (7바이트씩, 순서 번호 포함)
• Flow Control: 수신자의 준비 상태 신호

Segmentation:

• 송신자가 큰 데이터를 8바이트씩 분할
• 각 프레임이 CAN으로 전송
• 수신자가 다시 조합

Flow Control 파라미터:

• FS (Flow Status): Continue/Wait/Overflow
• BS (Block Size): CF 개수 제한
• STmin (Separation Time): CF 사이 최소 시간

에러 처리:

• Timeout: FC가 오지 않음 (1초)
• Unexpected CF: 순서 번호 오류
• Overflow: 수신자 버퍼 부족