토픽의 이름 짓기 및 구조화

DDS(Data Distribution Service) 미들웨어를 기반으로 하는 분산 시스템 아키텍처에서 ’토픽(Topic)’은 단순한 메시지 전달 경로의 이름을 넘어선다. 데이터 중심(Data-Centric) 설계 철학에서 토픽은 전역 데이터 공간(Global Data Space) 내에 존재하는 정보의 본질적 식별자이자, 데이터의 생산자(DataWriter)와 소비자(DataReader) 간의 강력한 계약(Contract)을 형성하는 핵심 매개체이다.1 시스템의 규모가 커지고 복잡도가 증가함에 따라 초기에 결정된 토픽의 명명 규칙(Naming Convention)과 구조화 전략은 시스템의 성능, 확장성(Scalability), 그리고 상호운용성(Interoperability)을 좌우하는 결정적인 기술 부채(Technical Debt) 혹은 자산이 된다.

본 장에서는 DDS 표준 명세와 다양한 산업 현장의 베스트 프랙티스, 그리고 RTPS(Real-time Publish-Subscribe) 와이어 프로토콜의 기술적 제약 사항을 종합적으로 분석하여, 견고하고 확장 가능한 토픽 설계 전략을 상세히 기술한다.

1. 데이터 중심 아키텍처와 토픽의 본질

DDS가 다른 메시지 지향 미들웨어(MOM)와 구분되는 가장 큰 특징은 데이터 중심성이다. MQTT나 AMQP와 같은 프로토콜이 “메시지를 어디로 보낼 것인가(Destination)“에 집중한다면, DDS는 “공유되는 데이터가 무엇인가(What)“에 집중한다.1 이러한 철학적 차이는 토픽의 이름 짓기 방식에 근본적인 변화를 요구한다.

1.1 토픽의 구성 요소와 식별

DDS 명세에 따르면, 데이터 리더와 데이터 라이터가 성공적으로 연결(Matching)되기 위해서는 다음 세 가지 요소가 반드시 일치하거나 호환되어야 한다.

토픽 이름(Topic Name): 도메인(Domain) 내에서 유일한 문자열 식별자.
데이터 타입 이름(Type Name) 및 구조: 데이터의 스키마(Schema)를 정의하는 IDL(Interface Definition Language) 구조체.
QoS(Quality of Service): 데이터 전달의 신뢰성, 지속성 등을 정의하는 정책.4

이 중에서 토픽 이름은 가장 먼저 확인되는 식별 키이다. 개발자는 토픽 이름을 지을 때 이것이 RPC(Remote Procedure Call)의 함수 이름이나 파일 시스템의 경로가 아니라, 관계형 데이터베이스(RDBMS)의 테이블 이름과 유사한 역할을 한다는 점을 인지해야 한다. 즉, 토픽은 특정 행위(Action)가 아닌 상태(State)를 저장하고 공유하는 공간을 의미한다.

1.2 상태(State) 기반 명명 철학

잘못된 토픽 설계의 대표적인 예는 동사(Verb)를 사용하는 것이다. 예를 들어 SendCameraImage나 UpdatePosition과 같은 이름은 명령형 프로그래밍의 잔재이다. DDS 환경에서는 CameraImage나 VehiclePosition과 같은 명사(Noun) 형태의 이름이 권장된다.6 이는 데이터가 시스템의 현재 상태를 나타내는 ’진실의 원천(Source of Truth)’임을 강조하며, 데이터가 언제, 누가 보냈는지와 무관하게 그 자체로 의미를 갖도록 한다.

2. 물리적 제약 사항과 표준 준수

이상적인 설계 원칙을 적용하기 전에, 현실적인 기술적 제약 사항을 이해해야 한다. OMG DDS API 표준과 실제 통신을 담당하는 RTPS 프로토콜 표준 사이에는 토픽 이름에 대한 미묘한 차이가 존재하며, 이는 이기종 시스템 간의 상호운용성 문제로 직결될 수 있다.

2.1 길이 제한의 진실: 256자의 벽

DDS API 표준(v1.4) 자체는 토픽 이름의 길이에 대해 명시적인 제한을 두지 않고 있다. 이론적으로는 메모리가 허용하는 한 무제한의 길이를 가질 수 있는 것처럼 보인다.4 그러나 시스템 간의 상호운용성을 보장하는 와이어 프로토콜인 RTPS(Real-time Publish-Subscribe) 명세는 이야기가 다르다.

RTPS 프로토콜은 패킷 헤더의 효율성과 임베디드 장치에서의 메모리 관리를 위해 토픽 이름 필드를 제한하는 경우가 많다. 특히 RTI Connext DDS, OpenDDS 등 주요 벤더의 구현체들은 RTPS 표준의 상호운용성 테이블(Table 9.12)을 준수하여 최대 256자의 길이 제한을 두고 있다.4

상호운용성 위험: 한 구현체가 256자를 초과하는 토픽 이름을 허용하더라도, 이를 다른 벤더의 구현체나 분석 도구(Analyzer), 혹은 제한된 메모리를 가진 임베디드 노드로 전송할 때 데이터가 잘리거나(Truncation) 통신 오류가 발생할 수 있다.
ROS 2 연동 시의 주의점: ROS 2(Robot Operating System)는 DDS를 하부 미들웨어로 사용하며, 긴 네임스페이스 경로를 사용하는 경향이 있다(예: /robot1/left_arm/joint3/position_controller/command). 이러한 경로가 DDS로 매핑될 때 rt/와 같은 접두어가 추가되면서 256자 제한을 초과할 위험이 있으므로, 설계 단계에서 이름의 길이를 엄격히 관리해야 한다.8

2.2 문자셋(Character Set)과 인코딩

토픽 이름은 기본적으로 ASCII 문자셋을 기반으로 한다. OMG DDS X-Types 명세 등은 문자 데이터에 대해 ISO-8859-1 (Latin-1) 또는 UTF-8을 언급하지만, 식별자로서의 토픽 이름은 POSIX 파일 시스템 경로 규칙이나 C++ 식별자 규칙을 따르는 것이 안전하다.9

권장 문자: 영문 대소문자(A-Z, a-z), 숫자(0-9), 그리고 구분자로서의 슬래시(/), 언더스코어(_), 하이픈(-).
금지 및 주의 문자: 공백(Space)은 절대 사용해서는 안 되며, 일부 구현체나 툴에서 파싱 오류를 일으킬 수 있다. 또한 *, ?, [, ]와 같은 문자는 와일드카드 필터링 시 메타 문자(Meta-character)로 해석될 수 있으므로, 토픽 이름 자체에 포함하는 것은 지양해야 한다.10 유니코드(한글 등) 사용은 로컬 시스템 내에서는 작동할 수 있으나, 이기종 간 직렬화(Serialization) 과정에서 인코딩 불일치로 인한 예기치 않은 동작을 유발할 수 있으므로 피하는 것이 원칙이다.

3. 의미론적 구조화 전략

토픽 이름은 시스템의 논리적 구조를 반영해야 한다. DDS의 평면적(Flat)인 토픽 공간을 인간이 인지하기 쉬운 계층적 구조로 조직화하는 전략이 필요하다.

3.1 계층적 명명 규칙 (Hierarchical Naming)

파일 시스템처럼 계층을 나누어 관리하는 것이 표준적인 관례이다. 구분자로는 슬래시(/)가 가장 널리 사용되며, 이는 POSIX 경로와 유사하여 개발자에게 익숙함을 제공한다.6

권장 패턴:

계층 (Level)	설명	예시
Domain/Scope	전체 시스템 내의 대분류	`Avionics`, `FactoryA`, `HospitalZone1`
Subsystem	하드웨어 또는 논리적 모듈 단위	`Navigation`, `Conveyor`, `ICU_Monitors`
Function/Category	기능적 분류	`GPS`, `Motor`, `Vitals`
Data Name	구체적인 데이터의 의미 (명사)	`Position`, `RPM`, `HeartRate`

이러한 계층 구조는 관리자가 시스템 전체의 데이터 흐름을 시각화하기 쉽게 만들고, 향후 설명할 파티션(Partition)이나 필터링 기능을 사용할 때 강력한 패턴 매칭을 가능하게 한다.6

3.2 데이터 타입과 토픽 이름의 분리 (Decoupling)

