Surgical Robots and Space Rovers: Down-to-Earth Architectural Lessons from Mars Reply

The use of robotics is growing across all industries and all facets of our lives. Robots can be found virtually everywhere, doing tasks ranging from mundane to extraordinary. Today, robots are used for sorting and distributing packages in distribution warehouses, for diffusing bombs in military campaigns, for space exploration on Mars and beyond, for minimally invasive surgery in operating rooms, for underwater exploration, for controlling autonomous tractors in agriculture, and much more. Even our cars are evolving into self-driving robots.

In order to effectively serve these many roles, robotic systems are becoming more and more complex, involving many processors working together and integrating disparate components into a heterogeneous system. These complex systems require mission-critical execution as well as real-time performance.

To meet these requirements many companies are turning to the Data Distribution Service (DDS) standard for the communication backbone of their robotic systems. DDS is a middleware protocol and API standard for data-centric connectivity from the Object Management Group (OMG). It’s used to integrate components of a system, providing low-latency data connectivity, extreme reliability, and a scalable architecture that business and mission-critical required by Internet of Things (IoT) applications.

 

 

And the good news is that RTI’s DDS implementation is being used by (or designed into) many of the robotics applications listed above. RTI Connext DDS is extremely well suited to robotics applications because it provides:

  •      High reliability. Connext DDS is industry-proven, it’s been used in mission-critical applications around the world, and it has been deployed in more applications than any other DDS implementation.
  •      Security. Connext DDS Secure provides the world’s first standards-compliant, off-the-shelf messaging platform that delivers the security, performance, and safety required for Industrial IoT deployment. It complies with the new Data Distribution Service (DDS) Security specification from OMG.
  •      Safety certification. Connext DDS is the only DDS implementation to achieve DO178A level C certification.
  •      High throughput and low latency communication.
  •      Support for communication transports. This includes UDP, TCP, bare, CAN bus, and shared memory. RTI’s DDS implementation includes a plugin transport architecture that makes it easy to create custom transports.
  •      Standardization. DDS provides a standard API allows developers to port DDS applications to any DDS implementation. DDS also provides a standard wire protocol (RTPS) that allows different DDS protocols to communicate with each other. This provides interoperability and eliminates vendor lock-in.

To learn more about RTI Connext DDS and its support for robotics applications, please join us at the upcoming seminar:

Distributed Robotic Control: Learn from the Experts

Hilton Garden Inn

Waltham, MA

9:00am to 12:00pm

June 15

Learn More and Register 

 

More Reasons to Love Eddy Reply

If you follow RTI blogs, you would remember Eddy was our project code name for Connext DDS Professional version 5.2.0. And you would remember how much we loved Eddy when it was released in summer last year. During the cold winter and spring, we spent a great amount of effort to make Eddy even better. Now Eddy has matured into version 5.2.3, which we are announcing this week!

One of the reasons we loved 5.2.0 was its support for unbounded sequences and strings. This feature enables our customers to efficiently manage memory when dealing with samples containing sequence or string members whose maximum size is unknown or quite large. A good example of a system that can benefit from this feature is video surveillance, where a developer may not know in advance the maximum size of the video frames sent on the wire. When we released Eddy, the feature was available for C++, C and .NET developers. In version 5.2.3, we added Java support for this feature. If you code in Java, check it out. You can learn more about unbounded sequences and strings in this Eddy blog.

Another reason we loved 5.2.0 was its ability to serialize/deserialize samples into/from a buffer. Applications could use this feature for different needs. For example, customers could save the serialized data in a database, disk or memory and access it offline to perform data analytics. In version 5.2.3, we added support for this feature to DynamicData in Java and .NET through the APIs:

  • DynamicData.to_cdr_buffer
  • DynamicData.from_cdr_buffer

Also, don’t forget to check out Connext Tools. With version 5.2.3, you can now replay multiple files as easy as how you recorded them, with simple configuration and no extra steps. If you are new to Connext Tools, take a look at this video explaining our data visualization feature in details, with great tips on leveraging it for debugging and developing your applications.  

You can never have too much security! Version 5.2.3 continues the mission of securing our customer’s systems with the latest and greatest OpenSSL. Well, almost the latest. Just a few days before we released 5.2.3, which supports OpenSSL 1.0.2g, OpenSSL announced version 1.0.2h.

More good news: The 5.2.3 release is even more “supportive” than 5.2.0. It adds support for the latest Visual Studio version (VS2015) and the latest Mac OS X (version 10.11, El Capitan).

