CAN 통신 Frame 종류와 구조

자동차 회사 혹은 자동차 부품 회사에 입사하게 되면, 아마도 정말 빈번하게 듣는 것 중 하나가 CAN 일 것입니다.

그도 그럴 것이 사실 상 현대 자동차의 전자 전기 아키텍쳐의 중심은 네트워크라고 할 수 있으며, 그 중에서도 가장 꾸준히 많이 쓰이는 프로토콜이 CAN이기 때문입니다.

Bosch가 Benz의 의뢰를 받고 CAN을 개발하기 전까지는 사실 ECU 간의 네트워크라는 건 실체가 없었고, 대부분의 제어기들은 서로 1 : 1 통신을 했었는데 보통 Serial Communication 중 UART 등을 이용하여 통신을 수행하곤 했습니다.

Benz는 앞으로 많은 제어기가 개발 및 운용될 것으로 예측했는데, 이렇게 1 : 1 통신으로만 구성해서는 제어기가 늘어 날 때마다 각 제어기간의 통신을 위한 라인이 기하급수적으로 늘어날 것이므로, 다른 방식을 찾아야 했습니다.

이러한 배경으로 Bosch가 개발한 것 이 CAN standard입니다.

CAN : Controller Area Network

정의 : Serial bus communication for real-time control application

그리고 CAN에 대한 정의는 ISO 11898 표준에도 정의되어 있습니다. 

정의에서도 보이다시피, CAN에서는 bus의 개념이 들어갑니다.

통신에서 bus 구조란, 공통 기능을 수행하는 배선 그룹으로 정의됩니다.

즉, 다양한 제어기간의 통신을 위한 라인을 공통으로 구성했다는 말이며, 이런 구성을 통해서 차량 내에 배선을 획기적으로 줄일 수 있게 됩니다. 

CAN Bus System

CAN의 특징을 좀 살펴보면, 다음과 같습니다. 

CAN은 두 가닥의 Wire로 구성된 통신입니다.

그리고 CAN의 message에는 주소가 들어가 있지 않고, 오로지 Identifier만 가지고 있습니다. 

모든 Node에서는 모든 message를 볼 수 있습니다. 

CAN은 두 가닥의 Wire의 differential signal입니다.

CAN controller and CAN transceiver

위에서 보다시피, CAN 물리적 와이어는 twisted이다. 이유는 외부의 노이즈로부터 강건하기 위해서 이다. 

CAN bus signal levels

CAN 신호는 두 개의 CAN 물리적 와이어의 전압 차이로 판단한다.

두 신호의 전압 차이가 2V이면, Dominant Logic L이고 0V이면 Recessive Logic H이다.

CAN Message

CAN bus는 broadcast 타입의 bus입니다. 이 말은 앞 서 이야기 한 것과 같이 모든 node들이 모든 전송되는 메시지를 들을 수 있습니다. 

CAN에는 특정 node에만 메시지를 보낼 수 있는 방법이 없습니다. 다만 CAN hardware에서 local filter를 구성할 수 있고, 이 기능을 통해서 각 node는 스스로 유용한 메시지에 대해서만 반응할 수도 있습니다 .

 

메시지 타입

1. the Data Frame

2. the Remote Frame

3. the Error Frame

4. the Overload Frame

 

The Data Frame

Summary : "Hello everyone, here's some data labeled X, hope you like it"

데이타 프레임은 가장 흔한 데이터 타입입니다. 이 데이터 타입은 크게 아래와 같이 구성되어 있습니다. 

• the Arbitration Field : 버스 내에서 두 개 혹은 그 이상의 노드가 경쟁할 때, 메시지의 우선순위를 결정하는 부분이다.
  
  • CAN 2.0A : 11bits Identifier와 1개의 RTR bit로 구성(data frame에서는 dominant로 표현)
  • CAN 2.0B : 29bits Identifier(여기에는 2개의 recessive bit인 SRR, IDE가 포함된다.)와 RTR bit로 구성 
• the Data Field : 여기는 0 ~ 8 bytes의 데이터가 포함된다.
• the CRC Field : 여기에는 15bits의 Checksum 값이 들어간다. 이 Checksum은 에러 감지용이다. 
• the Acknowledgement Slot : 올바르게 메시지를 수신할 수 있는 몇 가지 CAN controller는 메시지의 끝에 Acknowledgement비트를 보낸다. Transmitter는 이 Acknowledgement bit의 존재 여부를 확인해서 만약에 없다면, 메시지를 재송신한다. 

* Acknowledgement bit가 존재한다고 해서, 해당 메시지가 의도된 노드로 전달되었다는 의미는 아니다. 단지 Bus 내에 하나 혹은 그 이상의 노드가 해당 메시지를 들었음을 의미한다. 

* Arbitration Filed의 Identifier는 일종의 이름이긴 한데 이거 자체가 메시지의 내용을 식별하지는 않는다. 

 

The Remote Frame

summary : "Hello everyone, can somebody please produce the data labeled X?"

Remote Frame은 중요한 두가지 차이 빼고는 Data Frame가 같다.

• Arbitraction Field내에 RTR bit가 recessive로 표현되며 명시적으로 Remote Frame임을 알린다. 
• 여기에는 Data Field가 없다.

Remote Frame의 목적은 특정한 Data Frame의 전송을 다른 노드에 요청하는 것입니다. 

예를 들어서 Node A의 Arbitration Field를 234로 설정해서 Remote Frame을 전송하면, Node B가 적절하게 초기화 한 후에 Arbitration Field 234로 설정된 Data Frame으로 응답하게 된다.

하지만 보통 이 방식은 거의 사용되지 않는다. 

The Error Frame

summary : (everyone, aloud) "Oh Dear, Let's Try Again"

 간단히 말해서, Error Frame은 CAN msg가 Frame rule을 위반하는 특수 메시지이다. 

Node가 장애를 감지 할 때 전송되며 다른 모든 Node가 장애를 감지하게 되므로 Error Frame도 전송된다.

그러면 Transmitter가 자동으로 msg 재전송을 시도한다. 

그리고 Node가 Error Frame을 반복적으로 전송해서 Bus Traffic을 파괴할 수 없도록 보장하는 Error Counter scheme이 있다. 

The Overload Frame

Summary : "I'm a very busy little 82526, could you please wait for a moment?"

Overload Frame은 Error Frame과 유사하며, bus 점유가 너무 많은 Node에 의해 전송됩니다.

하짐하지만 오늘 날에는 CAN Controller가 너무 좋아져서 거의 자주 사용되지 않습니다. 

Overload Frame을 사용하는 거의 유일한 Controller가 82526이다.

 

 

 

참조 : https://www.kvaser.com/can-protocol-tutorial/

CAN Bus Protocol Tutorial | Kvaser

.