Vergleichsstand: 2026-05

Features & Vendor-Vergleich

Acht thematische Tabellen, geordnet nach OMG-Profile (Lite / Full / Micro), dann Sprach-Bindings, Bridges, CORBA-Coexistence, Standalone-Spec-Stacks und Build-Extras. Pro Zeile ein Spec-Anker; die Belegspalte verweist auf die Audit-Doku im Source-Repository.

Legende. vollständig implementiert in produktiver Release. partiell, Premium-Tier, Preview oder externer Service. nicht implementiert. ? aus offizieller Vendor-Doku nicht verifizierbar.

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 ZeroDDS Cyclone 11 Fast-DDS 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 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: 100 done / 0 partial / 0 open / 2 n/a · 557 Tests grün.

² ddsi-rtps-2.5: 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, XTypes 1.3 voller Type-System-Stack, DDS-Security 1.2, DDS-RPC 1.0, DLRL.

2.1 Erweiterte QoS-Policies

Policy 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/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¹²

¹ ZeroDDS liefert Transient (in-memory) + Persistent (on-disk, übersteht Neustart) über den eingebauten DurabilityService; Late-Joiner-Replay ist e2e getestet. Cross-Vendor-Wire-Replay über RTPS ist eine OMG-weite Lücke — kein Vendor interoperiert Transient/Persistent über RTPS. Siehe Hard Truths.

² OpenDDS Transient/Persistent funktioniert nur über proprietären Transport, nicht über RTPS — Cross-Vendor-Interop limitiert auf Transient-Local.

2.2 XTypes 1.3 — Type System

FeatureZeroDDSCycloneFast-DDS OSSFast-DDS ProRTI ConnextOpenDDSdust-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: 649 done / 4 partial / 0 open / 24 n/a (informativ).

² dds-xtypes-1.3: 82 done / 0 partial / 0 open / 1 n/a · 330 Tests grün.

³ RTI Connext Pro (bis 7.x): TypeLookup + TypeObjectV2 nach XTypes 1.3 für nächstes LTS angekündigt.

Cyclone DDS 0.9.0: Basic-XTypes ja, TypeLookup-Service kann Type-Dependencies nicht abrufen.

2.3 Security & RPC

FeatureZeroDDSCycloneFast-DDS OSSFast-DDS ProRTI ConnextOpenDDSdust-dds
DDS-Security 1.1¹
DDS-Security 1.2 (5 SPIs)¹
DDS-RPC 1.0²

¹ dds-security-1.2: 50 done / 0 partial / 0 open / 3 n/a · 655 Tests grün, alle 5 Plugin-SPIs (Auth / AccessControl / Crypto / Logging / DataTagging) live.

² dds-rpc-1.0: 94 done / 0 partial / 0 open / 10 n/a.

2.4 Object-Model Layer

FeatureZeroDDSCycloneFast-DDS ProRTI ConnextOpenDDSOpenSplice
DLRL (Data-Local-Reconstruction) DLRL 1.2¹

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

3 · Micro Profile — Resource-Constrained

Embedded / Microcontroller / Bare-Metal. Drei nicht-zusammenfallende Lager: full-DDS-mit-no_std (Connext Micro), DDS-XRCE-Client/Agent (eProsima Micro XRCE-DDS), Pure-Rust-DDS-no_std-Subset. ZeroDDS deckt alle drei auf einer Codebase.

FeatureZeroDDSConnext MicroDDS-XRCECycloneFast-DDS OSSdust-dds
no_std / bare metal Build¹
Static-Wiring / Allocation-Free
Full DDS 1.4 DCPS API auf Embedded¹²
DDS-XRCE Client³
DDS-XRCE Agent³
Pure-Rust (kein C-FFI im Kern)
Apache 2.0 License

¹ ZeroDDS baut heute ein no_std-Subset (foundation / cdr / xrce-client) auf thumbv7em-none-eabihf in der Default-Pipeline; die vollständige DCPS-Micro-Edition für Embedded ist in Arbeit.

