Sources and open questions

These notes cover all three instalments. Contemporary documents, later recollections and my own interpretation do different work in this account. The references below identify the principal evidence; the remaining gaps are collected at the end so that they need not repeatedly interrupt the narrative.

SPLICE: documents and recollections

The starting documents are Max J. Ceuleers’s “Naar een andere Systeemopzet: ‘Flexibele Standaardisatie’” (Memo SEAT 335, Hollandse Signaalapparaten B.V., 4 January 1984, 6 sheets) and Maarten Boasson’s “Systeem Architectuur” (Memo SEAT 362, 29 February 1984, 21 pages). The former records the industrial problem and institutional backing; the latter describes the DDBM architecture. Maarten’s later “Database system” patent (EP 0 271 945 B1; related U.S. Patent 5,301,339) describes a more developed design and names him as sole inventor.

The three American venues in the spring of 1986 are recorded in my 2010 ECLIPS manuscript, which Maarten reviewed. They are the earliest presently identified presentations outside Signaal, not a precisely dated first publication of a demonstrably complete SPLICE system. The earlier chronology and the origin of the name rest partly on family recollection.

The main published accounts of the architecture are Maarten Boasson, “Architecture of Real-Time Systems,” pp. 44–53 in W. H. J. Feijen, A. J. M. van Gasteren, D. Gries and J. Misra (eds.), Beauty Is Our Business: A Birthday Salute to Edsger W. Dijkstra (Springer-Verlag, 1990); “Control Systems Software,” IEEE Transactions on Automatic Control 38(7), July 1993, pp. 1094–1106; and J. H. van ’t Hag, “‘Data-centric to the max’, the SPLICE architecture experience,” ICDCS Workshops 2003, pp. 207–212. The surviving SPLICE user and reference manuals from 2000 and 2001 document the later facilities.

Maarten’s inaugural lecture at the University of Amsterdam on 18 October 1996, Het onmogelijke duurt iets langer, supplies both the broader architectural argument and the acknowledgements of Max Ceuleers’s and Herman Driessen’s roles. My English translation, The impossible takes a little longer (PDF), is included in this repository. The approximate 1989 date, identification with TACTICOS and rejected alternative architecture rest on my information; the lecture independently confirms Driessen’s decision to adopt Maarten’s architecture for a new product generation.

The formal work includes Marcello M. Bonsangue, Joost N. Kok, Maarten Boasson and Edwin D. de Jong, “A software architecture for distributed control systems and its transition system semantics,” ACM Symposium on Applied Computing 1998, pp. 159–168; Roel Bloo, Jozef Hooman and Edwin D. de Jong, “Semantical aspects of an architecture for distributed embedded systems,” ACM Symposium on Applied Computing 2000, vol. 1, pp. 149–155; and Jaco C. van de Pol, “Expressiveness of Basic Splice,” CWI Report SEN-R0033, December 2000. The results concern restricted formal models, not proofs of the complete implementations.

The accounts of shared memory, Ethernet engineering, timestamping and extrapolation, my SPLICE-lite contributions, the abandonment of general quality-and-decay selection, and the Sun and Rijkswaterstaat demonstrations rest substantially on my recollection. Hans van ’t Hag supplied the recollection about the operational need that led to context data. My suggested division between his contribution and my father’s generalisation remains an interpretation, not established individual authorship.

NDDS and the formation of DDS

The principal early sources are Gerardo Pardo-Castellote and Stan Schneider, “The Network Data Delivery Service: A Real-Time Data Connectivity System,” CIRFFSS ’94, vol. II, NASA Conference Publication 3251, pp. 591–597, AIAA-94-0889-CP; and “The Network Data Delivery Service: Real-Time Data Connectivity for Distributed Control Applications,” IEEE International Conference on Robotics and Automation 1994, vol. 4, pp. 2870–2876. The first bears a 1993 copyright but was published in 1994. The surviving NDDS 1.11b, 2.0b and 2.1d manuals, carrying copyrights from 1996, 1998 and 1999, document naming, source precedence, timing, buffering, reliability and the evolution of the API. RTI’s corporate history supplies the 1991 founding and 1995 commercial milestones.

Pardo-Castellote’s Experiments in the Integration and Control of an Intelligent Manufacturing Workcell (Stanford PhD dissertation, June 1995; also SUDAAR 675), chapter 4, printed p. 90, compares SPLICE and NDDS. His “OMG Data-Distribution Service: Architectural Overview,” ICDCS Workshops 2003, pp. 200–206, cites Boasson’s article in describing DDS and keyed data; van ’t Hag’s SPLICE paper immediately follows it. These establish engagement by 1995 and convergence by 2003. They neither date a first encounter nor demonstrate that SPLICE influenced the original NDDS design.

Customer pressure from both user communities is part of my recollection. Mark Swick’s “A Sea-Worthy Standard: 20 Years of DDS for the U.S. Navy” (RTI, 14 March 2024) gives the clearest published account of the Navy’s role, but is a vendor retrospective. Joseph M. Schlesselman, Gerardo Pardo-Castellote and Bert Farabaugh’s “OMG Data-Distribution Service (DDS): Architectural Update,” MILCOM 2004, vol. 2, pp. 961–967, and their HPEC presentation of 22 September 2005 document the joint proposal, chronology and connection with Navy open architecture. They do not independently establish every part of the retrospective causal account. I did not participate in the original DDS negotiations.

The standards and their subsequent development

