Booil Jung

Controller Area Network(CAN) 통신

1980년대 이전, 자동차 산업은 전자 기술의 도입으로 급격한 변화를 맞이하고 있었다. 엔진 제어, 변속기 제어, 잠김 방지 제동 시스템(ABS) 등 다양한 기능을 수행하는 전자 제어 장치(ECU, Electronic Control Unit)의 수가 증가함에 따라, 이들 간의 정보 교환 필요성 또한 증대되었다. 당시의 통신 방식은 각 ECU를 필요한 다른 ECU와 개별적으로 연결하는 점대점(Point-to-Point) 배선에 의존했다.1 이러한 방식은 차량 내 기능이 복잡해질수록 배선 뭉치, 즉 와이어 하네스(wire harness)의 부피, 무게, 그리고 비용을 기하급수적으로 증가시키는 명백한 한계에 봉착했다. 배선 복잡성의 증가는 생산 공정의 난이도를 높이고, 잠재적인 고장 지점을 늘려 차량의 신뢰성을 저해하는 요인으로 작용했다.1

이러한 구조적 문제를 해결하기 위해, 독일의 Robert Bosch 사는 1983년 새로운 차량용 네트워크 프로토콜 개발에 착수하여 1986년, Controller Area Network(CAN)를 세상에 처음 공개했다.3 CAN의 등장은 단순히 배선을 줄이는 기술적 개선을 넘어, 차량 내 전자 시스템 아키텍처의 근본적인 패러다임 전환을 이끌었다. 여러 ECU가 단 두 가닥의 공용 버스 라인을 통해 데이터를 주고받을 수 있게 됨으로써, 차량 전장 시스템은 비로소 효율적이고 확장 가능한 네트워크 구조를 갖추게 되었다. 이후 CAN은 1991년 국제 표준화 기구(ISO)에 의해 ISO 11898 표준으로 공식화되면서 전 세계 자동차 산업의 표준 통신 프로토콜로 확고히 자리 잡았다.3

CAN 프로토콜은 기존의 중앙 집중형 통신 방식과 근본적으로 다른 두 가지 핵심 철학을 바탕으로 설계되었다.

첫째는 멀티-마스터(Multi-Master) 방식의 분산 제어 구조이다. CAN 네트워크에는 통신을 총괄하는 중앙 호스트 컴퓨터나 마스터(Master) 노드가 존재하지 않는다.3 버스에 연결된 모든 노드는 동등한 자격을 가지며, 버스가 비어있을 때 언제든지 데이터를 전송할 수 있다.6 이는 특정 마스터 노드의 고장이 전체 시스템의 마비로 이어지는 단일 지점 장애(Single Point of Failure)를 원천적으로 배제하여 시스템 전체의 강건성(Robustness)을 극대화한다.3

둘째는 ‘주소’가 아닌 ‘메시지 식별자(Identifier)’ 기반의 통신이다. CAN 통신에서 노드는 특정 수신자를 지정하여 메시지를 보내지 않는다.8 대신, 전송하려는 데이터의 종류와 중요도를 나타내는 고유한 메시지 ID를 프레임 앞부분에 담아 버스 전체에 브로드캐스트(Broadcast)한다.10 버스에 연결된 모든 노드는 이 메시지를 수신한 후, 메시지 ID를 확인하여 자신에게 필요한 정보인지를 판단하고 선택적으로 처리한다.10 이러한 ‘생산자-소비자(Producer-Consumer)’ 모델은 시스템의 유연성과 확장성을 획기적으로 향상시킨다. 새로운 노드를 추가할 때 기존 노드들의 소프트웨어를 변경할 필요 없이, 필요한 메시지 ID를 수신하도록 설정하기만 하면 되기 때문이다.8

이러한 설계 철학을 바탕으로 CAN은 다음과 같은 독보적인 장점을 제공한다.

• 배선 절감 및 비용 효율성: 단일 버스를 공유함으로써 기존 점대점 방식 대비 배선을 획기적으로 줄여 차량의 무게를 감소시키고, 이는 연비 향상으로 이어진다. 또한, 배선 복잡성 감소는 생산 비용과 시간을 절감하는 효과를 가져온다.1
• 높은 신뢰성: 전기적 노이즈가 극심한 차량 환경에서도 안정적인 통신을 보장하기 위해 차동 신호 방식과 강력한 다단계 오류 감지 및 처리 메커니즘을 내장하고 있다.3
• 실시간성 보장: 메시지 ID에 기반한 비파괴적 우선순위 중재 방식을 통해, 여러 노드가 동시에 데이터를 전송하려 할 때에도 가장 긴급한 데이터가 지연 없이 전송되도록 보장한다. 이는 결정론적(Deterministic) 통신을 가능하게 하여 안전이 중요한 제어 시스템에 필수적이다.10

CAN의 설계 철학인 ‘탈중앙화된 메시지 중심 브로드캐스트’는 단일 지점 장애를 제거하여 놀라운 강건성을 확보했다. 어떤 노드가 고장 나도 나머지 네트워크는 정상적으로 동작할 수 있다. 하지만 바로 이 점이 CAN의 근본적인 보안 취약점을 낳았다. 프로토콜은 메시지의 내용, 즉 ID는 신뢰하지만 그 메시지를 보낸 물리적 송신자(Source)는 전혀 검증하지 않는다. 이는 네트워크에 연결된 모든 노드가 선의를 가지고 동작한다는 암묵적인 신뢰를 전제로 한 설계이며, 이로 인해 메시지 위조(Spoofing)와 같은 공격에 본질적으로 취약하게 된다. 어떤 노드든 특정 ID를 가진 메시지를 버스에 전송할 수 있다는 것은, 시스템이 ID ‘0x123’이 엔진 RPM 정보를 담고 있다는 사실은 알지만, 이 메시지를 실제 ‘엔진 ECU’가 보냈는지, 아니면 악의적으로 연결된 ‘공격자 노드’가 보냈는지를 구별할 방법이 프로토콜 자체에는 없음을 의미한다. 이 ‘송신자 익명성’은 시스템의 유연성과 강건성을 높이는 핵심 요소인 동시에, 보안 관점에서는 ‘인증 부재’와 동일한 의미다. 따라서 CAN의 가장 뛰어난 설계 특징이 동시에 가장 큰 보안 허점이 되는 역설적인 구조를 가지고 있으며, 이는 본 보고서의 후반부에서 심도 있게 다룰 핵심 주제가 된다.

CAN 프로토콜의 높은 신뢰성과 핵심 기능들은 물리 계층의 정교한 전기적 설계에 깊이 뿌리내리고 있다. 물리 계층은 단순히 비트를 전기 신호로 변환하여 전송하는 수동적인 매체를 넘어, 데이터 링크 계층의 핵심 로직을 구현하는 능동적인 역할을 수행한다.

CAN 통신은 CAN_High (CAN_H)와 CAN_Low (CAN_L)라는 두 개의 전선을 꼬아 만든 꼬임쌍선(Twisted Pair)을 통해 이루어진다.12 이는 단일 전선을 사용하는 방식과 달리, 두 전선 간의 ‘전압 차이’($V_{diff}$)를 이용하여 논리 상태를 구분하는 차동 신호 방식을 채택한다.17

이 방식의 가장 큰 장점은 외부 노이즈에 대한 강한 내성이다. 자동차 내부에는 모터, 점화 장치, 각종 스위치 등 강력한 전자기 간섭(EMI)을 발생시키는 원인이 많다.16 외부에서 유입되는 이러한 공통 모드 노이즈(Common-mode Noise)는 물리적으로 인접한 두 전선에 거의 동일한 크기와 위상으로 영향을 미친다. 따라서 각 전선의 대지 전압은 변동하더라도, 두 전선 간의 전압 차이($V_{diff}$)는 거의 변하지 않고 유지된다.17 CAN 트랜시버는 이 차동 전압만을 감지하여 데이터를 복원하므로, 노이즈가 심한 환경에서도 매우 안정적인 통신이 가능하다.21

CAN 버스는 두 가지의 명확한 논리 상태를 가지며, 이는 각각 고유한 전기적 특성을 통해 구현된다. 이 두 상태는 논리 ‘0’에 해당하는 우성(Dominant)과 논리 ‘1’에 해당하는 열성(Recessive)으로 정의된다.6

가장 널리 사용되는 고속 CAN(High-Speed CAN, ISO 11898-2 표준)의 경우, 각 상태의 전압 레벨은 다음과 같다.10

• 열성 상태 (Recessive State): 이 상태는 버스가 유휴(Idle) 상태일 때의 기본 상태이며, 논리 ‘1’을 나타낸다. 이때 CAN_H와 CAN_L 라인의 전압은 모두 약 2.5V로 동일한 수준을 유지한다. 따라서 두 라인 간의 차동 전압은 거의 0V에 가깝다 ($V_{diff} = V_{CAN_H} - V_{CAN_L} \approx 0V$).17
• 우성 상태 (Dominant State): 이 상태는 논리 ‘0’을 나타낸다. 트랜시버가 우성 상태를 구동하면, CAN_H 라인의 전압은 약 3.5V로 상승하고 CAN_L 라인의 전압은 약 1.5V로 하강한다. 이로 인해 약 2.0V의 명확한 차동 전압이 발생한다 ($V_{diff} \approx 2.0V$).14

수신 측 트랜시버는 이 차동 전압을 특정 임계값(Threshold)과 비교하여 논리 상태를 판별한다. ISO 표준에 따르면, 차동 전압이 0.9V보다 크면 우성 상태로, 0.5V보다 작으면 열성 상태로 인식하도록 규정되어 있다.17 0.5V와 0.9V 사이는 불확실한 구간으로 정의하여 신호 판별의 안정성을 높인다.

CAN 버스의 가장 중요한 물리적 특징 중 하나는 ‘Wired-AND’ 동작 원리이다. 이는 여러 노드가 동시에 버스에 신호를 전송할 때 발생하는 충돌을 해결하는 근간이 된다. 이 원리는 다음과 같이 요약할 수 있다: 단 하나의 노드라도 우성(Dominant) 상태를 전송하면, 전체 버스는 우성 상태가 된다. 버스가 열성(Recessive) 상태가 되기 위해서는 네트워크에 연결된 모든 노드가 동시에 열성 상태를 전송해야만 한다.6

이러한 현상은 각 상태의 전기적 구동 방식 차이에서 비롯된다. 우성 상태는 트랜지스터를 통해 능동적으로 전압을 구동하는 강한 신호인 반면, 열성 상태는 종단 저항에 의해 약하게 바이어스되는 수동적인 상태다. 따라서 우성 신호는 열성 신호를 항상 덮어쓸(overwrite) 수 있다.17 이 물리적 특성은 데이터 링크 계층에서 이루어지는 비트 단위 중재(Bit-wise Arbitration) 메커니즘을 하드웨어적으로 완벽하게 지원하는 기반이 된다.

