CAN(Controller Area Network) #Part 2 - Data link/Network Layer

 이 부분을 쓸 생각을 하니 벌써부터 머리가 아파온다. 아마 이제까지 다루었던 부분 중에 가장 어려운 부분이 될 것 같은데...하나하나 차근차근 보도록 하자. 이 부분을 정확히 이해를 하고 있다면, CAN(Controller Area Network) 이라는 프로토콜의 대부분을 이해하고 있는 것이다. 그럼 먼저 늘 그렇듯이 OSI 7 Layer 부터 시작을 해 보자. 

 CAN 은 크게 세가지의 분류로 나누어 진다. 상용 트럭을 뜻하는 HD 인 부분과 일반적인 상용 프로토콜로 쓰이는 Standard 그리고 트윅이 된 Legislated 가 있다. 각 종류에 대한 부분은 표기된 문서에서 정의가 되어 있으니, 더 필요한 자료가 있거나 더 깊은 이해를 필요로 한다면 해당 문서를 찾아서 보길 권한다. 해당 문서를 보기전에 이 포스팅을 본다면 꽤나 많은 도움이 될 것이다. 

 전에 KWP 2000 을 설명하며 자동차 통신에서는 세가지의 Layer 만 쓴다고 했었다. 그런데 가만히 보니 거짓말이지 않은가!! 7개 전부를 사용하고 있다. 그건 맞기도 하고 틀리기도 하다. 사실 2번 부터 6번까지는 Data link layer라고 할 수 있을 정도로 맞는 부분이며 정의하는 문서들만 봐도 Standard 의 경우는 3가지 종류이다. 이런 연유로 이번 포스팅에서는 2번 부터 6번을 아우르는 내용을 포스팅 하게 되었다. 이미 설명을 했던 KWP 2000 의 Data link Layer 부분에서는 크게 세가지 부분을 다뤘는데, 통신 Initialization 과 메세지 포멧, 그리고 타이밍이였다.  CAN 에서는 거기에 더해서 Network Layer 부분인 메세지 컨트롤 부분이 추가가 된다. 그럼 하나씩 알아가 보도록 하자. 

 CAN(Controller Area Network) 의 대략적인 메세지 포맷이다. 살펴보면 SOF 라는 부분과 EOF 라는 부분이 보이는데 이 부분이 Initialization 부분이다. KWP 2000 의 Initialization 과는 약간 다른 부분인데, KWP 2000 의 경우는 통신 시작을 위한 것 이였다면, CAN 의 경우는 메세지 프레임을 보내기 위한 것이다. 간단하게 말하면 시리얼 통신의 Start bit와 동일한 목적을 가지고 있다. EOF의 경우는 마찬가지로 Stop bit 를 뜻한다고 보면 이해하기 편할 것이다. 

 조금 다른 관점으로 보이는 메세지 프레임의 형식이다. ID 부분이 좀더 세분화 되어 표현이 되어 있는데, 이 그림에서는 11 bit ID 와 29 bit ID 의 차이를 보여준다. 뒤 쪽에 붙는 CRC와 ACK의 경우는 CAN controller 에서 처리를 하는 부분이기 떄문에 실제로는 다룰 필요는 없지만, HW 적으로 관심이 있는 분들을 위해 간략하게 나마 설명을 하겠다. 

 먼저 CRC에 대한 부분이다. 이 부분은 KWP 2000의 CS 처럼 데이터의 신뢰성을 위해 있는 부분이다. 정해진 계산 방식을 통해 CAN 메세지의 합을 보내는데, 일반적인 Analyzer 를 통해 메세지를 보게 되면 나오지 않는다. 오직 실제 스코프로 찍었을 경우만 나오게 되는데, 혹시나 궁금하다면 찍어보면 쉽게 확인 할 수 있다. 기본적인 계산 방식은 SUM이다. 

 ACK 에 대한 부분은 통신라인이 살아있는지에 대한 체크를 하는 부분이다. Sync 형식으로 이루어진 CAN에서 라인의 데이터가 신뢰성이 있는지를 체크하는 두번쨰 부분이기도 하는데, CRC 가 데이터의 내용을 확인 하는 부분이라면 ACK 는 통신라인의 신뢰성을 확인하는 부분이다. CRC 와 마찬가지로 일반적인 통신화면으로는 보이지 않는다. 바로 이 녀석들 떄문에 일반적인 시리얼 방식으로는 CAN은 통신이 되지 않는다. Single 의 경우 한 라인을 사용하기 때문에 가능할 것 처럼 보이지만, 첫 번째로는 통신 속도에 대한 타이밍 때문에 통신이 되지 않으며, 설사 그 부분이 처리가 되었다고 하더라도 메세지 포멧 부분의 처리를 하지 못한다면 통신이 불가능 하다. 게다가 이 부분은 스코프로 찍지 않는 이상 볼 수 조차 없다. 

 그렇다면 실제로 쓰이는 데이터의 모습은 어떠할까? 우리가 다룰 부분은 크게 세가지로 나누어진 Bit stuffing 이라는 부분이다. 해당 부분은 다음과 같다.

 Arbitration Field, Control Field, Data field 이 세가지 부분이 여기서 다룰 부분이다. 여기까지가 대략적인 그림이였다면 이후 부터는 굉장히 머리가 아픈 어려운 부분이다. 먼저 Arbitration Field 에 대해서 알아보자. 

 이 표는 Arbitration field 와 Control Field 까지 쓰이는 비트들을 정의해 놓은 것이다. 각 비트별로 쓰이는 부분이 있는데, 이 표를 알아보기 편하게 바꿔주면 다음과 같다. 

