UDS 진단 통신 (1 / t.b.d.) - Transport Protocol, UDS의 개요

시작하기 전에

TSMaster에는 UDS (Unified Diagnostic Services) 모듈이 있다. 이 모듈에는 미리 구현해둔 UDS 기능들이 있다. 이 기능들 이용하여 자동차 제어기와 진단 통신을 할 수 있다. (진단 통신이 무엇인지는 아래에 설명합니다.)

당연히 이 기능을 이용하여 제어기의 진단 통신 기능을 검증할 수 있다. 적당한 시험 케이스를 만들면 진단 통신에 사이버 보안 위험이 있는 지도 검증할 수 있다.

Automatic Diagnostic (이하, 자동 진단) 기능을 이용하면, 진단 통신 기능 검증이나 사이버 보안 검증 시험을 자동화 할 수 있다. 시험 자동화는 매우 중요하다. 자동차 시스템 개발에는 많은 항목들이 있다. 그들 중 하나가 진단 통신이다. 소프트웨어 릴리즈 때마다 진단 통신 기능 검증은 반복된다. 반복되는 작업을 자동화하면 개발 기간을 단축하고, 비용을 낮추고, 품질을 높일 수 있다.

나는 당초에 이 블로그에서 TSMaster의 자동 진단 기능을 이용하여 제어기 진단 통신의 기능 검증 방법 그리고 사이버 보안 검증 방법을 설명하려고 생각했다. 블로그를 쓰려다 보니, 설명이 필요한 세부 주제들이 여럿 있어 한편의 글에 모두 담기에 내용이 너무 많다는 것을 알았다. 그래서 블로그 시리즈를 쓸 것이다.

블로그를 쓰려니 내가 쓰려는 블로그 주제에 관해 자료 조사를 하게 된다. 조사를 하다 보니 많은 좋은 참고 자료들을 쉽게 찾을 수 있다. 내 블로그를 읽는 사람들도 쉽게 좋은 자료들을 찾을 수 있기는 마찬가지다. 나의 다른 블로그도 그렇듯이 TSMaster를 사용하는데 필요한 최소한만 설명한다.

  

개요

• 진단 통신을 간략히 (실습을 위해 필요한 정도만) 설명한다. TSMaster로 UDS 서비스 설정을 하게 되는데, 이에 필요한 최소한을 설명한다.
• 진단 통신을 하다 보면 한 메시지에 다 담을 수 없는 긴 데이터를 전송해야 할 경우가 있다. 데이터를 잘라서 전송하는 방법이 Transport Protocol (TP)이다. TP를 설명한다.
• 설정한 UDS 서비스 메시지를 제어기에 전송하고 제어기의 회신을 받아 기능을 검증할 수 있다. 이는 Diagnostic Console에서 한다. 이를 설명한다.
• 자동 진단 (Automatic Diagnostic) 기능을 이용하면 진단 통신을 검증하는 시험 케이스들을 만들고, 시험 케이스들을  실행하고, 실행 과정과 결과를 로그 파일로 저장할 수 있다. 로그 파일을 처리하면 pass/fail의 시험 결과를 보고서로 만들 수도 있다.

  

Diagnostic Module

• 메인 메뉴/ Application/ Diagnostic Module을 클릭하여 Diagsnostic 창을 연다.

메인 메뉴/ Application/ Diagnostic Module 버튼 위치

• Diagnostic 창은 아래 그림과 같다.

Diagnostic 창

• 아래의 탭들이 있다.
  • Protocol (ISO TP), Basic Diagnostic Config, Diagnostic Console, Automatic Diagnostic
• 이들 각각을 살펴볼 것이다. 그 전에 진단 통신의 용도를 먼저 설명한다.

 

 진단 통신

• 제어기들은 자체 진단 기능이 있다. 자체 진단은 전기적 이상이나 신호 타당성 이상을 감지한다. 전기적 이상의 예로 연결이 끊어진 단선 (open), 끊어진 연결이 접지나 배터리에 연결된 단락 (short to ground, short to battery) 등이 있다. CAN 통신 이상의 예로, 버스 선에 메시지가 없는 CAN bus off 가 있다. 신호의 값이 미리 정한 고장 값 (전체 비트가 1, 8비트 신호라면 0b11111111 = 0xFF. 현장에서 흔히 FF가 떴다라고 한다.)인 CAN 신호 이상이 있다. 조향각 신호는 우회전을 나타내는데, 횡가속도 신호는 좌회전을 나타내는 경우처럼 신호들이 서로 논리적/물리적으로 맞지 않을 때 타당성 이상이 감지된다. 이와 같은 제어기의 자체 진단을 On-Board Diagnostic (OBD)이라고 한다. 
• OBD에서 결함이 발견되면 제어기는 결함에 해당하는 코드를 저장한다. 흔히 진단 코드라고 한다. Diagnostic Trouble Code를 번역한 용어이다 DTC라고도 한다.   
• 자동차를 정비할 때, 정비사가 하는 진단은 Off-Board Diagnostic이다. 정비사는 진단기(tester)를 이용하여 차 안에 제어기들과 통신하며 정비를 한다. 이 통신을 진단 통신이라고 한다. 진단 통신으로 정비사는 OBD로 발견된 결함이 있는지, 있다면 무슨 결함인지, 정비 (단선 결함이라면 선을 연결한다.) 후 결함 소거를 시도하여 문제가 해되었는 지 등을 점검한다.
• 정비사가 진단 통신으로 제어기에 명령하는 것을 서비스 요청이라고 한다. 자동차 제조사, 자동차, 제어기 제조사, 제어기는 다양하지만 진단 통신으로 요청하는 서비스는 몇 가지로 분류할 수 있다. ISO 14229는 서비스들을 "통합"하여 정리 및 정의하고, "진단"기와 제어기가 "서비스"를 요청하고 응답하는 통신 프로토콜을 정리하였다. 통합 진단 서비스, Unified Diagnostic Service, UDS이다.
• UDS에 정의된 서비스는 아래와 같다. 출처: Wikipedia (Unified Diagnostic Services - Wikipedia)

Function group/ 부가 설명	Service
Diagnostic and Communications Management   제어기가 정상 작동 상태 중에 할 수 있는 서비스와 정상 작동을 중지한 상태에서 할 수 있는 서비스가 있다. 제어기 상태 전환과 관련한 서비스들이다. (상태를 세션 혹은 모드라고 한다.) 자동차 사이버 보안 위험이 높아지면서 진단 통신에 접근 통제 같은 보안 기능들이 추가되었다. DTC 관련 설정이나 소거를 하는 기능도 포함한다.	Diagnostic Session Control
	ECU Reset
	Clear Diagnostic Information
	Security Access
	Communication Control
	Authentication
	Tester Present
	Access Timing Parameters
	Secured Data Transmission
	Control DTC Settings
	Response On Event
	Link Control
Data Transmission   제어기에 연결된 센서의 입력이나 액추에이터로의 출력은 계속 변한다. 입출력 데이터에 미리 식별자 (Data ID, DID)를 정하고, 테스터로 제어기에 DID의 값을 요청하는 통신을 통해 센서나 액추에이터의 현재 값을 읽을 수 있다. 특정 정보는 제어기의 비휘발성 메모리에 저장된다. 예를 들면, 센서 캘리브레이션의 보정 값이나, 차량 배리언트(형상) 정보 등이다. 이런 정보에 미리 식별자를 정하고, 식별자를 이용하여 비휘발성 메모리에 값을 기록한다.  주소를 이용하여 메모리에서 값을 읽거나 메모리에 값을 기록한다.	Read Data By Identifier
	Read Memory By Address
	Read Scaling Data By Identifier
	Read Data By Identifier Periodic
	Dynamically Define Data Identifier
	Write Data By Identifier
	Write Memory By Address
Stored Data Transmission   제어기 자체 진단에서 검출된 결함이 DTC로 메모리에 저장된다. 결함 기록을 읽거나 소거한다. 내 경험으로는 가장 많이 사용되는 기능이다.	Clear Diagnostic Information
	Read DTC Information
Input / Output Control   제어기에 연결된 입출력을 직접 제어한다. ESC의 경우 밸브를 여닫거나, 모터를 구동하거나 멈추거나 속도를 조절한다. (제어기로) 입력 값을 변경하기도 하나? Input Control By Identifier라는 서비스가 정의된 것으로 보아 그런가 보다.	Input Output Control By Identifier
Remote Activation of Routine   예를 들면, 브레이크 유압 라인의 공기 빼기 작업을 하기 위해서는 ESC의 밸브 제어와 모터 제어가 미리 정해진 순서에 따라 수행되어야 한다. 이를 일일이 Input Output Control By Identifier 서비스를 이용하여 구현할 있으나 번거롭고 오류의 가능성이 높다. 이런 절차는 제어기에 서비스 "루틴"으로 프로그램 되어있다. Input Output Control By Identifier 보다 훨씬 간략한 통신으로 서비스 루틴을 실행한다.	Routine Control
Upload / Download   소프트웨어를 진단기에서 제어기로 혹은 제어기에서 진단기로 전송한다. 진단기에서 제어기로 전송하는 경우, 리프로그래밍 혹은 리플래시(플래시 메모리에 다시 쓴다라는 의미)라고 한다.	Request Download
	Request Upload
	Transfer Data
	Request Transfer Exit
	Request File Transfer

 

