CAN은 ECU 간 통신을 담당하고 있는 버스 시스템으로 오늘날 운행되는 대부분 차량에서 널리 사용되고 있다. 그러나 통신 수요가 더욱 증가하면서 점차 차량 제조업체들은 CAN을 이용한 차량 네트워크에 대한 한계에 직면하고 있다. Ethernet과 CAN FD는 더 넓은 대역폭을 제공하고 기존 버스 시스템의 일부 작업을 대체하고 있다. 넓은 대역폭 외에도, Ethernet과 CAN FD는 새로운 통신 패러다임 도입에도 적합하다.

원문│Automobil Elektronik, 2015년 7/8월호

기존의 CAN 메시지는 한번에 최대 8바이트의 페이로드 데이터를 전송한다. 효율적으로 페이로드 데이터와 프로토콜 오버헤드 간의 최적 비율을 유지하기 위해서는 8바이트를 모두 사용하는 것이 유리하다. 그러나 차량 바퀴 속도 등과 같이 개별적인 데이터 요소(신호)는 보통 그 길이가 8바이트에 미치지 못하기 때문에 몇몇 신호와 함께 전송된다. 효율적인 사용을 위해 각 CAN 메시지 안에 여러 신호들을 정의하는 작업은 매우 복잡하다.

통신 매트릭스는 데이터베이스에서 정의된다. CAN의 경우 DBC나 FIBEX, 또는 AUTOSAR 시스템 디스크립션 중 한가지를 이용해 정의할 수 있다. 데이터베이스(그림 1)에는 메시지 및 그 구성요소 뿐만 아니라 연관된 송수신 관계도도 함께 포함돼 있다.
그 밖에도 데이터베이스에는 신호와 메시지 사이의 추상화 계층인 프로토콜 데이터 유닛(Protocol Data Units, PDU)이 정의돼 있다.

CAN FD, 향상된 CAN 버스

CAN 버스의 최대 전송 속도인 1Mbps는 오늘날의 통신 수요를 맞추기에 턱없이 부족하다. 이러한 대역폭 문제를 위한 해결책 중 하나는 가변 데이터 전송 속도를 갖춘 CAN(CAN FD)을 이용하는 것이다. 향상된 CAN 프로토콜은 최대 8 Mbps의 전송속도를 지원한다. 이는 기존의 CAN에 비해 다음과 같이 두 가지 기능이 개선됐다.

1. 페이로드 데이터 바이트가 더 높은 비트 전송 속도로 전송된다. 최대 케이블 길이 등과 같은 CAN의 다른 특성들을 가급적 동일하게 유지하기 위해 CAN 메시지의 헤더와 트레일러는 정상적인 비트 전송 속도로 전송된다.
2. CAN FD 메시지에는 한 번에 최대 길이가 64바이트인 페이로드 데이터가 포함된다. 8배 빠른 비트 전송 속도가 사용되고 64바이트인 페이로드 데이터가 전송되면, 전송 시간은 8바이트인 페이로드 데이터를 전송하는 기존의 CAN 메시지와 비슷하다.

CAN FD 이용 시, 앞서 언급한 바 있는 통신 매트릭스의 복잡성도 많이 증가한다. 최대 8배 증가된 메시지에서 효율적인 통신을 위해 네트워크 설계자는 반드시 신호들을 논리적으로 그룹화시켜야 한다. 또한 일부 시나리오에서는 사전에 CAN 용으로 정의한 PDU를 CAN FD에서도 사용할 수 있도록 요구한다. 이 경우 더 긴 길이의 페이로드 데이터의 장점이 없어져 하나의 메시지로 다수의 PDU를 전송할 수 있는 n-PDU-프레임 매핑(n-PDU-to-frame mapping)을 이용한다.

게이트웨이를 이용한 시나리오에서 n-PDU-프레임 매핑을 사용한 예

게이트웨이 시나리오(그림 2)에서, 기존 CAN 버스의 대역폭은 더 이상 충분하지 않다. 여기서 3개의 CAN 버스가 하나의 게이트웨이로 연결돼 있고, 모든 버스는 이미 버스 로드의 한계(load limit) 상태로 운영되고 있다고 가정해 보자. CAN 버스 3에는 나머지 두 버스로 전송되는 데이터 대부분을 이용하고 있는 ECU가 부착돼 있다.

