Connext DDS + Android Reply

Android is the dominant operating system in mobile, for both phones and tablets. As mobile eats away at the traditional desktop/laptop market, Android rivals Windows, Linux and Mac OSX as an operating system of major importance. Fueled by its application development eco system, Android is recruiting new developers at an unprecedented rate and those developers are innovating, creating novel application and taking Android into new places.

If we look past the Android Application Framework, we see an operating system that fits very well with the needs of embedded systems. Increasingly Android is being applied to such opportunities. So Android is becoming relevant, not only to the consumer aspect of the Internet of Things, but also to the industrial aspect. We expect to see a breakthrough in embedded device to cloud connectivity further driving new embedded applications.

To address the needs of developers, we have provided our distributed applications platform, RTI Connext DDS, on Android enabling the creation of publish and subscribe applications for the Industrial Internet of Things.

30dayFree trial rti connext dds professional

Let Your LabVIEW VI Go Mobile. 1

Picture1My smartphone has become an essential part of my life. Not only do I have my phone with me wherever I go, but it provides me with capabilities that touch all sorts of aspects of my day to day life. My current favorites:

  1. Provides me with instant access to my emails, and people with instant access to, well, me. (bit of a double-edged sword)
  2. Contains the information about all my different membership cards.
  3. Allows me to control my home (e.g. alarm system, lights, garage door), remotely.

But it doesn’t end there! I read books on my phone, check traffic, get directions, and take pictures. My phone even has become my boarding pass when I’m on travel. It makes me sometimes wonder if there’s anything my phone can’t do. There is.

I can’t just run any application that I am used to from my laptop or PC on my phone. Depending on what I used to create my application, I might not be able port it to my phone. Applications have to be re-written in a language. LabVIEW is a great tool for for creating custom applications that interact with real-world data or signals in fields such as science and engineering. The graphic programming approach makes it easy to manipulate data and provide visualization of information. However I can’t run any LabVIEW programs on a phone or tablet. 

National Instrument’s LabVIEW programs are called virtual instruments, or VIs, because their appearance and operation imitate physical instruments, such as oscilloscopes and multimeters. LabVIEW contains a comprehensive set of tools for acquiring, analyzing, displaying, and storing data, as well as tools to help you troubleshoot code you write. In LabVIEW, you build a user interface, or front panel, with controls and indicators. Controls are knobs, push buttons, dials, and other input mechanisms. Indicators are graphs, LEDs, and other output displays. After you build the user interface, you add code using VIs and structures to control the front panel objects.

It just so happens that LabVIEW supports a variety of platforms (e.g. Linux, Windows) but unfortunately you can’t run a LabVIEW VI directly on a mobile (android or iOS) device. That’s unfortunate since my phone is almost always on me. Thankfully, National Instruments does provide a Data Dashboard for LabVIEW which is great to create a custom dashboard on mobile devices.

The Data Dashboard is as its name suggests: a dashboard to display information. The Data Dashboard communicates by networking deployed NI Shared Variables, LabVIEW Web Services with visual objects like graphs, meters, and switches among many other available controls and indicators.  If you’re developing a mobile application, this can offer you some great elements, but you need something more. What’s the value? What problem can it solve? A mobile application should to be more a Data Dashboard some buttons. What data is it operating on?

Applications on mobile devices can do more than just being a dashboard or front end for information. Sometimes you can add additional value to mobile application by making use of features provided on the devices. Location services is a common native feature that app developers leverage.  So how can I build an application that can leverage my mobile phone’s capabilities and run  on the mobile platform? Simple. I use the RTI DDS Toolkit for LabVIEW alongside RTI Connext DDS for mobile devices.

The RTI DDS Toolkit for LabVIEW and RTI Connext for mobile devices here is the perfect solution which allows for custom application which can take advantages of running on a mobile platform. 

