CAN 버스

CAN bus

CAN 버스(Controller Area Network)는 마이크로컨트롤러와 장치가 호스트 컴퓨터 없이 서로의 응용 프로그램과 통신할 수 있도록 설계된 차량 버스 표준입니다.메시지 기반 프로토콜로, 원래는 구리를 절약하기 위해 자동차 내의 다중 전기 배선을 위해 설계되었지만 다른 여러 맥락에서도 사용할 수 있습니다.각 장치에 대해 프레임의 데이터는 직렬로 전송되지만 두 개 이상의 장치가 동시에 전송되는 경우 다른 장치는 백오프하는 동안 가장 높은 우선 순위의 장치가 계속될 수 있습니다.프레임은 송신 디바이스를 포함한 모든 디바이스에 의해 수신됩니다.

역사

CAN 버스의 개발은 1983년 로버트 보쉬 GmbH에서 시작되었습니다.[1]이 프로토콜은 1986년 미시간주 디트로이트에서 열린 SAE(Society of Automotive Engineers) 회의에서 공식적으로 발표되었습니다.최초의 CAN 컨트롤러 칩은 1987년 인텔에 의해 소개되었으며 얼마 지나지 않아 필립스에 의해 소개되었습니다.[1]1991년에 출시된 메르세데스-벤츠 W140은 CAN 기반의 멀티플렉스 배선 시스템을 탑재한 최초의 생산 차량입니다.[2][3]

Bosch는 CAN 사양의 여러 버전을 발표했습니다.가장 최근의 것은 1991년에 출판된 CAN 2.0입니다.이 규격은 두 부분으로 되어 있습니다.A 부분은 11비트 식별자가 있는 표준 포맷을 위한 것이고, B 부분은 29비트 식별자가 있는 확장 포맷을 위한 것입니다.11비트 식별자를 사용하는 CAN 장치를 일반적으로 CAN 2.0A라고 하며 29비트 식별자를 사용하는 CAN 장치를 일반적으로 CAN 2.0B라고 합니다.이러한 표준은 Bosch에서 다른 사양 및 백서와 함께 자유롭게 사용할 수 있습니다.[4]

1993년에 국제 표준화 기구(ISO)는 CAN 표준 ISO 11898을 발표하였으며, 이는 나중에 데이터 링크 계층을 포함하는 ISO 11898-1과 고속 CAN을 위한 CAN 물리 계층을 포함하는 ISO 11898-2의 두 부분으로 재구성되었습니다.ISO 11898-3은 나중에 발표되었으며 저속의 내결함성 CAN을 위한 CAN 물리 계층을 다룹니다.물리 계층 표준 ISO 11898-2 및 ISO 11898-3은 Bosch CAN 2.0 사양의 일부가 아닙니다.

2012년에 Bosch는 CAN FD 1.0 또는 CAN과 Flexible Data-Rate를 출시했습니다.이 규격에서는 다른 프레임 형식을 사용하여 데이터 길이를 다르게 할 뿐만 아니라 중재가 결정된 후에 선택적으로 더 빠른 비트 전송률로 전환할 수도 있습니다.CAN FD는 기존 CAN 2.0 네트워크와 호환되므로 새로운 CAN FD 장치가 기존 CAN 장치와 동일한 네트워크에서 공존할 수 있습니다.2018년 현재 Bosch는 CAN 표준 확장에 적극적입니다.

CAN 버스는 OBD(On-Board Diagnostics)-II 차량 진단 표준에 사용되는 5가지 프로토콜 중 하나입니다.OBD-II 표준은 1996년부터 미국에서 판매되는 모든 자동차와 경트럭에 의무적으로 적용되고 있습니다.EOBD 기준은 2001년부터 유럽연합에서 판매되는 모든 가솔린 차량과 2004년부터 모든 디젤 차량에 의무적으로 적용되고 있습니다.[6]

적용들

  • 승용자동차, 트럭, 버스(연소자동차 및 전기자동차)
  • 농기구
  • 항공·항법용 전자장비
  • 산업 자동화 및 기계 제어
  • 엘리베이터, 에스컬레이터
  • 빌딩자동화
  • 의료기기 및 장비
  • 페델렉
  • 모형 철도/철도
  • 선박 및 기타 해상 응용 프로그램
  • 조명제어장치
  • 3D 프린터
  • 로봇/자동화

오토모티브

현대의 자동차는 다양한 서브시스템을 위한 70개의 전자제어장치(ECU)를 가질 수 있습니다.[7]전통적으로 가장 큰 프로세서는 엔진 제어 장치입니다.기타는 자율 주행, 첨단 운전자 보조 시스템(ADAS), 변속기, 에어백, ABS, 크루즈 컨트롤, 전동식 파워 스티어링, 오디오 시스템, 파워 윈도우, 도어, 미러 조정, 하이브리드/전기 자동차용 배터리 및 충전 시스템 등에 사용됩니다.이들 중 일부는 독립적인 서브시스템을 형성하지만 다른 것들 간의 커뮤니케이션은 필수적입니다.서브시스템은 액츄에이터를 제어하거나 센서로부터 피드백을 받아야 할 수 있습니다.CAN 표준은 이러한 요구를 충족시키기 위해 고안되었습니다.주요 장점 중 하나는 서로 다른 차량 시스템 간의 상호 연결을 통해 소프트웨어만으로 광범위한 안전, 경제 및 편의 기능을 구현할 수 있다는 점입니다. 이러한 기능이 기존의 자동차 전기를 사용하여 유선으로 연결된 경우 비용과 복잡성을 가중시킬 수 있습니다.예를 들면 다음과 같습니다.

  • 자동 시동/정지: 차량 주변의 다양한 센서 입력(속도 센서, 스티어링 각도, 에어컨 ON/OFF, 엔진 온도)이 CAN 버스를 통해 수집되어 정지 상태에서 엔진을 셧다운할 수 있는지 여부를 판단하여 연비 및 배기 가스 배출을 개선합니다.
  • 전자식 주차 브레이크:힐 홀드 기능은 CAN 버스를 통해 차량의 틸트 센서(도둑 경보 장치에도 사용됨) 및 주행 속도 센서(ABS, 엔진 컨트롤 및 트랙션 컨트롤에도 사용됨)로부터 입력을 받아 차량이 경사로에 정차 중인지 여부를 판단합니다.마찬가지로 안전 벨트 센서(에어백 컨트롤의 일부)의 입력이 CAN 버스에서 공급되어 안전 벨트가 체결되었는지 여부를 판단하여 주차 브레이크가 꺼지면 자동으로 해제됩니다.
  • 주차 지원 시스템: 운전자가 후진 기어를 체결하면 변속기 컨트롤 유닛이 CAN 버스를 통해 신호를 전송하여 주차 센서 시스템과 도어 컨트롤 모듈을 모두 활성화하여 조수석 측 도어 미러가 아래로 기울어지도록 하여 연석의 위치를 표시할 수 있습니다.또한 CAN 버스는 레인 센서로부터 입력을 받아 후진 시 리어 윈드스크린 와이퍼를 작동시킵니다.
  • 자동 차선 보조/충돌 방지 시스템:주차 센서의 입력은 또한 CAN 버스가 차선 이탈 경고와 같은 운전자 지원 시스템에 외부 근접 데이터를 제공하는 데 사용되며, 최근에는 이러한 신호가 CAN 버스를 통해 이동하여 능동형 충돌 방지 시스템에서 유선으로 브레이크를 작동합니다.
  • 자동 브레이크 와이퍼 작동:레인 센서(주로 자동 윈드스크린 와이퍼에 사용됨)에서 입력을 CAN 버스를 통해 ABS 모듈로 전송하여 브레이크 로터의 수분을 제거하기 위해 주행 중에 감지할 수 없는 브레이크 작동을 시작합니다.일부 고성능 아우디BMW 모델에는 이러한 기능이 포함되어 있습니다.
  • 센서는 가장 적합한 장소에 배치될 수 있으며, 센서의 데이터는 여러 개의 ECU에서 사용됩니다.예를 들어, 실외 온도 센서(전통적으로 전방에 배치된)를 아웃사이드 미러에 배치하여 엔진에 의한 가열을 방지할 수 있으며, 엔진, 실내 온도 조절 장치 및 운전자 디스플레이에 의해 사용되는 데이터가 있습니다.

