IoT 애플리케이션의 유무선 네트워크에 잘 알려진 통신 프로토콜을 사용하는 것이 중요한 요구사항이 되고 있다. CAN은 널리 보급된 성숙한 단계의 유선 네트워킹 솔루션이다. CAN의 견고성, 신뢰성, 안정성은 IoT를 위한 핵심적인 특징이다

CAN 프로토콜 개발은 1983년에 시작됐다[1]. 1986년 SAE(Society of Automotive Engineers)는 미시간 주 디트로이트에서 이 프로토콜을 공식 발표했다. 최초의 CAN 컨트롤러 디바이스는 1987년에 등장했다. 독일의 로버트 보쉬(Robert Bosch GmbH)는 1991년 CAN 2.0 사양을 발표했다[2].

CAN 프로토콜은 1993년 ISO가 11898-1 표준을 공표하면서 국제적인 사양으로 발전했으며, 이후 1995년과 2003년에 업그레이드됐다[3]. 보쉬는 2012년 CAN 데이터 링크 계층 프로토콜(CAN FD)을 개선했으며, 개선판은 ISO 11898-1에 추가되어 2014년에 공표되었다.

CAN은 자동차 애플리케이션의 차량내 전자 네트워킹을 위해 만들어졌다.

현재는 이러한 차량 내의 여러 네트워크 단계에서 도어 장치나 브레이크 컨트롤러, 탑승자수 계산 장치 등을 연결하는 데 사용된다.

지난 20년 동안 다른 엔지니어링 분야에서 다양한 애플리케이션을 위해 CAN프로토콜을 도입한 데는 CAN이 가진 신뢰성이 핵심적인 이유로 작용했다.

CAN은 항공기에서 비행 상태 센서, 항법 시스템, 기타 조종석 계기 등의 애플리케이션에 사용된다. 또한 CAN 버스는 기내 데이터 분석부터 연료 시스템, 펌프, 리니어 액추에이터와 같은 항공기 엔진 제어 시스템에 이르기까지 많은 항공우주 애플리케이션에 사용된다. 노면전차(streetcar), 트램, 지하철, 경전철, 장거리 열차와 같은 철도 애플리케이션에서도 CAN이 사용된다.

의료장비 제조업체들은 의료 기기의 임베디드 네트워크로 CAN을 사용한다.

병원은 CAN을 사용하여 전체 수술실을 관리한다. 즉 CAN 기반 시스템으로 조명, 테이블, 카메라, X-레이 장비, 환자 침대를 제어한다. 또한 CAN은 실험실 장비, 운동 경기 카메라, 자동문, 커피자판기에 이르기까지 비산업 애플리케이션에도 사용된다[4].

CAN 기술 개요

오늘날 자동차는 다양한 서브시스템을 위한 수십 가지의 ECU(전자제어장치)를 탑재한다. 이 중에서 비교적 복잡한 프로세서는 보통 ECM(엔진 제어 모듈) 또는 PCM(파워트레인 제어 모듈)이라고도 하는 엔진 제어 장치다. 그 외에 트랜스미션, 에어백, ABS(앤티록 브레이크), 크루즈 제어, EPS(전동 파워 스티어링), 오디오 시스템, 윈도우 리프트, 도어 잠금, 미러 및 시트 조절, 하이브리드/전기차용 배터리 및 충전 시스템 등에 사용되는 프로세서가 있다.

이러한 프로세서중 일부는 독립적인 서브시스템을 구성하지만 이러한 서브시스템 간에는 반드시 통신이 필요하다[4]. 서브시스템은 보통 액추에이터를 제어하거나 센서에서 피드백을 수신해야 한다. CAN 표준은 이 요구사항을 충족하고 모든 ECU 모듈간의 배선을 줄이기 위한 목적으로 만들어졌다(그림 1 참조).

각 CAN 노드는 메시지를 송수신할 수 있지만 송신과 수신을 동시에 할 수는 없다. 메시지는 메시지의 의미와 우선순위를 식별하는 ID(식별자), 최대 8바이트의 데이터로 구성된다. 개선된 CAN(CAN FD)은 데이터 섹션의 길이를 프레임당 최대 64바이트까지 확장한다[5]. 메시지는 버스로 직렬로 전송된다. 전송된 신호 패턴은 NRZ(Non-Return-to-Zero)로 인코딩되어 모든 노드에서 감지된다.