이 게이트웨이는 필요한 데이터를 ECU로 라우팅시키는 역할을 한다. 만약, 장치의 세대 변화로 인해 CAN 버스 3에 부착된 ECU가 추가적인 통신 메시지가 필요할 경우 CAN 버스 3의 대역폭은 더 이상 충분하지 않다. 그러므로 CAN FD가 대신 사용돼야 한다. 또한, 이밖에도 다음과 같은 추가 요구사항이 있다.

- 효율적인 버스 이용을 위해 길이가 64바이트인 페이로드 데이터 이용
- 사전에 정의된 PDU는 변경 불가
- 게이트웨이를 더 복잡하게 만들 수 없음

이러한 요구사항을 충족하기 위해서는 게이트웨이를 통해 하나의 CAN FD 메시지로 사전에 정의된 다수의 CAN PDU를 전송해야 한다.
지금까지 메시지의 내용은 각각의 CAN 식별자(CAN ID)를 통해 식별해왔다.

하지만 CAN FD 메시지 하나에 다수의 PDU가 포함되기 때문에, 수신기는 더 이상 데이터 식별용 CAN ID를 사용할 수 없다. 한 가지 가능한 해결책은 CAN FD 메시지의 내용을 데이터베이스에서 고정으로 정의하는 것이다. n-PDU-프레임 매핑을 사용하는 경우 와는 반대로 이 데이터베이스는 CAN FD 메시지 내에 잠재적으로 포함될 수 있는 PDU를 정의한다. ECU가 실제 보내는 PDU는 런타임 도중에 선택된다.

이에 대한 시나리오는 그림 2에 도식으로 설명했다. CAN 버스1과 CAN 버스 2상의 각각의 ECU와 게이트웨이 자체는 CAN FD 버스를 통해 전송하게 될 PDU를 보낸다. 게이트웨이는 메시지 전송 시간까지 CAN FD 메시지에 PDU를 채운다. 각각의 PDU 앞부분에는 작은 헤더(header)가 부착돼 있어 수신기가 메시지에서 각각의 PDU를 추출할 수 있도록 지원한다. 이를 통해 게이트웨이는 더 이상 PDU 전송 순서에 신경을 쓰지 않고, 지정된 메시지 레이아웃을 유지하는 것과 같은 복잡한 업무를 구현할 수 있다. 뿐만 아니라 게이트웨이가 필요로 하는 자원의 요구도 가능한 줄일 수 있게 됐다.
CAN FD 메시지 전송은 다음과 같은 다양한 이벤트를 통해 실행된다.

1. 메시지의 발신 버퍼가 가득 찬 경우
2. 완성 메시지에 대해 정의된 타임아웃이 만료된 경우.
3. 각 PDU에 대해 정의한 타임아웃이 만료된 후에는 PDU가 포함된 메시지가 발송
4. PDU가 발신용 버퍼에 복사된 후 즉시 메시지를 발신할 수 있는 속성을 가진 경우

하나의 메시지에 포함된 다수의 PDU를 전송하는 옵션은 AUTOSAR release 4.2.1부터 내장돼 있다. 이 메커니즘은 I-PDU 멀티플렉서(Multiplexer) 모듈에서 네트워크 종류에 상관없이 사용할 수 있기 때문에, CAN FD 이외에도 예를 들어 FlexRay나 Ethernet에서도 사용할 수 있다.

이 모듈은 단순히 PDU를 모으는 역할 이외에도 다양한 전송 조건 및 두 개의 상이한 PDU 헤더 포맷도 지원하고 있다. CAN FD와 FlexRay의 경우 4바이트의 헤더가 주로 이용되며, Ethernet의 경우 8바이트의 헤더가 일반적으로 이용된다.

훨씬 큰 페이로드 데이터 길이제공하는 Ethernet

CAN과 비교할 때, Ethernet은 최대 페이로드의 데이터 길이가 185배나 된다.
1,500바이트의 PDU 안에 수천 개의 신호를 삽입하는 기존의 정의는 실제로 현실성이 없다. 그러나 게이트웨이용으로 사용하는 경우 기존의 CAN 또는 FlexRay의 PDU를 Ethernet의 PDU와 1:1로 전송할 때 유리할 수 있다. CAN FD처럼 하나의 메시지에 다수의 PDU를 포함해 전송하는 작업은 Ethernet에서도 변경 없이 사용할 수 있다. CAN FD와 FlexRay와는 대조적으로, AUTOSAR에서는 Ethernet에 대해 두 가지의 동등한 접근 방식을 지정하고 있다.

