CAN

CAN 은 자동차 안의 작은 컴퓨터들이 선 두 가닥을 함께 쓰며 메시지를 주고받게 해 주는 통신 규칙입니다. 자동차 한 대에 들어 있는 여러 제어 장치가 같은 두 가닥에 매달립니다. 급한 메시지가 언제나 먼저 나가도록 차례도 정해 줍니다. 잡음이 많은 공장 기계에서도 씁니다.

상세

CAN(Controller Area Network, 컨트롤러 영역 네트워크)은 여러 장치가 버스 하나를 함께 쓰며 짧은 메시지를 주고받는 규칙입니다. 버스는 여러 장치가 함께 쓰는 선 묶음입니다. CAN 버스에 매달린 장치 하나하나를 노드라고 부릅니다.

자동차에서는 노드가 대개 ECU(Electronic Control Unit, 전자 제어 장치)입니다. ECU 는 엔진이나 브레이크 같은 부품 하나를 맡아 센서 값을 읽고 부품을 움직이는 작은 컴퓨터입니다. 자동차 한 대에 ECU 가 여럿 들어갑니다.

이 절은 먼저 CAN 이 왜 생겼고 노드를 어떻게 잇는지 봅니다. 그다음 누가 먼저 보낼지 정하는 방법과 메시지 한 개의 모양, 그 안에서 오가는 확인 응답을 따라갑니다. 끝으로 오류를 다루는 법, 속도의 한계, 운영체제에서 보이는 모습을 보고 이웃 통신 방식과 견줍니다.

배선을 줄이려고 함께 쓰는 두 가닥

장치끼리 선을 하나하나 이으면 장치가 늘 때마다 선이 불어납니다. 장치가 열 개면 둘씩 짝짓는 연결만 마흔다섯 개입니다. 선이 늘면 차가 무거워집니다. 이을 곳이 많으니 고장 날 곳도 늘어납니다.

CAN 은 모든 노드가 같은 두 가닥에 매달리게 합니다. 노드가 하나 늘어도 그 노드를 버스에 잇기만 하면 됩니다.

대신 여럿이 한 선을 나눠 쓰니 누가 언제 말할지 정하는 규칙이 필요합니다. 아래 소절 대부분이 이 규칙을 다룹니다.

CAN_H 와 CAN_L 의 전압 차

CAN 의 두 가닥은 CAN_H 와 CAN_L 이라고 부릅니다. H 는 high, L 은 low 의 머리글자입니다. 두 선은 같은 비트를 함께 싣습니다.

받는 쪽은 한 선의 전압이 아니라 두 선의 전압 차를 읽습니다. 이런 방식을 차동 신호라고 합니다. 차이가 크게 벌어져 있으면 0, 차이가 거의 없으면 1 로 읽습니다.

차동 신호를 쓰면 잡음이 끼어도 값이 덜 틀어집니다. 엔진 점화 같은 전기 잡음은 나란히 놓인 두 선에 거의 똑같이 끼어듭니다. 두 선이 함께 오르내리니 둘의 차이는 바뀌지 않습니다.

두 선은 대개 서로 꼬아서 깝니다. 꼬아 두면 두 선이 같은 잡음을 받기 쉬워집니다. 이런 선을 트위스티드 페어라고 합니다.

버스의 양 끝에는 종단 저항을 하나씩 답니다. 선 끝에 닿은 신호가 되튀어 돌아오면 다음 비트와 섞입니다. 종단 저항이 이 되튐을 막습니다.

노드 하나를 이루는 세 부품

노드 하나는 대개 세 부품으로 나뉩니다. 맨 위는 일을 하는 마이크로컨트롤러입니다. 마이크로컨트롤러는 프로세서와 메모리를 칩 하나에 담은 작은 컴퓨터입니다.

그 아래 CAN 컨트롤러가 메시지를 비트로 바꿔 내보냅니다. 받은 비트는 다시 메시지로 묶습니다. 누가 먼저 보낼지 가리는 일과 오류 검사도 CAN 컨트롤러가 합니다. 이 부품은 마이크로컨트롤러 칩 안에 들어 있기도 합니다.

