1. Introduction

RTI® Routing Service, is an out-of-the-box solution that allows developers to rapidly scale and integrate real-time systems that are disparate or geographically dispersed. It scales RTI Connext® DDS applications across domains, LANs and WANs, including firewall and NAT traversal.

It also supports DDS-to-DDS bridging by allowing you to make transformations in the data along the way. This allows unmodified DDS applications to communicate even if they were developed using incompatible interface definitions. This is often the case when integrating new and legacy applications or independently developed systems. Using RTI Routing Service Adapter SDK, you can extend Routing Service to interface with non-DDS systems using off-the-shelf or custom-developed adapters.

Traditionally, Connext DDS applications can only communicate with applications in the same domain. With Routing Service, you can send and receive data across domains. You can even transform and filter the data along the way! Not only can you change the actual data values, you can change the data’s type. So the sending and receiving applications don’t even need to use the same data structure. You can also control which data is sent by using allow and deny lists.

Routing Service Overview

Figure 1.1 Routing Service Overview

Simply set up Routing Service to pass data from one domain to another and specify any desired data filtering and transformations. No change are required in the Connext DDS applications.

Key benefits of Routing Service:

  • It can significantly reduce the time and effort spent integrating and scaling Connext DDS applications across Wide Area Networks and Systems-of-Systems.
  • With Routing Service, you can build modular systems out of existing systems. Data can be contained in private domains within subsystems and you can designate that only certain “global topics” can be seen across domains. The same mechanism controls the scope of discovery. Both application-level and discovery traffic can be scoped, facilitating scalable designs.
  • Routing Service provides secure deployment across multiple sites. You can partition networks and protect them with firewalls and NATS and precisely control the flow of data between the network segments.
  • It allows you to manage the evolution of your data model at the subsystem level. You can use Routing Service to transform data on the fly, changing topic names, type definitions, QoS, etc., seamlessly bridging different generations of topic definitions.
  • Routing Service provides features for development, integration and testing. Multiple sites can each locally test and integrate their core application, expose selected topics of data, and accept data from remote sites to test integration connectivity, topic compatibility and specific use-cases.
  • It connects remotely to live, deployed systems so you can perform live data analytics, fault condition analysis, and data verification.
  • RTI Routing Service Adapter SDK allows you to quickly build and deploy bridges to integrate DDS and non-DDS systems. This can be done in a fraction of the time required to develop completely custom solutions. Bridges automatically inherit advanced DDS capabilities, including automatic discovery of applications; data transformation and filtering; data lifecycle management and support across operating systems; programming languages and network transports.
Routing Service Adapter Overview

Figure 1.2 Quickly build and deploy bridges between natively incompatible protocols and technologies using Connext DDS

1.1. How To Read This Manual

The content of this manual assumes you are familiar with Connext DDS concepts. While you can read any section independently, if you are new to Routing Service we recommend starting with the Tutorials to get an overview of what this application can do.

Then read the Core Concepts for deeper knowledge of Routing Service specific concepts. You can then refer to the Configuration to start defining and customizing your Routing Service.

You can read any of the other sections as you see fit based on what your application or system needs are.

1.2. Paths Mentioned in Documentation

This documentation refers to:

  • <NDDSHOME> This refers to the installation directory for Connext DDS.

    The default installation paths are:

    • macOS® systems: /Applications/rti_connext_dds-version
    • UNIX®-based systems, non-root user: /home/your user name/rti_connext_dds-version
    • UNIX-based systems, root user: /opt/rti_connext_dds-version
    • Windows® systems, user without Administrator privileges: <your home directory>\rti_connext_dds-version
    • Windows systems, user with Administrator privileges: C:\Program Files\rti_connext_dds-version

    You may also see $NDDSHOME or %NDDSHOME%, which refers to an environment variable set to the installation path.

    Whenever you see <NDDSHOME> used in a path, replace it with your installation path.

    Note for Windows Users: When using a command prompt to enter a command that includes the path C:\Program Files (or any directory name that has a space), enclose the path in quotation marks. For example: “C:\Program Files\rti_connext_dds-version\bin\rticlouddiscoveryservice.bat”

    Or if you have defined the NDDSHOME environment variable: "%NDDSHOME%\bin\rticlouddiscoveryservice.bat"

  • <path to examples> By default, examples are copied into your home directory the first time you run RTI Launcher or any script in <NDDSHOME>/bin. This document refers to the location of the copied examples as <path to examples>.

    Wherever you see <path to examples>, replace it with the appropriate path.

    Default path to the examples:

    • macOS systems: /Users/your user name/rti_workspace/version/examples
    • UNIX-based systems: /home/your user name/rti_workspace/version/examples
    • Windows systems: your Windows documents folder\rti_workspace\version\examples. Where 'your Windows documents folder' depends on your version of Windows. For example, on Windows 10 systems, the folder is C:\Users\your user name\Documents.

1.3. Files Mentioned in Documentation

Table 1.1 Files mentioned in the documentation
File Description
ServiceCommon.idl Definitions of infrastructure types.
ServiceAdmin.idl Definition of remote administration types.
RoutingServiceMonitoring.idl Definition of monitoring types specific to Routing Service.