글로벌 데이터 공간(Global Data Space) 개념

1. 서론: 연결 중심에서 데이터 중심으로의 전환

DDS(Data Distribution Service) 아키텍처의 심장을 이루는 가장 핵심적이고 혁신적인 개념은 바로 **글로벌 데이터 공간(Global Data Space, 이하 GDS)**이다. 현대의 분산 시스템, 특히 국방, 항공우주, 산업 자동화, 그리고 자율주행 자동차와 같이 실시간성과 신뢰성이 최우선으로 요구되는 환경에서, 시스템 복잡도를 낮추고 확장성을 보장하기 위한 해답으로 등장한 것이 바로 이 GDS 개념이다.1

기존의 통신 미들웨어, 예를 들어 소켓(Socket) 프로그래밍이나 메시지 지향 미들웨어(Message-Oriented Middleware, MOM)는 기본적으로 ’메시지 전달(Message Passing)’에 초점을 맞추었다. 이 패러다임에서 개발자의 주된 관심사는 “어떻게(How) 데이터를 A지점에서 B지점으로 보낼 것인가?“에 있다. 개발자는 수신자의 주소(IP, Port)를 알아야 하고, 연결 상태를 관리해야 하며, 데이터의 직렬화와 역직렬화를 직접 통제해야 했다. 이는 시스템의 규모가 커질수록 기하급수적으로 복잡해지는 ’연결(Connection)’의 문제를 야기한다.

반면, DDS가 제안하는 데이터 중심 게시-구독(Data-Centric Publish-Subscribe, DCPS) 모델은 질문을 바꾼다. “데이터는 무엇(What)이며, 어떤 상태(State)여야 하는가?” GDS는 이러한 철학적 전환을 기술적으로 구현한 추상화 계층이다.1 GDS는 물리적으로 분산된 수많은 컴퓨터와 애플리케이션들이 마치 하나의 거대한 공용 메모리를 공유하는 것처럼 동작하게 만든다. 개발자는 네트워크의 복잡한 배관(Plumbing) 작업에서 해방되어, 단순히 로컬 메모리에 있는 변수를 읽고 쓰는 것만으로도 전체 시스템과 소통할 수 있게 된다.

이 장에서는 GDS가 단순한 네트워크 망이 아니라, 어떻게 시공간의 제약을 뛰어넘는 데이터 저장소이자 유통 채널로 기능하는지, 그리고 그 이면에 숨겨진 기술적 메커니즘인 ’환상(Illusion)’의 구현 원리를 심층적으로 분석한다.

2. 가상 공유 메모리(Virtual Shared Memory)로서의 GDS

2.1 분산 공유 메모리(DSM)의 유산과 진화

컴퓨터 과학의 역사에서 분산된 프로세스 간의 통신을 메모리 읽기/쓰기 모델로 추상화하려는 시도는 오랫동안 지속되어 왔다. 1980~90년대의 분산 공유 메모리(Distributed Shared Memory, DSM) 연구는 물리적으로 떨어진 노드들의 메모리를 하나의 주소 공간으로 매핑하여 프로그래밍의 편의성을 높이고자 했다.1 물리적 공유 메모리(Physical Shared Memory)가 멀티코어 프로세서나 SMP(Symmetric Multiprocessing) 시스템 내에서 하드웨어적으로 구현된다면, DSM은 소프트웨어적으로 페이지 폴트(Page Fault) 등을 이용해 이를 에뮬레이션했다.5

그러나 전통적인 DSM은 ’엄격한 일관성(Strong Consistency)’을 유지하려는 노력 때문에 광역 네트워크(WAN)나 대규모 분산 환경에서는 심각한 성능 저하와 확장성 한계에 직면했다. 모든 노드가 항상 동일한 메모리 상태를 보장받아야 한다면, 통신 오버헤드가 실제 연산보다 더 커지는 현상이 발생하기 때문이다.1

DDS의 GDS는 이러한 DSM의 개념적 유산을 계승하되, 실시간 시스템의 요구사항에 맞춰 진화시킨 형태이다. GDS는 엄격한 일관성 대신 **‘느슨한 결합(Loose Coupling)’**과 ‘최종적 일관성(Eventual Consistency)’ 모델을 채택했다. 이는 데이터가 즉시 모든 곳에서 동일할 필요는 없지만, 필요한 곳에는 필요한 시간 내에 반드시 전달되어야 한다는 실용적 접근이다. 따라서 GDS는 전통적인 가상 메모리처럼 주소(Address) 기반으로 접근하는 것이 아니라, 내용(Content)과 키(Key) 기반으로 접근하는 관계형 데이터 모델을 차용하여, 훨씬 더 유연하고 확장 가능한 ’가상 데이터 공간’을 형성한다.7

2.2 GDS의 본질: 환상(Illusion)의 기술적 구현

엄밀히 말해, 물리적인 실체로서의 ’글로벌 데이터 공간’은 존재하지 않는다. 하늘에 떠 있는 거대한 중앙 서버나 클라우드 저장소가 있는 것이 아니다.9 GDS는 미들웨어가 만들어내는 정교한 **환상(Illusion)**이다.

이 환상의 실체는 각 참여자(Participant) 노드에 존재하는 **로컬 데이터 저장소(Local Data Store)**들의 집합이다. DDS 사양에서는 이를 **히스토리 캐시(HistoryCache)**라고 정의한다.11

데이터의 발생: 퍼블리셔(Publisher)가 데이터를 GDS에 쓴다는 행위는, 실제로는 자신의 로컬 DataWriter HistoryCache에 데이터 변경 사항(CacheChange)을 기록하는 것이다.
데이터의 전송: 미들웨어의 백그라운드 스레드는 이 변경 사항을 감지하고, RTPS(Real-Time Publish-Subscribe) 프로토콜을 통해 네트워크 패킷으로 직렬화하여 관심 있는 서브스크라이버들에게 전송한다.14
데이터의 수신: 서브스크라이버 측의 미들웨어는 패킷을 수신하여 역직렬화한 후, 자신의 로컬 DataReader HistoryCache에 데이터를 재구성한다.
데이터의 소비: 애플리케이션이 데이터를 읽는 행위는 네트워크를 기다리는 것이 아니라, 이미 자신의 로컬 메모리에 도착해 있는 HistoryCache의 데이터를 읽는 것이다.

이러한 메커니즘 덕분에, 애플리케이션 관점에서는 데이터가 어디서 왔는지, 네트워크 지연이 얼마인지 알 필요 없이, 마치 로컬 변수를 다루듯 즉각적인 데이터 접근이 가능해진다. 즉, GDS는 **“데이터 이동(Data in Motion)”**을 관리하여 **“데이터 정지(Data at Rest)”**의 환상을 제공하는 기술이다.9

2.3 중앙 집중식 아키텍처와의 비교

GDS의 개념을 명확히 이해하기 위해, 중앙 서버(Broker/Server) 기반의 아키텍처와 비교해 볼 필요가 있다. MQTT나 RESTful 서비스와 같은 기술들은 중앙의 중개자(Broker)나 서버에 의존한다.

