02. 차량 플랫폼 - SOME/IP와 DDS의 차이

SOME/IP와 DDS는 모두 차량 제어 메시지에 사용할 수 있는 자동차 미들웨어 솔루션 입니다. SOME/IP와 DDS는모두 publish/Subscribe을 기반으로 한 메시지 패턴을 사용하여 정보를 효율적으로 분배하고 처리하고, PRC(Remote Procedure Call)을 기반으로 한 메시지 패턴을사용하여 서버와클라이언트 간의 직접적인 통신을 가능하게 합니다. 이러한

이러한 메시지 패턴을 기반으로 서비스의 제공자/이용자/종속성 등을 설정하여 서비스를 정의할 수 있으며, 서비스 기반 통신을 통해 대규모의 메시지를 효율적으로 관리할 수 있으며 많은 태스크를 효율적으로 작업할 수 있게 됩니다.

 

한편, SOME/IP는 자동차산업을 위해 설계된 통신 프로토콜로 서비스 제공자와 소비자는 중앙 브로커 없이 직접적으로 연결된다는 특징이 있습니다. 데이터와 기능들은 서비스 지향 통신의 패러다임을 따라서비스로 캡슐화되며, 메소드와 이벤트, 그리고 필드는 서비스 인터페이스를 기술할 때 사용됩니다. SOME/IP와 DDS는 모두 유니캐스트 또는 멀티캐스트 통신 방식을 사용하며, TCP/UDP를 전송 프로토콜로 사용합니다. 두 통신 방식 모두 데이터나 서비스의 발행자와 구독자를 찾을 때 런타임에 서비스가 제공되고, 알림을 구독할 수 있는 서비스 검색 메커니즘을 사용합니다.

출처 : 벡터

출처 : 벡터

SOME/IP와 DDS의 가장 큰차이점은 SOME/IP는 자체 QoS메커니즘을 정의하지 않지만, DDS는 광범위한 QoS 메커니즘을 지원한다는 점에 있습니다. QoS(Quality - of - Service) 파라미터란 통신 프로토콜의 특성을 다루며 데이터 송수신 관련 설정을 목적에 맞추어 유저가 직접 설정할 수 있도록 되어 있습니다. 이는 TCP 처럼 데이터 손실을 방지함으로써 신뢰도를 우선시하거나, UDP 처럼 통신 속도를 최우선 하여 사용하는 기능등이 대표적으로 사용되고 있습니다. 이를 통해 차량에서 실시간성을 보장해야 하는 데이터와 안전과 직결되어 신뢰성을 보장해야하는 데이터 등에 맞게 통신 프로토콜을 최적화 하여 적용할 수 있게 됩니다. 

 

또한 SOME/IP는 PRC 통신 패턴을 직접적으로 제공하지만, DDS는 여러개의 토픽을 전송 및 반환 채널로 구성하여 서비스를 요청하고 응답하는 방식으로 구현됩니다. 즉, 메시지 인터페이스를 변형하여 서비스를 요청하는 쪽과 서비스를 수행하는 쪽을 정의한 service 인터페이스를 구성하여 PRC 통신을 하며, 이러한 서비스 통신 방법을 사용하여 서비스의 외부, 내부에서 매개변수를 쉽게 지정(Set)하거나 변경할 수 있고, 쉽게 가져(Get)와서 사용할 수 있게 됩니다. 

출처 : eprosima

 

한편, 차량의 제어기의 대부분은 오토사를 기반으로 설계되어야 하기 때문에 임베디드 시스템을 구현할 때에는 해당 프로토콜이 오토사 솔루션에 얼마나 잘 통합될 수 있는지 또한 고려사항이 됩니다.  클래식 오토사에서 어플리케이션 계층은 런타임 환경을 통해 베이직 소프트웨어와 연결되지만 어댑티브 오토사에서는 ARA:COM 인터페이스 하위의 프로토콜을 바인딩을 통해 구현합니다. 따라서 DDS는 어댑티브 오토사로의 통합은 가능하지만, 클래식 오토사의 경우 오토사 OS에 따라 RTE에 대한 적용이 필요합니다. 또한 클래식 오토사의 SoAd 모듈에 배치되어있는 SOME/IP와는 달리 DDS는 오토사 모듈(SoAd, TcpIp, PduR)에서 프로토콜 호환성에 대한 문제가 있습니다.   

 

DDS는 광범위한 사양과 다양한 기능으로 인해 다수의 어플리케이션에 적합하지만, 넓은 프로토콜의 범위와 여러 가지 QoS 기능들로 인해 SOME/IP보다 메모리에 대한 수요가 훨씬 큽니다. 따라서 DDS를 마이크로 컨트롤러에서 구현하는 것은 매우 제한적이며, 오토사에서도 어댑티브 오토사에서만 DDS를 표준화된 방식으로 채택하여 구현할 수 있게 하였습니다.  현재 차량 내부 어플리케이션으로 DDS와 SOME/IP가 대두되고 있으며, DDS가 기존의 SOME/IP르 대신할 수 있을 지는 지켜봐야 할 것입니다.