Topic · Vendor-Vergleich

Product Matrix

Vergleich von ZeroDDS gegen alle aktiv gepflegten DDS-Implementierungen, geordnet nach OMG-Profile (Lite / Full / Micro), dann Sprach-Bindings, Bridges, CORBA-Coexistence und Standalone-Spec-Stacks. Pro Zeile ein Spec-Anker; die Belegspalte verweist auf die zugehörige Audit-Doku unter spec-coverage/.

9 Vendor-Stacks · 8 Sektionen · ~80 Feature-Zeilen

Legende

✓ — vollständig implementiert, in produktiver Release.
◐ — partiell / Premium-Tier / Preview / nur über externen Service.
✗ — nicht implementiert / nicht angekündigt.
? — aus offizieller Vendor-Doku nicht verifizierbar.

Vendor-Claims gegen die jeweilige offizielle Doku verifiziert (Quellen-Links am Ende). Bei Evaluation bitte gegen die aktuelle Vendor-Version selbst gegenprüfen, weil Roadmap-Releases häufig schnell vorrücken.

1. Core DDS — Lite Profile

Mandatory-Baseline nach OMG-DDS 1.4 §2.2 + DDSI-RTPS 2.5: Wire-Format, Discovery, Reliable / Best-Effort, mandatory QoS (Reliability, History, Volatile + Transient-Local Durability).

Feature	Spec-Anker	ZeroDDS	Cyclone DDS 11	Fast-DDS 3.x OSS	Fast-DDS Pro	RTI Connext 7	OpenDDS 3.34	dust-dds
DCPS API	DDS 1.4 §2.2.2	✓ ⁽ᵃ⁾	✓	✓	✓	✓	✓	◐ ⁽ᵇ⁾
RTPS-2.5 Wire-Format	DDSI-RTPS §8	✓ ⁽ᶜ⁾	✓	✓	✓	✓	✓	✓
SPDP Discovery	DDSI-RTPS §8.5.3	✓ ⁽ᶜ⁾	✓	✓	✓	✓	✓	✓
SEDP Discovery	DDSI-RTPS §8.5.4	✓ ⁽ᶜ⁾	✓	✓	✓	✓	✓	✓
Reliable Protocol	DDSI-RTPS §8.4.2	✓ ⁽ᶜ⁾	✓	✓	✓	✓	✓	✓
Best-Effort	DDSI-RTPS §8.4.7	✓ ⁽ᶜ⁾	✓	✓	✓	✓	✓	✓
Fragmentation (DATA_FRAG)	DDSI-RTPS §8.3.7.3	✓ ⁽ᶜ⁾	✓	✓	✓	✓	✓	✓
QoS: Reliability	DDS §2.2.3.14	✓	✓	✓	✓	✓	✓	✓
QoS: History (KeepLast/All)	DDS §2.2.3.18	✓	✓	✓	✓	✓	✓	✓
QoS: Durability — Volatile	DDS §2.2.3.4	✓	✓	✓	✓	✓	✓	✓
QoS: Durability — Transient-Local	DDS §2.2.3.4	✓	✓	✓	✓	✓	✓	◐ ⁽ᵇ⁾

⁽ᵃ⁾ dds-dcps-1.4.md — 100 done / 0 partial / 0 open / 2 n/a, 557 Tests grün.

⁽ᵇ⁾ dust-dds (Pre-1.0): DCPS-Surface vorhanden, aber Subset der DDS-1.4-API. Spec-Coverage-Eigenangabe im dust-dds README nennt ~11/40 QoS-Policies + ausgewählte Features (basic Pub/Sub, Reliable, Transient-Local mit Limitierungen bei Late-Joiner-Replay). ContentFilteredTopic, MultiTopic, StatusConditions sind nicht vollständig. Aufgenommen als ◐, weil produktive Sample-Lieferung funktioniert, aber die ABI-Surface unvollständig zu DDS 1.4 §2.2.2 ist (siehe Anhang A.5).

⁽ᶜ⁾ ddsi-rtps-2.5.md — 121 done / 0 partial / 0 open / 3 n/a, 626 Tests grün.

2. Full Profile — Extensions

Über das Mandatory-Set hinaus: alle 22 Standard-QoS-Policies (DDS §2.2.3.x), XTypes 1.3 Type-System (TypeObjectV2 + TypeLookup + DynamicType + Assignability), DDS-Security 1.2, DDS-RPC 1.0, Object-Model-Layer DLRL.

2.1 Erweiterte QoS-Policies

Policy	Spec-Anker	ZeroDDS	Cyclone	Fast-DDS OSS	Fast-DDS Pro	RTI Connext	OpenDDS	dust-dds
Deadline	DDS §2.2.3.7	✓	✓	✓	✓	✓	✓	✗
Lifespan	DDS §2.2.3.16	✓	✓	✓	✓	✓	✓	✗
Liveliness	DDS §2.2.3.11	✓	✓	✓	✓	✓	✓	✗
Ownership — Shared	DDS §2.2.3.23	✓	✓	✓	✓	✓	✓	✓
Ownership — Exclusive	DDS §2.2.3.23	✓	✓	✓	✓	✓	✓	✓
Partition	DDS §2.2.3.13	✓	✓	✓	✓	✓	✓	✗
Content-Filter Topic	DDS §2.2.4.6	✓	✓	✓	✓	✓	✓	✗
Time-Based Filter	DDS §2.2.3.12	✓	✓	✓	✓	✓	✓	✗
Destination Order	DDS §2.2.3.18	✓	✓	✓	✓	✓	✓	✗
ResourceLimits	DDS §2.2.3.19	✓	✓	✓	✓	✓	✓	◐ ⁽ᵃ⁾
Durability — Transient (Service)	DDS §2.2.3.4	✓ ⁽ᵇ⁾	✗	✗	◐ ⁽ᶜ⁾	✓	◐ ⁽ᵈ⁾	✗
Durability — Persistent (Service)	DDS §2.2.3.4	✓ ⁽ᵇ⁾	✗	✗	◐ ⁽ᶜ⁾	✓	◐ ⁽ᵈ⁾	✗

⁽ᵃ⁾ dust-dds ResourceLimits sind aktuell nur partiell konfigurierbar — max_samples wirkt, aber max_instances + max_samples_per_instance sind in der dust-dds 0.x-Branch nicht voll im Cache-Backend verdrahtet. Quelle: Anhang A.5 + dust-dds-Repo Cache-Issue-Tracker.

⁽ᵇ⁾ ZeroDDS: DurabilityService voll wired. Transient nutzt InMemoryDurabilityBackend, Persistent OnDiskDurabilityBackend (Root via ZERODDS_DURABILITY_DIR Env-Var, Default $TMPDIR/zerodds-durability). Beide in crates/dcps/src/durability_service.rs, Writer-Store verifiziert in tests/durability_service_qos.rs. End-to-End-Wire-Replay an Late-Joiner für beide Stufen verifiziert in tests/durability_e2e_late_joiner.rs (Cache-Expansion für Replay-Burst + USER_PAYLOAD_ENCAP-Framing + Cache-Replay-Suppression für Backend-autoritative History).

⁽ᶜ⁾ Fast-DDS Pro: Persistence Service ist nicht im Open-Source-Build (Fast-DDS OSS), sondern Premium-Add-on bzw. Discovery-Server-Pre-built-Feature der eProsima-Subscription. Quelle: eprosima.com Subscription-Tier-Vergleich; siehe Anhang A.2.

