CAN (통신)

개요

CAN은 차량 내부 통신으로 가장 많이 쓰이는 통신 프로토콜 중 하나이다. CAN 프로토콜은 차량 내 네트워크(In-Vehicle Network)에 적합한 특징 덕분에 많은 차량에서 내부 통신 프로토콜로 사용되고 있다. 사용자의 안전과 밀접하게 관련된 차량 내 주요 전자 제어장치(electronic control unit: ECU)는 CAN 버스를 기반으로 구성 되어 있으며 버스 상에 발생하는 고장을 진단하여 고장 노드의 식별 및 위치정보를 사용자에게 알려 주어 사고에 대비하여야 한다. 또한 네트워크상의 전자 제어 장치는 자체 클록을 갖고 있으며 이를 기반으로 동작한다. 클록은 다양한 외부 환경의 영향으로 노드간의 클록 오차가 발생하고 시간이 지남에 따라 클록 오차는 누적되어 오류를 유발하게 된다. 따라서 이를 해결하기 위하여 일정 시간 마다 동기화를 수행하여 오차를 줄여 줄 필요성이 있다. CAN은 여러 개의 CAN 디바이스가 서로 통신할 수 있는 경제적이며 안정적인 네트워크를 제공한다. 이 같은 네트워크의 장점은 ECU(electronic control units)가 시스템 내 각 디바이스마다 아날로그 및 디지털 입력을 갖는 것이 아니라 단일의 CAN 인터페이스만 보유한다는 점이다. 따라서 자동차의 전체 비용과 중량도 줄일 수 있다. 네트워크상의 각 디바이스에는 CAN 컨트롤러 칩이 있어 매우 지능적이다. 네트워크상의 모든 디바이스는 전송되는 모든 메시지를 확인한다. 각 디바이스는 해당 메시지가 관련된 것인지 필터링 되어야 할 지 여부를 결정한다. 또한, 모든 메시지는 우선순위가 있으므로 두 개의 노드가 동시에 메시지를 전송할 경우, 우선순위가 높은 메시지가 먼저 전송되고 낮은 우선순위의 메시지는 전송이 연기된다.

등장배경

CAN은 1985년 독일의 전기·전자기기 및 자동차부품회사인 로버트보쉬(Robert Bosch)사에서 차량 네트워크용으로 최초로 개발되었다. 과거 1980년대까지 자동차는 대부분 기계식이었다. 그러다 점차 기술의 발전으로 인하여 자동차에 다양한 모듈(ECU) 들이 생겨났고 이러한 모듈들이 서로 통신하기 위해 비동기 직렬 통신 방식인 UART(Universal Asynchronous Receiver/Transmitter)를 사용한다. 그러나 UART의 통신은 각 모듈이 1:1 통신을 해서 모듈이 추가될 때마다 더 많은 연결선이 필요하다. 수많은 연결선은 자동차의 공간을 점점 더 많이 차지하게 되었고 이는 자동차 무게를 증가시키고 원가를 상승시키는 결과를 초래했다. 메르세데스-벤츠(Mercedes-Benz)는 이러한 문제점을 해결하기 위해서 보쉬(Bosch)에 차량용 네트워크를 만들어달라고 의뢰를 하였고 1985년에 보쉬는 CAN을 개발했다. 과거에 자동차 제조업체들은 포인트 투 포인트 와이어링 시스템을 사용하여 차량 내 전자장치를 연결하였다. 그러나 더욱 더 많은 전자장치를 차량 내에 탑재하게 됨에 따라, 배선 장치(wire harnesses)는 공간을 많이 차지할 뿐 아니라 무게가 많이 나가며 비용이 많이 들게 되었다. 이에 업체들은 전용 와이어링을 사용함으로써 배선 비용, 복잡성 그리고 무게를 경감시킬 수 있었다. CAN은 지능형 디바이스 네트워크 구축을 위한 높은 무결성의 시리얼 버스 시스템으로서 차량용 네트워크의 표준으로 부상하였다. 자동차 업계에서는 신속하게 CAN을 도입하였으며 1993년에는 ISO에서 국제 표준 규격(ISO 11898)으로 제정하였다. 1994부터 CANopen, DeviceNet 등 CAN에 대한 여러 가지 상위 레벨 프로토콜이 표준화되었다. 다른 업계에서도 이 같은 프로토콜을 광범위하게 채택함에 따라 CAN은 산업 통신에 있어 표준으로 자리매김하게 되었다.