Often it is not just mobile applications. In some cases you have legacy application or applications outside of LabVIEW which need to share information with the LabVIEW program. The same mechanism which can be used for mobile applications can also be used to interface with non LabVIEW applications. The RTI Connext solution also allows for easy interfaces with LabVIEW VIs from any non-LabVIEW application thanks to the use of DDS. The specification for DDS provides great capability for applications that want to leverage the distribution of state data. Not only can you specify the type of data of your interface but you can also specify the behavior of how that data will be delivered. For example you application can get the latest state information automatically when it starts up. No need to run queries. You can define how much historical data you want. This eliminates a lot of the programming otherwise needed to get the application in the right state at start-up.

labview-ecosystem connext DDS toolkit

Another advantage of using the RTI DDS Toolkit for LabVIEW is that the publish/subscribe pattern allows for multiple mobile applications to interface with the LabVIEW VI without having to change the VI or the VI’s configuration. This allows you to build completely open systems which can easily be extended with new applications without having to modify existing programs.

In some cases, it is not desired to have a degree of openness that allows for any application to publish or subscribe to data. With the new secure DDS standard which supports fundamental security techniques and fine granularity of control allows you to control what can be let out of the cyber world and what has to stay securely locked in. Secure DDS let you control who has the rights to see, publish, and subscribe to data on a per topic basis. This allows for building systems that are easily extendable but provide secure access to data. This is especially important when communicating through a public network.  Connext DDS Secure provides the world’s first standards-compliant, off-the-shelf messaging platform that delivers the security, performance and safety required for deployment of the Industrial Internet of Things. It complies with the new Data Distribution Service (DDS) Security specification from the Object Management Group (OMG).

Let’s look at an example how information can be shared between mobile applications and LabVIEW VIs. The first step is defining the interface between the mobile application and your LabVIEW VI. At the minimum there is status information from the VI to the mobile application and command like information from the application to the VI. In RTI Connext the data type would be specified in IDL, in LabVIEW as a cluster. Let’s assume we want to track some assets. The status information would contain it’s position (longitude and latitude), speed, and direction as compass heading (0-360 degrees). The type could be defined in IDL as follow:

struct status {
    float longitude;
    float latitude;
    float speed;
    long direction;

In LabVIEW the corresponding cluster looks like this:

labview vi cluster rti connext dds

Now that the interface is defined we need to create an application which subscribes to the status and the VI which publishes the status updates. The RTI DDS Toolkit for LabVIEW Getting Started Guide explains how to create a DDS writer for complex type. The example uses the created cluster as control for the input values. However in most applications the actual values will come from external sensors. So we have to create the cluster using the Bundle Function. The bundle function uses the cluster definition as reference and has inputs for the different cluster elements. Here is an example of creating the cluster:

labview vi cluster rti connext dds

The cluster is then passed to the RTI Connext Complex Data writer.

On the mobile platform the application can be developed like any other application using RTI Connext. The above example is for the status message from the LabVIEW VI to a mobile application. Additional messages can be used for information flowing in either direction. For messages from the mobile application the VI would be the subscriber and the mobile application would be the publisher.  The information would be received as a cluster in the VI and can be broken up in separate variables using the unbundle function similar to how the bundle function was used in the example above.

Once the data types are defined and the next step is to define the behavior of how data is delivered by fine tuning the DDS QoS settings as described in the following blog .

Don’t feel limited to the platforms LabVIEW supports when creating your system. The RTI DDS Toolkit for LabVIEW and RTI Connext DDS make it possible to take your system anywhere. The use of DDS allows you to develop global systems regardless of operating system, location, and programing languages. RTI Connext truly enabled your systems to work as one.

Create A P2P Distributed Application In Under 35 Lines Of C++11 Code! 7

If I had to give you one reason why C++ is king (and this isn’t changing anytime soon) it would be this: C++ lets you create very powerful abstractions with zero or minimal runtime impact. Few languages can offer both.When designing your API, it’s critical that you take advantage of what the language has to offer – leveraging its strengths to enhance, among other things, its usability.

C++ is much more than C with classes, but we found that our existing RTI Connext DDS C++ API lacked this spirit. We didn’t take full advantage of its strengths, partly because we wanted to support old compilers. As a result, the API didn’t meet the needs of some of our users. Fortunately that’s going to change (very) soon!

I’m really excited to say that our new C++ API is receiving the attention it deserves. The new API, based on the OMG DDS C++ PSM includes what customers like you want to see in a modern C++ API. Designed with generic programming at its heart, the new C++ API is easy to use, STL-friendly, and ready for C++11.

To prove it, I’m going to show you how you can write your peer-to-peer distributed Hello World applications (publisher and subscriber) in under 35 lines of code, because fewer lines that do more mean less code to maintain and fewer chances to write bugs.

void publisher()
    DomainParticipant participant (0);
    Topic<StringTopicType> topic (participant, "Hello World Topic");
    DataWriter<StringTopicType> writer(Publisher(participant), topic);

