Simulation Trial Results for the Cooperative Autonomous ... · Simulation Trial Results for the Cooperative Autonomous Underwater Vehicle Demonstration (SA15) Anthony Travers Maritime

UNCLASSIFIED

Simulation Trial Results for the Cooperative

Autonomous Underwater Vehicle Demonstration

(SA15)

Anthony Travers

Maritime Platforms Division

Defence Science and Technology Organisation

DSTO–TN–1171

ABSTRACT

A simulation trial was conducted to test the connectivity between the twoheterogeneous software systems that were part of a cooperative AutonomousUnderwater Vehicle Demonstration being undertaken by the Australian andSingaporean defence science agencies. Since the final, demonstration trial wasto be undertaken in Singapore, with no possibility of undertaking repeat tri-als, a risk management strategy was developed. This included, where possible,using the internet to simulate connectivity and communciation between thetwo nations’ vehicles. The trial, which involved connecting the mission man-agement systems of the two vehicles, and testing the High Level Protocol’sfunctionality for the prescribed Mission, culminated in a successful demonstra-tion of all relevant systems functioning together.

APPROVED FOR PUBLIC RELEASE

UNCLASSIFIED

DSTO–TN–1171 UNCLASSIFIED

Published by

DSTO Defence Science and Technology Organisation506 Lorimer St,Fishermans Bend, Victoria 3207, Australia

Telephone: (03) 9626 7000Facsimile: (03) 9626 7999

c© Commonwealth of Australia 2013AR No. 015-9585May, 2013

APPROVED FOR PUBLIC RELEASE

ii UNCLASSIFIED

UNCLASSIFIED DSTO–TN–1171

Simulation Trial Results for the Cooperative AutonomousUnderwater Vehicle Demonstration (SA15)

Executive Summary

Australian/Singapore Subsidiary Agreement 15 “COOPERATIVE AUV DEMONSTRA-TION” involved the development of Mission Management software to autonomously man-age the vehicles for a trial. This software was used to maintain an overall Mission-levelrepresentation and to trigger vehicle-level behaviours in the Autonomous Underwater Ve-hicles participating in the mission.

Rapid development software techniques provided the ability to address changing re-quirements for the Mission Manager. This proved very effective in facilitating the prepa-rations for the final demonstration.

From July to August 2008, a number of internet-based simulation trials were conductedto test the ability for the Singaporean Meredith Autonomous Underwater Vehicle andDSTO’s Mullaya Autonomous Underwater Vehicle to communicate via an agreed protocol.

The simulation trial provided an important opportunity to test software integrationand thus providing a more mature robust end product. This delivered significant benefitsto the International Collaboration in terms of minimising risk, facilitating development ofsolutions to identified problems, and reducing the cost of the cooperative program.

For future similar trials, it is recommended that an equivalent simulation trial beconducted to de-risk trials by testing as much of the interconnectivity of the softwaresystems as practicable. It is also recommended that more detailed simulations of thecommunication mediums also be trialled to help develop and test the robustness of theproposed solutions (especially in challenging domains like underwater).

UNCLASSIFIED iii


THIS PAGE IS INTENTIONALLY BLANK

iv UNCLASSIFIED


Author

Anthony TraversMPD

Tony Travers is a Senior Research Scientist at Maritime Plat-forms Division of DSTO. He is responsible for the AutonomousMission Management and Collision Avoidance Systems for theAutomation and Unmanned Maritime Systems Group. Tony isalso part of a team that develops scientific visualisations for usein concept evaluation and forensic investigation within Defence.He joined DSTO in 1999.

Tony has a PhD in Artificial Intelligence from Curtin Univer-sity of Technology in Perth. He has expertise in areas such ascomputer programming, 3D graphics, artificial intelligence andsimulation.

UNCLASSIFIED v



vi UNCLASSIFIED


Contents

1 Introduction 1

2 Communication System Design 1

