본문 바로가기

조금은 전문적인 이야기/자동차 통신

Keyword Protocol 2000 #Part 2 - Data link Layer


 이번엔 Keyword Protocol 2000 의 두번째 섹션인 Data link Layer 에 대해 다뤄 보도록 하겠다. 미리 이야기를 하지만 이 녀석은 어렵다. 이전까지의 내용도 쉽진 않았겠지만, 이 녀석은 특히나 어렵다. 게다가 설명만으로는 부족하며, 실제 차량과의 통신에서 직면하게 되는 문제의 대부분이 이 녀석의 문제이다. 고로 이 녀석만 이해를 하면 해당 프로토콜의 대부분의 이해를 하고 있다고 볼 수 있는 것이다. 사실 이 녀석의 분석이 통신분석의 가장 재미 있는 부분이자 골때리는 부분이기는 하다. 미리 정의가 되어 있는 문서나 자료가 있다면 쉬운 문제이지만, 그렇지 않은 경우 프로토콜 제작자의 엄청난 창의력을 보게 되는 부분이기 때문이다. 


 각설하고, 먼저 이전에 설명을 했던 OSI7 Layer(Open Systems Interconnection Reference Model) 에 대해 간략하게 설명을 하면서 시작을 해보자. 이전에 설명을 했던 부분은 PC Communication 에 대한 부분 이였는데, 일전에도 한번 설명을 했던 것 처럼 자동차의 통신에서는 세가지 부분만 쓰인다. 


 그림을 보면 알겠지만, 3번 부터 6번 까지는 쓰이지 않는다고 되어 있다. 그리고 이전에 설명을 했던 Keyword Protocol 2000 #Part 1 - Physical Layer 는 당연히 1번을 뜻하며 간략하게 설명을 했던 SID(Service Identifier)와 PID(Parameter Identifier)의 기초 가 7번이 되시겠다. 7번에 대해서는 차후에 다시 다루겠는데, 대부분의 자동차 통신용 프로토콜은 해당 Layer 를 공통으로 사용을 하기 떄문에 프로토콜 별로 설명할 필요는 없다. 단! UDS(Unified Diagnostic Services) 라고 부르는 녀석은 나중에 추가가 된 녀석으로 7번이 다른 녀석이다. 


  간략하게 통신에 대해 설명을 해보자면, 크게 보면 두 가지의 방식으로 이루어 진다. 일전에도 설명을 했는데, Gateway가 있는 녀석과 없는 녀석이다. 



 이 두녀석의 차이점은 개별 SRC Address를 사용 하는 녀석과 통합 SRC Address 를 사용하는 차이점이다. 사실 이에 대한 부분은 CAN에서 설명하는 편이 더 편하기는 한데 간략하게 설명을 하자면 개별형의 경우는 각 ECU 별로 고유한 ID를 가지고 있으며 1:1로 통신이 가능한 녀석이고 통합형의 경우는 ECU 들이 하나의 ID로 통신을 하는 형식이다. 좀 더 쉽게 설명을 하자면, 개별형의 경우는 Body 계열의 계기판, 에어컨등의 ID가 모두 따로 책정이 되어 1:1로 통신이 가능하지만, 통합형의 경우 Body 의 통합 ID 하나로 SID의 응답에 따라 지정된 Position 에서 해당 모듈의 값을 읽을 수 있다. 그리고 좀 더 세분화를 해보면 각 통신 타입 별로 Physical addressing 과 Functional addressing 으로 나누어 지는데, 이는 그룹별 통신을 뜻한다. 쉬운 말로는 1:! 통신과 1:X 통신을 뜻하는 것이다. 즉 Request 하나에 응답이 한개의 ECU에서 오는냐 여러개의 ECU에서 오느냐의 차이이다. 


 먼저 우선이 되어야 할 부분은 통신의 속도를 찾는 것이다. 찾는 방법은 통신 신호 분석하기 에서 설명을 해 놓았다. 대부분의 KWP2000 의 통신 속도는 10417 BPS로 이루어 지며 간혹 9600 BPS로 이루어져 있다. 물론 각 메이커에 따라 통신 속도는 다를 수 있으니 가장 좋은 방법은 분석하고자 하는 메이커의 문서를 찾는 것이 제일 좋으며 여의치 않을 경우 스코프로 찾아야 한다.(쉽진 않겠지만...) 어느정도의 마진 폭이 있으니 대략적인 속도만 맞추더라도 통신은 가능하다. 


 그러면 이제 통신을 시작해 보자. 일반적인 KWP 2000 의 경우는 Fast initialization 을 시작으로 통신을 시작하게 된다. 이 부분의 필요성은 통신의 신뢰성을 위해서 통신이 시작된다는 것을 알리는 부분이다. 솔직한 심정으로는 이 녀석의 필요성이 그리 크지는 않다고 느끼지만, 통신 라인상의 오작동을 일으킬 우려가 있어 만들어 놓은 것이다. ISO 9141-2 에서는 5 BPS Initial 로 이 녀석과 비슷한 녀석이 있고 숫자는 적으나, 통신라인에 아날라이져가 물려있는 경우 이 부분이 필요 없는 경우도 있다. 



 그림을 보면서 설명을 하자면 T idle이라는 부분은 통신라인의 기본 상태를 뜻한다. Physical Layer 에서 설명 했던 것과 같이 기본상태는 VCC의 High 상태이다. 여기서 T iniL를 통해 전압을 내려주고 다시 올려준 뒤에 통신 신호를 보내게 된다. 이 작업이 이루어지지 않으 채로 통신신호를 보내 봐야 ECU에서는 아무런 응답이 없다. 전압을 내리는 시간과 올리는 시간도 정해져 있는데, 마진 폭이 그리 크지 않기 때문에 조금 민감한 부분이라 할 수 있다. 하지만 실제 통신을 해보면, 사실 규격보다는 마진폭이 넉넉하게 설정이 되어 있다. +/- 5정도로 보면 되는데, 간혹 민감한 ECU의 경우는 제대로 통신이 이루어지지 않기도 하다. 통신 분석시에 시작 조차 제대로 되지 않는다면 이녀석일 확률이 대부분 이다. 


 그럼 이제 보내야 하는 메세지를  확인을 할 차례인데, 전의 포스팅에서 SID 에 대해 다루면서 간략하게 설명을 한 적이 있지만 다시 제대로 설명을 하도록 한다. 



 이것이 KWP 2000의 기본적인 메세지 포멧이다. Fmt + Tgt + Src + Len 으로 이루어진 Header 가 있고 Sid + Pid + Data 로 이루어진 Data 가 있으며 마지막으로 CS로 마무리가 된다. 크게 3등분을 해서 볼 수 있는데 각 부분에 대해 설명을 하자면 Fmt의 경우는 Format Byte로 메세지의 형식을 정의한다. 



 보면 알겠지만 비트별로 분리를 하자면 이런식으로 규격이 정해진다. A0 부분이 위에서 말을 했던 Physical addressing 인지 Functional addressing 인지 정의가 되는 부분이다. 간단하게 말해서 0x8X로 시작이 되면 Physical 이고 0xCX로 시작이 되면 Functional 이라는 이야기 이다. A1 부분이 0 이 되는 HM0 과 HM1 의 경우도 있으니 보게 되더라도 놀랄 필요는 없다. 기본적으로 HM0과 HM1의 경우도 메세지 포맷은 비슷하다. 덫 붙이자면 아래에 이야기를 하겠지만 사실 전체적인 메세지의 포멧을 결정하는 것은 Key byte 라는 녀석이다. Fmt 는 메세지 형식을 결정 하는 것이 아니라 결정된 메세지 형식을 보여주는 것이다. 



 L5 ~ L0 까지 이루어진 부분은 메세지의 길이를 뜻하는 Len 을 뜻한다. 이는 Key byte 에 따라 Fmt 에 포함이 될 수도 있고 되지 않을 수도 있다. 단 예외가 있다면 Fmt 에 포함될 최대 Len의 길이는 0x3F 개 이다. 딱봐도 비트가 6개 밖에 없으니, 그 이상이 포함되려면 Fmt 에서 분리가 되어야 한다. 기본적으로 Len은 0xFF 개, 즉 255개 까지 지정이 가능하다. 단 트윅이 된 프로토콜에서는 그 이상의 데이터도 지정이 가능하기는 하다.



 이 메세지 포멧을 보면 Len이 Fmt에 포함이 된 녀석과 그렇지 않은 녀석의 차이점을 알 수 있다. 그리고 나머지에 대해서 설명을 하자면 Tgt 의 경우는 Target address 로 메세지가 보내질 녀석의 ID가 되겠고, Src 는 메세지를 보내는 녀석 즉 Source address 가 된다. Sid 에 대해서는 간략하게 설명을 했었고 이후 7번에 대해 다루면서 자세하게 이야기를 할 예정이다. Data 부분은 말그대로 Pid 와 Data 를 뜻하며 CS 의 경우는 Check sum 으로 메세지가 끝났다는 것을 알려주는 것이자 메세지의 신뢰도를 알려주는 부분이다. 


 메세지 포멧을 보면 알겠지만, KWP 2000 에서는 두 부분으로 메세지의 신뢰성을 보장한다. 첫 번째로는 Len의 길이를 지정해서 해당 메세지가 가지고 있는 길이를 말해주며, CS로 Length 만큼의 데이터를 받았을 때 그 메세지가 제대로 된 메세지 인지를 판별하는 것이다. 이러한 이유로 솔직히 Fast initial은 필요가 없기도 하다. 


 추가로 표만 본다면 이해가 잘 되지 않으니 간단한 통신 데이터를 보면서 설명을 해보자면 다음과 같다. 


