01

넓은 의미에서 CAN XL의 주요한 기술적 파라미터가 다음과 같이

정의되었다. 데이터 속도가 최대 10Mbit/s이고 사용자 데이터의

가변 길이 범위가 1~2,048bit인 CAN의 새 버전은 CAN XL 프레

임 내에서 완전한 Ethernet 프레임을 전송할 수도 있다. 달리 말

하면 모두 예상했듯이 CAN XL은 대체로 CAN 또는 CAN FD와 그

리고 신호 기반 통신 컨셉트와 역호환된다. 현재 이 버전은 특히

ADAS(Advanced Driver Assistance System: 첨단 운전자 보조 시

스템)와 자율 주행에 Ethernet 고성능 통신이 필요없는 경차 및 소

형차용 전자 아키텍처의 개발을 추진할 때 유용하다. CAN XL을

사용할 경우, 기존 네트워킹 컨셉트와 와이어링 하네스를 대폭 수

정하지 않고도 계속 사용할 수 있다.

CAN XL로 두 세계의 장점을 모두 활용

그럼에도 불구하고 SOME/IP(Scalable Service-Oriented Middle-

warE over IP)-SD 서비스 검색 프로세스에서 SOME/IP 미들웨어

가 핵심 요소로서 중요하기 때문에 미래에도 Ethernet을 사용한

서비스 지향적인 IP 통신 분야는 건재할 것이다. 차량 탑승 시

SOME/IP를 사용하면 공급자(데이터 소스)와 소비자(데이터 싱크)

간에 동적 링크를 설정할 수 있다. 최신 어플리케이션의 경우 데

이터나 서비스를 제공하는 주체가 누구인지는 중요하지 않다.

서비스 지향적인 통신은 또한 동적 데이터 구조도 전송한다. 예

를 들어 센서 데이터 융합 어플리케이션의 경우 전송할 데이터양

은 어플리케이션의 런타임 동안에만 생성된다. 이러한 데이터는

신호 기반 통신의 일반적인 방식처럼 정적으로 매핑할 수 없다.

이와 달리, 이 통신 시스템에서는 데이터를 동적으로 직렬화해야

한다. AUTOSAR Classic Platform의 경우 SomeIpXf 모듈이 직렬

화를 처리한다. 이 모듈은 AUTOSAR의 미들웨어 레벨에 속하기

때문에, CAN XL의 동적 데이터를 직렬화할 때도 이 기능을 사용

할 수 있다.

SOME/IP-SD를 사용한 동적 링크 연결

SOME/IP는 완전 동적 연결과 반-동적 링크 연결을 모두 지원한

다. 완전 동적 링크 연결은 네트워크 노드들이 서로 상대 노드의

IP 및 MAC 주소를 모를 때 사용된다. 모든 프로토콜 레벨에서 동

적 통신을 설정하면 다음과 같은 몇 가지 이점이 있다. 먼저, ECU

를 수정하지 않고도 네트워크 내에서 서비스를 원하는 다른 노드

에 재배치할 수 있다. 이러한 재배치는 MAC 및 IP 주소에도 동일

하게 적용된다. 필요한 경우 소비자와 공급자는 ARP(Address

Resolution Protocol: 주소 결정 프로토콜)를 PHY 여러 번 사용하

여 각각 자신의 MAC 및 IP 주소를 결정할 수 있다.

CAN XL에서의 IP 컨셉트SOME/IP에서 SOME/CAN으로의 전환

미래 세대의 자동차 네트워킹은 주로 다양한 Ethernet 및 CAN 버전의 사용에 기반하게 될 것이다. Ethernet이 서비스 기반 IP 통

신 및 지원 시스템 수준의 SOME/IP 미들웨어에서 우세를 보이지만, 신호 기반 CAN 네트워킹도 향후 드라이브 및 섀시 부문에서 오

랫동안 지속될 것이다. 새로운 CAN XL은 위와 같이 근본적으로 다른 두 가지 컨셉트가 공존하면서 상호 작동할 수 있도록 하는 데