UDS 메시지 구조

• 진단 통신은 요청(request)와 응답(response)로 이뤄진다.
• 요청 (request) 메시지의 구조는 아래와 같다. 

Service Id

Sub-function Id (선택)

Request Data Id

• UDS에 정의된 서비스 요청 메시지의 Service Id (SID)는 아래 표와 같다.

Service	Request   SID
Diagnostic Session Control	0x10
ECU Reset	0x11
Clear Diagnostic Information	0x14
Security Access	0x27
Communication Control	0x28
Authentication	0x29
Tester Present	0x3E
Access Timing Parameters	0x83
Secured Data Transmission	0x84
Control DTC Settings	0x85
Response On Event	0x86
Link Control	0x87
Read Data By Identifier	0x22
Read Memory By Address	0x23
Read Scaling Data By Identifier	0x24
Read Data By Identifier Periodic	0x2A
Dynamically Define Data Identifier	0x2C
Write Data By Identifier	0x2E
Write Memory By Address	0x3D
Clear Diagnostic Information	0x14
Read DTC Information	0x19
Input Output Control By Identifier	0x2F
Routine Control	0x31
Request Download	0x34
Request Upload	0x35
Transfer Data	0x36
Request Transfer Exit	0x37
Request File Transfer	0x38

• Sub-function Id와 Request Data Id는 SID 별로 정해져 있다. 상세는 관련 표준이나 제조사의 사양서에 따른다.
• 응답 메시지는 두 종류로 나눠진다. 긍정 응답 (positive response)과 부정 응답 (negative response)
• 부정 응답 메시지의 구조는 아래와 같다.

  0x7F

  Service Id

  NRC (Negative Response Code)

• 부정 응답의 첫번째 바이트는 0x7F으로 고정이다. 부정 응답인지 쉽게 판별할 수 있다.
• 부정 응답의 두번째 바이트는 서비스 요청 SID이다. 무슨 서비스 요청에 대한 부정 응답인지를 알 수 있다.
• 부정 응답의 세번째 바이트는 부정 응답의 원인 (NRC, Negative Response Code)이다. 아래 표는 Wikipedia의 NRC 표에서 일부를 가져왔다. 부정 응답의 원인에 따라 적절하게 조치하게 된다.

NRC	Description
0x10	General reject
0x11	Service not supported
0x12	Subfunction not supported
0x13	Incorrect message length or invalid format
0x14	Response too long
0x21	Busy, repeat request
0x22	Conditions not correct
0x24	Request sequence error
0x25	No response from subnet component
0x26	Failure prevents execution of requested action
0x31	Request out of range
0x33	Security access denied
0x34	Authentication failed
0x35	Invalid key
0x36	Exceeded number of attempts
0x37	Required time delay not expired
0x38	Secure data transmission required
0x39	Secure data transmission not allowed
0x3A	Secure data verification failed

• 긍정 응답 메시지의 구조는 아래와 같다.

요청 Service Id + 0x40

Sub-function Id (선택)

Request Data Id

• 첫번째 바이트는 SID이다. "응답" 메시지의 SID = "요청" 메시지의 SID + 0x40 관계이다. 어느 요청 메시지의 응답인지 알 수 있다.
• SID가 0x19인 Read DTC Information 서비스의 요청 메시지와 긍정 응답 메시지의 예는 아래와 같다.
• 요청 메시지
  • 0x19 0x02 0x89
  • 0x19: SID for Read DTC
  • 0x02: Sub-function. 예, 어떤 종류의 DTC를 읽어라. 
  • 0x89: Request data parameter: 예, 어떤 상태의 DTC를 읽어라.