비교 항목	중앙 집중식 모델 (MQTT, Client-Server)	DDS 글로벌 데이터 공간 (GDS)
아키텍처 위상	스타(Star) 토폴로지 (중앙 브로커/서버 중심)	메시(Mesh) 또는 버스(Bus) 토폴로지 (P2P 완전 분산)
데이터 저장 위치	중앙 서버/브로커의 큐(Queue) 또는 DB	각 노드의 로컬 히스토리 캐시(HistoryCache)에 분산 저장
단일 실패 지점	존재함 (서버 다운 시 전체 마비)	존재하지 않음 (개별 노드 실패가 전체에 영향 없음)
통신 경로	송신자 $\rightarrow$ 브로커 $\rightarrow$ 수신자 (2 hop)	송신자 $\rightarrow$ 수신자 (1 hop, Direct)
상태 관리	서버가 클라이언트의 상태를 관리	각 참여자가 자신의 상태를 관리하며 GDS를 통해 동기화
확장성(Scalability)	서버 성능에 종속적 (병목 발생 가능)	네트워크 대역폭과 참여자 수에 따라 선형적 확장 가능
데이터 모델	메시지 큐, 토픽 트리, URL 리소스	도메인, 토픽, 키, 인스턴스 (관계형 모델)

[표 2-1] 중앙 집중식 아키텍처와 DDS GDS 아키텍처의 상세 비교 8

GDS는 중개자가 없는(Brokerless) 구조이므로, 데이터는 최단 경로를 통해 이동하며 지연 시간(Latency)이 최소화된다. 또한, 중앙 서버가 없기 때문에 시스템의 한 부분이 파괴되거나 연결이 끊겨도 나머지 부분은 정상적으로 동작하는 **극도의 생존성(Survivability)**을 보장한다. 이는 전장 시스템이나 재난 대응 로봇과 같이 열악한 환경에서 DDS가 선택되는 결정적인 이유이다.2

3. GDS의 3차원적 결합 분리 (Decoupling)

GDS 아키텍처가 제공하는 가장 강력한 효용은 시스템 구성 요소 간의 **결합도(Coupling)**를 획기적으로 낮추는 것이다. 소프트웨어 공학에서 결합도가 낮다는 것은 유지보수성, 확장성, 재사용성이 높다는 것을 의미한다. GDS는 공간(Space), 시간(Time), **흐름(Flow)**의 세 가지 차원에서 완벽한 결합 분리를 제공한다.2

3.1 공간적 결합 분리 (Space Decoupling): 위치 투명성과 익명성

공간적 결합 분리는 통신하는 두 주체가 서로가 누구인지, 어디에 있는지 알 필요가 없음을 의미한다.

익명성(Anonymity): 퍼블리셔는 자신의 데이터가 누구에게 전달되는지, 몇 개의 서브스크라이버가 존재하는지 알 필요가 없다. 서브스크라이버 역시 데이터가 어떤 IP 주소의 어떤 장비에서 생성되었는지 알 필요가 없다. 그들은 오직 **‘토픽(Topic)’**이라는 데이터의 이름만을 공유할 뿐이다.22
자동 발견(Automatic Discovery): GDS는 새로운 참여자가 시스템에 들어오거나 나가는 것을 동적으로 감지한다. SPDP(Simple Participant Discovery Protocol)와 SEDP(Simple Endpoint Discovery Protocol)라 불리는 내부 프로토콜이 백그라운드에서 끊임없이 동작하며 “누가 어떤 데이터를 생산하고 소비하는지“에 대한 메타데이터를 교환한다.11
플러그 앤 플레이(Plug-and-Play): 이 기능 덕분에, 이미 운용 중인 시스템에 새로운 센서 노드를 추가하거나 모니터링 콘솔을 연결할 때, 기존 시스템의 코드를 수정하거나 재설정할 필요가 전혀 없다. 새로운 장비의 전원을 켜는 순간 GDS는 이를 인식하고 즉시 데이터 흐름을 연결한다.16

3.2 시간적 결합 분리 (Time Decoupling): 비동기적 존재

시간적 결합 분리는 데이터의 생성 시점과 소비 시점이 반드시 일치할 필요가 없음을 의미한다. 일반적인 소켓 통신이나 전화 통화는 양쪽이 동시에 ‘온라인’ 상태여야만 정보 교환이 가능하다. 그러나 GDS는 시간의 제약을 넘어선다.