최근 몇 년 동안, 데이터 전송 속도와 신뢰성이 덜 중요한 에어컨 및 인포테인먼트와 같은 중요하지 않은 서브시스템에 대한 CAN을 보완하기 위해 LIN 버스(Local Interconnect Network) 표준이 도입되었습니다.

다른.

  • CAN 버스 프로토콜은 2009년부터 도로 자전거용 Shimano DI2 전자 기어 변속 시스템에 사용되고 있으며, Ansmann 및 BionX 시스템에서도 직접 구동 모터에 사용되고 있습니다.
  • CAN 버스는 일부 CAN 컨트롤러 및 프로세서의 저렴한 비용 때문에 일반 자동화 환경에서 필드 버스로도 사용됩니다.
  • NISMO를 포함한 제조사들은 게임의 GPS Data Logger 기능을 사용하여 비디오 게임 그란 투리스모 6에서 실제 레이싱 랩을 재현하기 위해 CAN 버스 데이터를 사용하는 것을 목표로 하고 있습니다. 그러면 플레이어가 실제 랩과 경주할 수 있게 됩니다.[8]
  • 존스 홉킨스 대학 응용물리학 연구소의 모듈형 보철 림(MPL)은 로컬 CAN 버스를 사용하여 보철 팔의 서보와 마이크로컨트롤러 간의 통신을 용이하게 합니다.
  • FIRST 로봇 대회에 참가한 팀들은 널리 CAN 버스를 사용하여 로보리오와 다른 로봇 제어 모듈 간의 통신을 수행합니다.
  • CueScript 텔레프롬프터 범위는 동축 케이블을 통한 CAN 버스 프로토콜을 사용하여 CSSC – Desktop Scroll Control을 메인 장치에 연결합니다.
  • CAN 버스 프로토콜은 주요 상용 디지털 명령 제어 시스템 제조업체의 모델 철도 센서 피드백 시스템 및 다양한 오픈 소스 디지털 모델 철도 제어 프로젝트와 같은 전기적으로 잡음이 많은 환경에서 내결함성으로 인해 널리 구현됩니다.
  • Shearwater Research는 다양한 제조업체의 다이빙 재호흡기에 다이빙 컴퓨터를 통합하는 데 사용하기 위해 이 프로토콜을 DiveCAN으로[9] 구현했습니다.

건축학

물리적 조직

CAN은 노드(node)라고도 하는 ECU(electronic control unit)를 연결하기 위한 멀티 마스터 직렬 버스 표준입니다(자동차 전자 장치는 주요 애플리케이션 도메인).통신하려면 CAN 네트워크에 두 개 이상의 노드가 필요합니다.노드는 간단한 디지털 로직(예: PLD)에서 FPGA를 통해 광범위한 소프트웨어를 실행하는 임베디드 컴퓨터까지 장치와 인터페이스할 수 있습니다.이러한 컴퓨터는 범용 컴퓨터(예: 노트북)가 USB 또는 이더넷 포트를 통해 CAN 네트워크의 장치와 통신할 수 있는 게이트웨이가 될 수도 있습니다.

모든 노드는 물리적으로 통상적인 2-와이어 버스를 통해 서로 연결됩니다.와이어는 120 ω(공칭) 특성 임피던스를 가진 트위스트 페어입니다.

이 버스는 차동 유선 AND 신호를 사용합니다.CAN High (CANH) 및 CAN Low (CANL)의 두 신호는 CANH > CANL인 "우점" 상태로 구동되거나 수동 저항기에 의해 CANH ≤ CANL인 "우점" 상태로 구동 및 당겨지지 않습니다. 0 데이터 비트는 우점 상태를 인코딩하는 반면 1 데이터 비트는 우점 상태를 인코딩하여 유선-AND 협약을 지원합니다.버스에서 ID 번호가 낮은 노드에 우선 순위를 부여합니다.

고속 CAN 네트워크.ISO 11898-2.

고속 CAN(CAN에서는 최대 1 Mbit/s, CAN-FD에서는 5 Mbit/s의 비트 속도)이라고도 불리는 ISO 11898-2는 각 끝에 120 ωRESS 저항으로 종단 처리된 선형 버스를 사용합니다.

고속 CAN 신호 전송.ISO 11898-2.

장치가 도미넌트(0)를 전송할 때는 고속 CAN 신호를 통해 CANH 와이어를 3.5V 방향으로, CANL 와이어를 1.5V 방향으로 구동하는 반면, 도미넌트를 전송하는 장치가 없는 경우 종단 저항은 두 와이어를 공칭 차동 전압 0V의 패시브(1) 상태로 수동적으로 되돌립니다. (수신기는 모든 차동 장치를 고려합니다.0.5V 미만의 전압을 열성으로 합니다.)우세한 차동 전압은 공칭 2V입니다.우세 공통 모드 전압(CANH+CANL)/2는 공통의 1.5~3.5V 이내여야 하며 열성 공통 모드 전압은 공통의 ±12 이내여야 합니다.

저속 무장애 CAN 네트워크ISO 11898-3.

저속 또는 내결함성 CAN(최대 125kbit/s)이라고도 불리는 ISO 11898-3은 선형 버스, 스타 버스 또는 선형 버스로 연결된 다중 스타 버스를 사용하며 전체 종단 저항의 일부로 각 노드에서 종단됩니다.전체 종단 저항은 100 ω에 가까워야 합니다.

저속 CAN 신호 전송.ISO 11898-3.

저속 무장애 CAN 신호는 고속 CAN과 유사하게 작동하지만 전압 스윙이 더 큽니다.우세 상태는 CANH를 장치 전원 전압(5V 또는 3.3V)으로 구동하여 전송되고 우세(0)를 전송할 때 CANL을 0V로 구동하여 전송되는 반면 종단 저항기는 버스를 0V의 CANH와 5V의 CANL로 리세스 상태로 당깁니다.이것은 CANH-CANL의 부호만을 고려한 더 간단한 수신기를 사용할 수 있습니다. 두 와이어 모두 손상 없이 -27 ~ +40V를 처리할 수 있어야 합니다.

전기적 특성

고속 CAN과 저속 CAN 모두에서 CAN 와이어가 능동적으로 구동되기 때문에 도미넌트 전환이 발생하면 전환 속도가 더 빨라집니다.도미넌트에서 열성으로 전환되는 속도는 주로 CAN 네트워크의 길이와 사용되는 와이어의 용량에 따라 달라집니다.

고속 CAN은 일반적으로 버스가 환경의 한쪽 끝에서 다른 쪽 끝까지 운행되는 자동차 및 산업 분야에서 사용됩니다.장애 허용 CAN은 노드 그룹을 함께 연결해야 하는 곳에 자주 사용됩니다.

사양에서는 버스를 최소 및 최대 공통 모드 버스 전압 내에 유지해야 하지만 버스를 이 범위 내에 유지하는 방법은 정의하지 않습니다.

CAN 버스를 종료해야 합니다.종단 저항은 버스를 열성 또는 공회전 상태로 되돌리고 반사를 억제하는 데 필요합니다.

고속 CAN은 선형 버스의 각 끝단에 120 ω 저항기를 사용합니다.저속 CAN은 각 노드에서 저항기를 사용합니다.ISO 11783에 정의된 종단 바이어스 회로와 같은 다른 유형의 종단이 사용될 수 있습니다.[10]