Request        :    81 C7 F0 81 B9      

Response      :    83 F0 C7 C1 E9 8F 73


 이런식으으로 통신이 이루어 졌을 때 Request 의 0x81 은 Fmt 를 뜻하며, 0x8X Physical addressing 을 사용하는 1:1 방식의 통신이고 랭스는 0x01 로 Fmt에 포함이 되어 있으며 한 바이트 이다. 그리고 통신을 하고자 하는 ECU의 ID 는 0xC7 이며, 테스트 장비의 ID 는 0xF0 로 책정이 되어 있다. 그리고 Sid는 0x81로 통신 오픈을 뜻한다. 응답 패턴을 보면 Fmt 가 0x83 으로 1:1 방식의 랭스가 0x03 개 이며 0xF0 로 Request를 보내온 테스터에게 보내는 메세지 이다. 0xC7의 ID를 가진 ECU가 보내는 메세지 이며, Sid는 0xC1 으로 0x81 에 대한 긍정응답이다. 그리고 뒤에 붙는 0xE9 와 0x8F 가 Key byte 이다. 두 메세지 모두 전체 코드를 더하면 0xB9 와 0x73 으로 끝나는 CS를 가지고 있다. 

 자 그럼 이제 이 녀석이 KWP 2000 인 이유인 Key byte 에 대해 알아보자. 사실 Key byte는 KWP2000 에서만 쓰이는 것은 아니며, 일부 ISO 9141 -2 에서도 쓰인다. 그리고 더 명확하게 말을 하자면, ISO 9141 - 2 에서도 Key byte를 사용하는 녀석은 KWP 프로토콜이라고 부르기도 한다. 나중에 설명을 하겠지만 둘의 차이는 Initial 의 방식에 있다. 즉 ISO 9141 -2 와 KWP 2000 의 중간에 낀 녀석이 존재 한다는 이야기다. 


 이야기가 좀 샛는데 본격적으로 설명을 해보자면, 이 통신 오픈을 한 뒤에 오는 Key byte로 전체적인 통신 메세지의 포멧이 정의가 된다. 사실 ECU에서는 이미 설정이 되어 있는 것을 알려주는 것이 불과 한데, 쉬운말로 이야기를 하면, 테스터가 "통신을 시작하자" 고 보내면 ECU에서 "이런 식으로 메세지를 줘야 해" 라고 응답하는 것이다. 



 문서를 누가 만들었는지는 몰라도 참 개떡같이 만들었다고 생각하는 부분인데, Key byte 의 부분은 바이트의 위치가 거꾸로다. 즉 먼저온 바이트가 KB2 가 되는 것이고 나중에 온 녀석이 KB1 이 된다. 영어로 되어 있으니 뭔가 어렵게 느껴질 테지만, 풀어서 설명을 하자면 다음과 같다. 



 위 쪽의 예를 들어서 보여준 코드의 Key byte 에 대한 분석도 포함이 되어 있는데, 예에서 받은 코드의 형식은 이 ECU는 Fmt 에 Len 이 포함이 되어야 하며, Len 의 분리가 되지 않으니 최대 Data 의 길이는 0x3F 개로 정의가 된다. 그리고 Header 는 1 byte 이상의 TGT/SRC 가 포함이 된 형식이며, 타이밍은 일반 타이밍으로 통신을 한다. 


 이런 식으로 Key byte 의 분석이 이루어 지는데, 정의 문서에는 각 Key byte 별로 정리가 되어 있는 테이블이 있다. 일반적인 녀석들의 테이블 이며, 이 테이블에서 벗어난 창의력이 풍부한 녀석들도 있으니 맹신하면 안된다. 



 추가적으로 위의 메세지 포멧에 나오지 않았던 모드들에 대한 설명을 하자면, Key byte 세팅에서 가능 한 것 처럼 Header가 변경이 되는 녀석이 있다. 



 한바이트 헤더에 대한 메세지 포맷이 추가가 되어 있는데, 한바이트 일 경우 Fmt가 단순하게 ECU의 ID를 뜻하기도 하며 Len을 뜻하기도 한다. 이는 Key byte 의 조합으로 결정이 되는 것이다. 


 자 그렇다면 이제 메세지 형식을 알아냈고, 메세지를 조함 할 수 있게 되었는데 어떤 타이밍으로 메세지를 보내야 하는가에 대한 문제가 남았다. Key byte 에서 타이밍에 대한 부분이 있는데, 일반 타이밍과 확장 타이밍에 대한 부분이다. 설명하기 앞서 기본적인 타이밍에 대해 이해를 해야 한다. 



 그림에서 설명이 된 작은 직사각형 박스는 하나의 Byte 를 뜻하는 것이며, 메세지의 타이밍에 대한 설명이 되어 있다.