    writer.write("Hello, World!");

void subscriber()
    DomainParticipant participant (0);
    Topic<StringTopicType> topic (participant, "Hello World Topic");
    DataReader<StringTopicType> reader (Subscriber(participant), topic);

    ReadCondition read_condition (
            LoanedSamples<StringTopicType> samples = reader.take();
                std::ostream_iterator<const StringTopicType&>(std::cout, "\n"));

    WaitSet waitset;
    waitset += read_condition;

    while (1) {

If you’re familiar with DDS, you probably know exactly what is going on. If you don’t, you just need to know briefly what these entities mean in the world of DDS:

  • A participant is the entity that lets you join a domain, which is a logical partition of the world identified by an ID.
  • A topic names what you are interested in (subscription) or what you know about (publication). A topic has a type associated to it.
  • A DataReader lets you receive data from a topic and a DataWriter lets you send data about a topic.

RTI Connext DDS takes care of matching subscribers and publishers of a topic and delivering data to the interested parties efficiently. Using WaitSets and Conditions is one of the patterns you can use to get notified about new data.

Basic DDS entities

DDS entities in our Hello World example

You can compare this code with a similar example in the current Connext DDS C++ API: publisher and subscriber.

You might first notice that we don’t need a single line of code for error checking or cleanup. The API throws exceptions in case of errors. You only need to handle exceptions if you have something useful to do—otherwise just let them propagate. Smart pointers manage entities such as the DomainParticipant or the DataReader and destructors take care of the cleanup for you. Even the LoanedSamples object, encapsulating data owned by the inner layers of the middleware, will return the loan in its destructor.

As I said before, generic programming dominates the API. In fact, we could have written this example for a generic data type T and barely changed anything else. If T is not a valid DDS type, you’ll find out at compile time, because the types you can use define the compile-time constant dds::topic::is_topic_type<T>::value to 1. No surprises at run-time!

The use of iterators lets us write pretty cool, succinct code, such as the call to std::copy—free of loops or conditions.

    std::ostream_iterator<const StringTopicType&>(std::cout, "\n"));

That code is equivalent to:

for (rti::sub::SampleRef<StringTopicType> sample : samples) {
    if ( {
        std::cout << << "\n";

First, iterators let us feed our data into any generic algorithm. By using an iterator adapter (valid_samples) we iterate only through samples that contain valid data. Finally, since we tell the compiler how to automatically get the data (T) from a SampleRef<T>, you don’t need to do it yourself.

Another new and interesting pattern in the API is the association of WaitSet Conditions and their handlers. The operation WaitSet::dispatch() directly calls the handlers of the active conditions—your application no longer needs to make that association as it would in the current API.

With compiler support, you can write your function as a lambda right where it matters.

As you can see, a lot has changed to make your code shorter, easier to maintain and use, and more robust. The best part is that none of these abstractions make the application run any slower.

This was just a small sample of the new C++ API. Please leave your comments and questions here or in the RTI Community. If you want to access to a preview version, contact us at UPDATE: The Modern C++ API is already available with RTI Connext 5.2