동작원리

CAN은 다중통신망(Multi Master Network)이며 CSMA/CD+AMP(Carrier Sense Multiple Access/Collision Detection with Arbitration on Message Priority) 방식을 이용한다. 먼저 CAN 노드에 메시지를 보내기 전에 CAN 버스라인이 사용 중인지를 파악한다. 또한 메시지 간 충돌 검출을 수행한다. 이 때 어떠한 노드로부터 보내진 메시지는 송신측이나 수신측의 주소를 포함하지 않는다. 즉 주소지정방식으로 통신하지 않는다. 대신 메시지의 처음부분에 CAN 네트워크상에서 각각의 노드를 식별할 수 있도록 각 노드마다 유일한 식별자(ID-11bits 또는 29bits)를 가지고 있다. 네트워크상에 연결된 모든 노드는 네트워크상에 있는 메시지를 수신한 후 자신이 필요로 하는 식별자의 메시지인 경우에만 받아들이고, 그렇지 않은 경우의 메시지는 무시한다. 네트워크상(CAN 통신 라인)에 흘러 다니는 여러 노드의 데이터들이 동시에 사용자가 필요로 하는 노드로 유입되는 경우에는 식별자의 숫자를 비교하여 먼저 받아들일 메시지의 우선순위를 정하는데, 식별자의 숫자가 낮을수록 우선순위가 높다. 우선순위가 높은 메시지가 CAN 버스의 사용 권한을 보장받으며 이때 낮은 순위의 메시지는 자동적으로 다음 버스 사이클에 재전송이 되도록 한다. 각 CAN 메시지는 11비트의 식별자(CAN 2.0A), 또는 29비트의 식별자(CAN 2.0B)를 가지며, CAN 메시지의 맨 처음 시작부분에 위치(그림 3 참조)한다. 이러한 식별자는 메시지의 형태를 식별시켜주는 역할과 메시지에 우선순위를 부여하는 역할을 한다.

CAN 통신 프로토콜은 CAN 버스에서 디바이스들 통신 사이로 데이터가 전달되는 방법을 명시한다. 이것은 ISO의 개방형 시스템 상호연결 모델(Open System Interconnection model)을 따르며, 이 모델은 통신 네트워크 표준인 일곱 계층으로 되어 있다. 이 OSI 모델은 두 개 네트워크 노드들 간의 계층화된 통신 시스템을 기술하며, 이론상 각 계층은 로컬 모드에서는 오직 자신의 직접적인 위, 아래의 계층들과 통신할 수 있으며, 원격 모드에서는 동등한 계층과 통신할 수 있다. OSI 모델의 계층들은 아래의 표에 나와 있다. 사실 CAN 프로토콜은 OSI 모델의 가장 낮은 두 개 층들로 설명될 수 있다 - 데이터 링크 계층과 물리적 계층. 애플리케이션 계층 프로토콜들은 개별적인 CAN 사용자들에 의해 개발된 독자 구조, 또는 특정 산업 내에서 사용되는 새로운 표준들 중의 하나이다. 프로세스-제어/제조 분야에서 사용되는 공통적인 애플리케이션 표준 층은 DeviceNet으로, 이것은 PLC의 네트워킹과 지능 센서들 그리고 액추에이터에 특히 적합하다. 자동차 산업에서 많은 제조업체들은 그들 자신의 독자적인 표준을 사용하고 있다.

CSMA/CD-NDBA

