ISO 9141 Physical Layer/Data link Layer

 이번엔 구형 프로토콜 중 하나인 ISO 9141 이라는 녀석을 알아볼 차례다. 이 녀석의 경우는 KWP 2000 과 유사한 Serial 계열의 통신이기 때문에 1번과 2번이 굉장히 유사하다. 다만 이전에도 설명을 했던 적이 있는데, Initialization 을 하는 방법이 대표적으로 차이가 난다. KWP 2000의 Fast initialization 과는 달리 이 녀석은 특정한 BPS로 하는데, 이게 또 꼭 정해져 있지만은 않다. 

 물론 일반적인 ISO 9141 -2 의 경우는 정확히 스펙에서 정의가 되어 있지만 그렇지 않은 경우 각 제조사의 스펙을 따른다. 여기에서는 되도록이면 일반적인 내용만 다루도록 할 예정이며 수 많은 변종들은 직접 눈으로 확인 하길 바란다. 사실 이 프로토콜의 경우는 OBD - I 부터 쓰이던 것이기 때문에, 프로토콜 개발자의 엄청난 창의력과 상상력을 맛볼 수 있다. 

 일단 Physical Layer 부터 시작을 하자면, 따로 설명할 필요도 없이 KWP 2000 과 동일 하다. KWP 2000의 Physical Layer 를 기억하는가? 전압 레벨까지 모두 동일한데, 다른점이 있다면 이 녀석은 1:1 로만 통신을 한다는 이야기다. 여기서 주의 할 점은 메세지의 플로우가 1:1 이라는 소리가 아니라 1개의 테스터와 1개의 ECU가 통신을 한다는 이야기 이다. KWP 와 CAN 의 경우는 Functional 을 통한 1:X 가 가능했지만 이녀석은 변종이 아니라면, 반드시 한개의 ECU와만 통신이 가능하다. 

 그 이유는 Initial 방식의 차이에 있는데, KWP 의 경우는 통신 라인의 Wake up을 뜻하는 것 이였다면, 이녀석의 경우는 ECU 에게 통신 시작을 알리는 형태이기 때문이다. 그렇다면 어떤식으로 이루어 지는지 알아 보도록 하자. 

 내가 설명했던 통신신호 분석하기를 이해 했다면,  이 그림이 의미하는 것이 무엇인지 알 수 있을 것이다. 비록 독일어로 써있기는 하지만, 통신의 기본 상태인 "1"에서 시작을 해서 Start 비트인 0을 시작으로 LSB 부터 읽는 리틀엔디안 방식의 Byte 데이터 이다. 이 그림을 다시 설명하는 이유는 ISO 9141 의 Initial code 를 설명하기 위해서 이다. 

 ISO 9141 의 Initial code 는 7 비트로 이루어진 ECU의 고유 주소를 나타낸다. 이 프로토콜을 사용하는 ECU 의 경우는 각각에 설정된 고유한 Address code 가 있는데, 그 것이 바로 Initial code 가 되는 것이다. 바로 이 이유로 이 프로토콜에서는 1:1 통신 밖에 할 수 없는 것이다. 통신을 시작할 때 목표 ECU 에게 통신 시작을 알려주고 그 ECU 랑만 통신을 하게 되는 것이다. 그렇다면 대략적인 이녀석의 Initial 과정을 알아보도록 하자. 

 자 이 그림에서 간단하게 정리가 되어 있다. 고맙게도 타이밍 까지 모두 정리가 되어 있는데, 눈에 익은 녀석들도 있지만 처음 보는 녀석들도 있다. 그리고 타이밍의 경우 Initial code 를 보내기 전에 대기하는 W5, 그리고 Sync byte 가 오기 까지 기다리는 W1, 그리고 Key byte 와 연관이 된 W2, W3 그리고 메세지 블럭 타이밍인 W4로 이루어져 있다. 여기서 이렇게 까지 세분화 되어 있는 이유는 이 녀석은 통신 BPS가 변하기 때문이다. 

 먼저 설명을 했다 시피 Initial code 를 보내는 BPS 는 메이커 별로 정해져 있다고 말을 했었다. 예를 들면 일반적인 스펙에서의 녀석은 5 BPS 로 Initial 과정을 거치게 되는데, 이후 본래의 통신 속도로 Sync byte 를 응답하게 되어 있다. 변경되는 BPS 역시 메이커 별로 다르지만, "대부분" 9600 이나 10.4 K BPS 를 사용한다. 대부분 이라고 한 이유는 당연히 이외의 속도가 존재하기 때문이다. 

 그렇다면 Sync byte 에 대하여 알아보자. 통신 속도가 변경이 되는 연유로 이 프로토콜에서는 특별한 바이트가 사용이 되는데 이 바이트의 목적은 아주 단순하게 통신 속도 확인을 위한 것이다. 

 아주 단순하게 생겼지만 속도 확인이 용이하도록 1 0 1 0 1 0 1 0 의 모습을 하고 있다. 즉 "0x55" 가 싱크 바이트 인 것이다. 간혹 여러가지 연유로 통신 속도를 찾아야 할 경우 이녀석을 보는 것이 가장 확실하고 정확한 방법이다. 

 이제 익숙한 Key byte 를 살펴볼 차례 이다. 이 녀석은 이름 그대로 KWP 2000 의 그 녀석이다. 예전에 설명을 할 때 ISO 9141 에서도 Key byte를 사용하며, KWP 라고 부르기도 한다고 했었다. 그 이유는 이 녀석도 Key byte 의 설정을 그대로 따르고 있기 때문인데 간혹 차이가 있는 녀석은 Key byte 에 추가적으로 Byte 가 붙는 녀석들이다. 그 녀석들은 해당 모듈의 Part number 를 나타내는 부분일 경우가 많은데, 붙는 이유는 같은 Address 를 사용하는 경우 차이를 두기 위해 코드를 심는 경우이다. 대부분의 경우 Address 를 다르게 두어 만들기는 하지만, 일부 메이커의 경우 "C1", "C2" 라는 인자를 두어 구분하기도 한다. 이런 경우에는 대부분 코드의 신뢰성을 위해 CS 가 따라 붙는다. 

 혹시 이 그림이 이해가 되지 않는 다면, Keyword Protocol 2000 #Part 2 - Data link Layer 를 다시한번 곱씹고 오기를 바란다. KWP 2000 과 동일한 Key byte 의 모습이다. KWP 2000 과의 가장 큰 차이점은 ISO 9141 은 TGT와 SRC를 반드시 사용을 해야 할 필요가 없다는 점이다. 

한번 설명을 했던 그림인데, KWP 2000 의 경우는 FMT가 "8X' 인 녀석들이 주로 다뤄 졌었다. 하지만 ISO 9141 은 그렇지 않다. 물론 Key byte 의 해석은 동일하게 하면 되지만, FMT가 다른 처음 보는 녀석들이 등장하게 된다. 

 이 그림 역시 한번 나왔던 그림인데, 여기서 1 Byte FMT 및 변종 FMT 에 대해 설명을 했었다. 설명에서 1 byte는 랭스가 될 수도, ECU의 ID가 될 수도 있다고 이야기를 했었는데, 그 녀석들의 대부분이 ISO 9141 에서 쓰이는 녀석들이다. 더 정확한 설명을 위해서 다음표를 보자. 

 FMT의 모습이다. "HM0"과 "HM1" 을 기억하는가? 그 녀석이 여기에 설명이 되어 있다. 일반적인 HM2, 3 의 경우는 이미 KWP 2000 에서 다뤘기 때문에 따로 설명하지 않겠다. 

 HM0 의 경우는 FMT 가 "0x3X" 이하로 시작하는 녀석들이다. 무언가 익숙하지 않은가? KWP 2000 에서 다루는 최대 랭스의 길이가 0x3F 라고 했었다. 감이 오는가? 그렇다 이녀석은 바로 랭스를 뜻한다. 표에서도 설명이 된 것과 같이 이 녀석은 헤더에 Address 정보를 가지고 있지 않은 랭스로만 이루어진 녀석이다. 대부분의 "구형" ISO 9141 은 이 녀석의 모습을 하고 있다. 

 HM1 의 경우는 FMT 가 "0x4X" 혹은 "0x6X" 로 이루어진 녀석을 말한다. 물론 변종도 있을 수 있으나, 대부분 이 영역을 사용하는 녀석들은 "상용" 프로토콜이다. 바로 이 녀석이 그 유명한 ISO 9141 - 2 라는 뜻이다. 이런식으로만 본다면 재미도 없고 이해도 되지 않으니 예를 보면서 이해를 해보도록 하자. 