A 종단 바이어스 회로는 4-와이어 케이블의 CAN 시그널링 외에도 전원 및 접지를 제공합니다.이를 통해 각 버스 세그먼트의 각 끝단에서 자동으로 전기적 바이어스종단 처리를 제공합니다.ISO 11783 네트워크는 버스 세그먼트 및 ECU의 핫 플러그인 및 제거를 위해 설계되었습니다.

노드

CAN 버스 노드

각 노드는 다음을 요구합니다.

  • 중앙 처리 장치, 마이크로프로세서 또는 호스트 프로세서
    • 호스트 프로세서는 수신된 메시지의 의미와 전송할 메시지를 결정합니다.
    • 센서, 액추에이터 및 제어 장치는 호스트 프로세서에 연결될 수 있습니다.
  • CAN 컨트롤러 - 종종 마이크로컨트롤러의 필수 구성 요소
    • 수신: CAN 컨트롤러는 전체 메시지를 사용할 수 있을 때까지 버스에서 수신된 직렬 비트를 저장하며, 이를 호스트 프로세서가 가져올 수 있습니다(보통 CAN 컨트롤러가 인터럽트를 트리거함).
    • 보내기: 호스트 프로세서는 CAN 컨트롤러로 전송 메시지를 전송하며, CAN 컨트롤러는 버스가 비어 있을 때 해당 버스에 비트를 직렬로 전송합니다.
  • IMT-2000 3GPP-ISO 11898-2/3 표준에 의해 정의된 송수신기
    • 수신: CAN 버스 레벨에서 CAN 컨트롤러가 사용하는 레벨로 데이터 스트림을 변환합니다.보통 CAN 컨트롤러를 보호하기 위한 보호 회로가 있습니다.
    • 전송: CAN 컨트롤러의 데이터 스트림을 CAN 버스 레벨로 변환합니다.

각 노드는 메시지를 주고받을 수 있지만 동시에 메시지를 보낼 수는 없습니다.메시지 또는 프레임은 주로 메시지의 우선 순위를 나타내는 ID(identifier)와 최대 8개의 데이터 바이트로 구성됩니다.CRC, ACK(확인 슬롯) 및 기타 오버헤드도 메시지의 일부입니다.향상된 CAN FD는 데이터 섹션의 길이를 프레임당 최대 64바이트까지 확장합니다.메시지는 NRZ(Non-Return-to-Zero) 형식을 사용하여 버스에 직렬로 전송되고 모든 노드에 의해 수신될 수 있습니다.

CAN 네트워크에 의해 연결되는 장치는 일반적으로 센서, 액추에이터 및 기타 제어 장치입니다.이 장치들은 호스트 프로세서, CAN 컨트롤러 및 CAN 트랜시버를 통해 버스에 연결됩니다.

데이터전송

CAN 데이터 전송은 경쟁 해결의 무손실 비트 와이즈 중재 방법을 사용합니다.이 중재 방법은 CAN 네트워크의 모든 노드를 동기화하여 CAN 네트워크의 모든 비트를 동시에 샘플링하도록 요구합니다.이것이 어떤 사람들이 CAN을 동기화라고 부르는 이유입니다.불행히도 데이터가 비동기 형식으로 전송되기 때문에, 즉 클록 신호 없이 동기식이라는 용어는 정확하지 않습니다.

CAN 사양에서는 도미넌트 비트 및 열성 비트라는 용어를 사용합니다. 여기서 도미넌트는 논리적 0(전송기에 의해 전압으로 능동 구동됨)이고 열성은 논리적 1(저항기에 의해 수동적으로 전압으로 복귀됨)입니다.유휴 상태는 열성 레벨(논리 1)로 표시됩니다.한 노드가 우세한 비트를 전송하고 다른 노드가 우세한 비트를 전송하면 충돌이 발생하고 우세한 비트가 승리합니다.이는 우선순위가 높은 메시지에 지연이 없음을 의미하며, 우선순위가 낮은 메시지를 전송하는 노드는 지배적인 메시지가 종료된 후 자동으로 6비트 클록을 재전송하려고 시도합니다.이를 통해 CAN은 실시간 우선 통신 시스템으로 매우 적합합니다.

논리 0 또는 1에 대한 정확한 전압은 사용되는 물리 계층에 따라 달라지지만, CAN의 기본 원리는 각 노드가 송신 노드 자체(자체)를 포함하여 CAN 네트워크의 데이터를 수신하도록 요구합니다.논리 1이 모든 전송 노드에 의해 동시에 전송되는 경우, 전송 노드와 수신 노드를 모두 포함한 모든 노드에 의해 논리 1이 표시됩니다.논리 0이 모든 전송 노드에 의해 동시에 전송되는 경우, 논리 0은 모든 노드에 의해 표시됩니다.논리 0이 하나 이상의 노드에 의해 전송되고 있고 논리 1이 하나 이상의 노드에 의해 전송되고 있다면 논리 1을 전송하는 노드를 포함한 모든 노드에 의해 논리 0이 표시됩니다.노드가 논리 1을 전송하지만 논리 0을 보면 경쟁이 있음을 깨닫고 전송을 중단합니다.이 프로세스를 사용하여 논리 1을 전송하는 노드는 다른 노드가 논리 0을 전송할 때 중재를 잃고 탈락합니다.중재가 실패한 노드는 나중 전송을 위해 메시지를 재큐잉하고 CAN 프레임 비트 스트림은 한 노드만 전송되도록 오류 없이 계속됩니다.이것은 첫 번째 1을 전송한 노드가 중재에서 진다는 것을 의미합니다.CAN 2.0B의 경우 11(또는 29) 비트 식별자가 모든 노드에 의해 CAN 프레임 시작 시 전송되므로, 식별자가 가장 낮은 노드는 프레임 시작 시 더 많은 0을 전송하며, 이는 중재에서 이기거나 우선 순위가 가장 높은 노드입니다.

예를 들어 ID가 15(이진 표현, 0000000111111) 및 16(이진 표현, 00000010000)인 두 노드가 있는 11비트 ID CAN 네트워크를 생각해 보겠습니다.이 두 노드가 동시에 전송하는 경우, 각 노드는 먼저 시작 비트를 전송한 다음 중재 결정 없이 ID의 처음 6개의 0을 전송합니다.

시작
조금
ID 비트 나머지 프레임은
10 9 8 7 6 5 4 3 2 1 0
노드15 0 0 0 0 0 0 0 0 1 1 1 1
16절 0 0 0 0 0 0 0 1 전송 중지됨
CAN 데이터 0 0 0 0 0 0 0 0 1 1 1 1

ID 비트 4가 전송되면, ID가 16인 노드는 자신의 ID에 대해 1(recessive)을 전송하고, ID가 15인 노드는 자신의 ID에 대해 0(dominant)을 전송합니다.이렇게 되면 ID가 16인 노드는 자신이 1을 전송한 것을 알면서도 0을 보고 충돌이 있다는 것을 깨닫고 중재에서 졌습니다.노드 16은 전송을 중지하므로 ID가 15인 노드는 데이터 손실 없이 전송을 계속할 수 있습니다.ID가 가장 낮은 노드는 항상 중재에서 이기므로 우선 순위가 가장 높습니다.

40 m 미만의 네트워크 길이에서는 최대 1 Mbit/s의 비트 전송이 가능합니다.비트 전송률을 낮추면 네트워크 거리가 길어집니다(예: 125kbit/s에서 500m).향상된 CAN FD 표준은 중재 후 비트 레이트를 증가시킬 수 있으며, 중재 비트 레이트의 최대 10배 이상 데이터 섹션의 속도를 증가시킬 수 있습니다.

ID할당

메시지 ID는 단일 CAN 버스에서 고유해야[11] 합니다. 그렇지 않으면 두 노드가 중재 필드(ID) 끝을 넘어 계속 전송되어 오류가 발생합니다.