CAN 버스는 물리적으로 두 개의 전선을 서로 꼬아 만든 꼬임쌍선(Twisted Pair Cable)을 사용한다.12 전선을 꼬는 이유는 외부에서 유입되는 자기장 형태의 노이즈가 두 전선에 동일하게 유도되도록 하기 위함이다. 각 꼬임 루프에서 유도되는 노이즈 전류의 방향이 서로 반대가 되어 상쇄되므로, 노이즈 제거 효과를 극대화할 수 있다.16

또한, 안정적인 고속 통신을 위해 버스 라인의 양쪽 끝단에는 반드시 120Ω의 종단 저항(Termination Resistor)을 연결해야 한다.15 이 저항은 두 가지 핵심적인 역할을 수행한다. 첫째, 고주파 신호가 케이블 끝에서 반사되어 되돌아와 원래의 신호와 간섭을 일으키는 현상을 방지한다. 둘째, 버스가 열성 상태일 때 차동 전압을 0V로 안정시키고, 버스의 전체 임피던스를 일정하게 유지하여 신호의 무결성(Signal Integrity)을 보장한다.7

일반적인 통신 프로토콜에서 물리 계층은 상위 계층의 데이터를 안정적으로 전달하는 수동적 역할에 머무는 경우가 많다. 그러나 CAN에서 물리 계층의 ‘Wired-AND’ 특성은 데이터 링크 계층의 핵심 기능인 ‘비파괴적 우선순위 중재’를 가능하게 하는 능동적이고 필수적인 요소다. 즉, 물리적 특성과 프로토콜 규칙이 매우 긴밀하게 결합되어 CAN의 핵심적인 효율성과 실시간성을 구현한다. 예를 들어, 중재 과정에서 노드 A가 ‘1’(Recessive)을, 노드 B가 ‘0’(Dominant)을 동시에 전송하면, ‘Wired-AND’ 로직에 의해 버스의 실제 상태는 ‘0’(Dominant)이 된다.17 이때 노드 A는 자신이 ‘1’을 보냈음에도 버스에서 ‘0’을 감지하고, 자신이 우선순위에서 밀렸음을 즉시 인지하여 전송을 중단한다. 반면 노드 B는 자신이 보낸 ‘0’과 버스 상태가 일치하므로 계속해서 전송을 이어나간다. 이 과정에서 노드 B의 메시지는 전혀 손상되지 않는다. 만약 물리 계층이 이런 충돌 해결 기능을 제공하지 않는다면, 두 메시지 모두 깨지고 이더넷처럼 파괴적인 충돌 후 재전송 절차를 밟아야 할 것이다. 이처럼 CAN의 물리 계층은 단순한 신호 전달자를 넘어, 프로토콜의 논리적 알고리즘을 구현하는 하드웨어적 기반 그 자체이며, 두 계층은 분리해서 생각할 수 없을 정도로 유기적으로 통합되어 있다.

데이터 링크 계층은 CAN 프로토콜의 논리적 핵심으로, 여러 노드가 공유 버스를 효율적이고 신뢰성 있게 사용할 수 있도록 하는 규칙과 절차를 정의한다. 이 계층의 가장 중요한 역할은 버스 접근을 제어하고, 메시지의 우선순위를 결정하며, 데이터의 무결성을 보장하는 것이다.

CAN은 버스 접근 방식으로 CSMA/CD+AMP (Carrier Sense Multiple Access / Collision Detection with Arbitration on Message Priority)를 채택한다.26 이 용어는 CAN의 동작 방식을 잘 설명한다.

• CSMA (Carrier Sense Multiple Access): 모든 노드는 데이터를 전송하기 전에 먼저 버스가 사용 중인지(Carrier Sense) 확인한다. 버스가 유휴 상태(Recessive)일 때만 전송을 시작할 수 있다. 다수의 노드(Multiple Access)가 이 규칙에 따라 버스에 접근한다.
• CD+AMP (Collision Detection with Arbitration on Message Priority): 만약 두 개 이상의 노드가 동시에 버스가 비어있다고 판단하고 전송을 시작하면 충돌(Collision)이 발생한다. CAN은 이 충돌을 감지(Collision Detection)하지만, 이더넷처럼 전송을 중단하고 랜덤 시간 동안 대기하는 파괴적인 방식을 사용하지 않는다. 대신, 메시지 우선순위에 기반한 중재(Arbitration on Message Priority)를 통해 충돌을 해결한다. 이 중재 과정은 비파괴적(Non-Destructive)이어서, 우선순위가 가장 높은 메시지는 아무런 데이터 손상이나 시간 지연 없이 전송을 완료하게 된다.10 우선순위가 낮은 메시지들은 자동으로 전송을 중단하고 다음 버스 유휴 상태를 기다린다.

비파괴적 중재는 CAN 프로토콜의 가장 독창적이고 핵심적인 메커니즘이다. 이는 물리 계층의 ‘Wired-AND’ 특성을 기반으로 동작한다. 여러 노드가 동시에 전송을 시작하면, 각 노드는 자신의 메시지 ID를 최상위 비트부터 하나씩 버스에 전송하면서, 동시에 버스의 실제 상태를 다시 읽어 들인다(Bit Monitoring).27

중재 과정은 다음과 같이 진행된다.

1. 모든 송신 노드는 자신의 ID 비트를 순서대로 버스에 출력한다.
2. 각 비트를 출력한 직후, 해당 노드는 버스의 실제 상태를 읽어 자신이 출력한 비트와 일치하는지 비교한다.
3. 만약 자신이 열성 비트(‘1’)를 출력했는데 버스에서 우성 비트(‘0’)가 감지된다면, 이는 자신보다 더 높은 우선순위의 메시지가 존재함을 의미한다. 이 경우, 해당 노드는 즉시 중재에서 패배했음을 인지하고 남은 비트의 전송을 중단한 뒤 수신 모드로 전환된다.20
4. 자신이 출력한 비트와 버스의 상태가 계속 일치하는 노드는 다음 비트를 계속해서 전송한다.

CAN 메시지 ID는 이진수 값이 낮을수록 더 많은 우성 비트(‘0’)를 포함하게 된다. 따라서 ID 값이 낮을수록 우선순위가 높다.6 이 간단하고 강력한 규칙에 따라, 중재 필드 전송이 끝났을 때 단 하나의 노드, 즉 가장 낮은 ID를 가진 메시지를 전송하는 노드만이 버스에 남게 되며, 이 노드가 버스 점유권을 최종적으로 획득한다. 이 과정에서 우선순위가 가장 높은 메시지는 어떠한 방해도 받지 않고 전송을 계속할 수 있다.

CAN은 비동기 통신 방식이지만, 프레임이 전송되는 동안 모든 노드가 동일한 비트 타이밍을 유지해야 한다. 이를 위해 CAN은 NRZ(Non-Return-to-Zero) 인코딩 방식을 사용하는데, 이는 비트 구간 동안 신호 레벨이 변하지 않음을 의미한다.25 만약 동일한 신호(연속된 ‘0’ 또는 ‘1’)가 길게 이어지면, 수신 노드들의 내부 클럭과 송신 노드의 클럭 간의 미세한 오차(Clock Drift)가 누적되어 비트의 시작과 끝을 정확히 구분하지 못하게 될 수 있다.

이러한 동기화 실패를 방지하기 위해 CAN은 비트 스터핑(Bit Stuffing)이라는 메커니즘을 사용한다. 송신 노드는 데이터 스트림을 모니터링하다가 동일한 극성의 비트가 5개 연속되면, 강제적으로 그 다음에 반대 극성의 비트(Stuff Bit)를 하나 삽입하여 전송한다.13 예를 들어, ‘00000’ 다음에는 ‘1’을, ‘11111’ 다음에는 ‘0’을 삽입한다.

수신 측 노드들은 이 규칙을 알고 있으므로, 5개의 연속된 동일 비트 뒤에 오는 반대 극성의 비트를 Stuff Bit로 인지하고 자동으로 제거하여 원래의 데이터를 복원한다.32 이 메커니즘은 프레임 내에 주기적으로 신호의 상승 또는 하강 에지(edge)가 발생하도록 보장하여, 모든 노드가 이 에지를 기준으로 자신의 내부 클럭을 재동기화(Resynchronization)할 수 있게 한다.13

CAN 프로토콜은 통신 시스템의 표준 모델인 OSI 7계층 참조 모델의 관점에서 볼 때, 가장 하위의 두 계층에 해당한다.18

• 물리 계층 (Physical Layer): ISO 11898-2 (고속 CAN) 또는 ISO 11898-3 (저속, 내고장성 CAN)과 같은 표준에 의해 정의된다. 이 계층은 비트를 전기 신호로 변환하는 방법, 케이블 사양, 커넥터, 전압 레벨 등 통신의 물리적, 전기적 측면을 규정한다.5
• 데이터 링크 계층 (Data Link Layer): ISO 11898-1 표준에 의해 정의된다. 이 계층은 데이터의 논리적 구성을 다루며, 메시지 프레이밍, 중재, 오류 감지 및 신호화, 확인 응답 등과 같은 프로토콜의 핵심 규칙을 포함한다.18

CAN 표준 자체는 이 두 계층만을 정의한다. 실제 애플리케이션에서 데이터가 무엇을 의미하는지, 특정 기능을 어떻게 수행할지 등은 CAN 상위에서 동작하는 상위 계층 프로토콜(Higher-Layer Protocols)에 의해 정의된다. 대표적인 예로는 산업 자동화 분야의 CANopen과 DeviceNet, 상용차 분야의 SAE J1939 등이 있다.10 이들은 CAN이 제공하는 안정적인 데이터 전송 서비스를 기반으로 특정 응용 분야에 필요한 추가적인 규칙과 서비스를 제공한다.