11 bit Identifier

29 bit Identifier

 위에서 봤던 그림을 좀더 세분화 해서 비트 단위로 정리가 되어 있는 것인데, 표와 매칭을 해서 살펴보면 쉽진 않겠지만 어느정도 이해는 가능 할 것이다. 11 Bit의 경우는 0X XX 로 이루어진 ID로 통신을 하는 것이며, 29 bit 는 1X XX XX XX 이렇게 네 바이트로 이루어진 ID로 통신을 하게 된다. 좀더 쉬운 이해를 위해 예를 들자면 각 Bit type 별 통신 데이터는 다음과 같다. 

11 bit Identifier

07E0     01 20 00 00 00 00 00 00

07E8     01 60 AA AA AA AA AA AA

29 bit Identifier

18DA00FA     03 22 F1 00 FF FF FF FF

18DAFA00     07 62 F1 00 00 02 02 03

 풀어서 설명을 하면 07E0/07E8 이 11 bit 의 ID 부분이 되는 것이고 18DA00FA/18DAFA00 부분이 29 bit 의 ID 부분이 되는 것이다. 여기서 살펴보면 재미있는 부분이 있는데, 11 bit 의 경우는 고유한 ID 체계를 가지고 있지만 29 bit의 경우 KWP 2000 과 유사한 부분이 있다. 18 DA 인 부분을 제외하면 KWP 2000 의 TGT/SRC 와 동일한 성격을 가지고 있는 것이다. 두 가지 형태 모두 KWP 2000 처럼 Physical addressing 과 Functional addressing 을 쓸 수 있는데, 특정하게 세팅이 된 ID 가 있으며, 그 것은 스펙 문서에서 확인을 할 수 있다. 단 메이커 별로 차이가 있을 수 있으니, 한 가지라고 생각 하면 안된다. 

 그리고 ID 부분에서 추가로 설명을 할 부분이 있는데, 그 부분은 바로 Extended 모드이다. 29 bit의 경우는 여태까지 본적은 없는데, 11 bit 의 경우 왕왕 접하는 것이 바로 이 녀석이다. 메이커 별 트윅이라고 생각을 할 수 있는데, 당연히 공식 문서에 정의가 되어 있다. 

 이 표를 보면 Addressing 이라고 부르는 부분이 ID를 넘어가 있는 것을 볼 수 있는데, 두 가지 타입이 모두 존재한 다는 것이다. 즉 ID가 정해진 바이트 외에 +1 이 될 수 있다는 이야기다. 예를 들어 설명을 하자면 다음과 같다. 

11 bit Normal Identifier

07E0     [01] 20 00 00 00 00 00 00

07E8     [01] 60 AA AA AA AA AA AA

11 bit Extended Identifier

07B0     04 [02] 10 81 00 00 00 00

