CAN 통신 실전 입문 — 이론부터 Vector 드라이버 설정까지

# UDS 진단 프로토콜 — CAN 위에서 ECU를 제어하는 방법

## 진단 통신이란

CAN 버스로 엔진 RPM을 읽고 센서 값을 전송하는 것은 **기능 통신**이다. 차량이 실제로 주행하며 ECU끼리 주고받는 데이터다.

**진단 통신**은 다르다. 공장 출하 전 검사, 정비소에서의 고장코드 조회, 펌웨어 업데이트, ECU 초기화 등 — 대부분 차가 멈춰있는 상태에서 외부 도구(tester)가 ECU에 명령을 보내는 방식이다.

**UDS(Unified Diagnostic Services, ISO 14229)**는 이 진단 통신의 국제 표준이다. 거의 모든 자동차 OEM에서 채택한다.

## ISO-TP — CAN 8바이트 한계 넘기

UDS 메시지는 8바이트를 넘는 경우가 많다. 예를 들어 펌웨어 이미지는 수백 KB다. CAN 프레임의 최대 페이로드는 8바이트인데, 어떻게 큰 데이터를 전송하는가?

답은 **ISO-TP(ISO 15765-2)**다. ISO-TP는 여러 CAN 프레임을 이어 붙여 최대 4095바이트(CAN FD는 더 큼)를 하나의 메시지처럼 전송하는 전송 레이어다.

```
ISO-TP 프레임 타입:
┌──────────────┬──────────────────────────────────────┐
│ Single Frame │ 7바이트 이하 데이터 → 한 프레임으로 전송     │
│ First Frame  │ 긴 메시지의 첫 프레임 (총 길이 포함)       │
│ Consecutive Frame │ First Frame 이후의 연속 프레임        │
│ Flow Control │ 수신 측이 "계속 보내도 돼" 허가 신호       │
└──────────────┴──────────────────────────────────────┘
```

```
Tester                     ECU
  │──── First Frame ──────────→│  (총 길이 = 100바이트)
  │←─── Flow Control ──────────│  ("보내도 돼, 블록 크기 = 10")
  │──── Consecutive Frame 1 ──→│
  │──── Consecutive Frame 2 ──→│
  ...
  │──── Consecutive Frame N ──→│
```

## UDS 서비스 구조

UDS는 **서비스(Service)**와 **응답(Response)** 쌍으로 동작한다.

요청 메시지: `[Service ID] [Sub-function 또는 파라미터]`
성공 응답: `[0x40 + Service ID] [데이터]`
실패 응답: `[0x7F] [Service ID] [NRC(Negative Response Code)]`

주요 서비스 목록:

| Service ID | 이름 | 용도 |
|-----------|------|------|
| `0x10` | DiagnosticSessionControl | 진단 세션 전환 (Default ↔ Extended ↔ Programming) |
| `0x11` | ECUReset | ECU 강제 리셋 |
| `0x14` | ClearDiagnosticInformation | DTC(Fault Code) 삭제 |
| `0x19` | ReadDTCInformation | DTC 조회 |
| `0x22` | ReadDataByIdentifier | DID 기반 데이터 읽기 |
| `0x2E` | WriteDataByIdentifier | DID 기반 데이터 쓰기 |
| `0x27` | SecurityAccess | 보안 잠금 해제 (Seed/Key) |
| `0x31` | RoutineControl | 특정 루틴 실행 (예: 자가 진단) |
| `0x34/0x36/0x37` | RequestDownload/TransferData/RequestTransferExit | 펌웨어 다운로드 |

## ReadDataByIdentifier (0x22) 예시

가장 자주 쓰이는 서비스 중 하나다. 특정 DID(Data Identifier)에 해당하는 데이터를 읽는다.

```
요청: 0x22 0xF1 0x90
→ Service=0x22, DID=0xF190 (VIN, 차대번호)

응답 (성공): 0x62 0xF1 0x90 + 17바이트 VIN 데이터
            ↑ 0x40 + 0x22 = 0x62 (Positive Response)

응답 (실패): 0x7F 0x22 0x31
            ↑ NRC 0x31 = requestOutOfRange (DID 없음)
```

## SecurityAccess (0x27) — 보안 잠금

보안이 필요한 서비스(예: 펌웨어 업데이트, 교정값 쓰기) 전에 반드시 SecurityAccess를 통과해야 한다. Seed/Key 방식으로 동작한다.

```
Tester                     ECU
  │── 0x27 0x01 ─────────────→│  ("Seed 줘")
  │←── 0x67 0x01 + Seed ───────│  (4바이트 랜덤 Seed)
  
  [Tester가 Key 계산: Key = f(Seed, SecretAlgorithm)]
  
  │── 0x27 0x02 + Key ─────────→│  ("Key 여기 있어")
  │←── 0x67 0x02 ────────────────│  (잠금 해제 성공)
```

Key 계산 알고리즘은 OEM마다 다르고 비공개인 경우가 많다. 이 알고리즘이 알려지면 누구든 ECU를 재프로그래밍할 수 있어 보안 위협이 된다.

## DTC — 고장코드 체계

DTC(Diagnostic Trouble Code)는 ECU가 이상을 감지했을 때 저장하는 고장코드다. `P0300`처럼 영문자 + 숫자 형태로 정의되어 있다.

| 첫 글자 | 분류 |
|--------|------|
| P | Powertrain (엔진·변속기) |
| C | Chassis (제동·조향·서스펜션) |
| B | Body (에어백·에어컨·도어) |
| U | Network (CAN 통신 관련) |

`0x19 0x02 0xFF`(ReadDTCInformation, reportDTCByStatusMask, 전체)를 보내면 현재 저장된 모든 DTC를 반환한다.

## CANoe에서 UDS 테스트

CANoe의 **Diagnostic Console** 또는 **CAPL 스크립트**로 UDS 요청을 보내고 응답을 분석할 수 있다. DBC 파일과 별도로 **ODX/PDX 파일**이 있으면 서비스 정의가 자동으로 적용되어 훨씬 편리하게 진단 통신을 테스트할 수 있다.

---

이 시리즈는 CAN 통신의 물리 레이어(트랜시버, 버스 구조)에서 시작해 Bit Timing, 하드웨어 필터, PC 드라이버 설정, DBC 기반 신호 해석, UDS 진단 프로토콜까지 한 흐름으로 연결했다. CAN 하나를 제대로 이해하면 LIN, CAN FD, Automotive Ethernet으로 확장하는 것도 같은 방식으로 접근할 수 있다.

UDS 진단 프로토콜 — CAN 위에서 ECU를 제어하는 방법

// COMMENTS

ON THIS PAGE