UDS 진단 통신 (3 / t.b.d.) - 진단 요청/ 응답 메시지 설정

시작하기 전에

지난 2 회의 설명에서 (UDS 진단 통신 (1 / t.b.d.) - Transport Protocol, UDS의 개요, UDS 진단 통신 (2 / t.b.d.) - Transport Protocol 설정) 통신 프레임의 크기 제한을 초과하는 큰 데이터를 전송하기 위한 용도의 Transport Protocol(TP)과 TP의 파라미터들을 설정하는 방법을 설명하였다. 그래서 CAN의 메시지 크기 제약을 걱정하지 않고 통신을 할 수 있다는 것을 알았다. (이는 진단 통신, CAN 뿐 아니라 다른 통신에도 적용될 수 있다. 어느 통신이나 크기 제약이 있으니까. 그렇다고 모든 통신이 동일한 TP 표준을 사용하지는 않는다. 개념이 유사할 뿐이다.)

내가 원래 설명하고자 하는 것은 UDS, 즉, 진단 통신이다. UDS 진단 메시지의 크기가 큰 경우, 메시지를 어떤게 전달하는 지를 미리 설명하느라 TP를 설명하였다. 본격적으로 UDS를 설명한다. 나는 이전 블로그에서 아래와 같이 진단 통신과 UDS를 설명하였다.

