자동차 ECU는 정비소와 어떻게 대화할까? (UDS 진단 통신 쉽게 이해하기)

차량 진단 통신 시리즈 01

정비소에서 차를 맡기면 정비사가 노트북을 차에 연결합니다.
잠시 후 화면에 각종 수치와 오류 코드가 쭉 나열됩니다.

ECU가 몇 개인지, 어떤 센서가 이상한지, 언제 오류가 발생했는지까지.
정비사는 차와 대화하듯 정보를 꺼냅니다.

그런데 이 대화는 어떻게 이루어지는 걸까요?
ECU가 정비 장비의 질문을 어떻게 알아듣고, 어떻게 답하는 걸까요?

그 언어가 바로 UDS(Unified Diagnostic Services)입니다.

진단 통신이란 무엇인가

차량 진단 통신은 외부 장비(진단기, 테스터)가 차량 내부 ECU에 접근해 정보를 읽거나 특정 동작을 요청하는 통신입니다. 크게 세 가지 목적으로 사용됩니다.

목적	설명	예시
고장 진단	ECU에 저장된 오류 코드(DTC)를 읽어 문제 원인 파악	엔진 경고등 원인 확인
데이터 조회	실시간 센서값, 파라미터 읽기	엔진 RPM, 냉각수 온도, 배터리 전압
ECU 제어·설정	ECU 초기화, 파라미터 쓰기, 액추에이터 제어	DPF 재생 강제 실행, 에어백 리셋
펌웨어 업데이트	새 소프트웨어를 ECU에 플래싱	리콜 소프트웨어 업데이트

OBD-II(On-Board Diagnostics)는 배기가스 관련 진단을 위해 법적으로 의무화된 표준 포트입니다. 누구나 접근 가능합니다. UDS는 그보다 훨씬 깊은 제조사 수준의 진단 프로토콜입니다. 정비소나 OEM 개발 장비에서 사용하며, 접근 권한 제어가 필요합니다.

UDS — 자동차 ECU의 공통 언어

UDS(Unified Diagnostic Services)는 ISO 14229 표준으로 정의된 차량 진단 통신 프로토콜입니다. 2006년 처음 발행됐으며, 현재 거의 모든 완성차 OEM이 사용하는 사실상의 업계 표준입니다.

"Unified"라는 이름에서 알 수 있듯, 과거에는 OEM마다 제각각이던 진단 프로토콜을 하나로 통합한 것입니다. BMW, 현대, 토요타, 폭스바겐 모두 UDS를 씁니다. 진단 장비 제조사 입장에서는 하나의 프로토콜만 구현하면 모든 차량을 지원할 수 있게 됐습니다.

UDS는 OSI 7계층 모델에서 애플리케이션 레이어(7계층)에 해당합니다. 실제 물리 전송은 CAN, CAN FD, LIN, Ethernet 등 다양한 통신 레이어 위에서 동작합니다. UDS 자체는 "무슨 서비스를 요청하느냐"를 정의하고, 실어나르는 방법은 하위 레이어가 담당합니다.

UDS의 기본 구조 — 요청과 응답

UDS는 클라이언트-서버 모델로 동작합니다. 진단 장비(테스터)가 클라이언트, ECU가 서버입니다. 테스터가 요청을 보내고 ECU가 응답합니다.

모든 UDS 메시지는 SID(Service Identifier)로 시작합니다. SID는 1바이트로, 어떤 서비스를 요청하는지를 나타냅니다. 응답 메시지의 SID는 요청 SID에 0x40을 더한 값입니다.

UDS 메시지 구조

SID
1 byte

Sub-function
1 byte (선택)

Data Parameters
가변 길이

요청 (Request)

SID + 0x40
1 byte

Response Data
가변 길이

긍정 응답 (Positive Response)

0x7F

요청 SID

NRC (오류 코드)

부정 응답 (Negative Response)

예를 들어 DTC(고장 코드)를 읽는 서비스 SID는 0x19입니다. 요청을 보내면 ECU는 0x59(0x19 + 0x40)로 응답하고 저장된 오류 코드 목록을 돌려줍니다.

실제 UDS 대화 예시 — DTC 읽기

테스터

19 02 FF

SID 0x19 (ReadDTCInformation) | 서브기능 0x02 (보고 유형) | 0xFF (모든 상태)

↓

ECU

59 02 FF 00 B1 20 2F ...

SID 0x59 (긍정 응답) | 저장된 DTC 목록 반환 (예: P0B12 — 배터리 셀 불균형)

