자동차 통신 중 하나 CAN 통신(Controller Area Network)

통신은 사람이나 사물 간에 매체를 통하여 정보나 의사를 전달하는 것을 말합니다. 자동차 안에는 수많은 부품 및 제어기들이 있습니다. 엔진을 제어하는 ECU (Engine Control Unit), 변속기를 제어하는 TCU (Transmission Control Unit), 각종 ADAS (Advanced Driver Assistance System) 관련 제어기 등 수십 개에 해당하는 제어기들이 차량에 장착되고, 제어기들은 서로 데이터를 주고받으며 공유된 정보를 통해 다양한 제어를 하게 됩니다. 데이터를 주고받을 때 제어기들 간의 규칙이 있어야 원활한 통신을 할 수 있는데, 이러한 규칙을 통신 프로토콜 (Protocol)이라고 합니다. 자동차 내에는 CAN (Controller Area Network) 통신, LIN 통신, LAN 통신 등 다양한 통신 방법을 용도에 맞게 사용하고 있습니다. 그중에서 CAN 통신이 자동차에서 가장 많이 사용되고 있습니다.

 

 

CAN 통신은 자동차 부품회사인 보쉬 (BOSCH)에서 개발된 차량용 네트워크 통신 방식으로, 전기적 노이즈 발생이 많은 자동차 환경에서 신뢰성을 확보하기 위해 개발된 통신 방식입니다.

 

 

CAN 통신은 왜 만들어졌을까요?

1980년대까지 자동차는 대부분 기계식이여서 전자적 제어를 하지 않았습니다. 점차 기술의 발전으로 인하여 자동차에 다양한 전자제어 시스템(ECU)들이 생겨났고 이러한 ECU들이 서로 통신하기 위해 비동기 직렬 통신 방식으로 불리는UART(Universal Asynchronous Receiver/Transmitter)를 사용했습니다. 그러나 UART의 통신은 각 ECU들이 1:1 통신을 해서 ECU가 추가될 때마다 같은 수의 연결이 필요했습니다. ECU가 늘어나면서 도저히 감당할수 없을정도로 많은 연결이 생기고 공간이나 케이블의 무게가 점점 증가하면서 결국 원가를 크게 상승시키게 되었습니다.

이러한 문제 해결을 위해서 메르세데스-벤츠(Mercedes-Benz)는 보쉬(Bosch)에 차량용 네트워크를 만들어달라고 의뢰를 하였고 1985년에 보쉬에 의해서 CAN이 만들어졌습니다. 여러 개의 CAN Device가 붙은 ECU들이 서로 통신할 수 있으며, 하나의 CAN 인터페이스로 여러 개의 모듈을 제어할 수 있어서 연결선 수의 감소, 자동차 무게의 경감, 원가 하락뿐만 아니라 효율적으로 시스템 제어가 가능해졌습니다. 이렇게 사용되어 지던 인터페이스는 1993년에 ISO가 국제 표준 규격으로 제정됩니다. 이렇게 CAN은 자동차 통신의 필수불가결 요소가 되었고 현재 제2세대까지 나왔습니다.

 

2.1 CAN 프로토콜 규격

CAN 메시지에 있는 식별자(ID)의 길이에 따라 두 가지 모드로 구분됩니다.

• 표준 CAN(버전 2.0A): 11비트 식별자
• 확장 CAN(버전 2.0B): 29비트 식별자

ISO 규격에 따라 두 가지로 구분되며 통신 속도에서 차이가 있습니다.

• ISO 11898: 1Mbps 이상의 고속 통신 가능
• ISO 11519: 125Kbps 까지의 통신 가능

대부분의 CAN 2.0A 컨트롤러는 오직 표준 CAN 포맷의 메시지만 전송 및 수신이 가능하며, 확장 CAN 포맷(CAN 2.0B)의 메시지를 수신하더라도 그 메시지를 무시해 버립니다. 즉, CAN 2.0A 컨트롤러에서 보내온 메시지 데이터만 유효합니다. 그러나 CAN 2.0B 컨트롤러는 양쪽 메시지 포맷(CAN 2.0A, CAN 2.0B)에 대해 모두 송수신이 가능합니다.

2.2 CAN 메시지 포맷(구조)

