From M2M to Sys2Sys
DDS Component Links Incompatible Network System Interfaces to Build Multisystem Applications
Eliminating the need for custom bridges between different protocols, be they non-real-time or real-time, a configurable bridge technology can link in different and legacy networks locally or globally.
TOM WILLIAMS, EDITOR-IN-CHIEF
Page 1 of 1
By now, the world is familiar with machine-to-machine (M2M) systems in which autonomous or semi-autonomous nodes communicate and share data over a dedicated network to operate as an integrated system even though the nodes may be distributed over a local area network or even across the Internet. In many cases, at least parts of these M2M systems can be implemented on real-time local area networks. Of course, nobody is going to pretend that real-time performance can be maintained between remote nodes that must communicate via TCP/IP over the Internet.
Another aspect of M2M systems is that they are mostly designed as an integrated, albeit distributed, application with a predetermined idea of their scope and purpose. To that end, the data that they exchange, be it real-time or non-real-time, is limited to a set of compatible data types and network protocols.
But now what if we want to integrate networked real-time systems into a sort of “system of systems?” Would we call that S2S or Sys2Sys? What if it were seen as an advantage to connect systems that had not even been designed with each other’s existence in mind, but afterward there was an advantage perceived in getting them to work together? Such integration could take place either in a local area network scenario where it would still be possible to maintain real-time behavior between systems, or between remote systems over the Internet where it would not.
Traditionally, the means of linking incompatible data boil down to two options: You can either go into the systems themselves and modify the interfaces to make them compatible, or you can build a bridge between them to translate the data types and protocols to meet the different interface requirements. The solution being offered by Real-Time Innovations with the latest release of their version of the Data Distribution Service network technology, RTI DDS 4.5, amounts to the bridging approach. However, it also maintains the real-time publish/subscribe model of the DDS side yet allows the integration of real-time or non-real-time technologies over its bridge called the Routing Service (Figure 1).
Developers can quickly build and deploy bridges between natively incompatible protocols and technologies using the Routing Service component from RTI.
DDS is networking middleware originated by the Object Management Group (OMG) that uses a publish/subscribe model for sending and receiving data among nodes on the network. Under publish/subscribe, sending nodes (publishers) need not send their messages to specific receivers; they are sent without knowledge of who the subscribers might be. Subscribers declare interest in receiving messages of a given topic or topics (e.g., temperature, pressure, etc.) without knowledge of who the publishers are. DDS also offers automatic discovery so that subscribers can find publishers that are offering topics of interest. In addition, it is also possible to specify message priorities and timing constraints.
The result is that DDS provides a high level of decoupling between individual components on the network, making integration of new components easier. This is especially notable when it comes to integrating systems that were never designed to interface with each other to begin with. As such large network projects as the DoD’s Global Information Grid (GIG) and the Smart Grid for the national energy system are being built out, it is especially important to be able to bring in legacy systems as well as systems that may seem upon later consideration to be important components to include without extensive redesign work.
Essentially, RTI’s DDS 4.5 has introduced a new network component that adheres to the capabilities to mediate between disparate applications. Using a new Adapter Software Development Kit (SDK), systems can build and deploy bridges to integrate DDS and non-DDS systems in a fraction of the time required to develop completely custom solutions. Bridges automatically inherit advanced RTI Data Distribution Service capabilities, including automatic discovery of applications; data transformation and filtering; data lifecycle management; and support across operating systems, programming languages and network transports. With more than 20 new Application Programming Interfaces (APIs), the Adapter SDK provides developers with a flexible tool to enhance the interoperability of their systems.
The component, called the Routing Service, comes with several pre-built interfaces such as one that supports the non-real-time Java Messaging Service (JMS), and another that supports the real-time CANbus technology. By using this bridging technology, for example, a CANbus node that needed data from the DDS network would be able, through the Routing Service, to automatically discover nodes on the DDS network that offered the data topics it was looking for. However, nothing on the CANbus side of the bridge would need to be modified. And the CANbus, being itself a real-time network, could work within the timing definitions supported by DDS.
On the other hand, a JMS network would interface the same way via the Routing Service but, being a non-real-time technology, would not operate in real time. Rather, it would most likely retrieve or supply status data needed for its applications. A similar situation would apply when interfacing different network systems over the globe by way of the Internet.
The RTI DDS middleware is implemented directly on top of the Universal Data Protocol (UDP), which allows the use of hardware multicast to send data efficiently in one network operation to a large number of clients simultaneously. The Internet protocol, TCP/IP, on the other hand, is a connection-oriented technology that is good at connecting a client to a server. Thus we can envision DDS real-time networks, perhaps with other real-time or non-real-time technologies, attached locally via the routing service and also linked to other network entities across the globe by way of the Internet (Figure 2).
DDS is extended with support for other integration standards, advanced information and routing capabilities and a set of tools and runtime services. This accelerates the integration of DDS applications with non-DDS applications and into systems of systems.
This becomes even more interesting as we move into cloud computing and its applications. Cloud computing, of course, depends on the “cloud,” which is the Internet, and its many connected services and devices. The actual cloud application is conceived in terms of the unique application idea that can make creative use of not only original code but also of the existing services and devices. Often, ideas for cloud applications originate or are enhanced because their creators discover unique services that can be integrated into what they are already doing in innovative ways. The ability to realize these ideas depends on the ease of integration. Once a service is already connected to the Internet, that is pretty straightforward. Getting disparate, isolated and incompatible nodes connected to the cloud where they can be discovered and utilized—and where, not to be forgotten, they can potentially charge for their services—is another matter.
RTI’s DDS is a serverless solution; it is a library that is fully embedded in the application. At present, it relies on the operating system and a hypervisor function to work with multicore processors. But it is also specifically designed to take advantage of a multicore architecture. For example, it is possible to set processor core affinity for selected threads, which allows them to confidently use that core’s Level 1 cache to enhance performance. And the higher priority threads assigned to a given core naturally execute ahead of the lower priority threads.
There is also support for query conditions under which messages, once received, are placed in a relational data structure. Then the application thread can, for example, simply request the latest track and position data of a target of interest where that data is automatically updated every time the message is received from the publisher, processed and stored in the local data structure where it is immediately available to the application.
From stand-alone devices to small networks to large real-time M2M systems and now to globally connected system to system applications, the ability to dynamically interface and connect these components will become ever more important to the growth of networked services.