본문 바로가기

연구노트/통신 설계

CAN 통신설계

CAN 통신설계

용어 설명

  1. ECU ( Electronic Control Unit )

ECU는 자동차에서 사용되는 많은 전자 제어 장치들을 지칭하는 말이며 아래와 같은 장치들이 포함

ACU : Airbag Control Unit

- ACU는 차량 곳곳에 설치된 가속도 센서, 충돌 센서, 회전 속도 센서 등으로부터 충격 데이터를 실시간으로 수신하고 분석

ECU : Engine Control Unit

- ECU는 엔진과 다른 차량 부품 곳곳에 위치한 다양한 센서들로부터 데이터를 지속적으로 수집

TCU : Transmission Control Unit

- 변속기 제어 장치 TCU는 일반적으로 차량의 센서와 엔진 제어 장치(ECU) 에서 제공하는 데이터를 사용하여 최적의 성능, 연비 빛 변속 품질을 위해 차량의 기어를 언제 어떻게 변경해야 하는지 계산

BCU : Brake Control Unit

- 안전하고 효과적인 작동을 보장하기 위해 차량 또는 장비의 제동 시스템을 관리하고 제어하는 전자 장치

OBD : On-Board-Diagnostics

- 차량의 배출가스 관련 부품 및 엔진 제어 장치(ECU)의 상태를 지속적으로 감시하고, 이상이 발생했을 때 운전자와 정비사에게 그 정보를 알려주는 역할

ECU는 각종 센서에서 오는 정보를 토대로 최적의 결과를 판단하는 일을 함.

자동차의 성능이 발전함에 따라 구동계 뿐만 아니라 각종 전자장치를 제어하는 역할 까지 하고 있음.

과거 자동차에는 ECU가 30개 미만으로 내장되어 있었지만, 최근엔 편의를 위한 장치들이 많아지면서 최대 100여개 까지도 내장되고 있음.

CAN 통신

  1. CAN 등장배경

1980년대까지는 자동차는 대부분 기계식이었으나, 기술발전으로 자동차의 다양한 모듈(ECU)이 생겼으며 서로 통신하기 위해 UART를 사용.

하지만, UART 통신은 각 모듈이 1 : 1 통신이므로 ECU가 추가될 때 마다 더 많은 연결선이 필요하였으며 수많은 연결선은 자동차의 공간을 점점 많이 차지하게 되고, 자동차의 무게를 증가시키고 원가 상승결과를 초래 → 그래서 CAN 개발.

여러 개의 CAN 장치( Device ) 가 서로 통신할 수 있으며, 하나의 CAN 인터페이스로 여러 개의 모듈을 제어할 수 있어, 연결선 수의 감소, 자동차 무게의 경감, 원가 하락뿐 아니라 효율적인 시스템 제어가 가능.

2. CAN 이란 ?

CAN ( Controller Area Network ) 통신

차량 내에서 Host 컴퓨터 없이 MCU나 장치들이 서로 통신하기 위해 설계된 표준통신규격

차량 내 ECU ( Electronic control unit ) 들은 CAN 프로토콜을 사용하여 통신

초기에 차량네트워크용으로 개발하였으나 최근 산업 전분야에 폭넓게 적용

CAN Controller, CAN Transceiver

- 차량용 네트워크의 백본망을 구성하고 있는 CAN 프로토콜은 CAN Controller 와 CAN Transceiver 로 구현

- CAN Controller는 내무 버퍼를 가지며 Transceiver에서 전달되는 수신 메시지에 대해 유효한 데이터인지 아닌지를 ID기반으로 판별한 후, 유효한 데이터인 경우 MCU로 전달.

- 송신 메시지의 경우 MCU에서 전송하고자 하는 데이터에 대해 CAN Transceiver로 전달.

- CAN Transceiver는 CAN 버스 혹은 MCU 에서 전달되는 송수신 데이터를 전기적 신호로 변환함.

- CAN Transceiver는 MCU 로부터 전달된 데이터를 CAN 통신용 데이터로 변환하며, - - - CAN 버스에서 전달된 CAN 통신용 데이터를 MCU 송수신용 데이터로 변환함.

CAN_H, CAN_L

- 전기적으로 신호를 전송하는 역할을 하는 물리계층에서, CAN은 광섬유나 꼬인 2선 ( Twist Pair Wire )과 같은 다양한 종류의 매체를 사용하여 통신 할 수 있음.

- 꼬인 2선 시그널링은 각 전선에 서로 다른 전압을 사용하여 버스상에서의 노이즈를 줄임.

- 이때 꼬인 2선을 각각 CAN_H, CAN_L 라고 부름.

Case1. MCU 에 CAN Controller 내장 되지 않은 경우

Case2. MCU 에 CAN Controller 내장된 경우

3. CAN 특징

