이더넷에 기반을 둔 BroadR-Reach 는 카메라 애플리케이션과 함께 이미 차량에서 사용되고 있으며, 다른 애플리케이션 영역에서도 사용될 것으로 보인다. 전문적인 개발 툴을 이용하면 서로 다른 네트워크 간의 통신에 대한 동기화된 시간 표시가 가능하다. 대역폭의 효율을 높이기 위해 차량용 IP 네트워크는 정적인 CAN 통신과는 달리 동적이고 서비스 지향적으로 설정 된다. 그러므로 개발 툴은 SOME/IP 와 같은 서비스 지향적인 프로토콜을 반드시 지원해야 한다.

이 글은 SOME/IP(Scalable Service-Oriented Middleware on Ethernet/IP)의 예를 통해 동적이고 서비스 지향적인 IP 네트워크의 통신 버스 시뮬레이션[1] 시행 방법에 대해 다룬다(그림 1). 또한 미디어 액세스 측면에서의 동기화 및 제어된 신호 인가(controlled stimulation)[2]에 대해 논의하고 효과적인 개발 시스템에 대한 제안으로 마무리한다.
 

 

SOME/IP에 기반한 서비스 프로토콜의 사용

이더넷 및 IP 분야에서는 선택할 수 있는 프로토콜이 많아 거의 모든 상황에서 사용할 수 있는 프로토콜이 이미 개발되어 있을 것으로 생각할 수 있다. 그러나 차량 내 네트워킹은 0에서 시작하지 않기 때문에 특정한 요구사항이 바로 나타날 수 있다. 예를 들면, , 이 프로토콜이 기존의 시스템내에 포함 되어야만 하는 경우가 있다. 이러한 문제는 특히 AUTOSAR 통합이나 오류 발생 시 지연을 줄이기 위한 빠른 반응 시간 등과 연관되어 있다. BMW사는 차량에 대한 요구사항을 충족시키기 위해 개방형 프로토콜인 SOME/IP를 개발하고 규격화했다. 이에 벡터(Vector)에서는 TCP/IP 스택, SD(Service Discovery), BroadR-Reach용 이더넷 드라이버 등을 포함해 ECU에서 사용되는 SOME/IP 프로토콜의 구현을 지원하고 있다.
SOME/IP 프로토콜은 서비스 지향(Service-oriented) 통신을 위한 인터페이스를 제공한다(그림 2). 이 프로토콜은 CAN에서 흔히 사용하는 순수한 신호 기반 통신과 구별된다. SOME/IP 프로토콜은 크게 세 부분, 즉 SD(Service Discovery), 원격 절차 호출 (RPC), 데이터 처리를 위한 액세스로 나눌 수 있다. SD 영역은 ECU가 서비스를 검색하거나 네트워크 상에서 다른 서비스를 제공하도록 한다. 사용자는 RPC를 통해 SD가 제공하는 방법을 활용할 수 있다(그림 3, A 구역). 또한, 특정 이벤트에 대한 알림(notification)을 설정하는 것도 가능하다(그림 3, B 구역). 애플리케이션은 특정 프로세스 데이터에 액세스하기 위해 읽기/쓰기 기능을 사용할 수 있다(그림 3, C 구역). SOME/IP 프로토콜의 목표는 유연한 통신을 구현하기 위해 사용 가능한 대역폭을 최적으로 사용하는 것이다. 이러한 통신과 신호는 FIBEX 4.1 이상 또는 AUTOSAR 포맷 4.1 버전 이상을 통해 설명된다.
 

통신 버스 시뮬레이션에서 SOME/IP 프로토콜은 모든 자유도(degree of freedom)에 대해 복잡한 프로토콜과 미들웨어의 역할을 한다. 이용자의 복잡함을 최소화하기 위해 시뮬레이션은 대부분 자동으로 구성된다. 여기에는 FIBEX 4.1 이나 AUTOSAR 와 같은 표준화된 기술파일을 사용하는 것도 포함된다. 이를 통해 사용자는 시그널에 바로 액세스할 수 있다. 그러나 구성 파일을 수동으로 덮어쓰는 것(Overwriting)은 오류 케이스 유발 등의 테스트를 할 때 바람직하다.

테스트 툴을 위한 유연한 네트워크 액세스

통신 버스 시뮬레이션과 같은 복잡한 테스트를 툴을 통해 가장 최적으로 수행하기 위해서는 애플리케이션이 물리 매체에 유연하게 액세스할 수 있어야 한다(그림 4, Remaining Bus Simulation).
이러한 액세스 방식을 통해 개발자는 네트워크에 오류 케이스(예: CRC 오류)를 생성할 수 있다. 만약 두 노드 간 연결을 분석하는데 일차적인 초점을 맞춘다면 투명하고 간섭이 없는 액세스가 가능하도록 추가적인 조치를 해야 한다. 이런 조치가 필요한 이유는 OABR(Open Alliance BroadRReach)이 논리적으로는 하나의 버스 시스템이지만 전기적으로는 점 대 점(Point to Point) 접속이기 때문이다.



그림 3: SOME/IP 는 RPC 와 같은 다양한 유형의 액세스와 알림 기능 및 읽기/ 쓰기 기능을 제공한다.