1990년대 초반 메시지의 ID 선택은 단순히 데이터의 종류와 송신 노드를 식별하는 것에 기초하여 이루어졌지만, ID를 메시지 우선순위로 사용함에 따라 실시간 성능이 저하되었습니다.이러한 시나리오에서, 모든 메시지가 마감일을 준수하도록 보장하기 위해서는 일반적으로 약 30%의 낮은 CAN 버스 사용량이 필요했습니다.그러나 메시지의 마감일을 기준으로 ID를 대신 결정할 경우, 숫자 ID가 낮을수록 메시지 우선 순위가 높아지기 때문에 일반적으로 메시지 마감일을 놓치기 전에 70-80%의 버스 사용을 달성할 수 있습니다.[12]

비트 타이밍

CAN 네트워크의 모든 노드는 동일한 명목 비트율로 작동해야 하지만 노이즈, 위상 이동, 오실레이터 공차 및 오실레이터 드리프트는 실제 비트율이 명목 비트율이 아닐 수 있음을 의미합니다.[13]별도의 클럭 신호를 사용하지 않기 때문에 노드를 동기화하는 방법이 필요합니다.중재 중에 동기화는 중요한데, 중재 중의 노드들은 자신들의 전송 데이터와 다른 노드들의 전송 데이터를 동시에 볼 수 있어야 하기 때문입니다.노드 간 오실레이터 타이밍의 변동이 오류를 발생시키지 않도록 하려면 동기화도 중요합니다.

동기화는 버스 유휴 기간(시작 비트) 후 첫 번째 열성에서 우세한 전이로 하드 동기화로 시작합니다.프레임 동안 모든 열성에서 우세한 전이에 대해 재동기화가 발생합니다.CAN 컨트롤러는 공칭 비트 시간의 배수에서 전환이 발생할 것으로 예상합니다.컨트롤러가 예상하는 정확한 시간에 전환이 발생하지 않으면 컨트롤러는 그에 따라 공칭 비트 시간을 조정합니다.

조정은 각 비트를 퀀타(quanta)라고 하는 시간 슬라이스의 개수로 나누고, 비트 내의 4개 세그먼트(동기화, 전파, 위상 세그먼트 1 및 위상 세그먼트 2) 각각에 일부 개수의 퀀타를 할당함으로써 이루어집니다.

비트당 10개의 시간 양자를 갖는 CAN 비트 타이밍의 예

비트가 분할되는 양자의 수는 컨트롤러별로 달라질 수 있으며, 각 세그먼트에 할당되는 양자의 수는 비트 레이트 및 네트워크 상황에 따라 달라질 수 있습니다.

이때까지 컨트롤러는 시간차를 계산하고 위상 세그먼트 1을 늘리거나 위상 세그먼트 2를 줄이게 됩니다.이를 통해 수신기와 송신기의 타이밍을 효과적으로 조정하여 동기화할 수 있습니다.이 재동기화 프로세스는 송신기와 수신기가 동기화 상태를 유지하도록 하기 위해 모든 열성에서 우세한 전환 시에 연속적으로 수행됩니다.지속적으로 재동기화하면 노이즈로 인해 발생하는 오류를 줄일 수 있고, 중재에서 실패한 노드에 동기화된 수신 노드는 중재에서 이긴 노드에 재동기화할 수 있습니다.

층수

CAN 프로토콜은 많은 네트워킹 프로토콜과 마찬가지로 다음과 같은 추상화 계층으로 분해할 수 있습니다.

응용 계층
객체 계층
  • 메시지 필터링
  • 메시지 및 상태 처리
전사층

대부분의 CAN 표준은 전송 계층에 적용됩니다.전송 계층은 물리 계층으로부터 메시지를 수신하고 해당 메시지를 개체 계층으로 전송합니다.전송 계층은 비트 타이밍 및 동기화, 메시지 프레이밍, 중재, 확인, 오류 탐지 및 시그널링, 장애 제한을 담당합니다.성능:

  • 고장 구속
  • 오류감지
  • 메시지 유효성 검사
  • 확인
  • 중재
  • 메시지 프레이밍
  • 전송속도 및 타이밍
  • 정보 라우팅
물리층
터미네이터 저항기가 있는 CAN 버스 전기 샘플 토폴로지

CAN 버스(ISO 11898-1:2003)는 원래 물리 계층에 대한 추상적인 요구사항들만을 가지고 링크 계층 프로토콜을 특정하였는데, 예를 들어, 지배적인 상태 및 리세스 상태의 사용을 통해 비트 레벨에서 다중-액세스를 갖는 매체의 사용을 주장하였습니다.물리 계층의 전기적 측면(전압, 전류, 도체의 수)은 ISO 11898-2:2003에 명시되어 있으며, 현재 널리 인정되고 있습니다.그러나 물리 계층의 기계적 측면(커넥터 유형 및 개수, 색상, 라벨, 핀-아웃)은 아직 공식적으로 지정되지 않았습니다.따라서 자동차용 ECU에는 일반적으로 다양한 종류의 케이블이 있는 특정한(종종 맞춤형) 커넥터가 있으며, 그 중 두 개가 CAN 버스 라인입니다.그럼에도 불구하고 기계적 구현을 위한 몇 가지 사실상의 표준이 등장했는데, 가장 일반적인 것은 다음과 같은 핀-아웃이 있는 9핀 D-sub 타입커넥터입니다.

  • 핀 2: CAN-로우(CAN-)
  • 핀 3: GND (접지)
  • 핀 7: CAN-하이(CAN+)
  • 핀 9: CAN V+ (전원)
남성 DE-9 커넥터(플러그)

CAN에 대한 이 사실상의 기계적 표준은 노드 내에서 암수 9핀 D-서브 커넥터가 서로 전기적으로 병렬로 연결된 노드로 구현될 수 있습니다.버스 전원은 노드의 수 커넥터에 공급되고 버스는 노드의 암 커넥터로부터 전원을 끌어옵니다.이는 전원이 암 커넥터에서 종료된다는 전기 공학 관례를 따릅니다.이 표준을 채택하면 두 세트의 버스 와이어를 각 노드에서 하나의 D 커넥터에 연결하기 위해 맞춤형 스플리터를 제작할 필요가 없습니다.노드 외부에서 컨덕터를 연결하는 이러한 비표준(맞춤형) 와이어 하니스(스플리터)는 버스 신뢰성을 떨어뜨리고 케이블 교환성을 없애며 와이어링 하니스의 호환성을 떨어뜨리고 비용을 증가시킵니다.

완전한 물리 계층 사양(전기적 외에 기계적)의 부재는 CAN 버스 사양을 물리적 구현의 제약과 복잡성으로부터 해방시켰습니다.그러나 기계적으로 호환되지 않기 때문에 CAN 버스 구현은 상호 운용성 문제에 노출되었습니다.상호 운용성을 개선하기 위해, 많은 차량 제조업체들은 회선의 기생 커패시턴스에 대한 요구 사항과 조합하여 허용된 CAN 송수신기 세트를 설명하는 사양을 생성했습니다.허용된 기생 커패시턴스에는 ESD 보호(ISO 7637-3에 대한 ESD)뿐만 아니라 커패시터가 모두 포함됩니다.기생 커패시턴스 외에도 12V 시스템과 24V 시스템은 라인 최대 전압 측면에서 동일한 요구 사항을 가지고 있지 않습니다.실제로 점프 스타트 이벤트에서는 경차 라인이 24V까지 올라갈 수 있는 반면 트럭 시스템은 36V까지 올라갈 수 있습니다.새로운 솔루션이 등장하여 CAN FD뿐만 아니라 CAN에도 동일한 구성 요소를 사용할 수 있습니다( 참조).

