May 31, 2008

Extensible and Dynamic Topic Types for DDS

here The OMG DDS standard has been designed to effectively support statically defined data models. This assumption ensures that topics data types are known at compile time, that every member of the DDS global data space agrees precisely on the same topic-type association, and that extensions are captured by either DLRL classes inheritance, or by DCPS IS-A relations. Although this model allows for good properties such as static type checking and very efficient, low-overhead, implementation of the standard it also suffers a few drawbacks. Namely, it is hard to cope with data models evolving over time unless all the elements of the system are upgraded consistently. It is also complex to deal with dynamically defined topics, although in some case this is achievable by means of proprietary APIs.

These limitation are currently being addressed in the scope of the OMG RFP mars/2008-05-03, which is looking  to extend the DDS standard with the following features:

     Extensible Topic Type System. This will define an abstract type system for DDS Topics Type, that shall provide built-in support for extensibility, as well as support for complex types such as object maps, and sparse data.

     Dynamic DDS API. A Dynamic DDS API, to be used as an alternative to existing API, that shall allow to define, read, take, access, and write, Topics whose types are not know at compile time.

     Data Encapsulation Format. New data encapsulation format, or extend existing, so to efficiently support extensible and dynamic types.

The RFP is available here.



May 20, 2008

Webcasts: System Wide Interoperability for Next-Generation Air Navigation Systems - May 21st, 2008

Air Navigation Systems are increasingly being challenged by significant increases in traffic volume, which are projected to double by 2025. These systems also demand seamless information sharing to enable new operational requirements, such as ubiquitous and real-time access to flight data information and improved gate-to-gate services. Several programs in Europe and USA, such as the CoFlight European Flight Data Processor (eFDP), ICOG, SWIM, SESAR, and NEXT-GEN, are investigating how these challenges can be addressed from a technological and operational perspective. The OMG Data Distribution Service (DDS)—already embraced by programs such as CoFlight and ICOG-2—is emerging as a key standard technology for enabling system-wide interoperability since it can ensure the performance, availability, and determinism required by Air Navigation Systems. The webcasts will (1) explain what is motivating the swift adoption of DDS in next-generation Air Navigation Systems and (2) provide concrete examples of using OpenSplice DDS to solve challenging Air Navigation Scenarios.

I am running this webcast tomorrow, hope to see you there!


May 12, 2008

What is DDS?

In short, the Data-Distribution Service for Real-Time Systems (DDS), is QoS-enabled data-centric (topic-based) publish subscribe middleware. In order to understand what this means, let's try to explain every relevant bit of the above definition

Publish/Subscribe (P/S): P/S is a communication paradigm under which different parties, namely publishers and subscribers, can asynchronously and anonymously exchange information based on their interest. Under this communication paradigm Publishers produce data, while Subscribers consume the portion of data they are interested in. The interest is usually captured under the form of a subscription, and depending on how subscriptions are expressed we usually distinguish between Topic-based P/S, Content-based P/S, Subject-based P/S, etc. In Topic-based P/S, subscription are expressed by means of topics, which usually are identified by means of unique names and an associated (dynamic) type. On the other hand, in Content-based P/S subscriptions are defined by a matching-expression which identifies the property of produced data that are of interest for a subscriber.

Data-Centric: DDS is Data-Centric in the sense that it makes it possible to organize its Topics in a relational model, thus providing support for identity and relations. As such, for each Topic can be defined one or more primary keys, and one or more foreign keys representing respectively the instance and the relationships with other Topics. In a sense, a DDS Topic can be thought as specifying a database table, where the Topic key(s) uniquely identify a row, and the topic attribute define the table columns. In DDS jargon a database row is called a Topic Instance, while the stream of update to a specific Topic Instance are called Topic Sample.

In DDS subscription are referred to a Topic, to a content-filtered Topic or a MultiTopic. A Topic subscription is pretty straightforward as express the interest to receive all the instance for a specific topic. A content-based Topic subscription allows to subscribe to a Topic but to receive only the samples the match the provided SQL92 filter. Finally, a multi-topic subscription provides a mean to subscribe to the JOIN of two or more Topics.

Since DDS supports relational data-modeling, it should not come at surprise that it also provides an Object/Relational Mapping (ORM), which in this context is called Data Local Reconstruction Layer(DLRL). But to avoid overloading you with information I'll explore this in another post, for the time being it is good to know that such a feature is available!

QoS-Enabled: DDS provides an extremely rich set of Quality of Service Policies that allow to control the most important non-functional properties of the Topics, as well as of the entities that generate and consume them. As an example, it is possible to control the timeliness properties, such as, deadline, time-based-filter, and latency-budget, it is possible to control the importance of data, is durability, etc.

I believe this is enough information for the time being. I'll provide more detailed explanation in later posts, but this should (hopefully) give a first idea of what DDS is capable of. Before I forget, some useful resources on the DDS can be found at:

- DDS Standard Portal
- DDS Forum

There are also a few intro paper that have been written by various folks, one of the latest it this.


Why a DDS Blog?

It is now a few months that I was feeling the urge to start a blog on this extra cool new standard called "The Real-Time Data Distributions Service for Real-Time Systems", or DDS for short. I've been involved with DDS for the past few years, have had a chance to exploit it in rather challenging applications. There are a few goal I had in mind when creating this blog, and these were roughly (1) share what I've learned in applying DDS in mission- and business-critical distributes systems, (2) help in understanding what lays under the DDS iceberg tip, and (3) give heads-up on what's coming-up in the next standard revisions.