UDS란 무엇인가? 자동차 ECU 진단 프로토콜 ISO 14229 완벽 정리

자동차 ECU 개발을 시작하면 가장 먼저 접하게 되는 분야 중 하나가 진단(Diagnostics)이다. 차량 개발, 생산, 정비, OTA 업데이트, 고장 분석까지 거의 모든 과정에서 사용되는 핵심 기술이 바로 UDS(Unified Diagnostic Services)이다.

 

특히 AUTOSAR 기반 ECU를 개발하거나 CANoe, CANalyzer, DCM, DEM 등을 다루는 개발자라면 UDS에 대한 이해는 필수라고 할 수 있다.

 

이번 글에서는 UDS의 개념부터 통신 구조, 주요 서비스, AUTOSAR와의 관계, 실무 활용 사례까지 한 번에 정리해본다.

 

UDS란?

 

UDS(Unified Diagnostic Services)는 차량 내 ECU(Electronic Control Unit)와 외부 진단기(Tester)가 통신하기 위한 국제 표준 진단 프로토콜이다.

 

국제 표준인 ISO 14229에 정의되어 있으며, ECU 진단을 위한 공통 서비스 집합을 제공한다. 이를 통해 제조사와 ECU 종류가 달라도 동일한 방식으로 진단 기능을 수행할 수 있다.

 

쉽게 말하면, ECU의 상태를 읽고, 고장을 확인하고, 소프트웨어를 업데이트하기 위한 표준화된 통신 규칙이라고 이해하면 된다.

 

현재 대부분의 자동차 OEM과 Tier-1 업체는 ECU 진단 기능을 구현할 때 UDS를 사용한다.

 

왜 UDS가 필요할까?

 

과거에는 제조사마다 서로 다른 진단 프로토콜을 사용했다.

대표적으로 K-Line, KWP2000, 제조사 전용 프로토콜 등이 존재했다.

 

하지만 차량 전자화가 진행되면서 ECU 수가 수십 개에서 많게는 100개 이상으로 증가하였고,

서로 다른 진단 프로토콜을 유지하는 것이 매우 비효율적이 되었다.

 

이를 해결하기 위해 등장한 것이 UDS이다.

 

UDS를 사용하면 하나의 진단기로 다양한 ECU를 동일한 방식으로 진단할 수 있으며,

OEM과 공급업체 간의 개발 효율성도 크게 향상된다.

 

UDS와 CAN의 차이

 

많은 입문자가 CAN과 UDS를 동일한 개념으로 생각한다.

하지만 둘은 완전히 다른 계층이다.

구분	CAN	UDS
역할	통신 버스	진단 프로토콜
표준	ISO 11898	ISO 14229
계층	Physical/Data Link	Application
목적	데이터 전송	ECU 진단

 

비유하면,

CAN = 도로
UDS = 도로 위를 달리는 진단 메시지

 

이다.

 

즉, UDS는 CAN 위에서 동작하는 애플리케이션 프로토콜이다.

 

UDS는 CAN만 사용할까?

 

아니다. UDS는 특정 물리 계층에 종속되지 않는다.

대표적으로 다음과 같은 네트워크에서 사용된다.

• CAN
• CAN FD
• FlexRay
• LIN
• Ethernet(DoIP)

다만 실제 양산 차량에서는 대부분 CAN 또는 CAN FD 기반의 DoCAN(Diagnostics over CAN)이 가장 널리 사용된다.

 

UDS 통신 구조

 

UDS는 Client-Server 구조로 동작한다.

 

진단기(Tester)가 요청(Request)을 보내면 ECU가 응답(Response)을 반환한다.

예를 들어 차량의 VIN 정보를 읽고 싶다면 다음과 같은 요청을 보낸다.

22  F1 90

 

ECU는 다음과 같이 응답한다.

62 F1 90 57 56 57 ...

 

여기서

22 = ReadDataByIdentifier
F1 90 = VIN DID

 

를 의미한다.

 

위의 이미지에 보이는 A0 01 은 OEM 또는 ECU에서 정의한 사용자 DID이며, 의미는 프로젝트마다 다를 수 있다.

 

SID(Service Identifier)란?

 

UDS의 모든 기능은 SID(Service Identifier)로 구분된다.

즉, "어떤 진단 서비스를 수행할 것인가?" 를 나타내는 코드이다.

 

예를 들어

• 10 = Session Control
• 11 = ECU Reset
• 22 = Read Data By Identifier
• 27 = Security Access

와 같이 정의된다.

 

실무에서 가장 많이 사용하는 UDS 서비스

 