맨 아래 CAN 트랜시버는 비트를 두 선의 전압으로 바꿉니다. 반대로 두 선의 전압 차를 읽어 비트로 돌려줍니다.

flowchart TD
    subgraph N1["노드 하나"]
        M["마이크로컨트롤러"] --> C["CAN 컨트롤러"] --> X["CAN 트랜시버"]
    end
    X --- B["버스 · CAN_H 와 CAN_L 두 가닥"]
    B --- N2["다른 노드"]
    B --- N3["다른 노드"]
    T1["한쪽 끝 · 종단 저항"] --- B
    B --- T2["다른 쪽 끝 · 종단 저항"]

그림의 다른 노드들도 속은 왼쪽 노드와 같은 세 부품입니다. 모든 노드가 트랜시버를 거쳐 같은 두 가닥에 붙습니다.

0 이 1 을 덮는 우성과 열성

CAN 에서는 두 값에 이름이 따로 있습니다. 0 은 우성(dominant), 1 은 열성(recessive)이라고 부릅니다. 이름처럼 0 이 1 을 이깁니다.

열성은 노드가 선을 놓아두는 상태입니다. 우성은 노드가 두 선의 전압을 벌려 놓는 상태입니다. 한 노드라도 전압을 벌리면 선은 우성이 됩니다.

아래 표는 두 노드가 같은 순간에 값을 보낼 때 선에 남는 값입니다.

모든 노드가 1 을 보낼 때만 선이 1 로 남습니다. 여럿이 동시에 보내도 선의 값은 늘 하나로 정해집니다. 뒤에 나오는 중재와 확인 응답과 오류 알림이 모두 이 성질을 씁니다.

주소 대신 식별자

CAN 메시지에는 받을 노드의 주소가 없습니다. 대신 메시지마다 식별자(identifier)라는 번호가 붙습니다.

식별자는 「누구에게」가 아니라 「무슨 값인가」를 말합니다. 예를 들어 식별자 0x123 을 「바퀴 속도」로 정해 두면 바퀴 속도를 재는 노드는 늘 이 번호로 값을 내보냅니다. 0x 는 16진수라는 표시입니다.

보낸 메시지는 버스의 모든 노드에 닿습니다. 이렇게 모두에게 한꺼번에 보내는 방식을 브로드캐스트라고 합니다. 노드마다 자기에게 필요한 식별자만 골라 받고 나머지는 버립니다.

덕분에 노드를 더해도 다른 노드를 고칠 필요가 없습니다. 새 계기판이 바퀴 속도를 보고 싶으면 0x123 을 받기만 하면 됩니다. 보내는 노드는 누가 듣는지 모릅니다.

기판 위의 칩을 잇는 I2C(Inter-Integrated Circuit, 집적 회로 간 통신)는 이와 반대입니다. 상대 칩의 주소를 불러 말을 겁니다. CAN 은 받을 쪽을 고르지 않고 무슨 값인지만 밝힙니다.

CAN 에서 메시지 하나를 실어 나르는 비트 묶음을 프레임이라고 합니다. 식별자는 이 프레임에 실려 나갑니다.

기본 프레임의 식별자는 11비트라서 번호를 2048 가지 쓸 수 있습니다. 번호가 모자라는 곳을 위해 29비트 식별자를 쓰는 확장 프레임도 있습니다.

번호가 작은 메시지가 이기는 중재

버스가 조용하면 어느 노드든 보내기 시작할 수 있습니다. 두 노드가 같은 순간에 시작하는 일도 생깁니다. 이때 누가 계속 보낼지 정하는 과정을 중재(arbitration)라고 합니다.

보내는 노드는 비트 하나를 내보낼 때마다 선을 다시 읽습니다. 자기가 1 을 보냈는데 선이 0 이면 다른 누군가 0 을 보낸 것입니다. 그 노드는 바로 보내기를 멈추고 받는 쪽으로 돌아섭니다.