CSMA/CD 는 충돌 탐지 기능을 가진 Carrier Sense Multiple Access 를 나타낸다. CSMA/CD를 이용하면 버스 주소지정이 버스 상(carrier sense)에서 반송파를 감지(listening)하여 이루어지며, 단지 버스가 유휴상태일 때 전송된다. 이 방식에서, 다중 노드들이 동일한 네트워크에 연결되는 것이 기능하다. 충돌이 탐지되면, 재전송하기 전에 임의 시간이 지날 때까지 전송을 시작했던 모든 노드들이 다시 "listen"으로 되돌아가게 된다. 그러나 이 기법은 과중하게-로드된 버스에서는 여전히 약간의 지연을 유발한다. 이러한 지연을 피하기 위해, CAN 버스에서 두 개 노드들이 동시에 전송할 때, 한 개 메시지가 우선순위를 갖게 하는 방법이 필요하다 - 이것은 'Non-Destructive Bit-wise Arbitration' 을 사용하여 달성된다. CAN 버스의 각 노드는 유일한 식별자(ID)를 가지며, 그것은 11비트 또는 29 비트 숫자이다. CAN은 이진 0 이 이진 1 에 우선하도록 결정한다. 따라서 더 낮은 ID 번호 - 더 높은 우선순위, 그러므로 식별자 0 (즉, 11 이진 0 들) 이 버스에서 최고의 우선순위를 갖는다. 이것을 알아보는 다른 방법으로 메시지 충돌 상황이 있는데, 다른 노드가 1 을 보낼 때 0 을 보내는 최초의 노드가 버스 제어를 획득하게 되고 성공적으로 자신의 메시지를 전송하는 것이다.

물리 계층

CAN에는 여러 종류의 다른 물리 계층이 있다. CAN 노드는 반이중 모드에서 다른 노드와 통신할 수 있다. 노드는 대표적으로 마이크로 컨트롤러(Micro Controller), CAN 트랜시버(Transceiver)로 구성된다. 마이크로 컨트롤러는 메시지를 만들어 CAN 컨트롤러로 송신을 명령하거나 CAN 컨트롤러로부터 수신된 메시지를 넘겨받는다. CAN 컨트롤러는 명령에 따라 TTL 레벨의 Tx, Rx 신호를 송수신한다. CAN 트랜시버는 TTL 레벨의 Tx를 CAN 규격의 차등 신호로 변환하여 버스로 송신하거나 버스의 차등 신호를 TTL 레벨의 Rx 신호로 변환하여 CAN 컨트롤러로 전달한다. CAN의 버스는 CAN_High와 CAN_Low로 이루어진 차등 신호를 전달하며 차폐꼬임상선을 사용한다. 이 같은 물리 계층은 전기적 레벨, 신호 구조, 케이블 임피던스, 최대 보드(baud) 속도 등 CAN 네트워크의 특정 사항을 분류한다. 가장 보편적이며 널리 사용되는 물리 계층은 아래와 같다.

• High-Speed CAN : 현재까지 가장 보편적으로 사용되는 계층이다. 고속 CAN 네트워크는 두 개의 와이어로 실행되며 최대 1 Mb/s 전송 속도로 통신을 진행한다. 고속 CAN의 다른 명칭으로는 CAN C와 ISO 11898-2가 있다. 일반적인 고속 CAN 디바이스에는 ABS(anti-lock brake systems), 엔진 컨트롤 모듈 그리고 방출 시스템 등이 있다.

• 저속/내고장 CAN 하드웨어 : 저속/내고장(fault-tolerant) CAN 네트워크 또한 두 개의 와이어로 실행되고, 최고 125 kb/s 속도로 디바이스와 통신하며, 내고장 기능이 있는 트랜시버를 제공한다. 저속/내고장 CAN 디바이스는 CAN B 및 ISO 11898-3으로도 알려져 있다. 자동차에서의 일반적인 저속/내고장 기기에는 안락장치가 있다. 차량의 문을 열고 닫을 때의 강도를 고려하여 차량의 문을 통과해야 하는 와이어는 저속/내고장이다. 또한, 브레이크 등과 같이 강화된 보안 레벨이 요구되는 경우, 저속/내고장 CAN은 그 해결책이 될 수 있다.