07C0     F1 [02] 50 81 00 00 00 00

 자 두 형식의 차이를 보면 Normal 의 경우 ID 다음에 바로 Control field 가 왔으나, Extended 의 경우는 ID 뒤에 한 바이트가 더 붙어 있는 것을 볼 수 있다. 이 한바이트가 Addressing 을 통해 추가된 Sub ID 라고 보면 된다. KWP 2000 의 Gateway 를 통한 통신 방식을 기억하는가? 한개의 ID로 여러개의 모듈을 통신하는 타입이 있다고 이야기를 했었는데, 바로 그 부분이 이 녀석이다. 그때 CAN에서 설명을 하는 편이 이해하기 편하다고 이야기를 했었다. 그 이유는 다음과 같은데, Extended 모드의 경우는 ID가 한개로 정의가 되어 있으며, 뒤쪽의 Sub ID로 통신하는 모듈이 갈린다. 이 모드가 존재하는 이유는 CAN 의 통신 라인에 있다. 두 개의 통신라인을 쓰기 때문에, 그룰별로 나누기가 어려운데, Extended 모드를 통해 그룹을 정할 수가 있는 것이다. 실제로 많은 메이커에서 바디 계열의 그룹 모듈에서 이 모드를 사용한다. 쉽게 예를 들자면 다음과 같다. 

07B0     01 [02] 10 81 00 00 00 00   -> Body control module

07B0     02 [02] 10 81 00 00 00 00   -> Cluster control module

07B0     03 [02] 10 81 00 00 00 00   -> Air conditioning control module

07B0     04 [02] 10 81 00 00 00 00   -> Head lamp control module

 예 에서 표시 된 것 처럼 통신이 되는 모듈은 달라도 모두 ID가 07B0로 동일하다. 이 모드가 의미하는 것은 Functional 명령을 통해 이 그룹의 전체 모듈과 동시에 통신이 가능하다는 것이다. Sub ID를 결정하는 방법은 메이커 별로 상이한데 간단하게 설명을 하자면 다음과 같다.  

 KWP 2000과 CAN 의 메세지 프레임을 예로 들어서 설명을 해 놓은 것인데, TGT/SRC 를 DL 이라는 부분으로 바꿔 Sub ID를 만드는 것이다. 여기서의 DL 은 간단하게 이야기 하자면 Sub ID 와 Control filed 이 합쳐진 부분을 뜻한다. 다시한번 말하지만 Sub ID 를 정하는 기준은 메이커 별로 상이하다. 즉 모든 메이커가 다른 방식의 계산방식을 가지고 있다는 것이다. 

 다음으로 Control Filed 에 대해서 알아보자. CAN 이 다른 프로토콜과 다른 가장 큰 부분인데, 간단하게 그림을 먼저 보면서 설명을 하자면 다음과 같다. 

 이 부분에서 행해지는 작업은 메세지의 형식이 어떤 것인지를 판별하는 것이다. 이 메세지가 Single frame 인지 아니면 First frame 또는 Flow control/Consecutive frame 인지를 판별하는 것이다. 이 부분에서 KWP 2000 에서는 사용하지 않는 Network control 에 대한 부분이 들어가 있다. 일반적으로 KWP 2000 에서는 1:1 통신이 주를 이루며 1:X 통신의 경우는 Functional addressing 일 경우에만 해당이 되었다. 결국 일반적으로 0xFF 까지의 길이를 가지는 데이터 밖에 컨트롤을 못했는데, 그 한계를 없애기 위해 등장한 것이 바로 Flow control 이다. 일반적으로 CAN의 Data filed는 정확하게 7개로 정해져 있는데 더 많은 데이터를 컨트롤 하기 위해서는 Flow control 이라는 것을 해야 한다. 

 이 표에서 각 모드를 정의를 하고 있는데, 컨트롤 필드의 High nibble 에 따라 모드가 정의가 된다. 알기 쉽게 정리를 하자면 다음과 같다. 

0X  : Single frame

1X  : First frame

2X  : Consecutive frame

3X  : Flow control

 각 모드 별로 메세지 형식이 조금씩 차이가 있는데, 먼저 간략하게 Single frame 에 대해서 설명을 하자면 흔히 보던 1:1 방식의 데이터 이다. 위에서 예를 들었던 것처럼 한개의 ID, SID 로 Request를 보내고 한개의 ID, SID 응답을 받는 것이다. 

07E0     [01] 20 00 00 00 00 00 00