2.1 Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.2 The Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2.1 Buoy Position (Buoy ↔ Mullaya) . . . . . . . . . . . . . . . . . . 3

2.2.2 Vehicle Position (Mullaya ↔ Meredith) . . . . . . . . . . . . . . . 3

2.2.3 Message Check (Mullaya → Meredith) . . . . . . . . . . . . . . . 4

2.2.4 Reacquire (Meredith ↔ Mullaya) . . . . . . . . . . . . . . . . . . 4

2.2.5 Meredith MMI (Singapore Control Modem → Meredith) . . . . . 4

2.2.6 Time Division Multiplexing Scheme . . . . . . . . . . . . . . . . . 5

3 Mullaya Mission Management 6

3.1 Mission Management System Support Infrastructure . . . . . . . . . . . . 6

3.2 Integrating the Mission Manager with the Mullaya Infrastructure . . . . . 6

3.3 Mission Manager Design Concept . . . . . . . . . . . . . . . . . . . . . . . 6

4 Simulation Trial Design and Implementation 9

5 Simulation Trial Results 12

6 Conclusion 13

References 13

UNCLASSIFIED vii



viii UNCLASSIFIED


1 Introduction

Under Subsidiary Arrangement Number 15 to the Agreement between the Governmentof the Republic of Singapore and the Government of Australia for Cooperation in De-fence Science and Technology (Subsidiary Arrangement Number 15, Cooperative AUVDemonstration 2005), a Cooperative Autonomous Underwater Vehicle (AUV) Demon-stration was organised between the Singaporean Defence Science and Technology Agency(DSTA) and the Australian Defence Science and Technology Organisation (DSTO). TheSingaporean Defence Science Organisation (DSO) provided the technical capability onbehalf of the DSTA.

Under Subsidiary Arrangement Number 15 (SA15), it was proposed that the DSTA/DSOvehicle “Meredith” and the DSTO vehicle “Mullaya” conduct a cooperative demonstra-tion in Singaporean waters. The key planned events for the trial were: the deploymentof the vehicles, the vehicles transiting to a given location, the survey of an area and thereacquisition of a target that had been detected by one of the vehicles. Both vehiclesused a common type of acoustic modem to provide the sole mechanism for communicationbetween the vehicles. The cooperative trial, including details of the demonstrated mission,are described in detail in the final report of the Trial (Neill 2012).

As part of the preparation for the Demonstration, a simulation of the mission wasconducted with the aim of identifying and mitigating risks and testing the integrationof the two vehicles’ software systems. The internet was used to mimic the connectivityprovided by the acoustic modems, thus enabling remote testing of the two research teams’software systems. This Technical Note details the design, implementation and the resultsof the Simulation Trial (conducted during July and August 2008).

2 Communication System Design

Both Meredith and Mullaya are custom built vehicles with their own individual softwaresystems for control and mission management. In order to facilitate the interaction be-tween the vehicles, an abstract High Level Communications protocol (hereafter called the“Protocol”) was developed specifically for this Demonstration. The Protocol was designedunder the assumption that there was no need to interact at vehicles’ control system level.Hence it was necessary and sufficient that the Protocol provide limited command and con-firmation messages that would be sent between the two vehicles in order to coordinate eachvehicle’s mission state. The Protocol also contained data messages needed to determineMullaya’s current position.

The development of the Protocol was driven by two key aspects of the Demonstration.Firstly, underwater acoustic communications is highly error prone and has an extremelylow bandwidth (the amount of data that can be sent over a given time). Secondly, thetwo heterogeneous systems participating in the trial need to be able to communicate usingthe same “language” in order for them to communicate effectively. The Protocol provideda simple set of commands with an element of redundancy built in to the basic commandstructure (simple letter repetition inside the commands).

UNCLASSIFIED 1


