emrcnort
emrcnort

Reputation: 77

Data communication using RTI Connext DDS

There is a desktop application that is already compiled and I cannot access the source code. This application generates real flight data and provides the opportunity to send this data to desired sockets over the network.

I can receive this data with a program that I wrote using classic client-server methods (in C#). But I want to integrate DDS into my project and do this with RTİ Connext DDS.

I know that to use DDS, settings like "QoS" and "Topic" must be the same on both the publisher and the subscriber side. It seems easy to make these settings in my application that I created and will subscribe. But I can not access the source codes of the publisher application, so I cannot set parameters such as "QoS" and "Topic" for data communication in publisher side.

As a result of my research, I learned that I should do this using Routing Service. Can Routing Service provide data transmission between applications without QoS and Topic definitions? Or does it automatically make the necessary settings for data transmission?

I'm new to this and I'm trying to learn. I would be glad if someone helps me understand

Upvotes: 2

Views: 1050

Answers (1)

Reinier Torenbeek
Reinier Torenbeek

Reputation: 17383

One approach to integrate your existing application with a DDS-based system is by introducing an application that receives the data coming from your existing application and subsequently forwards it to the DDS Domain, after converting it to the expected format. RTI's Routing Service was designed to do that in a generic way, but you could also use your own C# program to do the same.

When using the Routing Service (RS), all necessary settings like Topic and type-names as well as QoS settings can be selected using a configuration file. The difficult part is the receiving of the data from your original application, because that is specific to your situation whereas RS is a generic component. Routing Service allows for inserting your own so-called adapter, which is basically a loadable plug-in responsible for reading the data from the existing application -- you have to code that yourself. Additionally, conversion of that data can be customized with a so-called processor, again a piece of software that you have to write yourself.

In your case, at this stage, it seems more appropriate to extend your C# application that reads the data using the classic client-server method and have it forward the data to the DDS Domain. For that purpose, you will have to define the DDS DataType in IDL (if you have not done so already) and let the RTI code generator generate the associated C# datatypes and strongly-typed C# DataWriter classes for publishing the data. Your application will have to listen for data coming from your existing (server) application, read it when it arrives, format it according to the C# datatypes generated by the DDS code generator and then forward it to your DDS DataWriter. The latter you can configure with the Topic and type-name as well as QoS settings according to your needs using the normal DDS mechanisms.

Once the data is forwarded to the DDS Domain by your extended C# application, other applications can subscribe to that data directly. Indeed, this is a matter of choosing the right Topic and setting the correct QoS policies. From your problem description so far, it does not look like you need the Routing Service.

Common examples when Routing Services are applied are:

  • When you are building systems of systems, Routing Service(s) can transparently forward DDS data between them -- a bit like an IP router does for IP traffic. Examples are layered databus architectures and systems that include different subnetworks or geographically dispersed DDS Domains that need to be interconnected.
  • If you want to import or export information to or from the DDS Domain from or to other types of "data domains", Routing Service provides a generic framework for that. This often requires customization of the plugins to do the required data transformations, like in your case. Other examples, supported out of the box, are integration with relational databases, for recording time-series or for capturing the current state of the DDS Domain.

Upvotes: 1

Related Questions