CAN 기반 통신 네트워크가 제공하는 기능[1, 6]:

? 멀티마스터 기능: 버스가 유휴상태인 경우 모든 CAN 노드는 메시지를 보낼 수 있다.
? 브로드캐스트 통신: 전송된 모든 메시지는 모든 노드에서 수신된다. 수신 노드는 ID 필터링 기준에 따라 메시지의 관련성 여부를 판단한다.
? 정교한 오류 감지 및 결함 격리 메커니즘과 문제가 발생한 메시지의 재전송: 이로써 데이터 무결성과 일관성이 보장된다.
? 비파괴성 버스 중재: 두 개 이상의 CAN 노드가 동시에 메시지 전송을 요청하는 경우 우선순위가 가장 높은 메시지가 즉시 버스 액세스 권한을 획득하도록 프로토콜이 보장한다.

CAN 네트워크로 연결되는 디바이스는 일반적으로 센서, 액추에이터 및 기타 제어 장치다. 이러한 장치는 CAN 네트워크에서 상호 운용되면서 일반적인 명령 및 상태, 액추에이터 명령, 센서노드에서 캡처된 센서 데이터를 교환하거나, 애플리케이션 환경 전반에 걸쳐 데이터를 수집할 수 있는 다른 노드에 정보를 요청한다. 이러한 장치는 버스에 직접 연결되지 않고 로컬 호스트 프로세서, CAN 컨트롤러, CAN 트랜시버를 통해 연결되기도 한다[6].

전형적인 CAN 프레임의 경우 40m 미만의 네트워크 거리에서 최대 1 Mbit/s의 전송속도가 가능하다. 전송속도를 낮추면 네트워크 거리를 늘릴 수 있다 (예: 125 kbit/s에서 500 m)[6]. 현재 구축 중인 CAN FD 기능은 데이터 섹션의 속도를 최대 8 Mbit/s로 높여준다[5].

CAN 메시지 형식

CAN 디바이스는 프레임이라는 패킷으로 CAN 네트워크에서 데이터를 전송한다. 그림 2의 전형적인 CAN 확장(CAN Extended) 형식의 CAN 프레임(또는 메시지) 예는 다음과 같은 비트필드로 구성된다[3, 5, 6].

? SOF(프레임 시작) 비트-주도적(로직 0) 비트가 있는 메시지의 시작을 나타낸다.
? 중재 ID-메시지를 식별하고 메시지의 우선순위를 나타낸다. 11비트 표준 또는 29비트 확장 ID.
? 제어 비트-IDE(식별자 확장), RTR(원격 전송 요청), FDF(CAN FD 선택), DLC(데이터 길이 코드).
? 데이터 필드-전형적인 CAN 프레임의 경우 0~8바이트 데이터, CAN FD 프레임의 경우 0~64바이트 데이터로 구성된다.
? CRC(순환 중복 검사)-순환 중복 검사 코드와 열성 구획 비트로 구성된다. CRC 필드는 오류 감지에 사용된다.
? ACK(확인) 슬롯-메시지를 올바르게 수신하는 모든 CAN 컨트롤러는 메시지 끝에 ACK 비트를 전송한다.

CAN 네트워크의 각 노드에는 자체 클록이 있으며 데이터 전송 중 클록은 전송되지 않는다. 네트워크 자체는 모든 노드에서 공유되는 특정 전송속도에 맞춰 구성된다. 그러나 각 노드는 예상 전송속도에 따라 시간 단위로 사용되어 공칭 비트 시간을 정의하는 로컬 클록에서 파생되는 Tq(시간 할당량)를 정의한다. 동기화는 프레임의 각 비트를 세그먼트 수로 나누는 방식으로 수행된다(동기화, 전달, 위상 1 및 위상 2). 각 세그먼트의 길이는 네트워크 및 전송속도 요구사항을 기반으로 조절 가능하다. 샘플 포인트는 위상 세그먼트 1과 위상 세그먼트 2 사이에 위치한다. 동기화 규칙은 CAN 프로토콜 표준에 상세하게 명시된다[3].