ISO 11898-2:2003의 노이즈 내성은 버스의 각 끝단에 낮은 값 저항(120옴)을 사용하여 버스의 차동 임피던스를 낮은 레벨로 유지함으로써 달성됩니다.그러나 CAN과 같은 저임피던스 버스는 휴면 상태일 때 다른 전압 기반 시그널링 버스보다 더 많은 전류(및 전력)를 끌어냅니다.CAN 버스 시스템에서 한쪽 신호 라인의 전류가 다른 신호의 반대 방향 전류에 의해 정확히 균형을 맞추는 균형 라인 작동은 수신기에 대해 독립적이고 안정적인 0V 기준을 제공합니다.베스트 프랙티스는 이미 소음이 많은 자동차의 RF 환경에서 간섭 민감성을 줄이고 RF 방출을 최소화하기 위해 차폐된 케이블에서 CAN 버스 균형 쌍 신호가 트위스트 페어 와이어로 전달되는 것을 결정합니다.

ISO 11898-2는 노드 간의 높은 전압 연결을 유지하기 위해 버스를 따라 0V 레일이 운행됨으로써 송신기와 수신기 간의 공통 모드 전압에 대한 내성을 어느 정도 제공합니다.또한, 상술한 사실상의 기계적 구성에 있어서, 송수신부 노드들 각각에 전력을 분배하기 위한 공급 레일을 포함합니다.설계는 모든 송수신기에 공통 공급을 제공합니다.버스가 적용할 실제 전압과 버스에 적용할 노드는 응용 프로그램별이며 공식적으로 지정되지 않습니다.공통 관행 노드 설계는 각 노드에 노드 호스트로부터 광학적으로 격리된 트랜시버를 제공하고 버스에 의해 제공되는 범용 공급 레일로부터 트랜시버를 위한 5 V 선형 조절 공급 전압을 도출합니다.이를 통해 일반적으로 공급 레일의 작동 마진이 여러 노드 유형에 걸쳐 상호 운용성을 확보할 수 있습니다.이러한 네트워크의 일반적인 전원 전압 값은 7~30V입니다.그러나 공식적인 표준이 없다는 것은 시스템 설계자가 공급 레일 호환성을 책임진다는 것을 의미합니다.

ISO 11898-2는 버스의 각 단부에 저항기 종단이 있는 다중 드롭된 단일 종단 균형 라인 구성으로 형성된 전기적 구현을 설명합니다.이 구성에서 우세 상태는 CAN을 스위칭하는 하나 이상의 송신기가 0V를 공급하고 (동시에) CAN+를 +5V 버스 전압으로 스위칭하여 버스를 종단하는 저항기를 통한 전류 경로를 형성합니다.이와 같이 종단 저항은 신호 시스템의 필수 구성 요소를 형성하며, 이는 단지 고주파에서의 파동 반사를 제한하기 위한 것이 아니라 포함됩니다.

리세스 상태에서는 신호 라인과 저항기가 양쪽 레일에 대해 고임피던스 상태로 유지됩니다.CAN+와 CAN-의 전압은 레일 사이의 중간 전압으로 약합니다.버스에 있는 송신기 중 어느 것도 우세 상태를 주장하지 않는 경우에만 버스에 열성 상태가 존재합니다.

우세 상태에서는 신호선과 저항기가 레일에 대해 낮은 임피던스 상태로 이동하여 전류가 저항기를 통해 흐릅니다.CAN+ 전압은 +5V로, CAN-은 0V로 증가합니다.

신호 상태에 관계없이 버스 끝에 있는 종단 저항으로 인해 신호 라인은 항상 서로에 대해 낮은 임피던스 상태에 있습니다.

이러한 시그널링 전략은 RS-422/3, RS-485 등과 같이 차동 라인 드라이버/수신기를 사용하고, 평형 라인의 차동 모드 전압에 기초한 시그널링 시스템을 사용하는 다른 평형 라인 전송 기술과 큰 차이가 있습니다.이러한 시스템에 대한 다중 액세스는 일반적으로 세 가지 상태(활성 하이, 활성 로우 및 비활성 트라이 스테이트)를 지원하는 미디어에 의존하며 시간 영역에서 처리됩니다.CAN 버스의 다중 액세스는 '유선 AND' 네트워크와 개념적으로 유사한 두 가지 상태만을 지원하는 시스템의 전기적 논리에 의해 가능합니다.

CAN 네트워크는 표준 또는 기본 프레임 형식(CAN 2.0 A 및 CAN 2.0 B에서 설명)과 확장 프레임 형식(CAN 2.0 B에서만 설명)의 두 가지 다른 메시지(또는 프레임) 형식으로 작동하도록 구성할 수 있습니다.두 형식의 차이점은 CAN 기본 프레임은 식별자에 대해 11비트 길이를 지원하고 CAN 확장 프레임은 식별자에 대해 11비트 식별자(기본 식별자)와 18비트 확장(식별자 확장)으로 구성된 29비트 길이를 지원한다는 것입니다.CAN 베이스 프레임 포맷과 CAN 확장 프레임 포맷의 구분은 IDE 비트를 이용하여 이루어지며, IDE 비트는 11비트 프레임의 경우 도미넌트로 전송되고, 29비트 프레임의 경우 열성으로 전송됩니다.확장 프레임 형식 메시지를 지원하는 CAN 컨트롤러는 CAN 기본 프레임 형식으로 메시지를 송수신할 수도 있습니다.모든 프레임은 프레임 전송의 시작을 나타내는 SOF(Start-of-Frame) 비트로 시작합니다.

CAN에는 다음과 같은 4가지 프레임 유형이 있습니다.

  • 데이터 프레임: 전송을 위한 노드 데이터를 포함하는 프레임
  • 리모트 프레임 : 특정 식별자의 전송을 요청하는 프레임
  • Error Frame: 임의의 노드가 오류를 탐지하여 전송한 프레임
  • 오버로드 프레임(Overload Frame): 데이터 또는 원격 프레임 사이에 지연을 주입하기 위한 프레임

자료틀

데이터 프레임은 실제 데이터 전송을 위한 유일한 프레임입니다.두 가지 메시지 형식이 있습니다.

  • 기본 프레임 형식: 식별자 비트 11개 포함
  • 확장 프레임 형식: 식별자 비트 29개 포함

CAN 표준은 구현이 기본 프레임 형식을 수용해야 하며 확장 프레임 형식을 수용할 수 있지만 확장 프레임 형식은 허용해야 합니다.

기본 프레임 형식

스터프 비트, 정확한 CRC 및 프레임 간 간격을 포함한 완전한 CAN 버스 프레임

프레임 형식은 다음과 같습니다.비트 값은 CAN-LO 신호에 대해 설명됩니다.

필드명 길이(비트) 목적
프레임시작 1 프레임 전송의 시작을 나타냅니다.
식별자(녹색) 11 메시지 우선 순위를 나타내기도 하는 (고유의) 식별자
스터프 비트 1 동기화를 유지하기 위한 약간의 반대 극성. § 비트 스터핑 참조
원격전송요청(RTR)(파란색) 1 데이터 프레임의 경우 우세(0), 원격 요청 프레임의 경우 열성(1)이어야 합니다(아래 원격 프레임 참조).
식별자 확장 비트(IDE) 1 11비트 식별자가 있는 기본 프레임 형식의 경우 우세(0)여야 합니다.
예약 비트(r0) 1 예약 비트.우세(0)여야 하지만 우세 또는 열성으로 인정됩니다.
데이터 길이 코드(DLC)(노란색) 4 데이터 바이트 수(0~8바이트)[a]
데이터 필드(빨간색) 0–64(0-8바이트) 전송할 데이터(DLC 필드에 따라 지정된 바이트 단위의 길이)
CRC 15 주기적중복검사
CRC 구분 기호 1 열성이어야 함(1)
ACK 슬롯 1 송신기가 열성(1)을 전송하고 모든 수신기가 우세(0)를 주장할 수 있습니다.
ACK 구분 기호 1 열성이어야 함(1)
EOF(End of Frame) 7 열성이어야 함(1)
프레임간 간격(IFS) 3 열성이어야 함(1)
  1. ^ 4비트 DLC에서 9-15 사이의 값이 전송되는 것은 물리적으로 가능하지만, 데이터는 여전히 8바이트로 제한됩니다.특정 컨트롤러는 8바이트보다 큰 DLC의 송수신을 허용하지만 실제 데이터 길이는 항상 8바이트로 제한됩니다.