Because of the complexity and variability of the physical environment, through-waterdigital acoustic communications is very prone to transmission errors (see, for example Chitre,Shaabudeen, Freitag & Stojanovic (2008)). Consequently, wherever long messages or com-mands must be sent, sophisticated error correction and/or redundancy schemes need tobe adopted. In the present case, however, given the simplicity of the commands and thefact that new commands would be transmitted relatively infrequently, it was decided thatsimple repetition of entire commands would be used to counter the expected errors in thedata (resending entire commands if an acknowledgement was not received in due time).

A simulation trial was designed to test the integration of the two heterogeneous softwaresystems. The testing mimicked the full mission being conducted and used the communi-cations Protocol to send messages between the two vehicles via an internet connection.

This approach enabled the two teams to significantly de-risk the whole programme inan environment where each team had access to a full suite of diagnostic hardware. If theapproach proved to be effective it was anticipated that the use of simulation trials, utilisingthe internet as the underlying communications framework, could become an often-usedfeature of international collaborative trials.

2.1 Connection

The DSTO and DSO AUVs were developed independently, using different operating sys-tems, different design approaches and were implemented in different programming lan-guages. The nature of the systems was also significantly different. The only effectivemeans of communication between these two vehicles was via low data rate acoustic mo-dem system (the only practical form of underwater communication currently availableto underwater vehicles). Data transmission via underwater acoustic communications issubject to high error rates due to the nature of the transmission medium.

A common abstract communication Protocol was developed to provide connectivitybetween the heterogeneous systems. Each team would independently develop its ownimplementation of the functionality detailed in the Protocol. The Protocol consists of anumber of predetermined text messages that would be sent between the vehicles. The textmessages detailed prescribed command and information messages.

For the simulation trial, an internet connection was used to replace the functionalityof the acoustic modem. No attempt was made to simulate the speed or lossy nature of theenvironment, as the focus of this simulation trial was upon the basic functionality of themission and the Protocol. Simulation of the underwater environmental factors would havebeen a valid test to perform but given the restrictions in resources it was decided that asimple functionality test was of higher priority. Given the planned vehicle separations forthe mission and the anticipated time between transmission of mission-critical commands,it was estimated that – in cases where transmission errors occurred – commands could bere-transmitted several times without compromising the mission.

2 UNCLASSIFIED


2.2 The Protocol

This section details the elements of the protocol that were implemented by the individualteams. The specification for the protocol defined both message formats and an agreedtime subdivision multiplexing scheme. Only a subset of the commands have been includedin this report - sufficient to enable the reader to understand the following discussion. Afull set of command definitions are included in Neill (2012). Protocols are reported asdefined in the present tense.

2.2.1 Buoy Position (Buoy ↔ Mullaya)

The Mullaya vehicle utilised a self-calibrating, long-baseline navigation system called Nav-Song. The operational principles of NavSong are described in Neill, Knox, Ward &Lawrence (2006) and the specific implementation of NavSong is described in a companionreport (Neill 2012).

The positions of each of the two buoys are used by the NavSong System to triangulatethe vehicle’s position. The following format was used by Mullaya’s control systems torequest the buoy’s position and receive the consequential position update. This formatwas specified by the buoy’s developer Nautronix (now called L-3 Nautronix).

Description Code Notes

Buoy Position Request $LBuoyZ where Buoy is “A” or “B”.

MGRS1Most Significant $LBuoy pos where Buoy is “A” or “B” and posis the most significant MGRS data.

MGRS Least Significant $LBuoy pos where Buoy is “A” or “B” and posis the least significant MGRS data.

The data in the Most Significant and Least Significant fields is quite distinct (the MostSignificant contains 7 Alphanumeric characters whereas the Least Significant is 8 numericcharacters only) and thus can be used to differentiate between the different contexts.

2.2.2 Vehicle Position (Mullaya ↔ Meredith)

Each vehicle will report its current position when it is able (i.e. not transmitting MissionMessages), by default sending the Least Significant MGRS field only.