이더넷의 CSMA/CD에서 충돌은 전송 실패를 의미하며, 이후 각 노드는 랜덤한 시간 동안 대기 후 재전송을 시도한다. 이는 본질적으로 비결정론적(Non-deterministic)이어서, 특정 메시지가 언제 전송될지 예측하기 어렵다. 반면, CAN의 중재 메커니즘은 충돌을 우선순위 결정 과정으로 적극 활용한다. 가장 우선순위가 높은 메시지는 정해진 시간 내에 반드시 전송됨을 보장받는다. 이는 CAN이 단순한 통신 프로토콜을 넘어, 분산된 실시간 제어 시스템을 위한 ‘결정론적(Deterministic) 스케줄링 알고리즘’을 하드웨어 수준에서 구현한 것임을 의미한다. 시스템 설계자는 가장 높은 우선순위의 메시지에 대한 최악의 경우 전송 지연 시간(Worst-Case Latency)을 수학적으로 계산할 수 있다. 이 예측 가능성, 즉 결정론적 특성이 바로 브레이크, 에어백, 엔진 제어 등 안전이 최우선인(Safety-critical) 실시간 애플리케이션에 CAN이 절대적으로 사용되는 이유이다.14

CAN 네트워크를 통해 교환되는 모든 정보는 ‘프레임(Frame)’이라는 표준화된 패킷 구조에 담겨 전송된다. 프레임의 구조는 데이터 전송, 원격 요청, 오류 보고 등 다양한 목적을 효율적으로 수행하도록 정교하게 설계되었다.

CAN 프로토콜은 목적에 따라 네 가지 종류의 프레임을 정의하고 있다.5

1. 데이터 프레임 (Data Frame): 네트워크상의 한 노드에서 다른 노드들로 실제 데이터를 전송하는 데 사용되는 가장 일반적이고 기본적인 프레임이다.5
2. 원격 프레임 (Remote Frame): 특정 ID를 가진 데이터 프레임의 전송을 다른 노드에게 요청하기 위한 프레임이다. 예를 들어, 디스플레이 장치가 온도 센서에게 현재 온도 값 전송을 요청할 때 사용될 수 있다. 원격 프레임은 데이터 필드가 없다는 점이 데이터 프레임과의 주된 차이점이다.5 이는 프레임 내의 RTR(Remote Transmission Request) 비트를 ‘1’(Recessive)로 설정하여 구분한다.15
3. 오류 프레임 (Error Frame): 어떤 노드든 버스 상에서 프로토콜 위반 오류를 감지했을 때, 이를 네트워크의 모든 노드에게 알리기 위해 전송하는 특수한 프레임이다. 오류 프레임은 현재 진행 중인 데이터 전송을 즉시 중단시키고 파괴하여, 잘못된 데이터가 전파되는 것을 막는다.5
4. 과부하 프레임 (Overload Frame): 수신 노드가 아직 이전에 수신한 메시지를 처리할 준비가 되지 않아 다음 프레임을 수신하기까지 추가적인 지연 시간이 필요할 때 전송된다. 이는 주로 수신 버퍼가 가득 찬 경우와 같은 특정 조건에서 발생하며, 프레임 간의 간격을 강제로 늘리는 역할을 한다.5

실제 임베디드 시스템 개발 환경에서 프로그래머는 주로 데이터 프레임과 원격 프레임의 송수신 로직을 구현한다. 오류 프레임과 과부하 프레임은 CAN 컨트롤러 하드웨어가 프로토콜 규칙에 따라 자동으로 감지하고 생성하여 처리하므로, 일반적으로 애플리케이션 소프트웨어 수준에서 직접 제어하지 않는다.37

데이터 프레임은 CAN 통신의 핵심이며, 여러 개의 필드로 구성되어 각각 명확한 역할을 수행한다.

• SOF (Start of Frame): 단 하나의 우성 비트(‘0’)로 구성된다. 프레임의 시작을 모든 노드에 알리고, 각 노드가 이 비트의 하강 에지(falling edge)를 기준으로 내부 클럭을 동기화하는 기준점이 된다.9
• 중재 필드 (Arbitration Field): 메시지의 식별자(ID)와 RTR 비트로 구성되며, 프레임의 우선순위를 결정하고 버스 접근 권한을 획득하는 중재 과정에서 사용되는 핵심 영역이다.
• 제어 필드 (Control Field): 총 6비트로 구성된다. 프레임 형식이 표준인지 확장인지를 나타내는 IDE(Identifier Extension) 비트, 향후 사용을 위해 예약된 비트(r0, r1), 그리고 데이터 필드의 길이를 바이트 단위로 명시하는 4비트 DLC(Data Length Code)를 포함한다.5
• 데이터 필드 (Data Field): 실제 전송하고자 하는 데이터를 담는 부분이다. Classical CAN에서는 0에서 8바이트까지의 길이를 가질 수 있으며, 실제 길이는 제어 필드의 DLC 값에 의해 결정된다.10
• CRC 필드 (Cyclic Redundancy Check Field): 전송 오류를 검출하기 위한 필드이다. SOF부터 데이터 필드까지의 비트 스트림을 기반으로 생성된 15비트의 CRC 값과, CRC 필드의 끝을 알리는 1비트의 CRC 구분자(Delimiter, 항상 Recessive ‘1’)로 구성된다.10
• ACK 필드 (Acknowledgement Field): 2비트로 구성되어 메시지의 정상 수신 여부를 확인한다. 첫 번째 비트인 ‘ACK Slot’은 송신자가 열성(‘1’)으로 전송하는데, 메시지를 오류 없이 성공적으로 수신한 수신 노드들이 이 슬롯에 우성(‘0’) 신호를 보내 응답한다. 두 번째 비트는 ACK 구분자(Delimiter, 항상 Recessive ‘1’)이다.11
• EOF (End of Frame): 7개의 연속된 열성 비트로 구성된다. 이 필드는 프레임의 끝을 명확하게 알리는 역할을 하며, 고정된 형식으로 되어 있어 형식 오류(Form Error) 검출에도 사용된다.9
• IFS (Inter-Frame Space): 프레임과 프레임 사이의 간격을 나타낸다. 최소 3개의 열성 비트로 구성되며, 이 시간 동안 버스는 유휴 상태가 되어 다음 전송을 준비한다.20

CAN 프로토콜은 두 가지의 데이터 프레임 형식을 지원하며, 가장 큰 차이는 식별자(ID)의 길이에 있다.

• 표준 형식 (Standard Format, CAN 2.0A): 11비트의 식별자를 사용한다. 이는 이론적으로 $2^{11} = 2048$개의 고유한 메시지를 구분할 수 있게 한다.12 주로 승용차와 같이 상대적으로 노드 수가 적은 시스템에 사용된다.
• 확장 형식 (Extended Format, CAN 2.0B): 29비트의 식별자를 사용한다. 이는 약 5억 3천만 개($2^{29}$)라는 방대한 수의 메시지를 구분할 수 있어, 상용차, 건설기계 등 수많은 메시지 ID가 필요한 대규모 복합 시스템에 적합하다.12

이 두 형식은 동일한 버스 상에서 문제없이 공존할 수 있도록 중재 필드가 정교하게 설계되었다.38

• 구조적 차이:

  • 표준 프레임의 제어 필드에 있는 IDE(Identifier Extension) 비트는 우성(‘0’)으로 설정되어, 11비트 ID를 사용하는 프레임임을 나타낸다.5

  • 확장 프레임은 29비트 ID를 11비트의 ‘Base ID’와 18비트의 ‘Extended ID’로 나누어 배치한다. 이때 IDE 비트는 열성(‘1’)으로 설정되어 확장 프레임임을 명시한다.38 또한, 표준 프레임의 RTR 비트 위치에는

    SRR(Substitute Remote Request) 비트가 대신 들어가며, 이 비트는 항상 열성(‘1’)이다.42

• 호환성 및 우선순위 중재: 만약 동일한 11비트 Base ID를 가진 표준 데이터 프레임과 확장 프레임이 동시에 버스에서 중재를 시작한다고 가정해보자. 표준 프레임의 RTR 비트는 데이터 프레임이므로 우성(‘0’)이다. 반면, 확장 프레임의 해당 위치에는 항상 열성(‘1’)인 SRR 비트가 있다. 따라서 중재 과정에서 이 비트를 비교하는 시점에, 우성 비트를 가진 표준 프레임이 항상 중재에서 승리하게 된다. 이 설계는 하위 호환성을 보장하고, 두 형식이 혼재된 네트워크에서도 안정적인 동작을 가능하게 하는 핵심 요소이다.42

필드 구분	세부 필드	표준 프레임 (CAN 2.0A)	확장 프레임 (CAN 2.0B)	설명
SOF	Start of Frame	1 비트	1 비트	프레임의 시작을 알리는 우성 비트
중재 필드	Base Identifier	11 비트	11 비트	메시지 식별자 및 우선순위 결정 (1차)
	RTR / SRR	1 비트 (RTR)	1 비트 (SRR)	RTR: 데이터/원격 프레임 구분. SRR: 확장 프레임 식별용, 항상 열성(1)
	IDE	(제어 필드에 위치)	1 비트	Identifier Extension. 표준은 우성(0), 확장은 열성(1)
	Extended Identifier	-	18 비트	메시지 식별자 및 우선순위 결정 (2차)
제어 필드	IDE	1 비트	(중재 필드에 위치)	표준 프레임임을 나타내는 우성(0) 비트
	r0 / r1	1 비트 (r0)	2 비트 (r1, r0)	예약 비트
	DLC	4 비트	4 비트	데이터 필드의 바이트 길이 (0-8)
데이터 필드	Data	0 - 8 바이트	0 - 8 바이트	실제 전송 데이터
CRC 필드	CRC Sequence	15 비트	15 비트	오류 검출을 위한 코드
	CRC Delimiter	1 비트	1 비트	CRC 필드의 끝을 알리는 열성 비트
ACK 필드	ACK Slot	1 비트	1 비트	수신 노드의 정상 수신 응답
	ACK Delimiter	1 비트	1 비트	ACK 필드의 끝을 알리는 열성 비트
EOF	End of Frame	7 비트	7 비트	프레임의 끝을 알리는 7개의 열성 비트
IFS	Inter-Frame Space	3 비트 (최소)	3 비트 (최소)	프레임 간 간격

ACK 필드는 단순한 수신 확인 응답 이상의 의미를 갖는다. 이는 버스에 연결된 모든 수신 노드들이 참여하는 일종의 ‘분산형 합의(Distributed Consensus)’ 메커니즘이다. 송신자는 특정 노드가 메시지를 받았는지 개별적으로 확인하는 것이 아니라, ‘네트워크상의 누군가가 유효하게 메시지를 수신했는가?’라는 단일 질문에 대한 답만 얻는다. 단 하나의 노드라도 정상적으로 메시지를 수신하여 ACK Slot을 우성(‘0’)으로 만들면, 송신자는 전송이 성공했다고 간주한다.5 이 방식은 프로토콜을 극도로 단순화하고 효율적으로 만들지만, 동시에 중요한 전제 조건을 내포한다. 만약 네트워크에 활성화된 수신 노드가 하나도 없다면(예: 개발 단계에서 단일 노드만 연결하여 테스트하는 경우), ACK 응답을 해줄 노드가 없으므로 송신자는 필연적으로 ACK 오류를 감지하게 된다.28 이 오류가 반복되면 송신 노드의 송신 오류 카운터(TEC)가 급격히 증가하여 결국 스스로를 네트워크에서 차단하는 Bus-Off 상태에 빠지게 된다.47 따라서 CAN 네트워크가 정상적으로 동작하기 위해서는 최소 2개 이상의 활성화된 노드가 존재해야 한다는 점은 이론만 학습해서는 알기 어려운, 실무에서 흔히 마주치는 중요한 함정이다.

CAN 프로토콜이 자동차와 같이 안전이 최우선인(Safety-critical) 환경에서 수십 년간 표준으로 사용될 수 있었던 가장 큰 이유는 타의 추종을 불허하는 신뢰성에 있다. 이 신뢰성은 프레임 전송의 모든 단계에 걸쳐 촘촘하게 설계된 다층적 오류 감지 메커니즘과, 결함이 발생한 노드를 스스로 네트워크에서 격리시키는 정교한 오류 국소화(Fault Confinement) 기능에 기반한다.

CAN은 전송 과정에서 발생할 수 있는 거의 모든 종류의 오류를 감지하기 위해 5가지의 독립적인 메커니즘을 상호 보완적으로 사용한다.27

1. 비트 오류 (Bit Error): 송신 노드는 자신이 버스에 비트를 전송하는 동시에, 버스에 실리는 실제 비트 레벨을 다시 읽어 들인다(Bit Monitoring). 만약 자신이 전송한 값과 버스에서 읽은 값이 다르다면, 이는 다른 노드와의 충돌 또는 전송 오류를 의미하므로 즉시 비트 오류로 감지한다. 단, 중재 과정에서 우선순위가 밀려 열성 비트가 우성 비트로 덮어쓰이는 경우와, ACK 슬롯에서 수신 노드의 응답을 받는 경우는 정상적인 동작이므로 비트 오류로 간주하지 않는다.13
2. 스터프 오류 (Stuff Error): 동기화를 위해 사용되는 비트 스터핑 규칙은 오류 감지에도 활용된다. 송신 노드는 동일한 극성의 비트가 5개 연속되면 강제로 반대 극성의 비트를 삽입한다. 따라서 정상적인 프레임 내(CRC 필드까지)에서는 동일 극성의 비트가 6개 이상 연속으로 나타날 수 없다. 만약 어떤 노드든 6개 이상의 연속된 동일 비트를 감지하면, 이는 동기화 실패 또는 프레임 손상을 의미하므로 스터프 오류로 판단한다.13
3. CRC 오류 (CRC Error): 송신 노드는 프레임의 주요 부분(SOF부터 데이터 필드까지)에 대해 15비트의 CRC(Cyclic Redundancy Check) 값을 계산하여 프레임에 포함시킨다. 메시지를 수신한 모든 노드는 동일한 방식으로 CRC 값을 직접 계산한 후, 수신된 CRC 값과 비교한다. 만약 두 값이 일치하지 않으면 전송 중에 데이터가 변조되었음을 의미하므로, 수신 노드는 CRC 오류를 발생시킨다.10
4. 형식 오류 (Form Error): CAN 프레임에는 CRC 구분자, ACK 구분자, EOF(End of Frame) 필드와 같이 항상 열성(‘1’) 비트로 정의된 고정 형식 필드들이 존재한다. 만약 이 필드들에서 우성(‘0’) 비트가 감지되면, 이는 프레임 구조 자체가 손상되었음을 의미하므로 형식 오류로 처리한다.13
5. 확인 오류 (Acknowledgement Error): 송신 노드는 ACK 필드의 ACK 슬롯에 열성(‘1’) 비트를 전송하고, 최소 하나 이상의 수신 노드로부터 우성(‘0’) 비트 응답을 기대한다. 만약 ACK 슬롯에서 우성 비트를 감지하지 못하고 자신이 보낸 열성 비트를 그대로 다시 읽는다면, 이는 네트워크 상의 어떤 노드도 메시지를 정상적으로 수신하지 못했음을 의미한다. 이 경우 송신 노드는 확인 오류를 감지한다.10

CAN은 단순히 오류를 감지하는 데 그치지 않고, 오류의 원인이 되는 노드를 식별하고 네트워크 전체에 미치는 영향을 최소화하기 위한 정교한 ‘오류 국소화’ 메커니즘을 갖추고 있다. 이 메커니즘의 핵심은 각 노드가 스스로의 통신 상태를 추적하는 오류 카운터와, 그 값에 따라 노드의 동작 모드를 변경하는 상태 천이(State Transition)이다.

• 오류 프레임 (Error Frame) 전파: 위 5가지 메커니즘 중 하나에 의해 오류가 감지되면, 해당 노드는 즉시 오류 프레임을 전송한다. 오류 프레임은 6개의 연속된 동일 극성 비트(Error Flag)로 시작하여 의도적으로 스터핑 규칙을 위반한다. 이 비정상적인 신호 패턴은 버스 상의 다른 모든 노드에게 즉시 오류 상황을 전파하며, 모든 노드는 현재 진행 중이던 프레임 수신을 중단하고 해당 프레임을 파기한다. 이 과정을 통해 잘못된 데이터가 네트워크에 퍼지는 것을 막고, 데이터의 일관성을 유지한다.10

• 오류 카운터 (TEC & REC): 각 CAN 노드는 내부에 두 개의 오류 카운터를 가지고 있다: 송신 오류 카운터(Transmit Error Counter, TEC)와 수신 오류 카운터(Receive Error Counter, REC).13 이 카운터들은 다음과 같은 비대칭적 규칙에 따라 증감한다.

  • 증가: 오류가 발생하면 카운터 값이 크게 증가한다 (예: 송신 오류 시 TEC +8).

  • 감소: 메시지 송수신에 성공하면 카운터 값이 작게 감소한다 (예: 성공적인 송신 시 TEC -1).

    이 비대칭적 규칙은 일시적인 외부 노이즈로 인한 단발성 오류와, 노드 자체의 영구적인 결함으로 인해 지속적으로 발생하는 오류를 구분하는 핵심적인 역할을 한다.41

• 노드 상태 천이 (Node State Transition): 오류 카운터 값에 따라 노드의 상태는 다음 3단계로 동적으로 변화하며, 이는 결함이 있는 노드를 네트워크로부터 점진적으로 격리시키는 역할을 한다.

  1. 오류 활성 (Error-Active): 모든 노드의 기본 상태로, TEC와 REC가 모두 127 미만일 때 유지된다. 이 상태의 노드는 오류를 감지하면 6개의 우성 비트로 구성된 ‘활성 오류 플래그(Active Error Flag)’를 전송하여 버스 통신을 적극적으로 중단시킨다.25
  2. 오류 수동 (Error-Passive): TEC 또는 REC 중 하나라도 127을 초과하면 이 상태로 전환된다. 이 상태의 노드는 여전히 통신에 참여할 수 있지만, 오류를 감지하더라도 6개의 열성 비트로 구성된 ‘수동 오류 플래그(Passive Error Flag)’를 전송한다. 이 열성 플래그는 다른 노드의 우성 비트에 의해 덮어쓰여지므로, 버스 통신을 방해하지 않는다. 즉, 오류 수동 상태의 노드는 오류를 감지하더라도 이를 네트워크 전체에 적극적으로 전파할 수 없게 된다. 또한, 메시지 전송 후 다음 전송까지 추가적인 지연 시간을 기다려야 하므로 버스 점유율이 제한된다.25
  3. 버스 오프 (Bus-Off): 송신 오류 카운터(TEC)가 255를 초과하면 노드는 이 상태에 진입한다. 이는 해당 노드에 심각하고 영구적인 결함이 발생했음을 의미한다. Bus-Off 상태가 된 노드는 스스로 CAN 트랜시버를 비활성화하여 버스로부터 논리적으로 완전히 분리된다. 더 이상 어떠한 신호도 버스에 전송하지 않으므로, 지속적으로 오류를 발생시키는 ‘바보(babbling idiot)’ 노드가 전체 네트워크를 마비시키는 것을 방지하는 최종 방어선 역할을 한다. Bus-Off 상태에서 정상 상태로 복귀하기 위해서는 일반적으로 호스트 마이크로컨트롤러의 개입(리셋)과 함께, 버스에서 128회에 걸쳐 11개의 연속된 열성 비트 시퀀스가 감지되는 특정 조건을 만족해야 한다.6

CAN의 오류 국소화 메커니즘은 단순한 오류 보고 체계를 넘어, 중앙 관리자 없이 각 노드가 스스로의 상태를 진단하고 네트워크 전체의 안정을 위해 자가 격리까지 수행하는 정교한 ‘분산형 네트워크 면역 시스템’과 같다. 특히 TEC/REC 카운터의 비대칭적 증감 규칙은 일시적인 노이즈로 인한 단발성 오류와 노드 자체의 영구적 결함을 구분해내는 핵심 알고리즘이다. 가끔 오류가 발생하는 정상 노드는 성공적인 통신을 통해 카운터를 다시 낮출 기회를 갖지만, 계속해서 오류를 일으키는 결함 노드는 카운터가 급격히 누적되어 결국 Error-Passive 상태를 거쳐 Bus-Off 상태로 격리될 수밖에 없다. 이 모든 과정이 각 노드 내부의 CAN 컨트롤러에 의해 자율적으로, 그리고 분산적으로 일어난다. 이 시스템 덕분에 단일 노드의 치명적인 고장이 전체 안전-필수 네트워크의 붕괴로 이어지는 것을 막을 수 있으며, 이는 CAN이 자동차 산업에서 신뢰의 상징이 된 근본적인 이유다.

수십 년간 자동차 및 산업용 네트워크의 표준으로 군림해온 Classical CAN은 그 견고함과 신뢰성에도 불구하고, 기술의 발전에 따라 명확한 성능적 한계에 직면하게 되었다. 이에 대응하여 CAN 프로토콜은 기존의 장점을 계승하면서 성능을 대폭 향상시킨 CAN FD와 CAN XL로 진화했다.

Classical CAN 프로토콜(CAN 2.0A/B)은 두 가지 주요한 성능적 제약을 가지고 있었다.