한 가지 확실한 방법은 시스템에서 사용하는 스위치에 추가적인 모니터 포트를 사용하는 것이다. 그러나 비용상의 문제로 생산 시스템에 이러한 방법을 항상 적용할 수는 없다[3]. 스위치는 미러링(mirroring)을 통해 수신된 모든 패킷을 모니터 포트로 전달한다. 이러한 방법은 수신된 데이터 패킷들이 공통의 시간 기준(time reference)을 갖고 있지 않기 때문에 타임스탬프를 사용할 수 없다는 단점이 있다. 또한, 유효 패킷만 모니터 포트로 전달하기 때문에 오류 분석이 어렵다.
TAP(Test Access Point)이라는 방식을 이용하면 분석 대상 네트워크에 거의 영향을 주지 않고 미디어 액세스가 가능하다[2]. 표준 스위치와는 달리, TAP 은 두 노드 간 통신에 영향을 주지 않고 이더넷 네트워크를 투명하게 분석하는 것이 가능하다(그림 4, Flexible TAP). TAP 은 다음과 같은 요구사항에 따라 두 가지 모드로 운영할 수 있다.

> 순수한 수동 운영 모드에서는 짧고 일정한 대기 시간을 보장하지만, 이 모드에서는 매체에 대한
수신만 가능하다.
> 능동 모드에서는 추가 데이터를 기존 커넥션에 주입시킬 수 있다.

그러나 물리 계층(OSI 계층 1)에서는 추가적인 흐름 제어가 필요하므로 능동적인 접속을 할 수 없다. 흐름 제어는 계층 2 까지는 사용 가능하며 흐름 제어가 가능하더라도 흐름 제어가 일정한 대기시간을 보장하지는 않는다.
선택한 방법과 상관없이 물리 계층에 최대한 가까운 곳에서 측정한 정확한 타임스탬프는 패킷 데이터의 정밀한 분석에 필요하다. 이러한 타임스탬프는 다른 인터페이스와도 동기화시켜야 하는데, 네트워크 분석은 하나 이상의 이더넷 경로는 물론 다른 차량용 네트워크에도 초점을 맞추어야 하기 때문이다.

개발 툴의 선정

앞에서 한 고려사항들을 바탕으로 모든 개발자는 개발 툴을 선정하기 전에 5 가지의 질문을 던져야 한다.

> 이 개발 시스템은 SOME/IP 와 같은 서비스 지향적 통신을 지원하는가?
> 이 개발 시스템은 프로토콜을 위반하거나, 위반하지 않으면서 로깅이나 통제된 신호 인가를 제공하는가?
> 이 개발 시스템은 OABR이나 CAN, FlexRay, MOST와 같은 전형적인 차량용 네트워크에 대한 액세스를 제공하는가?
> 이 인터페이스는 미러링용 TAP 또는 컨버터나 스위치로 융통성 있게 사용할 수 있는가?
> 이기종 네트워크를 지원하는 인터페이스가 일반적으로 사용되는 버스 시스템과 IP 네트워크에 동기화되는가?

CANoe.IP 개발 툴은 벡터의 VN5610 이더넷/CAN 인터페이스와 함께 이러한 조건을 모두 만족하며, 이미 여러 자동차 OEM 업체 및 공급업체에서 사용되고 있다.

전망

IP 기반의 서비스 지향적 통신은 상당한 발전을 하고 있다. 카메라 애플리케이션에서 사용된 후 이더넷은 인포테인먼트 분야에서 사용되고, 앞으로는 백본 등과 같은 다른 시스템 영역에서도 사용될 것이다. 차량 네트워크 개발자들에게 멀티 버스 기능이나 통신 버스 시뮬레이션, 모든 데이터 패킷에 대한 낮은 타임스탬프는 점차 중요해질 전망이다.
 

참조:
[1] Schnelle Wege zur Restbussimulation: Virtuelle Netzwerke ohne Programmier-Know-how erstellen (“Quick paths to the remaining bus simulation: Creating virtual networks without programming know-how”), Stefan Albrecht and Peter Decker, Automobil Elektronik 03/2012
[2] Neue Werkzeuge für Automotive Ethernet (“New tools for automotive Ethernet”), Hans-Werner Schaal, Matthias Schwedt, Hanser automotive 3-4/2013
[3] Herausforderungen von Ethernet-Debugging (“Challenges of Ethernetdebugging”), Helge Zinner, www.elektroniknet.de, October 2012


좌측부터:
한스 베르너 샬 (Hans-Werner Schaal) (Dipl.-Ing.)
벡터 인포매틱(Vector Informatik)에서 이더넷과 Car2x, 그리고 J1939 나 ISOBUS 같은 개방형 CAN 프로토콜 분야의 사업개발 매니저이다.

마티어스 쉬베트 (Matthias Schwedt) (Dipl.-Ing. (FH))
벡터 인포매틱(Vector Informatik)에서 이더넷과 FlexRay, MOST150 네트워크 인터페이스의 FPGA 개발을 담당하며, VN56xx 이더넷 네트워크 인터페이스 제품 라인의 프로젝트 팀장이다.

페터 펠메트 (Peter Fellmeth) (Dipl.-Ing. (FH))
벡터 인포매틱(Vector Informatik)에서 그룹장이자 제품 매니저로서, 이더넷과 J1939, ISOBUS 분야의 제품 개발과 고객별 프로젝트를 담당하고 있다.