Understanding RTI Connext DDS Secure Reply

Our Connext DDS Secure product is generating unprecedented interest. We rarely see so much demand for, and curiosity about, a product. It’s especially unusual because the product is still in Beta yet customers are nonetheless planning to ship it asap.  I thought I’d answer a few of the most common questions.

First, the new DDS Security standard specifies a security architecture and model. The Beta standard was adopted in March by OMG. We (RTI) chair the finalization committee; it should be final next year. RTI is first with support for the new standard. I’m sure other DDS vendors will also implement it, but nobody else has a product yet.

DDS Security is unique in the middleware space for several reasons. First, it addresses security more completely than other standards. The specification covers authentication, access control, confidentiality, integrity, non-repudiation, and logging. Second, it has a “plug in” design. The spec defines a set of standard plug-in components and an interoperable wire spec. But, you can define your own algorithms for the plugins. Finally, it protects DDS “topics,” not nodes or connections. So, it offers fine-grain control and can adapt to the unique Industrial Internet of Things (IIoT) requirements. It’s the first security standard that targets IIoT device-to-device and device-to-cloud networks rather than human or server-centric architectures.

Perhaps an example will make this more clear. Consider this (very) simple system:

SecurityFig

Here, “PMU” represents a sensor (a phase measurement unit, common in power control).  The “CBM” (condition-based maintenance) analysis component is monitoring the system and looking for system health issues.  The simple operation of this system: the PMU sensor writes the state, the control reads that state and writes a set point. The CBM reads the state and writes alarms.  The operator can monitor the system.

In DDS, this system is easily set up as data flow between topics.  Of course, DDS specifies data rates, reliability requirements, and more.

To secure this system with Connext DDS Secure, you would create a configuration file that conveyed this:

PMU: State(w)
CBM: State(r); Alarms(w)
Control: State(r), SetPoint(w)
Operator: *(r), Setpoint(w)

This says, simply, that PMU can only write State.  Control can only read State and write SetPoint.  CBM can only read State and set Alarms.  And the operator can read anything and write the SetPoint (perhaps to turn off the system).  Connext DDS Secure directly enforces these very logical system constraints.

It really is that conceptually simple.  Of course, you still have to distribute certificates and the configuration file.  But, this “topic based” security is much more intuitive for IIoT systems than designs based on locking out protocols, or isolating nodes, or restricting access based on user roles.  Connext DDS Secure acts on the dataflow itself, directly and simply.

Importantly, our Connext DDS Secure product also doesn’t require any application code changes. You configure it & go. Connext DDS Secure offers practical, intuitive protection for existing systems.

Of course, no security protection is foolproof.  So, most all practical security systems combine protection (stopping bad things) with detection (finding and isolating breaches).  This is the reason, for instance, that your laptop has both a firewall (protection) and a virus scanner (detection).  Together, protection and detection provide much more secure systems.

DDS, being a software “DataBus”, also allows easy monitoring. We used that with PNNL to implement a “retrofit” security test for the power grid, replacing an old DNP3 line with a secure DDS line, thus implementing protection.  By tapping into the DataBus traffic and meta-traffic flow, we could then add a scripting capability (we have a slick Lua component).  Simple scripts could then detect many potential attacks, including compromised systems, man-in-the-middle attacks, etc. See http://blogs.rti.com/2014/06/05/how-pnnl-and-rti-built-a-secure-industrial-control-system-with-connext-dds/

So, DDS lets you combine protection (the standard) with detection (through the DataBus).  Both are relatively simple to implement.

Our product is currently in early access release.  However, it is already undergoing fire testing.  Here is one very extensive test activity:

The USS SECURE cybersecurity test bed is a collaboration between the National Security Agency, Department of Defense Information Assurance Range Quantico, Combat Systems Direction Activity Dam Neck, NSWCDD, NSWC Carderock/Philadelphia, Office of Naval Research, Johns Hopkins University Applied Physics Lab, and Real Time Innovations Inc. USS SECURE’s test bed determines the best combination of cyberdefense technologies to secure a naval combatant without impacting real time deadline scheduled performance requirements.

As you can see, our security product expects some really demanding customers.  We can’t tell you much about these tests for obvious reasons.  However, I can say that I am very proud of our Connext DDS Secure product.  At this, and many other sites, it is proving extremely effective.

RTI Connext DDS Secure will be generally available next year.  If you have questions, please ask your local rep…

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

Scaling Down: DDS into Sensor Networks Reply

london connext conference rti EMEA 2014

Connext Conference 2014 is taking place 8-9 October in London. To learn more or RSVP, visit http://www.rti.com/connextcon.

