[프로젝트 회고-下] CAN 통신 다시 살펴보기

#Embedded

최근 진행한 프로젝트에서 CAN 통신 위주로 다시 살펴보기

이전 글에서 최근 진행한 임베디드 프로젝트에서 사용했던 시리얼 통신들에 대해서 다시 공부했었다.

이번에는 CAN 통신에 대해서 다시 공부해 보려고 한다.

CAN (Controller Area Network)

CAN은 차량 내 전자 제어 장치(ECU) 의 수가 증가하면서 배선 문제와 신뢰성 문제를 해결하기 위해 1985년 Bosch에서 개발하여 1986년 SAE에서 공개된 기술이다.

CAN은 여러 장치들이 하나의 버스 라인에 연결되어 데이터를 주고 받는 실시간 통신 프로토콜로 최대 1Mbps 통신 속도를 지원한다.

기기들이 하나의 버스에 물려 있기 때문에 각 장치는 메시지의 ID를 기반으로 필요한 데이터만 수신하며 ID의 값이 낮을수록 우선순위가 높다.

CAN BUS는 CAN_H와 CAN_L 두 선의 전압 차이를 이용하는 차동 신호 방식을 사용하여 노이즈에 강한 특징을 가진다.

또한 두 가닥의 선이 서로 반대 방향으로 전류가 흘러 자기장을 상쇄시킨다.

CAN 구성요소

Can https://analog-circuit-design.tistory.com/entry/38-CAN-%ED%86%B5%EC%8B%A0-%ED%9A%8C%EB%A1%9C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0 CAN은 두 가닥의 꼬인 선인 CAN_H와 CAN_L 선을 이용하여 통신을 하고 필요한 구성 요소는 다음과 같다.

  • CAN Controller
    • 메시지 생성 / 해석
    • Arbitration (우선순위 경쟁)
  • CAN Transceiver
    • 디지털 ↔ 전기 신호 변환기
    • Controller의 TX 신호 → CANH/CANL 전압으로 변환
    • CAN BUS 신호 → MCU가 읽을 수 있는 RX 신호로 변환
  • CAN BUS
    • 모든 노드를 연결하는 물리적인 선
  • 종단 저항
    • 버스 양 끝에 120Ω 저항을 배치
    • 신호 반사를 막아 통신 오류를 방지

MCU에서 메세지를 보낼 경우

MCU -> Controller -> Transceiver -> CAN BUS -> (모든 노드로 브로드캐스트)

위와 같은 과정을 거친다. 버스가 하나이기에 메시지는 모든 노드에게 전송이 되고 각 노드는 메시지의 ID를 참고하여 해당 메시지를 수신할지 말지 결정한다.

CAN Error

CAN의 노드들은 아래 세 가지 상태를 가진다.

  • Error Active : 에러가 없는 정상 상태 (에러가 없다는 뜻은 아님)
  • Error Passive : 에러가 있을 수도 있는 상태
  • Bus Off : 버스에 배재된 상태

CAN 통신에서 에러가 발생할 수 있는 상황은 아래 5가지가 있다.

Bit Error

송신한 비트와 실제 버스에서 읽은 비트가 다른 경우 발생한다.

단, Arbitration 과정에서는 예외적으로 허용된다.

Stuff Error

Stuff Bit를 이용해서 클럭을 동기화시킨다.

5개의 동일한 비트가 연속으로 전송되는 경우 반전 비트 (Stuff Bit)를 추가해야 된다.

반전비트가 없으면 에러 처리를 한다.

Form Error

표준 Frame 포맷과 상이한 값이 수신되는 경우 에러 처리함

CRC Error

송신 측에서 계산한 CRC 값과 수신 측에서 계산한 CRC 값이 다를 경우 발생한다.

데이터 무결성 검증을 위한 에러이다.

Acknowledgement Error

수신 노드는 정상적으로 프레임을 수신하면 ACK 슬롯에서 dominant 비트를 전송한다.

만약 송신 노드가 ACK를 감지하지 못하면 전송 실패로 판단하고 재전송을 수행한다.

CAN Data Frame

can-data-frame https://namu.wiki/w/CAN(%ED%86%B5%EC%8B%A0)

CAN의 데이터 프레임은 위와 같은데 눈 여겨볼 점은 Data의 영역이 0~64 bit로 최대 8바이트까지 한 번에 보낼 수 있다는 점이다.

CAN TP

CAN은 기본적으로 8Byte 데이터를 한 번에 보낼 수 있는데 그 이상의 데이터를 보내기 위해 CAN TP (ISO-TP)를 사용한다.

CAN TP는 CAN Controller 위에서 동작하는 상위 프로토콜로 소프트웨어적으로 구현된다.

CAN TP의 전송 과정은 다음과 같다.

  1. 데이터가 7바이트 이하이면 Single Frame (SF) 으로 한 번에 전송한다.

  2. 데이터가 8바이트 이상이면 First Frame (FF) 을 전송한다.

    • 전체 데이터 길이를 포함
    • 첫 6바이트 데이터를 함께 전송

  3. 수신 측은 Flow Control (FC) 프레임을 전송한다.

    • 송신을 계속해도 되는지 여부 전달
    • Block Size (한 번에 보낼 프레임 수)
    • Separation Time (프레임 간 최소 간격)

  4. 송신 측은 Consecutive Frame (CF) 을 순차적으로 전송한다.

    • 7바이트씩 나누어 전송
    • Sequence Number (0~15)로 순서 관리

  5. 모든 데이터 전송이 완료되면 수신 측에서 이를 재조립하여 원본 데이터를 복원한다.

CAN FD

CAN FD는 기존 CAN 통신의 데이터 처리량 한계를 극복하기 위해 개발된 2세대 차량 네트워크 프로토콜이다.

기본적인 CAN 통신과의 차이점은 아래와 같다.

can_fd-frame

  1. 데이터 필드 길이 : 8Byte → 64Byte
  2. 전송 속도 : 1Mbps → 2, 5, 8Mbps 제공
  3. CRC 필드 길이 증가 (보안성 ↑)

CAN FD는 기존 CAN과 하위 호환성을 제공하여 기존 CAN 네트워크에 CAN FD 장치를 추가할 수 있다.

단점

CAN과 CAN FD 모두에게 해당하는 단점은 우선순위가 낮은 메시지는 무한정 지연될 수 있으며 이에 대한 지연 시간을 예측할 수 없다.

메시지의 Starvation 상태를 방지하기 위해서는 버스 사용율을 60-70% 이하로 사용해야 된다.