P1 : ECU Response의 Byte 간 타이밍

P2 : ECU 의 통신 대기 타이밍

P3 : 테스터의 통신 대기 타이밍

P4 : 테스터의 Byte 간 타이밍


 사실 이부분은 실제로 차량에서 통신을 하며 스코프를 찍어보며 봐야 이해가 되는 부분이기는 하다. Key byte와 함께 Data link에서 핵심을 이루는 부분이기 때문에, 정확하게 이해를 하고 있어야 하는 부분이다.



 일반적으로 접하는 일반 타이밍에 대한 표다. P1은 0~20 ms로 정의되며 P2는 25~50 ms. 그리고 P2*은 25~5000 ms로 정의가 되어 있다. P*의 경우는 통신이나 세션이 오픈이 되었을 때, 해당 타이밍 내에 통신을 하지 않을 경우 닫히는 제한시간을 뜻한다. P3의 경우는 55~5000 ms로 설정이 되어 있는데, 일반적인 경우 55 ms 내에 응답이 와야 하며, 네가티브 펜딩이 걸렸을 경우 5000 ms 까지 늘어난다는 이야기 이다. 네가티브 펜딩에 대해서는 7번을 설명할 때 함꼐 설명을 하겠지만, 0x7F 로 네가티브 응답이 오는 경우 PID의 종류에 따라 이유가 나온다. 펜딩을 뜻하는 0x78 은 말그대로 처리가 늦어지니 대기하라는 응답이다. 마지막으로 P4는 5~20 ms로 책정이 되어 있다. 



 일반적이지 않은 확장 타이밍이다. 확장 타이밍의 경우 0x83 SID를 통해 지정이 가능하며, 지정이 가능한 범위는 해당 테이블과 같다. 타이밍 지정은 ATP(Access timing parameter) 라고 부르는데 지정을 하는 방법은 메세지를 통해서 가능하다. 



 이 부분 역시 다음에 다시 설명을 하겠지만, PID를 통해 모드 선택이 가능하고 각 포지션 별로 P2~P4가 지정이 되어 있다. 그리고 해당 타이밍의 연산표는 다음과 같다. 



 솔직히 말을 하자면 확장 타이밍의 경우는 거의 쓰이지 않는다. 확장 타이밍을 지원 하더라도 일반 타이밍을 포함하고 있기 때문에, 별다른 세팅 없이 일반 타이밍으로도 통신은 잘 이루어 지기 때문이다. 다만 Reprogramming 등의 특정한 타이밍이 필요한 경우는 반드시 설정을 해 주어야 한다. 


 끝으로 정리를 하자면, 이번 포스팅에서는 통신의 시작과 메세지 포맷, 그리고 통신 타이밍에 대해 정의를 설명 했다. 1번에서 신호 레벨과 통신 PIN 지정을 했고, 이번에 메세지의 형식과 타이밍을 지정을 했으니 7번의 SID와 조합을 하면 통신이 어떤식으로 이루어 지는지는 어느정도 감이 왔을 것이다. 사실 이 내용들이 쉬운 내용은 아니기 때문에 직접 차량에서 통신을 해보고 문제를 접해 봐야 잘 이해가 되는 부분도 있을 것이다. 한두번 글을 읽는 것으로는 절대로 이해가 되지 않는 내용들이니 어느정도의 경험이 생긴 뒤에 다시 읽어 보면 이해가 될 것이다.