Below is an abstract of a talk that RTI plans to have available at the RTI Connext Users Group meeting, to be held in London next week (http://www.rti.com/connextcon).

RTI is a firm believer in the Data Centric model of Pub/Sub. Even in places we can’t yet reach.

When it’s a question of scale, customers of RTI generally ask about the macro abilities of Connext DDS: how far up, or how far out RTI Connext DDS will scale, looking to support thousands, tens of thousands or even millions of discrete points-of-presence across their systems of systems. Sometimes this happens at design time, sometimes this happens after deployment.

On the other hand, sometimes it’s scaling downwards. RTI Connext Micro and Connext Cert support applications running on devices with limited size, weight and power requirements, but these systems still assume a certain level of hardware and capability.

Yet, there is still room for more — or in this case, less!

RheinMain University (http://wwwvs.cs.hs-rm.de) in Wiesbaden, Germany, has spent years looking at using the OMG DDS standard in the sub-RTI Micro domain. Here is Kai Beckmann, Dipl.-Inform.(FH), M.Sc., discussing what they’ve been working on.

sDDS – An adaptable DDS Solution for Wireless Sensor Networks.

Wireless Sensor Networks (WSN, cf. ZigBee, 6LoWPAN) are maturing into real world applications, from classical environment monitoring, home automation and the internet of things to industrial automation scenarios. There are improvements regarding available hardware resources, but the energy consumption is yet a limiting factor, and so are the heterogeneous software and hardware platforms. The Data Distribution Service (DDS) provides a standardised interoperable data-centric publish/subscribe architecture with real-time capabilities, suitable for many data-centric WSN scenarios.

However, DDS is rooted in larger-scale architectures – the full middleware functionality generally exceeds the available resources on an average sensor node – and the RTPS network protocol is not tailored to the small network frames common to WSN. We therefore propose sDDS, a DDS implementation for minimal embedded systems found in WSN. A Model-driven software development (MDSD) process is utilised to specify the system structure and applications requirements of the DDS functionality, and to generate individual sDDS implementations for each node. Furthermore, we present SNPS as an alternative transport protocol for DDS communication, particularly in WSN scenarios. SNPS has been designed as part of sDDS, optimizing for minimal footprint and compatibility between sDDS instances with different subsets of functionality.

Longer term, I would like to work with RheinMain University, with the purpose of bridging their SNPS transport protocol into an RTPS-based, full RTI Connext DDS system — giving the full scale system direct, data-centric access to the WSN for the purposes of aggregation, C2 and HMI, and giving the WSN direct, data-centric access to full scale systems for off-node processing.

If the idea of data-centric Sensor Networks interest you, there’s still time to register to attend.

DDS, Security, Smart People, Great Leadership, Fun Lunches, and James Gosling = Magical Internship Reply

ramya_headshotby Ramya Pradhan

I was at an NBA Orlando Magic game when I received news confirming the summer internship offer from RTI.  I knew from the first time I learnt about the company through my doctoral research on fault tolerance in distributed systems that RTI would be an awesome place to gain hands-on experience in my field of research.  The internship far exceeded my expectations in giving me ample opportunities to learn, contribute, and grow both professionally and personally.  The people, the work culture, and the profound impact RTI has in the fast emerging field of Internet of Things make it among the coolest places to be.  Come along as I reminisce over my experiences as an Intern.

I am a Computer Science doctoral student at the University of Central Florida.  I work on bio-inspired models for fault tolerance in distributed systems.  It was during one of my literature review sprints that I became aware of RTI through Dr. Douglas C. Schmidt’s research on fault tolerance.  The more I became acquainted with the research at RTI on distributed systems and its vast reach in the industry, the more I wanted to be associated with RTI.  I was overwhelmed when I saw internship openings for summer and lost no time in applying!  The interview process was quite rigorous, but I thoroughly enjoyed talking to the engineers who were more than passionate about their work.  I knew right then that RTI was where I wanted to be – at a place where your passion for what you do is nurtured aplenty!

On accepting the offer, I was delighted to know that I would be working on RTI DDS Connext Secure.  Secure systems  has always been one of my favorites.  I eagerly looked forward to experience the confluence of security and distributed systems.  I vividly remember my first day at work like it was yesterday. I was excited.  I was nervous.  I was a little uncertain.  I did have the theoretical know-how, but had little practical hands-on experience with distributed systems in the industry.  After completing the initial orientation meetings with the HR, IT, Accounting, and Safety departments, I was introduced to the Engineering team and to my mentor, Yusheng, over lunch.  It was a fine gathering in the kitchen.  It reminded me of family dinners at the table.  Little did I know then that this would be among the things I would miss the most!  Next was the meeting I was most looking forward to – a meeting with the VP of Engineering, Jan.  He introduced me to the workings of the RTI DDS Connext technology, tools, and potential projects that I would work on.  I was given all the material that I needed to ramp myself up to begin work as RTI’s Software Engineering Intern for Security.

I spent the next two weeks learning.  I watched presentations by the CEO, read orientation handouts, installed software with guidance from the build notes and a lot of help from the fantastic support team, and had whiteboard discussions with Yusheng to facilitate my understanding of the team’s expectations.  It was a completely immersive experience for me; part of it fueled by my curiosity, but mostly by my colleagues’ enthusiasm for the work they did.  Never once did I find anyone too busy to help me with obstacles along the way.  Thinking back upon this very aspect reminds me of an ancient Indian adage – “Yatha raja, thatha praja” meaning, “As is the king, so are his subjects”.  I strongly felt the CEO’s Servant Leadership style infused in all my colleagues; it was others’ needs first.

Smart People, Great Leadership: With CEO Dr. Stan Schneider, CTO Dr. Gerardo Pardo-Castellote, and the engineers.

Smart People, Great Leadership: With CEO Dr. Stan Schneider, CTO Dr. Gerardo Pardo-Castellote, and the engineers.

Upon completing the initial training, I eagerly set forth to explore my tasks.  I started each day with a list of things to work on.  I would settle down with a freshly brewed cup of coffee from the kitchen and start working off my list.  By noon, the Engineering team would all go to get lunch from the neighboring fast food places or the food trucks.  We would bring the food to the kitchen and sit at the tables – family style!  From then on, it was an hour of pure fun!  It was like unwinding with friends in the middle of the day filled with laughter, funny anecdotes, super heroes, history and traditions – Belgian, Italian, Spanish, Mexican, Indian, and Chinese, and work humor.  Oh, what fun it was!  It was truly rejuvenating to get back to work after lunch.  Each evening, upon my request, Yusheng and I had a meeting to discuss my work and progress. This ensured that we knew each other’s expectations and would have little gap in communication.  My day ended with most things taken care of from my to-do list.  In leaving for the day, I would eagerly look forward to the next day; that was the magic of the work culture at RTI.

The internship gave me a valuable exposure to the challenges that exist in the field of developing messaging systems for distributed systems, particularly in secure messaging.  The internship reinforced my belief that challenges are just fantastic opportunities waiting to be uncovered.  I am grateful to my mentor for letting me explore some of those fantastic opportunities.  Some solutions were easier to come up with than others, but most of all I enjoyed the process of coming up with solutions.  It typically involved a lot of whiteboard discussions, extensive analyses of code dependencies, thorough planning for integrating new code, and comprehensive debugging.  The most important takeaway for me from this process was that work could make one happy.

Adventures: Meeting James Gosling, visiting Chabot Space Center and Redwood National Forest.

Adventures: Meeting James Gosling, visiting Chabot Space Center and Redwood National Forest.

As I look back on the things that I have learnt and gained over the past summer, I am filled with gratitude for being given the opportunity to do so. Top of the list are motivating leadership, working with intelligent, dedicated, and passionate colleagues, challenges that seek creative solutions, the feeling that exudes ‘All for one and one for all’ at weekly engineering team meetings, the super fun lunch hour, FIFA world cup matches, and definitely, meeting James Gosling!  Thanks so much, Jan, for letting us know that James Gosling was in a restaurant near by!  Well, the Orlando Magic lost the game that day, but I won the most magical summer.  Thank you RTI for showing not only can one’s distributed system achieve impossible tasks when working as one but so can a company working as one – #1RTI.

ramya internship rti sunnyvale engineering

DDS Security: Completion of my first project under the able guidance of my mentor Yusheng Yang.

Leveraging W3C Org Documents (XML, etc) in RTI Connext DDS 1

london connext conference rti EMEA 2014

Connext Conference 2014 is taking place 8-9 October in London. To learn more or RSVP, visit http://www.rti.com/connextcon.

This is an abstract of a demo that RTI plans to have available at the RTI Connext Users Group meeting, to be held in London next month (http://www.rti.com/connextcon).

Working with structured data, each domain (Enterprise, Real-Time, Java ESB, etc.) will have its preferred method or defined structure for in-memory, and for stored data instances. The fun is when you move across the boundaries from one domain to another, or when you want to leverage one standard’s structures within a non-native domain.

The W3C consortium defines a Document Object Model to hold data in-memory, as well as XML and the Schema-for-Schemas, XSD, used when you want to serialize the data and communicate it to a third party. In OMG DDS, the equivalents are the Dynamic Data Object and Type-specific object PSMs, and RTPS serialization when transmitting instances.

Various ways to leverage the W3C standards in an RTI Connext DDS environment are demonstrated, including:

  • DCPS Discovery information to XML, useful for:
    • Self-documenting DDS Domains
    • Capturing snapshots of what is on a DDS Domain
  • Discovered Type information to XSD or XML, useful for:
    • Auto-generated Type info, formatted as XML for use with RTI Tools that can read XML-defined Types
    • Auto-generated XML Schema Documents, for XML files that can be used to pre-load instances with specific information (‘Configuration Propagation’, ‘Test’, and other use-cases)
  • Generating XSD information for use by Enterprise tools (that can’t read IDL)
  • etc

An example Java application is demonstrated, that uses DCPS Discovery Topics to generate XML and XSD files, as well as show how to read in XML files for use by DDS applications, either for remote configuration (when published as Last-Value-Cache for example), or for pre-loading Type instances for publication via:

ShapeTypeExtended steInstance =
ShapeTypeExtendedTypeSupport.load_from_xml_by_name(
"MyXmlInstances.xml", "YellowTriangleThree");

Service Provision and Discovery Reply

london connext conference rti EMEA 2014

Connext Conference 2014 is taking place 8-9 October in London. To learn more or RSVP, visit http://www.rti.com/connextcon.

This is an abstract of a demo that RTI plans to have available at the RTI Connext Users Group meeting, to be held in London next month (http://www.rti.com/connextcon).

The Oasis Reference Architecture for Service Oriented Architecture defines the concepts surrounding service ‘reachability’, including the use of Federated Service Registries (what services are known about) and Service Repositories (what you need to know, to access a service).  Once your Consumer knows what Services are available, and also how to attach to a given Service Interface, you’re now rocking that SOA.  So how does that apply to a real-time SOA, using DDS?

If you sort of squint at it, the DDS anonymous DCPS Discovery protocol is a part of the Service Registry.  For the Service Repository, Discovery also can supply you with the Types, but only supports the pub-sub integration pattern.  There isn’t any automated, or standards-driven, protocol for doing this using DDS.

To get a full, Federated Registry-Repository (cf Figure 38, page 63 of the reference document linked above), you can implement a Service Discovery process.  Using a well-known topic and type, you can search for suitable Service Interfaces (based on Search or Keywords, etc), determine what integration pattern a Service uses, find the Topics that are needed for it, and merge that information with the normal DCPS Discovery discovered information.  The end result is to build, ad-hoc, the necessary infrastructure to accesses that Service’s Interface — without requiring a maintained Repository.

For the London Connext Conference, RTI has a Raspberry Pi with an attached Pressure/Altimeter/Temperature sensor that publishes using pub/sub.  A service starts up and subscribes to the PAT data, which it then offers (as a Service Interface) via Request/Reply and “Last Value Cache” QoS.  The Service publishes a provision instance, loaded from an XML file, on a well known topic (“Service Provision”).  The instance includes particulars of the Service Interface:  This service uses Simple Request Reply, This is the Request Topic, the Reply Topic, with respective topic Type names, these are my human defined keywords.

A service consumer can now query the “Service Provision” topic using a content filter on the keywords, to find an arbitrary Temperature Service, identify that it is Simple Request/Reply, create the necessary Request writers and Reply readers (using the Types from normal Discovery process), make a request and process the reply.  The only foreknowledge the Consumer has, is that there may be a Temperature sensor on the network that uses a specific set of keywords.

Mark Your Calendars! Reply

rti connext dds road show safety security distributed systems

Build Safe & Secure Distributed Systems for Aerospace & Defense: How to Meet DoD Open Architecture Requirements and Cyber Security Guidance

Build Safe & Secure Distributed Systems for the Industrial Internet of Things: How to Architect Scalable Systems for the Industrial Internet using Open Standards

 To stay up to date on the latest RTI news and events, be sure to follow us on twitter and visit our events page.

Connext Conference London! Reply

connext conference london rti dds users group

Connext Conference London is going to be held on October 8th and 9th and we’d love to see you there!

This 2 day event kicks off with a Connext DDS Users Group meeting where we’re going to focus on the topics that matter the most to you. We’re kicking off the event with a Keynote from Bryn Balcombe, Technology Director at London Live. He is going to speak discuss how the Industrial Internet technologies and protocols will change the way we experience live events – in the venue, in the home and on your phone

Throughout the event you’ll have ample opportunity to network with other DDS developers, share your experiences, and gather insights.

For registration, schedule details, up-to-date information on speakers, and all general information relating to Connext Conference London, visit www.rti.com/connextcon or reach out to our EMEA sales team at emea-sales@rti.com.

connext conference london rti dds users group

Let Your LabVIEW VI Go Mobile. Reply

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.