## 3 Description of the Maritime Data Transfer Protocol
### Messages from the Maritime Data Transfer Protocol  
The middleware follows the Data Distribution Service (DDS) specification which supports Data-Centric Publish-Subscribe (DCPS) in real-time systems. DDS is a middleware protocol standard for data-centric integration that features extensive fine control of real-time QoS parameters. MDTP relays on the Object Management Group (OMG) standard referred to as DDS Interoperability-Real Time Publish Subscribe wire-protocol (DDSI-RTPS) [42] for implementation works, as it guarantees interoperability with the three main DDS solution providers, i.e., Twin Oaks CoreDX DDS [43], OpenSpliceDDS (PrismTech, Stirling, UK, [44]) and RTI Connext DDS [45]. According to DDSI-RTPS, a message has a header and one to several possible submessages. The header contains information about the RTPS protocol, the vendor and the Globally Unique Identifier (GUID). Each of the submessages has it own submessage header with an id that identifies the type of submessage, and one to several submessage elements. In a communication between the middleware and a vehicle each message PDU will contain three submessages (as represented in Figures 3 and 4): a submessage with information about the timestamp (INFO_TS), a submessage with the data we want to transmit (DATA) and a submessage to inform that there is data available in the writer (HEARTBEAT). Depending on the vendor, there are differences in the size of the message PDUs. A default PDU with a serialized data of 63 bytes has a size of 138 bytes with Open Splice DDS Community version (OSPL) whereas with Twin Oaks CoreDX DDS, it has a size of 106 bytes. The main difference is  
Figure 4: Message PDU with Twin Oaks CoreDX DDS. Figure 3: Message PDU with Open Splice DDS Community version. that OSPL uses 40 bytes for default QoS specification whereas TwinOaks includes a generic vendor submessage of size 8 bytes. The Serialized Data section of the PDU contains the information to be transmitted between the endpoints of the communication, namely the middleware and AUVs. In our scenario, there are two possible communication channels: an acoustic channel (provided by acoustic modems manufactured by Evologics), to be used when AUVs are underwater, and an IP channel or high bandwidth radio link (e.g., WiFi), to be used when AUVs are at the surface level. Being the bandwidth for acoustic communications very limited, as it has already been explained, the type of information expected to be exchanged between the middleware and AUVs when they are underwater has been analyzed, in order to minimized the size of the PDUs to be transmitted. Several different kinds of data have been define with the purpose of transferring data according to the needs of a mission, or the tasks it is subdivided in. These different types are as follows:  
1. Environment data. These are the data that are related to the surroundings of the location where the autonomous maritime vehicles are deployed. 2. Status: The pieces of information collected from here are about the vehicle that has been deployed. They complement the environment data because status data offer the information that was omitted by them. 3. Situational information: The data deal with the location and movements of the autonomous maritime vehicle that is deployed, such as location, turning parameters or vehicle speed. 4. Other information: These data contain all the information about other features of a deployment, like the algorithm that has been used for positioning. The information of interest susceptible to be exchanged has been summarized in Table 3: