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 or reach out to our EMEA sales team at

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.

Replacing ZeroMQ with RTI Connext DDS in an Actor Based System 7

Scalability is one of the key properties of modern software that allows for applications to adapt to changes in the context where they’re operating. Nowadays, distributed architectures, cloud computing, and multicore processors change the development of concurrent programming such that they help to fulfill scalability requirements. In these scenarios, the traditional shared state programming has shown its limit: threads must be able to synchronize to guarantee concurrency. This can be a complex, tricky, and expensive operation that if it is not done correctly, can easily lead to race conditions, deadlocks, or starvation; possibly compromising the overall performance of the system.

A different approach to concurrency can be used to address those problems – the Actor Model. The actor model provides a lightweight and isolated isolated way to create entities that don’t share state and that communicate only through asynchronous non-blocking messages, both locally and in distributed systems. Since they don’t share state, they can easily be used to achieve high concurrency and scalability in systems with distributed architectures and multicore processors.

As shown in Figure 1, in an actor based system, the actor can be seen as the fundamental unit of computation that embodies:

  1. Behavior: what does the actor do
  2. State: a set of variables that can be changed by the behavior
  3. Communication: how does the actor communicate with other actors

Figure 1: an actor is defined by a state, a behavior and a mailbox

Each actor in the system has a ‘mailbox’ and it becomes active only when another actor sends a message to their mailbox. Upon receipt of a message, the actor can:

  1. Create new actors
  2. Send messages
  3. Produce side-effects (e.g. write a file)

One of the most popular solutions based on the Actor Model is Akka: a toolkit and runtime framework for building highly concurrent, distributed, and fault tolerant applications on the JVM. Akka is written in Scala and has language bindings for Scala and Java. It has a modular structure that can easily be extended with the so-called ‘Extensions’.

In Akka, actors are purely reactive components: an actor is passive until a message is sent to it. When a message arrives to the actor’s mailbox one thread is allocated to the actor, the message is extracted from the mailbox and the actor applies the behavior. When the processing is done, the thread is returned to the pool. This way actors don’t occupy any CPU resources when they are inactive.

The actor’s behavior is the computation logic that is executed in response to a message. The internal state of the actor can change only as a response to a message, and the only way to observe the state is via message exchange. An actor can only process one message at a time—there is no need of synchronization nor coordination.

To define an actor in Akka, you have to extend the Actor trait, implementing the receive method, which is never called concurrently.

class MyActor extends Actor {
    def receive = {
        case “test” ⇒ println(“Receive test message”)
        case “send” ⇒ sender ! message
        case _      ⇒“Unknown message”)

The receive method returns a PartialFunction, e.g. a ‘match/case’ clause in which the message can be matched against the different case clauses, using Scala pattern matching.

To create an actor, first an ActorSystem has to be created. Calling the actorOf method will return a reference to the actor. To specify options, it is possible to pass a configuration class to the actorOf method.

val system = ActorSystem("mySystem")
val myActor = system.actorOf(Props[MyActor], "myactor")
val child = context.actorOf(Props[MyActor], name = "myChild")

To send a message to an actor, you have to use the ! (bang) function, which is asynchronous and non blocking. The semantic of delivery is at-most-once both for local and remote actors. Thanks to the message passing communication of actor model, there is no tight-coupling between sender and receiver. Actors are location transparent and distributable by design; actors share no data and communicate using message passing, they can be mapped on a distributed architecture (scaling out).

Remote communication can be achieved using:

  1. Configuration files: the same system can be configured as distributed without code changes.
  2. Extensions

If the actor is a remote actor, it uses remote call under the hood. Akka can be configured to use various transports. The default transport mechanism is a Netty based TCP driver. Netty is an asynchronous event-driven framework for the development of maintainable and high performance applications. Asynchronous one-to-one channels are created between remote actors. So, sending a message to remote actors serializes the message transparently and sends it to the remote JVM. However, this solution is particularly inefficient for one-to-many communication patterns, as each message is replicated on the physical channel for each receiver.

Below, there is the snippet of a configuration file that uses the default Netty transport for remote communications. It specifies hostname and port parameters (passed to the remote system) to identify the system:

actor {
    provider = "akka.remote.RemoteActorRefProvider"
remote {
    enabled-transports = ["akka.remote.netty.tcp"]
    netty.tcp {
        hostname = ""
        port = 2552

Akka has two ways of using remote communication: lookup a remote actor and create a remote actor.

To lookup an actor on a remote node, you can use the actorSelection(path) method:

val selection = 
        "akka.tcp://actorSystemName@ /user/actorName")
selection ! "Hello"

To create an actor on a remote node, you can use actorOf(Props[...], actorName) method instead, specifying in the configuration file of the application where the remote actor resides, using the address and the port of the remote system:

actor {
    deployment {
        /myActor {

The same semantics are used for sending messages to remote and local actors—there is no API dedicated for remote communication. If no deployment configuration exists, then actor is deployed locally.

Using Netty, a remote actor that wants to communicate to multiple actors has to know each receiver and replicate the message for each Netty TCP channel. This is clearly inefficient and difficult in scenarios where actors are mobile (i.e., they enter and exit the system frequently). For this reason a PUB/SUB communication pattern is needed.

Akka’s modular structure makes it easy to add external features and to manage them thought Akka itself.

Akka supports the PUB/SUB communication pattern through the ZeroMQ Extension. ZeroMQ is an asynchronous messaging library with a non-dedicated message broker. It supports different transports such as IPC, multicast (PGM), and TCP communication. The main disadvantage in using ZeroMQ as the base for PUB/SUB in Akka is its limited QoS capabilities. Also, the ZeroMQ PUB/SUB sockets are using TCP or PGM and there is no guarantee of reliability as slow subscribers drop messages. Other kinds of ZeroMQ sockets and other patterns can be used (e.g. ROUTER-DEALER), with the downside of increasing the complexity of the application.

To overcome these problems we decided to replace ZeroMQ with DDS. To do this, we developed an Akka Extension using RTI Connext DDS. Our Connext DDS extension follows Akka’s modularity principles, and thus can be easily integrated in an Actor System and used to integrate actors to a pre-existing systems based on DDS. The DDS Extension allows efficient one­-to-­many communication through the PUB/SUB Model offered by DDS.

The RTI Connext DDS extension adds a wide range of QoS policies to have the best delivery semantics for application-­level requirements, trade­-off between quality guarantees, and communication costs. For these reasons, we feel that the DDS extension represents an improvement in comparison with the ZeroMQ Extension.

Using DDS, actors can now exchange messages with one another, so long as they’re registered to the same DDS topic. This is accomplished using a proxy actor, called ActorDW, which encapsulates a DDS DataWriter. Other actors in the system send messages to ActorDW, using the usual actor syntax. A representation of the complete interaction is represented in Figure 2.


Figure 2: Interaction between ActorDW and DDS

The operation of loading the extension is similar to the ZeroMQ extension, as well as the rest of the extensions available for Akka:

val system = ActorSystem("DDSAkkaSystem")
val dds = DDSExtension(system)

The DDSExtension API is higher-level and more abstract than ZeroMQ extension’s. To publish a message the extension offers the newDataWriter method. The user has to specify only DDS’s DomainID, the topic name, and the name of the actor:

val actorDW = dds.newDataWriter(0, "My Topic", "myActorDW")

The method will return an actor that can be used with the usual bang syntax:

actorDW ! message

Using newDataWriter method in its simplest form, will use default values for DataWriterQoS,
DomainParticipantQos, and TopicQos. However a user can specify its own custom QoS parameters:

val qosDataWriter = DataWriterQos()
qosDataWriter.reliability(Reliability = Reliable)
val qosTopic = TopicQos()
qosTopic .reliability(Reliability = Reliable)
val actorDW = dds.newDataWriter(qosDataWriter , qosDomain, qosTopic, 0, "Test Topic", "datawriter")

In Figure 3 we see the actions hidden from the user; these actions are executed automatically by the DDSExtension  and include:

  1. Retrieve or create the DDS Domain
  2. Retrieve or create the Topic
  3. Create a DDS DataWriter
  4. Create and return the actor

Figure 3: actions performed under the hood for a DataWriter Actor

On the subscriber’s side, the extension provides the newDataReaderWS method. Firstly, the user has to create the actor that will receive the data, and then pass it to the method:

val actorDR = system.actorOf(Props[DRActor], "MyActorDR")
dds.newDataReaderWS(0, "Test Topic", actorDR, read)

Even in this case, the method has two forms: the simplest one gives default values for DataWriterQoS, DomainParticipantQos, and TopicQos, but users can specify their own custom QoS settings:

val qosDataReader = DataReaderQos()
qosDataReader.reliability(Reliability = Reliable)
val qosTopic = TopicQos()
qosTopic.reliability(Reliability = Reliable)

val actorDR = dds.newDataReader(qosDataReader , qosDomain, qosTopic, 0, "Test Topic", read)

The actions that the API performs are illustrated in Figure.


Figure 4: action performed automatically by the ActorDR

The system, creates a DDS DataReader and then registers the actor and the DataReader in a data structure, which depends on the type of the condition, contained in another component called DDSDemultiplexer.
The DDSDemultiplexer, illustrated in Figure 5, is a singleton that wraps a DDS WaitSet and offers methods to attach and detach conditions.


Figure 5: DDSDemultiplexer structure

At system startup, a thread is assigned to the DDSDemultiplexer, and it will block itself waiting for samples0. As shown in Figure 6, when a DataWriter writes some data into the Topic, the thread will be awake, and it will check if there are actors registered for that particular event. If so they will be notified.


Figure 6: DDSDemultiplexer loop waiting for data and then it notifies the DataReader when new Data is available

val readConditions = Map[ReadCondition, DDSNode]()
val statusConditions = Map[StatusCondition, DDSNode]()

while (running) {
    val retcode = ws.wait(activeConditions, timeout)
    val cond = activeConditions.get(i)
    val node = statusConditions.get(cond)

    getSample(cond, node)

As you can see, the Actor Model is an interesting approach you can use to solve issues related to concurrency, especially in distributed systems. We explored the challenges and the limitations when it comes to remote actors in regards to one-to-many communication patterns, showing how PUB/SUB is necessary to implement scalable solutions. We also illustrated the limitations of the ZeroMQ Extension for PUB/SUB, most notable concerning QoS configurations. For these reasons, we implemented an easy to use RTI Connext DDS extension that, with minimal effort from the user, can be easily tuned and configured. Using this approach, actors can now communicate, using RTI Connext DDS, where they’re able to take advantage of the PUB/SUB model and the great QoS support out of the box.

If you have any questions, feel free to comment and we will get back to you ASAP!

Note: This Blog post was written by Marco Franzoni (University of Bologna) and Gianpiero Napoli (RTI) and is part of Marco’s recent work for his M.Sc. Degree in Computer Engineering from the University of Bologna: “Quality-of-Service Support in Distributed and Wide-Scale Actor Systems”

Simplifying the use of DDS 1

The specification for DDS provides great capability for applications that want to leverage the distribution of state data in a very customized efficient manner. I say customized here because not only can you specify the unique type of data but you can also specify the behavior of how that data will be delivered, persisted, filtered and stored within the middleware. Actually, the capabilities provided by DDS are not unique to data communications between systems. However, what DDS provides is all of this functionality within the middleware, thus eliminating the need for your applications to provide the same. No coding necessary to filter data based on satisfying a range specification on one or more of the fields within your data. No coding necessary to provide previously published data to late joining applications. No coding necessary to enable the storage of a historical data publications for live trending analytics to be performed. No coding for these things means application developers can spend their time on more important unique aspects of their application and thus a deliver a better end product with shorter time to market. All of this functionality is enabled and specified through simple code generation and configuration elements known as Quality of Service. As you might guess, this configuration can become difficult to create and manage. If someone is just getting started with understanding DDS, this can become a daunting task to undertake. In order to address this initial view of DDS for developers, there are few things that we have done here at RTI to help with simplifying the use of DDS for some basic applications. Take for example, the process of creating a unique data type, running code generation, setting up a project and including all of the generated files in to the project. For a very simple type, this process seems a little excessive. We have eliminated the need to perform this process for a few simple types. In fact, our latest version of DDS, RTI Connext DDS, includes built-in types for 2 basic types:

  • String    // Simple ASCII String message
  • Octet     // Simple byte array message

We also provide keyed versions of these if you want have unique instances of these. The use of these built-in types can be found within our User Manual for DDS and can save a lot of time when creating your applications. Next, we have taken the complexity of having to learn and create Quality of Service profiles for each specific type of data flow in your system and have reduced them down into a set of built-in behavior profiles that can be used directly within your application. These built-in profiles will eliminate the need to of spending hours and hours pouring over our great documentation on each of the various Quality of Service behaviors. Literally this can shorten your time to getting started in creating a DDS publish / subscribe application from several days into an effort that is less than a couple of hours. The great thing about these behavior profiles is that they represent about 75% of the most common use cases we have found projects using out in the field. Here are a few of the built-in profiles:

  • Best Effort
  • Reliable Keep Last One
  • Pattern Streaming
  • Pattern Event
  • Pattern Status



We have provided some great examples of built-in profiles available for you to download and use up on our Community Portal. You can find the examples here:

In addition to these examples, here are some other things up on Community that may be of interest:

Let us know what you think about these aspects of Simplifying the Use of DDS!

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

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

Improving Efficiency & Quality of Patient Care With Connext DDS Reply

case and code medical device interoperability rti connext dds use case

Interoperability between medical devices can improve both the quality and efficiency of patient care, saving lives and money. Fortunately, with the help of FDA’s recent recognition of medical device interoperability standards and advent of the Industrial Internet of Things, interest and investment in medical device interoperability are increasing.

RTI Connext DDS is particularly well-suited as a communication platform for medical devices. It supports the Data Distribution Service (DDS), the only interoperability standard designed for real-time systems. It features peer-to-peer communications and automatic discovery, so does not require servers or system administration. It is also easy to integrate with existing applications, devices and hospital IT systems.

One serious challenge today is “Alarm Fatigue.” This is the focus of RTI’s new Case + Code example. According to a FierceHealthcare article, hospitals rank alarm fatigue as top patient safety concern. Alarm fatigue occurs when clinicians and nurses become overwhelmed with constant noise of false alarms and turn alarms down or off.

case and code medical dds use case

RTI’s newest Case + Code Example illustrates how RTI Connext DDS can be used to counteract alarm fatigue in hospital or clinical settings. The implementation correlates data coming from different medical devices (in this case Pulse Oximeter and ECG) via the RTI Connext DDS data bus; it then generates alarms based on alarm probability values. The result is significantly fewer false alarms.


For technical details of the Case + code example, please visit our github repository.  You can copy the code and use it in your own implementation as you see fit. Any questions or technical difficulties? Don’t hesitate to post it on RTI’s community portal at

Guest Post: Accelerating the IoT – Adding Security in Legacy Systems Reply

This post, penned by Geoff Revill, was originally published on linkedIn (here). We liked it so much that we wanted to share it with you all. Thank you, Geoff!

rti connext dds secure

For the most part, the Industrial Internet aspect of the IoT won’t happen until we can figure out a way to build security into legacy deployed systems. There is trillions of dollars of deployed systems that essentially rely on physical security measures, replacing these systems with shiny new cyber-ready systems will take decades. Accessing their wealth of data via the Internet is a major security challenge – few of these systems were designed to be secured against cyber attack. So the wealth of shareable sensor data and industrial insights remains locked in proprietry system deployments. In many cases that’s just the way the owners like it, and for many there is no real reason – yet – to open up their systems to the Internet. But the innovative large scale entities that find ways to open up their systems could unlock a mobile-like app phenomena – becoming the Apple or Google of the IoT age. It’ll take a bold move by an even bolder entity to do this, but with high risks come high rewards. And if they don’t, be assured Apple or Google or similar will gradually encroach on that Industrial home turf.

This is why I found this story so fundamentally exciting ( ) because it defines a way to secure the transport infrastructure of pretty much any SCADA style system. It even includes a rapid prototyping scripting interface to allow continuous evolution of cyber-defence techniques with instant deployment capability. It combines fundamental security techniques with a truly agile response mechanism – and fine grain control of what information can be let out of the cyber-walled garden and what has to stay securely locked in. Even better its based on technology the worlds largest defence agency has already tried tested and found to be securely acceptable – if it’s good enough to defend the lives our brave fighting men then surely its good enough to consider for the innovative first movers in the Industrial Internet of Things?

Make Your Distributed System Cyber-Secure Reply

rti connext dds secureHow do you approach such a challenge? The larger your distributed system is, the more attack points you require to secure and defend it against hackers, and yet at the same time, the more varied your authorized access levels need to be. You may need to facilitate maintenance, updates and upgrades, monitoring and many other system-wide tasks, each requiring differing access rights to many overlaid sub-elements of your distributed system.

Defending distributed systems is usually done in one of two ways:

  1. Physical security. The larger, distributed system is secured by isolating the systems to be protected from cyber-interaction.
  2. Simplified lock-down. Security is achieved by minimizing access rights to a few privileged employees with high security clearances/special permissions.

Both solutions deny access to the full potential that the Internet of Things is meant to enable, while massively restricting the flexibility required for day-to-day operational procedures. So the lack of security becomes a business benefit trade off.  But why would you ever knowingly trade away value in your operational infrastructure?

In IT systems the problem is largely delegated to the database – with data access rights defined and limited through authorization and authentication methods, as well as the usual encryption of critical data where needed.  But few real-time systems store their time critical data in databases due to the performance hit or cost issues.  Yet it’s the data in motion that needs protection in real-time systems, this is the critical business asset.

In some systems another issue comes into play –the ability of a hacker to alter control parameters becomes a safety issue as well as a brand reputation and data value loss problem.  The consequences of which can be far more far-reaching than the mere loss of some data.

So what’s needed is database style defense tools that operate across a system infrastructure.  This is exactly what RTI Connext DDS Secure is designed to do.


One tool chain to manage authentication, access control, encryption, access privileges and security monitoring.

In fact with the RTI tools you can go further, and enable agile attack response tool development just like Rajive did when he built a secure SCADA infrastructure with PNNL – in fact he showed this toolchain can be applied retrospectively to legacy distributed systems deployments.

Connext DDS Secure – the best defense for your cyber-enabled infrastructure – plug it in today!

Additional information on Connext DDS Secure:

If you have any questions, please don’t hesitate to ask! We’re here to help.