Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > EDA/IP

Real-time publish-subscribe now a standard

Posted: 01 Mar 2005 ?? ?Print Version ?Bookmark and Share

Keywords:dds standard? omg? qos? publish-subscribe? real-time systems?

Gerardo Pardo-Castellote of real-time innovations Inc. discusses the new options open to applications developers with the introduction of the data-distribution service standard.

The recently adopted data-distribution service (DDS) standard from the Object Management Group (OMG) brings publish-subscribe data-distribution technology to the world of networked real-time devices. The DDS standard unifies some of the best practices in existing publish-subscribe middleware. A key aspect of the DDS standard is the pervasive use of quality-of-service (QoS) to configure the system and introduce middleware-brokered QoS contracts between publishers and subscribers. QoS contracts provide the performance, predictability and resource control required by real-time and embedded systems while preserving the modularity, scalability and robustness inherent to the anonymous publish-subscribe model.

In June 2004, the OMG finalized the DDS specification for real-time systems. This is a significant addition to the portfolio of specifications addressing the needs of real-time systems. Despite the novelty, the underlying technology is well proven and is already successfully deployed in the industrial automation, transportation and defense sectors.

DDS enables applications to use a simpler programming model to deal with distributed data-centric applications. Rather than developing custom event/messaging schemes or artificially creating wrapper CORBA objects to access data remotely, the application can identify the data it wishes to read and write using a simple string label (the topic name) and use a data-centric API to directly read and write the data.

Data distribution

The classic distributed shared-memory model allows applications to access data remotely using simple read/write operations. However, these architectures do not scale beyond SMP computers or tightly-coupled clusters. The reason is that the random-access semantics of memory and the implied totally-reliable "instantaneous" response cannot be implemented transparently in a LAN or WAN where computers can join and leave and communication links can have sporadic faults. Hiding all these details from the application is not practicalthe model is simply not a good fit for the physical realities of a distributed system.

The publish-subscribe model, on the other hand, has steadily gained popularity in the context of distributed-systems programming. The key concept behind it is simple. Applications must be programmed in such a way that the declaration of intent to access the information (i.e. what the application wants to do) is separate from the information-exchange itself. This separation allows the middleware to "prepare itself," reserving all the needed resources such that the information access can be as efficient as possible.

In the context of DDS, the publish-subscribe approach means that the application must declare its intent of writing data and specify which data objects it wishes to write (i.e. define its publications). Similarly, it must declare its intent to read data and specify which data objects it intends to read (i.e. define its subscriptions) before it actually writes or reads the data itself.

A defining aspect of a publish-subscribe system is how the applications identify what they intend to publish or subscribe. Most publish-subscribe systems use a combination of an application-selected label (called a topic) and a filter on the content of the data itself. DDS uses a slightly more powerful approach that combines the topic, content and special field (the key) to identify each data object in the global data space.

The DDS specification was developed with the needs of real-time systems in mind. To this end, it defines a comprehensive list of QoS policies that allow the application to finely-tune the resources used by the system. Also, the DDS API includes a programmable callback mechanism designed to provide immediate notification to the user of any relevant data or status changes. This results in high performance in terms of latency and throughput.

The basic concept of publish-subscribe has been applied to communication services other than data distribution (i.e. event and message distribution). These other middleware technologies differ in that the information exchange model is message-centric instead of data-centric. In other words, the application architect cannot think in terms of being able to read or write data. Rather it is restricted to architect the system in terms of sending messages (or events) to other applications. In practical terms, this means that the data model will have to be built by the developer in a custom way at considerable engineering cost.

The DDS model, however, does support event propagation and messaging by means of special QoS settings. In that sense, the data-distribution model subsumes the capabilities of many event-distribution and messaging models.

Global data space

In data-centric systems, the information exchanges refer to reading and writing the values of global data objects. Given that new values typically override prior values, both application and middleware need to identify the actual instance of the global data object the value applies to. Hence, a publisher writing the value of a data object must have the means to indicate uniquely the data object it is writing. This way, the middleware can distinguish the instance being written and decide, for example, to keep only the most current value.

The combination of a fixed-type topic and a key is sensible for data-centric systems because the topic represents a set or related data objects that are treated uniformly (e.g. track information of aircraft as generated by a radar system), where each individual aircraft can be distinguished by the value of a data field (e.g. the flight number) which is interpreted as the key. Alternatively, a topic can be associated with a unique data stream (e.g. an alert) in the case where the topic does not define any keys.

The application-developer defines the format of the key for each topic using the OMG IDL language. The key may be a single value within the data object (e.g. a serial number field) or a combination of fields (e.g. airline name and flight number).

This use of a key is unique to data-centric systems and is neither used in "enterprise" publish-subscribe systems nor in event-distribution systems.

QoS policies

An important aspect of the DDS standard is the pervasive use of QoS policies to configure the system and the introduction of middleware-brokered QoS contracts between publishers (who offer a maximal level for each QoS policy) and subscribers (who request a minimum level for each QoS policy).

QoS contracts provide the performance, predictability and resource control required by real-time and embedded systems, and also preserves the modularity, scalability and robustness inherent to the anonymous publish-subscribe model.

Info exchange

The information transferred by data-centric communications can be classified into signals, state data and commands/events/messages.

Signals represent data that is continuously changing, such as the readings of a sensor. Signal publishers typically set the RELIABILITY QoS to best-efforts and HISTORY QoS to either KEEP_LAST.

State data represents the state of a set of objects (or systems) codified as the most current value of a set of data attributes (or data structures). The state of an object does not necessarily change with any fixed period. Fast changes may be followed by long intervals with no change. Consumers of state data are typically interested in the most current state. Moreover, as the state may not change for a long time, the middleware must ensure that the most current state is communicated reliably. Thus, if a value is missed, then it is not generally acceptable to wait until the value changes again. State-data publishers typically set the RELIABILITY QoS to reliable and HISTORY QoS to KEEP_LAST.

Commands/events/messages represent streams of the values, each having individual meaning that is not subsumed by subsequent values. They can be processed in either FIFO or priority order. Command/event/message publishers set the RELIABILITY QoS to reliable and HISTORY QoS to KEEP_ALL.

Many real-time applications have a requirement to model some of their communication patterns as a pure data-centric exchange where applications publish (supply or stream) data that is then available to any interested applications. These types of real-time applications can be found in C4I systems, industrial automation, distributed control and simulation, telecom equipment control and network management. Of primary concern to these real-time applications is the efficient distribution of data with minimal overhead and the ability to control QoS policies that affect the predictability, overhead and resources used.

The lack of standards in this area had forced application developers to use proprietary solutions or develop the infrastructure themselves. With the introduction of the OMG DDS as a real-time systems standard, there are now COTS products that provide this infrastructure with potentially great savings for the applications developers.

- Gerardo Pardo-Castellote

Real-Time Innovations Inc.

Article Comments - Real-time publish-subscribe now a st...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top