식별자는 가장 큰 자리의 비트부터 나갑니다. 그래서 처음 갈리는 비트에서 0 을 가진 쪽, 곧 식별자가 작은 쪽이 이깁니다. 아래는 0x123 과 0x12A 가 같은 순간에 시작한 경우입니다.

노드 A  001 0010 0011   // 0x123
노드 B  001 0010 1      // 여기서 물러남
선      001 0010 0011   // A 의 비트만 남음

일곱째 비트까지는 둘이 같아서 선도 같은 값입니다. 여덟째 비트에서 A 는 0, B 는 1 을 보냅니다. 선은 0 이 됩니다. B 는 자기가 보낸 값과 다른 것을 보고 물러납니다. A 는 끊기지 않고 끝까지 보냅니다.

물러난 B 는 버스가 다시 조용해지면 같은 프레임을 다시 보냅니다. 진 쪽도 프레임을 잃지 않고 이긴 쪽도 시간을 잃지 않습니다. 예전 이더넷은 둘이 동시에 보내면 두 프레임이 다 깨져 둘 다 다시 보냈습니다. CAN 에서는 이긴 쪽의 프레임이 깨지지 않습니다.

식별자 번호가 곧 우선순위인 셈입니다. 브레이크처럼 급한 메시지에 작은 번호를 줍니다. 같은 식별자를 두 노드가 함께 쓰면 중재가 갈리지 않으므로 번호는 미리 나눠 둡니다.

데이터 프레임의 모양

값을 실어 나르는 프레임을 데이터 프레임이라고 합니다. 아래 표는 기본 식별자를 쓰는 데이터 프레임이 앞에서부터 무엇으로 이루어지는지 보입니다.

표의 검사값은 CRC(Cyclic Redundancy Check, 순환 중복 검사)입니다. 보내는 쪽이 앞부분 비트로 값을 계산해 붙입니다. 받는 쪽은 같은 계산을 해서 실려 온 값과 맞춰 봅니다.

표의 구분 비트는 늘 1 인 비트 하나입니다. 앞 칸과 뒤 칸 사이를 띄워 둡니다.

제어 부분의 네 비트가 데이터 길이를 적습니다. 이 값을 DLC(Data Length Code, 데이터 길이 코드)라고 합니다. 원격 요청 비트는 조금 뒤 리모트 프레임에서 다시 봅니다.

데이터가 많아야 8바이트라서 프레임 하나가 짧습니다. 한 노드가 버스를 오래 붙잡지 못하니 급한 메시지가 오래 기다리지 않습니다. 프레임과 프레임 사이에는 1 이 세 개 이상 끼어 쉼을 둡니다.

한 프레임 안에서 오가는 확인 응답

CAN 에서는 보내고 잘 받았다는 답을 듣는 왕복이 프레임 하나 안에서 끝납니다. 보내는 노드는 검사값까지 보내고 확인 응답 칸에 이르면 1 을 내보냅니다. 1 은 열성이라 누구든 0 으로 덮을 수 있습니다.

프레임을 탈 없이 받은 노드는 바로 그 칸에 0 을 보냅니다. 보내는 노드는 그 칸에서 선을 읽어 0 이면 누군가 받았다고 압니다. 1 이 남아 있으면 아무도 못 받은 것이라 오류로 칩니다.

sequenceDiagram
    participant S as 보내는 노드
    participant R as 받는 노드들
    S->>R: 시작 · 식별자 · 제어 · 데이터 · 검사값
    Note over R: 검사값을 맞춰 본다
    S->>R: 확인 응답 칸에 1
    R-->>S: 같은 칸에 0 을 덮어쓴다
    S->>R: 구분 비트 · 끝

그림처럼 받는 쪽의 답은 프레임을 따로 만들지 않습니다. 보내는 노드가 비워 둔 한 비트를 받는 쪽이 채우는 것이 전부입니다.

이 답이 알려 주는 것은 「누군가 받았다」까지입니다. 그 값이 필요한 노드가 받았는지는 모릅니다. 노드 열 개 중 하나만 받아도 확인 응답 칸은 0 이 됩니다.