확장 프레임 형식

프레임 형식은 아래 표의 여기서부터 다음과 같습니다.

필드명 길이(비트) 목적
프레임시작 1 프레임 전송의 시작을 나타냅니다.
식별자 A(녹색) 11 메시지 우선 순위를 나타내는 (고유) 식별자의 첫 번째 부분
대체 원격 요청(SRR) 1 열성이어야 함(1)
식별자 확장 비트(IDE) 1 29비트 식별자가 있는 확장 프레임 형식의 경우 열성(1)이어야 합니다.
식별자 B(녹색) 18 메시지 우선 순위를 나타내기도 하는 (고유) 식별자의 두 번째 부분
원격전송요청(RTR)(파란색) 1 데이터 프레임의 경우 우세(0), 원격 요청 프레임의 경우 열성(1)이어야 합니다(아래 원격 프레임 참조).
예약 비트(r1, r0) 2 도미넌트(0)로 설정해야 하지만 도미넌트 또는 열성 비트로 허용되는 예약 비트
데이터 길이 코드(DLC)(노란색) 4 데이터 바이트 수(0~8바이트)[a]
데이터 필드(빨간색) 0–64(0-8바이트) 전송할 데이터(DLC 필드에 따라 지정된 길이)
CRC 15 주기적중복검사
CRC 구분 기호 1 열성이어야 함(1)
ACK 슬롯 1 송신기가 열성(1)을 전송하고 모든 수신기가 우세(0)를 주장할 수 있습니다.
ACK 구분 기호 1 열성이어야 함(1)
EOF(End of Frame) 7 열성이어야 함(1)
  1. ^ 4비트 DLC에서 9-15 사이의 값이 전송되는 것은 물리적으로 가능하지만, 데이터는 여전히 8바이트로 제한됩니다.특정 컨트롤러는 8바이트보다 큰 DLC의 송수신을 허용하지만 실제 데이터 길이는 항상 8바이트로 제한됩니다.

두 개의 식별자 필드(A & B)는 결합되어 29비트 식별자를 형성합니다.

리모트 프레임

  • 일반적으로, 데이터 전송은 데이터 소스 노드(예를 들어, 센서)가 데이터 프레임을 전송함으로써 자율적으로 수행됩니다.그러나 대상 노드가 원격 프레임을 전송하여 소스에 데이터를 요청할 수도 있습니다.
  • 데이터 프레임과 원격 프레임 사이에는 두 가지 차이점이 있습니다.첫째, RTR 비트는 데이터 프레임에서 우세한 비트로 전송되고 둘째, 원격 프레임에서는 데이터 필드가 없습니다.DLC 필드는 요청된 메시지의 데이터 길이(전송된 메시지가 아님)를 나타냅니다.
    예.,
RTR = 0 ; 데이터 프레임에서 지배적
RTR = 1 ; 원격 프레임의 열성형

동일한 식별자를 갖는 데이터 프레임과 리모트 프레임이 동시에 전송되는 경우, 식별자에 이어 도미넌트 RTR 비트로 인해 데이터 프레임이 중재에서 승리합니다.

에러 프레임

오류 프레임은 두 개의 다른 필드로 구성됩니다.

  • 첫 번째 필드는 서로 다른 스테이션에서 제공된 ERROR FLAGS(6–12개의 우세/강하 비트)의 중첩에 의해 제공됩니다.
  • 다음 두 번째 필드는 ERROR DELMITER(8개의 열성 비트)입니다.

오류 플래그에는 두 가지 유형이 있습니다.

활성 오류 플래그
6개의 우세한 비트 – 네트워크에서 오류 상태 오류가 활성 상태인 오류를 탐지하는 노드에 의해 전송됩니다.
수동 오류 플래그
6개의 열성 비트 – 네트워크에서 오류 상태 오류 패시브 상태인 활성 오류 프레임을 탐지하는 노드에 의해 전송됩니다.

CAN에는 두 개의 오류 카운터가 있습니다.

  1. 전송 오류 카운터(TEC)
  2. 수신 오류 카운터(REC)
  • TEC 또는 REC가 127보다 크고 255보다 작으면 버스에서 Passive Error 프레임이 전송됩니다.
  • TEC 및 REC가 128 미만이면 버스에서 Active Error 프레임이 전송됩니다.
  • TEC가 255보다 크면, 노드는 버스 오프(Bus Off) 상태가 되며, 여기서 프레임은 전송되지 않습니다.

과적프레임

오버로드 프레임에는 두 개의 비트 필드가 포함됩니다.오버로드 플래그 및 오버로드 구분 기호입니다.오버로드 플래그가 전송될 수 있는 오버로드 조건에는 다음 두 가지가 있습니다.

  1. 수신기의 내부 상태, 다음 데이터 프레임 또는 원격 프레임의 지연이 필요합니다.
  2. 인터미션 중에 우세한 비트를 탐지합니다.

케이스 1로 인한 오버로드 프레임의 시작은 예상되는 인터미션의 첫 번째 비트 시간에만 시작되도록 허용되는 반면 케이스 2로 인한 오버로드 프레임은 도미넌트 비트를 검출한 후에 한 비트가 시작됩니다.오버로드 플래그는 6개의 우세한 비트로 구성됩니다.전체 양식은 활성 오류 플래그의 양식과 일치합니다.오버로드 플래그의 형태는 인터미션 필드의 고정 형태를 파괴합니다.결과적으로, 다른 모든 스테이션들 또한 과부하 상태를 감지하고 그들 측에서는 과부하 플래그의 전송을 시작합니다.오버로드 구분 기호는 8개의 열성 비트로 구성됩니다.오버로드 구분 기호가 오류 구분 기호와 같은 형식입니다.

ACK 슬롯

승인 슬롯은 유효한 CAN 프레임의 수신을 승인하는 데 사용됩니다.프레임을 수신한 각 노드는 오류를 발견하지 않고 ACK 슬롯에서 우세한 레벨을 전송하므로 송신기의 열성 레벨을 무시합니다.송신기가 ACK 슬롯에서 열성 레벨을 감지하는 경우, 어떤 수신기도 유효한 프레임을 발견하지 못했다는 것을 알 수 있습니다.수신 노드는 유효한 프레임을 수신하지 않았음을 나타내기 위해 열성형을 전송할 수 있지만, 유효한 프레임을 수신한 다른 노드는 이를 우세형으로 재정의할 수 있습니다.송신 노드는 CAN 네트워크의 모든 노드가 메시지를 수신했는지 알 수 없습니다.

종종, 디바이스의 동작 모드는 승인되지 않은 프레임들을 반복하여 재전송하는 것입니다.이로 인해 결국 오류 수동 상태로 전환될 수 있습니다.

프레임 간격

데이터 프레임과 원격 프레임은 인터프레임 공간(interframe space)이라는 비트 필드에 의해 이전 프레임과 분리됩니다.인터프레임 공간은 최소 3개의 연속적인 리세스(1) 비트로 구성됩니다.이후, 도미넌트 비트가 검출되면, 다음 프레임의 Start of frame 비트로 간주됩니다.오버로드 프레임과 에러 프레임에는 인터프레임 공간이 선행되지 않으며 여러 오버로드 프레임에는 인터프레임 공간이 구분되지 않습니다.인터프레임 공간에는 비트 필드 인터미션과 버스 아이들, 이전 메시지의 송신기였던 에러 패시브 스테이션에 대한 송신 중단이 포함됩니다.[16]

