(working title)

A data distribution system for cooperative mobile autonomous agents (specifically, AUVs), whose point-to-point communication is subject to uncontrollable loss, up to 4 seconds of one-way latency, and complete disconnection of indeterminate duration. Beyond enabling reliable networking over unreliable links, this system enables autonomous balancing of communication needs with mission completion.

These pages are linked in-text, but also provided here for easy reference:

• MCCIWireProtocol
• MCCIDistributionSchema
• MCCIServerOperation

Consider AUVs A, B, C, D, E, and F with the following data links, red for underwater acoustic and blue for abovewater radio ethernet:

We seek to enable the following use cases for communication in unified manner:

1. Simple one-off requests: D requests information from E, which is delivered via the acoustic link

2. Multihop one-off requests: C requests information from E, which is delivered via the acoustic link

3. Best-path: B requests information from D, which is delivered via the radio link

4. Heterogeneous networking: B requests information from E, which is delivered via a combination of acoustic and radio links

5. Distributed caching: A requests the same information from E, but B delivers a cached copy of it without forwarding the request

6. Dead drops: B delivers information to D and disconnects. Later, F connects to D in order to retrieve the information that originated from B

   

7. Communicative behavior: A needs a high volume of data from E, so both vehicles decide to surface and establish a radio link between themselves

   

We require these cases to remain operable in situations where packet losses are at least 50%, and where single-hop delay is at least 5 seconds.

MCCI is meant to be a pragmatic extension of (and in some areas, a replacement for) existing AUV software systems that are industry-accepted as correct approaches to the problem of AUV autonomy. There are several paradigms that MCCI must integrate with if it is to be useful.

The star-topology concept of MOOS is at the core of the MCCI design. A vehicle's autonomy suite might be split into several (if not dozens) of individual software processes, and these process may be spread out over several individual computers (possibly running different OSes). However, these processes and machines are integrated by connecting to a single communications server, over a LAN if necessary. The communications server provides a blackboard-style architecture, where a set of named variables are constantly updated via messages sent from the individual clients. Clients are able to request to be notified of any updates to these variables, along with the new values.

The server exerts no control over which clients might update a given variable, however it does offer the guarantee that the data type for each variable will remain constant (i.e., a string variable will always be a string, integer will always be an integer, and so on).

MCCI will integrate with all communications technologies currently used by AUVs

• acoustic modems, via existing Goby libraries
• radio ethernet (FreeWave)
• WiFi
• Iridium

To avoid all conflicts between programming languages and OSes, MCCI is defined as a wire protocol_. The server will maintain "good behavior" on the part of its clients (in terms of proper handshaking and request/response), but there will be no compile-time nor run-time dependencies between the server and any of the clients.

MCCI will support structured data types, specifically employing Google Protocol Buffers for serialization and deserialization of published data.

Parallel development of autonomy software components has many advantages, but also creates problems. Between a given set of client applications, the variable names, data structure definitions, and the mappings between them may change -- different codebases and different AUV platforms may be involved.

Although it would be highly impractical (if not impossible) to prevent the errors or erratic behavior caused by these sorts of divergences, we can make inconsistencies in data structures easier to detect and easier to correct. This is a byproduct of a bandwidth-saving technique called a distribution schema_.

We need a good system for creating, managing, and versioning the run-time configuration of the system.

Applications have settings, vehicles have many applications. Further, several vehicles might be configured to work together in the same cruise.

We need a good system for monitoring the (standard) output of clients.

We need a good system for launching and managing a set of clients.

We need at least the following tools for a usable system:

• Viewer (and editor) for the output of any variable
• A tool for visualizing the production/consumption graph of each variable by clients
• General-purpose plotting tool that understands data structures. This tool should be able to unpack numeric values from fixed-length data structures, and extensible with handlers for more complicated data types.
• A rich logger and playback tool
• A network visualization tool

We need the ability to alter the "clock speed" of all clients for faster simulations.

The system must provide robust abilities for clients to request the data they need, when they need it. The system must not deliver data whose relevance has lapsed; only data that is of value to its recipient should be transmitted, and it should be sent in order of that value.

The system must exploit multicast communications when appropriate, and exploit its ability to eavesdrop.