값을 달라고 묻는 리모트 프레임

노드가 값을 기다리지 않고 먼저 물을 수도 있습니다. 이때 보내는 것이 리모트 프레임입니다. 원격 요청 비트를 1 로 두고 데이터 없이 식별자만 보냅니다.

그 식별자의 값을 맡은 노드가 이 프레임을 보면 같은 식별자로 데이터 프레임을 내보냅니다. 묻는 프레임 하나와 답하는 프레임 하나가 왕복을 이룹니다.

현장에서는 리모트 프레임보다 노드가 정해진 주기마다 값을 내보내는 방식이 더 흔합니다. 바퀴 속도 노드가 묻지 않아도 일정한 간격으로 속도를 내보내는 식입니다.

클록 선 없이 박자를 맞추는 비트 스터핑

CAN 에는 박자를 알려 주는 클록 선이 없습니다. 노드마다 미리 같은 속도로 맞춰 두고 각자 자기 시계로 비트를 읽습니다. 두 시계는 조금씩 어긋나므로 중간중간 다시 맞춰야 합니다.

노드는 선의 값이 1 에서 0 으로 바뀌는 순간에 자기 시계를 다시 맞춥니다. 그런데 같은 값이 길게 이어지면 바뀌는 순간이 오지 않습니다.

그래서 보내는 노드는 같은 비트가 다섯 개 이어지면 반대 비트를 하나 끼워 넣습니다. 이것을 비트 스터핑(bit stuffing)이라고 합니다. 받는 노드는 같은 비트 다섯 개 뒤에 온 그 비트를 빼고 읽습니다.

0000 0000      // 보내려는 비트
00000 1 000    // 선으로 나가는 비트

0 여덟 개 중 다섯째 뒤에 1 이 하나 끼었습니다. 받는 쪽은 이 1 을 버리고 0 여덟 개로 되돌립니다.

이 규칙에는 덤이 하나 있습니다. 프레임의 시작부터 검사값까지는 같은 비트가 여섯 개 이어질 수 없습니다. 거꾸로 같은 비트 여섯 개를 「무언가 잘못됐다」는 신호로 쓸 수 있습니다. 다음 소절의 오류 프레임이 이 성질을 씁니다.

오류를 모두에게 알리는 오류 프레임

CAN 노드는 프레임을 주고받으며 여러 가지를 검사합니다. 아래 표는 노드가 무엇을 보고 오류로 판단하는지 보입니다.

오류를 찾은 노드는 바로 0 여섯 개를 잇달아 보냅니다. 같은 비트 여섯 개는 스터핑 규칙을 어기므로 다른 노드도 모두 오류를 알아챕니다. 이렇게 오류를 알리는 비트 묶음을 오류 프레임이라고 합니다.

오류 프레임을 본 노드는 모두 지금 받던 프레임을 버립니다. 보내던 노드는 버스가 조용해지면 같은 프레임을 저절로 다시 보냅니다. 프로그램이 재전송을 따로 챙기지 않아도 됩니다.

이 방식 덕분에 노드들은 대개 같은 결과를 봅니다. 한 노드가 버린 프레임은 다른 노드도 버립니다.

고장 난 노드를 떼어 내는 오류 카운터

오류 프레임에는 위험이 하나 있습니다. 고장 난 노드 하나가 멀쩡한 프레임마다 오류를 외치면 버스 전체가 멈춥니다. CAN 은 이런 노드가 스스로 물러나게 합니다.

노드마다 오류 카운터를 두 개 둡니다. 송신 카운터는 보낼 때 난 오류를 셉니다. 수신 카운터는 받을 때 난 오류를 셉니다.

보낼 때 오류가 나면 송신 카운터가 8 오릅니다. 받을 때는 수신 카운터가 대개 1 오릅니다. 탈 없이 주고받을 때마다 1 씩 내려갑니다.

카운터 값에 따라 노드는 세 상태를 오갑니다. 아래 그림이 그 흐름입니다.