• 전송 속도: 최대 전송 속도가 1Mbps로 제한되었다. 이는 초기 ECU 제어에는 충분했으나, 소프트웨어의 복잡성이 증가하고 데이터 교환량이 늘어나면서 병목 현상을 유발하기 시작했다.58
• 데이터 페이로드: 하나의 프레임에 실을 수 있는 데이터의 최대 크기가 8바이트에 불과했다.58 8바이트보다 큰 데이터를 전송하기 위해서는 데이터를 여러 개의 프레임으로 분할해야 했고, 이는 프레임 헤더로 인한 오버헤드를 증가시켜 실제 데이터 전송 효율(Throughput)을 저하시켰다.

특히 첨단 운전자 보조 시스템(ADAS), 고해상도 인포테인먼트, 차량의 펌웨어를 무선으로 업데이트하는 OTA(Over-the-Air) 기술 등이 보편화되면서 대용량의 데이터를 빠르고 효율적으로 전송해야 할 필요성이 급증했고, 이는 Classical CAN의 한계를 더욱 명확하게 드러냈다.59

CAN FD는 Classical CAN의 한계를 극복하기 위해 2012년 Bosch에 의해 개발된 차세대 프로토콜이다. CAN FD는 기존 CAN의 프레임 구조와 핵심 원리를 유지하면서 데이터 전송 효율을 극적으로 높이는 데 초점을 맞췄다.

• 가변 데이터 전송률 (Flexible Data-Rate): CAN FD의 가장 혁신적인 특징은 하나의 프레임 내에서 두 가지 다른 비트레이트를 사용하는 것이다. 버스 중재(Arbitration)나 확인 응답(Acknowledgement)과 같이 네트워크의 안정성과 관련된 민감한 구간은 기존 CAN과 동일한 저속 비트레이트(예: 500kbps)로 동작한다. 이를 통해 높은 노이즈 내성과 하위 호환성을 유지한다. 반면, 실제 데이터와 CRC를 전송하는 구간(Data Phase)에서는 비트레이트를 최대 8Mbps까지 동적으로 높여 전송 시간을 획기적으로 단축한다.15
• 확장된 페이로드 (Increased Payload): 데이터 필드의 최대 크기를 기존 8바이트에서 64바이트로 8배 확장했다.11 이는 한 번의 전송으로 더 많은 데이터를 보낼 수 있게 하여, 메시지를 분할하고 재조립하는 오버헤드를 줄인다. 결과적으로 프레임 헤더 대비 실제 데이터의 비율, 즉 프로토콜 효율성이 크게 향상된다.58
• 하위 호환성: CAN FD는 기존 CAN 네트워크와의 공존을 고려하여 설계되었다. CAN FD 컨트롤러는 Classical CAN 프레임을 송수신할 수 있으며, CAN FD 기능이 없는 기존 CAN 노드는 CAN FD 프레임을 오류로 인식하고 무시하도록 되어 있다. 이를 통해 기존 시스템의 점진적인 업그레이드가 가능하다.59

CAN XL은 CAN FD로도 감당하기 어려운 대용량 데이터 전송 요구와, 차량 내 이더넷 백본(Backbone) 네트워크와의 효율적인 연동을 위해 개발되고 있는 최신 CAN 프로토콜이다.63

• 대폭 확장된 페이로드: 최대 2048바이트의 데이터 페이로드를 지원한다. 이는 기존 CAN FD의 64바이트보다 32배나 큰 크기로, 센서의 원시 데이터(raw data)나 진단 데이터 덤프 등 대용량 정보를 단일 프레임으로 전송할 수 있게 한다. 또한, 이더넷과 같은 다른 프로토콜의 패킷을 CAN XL 프레임 내에 담아 전송하는 터널링(Tunneling) 기술을 가능하게 한다.62
• 향상된 속도: 데이터 전송률을 10Mbps 이상으로 높이는 것을 목표로 한다. 이는 CAN FD와 100Mbps급 차량용 이더넷(100BASE-T1) 사이의 성능 격차를 메우는 역할을 하여, 네트워크 아키텍처 설계에 더 많은 유연성을 제공한다.62
• 보안 및 부가 기능 강화: 설계 단계부터 CANsec과 같은 보안 기능을 통합하는 것을 고려하고 있으며, 가상화(Virtualization) 지원 등 미래 자동차 아키텍처에 필요한 고급 기능들을 포함하고 있다. 이를 통해 기존 CAN, CAN FD, 그리고 이더넷이 혼합된 하이브리드 네트워크에서 원활하게 동작하도록 설계되었다.62

항목	Classical CAN (CAN 2.0)	CAN FD	CAN XL
최대 전송 속도	1 Mbps	8 Mbps (데이터 위상)	10 Mbps 이상
최대 페이로드 크기	8 바이트	64 바이트	2048 바이트
핵심 기술	단일 비트레이트, 11/29 비트 ID	가변 비트레이트, 확장된 DLC	대용량 페이로드, 이더넷 터널링 지원
주요 적용 분야	전통적인 차체/파워트레인 제어	ADAS, 고속 데이터 로깅, OTA	이더넷 백본 하위 네트워크, 대용량 데이터 전송
주요 표준 문서	ISO 11898-1:2015	ISO 11898-1:2015	CiA 610-1 (개발 중)

CAN의 진화 과정은 단순히 속도와 용량을 늘리는 것을 넘어, 차량 네트워크 아키텍처의 근본적인 변화에 발맞춰 CAN의 역할을 재정의하고 생존 공간을 확보하려는 전략적인 움직임으로 해석할 수 있다. CAN은 대역폭이 절대적으로 중요한 백본(Backbone) 네트워크의 역할은 이더넷에 넘겨주는 대신, 존(Zone) 컨트롤러와 말단 센서/액추에이터를 연결하는 ‘미드-레인지(Mid-range)’ 및 ‘엣지(Edge)’ 통신에서 자신의 강점을 극대화하는 방향으로 진화하고 있다. 특히 CAN FD의 이중 비트레이트 기술은 기존 CAN의 최대 장점인 강건한 중재 메커니즘을 그대로 계승하면서 데이터 처리량만 선택적으로 높인, ‘혁명’이 아닌 ‘현명한 개량’의 대표적인 사례다. 이는 기존 CAN 시스템에 익숙한 엔지니어들에게 낮은 학습 곡선을 제공하고, 방대한 기존의 소프트웨어 자산과 노하우를 재활용할 수 있게 한다. CAN XL은 이 전략을 한 단계 더 발전시켜 이더넷과의 연동성을 강화함으로써, 이더넷이 주도하는 네트워크에서 하위 시스템을 효율적으로 묶어주는 보조적인 역할, 즉 ‘서브넷(Subnet) 통신’의 강자로서의 입지를 굳히려 하고 있다. 결국 CAN의 진화는 이더넷과의 정면 대결을 피하고, 서로의 강점을 활용하는 협력적이고 계층적인 네트워크 구조에서 자신의 필수적인 역할을 찾아가는 과정이다.

CAN은 자동차 산업에서 탄생했지만, 그 탁월한 신뢰성과 비용 효율성 덕분에 다양한 산업 분야로 확산되었으며, 현대의 복잡한 차량 네트워크 내에서도 다른 프로토콜들과 역할을 분담하며 핵심적인 위치를 차지하고 있다. 미래의 소프트웨어 정의 자동차(SDV) 시대에도 CAN은 새로운 역할로 그 중요성을 이어갈 것이다.

CAN 프로토콜은 자동차라는 혹독한 환경에서 그 신뢰성이 검증된 이후, 다양한 산업 분야에서 핵심적인 제어 네트워크로 채택되었다.

• 산업 자동화: 공장 내의 로봇, 컨베이어 벨트, 각종 센서와 액추에이터들을 연결하여 분산 제어 시스템을 구축하는 데 널리 사용된다. 노이즈가 많은 공장 환경에서도 안정적으로 동작하는 점이 큰 장점이다.2
• 의료 기기: 수술실 내의 조명, 수술대, 카메라, X-레이 장비 등을 통합 제어하거나, 병원 내 다양한 의료 장비 간의 데이터 교환 및 원격 모니터링 시스템에 활용된다.3
• 항공 우주 및 운송: 항공기의 비행 제어 시스템, 철도 차량의 내부 네트워크, 선박의 엔진 및 항법 장치 제어 등 높은 신뢰성이 요구되는 분야에서 필수적인 통신 수단으로 자리 잡았다.3
• 기타: 이 외에도 건설 중장비, 농기계, 엘리베이터 제어 시스템, 심지어는 커피 자판기에 이르기까지 임베디드 제어가 필요한 거의 모든 분야에서 CAN을 찾아볼 수 있다.65

현대의 자동차는 단일 통신 프로토콜만으로 모든 요구사항을 충족할 수 없을 만큼 복잡해졌다. 따라서 각 프로토콜의 장단점에 따라 역할을 분담하는 이종(Heterogeneous) 네트워크 아키텍처가 일반적이다.

• LIN (Local Interconnect Network): 최대 20kbps의 저속 통신을 제공하는 저비용의 마스터-슬레이브 방식 프로토콜이다. CAN의 성능과 비용이 과도한 간단한 기능, 예를 들어 창문, 미러, 시트 제어, 실내등, 와이퍼 등과 같은 차체 편의 장치를 제어하는 데 사용된다. CAN 게이트웨이를 통해 상위 네트워크와 연결되며, 전체 시스템의 비용을 최적화하는 데 기여한다.34
• FlexRay: 최대 10Mbps의 높은 전송 속도와 이중 채널을 통한 뛰어난 고장 감내(Fault-tolerance) 성능을 제공한다. 특히 시간 동기화 기반의 TDMA(Time-Division Multiple Access) 방식을 지원하여, 모든 메시지가 정해진 시간에 지연 없이 전송됨을 보장하는 완벽한 결정론적 특성을 가진다. 이 때문에 과거에는 조향(Steer-by-wire)이나 제동(Brake-by-wire)과 같이 최고 수준의 안전성과 실시간성이 요구되는 X-by-Wire 시스템에 주로 사용되었다.66
• Automotive Ethernet: 100Mbps에서 수 Gbps에 이르는 고대역폭을 제공하며, 차량의 새로운 백본(Backbone) 네트워크로 부상하고 있다. ADAS 센서(카메라, 레이더, LiDAR) 데이터 퓨전, 고화질 인포테인먼트 스트리밍, 대용량 OTA 업데이트, 고속 진단 등 기존 차량 네트워크로는 감당할 수 없었던 대량의 데이터 전송을 담당한다.68

자동차 산업은 하드웨어 중심에서 소프트웨어 중심으로 패러다임이 전환되는 소프트웨어 정의 자동차(SDV, Software-Defined Vehicle) 시대로 진입하고 있다. SDV는 차량의 기능이 고정된 하드웨어가 아닌 소프트웨어에 의해 정의되고, 중앙 집중식 고성능 컴퓨터와 존(Zone) 아키텍처를 기반으로 한다.61