늦은 참여자(Late Joiner) 지원: DDS의 내구성과 지속성(Durability & Persistence) QoS 정책은 퍼블리셔가 데이터를 전송한 후 종료되거나 네트워크에서 사라지더라도, 데이터가 GDS 내에(엄밀히 말하면 내구성을 가진 노드의 캐시나 지속성 서비스에) 살아남도록 한다. 나중에 부팅된 서브스크라이버는 GDS에 접속하는 즉시 과거의 데이터를 수신하여 현재 시스템의 상태를 따라잡을 수 있다.10
데이터 수명(Lifespan) 관리: GDS 내의 데이터는 영원히 존재하는 쓰레기가 되지 않는다. Lifespan QoS를 통해 데이터의 유효 기간을 설정하면, 시간이 지난 정보는 자동으로 소멸한다. 이는 GDS가 단순한 파이프가 아니라, 시간의 흐름을 인지하는 지능형 저장소임을 보여준다.25

3.3 흐름의 결합 분리 (Flow Decoupling): 성능의 비동기화

흐름의 결합 분리는 송신자와 수신자의 처리 속도 차이나 네트워크 상태가 서로의 실행 흐름을 차단(Block)하지 않음을 의미한다.

논블로킹(Non-blocking) 통신: 퍼블리셔는 서브스크라이버가 데이터를 다 처리할 때까지 기다리지 않고, 자신의 속도대로 데이터를 쏟아낼 수 있다. 서브스크라이버 역시 데이터를 하염없이 기다리는 폴링(Polling) 방식 대신, 데이터가 도착했을 때 비동기적으로 알림을 받는 리스너(Listener)나 웨이트셋(WaitSet) 패턴을 사용한다.20
트래픽 셰이핑(Traffic Shaping): 만약 퍼블리셔가 너무 빠른 속도로 데이터를 보내 서브스크라이버가 감당할 수 없다면, GDS는 TimeBasedFilter QoS를 통해 서브스크라이버에게 전달되는 데이터의 빈도를 조절하거나, History QoS를 통해 오래된 데이터를 덮어쓰는 방식으로 흐름을 제어한다. 즉, GDS는 서로 다른 성능을 가진 노드들 사이에서 완충재(Buffer) 역할을 수행하여 시스템 전체의 안정성을 유지한다.2

4. GDS의 구조와 식별 체계 (Taxonomy)

무형의 공간인 GDS가 혼란에 빠지지 않고 질서를 유지하기 위해서는 명확한 주소 체계와 구획화가 필요하다. DDS는 이를 위해 도메인(Domain), 토픽(Topic), **인스턴스(Instance)**라는 계층적 구조를 사용한다. 이는 관계형 데이터베이스(RDBMS)의 구조와 매우 유사하다.

4.1 도메인(Domain): 논리적 격벽과 가상 네트워크

GDS의 최상위 구분자는 **도메인(Domain)**이다. 도메인은 Domain ID(정수형)로 식별되는 논리적인 가상 네트워크이다.25

데이터 격리: 서로 다른 도메인 ID를 가진 애플리케이션들은 같은 물리적 네트워크 스위치에 연결되어 있어도 서로 통신할 수 없다. 이는 마치 라디오 주파수 채널과 같아서, 채널이 다르면 서로의 신호를 전혀 감지하지 못한다.
용도: 하나의 물리적 시스템 내에서 ‘제어용 트래픽(Domain 0)’, ‘로깅용 트래픽(Domain 1)’, ‘시뮬레이션용 트래픽(Domain 2)’ 등을 완벽하게 분리하여 상호 간섭을 방지하는 데 사용된다.1 이는 보안적 측면에서도 중요한데, 민감한 데이터를 다루는 도메인을 분리함으로써 물리적 망 분리 없이도 논리적 망 분리 효과를 낼 수 있다.11

4.2 토픽(Topic): 데이터의 명명과 타입