• 단일 와이어 CAN 하드웨어 : 단일 와이어 CAN 인터페이스는 최고 33.3 kb/s(고속 모드에서는 88.3 kb/s) 속도로 디바이스와 통신한다. 단일 와이어 CAN의 다른 명칭은 SAE-J2411, CAN A 및 GMLAN이다. 차량 내 일반적인 단일 와이어 디바이스는 고성능을 요구하지 않는다. 일반적인 애플리케이션에는 좌석과 거울 조정기 등의 안락 장치가 있다.

물리 계층에서, CAN은 광섬유 또는 꼬인 2선(가장 보편적) 같은 다양한 종류의 매체를 사용하여 통신할 수 있다. 꼬인 2선 시그널링은 각각의 전선에서 서로 다른 전압들을 사용하여 실행되므로 (balanced-line signalling 으로도 알려져 있다), 한 전선에서의 신호 전압은 또한 다른 전선에서 전송되지만, 반전된다. 수신기에서, 이 신호는 한 신호를 반전하고 두 개의 신호를 합해서 복원된다 - 이것은 두 개 전선들에 대해 공통적인 것이므로, 이 방법은 버스 상에서 발견된 어떤 노이즈도 줄일 수 있다. 바로 이 과정에서 CAN은 자체의 잡음 면역(noise immunity)과 결함 허용(fault tolerance) 기능들을 유도한다. 두 개의 전선들은 CAN_H (또는 CAN High)와 CAN_L (또는 CAN Low)로 불린다. 정지 상태(또는 "recessive") 에서 CAN_H 와 CAN_L 은 2.5V에 놓이다. 이것은 디지털 "1"로 표시되며, 또한 "recessive" 비트로도 알려져 있다. 디지털 '0' 은 또한 "dominant' 비트로도 알려져 있으며, CAN_L보다 큰 CAN_H에 의해 지시된다. 일반적으로 디지털 '0' 의 경우, 관련된 전압은 CAN_H = 3.5V 그리고 CAN_L = 1.5V이다.

특징

노드 지향 전송과는 달리, 두 개의 특정 노드들 간에 메시지 전송이 발생되는, CAN을 이용한 메시지 전송은 이른바 “producer-consumer principle”을 바탕으로 이루어진다. 생산자 노드에 의해 전달된 메시지는 모든 다른 사용자 노드들에 의해 수신될 수 있다. 이를 위해, 메시지는 목적지 주소 대신 분명한 “메시지 식별자”로 표시된다. 네트워크의 모든 노드들에 대한 메시지 전송은 “방송(broadcasting)” 으로도 일컬어진다. CAN 프로토콜에서, 메시지들은 일반적으로 11-비트 길이 식별자 (표준 포맷)를 갖는다. 이것은 시스템마다 2048개의 서로 다른 메시지들이 정의될 수 있다는 것을 의미한다. 이 수는 대부분의 애플리케이션들에서는 충분하고도 남는다. 그러나 특수한 애플리케이션들의 경우(예, 대형 차량들, SAE J1939) 29비트 길이 식별자 (확장 포맷) 사용과 따라서 최대 512백만 개의 서로 다른 메시지들 정의도 기능하다. 노드는 반드시 버스의 메시지 열에서 이것을 위해 관련된 메시지를 여과(filter)해야 한다. 이렇게 하기 위하여, CAN 프로토콜 컨트롤러 칩은 이른바 수용 필터링 (acceptance filtering)의 형태로 하드웨어에 의해 실행되는 구조를 제공한다.

사건 지향 메시지 전송