그림 3에는 CAN 비트당 시간 할당량이 10인 예제 CAN 비트 타이밍이 나와 있다.

FlexCAN CAN 컨트롤러

그림 4에는 여기서 사례연구로 사용되는 FlexCAN, CAN 컨트롤러 IP 블록[7]이 나와 있다. 이는 프로세서를 호스트하기 위한 CAN 트랜시버와의 인터페이스에 필요한 모든 리소스의 디지털 구현이다.

PE(프로토콜 엔진) 하위 블록은 CAN트랜시버 인터페이스에서 직렬 형식으로 CAN 메시지를 수신한다. PE는 CAN 프로토콜 규칙에 따라 메시지를 검증하고 수신 및 송신 프로세스에 대한 CAN 비트 타이밍을 제어하고 다양한 비트 필드에서 발견되는 오류를 감지하여 드러낸다(예: 비트 스터프 오류, 폼 오류, CRC 오류, 수신 중 ACK 오류, 송신 중 비트 오류). CAN 메시지의 다양한 비트 필드를 디코딩하며 메시지 조각을 CHI(컨트롤러 호스트 인터페이스) 하위 블록으로 전송한다. 또한 CHI에서 메시지 조각을 수신하고 완전한 메시지를 조합하여 이를 올바른 메시지 형식에 따라 CAN 트랜시버로 직렬 전송한다.

로컬 RAM 메모리는 각각 고정 바이트수로 구성되어 ID 비트, 일부 제어 비트, 시간 스탬프와 데이터 바이트를 저장하는 MB(메일박스)라고 하는 여러 가지 특정 데이터 구조로 체계화된다. 각 MB는 RxMB(수신 메일박스) 또는 TxMB(송신 메일박스)로 구성될 수 있다.

CHI 하위 블록은 수신되는 메시지의 ID 비트를 RxMB에 위치한 대상 ID와 비교하여 해당 메시지를 검사한다.

RxMB로 구성된 모든 MB는 스캔되며, ID가 수신된 메시지의 ID와 일치하는 경우 수신 메시지는 나중에 호스트 프로세서에서 처리하기 위해 선택한 RxMB에 저장된다. 또한 CHI는 정기적으로 송신용으로 구성된 TxMB 목록을 스캔하여 CAN 송신 우선순위가 가장높은 ID를 검색하여 선정된 TxMB 콘텐트를 PE 하위 블록으로 전송한다.

CHI는 부가적으로 호스트 프로세서에 버스 인터페이스를 구현하여 호스트에서 제어 정보를 받는다(CAN 비트 시간 구성, 내부 프로세스를 위한 제어 비트 등). 또한 성공적인 메시지 수신 또는 송신이 발생한 경우 호스트에 인터럽트를 생성하고 통신이 진행되는 동안처리 및 오류 상태를 보고한다.

IoT 애플리케이션의 CAN

IoT는 인터넷을 통해 제어 및 데이터를 주고받는 디바이스 네트워크다. 이러한 디바이스에는 내부 상태 또는 외부 환경과 상호작용하기 위한 임베디드처리 기능이 포함돼 있다. 이러한 아키텍처는 복잡한 시스템에서 상호 연결된 디바이스의 원격 모니터링 또는 제어를 위한 잠재력을 지녔다[8].

IoT는 제조공장, 에너지 그리드, 의료시설, 운송 시스템과 같은 새로운 장소를 인터넷에 연결하며, 이로써 어디서나 이러한 모든 장소를 제어할 수 있다. 이와 같은 연결은, 즉 더 많은 장소에서 더많은 데이터가 수집되고, 효율성을 높이고, 안전과 보안을 개선하기 위한 방법이 더 많아짐을 의미한다. 사물, 동물 또는 사람들에게 고유한 식별자가 부여되며 사람 대 사람 또는 사람 대 컴퓨터의 상호작용 없이 네트워크를 통해 자동으로 데이터를 전송하는 능력이 주어진다.