• 응답 메시지:
  • 0x59 0x02 0x89 0x52 0x00 0x01 0x89 0x52 0x03 0x01 0x89 0x52 0x06 0x01 0x89 0x52 0x09 0x01 0x89 0x55 0x01 0x13 0x08 0x64 0x16 0x13 0x89 0x64 0x17 0x13 0x89 0x52 0x83 0x87 0x89 0x56 0x13 0x87 0x89 0x56 0x46 0x87 0x89 0x56 0x56 0x87 0x89 0x56 0x88 0x87 0x89 0x58 0x14 0x87 0x89 0x58 0x17 0x87 0x89 0x57 0x02 0x4a 0x08 0x56 0x69 0x87 0x09 0x58 0x70 0x87 0x09 0xaa 0xaa 0xaa 0xaa 0xaa
  • 0x59: 요청 메시지 SID + 0x40 = 0x19 + 0x40 = 0x59
  • 0x02: 요청 메시지의 Sub-function.
  • 0x89: 요청 메시지의 request data parameter
  • 0x52 … 0xaa: Read DTC에 대한 응답. 즉, DTC
    • 0xaa: 패딩 (padding) 바이트. 메시지의 남는 빈 칸을 채우는 용도
• 위 응답 메시지의 길이는 71 바이트이다. 진단 통신도 (일반적으로) 차량의 CAN 버스를 이용한다. CAN은 데이터 길이가 최대 8 바이트로, CAN-FD는 최대 64 바이트로 한정되어 있다. CAN/CAN-FD의 데이터 길이 제한을 넘는 큰 데이터를 전송(Transport)하는 방법이 필요하다. (너무도 당연하게) 데이터를 잘라서, 여러 메시지들에 나눠서 보내야 한다. ISO 15765-2는 이 방법을 정의한다. 이 방법을 Transport Protocol이라고 한다. 흔히, ISO TP 혹은 TP라고 한다.

  

Transport Protocol (TP)

• 메시지 크기 한계보다 큰 데이터를 여러 메시지로 잘라서 보낼 때 (멀티-메시지 전송이라고 하겠다.)는 크게 두 가지 측면이 있다.
  • 우려: 여러 메시지들 중 전송 누락된 메시지는 없는가? ➡️ 대응: 메시지에 일련 번호를 부여한다.
  • 우려: 여러 메시지들 중 수신 누락된 메시지는 없는가? ➡️ 대응: 수신 측에서 수신 가능한 전송 속도와 양을 지정한다. 이를 플로우 컨트롤 (Flow Control, FC) 이라고 한다.
• TP의 메시지 플로우는 아래 그림과 같다.

TP의 메시지 플로우. 위 Read DTC 예제에서, 제어기가 Sender이고 진단기가 Receiver가 된다. 리프로그램을 하는 경우라면, Sender는 진단기이고 Receiver는 제어기가 된다.

• 위에 예로 든 Read DTC를 예로 설명한다. Sender를 제어기, Receiver를 진단기이다. 현재 진단기가 제어기에 Read DTC를 요청하여, 진단기는 제어기에 71 바이트의 데이터를 전송한다.
• 제어기는, 소위, First Frame (FF)을 보낸다. FF에는 멀티-메시지 응답이라는 표시가 있어야 한다. 그리고 총 몇 바이트의 데이터를 보낼 것인지 표시를 해야 한다. 그래야 수신 측에서 큰 데이터를 수신할 준비를 하고 메시지들을 수신한 후에 누락 혹은 초과 여부를 검증할 수 있다. 그래서 FF의 구조는 아래 그림과 같다. (nibble(니블)은 4 비트이다.)

Message Type	Byte 1		Byte 2	Byte 3	Byte 4 – Byte 7	Byte 8
	High nibble	Low nibble
First Frame (FF)	0001	FF_DL First Frame Data Length 최대 4095 바이트		DATA 1	...	DATA 6

• 위 그림은 데이터 길이가 최대 8 바이트인 CAN 메시지의 경우이다. CAN-FD의 최대 데이터 길이가 64 바이트이지만, 실제 진단 통신에서는 8 바이트만 사용하는 경우가 많다.
• FF_DL은 총 12 비트이다. 따라서 TP로 한 번에 전송할 수 있는 최대 데이터는 4095 바이트다.
• FF을 수신한 진단기는, 소위, Flow Control (FC) 메시지로 송신 조건을 응답한다. FC 에는 메시지 전송 간격 (STmin. Separation Time Minimum)과 수신 가능한 데이터 총량(BS. Block Size)이 있다. 그래서 FC의 구조는 아래 그림과 같다.