07E8     [01] 60 AA AA AA AA AA AA

 여기서 Control fileld 는 [01] 이다. "0X" 모드에 해당하며 메세지의 길이가 "0x01" 인 녀석인데, 그에 대한 응답도 역시 Single frame 으로 왔다. 이 녀석의 경우는 그렇게 어려운 부분이 없고 1:1 로 통신이 되는 간단한 녀석이다. 하지만 문제는 다음에 있다. 

07E0     06 12 02 01 01 02 00 00

07E8     [11] [57] 52 02 01 01 02 00

07E0     [30] [00] [00] 00 00 00 00 00

07E8     [21] 00 00 58 3F 80 03 00

07E8     [22] 02 01 02 00 04 46 00

07E8     [23] 05 50 00 0B 63 00 0C

07E8     [24] 0A 8A 00 0D 00 00 0E

07E8     [25] 87 00 0F 00 00 10 00

07E8     [26] 00 00 11 FF 00 1F 00

07E8     [27] 03 00 20 A0 18 A0 15

.......

 먼저 첫 번째로 [11] [57] 인 녀석을 보면 이 녀석은 "1X" 타입으로 0x0157 개의 메세지 길이를 가진 녀석이라는 소리다. KWP 2000 에서 컨트롤 할 수 있는 데이터의 길이가 0xFF 였는데, 딱 보면 알겠지만 CAN 에서는 0x0FFF 까지 컨트롤이 가능하다는 이야기 이다. First frame 의 경우는 앞이 "1X" 로 시작하며 뒤쪽에 Length Byte 가 추가로 붙는 다는 점을 제외하면 Sing frame 과 차이점은 없다. 

 그 후에 [30] [00] [00] 로 나머지 메세지를 보내라는 Flow control 을 한다. Flow Control 의 경우는 크게 세가지의 경우로 나누어 지는데 "3X" 의 로우 니블의 형식과 그 뒤의 두개의 Byte 에 따라 나누어 진다. 

 

첫 번째로 로우 니블에 대한 이야기 이다. 여기서 "3X" 의 X가 무엇이냐에 따라 Flow의 성향이 바뀌는데 그 내용은 다음과 같다. 

30   : Clear to send -> 메세지를 바로 보내는 모드

31   : Wait

32   : Over flow

3X  : Reserved

 흔히 쓰이는 0x30 외에도 몇 가지의 모드가 존재 하는데, 흔히 접하는 부분은 아니다. 0x31 의 경우는 Wait 를 나타내는 코드로 대부분의 경우 ECU 에서 보내지게 된다. 아마 여러가지 이유로 처리가 지연이 될 경우 보내지게 되는 것 같은데, 일반적인 경우는 보기 힘들고 Reprogramming 모드에서 접할 수 있다. 다음으로는 0x32 의 경우 Over flow 를 뜻하는 코드로 역시나 일반적인 경우는 보이지 않으며, 메세지가 아주 길 경우 나오게 된다. 나머지로는 0x32 이후 짝을 이루며 나오게 되는 0x3X 부분이 있는데, 이는 플로우 컨트롤의 넘버링을 위해 주로 쓰인다. 이 코드들은 일반적인 경우 대부분 쓰이지 않으며, ECU Reprogramming 을 하는 등의 아주 긴 내용을 다룰 때 쓰이는 부분이기 때문에, 이런 것이 있다는 정도만 알아두면 된다. 

 두 번째로는 좀 어려운 이야기 일 수도 있는데 일반적으로 쓰이는 경우는 "30" 이 대부분 이지만, 뒤쪽의 세팅 형식에 따라 나머지 것들이 필요하다. 

 뒤쪽의 BS에서는 보내지는 나머지 데이터들에 대한 블록 세팅이 가능하다. 즉 이 BS에서 세팅이 된 만큼의 블록만 받게 되는 것인데, "00" 의 경우는 모든 데이터가 바로 오게 되며 0x01 ~ 0xFF 의 숫자 지정을 통해 특정 갯수만 받을 수 있다. 예를 들면 0x08 로 지정을 하면 8개의 블럭만 받는 다는 이야기다. 그 후에는 세팅했던 블록 만큼 지정된 범위의 데이터를 받을 수가 있다. 예를 들어 블록 세팅을 하게 되면 프레임의 형태는 다음의 형태를 띄게 된다. 

07E0     06 12 02 01 01 02 00 00