여기서 사물에는 심장 모니터를 이식한 사람, 바이오칩 응답기를 단 가축, 타이어 압력이 낮은 경우 운전자에게 경고하는 센서를 내장한 자동차, 또는 IP 주소를 받고 네트워크를 통해 데이터를 전송하는 기능을 갖춘 기타 모든 자연물 또는 인공물이 포함된다. 지금까지 IoT는 제조 및 전력, 석유, 가스 설비의 M2M통신과 밀접하게 관련돼 있었다.

IoT가 부상하면서 네트워킹에 새로운 디바이스 유형과 새로운 위치가 추가되고 있다. 네트워크는 극한 기후와 온도 조건에서도 사람과 사물을 안정적으로, 안전하게 연결해야 한다. 또한 이러한 네트워크는 크기와 무게, 전력 측면에서 제약이 있는 디바이스에 위치에 관계없이, 어떤 조건에서도 단절 없는 연결을 제공해야 한다[9].

그런 의미에서 IoT 애플리케이션의 유무선 네트워크에 잘 알려진 통신 프로토콜을 사용하는 것이 중요한 요구사항이 되고 있다. CAN은 현재 널리 보급된 성숙한 단계의 유선 네트워킹 솔루션이다. CAN의 견고성, 신뢰성, 안정성은 IoT를 위한 핵심적인 특징이다.

기존 CAN 사용을 기반으로 하는 CAN 컨트롤러는 항상 최대 버스 대역폭에 가깝게 통신하며 지속적으로 동작하도록 만들어졌다. 노드에는 상시 전력이 공급되거나 버스에서 전원이 차단된다. 그 반대의 경우에 있는 IoT 애플리케이션은 다수의 네트워크 노드 사이에서 드물게 통신하며 여기서는 전력소비가 중요한 전제 조건이 될 것이다.

향상된 재가동 기능

그림 5는 저전력 모드에서 특정 메시지 수신 시 선택적 가동(wake up)을 위한 프리텐디드 네트워킹(Pretended Networking, PN)[10]이라는 새로운 기능을 추가하기 위해 원래의 FlexCAN CAN컨트롤러에 구현된 수정 사항을 보여준다. ECU와 CHI 하위 블록의 리소스 대부분이 저전력 모드에 있을 때, 즉 클록이 게이팅되어 기능을 줄이고 전력을 절감할 때 프로토콜 엔진 하위 블록이 메시지 비교를 위한 추가 기능을 포함하도록 확장된다. 초기 솔루션은 선택성 없이 모든 버스에서 버스 활동 감지를 기반으로 재가동하는 방법을 사용했다.

이 기술을 사용하면 특정 기능과 관련이 없는 메시지가 수신되더라도 모든 ECU가 재가동되며, ECU를 가동하기 위한 긴 부팅 시간으로 인해 호스트 프로세서가 메시지를 캡처해 처리하기까지 시간이 지연된다.

PIN은 CAN 네트워크의 다양한 노드에 설치된 애플리케이션이 최대한 오래 ECU를 저전력 모드로 둘 수 있도록 하는 접근방법을 제공한다. 모든 ECU는 각각의 인터럽트가 전달되는 즉시 PN하위 블록에서 비교되는 특정 CAN 메시지를 통해 선택적으로 재가동이 가능하다. ECU 부팅 시간에 따르는 단점이 없다. 또한 재가동 메시지는 CAN 모듈내에 저장되므로 재가동 소스를 식별가능하고 각각의 데이터는 ECU가 정상작동을 재개한 후 사용할 수 있다.

기존 CAN 컨트롤러에 PN 기능이 추가되면 여러 스마트 노드(센서와 액추에이터 모두)로 구성된 대규모 네트워크의 구축이 가능하다. 노드를 대기 또는 저전력 모드로 두었다가 마스터 노드 또는 중요한 정보를 가진 노드를 통해 선택적 재가동 메시지를 전달함으로써 적시에 재가동하여 필요한 정보를 전체 네트워크에 전송하거나 네트워크에서 명령 또는 특정 정보를 수신할 수 있다[11, 12].