stateDiagram-v2
    state "에러 액티브" as A
    state "에러 패시브" as P
    state "버스 오프" as O
    [*] --> A
    A --> P: 카운터 하나가 128 에 이름
    P --> A: 둘 다 128 아래로 내려감
    P --> O: 송신 카운터가 256 에 이름
    O --> A: 다시 붙는 절차

처음에는 에러 액티브 상태입니다. 상태 이름의 에러는 오류와 같은 말입니다. 오류를 보면 앞에서 본 대로 0 여섯 개를 보내 모두에게 알립니다.

카운터 하나가 128 에 이르면 에러 패시브 상태가 됩니다. 이 노드는 오류를 알릴 때 1 여섯 개를 보냅니다. 1 은 열성이라 다른 노드가 보내는 프레임을 깨지 못합니다. 자주 틀리는 노드가 남의 통신을 끊지 못하게 목소리를 낮추는 것입니다.

송신 카운터가 256 에 이르면 버스 오프 상태가 됩니다. 노드는 버스에서 손을 떼고 아무것도 보내지 않습니다. 버스가 한동안 조용한 것을 정해진 횟수만큼 확인한 뒤에야 다시 붙을 수 있습니다. 많은 시스템은 이때 다시 붙일지를 소프트웨어가 정하게 둡니다.

속도와 선 길이

CAN 은 초당 최대 100만 비트, 곧 1Mbit/s 로 보냅니다. 선이 길수록 이 속도를 낮춰야 합니다.

중재 때문입니다. 중재가 되려면 비트 하나가 끝나기 전에 버스의 모든 노드가 같은 값을 봐야 합니다. 선이 길면 신호가 끝까지 갔다 오는 데 시간이 더 걸립니다. 그만큼 비트 하나를 길게 잡아야 하니 속도가 내려갑니다.

데이터를 많이 나르는 데는 맞지 않습니다. 8바이트를 싣는 프레임 하나에 앞뒤로 수십 비트가 더 붙습니다. CAN 은 짧은 값을 자주, 놓치지 않고 나르는 쪽에 맞춰져 있습니다.

이 한계를 넓힌 것이 CAN FD(CAN with Flexible Data-rate, 유연한 데이터 속도의 CAN)입니다. 한 프레임에 64바이트까지 싣습니다.

CAN FD 는 중재가 끝나면 데이터 부분만 더 높은 속도로 보냅니다. 확인 응답 앞에서는 원래 속도로 돌아옵니다. 확인 응답도 중재처럼 모든 노드가 같은 비트를 함께 봐야 하기 때문입니다.

CAN 위에 얹히는 규약

CAN 이 정하는 것은 프레임을 탈 없이 나르는 데까지입니다. 식별자 0x123 이 바퀴 속도인지, 데이터 바이트가 어떤 단위인지는 정하지 않습니다. 그 뜻은 차 제조사가 정하거나 CAN 위에 얹힌 다른 규약이 정합니다.

산업 기계를 잇는 CANopen, 트럭과 버스 같은 대형 차량의 J1939 가 그런 규약입니다. 자동차 고장 진단 단자로 쓰는 OBD-II(On-Board Diagnostics II, 차량 자가 진단 2판)도 요즘 차에서는 CAN 위로 오갑니다.

8바이트보다 큰 값은 여러 프레임으로 쪼개 보내고 받는 쪽이 다시 잇습니다. 이 쪼개기와 잇기도 CAN 위의 규약이 맡습니다.

리눅스에서 네트워크 인터페이스로 보이는 CAN

리눅스는 CAN 을 네트워크 인터페이스로 내놓습니다. 이 구조를 SocketCAN이라고 부릅니다. CAN 장치를 붙이면 이더넷의 eth0 처럼 can0 이라는 인터페이스 이름이 생깁니다.

프로그램은 소켓을 열어 프레임을 주고받습니다. 웹 서버가 TCP(Transmission Control Protocol, 전송 제어 프로토콜) 소켓으로 바이트를 읽고 쓰는 것과 같은 방식입니다. 다른 점은 주고받는 단위가 바이트의 흐름이 아니라 CAN 프레임 하나라는 것입니다.