CAN 네트워크의 각 노드는 버스가 자유로워지자마자 메시지 전송을 시작할 수 있다. 이것은 하나 이상의 네트워크 노드에서 동시에 메시지 전송이 시작될 수 있기 때문에, 중재 처리가 필수이며, 따라서 실제로는 단 한 개의 노드만이 메시지 전송을 계속할 수 있도록 한다. 모든 노드가 메시지 전송을 시작할 수 있기 때문에, 네트워크의 모든 노드들 사이에서 직접적인 메시지 전송이 기능하다. 따라서 요청 시, 즉 관련 사건이 발생했을 때 메시지를 전송만 하는 것이 기능하다. 주기적 메시지 전송과 비교하면, 요청된 데이터 전송률에서 상당히 낮아진 버스 적재 또는 감소된 결과를 가져온다.

버스 중재

CAN 네트워크에서 모든 노드는 버스가 자유로워지면 바로 메시지 전송을 시작할 수 있으므로, 여러 개의 노드들이 동시에 전송 처리를 시작하는 것이 기능하다. 노드가 서로 전송된 데이터를 간섭하는 것을 막기 위해, 동시에 중재되는 모든 메시지들 중 가장 높은 우선순위를 가진 메시지가 중재 단계에서 결정된다. 실제로 가장 높은 우선순위 메시지를 전송하는 네트워크 노드만이 메시지 전송을 계속할 수 있게 된다. 메시지 식별자의 가장 싼 값을 가진 메시지가 가장 높은 우선순위를 갖게 된다. 각각의 노드는 중재 단계 동안 버스에서 signal level을 관찰한다. 이 중재 단계는 메시지 식별자의 전송과 소위 RTR 비트로 불리는 것의 전송으로 이루어져 있다. 만약 네트워크 노드가 우성 버스 레벨 (우성 비트)을 발견한다면, 이것은 열성 레벨(열성 비트)로 전환되고, 전송 처리가 즉시 중단되지만, 이 경우 동시에 더 높은 우선순위를 가진 메시지는 분명히 전송되고 수신 상태로 들어가게 된다. 모든 메시지가 버스 중재(bit-wise bus arbitration )로 전송되면, 이 과정은 확실한 “손실 없는” 버스 액세스가 된다.

우선순위 지향 메시지 전송

위에 설명된 중재 처리는 버스가 자유로워질 경우 언제나 항상 가장 높은 우선순위의 메시지가 전송된다는 것을 보여준다. 메시지의 우선순위는 메시지 식별자의 값으로 결정된다. 이 값이 더 작을수록, 메시지의 우선순위는 더 높아진다. 우선순위 지향 메시지의 원칙은 데이터 전송에 이용할 수 있는 대역폭의 가장 효율적인 사용을 가능하게 한다. 따라서 낮은 우선순위의 메시지가 실제로 보다 높은 우선순위를 가진 메시지를 지연시키는 일 없이 100% 버스를 점령하는 것이 기능하다. 가장 높은 우선순위를 가진 메시지의 경우, 1 Mbit/s 의 전송 속도에서 최대 약 130 µs 의 대기 시간이 일어난다. 반면, CAN 시스템을 설계할 때는, 높은 우선순위 메시지가 버스를 계속 점령하지 않는다는 것이 지켜져야 한다. 이것은, 예를 들면 전송 금지 시간 (CANopen: "Inhibit Time")을 도입함으로써 기능하다.

비트율/버스 길이

CAN 에서 사용되는 bit-wise 중재 원칙은 bit-time 간격 내에서 버스를 걸쳐 분배되는 전체 네트워크 노드들의 local bit level 의 비교를 필요로 한다. 버스를 걸쳐 신호 분배에 요구되는 신호 전파 시간은 버스 길이에 비례하기 때문에 버스 간격의 필요한 지속시간은 버스 길이의 연장에 따라 늘어난다. 최대 버스 길이(네트워크 확장)와 최대 비트율(bit rate)은 따라서 역으로 비례한다. 100m 이상의 버스 길이의 경우, 다음의 경험 법칙이 계산에 사용될 수 있다.

$Baudrate(inMbit/s)xbuslength(inm)=60$

메시지 길이/최대 메시지 비율

최대 8 바이트의 데이터는 한 개의 CAN 메시지로 전송될 수 있다. 이용 가능한 데이터 전송 능력은 자동화 시스템 또는 모터 차량 분야의 거의 모든 애플리케이션들이 사용하기에 충분한다. 보다 큰 데이터 블록들은, 가령 디바이스 구성을 위한, 일련의 연속 CAN 메시지로 전송될 수 있다. 짧은 메시지의 가장 큰 장점은 높은 우선순위 메시지에 맞는 보다 짧은 대기 시간과 높은 결함을 지닌 환경에서도 전송할 수 있는 능력이다. 짧은 메시지의 경우 (전송 시간), 두 결함 사이에서 방해 받지 않고 전송될 수 있는 가능성은 보다 긴 메시지들의 전송에서보다 훨씬 높다. 1 Mbit/s 의 비트율로, 평균 데이터 길이 4 바이트에서는 초당 약 10,000 개의 메시지들이 전송될 수 있으며 8 바이트 데이터 길이(표준 포맷)에서는 초당 약 7,200 개의 메시지가 전송될 수 있다.

오류 검출/차단

CAN 프로토콜의 가장 눈에 띄는 특징 가운데 하나는 전송 오류를 검출하는데 특히 뛰어난 능력이다. 따라서 이것은 매우 높은 요구들, 예를 들면 모터 차량에서의 제어 장치들의 네트워킹을 충족시킨다. 뛰어난 오류 검출 능력은 오류 검출의 서로 다른 측정들의 결합으로 얻어진다. 이러한 점에서 가장 효과적인 측정들 중 하나는 모든 전역적인 유효 오류들을 검출하는 메시지의 전달자에 의한 버스 레벨의 모니터링이다. 또한, 모든 메시지 수신자가 정의된 포맷 요소와 CRC 세그먼트에 기초하여 수신된 각 메시지들을 확인한다. 이러한 방식으로 단지 국소적으로 유효한 오류들이 검출된다. 또한 전송 오류 검출 외에도, CAN 프로토콜은 결함 네트워크 노드들을 검출하고 차단하는 체계를 갖고 있다. 이는 결함 네트워크 노드들이 계속적으로 메시지 전송을 방해하는 것을 막을 수 있다.

오류 신호

노드-지향 전송의 통신 개념과는 대조적으로, 메시지-지향 프로토콜로서의 CAN 은 오류 신호(Error signaling) 원리를 사용한다. 각각의 네트워크 노드는 버스에서 전송된 모든 메시지를 오류와 관련하여 검사한다. 전송 또는 수신 네트워크 노드가 오류를 발견하는 즉시, 오류 메시지 (오류 프레임)를 전송함으로써 모든 다른 노드들에게 이것을 신호로 알린다. 이것은 일반적으로 우성 비트 순차로, 동일한 극성을 가진 여섯 비트들의 비트 조합을 포함한다. 모든 네트워크 노드들은 오류 신호를 탐지하고 이미 수신된 메시지의 세그먼트를 취소한다. 따라서 네트워크 모든 모드들에서 일관된 데이터가 확보된다. 전송 노드가 오류 프레임 또는 수신된 것을 전송하자마자, 이것은 즉시 다른 버스 중재 처리로 앞서 전달된 메시지를 다시 전송하려 시도한다. 오류 신호 체계는 네트워크의 모든 노드를 이용한 메시지 전송의 무-오류(error-free)와 일관성을 확보한다. 오류 신호는 오류가 검출된 후 즉시 발생하기 때문에, 매우 짧은 오류 복구 시간이 기능하다. 또한 오류가 발견되었을 때만 버스를 추가적으로 차지하는 것은 추가 버스 적재를 상당히 낮추는 장점을 갖는다.