비트 스터핑

항목 비트 추가 전후의 CAN 프레임(보라색).잘못된 CRC는 비트 스터핑 일러스트레이션 목적으로 사용됩니다.

동기화를 유지하기에 충분한 전환을 보장하기 위해 같은 극성의 5비트 연속 후에 반대 극성의 비트를 삽입합니다.이 방법은 비트 스터핑(bit stuffing)이라고 하며, CAN과 함께 사용되는 NRZ(Non-Return-to-zero) 코딩 때문에 필요합니다.채워진 데이터 프레임은 수신기에 의해 압축이 해제됩니다.

프레임의 모든 필드는 CRC 구분 기호, ACK 필드 및 프레임 끝을 제외하고 고정된 크기이며 채워지지 않습니다.비트 스터핑이 사용되는 필드에서는 동일한 극성(1111 또는 000000)의 연속된 6비트가 오류로 간주됩니다.활성 오류 플래그는 오류가 감지되면 노드에서 전송할 수 있습니다.활성 오류 플래그는 6개의 연속적인 도미넌트 비트로 구성되며 비트 스터핑 규칙을 위반합니다.

비트 스터핑은 데이터 프레임이 위의 표에 나와 있는 비트를 단순히 열거함으로써 예상하는 것보다 더 클 수 있음을 의미합니다.비트 스터핑 후 CAN 프레임(베이스 포맷)의 최대 크기 증가는 다음과 같습니다.

11111000011110000...

다음과 같이 채워집니다( 굵게 표시된 비트 stuff).

111110000011111000001...

스터핑 비트 자체는 5개의 연속적인 동일한 비트 중 첫 번째 비트일 수 있으므로 최악의 경우 4개의 원본 비트 당 하나의 스터핑 비트가 있습니다.

기본 프레임의 크기는 다음과 같이 제한됩니다.

여기서 n은 최대 8개의 데이터 바이트 수입니다.

+ + 채우기 전 프레임의 크기이므로 최악의 경우 첫 번째 비트 뒤에 원래 비트 4개마다 1비트가 추가되며(따라서 분자의 -1) 헤더의 비트 레이아웃 때문에 44개 중 34개만 비트 스터핑의 대상이 될 수 있습니다.

액자형 충전하기 전에 소를 채운 후에 박음질 총프레임길이
밑틀
신장틀

비트 스터핑 방식의 바람직하지 않은 부작용은 수신된 메시지에서 적은 수의 비트 오류가 디스터핑 프로세스를 손상시켜 더 많은 수의 오류가 디스터핑된 메시지를 통해 전파되도록 할 수 있다는 것입니다.이는 원래 오류에 대한 CRC의 보호 수준을 감소시킵니다.프로토콜의 이러한 결함은 고정된 스터프 비트와 삽입된 스터프 비트의 수를 기록하는 카운터의 조합을 사용하여 CAN FD 프레임에서 해결되었습니다.

CAN 하위 계층 표준

ISO 11898 시리즈는 도로 차량 내에서 사용하기 위한 분산 실시간 제어 및 다중화를 지원하는 Controller Area Network라는 시리얼 통신 카테고리의 물리적 및 데이터 링크 계층(ISO/OSI 모델의 레벨 1 및 2)을 지정합니다.[17]

몇 가지 CAN 물리 계층 및 기타 표준이 있습니다.

ISO 11898-1:2015CAN(Controller Area Network)데이터 링크 계층(DLL) 및 물리적 신호 전달을 규정합니다.[18]본 문서는 ISO/IEC 7498-1에 제정된 개방형 시스템 상호접속(OSI)위한 ISO 참조 모델에 따른 계층적 계층의 CAN의 일반적인 아키텍처를 설명하고 상세 사양의 CAN DLL을 구현하는 모듈 간의 디지털 정보 교환 설정을 위한 특성을 제공합니다논리 링크 제어(LLC) 서브레이어 및 MAC(Medium Access Control) 서브레이어를 포함하는 것을 특징으로 하는 방법.

ISO 11898-2:2016은 컨트롤러 영역 네트워크의 물리 계층을 구성하는 고속(최대 1 Mbit/s의 전송 속도) 매체 액세스 유닛(MAU) 및 일부 매체 종속 인터페이스(MDI) 기능을 규정합니다(ISO 8802-3 기준).ISO 11898-2는 2-와이어 균형 시그널링 방식을 사용합니다.이 층은 차량 파워트레인 응용 분야 및 산업 제어 네트워크에서 가장 많이 사용되는 물리적 층입니다.

ISO 11898-3:2006은 최대 125kbit/s까지 40kbit/s 이상의 전송 속도로 CAN을 장착한 도로 차량의 전자 제어 장치 간의 디지털 정보 교환을 설정하기 위한 저속, 내결함성, 중의존성 인터페이스를 규정하고 있습니다.

ISO 11898-4:2004는 CAN(TTCAN)에서 시간 트리거 통신을 지정합니다.CAN이 장착된 도로 차량의 전자제어장치(ECU) 간의 디지털 정보의 시간 트리거 교환 설정에 적용될 수 있으며, ISO 11898-1에 따라 논리적 링크 및 미디어 액세스 제어 모두의 동작을 조정하는 프레임 동기화 개체를 지정하고,시간 triggered 통신 스케줄을 제공합니다.

ISO 11898-5:2007은 도로 차량 내에서 사용하기 위해 최대 1 Mbit/s의 전송 속도를 위한 CAN 물리 계층을 지정합니다.ISO 8802-2에 따른 매체 접근 장치 기능 및 일부 매체 의존적 인터페이스 기능에 대해 설명합니다.이는 ISO 11898-2의 확장을 의미하며, 활성 버스 통신이 없는 동안 저전력 소비 기능을 필요로 하는 시스템을 위한 새로운 기능을 다룹니다.

ISO 11898-6:2013은 도로 차량 내에서 사용할 수 있도록 최대 1 Mbit/s의 전송 속도를 위한 CAN 물리 계층을 지정합니다.ISO 8802-2에 따른 매체 접근 장치 기능 및 일부 매체 의존적 인터페이스 기능에 대해 설명합니다.이는 ISO 11898-2 및 ISO 11898-5의 확장을 나타내며, 구성 가능한 CAN 프레임을 사용하여 선택적 웨이크업 메커니즘을 지정합니다.

ISO 16845-1:2016은 ISO 11898-1에 명시된 CAN 구현의 적합성을 검사하는 데 필요한 방법론 및 추상 테스트 스위트를 제공합니다.

ISO 16845-2:2018은 선택적 웨이크업 기능이 구현된 CAN 송수신기가 지정된 기능을 준수하는지 확인하는 테스트 계획을 실현하기 위한 테스트 사례 및 테스트 요구사항을 수립합니다.ISO 16845-2:2018에 정의된 테스트의 종류를 적합성 테스트라고 합니다.

CAN 기반 상위 계층 프로토콜

CAN 표준에는 흐름 제어, 장치 어드레싱, 하나의 메시지보다 큰 데이터 블록의 전송 등과 같은 공통적인 통신 기능이 포함되어 있지 않기 때문에, 무엇보다도 애플리케이션 데이터가 많이 구현되었습니다.몇 가지는 비즈니스 영역에 대해 표준화되어 있지만, 모든 것은 각 제조업체에 의해 확장될 수 있습니다.승용차의 경우 제조사마다 기준이 있습니다.

CiA(CAN in Automation)는 CAN 기반 상위 계층 프로토콜과 이들의 국제 표준화를 개발 및 지원하는 국제 사용자 및 제조업체 단체입니다.[19]이러한 사양 중에는 다음이 있습니다.

표준화된 접근방식

기타접근방법

CANopen 리프트

2001년 설립된 CANopen Special Interest Group(SIG) "리프트 컨트롤(Lift Control)"은 리프트 컨트롤 시스템을 위한 CANopen 응용 프로그램 프로파일 CiA 417을 개발합니다.기능을 확장하고, 기술적 내용을 개선하며, 리프트 제어 시스템에 대한 현재의 법적 기준을 충족하도록 보장합니다.CiA 417의 첫 번째 버전은 2003년 여름에 출시되었으며, 2010년 2월 버전 2.0, 2012년 7월 버전 2.1.0, 2015년 12월 버전 2.2.0, 2020년 2월 버전 2.3.1이 출시되었습니다.

Jörg Hellmich(ELFIN GmbH)는 본 SIG의 의장이며 CAN 오픈 리프트에 관한 내용을 담은 CAN 오픈 리프트 커뮤니티의 Wiki를 관리하고 있습니다.

보안.

CAN은 낮은 수준의 프로토콜로 고유한 보안 기능을 지원하지 않습니다.또한 표준 CAN 구현에는 암호화 기능이 없으므로 이러한 네트워크는 중간 프레임 가로채기에 열려 있습니다.대부분의 구현에서 애플리케이션은 자체적인 보안 메커니즘(예: 들어오는 명령 또는 네트워크 상의 특정 장치의 존재를 인증하는 것)을 구축할 것으로 예상됩니다.적절한 보안 조치를 시행하지 않을 경우 상대가 버스에 메시지를 삽입하는 데 성공할 경우 다양한 유형의 공격이 발생할 수 있습니다.[20]펌웨어 수정, 키 프로그래밍 또는 안티록 브레이크 액추에이터 제어와 같은 일부 안전에 중요한 기능에는 암호가 존재하지만, 이러한 시스템은 범용적으로 구현되지 않으며 시드/키 쌍의 수가 제한적입니다.

개발도구

CAN 버스를 개발하거나 문제를 해결할 때 하드웨어 신호를 검사하는 것이 매우 중요할 수 있습니다.로직 분석기버스 분석기는 신호를 수집, 분석, 해독 및 저장하는 도구로, 사람들이 자유롭게 고속 파형을 볼 수 있도록 해줍니다.CAN 버스 모니터 뿐만 아니라 전문 도구도 있습니다.

CAN 버스 모니터는 종종 하드웨어소프트웨어를 조합하여 CAN 버스를 사용하는 하드웨어를 개발하는 동안 사용되는 분석 도구입니다.

일반적으로 CAN 버스 모니터는 CAN 버스의 트래픽을 청취하여 사용자 인터페이스에 표시합니다.종종 CAN 버스 모니터는 CAN 프레임을 버스로 전송함으로써 CAN 버스 활동을 시뮬레이션할 수 있는 기능을 제공합니다.따라서 CAN 버스 모니터는 CAN 버스에 연결된 특정 장치의 반응을 검증하기 위해 해당 장치에서 예상되는 CAN 트래픽을 검증하거나 CAN 트래픽을 시뮬레이션하는 데 사용할 수 있습니다.

라이센싱

Bosch는 이 기술에 대한 특허를 보유하고 있지만, 원래 프로토콜과 관련된 특허는 현재 만료되었습니다.CAN 호환 마이크로프로세서 제조업체는 Bosch에 CAN 상표 및 CAN FD와 관련된 최신 특허 사용에 대한 라이센스 비용을 지불하며, 이러한 라이센스 비용은 일반적으로 칩 가격으로 고객에게 전달됩니다.CAN 호환 모듈이 포함된 맞춤형 ASIC 또는 FPGA 제품 제조업체는 CAN 상표 또는 CAN FD 기능을 사용하려면 CAN 프로토콜 라이센스에 대한 수수료를 지불해야 합니다.[21]

참고 항목

  • 바이트플라이트
  • 자동차 오디오 – 차량 내 엔터테인먼트 전자 장치 에 대한
  • CAN 버스 모니터 컴퓨터가 없는 장치 간 통신 표준방향 전환 하는 페이지
  • IMT-2000 3GPP-CANopen 임베디드 시스템을 위한 통신 프로토콜
  • CANpie – CAN용 오픈 소스 장치 드라이버
  • CAN FD – 전송 속도가 빨라진 CAN의 새로운 구현
  • can4linux – CAN용 오픈 소스 Linux 장치 드라이버
  • FlexCAN – 대안적인 구현.
  • FlexRay – CAN에 대한 고속 대안
  • 네트워크 버스 목록 – 단일 충돌 도메인 전자 통신 버스 시스템 목록
  • Local Interconnect Network – 저비용 대안
  • Modbus – 주로 프로그래밍 가능한 로직 컨트롤러용으로 개발된 직렬 통신 프로토콜
  • MOST 버스 산업에서 사용되는 고속 멀티미디어 네트워크 기술 리디렉션 에 대한 하는 페이지
  • OBD-II PID – 파라미터 ID 목록
  • OSEK – 자동차 내 임베디드 운영체제 사양
  • SAE J1939 - 트럭 및 버스 통신 프로토콜
  • 소켓 CAN – 오픈 소스 CAN 드라이버 세트와 폭스바겐 리서치가 Linux 커널에 제공한 네트워킹 스택입니다.

참고문헌

  1. ^ a b "CAN History". CAN in Automation.
  2. ^ "Mercedes-Benz S-Class W 140". mercedes-benz.com. 23 February 2016. Retrieved 27 October 2017.
  3. ^ "CAN in Automation - Mercedes W140: First car with CAN". can-newsletter.org. Retrieved 27 October 2017.
  4. ^ "Bosch Semiconductor CAN Literature". Archived from the original on 2017-05-23. Retrieved 2017-05-31.
  5. ^ de Andrade, R.; Hodel, K. N.; Justo, J. F.; Laganá, A. M.; Santos, M. M.; Gu, Z. (2018). "Analytical and Experimental Performance Evaluations of CAN-FD Bus". IEEE Access. 6: 21287–21295. doi:10.1109/ACCESS.2018.2826522.
  6. ^ 차량 탑재 진단용 Building Adapter 2018-05-14 Wayback Machine, obddiag.net 에서 보관, 2009-09-09에 액세스
  7. ^ 분산 제어 시스템 A에 대한 이벤트 트리거 및 시간 트리거 개념 비교Albert, Robert Bosch GmbH Embedded World, 2004, Nürnberg
  8. ^ "NISMO Increases GT6 GPS Data Logger Functionality and Track Count". www.gtplanet.net. 25 October 2014.
  9. ^ "What is DiveCAN and why should I care?". 22 March 2016.
  10. ^ "ISO11783 a Standardized Tractor – Implement Interface" (PDF).
  11. ^ ISO 11898-1:2015 – Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical signalling.
  12. ^ Daigmorte, Hugo; Boyer, Marc (2017), "Evaluation of admissible CAN bus load with weak synchronization mechanism", Proc. of the 24th Int. Conf. on Real-Time Networks and Systems (RTNS 2017), Grenoble, France: ACM
  13. ^ "Understanding Microchip's CAN Module Bit Timing" (PDF).
  14. ^ "ISO7637-3 diodes protection for CAN bus".
  15. ^ "CAN bus ESD protection".
  16. ^ "CAN BUS MESSAGE FRAMES – Overload Frame, Interframe Space". 18 November 2009.
  17. ^ "Controller Area Network (CAN)". Vector Group. Archived from the original on 25 April 2016. Retrieved 25 Sep 2013.
  18. ^ "ISO 11898-1:2003 - Road vehicles -- Controller area network (CAN) -- Part 1: Data link layer and physical signalling". ISO.
  19. ^ CiA: 국제 표준화.
  20. ^ "We Drove a Car While It Was Being Hacked". www.vice.com. Archived from the original on 8 November 2019.
  21. ^ "License Conditions CAN Protocol and CAN FD Protocol" (PDF). Archived from the original (PDF) on 2016-03-16. Retrieved 2016-03-15.

외부 링크

사양서
다른.