Skip to the main content.

Did you know?

 

RTI is the world’s largest DDS supplier and Connext is the most trusted software framework for critical systems.

Success-Plan-Services-DSSuccess-Plan Services

Our Professional Services and Customer Success teams bring extensive experience to train, problem-solve, mentor, and accelerate customer success.

Learn more

Developers

From downloads to Hello World, we've got you covered. Find all of the tutorials, documentation, peer conversations and inspiration you need to get started using Connext today.

Try the Connectivity Selection Tool ⇢

Resources

RTI provides a broad range of technical and high-level resources designed to assist in understanding industry applications, the RTI Connext product line and its underlying data-centric technology.

Company

RTI is the infrastructure software company for smart-world systems. The company’s RTI Connext product is the world's leading software framework for intelligent distributed systems.

Contact Us

News & Events
Cooperation

2 min read

Time to Migrate from PrismTech OpenSplice to RTI Connext DDS

Time to Migrate from PrismTech OpenSplice to RTI Connext DDS

With the recent acquisition of PrismTech by the Taiwanese company ADLINK, we are seeing increased demand for porting from OpenSplice to RTI Connext DDS. One of the benefits of going with a standard like Data Distribution Service for Real-Time Systems (DDS) is that you have options if your middleware supplier becomes unreliable for any reason. That's why the DDS community went to so much trouble to develop more than just a wire protocol standard. The DDS specification also includes API definitions, with the explicit goal of making it easier to port.

In particular, DDS specifications include both a PIM (platform independent model) and a set of language PSMs (platform specific models). The PIM defines all the important user-visible API concepts including the DDS Entities (DomainParticipant, Topic, Publisher, Subscriber, etc.), their operations and behavior, the QoS, the listeners, and so on. All DDS implementations use the PIM. That means that the structure and major options in your code will translate unchanged to a different DDS implementation.

The PSMs are much newer and they are only unambiguously defined for C++ and Java. Other programming languages come from the IDL-derived mappings (also standard). If you used one of the new standard language PSM APIs, it's even easier to port your application. Even if you didn’t, the common PIM makes it a straightforward process. Of course, in general, there are some differences between versions, both API variability and "non standard" options, features, and configuration. Still, compared to porting to a new middleware architecture, the work required to port is minimal.

How hard is it to port an existing application from OpenSplice DDS to the RTI Connext DDS in practice?

It's not trivial, but it's not that bad, either. One significant difference between these two SDKs is in the IDL syntax. Although most of the IDL syntax is identical, there is a difference in how “key attributes” are indicated. Connext DDS uses the DDS-XTYPES standard format consisting of a “@Key” annotation placed inside a comment. OpenSplice uses a (non-standard) “#pragma keylist” directive. We can see this difference in the example below.

OpenSpliceDDS IDL Equivalent Connext DDS IDL
struct Coordinates {
    float latitude;
    float longitude;
    float altitude;
};

struct Flight  {
    string<32>  airlineCode;
    long        flightNumber;
    string<3>   departureAirport;
    string<3>   arrivalAirport;
    long long   departureTime;
    Coordinates currentPosition;
};

#pragma keylist Flight airlineCode flightNumber
struct Coordinates {
    float latitude;
    float longitude;
    float altitude;
};

struct Flight  {
    string<32>  airlineCode;  //@Key
    long        flightNumber; //@Key
    string<3>   departureAirport;
    string<3>   arrivalAirport;
    long long   departureTime;
    Coordinates currentPosition;
};

The first step in the migration is to modify the IDL files replacing #pragma keylist with the //@Key annotation, as shown above.

Once the IDL file(s) have been migrated, the rtiddsgen tool can be used to generate all the network marshaling/unmarshaling code. This allows the data to understood by any computer, independent of processor architecture, operating system, and programming language. The rtiddsgen tool is included with the Connext DDS SDK. In addition to generating the network marshaling code, rtiddsgen can generate example code and makefiles / build projects for the programming languages and platforms of your choice.

Beyond this there are a few application code edits that may be required. These affect the initialization of the TypeSupport, the use of the ReturnCode_t type, the use of the length() operation on types String and Sequence, and the way sequences are passed to the DataReader read/take operations.

RTI has experience doing this! Some RTI customers, including many of our largest and happiest customers, started with OpenSplice before they discovered the performance, quality, tools, and top-flight support from RTI. So, before you start this effort, contact us. We have a migration SDK including compatible headers, examples, and more. Better yet, we can offer you a cost-effective service to help you transition quickly and correctly.