명령줄에서 시험할 때는 can-utils 라는 도구 묶음의 cansend 와 candump 를 흔히 씁니다. 아래 첫 줄은 받는 터미널에서 먼저 띄워 둡니다. 둘째 줄은 다른 터미널에서 식별자 0x123 으로 4바이트를 보냅니다. 첫 줄 오른쪽 주석은 그때 받는 터미널에 찍히는 프레임입니다.

candump can0 # 찍힘 can0 123 [4] 11 22 33 44
cansend can0 123#11223344 # 보낸다

123#11223344 에서 # 앞은 16진수 식별자입니다. 뒤는 데이터 바이트입니다. candump 가 찍은 [4] 는 데이터 길이, 곧 DLC 입니다.

하드웨어 없이 시험할 수도 있습니다. 리눅스는 vcan 이라는 가상 CAN 인터페이스를 만들어 줍니다. 선이 없어도 프로그램끼리 CAN 프레임을 주고받아 볼 수 있습니다.

I2C·SPI 와 견줌

I2C 와 SPI(Serial Peripheral Interface, 직렬 주변 장치 인터페이스)는 한 기판 위의 칩을 잇는 통신 규칙입니다. I2C 는 선 두 가닥에 칩 여러 개를 매달고 주소로 상대를 부릅니다. SPI 는 칩마다 선택선을 따로 깔아 상대를 고릅니다.

두 방식 모두 대화를 여는 칩이 정해져 있습니다. 이 칩을 컨트롤러라고 부릅니다. 앞에서 본 CAN 컨트롤러와는 다른 말입니다. 아래 표는 기판 밖의 장치끼리 잇는 CAN 이 두 방식과 무엇이 다른지 견줍니다.

CAN 은 서로 떨어진 장치 여럿이 잡음 속에서 짧은 값을 놓치지 않고 나눠야 할 때 씁니다. 자동차, 공장 기계, 로봇, 의료 장비가 그런 곳입니다.

큰 데이터를 나르는 데는 쓰지 않습니다. 카메라 영상처럼 큰 데이터를 다루는 차에서는 이더넷 같은 다른 방식을 함께 씁니다. 인터넷처럼 주소로 멀리 있는 상대를 찾는 일도 CAN 이 맡지 않습니다.

관련 항목

CAN 프레임을 이루는 부분

식별자 · 데이터 프레임 · 리모트 프레임 · 오류 프레임 · 확장 프레임 · 데이터 길이 코드 · CRC · 확인 응답 · 프레임

CAN 이 비트를 다루는 방식

우성 · 열성 · 버스 중재 · 비트 스터핑 · 차동 신호 · 브로드캐스트 · 직렬 통신 · 클록 · 우선순위

CAN 노드를 이루는 부품과 배선

ECU · 마이크로컨트롤러 · CAN 컨트롤러 · CAN 트랜시버 · 트위스티드 페어 · 종단 저항 · 노드

CAN 노드가 오류를 겪으며 오가는 상태

에러 액티브 · 에러 패시브 · 버스 오프 · 오류 · 재전송

CAN 위에 얹히는 상위 규약

CANopen · J1939 · OBD-II · ISO-TP · UDS · DeviceNet

CAN 을 넓힌 후속 규격

CAN FD · CAN XL · TTCAN

CAN 과 같은 역할을 두고 겨루는 통신 방식

LIN · FlexRay · RS-485 · 이더넷 · 차량용 이더넷 · I2C · SPI · UART

리눅스에서 CAN 을 다루는 구성 요소

SocketCAN · can-utils · vcan · 소켓 · 네트워크 인터페이스 · 디바이스 드라이버 · Linux

CAN 이 속하는 상위 분류

버스 · 필드버스 · 차량 네트워크 · 임베디드 · 네트워크

CAN 을 쓰는 산업 분야

자동차 전장 · 산업 자동화 · 로봇 · 의료 기기