CAN에서는 데이터 프레임(data frame), 리모트 프레임(remote frame), 에러 프레임(error frame), 오버로드 프레임(overload frame)의 4가지 프레임 타입을 정의하고 있습니다. 데이터 프레임은 일반적으로 데이터 전송에 사용되며, 리모트 프레임은 수신할 노드에서 원하는 메시지를 전송할 수 있는 송신 노드에게 전송을 요청할 때 사용됩니다. 에러 프레임은 메시지의 에러가 감지되었을 때 시스템에 알릴 목적으로 사용됩니다. 마지막으로 오버로드 프레임은 메시지의 동기화를 목적으로 사용됩니다. CAN 통신에서 데이터 송수신은 메시지 프레임을 사용하여 이루어집니다. 메시지 프레임의 구조는 다음과 같습니다.

다음 표는 CAN 메시지 프레임의 각 필드에 대한 설명입니다.

필드설명

SOF(Start Of Frame)	한 개의 dominant 비트로 구성되어 있으며, 메시지의 처음을 지시하고 모든 노드의 동기화를 위해 사용된다.
Arbitration Field (중재 필드)	11비트 또는 29비트의 크기를 갖는 ID와 1비트의 RTR(Remote Transmission Request) 비트로 구성된다. 이 영역은 둘 이상의 노드에서 메시지의 전송이 동시에 일어날 경우 발생하는 메시지 간의 충돌을 조정하는 데 사용된다. RTR비트의 값은 데이터 프레임인지(‘d’) 리모트 프레임인지(’r’)를 결정하는 데 사용된다.
Control Field (제어 필드)	2비트의 IDE(IDentifier Extension) 비트, 4비트의 데이터 길이 코드(DLC, Data Length Code)로 구성된다. R0는 Reserved 비트(Extended CAN 2.0B R0, R1)이다.
Data Field (데이터 필드)	8bytes까지 사용 가능하며, 데이터를 저장하는 데 사용된다(특정한 노드에서 다른 노드로 전송하는 데이터를 포함).
CRC (Cyclic Redundancy Check) 필드	SOF에서부터 데이터 필드까지의 비트열을 이용해 생성한 15비트의 CRC 시퀀스와 하나의 ‘r’비트의 CRC 델리미터로 구성되어 있다. 이것은 메시지 상의 에러 유무를 검사하는데 사용된다.
ACK(ACKnowledge) 필드	한 비트의 ACK 슬롯과 하나의 ACK 델리미터(‘d’)로 구성되어 있다. 임의의 노드에서 올바른 메시지를 수신하게 되면 ACK 필드를 받는 순간 ACK 슬롯의 값을 ’d’로 설정해 버스 상에서 계속 전송하게 된다.
EOF(End Of Frame, 프레임종료)	7개의 ‘r’비트로 구성되어 메시지의 끝을 알리는 목적으로 사용된다.

---

 

CAN FD는그럼?(이전엔 CAN-HS )

 

오늘은 CAN이후 발전된  “CAN FD(CAN with Flexible Data rate)” 통신에 대해 알아보도록 하겠습니다. CAN FD 통신을 만들게 된 배경과 CAN FD의 특징과  동작 방법에 대해서 설명드릴게요.

차량 통신 기술의 진화(※ 출처: Frost & Sullivan)

차량 내부 네트워크 적용분야 및 대역폭 – 출처: Freescale Technology Forum, 2014

 

1. CAN FD의 등장 배경

Bosch에서 개발한 CAN 통신 네트워크는 약 30년 동안 ECU를 연결하는 De facto Standard 통신 방법이었습니다. 그런데차량 내 데이터 트래픽이 증가하면서 CAN 버스도 더 많은 데이타 트래픽을 할 수 있는 통신 방법이 요구되었습니다. 그래서 개발된 것이 고성능의 FlexRay나 Ethernet등이 있습니다.

이러한 요구사항을 반영하여 2012년에 Bosch사가 CAN FD(CAN with Flexible Data rate)를 발표합니다. 실제로 반도체 업체에서도 기존 CAN Tranceiver에 FD기능을 탑재하여 제품을 출시하고 있습니다. 결국 기존 지배적인 시장을 기반으로 BOSCH사에서 CAN FD를 다시한번 Defacto standard로 만들려고 하고 있습니다.