07E8     [11] [57] 52 02 01 01 02 00

07E0   [30] [02] [00] 00 00 00 00 00

07E8     [21] 00 00 58 3F 80 03 00

07E8     [22] 02 01 02 00 04 46 00

07E0   [30] [02] [00] 00 00 00 00 00

07E8     [23] 05 50 00 0B 63 00 0C

07E8     [24] 0A 8A 00 0D 00 00 0E

07E0   [30] [02] [00] 00 00 00 00 00

07E8     [25] 87 00 0F 00 00 10 00

07E8     [26] 00 00 11 FF 00 1F 00

.......

 먼저와의 차이점이 눈에 보이는가? 그렇다면 세 번째인 STmin 은 무엇일까? 이 것은 예상했겠지만 Timing에 대한 부분이다. 

 자 이렇게 세팅을 해서 지정한 타이밍으로 데이터를 주고 받는 것이다. 사실 CAN 의 경우 타이밍에 대한 부분은 CAN Controller 에서 다 알아서 해주기 때문에, 크게 신경쓸 부분은 없다. 다만 보내는 명령을 조절할 수 없는 차량측 ECU의 Flow control 의 경우는 이 내용을 알아야 제대로 된 통신을 할 수 있다. 대부분의 경우 "00"으로 되어 있지만 간혹 그렇지 않은 경우가 있기 때문이다. 

 마지막으로 "2X" 인 Consecutive frame 에 대하여 알아보면 굉장히 간단하다. 나머지 데이터를 "2X' 로 시작하는 블럭에 넣기만 하면 되는 것이다. 물론 넘버링이 이루어 져서 0x21 ~ 0x20 까지 순환이 되는 구조인데, 0x2F 다음은 0x20 이라는 부분만 조심하면 딱히 문제가 되는 부분은 없다. 

 마지막으로 전체적인 Flow control 에 대한 개념도는 이 그림으로 설명이 가능하다. 

 위에 설명한 내용들은 종합적으로 설명한 그림인데, 위의 내용과 함께 보면 좀더 쉬운 이해가 가능 할 것이다.  

 그럼 이제 메세지 포맷까지 알았으니, 타이밍에 대한 부분을 설명할 차례이다. 사실 이 부분은 위에도 썻지만 Controller 에서 알아서 해주는 부분이긴 하지만, 테스터의 컨트롤러는 제어가 가능하지만 ECU의 컨트롤러는 제어가 쉽지 않기에 알아두면 좋은 내용이다. 사실 각 ECU 별 스펙을 통해 해당 내용은 정의가 되어 있다. 

 일반적인 CAN의 데이터 통신 타이밍이다. 비트별 타이밍 부분은 이미 CAN(Controller Area Network) #Part 1 - Physical  Layer 에서 설명이 되어 있으므로 P2 와 S3 만 정의가 된다. 딱 보면 알겠지만 굉장히 빠른 통신임에도 불구하고 각 프레임간의 대기시간은 넉넉한 것을 볼 수 있다. 일반적으로 50 ms 의 대기시간을 가지며, 펜딩일 경우 5000 ms 의 대기 시간을 가진다. 그리고 오픈이 되는 세션 별로 차이가 있는 것을 확인 할 수 있다. 

 Flow control 시의 타이밍에 대한 이야기 이다. 이 부분은 STmin 의 세팅을 통해 조절이 가능한 부분이지만, 기본적인 경우에 대한 스펙은 명시가 되어 있다. 

 조금 어려운 내용이지만 CAN 프로토콜의 대부분에 대한 정의가 끝났다. 누락된 세부적인 내용은 크게 중요한 내용이 아니기 때문에 제외를 했는데, 혹시 궁금하다면 해당 스펙 문서를 찾아보길 바란다. PDU나 각 비트 세팅에 대한 정의가 모두 문서에서 이루어져 있으나 반드시 알아야 될 부분은 아니기에 제외시켰다. 사실 이 내용만으로도 충분히 머리는 아플 것이기 때문이다. 

 이 내용을 이해를 했다면, 실제로 CAN 프로토콜을 사용해서 개발이나 분석을 할 준비가 끝났다는 이야기 이다. 전에도 이야기를 했지만 7번의 경우 UDS를 제외하면 모든 프로토콜이 거의 동일하기 때문이다.