부정 응답 예시 — 권한 없는 서비스 요청

테스터

34 00 44 ...

SID 0x34 (RequestDownload) — 펌웨어 다운로드 요청

↓

ECU

7F 34 33

0x7F (부정 응답) | 0x34 (요청한 SID) | NRC 0x33 (SecurityAccessDenied — 보안 인증 필요)

UDS의 주요 서비스들

UDS는 수십 개의 서비스를 정의합니다. 자주 쓰이는 것들을 카테고리별로 정리하면 이렇습니다.

진단 세션·보안

0x10 DiagnosticSessionControl — 세션 전환

0x11 ECUReset — ECU 재시작

0x27 SecurityAccess — 보안 잠금 해제

0x29 Authentication — 고급 인증 (UDS 2020+)

데이터 읽기·쓰기

0x19 ReadDTCInformation — 고장 코드 읽기

0x22 ReadDataByIdentifier — 데이터 읽기

0x2E WriteDataByIdentifier — 데이터 쓰기

0x14 ClearDiagnosticInformation — DTC 삭제

제어·테스트

0x2F InputOutputControlByIdentifier — 액추에이터 제어

0x31 RoutineControl — 루틴 실행 (자가진단 등)

0x85 ControlDTCSetting — DTC 기록 켜기/끄기

0x28 CommunicationControl — 통신 제어

펌웨어 업로드·다운로드

0x34 RequestDownload — 다운로드 시작 요청

0x35 RequestUpload — 업로드 시작 요청

0x36 TransferData — 데이터 전송

0x37 RequestTransferExit — 전송 종료

진단 통신은 단순한 오류 코드 확인 도구가 아닙니다. ECU 재시작, 메모리 접근, 액추에이터 직접 제어, 소프트웨어 교체까지 가능한 강력한 제어 채널입니다. 만약 인증 없이 누구나 이 채널에 접근할 수 있다면, 차량 보안은 아무리 다른 곳을 잘 막아도 이 구멍 하나로 무너질 수 있습니다. 특히 0x34~0x37(펌웨어 다운로드/업로드)은 반드시 Security Access(0x27) 인증을 통과해야만 사용 가능합니다.

왜 "세션"이라는 개념이 필요할까

UDS에는 진단 세션(Diagnostic Session)이라는 개념이 있습니다. ECU는 항상 동일한 서비스를 제공하지 않습니다. 어떤 세션에 있느냐에 따라 허용되는 서비스가 달라집니다.

세션 종류	SID	허용 범위	주요 사용 상황
Default Session	0x01	기본 읽기 서비스만 허용	평상시, 일반 OBD 진단
Extended Session	0x03	파라미터 읽기/쓰기, 액추에이터 제어	정비소 고급 진단
Programming Session	0x02	펌웨어 다운로드, 메모리 쓰기	ECU 소프트웨어 업데이트

Default Session에서는 펌웨어 다운로드 서비스(0x34)를 요청해도 NRC 0x7E(serviceNotSupportedInActiveSession)로 거절됩니다. Programming Session으로 전환하고, Security Access 인증을 통과해야 비로소 플래싱이 가능합니다. 이 구조 자체가 하나의 보안 레이어입니다.

UDS는 어떤 물리 경로로 전달되나

UDS 메시지는 다양한 물리 레이어 위에서 전달됩니다. 가장 흔한 경로는 OBD-II 포트를 통한 CAN 버스이지만, 최신 차량에서는 Ethernet 기반 진단도 늘고 있습니다.

전송 레이어	특징	주요 사용
CAN + ISO 15765 (DoIP over CAN)	전통적인 방식. 속도 제한 있음	대부분 양산차 OBD-II 진단
Ethernet + DoIP (ISO 13400)	고속 전송. 대용량 펌웨어 업데이트에 적합	최신 차량, 공장 플래싱, OTA 연계
LIN	저속, 단순 ECU용	바디 도어 모듈, 시트 ECU 등

특히 DoIP(Diagnostics over Internet Protocol)는 차량 내 Ethernet이 확산되면서 중요해지고 있습니다. CAN보다 훨씬 빠르기 때문에 수백 MB짜리 펌웨어 업데이트도 현실적인 시간 안에 가능해졌습니다.

테스터는 ECU와 직접 연결되지 않는다

한 가지 중요한 오해가 있습니다. 진단기가 OBD-II 포트에 연결되면 차량 내 모든 ECU에 직접 접근할 수 있다고 생각하기 쉽습니다. 하지만 실제 구조는 다릅니다.