첫번째 접근 방식은 CAN FD처럼 I-PDU 멀티플렉서에 내장된 n-PDU-프레임 매핑을 사용하는 것이다. 동일한 PDU 수집 알고리즘이 소켓 어댑터(Socket Adaptor) 모듈 내에 지정돼 있어 이를 통해 AUTOSAR 아키텍처의 나머지 부분과 TCP/IP 스택을 연결할 수 있다. 소켓 어댑터 사용시, Ethernet 기반의 통신 수단에 대한 추가적인 제어가 가능하다.

Ethernet과 다른 네트워크 토폴로지(network topology)

페이로드 데이터 길이 이외에 도, Ethernet은 네트워크 토폴로지 및 주소 지정(addressing) 측면에서 다른 네트워크 기술과 상당히 다르다(그림 3). CAN은 기존의 버스 토폴로지(bus topology)를 이용하는 반면, FlexRay는 스타 토폴로지(star topology)를 이용해 물리적으로 구현되는데, 논리적 관점에서 볼 때 이 또한 버스와 같은 방식으로 구현된다. 이 두 네트워크 기술 모두 노드(node)로 메시지를 발송한다.

각각의 네트워크 노드는 메시지가 노드에 적합한지, 그리고 이를 추가로 처리를 할 것인지에 대해 독립적으로 결정한다. 이러한 작업은 CAN의 경우 CAN ID를 통해, FlexRay의 경우 Slot ID를 통해 이뤄진다. 두 경우 모두 ID는 메시지의 내용을 분류하는 데 사용된다. 하나의 메시지를 단지 한 대의 수신기로 선별적으로 발신할 수 있는 옵션은 없다.

따라서 CAN과 FlexRay는 전파 매체이다. Ethernet 또한 초기에는 일종의 버스 시스템이었다. Ethernet용 케이블로는 동축 케이블과 T 소자(T-element)가 사용됐다. 오늘날 대부분의 경우 Ethernet은 점 대 점(point-to-point) 접속 방식을 통해 충돌을 방지하고 트리 토폴로지(tree topology)를 이용한 능동적 교환(actively switched) 네트워크 방식이다.

모든 Ethernet 노드는 MAC 주소를 보유하고 있으며, 이 주소는 네트워크 내의 고유한 주소 지정(addressing) 작업에 사용된다. 자신의 MAC 주소가 수신지로 지정되면 노드는 메시지를 처리한다. 다시 말해, 발신기는 수신기에 대해 알고 있어야 하며 메시지 안에 해당 목적지의 주소를 입력해야한다.

이러한 1:1 통신 관계는 소위 유니캐스트 주소 지정(unicast addressing)이라는 방식을 사용한다. 만약 유니캐스트 주소 지정 방식의 메시지가 모든 네트워크 노드로 발송된다 하더라도, 오직 한 대의 수신기만이 해당 패킷을 처리한다. 다른 모든 수신기는 해당 패킷을 폐기한다. 불필요하게 네트워크에 과부하가 걸리는 것을 방지하기 위해, 활성화된 네트워크 접속 장비로 스위치가 도입됐다. 스위치는 잠깐의 학습 단계를 거친 후, 주소가 지정된 목적지로 메시지를 전달한다. 이를 통해 사용자는 가용한 대역폭을 효율적으로 사용할 수 있을 뿐만 아니라, 스위치는 유니캐스트 주소 지정 메시지를 네트워크상에서 동시에 전달할 수 있다.

그림3은 스위치 두 대 로 구성된 Ethernet 네트워크의 예를 보여준다. 첫 번째 스위치는 그림 위쪽의 ECU에 있으며, 두 번째 스위치는 라벨이 붙어있지 않은 ECU에 설치돼 있다. 채색된 부분은 병렬이며 네트워크에서 간섭을 받지 않는 통신 경로이다. 모든 접속 회선은 최대 100 Mbps의 전이중(fullduplex) 데이터 전송을 지원한다. 그 결과, 100 Mbps의 대역폭은 병렬 경로의 수만큼 늘어나게 된다. Ethernet은 1:n(multicast)뿐만 아니라 1:전체(broadcast) 통신도 지원한다. 만약 이러한 주소 지정 방법을 잘 사용하지 못하면, 앞서 설명한 Ethernet의 장점을 제대로 활용할 수 없다.