1As a descriptive example, the Military Grid Reference System (MGRS) message 48NUG9076044909can be interpreted as: 48N is a Gridzone designator, where the numeral 48 corresponds to the 6 degree wideUTM zone (of which the Earth is broken down into zones 1-60) and N is a latitude descriptor, defining an 8degree wide strip in latitude (zone N covers latitude 0-8 degrees North) - UG is a 100 km x 100 km squarearea located within the 6 degree by 8 degree zone indicated by the 48N prefix - 90760 is a 5 digit east-westcoordinate, defining the longitude to an ultimate precision of one metre - 44090 is a 5 digit north-southcoordinate, defining the latitude to an ultimate precision of one metre. (Taken from Neill (2012))

UNCLASSIFIED 3



Vehicle Position PPP id pos where id is the vehicle id, pos isthe position of the vehicle (eitherMost or Least significant dependingon the context).

Most Significant MGRSrequest

QQQ id where id is the vehicle id that therequest is sent to, to request theretransmit of the Most SignificantMGRS component.

Upon receiving the Most Significant MGRS request, the recipient will transmit theMost Significant MGRS value at the first opportunity. It will then revert back to sendingLeast Significant MGRS data.

2.2.3 Message Check (Mullaya → Meredith)

During deployment, the Meredith vehicle will be sent a Message Check2 message fromMullaya. Meredith’s acknowledgement of this check demonstrates the two way communi-cations between the vehicles is functional.


Message Check CCC

Acknowledge AAA CCC Acknowledge vehicle check

2.2.4 Reacquire (Meredith ↔ Mullaya)

The Meredith vehicle transmits the location of the target to Mullaya. Mullaya acknowl-edges the location and then replies when it has found the target.


Hunt Target HHH pos where pos is the MGRS location ofthe target to hunt

Acknowledge AAA HHH pos where pos is the MGRS location ofthe target to hunt

Found Target VVV

2.2.5 Meredith MMI (Singapore Control Modem → Meredith)

Time was reserved for the Meredith vehicle to communicate back to the SingaporeanMission Management Interface (MMI).

The Meredith vehicle can send a simple status message to provide an update of thevehicle’s current status.

2The Singaporean team, on occasion, also identified this as the Deploy Command meaning “I have beendeployed and am ready to commence my mission”.

4 UNCLASSIFIED



Meredith Status LLL state where state is short code indicatingthe vehicle status.

In the case of a situation where the Meredith vehicle must abort the mission, anemergency message is sent to the vehicle to tell it to abort. The vehicle will acknowledgethe receipt of the message and immediately surface and shutdown.


Stop/Abort SSS

Acknowledge AAA SSS

2.2.6 Time Division Multiplexing Scheme

While operating within one particular frequency band, an acoustic modem can either sendor receive. When the modem is sending then it cannot receive and vice-versa. Thus ifthere are multiple, frequency matched send/receive acoustic modems using the same trialarea, they will need to coordinate their send/receive times so that they are not sending atthe same time. For this trial, a Time Division Multiplexing Scheme was chosen, utilisinga thirty second cycle, where different acoustic modems were assigned different times toperform their acoustic sends, as detailed in the Table 1. When a modem was not in sendmode it was able to receive messages.

Table 1: Multiplexing windows for the different systems.

Time (Window) User

1-4 Meredith’s position/message

7-8 Emergency Message from MMI

11-14 Mullaya’s position/message

17-21 Navigation Buoy1

24-28 Navigation Buoy2

Each system would have its local clock synchronised to GPS time at the beginning ofthe trial. Gaps were allowed between the send times to allow for messages to completebefore the new sender began its turn.

There was some fluidity to the Mullaya and Buoy times. Rather than the buoys sendingtheir messages at predetermined times they required a prompt from the Mullaya Vehicle(that is, they operated in responder mode). Mullaya sent a message to the Buoys toprompt them to send their position message. Buoy 2 sent its position at a fixed periodafter Buoy 1. There was, in principle, a potential for this to overrun the designatedsend period (and end up in Meredith’s transmit time) but this should only happen underextreme circumstances (when Buoys are very far from the vehicle or Buoy 1 message isnever received).