1) 메시지 지향성 프로토콜 ( Message – Oriented Protocol )

CAN은 노드의 주소에 의해 데이터를 주고 받는 것이 아니라 메시지의 우선순위에 따라 ID ( Identifier )를 할당하고 이 ID 를 이용해 메시지를 구별하는 방식을 사용

즉, 임의의 한 노드 A가 메시지를 전송했다면, A를 제외한 나머지 노드들은 A가 전송한 메시지가 자신에게 필요한 메시지인지를 판단 ( ID 기반 판단 ) → 자신에게 필요하다면 받아들이고 아니라면 무시

2) 보안적인 에러 감지

CAN 은 에러 감지를 상호 보완적으로 하기 때문에 높은 안정성을 보장

메시지 전송 시, 에러가 감지되면 자동적으로 해당 메시지를 즉시 재전송하는 기능이 있어 에러 회복시간이 짧음

3) 멀티 마스터 기능 ( 다중 주인 )

CAN 을 기반으로 한 네트워크에는 버스를 점유하기 위한 노드 ( Bus Master ) 가 필요 없음

모든 BUS 가 Master 가 되어 BUS 가 비어 있을 때 ( IDLE ) 라면 언제든지 메시지 전송이 가능

모든 노드는 BUS 가 비워지는 즉시 메시지 전송을 시작하며, 만약 CAN 버스에서 두개의 노드에서 메시지를 동시에 전송하려고 하더라도 우선순위 ( 식별자, ID )에 따라 각각 전송이 됨.

즉, 우선순위가 높은 메시지 ( 더 낮은 ID 번호가 더 높은 우선순위 ) 가 먼저 전송.

4) 노드감지 및 비활성화

CAN 은 BUS 의 상태를 항상 모니터링 하기 때문에 실시간으로 결함이 있는 노드를 감지해 해당 노드를 비활성화 함으로써 네트워크의 신뢰성을 보장

5) 전기적 노이즈의 강함

꼬인2선 ( Twist Pair Wire, CAN_H, CAN_L ) 을 이용하여 전기적으로 차별된 통신을 하여 전기적 노이즈에 매우 강함 ( 노이즈 영향 최소화 )

6) 저렴한 가격 및 구성의 용이성

현재 수십 개의 반도체 제조업체가 다양한 CAN 컨트롤러와 트랜시버를 개발 및 판매하고 있어 가격이 저렴하고 조달이 용이

7) PLUG & PLAY 기능

플러그 앤 플레이 기능을 제공해서 CAN 컨트롤러를 BUS 에 간편하게 연결하고 끊을 수가 있어, 여러 장치를 추가 및 제거가 용이

8) 고속 및 원거리 통신

최대 1M bps에 달하는 고속통신을 제공하며, 최대 1km 까지 원거리 통신이 가능

CAN 동작원리

  1. CAN 네트워크 동작원리

CAN 은 다중통신망 ( Multi Master Network ) 이며, CSMA / CD + AMP 방식을 이용

CAN Bus 라인이 사용 중인지 파악 후 메시지간 충돌 검출을 수행

메시지의 처음부분에 CAN 네트워크상에서 각각의 노드를 식별 할 수 있도록 각 노드마다 유일한 식별자 ID를 가지고 있음

네트워크상 연결된 모든 노드는 메시지를 수신 후 필요로 하는 식별자의 메시지인 경우만 받아들이고, 그렇지 않은 경우 무시

여러 노드의 데이터들이 동시에 사용자가 필요로 하는 노드로 유입될 경우 식별자의 숫자를 비교하여 메시지의 우선순위를 정하는데, 식별자의 숫자가 낮을수록 우선순위가 높음 ( 0, 1 )

우선순위가 높은 메시지가 CAN 버스의 사용권한을 보장받으며, 이 때 낮은 순위의 메시지는 자동적으로 다음 사이클에 재전송됨

CAN 메시지는 11bit 의 식별자 ( CAN 2.0A ) 또는 29비트의 식별자 (CAN 2.0B )를 가지며, CAN 메시지의 맨 처음 시작부분에 위치

이 식별자는 메시지의 형태를 식별해주는 역할과 메시지에 우선순위를 부여하는 역할

CAN 통신 프로토콜

  1. CAN 통신 프로토콜 규격

CAN Message 의 식별자 ( ID ) 의 길이에 따라 두가지 모드로 구분

11bit 식별자 : 표준 CAN ( 버전 2.0A )

29bit 식별자 : 확장 CAN ( 버전 2.0B )

대부분 CAN 2.0 컨트롤러는 오직 표준 CAN 포맷의 메시지만 송수신이 가능하며, 확장 CAN 포맷의 메시지를 수신하더라도 그 메시지를 무시.

즉, CAN 2.0A 컨트롤러에서 보내온 메시지 데이터만 유효