유니캐스트 주소 지정 방식의 경우 네트워크상의 정보는 수신기에서 발신기로 이동한다. 발신기는 네트워크상에서 어떤 수신기가 어떤 데이터(PDU)에 관심이 있는지 알고 있어야 하며, n-PDU-프레임 매핑을 통해 메시지를 적절하게 합쳐야 한다. 동일한 PDU를 수신하는 수신기가 여러 대 있는 경우에는 해당 PDU 또는 메시지를 여러차례 발송하는 것도 가능하다. 이러한 수신기별 데이터 분기 (data fan-out)는 Socket Adaptor를 장착한 AUTOSAR에서 쉽게 구현할 수 있다.

새로운 통신 패러다임:

서비스 지향적인 통신 Ethernet의 특성뿐만 아니라 복잡한 네트워크를 융통성 있게 제어하고자 하는 차량 제조업체의 요구에 따라 자동차 산업에도 서비스 지향적인 통신이 도입됐다.

인터넷으로부터 비롯된 이 익숙한 통신 패러다임은 차량의 네트워크 분야로도 전파됐으며, Service Discovery(SD) 및 Service-oriented Middleware over Internet Protocol(SOME/IP) 등과 같이 차량용으로 최적화된 특정 프로토콜도 사용되고 있다. 지금까지 우리는
차량용 네트워크에 존재하는 발신기와 수신기에 대해 이야기를 했다. 서비스 지향적인 통신에서는 서비스를 제공하는 ECU(서버)와 이 서비스를 이용하는 ECU(클라이언트)가 존재한다.

서버는 Service Discovery 프로토콜을 이용해 런타임 시에 제공되는 서비스와 어떻게 이 서비스가 전달되는지 알려준다.
클라이언트는 나중에 자동으로 데이터를 업데이트 받기 위해 서버의 메소드를 호출(Remote Procedure Call)하거나, 서버에 가입(subcribe)한다. 후자의 경우 서버는 특정 데이터 요소를 제공하는 이벤트를 통해서 가입한 모든 클라이언트에 그 값을 발송한다. 서버의 애플리케이션은 데이터 업데이트 관련 전송을 작동(trigger)시킨다.

n-PDU-프레임 매핑을 통해 하나의 메시지에 다수의 이벤트를 포함할 수 있다. 그림4는 서비스 지향적인 통신의 두 가지 원리를 도식화해 보여준다.

메소드 호출 및 데이터 업데이트의 경우, 전송하는 데이터의 길이가 매우 다양하다.
이와 같이 다양한 데이터 길이를 지원하는 것도 SOME/IP의 주요 특징 중 하나이다. 이를 통해 구조화되고 복잡한 애플리케이션 데이터를 직렬화해, ECU의 나머지 Basic Sofware가 바이트 스트림(byte stream)의 발신 또는 수신 작업만 처리할 수 있도록 한다. 이러한 이유로 인해 더 이상 데이터베이스에서 정확한 메시지 레이아웃이 정의되지 않는다.

AUTOSAR는 SD와 SOME/IP를 전폭적으로 지원한다. SD와 SOME/IP의 플랫폼 독립성 때문에 이 프로토콜들은 AUTOSAR ECU 및 기타 플랫폼 간의 데이터 교환에도 사용된다.

더 큰 페이로드 데이터 길이로 CAN FD와 Ethernet은 새로운 데이터 전송 방식에 대한 가능성을 제시하고 있다. 또한, CAN FD와 Ethernet은 차량 제조업체 및 협력 업체에 시스템 설명서 작성 시 새로운 도전을 제기하고 있다. 하나의 CAN FD 또는 Ethernet 메시지에 다수의 PDU를 삽입하는 n-PDU-프레임 매핑은 하나의 CAN FD 또는 Ethernet 메시지에 다수의 PDU를 삽입할 수 있도록 지원한다.

그러나 Ethernet의 경우 사용자 데이터 길이의 증가뿐만 아니라, 가용한 대역폭 또한 증가했다. 더욱이, 교환 네트워크 및 이와 연관된 새로운 주소 지정 방식은 자동차 산업에 작은 혁명을 가져오고 있다. 데이터 분배를 위한 새로운 메커니즘이 필수적이다. 이를 바탕으로 서비스 지향적인 통신을 통해 데이터 교환을 보다 역동적으로 실시할 수 있다. AUTOSAR 4.2.1은 이미 제시한 메커니즘을 모두 지원해 새로운 통신 패러다임의 구현을 촉진하고 있다.

현 AUTOSAR 버전의 Basic Software 구현이 이미 가능하다. 한 예로 벡터의 개발 툴인 CANoe와 함께 출시된 MICROSAR를 활용해 CAN FD 및 Ethernet 네트워크 분석과 테스트를 간편하게 실행할 수 있다.