1. Diagnostic Session Control (0x10)

진단 세션을 변경하는 서비스이다.

대표적인 세션은 다음과 같다.

• Default Session
• Extended Session
• Programming Session

일반 진단은 Default Session에서 수행되며,

소프트웨어 다운로드나 특수 진단 기능은 Extended 또는 Programming Session에서 수행된다.

 

2. ECU Reset (0x11)

ECU를 재시작하는 서비스이다.

실무에서는

• Flashing 완료 후 재부팅
• ECU 상태 복구
• 개발 중 기능 검증

등에 사용된다.

 

3. ReadDataByIdentifier (0x22)

실무에서 가장 많이 사용하는 서비스이다.

특정 DID(Data Identifier)의 값을 읽는다.

 

실제 프로젝트에서는

• VIN
• HW Version
• SW Version
• Calibration Version
• Serial Number

등을 읽을 때 사용한다.

 

4. WriteDataByIdentifier (0x2E)

DID 값을 쓰는 서비스이다.

대표적인 활용 사례로는

• EOL Coding
• 차량 옵션 설정
• 생산라인 설정값 기록

등이 있다.

 

5. Read DTC Information (0x19)

고장 코드를 읽는 서비스이다.

정비소에서 사용하는 대부분의 스캐너가 이 기능을 사용한다.

 

조회 가능한 정보로는

• DTC 번호
• DTC 상태
• Freeze Frame
• Snapshot Data

등이 있다.

 

6. Clear Diagnostic Information (0x14)

저장된 DTC를 삭제하는 서비스이다.

주로 정비 완료 후 사용된다.

 

7. Security Access (0x27)

ECU 보안을 위한 서비스이다.

모든 기능을 누구나 사용할 수 있으면 차량 보안에 심각한 문제가 발생한다.

따라서 Flash Download, Coding, Calibration 등은 보안 인증 후에만 허용된다.

일반적인 과정은 다음과 같다.

 Seed Request
         ↓
Seed Response
         ↓
   Key 계산
         ↓
  Send Key
         ↓
    Unlock

 

이를 Seed-Key 방식이라고 부른다.

 

8. Routine Control (0x31)

ECU 내부 기능을 실행하는 서비스이다.

예시로 EEPROM 검사, RAM 테스트, 모터 구동 테스트, 자가진단 수행 등이 있다.

 

9. Tester Present (0x3E)

진단 세션을 유지하기 위한 서비스이다.

일정 시간 동안 메시지가 없으면 ECU는 자동으로 Default Session으로 복귀한다.

 

이를 방지하기 위해 Tester는 주기적으로 3E 00 메시지를 전송한다.

 

Negative Response Code(NRC)

 

UDS 요청이 실패하면 ECU는 NRC(Negative Response Code)를 반환한다.

 

예시

7F 22 31

 

의 의미는

7F = Negative Response
22 = 요청 SID
31 = Request Out Of Range

 

이다.

실무에서 자주 보는 NRC는 다음과 같다.

• 0x11 Service Not Supported
• 0x12 Sub Function Not Supported
• 0x13 Incorrect Message Length
• 0x22 Conditions Not Correct
• 0x31 Request Out Of Range
• 0x33 Security Access Denied
• 0x78 Response Pending

CANoe 로그 분석 시 가장 자주 보게 되는 데이터 중 하나이다.

 

ECU Flashing은 어떻게 이루어질까?

 

차량 소프트웨어 다운로드(FOTA 포함)는 대부분 UDS 기반으로 수행된다.

 

대표적인 순서는 다음과 같다.

 

실제 OEM 프로젝트에서도 거의 동일한 절차를 사용한다.

 

정리

 

UDS(ISO 14229)는 현재 자동차 진단 분야의 사실상 표준이다.

 

차량 개발부터 생산, 정비, OTA 업데이트, ECU 플래싱, 고장 진단까지 대부분의 진단 기능이 UDS를 기반으로 동작한다.

또한 AUTOSAR 환경에서는 DCM 모듈이 UDS 서비스를 처리하며, 현대 차량의 거의 모든 ECU가 UDS를 지원한다.

 

자동차 임베디드 개발자라면 최소한 Session Control(0x10), DID Read(0x22), DTC Read(0x19), Security Access(0x27), Tester Present(0x3E)의 동작 원리는 반드시 이해해야 한다.

 

이 다섯 가지 서비스만 제대로 이해해도 대부분의 CANoe Trace와 진단 로그를 해석할 수 있으며, AUTOSAR DCM 설정도 훨씬 쉽게 이해할 수 있다.