The experimental design for the cooperative trial virtually ensured such overruns couldnot occur: 1) the vehicles and the buoys were confined to an area which required two-way acoustic transmission times of less than one second; 2) by design the low power of

UNCLASSIFIED 5


the acoustic transmissions set an upper operational range which could be accommodatedwithin the defined time slots.

3 Mullaya Mission Management

The Mullaya Mission Manager provided functionality to allow the mission to run througheach of its phases automatically. It also provided a User Interface that allowed Supervisorsto monitor and, if necessary, intervene in the mission.

3.1 Mission Management System Support Infrastructure

Flex and LiveCycle Data Services were chosen to provide the functionality of the MullayaMission Manager. Flex is a modern development environment (based on Actionscript 3)that runs in the Flash Player. It allows rapid construction of Graphical User Interfaces(GUIs) for use in situations such as applied here, where experimental results may deter-mine that ongoing refinement of both the underlying Mission Manager and the GUI arenecessary or desirable. Flex is computationally resource efficient and uses a Messagingsystem that allows near real-time communications between its components. Being webbased, it also allows the Flex programs to be run anywhere on the Internet. The Singa-pore Trial had the potential to be monitored (via Flex components) from Australia in realtime, assuming there was appropriate internet connectivity available to the trial site.

The Flex system requires a Webserver to provide some of this functionality and aTomcat 6 Server was chosen. It also uses a server side system called LiveCycle DataServices (LCDS) to provide the messaging system. The design of the Flex system supportsindividual programs, all performing small sets of tasks whilst communicating to each other.This allowed for a flexible design that facilitates rapid change.

3.2 Integrating the Mission Manager with the Mullaya In-frastructure

The backbone of Mullaya’s internal communications system was based on a system calledCentrale (Valentinis, Wharington & Dunn 2005). Connecting the Mission Manager toCentrale proved to be a non-trivial problem. Theoretically, the Monitor could be connectedas a Java Client (as Tomcat is a Java based system). Due to resourcing issues this optionwas not pursued, instead a simple Remote Method Invocation (RMI) Client Server wascreated to connect a simple Centrale Java client to the Tomcat Server.

3.3 Mission Manager Design Concept

The design of the Mission Manager focused on the mission being conducted as a series ofevents and states that progressed the mission from the start to the finish. Inputs from thevehicle would be received via Centrale and used as trigger states in the Mission Manager

6 UNCLASSIFIED


Figure 1: The Viewer provided a link between the Centrale Infrastructure (which con-tained the Mission Management system) and the Web-based Visualisation software.

to change states and trigger new events. Figure 1 shows the Mission Manager subscribingto the Centrale Variables via the RMI connection.

The system was designed to inform the human supervisor of the current state of themission and new information was sent to the Centrale system to update the waypoints (viathe system’s mission visualisation tool Third Eye (Knox 2012)). The Mission Managerwould process information about the vehicle’s positions and perform Waterspace Man-agement (essentially informing the supervisor of the distance between the vehicles andflashing an alert if the distance went below a set minimum).

In the Mission Manager (see Figure 2), the communications system and the navigationsystem where used as triggers to change between mission states.

There were two key states in the mission: Deploy and Reacquire.

UNCLASSIFIED 7


Figure 2: The Mission Manager Monitor Screen. As the mission proceeds, the system“steps through” the various stages of the mission. The Supervisor had the ability to man-ually progress the mission if required.

8 UNCLASSIFIED


When the mission started, the Mullaya vehicle would automatically send a Check Sta-tus message (“CCC”) to Meredith via the acoustic comms system. Meredith would replywith the acknowledgement (“AAA CCC”) if it received that message. This demonstratedsuccessful two way communication between the vehicles had been established and endedthe Deploy phase.