도메인 내부에서 데이터는 **토픽(Topic)**으로 분류된다. 토픽은 GDS 내에서 데이터가 흐르는 강(River)이나 파이프라인의 이름과 같다. 토픽은 다음의 세 가지 요소로 정의된다.11

토픽 이름(Topic Name): “EngineTemperature”, “AircraftPosition“과 같은 고유한 문자열 식별자.
데이터 타입(Data Type): OMG IDL(Interface Definition Language)로 정의된 구조체(Struct). 데이터의 구조와 형식을 엄격하게 정의한다.
QoS(Quality of Service): 해당 데이터가 어떻게 전달되어야 하는지에 대한 정책 집합.

이러한 구조는 데이터베이스의 테이블(Table) 정의와 유사하다. 퍼블리셔와 서브스크라이버가 통신하기 위해서는 반드시 도메인 ID, 토픽 이름, 데이터 타입이 모두 일치해야 한다.

4.3 키(Key)와 인스턴스(Instance): 데이터 객체의 식별

GDS의 가장 강력한 특징 중 하나는 데이터를 단순한 메시지가 아닌, 식별 가능한 **객체(Object)**로 다룬다는 점이다. 이를 가능하게 하는 것이 **키(Key)**의 개념이다.25

키(Key)의 역할: 데이터 타입 내의 특정 필드(예: sensor_id, flight_number)를 키로 지정하면, GDS는 이 키 값을 기준으로 데이터를 개별 **인스턴스(Instance)**로 구분 관리한다.
인스턴스 관리: 예를 들어 “AircraftPos“라는 토픽에 flight_id가 키로 설정되어 있다면, GDS는 수천 대의 비행기 위치 정보를 단 하나의 토픽으로 처리하되, 각 비행기(flight_id=101, flight_id=102…)를 독립적인 인스턴스로 추적한다.
생명주기 추적: 이를 통해 특정 비행기의 데이터가 끊기거나(Disposed/Unregistered), 상태가 변경되었을 때 GDS는 이를 인지하고 서브스크라이버에게 “101번 비행기 인스턴스가 사라졌다“는 이벤트를 통보할 수 있다. 이는 단순한 메시징 시스템에서는 구현하기 어려운 고급 기능이다.14

5. GDS의 물리적 구현 심화: RTPS와 캐시 관리

앞서 GDS가 ’환상’이라고 언급했지만, 이 환상을 지탱하는 물리적 실체는 매우 견고하게 설계되어 있다. 이 섹션에서는 GDS가 하부에서 어떻게 작동하는지 기술적으로 분해해 본다.

5.1 히스토리 캐시(HistoryCache)의 작동 메커니즘

모든 DDS 엔티티(DataWriter, DataReader)는 커널 메모리 혹은 유저 공간 메모리에 **히스토리 캐시(HistoryCache)**를 유지한다. 이 캐시는 GDS를 구성하는 가장 작은 물리적 단위이다.11

쓰기 과정: 애플리케이션이 write()를 호출하면, 데이터는 즉시 네트워크로 나가는 것이 아니라 DataWriter의 HistoryCache에 CacheChange라는 객체로 등록된다.
전송 과정: RTPS 프로토콜 엔진은 비동기적으로 이 캐시를 스캔하여 아직 전송되지 않은 CacheChange를 UDP/IP 패킷(DATA submessage)으로 변환하여 멀티캐스트 그룹으로 송출한다.
읽기 과정: 수신 측 RTPS 엔진은 패킷을 받아 유효성을 검증한 후, DataReader의 HistoryCache에 CacheChange를 삽입한다. 이때, RESOURCE_LIMITS QoS에 따라 캐시가 꽉 찼다면 오래된 데이터를 밀어내거나(Keep Last), 새로운 데이터를 거부(Keep All + Reject)하는 등의 관리가 일어난다.14