HM0

Tester : [02] B0 00 B2 

ECU   :  [06] F0 AA 10 32 10 01 F2

Tester : [02] 11 00 13 

ECU   :  [21] A1 04 00 00 00 00 00 00 00 00 00 00 00 01 FE 02 00 00 6F 49 49 6C 57 55 F4 0E D8 2B D3 EB 3F 01 07 E3

Tester : [02] 10 00 12 

ECU   :  [20] A0 20 39 30 30 37 36 38 34 33 20 30 36 39 36 20 30 36 39 36 20 30 32 39 39 20 30 31 33 20 33 06 6A

HM1

Tester : 48 [06] 0F 00 56 00

ECU    : 48 [12] 8F 00 18 20 31 26 01 01 03 51 98 51 98 A0 E8 03

Tester : 48 [07] 28 22 07 99 00

ECU    : 48 [06] A8 48 37 01

Tester : 48 [06] 50 01 98 00

ECU    : 48 [06] D0 01 18 01

 자 둘의 차이점이 보이는가? HM0 에서는 첫 번째 바이트가 바로 랭스로 쓰였으며, CS를 제외한 Byte의 길이를 나타낸다. HM1 의 경우는 "0x48"의 FMT를 가지는 녀석의 통신 상황을 보여준다.

 이제 나머지 두 가지인 K2/Add compl. 에 대해 알아보자. 이 두 부분은 Initial 단계가 끝났다는 내용을 보내주면 내용에 대한 응답이 올라오는 부분을 나타내는데, 이 표시를 주는 방법은 크게 두 가지로 나누어 진다. 첫 번째의 경우는 대부분의 경우인 HM1, HM2, HM3 에서 사용하는 오픈 코드를 보내는 방식이다. 이 경우는 크게 따로 구분이 될 필요가 없을 정도로 익숙한 명령이 보일 것이다. 문제가 되는 녀석은 바로 HM0 녀석이다. 이 녀석은 Complete 명령을 보내는 것도 특이한데, 한 바이트로 보내게 되고 그 바이트는 K2 에 의해 결정된다. 괜히 "K2" Compl. 가 아닌 것이다. 사실 굉장히 간단하게 K2의 Byte를 비트 반전시킨 값을 보내주면 된다. 그렇게 K2 Compl.를 보내면 ECU 에서는 거의 ECU의 Information 로 구성된 Add compl.를 보내 과정이 완료 되었음을 알린다. 역시 잘 이해가 되지 않을 테니 예를 보면서 설명을 하도록 하겠다. 

HM1, HM2, HM3

5BPS          : 33

Sync          : 55

K1              : EF

K2              : 8F

K2 Compl.   : 82 10 F1 10 83 16

Add Compl. : 81 F1 10 50 D2

HM0

5BPS          : 33

Sync          : 55

K1              : 52

K2              : 80

K2 Compl.   : 7F

Add Compl. : 20 A0 20 39 30 30 37 36 38 34 33 20 30 36 39 36 20 30 36 39 36 20 30 32 39 39 20 30 31 33 20 33 06 6A 

 두 녀석의 차이가 확실하게 보이지 않는가? 사실 HM0 의 경우는 대부분의 변종들이 베이스로 택하고 있는 경우가 많다. 이후의 내용은 KWP 2000 과 완전히 동일하다. 메세지 포멧이 변경이 된 변종들을 제외한다면, 일반적으로 KWP 2000 에서 사용하는 타이밍을 크게 벗어나는 일은 거의 없다. 

 오늘의 포스팅을 통해서 구형 프로토콜인 ISO 9141 에 대해 "대략적"으로 살펴봤다. 사실 이 프로토콜의 경우는 정해진 상용스펙을 따르는 경우보다 그렇지 않은 경우가 더 많기 때문에, 분석을 위해서는 많은 작업이 필요한 프로토콜이다. 다만 정해진 스펙을 따르고 거의 예외가 없는 KWP 2000 이나 CAN 보다는 분석하는 재미가 더 있는 녀석임에 틀림이 없는데, 이쪽 계통의 일을 한다면, 수많은 변종 프로토콜을 만나게 될 것이다. 그런 프로토콜들을 만났을 때 어느정도 가이드 라인을 해주는 것이 바로 공식 스펙이다.