이 새로운 구조에서 각 통신 프로토콜의 역할은 재정의된다.

• 이더넷은 중앙 컴퓨터와 각 지역(Zone)을 담당하는 존 컨트롤러들을 연결하는 고속 백본 네트워크의 역할을 수행한다.69
• CAN/CAN FD는 각 존 컨트롤러와 그 지역에 물리적으로 위치한 말단 센서 및 액추에이터들을 연결하는 ‘존 내부 네트워크(Intra-zonal Network)’로서의 역할이 더욱 중요해진다. 예를 들어, 차량의 전방 좌측 존 컨트롤러는 헤드라이트, 방향지시등, 레이더 센서, 휠 스피드 센서 등을 CAN 버스로 묶어 제어한다. 이는 실시간 제어에 필수적인 강건성, 결정론적 특성, 그리고 비용 효율성을 모두 만족시키는 최적의 솔루션이다.66

자율주행 시스템은 크게 인지(Perception), 판단(Planning), 제어(Control)의 3단계로 구성된다. CAN은 이 중 제어(Control) 단계에서 핵심적인 역할을 수행한다. 카메라, LiDAR 등으로부터 수집된 방대한 데이터는 이더넷을 통해 중앙 컴퓨터로 전달되어 처리되고(인지), AI 알고리즘을 통해 주행 경로와 행동이 결정된다(판단). 중앙 컴퓨터가 내린 최종적인 제어 명령, 예를 들어 ‘조향각 5도 변경’ 또는 ‘제동력 30% 인가’와 같은 실시간 명령은, CAN/CAN FD를 통해 스티어링, 브레이크 등 실제 액추에이터 ECU에 전달되어 실행된다. 이 마지막 통신 경로에서 CAN의 높은 신뢰성과 결정론적 실시간성은 자율주행의 안전을 보장하는 최후의 보루 역할을 한다.5

미래 차량 네트워크는 단일 프로토콜이 모든 것을 지배하는 구조가 아닌, 목적에 최적화된 ‘이종(Heterogeneous) 계층형 네트워크’가 될 것이다. 차량이 ‘바퀴 달린 데이터 센터’로 진화함에 따라, 모든 통신 요구를 단 하나의 프로토콜로 해결하려는 시도는 비효율적이다. 미래 차량은 인간의 신경계와 같이 계층화된 네트워크 구조를 가질 것이다. 고대역폭의 이더넷이 뇌와 척수를 잇는 중추 신경계 역할을 한다면, CAN/CAN FD는 척수에서 각 근육과 감각 기관으로 뻗어 나가는 말초 신경계의 역할을 담당하게 된다. CAN의 미래는 이더넷과의 경쟁이 아닌, 이러한 계층적 구조 속에서 자신의 고유한 가치를 증명하며 상호 보완하는 데 있다. CAN의 역할은 사라지는 것이 아니라, ‘차량 전체의 백본’에서 ‘각 존의 실시간 제어 버스’로 더욱 전문화되고 명확해지며, 이는 CAN의 지속 가능한 미래를 보장하는 핵심적인 변화다.

CAN 프로토콜은 폐쇄적인 차량 내부 네트워크를 가정하고 신뢰성을 최우선으로 설계되었기 때문에, 현대적인 관점에서의 보안 기능은 전혀 고려되지 않았다. 커넥티드 카와 자율주행 기술이 발전하면서 차량이 외부 네트워크와 연결됨에 따라, CAN의 내재된 보안 취약점은 심각한 위협으로 부상하고 있다.

CAN 프로토콜의 근본적인 취약점은 ‘신뢰’를 기반으로 한 설계에서 비롯된다.

• 인증 및 암호화 부재: 프로토콜 자체에 메시지를 보낸 송신자를 확인하는 인증(Authentication) 기능이나 메시지 내용을 보호하는 암호화(Encryption) 기능이 전무하다.75 CAN 버스에 연결된 모든 노드는 다른 모든 노드를 신뢰한다는 암묵적인 가정 하에 동작한다.
• 브로드캐스트 특성: 모든 메시지가 네트워크 전체에 전파되므로, 버스에 접근 권한만 있다면 누구나 모든 통신 내용을 도청(Sniffing 또는 Eavesdropping)할 수 있다.78

이러한 특성으로 인해, 공격자가 OBD-II 포트, 무선 통신 모듈(블루투스, Wi-Fi), 또는 취약한 ECU를 통해 CAN 버스에 물리적으로나 논리적으로 접근하게 되면, 네트워크를 쉽게 장악하고 차량을 위험에 빠뜨릴 수 있다.79

CAN의 내재된 취약점은 다양한 형태의 사이버 공격을 가능하게 한다.

• 스푸핑 (Spoofing): 공격자가 악의적인 메시지를 정상적인 ECU가 보낸 것처럼 ID를 위장하여 버스에 주입하는 공격이다. 예를 들어, 공격자 노드가 브레이크 ECU를 가장하여 ID ‘0x220’으로 ‘브레이크 해제’ 명령을 보내거나, 계기판 ECU를 속여 속도계를 ‘0’으로 표시하게 만들 수 있다. 송신자 인증이 없기 때문에 수신 ECU들은 이 메시지를 정상적인 명령으로 인식하고 그대로 수행하여 치명적인 사고로 이어질 수 있다.6
• 서비스 거부 (DoS, Denial of Service): CAN의 우선순위 중재 메커니즘을 악용하는 공격이다. 공격자가 가장 높은 우선순위(가장 낮은 숫자, 예: ID ‘0x000’)를 가진 메시지를 매우 빠른 주기로 계속해서 버스에 전송하면, 다른 모든 정상적인 메시지들은 버스 점유권을 얻지 못하고 전송이 무기한 지연된다. 이로 인해 엔진, 브레이크 등 필수적인 제어 시스템 간의 통신이 마비될 수 있다.75 또한, 특정 ECU를 목표로 오류 프레임을 유발하여 해당 ECU의 오류 카운터를 강제로 증가시켜 Bus-Off 상태로 만들어 네트워크에서 이탈시키는 정교한 DoS 공격도 가능하다.6
• 리플레이 (Replay): 공격자가 정상적인 통신 상황에서 특정 메시지(예: 스마트키의 ‘문 잠금 해제’ 명령)를 기록해 두었다가, 나중에 그대로 재전송하여 의도치 않은 동작(차량 도난 등)을 유발하는 공격이다. 메시지에 시간 정보나 순서 번호가 없기 때문에 방어가 어렵다.78

이러한 위협에 대응하기 위해, 기존 CAN 네트워크의 취약점을 보완하는 다양한 보안 기술들이 개발 및 적용되고 있다.

• 보안 게이트웨이 (Secure Gateway): 차량 내부 네트워크를 여러 도메인(예: 파워트레인, 차체, 인포테인먼트)으로 분리하고, 그 사이에 위치하여 방화벽 역할을 수행한다. 게이트웨이는 사전에 정의된 규칙(Rule-based Filtering)에 따라 도메인 간 메시지 흐름을 제어하며, 허가되지 않은 ID나 비정상적인 데이터 패턴을 가진 메시지의 전송을 차단하여 공격이 중요한 제어 시스템으로 확산되는 것을 막는다.79
• 침입 탐지 시스템 (IDS, Intrusion Detection System): CAN 버스 트래픽을 실시간으로 모니터링하여 공격을 탐지하는 시스템이다. 특정 메시지의 주기나 순서, 데이터 값의 범위 등 정상 상태의 통신 패턴을 학습한 후, 이와 다른 비정상적인 패턴이 감지되면 이를 침입으로 판단하고 경고한다. 최근에는 머신러닝(ML) 및 딥러닝(DNN) 기술을 활용하여 알려지지 않은 새로운 공격까지 탐지하는 연구가 활발히 진행되고 있다.77
• 메시지 인증 (Authentication): 메시지에 암호학적 정보를 추가하여 무결성과 송신자의 신뢰성을 검증하는 방식이다.
  • SecOC (Secure On-board Communication): AUTOSAR 표준의 일부로, CAN 프레임의 데이터 필드 일부에 MAC(Message Authentication Code)을 추가하는 방식이다. 수신 노드는 공유된 비밀 키를 이용해 MAC을 검증함으로써 메시지가 전송 중에 변조되지 않았고, 허가된 송신자로부터 온 것임을 확인할 수 있다. 현재 많은 양산 차량에 적용되고 있는 실용적인 기술이다.84
  • CAN-Auth: MAC과 같은 암호학적 정보를 CAN 프레임 자체에 숨겨 전송하는 다양한 경량 인증 기법들을 통칭한다. 이는 기존 프레임 구조의 변경을 최소화하면서 보안을 추가하려는 시도이다.85
• CANsec: 하드웨어 기반의 포괄적 보안: 차세대 프로토콜인 CAN XL을 위해 표준화된 보안 계층으로, 가장 진보된 형태의 보안 솔루션이다. CANsec은 데이터의 무결성 및 인증을 위해 AES-CMAC 알고리즘을, 기밀성(암호화)을 위해 AES-GCM 알고리즘을 사용한다. 이러한 복잡한 암호 연산은 전용 하드웨어 가속기(IP Core)를 통해 처리되므로, ECU의 주 프로세서에 거의 부하를 주지 않으면서 실시간 성능 저하를 최소화한다. 이를 통해 강력한 보안과 CAN의 실시간성을 동시에 만족시키는 것을 목표로 한다.64

CAN 보안을 구현하는 데 있어 가장 큰 기술적 난제는 ‘실시간성’과 ‘보안 오버헤드’ 사이의 근본적인 상충 관계(Trade-off)이다. MAC 생성 및 검증과 같은 암호학적 연산은 처리 시간을 요구하고, MAC 데이터 자체는 프레임의 한정된 페이로드를 차지하여 전송 시간을 증가시킨다. 이러한 지연(Latency)은 1ms 단위의 정밀한 제어가 필요한 시스템에서 CAN의 핵심 가치인 결정론적 실시간성을 훼손할 수 있다. 따라서 CAN 보안 기술의 발전 방향은 단순히 강력한 암호 알고리즘을 적용하는 것이 아니라, 하드웨어 가속(CANsec), 경량화된 프로토콜(CAN-Auth), 또는 비암호학적 방어 기법(IDS, 게이트웨이) 등을 통해 ‘성능 저하를 최소화하면서 충분한 수준의 보안을 달성’하는 최적의 균형점을 찾는 데 집중되고 있다. 이는 ‘어떤 암호를 쓸 것인가’의 문제를 넘어, ‘어떻게 하면 성능 저하 없이 암호를 적용할 것인가’라는 시스템 엔지니어링의 문제에 가깝다.