결국 GDS는 네트워크 상에 분산된 수천, 수만 개의 HistoryCache들이 RTPS 프로토콜을 통해 끊임없이 동기화되는 상태 그 자체를 의미한다. 이 과정에서 HISTORY QoS의 KEEP_LAST와 KEEP_ALL 설정은 GDS가 ’최신 상태만 보여주는 전광판’이 될지, ’모든 이력을 간직한 블랙박스’가 될지를 결정한다.14

5.2 RTPS 프로토콜: GDS의 신경망

RTPS(Real-Time Publish-Subscribe)는 GDS를 위한 표준 와이어 프로토콜(Wire Protocol)이다.12 RTPS는 단순히 데이터를 나르는 것을 넘어, GDS의 무결성을 유지하기 위한 다양한 서브메시지(Submessage)를 정의한다.

DATA: 실제 사용자 데이터를 나른다.
HEARTBEAT: 퍼블리셔가 “내가 보낸 데이터 중 빠진 것이 없느냐“고 묻는 신호이다. 신뢰성(Reliability)을 보장하기 위해 주기적으로 발송된다.
ACKNACK: 서브스크라이버가 “몇 번 데이터가 누락되었다“고 알리거나(Negative ACK), “잘 받았다“고 응답하는 신호이다.
GAP: 더 이상 유효하지 않은 데이터(필터링 되었거나 만료된 데이터)를 건너뛰라고 지시하여 서브스크라이버의 처리 부하를 줄인다.

이러한 프로토콜 레벨의 상호작용은 애플리케이션 개발자에게는 완전히 투명하게(Transparent) 감춰져 있다. 개발자는 오직 GDS라는 추상화된 공간만을 바라보며 프로그래밍하면 된다.

6. 결론: 소프트웨어 정의 시스템(SDV, IoT)을 위한 데이터 백본

글로벌 데이터 공간(GDS)은 단순한 데이터 전송 통로가 아니다. 그것은 분산 시스템의 ’상태(State)’를 관리하고 공유하는 동적인 데이터베이스이다.

현대의 시스템 아키텍처는 하드웨어 중심에서 소프트웨어 중심(Software-Defined)으로 변화하고 있다. 자동차는 ’바퀴 달린 데이터센터(SDV)’가 되고 있고, 공장은 ’지능형 사물 인터넷(IIoT)’으로 연결되고 있다. 이러한 환경에서 GDS는 이질적인 수많은 장치들이 서로의 존재를 모르면서도 협력할 수 있게 하는 공통의 언어이자 공간을 제공한다.17

GDS를 이해한다는 것은 단순히 DDS 라이브러리의 사용법을 익히는 것을 넘어, **데이터 중심(Data-Centric)**으로 세상을 바라보는 관점을 갖게 됨을 의미한다. 데이터를 메시지가 아닌, 살아있는 유기체처럼 관리하는 GDS의 철학은 복잡성의 늪에 빠진 현대 소프트웨어 공학에 명쾌한 해법을 제시한다. 이제 이어지는 장들에서는 이 GDS 위에서 데이터를 어떻게 정의(IDL)하고, 어떤 품질(QoS)로 제어할 것인지에 대한 구체적인 방법론을 다루게 될 것이다.

7. 참고 자료