그림 6은 대다수 노드를 저전력 모드(회색 상자)의 비활성 상태로 유지하면서 활성 노드(흰색 상자) 사이에 정보를 교환하는 네트워크의 예를 보여준다. 노드 1이 노드 5와 9(그림 6.a)를 재가동하면 메시지 교환을 시작하고(그림 6.b) 이후 다시 저전력 모드로 돌아간다.



IoT는 원격 액세스 및 제어라는 본연의 장점으로 인해 일반적으로 무선 네트워크와 연계된다. 그러나 CAN은 배선 토폴로지를 간소화했으며 프로토콜의 견고함은 일부 애플리케이션에서 유용하다.

CAN은 견고성, 신뢰성, 안정성이 핵심 요소인 자동차 애플리케이션에서 광범위하게 사용되는 성숙한 통신 기술이다. 30년 가까운 기간 동안 자동차 및 기타 환경에서 사용과 테스트를 거쳤다.

CAN 프로토콜은 멀티마스터이므로 모든 노드가 마스터 노드와 무관하게 독립적으로 통신을 시작할 수 있다. ID는 노드 주소가 아닌 메시지 유형을 나타낸다. 우선순위가 높은 메시지가 먼저 전송된다. 전송된 메시지는 모든 노드에 도달하지만 해당되는 특정 ID로 구성된 노드에만 수신된다. 통신 오류는 감지되어 로깅되므로 지엽적 또는 전역적으로 관리가 가능하다. 실패한 메시지는 자동으로 다시 전송된다. 데이터 충돌은 CAN 프로토콜에 의해 자동으로 관리된다. 이러한 모든 특성에 프리텐디드 네트워킹 기능을 통한 선택적 재가동까지 결합되면서 CAN은 IoT 애플리케이션의 유선 통신을 위한 충분한 기술이 됐다.


참/고/문/헌
1] CAN in Automation (CiA), “Controller Area Network (CAN)”http://www.can-cia.org/index.php?id=systemdesign-can
[2] -,- “Bosch Controller Area Network (CAN) version 2.0”
http://www.freescale.com/files/microcontrollers/doc/data_sheet/BC ANPSV2.pdf
[3] ISO - International Standardization Organization, “ISO 11898-1 Road vehicles - Controller area network (CAN) -Part 1:
Data link layer and physical signaling”, http://www.iso.org/iso/iso_catalogue.htm.
[4] National Instruments Corporation, “Controller Area Netwokr (CAN) Overview”, Nov 2011, white paper available in:
http://www.ni.com/white-paper/2732/en/
[5] Robert Bosch GmbH, “CAN with Flexible Data-Rate Specification Version 1.0”, April, 2012, available in:
http://www.bosch- semiconductors.de/media/pdf_1/canliteratur/can_fd_spec.pdf
[6] K. Etschberger , “Controller Area Network”, IXXAT Press,Germany, 2001 - ISBN 3-00-007376-0
[7] D. Peterson, “MPC5510 New FlexCAN Module Features”, Application Note AN3488, June 2007, Freescale Semiconductor,
Inc, available in: http://cache.freescale.com/files/32bit/doc/app_note/AN3488.pdf?&P arent_nodeId=&Parent_pageType=
[8] K. Kaivan, G. Atkinson, “What the Internet of Things (Io)T Needs to Become a Reality”, white paper available in:
http://www.freescale.com/files/32bit/doc/white_paper/INTOTHNGS WP.pdf
[9] Cisco Systems, Inc, “Internet of Things Overview”, available in: http://www.cisco.com/web/solutions/trends/iot/embedded.html
[10] M. Hell, U. Kelling, “Power Saving in CAN Applications”,Porceedings of the 13th iCC, pp. 02-9, Germany, 2012 ,available in:
http://www.can-cia.org/?id=1495
[11] F. H. Behrens, P. E. Domingues, M. Marinho and J. A. M. Hlaonda,
“Handling of Wake-Up Messages in Controller Area Networks”, paetnt number US20130318380A1
[12] Freescale Semiconductor, Inc, “Future Advances in Body Electronics”, March 2013, white paper available in:
http://cache.freescale.com/files/automotive/doc/white_paper/BODY DELECTRWP.pdf?&Parent_nodeId=&Parent_pageType=