The principal specifications are OMG, Data Distribution Service for Real-time Systems, version 1.0 (December 2004), and Data Distribution Service (DDS), version 1.4 (April 2015). These supply the application contract, topics and keys, QoS, durability, lifecycle and ownership. DDS Data Local Reconstruction Layer (DDS-DLRL), version 1.4, and its catalogue entry document the later separation of the optional object layer.

The wire-protocol history uses DDSI-RTPS, version 2.0 (April 2008), version 2.5 (April 2022), and Stefaan Sonck Thiebaut et al., “Real-Time Publish Subscribe (RTPS) Wire Protocol Specification,” Internet-Draft, 22 February 2002. Vendor records document the 2009, 2010 and 2011 demonstrations. The much later arrival of routine mixed-vendor systems is my observation, not a date defined by those demonstrations.

The discussion of the wider standards family draws on Extensible and Dynamic Topic Types for DDS, version 1.3 (February 2020), and DDS Security, version 1.1 (2018). The OpenSplice 6 feature history records DDSI2 general availability and DLRL deprecation in the same release. The assessment of DLRL’s limited adoption and bit rot also draws on my own experience.

The absence of a common transient and persistent durability protocol is documented in the deferred OMG issues DDSIRTP23-26 and DDSIRTP25-13, and the still-open DDSIRTP26-1. OpenSplice’s DDSI2 deployment guide and durability API documentation describe the architectural distinction between transient and transient-local retention. The observations about implementation costs, Cyclone DDS and Zetta DDS, and the uneven use of durability draw also on my implementation and standards experience. Product-status observations describe the situation considered in this 2026 account.

ECLIPS

The main source is my ECLIPS, a distributed data space with induced structure and capability-based protection (PDF), a 35-page manuscript dated 25 May 2010 and marked “Submitted to ACM TOCS, 2010-05-25”. A much shorter version, “ECLIPS, A Distributed Data Space with Induced Structure and Capability-based Protection,” appeared at the 22nd IASTED International Conference on Parallel and Distributed Computing and Systems, Marina del Rey, 8–10 November 2010.

The long manuscript supplies the model, the explicit thought-experiment qualification, its stated limitations, the construction of SPLICE in the appendix and the acknowledgements. It cites DDS 1.2 (2007); the comparisons here also use the later specifications listed above. The chronology of my thinking in the late 1990s and 2008–09, and the account of the current implementation experiment, are my own recollections and assessments. The placement of ECLIPS after DDS in this series is an order of exposition, not a claim that its design followed all the later DDS developments discussed here.

Zenoh as a contrasting direction

Zenoh’s overview states the aim of spanning microcontrollers through cloud environments while bringing publication, storage and queryable computation under common abstractions. Its manual of abstractions describes keys, key expressions, subscribers, queryables and storages; the Rust API overview describes publish/subscribe, query/reply and byte payloads. These support the description of the common access model. The contrast with ECLIPS—broader reach through fewer universal semantic commitments, compared with stronger relations among local replicas in a more restricted environment—is my interpretation of the designs, not a claim that one descends from or supersedes the other.

The account of Zenoh’s beginnings is my recollection: Angelo Corsaro initiated the DDS-XRCE process and drafted an early Zenoh design; I proposed a more compact DDSI-RTPS which went nowhere, then joined Angelo in refining Zenoh and implemented early versions, particularly Zhe. Much of the subsequent work was done by colleagues in the French office, with progressively less input from me as I concentrated on Cyclone DDS and eventually withdrew. The contemporary Zenoh design should not be attributed to me on the strength of that early involvement. Nor does the resemblance between Zenoh’s hierarchical naming and early NDDS establish descent from NDDS.

What remains to be established

The gaps fall into four groups:

SPLICE’s early chronology. Evidence of work before formal backing; the first prototype and its platform; the relationship of SigMA and the remembered Sun 3 and Atari Transputer experiments to operational TACTICOS; the transition from hardware DDBMs to software agents; and the first dated uses of sorts, keys, worlds and context data. The precise dates and contents of the 1986 presentations remain particularly valuable for the anniversary account. Contemporary notes, correspondence, diagrams, photographs or software could change this reconstruction.
The intermediate documentary record. The 1990 chapter cites Maarten’s “Software design and system architecture” (NATO workshop, Brussels, 1987), “Modeling in real-time systems” (Computer Standards & Interfaces 6(1), 1987, pp. 107–114), J. A. Droppert, H. B. M. Jonkers and H. M. H. Loomans’s A COLD-1 Specification of SPLICE (Philips NatLab, August 1989), and R. van der Land’s SPLICE Routing (Leiden, July 1989). Their recovery would narrow the gap between the early proposal and the mature descriptions. Contemporary Ethernet-loading calculations, timestamping-board documentation and records of the Sun and Rijkswaterstaat demonstrations would also help.
NDDS and the standardisation decisions. Early manuals and release notes could date API changes and the introduction of keys more exactly. Contemporary Navy evaluations and programme records could establish the decisive requirements and the contributions of customer representatives. The available record is better at naming corporate participants than at assigning particular parts of DDS and DDSI to individuals.
The limits of the historical interpretation. A product-by-product account of transient and persistent support, the unsuccessful durability proposals, and evidence of substantial early DLRL implementations beyond OpenSplice would strengthen or qualify the account. Examples of how applications actually handle identity, validity, authority, failover and reconciliation would test the architectural criticism more directly than another list of middleware features. ECLIPS itself still needs evidence about correctness and cost beyond the design argument and an exploratory implementation.