[protocol] UDS 이론 정리

🚐 진단 통신 프로토콜 이란?

진단 통신은 자동차 제어기의 고장에 따른 사고를 방지하기 위한 ISO 기반 표준 통신 프로토콜이다.
진단 통신에 필요한 장치를 차량의 ECU 또는 OBD 단에 연결하여 공통적으로 아래와 같은 기능을 수행 한다.

• ECU 리프로그래밍 : 진단통신을 통해 ECU에 새로운 소프트웨어를 업데이트하여 오류 수정 및 성능 개선
• ECU 정보 획득 : ECU의 다양한 정보를 획득  
• 오류 진단 : 오류 코드를 읽고 해석하여 차량의 문제를 진단 

🚐 진단 통신 프로토콜 종류

진단 통신 프로토콜은 아래 3가지가 있으며 역할은 서로 비슷하나 중점 사항에 따라 조금씩 다르며 
3가지 모두 법적 의무사항이 있다.

   1) UDS(Unified Diagnostic Services)

     - 차량 오작동 진단에 중점을 두며 ECU와 진단 장치 간의 통신에 중점을 두는 진단 프로토콜 
     - ISO 14229에 따라 정의 

   2) OBD(On-Board Diagnostics)

     - 배출 가스 관련 진단에 중점을 두며 고장이 발생할 경우 자가 점검에 중점을 두는 진단 프로토콜
     - ISO 15765에 따라 정의

   3) XCP(eXtended Controller Parameterization)  

     - 차량의 ECU에 저장된 오류 코드를 읽고 해석함에 중점을 두는 진단 프로토콜
     - 차량의 ECU와 진단 장치 간의 데이터 통신을 위한 확장 가능한 네트워크 생성을 지원

     - low bandwidth delay나 real-time fault analysis가 요구되는 onboard 진단 시스템에 사용됨
     - ISO 22765에 따라 정의

 

🚐 연결 방법

ECU와 직접 연결

1. ECU의 커넥터에 진단 장비를 연결
2. 진단 장치를 켜고, ECU와 통신 시작
3. 원하는 기능을 선택 하여 수행(e.g. 정보 획득, ECU를 리프로그래밍 등)  

  ECU와 직접 연결할 경우 아래와 같은 장점이 있다.

• 더 빠르고 정확한 데이터 획득
  직접 연결 시 진단 장치가 ECU의 데이터에 직접 액세스할 수 있으므로 더 빠르고 정확한 데이터 획득이 가능
• 더 많은 기능의 사용
  직접 연결 시 ECU의 모든 기능을 사용할 수 있으므로, 더 많은 기능을 사용 가능

OBD 단에 연결

1. 차량의 OBD 단에 진단 장비를 연결
2. 진단 장치를 켜고, ECU와 통신 시작
3. 원하는 기능을 선택 하여 수행(e.g. 정보 획득, ECU를 리프로그래밍 등)  

   OBD 단에 연결할 경우 아래와 같은 장점이 있다.

• 편리한 사용
  OBD 단은 차량의 운전석 아래에 위치하고 있어, 쉽게 접근할 수 있음
• 모든 차량에서 사용 가능
  OBD 단은 모든 차량에 탑재되어 있으므로, 모든 차량에서 UDS를 사용할 수 있습니다.

🚐 UDS의 기능

• ECU 리프로그래밍(프로그램 Flash)
• 데이터 요청 및 쓰기
• 테스트와 결과 값 반환
• 메모리 클리어링
• 스케쥴 재설정
• 커뮤니케이션 매니지먼트(e.g 세션 컨트롤, 디바이스 리셋, 보안접근, 통신 컨트롤)
• 데이터 메모리 또는 ID 읽고 쓰기
• 저장 데이터 관리(진단정보 불러오기 및 삭제)
• I/O 컨트롤 입력값과 출력값을 조정

🚐 UDS 동작 과정

 1) 물리적 연결
     ECU에 연결하거나 OBD 단에 연결
 2) 권한(Session) 요청
     진단 장치는 ECU에 연결되면, ECU로부터 권한(Session)을 요청
 3) 주문 (SID 입력)
     진단 장치는 ECU에 대한 정보를 획득하거나  ECU를 진단하기 위해 주문(요청을 나타내는 코드)을 입력함
     이를 통해 ECU 진단 또는 업데이트 같은 동작을 수행함 
 4) 응답 회신
     ECU는 진단 장치의 주문에 대한 응답을 회신함 성공이면 긍정 응답 실패면 부정 응답 회신

 

🚐 UDS Message Structure

ECU에 Request를 보내거나 Response를 받을 때 Message는 아래와 같은 구조를 가진다.
PCI ~ Padding 까지 총 8 Bytes의 크기, CAN ID는 29bits의 크기를 가진다.

Request 