초보 개발자가 가장 흔히 범하는 안티 패턴 중 하나는 데이터 타입(Type)의 이름과 토픽(Topic)의 이름을 동일하게 강제하는 것이다. 예를 들어, VideoFrame이라는 IDL 구조체를 정의하고, 이를 전송하는 토픽 이름도 VideoFrame으로 고정하는 경우이다. 이는 DDS의 재사용성을 심각하게 저해한다.11

설계 원칙: 타입은 데이터의 **구조(Structure)**를 정의하고, 토픽은 데이터의 **문맥(Context)**을 정의한다.
사례: Temperature라는 하나의 데이터 타입(float 값과 단위를 포함하는 구조체)은 EngineTemperature, CabinTemperature, AmbientTemperature라는 세 개의 서로 다른 토픽에서 재사용되어야 한다. 만약 토픽 이름을 타입 이름과 동일하게 한다면, 엔진 온도와 실내 온도를 구분하기 위해 EngineTemperatureType, CabinTemperatureType이라는 불필요한 중복 타입을 정의해야 하는 모순에 빠진다.

따라서 토픽 이름은 해당 데이터가 시스템 내에서 수행하는 ’역할’을 반영해야 하며, 그 데이터가 어떤 ’형태’를 띠는지는 타입 정보에 맡겨야 한다.

4. 논리적 격리: 파티션(Partition) 대 토픽 계층

토픽 이름을 통한 계층화는 직관적이지만, 런타임에 구조를 변경하기 어렵다는 단점이 있다. 예를 들어, RoomA/Sensor라는 토픽을 RoomB/Sensor로 변경하려면, 퍼블리셔와 서브스크라이버의 코드를 수정하거나 재설정 후 엔드포인트를 다시 생성해야 한다. DDS는 이를 보완하기 위해 **파티션(Partition)**이라는 강력한 논리적 격리 메커니즘을 QoS 정책으로 제공한다.12

4.1 파티션의 개념과 매커니즘

파티션은 도메인 참여자(DomainParticipant), 퍼블리셔(Publisher), 서브스크라이버(Subscriber) 레벨에서 설정할 수 있는 문자열 리스트이다. 데이터가 전달되기 위해서는 토픽 이름이 일치해야 할 뿐만 아니라, 퍼블리셔와 서브스크라이버가 소속된 파티션 문자열 중 **하나라도 일치(Intersection)**해야 한다.10

유연성: 파티션 QoS는 런타임에 동적으로 변경 가능하다. 이는 엔드포인트를 삭제하고 다시 생성하는 무거운 작업 없이, 데이터의 흐름을 즉시 제어할 수 있음을 의미한다.12
와일드카드 지원: 파티션 이름에는 *, ?와 같은 와일드카드나 POSIX fnmatch 스타일의 정규 표현식을 사용할 수 있다. 예를 들어, 서브스크라이버가 ZoneA/* 파티션에 가입하면, ZoneA/Section1, ZoneA/Section2 등 해당 패턴에 매칭되는 모든 퍼블리셔로부터 데이터를 수신할 수 있다.10

4.2 설계 트레이드오프: 언제 무엇을 사용할까?

표 4.1-1: 토픽 이름 내 구분과 파티션 QoS 비교

비교 항목	토픽 이름에 계층 포함 (예: RoomA/Temp)	파티션 QoS 사용 (예: Topic: Temp, Partition: RoomA)
주요 목적	데이터의 종류(Type/Meaning) 구분	데이터의 범위(Scope/Location) 구분
통신 매칭	이름이 정확히 일치해야 함	토픽 이름 일치 AND 파티션 교집합 존재
런타임 변경	불가능 (엔드포인트 재생성 필요 - 비용 높음)	가능 (메타데이터 업데이트 - 비용 낮음)
와일드카드	DDS 표준 구독 시 지원 미비 (별도 기능 필요)	파티션 매칭 시 강력한 와일드카드 지원
메모리 사용	각 토픽 이름별로 별도 리소스/히스토리 관리	동일 토픽 공유, 논리적 그룹만 분리
권장 사례	`CameraImage`, `LidarScan` 등 데이터 성격이 다를 때	`Floor1`, `Floor2` 등 같은 데이터를 구역별로 나눌 때

결론적으로, 데이터의 **‘내용(Content)’**이 다르면 다른 토픽 이름을 사용하고, 데이터의 **‘배치(Deployment)’**나 **‘논리적 그룹(Logical Group)’**만 다르다면 동일한 토픽 이름을 사용하되 파티션으로 구분하는 것이 최적의 설계이다.14

5. 데이터 입도(Granularity)와 검색(Discovery) 성능

토픽 구조화에서 가장 까다로운 결정은 “얼마나 잘게 쪼갤 것인가”, 즉 입도(Granularity)의 문제이다. 이는 시스템의 성능, 특히 초기 기동 시의 검색(Discovery) 트래픽과 직결된다.

5.1 세립도(Fine-grained) vs. 조립도(Coarse-grained)

세립도 (Fine-grained): 각 데이터 항목마다 개별 토픽을 할당한다. (예: Sensor/1/Voltage, Sensor/1/Current)
장점: 구독자가 필요한 데이터만 정확히 선택할 수 있어 대역폭 효율이 높다. 접근 제어(Security)를 정밀하게 설정할 수 있다.16
단점: 토픽 수가 수천, 수만 개로 늘어날 수 있다.
조립도 (Coarse-grained): 연관된 데이터를 하나의 구조체로 묶어 단일 토픽으로 발행한다. (예: Sensor/1/Status 토픽 내에 전압, 전류, 온도를 모두 포함)
장점: 토픽 수가 줄어들어 관리가 용이하다. 데이터 간의 시간적 동기화(Atomicity)가 보장된다.18
단점: 일부 데이터만 필요한 경우에도 전체 구조체를 수신해야 하므로 대역폭 낭비가 발생할 수 있다.

5.2 검색 포화(Discovery Saturation)와 성능 한계

DDS의 표준 검색 프로토콜(SPDP/SEDP)은 모든 참여자가 자신이 가진 엔드포인트(DataWriter/DataReader) 정보를 네트워크상의 모든 참여자와 교환한다. 교환해야 할 메타데이터의 양은 대략 $N_{participants} \times N_{endpoints}$ 에 비례한다.

토픽 수가 수천 개 이상으로 증가하면 ’Discovery Storm’이라 불리는 현상이 발생한다. RTI 등의 벤치마크 결과에 따르면, 토픽 수가 적을 때는 검색이 밀리초(ms) 단위로 완료되지만, 수천 개 단위가 되면 초(s) 단위로 지연되거나, 네트워크 버퍼 오버플로우로 인한 패킷 손실 및 재전송이 발생하여 CPU 사용률이 급증한다.20 특히, 각 토픽 이름 문자열이 모든 알림 패킷에 포함되므로, 긴 토픽 이름은 이 문제를 악화시킨다.23

5.3 해결책: 토픽 키(Key)와 인스턴스(Instance)의 활용

DDS는 이 딜레마를 해결하기 위해 키(Key) 개념을 제공한다. 수천 개의 센서에 대해 각각 Sensor/1, Sensor/2… 와 같이 별도의 토픽을 만드는 대신, SensorReadings라는 단일 토픽을 생성하고 데이터 구조체 내에 sensor_id 필드를 @key로 지정한다.

동작 원리: DDS는 동일한 토픽 내에서 키 값이 다른 데이터를 별도의 **인스턴스(Instance)**로 관리한다. 논리적으로는 수천 개의 채널이 존재하지만, 물리적인 토픽(및 검색 엔드포인트)은 하나뿐이므로 검색 트래픽이 획기적으로 감소한다.1
구독 필터링: 특정 센서 데이터만 필요한 구독자는 ContentFilteredTopic을 사용하여 sensor_id = 5와 같은 필터 조건을 걸면, 미들웨어 레벨에서 필터링되어 네트워크 부하 없이 원하는 인스턴스만 수신할 수 있다.25

따라서 대규모 시스템에서는 **“토픽은 데이터의 종류(Class)를 정의하고, 키(Key)는 데이터의 개체(Object)를 식별한다”**는 원칙을 따르는 것이 성능 최적화의 지름길이다.

6. 고급 구독 패턴과 와일드카드 한계 극복

많은 개발자가 MQTT의 sports/tennis/#와 같은 와일드카드 토픽 구독 기능을 DDS에서 기대한다. 그러나 DDS 표준은 기본적으로 토픽 이름에 대한 와일드카드 구독을 직접적으로 지원하지 않는다(즉, create_datareader("Sensor/*")와 같은 호출은 표준 API에 없다).27

6.1 왜 지원하지 않는가?

DDS는 정적 타입 강제(Static Type Safety)를 중시한다. Sensor/*에 매칭되는 토픽들이 서로 다른 데이터 타입을 가질 경우, 데이터 리더가 이를 처리할 방법이 모호해지기 때문이다. 또한, 모든 매칭되는 토픽에 대해 리더를 내부적으로 동적 생성하는 것은 실시간성(Real-time)을 저해할 수 있다.28

6.2 대안: MultiTopic과 Built-in Topic 활용

MultiTopic: 표준에 정의된 MultiTopic 기능은 여러 토픽의 데이터를 SQL 구문과 유사한 방식으로 결합하거나 선택할 수 있게 해주지만, 구현의 복잡성 때문에 모든 벤더가 이를 완벽하게 지원하지는 않는다.25
Built-in Discovery Topics: 시스템 내의 모든 토픽 목록을 동적으로 알고 싶다면, DDS가 내부적으로 발행하는 DCPSPublication이나 DCPSSubscription 빌트인 토픽을 구독하여 메타데이터를 모니터링할 수 있다. 이를 통해 현재 존재하는 토픽 이름을 파악하고, 필요한 토픽에 대해 동적으로 리더를 생성하는 애플리케이션 로직을 구현할 수 있다.27

하지만 가장 실용적인 해결책은 앞서 언급한 파티션 QoS 또는 **X-Types(Extensible Types)**의 상속 기능을 활용하여 타입 호환성을 유지하면서 유연성을 확보하는 것이다.9

7. 상호운용성을 위한 토픽 명명 (ROS 2 및 FACE 표준)

최근 DDS는 독립적으로 사용되기보다 ROS 2나 FACE와 같은 상위 프레임워크의 통신 계층으로 사용되는 경우가 많다. 이때는 해당 프레임워크의 명명 규칙을 DDS 토픽 이름에 매핑하는 규칙을 엄격히 준수해야 한다.

7.1 ROS 2 (Robot Operating System) 매핑 규칙

ROS 2는 DDS 토픽 이름 앞에 접두어(Prefix)를 붙여 네임스페이스를 관리한다.8

Topics: rt/ 접두어 사용 (예: rt/chatter)
Services: 요청은 rq/, 응답은 rr/ 접두어 사용
Parameters: rp/ 접두어 사용

DDS 툴을 사용하여 ROS 2 네트워크를 모니터링하거나, 비(非) ROS DDS 애플리케이션이 ROS 2 노드와 통신하려면, 반드시 이 접두어를 포함한 정확한 토픽 이름을 사용해야 한다. 또한 ROS 2의 노드 이름과 네임스페이스가 길어질 경우 DDS의 256자 제한에 걸리지 않도록 주의해야 한다.8

7.2 FACE (Future Airborne Capability Environment) 표준

국방 항공 소프트웨어 표준인 FACE는 TSS(Transport Services Segment) 계층을 통해 통신을 추상화한다. FACE 데이터 아키텍처는 개념적(Conceptual), 논리적(Logical), 플랫폼(Platform) 모델로 변환되는데, 최종적으로 DDS 토픽 이름은 FACE 설정 파일(Configuration)에 정의된 View나 Connection의 식별자와 매핑된다.32

FACE 환경에서는 개발자가 임의로 토픽 이름을 짓기보다, 시스템 통합(System Integration) 단계에서 정의된 구성 파일(DDS XML Configuration 등)을 통해 생성된 코드를 따르는 것이 일반적이다. 이 경우 토픽 이름은 FACE 인터페이스의 유니크 ID나 메시지 타입 이름을 포함하는 경우가 많다.34

8. 안티 패턴(Anti-Patterns)과 설계 체크리스트

마지막으로, 토픽 설계 시 반드시 피해야 할 안티 패턴들을 정리한다.11

God Topic (신 토픽): 시스템의 모든 데이터를 GlobalData라는 하나의 거대한 토픽과 Union 타입으로 처리하려는 시도. 이는 DDS의 필터링 효율성을 떨어뜨리고, 불필요한 직렬화/역직렬화 비용을 발생시킨다.
동적 이름 생성 (Ephemeral Topics): Log_20231027_120001과 같이 시간에 따라 이름이 바뀌는 토픽을 지속적으로 생성하는 것. 이는 엔드포인트 생성/삭제의 반복으로 인한 CPU 부하와 검색 트래픽 폭주를 유발하여 시스템을 불안정하게 만든다. 시간 정보는 토픽 이름이 아닌 데이터 페이로드(Payload) 내에 포함되어야 한다.
암호 같은 약어 사용: 대역폭 절약을 위해 Avionics/GPS/Position 대신 A/G/P와 같이 극단적인 약어를 사용하는 것. RTPS 프로토콜은 토픽 이름을 정수로 매핑하는 최적화를 수행하므로, 초기 검색 단계 이후에는 긴 이름이 대역폭에 영향을 주지 않는다. 가독성을 희생하면서 이름을 줄일 필요는 없다.

설계 체크리스트:

토픽 이름이 데이터의 ’상태(State)’를 명사형으로 표현하는가?
토픽 이름이 데이터 타입 이름과 분리되어 있는가?
전체 이름 길이가 256자를 넘지 않는가 (ROS 2 접두어 포함)?
유사한 데이터가 수천 개일 경우, 별도 토픽 대신 ’키(Key)’를 사용했는가?
논리적 격리를 위해 토픽 이름 변경 대신 파티션 QoS를 고려했는가?
이름에 공백이나 특수문자(와일드카드용 문자)가 포함되지 않았는가?

성공적인 DDS 시스템은 코드를 작성하기 전, 칠판 위에서의 토픽 설계에서 시작된다. 4.1절에서 다룬 원칙들은 단순한 이름 짓기가 아니라, 시스템의 데이터 모델을 정의하고 효율적인 통신 구조를 수립하는 아키텍처링의 핵심 과정임을 기억해야 한다.

9. 참고 자료

OMG Data-Distribution Service: Architectural Overview, https://d2vkrkwbbxbylk.cloudfront.net/sites/default/files/DDS_Architectural_Overview.pdf
Data-Centric Programming Best Practices: - RTI, https://www.rti.com/hubfs/docs/DDS_Best_Practices_WP.pdf
What Is DDS? - MATLAB & Simulink - MathWorks, https://www.mathworks.com/help/dds/gs/dds-conceptual-overview.html
Limit on DDS topic names - Stack Overflow, https://stackoverflow.com/questions/27970321/limit-on-dds-topic-names
Data Distribution Service for Real-Time Systems Specification - Object Management Group (OMG), https://www.omg.org/spec/DDS/1.1/PDF/
Topic Hierarchy and Topic Architecture Best Practices - Solace, https://solace.com/blog/topic-hierarchy-best-practices/
Topic Name [DDS Foundation Wiki], https://www.omgwiki.org/ddsf/doku.php?id=ddsf:public:guidebook:06_append:glossary:t:topicname
Topic and Service name mapping to DDS - ROS2 Design, https://design.ros2.org/articles/topic_and_service_names.html
Extensible and Dynamic Topic Types for DDS - Object Management Group (OMG), https://www.omg.org/spec/DDS-XTypes/1.1/PDF
PARTITION QoS Parameter [DDS Foundation Wiki] - OMG Wiki, https://www.omgwiki.org/ddsf/doku.php?id=ddsf:public:guidebook:06_append:02_quality_of_service:partition
Don’t Force Topic Names to be the Same as Type Names | Data Distribution Service (DDS) Community RTI Connext Users, https://community.rti.com/best-practices/dont-force-topic-names-be-same-type-names
3.2.5. Partitions — Fast DDS 2.14.5 documentation, https://fast-dds.docs.eprosima.com/en/2.14.x/fastdds/dds_layer/domain/domainParticipant/partition.html
RTI Connext Modern C++ API: dds::core::policy::Partition Class Reference - RTI Community, https://community.rti.com/static/documentation/connext-dds/7.4.0/doc/api/connext_dds/api_cpp2/classdds_1_1core_1_1policy_1_1Partition.html
1. Topics, Domains and Partitions — The Data Distribution Service Tutorial, https://download.zettascale.online/www/docs/OpenSplice/v6/html/ospl/DDSTutorial/topics-etc.html
Advanced Tutorial Using QoS to Solve Real-World Problems - DDS Foundation, https://www.dds-foundation.org/sites/default/files/DDS_Advanced_Ttutorial_00-T5_Hunt-revised.pdf
Difference between Fine-Grained and Coarse-Grained SIMD Architecture - GeeksforGeeks, https://www.geeksforgeeks.org/computer-organization-architecture/difference-between-fine-grained-and-coarse-grained-simd-architecture/
Difference between Fine-Grained and Coarse-Grained SIMD Architecture - Tutorials Point, https://www.tutorialspoint.com/difference-between-fine-grained-and-coarse-grained-simd-architecture
Finding the Right Data Granularity in Data Modeling and Data Warehousing - Medium, https://medium.com/@sathishdba/finding-the-right-data-granularity-in-data-modeling-and-data-warehousing-19e4644c418a
Coarse-grained vs fine-grained [closed] - Stack Overflow, https://stackoverflow.com/questions/3766845/coarse-grained-vs-fine-grained
Maximum number of DDS Topics that may be created in a single DDS Domain, https://stackoverflow.com/questions/15005702/maximum-number-of-dds-topics-that-may-be-created-in-a-single-dds-domain
1.1.3. Discovery Performance — RTI Connext Performance Benchmarks 6.1.0 documentation - RTI Community, https://community.rti.com/static/documentation/performance/benchmarks/srcDoc/pro/6.1.0/core/discovery/discovery_performance.html
DDS Discovery very slow | Data Distribution Service (DDS) Community RTI Connext Users, https://community.rti.com/content/forum-topic/dds-discovery-very-slow
Configuring Resource Limits in Connext DDS Micro - RTI Community, https://community.rti.com/kb/configuring-resource-limits-connext-dds-micro
What is the max. number of octets I can put into the topic_data for builtin topics? | Data Distribution Service (DDS) Community RTI Connext Users, https://community.rti.com/kb/what-max-number-octets-i-can-put-topicdata-builtin-topics
Content-Subscription Profile - OpenDDS 3.34.0-dev, https://opendds.readthedocs.io/en/master/devguide/content_subscription_profile.html
Question about Content Filtered Topic | Data Distribution Service (DDS) Community RTI Connext Users, https://community.rti.com/forum-topic/question-about-content-filtered-topic
Subscribing to the built-in topic “DCPSTopic” in DDS - Stack Overflow, https://stackoverflow.com/questions/15295220/subscribing-to-the-built-in-topic-dcpstopic-in-dds
How to subscibe to group of similar DDS topics using wildcard - Stack Overflow, https://stackoverflow.com/questions/34370274/how-to-subscibe-to-group-of-similar-dds-topics-using-wildcard
Data Distribution Service (DDS) - Object Management Group (OMG), https://www.omg.org/spec/DDS/1.4/PDF
ROS2 + DDS: A Field Guide to Interoperability - RTI, https://www.rti.com/blog/ros2-dds-a-field-guide-to-interoperability
Doubt in ROS-2 design document about topics - Robotics Stack Exchange, https://robotics.stackexchange.com/questions/97927/doubt-in-ros-2-design-document-about-topics
FACE Standard for Avionics Software | Ansys, https://www.ansys.com/industries/face-standard-aviation-software
(PDF) Model-based Code Generation for the FACE™ Technical Standard FACE Transport Service Segment (TSS) Type Specific Code and Configuration File A rmy FA CE™ TIM Paper - ResearchGate, https://www.researchgate.net/publication/327346918_Model-based_Code_Generation_for_the_FACE_Technical_Standard_FACE_Transport_Service_Segment_TSS_Type_Specific_Code_and_Configuration_File_A_rmy_FA_CE_TIM_Paper
Applying Transport Services Segment (TSS) Concepts, https://www.omgwiki.org/face/lib/exe/fetch.php?media=wiki:interop-wg:applying_tss_concepts_rev_b_no_comments.pdf
Anti-Patterns vs. Patterns: What Is the Difference? – BMC Software | Blogs, https://www.bmc.com/blogs/anti-patterns-vs-patterns/