BUT, CAN 2.0B 컨트롤러는 양쪽 메시지 포맷 ( CAN 2.0A, 2.0B ) 에 대해 모두 송수신이 가능

2. CAN 메시지 패킷 ( 구조 )

CAN 에서는 데이터 프레임, 리모트 프레임, 에러 프레임, 오버로드 프레임의 4가지 타입을 정의

데이터 프레임 : 일반적인 데이터 전송에 사용

리모트 프레임 : 수신노드에서 원하는 메시지를 송신노드에게 전송 요청시 사용

에러 프레임 : 메시지의 에러가 감지되었을 때 시스템에 알릴 목적으로 사용

오버로드 프레임 : 메시지의 동기화 목적

CAN 통신에서 데이터 송수신은 메시지 프레임을 사용하여 이루어짐.

3. 표준 CAN 메시지 구조 ( 2.0A )

1) 프레임의 시작 필드 ( SOF : Start of Frame )

메시지 프레임의 시작을 표시하기 위한 필드

메시지 프레임의 최우선에 위치하며 디폴트 0 값을 가짐

2) 중재 필드 ( Arbitration Field )

11비트의 식별자와 원격 전송 요구 ( RTR ) 비트로 구성

디폴트 0 값을 가짐

RTR 비트 값 0 : CAN 메시지가 데이터 프레임이라는 것을 가리킴

RTR 비트 값 1 : CAN 메시지가 원격전송요청( RTR : Remote Transmission Request )을 의미

즉, CAN 메시지가 데이터 프레임이 아닌 원격프레임 ( Remote Frame ) 상태임을 나타냄

원격 프레임은 데이터 버스 상의 어떤 한 노드로부터 다른 노드로 데이터를 전송 요청 시 사용됨

3) 제어 필드 ( Control Field )

6비트로 구성되며 향후에 사용되기 위해 예약된 두 개의 0 값을 가지는 R0, R1 와 DLC ( Data Length Code )로 구성

DLC : 데이터 필드의 바이트 수를 가리키며, 4바이트의 데이터 길이 코드

4) 데이터 필드 ( Data Field )

한 노드로부터 다른 노드로 전하고자 하는 데이터를 넣기 위한 필드

0 ~ 8 byte 로 구성

5) CRC 필드 ( CRC : Cyclic Redundancy Check )

15비트의 주기적 중복확인 ( CRC )코드를 가지며 데이터필드의 종료를 알리는 1 의 값 을 가지는 비트로 구성

6) ACK 필드 ( ACKnowledge Field )

2비트로 구성되며 첫 번째 비트는 0 값을 가지는 Slot 비트

Slot 비트는 메시지를 성공적으로 수신한 다른 노드로부터 전송된 1 의 값을 기록

두번째 비트는 1의 값을 가짐

7) 프레임 종료 필드 ( EOF : End of Frame Field )

7비트로 구성되며 모두 1의 값을 가짐

EOF 뒤의 모두 1의 값을 가진 3비트의 프레임 중단 필드 ( Intermission Field ) 가 이어 짐

3비트의 ITM 주기 이후에 CAN 버스라인은 IDLE 상태 ( 다른 노드가 데이터를 보낼 수 있는 상태 ) 로 인식

4. 확장 CAN 메시지 구조 ( 2.0B )

표준 CAN 메시지 구조 ( 2.0A ) 와 구분을 위해 29비트 프레임 식별자를 가짐.

표준 CAN 메시지 구조 ( 2.0A ) 와 호환됨

표준 CAN ( 2.0A ) 와 차이점은 중재 필드가 두개의 CAN 메시지 식별자로 구분되어 포함

첫 번째 ( 기본 ID ) : 11비트 길이로 2.0A 와 호환되게 되어 있음

두 번째 필드 ( 확장 ID ) : 18비트 길이로 ID는 총 29비트로 구성

두 개의 ID 필드 사이에 ID 확장자 ( IDE : identifier Extension ) 가 있어 두 개의 ID 필 드를 구분

SRR ( Subtitute Remote Request ) 비트

중재필드에 속하며, 표준 데이터 프레임과 확장 데이터 프레임을 중재해야 하는 경우에 대비하기 위해 항상 1 의 값을 전송

만약 표준 데이터 프레임과 확장 데이터 프레임이 같은 기본 ID ( 11비트 ) 를 갖고 있 으면 표준 데이터 프레임이 우선 순위를 가짐.

'연구노트 > 통신 설계' 카테고리의 다른 글

RS-232 통신 인터페이스 설계  (0) 2025.10.17
HDLC 통신설계  (0) 2025.09.30
I2C 통신설계  (0) 2025.09.25
SPI 통신설계  (0) 2025.09.24
UART 통신설계  (0) 2025.09.24