Tinverse logo Tinverse LLC

Sep 26, 2026

Why We Built Tin DDS: Replacing Black-Box Middleware in Regulated Robotics

If you lead software engineering or system architecture for a surgical robot, diagnostic machine, or safety-critical autonomous system, you have almost certainly encountered the middleware dilemma:

  1. The Black-Box Tax: You purchase proprietary middleware from traditional commercial vendors where the core is delivered as closed-source binaries. When you prepare your FDA 510(k), PMA, or IEC 62304 regulatory submission, that middleware sits in your design history file as SOUP (Software of Unknown Provenance). You cannot inspect the implementation, cannot step through memory allocation under an RTOS, and must reverse-engineer test campaigns to satisfy auditors.
  2. Planning an Integration: Teams need to understand delivery materials, access terms, support scope, and commercial terms before selecting middleware.
  3. The Open-Source Qualification Burden: If you turn to generic open-source DDS stacks, you inherit huge unverified codebases with frequent releases, no formal models, unverified zero-copy semantics, and zero regulatory evidence. You end up having to do the qualification, SOUP dossier creation, and fuzzing in-house.

We built Tin DDS (C++26) and Retina (Rust) to dismantle this tradeoff.


1. Evidence, Not Assurances

Tinverse can help prepare regulatory evidence packages scoped to your product and available engineering records.

  • Regulatory Evidence Support: We can help organize software development, risk management, SOUP, and verification evidence around your product requirements and intended use.
  • Formal Verification: Critical distributed state transitions (RTPS reliability and repair, discovery convergence, lease expiry, and shared-memory descriptor ownership) and pure deterministic properties (QoS compatibility, CDR layout predicates, and XTypes assignability) are verified using formal state-machine correctness proofs.
  • Bit-for-Byte Reproducibility: Every build is defined in hermetic, declarative build recipes, producing bit-identical binaries with cryptographically signed Software Bills of Materials (SBOMs) and provenance receipts.

2. Engagement Scoped to Your Program

Tell us about your target hardware, integration requirements, and evidence needs. We agree on delivery materials, access terms, engineering support, schedule, and commercial terms for each engagement.


3. Measured Performance Published with Its Caveats

Most vendors publish "hero numbers" on custom lab hardware without disclosing loss counters or measurement boundaries.

We publish our raw observations, delivery counters, compiler flags, and build identities. In our matched homogeneous ARM64 Linux cohort (64-byte sample, 2 processes, reliable UDP, 10,000 retained observations per run):

Middleware p50 One-Way p99 One-Way p99.9 One-Way Throughput
Tin DDS 0.1.0 (C++26) 5.20 µs 6.92 µs 10.50 µs 93,223 exch/s
Retina 0.1.0 (Rust) 6.43 µs 9.09 µs 10.91 µs 75,052 exch/s
Leading Open-Source Alternative B (0.10.4) 16.36 µs 18.65 µs 77.42 µs 30,006 exch/s
Leading Open-Source Alternative A (2.14.6) 19.26 µs 26.05 µs 40.56 µs 24,692 exch/s
Leading Commercial Alternative (7.7.0) 22.00 µs 34.00 µs 156.00 µs 22,464 exch/s

Every five-implementation test run completed all 10,000 measured exchanges with 0 reported packet losses.

For intra-machine communication, Tin DDS features daemon-backed shared memory with descriptor queues and explicit loan lifecycles, clocking raw descriptor notification at 412 ns.


4. What We Do Not Do (Our Explicit Gaps)

We believe radical transparency is the only way to build lasting trust with safety-critical engineering teams. Tin DDS is explicitly not a general-purpose, fleet-wide cloud DDS:

  • No WAN Routing or Cloud Traversal: Optimized strictly for on-robot and intra-machine real-time networks. If you need fleet-wide cloud routing over WAN, traditional enterprise WAN routers are the right tool today.
  • No Dynamic Schema Mutation: We support strict XTypes assignability and type identifiers, but live in-flight topic schema mutation is not supported.
  • No SQL Content Filtering: Content filtering uses application-supplied typed predicates and serialized validators, not dynamic SQL parsing.

5. Prove It on Your Hardware in 48 Hours

We do not ask engineering teams to believe marketing claims. We invite you to test us:

Send us your representative message types (.msg / .idl) and target QoS constraints. Within 48 hours, we will send you a reproducible test harness and a signed benchmark report showing your exact workload running on Tin DDS / Retina with p50/p99 latency, delivery counters, and every caveat in writing.

To get started, explore our Honest Comparison & Battlecards or reach out directly to engineering@tinverse.com.