² Micro XRCE-DDS ist eigener OMG-Standard — Clients reden über einen Agent (Broker) mit der DDS-Global-Data-Space, nicht peer-to-peer.

³ dds-xrce-1.0: 82 done / 0 partial / 0 open / 13 n/a · 301 Tests grün.

4 · Sprach-Bindings

SpracheZeroDDSCycloneFast-DDS OSSFast-DDS ProRTI ConnextOpenDDSdust-ddsRustDDS
Rust (native)
C (FFI)¹
C++ (DDS-PSM-Cxx 1.0)²
Java (DDS-Java-PSM 1.0)³
Python¹
C# / .NET¹
TypeScript / JavaScript¹

¹ C, C#, Python und TypeScript sind ZeroDDS-Vendor-Bindings über das native zerodds-c-api-FFI (für diese Sprachen existiert kein formales OMG-PSM). C: direkt das c-api. C#: volles P/Invoke-DCPS-Runtime (Factory/Participant/Pub/Sub/Writer/Reader/QoS/Listener), NativeAOT-kompatibel, mit CDR-Source-Generators (crates/cs). Python: PyO3-DCPS-Runtime mit eigener Python-Testsuite (crates/py). TypeScript: koffi-N-API-Binding für Node mit voller DCPS-Oberfläche (crates/ts-node) plus ein Browser-WASM-XCDR-Codec (crates/ts-wasm).

² dds-psm-cxx-1.0: 103 done / 0 partial / 0 open / 19 n/a · 134 Tests grün.

³ dds-java-psm-1.0: 71 done / 0 partial / 0 open / 16 n/a · 251 Tests grün.

5 · Bridges — Cross-Protocol Gateways

Native ZeroDDS-Bridges als eigene Crates, kein externer Sidecar. Die meisten DDS-Vendoren nutzen für Cross-Protocol externe Tools.

BridgeZeroDDSCycloneFast-DDS OSSFast-DDS ProRTI ConnextOpenDDS
DDS ↔ AMQP 1.0¹
DDS ↔ MQTT 5.0¹
DDS ↔ CoAP (RFC 7252)
DDS ↔ WebSocket (RFC 6455)
DDS ↔ gRPC
DDS ↔ OPC-UA¹
DDS ↔ HTTP/REST (Web-Profile)
DDS ↔ Zenoh²
DDS ↔ ROS 2 (RMW)³

¹ RTI Routing-Service — proprietäres Pluggable-Adapter-Tool, kein nativer First-Class-Bridge.

² Cyclone-zenoh-Bridge ist ZettaScale-extern (zenoh-plugin-dds).

³ Eigener Pure-Rust rmw_zerodds-Shim (zerodds-ros2-rmw + C-FFI-Wrapper); REP-2003/2004-Mapping, ROS-2-Live-Interop bidirektional.

6 · CORBA + DDS — Coexistence in beiden Welten

CORBA und DDS sind separate OMG-Welten mit Crossover. Niemand sonst liefert beide Welten nativ aus einer einzigen Codebase — ORB-Vendoren liefern kein DDS, DDS-Vendoren kein CORBA. Am nächsten kommt OCI (TAO + OpenDDS, gleicher Anbieter) oder TAO+CIAO mit externem DDS — aber ohne nativen Ein-Stack-Pfad. ZeroDDS hat beides als First-Class auf einer Rust-Codebase.

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

KomponenteZeroDDSTAO (ACE)omniORBMICOJacORB
GIOP / IIOP 3.x Wire CORBA 3.3 §15
POA CORBA 3.3 §11
COS Naming Service
CSIv2 (Security)
CORBA 3.3 IDL → C++ Annex A.1
CORBA 3.3 IDL → Java Annex A.4
Pure-Rust Implementation
Apache 2.0 License¹¹¹