Message Type	Byte 1		Byte 2	Byte 3	Byte 4 – Byte 7	Byte 8
	High nibble	Low nibble
Flow Control (FC)	0011	FS Flow Status 0: ContinueToSend (CTS) 1: Wait (WT) 2: Overflow (OVFLW)	BS	STmin	N/A

• 제어기는 FC의 조건에 맞게 데이터를 전송한다. BS를 초과하는 데이터를 전송해야 한다면, 제어기는 BS 만큼 데이터를 전송한 후 진단기로부터 다음 블록 전송을 허락하는 FC 메시지를 기다린다. 제어기는 FC 메시지 수신 후 다음 블록을 전송한다.
• 제어기가 연속적으로 보내는 메시지들을 Consecutive Frame (CF)라고 한다. CF에는 몇 번째 CF인지를 표시해야 수신 측에서 누락/중복을 확인할 수 있다. 또 동일한 데이터가 반복해서 전송되는 경우, 동일 데이터가 아닌 것을 알 수 있다. 그래서 CF의 구조는 아래 그림과 같다.

Message Type	Byte 1		Byte 2	Byte 3	Byte 4 – Byte 7	Byte 8
	High nibble	Low nibble
Consecutive Frame (CF)	0010	SN (Serial Number) 0 -> 15 -> 0 -> 15 -> …	DATA 1	DATA 2	...	DATA 7

• 데이터가 작아 멀티-메시지 전송이 아닌 단일-메시지 전송의 경우도 있다. 이때 메시지를 Single Frame (SF)라고 한다. SF의 구조는 아래 그림과 같다.

Message Type	Byte 1		Byte 2	Byte 3	Byte 4 – Byte 7	Byte 8
	High nibble	Low nibble
Single Frame(SF)	0000	SF_DL Single Frame Data Length 최대 7 바이트	DATA 1	DATA 2	...	DATA 7

• TP에는 위 4가지 메시지 종류 (FF, FC, CF, SF)가 있다.
• 메시지의 첫번째 바이트의 하이 니블(4 bit)에서 메시지 종류를 판별할 수 있다.
• SF는 첫번째 바이트의 로우 니블에서 데이터 길이를 알 수 있다.
• FF는 첫번째 바이트이 로우 니블과 두번재 바이트에서 전체 데이터 길이를 알 수 있다.
• FC는 첫번째 바이트의 로우 니블에서 수신 측의 상태를 알 수 있다.
• CF는 첫번째 바이트의 로우 니블에서 메시지의 순환하는 일련 번호를 알 수 있다.
• 위 Read DTC의 응답인 71 바이트는 아래와 같이 11개 메시지로 분리되어 전송된다.
  • ' ' 안의 숫자는 16 진수 (Hex) 이다. 
  • [ ] 안이 숫자들이 전송된 데이터이다. 
  • 메시지 번호는 참고용이다. 전송된 데이터가 아니다.

 1: ['10', '47', '59', '02', '89', '52', '00', '01'] 10: FF이다. 47: 10 진수로 71. 전체 데이터 길이 = 71 바이트. 59 = 19 + 40. 19의 긍정 응답이다.
 2: ['21', '89', '52', '03', '01', '89', '52', '06'] 21: CF이다. CF의 1번 메시지다.
 3: ['22', '01', '89', '52', '09', '01', '89', '55'] 22: CF이다. CF의 2번 메시지다.
 4: ['23', '01', '13', '08', '64', '16', '13', '89']
 5: ['24', '64', '17', '13', '89', '52', '83', '87']
 6: ['25', '89', '56', '13', '87', '89', '56', '46']
 7: ['26', '87', '89', '56', '56', '87', '89', '56']
 8: ['27', '88', '87', '89', '58', '14', '87', '89']
 9: ['28', '58', '17', '87', '89', '57', '02', '4a']
10: ['29', '08', '56', '69', '87', '09', '58', '70']
11: ['2a', '87', '09', 'aa', 'aa', 'aa', 'aa', 'aa'] 21: CF이다. CF의 10번 메시지다. aa는 패딩 바이트.

 

마무리

• 이 정도면 TSMaster의 UDS 모듈 사용법을 실습하기에 충분한 진단 통신에 관한 기초 지식이길 바란다.

 

ESC(a.k.a. VDC, ESP)?

Electronic Stability Control Technology(ESP, DSC, ESC, A-TRC) (youtube.com)