Controller Area Network(CAN)는 지난 40여 년간 자동차의 복잡한 배선 문제를 해결하는 단순한 기술적 솔루션을 넘어, 분산 제어 시스템의 신뢰성과 효율성을 상징하는 기술적 아이콘으로 자리매김했다.2 그 성공의 핵심에는 물리 계층과 긴밀하게 결합된 비파괴적 우선순위 중재, 다층적인 오류 감지 및 자가 격리 메커니즘, 그리고 낮은 구현 비용이라는 독보적인 장점들이 있었다.10 이 견고한 설계 철학은 CAN이 자동차를 넘어 산업 자동화, 의료, 항공우주 등 신뢰성이 절대적으로 요구되는 모든 분야로 확산되는 원동력이 되었다.

그러나 기술의 발전은 영원한 강자를 허락하지 않는다. ADAS, 자율주행, 커넥티드 서비스의 등장은 기존 CAN이 감당할 수 없는 수준의 대역폭과 본질적으로 고려되지 않았던 보안이라는 새로운 시대적 요구를 가져왔다. 이에 직면하여 CAN은 도태되는 대신 진화를 선택했다. CAN FD와 CAN XL로의 기술적 진화는 대역폭의 한계를 극복하려는 노력이며, SecOC와 CANsec과 같은 보안 계층의 추가는 신뢰의 기반 위에 안전을 더하려는 시도다. 이는 경쟁 프로토콜에 의해 완전히 ‘대체’되는 것이 아닌, 시대의 요구에 맞춰 스스로를 변화시키는 ‘적응’을 통한 능동적인 생존 전략이다.

미래의 자동차 및 산업 자동화 시스템에서 CAN은 더 이상 단독 주연이 아닐 것이다. 차량의 중추 신경망은 고대역폭의 이더넷이 담당하게 될 것이다. 하지만 CAN은 이러한 변화 속에서 사라지는 것이 아니라, 자신의 역할과 가치를 더욱 명확히 할 것이다. 이더넷이라는 고속 백본과 공존하는 이종(Heterogeneous) 네트워크 아키텍처에서, CAN은 실시간 제어가 필요한 말단 영역, 즉 존(Zone) 내부의 센서와 액추에이터를 가장 효율적이고 안정적으로 연결하는 필수적인 구성 요소로서 그 가치를 이어나갈 것이다.88 CAN의 역사는 하나의 위대한 기술이 어떻게 시대의 요구에 맞춰 진화하고, 다른 기술과의 공존 속에서 자신의 고유한 가치를 지속적으로 증명해 나가는지에 대한 훌륭한 사례로 남을 것이다.

1. CAN통신 이란, 8월 14, 2025에 액세스, https://prosigi.tistory.com/34
2. 단일 네트워크를 위한 CAN(Controller Area Network) 프로토콜 - 아이씨엔매거진, 8월 14, 2025에 액세스, https://icnweb.kr/2015/12837/%EB%8B%A8%EC%9D%BC-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC%EB%A5%BC-%EC%9C%84%ED%95%9C-cancontroller-area-network-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C/
3. CAN(Controller Area Network)이란? - 소프트웨어 공장 - 티스토리, 8월 14, 2025에 액세스, https://coding-by-head.tistory.com/entry/can-intro
4. [CAN 통신 핸드북] 01강 CAN 통신이란? - YouTube, 8월 14, 2025에 액세스, https://www.youtube.com/watch?v=yEfWvbLQd9A
5. CAN bus - Wikipedia, 8월 14, 2025에 액세스, https://en.wikipedia.org/wiki/CAN_bus
6. CAN(통신) - 나무위키, 8월 14, 2025에 액세스, https://namu.wiki/w/CAN(%ED%86%B5%EC%8B%A0)
7. [통신] CAN 통신 개요 - 개발일지, 8월 14, 2025에 액세스, https://maloveforme.tistory.com/279
8. CAN (Controller Area Network) 개념 및 역사 - 소프트웨어 공장, 8월 14, 2025에 액세스, https://coding-by-head.tistory.com/entry/canopen-history
9. CAN 통신의 이해 - 상두’s, 8월 14, 2025에 액세스, https://gomsik.tistory.com/83
10. CAN (Controller Area Network) 프로토콜 개요 - NI, 8월 14, 2025에 액세스, https://www.ni.com/ko/shop/seamlessly-connect-to-third-party-devices-and-supervisory-system/controller-area-network–can–overview.html
11. CAN 통신에 대해 알아보기 - HMG Developers, 8월 14, 2025에 액세스, https://developers.hyundaimotorgroup.com/blog/54
12. 캔통신(CAN Communication)이란? CAN Bus Basics : A Simple Guide, 프레임 구조, 8월 14, 2025에 액세스, https://famtech.tistory.com/313
13. CAN Bus Errors Explained - A Simple Intro [2025] - CSS Electronics, 8월 14, 2025에 액세스, https://www.csselectronics.com/pages/can-bus-errors-intro-tutorial
14. CAN Basics (bit-wise arbitration, differential signals) - Kvaser, 8월 14, 2025에 액세스, https://kvaser.com/lesson/can-basics-bit-wise-arbitration-differential-signals/
15. CAN 통신: 자동차 통신의 핵심 - Health and Security, 8월 14, 2025에 액세스, https://healthierusd.tistory.com/99
16. CAN_K: CAN 버스 - Vector E-Learning, 8월 14, 2025에 액세스, https://elearning.vector.com/mod/page/view.php?id=1892
17. What Do CAN Bus Signals Look like? - Texas Instruments, 8월 14, 2025에 액세스, https://www.ti.com/document-viewer/lit/html/SSZTCN3

18. AN-1123: Controller Area Network (CAN) Implementation Guide

    Analog Devices, 8월 14, 2025에 액세스, https://www.analog.com/en/resources/app-notes/an-1123.html

19. elearning.vector.com, 8월 14, 2025에 액세스, https://elearning.vector.com/mod/page/view.php?id=340#:~:text=Differential%20signals&text=This%20effectively%20eliminates%20the%20negative,CAN%20low%20line%20(CANL).
20. CAN 통신의 개념과 원리 - 디카페인 코딩, 8월 14, 2025에 액세스, https://www.gyuray.dev/can-bus-protocol
21. CAN Bus Explained - A Simple Intro [2025] - CSS Electronics, 8월 14, 2025에 액세스, https://www.csselectronics.com/pages/can-bus-simple-intro-tutorial
22. What do CAN bus signals look like? - Texas Instruments, 8월 14, 2025에 액세스, https://www.ti.com/lit/pdf/ssztcn3

23. Simple Circuit Provides Adjustable CAN-Level Differential-Output Signal

    Analog Devices, 8월 14, 2025에 액세스, https://www.analog.com/en/resources/analog-dialogue/articles/circuit-for-adjustable-can-level-differential-output-signal.html

24. CAN_E: CAN Bus Levels - Vector E-Learning, 8월 14, 2025에 액세스, https://elearning.vector.com/mod/page/view.php?id=341
25. Controller Area Network (CAN) - Layer - Knowledgebase - dissecto, 8월 14, 2025에 액세스, https://munich.dissec.to/kb/chapters/can/can.html
26. CAN 개요, 8월 14, 2025에 액세스, http://web.chungbuk.ac.kr/~kwjeong/lectures/green_car_system/CANinfo.pdf
27. CAN Error Handling - Kvaser, 8월 14, 2025에 액세스, https://kvaser.com/lesson/can-error-handling/

28. Error Detection in CAN

    All About Circuits, 8월 14, 2025에 액세스, https://forum.allaboutcircuits.com/threads/error-detection-in-can.200012/

29. CAN_K: 비트 스터핑 - Vector E-Learning, 8월 14, 2025에 액세스, https://elearning.vector.com/mod/page/view.php?id=1901
30. 강좌<10>: CAN 통신 사용 - 리얼시스, 8월 14, 2025에 액세스, http://realsys.co.kr/data/arm/10.CAN%ED%86%B5%EC%8B%A0%20%EC%82%AC%EC%9A%A9.pdf
31. CAN 통신(캔 통신) Bit Stuffing 이란? - 글쓰는 엔지니어 - 티스토리, 8월 14, 2025에 액세스, https://kennyshin.tistory.com/54
32. CAN protocol의 이해 - 정보통신공학과, 8월 14, 2025에 액세스, https://dept.kookje.ac.kr/automobile/index.php?pCode=notice2&mode=fdn&idx=397&num=2
33. CAN Error Detection and Confinement - NI-CAN Documentation, 8월 14, 2025에 액세스, https://documentation.help/NI-CAN/CAN_Error_Detection_and_Confinement.html
34. Controller Area Network (CAN) Standards - The ANSI Blog, 8월 14, 2025에 액세스, https://blog.ansi.org/ansi/controller-area-network-can-standards-iso-11898/
35. 맞춤형 태블릿 트럭 - CAN 버스 프레임 구성 - 지식 - Neway (HK) Holding Limited, 8월 14, 2025에 액세스, http://ko.newaye.com/info/customized-tablet-truck-can-bus-frame-compos-74862016.html
36. CAN 통신 프레임(Frame) 타입 - Developer eeun’s diary - 티스토리, 8월 14, 2025에 액세스, https://developer-eun-diary.tistory.com/76
37. 1. 데이터 송신 (1) 데이터 프레임 (2) 리모트 프레임 - Joondong2 기술블로그, 8월 14, 2025에 액세스, https://joondong.tistory.com/13
38. CAN message format: An overview - HMS Networks, 8월 14, 2025에 액세스, https://www.hms-networks.com/tech-blog/blogpost/hms-blog/2024/06/18/can-message-format-an-overview
39. CAN_K: 프레임 종류 - Vector E-Learning, 8월 14, 2025에 액세스, https://elearning.vector.com/mod/page/view.php?id=1896
40. CAN 통신의 이해 - 기술블로그 - INSIGHT - 페스카로(FESCARO) - 미래 모빌리티 소프트웨어 솔루션 전문기업(자동차 사이버보안, 제어기, V2X), 8월 14, 2025에 액세스, https://www.fescaro.com/ko/archives/249/
41. CAN 통신 - 메시지 타입과 구조, 8월 14, 2025에 액세스, https://eteo.tistory.com/381
42. Difference between Standard CAN and Extended CAN frame - Automotive Vehicle Testing, 8월 14, 2025에 액세스, https://automotivevehicletesting.com/standard-can-and-extended-can-frame/
43. CAN통신의 기초-3 - 도닦는공돌이, 8월 14, 2025에 액세스, https://electronicsdo.tistory.com/entry/CAN%ED%86%B5%EC%8B%A0%EC%9D%98-%EA%B8%B0%EC%B4%883
44. Standard CAN vs Extended CAN - Embedclogic, 8월 14, 2025에 액세스, https://embedclogic.com/can-protocol/standard-can-vs-extended-can-protocol-frame/
45. What Is Can Bus (Controller Area Network) - Dewesoft, 8월 14, 2025에 액세스, https://dewesoft.com/blog/what-is-can-bus