중요한 역할을 해야 한다. 이 경우 CAN XL ECU가 서비스 기반 통신에 참가하는지 여부와 공존 및 상호 작동을 가능케 할 방법이 무

엇인지에 대한 질문이 제기된다.

02

기술기사 / CAN XL에서의 IP 컨셉트

CAN XL 스택에 대한 요구사항은 상당히 까다롭다. CAN XL에서

Ethernet 프레임들을 통합할 수 있게 되는 순간 CAN XL ECU에도

공통 TCP/IP 스택이 필요하게 된다. 명심해야 할 점은 CAN XL 프

레임에는 Ethernet 프레임이 내장되어 있는데, Ethernet 프레임에

는 IP 패킷이 포함되어 있다. 결과적으로 인터페이스 계층이 Eth-

ernet의 작동 방식은 물론 CAN의 작동 방식도 수용할 수 있어야

한다. 인터페이스 계층의 CAN 파트는 Ethernet 프레임의 압축을

푸는 한편, Ethernet 파트는 IP 프레임의 압축을 푼다. 이밖에 각

CAN XL 노드에는 가상의 MAC 주소가 필요하다. 다음으로 CAN

XL PHY는 Ethernet 네트워크에서 수신한 프레임을 CAN XL로 이

어서 전송하기 위해, 그리고 모든 CAN XL 노드가 응답 데이터용

으로 또 다른 CAN 프레임을 갖도록 하기 위해 하나의 CAN 프레

임만 있으면 된다. 필터 기능은 프레임에 포함된 MAC 주소를 기

반으로 수행할 수 있다. 이러한 조건에서 SOME/IP, SOME/IP-SD

및 ARP는 순수 Ethernet 네트워크에서의 작동과 똑같게 작동한다

(그림 2).

마찬가지로, 고정 IP 주소와 MAC 주소를 사용하는 반-동적 링크

연결을 선호하는 몇 가지 이유가 있다. 각 ECU에는 다른 네트워

크 노드의 IP 및 MAC 주소가 저장되는 매핑 테이블이 있다. 이 방

법 또한 런타임 동안 서비스 레벨에서 동적 통신을 구성하지만,

여기서는 ARP 없이도 구성할 수 있기 때문에 통신을 더 빠르게

시작할 수 있다. 반-동적 링크 연결에서는 모든 IP 및 MAC 주소

가 알려져 있기 때문에 서비스를 임의로 이동할 수도 있다. 단, 이

제 IP/MAC 주소를 더 이상 변경할 수 없다는 단점이 있다. 이 경

우에는 관련된 모든 ECU의 매핑 테이블을 업데이트해야 한다. 알

아두어야 할 중요한 점은 업계에서는 차량 또는 모델 시리즈에 따

라 때로는 완전 동적 링크 연결을, 때로는 반-동적 링크 연결을 사

용한다는 점이다. SOME/IP는 Ethernet이 교환형 네트워크만 포

함하든, 아니면 버스 토폴로지를 함께 포함하든, 이와 관계없이

모든 Ethernet 버전에서 작동한다.

CAN XL에서의 서비스 지향 통신

Ethernet과 CAN 도메인 간의 링크 요소로서 자신의 역할을 제대

로 처리하기 위해 CAN XL은 또한 서비스 지향적인 통신에도 참

가할 수 있어야 한다. 따라서 기술적 측면에서 CAN XL이 미래의

E/E 아키텍처에 어떤 옵션을 제공할 수 있는지 설정하는 일은 E/E

아키텍처 설계자에게 커다란 관심사이다. 동시에 사용자도 가장

비용 효율적인 솔루션을 찾기 위해 지속적으로 노력하고 있다. 이

경우 중요한 요소는 개별 솔루션의 소프트웨어 스택과 ECU 하드

웨어에 어떤 요구사항을 부과할 것인지 결정하는 일이다.

Ethernet 프레임의 라우팅

첫 번째 가능성은 CAN XL에서 Ethernet 프레임을 라우팅하는 것

이다. 이를 위해 표준 Ethernet 스위치를 사용할 수 있다. 하드웨

어 측면에서 볼 때, CAN XL 네트워크가 연결된 포트와 CAN XL

버스 사이에 CAN XL PHY를 개발하여 이를 통합해야 한다. 이 경

우 CAN XL PHY는 통신 방향에 따라 모든 Ethernet 프레임을

CAN XL 프레임에, 또는 그 반대로 복사할 수 있어야 한다. 이는

Ethernet 스위치에서만 필요하며, CAN XL 노드에서는 일반적으

로 사용하는 트랜시버로 충분하다. 물론 기존 게이트웨이를 사용

하는 것도 언제나 가능하다(그림 1).

그림 1: CAN을 사용하는 Ethernet CAN 네트워크

IP 프레임의 라우팅

두 번째 가능성은 적합한 게이트웨이를 사용하는 것과 Ethernet

프레임 대신 IP 프레임을 CAN XL로 라우팅하는 것이다. 게이트웨

이가 하는 일은 Ethernet 프레임에서 IP 프레임의 패킹을 풀어내

는 일이다. 적절한 자체 라우팅 테이블을 사용하여 게이트웨이는

포함된 IP 주소를 CAN XL 프레임에 패킹하고 CAN XL 버스로 라

우팅할 패킷으로 인식하는데, 여기서도 CAN XL ECU에 TCP/IP 스

택이 필요하다. CAN 인터페이스는 구현할 때 사소한 변경만 필요

하지만, TCP/IP 스택의 경우에는 커다란 변경이 예상된다. 프레임

에 포함된 IP 주소는 필터링에 사용할 수 있다. 이 시나리오에서도

SOME/IP와 SOME/IP-SD는 순수 Ethernet 네트워크에서의 작동과

똑같게 작동한다(그림 3).

그림 2: CAN XL을 통한 임베디드 Ethernet 통신용 스택

03

기술기사 / CAN XL에서의 IP 컨셉트

그림 4: 새 SOME/CAN 모듈을 탑재한 스택에서 SOME/IP의 직렬화

해결책이 관심을 끈다. 여기서는 새로 도입된 “SOME/CAN” 계층

이 소프트웨어 스택의 TCP/IP(TCPIP) 및 소켓 어댑터(SOAD) 모

듈을 대체한다. SOME/CAN 계층은 저작자들의 제안으로서, 시

장에 관심을 가질 경우 더 자세히 사양을 정해 구현해야 한다. 라

우팅, SOME/IP에서 SOME/CAN으로의 변환은 게이트웨이에서

이루어진다. SOME/IP 메시지는 PDU 라우터 모듈에서 변환된다.

SOME/IP-SD 메시지는 어플리케이션에서 역직렬화했다가 해당

SOME/CAN 메시지로 도로 직렬화해야 한다. 이 과정에서, 게이

트웨이가 SOME/IP-SD 헤더의 IP 주소 및 포트 번호를 대체하고

(예를 들면 CAN ID로) 프레임을 “CAN XL 유형”으로 식별한다.

CAN XL 프레임은 이제 포함되고 수정된 SOME/IP 프레임을 전

송하고, 그 결과 “SOME/CAN 메시지”로 지정되어야 한다. Ether-

net SOME/IP 가입자가 전용 (UDP) 포트를 수신 대기하는 한편,

SOME/CAN 가입자는 특수 SOME/CAN ID를 대기한다. SOME/

CAN 메시지가 관련되었는지, 아니면 서비스 검색이 관련되었는

지는 헤더에 메시지 값으로 표시된다. 메시지 값 0xFFFF 8100이

서비스 검색 메시지를 식별한다(그림 4).

그림에서 보듯이 SOME/IP 통신은 TCP/IP 스택 없이도 CAN으로

변환할 수 있다. 비록 적절하게 확장된 AUTOSAR 스택의 특정 소