¹ omniORB ist LGPL+BSD, MICO ist GPL/LGPL, JacORB ist LGPL — Open-Source aber nicht Apache 2.0; relevant für proprietären Bestand.

6.2 DDS+CORBA Coexistence — wer hat beide Welten

KomponenteZeroDDSTAO + CIAORTI ConnextOpenDDSOpenSplice
CORBA 3.3 ORB nativ¹
DDS 1.4 nativ²
CCM 4.0 (Component Container)
DDS4CCM (DDS-CCM-Bridge)³
DLRL (DDS-Object-Layer)
Eine Codebase / kein Multi-Vendor-Setup¹n/an/a

¹ RTI Connext hat keinen nativen CORBA-ORB. Das historische RTI CORBA Compatibility Kit (IDL-Type-Sharing, kein Gateway) ist seit Connext 6.1.1 entfernt; CORBA kam über die OCI/TAO-Reseller-Partnerschaft, CCM/DDS4CCM via Remedy IT (CIAO/AXCIOMA).

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

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

TAO+CIAO ist OpenSource auf einer Codebasis, aber ohne nativen DDS-Stack — DDS via OpenDDS (OCI) oder 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.

Praxis: Für Bestände, die CORBA und DDS gleichzeitig sprechen (Telco, Finanzindustrie, Defense, Legacy-Telematik), deckt ZeroDDS beide Welten plus CCM/DDS4CCM aus einer einzigen Codebase ab — eine IDL-Quelle für beide Wire-Pfade, dieselben Sprach-PSMs, kein Multi-Vendor-Integrations-Setup.

7 · Foreign-Specs als Standalone-Crates

Jeder Bridge-Spec ist auch ohne den DDS-Stack nutzbar — als eigene Crate für jedes Rust-Projekt. Pure-Rust + DDS-Bridge nativ + Apache 2.0 sind die durchgängigen Differenzierer gegen die etablierten C-/Java-/Rust- Alternativen.

8 · Build, Distribution, Compliance

EigenschaftZeroDDSCycloneFast-DDS OSSFast-DDS ProRTI ConnextOpenDDSdust-dds
LizenzApache 2.0EPL 2.0Apache 2.0prop.prop.Apache 2.0Apache 2.0
Pure-Rust (zero C-FFI im Kern)
forbid(unsafe_code) im Kernn/an/an/an/an/a
no_std Build-Profil¹
Toolchain auf qualifiziertem Channel²n/an/an/an/an/an/a
Safety-Cert (DO-178C / ISO 26262)³
MSRV (Minimum Rust)1.88n/an/an/an/an/avaries
Cross-Vendor-Wire-Interop

¹ RTI Connext Micro ist separates Produkt für Embedded.

² Rust 1.88 = Ferrocene 25.08.0 (qualifiziert ISO 26262 ASIL-D / IEC 61508 SIL-3 / IEC 62304).

³ Workspace-Cert ist Partnerschafts-Pfad jenseits v1.x. Siehe Hard Truths.

ZettaScale Motionwise Cyclone DDS — kommerzielle Variante, ISO 26262 zertifiziert (Serien-Automobil).

Live-Interop-Job in der Default-CI gegen Cyclone DDS + Fast-DDS (SPDP-Discovery + XCDR2-Roundtrip).

Methodik

Vendor-Claims sind gegen offizielle Doku verifiziert (Stand 2026-05). ZeroDDS-Belege referenzieren die per-Spec-Audit-Doku im Source-Repository nach docs/spec-coverage/PROCESS.md: Item-für-Item gegen die OMG-PDF mit Spec-Zitat + Repo-Pfad + Test-Pfad + Status. Test-Counts stammen aus der Default-CI (cargo test --workspace).

Bei Evaluation: bitte gegen die jeweilige Vendor-Version selbst gegenprüfen. Roadmap-Releases vorrücken regelmäßig, insbesondere XTypes-1.3-TypeLookup und DDS-Security 1.2.