메시지 구조

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은 차량용으로 개발되었으므로 가장 보편적인 애플리케이션은 차량 내의 전자 네트워킹이다. 차량용 외에도 오랜 기간 CAN의 안정성과 장점이 입증되면서 타 업계에서도 광범위한 애플리케이션에 CAN 버스를 도입하였다. 그 일례로 철도용 애플리케이션(트램, 지하철, 경전철, 장거리 열차 등)에 CAN이 도입되었다. 이와 같은 차량 내 여러 네트워크의 다른 레벨에서도 CAN을 찾아볼 수 있다. 또한 CAN은 항공기 상태 센서, 내비게이션 시스템, 조종실 내 리서치 PC 등 항공기 애플리케이션에도 적용되었다. 뿐만 아니라, 기내 데이터 분석에서부터 엔진 컨트롤 시스템(연료 시스템, 펌프, 선형 액추에이터 등)에 이르는 다양한 우주 항공 애플리케이션에서도 CAN 버스가 사용된다. 의료기기 제조업체들은 의료기기의 임베디드 네트워크로 CAN을 사용한다. 실제로 일부 병원에서는 CAN을 사용하여 수술실 전체를 관리하기도 한다. 즉, CAN 기반 시스템으로 조명, 테이블, 엑스레이 머신, 환자 침대 등 수술실에 배치된 모든 것을 컨트롤한다. 승강기와 에스컬레이터는 임베디드 CAN 네트워크를 사용하며, 병원에서는 CANopen 프로토콜을 사용하여 패널, 컨트롤러, 도어 안전장치 등의 디바이스를 서로 연결하며 컨트롤한다. 또한 CANopen은 실험실 장비, 스포츠 카메라, 망원경, 자동문, 커피 메이커 등의 비 산업용 애플리케이션에도 사용된다.

CAN 통신 프로토콜은 차량 내 네트워크로 적용하기에 적합한 여러 특징이 있다. 우선 CAN은 다른 차량 내부 통신 프로토콜에 비해 노드 설치비용 대비 통신 속도가 빠르다. 또한 cyclic redundancy check(CRC), bit stuffing 등의 오류 방지 기능을 적용하고 외부 노이즈에 강한 2선 차동 신호를 사용하여 높은 신뢰성을 갖추고 있다. 하지만 이러한 장점에도 불구하고, 차량에 탑재되는 ECU의 증가와 ECU 간의 데이터 전송량이 증가하게 되면서 CAN bus의 부하를 줄일 수 있는 새로운 프로토콜이 필요하게 되었다. CAN-FD는 CAN의 단점을 보완한 통신 프로토콜이다. 통신 속도가 1 Mbit/s로 일정한 CAN과 다르게 CAN-FD는 data phase에서 최대 8 Mbit/s 통신이 가능하다. 또한 하나의 CAN frame이 보낼 수 있는 데이터 전송량도 최대 64 byte로 증가하게 되면서 더 많은 데이터를 짧은 시간 동안 송수신할 수 있게 되었다. 이러한 장점은 CAN node 간의 빠른 통신을 가능하게 하며, 탑승자의 안전과 관련된 ECU의 데이터가 차량의 주행에 신속히 적용될 수 있도록 한다. 또한 CAN-FD는 CAN 통신과 호환이 가능하므로 CAN-FD 통신 프로토콜을 새롭게 적용할 때 비용 부담이 적다는 장점이 있다.

CAN-FD 프로토콜

