zerodds
Radikal transparent

Hard Truths

Wir sagen dir geradeheraus, wo wir stehen — denn jung, frisch und offen schlägt alt und undurchsichtig. Und überall, wo wir noch wachsen, gilt eine einfache Regel: das ist unser Job, nicht dein Risiko. Du findest ein Problem? Dann ist es unsere Aufgabe, es zu lösen.

Jung, frisch, ohne Altlasten

Ja — RTI gibt's seit 2008, Cyclone seit 2013, OpenSplice seit 2007. Wir nicht. Genau das ist die gute Nachricht: kein 20 Jahre gewachsener C++-Build-Zoo, keine Legacy-Schulden, kein behäbiger Release-Rhythmus. Wir bewegen uns schnell, der Code ist Pure-Rust und auditiert, Cross-Vendor-Wire-Interop läuft in der Default-CI, die Spec-Audits sind byte-genau.

Was die Etablierten an Field-Hours voraushaben, holen wir nicht mit Alter auf, sondern mit Tempo, Transparenz und Verantwortung: findest du eine Kante, ist sie unsere — nicht deine. Wer heute zwingend zwei Jahrzehnte Mil-Aero-Runtime hinter sich braucht, startet mit einem Pilot und wächst mit uns.

Safety-Cert: noch nicht — aber wir gehen den Weg mit dir

RTI Connext und Fast-DDS Pro haben heute Safety-Zertifikate (DO-178C, ISO 26262 ASIL-D). Wir noch nicht.

Was wir haben: eine auf Ferrocene aligned Toolchain (qualifizierter rustc, ASIL-D / SIL-3 / IEC 62304) — die Grundlage steht. Brauchst du das Cert auf Workspace-Ebene, gehen wir den Weg zum Class-Level mit dir, als Partnerschaft mit einem Cert-Body. Wir lassen dich damit nicht allein.

Transient/Persistent: Backend steht, die letzte Parität ist unser Job

Das Durability-Backend für TRANSIENT und PERSISTENT ist implementiert (crates/dcps/src/durability_service.rs, In-Memory + On-Disk, am Writer-Data-Path angeschlossen). Lokale Transient/Persistent-History funktioniert.

Ehrlich: die volle Cross-Vendor-Wire-Replay-Parität mit RTI Connext — einen entfernten Transient-Writer-History beim Late-Join nachladen — ist noch am Reifen, wie bei Cyclone und Fast-DDS OSS. Brauchst du sie für dein Szenario, sag es uns; sie zu schließen ist unsere Aufgabe, nicht dein Workaround.

Sprach-Bindings: jung, aber komplett

IDL-Codegen für C / C++ / Java / C# / TypeScript / Rust ist produktiv: aus einer .idl-Datei entstehen native, byte-genau wire-kompatible Datentypen je Sprache (idl-cpp + DDS-PSM-Cxx, idl-java + DDS-Java-PSM, idl-csharp, idl-ts, idl-rust + DdsType-Trait — zusammen über 900 Tests).

Runtime-Bindings (native DCPS-API in der Zielsprache: C++, C#, Java, Python, TS-Node, TS-WASM, plus die zerodds-c-api-FFI-Brücke) sind ausgeliefert und auf crates.io publiziert.

Die ehrliche Grenze ist Reife, nicht Vollständigkeit: für Sprachen wie Python hat die Konkurrenz mehr Field-Time, ihre Bindings sind eingelaufener. Findest du eine raue Kante, ist es unser Job, sie zu schleifen — nicht deiner, sie zu umschiffen.

Support: 24/7, weltweit — und du redest mit den Leuten, die den Code schrieben

Open-Source heißt bei uns nicht „viel Glück im Forum". Brauchst du garantierte Reaktionszeit, Audit-Trail, 24/7-Support in jeder Zeitzone und jedem Land — wir liefern das.

Als vertragliches Engagement, zugeschnitten auf dein Setup: ein vereinbarter SLA, dazu Integration, Migration, Architektur-Reviews, Custom-Development, langfristige Begleitung. Dein Code bleibt in deinem Repository, Apache 2.0 (oder kommerzielle Lizenz nach Wunsch).

Der Unterschied zu den Großen: bei uns landest du nicht in einer anonymen Ticket-Warteschlange. Du redest mit den Menschen, die den Code geschrieben haben. Was wir (noch) nicht haben, ist eine Support-Organisation in der schieren Größe eines 20-Jahre-Vendors — den SLA aber sehr wohl.

ROS 2: funktional grün, und drop-in

rmw_cyclonedds und rmw_fastrtps sind seit Jahren in ROS-2-Production. Unser rmw-zerodds ist ein drop-in RMW gegen die DCPS-Public-API von ZeroDDS — live gegen rmw_cyclonedds getestet (Talker/Listener bidirektional 20/20), eine Umgebungsvariable, kein Fork.

Ehrlich: dieselbe Field-Time wie die etablierten RMW-Layer haben wir nicht. Deshalb evaluierst du ZeroDDS-RMW als Pilot — und wenn dabei etwas klemmt, ist das Ticket bei uns, nicht bei dir.

QoS: alle 22 Policies, voll getestet — ohne XML-Kurs

Alle 22 Standard-DDS-1.4-QoS-Policies sind implementiert und unter Test (DCPS-1.4-Audit: 90 done / 0 partial / 0 open), cross-vendor verifiziert. Und du musst keine 20 XML-Tutorials durcharbeiten, bis Daten fließen: sinnvolle Defaults, und ein QoS-Mismatch scheitert laut — ein qos.incompatible-Event nennt die genaue Policy, statt still nichts zu liefern.

Der einzige reale QoS-Vorbehalt ist die Cross-Vendor-Durability-Replay-Parität (Sektion oben). Coverage-Matrix pro Policy: Spec-Coverage.

Bench — gegen alle vier OSS-Vendoren gemessen, und vorn

Roundtrip-Latenz im 5-Stack-Vergleich auf demselben Host, jeder Stack mit seinem eigenen vollen DCPS-Pfad — vanilla Linux, ohne RT-Tuning (der konservative Fall). Roh-Daten + Methodik: Performance-Vergleich.

Self-Roundtrip, 0-Byte-Payload, p50 / p99 (µs):

Die ehrliche Einordnung: das ist Same-Host-Loopback ohne RT-Tuning — kein Beweis für eine getunte Production-Umgebung. Gegen die kommerziellen Pro-Ligen (RTI Pro, Fast-DDS Pro mit Custom-Allocator / Lock-Free-Ring / SIMD-CDR) messen wir bewusst noch nicht, solange wir dort nicht ehrlich mithalten — diesen Schritt holen wir nach, nicht beschönigen.

Kurz gesagt

ZeroDDS spielt seine Stärken aus, wenn:

Und wenn du etwas brauchst, das heute anderswo reifer ist — eine Zertifizierung, jahrelange Field-Time: sag es uns trotzdem. Diese Seite ist der Beweis, dass wir transparent sind, wo wir stehen — und genau deshalb machen wir deine Anforderungen zu unserem Plan: Pilot, 24/7-SLA, Custom-Development, Einfluss auf die Roadmap. Wir wollen mit dir arbeiten, nicht dich wegschicken.

Reden wir

Schau dir die Features-Matrix an — und dann lass uns reden. Pilot, Migration, eine konkrete Anforderung für die Roadmap, ein Problem, das wir lösen sollen: alles willkommen über den Business-Kontakt. Bei uns ist dein Problem unser Job.