RTI software helps run BlueFin unmanned underwater vehicle

CAMBRIDGE, Mass. - Officials at BlueFin Robotics Corp. needed a middleware to distribute data between applications for their BlueFin 9 Unmanned Underwater Vehicle (UUV). They found what they were looking for with the NDDS (Network Data Distribution Service), from Real-Time Innovations (RTI) in Sunnyvale, Calif.

The BlueFin unmanned underwater vehicles use the Network Data Distribution Service middleware from Real-Time Innovations for interprocessor communications.

RTI’s publish-subscribe middleware, based on the Object Management Group’s (OMG) Data Distribution Service (DDS, V1.0), standardizes the software application programming interface (API) and underlying communications model a ­developer can use to create distributed ­applications. DDS is based on the Data-Centric Publish-Subscribe communications paradigm that offers the application developer a high level of abstraction and yet controls all the quality-of-service parameters needed for deploying real-time systems, RTI officials say.

“By using NDDS as a reliable and tested communications middleware, we have the time and resources to develop autonomy and operator tools that make us stand out from our competitors,” says Christopher Smith, software manager at BlueFin Robotics in Cambridge, Mass.

The primary issue with an underwater vehicle is communications; oftentimes communications with the vehicle are very limited or not existent at all. The UUV is preprogrammed and configured for a specific mission and then released in the water to perform its mission. Once the vehicle is underway, recovering the vehicle upon failure is near impossible; therefore the systems that control the vehicle must be extremely reliable to insure mission success and vehicle recovery, RTI officials say.

Officials at BlueFin Robotics selected NDDS as the communications framework for internal and external vehicle messaging because of its ability to address all of their current needs with the future ability to expand the number of processors in the system. The environment for the UUV uses two processors, with several processes running on each. NDDS is for the three types of interprocessor communications: streams, commands, and configurations, RTI officials say. The source of stream data is primarily sensors in which nonreliable, “last is best” type of messaging applies. In contrast to stream data, command and configuration data must be conveyed reliably to its receivers in order to maintain vehicle safety.

“The DCPS communications model excels at efficiently distributing data between applications,” says Gerardo Pardo-Castellote, RTI’s chief technology officer and co-author of the DDS specification. “Establishing communications is simple. Publishers register data they will be producing with the middleware and subscribers register the data they are interested in receiving. The publisher just sends or publishes the data. This model is robust, efficient, and data-centric.”

BlueFin Robotics engineers had several primary concerns with choosing an appropriate middleware: low-latency real-time performance; per message ­reliability/determinism; modularity and ­abstraction; heterogeneous communication environment; and expandability, RTI officials say.

The current design of the BlueFin 9 UUV uses two processors with an extra port for outside communications, according to RTI officials. By using NDDS between all processes on both nodes, BlueFin can expand their vehicle’s performance by moving processes to new processors. The NDDS publish/subscribe communications frame­work enables the future upgrade and expansion to take place with very little effort or concern about porting, code reuse, or implementation, RTI officials say.

The streams of data from the UUV sensors have critical information that the main vehicle computer needs without delay. NDDS best effort communications for all sensor data provides BlueFin with a low-latency message channel.

The nonstreaming data, consisting of commands and configuration, requires that reliability of those messages be maintained between publication (sender) and subscription (receiver). NDDS gives devel­opers the ability to specify which messages should be reliable and which messages should be deterministic, RTI ­officials say. Also, the ability to specify how many past messages NDDS will keep on a per message type (also called a “topic”) basis, ena­bles the system architects to tailor each mes­sage type to its own specific timing and reliability ­requirements.

NDDS allows users to subscribe to a data topic without knowing who is sending the data or when it will be sent. This allowed the individual BlueFin developers to work with minimal interaction with each other. It also makes it easy to perform unit testing, integration, and full system testing by simulating incoming messages to match real-world environments, RTI officials claim.

The nodes inside the BlueFin 9 UUV are running Linux on a Pentium CPU ­architecture, while the Operator Control node aboard the ship uses a Microsoft Windows platform. Because NDDS handles all data conversions and data serialization between nodes, having mixed platform environments of this nature is not a problem, RTI officials say. NDDS supports these platforms as well as Solaris and other real-time operating systems, enabling BlueFin to add or change platforms and architectures without changing their software framework.