In an operational context this could correspond to a situation where a second UUV isbeing introduced to an operational area to undertake a specialist task (such as identifica-tion of a mine-like contact or uploading of survey data to a so-called “data truck” - see,for example (Kragelund 2004) for discussion of the latter concept). The vehicle “declares”its presence so that the mission managers of both vehicles can implement appropriatewaterspace management procedures.

The second phase, Reacquire, was initiated by the Meredith vehicle sending a Reacquiremessage with an MGRS coordinate to Mullaya (“HHH” pos). Mullaya would then respondwith an acknowledgement (“AAA HHH” pos). Once Mullaya had reached that position(the distance between the current vehicle position and the coordinate in the ReacquireMGRS was within a selectable, preset tolerance) then it would send a Target Reachedmessage (“VVV”) to Meredith.

To support waterspace management, throughout the mission, the vehicles would sendeach other their current locations when possible. For Mullaya, this was managed auto-matically by the Mission Manager by taking the current Mullaya position, as provided viaCentrale and sending it automatically to Meredith via the acoustic communications sys-tem. Meredith’s current Position was also received via Mullaya’s acoustic communicationssystem and presented to the Mullaya operator (and an update send via Centrale).

Waterspace management was performed by comparing the positions of the two vehiclesand notifying the operator of the current separation distance between the vehicles. TheMission Manager Monitor would flash if the separation was below a safety tolerance (10metres in the case of the Singapore Trial).

Messages between the vehicles were sent strictly according to the 30 second cycle. Inthe case of the Mullaya Mission Manager, this was performed automatically by queuingmessages to be sent and then sending them during the Mullaya’s transmission window.If there were no mission messages to be sent then it would send the current position ofMullaya. It also automatically sent a message to the NavSong Buoys to initiate theirbroadcast.

4 Simulation Trial Design and Implementation

The overall design of the mission management system is illustrated in Figure 3. For theSimulation Trial, an alternative design was developed that provided the functionality toconnect the Mission Management Systems over the internet (see Figure 4). This simplifieddesign allowed the Mission Manager developers to focus upon how the mission managmentsystems interacted without having to consider the entire system. This design provided thecapability to robustly test the mission management systems interacting, as it providedthe flexiblity to test the system in ways that would have been time consuming and costly

UNCLASSIFIED 9


if the rest of vehicle’s support system (Mullaya and Meredith) were also required whenconnecting the Mission Managers.

The connection of the two software teams’ systems over the internet was implementedusing a socket server. The server allowed clients to connect to it and then forward anycommunications between the clients.

Figure 3: During the full mission, the two Mission Managers communicate through theirrespective vehicle’s systems via acoustic communications.

Due to ease of use and security considerations Transmission Control Protocol (TCP)was used as the network protocol. User Datagram Protocol (UDP) is more representativeof the acoustic communications (best effort rather than reliable, no check is made to seeif all the packets were received) but it was more complicated to implement.

The socket server was set up by DSO in Singapore and DSTO wrote a client to connectto that server. The server provided a service at a specified address at a specified port.DSO provided the details of the server address and the 2200 port was chosen.

The DSTO socket client used Flex to provide the socket functionality and there wassome concern that the security implicit to Flash/Flex would become an issue. The securityimplicit in Flash Player requires that any external data have a crossdomain.xml file at theroot of the webserver. DSO was able to provide this functionality but the risk was that,with all of the proxying via the firewalls at both ends, Flash would not permit the socketconnection. Because this was an acknowledged risk, ample time was allowed to addressconnectivity issues if they arose.

10 UNCLASSIFIED


Figure 4: Simplified Design allowing the Mission Managers to communicate over theInternet.

UNCLASSIFIED 11


5 Simulation Trial Results

The first goal of the simulation trial was to establish basic functionality between the DSTOsocket client and the DSO Socket server. An initial connectivity test was scheduled for 14July 2008. It proved impossible to establish any internet connection with Singapore dueto a problem with internet connectivity. Connectivity was restored late on 15 July andthe next trial was scheduled for 21 July and the days following.