Data Distribution Service (DDS) - Object Management Group (OMG), https://www.omg.org/spec/DDS/1.4/PDF
The Data Distribution Service, https://www.cs.wm.edu/~dcschmidt/PDF/dds-sos.pdf
Data Distribution Service for Real-Time Systems Specification - Object Management Group (OMG), https://www.omg.org/spec/DDS/1.1/PDF/
Virtual memory on data diffusion architectures | Request PDF - ResearchGate, https://www.researchgate.net/publication/223187487_Virtual_memory_on_data_diffusion_architectures
The data diffusion space for parallel computing in clusters - SciSpace, https://scispace.com/pdf/the-data-diffusion-space-for-parallel-computing-in-clusters-8cix1lo9xf.pdf
Middleware for Networked & Distributed Systems - UC Irvine, https://ics.uci.edu/~cs237/lecture2021/dsmlecture1-spr21.pdf
DerechoDDS: Strongly Consistent Data Distribution for Mission-Critical Applications - CS@Cornell, https://www.cs.cornell.edu/projects/Quicksilver/public_pdfs/2021226041.pdf
A Tale of Two Industrial IoT Standards: DDS and OPC-UA - RTInsights, https://www.rtinsights.com/dds-opc-ua-industrial-iot-standards/
What is DDS? - DDS Foundation, https://www.dds-foundation.org/what-is-dds-3/
global data space in RTI’s implementation of DDS - Stack Overflow, https://stackoverflow.com/questions/47768959/global-data-space-in-rtis-implementation-of-dds
Embedding Authentication & Authorization in Discovery Protocols for Standard Based Publish/Subscribe Middleware: A Performance Evaluation, https://www.scirp.org/journal/paperinformation?paperid=3999
The Real-time Publish-Subscribe Protocol (RTPS) DDS Interoperability Wire Protocol Specification - Object Management Group (OMG), https://www.omg.org/spec/DDSI-RTPS/2.2/PDF
A Platform Programming Paradigm for Heterogeneous Systems Integration - IEEE Xplore, https://ieeexplore.ieee.org/iel7/5/9383786/09268460.pdf
Dependency Chain Analysis of ROS 2 DDS QoS Policies: From Lifecycle Tutorial to Static Verification - arXiv, https://arxiv.org/html/2509.03381v1
integration of the safety certified pxros-hr real-time operating system in ros2 robotic system - CORE, https://core.ac.uk/download/643424998.pdf
1. Foundations — The Data Distribution Service Tutorial, https://download.zettascale.online/www/docs/Vortex/html/ospl/DDSTutorial/foundations.html
The Real Backbone of SDVs Is Data : RTI on the Future of DDS, https://www.autoelectronics.co.kr/article/articleView.asp?idx=6234
OMG Data Distribution Service: Real-Time Publish/Subscribe Becomes a Standard - RTI, https://www.rti.com/hubfs/docs/reprint_rti.pdf
Decoupling With Time (DWT) - The Hybrid Layer, https://thehybridlayer.com/biomimetic-dentistry/decoupling-with-time/
Modelling patterns for systems of systems architectures - SciSpace, https://scispace.com/pdf/modelling-patterns-for-systems-of-systems-architectures-2ki5sckrw5.pdf
Reconfiguration Service For PublishSubscribe Middl | PDF | System | Computing - Scribd, https://www.scribd.com/document/893061411/Reconfiguration-Service-for-PublishSubscribe-Middl
Data Distribution Service - Wikipedia, https://en.wikipedia.org/wiki/Data_Distribution_Service
A scalable publish/subscribe system for large mobile ad hoc networks - ResearchGate, https://www.researchgate.net/publication/220375654_A_scalable_publishsubscribe_system_for_large_mobile_ad_hoc_networks
DDS Protocol in IoT: Features, Architecture, Working, and Applications - OutRight Store, https://store.outrightcrm.com/blog/dds-protocol-in-iot/
Data-Centric Programming Best Practices: - RTI, https://www.rti.com/hubfs/docs/DDS_Best_Practices_WP.pdf
Topic-Based Resource Allocation for Real-Time Publish/Subscribe Communication Systems - EUDL, https://eudl.eu/pdf/10.4108/chinacom.2010.110
ADD - SESAR Joint Undertaking, https://www.sesarju.eu/sites/default/files/documents/solution/Sol46%2006%20ADD%20P14.1.3-D30-SWIM%20Architectural%20Definition%20Final.pdf
What Is DDS? - MATLAB & Simulink - MathWorks, https://www.mathworks.com/help/dds/gs/dds-conceptual-overview.html