Lastly, we have special news for mobile developers. The 5.2.3 release introduces Connext DDS to one more mobile operating system in addition to Android. Yes, iOS! Version 5.2.3 supports iOS 8.2. We look forward to your innovative iOS DDS applications soon!

iOS Suppport 5.3.2

So, if you loved Eddy, I am sure you will love our latest and greatest 5.2.3 release of RTI Connext DDS even more. Download the free trial and give it a try today!

Automatic QoS Enforcement with DDS & Software Defined Networking Reply

Andrew King

Author: Andrew L. King Ph.D. Candidate, Department of Computer and Information Science, University of Pennsylvania

Good abstractions drive progress in computing. The first turing-complete computers such as the ENIAC exposed a register-level programming abstraction enabling programmers to reconfigure the machines for different tasks. In the 1950s – 1970s the maturation of compiled languages enabled programmers to more easily port software from one machine architecture to another. From 1980 to the late 1990s saw the development of modularity abstractions (e.g., object oriented programming) making it easier to distribute the development of large software across large teams.  Throughout the 2000s to the present we’ve seen the development of programming abstractions designed to make it easier to build distributed and concurrent software systems.  DDS is a perfect example and its success proves how useful and necessary good abstractions are.

rti_blog_graphic.001

I’d argue that good abstractions for programming the IIoT must capture timing behavior. For example, DDS lets the programmer specify the maximum interval between updates to a topic data-instance via the DEADLINE parameter. Unfortunately, so far, holistic abstractions for timing have been elusive. While DDS can automatically perform runtime checks to ensure that DataReaders and DataWriters have consistent  DEADLINE QoS settings,  it is still possible for the DEADLINE QoS to be violated if the underlying network fabric delays or drops an update. Indeed, Bringing timing fully into the programming abstraction is difficult because the timing behavior of a software system only emerges when you map the software onto a particular platform (i.e., processor, operating system, and networking fabric).

In the context of a critical distributed hard real-time system, the developer must devote significant effort provisioning and configuring the underlying network fabric to ensure the required timing behavior. The configuration process usually involves setting priorities or transmission schedules for each time critical flow. Sometimes, If the underlying network fabric will be shared by more than one logically independent application, traffic policers and/or special partitioning features are setup to keep the different applications isolated. These network configurations are usually static and setup offline: If you want to add a new node to the network (e.g., a sensor or actuator) you have to bring the system down, manually reconfigure the network, then bring the system back up. Wouldn’t it be much nicer if the programmer could simply specify the logical timing behavior for the system and then trust that the specification would always be satisfied?

DDS and recent advances in Software Defined Networking (SDN) now make it possible to fully lift timing properties for distributed systems into a programming abstraction. The MIDdleware Assurance Substrate (MIDAS) is a research prototype developed in the PRECISE Center at the University of Pennsylvania. MIDAS  uses the OpenFlow SDN protocol to capture the QoS specifications of DDS clients as they come online and then control  the packet switching behavior of the network fabric to ensure those specifications are always satisfied: Based on the captured QoS specifications, MIDAS will generate  new network configurations to support the QoS of the DDS dataflows.  MIDAS will then apply schedulability analysis to verify that the configurations will guarantee the specified QoS. Finally, If the requested QoS can be guaranteed MIDAS will push the new configuration onto the network transparently (The QoS of existing flows will not be disrupted by the reconfiguration process itself).

Technologies like DDS make the development and operation of distributed real-time systems easier, faster, and overall less costly. Adding technologies like MIDAS to the mix takes these benefits to the next level:

  • Reduce Development Time: Automation of network configuration removes a significant chunk of development effort allowing developers to focus more on creating functionality (and hence value for their customers).
  • Reduce Equipment Costs: Many common COTS ethernet switches now support OpenFlow and can be used with MIDAS to support hard real-time systems. Many deployed ethernet switches can be made OpenFlow capable with a simple firmware update.
  • Increased Flexibility and Adaptability: MIDAS lets you add and remove network nodes at runtime. All resource provisioning is dynamic and ensures that no QoS is disrupted during configuration.
  • Increased Reliability: MIDAS’ network configurations ensures traffic bursts won’t overload buffers in networking equipment which means packets will only be dropped if there is a hardware failure.

If you are interested in knowing more about MIDAS and how it works please read the associated technical paper* or contact me (Andrew King, kingand@cis.upenn.edu). I’d also like to invite you to watch the the following youtube video. It demonstrates a distributed hard real-time system built using RTI’s Connext DDS with real-time behavior enforced by MIDAS:

*The technical paper describes an earlier prototype which used a simple custom publish/subscribe middleware. The current prototype is designed to work with DDS but the fundamental technical details are unchanged.