테스터의 진단 요청은 먼저 게이트웨이 ECU를 통과합니다. 게이트웨이는 어떤 진단 메시지를 어느 ECU로 전달할지 결정합니다. 허용되지 않은 요청은 대상 ECU에 도달하기 전에 차단됩니다.

과거 차량에서는 OBD-II 포트가 CAN 버스에 직접 연결되어 모든 ECU가 노출됐습니다. 이것이 지프 해킹 같은 사례에서 공격 경로가 된 이유입니다. 최근 차량은 게이트웨이가 진단 요청의 라우팅과 접근 제어를 담당하는 구조로 바뀌고 있습니다. 이 주제는 시리즈 5편에서 자세히 다룹니다.

현업에서는 실제로 이렇게 경험한다

OEM마다 표준 위에 사유 확장이 있다 — UDS는 ISO 표준이지만, OEM은 그 위에 자체 서비스와 DID(Data Identifier)를 추가합니다. 같은 0x22 서비스라도 어떤 DID를 지원하는지는 OEM마다 다릅니다. Tier-1 입장에서는 OEM의 진단 스펙 문서가 없으면 구현 자체가 불가능합니다.

진단 통신은 보안과 떼어놓을 수 없다 — ECU 개발에서 UDS를 구현할 때 Security Access(0x27) 설계가 가장 까다롭습니다. 어떤 세션에서 어떤 서비스를 허용할지, 시드-키 알고리즘을 어떻게 설계할지가 보안 수준을 결정합니다. 다음 편에서 다룰 핵심 주제입니다.

진단 타임아웃 관리가 생각보다 복잡하다 — UDS에는 P2 타임아웃(ECU 응답 시간), P2* 타임아웃(연장 응답 시간), S3 타임아웃(세션 유지 시간) 등 여러 타이머가 있습니다. 이 타이머를 잘못 구현하면 정비 장비와 통신이 끊기거나, 반대로 세션이 의도치 않게 유지되는 문제가 생깁니다.

게이트웨이가 진단 요청을 라우팅한다 — 테스터가 OBD-II 포트에 연결하면 게이트웨이 ECU가 어떤 ECU로 진단 메시지를 전달할지 결정합니다. 모든 ECU가 직접 외부에 노출되지 않습니다. 이 구조가 보안에서 중요한 이유는 시리즈 5편에서 다룹니다.

마무리

UDS는 자동차 ECU와 외부 장비가 대화하는 공통 언어입니다.
정비소에서 고장을 진단하고, 공장에서 소프트웨어를 업데이트하고,
개발 단계에서 ECU를 제어하는 모든 과정이 이 언어로 이루어집니다.

그런데 이 대화 창구가 열려 있다는 것은 동시에 공격자의 진입 경로가 될 수 있다는 의미이기도 합니다. 다음 편에서는 UDS에서 가장 중요한 보안 메커니즘인 Security Access(보안 인증)가 어떻게 동작하는지를 다룹니다.

핵심 요약

• UDS(ISO 14229)는 차량 ECU 진단을 위한 표준 프로토콜 — 거의 모든 OEM이 사용
• 클라이언트(테스터)-서버(ECU) 구조로 동작. SID로 서비스를 식별
• 응답은 긍정(SID+0x40) 또는 부정(0x7F + NRC)으로 구분
• 주요 서비스: DTC 읽기(0x19), 데이터 읽기(0x22), Security Access(0x27), 펌웨어 다운로드(0x34~0x37)
• 진단 세션(Default·Extended·Programming)에 따라 허용 서비스가 달라진다
• CAN 위에서도, Ethernet(DoIP) 위에서도 동작 — 최신 차량은 DoIP 비중이 높아지는 추세
• OBD-II는 누구나 접근 가능한 기본 진단, UDS는 제조사 수준의 심층 진단

차량 진단 통신 시리즈

1

자동차 ECU는 정비소와 어떻게 대화할까? — UDS 진단 통신 쉽게 이해하기  ← 현재 글

2

자동차는 왜 진단 인증(Security Access)을 사용할까?

3

UDS의 Diagnostic Session은 왜 필요할까?

4

차량 ECU 업데이트는 실제로 어떻게 진행될까? — Flashing 구조 이해하기

5

Gateway ECU는 왜 진단 요청을 차단할까?

UDS 진단통신 ISO14229 차량진단 ECU진단 OBD2 DoIP DTC 차량보안기술 SecurityAccess