-
UDS 진단 통신 (2 / t.b.d.) - Transport Protocol 설정diagnostic 2024. 10. 25. 02:06
시작하기 전에
지난 블로그 (UDS 진단 통신 (1 / t.b.d.) - Transport Protocol, UDS의 개요)에서 TP (Transport Protocol)의 기초를 설명하였다. 실제로 TP를 구현하는 데는 몇 가지 설정이 필요하다. 그 설정 항목들을 설명한다.
개요
- Diagnostic 창의 Protocol (ISO TP) 탭에 설정 항목들을 설명한다.
Transport Layer
- ISO TP 탭에는 아래 그림에 빨간색 네모로 표시한 두 개의 설정 페이지가 있다. Transport Layer와 Diagnostic Layer이다. (Description은 미래 기능 추가를 위한 것인가 보다. 아무 내용이 없다.)
- Bus Type:
- CAN, CAN-FD, LIN, Ethernet 중에서 선택한다.
- 나는 CAN-FD를 선택했다. 내가 실험용 VDC 제어기가 CAN-FD로 통신한다.
- Channel:
- (내 경우) Channel 1에서 Channel 8까지 선택 옵션이 있다.
- 나는 TC1014를 사용하고 있다. TC1014는 총 4개의 CAN/CAN-FD 채널을 지원한다. 나는 메인 메뉴/ Hardware/ Network Hardware 설정에서 CAN 채널을 1개로 설정했다. (그래도 선택 옵션은 Channel 1에서 Channel 8까지 나온다.) Channel 1을 선택했고 잘 작동한다.
- Request Id:
- 진단기가 제어기에 보내는 메시지의 Id이다.
- Bus Type에서 CAN/ CAN-FD를 선택하면 이 항목이 생긴다. Ethernet을 선택하면 IP 주소 입력으로 바뀐다.
- 진단기는 제어기별로 전용 메시지 Id를 하나씩 갖고 있다. 이를 피지컬 어드레스 (Physical Address)라고 한다.
- 내 VDC의 경우, 진단기-to-제어기 피지컬 Id는 0x7D1이다. “VDC는 0x7D1” 이렇게 표준에 정해진 것은 아니다.
- 하지만 진단 통신에 사용되는 메시지의 Id는 0x700번 대로 표준에 정해져 있다. 0x700번 대를 이진수로 표기하면 0b111 xxxx xxxx 다. 메시지 Id의 가장 높은 번호대다. 메시지 우선 순위가 가장 번호대다.
- Request Id Type:
- Standard와 Extended 중에서 선택한다. CAN 메시지는 Standard 형식과 Extended 형식이 있다.
- 제조사의 사양에 따라 설정한다.
- 측정한 CAN 메시지를 보면 쉽게 알 수 있다.
- Functional Id:
- 차에 10개의 제어기가 있고, 진단기가 전체 제어기에 Read DTC를 요청하는 경우를 생각해보자. 진단기는 피지컬 어드레스로 각 제어기에 서비스 요청을 보낼 수 있다. “1번 제어기 Read DTC, 2번 제어기 Read DTC, …, 10번 제어기 Read DTC” 이렇게 하는 셈이다. 불편하다. “전체 제어기 Read DTC” 이렇게 한 번에 모든 제어기에 서비스 요청을 하면 편리하다. 진단기가 모든 제어기에 한 번에 보내는 메시지의 Id를 펑셔널 어드레스 (Functional Address)라고 한다.
- 현대자동차 베뉴의 경우, 펑셔널 어드레스는 0x7DF 이다. 앞에 언급한 대로 진단 메시지의 Id는 7로 시작한다. 나는 7 , D iag, F unctional로 기억한다. 0x7DF가 표준인지는 모르겠다.
- Diagnostic을 흔히 Diag(다이아그)라고 부른다.
- Functional Id Type:
- Request Id Type의 설명과 같다.
- Filled Byte:
- 진단 통신에 사용되는 CAN 메시지의 길이는 미리 정해져 있다. 메시지의 남는 빈 칸을 채우는 용도다.
- 현대차 베뉴 VDC의 경우, 0xAA이다. 아마 베뉴의 모든 제어기가 0xAA일 것이다. 아마 모든 현대차 제어기가 0xAA일 것이다.
- 예를 들어, 메시지 길이는 8 바이트인데 데이터는 6 바이트라면 남는 2 바이트는 0xAA 0xAA 이렇게 채운다.
- 패딩 바이트 (padding byte)라고 부르는 사람도 많다.
- ST Min(R)
- TP에 따라 CF(Consecutive Frame)들을 연속으로 전송할 때, CF 전송 완료 시점에서 다음 CF 전송 시작 시점 사이의 시간이 ST (Separation Time)이다. 제어기의 데이터 처리 능력 대비 ST가 너무 짧으면 데이터를 처리하지 못하는 오버플로우가 발생한다. 그래서 제어기와 진단기는 최소 ST인 STmin을 FC(Flow Control)을 통해서 조율한다. (앞선 블로그의 TP에서 설명했다.)
- 수신할 때 STmin을 ST Min(R) 이라고 하는 것 같다. (R은 Receive의 R. 수신을 Rx라고도 한다. 송신은 Tx)
- TSMaster가 수신하는 경우의 ST이다. PC는 제어기에 비해 데이터 처리 능력이 수 백배는 좋을 것이다. 나는 ST Min(R)을 0으로 설정했다. 문제없다.
- User Define ST Min(T)
- ST Min(T)는 전송할 때 STmin이다. ST Min을 사용자가 설정할 것이라면 체크한다.
- 나는 체크하지 않았다. 제어기가 FC로 정한 STmin에 따른다.
- 만약에 STmin을 검증하는 시험을 한다면 체크할 것이다.
- ST Min(T)
- User Define ST Min(T)에 체크한 경우, 설정할 STmin이다.
- Block Size(T)
- (위 그림을 한 번 더 봐주십시오.) 연속해서 전송한 CF의 데이터 크기가 Block Size이다. Block Size를 정하는 것은 연속해서 몇 개의 CF를 전송할 것인지를 정하는 셈이다.
- 나는 제어기가 FC로 정한 Block Size에 따르기 위해 0으로 했다. 문제없다.
- FC Delay(T)
- 아래 그림에서 N_Br 시간일 것으로 “짐작”한다. 나는 기본 설정 값을 그대로 사용하였다. 문제없다.
출처: CanTP — Transport Protocol, for CAN communication in AUTOSAR BSW. | by Abhishek Anand | Medium
- FD Max DLC
- CAN-FD의 경우, 최대 메시지 길이는 64 바이트이다. 하지만 진단 통신에 64 바이트를 전부 사용하지 않고 CAN의 최대 메시지 길이인 8 바이트만 사용하기도 한다. 내가 실험에 사용하는 VDC의 경우가 그렇다. 나는 FD Max DLC를 8 바이트로 설정했다. 문제없다.
- At least 8 Bytes
- 진단 요청 메시지는 대부분 4 바이트 이하로 길이가 짧다. 데이터를 CF 메시지들에 나눠서 전송하다 보면 8 바이트 보다 짧은 데이터를 보내는 경우도 생긴다. 이럴 경우 메시지 자체의 길이를 줄이지 않고 남는 바이트에는 Filled Byte (위에서 말한 0xAA)를 채워서 전송하는 것이 내가 경험한 방식이다. 나는 At least 8 Bytes가 그런 의미라고 짐작했고 체크했다. 내 VDC에 문제없다.
- FD BRS
- CAN-FD의 경우, 헤더 전송 때와 데이터 전송 때 서로 다른 속도 (Baud Rate)로 전송할 수 있다. 이를 Baud Rate Switching이라고 한다. BRS는 사용할 수도 안 할 수도 있다. 자동차사의 선택에 따른다. 내 VDC는 BRS를 사용하지 않는 것 같다. 나는 FD BRS를 사용하지 않는 것으로 설정했고 문제없기 때문에 그렇게 추정한다.
- FD BRS를 사용하지 않는다고 짐작한 추가의 이유는 현대차 베뉴의 CAN 버스에 CAN-FD가 아닌 CAN 메시지들이 있기 때문이다. CAN 메시지를 전송하는 제어기들도 진단 통신을 할 것이다. 진단 통신의 펑셔널 어드레스 메시지들을 수신해야 할 것이다. BRS를 하면 이 제어기들은 메시지를 정상적으로 수신할 수 없다. 그래서 나는 FD BRS를 사용하지 않는다고 짐작했다.
- Max Length
- TP의 이론적인 최대 값인 4095로 설정했다.
- 자동차사가 이보다 더 작게 정했을 수도 있다. 이 값을 늘리면 MCU의 메모리 크기를 늘려 부품 가격을 높일 수도 있기 때문이다. 현재까지 문제없다.
- 아래 그래프는 Claude AI에게 자동차용 MCU 100개를 선정하여 그래프를 그려달라고 요청하여 받은 것이다. 매우 편리하다. 정확성은 알 수 없으나 내 주관적인 경험과 맞는다. 4,095 바이트(4K 바이트)는 자동차 제어기에서는 큰 양이다.
Diagnostic Layer
- Diagnostic Layer의 설정 항목들은 아래 그림과 같다. Detail 버튼을 클릭하면 참조할 수 있는 그림이 나온다.
- S2Timeout, STExtended:
- 아래 그림의 설명과 같다.
- 나는 기본 설정 값을 그대로 사용하였다. 문제없다.
- S3 Server Time, S3 Client Time
- 아래 그림의 설명과 같다.
- S3 Server Time out이라는 것이 있다. 제어기는 본연의 기능을 수행하는 디폴트 세션, 진단 기능을 수행하는 진단 세션 등 여러 세션들을 갖고 있다. 세션과 동일한 정의인지 모르겠으나 모드라고 하기도 한다. 디폴트 모드, 진단 모드. 진단 모드는 익스텐디드 모드라고도 한다. 익스텐디드는 아마 디폴트 모드 대비 수행하는 기능들이 더 늘어나서(extended) 붙은 이름일 것 같다.
- 예를 들어 진단 모드에서 진단기와 제어기는 진단 메시지들을 주고받는다. 제어기는 진단기가 S3 서버 타임 아웃 시간 동안 진단 메시지를 보내지 않으면 (즉, 타이머가 아웃되면) 스스로 디폴트 모드로 전환한다.
- 제어기가 S3 서버 타임 아웃되지 않도록 진단기는 적당한 주기마다 진단 메시지를 보낸다. 이 때 보내는 메시지를 Tester Present 메시지라고 한다.
- 나는 기본 설정 값을 그대로 사용하였다. 문제없다.
Tester Present
- 진단기가 제어기로 보낸다.
- 서비스 ID는 0x3E이다.
- 서브-평션으로 제어기의 응답 필요 여부를 정한다.
- 0x80: Response not required (주로 사용된다.)
- 0x00: Response required
- Tester Present를 피지컬 어드레스로 전송할 수도 펑셔널 어드레스로 전송할 수도 있다.
- 제일 자주 사용하는 0x3E 0x80를 사용할 수도 있고, (다음에 설명할 Basic Configuration 에서 설정해둔) Tester Present 메시지를 사용할 수도 있고, 직접 정의해서 사용할 수도 있다.
SeedKey
- 진단 통신 서비스들 중 일부는 보안이 필요하다. (앞으로 반복해서 나올 테니 이름이 필요하다. 보안 서비스라 부르겠다.) 제어기는 접근 권한이 확인된 요청에만 보안 서비스를 제공해야 한다.
- 접근 권한 확인 방법은 크게 인증서 기반과 암호 기반으로 나눌 수 있다. (구체적인 방법은 나중에 별도로 설명하겠다.)
- 암호 기반의 대표적인 방법은 Seed & Key 방법이다. 제어기와 진단기는 사전에 주어진 씨드에서 키를 연산하는 방법을 공유한다. 제어기가 임의로 생성한 씨드를 진단기에 보내면, 진단기는 공유된 방법으로 키를 계산한 후, 키를 제어기에 보낸다. 제어기도 공유된 방법으로 스스로 키를 계산한다. 제어기는 진단기에서 받은 키와 스스로 계산한 키가 같을 때만 이후 진단기의 보안 서비스 요청을 수행한다.
- 사용자가 씨드에서 키를 연산하는 방법을 TSMaster게 알려주는 방법은 두 가지가 있다.
- 씨드 키 연상 방법을 DLL로 만들고, TSMaster에 DLL의 경로를 설정한다.
- 씨드 키 연산 방법의 C 코드를 TSMaster에 입력한다.
- TSFlash는 제어기 소프트웨어 업데이트를 목적으로 하는 토선의 전용 도구이다. 전용 도구가 씨드 키 연산을 하도록 설정 할 수 있다.
마무리
- 이상으로 TP 설정 항목들을 설명하였다.
- (저 스스로 모든 설정 파라미터들을 조작해보지 못했습니다. 그렇게 하려면 제가 감당할 수 없는 너무 긴 시간이 필요합니다. 제 지식과 경험으로 제 나름의 이해를 설명하였습니다. 부정확한 설명이 있을 수 있습니다. 미리 양해를 구합니다.)
'diagnostic' 카테고리의 다른 글
UDS 진단 통신 (4 / t.b.d.) - ReadDTC 응답 해석을 위 미니프로그램 (1) 2024.10.25 UDS 진단 통신 (3 / t.b.d.) - 진단 요청/ 응답 메시지 설정 (0) 2024.10.25 UDS 진단 통신 (1 / t.b.d.) - Transport Protocol, UDS의 개요 (2) 2024.10.25 현대차의 DTC(Diagnostic Trouble Code) 설명을 찾는 방법 (0) 2024.10.25