CAN-FD 프로토콜을 적용한 차량의 ECU는 CAN node를 매개로 CAN frame을 송수신한다. CAN node는 CAN-FD 컨트롤러와 CAN transceiver로 구성되며, CAN bus와 2선 차동 신호로 연결되어 ECU 간의 통신을 가능하도록 한다. CAN node 내의 CAN-FD 컨트롤러는 ECU로부터 받은 데이터를 기반으로 CAN frame을 생성하거나, CAN bus로부터 받은 CAN frame을 샘플링하고 분석하여 data field 구간을 ECU에 전달하는 기능을 수행한다. CAN transceiver는 디지털 기반 시스템인 CAN-FD 컨트롤러가 아날로그 신호를 기반으로 한 CAN bus를 매개로 통신할 수 있도록 한다. CAN-FD 컨트롤러가 CAN frame을 송신하는 경우, CAN transceiver는 디지털 신호를 2선 차동 신호로 변환하는 기능을 수행한다. 반대로 CAN bus로부터 데이터를 받는 경우에는 2선 차동 신호를 디지털 신호로 변환하여 CAN-FD 컨트롤러가 CAN frame을 정상적으로 수신할 수 있도록 한다. CAN bus는 CAN node들을 물리적으로 연결하며, CAN high와 CAN low로 구성되는 2선 차동 신호를 사용하여 신뢰성을 갖추고 있다. 그림 1은 CAN 통신에서 사용하는 2선 차동 신호를 나타낸다. 디지털 신호 값이 0일 때, CAN high와 CAN low 신호는 기준 전압인 2.5V를 갖는다. 이는 CAN 통신에서 dominant이며 우성 bit를 의미한다. 반대로 디지털 신호 값이 1이면, CAN high와 CAN low 신호는 각각 3.5V, 1.5V를 갖는다. 해당 신호를 CAN 통신에서는 recessive로 규정하며, 이는 열성 bit를 의미한다. Dominant는 recessive보다 우선권을 가지며, CAN bus는 2선 차동 신호의 특성을 사용하여 CAN node에 우선순위를 부여한다. 각각의 CAN node는 고유 ID를 갖게 되는데, 통신 하고자 하는 다른 CAN node들과 MSB에서 LSB순으로 ID를 비교하여 우선순위가 높은 CAN node가 CAN bus를 먼저 사용할 수 있게 한다. CAN 통신 프로토콜의 우선순위 특성은 차량에서 중요한 기능을 수행하는 CAN node에게 우선순위가 더 높은 ID를 할당하여, CAN bus를 사용하고자 하는 CAN node가 많은 경우에도 차량의 정상적인 동작이 가능하게 한다.

접근법

BasicCAN/FullCAN

BasicCAN 과 FullCAN 이라 이름 붙여진, 두 개의 일반적인 CAN 접근법이 있다. 이것들은 들어오고 나가는 데이터가 처리되는 방식에서 서로 다르다. 간단히 말하면, BasicCAN은 CAN 메시지 전송과 수신을 처리하기 위해 호스트 CPU를 필요로 하며, 프레임 저장소를 다룬다. FullCAN은 메시지 전송, 메시지 수신 그리고 최대 16개 메시지들의 저장을 CAN 컨트롤러에 맡긴다. CPU는 정보가 필요할 때 CAN 컨트롤러에 문의한다. 이 방식에서, FullCAN은 CAN 처리의 책임을 CPU에서 배제시킨다 - 다른 작업들을 처리할 수 있는 자유를 부여. FullCAN에서 CAN 컨트롤러는 인터럽트가 설정되어 있다면 CPU를 인터럽트 할 수 있다 - 그리고 어떤 지정된 ID를 가진 메시지가 수신된다면 컨트롤러가 CPU를 인터럽트 하면서 "필터링 허용' 같은 작업들을 처리할 수 있다.

Standard CAN/Extended CAN

표준 CAN에서는 식별자들이 11비트 길이를 가지며 확장 CAN에서는 식별자들이 29비트 길이를 갖는다. CAN 프로토콜 버전 2.0 에서 명시된 것에 의하면, V2.0A 로 컴파일 하는 CAN 컨트롤러는 반드시 11-비트 식별자를 가져야만 한다. 반면 V2.0B 에서는, 11비트 또는 29비트 아무 것이나 될 수 있다. V2.0B active를 이용하면, CAN 컨트롤러는 표준 포맷과 확장 포맷 모두를 전송하고 수신할 수 있다. V2.0B passive를 이용하면, CAN 컨트롤러는 표준 프레임을 전송하고 수신하게 되며 확장 프레임은 오류 없이 무시하게 된다.