프트웨어 모듈에 따라 달라지지만, 이로써 SOME/CAN 구현이 가

능해진다. 따라서 하드웨어를 통한 필터링은 필요없게 된다.

하드웨어 필터링을 위한 확장

SOME/CAN 접근 방식이 적절하게 추가 개발되었더라면 하드웨

어 필터링을 여전히 실행할 수 있었을 것이다. 그리고 이를 위해

각 사용자가 노드 주소를 받았을 것이다. 그랬을 경우 이 노드 주

소가 하드웨어 필터링을 활성화한다. 이와 관련하여 서비스 제공

을 위해 멀티캐스트 또는 브로드캐스트 주소를 제공해야 한다. 이

제 노드 주소가 주소 지정에 사용되므로 게이트웨이는 이를 정적

으로 매핑해야 한다. 한편 동적 매핑의 경우, CAN 노드 주소에 대

해 적절한 주소 확인 솔루션을 구현해야 한다. 그리고 노드 주소

는 필터링과 네트워크 액세스를 분리한다. 따라서 사용자를 변경

하지 않고도 우선순위를 변경할 수 있다.

앞서 제시한 두 가지 가능성에서 다음과 같은 결론을 내릴 수 있

다. SOME/IP 기능은 두 가지 경우 모두에서 사용할 수 있다. Eth-

ernet 프레임을 라우팅할 때는 표준 스위치에서 새로운 CAN PHY

가 필요한 한편, CAN XL ECU의 소프트웨어 스택에서는 새로운 중

간 계층이 필요하다. 반면, IP 프레임을 라우팅할 때는 소프트웨어

스택도 변경해야 한다. 소프트웨어 모듈에서는 논리 변경이 필요

하지 않고, 단지 구현만 수정하면 된다. 두 가지 경우 모두에서 하

드웨어 필터링이 유용하지만, 리소스를 많이 사용한다.

TCP/IP 없이 CAN XL에서의 서비스 지향성

세 번째 가능한 해결책은 TCP/IP 스택을 완전히 없애는 것이다.

각 CAN XL ECU에 약 50~100 kB의 ROM 저장 용량을 저장할 수

있어 더 작고 저렴한 컨트롤러를 사용할 수 있기 때문에 이러한

그림 3: CAN XL을 통한 임베디드 IP 통신용 스택

04

기술기사 / CAN XL에서의 IP 컨셉트

요약 및 전망

이 기사에서는 CAN XL로 서비스 지향적인 통신을 구현하기 위한

몇 가지 옵션을 제시했다. Ethernet 프레임과 IP 프레임의 라우팅

을 예상할 수 있지만, 이를 효율적으로 구현하려면 하드웨어를 필

터링하는 좋은 방법이 필요하다. 또한 더 작고 비용 효율적인 컨

트롤러를 구현하려면, CAN XL에 TCP/IP 스택을 분배하는 방식으

로 SOME/IP 통신을 구현하는 것이 좋을 듯하다. 하드웨어의 초기

필터링 문제는 노드 주소를 도입하여 인터럽트 로드를 회피함으

로써 해결할 수 있다. CAN XL의 서비스 지향적인 통신이 어느 방

향으로 발전할 수 있는지에 대한 세부 내용은 아직 명확하지 않

다. 그러나 구현될 어플리케이션을 보면 CAN XL의 경우 서비스

지향성이 필요하다는 사실을 확실히 알 수 있다. 전반적으로 CAN

XL은 서비스 지향성을 잘 갖추고 있다.

Peter Decker2002년 벡터에 입사하여 네트워크 및 분산 시스템 부문에서 CAN 제품 관리자로 근무하고 있다.

Oliver Garnatz2000년 벡터에 입사하여 임베디드 소프트웨어 부문에서 솔루션 관리자로 근무하고 있다.

독일 출판물 “Hanser Automotive“ 2020년 6월호

이미지 권리: Vector Informatik GmbH