CAN (Controller Area Network) 개요
컨트롤러 영역 네트워크(CAN) 버스는 지능형 디바이스를 네트워크로 연결하는 고정밀 시리얼 버스 시스템입니다. CAN 버스 및 디바이스는 자동차 및 산업 시스템의 일반적인 구성요소입니다. CAN 인터페이스 디바이스를 사용하면 LabVIEW 어플리케이션을 작성하여 CAN 네트워크와 통신할 수 있습니다.
CAN은 Bosch가 1985년에 차량 내 네트워크를 위해 개발했습니다. 과거에 자동차 제조업체는 점대점 배선 시스템을 사용하여 차량 내 전자 장치를 연결했습니다. 제조업체는 자동차에서 점점 더 많은 전자 장치를 사용하기 시작했으며, 크고 무겁고 비싼 배선 하네스가 사용되었습니다. 그 후에는 전용 배선을 차량 내 네트워크로 교체하여 배선 비용, 복잡성 및 무게를 줄였습니다. 지능형 디바이스 네트워킹을 위한 고정밀 직렬 버스 시스템인 CAN은 표준 차내 네트워크로 부상했습니다. 자동차 산업은 빠르게 CAN를 도입했고, 1993년에는 ISO 11898이라는 국제 표준이 되었습니다. 1994년부터 CANopen 및 DeviceNet과 같은 몇 가지 상위 레벨 프로토콜이 CAN 위에 표준화되었습니다. 다른 시장에서는 이러한 추가 프로토콜을 널리 채택했으며, 이는 현재 산업용 통신의 표준입니다. 이 백서는 차량 내 네트워크로서의 CAN에 중점을 둡니다.
CAN 장점
저비용, 경량 네트워크
CAN은 여러 CAN 디바이스간 통신을 위한 경제적이며 안정적인 네트워크를 제공합니다. 이 방법의 장점은 전자 제어 유닛(ECU)이 시스템의 모든 디바이스에 대한 아날로그 및 디지털 입력을 가져야 하는 것이 아니라 단일 CAN 인터페이스만 가지면 된다는 점입니다. 따라서 자동차 전체 비용이 절감되며 무게도 줄어듭니다.
브로드캐스트 통신
네트워크의 각 디바이스에는 CAN 컨트롤러 칩이 있고, 따라서 지능적입니다. 네트워크의 모든 디바이스는 전송되는 모든 메시지를 볼 수 있습니다. 각 디바이스는 메시지가 중요한지, 아니면 제거해도 되는지 결정합니다. 이 구조에서는 최소한의 영향으로 CAN 네트워크를 수정할 수 있습니다. 네트워크를 수정하지 않고도 비전송 노드를 추가할 수 있습니다.
우선순위
모든 메시지에는 우선순위가 있으므로 두 개의 노드가 동시에 메시지를 전송하면 우선순위가 높은 메시지가 먼저 전송되고 낮은 우선 순위의 메시지는 전송이 연기됩니다. 이 중재는 비파괴적이며 가장 높은 우선순위 메시지가 방해받지 않고 전송될 수 있게 합니다. 이것은 또한 네트워크가 결정성 있는 타이밍 제약을 충족할 수 있도록 합니다.
에러 기능
CAN 스펙에는 각 프레임의 내용의 에러를 확인하도록 CRC(Cyclic Redundancy Code)가 포함되어 있습니다. 에러가 있는 프레임은 모든 노드에 의해 무시되며, 에러 프레임을 전송하여 네트워크에 에러를 신호할 수 있습니다. 전역 및 로컬 에러는 컨트롤러에 의해 구분되며 너무 많은 에러가 감지되면 개별 노드가 에러 전송을 중지하거나 네트워크에서 완전히 연결을 끊을 수 있습니다.
그림 1. CAN 네트워크는 배선 필요를 크게 줄입니다.
CAN은 자동차용으로 처음 만들어졌기 때문에 가장 일반적인 응용 분야는 차량 내 전자 장치 통신입니다. 그러나 다른 산업에서 지난 20년 동안 CAN의 신뢰성과 이점을 알게되면서 다양한 분야에서 CAN을 채택했습니다. 전차, 트램, 지하철, 경전철 및 장거리 열차와 같은 철도 분야에서도 CAN을 사용합니다.도어 유닛, 브레이크 컨트롤러, 승객 계산 유닛 등을 연결하는 CAN 장치의 예는 이러한 차량 내 여러 네트워크의 다양한 수준에서 찾을 수 있습니다.
CAN은 또한 비행 상태 센서, 항법 시스템 및 조종석 내 연구용 PC가 있는 항공기에서도 사용됩니다. 또한 기내 데이터 분석에서 연료 시스템, 펌프 및 선형 액추에이터와 같은 항공기 엔진 제어 시스템에 이르기까지 다양한 항공우주 분야에서도 CAN 버스를 찾을 수 있습니다.
의료 장비 제조업체는 CAN을 의료 장비의 임베디드 네트워크로 사용합니다. 실제로 일부 병원에서는 CAN을 사용하여 수술실 전체를 관리합니다. 병원은 CAN 기반 시스템을 사용하여 조명, 테이블, 카메라, X선 기계 및 환자 침대와 같은 수술실 구성요소를 제어합니다. 리프트와 에스컬레이터는 임베디드 CAN 네트워크를 사용하고 병원은 CANopen 프로토콜을 사용하여 패널, 컨트롤러, 도어 및 라이트 배리어와 같은 리프트 디바이스를 서로 연결하고 제어합니다. CANopen은 또한 실험실 장비, 스포츠 카메라, 망원경, 자동문, 심지어 커피 머신과 같은 비산업용 분야에서도 사용됩니다.
CAN 물리 계층
CAN에는 사용할 수 있는 여러 다른 물리 계층이 있습니다. 이러한 물리 계층은 전기적 레벨, 신호 체계, 케이블 임피던스, 최대 보 전송속도 등과 같은 CAN 네트워크의 특정 측면을 분류합니다.
가장 일반적이고 널리 사용되는 물리 계층은 다음과 같습니다.
고속/FD CAN
고속 CAN은 가장 일반적인 물리 계층입니다. 고속 CAN 네트워크는 2개의 선으로 구현되며 최대 1Mbit/s의 전송 속도 통신을 허용합니다. 고속 CAN의 다른 이름은 CAN C 및 ISO 11898-2가 있습니다. 일반적인 고속 CAN 디바이스에는 잠금 방지 브레이크 시스템, 엔진 제어 모듈 및 배출 가스 시스템이 포함됩니다. 유연한 데이터 속도를 갖춘 CAN(CAN FD)는 더 높은 데이터 속도를 위한 발전하는 표준이 있는 차세대 고속 CAN 통신입니다.
NI는 NI-XNET 드라이버를 통해 TJA1041 및 TJA1043 트랜시버를 사용하여 최대 8Mbit/s의 속도를 지원합니다. 트랜시버 공급업체가 CAN FD 속도에 대한 자격을 충족하게 되면서 NI는 필요에 따라 문서를 업데이트할 것입니다.
저속/내결함성 CAN 하드웨어
저속/내결함성 CAN 네트워크는 또한 2개의 선으로도 구현되고, 최대 125kbit/s의 속도로 디바이스들과 통신할 수 있으며, 내결함성을 트랜시버에 제공합니다. 저속/내결함성 CAN의 다른 이름으로는 CAN B 및 ISO 11898-3이 있습니다. 자동차의 일반적인 저속/내결함성 디바이스로는 편의 장치들이 포함됩니다.
차량의 문을 통과해야 하는 선은 문을 여닫을 때 발생하는 부하를 고려하여 저속/내결함성을 요구합니다. 또한 제동 등과 같이 높은 수준의 보안이 필요한 상황에서는 저속/내결함성 CAN이 해결책이 됩니다.
단선 CAN 하드웨어
단선 CAN 인터페이스는 최대 33.3kbit/s(고속 모드에서는 88.3kbit/s)의 속도로 디바이스와 통신할 수 있습니다. 단선 CAN의 다른 이름으로는 SAE-J2411, CAN A 및 GMLAN이 있습니다. 자동차의 일반적인 단선 디바이스에는 고성능이 필요하지 않습니다. 일반적인 어플리케이션에는 좌석 및 거울 조절 장치와 같은 편의성 장치가 포함됩니다.
소프트웨어 선택 가능 CAN 하드웨어
NI의 CAN 하드웨어 제품을 사용하면 어떤 온보드 트랜시버(고속, 저속/내결함성 또는 단선 CAN)라도 사용할 수 있게 소프트웨어 선택 가능 CAN 인터페이스를 구성할 수 있습니다. 다중 트랜시버 하드웨어는 여러 통신 표준의 조합이 필요한 어플리케이션을 위한 완벽한 솔루션을 제공합니다. 소프트웨어 선택 가능 CAN 하드웨어를 사용하면 맞춤 외부 CAN 트랜시버를 선택할 수도 있습니다.
LabVIEW 및 기타 언어에서의 CAN 프로그래밍
NI-XNET 소프트웨어 드라이버
NI-XNET 소프트웨어는 PCI/PXI-851x 및 NI 986x 디바이스에 포함되어 있으며 ni.com에서 무료로 다운로드할 수 있습니다. 이 새 드라이버는 Windows 및 LabVIEW Real-Time OS에서 NI LabVIEW, NI LabWindows/CVI 및 C/C++로 CAN, 로컬 상호 연결 네트워크(LIN) 및 FlexRay 어플리케이션을 개발하는 데 사용됩니다. NI-XNET 플랫폼의 일부로서 NI 851x 및 NI 986x 디바이스는 HIL(hardware-in-the-loop) 시뮬레이션, 고속 제어 프로토타이핑, 버스 모니터링, 자동화 컨트롤 등 수 백 프레임 및 신호를 리얼타임으로 고속 조작해야 어플리케이션에 적합합니다.
NI-XNET: 하나의 API, 많은 임베디드 네트워크
NI-XNET 플랫폼은 일련의 고성능 CAN, LIN, FlexRay 인터페이스를 CAN, LIN, FlexRay 프레임 및 신호를 쉽게 읽고 쓸 수 있도록 하는 NI-XNET API와 결합합니다.
프로그래밍은 적게, 성능은 최고로
NI-XNET 인터페이스는 하위 레벨 마이크로컨트롤러 프로그래밍의 성능과 Windows 및 LabVIEW Real-Time OS 개발의 속도 및 성능을 결합합니다. 특허 출원된 NI-XNET 디바이스 중심 DMA 엔진을 사용하면, PC 기반 CAN 인터페이스의 공통적인 문제인 시스템 지연을 밀리초에서 마이크로초 단위로 줄일 수 있습니다. 이 엔진은 온보드 프로세서를 구동하여 CPU 인터럽트 없이 인터페이스와 사용자 프로그램간 CAN 프레임과 신호를 이동하도록 하므로, 호스트 프로세서가 복잡한 모델 및 어플리케이션을 처리하는 데 시간을 더 할애할 수 있습니다.
NI-CAN 소프트웨어 드라이버
NI에는 모든 NI 레거시 CAN 인터페이스를 다루는 NI-CAN 드라이버 소프트웨어가 포함되어 있습니다. 다른 CAN 인터페이스를 사용하면 턴키 소프트웨어 도구를 구입하지 않으면 보드 기능의 일부만 활용할 수 있습니다. 그러나 모든 NI CAN 보드 기능은 완전히 노출되어 있으므로 선택한 프로그래밍 언어로 사용자 정의 어플리케이션을 개발할 수 있습니다.
NI-CAN 드라이버는 높은 레벨의 사용하기 쉬운 기능을 제공하여 전체 CAN 어플리케이션을 신속하게 개발하여 시간과 비용을 절약할 수 있도록 합니다.
NI-CAN 드라이버 소프트웨어는 두 가지 API를 제공합니다. 프레임 API는 CAN 프로그래밍을 위한 기존 API입니다. 프레임 API에서는 원시 데이터 바이트를 포함하는 CAN 프레임을 송수신할 수 있습니다. 사용자 프로그램은 확장된 엔지니어링 단위를 제공할 수 있도록 이러한 바이트를 구문 분석하고 확장해야 합니다.
NI는 NI-CAN 2.0 드라이버 소프트웨어에서 채널 API를 처음 도입했습니다. 데이터베이스 파일(.dbc 또는 .ncd)에 정의된 채널 이름을 사용하면 CAN 채널을 읽고 쓸 수 있습니다. 채널 API는 다음과 같은 장점을 제공합니다:
- 상위 레벨 프로그래밍
- 사용하기 쉬운 물리 단위
- 손쉬운 CAN/데이터 수집 동기화가 주 용도
- 벡터 데이터베이스 파일 통합 기능
CAN 프로토콜 용어
CAN 디바이스는 프레임이라고 하는 패킷으로 CAN 네트워크를 통해 데이터를 보냅니다. CAN 프레임은 다음 섹션으로 구성됩니다.
- CAN 프레임 --전체 CAN 전송: 중재 ID, 데이터 바이트, 승인 비트 등. 프레임은 메시지라고도 불립니다.
그림 2. 표준 CAN 프레임 포맷.
- SOF(start-of-frame) 비트 – 도미넌트(논리 0) 비트로 메시지의 시작을 나타냅니다.
- 중재 ID – 메시지를 식별하고 메시지의 우선순위를 나타냅니다. 프레임은 11비트 중재 ID를 사용하는 기본과 29비트 중재 ID를 사용하는 확장의 두 가지 형식으로 제공됩니다.
- IDE (식별자 확장) 비트 – 기본 프레임과 확장 프레임을 구분할 수 있게 합니다.
- RTR (원격 전송 요청) 비트 – 원격 프레임과 데이터 프레임을 차별화하는데 사용됩니다. 도미넌트(논리 0) RTR 비트는 데이터 프레임을 나타냅니다. 열성(논리 1) RTR 비트는 원격 프레임을 나타냅니다.
- DLC (데이터 길이 코드) – 데이터 필드에 포함된 바이트 수를 나타냅니다.
- 데이터 필드 – 0 – 8바이트의 데이터를 포함합니다.
- CRC (순환 중복 검사) – 15비트 순환 중복 검사 코드와 열성 구분자 비트를 포함합니다. CRC 필드는 에러 감지에 사용됩니다.
- ACK (접수 통지) 슬롯 – 메시지를 올바르게 수신한 모든 CAN 컨트롤러는 메시지 끝에 ACK 비트를 보냅니다. 전송 노드는 버스에 ACK 비트가 있는지 확인하고 없으면 전송을 다시 시도합니다. NI 시리즈 2 CAN 인터페이스에는 수신 전용 모드 기능이 있습니다. 여기에서는 모니터링 하드웨어에 의한 ACK 비트의 전송이 버스의 동작에 영향을 미치는 것을 방지하기 위해 억제됩니다.
- CAN 신호 – CAN 프레임 데이터 필드에 포함된 개별 데이터 조각. CAN 신호를 채널이라고 부를 수도 있습니다. 데이터 필드는 최대 8바이트의 데이터를 포함할 수 있기 때문에 단일 CAN 프레임은 0–64개의 개별 신호를 포함할 수 있습니다(64개 채널의 경우 모두 이진 신호).
그림 3. 신호는 CAN 프레임 내부의 특정 비트 수로 정의할 수 있습니다.
CAN 데이터베이스 파일은 CAN 프레임 및 신호 정의를 위한 변환 정보를 포함하는 텍스트 파일입니다. NI NI-XNET Database Editor 소프트웨어는 FIBEX 데이터베이스 파일(.xml), 벡터 데이터베이스 파일(*.dbc) 및 NI CAN 데이터베이스 파일(*.ncd)을 인식합니다.
각 신호에 대해 CAN 데이터베이스는 공학 단위로 변환하기 위한 규칙을 정의합니다.
데이터베이스에 저장되는 데이터는 다음과 같습니다.
- 채널 이름
- 메시지 내의 채널 위치(시작 비트)와 크기(비트 수)
- 바이트 순서 (인텔/모토롤라)
- 데이터 유형 (signed/unsigned/IEEE float)
- 변환 및 단위 문자열
- 범위
- 기본값
- 주석
이 정보를 사용하면 "원시" 프레임 정보(일반적으로 바이트)를 "실제" 값으로 쉽게 변환할 수 있습니다. 아래 그림은 이러한 변환의 예를 보여줍니다.
그림 4. 필요한 모든 변환 데이터는 프레임을 신호로 변환하기 위한 데이터베이스에 포함됩니다.
CAN 데이터베이스 파일에는 전체 차량에 대한 프레임 및 신호 정의가 포함될 수 있습니다. 모든 네트워크는 고유한 데이터베이스 파일을 갖습니다. 또한 이러한 데이터베이스 파일은 공급업체에 따라 다르며 일반적으로 기밀입니다.
여러 CAN API(NI-XNET 등)는 CAN 네트워크에서 데이터베이스 파일을 사용하여 여러 프레임 정보를 실제값으로 직접 자동 변환할 수 있습니다. 따라서 원시 프레임 값을 신경 쓸 필요가 없어 어플리케이션 개발이 간단해집니다.
CAN 통신 작동 방식
앞서 언급했듯이 CAN은 피어 투 피어(P2P) 네트워크입니다. 이것은 개별 노드가 CAN 버스에서 데이터를 읽고 쓸 수 있는 시기를 제어하는 마스터가 없음을 의미합니다. CAN 노드는 데이터를 전송할 준비가 되면 버스가 사용 중인지 확인한 다음 단순히 네트워크에 CAN 프레임을 씁니다. 전송되는 CAN 프레임에는 전송 노드나 의도한 수신 노드의 주소가 포함되어 있지 않습니다. 대신 네트워크 전체에서 고유한 중재 ID가 프레임을 식별합니다. CAN 네트워크의 모든 노드가 해당 CAN 프레임을 수신하고, 전송된 프레임의 중재 ID에 따라 네트워크의 각 CAN 노드는 프레임 수락 여부를 결정합니다.
여러 노드가 동시에 CAN 버스에 메시지를 전송하려고 하면 가장 높은 우선순위(가장 낮은 중재 ID)를 가진 노드가 자동으로 버스 접근 권한을 얻습니다. 우선순위가 낮은 노드는 다시 전송을 시도하기 전에 버스를 사용할 수 있을 때까지 기다려야 합니다. 이러한 방식을 통해 CAN 네트워크로 CAN 노드 간의 결정성 있는 통신을 보장할 수 있습니다.
그림 5. CAN에는 충돌을 피할 수 있도록 메시지에 대한 기본 우선순위를 제공합니다.
NI는 CAN 어플리케이션 개발을 위한 다양한 하드웨어 및 소프트웨어 도구를 제공합니다. NI는 PCI, PXI, USB, cRIO 및 CompactDAQ(C 시리즈)을 포함한 다양한 플랫폼을 위한 CAN 인터페이스를 제공합니다. PCI, PXI 및 C 시리즈의 경우 고속/FD, 저속/내결함성 및 단선 물리 계층 중에서 선택할 수 있습니다.
PCI 및 PXI를 위해 NI는 업계 최초의 고속/FD, 저속/내결함성 및 단선 트랜시버 포함 소프트웨어 선택 가능 CAN 인터페이스를 단일 디바이스에서 모든 보드, 모든 포트에 대해 제공합니다.
즉, 소프트웨어에서 사용하려는 모드를 간단히 선택할 수 있다는 뜻입니다.
'데이터계측분석 > 데이터통신 기술자료' 카테고리의 다른 글
| 데이터통신을 위한 적합한 네트워킹 프로토콜 선정방법 (0) | 2023.02.28 |
|---|---|
| LabVIEW에서 OPC 사용하기 (0) | 2023.02.22 |
| LIN 통신의 이해 (0) | 2023.02.10 |
| 랩뷰를 이용한 모드버스 통신 (0) | 2023.02.09 |
| 랩뷰를 이용한 제어 및 모니터링 어플리케이션의 네트워크 통신 (0) | 2023.02.09 |