• 제어기들은 자체 진단 기능이 있다. 자체 진단은 전기적 이상이나 신호 타당성 이상을 감지한다. 전기적 이상의 예로 연결이 끊어진 단선 (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에 서비스들이 잘 정의된 덕택에 TSMaster에서 (같은 종류의 다른 툴들에서도) 진단 서비스를 위한 통신을 “노 코드 혹은 로우 코드 (no code or low code)”로 구현할 수 있다. 이번에는 일부 서비스들을 예로 UDS 진단 통신을 설정하는 방법을 설명한다. 그리고 제어기를 대상으로 진단 통신을 실행하는 방법을 설명한다.

 

Basic Diagnostic Config

• UDS 표준은 진단을 위해 필요한 통신을 기능에 따라 그룹으로 구분하였다. 각 그룹에는 미리 ID를 부여한 서비스들이 있다. 아래 표와 같다.

Function group	Service ID (SID)	Service	Description
Diagnostic and Communications Management	0x10	Diagnostic Session Control	UDS는 여러 '세션' 을 정의함 정상 시작 시에는 ‘0x01 기본 세션’이 활성화됨 'Diagnostic Session Control' 서비스를 통해 세션 간 전환이 가능함. 일부 세션은 ‘0x27 Security Access’ 또는 ‘0x29 Authentication’ 같은 인증 보안이 필요할 수 있음 표준에 정의된 세션들의 예: 1. 0x01 기본 세션    - 가장 기본적인 접근 레벨    - 진단 정보 삭제, 데이터 식별자 읽기 등 기본 기능 제공 2. 0x02 프로그래밍 세션    - 업로드/다운로드 및 데이터 전송 서비스 접근 가능 3. 0x03 확장 진단 세션    - 진단/통신 관리, 데이터 전송, 입출력 제어 등 고급 기능 제공
	0x11	ECU Reset	제어기 리셋 서브-기능 Id를 지정하여 하드 리셋, 소프트 리셋 같은 서브 기능을 실행할 수 있음
	0x14	Clear Diagnostic Information	진단 코드 (DTC. diagnostic trouble code)를 삭제함
	0x27	Security Access	씨드-키 방식의 보안 접근
	0x28	Communication Control	메시지 전송을 on/off 함
	0x29	Authentication	0x27 Security Access 보다 더 진보한 인증서 기반의 보안 접근
	0x3E	Tester Present	진단 세션에  진입한 제어기는 일정 시간 동안 진단 요청이 없을 경우 기본 세션으로 자동 전환함. 이를 방지하기 위해서 진단기는 제어기에 주기적으로 Tester Present 신호를 보냄.
	0x83	Access Timing Parameters	진단기와 제어기 간의 통신에서는 특정 시간 제한을 준수해야 함. 시간을 어기면 연결이 중단된 것으로 간주됨. 시간 파라미터를 통신함
	0x84	Secured Data Transmission
	0x85	Control DTC Settings	정비 중 불필요한 DTC 저장을 방지하기 위해 결함 검출을 on/off 함
	0x86	Response On Event
	0x87	Link Control	진단 통신의 속도를 변경함
Data Transmission	0x22	Read Data By Identifier	제어기의 다양한 값을 조회할 수 있음 조회 가능한 정보: 정적 데이터: 부품번호, 소프트웨어 버전 등 동적 데이터: 센서 값 등 일반 CAN 신호와의 차이점: CAN 신호: ECU가 기능 수행을 위해 사용하는 정보 DID 데이터: 요청 시에만 전송함. 진단기를 위한 정보 차량 진단과 테스트에 필요한 상세 정보를 제공하는 중요한 서비스임
	0x23	Read Memory By Address	주소로 데이터를 읽는 서비스. 차량 진단과 테스트에 필요한 상세 정보를 제공하는 중요한 서비스임
	0x24	Read Scaling Data By Identifier
	0x2A	Read Data By Identifier Periodic	Read Data by Identifier를 자동으로 주기적으로 수행함. 시간 경과에 대한 데이터 변동을 모니터고자 할 때 사용함
	0x2C	Dynamically Define Data Identifier	지정된 데이터 식별자(DID) 풀을 사용하여 새로운 데이터 식별자를 구성할 수 있음 데이터 구성/그룹화 옵션: 1. defineByIdentifier(식별자로 정의) 2. defineByMemoryAddress(메모리 주소로 정의) 3. 위 두 방법의 조합 데이터를 유연하게 조합하고 관리할 수 있음
	0x2E	Write Data By Identifier	Id로 데이터를 메모리에 쓰는 기능
	0x3D	Write Memory By Address	주소로 데이터를 메모리에 쓰는 기능
Stored Data Transmission	0x14	Clear Diagnostic Information	Delete all stored DTC
	0x19	Read DTC Information	DTC를 읽는 기능
Input / Output Control	0x2F	Input Output Control By Identifier	진단 및 테스트 과정에서 시스템 신호를 직접 제어하고 모니터링하는 데 사용됨 옵션 바이트를 통한 제어 조건: 1. *ReturnControlToECU* (ECU로 제어 반환)    - 지정된 신호의 제어권을 장치로 반환 2. *ResetToDefault* (기본값으로 초기화)    - 신호를 시스템 전체의 기본값으로 재설정 3. *Freeze Current State* (현재 상태 고정)    - 현재 신호값을 고정 상태로 유지 4. *ShortTermAdjustment* (단기 조정)    - 제공된 값으로 신호를 일시적으로 설정
Remote Activation of Routine	0x31	Routine Control	다양한 종류의 제어 루틴을 실행할 수 있도록 함. 진단 및 테스트 루틴을 체계적으로 관리할 수 있음 세 가지 메시지 유형: 1. 시작 메시지(Start Message) 2. 중지 메시지(Stop Message) 3. 결과 조회 메시지(Results Query)
Upload / Download	0x34	Request Download	특정 위치에 대량의 데이터를 진단기에서 제어기로 다운로드 함
	0x35	Request Upload	특정 위치의 대량의 데이터를 제어기에서 진단기로 업로드 함
	0x36	Transfer Data	실제 데이터 전송에 사용되며 업로드와 다운로드 모두를 지원함. 대용량 데이터를 효율적으로 전송하기 위한 체계적인 방법을 제공함
	0x37	Request Transfer Exit	데이터 전송을 조기 종료할 때 사용함
	0x38	Request File Transfer	데이터 전송을 시작할 때 사용함

• Basic Diagnostic Config 탭에 위 표의 SID들이 미리 정의되어 있다. (일부 SID들은 정의되어 있지 않다.)
• 각 SID의 구체 사항들은 자동차사의 사양서에 따라 설정해야 한다. Diagnostic Session Control 아래에 Default Session으로 전환하는 서비스를 만드는 예제로 설정 방법을 설명한다.

 

Diagnostic Sessin Control 설정

요청(request) 설정

• (아래 그림 참조) $10 DiagnosticSessionControl을 우클릭하여 Add New Service를 한다. 그러면 새로운 10 00 DiagnosticSessionControl[숫자] 서비스가 트리에 추가된다.

Basic Diagnostic Config의 DiagnosticSessionControl에 새 서비스를 추가한다. 마우스 우클릭.

서비스가 추가된 상태

• 추가된 서비스를 선택하여 요청(Request)과 응답(Response)를 설정한다. 요청 설정 먼저 설명한다.

요청(request)와 응답(response)를 설정한다.

• DiagnosticSessionControl의 SID는 $10이다. (진단 통신에서는 16 진수를 $ 기호로 표시한다.) SID $10에는 세션을 지정하는 파라미터가 하나 있다. 

UDS 표준에 정해진 DiagnosticSessionControl의 SID와 파라미터가 미리 설정되어 있다.

• (아래 그림) Request 탭에서 파라미터를 설정할 수 있다. 파라미터 이름이 DiagnosticSessionType이다.  Value 칸에 직접 입력할 수 있다.

UDS 표준에 정의된 파라미터들은 ... 버튼을 클릭하여 창을 열어 선택하여 설정할 수 있다.

• (위 그림) 마우스 화살표가 있는 곳의 3점(…) 버튼을 클릭하면 UDS 표준에 정의된 DiagnosticSessionType들 중에서 선택할 수 있다. 

UDS에 정의된 DiagnosticSessionControl의 파라미터들

• 선택창에서 DefaultSession을 선택한다.
• ServiceName을 DefaultSession으로 바꾸면 아래 그림처럼 된다.

DiagnosticSessionControl DefaultSession으로 요청 메시지를 설정한 상태

• DiagnositcSessionControl은 그 외의 파라미터가 없다.
• Has Response를 체크하면 Response 탭이 생긴다. 언체크하면 Response 탭이 사라진다. DiagnosticSessionControl 요청에는 응답이 있을 것이라 체크한다.

응답이 있는 경우. 체크

응답이 없는 경우. 언체크. 응답 설정이 없어서 Response 탭이 사라진다.

• 요청(request) 설정은 "1차" 완료다.

응답(response) 설정

• UDS 진단 통신 (1 / t.b.d.) - Transport Protocol, UDS의 개요에서 설명한 것처럼 부정 응답 메시지의 포맷은 아래와 같고, NRC는 UDS 표준에 미리 정해져 있다. 자동차사나 협력사가 정의한 NRC가 있을 수도 있다. 어쨌든 부정 응답의 포맷은 아래 그림과 같다.

0x7F

요청한 SID

NRC (Negative Response Code, 부정 응답 원인 코드)

• 긍정 응답만 설정하면 된다.
• 기본 설정이 미리 되어있다. SID $10 요청의 긍정 응답은 $10 + $40 = $50으로 시작한다. $50에서 역으로 요청 SID가 $10 (DiagnosticSessionControl)인 것을 알 수 있다.
• $01은 요청 메시지에 있는 파라미터이다. 이를 통해서 요청 메시지를 확인할 수 있다. 응답 메시지에서 파라미터는 자동 설정된다.

응답 메시지 설정. UDS 표준에 따라 요청 메시지에 맞게 응답 메시지의 기본 설정이 되어있다.

• 기본 설정에 1 바이트가 더 있다. 맞으려니 생각하고 진단 통신을 실행해본다.

 

진단 통신 실행 (Diagnostic Console)

• Basic Diagnostic Config에서 설정한 서비스 요청과 응답을 Diagnostic Console에서 실행할 수 있다.
• Diagnostic Console 탭을 클릭한다.
• 왼쪽 진단 명령 트리창에서 앞에서 정의한 ‘10 01 DefaultSession’을 볼 수 있다. 더블 클릭하면 실행된다. 즉, 정의한 요청 메시지가 CAN 버스를 타고 제어기로 전송된다. 제어기는 응답한다.  요청 메시지와 응답 메시지가 오른쪽 아래 ISO 15765-2 탭에 표시된다.
• TP 탭에서 설정한 대로 요청 메시지의 Id는 0x7D1이다. 응답 메시지의 Id는 0x7D9이다.
• Basic Diagnostic Config에서 설정한 대로 요청 메시지는 ‘10 01’ 이다. 이를 트레이스 창에서 보면 ’02 10 01 AA AA AA AA AA’ 이다.
  • 02: 첫 바이트의 하이 니블이 0이다. 즉, SF (Single Frame)이다. 첫 바이트의 로우 니블이 2이다. 데이터 길이는 2 바이트 이다.
  • 10 01: 데이터다. 10은 Diagnostic Session Control 이고, 01은 Default Session 이다.
  •  AA AA AA AA AA: TP에서 진단 메시지 길이를 8 바이트로 설정했다. 데이터로 채우고 남은 5 바이트는 패딩 바이트인 AA로 채워진다.
• 응답 메시지는 ‘50 01 00 2D 00 C8' 이다. 이를 트레이스 창에서 보면 ’06 50 01 00 2D 00 C8 AA’ 이다.
  • 06: 첫 바이트의 하이 니블이 0이다. 즉, SF (Single Frame)이다. 첫 바이트의 로우 니블이 6이다. 데이터 길이는 6 바이트 이다.
  • 50 01: $50 - $40 = $10 이다. 요청 SID $10의 응답이다. $01은 요청 메시지의 파라미터 그대로다.
  • 00: 기본 설정에 있었던 추가 1 바이트다.
  • 2D 00 C8: 몰랐던 데이터다. 응답 설정에 없었는데, TSMaster가 응답 메시지의 길이를 참조해서 응답 데이터에 포함해 준다.
  • AA: 패딩 바이트다.

10 01 요청에 대한 응답 50 01 00 2D 00 C8

 

진단 통신 메시지를 트레이스 창에서 보면 진단 데이터에 더해서 TP 용도의 데이터들이 추가로 보인다.

• 진단 메시지를 설정한 후 실행하고 응답을 보는 것은 단 한 번의 더블 클릭으로 된다. 간단하다.
• 응답에 설정하지 않았던 바이트들을 설정해야 한다. 다시 Basic Diagnostic Config로 간다.

 

Basic Diagnostic Config 추가

• 내가 아는 통신 사양을 따라 Diagnostic Session Control 응답 메시지의 설정을 아래 그림과 같이 변경하였다.
  • Basic Diagnostic Cofig 탭으로 이동한다.
  • 설정을 하던 DefaultSession를 선택한다. (나는 문서 작성을 위해 10 01로 ChangeToDefaultSession 이라는 두 SID를 미리 설정해 두었다.)
  • Response 탭을 선택한다.
  • Parameters에 3 바이트를 추가한다. 각 바이트의 정의를 알기에 Name을 의미를 알기 쉬운 이름으로 했다.

DiagnosticSessionControl 실행으로 알게된 미정의된 3 바이트의 설정을 한다.

• 파라미터 표에서 우클릭을 하여 Parameters에 행을 추가한다. (아래 그림)

Parameters에 새 파라미터를 추가하는 방법. 표에서 우클릭한다.

• (위 그림)추가하는 파라미터의 Type을 선택할 수 있다. 한 바이트씩 읽을 데이터는 UInt (Unsigned Int) 혹은 Int(Signed Int)를 선택한다. Single은 단일 정도 소수점 실수로 32 비트다. Double은 배정도 소수점 실수로 64 비트다. Hex Array와 ASCII는 사용자가 비트 단위로 길이를 정할 수 있다. ASCII 데이터는 문자로 변환한다. Hex Array는 각 데이터 바이트가 16 진수로 변환한다. SystemVar를 이용하면 사용자가 정의했거나 기본적으로 제공되는 변수들 중에서 필요한 변수를 선택할 수 있다.
• (아래 그림) 시스템 변수를 선택하려면 + 기호를 클릭한다. 변수 선택창이 열린다.

변수 타입별 길이 [비트]. 시스템 변수를 이용할 수 있다.

• 시스템 변수, 미니프로그램, 판넬 기능 등을 이용하면 GUI를 갖춘 진단 통신 검증 자동화 프로그램을 작성할 있다. 나중에 이 방법을 별도 설명서로 만들 것이다.
• Diagnostic Console에서 바뀐 설정의 SID를 실행한다. (더블 클릭)

새 설정에 따라 응답 메시지가 잘 해석되었다.

 

마무리

• UDS의 DiagnosticSessionControl  표준에 따라 진단 서비스 메시지를 설정하고, 진단 서비스를 실행하여, 응답 메시지를 해석하는 방법을 설명하였다.
• DiagnosticSessionControl의 응답은 메시지 길이가 고정되어 설정하기가 간편하다.
• 다음에는 ReadDTC 진단 서비스의 요청 메시지와 응답 메시지 설정을 설명한다. ReadDTC의 응답 메시지는 길이가 가변적이다. 길이가 변하는 진단 메시지를 처리하는 방법과 함께 DTC 코드를 해석하는 미니프로그램을 작성하는 방법을 설명한다.