RTI Connext is powerful infrastructure software designed for the demanding connectivity requirements of mission-critical distributed systems. A key element of Connext is RTI Routing Service, a versatile tool that enables seamless data distribution across diverse and distributed systems. In this blog, we'll explore the different functions of the RTI Routing Service and how it empowers developers to create scalable, integrated, and efficient real-time systems.

Bridging Disparate Systems

Built on the Data Distribution Service (DDS^™) standard, each Connext system is made up of one or more databuses. A databus is a data-centric software framework for distributing and managing real-time data in intelligent distributed systems. One of the primary functions of RTI Routing Service is to act as a bridge between separate databuses, which connect separate domains or separate networks. This facilitates a system-of-systems architecture or what is also known as a layered databus approach.  

A real-world example of Connext being used as part of a layered databus is a modern healthcare system (see Figure 1).

Figure 1: Layered databus architecture

In this example, one DDS databus connects devices in a patient's room, while another separate databus connects different patients’ rooms with the nurses station. Yet another DDS databus connects all the nurses stations in the hospital as part of the hospital's IT system. In this layered databus architecture, the separate databuses are connected with each other using the RTI Routing Service. This gives system developers a single protocol that can support communication across the entire hospital.

RTI Routing Service can even selectively route only topics that make sense in the context of the application. Therefore, not all data is flowing everywhere, but rather only necessary data is flowing as required. In the diagram above, the ward databus may only need certain data from the room databus and RTI Routing Service gives customers control over exactly what data is passed through. One major RTI medical customer for example is currently using RTI Routing Service to group DomainParticipants to reduce discovery time and improve system startup time.

RTI Routing Service ensures that data flows smoothly between different parts of a system, even if they are geographically dispersed or operate using different network configurations. For information on how to create a layered databus architecture using RTI Routing Service, please read this RTI blog post.

Scaling and Integration Across Networks

As systems grow in complexity and size, the ability to scale becomes critical. RTI Routing Service allows for the scaling and integration of DDS systems across multiple platforms, systems, and networks. It supports different transports for each side of a route, such as using UDP multicast for the Local Area Network (LAN) and TCP for forwarding DDS samples across the Wide-Area Network (WAN). This flexibility ensures that data can be efficiently routed, regardless of the underlying network infrastructure.

A great example of this integration is the Integrated Battle Command System (IBCS) program, where each internal site uses DDS running over IPv4, but the radio network for connecting different locations uses DDS running over IPv6 connected through the RTI Routing Service.   

Writer-Side Filtering

Efficiency in data distribution is key for high-performance systems. RTI Routing Service enhances this objective by propagating topic filters to the remote writers, supporting writer-side filtering where possible. This means that only relevant data is sent across the network, reducing unnecessary traffic and optimizing resource usage. So, the Routing Service not only filters whole Topics, but can also filter each individual Topic as specified by a reader's Topic filter.

Data Transformation

The Routing Service is implemented using a pluggable processor, written in C or C++, that allows data passing through the routing services to be modified – for instance, fields in a data type can be changed, added, or removed altogether. Possible transformations include: splitting data, aggregation, content enrichment, data normalization, and delayed action buffering and then sending data.

Figure 2. Transforming data with RTI Routing Service. (Click here for a tutorial)

Connecting New and Legacy Systems

RTI Routing Service also plays a crucial role in facilitating communication between participants using different old and new operating systems, hardware, or DDS versions. Quite often, DDS developers have legacy code that must run on older hardware and use older DDS versions. The Routing Service allows these older systems to communicate with newer parts of the system, even allowing the newer system to use more advanced DDS features such as SPDP2 (more efficient discovery) or XCDR2 data representation (more efficient data encoding).

For example, the U.S. Armed Services used RTI Routing Service in a flight-critical network to map certain topics from a statically configured system using Connext Micro to a fully dynamic configuration using Connext Professional. By creating routes between these participants, Routing Service enables them to connect and communicate effectively, even though these participants may use different DDS versions or discovery protocols.

Web and Cloud Integration

RTI Routing Service extends the reach of DDS systems to the web and cloud environments. When used with RTI Real-Time WAN Transport, the Routing Service provides high-speed, secure cloud communications with cloud applications.

Figure 3. RTI Routing Service with RTI Real-Time WAN Transport

RTI Cloud Discovery Service helps facilitate discovery in cloud-based environments, providing dynamic discovery when multicast is not available and offering centralized discovery management.  In the end, a single protocol is communicating from edge to cloud. RTI has a “Case + Code” available that describes exactly how to use the Routing Service and Real-Time WAN Transport to connect to the cloud, including working example code. 

Converting Between Protocols

Quite often in large systems, several different communication protocols are used. It can therefore be a challenge for system integrators to convert between these protocols. The RTI Routing Service comes to the rescue by offering “adapters” that can convert between Connext and other protocols. RTI has developed many adapters including Kafka, OPC/UA, MQTT, and Modbus. A Software Development Kit (SDK) is provided to help users create their own adapters. One RTI customer, for instance, is currently creating an emissions reduction system that uses the RTI Routing Service as a Modbus to DDS converter. When the Routing Service is used to convert between protocols, it is known as the Connext Gateway. The Connext Gateway is considered an experimental feature that is part of RTI Labs.

Figure 4. Example of converting between protocols with RTI Routing Service Adapters. You can also create your own customer Routing Service protocol adapter with help from the Routing Service Software Development Kit.

Conclusion

RTI Routing Service is a multifunctional tool that addresses the challenges of data distribution in complex, real-time systems. Whether it's bridging between systems, scaling across networks, transforming data, or converting between protocols, RTI Routing Service is an indispensable component of the RTI Connext ecosystem. By leveraging its diverse functions, developers can build robust, scalable, and efficient systems that can stand the test of time and weather the technology evolution. To learn more, please download our new RTI Routing Service datasheet here.

About the author:

Dave Seltz
Regional FAE Manager

David Seltz is a Field Application Engineering Manager for Real-Time Innovations supporting customers in the eastern US area. David has been in the embedded industry for over 32 years working in engineering and sales roles.  Previous to his work at RTI, David was the world-wide FAE manager for Wind River Systems. He holds a Bachelor of Science degree in computer engineering from Lehigh University, and a Master of Science degree in computer engineering from the University of Massachusetts.