Unbounded Support For Sequences and Strings Reply

When we first designed Connext DDS, deterministic memory allocation was on the top of our priority list. At that time most of our customers used small data types such as sensor and track data. We decided to go with an approach in which we pre-allocated the samples in the DataWriter and DataReader queues to their maximum size. For example:

struct Position {
    double latitude;
    double longitude;

struct VehicleTrack {
    string<64> vehicleID; //@key
    Position position;

In the previous example, a sample of type VehicleTrack was pre-allocated to its maximum size. Even if vehicleID did not have a length of 64 bytes, Connext DDS pre-allocated a string of 64 bytes to store the sample value.

As our customer base increased, the set of use cases expanded, and with that came the need to be more flexible in our memory allocation policies. For example, customers may use Connext DDS to publish and subscribe video and audio. Typically these data types are characterized for having unbounded members. For example:

struct VideoFrame {
    boolean keyFrame;
    /* The customer does not necessarily know the maximum 
       size of the data sequence */
    sequence<octet> data;

Pre-allocating memory for samples like VideoFrame above may become prohibitive and really expensive as the customer will be forced to use an artificial and arbitrarily large bound for the variable size sequence. For example:

struct VideoFrame {
    boolean keyFrame;
    /* Alternatively the customer can use the code generator 
       command-line option -sequenceSize to set an implicit 
       limit for the unbounded sequence */
    sequence<octet,1024000> data; 

In Connext DDS 5.2.0, we have introduced support for unbounded sequences and strings.

To support unbounded sequences and strings, the Code Generator has a new command-line option: -unboundedSupport. This new option may only be used when generating code for .NET, C, and C++ (that is, the -language option must be specified for C++/CLI, C#, C, or C++).

With this option, Connext DDS will not pre-allocate the unbounded members to their maximum size. For unbounded members, the generated code will de-serialize the samples by dynamically allocating and de-allocating memory to accommodate the actual size of the unbounded member. Unbounded sequences and strings are also supported with DynamicData and Built-in Types and they integrate with the following tools and services:

  • Routing Service
  • Queuing Service
  • Recording Service on serialized and automatic mode (records in serialized format)
  • Replay Service when recorded in serialized mode
  • Spy
  • Admin Console
  • Toolkit for LabVIEW

The integration with Persistence Service, Database Integration Service and Spreadsheet Add-in for Microsoft Excel is not available at this point.

For additional information, check Chapter 3 Data Types and DDS Data Samples and Chapter 20 DDS Sample-Data and Instance-Data Memory Management in the RTI Connext DDS Core Libraries User’s Manual as well as the User’s Manuals for services and tools.

Visualize your data! Reply

Ok, I have to admit right from the start that I’m very excited about this feature. I’ve wanted a high-performance, platform-independent visualization for DDS data for more than a decade. When I was an RTI customer (we started with the 3.x version), I built a small UI to display data. It used generated code and was quite basic but still useful. Just the other day I heard from a person working on that project that they still use it! I can’t wait to show them what we now ship with Admin Console!

What can you do with it?

First things first, subscribe to your Topic of interest.


If you don’t have a data type, no problem. You can specify it through one (or more) XML files. Use rtiddsgen to generate them from your IDL or XML type file with the -convertToXml option. You can also specify more advanced settings including overriding QoS, setting a content filter, or picking from which DataWriters to receive data.


Here you can set the DataWriter filter.


Once you’ve picked your QoS and subscribed to the Topic, you’ll see the instances start filling in from the DataWriter(s). Instances? If you’re not familiar with this DDS concept, an instance is a unique piece of data within a Topic. In the Triangle topic (below), there are 3 instances, “ORANGE,” “MAGENTA,” AND “CYAN.” Each instance is shown in its own row. This display (which we call the Topic Data Tab) chooses a few fields to show by default but you can customize this to show the fields that you prefer.


But, I want to look at all of the fields. Of course, who wouldn’t?! To see all of the data, select an instance (a row in the Topic Data Tab) and then look at the Sample Inspector. This view shows all of the fields in a tree view. You can view all nested structures and you can see all of the metadata (SampleInfo) as well!


That’s very helpful but I want to see more than just the current value. There are two more views and they can show historical data. Let’s talk first about the Sample Log. This view shows each sample in its own row (regardless of which instance it is). This view stores sample data (10,000 samples by default) so you can look back at captured data (perhaps after using the pause feature). And this view works with the Sample Inspector so when you select a sample (row), the Sample Inspector displays all of the data fields. And, you can display multiple Topics in this view too!

I mentioned that there were two views which show historical data, the second one is the Time Chart. The Time Chart plots numerical field values as a function of time. You can use this view to compare data fields (either from different instances in the same Topic or instances in any number of other Topics). Or you can use it to look for trends in your data. The Time Chart also stores displayed data (1,000,000 values by default for each trace). You can put the Time Chart in historical mode to view this archived data.

This is also cool but how can I save my data to disk? Each of the views contains an export button image01. This button will export the data contained in the view into a comma-separated value (CSV) file (Topic Data Tab, Sample Log, & Time Chart) or a text file (Sample Inspector). You can also export the chart as an image from the Time Chart (using the button that looks like a camera).

What about performance? Data Visualization exhibits very good performance characteristics. But I’ll cover that in detail in a future blog post.

Is that all? There are many things that I haven’t covered here. If you want to see more right away, you can check out Data Visualization => Getting Started section of the Admin Console Help.

Replication and persistence features of RTI Queuing Service Reply

There are many queuing services available, but few support both persistence and replication. If preserving data integrity is vital to your business and you also need high performance or a full remote administration, RTI Queuing Service may be just what you need.

When considering replication, persistence or any other aspect of RTI Queuing Service, you should keep in mind the most basic and unique of its features: it uses DDS as the underlying messaging technology. If you don’t know RTI Queuing Service yet but you are familiar with DDS, you will find its concepts and APIs familiar. RTI Queuing Service seamlessly integrates with your existing DDS system. You can also use it to bring the power of DDS to your already existing queuing-based systems.


There are different scenarios where a replicated queuing service can help you. You may need a highly available service that will stay up when part of your system or network goes down. Additionally, you may also need to assure the integrity and consistency of your data when a failure occurs. If you are dealing with a queue of financial transactions, for example, you not only want your system to stay operative most of the time, you also need to know which transactions went through and which didn’t when a failure occurs. A replicated queuing service can keep your system running and at the same time provide a safe place for your data even under failure.

To provide a highly available service, RTI Queuing Service leverages the decentralized architecture and discovery capabilities of DDS. If part of your system fails, the surviving DDS subsystems will still communicate and keep you running. During a failure RTI Queuing Service will allow you to remotely administer the surviving subsystem. You will be able to issue remote administration commands without fear of a final, inconsistent global state once the failing nodes recover.

Remarkably, all RTI Queuing Service replication features also apply to each and every aspect of its remote administration capacities, and these capacities are wide! You can remotely create and destroy queues, see their messages, filter messages using SQL expressions or empty a queue. You will be able to perform these operations during a failure, changing your system configuration with the guarantee that it will end up in a global consistent state. Not many Queuing Services (if any) can offer this.

If you not only want a highly available service but also need to ensure data consistency under failure, RTI Queuing Service provides a robust replication protocol. The protocol is based on a level of redundancy provided by the user. This redundancy level applies to messages as well as message operations, such as the acknowledgment or the assignment of a message to a recipient. The focus of the replication protocol is not on redistributing messages to all operating nodes but on ensuring that only messages that are successfully replicated are transacted and that only message operations agreed upon by multiple nodes occur. DDS reliable Quality of Service already ensures that messages will eventually be delivered to the Queuing Service nodes when possible.

RTI Queuing Service makes sure that a queue message producer gets an acknowledgment for a message only if the message was successfully replicated with the desired redundancy level. The message will be negatively acknowledged if the enqueuing process fails to achieve the desired redundancy. Only acknowledged messages will be sent to consumers, and the rest will be consistently discarded across all the nodes. Optionally you can also require your messages to be delivered if the message recipient is known with the desired redundancy level; this is useful when a message has to be redelivered after a failure.

To configure RTI Queuing Service you are asked for the maximum number of nodes you are planning to run – the number of queue instances. From this number the replication level is calculated as the lowest integer that is higher than queue instances divided by 2.

Under the hood the queuing service nodes choose a master as the orchestra conductor for all operations. The master node is chosen automatically and it can change at any time depending on a variety of factors. You can set a master timeout period that controls for how long the nodes can remain unable to coordinate with others before they undergo an internal reconfiguration with a new master election process. The election is based on which nodes are most up to date so there is a high probability a node among your best nodes is elected master. You don’t need to worry about it.


If replication is not sufficient, you may consider whether any of the various persistence modes of RTI Queuing Service fits your needs. Using replication does not guarantee the integrity of your data under catastrophic failure affecting all or most of your nodes. But your data will survive almost anything if persistency – perhaps combined with replication – is used across multiple nodes. RTI Queuing service features configuration persistence and two modes of data persistence.

The two data persistence modes supported are quite different and may be useful in different situations. If you have many queues or you are keeping in the queues a very large number of messages (so large that they will not fit in your volatile memory), you can use a persistence mode based on an underlying database implementation. In this mode all the messages and their metadata (the message state) is at all times in your database (in your hard drive) and only there. On the other hand, if you do not have a large number of messages in the queues and want better performance, you can choose an alternative mode that keeps the messages’ metadata in both the volatile memory and the hard drive while messages themselves are kept only in a file system in the persistent storage.

Both persistence modes support the familiar hard drive synchronization modes that control whether the data goes straight to the hard drive or is allowed to live for a while in your OS buffers. Hard drive operations are slow and it is frequent practice to combine multiple hard drive writing operations in one. If you set synchronization FULL, every single modification of your data or metadata will be in the hard drive the moment it takes place.

RTI Queuing Service also allows you to persist the configuration of your entire system. This is very handy if you use remote administration to create queues or to dynamically configure a large system. If you end up with a very large and finely tuned system, you’ll want to ensure that the configuration isn’t lost.

Now you can benefit from the high-throughput, low-latency capabilities of DDS, the middleware used in many of the most sophisticated real-time systems around the world. And you can do queuing with the highest guarantees for the safety and integrity of your data.

For more information about RTI Queuing Service, please visit https://www.rti.com/products/dds/queuing-service.html.

A new family member: RTI Queuing Service 1

Author: Javier Povedano

Hey, have you heard the news? RTI is glad to announce a new member in the Connext family: RTI Queuing Service. It brings a bunch of cool new features to satisfy more use cases.

Typical Publish/Subscribe model vs. message queue model.

Figure. Typical Publish/Subscribe model vs. message queue model.

With the rise of cloud computing and Software as a Service (SaaS), queuing services have become more popular in recent years. The main purpose of queuing services is to provide a model in which a message is delivered to only one recipient based on certain criteria  When using the queue model, message generators (Producers) rely for the delivery of messages on a broker, which delivers messages to Consumers based on predetermined delivery strategy (for example, round robin). This approach makes queuing services the best candidate for load balancing and dispatching tasks among consumers.

Until the arrival of RTI Queuing Service, DDS Connext product family was more focused on publish-subscribe and request/reply scenarios. That doesn’t mean it was not already possible to perform one-to-one communications using the request/reply API or even implement round-robin delivery strategies at application level. The difference is that now, with Queuing Service, things become easier: users don’t have to worry anymore about implementing their own scheduling/dispatching strategy.

Apart from the one-to-one communication model, RTI Queuing Service brings a lot of new and exciting features and capabilities:

First, it is built using regular Data Distribution Service Topics, so you can still use the same standard API to communicate with Queuing Service including its rich set of Quality of Service (QoS) settings. The use of Connext DDS also brings another advantage: users can use existing Connext tools and services to communicate with Queuing Service.

Second, to make things more natural to users familiar with Queuing Services, RTI also provides a C# wrapper API based on introducing four new entities that are closer to message queuing concepts: QueueProducers, QueueConsumers, QueueRequesters, and QueueRepliers.

Third, it provides a REST-like remote administration API to inspect the status of the queues and samples. With this API, users will be able to create/delete queues, inspect their contents, access stored samples and their delivery status, and flush queues remotely.

Fourth, it provides an extra level of reliability thanks to its persistency capabilities. RTI Queuing Service offers persistence modes that allow undelivered samples to survive system crashes. With this mode, messages are saved on disk until they are delivered and acknowledged by a consumer, so they can be redelivered when the system is restarted after a failure. In addition, the persistent mode also allows the current configuration to persist on disk, so queues created remotely won’t be lost if the system is restarted.

Fifth, it provides a one-of-a-kind replication mechanism to support High Availability (HA) scenarios. When using replication, queues and samples are automatically replicated through multiple RTI Queuing Service instances working in coordination, so in case of failure, another replica can continue the delivery of samples to consumers seamlessly.

With all these capabilities, RTI Queuing Service has all the ingredients to satisfy use cases where the load-balancing and round-robin message distribution are important.

RTI Queuing Service is available as an add-on product to RTI Connext 5.2.0, on selected platforms.

Where to Find Things in 5.2.0 Reply

In 5.2.0, we’ve made some changes to simplify our directory structure, make our file size smaller, and make your downloads shorter.  In that process we’ve moved some files around, so here’s what you need to know:

Directory Structure Overview

rti_connext_dds-5.2.0/ Top-level RTI directory for all libraries, tools, and services.
  • bin/
Scripts to run tools, services, and utilities.  These scripts set up the environment correctly for RTI’s applications.
  • doc/
Documentation for all installed products, including manuals and APIs
  • include/
Header files for all installed products
  • lib/
All Connext libraries in the RTI SDK
  • java
Location of jar files.  Update your Java classpath to include these libraries.
  • <architecture>
Static SDK libraries you can link into your application and dynamic libraries you can add to your system-specific library path.
  • resource
Location of XML files, IDL files, example templates, and additional installers


All of our host bundles are now installed with installer executables. These should be pretty self-explanatory. We will always place the installation in an “rti_connext_dds-5.2.0” directory in the path you select.

All targets and add-ons are now being distributed as rtipkg files.  You can install rtipkg files using the RTI Package Installer – either through Launcher on the Installation tab, or at the command line using bin/rtipkginstall[.bat].

Changes to your Build System

rtiddsgen Location

The rtiddsgen script has moved from the scripts directory to the bin directory. If your build system automatically calls rtiddsgen to generate code from your IDL files, you will need to update your build scripts to call rtiddsgen from:


Java Development

If you develop Java applications, download any target bundle for your platform and add the lib/<architecture> directory to your library path. Note that you no longer need to add the jdk suffix to generate example code – instead you specify the target architecture you installed and the language as Java, such as:

rtiddsgen -example i86Win32VS2008 -language Java HelloWorld.idl

On Windows, you must either have the version of Visual Studio installed that matches the target architecture – such as Visual Studio 2008 for libraries in target architecture i86Win32VS2008 – or you can download a version of the Microsoft Redistributable Package that matches the target architecture you have chosen.  The Microsoft Redistributable Packages can be downloaded here.

.Net Development

If you are developing for .Net, you should download a target that maps to the version of the Visual Studio and .Net framework you are using.  All the necessary .Net libraries will be inside the target directory with the core libraries.  The targets map to .Net framework versions as shown in the table.

When you generate example code, you can specify the architecture name without specifying a .Net framework version.

i86Win32VS2008/x64Win64VS2008 .Net 2.0
i86Win32VS2010/x64Win64VS2010 .Net 4.0
i86Win32VS2012/x64Win64VS2012 .Net 4.5
i86Win32VS2013/x64Win64VS2013 .Net 4.5.1


The first time you run any RTI script, RTI’s examples will be copied into an rti_workspace directory.  This allows you to build and modify examples even if your installation is in a shared or non-writable location.  The default location where the workspace is copied is:

  • Mac OS X systems: /Users/your user name/rti_workspace/5.2.0/examples
  • Linux and other UNIX-based systems: /home/your user name/rti_workspace/5.2.0/examples
  • Windows systems: your Windows documents folder\rti_workspace\5.2.0\examples

You can choose not to copy the examples or to copy them to another location.  There is information on how to do that in the Getting Started Guide.

On the Floor at NIWeek: Presentations, Demos, New Technologies and Best Product Award! Reply


From the in-depth presentations, interactive panel discussions, technical training sessions, to the abundance of networking opportunities with peers and industry leaders, the 21st annual NIWeek conference is alive and kicking!

The conference opened on August 3rd in Austin, Texas, and true to Austin’s roots, the event was peppered with amazing rock music during keynotes and jazz at the Tuesday evening floor show.

Jazz at NIWeek 2015

This energy was infectious as once again NIWeek brought together the brightest minds in engineering and science. More than 3,200 innovators representing a wide spectrum of industries, from automotive and telecommunications to robotics and energy, came to Austin this week. Everyone was looking to discover the latest technology to accelerate productivity for software-defined systems in test, measurement, and control. Hopefully you are attending, because it is a fantastic event! RTI is in booth #1018 as well as the Pavilion at booth 805L where we are featuring our LabVIEW Tools Network demo.

Additionally, RTI’s Brett Murphy, our Director of Business Development, is presenting two sessions today:
Distributed Hardware-in-the-Loop Simulation With CompactRIO and DDS LabVIEW (2:15-3:15PM)
Data Communication Security for the Industrial Internet of Things (4:45-5:45PM)

RTI was also mentioned in the joint Cisco/NI Keynote this morning, Both Cisco and RTI are active members of the Industrial Internet Consortium (IIC). Our CEO, Stan Schneider is on the IIC Steering Committee. The IIC brings together organizations and technologies to accelerate growth of the Industrial Internet by identifying, assembling and promoting best practices. The Cisco/NI keynote highlighted our joint IIC efforts. In addition to the keynote, Cisco also featured RTI in their NI/IIC demo on the show floor.

Cisco featuring RTI in their NI/IIC demo

Lastly, we’re happy to announce that one of our products, RTI DDS Toolkit for LabVIEW, has been awarded the 2015 LabVIEW Tools Network Product of the Year award!

NIWeek 2015 RTI Accepting Award

The toolkit provides fast, scalable and interoperable publish/subscribe messaging for distributed applications. You can use it to share real-time data between LabVIEW applications and any other applications written in C, C++, C# and Java. The resulting solution works over any transport and can scale to hundreds or even thousands of heterogeneous applications across local- and wide-area networks. You can learn more about the product by visiting the NI Tools Network or by watching this brand new whiteboard video:

We hope to see you at the show!

Modern C++ is here! 1

We are thrilled to announce that the Modern C++ API for RTI Connext DDS is complete and publicly available now with RTI Connext 5.2 (data sheet). A lot of our customers have already experienced a new way to write DDS code through our preview version—we hope you’ll enjoy it too!

This brand-new C++ programming API, based on the ISO/IEC C++ 2003 Language DDS PSM (DDS-PSM-Cxx) specification, brings modern C++ techniques and patterns to DDS, most notably:

  • Generic programming
  • Integration with the standard library
  • Automatic object lifecycle management, with value types and reference types
  • C++11 support: move constructors, initializer lists, lambdas, range for-loops, and more

We’ve also updated the code that rtiddsgen generates for your IDL types.

Where can you start?

Ah! If your system is using the previous C++ API and you still want to take advantage of all the other great features and bug fixes in 5.2, don’t worry. It’s still fully supported—now we call it the Traditional C++ API.

Stay tuned for more Modern C++ here at the RTI blogs, coming soon!

I love Eddy Reply

Our releases are named after mountains. These internal project names sometimes are shared with our users. This can create for some consternation, as we learned with our 5.1.0 release. This release was named for a local Bay Area mountain: Mt. Diablo. Mount Diablo is a wonderful state park, with beautiful hikes in Rock City and breath taking vistas from the top. If you drop the “Mount” from the project name, folks get weary about your software.

Mount Eddy

Our current major release, RTI Connext 5.2.0, is internally called “Mount Eddy”, the highest summit in the Trinity Mountains.


We love Eddy.

… because Eddy is even more alive than any previous release. We updated the liveliness mechanism with some critical fixes.

… because Eddy creates Java Eclipse projects for me with all the build and runtime paths set up correctly!

… because Eddy’s thinner!  Eddy lost almost a gigabyte of weight!  (Eddy works out, and never skips leg day!)

… because Eddy provides unbounded love. … and unbounded sequences … and unbounded strings.

… because Eddy is a unifier among all the tools and services. A single JRE. A single unified directory structure. A new launcher.

… because Eddy is so supportive.  Eddy supports Android, latest RHEL 7, Ubuntu 14.04 spanking new VxWorks 7, Integrity 11, QNX, PPC, x86 and ARM. Tools on the Mac. Latest Windows toolchains. (Ooh, so multi-platform!)

… because Eddy delegates well, and hangs with external load balancers. “Hey buddy, how’ you doi’n?”

… because Eddy makes me feel secure, with improved TCP/TLS enhancements and two-phase participant discovery.

… because Eddy speaks klingon … I mean … supports the latest C++ PSM.

… because Eddy is an artist. Pretty lines, pretty pictures in the new Data Visualizer.

… because Eddy is patient and can wait in a queuing service line.

… because Eddy is wickedly fast. Generate code? .. poof .. done. Filter content … What content?  (Like a magician!)

… because Eddy continues to be a polyglot: C, C++, C#, Java, Lua … and even ADA right from the gecko. (So cultured!)

… and of course Eddy’s such a good communicator!

We hope you like our new RTI Connext 5.2 release. Check for more technical details in future blog posts.

More on 5.2: Press Release  |  Data Sheet

The Industry-First Vendor-Backed FACE ™ 2.1 TSS Reference Implementation is Here! Reply


A few weeks ago, we released a new version of our Future Airborne Capability Environment (FACE) Transport Service Segment (TSS) Reference Implementation. This new release is based on the FACE Technical Standard, Edition 2.1.

We introduced our first FACE TSS implementation two years ago. Since then we have worked with several military organizations to enable interoperable and reusable avionics systems. The result of our hard work is this new release. We hope that it will bring the power of DDS into next generation systems by providing an open, flexible and robust Commercial-Off-The-Shelf (COTS) communications foundation. There are three things in this release that we are excited about.

First, we are the first company to release a fully supported and vendor-backed TSS 2.1 reference implementation. Avionics software developers and platform integrators can now combine best-of-breed technologies with COTS components with proven safety certification credentials. This reduces integration and airworthiness certification risk while facilitating reuse across both manned and unmanned systems. For example, a surveillance system built for a Navy aircraft can be used in another vehicle without requiring a full system rebuild..

Second, the new FACE TSS implementation now supports C++. It includes a customized version of rtiddsgen that generates the C++ API specific to the message types that a component exchanges. The FACE standard requires that components (known as “Units of Portability”) use this type-specific interface and that component suppliers provide an IDL specification of the types.

Third, we provide the TSS Reference Implementation as portable source code. Customers are free to modify it to meet their own requirements. If you are a Connext DDS customer, we provide the TSS at no charge. For basic support and training, customers may optionally purchase an annual TSS Support Package. Customers may also contract with RTI Services to enhance the capabilities of the TSS to meet system-specific requirements.

To learn more about our new FACE TSS Reference Implementation, check out the FACE content on our website or watch the webinar on FACE Standard for Avionics Software and a Ready-to-Go COTS Platform.

Reaching for the Stars Reply

Listening this morning to an interview with science writer Brian Clegg, I got to thinking about how the smallest things can have the biggest impact. Clegg just published his latest book, The Quantum Age: How the Physics of the Very Small has Transformed Our Lives. In the interview, he noted that around 30% of the GDP for a developed country like the United States stems from inventions based on quantum physics, including lasers, microprocessors, and mobile phones.

Despite influencing our day-to-day lives in such ways, we often like to think of quantum effects in terms of weird things that don’t seem to make sense, like particles travelling back in time or teleporting: the stuff of science fiction.

For many science fiction fans like me, the gap between the dream of interstellar travel,teleporters that harnessing this quantum “weirdness” and the more prosaic reality of today’s limited space exploration is a bit of a let down. The fact that the Voyager 1 probe, the most distant person-made object, is still only 18 light hours from earth is somewhat at odds with the distances travelled during a typical episode of Star Trek.

On June 3, 2015, however, a very interesting feat was performed, one that brings the prospect of substantial planetary exploration closer. On that date, NASA astronaut Terry Virts shook hands with André Schiele from the European Space Agency (ESA) – and, crucially, each felt the strength of the other’s grip. What’s remarkable about this historic handshake is that the two men were 5,000 kilometres apart – one on the International Space Station (ISS) and the other firmly on the ground here on Earth.

Space station hapticTerry Virts performing a handshake on the ISS

This experiment demonstrated that it is possible for one person to precisely and instantly control an object on a planet’s surface from a location in space thousands of kilometres away, and to do so as if they were holding that object in their hands. That possibility offers the opportunity to explore planets intimately without ever setting foot on them. This is hugely significant because one of the limitations of planetary exploration is the extreme difficulty of landing astronauts on a foreign body and subsequently launching them safely back into space for the journey home.

Another limitation is the time it takes for signals to travel between Earth and other planets. For example, it takes 24 minutes for a command to travel on a roundtrip to Mars, our nearest planetary neighbour, which makes operating the Mars Rover remotely from Earth a challenging endeavour.

The most effective way to enable robotic exploration is to have an astronaut near enough to control the rover, preferably orbiting the planet, and this is exactly what the experiment proved is possible. Critically in this case, the demonstration proves not only that it is possible to move something, but by experiencing force feedback in real time, it becomes possible for the astronaut to act as if he or she were actually on the ground directly performing the task.

ISSThe International Space Station

This type of real-time communication leverages standardisation initiatives by the Open Management Group – in this case, an open real-time communications standard, the Distributed Data Standard (DDS), implemented by Sunnyvale’s RTI Inc. and used by the ESA for this experiment. (The learnings from this and other uses of the DDS standard are enabling a whole new era of communication between intelligent machines called the Industrial Internet of Things.)

By removing the need to develop a safe landing and take off system for humans, the ESA could take years and billions of dollars off the time and cost to reach further into the cosmos and learn more of its secrets. Accomplishments like the June 3 “handshake” will hopefully continue to fire the imagination of innovators to explore the quantum world on the ground as well as the frontiers of space, to the mutual benefit of all of us through continued growth of global GDP.

Further Reading: