CAN 버스 프로토콜 개요

CAN은 Controller Area Network(계측 제어기 통신망)의 약자입니다. 이런 유형의 통신은 여러 형태의 시스템 내부에 있으며, 가장 일반적인 것은 자동차입니다. 이런 시스템은 일반적으로 유선으로 연결되어 상호 통신하는 컨트롤러(마이크로프로세서/마이크로컨트롤러)로 구성됩니다. 무선 통신이 가능한 프로토콜 및 방법이 있지만 유선이 훨씬 더 일반적입니다. SPI, I2C, USB 및 기타 유사한 형식과 달리, CAN 버스는 데이터 통신에 매우 다른 형식을 사용합니다. CAN 버스는 차동 전압 레벨을 기반으로 합니다.

통신에는 두 개의 와이어가 사용되며 데이터를 동시에 전송합니다. 이들은 CAN Hi(하이) 및 CAN Lo(로우)로 전압 레벨이 서로 다르며 CAN 노드라 불리는 각 컨트롤러에서 해석됩니다. CAN Hi는 일반적으로 2.5V에서 3.75V이며, CAN Lo는 2.5V에서 1.25V입니다. 두 라인 모두 2.5V일 경우 해당 신호를 "열성(Recessive)"이라고 부르며 이진수 값 1에 해당합니다. CAN Hi가 3.75V이고 CAN Lo가 1.25V일 경우 해당 신호를 "우성(Dominant)"이라고 부르며 이진수 값 0에 해당합니다. 0이 로우이고 1이 하이인 디지털 로직을 이야기 한다면 개념적으로 이는 말이 되지 않지만, 이 프로토콜은 1 값보다 0 값을 찾습니다. 따라서 드라이버 로직은 일반적인 디지털 로직의 해석과는 반대입니다.

기본 결선도

결선에는 프로토콜에 고유한 몇 가지 특이한 양상이 있습니다. CAN 버스가 단선 프로토콜에 비해 가진 한 가지 이점은 다른 노드에 장애를 발생시키지 않고 노드의 연결을 끊을 수 있다는 것입니다. 특정 노드에서 CAN Hi 또는 CAN Lo가 끊어진 경우 시스템의 나머지 부분은 상관 없이 다른 노드에 데이터를 전송할 것입니다. 일부 시스템은 메인 라인이 다운되면 하나의 라인으로 데이터를 전송할 수도 있지만, 이는 회사에 따라 다릅니다(모든 시스템이 CAN Hi 또는 CAN Lo 라인이 다운된 상태에서 작동할 수 있는 것은 아닙니다). 그러나 120옴 저항에는 두 가지 목적이 있기 때문에 라인이 끊어져도 처리할 수 있는 시스템에서는 성능에 타격을 받습니다. 첫째로 Hi와 Lo 사이의 차동 전압을 제공하며 더불어 주파수가 더 높은 시스템에 대한 매칭 임피던스를 제공합니다. 이 프로토콜은 차동 전압에서 가장 잘 동작합니다. 또한 와이어 교차에는 두 가지 목적이 있습니다(트위스트 페어). 첫째, 외부로부터의 EMI 방사 차단에 도움이 됩니다. 둘째, 프로토콜이 고속으로 데이터를 전송할 때 EMI 문제에 도움이 됩니다.

다른 라인은 없습니다. 즉, 패킷(메시지)이 모든 노드로 동시에 전송됩니다. CAN 메시지 데이터 프레임에는 "주소"가 없지만, 사용자가 정의한 특정 메시지와 함께 우선 순위와 더불어 각 노드에서 무엇을 수락하고 거부할 지 결정하는 방법이 데이터 프레임 내에 있습니다. 다른 메세지와의 충돌을 방지하기 위해서는 데이터에 비트 세트가 있어야 하기 때문에, CAN 버스에서는 이런 문제를 방지할 수 있는 우선 순위가 중요합니다.

CAN 버스 데이터 형식

