본문 바로가기
자동차 임베디드 SW/CAN통신 & LIN통신

차량용 이더넷과 DDS에 대하여

by 존버매니아.임베디드 개발자 2025. 9. 9.
반응형

DDS (Data Distribution Service) 는 데이터-중심 pub/sub(데이터 생산/구독) 미들웨어

참고로 미들웨어란 애플리케이션(내 코드) 과 운영체제·네트워크(하드웨어/OS) 사이에서 중간 계층 역할을 하는 소프트웨어
개발자가 낮은 수준(소켓, 패킷, 스레드 관리 등) 을 직접 다루지 않고, 높은 수준의 API/서비스로 쉽게 프로그래밍하게 도와줌


DDS는 RTPS 프로토콜을 사용
(Real Time Publish-Subscribe)

보통 UDP/IP 위에서 동작하는 프로토콜.


RTI Connext란?
RTI (Real-Time Innovations) 라는 미국 회사가 만든 상용 DDS 미들웨어 제품군입니다.

DDS와 RTI Connext 관계를 비유하자면
DDS = 운영체제
RTI Connext = 윈도우
이런 느낌으로 이해하면된다.

OS라는 Sw가 있고,
OS의 실제 예시로
리눅스.윈도우.안드로이드 가 존재하는 것처럼
DDS라는 미들웨어도 실제 서비스 되는 제품이 여러종류가 있는데 그 중에서 가장 잘나가는 제품이 RTI 라는 회사에서 만든 RTI Connext임.

이 제품은 상용 제품이라 돈 주고 구매해서 써야한다.

OMG(표준화 기구)가 정의한 DDS 표준을 충실히 구현했고, 지금 시장에서 가장 많이 쓰이는 DDS 중 하나임

그 외의 DDS 제품은 아래와 같은 제품들이 있다.
RTI Connext (상용) → 안정성, 기능, 툴 지원 최고 수준. (라이선스 비용 有)

eProsima Fast DDS (오픈소스) → ROS 2 기본 DDS, 무료, 성능 최적화 꾸준히 발전 중.

Eclipse Cyclone DDS (오픈소스) → 경량화, 빠른 속도, 임베디드에 적합.

Twin Oaks CoreDX (상용, 경량) → 작은 메모리/임베디드용에 특화.


프로토콜 동작 개요
도메인이라는 개념이 있는데, 논리적인 공간을 의미한다. 같은 도메인 내에서만 서로 통신한다.
도메인은 숫자값으로 구분한다.
(도메인 0, 도메인1, 도메인2 ...)

물리적인 네트워크 망 자체가 분리돼있는게 아니고 DDS 에서 나눠놓은 논리적인 공간임

동작개요
1) SPDP(
Simple Participant Discovery Protocol)
통신에 처음 참여하게 되면 브로드 캐스트로 자신이 통신에 참여했음을 알린다.
(나는 도메인0 의 참가자 김철수다~ 라고 외침)

이를 통해 네트워크 참여자들이 서로의 존재를 인식하고 참여자 정보를 친구목록에 등록해놓는다. 이 과정을 SPDP 라고 한다.
이 과정을 통해 참가자들은 서로의 IP, Port 정보를 알게 된다

2)SEDP(Simple Endpoint Discovery Protocol)
한편, DDS는 참여자들이 각자 자신이 송신하려는 데이터, 자신이 수신받기 원하는 데이터 목록을 갖고 있는데 이런 정보를 서로 주고 받아서 정보 생산자, 소비자 간에 매칭을 하는데 이걸 SEDP라고 한다.
뒤에서 얘기하겠지만 주고 받으려는 데이터의 종류(?)를 Topic이라고 부른다.
그리고 데이터를 서로 어떻게(?) 주고 받을건지 통신 방식에 대한 것도 토픽마다 사전에 정의해놓는데 이걸 QoS라고 한다.
(송신측, 수신측의 토픽이 같아도 QoS는 다를 수 있음. QoS도 서로 호환될때만 서로 정보 교환가능)

Ex) 참여자 A는 차량속도 정보를 생산
  참여자 B는 차량속도 정보 필요함

참여자 A,B는
SEDP 과정을 통해 서로 매칭하게 됨.
(근데 사실 토픽만 일치하는게 아니라 QoS도 서로 호환될때만)

3) 위 과정을 통해 정보 생산자, 소비자 간의 매칭이 끝났으니 이제 둘 간의 정보교환이 이뤄지게 된다. 송신측이 수신측에게 지정된 QoS 방식으로 정보를 보낸다.

이게 대략적인 동작 개요이다.


주요 용어(상세)
Domain: 논리적 통신 영역(숫자). 서로 다른 도메인은 서로 안 보입니다.

Participant: 한 프로세스/노드의 DDS 인스턴스(= 네트워크 참가자).

Publisher / DataWriter: 데이터를 내보내는 쪽.

Subscriber / DataReader: 데이터를 받는 쪽.

Topic: 이름 + Type(데이터 구조) 조합.

QoS: 신뢰성, 내구성, 히스토리, 데드라인 등 전송 특성을 선언적으로 설정


보충설명
Topic은 어떤 정보를 주고 받을건지를 정한 것(예를 들어 차속, 배터리온도 처럼 주고받으려는 구체적인 데이터가 뭔지)

QoS는 정보를 어떻게 주고 받을건지 통신방식(?)을 정해놓은게 QoS이다.

앞에서 SEDP 과정을 통해 정보 생산자, 소비자 간에 매칭이 이뤄진다고했는데 사실 어떤 정보를 주고 받을건지에 대한 정보(Topic) 말고 QoS 정보도 서로 주고 받는다.
그리고 생산자,소비자 간에 QoS 가 매칭이 되야만 서로 소통가능하다.

QoS 예를 드는게 빠를거같다.
QoS 예시)
QoS 의 세부 속성들이 존재하는데
예를 들어

Reliability : Reliable과 Best Effort 중 선택
History : keep_last(5) , keep all 등 선택

Relable : 송신,수신측간에 ack,nack 등을 통해 데이터유실. 송신순서 바뀜 등을 방지할 수 있는 통신방식

Best Effort : 수신 잘 됐는지 모르겠고 데이터 계속 보냄

TCP 랑 UDP 같은 느낌임.
아무튼 QoS가 서로 맞아야 서로 통신가능함.

예를 들어 수신측은 Reliable 방식을 원하는데
송신측이 그걸 지원하지 않는다면 둘은 토픽은 같더라도 서로 정보 교환 못한다는 얘기임







반응형