46. Extended Frame Format. You can look into the CAN standard…

    by Indhra Pooja S J, 8월 14, 2025에 액세스, https://medium.com/@sjindhirapooja/extended-frame-format-1f83f821068d

47. what is CAN bus-off state ? - EmbeddedRelated.com, 8월 14, 2025에 액세스, https://www.embeddedrelated.com/thread/939/what-is-can-bus-off-state

48. Error Detection In CAN and Correction

    Dorleco, 8월 14, 2025에 액세스, https://dorleco.com/correction-and-error-detection-in-can/

49. [CAN통신] CAN Communication Error 란? (Delimiter, 에러, Data Frame, Bit Stuffing) - 팜테크(FAMTECH) - 티스토리, 8월 14, 2025에 액세스, https://famtech.tistory.com/341
50. CAN 에러 처리 - velog, 8월 14, 2025에 액세스, https://velog.io/@noogoolgga/CAN-%EC%97%90%EB%9F%AC-%EC%B2%98%EB%A6%AC
51. CAN 프로토콜 개요 - 소프트웨어 공장, 8월 14, 2025에 액세스, https://coding-by-head.tistory.com/entry/can-protocol

52. CRC, ACK & Form errors in CAN frames #E16

    Aishwarya Pattar - YouTube, 8월 14, 2025에 액세스, https://www.youtube.com/watch?v=HGPBvlUW7yk

53. Controller Area Network (CAN Bus) - Error Detection And Fault Confinement - Copperhill, 8월 14, 2025에 액세스, https://copperhilltech.com/blog/controller-area-network-can-bus-error-detection-and-fault-confinement/

54. 에러의 종류: CRC 에러와 Ack 에러의 차이점 - 인프런

    커뮤니티 질문&답변, 8월 14, 2025에 액세스, https://www.inflearn.com/community/questions/882191/%EC%97%90%EB%9F%AC%EC%9D%98-%EC%A2%85%EB%A5%98-crc-%EC%97%90%EB%9F%AC%EC%99%80-ack-%EC%97%90%EB%9F%AC%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90

55. [CAN 통신] CAN 에러 State와 Error Frame Format(Error Active, Error Passive, Bus Off) - 팜테크(FAMTECH) - 티스토리, 8월 14, 2025에 액세스, https://famtech.tistory.com/355
56. What are Error Active, Error Passive, and Bus off of CAN Bus? - CAN Wiki, 8월 14, 2025에 액세스, http://www.can-wiki.info/doku.php?id=can_faq:can_faq_erors
57. What is the difference between an error active node and an error passive node in CAN?, 8월 14, 2025에 액세스, https://stackoverflow.com/questions/54715288/what-is-the-difference-between-an-error-active-node-and-an-error-passive-node-in
58. Classsical CAN과 CAN FD BUS 통신 차이점, 데이터 프레임 분석(Data Frame), 8월 14, 2025에 액세스, https://famtech.tistory.com/314
59. CAN과 CAN FD의 차이점(캔통신, BUS, Communication, Difference) - 팜테크(FAMTECH), 8월 14, 2025에 액세스, https://famtech.tistory.com/468
60. Classic CAN과 CAN FD의 최대 전송 데이터 수 비교 - 글쓰는 엔지니어, 8월 14, 2025에 액세스, https://kennyshin.tistory.com/55
61. This is what your car’s network will look like in 2050 - Avnet, 8월 14, 2025에 액세스, https://www.avnet.com/americas/resources/article/this-is-what-your-car-network-will-look-like-in-2050/
62. CAN FD 및 최신 CAN XL 기술 심화 분석 - 소프트웨어 공장, 8월 14, 2025에 액세스, https://coding-by-head.tistory.com/entry/can-fd-1
63. CAN/CAN FD를 위한 노하우 및 솔루션, 8월 14, 2025에 액세스, https://www.vector.com/kr/ko/know-how/can/
64. CAN-SEC – CANsec Controller IP Core - Fraunhofer IPMS, 8월 14, 2025에 액세스, https://www.ipms.fraunhofer.de/en/Components-and-Systems/Components-and-Systems-Data-Communication/ip-cores/IP-Core-Modules/CANsec-IP-Core.html
65. IoT를 위한 CAN 통신 인터페이스 - elec4, 8월 14, 2025에 액세스, https://www.elec4.co.kr/article/articleView.asp?idx=8106
66. 미래자동차를 위한 차량 네트워크 기술 및 동향 - KESSIA-임베디드 …, 8월 14, 2025에 액세스, https://www.kessia.kr/bbs/download.php?tbl=memberwork&no=12293
67. FlexRay 자동차 통신 버스 개요 - NI, 8월 14, 2025에 액세스, https://www.ni.com/ko/shop/seamlessly-connect-to-third-party-devices-and-supervisory-system/flexray-automotive-communication-bus-overview.html
68. Automotive Ethernet enables software-defined vehicles - Broadcom Inc., 8월 14, 2025에 액세스, https://www.broadcom.com/blog/automotive-ethernet-enables-software-defined-vehicles
69. Software-Defined Vehicles Built on Ethernet - Microchip Technology, 8월 14, 2025에 액세스, https://www.microchip.com/en-us/about/media-center/blog/2021/the-drive-towards-the-software-defined-vehicle-built-on-ethernet
70. What is a Software Defined Vehicle? - IBM, 8월 14, 2025에 액세스, https://www.ibm.com/think/topics/software-defined-vehicle

71. Software-defined vehicle design resources

    TI.com - Texas Instruments, 8월 14, 2025에 액세스, https://www.ti.com/applications/automotive/software-defined-vehicle/overview.html

72. The Definitive Guide to Software Defined Vehicles

    Sonatus, 8월 14, 2025에 액세스, https://www.sonatus.com/blog/what-is-a-software-defined-vehicle/

73. A CAN Bus-Based Efficient Design for a Simple Autonomous Vehicle (AV) - ResearchGate, 8월 14, 2025에 액세스, https://www.researchgate.net/publication/370668560_A_CAN_Bus-Based_Efficient_Design_for_a_Simple_Autonomous_Vehicle_AV
74. GBP: How Did CAN Bus Revolutionize The Automotive Industry? - Sital Technology, 8월 14, 2025에 액세스, https://sitaltech.com/gbp-how-did-can-bus-revolutionize-the-automotive-industry/
75. 커넥티드 카에서의 보안기술동향, 8월 14, 2025에 액세스, [https://public.thinkonweb.com/journals/kiisc/digital-library/manuscript/file/23496/03.%20%ED%8A%B9%EC%A7%91%ED%98%B8]%EC%BB%A4%EB%84%A5%ED%8B%B0%EB%93%9C%20%EC%B9%B4%EC%97%90%EC%84%9C%EC%9D%98%20%EB%B3%B4%EC%95%88%EA%B8%B0%EC%88%A0%EB%8F%99%ED%96%A5.pdf

76. TrinitySec: Trinity-Enabled and Lightweight Security Framework for CAN-FD Communication

    Request PDF - ResearchGate, 8월 14, 2025에 액세스, https://www.researchgate.net/publication/373920164_TrinitySec_Trinity-Enabled_and_Lightweight_Security_Framework_for_CAN-FD_Communication

77. Understanding CAN Bus Vulnerabilities and How Blockchain Can Amplify Security - Medium, 8월 14, 2025에 액세스, https://medium.com/@chaincom/understanding-can-bus-vulnerabilities-and-how-blockchain-can-amplify-security-a58388bf1fb4
78. 차량 해킹 실습을 통한 CAN 통신 및 보안 이해(해킹기법 및 환경) - JMoon, 8월 14, 2025에 액세스, https://jmoon.co.kr/207
79. CAN Security - canis labs, 8월 14, 2025에 액세스, https://canislabs.com/cansecurity/
80. CANsec: A Practical in-Vehicle Controller Area Network Security Evaluation Tool - PMC, 8월 14, 2025에 액세스, https://pmc.ncbi.nlm.nih.gov/articles/PMC7506734/
81. Intrusion Detection in Vehicle Controller Area Network (CAN) Bus Using Machine Learning: A Comparative Performance Study - PMC, 8월 14, 2025에 액세스, https://pmc.ncbi.nlm.nih.gov/articles/PMC10099193/
82. CAN에서 메시지 순서 기반의 스푸핑 공격 방어 및 - C&IS LAB @ KAIST, 8월 14, 2025에 액세스, https://caislab.kaist.ac.kr/publication/thesis_files/2016/SHMS.pdf
83. Exposing New Vulnerabilities of Error Handling Mechanism in CAN - USENIX, 8월 14, 2025에 액세스, https://www.usenix.org/system/files/sec21fall-serag.pdf
84. Securing CAN networks in commercial vehicles - CAN/CiA, 8월 14, 2025에 액세스, https://www.can-cia.org/fileadmin/cia/documents/publications/cnlm/september_2022/cnlm_22-3_p30_securing_can_networks_in_commercial_vehicles_karthik_sivaramakrishnan_nxp.pdf
85. Security solutions for the CAN bus , bringing authentication to in-vehicle networks - UPT, 8월 14, 2025에 액세스, https://www.aut.upt.ro/~pal-stefan.murvay/papers/security_solutions_CAN_bus_bringing_authentication_to_in_vehicle_networks.pdf

86. CAN-SEC

    CANsec Acceleration Engine IP Core - CAST Inc., 8월 14, 2025에 액세스, https://www.cast-inc.com/interfaces/automotive-bus-controllers/can-sec

87. White Paper - CANsec: Security for the Third Generation of the CAN Bus - CAST Inc., 8월 14, 2025에 액세스, https://www.cast-inc.com/blog/white-paper-cansec-security-third-generation-can-bus
88. Next Generation In-vehicle Networking (IVN) Market Forecast - Coherent Market Insights, 8월 14, 2025에 액세스, https://www.coherentmarketinsights.com/market-insight/next-generation-in-vehicle-networking-market-3740