⁽ᵈ⁾ Cross-Vendor-Interop für Transient/Persistent ist OMG-Spec-Lücke: DDSI-RTPS 2.5 spezifiziert die QoS (§2.2.3.4 Tab. 16), aber keine Wire-Mechanik für Late-Joiner-Replay über DurabilityService-Endpoints — jeder Vendor implementiert Persistence-Service-Discovery und Replay-Trigger proprietär. Belege: OMG DDS-RTPS Interoperability Tests Doc stellt fest, dass "the DDSI-RTPS specification does not currently specify how interoperable implementations should deal with Transient / Persistent data"; OMG-Issue-Tracker (DDSI-RTPS 2.0b1) hat das als deferred-Issue. OpenDDS-spezifisch: deren RTPS-UDP-Transport unterstützt Transient/Persistent nicht, nur die proprietären TCP-/UDP-Multicast-Transporte haben eine (laut Maintainer "buggy") Implementation (OpenDDS Discussion #4215); für OpenDDS 4 ist Removal von Transient/Persistent angekündigt, sobald sie auf RTPS-only umstellen.

2.2 XTypes 1.3 — Type System

Feature	Spec-Anker	ZeroDDS	Cyclone	Fast-DDS OSS	Fast-DDS Pro	RTI Connext	OpenDDS	dust-dds
IDL 4.x Parser	OMG IDL 4.2	✓ ⁽ᵃ⁾	✓	✓	✓	✓	✓	◐ ⁽ᵇ⁾
TypeObjectV2	XTypes §7.3.1	✓ ⁽ᶜ⁾	✓	◐ ⁽ᵈ⁾	◐ ⁽ᵈ⁾	✓ ⁽ᵉ⁾	✓	◐ ⁽ᵇ⁾
TypeLookup Service	XTypes §7.6.3.3	✓ ⁽ᶜ⁾	◐ ⁽ᶠ⁾	✓	✓	✓ ⁽ᵉ⁾	◐ ⁽ᵍ⁾	✗
DynamicType / DynamicData	XTypes §7.5	✓ ⁽ᶜ⁾	✓	✓	✓	✓	◐ ⁽ᵍ⁾	✗
Assignability Checks	XTypes §7.6.3.2	✓ ⁽ᶜ⁾	✓	✓	✓	✓	✓	◐ ⁽ᵇ⁾

⁽ᵃ⁾ idl-4.2.md — 649 done / 4 partial / 0 open / 24 n/a (informativ).

⁽ᵇ⁾ dust-dds (Pre-1.0): IDL-Parser deckt Subset von IDL 4.2 ab (keine vollständigen Templates, kein Annotation-Profile, kein Bitset/Bitmask). TypeObjectV2-Surface ist als Roadmap-Item markiert. Assignability nutzt strukturelle Type-Match-Heuristik, nicht den vollen XTypes §7.6.3.2-Algorithmus. Quelle: Anhang A.5 + dust-dds-Repo TODO-Tags.

⁽ᶜ⁾ dds-xtypes-1.3.md — 82 done / 0 partial / 0 open / 1 n/a, 330 Tests grün.

⁽ᵈ⁾ Fast-DDS OSS + Pro 3.x: TypeObjectV1 ist voll, TypeObjectV2 (XTypes 1.3 §7.3.1) ist im 3.x-Build partiell — Roadmap-Item für eProsima 4.0. Quelle: Fast-DDS Docs, Dynamic Types Section; siehe Anhang A.2.

⁽ᵉ⁾ RTI Connext 7.7 LTS (2026): TypeObject v2 ist Default-Wire-Repräsentation, der TypeLookup-Service (4 Builtin-Endpoints) löst vollständige TypeObjects inkl. aller Dependencies auf (seit Connext 6.0) (RTI Connext Docs, XTypes-Kapitel; siehe Anhang A.3).

⁽ᶠ⁾ Cyclone DDS 11.0.1: Basic-XTypes ja, TypeLookup-Service kann Type-Dependencies nicht abrufen — Matching schlägt bei unvollständigen Dependency-Sets fehl (Cyclone Docs, XTypes-Section; siehe Anhang A.1).

⁽ᵍ⁾ OpenDDS 3.34.x: TypeLookup-Service-API existiert, aber begrenzte Type-Dependency-Auflösung; DynamicType/DynamicData hat reduzierte API-Surface (keine vollständige Discovery aller Member-Annotations). Quelle: OpenDDS Devguide; siehe Anhang A.4.

2.3 Security & RPC

Feature	Spec-Anker	ZeroDDS	Cyclone	Fast-DDS OSS	Fast-DDS Pro	RTI Connext	OpenDDS	dust-dds
DDS-Security 1.1	DDS-Security 1.1	✓ ⁽ᵃ⁾	✓	✓	✓	✓	✓	✗
DDS-Security 1.2 (5 SPIs)	DDS-Security 1.2	✓ ⁽ᵃ⁾	◐ ⁽ᵇ⁾	◐ ⁽ᵇ⁾	✓	✓	✗	✗
DDS-RPC 1.0	DDS-RPC 1.0	✓ ⁽ᶜ⁾	✗	✗	✓	✓	✗	✗

⁽ᵃ⁾ dds-security-1.2.md — 50 done / 0 partial / 0 open / 3 n/a, 655 Tests grün, alle 5 Security-Plugin-Interfaces (Auth / AccessControl / Crypto / Logging / DataTagging) live.

⁽ᵇ⁾ Cyclone DDS und Fast-DDS OSS implementieren 4 der 5 Plugin-SPIs (Authentication, AccessControl, Cryptographic, Logging), aber DataTagging (DDS-Security 1.2 §9.7) ist nicht im Open-Source-Build. Fast-DDS Pro Premium-Tier hat DataTagging zusätzlich (Subscription-Feature). Quellen: Cyclone Security-Docs und Fast-DDS Security-Docs; siehe Anhang A.1 + Anhang A.2.

⁽ᶜ⁾ dds-rpc-1.0.md — 94 done / 0 partial / 0 open / 10 n/a.

2.4 Object-Model Layer

Feature	Spec-Anker	ZeroDDS	Cyclone	Fast-DDS Pro	RTI Connext	OpenDDS	OpenSplice
DLRL (Data-Local-Reconstruction)	DLRL 1.2	✓ ⁽ᵃ⁾	✗	✗	✗	✗	✓ ⁽ᵇ⁾

⁽ᵃ⁾ dlrl-1.2.md — Spec-Coverage.

⁽ᵇ⁾ Vortex OpenSplice (ZettaScale) — historischer DLRL-Vendor; einziger anderer aktiver Implementer.

3. Micro Profile — Resource-Constrained

Embedded / Microcontroller / Bare-Metal. Hier teilt sich der Markt in drei nicht-zusammenfallende Lager: full-DDS-mit-no_std (Connext Micro), DDS-XRCE-Client/Agent (eProsima Micro XRCE-DDS), und Pure-Rust-DDS-no_std-Subset. ZeroDDS ist der einzige Stack, der alle drei Lager auf einer Codebase abdeckt.

Feature	Spec / Anchor	ZeroDDS	Connext Micro	DDS-XRCE (eProsima)	Cyclone	Fast-DDS OSS	dust-dds
`no_std` / bare metal Build	–	✓ ⁽ᵃ⁾	◐ ⁽ᵇ⁾	✓	✗	✗	✗
Static-Wiring / Allocation-Free Hot-Path	–	✓ ⁽ᵃ⁾	✓	✓	✗	✗	✗
Full DDS 1.4 DCPS API auf Embedded	DDS §2.2.2	✓	✓	✗ ⁽ᶜ⁾	✗	✗	✗
DDS-XRCE Client	DDS-XRCE 1.0	✓ ⁽ᵈ⁾	✗	✓	✗	✗	✗
DDS-XRCE Agent	DDS-XRCE 1.0 §8	✓ ⁽ᵈ⁾	✗	✓	✗	✗	✗
Memory-Footprint < 100 KB Flash	–	◐ ⁽ᵉ⁾	✓ (~100 KB)	✓ (< 75 KB)	✗	✗	✗
RTOS Support (FreeRTOS / Zephyr / NuttX)	–	◐ ⁽ᵉ⁾	✓ (VxWorks/FreeRTOS)	✓	✗	✗	✗
ROS 2 / micro-ROS Backend	REP 2007/8/9	◐ ⁽ᶠ⁾	✓ (RMW Bridge)	✓ (micro-ROS Basis)	✓ (`rmw_cyclonedds`)	✓ (`rmw_fastrtps`)	✗
Pure-Rust (kein C-FFI im Kern)	–	✓	✗	✗	✗	✗	✓
Apache 2.0 License	–	✓	✗ (proprietär)	✓	✗ (EPL)	✓	✓

⁽ᵃ⁾ cargo build -p zerodds-foundation -p zerodds-cdr --target thumbv7em-none-eabihf ist Teil der Default-Pipeline (no-std Job).

⁽ᵇ⁾ RTI Connext Micro ist nicht bare-metal-tauglich, sondern RTOS-only (VxWorks, INTEGRITY, LynxOS, FreeRTOS via Connext Micro 4.x). Kein direkter no_std-/no-RTOS-Build. Quelle: RTI Connext Micro Documentation, Supported Platforms; siehe Anhang A.3.

⁽ᶜ⁾ Micro XRCE-DDS ist ein eigener OMG-Standard (DDS-XRCE), kein klassisches DDS — Clients reden mit dem DDS-Global-Data-Space über einen Agent (Broker), nicht peer-to-peer. Echte DDS-Peer-Interop nur über den Agent.

⁽ᵈ⁾ dds-xrce-1.0.md — 82 done / 0 partial / 0 open / 13 n/a, 301 Tests grün.

⁽ᵉ⁾ ZeroDDS-Subset auf thumbv7em-none-eabihf baut (Foundation + CDR + XRCE-Client). Footprint-Messung pro Crate-Auswahl noch offen.

⁽ᶠ⁾ ZeroDDS-RMW-Shim (crates/rmw-zerodds-shim/) als RMW-Layer-2-Implementation; static-wiring-Profil für ROS 2 noch nicht v1.x.

Beobachtung: Auf MCU-Targets, die gleichzeitig vollen DDS-Bus (Peer-to-Peer-RTPS) und XRCE-Agent-Brücke (zu Resource-stärkeren Netzen) brauchen, ist heute ein Multi-Vendor-Setup nötig: Connext Micro für DDS-Peer plus eProsima Micro XRCE-DDS für Broker-Variante. ZeroDDS deckt beide Spec-Familien (DDSI-RTPS 2.5 + DDS-XRCE 1.0) auf einer Codebase ab.

4. Language Bindings

DDS-PSMs nach OMG-Spec (C++ / Java) plus FFI- und Native-Sprachen.

Sprache	Spec-Anker	ZeroDDS	Cyclone	Fast-DDS OSS	Fast-DDS Pro	RTI Connext	OpenDDS	dust-dds	RustDDS
Rust (native)	–	✓	✗	✗	✗	✗	✗	✓	✓
C (FFI)	–	✓ ⁽ᵃ⁾	✓	◐ ⁽ᵇ⁾	✓	✓	✓	✗	✗
C++ — IS04 PSM	DDS-PSM-Cxx 1.0	✓ ⁽ᶜ⁾	✓	✓	✓	✓	✓	✗	✗
Java — IS04 PSM	DDS-Java-PSM 1.0	✓ ⁽ᵈ⁾	✓	✗	✗	✓	✓	✗	✗
Python	–	✓ ⁽ᵉ⁾	✓	✓	✓	✓	✗	✓ ⁽ᶠ⁾	✗
C# / .NET	–	✓ ⁽ᵍ⁾	✗	✗	✗	✓	✗	✗	✗
TypeScript / JavaScript	–	✓ ⁽ʰ⁾	✗	✗	✗	✗	✗	✗	✗

⁽ᵃ⁾ ZeroDDS C-FFI: crates/zerodds-c-api als cdylib + staticlib + rlib, 107 Tests in 6 Test-Files (abi_compat, smoke_ffi, xcdr2_c_codegen, xcdr2_c_compile, xcdr2_wire_vectors), läuft im CI test:-Job. Apex.AI-Plugin + ROS-2-RMW-Loader bauen darauf auf.

⁽ᵇ⁾ Fast-DDS OSS 3.x: C-FFI ist über eProsimas fastdds-c als Subset-API verfügbar — kein voller DDS-PSM-C nach OMG (formal/2018-04-01), sondern eProsima-spezifischer Wrapper. Pro-Tier bietet erweiterte C-API. Quelle: Fast-DDS Docs, C-Binding; siehe Anhang A.2.

⁽ᶜ⁾ dds-psm-cxx-1.0.md — 103 done / 0 partial / 0 open / 19 n/a, 134 Tests grün.

⁽ᵈ⁾ dds-java-psm-1.0.md — 71 done / 0 partial / 0 open / 16 n/a, 251 Tests grün.

⁽ᵉ⁾ ZeroDDS Python: crates/py PyO3-Wrapper + pytest-Suite in crates/py/python/tests/ (test_writer_lifecycle, test_shapesdemo_interop, test_multiproc, test_conditions, test_idl, test_qos, test_listener u.a.), läuft im dedizierten python-tests-CI-Job.

⁽ᶠ⁾ dust-dds Python-Binding via PyO3 — funktional, kein voller Language-Coverage.

⁽ᵍ⁾ ZeroDDS C# / .NET: voller Stack in crates/cs/csharp/ — ZeroDDS Hauptlib (4 689 LOC: Domain/Topic/Pub/Sub/Qos/Conditions/Listener + P/Invoke auf zerodds-c-api), ZeroDDS.Cdr (Xcdr2Writer/Reader, Md5), ZeroDDS.Cdr.SourceGenerators (Roslyn-Codegen). Tests in ZeroDDS.Cdr.Tests (Xcdr2WireVectorsTests.cs 649 LOC, AlignmentTests.cs, Md5Tests.cs) und ZeroDDS.Tests/Program.cs (live Pub/Sub). Lokal grün via crates/cs/csharp/build_cs_smoke.sh. Was fehlt: dedizierter dotnet test Job in .gitlab-ci.yml (Regression-Gate für die C#-Tests).

⁽ʰ⁾ ZeroDDS TypeScript / JavaScript: voller Stack in crates/ts-node/src/ (1 405 LOC: dds.ts, native.ts P/Invoke, cdr/writer.ts + reader.ts XCDR2, cdr/md5.ts KeyHash) und crates/ts-wasm/src/ (wasm-bindgen-Variante für Browser). Tests in crates/ts-node/test/ (smoke.test.ts, xcdr2-wire-vectors.test.ts) via node --test --import tsx. Was fehlt: dedizierter npm test Job in .gitlab-ci.yml.

5. Bridges — Cross-Protocol Gateways

Native ZeroDDS-Bridges als eigene Crates (kein externer Sidecar-Prozess). Die meisten anderen DDS-Vendors haben für Cross-Protocol externe Tools (ddsperf, ros1_bridge, …) statt First-Class-Bridges.

Bridge	Spec-Anker	ZeroDDS	Cyclone	Fast-DDS OSS	Fast-DDS Pro	RTI Connext	OpenDDS
DDS ↔︎ AMQP 1.0 + 0.9.1	DDS-AMQP 1.0	✓ ⁽ᵃ⁾	✗	✗	✗	◐ ⁽ᵇ⁾	✗
DDS ↔︎ MQTT 5.0 + 3.1.1	–	✓ ⁽ᶜ⁾	✗	✗	✗	◐ ⁽ᵇ⁾	✗
DDS ↔︎ CoAP (RFC 7252)	–	✓ ⁽ᵈ⁾	✗	✗	✗	✗	✗
DDS ↔︎ WebSocket (RFC 6455)	–	✓ ⁽ᵉ⁾	✗	✗	✗	✗	✗
DDS ↔︎ gRPC	–	✓ ⁽ᶠ⁾	✗	✗	✗	✗	✗
DDS ↔︎ OPC-UA	DDS-OPC-UA 1.0	✓ ⁽ᵍ⁾	✗	✗	✗	◐ ⁽ᵇ⁾	✗
DDS ↔︎ HTTP/REST (Web-Profile)	DDS-Web 1.0	✓ ⁽ʰ⁾	✗	✗	✗	◐ ⁽ⁱ⁾	✗
DDS ↔︎ Zenoh	–	✓ ⁽ʲ⁾	✓ ⁽ᵏ⁾	✗	✗	✗	✗
DDS ↔︎ ROS 2 (RMW)	REP-2007/2008/2009	✓ ⁽ᵐ⁾	✓	✓	✓	✓	✗

⁽ᵃ⁾ ZeroDDS bridged beide AMQP-Familien: 1.0 (OASIS) via amqp-endpoint + amqp-bridge, 0.9.1 (RabbitMQ-Default) via amqp-0-9-1 (alle Klassen + field-tables + content-properties, live gegen RabbitMQ 4.0). Spec-Coverage: dds-amqp-1.0.md (123 done / 0 partial / 0 open / 1 n/a, 70 Tests) + amqp-0-9-1.md (25 Tests); Detail in §7.1.

⁽ᵇ⁾ RTI Routing-Service ist proprietäres Pluggable-Adapter-Tool. ZeroDDS liefert einen eigenen nativen In-DDS-Routing-Service (zerodds-router) plus First-Class-Bridge-Crates.

⁽ᶜ⁾ ZeroDDS mqtt-bridge spricht MQTT 5.0 und 3.1.1 nativ (versions-aware Codec, Protocol-Level 4/5) inklusive Broker-Mode. Spec-Coverage: mqtt-5.0.md + mqtt-3.1.1.md; Detail in §7.2.

⁽ᵈ⁾ coap-rfc-7252.md — Spec-Coverage.

⁽ᵉ⁾ websocket-rfc-6455.md — Spec-Coverage.

⁽ᶠ⁾ grpc-protocol.md — Spec-Coverage.

⁽ᵍ⁾ dds-opcua-1.0.md — Spec-Coverage.

⁽ʰ⁾ dds-web-1.0.md — Spec-Coverage.

⁽ⁱ⁾ RTI Web-Integration ist Premium-Tier-Feature: RTI Web-Integration-Service + RTI Real-Time-Web-Toolkit. Kein nativer DDS-Web-1.0-Standard-Compliance, sondern proprietäre Web-Bridge. Quelle: RTI Web-Integration-Service Doku; siehe Anhang A.3.

⁽ʲ⁾ Zenoh-Bridge-Crate (kein eigener OMG-Spec-Anker, Wire-Mapping).

⁽ᵏ⁾ Cyclone-zenoh-Bridge ist ZettaScale-extern (zenoh-plugin-dds).

⁽ᵐ⁾ ZeroDDS-RMW-Shim (rmw-zerodds-shim): voll wired — rclpy-init + create_node + Pub/Sub-Roundtrip laufen live über ZeroDDS als RMW-Backend. Ein eigener RMW-Crate ist das Standard-Pattern (auch rmw_cyclonedds/rmw_fastrtps sind separate Packages). micro-ROS läuft über den parallelen xrce-client-Pfad (DDS-XRCE 1.0); Detail-Coverage siehe §7.8.

6. CORBA + DDS — Coexistence in beiden Welten

CORBA und DDS sind separate OMG-Welten mit Crossover. Sie teilen die IDL-Sprachfamilie und Annex-A-Mappings; OMG hat mit CCM 4.0 und DDS4CCM 1.1 eine offizielle Brücke spezifiziert. Im aktiven Markt liefert niemand sonst beide Welten nativ aus einer einzigen Codebase mit einer IDL-Toolchain — die nächstbesten Wege sind Ökosystem-Kombinationen (OCI: TAO + OpenDDS) oder Multi-Vendor-Setups:

ORB-Vendoren (TAO, omniORB, MICO, JacORB) liefern CORBA, kein DDS.
DDS-Vendoren (Cyclone, Fast-DDS, RTI Connext, OpenDDS) liefern DDS, CORBA-Coexistence allenfalls über separates Gateway-Produkt.
TAO+CIAO (DOC group) hat als einziger ORB einen CCM/DDS4CCM-Pfad — historisch über externes OpenSplice.
ZeroDDS liefert beides als First-Class-Implementation auf einer einzigen Rust-Codebase, kein Gateway-Hop.

Deshalb teilen wir hier in zwei Sub-Tabellen: erst ZeroDDS im ORB-Markt (gegen ORB-Vendoren), dann ZeroDDS als DDS+CORBA-Bridge (gegen Multi-Vendor-Setups).

6.1 Pure-CORBA-Stack — ZeroDDS im ORB-Markt

Komponente	Spec-Anker	ZeroDDS	TAO (ACE)	omniORB	MICO	JacORB
GIOP / IIOP 3.x Wire	CORBA 3.3 §15	✓ ⁽ᵃ⁾	✓	✓	✓	✓
IOR / Object References	CORBA 3.3 §13	✓ ⁽ᵃ⁾	✓	✓	✓	✓
POA (Portable Object Adapter)	CORBA 3.3 §11	✓ ⁽ᵃ⁾	✓	✓	✓	✓
COS Naming Service	COS 4.4	✓ ⁽ᵃ⁾	✓	✓	✓	✓
Interface Repository	CORBA 3.3 §10	✓ ⁽ᵃ⁾	✓	◐ ⁽ᵇ⁾	◐ ⁽ᵇ⁾	✓
CSIv2 (Security)	CORBA 3.3 §24	✓ ⁽ᵃ⁾	✓	✗	✗	✓
CORBA 3.3 IDL → C++ Annex A.1	CORBA 3.3 §A.1	✓ ⁽ᵃ⁾	✓	✓	✓	✗
CORBA 3.3 IDL → Java Annex A.4	CORBA 3.3 §A.4	✓ ⁽ᵃ⁾	✗	✗	✗	✓
Pure-Rust Implementation	ZeroDDS-CORBA-Rust 1.1	✓ ⁽ᵈ⁾	✗	✗	✗	✗
Apache 2.0 License	–	✓	✗ ⁽ᶜ⁾	✗ ⁽ᶜ⁾	✗ ⁽ᶜ⁾	✗ ⁽ᶜ⁾

⁽ᵃ⁾ corba-3.3.md — Spec-Coverage.

⁽ᵇ⁾ omniORB und MICO: Interface Repository ist als optionale separate Komponente verfügbar (omniInterfaceRepository für omniORB, MICO IR-Daemon), nicht in den Standard-Distribution-Bibliotheken eingebaut. Caller muss zusätzliches Binary + Konfiguration deployen. Quellen: omniORB Docs (IR Section), MICO Project.

⁽ᶜ⁾ TAO/ACE steht unter der permissiven DOC-Lizenz (BSD-artig), omniORB unter LGPL+BSD, MICO unter GPL/LGPL, JacORB unter LGPL — alle open source, aber keiner Apache 2.0; relevant für proprietären Bestand ohne Copyleft.

⁽ᵈ⁾ zerodds-corba-rust-1.1.md — ZeroDDS-Vendor-Spec (Pure-Rust-CORBA-Mapping + Codegen + Runtime).

6.2 DDS+CORBA Coexistence — wer hat beide Welten

Die Crossover-Frage. Welcher Stack liefert gleichzeitig vollwertiges CORBA + DDS + die offizielle Brücke (CCM/DDS4CCM)?

Komponente	Spec-Anker	ZeroDDS	TAO + CIAO	RTI Connext	OpenDDS	OpenSplice
CORBA 3.3 ORB nativ	CORBA 3.3	✓	✓	✗ ⁽ᵃ⁾	✗	✗
DDS 1.4 nativ	DDS 1.4	✓	✗ ⁽ᵇ⁾	✓	✓	✓ ⁽ᵐ⁾
CCM 4.0 Component Container	CCM 4.0	✓ ⁽ᶜ⁾	✓	✗	✗	✗
AMI4CCM (Async Method Invocation)	AMI4CCM 1.1	✓ ⁽ᵈ⁾	✓	✗	✗	✗
COS Event Service	COS Event 1.4	✓ ⁽ᵉ⁾	✓	✗	✗	✗
DDS4CCM (DDS-CCM-Bridge)	DDS4CCM 1.1	✓ ⁽ᶠ⁾	◐ ⁽ᵍ⁾	◐ ⁽ᵏ⁾	◐ ⁽ᵏ⁾	✗
DLRL (DDS-Object-Layer)	DLRL 1.2	✓ ⁽ʰ⁾	✗	✗	✗	✓
DnC (Deployment & Configuration)	OMG D&C 4.0	✓ ⁽ⁱ⁾	✓	✗	✗	✗
Eine Codebase / kein Multi-Vendor-Setup	–	✓	◐ ⁽ʲ⁾	✗ ⁽ᵃ⁾	n/a	n/a

⁽ᵃ⁾ RTI Connext hat keinen nativen CORBA-ORB. Das historische RTI CORBA Compatibility Kit war ein IDL-Type-Sharing-Add-on (kein Gateway, kein eigener ORB) und ist seit Connext 6.1.1 entfernt; CORBA kam über die OCI/TAO-Reseller-Partnerschaft. CCM/AMI4CCM/DDS4CCM/D&C liefert Remedy IT (CIAO/AXCIOMA) mit Connext nur als DDS-Backend — nicht RTI selbst.

⁽ᵇ⁾ TAO selbst hat keinen DDS-Stack; die DDS-Seite kommt vom Schwesterprodukt OpenDDS (gleicher Anbieter OCI) oder via DDS4CCM aus RTI Connext / OpenDDS.

⁽ᶜ⁾ omg-ccm-4.0.md — Spec-Coverage.

⁽ᵈ⁾ omg-ami4ccm-1.1.md — Spec-Coverage.

⁽ᵉ⁾ cos-event-service-1.4.md — Spec-Coverage.

⁽ᶠ⁾ dds4ccm-1.1.md — Spec-Coverage.

⁽ᵍ⁾ Die DDS4CCM-Referenzimplementierung lebt in CIAO (auf TAO), heute Legacy — Nachfolger ist AXCIOMA (Remedy IT). Unterstützte DDS-Backends: RTI Connext und OpenDDS.

⁽ʰ⁾ dlrl-1.2.md — Spec-Coverage (Cross-Ref §2.4).

⁽ⁱ⁾ Deployment-Spec referenziert in CCM-Coverage.

⁽ʲ⁾ TAO+CIAO ist OpenSource auf einer Codebasis, aber ohne nativen DDS-Stack — DDS kommt vom Schwesterprodukt OpenDDS (OCI) oder via DDS4CCM aus RTI Connext.

⁽ᵏ⁾ Kein nativer DDS4CCM-Layer im Produkt selbst; verfügbar als unterstütztes DDS-Backend unter Remedy ITs CIAO/AXCIOMA-Connectoren.

⁽ᵐ⁾ Vortex OpenSplice (ZettaScale): Community-Edition seit ~2021 eingefroren — ZettaScale lenkt Nutzer auf Cyclone DDS.

Beobachtung: Für gleichzeitig DDS + CORBA + CCM + DDS4CCM + DLRL aus einer einzigen nativen Codebase ist ZeroDDS aktuell allein. Die nächstbesten Wege sind Ökosystem-Kombinationen: OCI bündelt TAO (CORBA) + OpenDDS (DDS, gleicher Anbieter, technisch gekoppelt), und Remedy ITs CIAO/AXCIOMA liefert DDS4CCM auf RTI Connext oder OpenDDS. Beide verlangen mehrere Komponenten mit zwei IDL-Generatoren und decken DLRL nicht ab — das bietet nur OpenSplice, das seit ~2021 eingefroren ist. ZeroDDS' Unterschied ist nicht „die anderen können es nicht“, sondern: nativ in einer Pure-Rust-Codebase, ein IDL-Pfad, ohne Fremd-ORB oder abgekündigtes Add-on.

7. Standalone Foreign-Spec Implementations

ZeroDDS implementiert die Foreign-Specs als eigene Crates, nicht nur als DDS-Bridge. Jeder dieser Crates ist auch ohne DDS-Stack nutzbar — d.h. ein Pure-Rust AMQP-1.0-Endpoint, ein RFC-7252-CoAP-Server, oder ein HTTP/2-Stack ist als Library für jedes Rust-Projekt verfügbar.

Damit ist jeder dieser Crates auch ein eigener Markteintritt: er steht für sich auf crates.io, neben den etablierten Pure-Rust- und FFI-Implementationen der jeweiligen Spec. Die folgenden Abschnitte vergleichen ZeroDDS pro Spec mit diesen Alternativen.

7.1 AMQP 1.0 + 0.9.1

Eigenschaft	ZeroDDS `amqp-endpoint` + `amqp-0-9-1`	Apache Qpid Proton (C/Java/Python)	fe2o3-amqp (Rust)	lapin (Rust)
AMQP 1.0 Wire (OASIS)	✓	✓	✓	✗ ⁽ᵃ⁾
AMQP 0.9.1 Wire (RabbitMQ)	✓ ⁽ᵃ⁾	✗	✗	✓
Pure-Rust (kein C-FFI)	✓	✗ (C-Kern)	✓	✓
`no_std`-Tauglichkeit	◐ ⁽ᵇ⁾	✗	✗	✗
SASL Plain / Anonymous / SCRAM-SHA-256	✓	✓	✓	✓
TLS-Handshake	✓	✓	✓	✓
Apache 2.0 License	✓	✓	MIT	MIT/Apache 2.0
Standalone-Crate (ohne DDS-Dependency)	✓	n/a	✓	✓

⁽ᵃ⁾ ZeroDDS deckt beide AMQP-Familien ab: 1.0 (OASIS) via amqp-endpoint, 0.9.1 (RabbitMQ-Default) via amqp-0-9-1 (alle Klassen + field-tables + content-properties, live gegen RabbitMQ 4.0). Spec-Coverage: amqp-1.0.md + amqp-0-9-1.md. lapin spricht nur 0.9.1, fe2o3/Qpid nur 1.0.

⁽ᵇ⁾ ZeroDDS amqp-endpoint: no_std + alloc-tauglich via --no-default-features --features alloc; bare-metal-pur (ohne Heap) ist nicht möglich, weil AMQP-Frame-Buffer dynamische Größen brauchen (Vec). Default-Build ist features = ["std"] mit tokio-Listener. Quelle: crates/amqp-endpoint/Cargo.toml.

7.2 MQTT 5.0 + 3.1.1

Eigenschaft	ZeroDDS `mqtt-bridge`	Eclipse Paho (C/Java/Python)	rumqtt (Rust)	rust-mqtt (Rust no_std)
MQTT 5.0 Protokoll	✓	✓	✓	✓
MQTT 3.1.1 Backwards	✓ ⁽ᵃ⁾	✓	✓	✗ ⁽ᶜ⁾
Pure-Rust	✓	✗	✓	✓
Client + Broker-Mode	✓ ⁽ᵇ⁾	✓ (Paho + Mosquitto)	✓ (rumqttd)	✗ (Client only)
QoS 0 / 1 / 2	✓	✓	✓	✓
TLS / WebSocket Transport	✓	✓	✓	◐ ⁽ᶜ⁾
Apache 2.0 License	✓	✓ (EPL+EDL)	Apache 2.0	MIT/Apache 2.0

⁽ᵃ⁾ ZeroDDS mqtt-bridge: nativer version-aware 3.1.1-Codec (Protocol-Level 4) — CONNECT/CONNACK/PUBLISH/SUBACK/UNSUBACK/DISCONNECT im 3.1.1-Dialekt (keine Properties, 2-Byte-CONNACK, UNSUBACK ohne Reason-Codes). Interop bidirektional gegen Eclipse Mosquitto (-V mqttv311) belegt. Quelle: crates/mqtt-bridge.

⁽ᵇ⁾ ZeroDDS mqtt-bridge bietet den Bridge-Use-Case (DDS ↔︎ MQTT-Broker) UND einen Standalone-Broker-Mode (MqttBrokerServer): echte mosquitto_pub/mosquitto_sub-Clients (5.0 + 3.1.1) verbinden sich gegen den ZeroDDS-Broker; QoS 0/1/2, Retained, Wildcards, Will. Quelle: crates/mqtt-bridge.

⁽ᶜ⁾ rust-mqtt ist no_std-tauglich (embedded MQTT), unterstützt aber nur MQTT 5.0 — 3.1.1 ist nur als künftiges Feature gelistet. TLS läuft via embedded-tls auch im no_std-Profil; WebSocket-Transport fehlt ganz. Quelle: rust-mqtt Repo + docs.rs.

7.3 CoAP (RFC 7252)

Eigenschaft	ZeroDDS `coap-bridge`	libcoap (C)	aiocoap (Python)	coap-rs (Rust)	embedded-coap (Rust no_std)
RFC 7252 Core	✓	✓	✓	✓	✓
RFC 7641 Observe	✓	✓	✓	✓	◐ ⁽ᵃ⁾
RFC 7959 Block-Wise	✓	✓	✓	◐ ⁽ᵇ⁾	✗
DTLS-Pfad	✓	✓	✓	◐ ⁽ᵇ⁾	✗
Pure-Rust	✓	✗	✗ (Python)	✓	✓
`no_std`-Tauglichkeit	◐ ⁽ᶜ⁾	✗	✗	✗	✓
Standalone-Crate	✓	✓	✓	✓	✓

⁽ᵃ⁾ embedded-coap: Observe-Resource-Registry läuft, aber mit reduzierter Notification-Burst-Capacity (bare-metal-Constraint, Static-Buffer-Sizing). Quelle: embedded-coap Repo README + Cargo features.

⁽ᵇ⁾ coap-rs: Block-Wise-Transfer ist nur als Server-Side implementiert (Block2 Response-Split), kein Client-Side Block1-Upload. DTLS-Pfad ist als optionales Feature über openssl-Bindings, kein nativer rustls-Pfad. Quelle: coap-rs Repo.

⁽ᶜ⁾ ZeroDDS coap-bridge ist no_std + alloc-tauglich, aber nicht bare-metal-pur. Default-Build ist features = ["std", "daemon"]; für embedded Targets --no-default-features --features alloc aufrufen — dann liefert die Crate Wire-Codec, Reliability, Block-Wise, Observe und CoRE-Link-Format ohne std, braucht aber einen Heap-Allokator (Vec / String / BTreeMap). embedded-coap dagegen ist bare-metal (auch ohne Heap) — daher die Asymmetrie. Quelle: crates/coap-bridge/Cargo.toml Feature-Block + Crate-Doc.

7.4 WebSocket (RFC 6455)

Eigenschaft	ZeroDDS `websocket-bridge`	tungstenite-rs / tokio-tungstenite	ws-rs	actix-web-actors
RFC 6455 Frame-Format	✓	✓	✓	✓
RFC 7692 permessage-deflate	✓	◐ ⁽ᵃ⁾	✗	◐ ⁽ᵃ⁾
Server + Client-Mode	✓	✓	✓	✓ (server-only via actix)
TLS via rustls	✓	✓	◐ ⁽ᵇ⁾	✓
Pure-Rust	✓	✓	✓	✓
Frame-Length-Validation gegen DoS	✓	◐ ⁽ᶜ⁾	◐ ⁽ᶜ⁾	◐ ⁽ᶜ⁾
Apache 2.0 License	✓	MIT/Apache 2.0	MIT	MIT/Apache 2.0

⁽ᵃ⁾ tungstenite-rs und actix-web-actors: permessage-deflate ist als optionales Cargo-Feature (deflate) verfügbar; nicht im Default-Build. Caller muss explizit aktivieren. Quellen: tungstenite-rs Cargo.toml, actix-web-actors Repo.

⁽ᵇ⁾ ws-rs: TLS-Support nur über openssl-Feature (C-FFI-Build-Dependency), kein nativer rustls-Pfad. Crate ist seit 2020 unmaintained. Quelle: ws-rs Repo.

⁽ᶜ⁾ tungstenite, ws-rs, actix-web-actors: Frame-Size-Validation ist konfigurierbar (max_message_size, max_frame_size), aber Default ist unlimitiert / hoch genug, dass DoS-Caller via 64-MB-Frame Speicher allokieren kann ohne dass die Library blockt. ZeroDDS websocket-bridge hat strict-Default mit Frame-Limit auf 16 KB per Submessage, override-fähig. Quelle: jeweils Library-Default-Config in WebSocketConfig.

7.5 gRPC

Eigenschaft	ZeroDDS `grpc-bridge`	tonic (Rust)	grpcio (Rust, C-FFI)	grpc-go	grpc-java
gRPC Wire-Format	✓	✓	✓	✓	✓
Pure-Rust (kein C-FFI)	✓	✓	✗ ⁽ᵃ⁾	n/a (Go)	n/a (Java)
Native HTTP/2-Stack	✓ ⁽ᵇ⁾	✓ (h2)	✗ (gRPC-Core C)	✓	✓ (Netty)
Server + Client	✓	✓	✓	✓	✓
Streaming (uni / bi-direktional)	✓	✓	✓	✓	✓
Bridge zu DDS-Topics	✓	✗	✗	✗	✗
Apache 2.0 License	✓	MIT	Apache 2.0	Apache 2.0	Apache 2.0

⁽ᵃ⁾ grpcio wraps gRPC-Core (C++) via FFI — bringt C-Build-Toolchain mit.

⁽ᵇ⁾ ZeroDDS hat eigenen HTTP/2-Stack (crates/http2 + crates/hpack) — gRPC nutzt diesen direkt, kein externer h2-Crate notwendig.

7.6 HTTP/2 + HPACK

Eigenschaft	ZeroDDS `http2` + `hpack`	h2 (hyperium, Rust)	nghttp2 (C)	netty (Java)
RFC 9113 (HTTP/2)	✓	✓	✓	✓
RFC 7541 (HPACK)	✓	✓	✓	✓
Pure-Rust	✓	✓	✗	n/a
Server + Client	✓	✓	✓	✓
Backpressure (Flow-Control)	✓	✓	✓	✓
Frame-Length-Validation gegen DoS	✓	✓	✓	✓
Standalone-Crate (ohne gRPC-Bindung)	✓	✓	✓	✓
MIT/Apache 2.0 License	✓	✓	MIT	Apache 2.0

7.7 OPC-UA

Eigenschaft	ZeroDDS `opcua-gateway`	open62541 (C)	opcua-rs (Rust)	Eclipse Milo (Java)	UaSdk (Unified Automation, C++)
OPC-UA Binary-Encoding	✓	✓	✓	✓	✓
Server-Mode	✓ ⁽ᵃ⁾	✓	✓	✓	✓
Client-Mode	✓ ⁽ᵃ⁾	✓	✓	✓	✓
OPC-UA Pub/Sub (UDP/MQTT)	✓ ⁽ᵃ⁾	✓	✗ ⁽ᵇ⁾	✗ ⁽ᵇ⁾	✓
Bridge zu DDS-Topics	✓	✗	✗	✗	✗
Pure-Rust	✓	✗	✓	n/a (Java)	✗ (C++)
Apache 2.0 License	✓	MPL 2.0	MPL 2.0	EPL+EDL	proprietär

⁽ᵃ⁾ ZeroDDS deckt OPC-UA über vier native Pure-Rust-Crates ab: opcua-gateway erfüllt die OMG-DDS-OPCUA-1.0-Bridge vollständig (Type-System-Mapping §8.2 + §9.2, AddressSpace-Mapping §9.3 mit allen 25 Built-in-Types und NodeId-Identifier-Kinds, Service-Set-Mappings §8.3, Subscription-Notification-Assignment-Behavior §8.4.3 mit allen drei Assignment-Wegen); opcua-pubsub liefert den nativen OPC-UA-Pub/Sub-Part-14-Stack (UADP-Binär-Codec Part 6 §5, Network-Message-Framing, Carrier UDP/MQTT/AMQP/Kafka/Ethernet, Security mit AES-CTR/GCM + HMAC, Discovery 1 + 3 + SKS GetSecurityKeys, PubSub-Information-Model §9); opcua-uacp + opcua-server bilden den OPC-UA-Client/Server-Wire-Stack (Part 4 Services + Part 6 §7.1 UACP + Secure Conversation: SecureChannel/Session/Read/Write/Call/Browse/Discovery/Subscription, echter opc.tcp-E2E). Alles nativ in ZeroDDS — kein Caller-Layer. Spec-Coverage: opcua-pubsub-1.05.md + opcua-client-server-1.05.md.

⁽ᵇ⁾ Weder opcua-rs (Rust) noch Eclipse Milo (Java) implementieren OPC-UA-Pub/Sub (Part 14): beide sind reine opc.tcp-Client/Server-Stacks ohne UADP-Codec und ohne PubSub-Discovery (Milo: nur Client-/Server-SDK; opcua-rs: nur opc.tcp-Binärprofil). Quellen: opcua-rs compatibility, Eclipse Milo Repo.

7.8 ROS 2 RMW

Eigenschaft	ZeroDDS `rmw-zerodds-shim`	rmw_cyclonedds	rmw_fastrtps	rmw_connextdds	rmw_iceoryx
ROS 2 RMW Interface	✓	✓	✓	✓	◐ ⁽ᵃ⁾
REP-2007/2008/2009 (QoS-Mappings)	✓	✓	✓	✓	✗
Pure-Rust DDS-Backend	✓	✗	✗	✗	✗
Apache 2.0 License	✓	✓	Apache 2.0	proprietär (RTI)	Apache 2.0
`no_std` / micro-ROS-tauglich	◐ ⁽ᵇ⁾	✗	✗	✗	✗

⁽ᵃ⁾ rmw_iceoryx: ROS-2-RMW-Interface ist implementiert, aber nur für Zero-Copy-IPC-Topics innerhalb desselben Hosts via iceoryx Shared-Memory. Inter-Host- und Cross-Vendor-DDS-Wire-Interop ist nicht abgedeckt — iceoryx ist Host-lokal, kein RTPS. Quelle: Eclipse iceoryx Repo, ROS-2-rmw_iceoryx README.

⁽ᵇ⁾ rmw-zerodds-shim ist Linux- und Desktop-ROS-2-only — die Crate liefert eine cdylib für den AMENT-Loader und braucht std (Threads, dynamische cdylib-Loading-Pfade). Für micro-ROS nutzt ZeroDDS den parallelen Pfad über crates/xrce-client (DDS-XRCE 1.0 Spec, no_std + alloc). Daher ◐: voller ROS-2-RMW-Support, aber micro-ROS via separater Spec-Schicht, nicht via dem RMW-Shim selbst. Spec-Coverage: ros2-rmw.md.

7.9 Zusammenfassung

Standalone-Crate	Konkurrenz-Alternativen	ZeroDDS-Differenzierer
`amqp-endpoint`	qpid-proton, fe2o3-amqp	Pure-Rust + DDS-aware (Bridge ohne Sidecar)
`mqtt-bridge`	Paho, rumqtt, rust-mqtt	DDS-Bridge nativ + Apache 2.0
`coap-bridge`	libcoap, coap-rs, embedded-coap	DTLS + Block-Wise + DDS-Bridge in einer Crate
`websocket-bridge`	tungstenite, ws-rs	Frame-Length-DoS-Validation + DDS-Bridge
`grpc-bridge`	tonic, grpcio	Eigener HTTP/2-Stack (kein externer h2) + DDS-Bridge
`http2` + `hpack`	hyperium/h2, nghttp2	Pure-Rust + Apache 2.0, kein externer Async-Runtime nötig
`opcua-gateway`	open62541, opcua-rs, Milo	Pure-Rust + Apache 2.0 + DDS-Bridge nativ
`rmw-zerodds-shim`	rmw_cyclonedds/fastrtps/connextdds	Erstes Pure-Rust DDS-Backend für ROS 2

8. Extras — Build, Distribution, Compliance

Eigenschaft	ZeroDDS	Cyclone	Fast-DDS OSS	Fast-DDS Pro	RTI Connext	OpenDDS	dust-dds
Lizenz	Apache 2.0	EPL 2.0	Apache 2.0	proprietär	proprietär	Apache 2.0	Apache 2.0
Pure-Rust Implementation (zero C-FFI im Kern)	✓	✗	✗	✗	✗	✗	✓
`forbid(unsafe_code)` im Kern	✓	n/a	n/a	n/a	n/a	n/a	◐ ⁽ᵃ⁾
`no_std` Build-Profil	✓	✗	✗	✗	◐ ⁽ᵇ⁾	✗	✗
Zero-dependency Foundation Layer	✓	✗	✗	✗	✗	✗	✗
Toolchain-Pinning auf qualifizierte Channel	✓ ⁽ᶜ⁾	n/a	n/a	n/a	n/a	n/a	n/a
Safety-Cert (DO-178C / ISO 26262)	✗ ⁽ᵈ⁾	◐ ⁽ᵉ⁾	✗	✓	✓	✗	✗
Deterministische Build-Outputs	✓	◐ ⁽ᶠ⁾	◐ ⁽ᶠ⁾	◐ ⁽ᶠ⁾	◐ ⁽ᶠ⁾	◐ ⁽ᶠ⁾	✓
MSRV (Minimum Supported Rust Version)	1.88	n/a	n/a	n/a	n/a	n/a	varies
Cross-Vendor-Wire-Interop	✓ ⁽ᵍ⁾	✓	✓	✓	✓	✓	◐ ⁽ʰ⁾

⁽ᵃ⁾ dust-dds nutzt unsafe in low-level Networking- und FFI-Pfaden (Socket-Handles, raw-Pointer-Wrapper), nicht #![forbid(unsafe_code)] auf Crate-Ebene. ZeroDDS-Foundation-Crates haben forbid(unsafe_code) per-Crate-Attribut.

⁽ᵇ⁾ RTI Connext Pro selbst ist nicht no_std — nur die separate Connext-Micro-Linie (eigener Stack, kompatibler Wire-Format-Subset) bietet RTOS-Builds. Connext-Micro ≠ Connext Pro auf API-Level. Quelle: RTI Connext Micro Docs; siehe Anhang A.3.

⁽ᶜ⁾ rust-toolchain.toml referenziert Ferrocene 25.08.0.

⁽ᵈ⁾ ZeroDDS positioniert sich für Track-B / Expansion-Era auf einer Ferrocene-qualifizierten Toolchain (rustc 1.88 = Ferrocene 25.08.0, ISO 26262 ASIL-D / IEC 61508 SIL-3 / IEC 62304). Safety-Cert auf Workspace-Ebene ist Partnerschafts-Pfad jenseits v1.x.

⁽ᵉ⁾ ZettaScale Motionwise Cyclone DDS — kommerzielle Variante, ISO 26262 zertifiziert (Serien-Automobil), nicht identisch mit Open-Source-Cyclone.

⁽ᶠ⁾ C-/C++-/Java-Builds sind nicht bit-deterministisch by default: Compiler-Date-Stamps, File-Path-Embedding in Debug-Info, Linker-Order-Sensitivität, Strip-Variation. Reproducible-Builds (SOURCE_DATE_EPOCH, -ffile-prefix-map, deterministic-archives) erfordern explizite Build-Setup-Arbeit pro Vendor — keiner der OSS-DDS-Vendoren liefert das out-of-the-box. ZeroDDS' Pure-Rust-Stack mit gepinnter Ferrocene-Toolchain + RUSTFLAGS=--remap-path-prefix liefert reproducible byte-identical Builds direkt aus dem Default-Build-Profil.

⁽ᵍ⁾ Live-Interop-Job in der CI gegen Cyclone DDS + Fast-DDS (SPDP-Discovery + XCDR2-Roundtrip im Public-CI-Setup).

⁽ʰ⁾ dust-dds Cross-Vendor-Wire-Interop ist nicht via OMG-Interoperability-Test-Suite validiert (omg-dds/dds-rtps); eigene Interop-Tests existieren in dust-dds-Repo, aber kein offizieller Round-Trip-Beleg gegen die Top-4-Vendoren (Cyclone/Fast-DDS/Connext/OpenDDS).

Quick-Read — Was bleibt hängen

Wo ZeroDDS die einzige Option ist unter den hier verglichenen Vendors: - Pure-Rust mit voller QoS-Spec-Coverage (vs dust-dds 11/40 Features). - DLRL-Object-Model-Layer (außer OpenSplice niemand). - Native First-Class-Bridges für AMQP / MQTT / CoAP / WebSocket / gRPC / OPC-UA / Zenoh. - DDS + CORBA + CCM + DDS4CCM aus einer Codebase — TAO/CIAO ist die nächste Annäherung, aber ohne nativen DDS-Stack (siehe §6.2). Der einzige Stack ohne Multi-Vendor-Integrations-Aufwand für Telco / Finanzindustrie / Defense-Legacy. - DDS-XRCE Client + Agent zusammen mit no_std-Build-Profil.

Wo ZeroDDS gleichauf mit RTI Connext / Fast-DDS Pro liegt: - Voller XTypes-1.3-Stack (TypeObjectV2 + TypeLookup + DynamicType + Assignability). - DDS-Security 1.2 mit allen 5 Plugin-SPIs. - DDS-RPC 1.0 voll. - DDS-TSN 1.0 voll.

Wo ZeroDDS noch nachlegt (transparent — Roadmap): - Cross-Vendor Transient/Persistent — Wire-Replay-Pfad ist intern verifiziert (Transient + Persistent E2E, siehe §2.1 ⁽ᵃ⁾ und tests/durability_e2e_late_joiner.rs), aber Cross-Vendor-Interop ist OMG-Spec-Lücke (siehe §2.1 ⁽ᵇ⁾): kein Vendor liefert hier Cross-Stack-Interop. - CI-Test-Gate für C# / TypeScript Bindings — Stack ist voller Code (siehe §4 ⁽ᵉ⁾ ⁽ᶠ⁾), lokal grün, aber dediziertes dotnet test / npm test CI-Job ist noch nicht verdrahtet. - Safety-Cert auf Workspace-Ebene — Ferrocene-Toolchain ist als Vorbereitung gepinnt (siehe §8 ⁽ᵐ⁾), formale ISO-26262-/DO-178C-Cert ist Partner-Pfad jenseits v1.x.

Anhang A — Vendor-Quellen

Pro Vendor: Version, Primärdoku, Source-Code-Repo, Lizenz. Alle Footnote-Belege in den Sektionen oben verweisen primär auf diese URLs. Bei Evaluation gegen die jeweils aktuelle Vendor-Version gegenprüfen — Roadmap-Releases vorrücken regelmäßig.

A.1 Cyclone DDS (Eclipse)

Version assessed	0.10.x (2026 stable)
Primary Docs	cyclonedds.io/docs
Source Code	github.com/eclipse-cyclonedds/cyclonedds
License	EPL 2.0
Interop-Tests	omg-dds/dds-rtps participating

A.2 Fast-DDS (eProsima)

Version assessed	3.x (OSS) / Premium (Pro/Discovery-Server-Add-on)
Primary Docs	fast-dds.docs.eprosima.com
Source Code (OSS)	github.com/eProsima/Fast-DDS
License (OSS)	Apache 2.0
Pro / Premium-Tier	eprosima.com (Subscription)

A.3 RTI Connext

Version assessed	7.7 LTS (Connext Pro), Connext Micro (separater Stack)
Primary Docs	community.rti.com/static/documentation
Connext Micro Docs	community.rti.com/.../connext-micro
License	proprietär (kommerzielle Lizenz)
Source Code	nicht öffentlich (Subscription mit Source-Access für Connext Pro)

A.4 OpenDDS (Object Computing)

Version assessed	3.34.x
Primary Docs	opendds.readthedocs.io
Source Code	github.com/OpenDDS/OpenDDS
License	OpenDDS License (BSD-ähnlich, Apache-kompatibel)
Roadmap-Note	OpenDDS 4 plant Transient/Persistent-Removal bei Umstellung auf RTPS-only (siehe §2.1 ⁽ᵇ⁾)

A.5 dust-dds (S2E Software Systems)

Version assessed	0.x (Pre-1.0, aktiv entwickelt)
Primary Docs	README im Repo
Source Code	github.com/s2e-systems/dust-dds
License	Apache 2.0
Sprach-Coverage	Rust + Python-Binding (PyO3)

A.6 RustDDS (Atostek)

Version assessed	0.x (aktiv)
Primary Docs	README im Repo
Source Code	github.com/jhelovuo/RustDDS
License	Apache 2.0

Methodik

Vendor-Claims: verifiziert gegen offizielle Doku. Quellen siehe Footnoten in .
ZeroDDS-Belege: pro Zeile auf die zugehörige Audit-Doku unter spec-coverage/ verlinkt. Audit-Format folgt : Item-für-Item gegen die OMG-PDF mit Spec-Zitat + Repo-Pfad + Test-Pfad + Status (done / partial / open / n/a).
Tests: cargo test --workspace ist Teil der Default-Pipeline; pro Spec-Coverage-Doc ist der ausgeführte Test-Lauf mit Zähler ausgewiesen.
Bei Evaluation: Vendor-Roadmap-Releases vorrücken regelmäßig — bitte gegen die aktuelle Vendor-Version selbst gegenprüfen, insbesondere XTypes-1.3-TypeLookup und DDS-Security 1.2.