UDS Request Message Structure

Reponse(Negative)

UDS Negative Reponse Structure

CAN ID 

첫 11비트에는 ECU의 주소 값이 들어가고 나머지 18비트에는 ECU에 대한 요청인 SID와 요청 데이터가 들어간다. 
ECU에 요청을 보내냐, 응답을 받냐에 따라 구분되며 Response, Request에 따른 설명은 아래와 같다.
(e.g. CAN ID 0x701 일 때 ECU 주소값 = CAN ID & 0x1FFFFFFF = 0x00000001, SID = 0x701 >> 22 = 0x00)       

PCI

CAN 버스에서 UDS를 요청할 때 전송하는 Frame의 성격과 전송할 Payload의 길이를 알려주는 영역

UDS SID & Session 

UDS  Session은 UDS 프로토콜에서 ECU와 진단 장치 간의 통신을 위한 기본적인 설정이다.

Session Transition Diagram

Session	권한	기능
Default Session	ECU에 연결만 하면 가능	기본적인 기능 (e.g. 데이터 읽기, ECU 리셋)
Extended Session	ECU로부터 권한을 받아야 함	Default Session 외 추가 기능 (e.g.기본적인 소프트웨어 업데이트)
Safety System Session	ECU로부터 특별한 권한을 받아야 함	안전 시스템 관리 기능
Programming Session	ECU로부터 특별한 권한을 받아야 함	ECU 소프트웨어 업데이트 기능

UDS SID는 ECU와 진단 장치 간의 통신을 위한 특정 UDS 서비스 Request, Response에 대한 ID 이다.
(※ Response ID = Request ID + 0x40)

SID(hex)	Service Name	Cvt	Default Session	Extended Session	Programming Session	Safety Session
10	DiagnosticSessionControl	M	O	O	O	O
11	EcuReset	M		O	O
14	ClearDiagnosticInformation	M		O
19	ReadDTCInformation	M	O	O
22	ReadDataByIdentifier	M	O	O	O	O
27	SecurityAccess	C		O	O	O
28	CommunicationControl	M		O
2A	ReadDataByPeriodicIdentifier	U		O
2E	WriteDataByIdentifier	C		O	O	O
2F	InputOutputControlByIdentifier	U		O
31	RoutineControl	C		O	O	O
34	RequestDownload	C			O
36	TransferData	C			O
37	RequestTransferExit	C			O
3E	TesterPresent	M	O	O	O	O
85	ControlDTCSetting	M		O	O

Sub Function Byte 

ECU에 대한 요청의 세부 정보를 나타내는 필드 SID는 ECU에 대한 요청의 종류를 나타낸다면 Sub Function Byte는
SID에 대한 세부 정보를 나타낸다.

일부 UDS 요청 프레임에서 사용되며, 선택적이므로 사용되지 않는 ID들도 있다.

* 첫 비트(7 bit) – SuppressPosRspMsgIndicationBit
(※ ECU의 Response가 Positive인지 명시하는 비트로, 0-False, Positive /1-True, not send Positive)

* 나머지 비트(6~1bit) – Sub-Function parameters
(※ 해당 진단 서비스에 대한 특정 파라미터 값)

Request Data Parameters

ECU에 요청하는 정보에 대한 매개변수(요청 유형, 요청 범위, 요청 대상 데이터) 필드

Padding

CAN 메시지의 길이가 8바이트 미만일 때 남은 공간을 채우기 위한 필드(0xAA)

🚐 Flash Reprogramming

ECU의 플래시 메모리에 새로운 펌웨어를 업데이트하는 프로세스로 Programming Session에 해당됨
플래시 메모리를 사용하는 이유는 아래와 같다.

• 비휘발성: Flash 메모리는 전원이 꺼져도 데이터가 유지됨 따라서, ECU가 종료되더라도
                   ECU의 운영 체제와 제어 알고리즘이 유지되 안정적임 
• 재기록 가능: Flash 메모리는 기존 데이터를 덮어쓰면서 새로운 데이터를 기록할 수 있음 따라서,
                       ECU의 펌웨어를 업데이트에 용이함
• 저렴: Flash 메모리는 다른 유형의 메모리보다 저렴하여 단가를 낮출 수 있음

🚐 Flash Boot Loader 

Flash Boot Loader는 ECU의 Flash 메모리에 저장된 프로그램이다. ECU가 부팅될 때 가장 처음 실행되는
프로그램으로, ECU의 운영 체제와 제어 알고리즘을 메모리에서 읽어와 실행하는 역할을 한다.

Flash Bootloader 구조

[참고]
https://nvdungx.github.io/unified-diagnostic-protocol-overview/

https://www.embitel.com/blog/embedded-blog/what-is-flash-bootloader-and-nuances-of-an-automotive-ecu-re-programming