모든 프로토콜과 마찬가지로, 데이터는 정한 표준에 따라 특정한 방식으로 구성됩니다. CAN 버스 프로토콜은 CAN 2.0으로 시작하여, ISO 11898로 업데이트되었으며, 여전히 개발은 진행 중입니다(긴 메시지를 위한 확장 버전의 프로토콜이 있습니다). 전체 CAN 프레임의 길이는 일반적으로 14바이트입니다. 다음은 CAN 메시지의 상세 내역입니다:

  • SOF(Start of Frame, 프레임의 시작): 새로운 CAN 메시지의 시작을 나타내며, 버스의 다른 노드들이 동기화되도록 합니다.
  • 중재(arbitration) 필드는 11비트의 ID와 다른 노드에 정보를 요청하면 우성으로 설정되는 1비트의 RTR(Remote Transit Request)을 포함하는 식별자입니다. ID는 각 노드가 해당 메시지를 신경 써야할 지 여부를 나타내는 맥락이기 때문에 다른 노드들이 신경을 씁니다. ID를 "주제" 처럼 행동하는 유사 주소(pseudo-address)라고 생각하십시오. 다른 노드가 "주제"에 관심이 없다면 메시지를 무시할 것입니다. 뿐만 아니라, ID는 충돌 방지를 위한 우선순위도 결정합니다. 통신이 동시에 발생하면, 노드는 우선 라인이 유휴 상태(열성)가 될 때까지 기다립니다. 한 노드는 열성 레벨을 출력하고 다른 노드는 우성 레벨을 출력한다면, 우성 전압이 항상 더 높은 우선순위입니다. 아래는 예제입니다.
  • 예제:

    노드1 메시지: 0011 0110 0000…
    노드2 메시지: 0010 1000 1100…

    왼쪽에서 오른쪽으로, 노드 2 메세지의 네 번째 비트가 우성인 '0’이기 때문에 노드 2가 먼저 전송됩니다. 노드 1은 이를 감지하여 메시지 전송을 중단하고 라인이 유휴 상태가 될 때까지 기다립니다.

  • R0는 향후 개발용 입니다.
  • 데이터 길이 코드는 반 바이트 길이이며 데이터 필드 내 실제 전송되는 데이터의 길이를 나타냅니다.
  • 데이터 필드는 프로그래밍을 위해 다른 노드로 보내고 싶은 데이터를 포함하고 있습니다.
  • CRC(Cyclic Redundancy Check, 순환 중복 검사)는 오류 감지용입니다. 우성 레벨에 오류가 없을 경우 이 비트를 덮어씁니다.
  • ACK(Acknowledge, 긍정 응답)는 오류가 없었음을 확인해주는 열성 비트입니다(에러가 있으면 우성).
  • EOF(End of Frame, 프레임의 끝)는 CAN 메시지 프레임의 끝을 알리는 7비트 필드이며 비트 스터핑(동기화 데이터)을 비활성화합니다.
  • iFS(interframe space: 프레임 간 간격)는 수신 노드가 별도의 버퍼로 정보를 옮길 수 있도록 지연 역할을 하는 또 다른 7비트 필드입니다.

CAN 메시지 프레임에는 5가지 오류 수정 메커니즘이 있습니다. 2개는 비트 레벨이며 3개는 메시지 레벨입니다. 비트 모니터링과 비트 스터핑이 비트 레벨입니다. 비트 모니터링은 각 노드에서 수행되며 어딘가에 오류가 있는지 여부를 모니터링합니다(중재 필드에서 수행됨). 에러는 특정한 방식으로 플래그됩니다. 다른 비트 레벨 오류 수정은 비트 스터핑입니다. 메시지로 동일한 레벨의 5비트가 전송되면 반대 레벨(열성 또는 우성)의 6번째 비트를 추가하여 송신기와 동기화할 수 있습니다. 각 노드는 이 추가 비트를 예상하고 있기 때문에 수신기에 의해 쉽게 제거됩니다.

두 가지 메시지 레벨 메커니즘은 프레임 검사와 CRC/ACK 필드입니다. 프레임 검사는 모든 CAN 파트가 존재하는지 그리고 ACK와 CRC 이후에 열성 비트가 있는지 확인합니다. 오류가 있을 경우, 두 가지 임계값이 있습니다. 첫 번째 오류가 발생하면, 노드에 대한 카운터를 증가시키는 플래그로서 비트 하나가 우성으로 설정됩니다. 카운터가 아직 1이라면, 열성 오류 플래그가 전송되고 트래픽은 정상적으로 지속됩니다. 그러나 카운터가 2가 되면, 심각한 오류를 나타내며 해당 노드는 중지됩니다. 메시지가 오류 없이 성공적으로 전송되면 카운터는 감소합니다.

CAN 버스를 직접 실험하고 싶다면, 사용해 볼 수 있는 몇 가지 평가 기판이 있습니다:

  1. https://www.digikey.kr/short/0w07wbtw
  2. https://www.digikey.kr/short/bmcd3c2m


영문 원본: Overview of the CAN Bus Protocol