On the 21 July, internet connectivity was available but the DSTO team was unable toestablish a connection between the Socket Server and the Socket Client. It was suspectedthat this was due to the Flash security issues, but on this occasion a loss of internetconnectivity (on the 22nd) due to routing issues prevented further investigation of theproblem.

Nevertheless, it was decided that the Flash Security problems were a major risk, so theDSTO client was rewritten to use a JAVA socket client. Flex was then used to connect tothe JAVA socket client, via Remote Procedure Calls, instead of behaving as a socket clientitself. This worked around the Flash Security problems and provide exactly the samefunctionality as the original socket client. This was implemented for the next scheduledtest on 28th July.

The 28 July test demonstrated, for the first time, a successful connection betweenthe DSTO socket client and the DSO socket server. There were a number of basic datacompatibility issues which necessitated modifications being made to the DSTO Java socketclient to make the two connections compatible. There was an issue with the reading of thedata at the DSO end that meant two copies of the message were received, but this didn’taffect the overall functionality.

On the 29th of July a full test of the DSTO Mission Manager was conducted with theDSO Meredith system using the internet connection provided by the socket server. Thefull simulated mission proceeded as expected and the Protocol was tested. There were afew small problems with the Protocol at both ends but for the greater part the first test ofthe mission was a success. These issues were addressed in preparation for the next test onthe 4th of August. An example of one of the problems encountered was that both teamshad assumed they were vehicle 1 and thus both transmitted at the same time. This simpleproblem was easily sorted out at this stage but would have been very confusing if it hadremained undiscovered until the final, at-sea trial.

On the 4th and 5th of August, several runs of the full simulated mission were conductedsuccessfully. All of the functionality of the mission was performed by the actual softwarethat was planned to be used for the final mission. There was still a small issue withDSO receiving duplicate messages but this did not affect the mission. The duplicates weredetermined to be caused by a problem at the DSO end and were addressed at a later dateby DSO.

12 UNCLASSIFIED


6 Conclusion

The simulation trial was conducted between 21 July and 5 August 2008. It demonstratedthat the two heterogeneous Autonomous Underwater Vehicles’ Mission Management sys-tems were able to communicate using the custom designed High Level Protocol. The testhighlighted some issues that were easily corrected.

The two teams were able to demonstrate large parts of software functionality withoutrequiring the actual hardware (and the teams needed to support them) to be co-located.Being able to test the software separately from the vehicle’s hardware proved to be avaluable experience as it provided the flexibility needed to identify several problems thatwould have been very difficult to detect in a full system environment. It also providedan opportunity for DSTO and DSO to work together for the first technical part of theDemonstration.

The concept of using simulation based trials for both software and hardware systemsis a powerful tool for de-risking international trials. It provides a cost effective meansof ironing out many of the complications inherent in complex systems and internationalcollaborations.

The rapid development that was achieved with the Flex based system allowed for flexi-ble and productive software development. It also allowed for more thorough testing. Giventhe productivity of the Flex based system, it is recommended that the rapid developmentapproach be adopted for creating custom-built software systems rather than trying tobuild a jack-of-all trades solution. In a research environment, with evolving scope andrequirements, the rapid development approach is much more appropriate as it allows forgreat flexibility and agility. Some savings could be made in designing a framework thatwould allow reuse of components in subsequent projects.

Thus it is proposed that a “Mission” builder tool be developed to enable missions tobe rapidly prepared. Initially this would involve a number of components to be manuallyconstructed as required but would eventually result in a component based mix and matchsystem where non-programmers could quickly construct missions from these components.

References

Chitre, M., Shaabudeen, S., Freitag, L. & Stojanovic, M. (2008), Recent advances inUnderwater Acoustic Communications and Networking, in ‘Proceedings of OCEANS2008’.

Knox, B. (2012), The Wane Manual, General Document, DSTO-GD-0705.

Kragelund, S. (2004), NPS Center for Autonomous Underwater Vehicle (AUV) Research2003 Annual Report, Technical Report NPS-MAE-04-002.

Neill, R. (2012), Final report of a cooperative research program undertaken through theSingaporean/Australian Subsidiary Agreement 15: “Cooperative AUV Demonstra-tion”, General Document, DSTO-GD-0678.

UNCLASSIFIED 13


Neill, R., Knox, B., Ward, T. & Lawrence, C. (2006), The Navsong and Netsong Naviga-tion, Command and Control Communications Demonstrator Project, in ‘Pacific 2006International Maritime Conference’, pp. 416–425.

Subsidiary Arrangement Number 15, Cooperative AUV Demonstration (2005), To theAgreement between the Government of the Republic of Singapore and the Governmentof Australia for Cooperation in Defence Science and Technology.

Valentinis, F., Wharington, J. & Dunn, S. (2005), An Experimenation Framework to Sup-port UAV Design and Development, in ‘Proceedings of First Australian Air VehiclesConference/Eleventh Australian International Aerospace Congress’.

14 UNCLASSIFIED

Page classification: UNCLASSIFIED

DEFENCE SCIENCE AND TECHNOLOGY ORGANISATIONDOCUMENT CONTROL DATA

1. CAVEAT/PRIVACY MARKING

2. TITLE

Simulation Trial Results for the CooperativeAutonomous Underwater Vehicle Demonstration(SA15)

3. SECURITY CLASSIFICATION

Document (U)Title (U)Abstract (U)

4. AUTHOR

Anthony Travers

5. CORPORATE AUTHOR

Defence Science and Technology Organisation506 Lorimer St,Fishermans Bend, Victoria 3207, Australia

6a. DSTO NUMBER

DSTO–TN–11716b. AR NUMBER

015-95856c. TYPE OF REPORT

Technical Note7. DOCUMENT DATE

May, 2013

8. FILE NUMBER

2008/1108936/19. TASK NUMBER

07/29910. TASK SPONSOR

CDS11. No. OF PAGES

1412. No. OF REFS

0

13. URL OF ELECTRONIC VERSION

http://www.dsto.defence.gov.au/

publications/scientific.php

14. RELEASE AUTHORITY

Chief, Maritime Platforms Division

15. SECONDARY RELEASE STATEMENT OF THIS DOCUMENT

Approved for Public Release

OVERSEAS ENQUIRIES OUTSIDE STATED LIMITATIONS SHOULD BE REFERRED THROUGH DOCUMENT EXCHANGE, PO BOX 1500,EDINBURGH, SOUTH AUSTRALIA 5111

16. DELIBERATE ANNOUNCEMENT

No Limitations

17. CITATION IN OTHER DOCUMENTS

No Limitations

18. DSTO RESEARCH LIBRARY THESAURUS

Unmanned Underwater Vehicle, Simulation, Trials

19. ABSTRACT

A simulation trial was conducted to test the connectivity between the two heterogeneous software sys-tems that were part of a cooperative Autonomous Underwater Vehicle Demonstration being undertakenby the Australian and Singaporean defence science agencies. Since the final, demonstration trial wasto be undertaken in Singapore, with no possibility of undertaking repeat trials, a risk managementstrategy was developed. This included, where possible, using the internet to simulate connectivityand communciation between the two nations’ vehicles. The trial, which involved connecting the mis-sion management systems of the two vehicles, and testing the High Level Protocol’s functionality forthe prescribed Mission, culminated in a successful demonstration of all relevant systems functioningtogether.

Page classification: UNCLASSIFIED

Documents

Simulation Trial Results for the Cooperative Autonomous ... · Simulation Trial Results for the Cooperative Autonomous Underwater Vehicle Demonstration (SA15) Anthony Travers Maritime