Full text of "INCREASING FLEET DATA TRANSFER CAPABILITIES USING AN UNMANNED AERIAL VEHICLE (UAV)"

See other formats

“Calhoun

Institutional Archive of the Naval Postgraduate School

Calhoun: The NPS Institutional Archive
DSpace Repository

Theses and Dissertations 1. Thesis and Dissertation Collection, all items

2020-12

INCREASING FLEET DATA TRANSFER
CAPABILITIES USING AN UNMANNED AERIAL
VEHICLE (UAV)

Abboud, Antoin J.; Granada, Katrina M.; Kemeny, Alex R.;
Laboy, Edwin R.; Sanders, Wesley C.; Shadle, Jacob S.

Monterey, CA; Naval Postgraduate School
http://hdl.handle.net/10945/66567

This publication is a work of the U.S. Government as defined in Title 17, United
States Code, Section 101. Copyright protection is not available for this work in the
United States.

Downloaded from NPS Archive: Calhoun

Calhoun is the Naval Postgraduate School's public access digital repository for

; \§ D U DL EY research materials and institutional publications created by the NPS community.
«iis : } Calhoun is named for Professor of Mathematics Guy K. Calhoun, NPS's first

NM KNOX appointed — and published —- scholarly author,

LIBRARY Dudley Knox Library / Naval Postgraduate School
411 Dyer Road / 1 University Circle

hiipe/fnwmcnpciedh Mibrary Monterey, California USA 93943

NAVAL
POSTGRADUATE
SCHOOL

MONTEREY, CALIFORNIA

SYSTEMS ENGINEERING
CAPSTONE REPORT

INCREASING FLEET DATA TRANSFER CAPABILITIES
USING AN UNMANNED AERIAL VEHICLE (UAV)

Antoin J. Abboud, Katrina M. Granada, Alex R. Kemeny,
Edwin R. Laboy, Wesley C. Sanders, and Jacob S. Shadle

December 2020

Advisor: Brigitte T. Kwinn

Approved for public release. Distribution is unlimited.

THIS PAGE INTENTIONALLY LEFT BLANK

Form Approved OMB
REPORT DOCUMENTATION PAGE No. 0704-0188

Public reporting burden for this collection of information is estimated to average | hour per response, including the time for reviewing
instruction, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of
information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions
for reducing this burden, to Washington headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson
Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project
(0704-0188) Washington, DC, 20503.

1. AGENCY USE ONLY 2. REPORT DATE 3. REPORT TYPE AND DATES COVERED
(Leave blank) December 2020 Systems Engineering Capstone Report
4. TITLE AND SUBTITLE 5. FUNDING NUMBERS

INCREASING FLEET DATA TRANSFER CAPABILITIES USING AN
UNMANNED AERIAL VEHICLE (UAV)

6. AUTHOR(S) Antoin J. Abboud, Katrina M. Granada, Alex R. Kemeny, Edwin

R. Laboy, Wesley C. Sanders, and Jacob S. Shadle

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING

Naval Postgraduate School ORGANIZATION REPORT
Monterey, CA 93943-5000 NUMBER

9. SPONSORING / MONITORING AGENCY NAME(S) AND 10. SPONSORING /
ADDRESS(ES) MONITORING AGENCY
N/A REPORT NUMBER

11. SUPPLEMENTARY NOTES The views expressed in this thesis are those of the author and do not reflect the
official policy or position of the Department of Defense or the U.S. Government.

12a. DISTRIBUTION / AVAILABILITY STATEMENT 12b. DISTRIBUTION CODE
Approved for public release. Distribution is unlimited. A
13. ABSTRACT (maximum 200 words)

Naval Surface Warfare Center Port Hueneme Division identified the need for an improved ship-to-shore
data transfer capability in order to meet future data demands. The demand for a better ship-to-shore data
transfer system has been a growing concern in recent years, primarily due to the increasing complexity of
combat system elements. These data needs, coupled with advancements in communication technology, will
aid in providing an effective and efficient data-transfer system beyond the current limitations of bandwidth.
One approach to enhance data transfer capability and supplement existing methods of ship data transfer is
the use of unmanned systems as either a primary or secondary means of communication. This capstone
delivers a concept of operations, system architecture, and modeling and simulation analysis for a conceptual
system intended to meet the United States Navy’s need of increasing ship-to-shore data transfer capability.
The results shown in the conceptual application of this approach yield a significant operational time
reduction when compared to the current method of data transfer. Supported by simulation and data analysis,
this reduction in operational time achieves positive results for both the feasibility of using an unmanned
aerial vehicle and increasing the capability for ship-to-shore data transfer onboard Navy vessels.

14. SUBJECT TERMS 15. NUMBER OF
data transfer, bandwidth, communications, unmanned aerial vehicle, ships, ship to shore PAGES
107

16. PRICE CODE

17. SECURITY 18. SECURITY 19. SECURITY 20. LIMITATION OF
CLASSIFICATION OF CLASSIFICATION OF THIS | CLASSIFICATION OF | ABSTRACT
REPORT PAGE ABSTRACT

Unclassified Unclassified Unclassified UU

NSN 7540-01 -280-5500 Standard Form 298 (Rev. 2-89)
Prescribed by ANSI Std. 239-18

THIS PAGE INTENTIONALLY LEFT BLANK

Approved for public release. Distribution is unlimited.

INCREASING FLEET DATA TRANSFER CAPABILITIES
USING AN UNMANNED AERIAL VEHICLE (UAV)

Antoin J. Abboud, Katrina M. Granada, Alex R. Kemeny,
Edwin R. Laboy, Wesley C. Sanders, and Jacob S. Shadle

Submitted in partial fulfillment of the
requirements for the degree of

MASTER OF SCIENCE IN SYSTEMS ENGINEERING
from the

NAVAL POSTGRADUATE SCHOOL
December 2020

Lead Editor: Katrina M. Granada

Reviewed by:
Brigitte T. Kwinn

Accepted by:
Ronald E. Giachetti
Chair, Department of Systems Engineering

ili

THIS PAGE INTENTIONALLY LEFT BLANK

ABSTRACT

Naval Surface Warfare Center Port Hueneme Division identified the need for an
improved ship-to-shore data transfer capability in order to meet future data demands. The
demand for a better ship-to-shore data transfer system has been a growing concern in
recent years, primarily due to the increasing complexity of combat system elements.
These data needs, coupled with advancements in communication technology, will aid in
providing an effective and efficient data-transfer system beyond the current limitations of
bandwidth. One approach to enhance data transfer capability and supplement existing
methods of ship data transfer is the use of unmanned systems as either a primary or
secondary means of communication. This capstone delivers a concept of operations,
system architecture, and modeling and simulation analysis for a conceptual system
intended to meet the United States Navy’s need of increasing ship-to-shore data transfer
capability. The results shown in the conceptual application of this approach yield a
significant operational time reduction when compared to the current method of data
transfer. Supported by simulation and data analysis, this reduction in operational time
achieves positive results for both the feasibility of using an unmanned aerial vehicle and

increasing the capability for ship-to-shore data transfer onboard Navy vessels.

THIS PAGE INTENTIONALLY LEFT BLANK

TABLE OF CONTENTS

I. EN PRODUCTION spssssssiscavenssvsetvasseasvccustsvees sessuyccesesoseude soueaceseeasvossnevenensynsteveekeavecests 1
A. PROJECT OV ER VIEW ‘assscvisscsncescccspccwstnsscestespneesasnnseeaseancobecasecaieespecenbes 1
B. BA CKG ROUND sis cecesiicsssepeessesansaviepsvonsceseaccsabannienasdvacavavernesiauseatenciberessoatees 1
C. PROBLEME OVER VTE W sississnscssceseacitecestueiconccconssenieus ovgaasavsentnescotsnesiasehes 2
D. PROJECT OBJECTIVES, scccesssovssssseevciescavsosassvnesenavevasovstovecsscavscaasvenvoevnes 3
E. TEAM STRUCTURE ics. ccscceecpudessescrescvensssnaegeceoscventedcavedoenscvoateinavgecsovedeuseds 4
F. STA KBRHOEDERS, psscccacsassacesnsssnessunedueutieseccaneasiacthacsensaganducasoeeeeteansucsetecss 5
G. SUIMIIVEA BY i205 s6ssccescusneidascacconvessececuseneccausuneeueacencsonaesancesanorteanovanevesvosceuseses 6
II. FECHNICAL APPROACH yo iccsccnicseccesescesstescsoarschuveoenssedensudeceesoenscvousesscceesesadendte 7
A. SCOPE wicacaisseicesvatcacuaceves sues vnscounsuweiosvaessasans ivassewavunsbeastssibsursbanGuicenessunesseassie 7
B. PRO CHS -csccchistsc ch nceticcasincocuisatcpecacaneaeceateeseciganenciae dia vaceanccccconnsaveesanienecastens 9
Cc. ASSUMPTIONS AND CONSTRAINTS ,........ccsccssscsssssssscsesscssscssssssecees 12
1. AUSSUIMPIOIOINS cid cass cvessiicecdecncadscduianccdaduca sutsedesavdncecasevacussisbaloateneceeeues 12
Zz, CONS CRAIG S55 escatectatiesecssoxceaiaceaneeeecas iene entree 12
D. SSUTIVEIVEALRY <i; 55 cciseescesecisascecasecassysysasenesscauenesvagsones vaueesnsenas car iesnovanevensrscaaeans 13
TEE. — LITERATURE: REV DEW 5 ccsiccccticedionssccacessctsccocvedsocencensevenassnavosetdssccavecsceesoendavones 15
A. DESIGN CONSIDERA TIONG. .....csccssssssssssssssesscssessssscssecsonscssesssscssnaccons 15
B. PERFORMANCE PARAMETER ...........ccsscsssssssscssccsscssssssecssecsseescoes 17
Cc. UAV CHARACTERISTICS AND SPECIFICATIONS ............scceseeees 19
D. ATUTERNA TEV ES sess scsvsskvevsncuevedexcesenvseusvsenavutvansvonsvevecessatvacostanssseuieuness 20
i, Alternative 1: Existing Satellite Technologies................csssseeee 21
Ds Alternative 2: UAV as a Relay...........ssccssssscsssscsscsccsssscssssssessessess 22
3. Alternative 3: UAV Wireless Receive and Transmit................ 22
4. Alternative 4: UAV Wireless Receive and Land.............sssseee 22
5. Alternative 5: UAV Wireless Receive and Transmit +
Ds ain Gh eesavecnsataseciscatessicaataninecaceseciaasndaausadvessaieiaeseecaauetasatenssaaeabasticselss 23
E. SUUIVEIVEA RY i585 scscccesdeseeisascaceuases seca savdnecsxusuavcucasencsosawesucssancercusnavancueavusceeuses 23
TV. SYSTEM CONCEPTUALIZATION......ccccccsssssssssssssssssssssssssosscosssssscssseccosscssess 25
A. OPERATIONAL CONCEPT DEFINITION ............sccssscssscsscessseseeccoes 25
1. GTM GENS oosc co 55 asec cceesscauieovns cancacccancesectcandec tons cavaceascacctesedavancavussousees 26
Zz; Operations and Support Descriptions...............cccscccsssscssssscesees 26
3. Operational ASSUMPTIONS............cccscccssscscssscccssccsesccsssesssseescesees 28
B. SYS TE VE TERRA Y CEE pei cscesssesaceesxsdeoeasesoucantassaceenceeacenanseneebaaetenacaaceees 29
1. Materiel Solutions Analysis (MSA) Phase ............csscccsssscesssscees 29

Vii

VI.

2. Technology Maturation and Risk Reduction (TMRR)
Be Engineering and Manufacturing Development (EMD)

4. Production and Deployment (PD) Phase ..............ccscccsssscessseeees
5. Operations and Support (O&S) Phase..............scssssccsssrcssssscesees
NEEDS ANALYSIS os sscssdesscsutayas snsdssedscetacecusdeussousaladssansdenndseslbnocccantataasneve
REQUIREMENTS ANALYSIS ........csssscssscssesssosssscsesssecsscssesssossesscenconses
Customer Expectations............cscccsssssssssssssssssssssscsssssesssssessssscssees
External CONS AUIS. o.cssccssesssersstcussvccsesecvecisdousossssscdavesssvvansobesvecse
Operational Scemar ios .........c.ccscssssssssssssssssssssssscssssscsssssesesaseseees
Utilization Environment .............ccsccccsssccssssccsssccssesscssssscssseseees
System: BOUNCArICS $55 saesccvsccepsasdseonccsocensstonsevacavnconecesnacovenapsvensesevens
System Requirements .........cccccsssscssscssssscscssssscssssscssssesssssesssscrsees
FUNCTIONAL AINATS YSIS 408s ccsstuvassossesatessevesdiooevitsesstvesdasbebacessenscasonts
1. Functional Flow Block Diagram (FFBD)............cccsccssssscsssseeees
2. Functional Requirements Decomposition.............ccsccsssscssssscees
SS UIVEN TAY: ecccsiceds vedcaddascasssecssedevsaaSosutbovsddsddicess sikcbbadedsassvsvitersddeuceausssebsviec

Sa ae Se

SYSTEM ARCHITECTURE siscisseostnsscctsscssiccbsssecucsouasencetecstoresdebasdesasseuedsdasecastes

ZORA ESO

REQUIREMENTS DIAGRAM...........cccsssssssssssssssssscessessssssesscsscsseseossess
HIERARCHY DIA GRA Mi ives sisistssciecsesisdsdeisecscisessciseasedascdsctsudscievtcscetestte
PACKAGE DEAG RA Mi ciccsscredisssiscesstoseadecesecatesteiecdaceessenscdeatssaceuseuoetouts
BLOCK DEFINITION DIAGRAM (BDD).........cscscssssssssssssssssssessessees
USE CASE. DEAGRA MM secssessescasessscsuseccacocdeestesucssdscasde devsusedestoncesdb ea uieiiase
AC TEV FV Y DEAG RAM occa cistie cine ccecaccecesbecs votced olitskisuscoteaeveielncacsesetededsess
SEQUENCE DIAGRAM siivsicsssstesccivecescnscesiescssedssdavecsuaseouseanecswudacssvaveses
SUIVEIVEAR Y ccccvcccaseshtecsecsccccnsdves cdewsceucubcce datnvavacepscvehsdsuasteceupcostscunasucspicens

MODELING AND SIMULATION ..........c.ccccsssssssssssssssssssssscsssessscssesssssessessessess

MODELING METHODOLOGY ..0...0.....cessccssesccscscccsecccscscsccssscseseeseoes
if Problem Identification.................cscsscscsssscscsssecssscsscssscsssscsssseseees
2. Model Development sicciscisiccisesisaccaseialsscauiiasenciuds saxsciasbincenalesvceuiaes
3. IFO CED Y ANG AUION sas seh covncuwsdasuacbussis swesseudacshaxepasecacsosesbcceszesestuoeces
4. Experimental Design and Simulation Conditions...................+
ALTERNATIVES ASSESSMENT ...........cccscscsecescssssssscsceecessssscsssceeee
1. SS EALISENCS swiscisicacscaneasncaacnesenteneetisatsnseawedecebieasthcseucancsbosaeinsusnedseasssoelns
De Multivariant Regression Modeling................sccccssssscccsssssccsseeees
3. BACCO Nal DGS aN ocak siesca ieeseszvedcecadadecv'esscevousaiacacechvatdcbindeceavisvectiesse
ALTERNATIVES COMPARISON ..........scssssssssssscssssssssssccesscsesssssscsene

Vill

D. SUIVEMEA REY sesecssssccncesusedanestavvsldcadsiisuaccpsecuseavestusdetwedssedvoudussteousensayivtansttesvuies 66

VEE WCONCE USION ossesetstintacdhaicapahssiseastdsaiascetsinksuctendesechsdscesteavasouctesstuoceebessetesasesceeosee 67
A. SUIVEIVIARY isesssiecdcacsdecaticbivetesiadssarscateascbsacsdoassessecesieioceevdepectebwatededderietdsies 67
B. BEEING BS cess cass ieesovescccseaissve seentsies dics aceaiects ca uceussunducnssnicsecnsuneucddavesseupeecases 68
C: RECOMMENDA TIONS vissssessscsncnticcsvcses cctecenecsvecestcusudeseacvecessecsedsveceosteee 70

APPENDIX: RESEARCH NOT INCLUDED IN THE LITERATURE

BRE VUE WW ss suceeuisotes sedi ceasuviedas das pucscelausiuas dcestudeoden eves shaq uisaudis sites atansckentaandanevsvucsdeatendses 73
LISTPOP REBETRENCES ss csistasccsscssecteiecocccncosdscitieusscosidusscasancndeeaseacccbescacceoneuascioascecsusses 7S
IND ETAL. DIS DRE UTION DS 0 cies ccesixestsnutetscesstescsuccaseassucsscvaseudueussicscceeetasedecaaedavsaes 81

THIS PAGE INTENTIONALLY LEFT BLANK

Figure 1.
Figure 2.

Figure 3.

Figure 4.

Figure 5.

Figure 6.

Figure 7.

Figure 8.

Figure 9.

Figure 10.

Figure 11.

Figure 12.
Figure 13.
Figure 14.
Figure 15.
Figure 16.
Figure 17.
Figure 18.
Figure 19.

Figure 20.

LIST OF FIGURES

Wea RCO: SOUCTUE s..st4s.ctsassergssasiegccasdacratinst oastaistevetnsiuacenetectestangtomantets 4
Tailored Vee Model. Adapted from INCOSE and Wiley (2015a). 0.0.0.0... 8
Tailored Vee Model Detail. Adapted from INCOSE and Wiley

(QO ae tiaras sata ems psn aa iea cease es mien erate ntata iach sie atateat. Pena eres o
igh (Level WBS 2c.i0es cies ce eee ee eee aes 10
Architecture Development Six-Step Process. Source: Office of the

Deputy Chief Information Officer (2020)... cee eeeeeeeeeeseeeseeceteeteeeeeneees 12
AoA Framework. Adapted from The MITRE Corporation (2013b) ......... 20
Theoretical and Practical Data Rates via Commercial Technology.

Bourcer Wells (QO) egos ssuhinte se tidtosmndentisienidsasconninetecnd ts briateteceasagacas 21
DAD Opetationial View soicseci5tosasr ache sciee, Motaenictencitesd nethna tae diosedaceune pas,
DAD High Level Activity Diagram. ...............cccceseecseeeseeceesceconeeceetteeceneeees a
DOD Acquisition Management Model (DOD 5000.2). Source:

PCI OLSSON) cscs acne he at Sedatcc a vedas ses ee danse a eoa sa, Slo Sane Bales 29
Needs Analysis Phase in the System Life Cycle. Source: Kossiakoff

(QOL esses sneesccussinsetisiy aawoa bares elereusrecananinadusnpessunahanasue aes dawenseaneedeeaaensonateale 34
DAD System Level FFBD (ship-to-shore data transfer) «0.0.0... eee 39
DAD System Requirements Diagram ........... ee ee eeceseceeeeeeeceeneeceeeeseeeeneees 44
DAD System Hierarchy Diagram 00.0.0... eeeeceessececesececeeeeesseceeseeeenaeeees 45
DAD System Mission Planning Package Diagram.............. ee eeeeeeeeeereees 46
High Level DAD System BD Des. ic2.22 inc eee deen eee Gece: 46
DAD Bolt-On UAV Subsystem BDD 0.0... eeceeeseceesneeeeeteeeeneeeenaeeees 47
DAD Ground-Based Subsystem BDD......... cee eeecceeeeceeeneeeenteeeeneeeenaeeees 47
DAD Ship-Based Subsystem BDD........ cee eee esseceseceeeeeeneeceecnseeeseeeeneees 48

DAD System Use Case Diagram for Receive and Transmit
PICO ALIY Cs f5 ice Si acs nds dass evcus pada omasuass ogooessesessdao cus sae ddasdecevasetnsyttmects 49

Figure 21.
Figure 22.
Figure 23.
Figure 24.
Figure 25.

Figure 26.

Data Upload to UAV (Receive and Transmit Alternative)... ee 51
ADD SEGUE Ce reign oy c2 co osascesysan aus ecadoessctdepaeesoecestassaes veseeccostteeses je
Satellite Baseliné Model 3.42122: dcesinsdicitee nein eels dls 56
UAY Relay Model wwissscasivsiaszevitesvearnavsnadeasaecedea sbasnaee gussctessnczeseadavsdeedwaractens 57
UAV Wireless Receive and Transmit Model ........0..ecceeeeeeeesseeeeeeeeeeeeneees 58
UAV Wireless Receive and Land Model... ee eeeeeeeceeseeesneceseeeeeeeeneees 59

xii

Table 1.

Table 2.

Table 3.

Table 4.

Table 5.

Table 6.

Table 7.

Table 8.

Table 9.

Table 10.

Table 11.

Table 12.

Table 13.

Table 14.

Table 15.

Table 16.

LIST OF TABLES

Capstone Delt Vera e ss sac cc ie cccsida tvs scone ctehat asctseraelestua cians cctvetes tonaaeeedss 4
Team Roles and Responsibilities 0.0.0.0... eeecesceecsececseececseececeeeeeeseeeenseeeenes 5
Capstone Stakeholders 2:03 :ccisce accede os ockieteen a dceiece teeed el ieslaptee ee dewidage 6
TOGIS Used sccstieveseltcopes taper sie erence eine Nee eed 11
UAV Characteristics and Performance Specifications ............ceseeeeteeees 19
2-Sample t-Test Results for Satellite and UAV Models’ Testability ........ 60
Descriptive Statistics for Satellite and UAV Models’ Output Times

PODS GB rai id cits sapceaeiiuiedetevepecseniotancmapcastiadeauupeeival ascites aiawepclilauotantees 60
Multivariable Linear Regression Statistics for Satellite Model................. 61
Multivariable Linear Regression Statistics for UAV Models................ 61
Level. Valuies for Input Factors 'u.csssscceessccsavescaesueseads (eeesasaosengance cedesvadnesondease 62
Factorial Design for Satellite and UAV Models’ Output «0.00... 63
CC OmparisOtin LI SUtS cis25 sesc03 coc eaudidirsecseedseaats ts tagcalaaanaseetasendasaneqnands Bee 64
Alternative Data Transfer Methods .......... cee eeseesseceseceseeeeseeceaeeneessneeeneees 65
Percentage Improvement (Time) UAV Relay vs. Satellite Relay ............. 68

Percentage Improvement (Time) UAV Receive and Land vs.
PALE HIG RELA cialis es Giese oS, carne cia Au cegyssuteele. es aed aces wadvanadeauasecnecas 69

Percentage Improvement (Time) UAV Receive and Transmit vs.
ALC LITER CLAY ook wna ccnt ctr sascs ataticg peasy aiteaegh Gadsden sens acmcencadumudete s tees eanceasoeaniae 69

Xlil

THIS PAGE INTENTIONALLY LEFT BLANK

XIV

LIST OF ACRONYMS AND ABBREVIATIONS

AoA analysis of alternatives

ASK amplitude shift keying

AUV autonomous underwater vehicle
BDD block definition diagram

CONOPS concept of operations

COTS commercial-off-the-shelf

CPU central processing unit

CS combat system

CSSQT combat system ships qualification trials
CyE cyber engineering

DAD Deployable Aerial Datalink

DOD Department of Defense

DOE design of experiments

DT developmental training

EMD engineering and manufacturing development
EMI electromagnetic interference

EVM earned value management

FCE forward connection error

FFBD functional flow block diagram
FRPDR full-rate production decision review
FSK frequency shift keying

FSO free-space optical

GB Gigabyte

Gbps gigabits per second

GCS ground control station

GOTS government off the shelf

GUI graphical user interface

HPA high power amplifier

IAW
IBD
TEEE
INCOSE
IOT&E
ISEA
Kbps
KPP

KU
KVM
LAN
LOS
LRIP
LTE
Mbps
MBSE
MIMO
MOE
MOP
MSA
MSSE
NAVSEA
NCC
NISE
NPS
NRC
NSWC PHD
O&S
OAM
PD

in accordance with

internal block diagram

Institute of Electrical and Electronics Engineers
International Council on Systems Engineering
initial operational testing and evaluation
In-Service Engineering Agent

kilobits per second

key performance parameter

Kurtz-unter

keyboard, video, mouse

local area network

line of sight

low-rate initial production

long-term evolution

megabits per second

model-based systems engineering
multiple-input multiple-output

measure of effectiveness

measure of performance

materiel solutions analysis

Master’s of Science in System Engineering
Naval Sea Systems Command

network collection center

Naval Innovate Science and Engineering
Naval Postgraduate School

National Research Council

Naval Surface Warfare Center Port Hueneme Division
operations and support

orbital-angular momentum

production and deployment

XVi

PMS
PSK
QAM
RF
RMDA
RMF
RN
RoCE
RTB
SE

SF
SME
Sol
SysML
TMRR
TOC
TPM
TPO
T&E
UAV
USN
USV
VSU
Wi-Fi
WAN
WBS
XLUUV

Project/Program Manager, Ship

phase shift keying

quadrature amplitude modulation

radio frequency

remote memory direct access

risk management framework

relay nodes

remote memory direct access over converged ethernet
return to base

systems engineering

ship’s force

subject matter expert

system of interest

systems modeling language

technology maturation and risk reduction
total ownership cost

technical performance measure

Thesis Processing Office

test and evaluation

unmanned aerial vehicle

United States Navy

unmanned surface vehicle

variable speed unmanned aerial vehicle
wireless fidelity

wireless area networks

work break down structure

extra-large unmanned underwater vehicle

XVii

THIS PAGE INTENTIONALLY LEFT BLANK

XVili

EXECUTIVE SUMMARY

This capstone was developed in response to a need for an improved ship-to-shore
data transfer capability in support of United States Navy (USN) test events, identified by
the Naval Surface Warfare Center Port Hueneme Division (NSWC PHD). Specifically,
there was a demand for a faster data transmission method to augment existing ship-to-
shore communication networks to support USN test events. Test event analysis and
distance support efforts necessitate tremendous amounts of data to be transferred to and
from shore-based activities. Data transfer constraints imposed by existing
communications systems can prohibit the possibility of timely test event data analysis and
distance support efforts. Test events are typically conducted post ship delivery or after an
availability period where major system upgrades are implemented. With the current goal
of a 355-ship fleet (O’Rourke 2020) and increasing complexity of ship systems, there will
be consistent and immediate demand for an improved data transfer capability to support
test events for the foreseeable future. In response, the capstone team captured relevant
information to develop the capstone problem statement:

The demand for a better ship-to-shore (bidirectional) data transfer system

has been of paramount concern in recent years, primarily due to the

increasing data needs of combat system elements. These data needs

coupled with advancements in communication technology will aid in

providing improved decision-making support and operational capabilities
beyond the current shipboard system limitations.

The capstone team identified a technological opportunity to fill this capability gap
by leveraging capabilities of existing unmanned aerial vehicle (UAV) platforms to
facilitate a supplementary line of communication capable of fulfilling stakeholder
requirements. Additionally, this system would have to operate in environmental
conditions associated with USN test events, interface with operators at the ship and
ground station, establish and maintain a bidirectional data connection as required between
the ship and ground station, and have the capability to interface and write data to
approved removable media. A conceptual system design was created, named Deployable

Aerial Datalink (DAD), with the intent to show that utilizing a UAV platform can

X1X

achieve stakeholder objectives. This system was intended to provide increased
availability of data from ship-to-shore. The DAD system operational concept consists of
using removeable media provided by ship’s force to upload to an external system, which
will then communicate with a bolt-on subsystem deployed on a UAV for data upload or
relay. In Figure 1, a USN ship equipped with a DAD modular computer subsystem is
utilizing the DAD system line of communication to receive or transmit data from the
DAD modular computer subsystem via the UAV equipped with a DAD bolt-on

subsystem.

1.3 UAY with: Bolt-On System

Los Angolea® ;

i
et |

11 US NAVY SHIP with Modular Computer Sub-Syvtem

Figure 1 - DAD Operational View

The capstone team used a tailored Systems Engineering Vee model during system
conceptualization, adapted from International Council on Systems Engineering
(INCOSE) and Wiley (2015). The study produced a concept of operations, technical
approach, set of feasible candidate solutions, system architecture, system model and
simulation, and feasibility results. The derived conceptual system was an aggregate of
analysis of existing communication methods and related systems paired with the

operational objectives. An analysis of alternatives (AoA) was conducted and four

potential solutions were identified for analysis; (1) keep using the existing satellite
technology, (2) using a UAV as a relay, (3) using a UAV for receipt and transmission,

and (4) using a UAV for data upload and hard drive removal.

From the derived system requirements, a physical architecture was developed by
applying partitioning criteria to translate requirements into system functions. System and
subsystem functions were then further decomposed, and feasibility criteria was applied to
develop a physical system architecture. Functions, interfaces, and system composition
were further defined and captured in the system architecture for which the capstone team
used the model-based systems engineering (MBSE) tool Innoslate to create the
conceptual system. Figure 2 provides a high-level DAD system block definition diagram

(BDD).

< beet =e a aA =
©.1.1 Bolt-On Sup System C.1.2 Grourd-Based Modular Computer Sub-Systen C.1.3 Stip-Based Modular Computer Sub-System

Figure 2 - DAD System BDD

With system requirements and system architectures defined, a modeling
methodology was determined in order to derive expected system performance. The
modeling and simulation tool ExtendSim was used to analyze relationships between
operational time and data rates using specific scenario conditions. Analyses supported the
use of UAVs as a data transfer platform and revealed preferable system configurations
and system employment methods. Preliminary findings showed promise that the
conceptual systems utilizing UAVs have potential to deliver an increased data transfer

capacity over existing communications systems at a lower operational cost to the USN.

XXi

References

INCOSE and Wiley. 2015a. INCOSE Systems Engineering Handbook: A Guide for
System Life Cycle Processes and Activities. New York: John Wiley & Sons.
http://ebookcentral.proquest.com/lib/ebook-nps/detail.action?docID=4040424.

O’Rourke, Ronald. 2020. Navy Force Structure and Shipbuilding Plans: Background and
Issues for Congress. Washington, D.C.: Congressional Research Service.
https://www.dau.edu/cop/test/DAU%20S ponsored%20Documents/
PM%20Cybersecurity %20Guidebook%20v 1 %200%20with%20publication%20n
otice.pdf.

XXil

ACKNOWLEDGMENTS

The capstone team would like to recognize their advisor, Department of Systems
Engineering lecturer Brigitte Kwinn, for her immeasurable guidance and support
throughout the capstone process. The capstone team would also like to thank Dr. Rama
Gheris, Department of Systems engineering professor, for her assistance in the
development and validation of the ExtendSim model and simulation. Although courses
were conducted online, special thanks are extended to the Department of Systems
Engineering professors and distance learning team for their continuous support during

the COVID-19 pandemic.

Additionally, the capstone team would like to acknowledge the several subject-
matter experts and stakeholders for their time and expertise. The capstone team would
like to extend their gratitude to their colleagues and supervisors from Naval Surface
Warfare Center Port Hueneme Division (NSWC PHD) and Project/Program Manager,
Ship (PMS) 500, for their flexibility and continuous support throughout the two-year

program.

Lastly, and most importantly, the team would like to thank their families for their

continuous support, understanding, and encouragement throughout the capstone process.

XXill

THIS PAGE INTENTIONALLY LEFT BLANK

XXIV

I. INTRODUCTION

A. PROJECT OVERVIEW

This capstone report is a result of a collaboration effort formed between Naval
Postgraduate School (NPS), Naval Surface Warfare Center Port Hueneme Division
(NSWC PHD), and Project/Program Manager, Ship (PMS) 500, to address the issue of
existing fleet data transfer limitations. The issue addressed in this report was presented to

the NPS Systems Engineering (SE) 311—192S cohort capstone team by NSWC PHD.

NSWC PHD provides the United States Navy (USN) surface fleet with
integration, test and evaluation (T&E), life-cycle engineering, and product support for
today’s and tomorrow’s warfare systems. NSWC PHD participates in numerous
certifying events such as combat system ships qualification trials (CSSQT) and various
other developmental and operational test events (Commander Naval Sea Systems
Command 2020a). As one of the sponsors of NSWC PHD, PMS 500 “manages the
design and construction of destroyers, amphibious ships, special mission and support
ships, as well as a wide range of boats and craft for United States (U.S.) agencies and

foreign military sales” (Commander Naval Sea Systems Command 2020b).

The capstone team employed a combination of various engineering disciplines
(aerospace, computer, mechanical, industrial, and marine engineering), experience
supporting the Department of Defense (DOD), research, and subject matter expert (SME)
input to develop a potential solution to address an existing data transfer capability gap to
support USN test events. The principal goals of this capstone were to investigate the
feasibility of utilizing unmanned aerial vehicles (UAVs) to improve ship-to-shore data

transferring capabilities and develop a conceptual deployable datalink system.

B. BACKGROUND

As described in ‘A Design for Maintaining Maritime Superiority’ version 2.0 and
the DOD modernization strategy, the global threat landscape is continually changing and
the U.S. no longer has the competitive advantage in all areas, making it crucial to

modernize our digital world to maintain competitiveness. To ensure advantage in all
1

areas (Department of Defense 2019), the focus must include the role of data in decision
making (United States Chief of Naval Operations 2018). USN involvement in
maintaining a competitive advantage is instrumental and as a maritime nation, the USN
must increase naval power and warfighting capability through “improved readiness and
reliability of systems to ensure combat mission capable ships” (Naval Sea Systems
Command 2019). Availability of data is at the center of ensuring ships’ combat readiness
and meeting the DOD modernization strategy, as it enables “identification needed for
subsequent actions, lessons learned, design of improved tactics and systems” (Duren and
Pollard 1991), along with “improved decision making support and enhanced operational

capabilities” (Office of the Chief Information Officer 2000).

As the In-Service Engineering Agent (ISEA) for multiple USN surface ship
combat system elements, NSWC PHD provides distance and on-site support, training,
troubleshooting, maintenance, and other logistics and engineering functions. Increased
availability of data will enable NSWC PHD to more effectively perform ISEA functions
by bypassing typical delays in receiving data and ultimately will contribute to combat
system readiness. Typical delays include data shipment and waiting for ships to return

from deployment.

C. PROBLEM OVERVIEW

USN T&E events generate immense quantities of data, due to the increasing
complexity of modern Naval combat systems. Post-event analysis and distance support
efforts require combat system data to be transferred from ship to ground-based activities.
Bandwidth limitations imposed by existing methods of data transfer can affect the
timeliness of associated analysis required for test event certification or distance support.
These issues are central to the vision statement provided by the capstone vision owners:

Transferring data from ship-to-shore has been and continues to be a

challenge for the USN. Unless we come up with a dynamic solution, soon,

we will carry this problem onto new developments/platforms. The idea

behind this project is to develop a system capable of transferring classified

and unclassified data from an UAV to a shore-based site. Although

intended for UAVs, the system should also be compatible with other
platforms with minimum to no impact to the platform’s infrastructure.

In line with NSWC PHD’s role with providing T&E and direct fleet support to
surface ships, the intent of this project is to conceptually design a data transfer platform
for UAV deployment to enable faster availability of data for analysis (Commander Naval
Sea Systems Command 2020a). The concepts fundamental to design of the data transfer
platform included being standalone and external to ships’ infrastructure. This design
concept addressed one of the challenges identified by the National Research Council
(NRC). According to the NRC, the U.S. continues to struggle to meet the changing needs
of ship communications due to constraints regarding available space for communication
suites and upgrading infrastructure to rapidly expanding needs (National Research
Council 2000). Another important aspect of the conceptual system is the intent to provide
a method of ship-to-shore data transfer additional to existing ships’ communication
capabilities. As stated in the 2020 USN Information Superiority Vision, a major
challenge the USN faces with the transfer of data from ship-to-shore is bandwidth
limitations. The path for the data to transit is too constrained to achieve data transfer in
time requirements(Office of the Chief Information Officer 2020). One approach to
enhance data transmission capability is to supplement existing methods of ship-to-shore

data transfer through use of UAVs as communication nodes.

The capstone team developed a system concept named Deployable Aerial
Datalink (DAD) to address the deficiencies identified by the capstone vision owners.
Accounting for resources and schedule, the capstone team limited the project scope to

preliminary design of the DAD system concept.

D. PROJECT OBJECTIVES

The primary objective of this capstone was to investigate the feasibility of
utilizing a UAV as a communication node for ship-to-shore data transfer. A secondary
objective for this capstone was increasing data availability to ultimately contribute to
combat system readiness. A tertiary objective was to provide NSWC PHD and other
DOD activities with a feasible option to supplement existing data transfer methods. The
last objective of this capstone was to provide NPS and NSWC PHD with the deliverables
identified in Table 1.

Table 1. | Capstone Deliverables

Analysis of A comparison and evaluation of alternative solutions

Alternatives that meet desired stakeholder capabilities.

Architecture A graphical representation that defines the structure of
the system.

Concept of A description of integrated system characteristics and

Operations objectives from the stakeholder perspective.

Literature Review

A review of available scholarly resources related to the
system concept.

Requirements

Definitions of various system functional and non-
functional needs.

E. TEAM STRUCTURE

Team Rico organization was structured as shown in Figure 1. Each team member

was designated responsible for at least one section, and each team member was expected

to contribute to remaining sections. High level descriptions of roles and responsibilities

for each project area are described in Table 2.

Team Lead

Antoin Abboud
Katrina Granada (co-lead)

Requirements
Engineering

Wesley Sanders
Alex Kemeny

Architecture
Design

Jacob Shadle
Antoin Abboud

Analysis of
Alternatives

Edwin Laboy
Wesley Sanders

Technical
Editor

Katrina Granada
Alex Kemeny (co-editor)

Figure 1.

Team Rico Structure

Table 2. Team Roles and Responsibilities

Project Led the development of the capstone project and was the focal
Lead point for communication with project sponsors; was
responsible for setting expectations and direction for the team
during the project, developed a project plan, managing
deliverables, assign tasks to team, and provided updates on a
regular basis to advisors; was responsible for keeping team
members and stakeholders informed of key developments and
any changes in the project plan; was responsible for
mitigating any risk involved as the project progresses
Engineering Included responsibility of gap analysis associated with
Analyst alternative solutions; identified risks associated with each
alternative solution
Tech Writers/ | Included responsibility of overall project documentation and
Editors ensured proper spelling, grammar, and formatting; tasked
with project report management and submission to the Thesis
Processing Office (TPO)
System Included responsibility for the design and documentation of
Architects system interface, key system components, and infrastructure;
tasked with the overall design of the system and ensuring
modeling of system meets technical and functional

requirements
Requirements | Included definition, documentation, and requirements
Engineers maintainment; modeling and simulation; analysis of

stakeholders needs and conversion to requirements into a
standard format.

F. STAKEHOLDERS

A list of stakeholders and their primary areas of interest are identified in Table 3.
The most important stakeholder identified is the Fleet, as the main goal of increasing
availability of data is to contribute to Fleet readiness through improved ISEA support.
Other stakeholders for this capstone include NSWC PHD, not only as the vision owners,
but as the command that plays a vital role in supporting combat and weapon systems
during T&E and ISEA activities; Naval Sea Systems Command (NAVSEA); and
Program Executive Offices (PEOs) (Commander Naval Sea Systems Command 2020a).

Table 3. Capstone Stakeholders

Fleet Improve combat and weapon system readiness,
increase availability of system data for
decision making

NSWC PHD Increase availability of combat and weapon
system data to improve readiness, increase
knowledge, improve ISEA support

NAVSEA Improve fleet readiness, increase ISEA
effectiveness and support, reduce total
ownership cost (TOC)

PEOs Improve fleet readiness, reduce combat

system failure trends, reduce TOC

G. SUMMARY

Maintaining maritime advantage continues to drive the USN to seek new and
improved methods of increasing naval power and warfighting capability. Increased
availability of data from ship-to-shore contributes to warfighting capability through
combat system readiness and enabling ISEAs to better effectively address life cycle
issues. The purpose of this capstone was to investigate the feasibility of increasing data

through use of UAVs as nodes between ship-to-shore data transfer.

HW. TECHNICAL APPROACH

The intent of the DAD system is to increase fleet data transfer capabilities using
UAVs. In order to realize this intent, this project used the SE methodology in line with
the concepts outlined in the International Council on Systems Engineering (INCOSE)
handbook (INCOSE and Wiley 2015a). The same INCOSE handbook provided the

following explanations of SE terminology:

SE is an interdisciplinary approach and means to enable the realization of
successful systems. It focuses on defining customer needs and required
functionality early in the development cycle, documenting requirements,
and then proceeding with design synthesis and system validation while
considering the complete problem... A life cycle can be defined as the
series of stages through which something (a system of manufactured
product) passes... Functionality of a system is typically expressed in terms
of the interactions of the system with its operating environment, especially
the users...System architecture is the fundamental concepts or properties
of a system in its environment embodied in its elements, relationships, and
in the principles of its design and evolution... The Vee model is a
sequential method used to visualize various key areas for SE focus,
particularly during the concept and development stages.

A. SCOPE

For this capstone, the Vee model aligned best with the expected deliverables as it
provided the framework for system conceptualization. The capstone team tailored the
Vee model to fit the unique requirements of conceptualizing the DAD system, as seen in
Figure 2 and Figure 3. The scope of this capstone only considered the left side of the Vee
model and included aspects of key SE processes defined by INCOSE (2020):

Establishing stakeholders’ success criteria and concerns, and defining
actual or anticipated customer needs and required functionality, early in
the development cycle, and revising them as new information is gained
and lessons are learned...Investigating the solution space, proposing
alternative solution and operational concepts...Architecting a solution or
set of solutions based on the selected concept(s)... Modeling (or otherwise
evaluating) the solution at each relevant phase of the endeavor...in order
to establish required capability and performance; increase confidence that
the solution will work as expected and required...Providing the SE
knowledge and information required by all stakeholder groups to ensure

coherence of the whole endeavor — typically including a vision statement,
operational concepts, architecture definition.

System Development, ,
Define System Full System Operation
Requirements, and Verification
CONOPS

Integration, verification, validation pper Level System

Upper Level System Realization,
Requirements and Verification of

Design, AoA system

Integration, verification, validation

Sub-System
Requirements, Realization,
Component Detailed Verification of

Figure 2. Tailored Vee Model. Adapted from INCOSE and Wiley (2015a).

ystem Development,

Define System integration, verification, validation

Requirements,
CONOPS

Upper Level System Ted itl Me elie Me ciiler ides
Requirements and

Design, AoA

System Lifecycle
Functional Analysis
System Modeling & Simulation

a ea aig a a acetal na rc a ee arr

Figure 3. Tailored Vee Model Detail. Adapted from INCOSE and Wiley
(2015a).

In conjunction with the tailored Vee model, the capstone team developed a work
breakdown structure (WBS) to further detail the SE method. Figure 4 shows the high-
level processes used to define stakeholder needs through system architecture design and
solution recommendation. Table 4 lists the tools used to perform the SE processes

outlined in Figure 4.

B. PROCESS

The first step taken to define stakeholder needs was to translate the stakeholders’
vision statement into the capstone problem definition and capstone objectives. This
process required review of existing technologies in the fields of ship-to-shore
communications, ship to UAV, UAV to shore communications, and bandwidth
limitations. The development of the concept of operations (CONOPS) for the DAD

system resulted from this process.

1.0 Define
stakeholder needs

1.1 Research
stakeholder needs

1.2 Conduct needs

2.0 Requirements
Analysis

2.1 Define system
requirements

2.2 Define functional

3.0 System
Architecture Design

3.1 Develop system
architecture with
Innoslate

3.2 Recommend a
solution for

Nnalysi f iremen F j
analysis equirements implementation

1.3 Develop 2.3 M&S using
CONOPS ExtendSim

2.4 Conduct AoA

Figure 4. High Level WBS

The next phase in system conceptualization was requirements analysis. During
this phase, the capstone team identified system and operational requirements through the
analysis of the existing technology review and decomposition of stakeholder needs.
ExtendSim software application was utilized to create a mathematical model of the DAD
system and simulated the effects of inputs on output performance (Law 2013). Another
aspect of the tailored SE process during the requirements analysis phase is the analysis of
alternatives (AoA). The AoA enabled evaluation of solutions generated to meet DAD

system requirements and identified associated potential risks (AcqNotes 2018b).

Table 4. Tools Used

Microsoft Word Word processor software used for document
creation and editing.

Microsoft Excel Spreadsheet software used for data visualization,
analysis and calculations.

Microsoft Project Project management software used to outline

milestones, deliverables, budget, schedule, and
project progress.

Microsoft Power Point Presentation software used to present project
briefings.

Microsoft SharePoint Cloud service used for file sharing and storage.

Innoslate Architecture and system modeling software tool
used to create diagrams, drawings, and schema of
the project.

ExtendSim Simulation software used for modeling and
optimization.

The process of system architecting builds upon the derived system requirements
to develop an architecture as a foundation to guide system design (The MITRE
Corporation 2013). In line with DOD architecture framework 2.0, the team utilized a
multi-step process to develop the architecture framework, as seen in Figure 5. These steps
included determining the intended use of the architecture, determining the architecture
scope, determining data required to support architecture development, collecting
architecture data, conducting analysis of architecture objectives, and presenting results in
accordance with decision-maker (or stakeholder) needs (Office of the Deputy Chief
Information Officer 2020). Innoslate modeling software was used to create the

architectural views that are later provided in this report.

Actomated repos tonet Porthall Anatyses + Architecture presentatorn and views
and tuncbore Crarecterstes + Actraty Models + Capocty Analyses +Reusetie arctrvtectus data
+ Technologie bounds + Apctdectura dela erthet + Oute Modes «Wtercperatity assessmerts = + Anatyns reports
Tune tamels) *Levets of deta! Models Brsenets Process anetyat
resource Units of mageure Cyparctabormt Modett Teut ochtectre it
wu scrmose Assormed Meats regetwation acourecy, and suftcency

Figure 5. Architecture Development Six-Step Process. Source: Office of the
Deputy Chief Information Officer (2020).

C. ASSUMPTIONS AND CONSTRAINTS

The team developed the following set of assumptions and constraints applicable

to this capstone scope:

1, Assumptions

The intent of the system is to supplement existing methods of data

transfer.

The intent of the system is to be temporarily deployed on USN surface

vessels for CSSQTs or other test events.
2 Constraints

Capstone schedule has limited the scope of system development.

System concept will include use of UAV as directed by vision owners.

Depth of system concept development is limited to keep capstone

unclassified.

The team did not have the ability to purchase, manufacture, prototype,
functionally test, or verify the system outside of conceptualization and

model-based systems engineering (MBSE) methods.

Assumptions regarding the operation of the DAD system are listed in Chapter III,

Section A.

D. SUMMARY

The scope of this capstone included SE activities found in the left side of the Vee
model, including system development, definition of system requirements, a CONOPS, an
alternatives analysis, and preliminary system architecture. The required tasks for the
capstone were broken down into three main focuses; defining stakeholder needs,
requirements analysis, and system architecture design. Assumptions and constraints

applicable to the scope of the capstone were identified.

THIS PAGE INTENTIONALLY LEFT BLANK

Hi. LITERATURE REVIEW

The purpose of this literature review was to research current knowledge and
identify knowledge gaps. It includes scholarly reports, scientific journals, technological
patents, and academic theses. The research was divided into three sections to enable
greater understanding of the different components that are covered by the scope of the
capstone project. These documents were analyzed with specific focus on how the
capstone team could apply the information to the DAD system. The first section
summarizes studies found regarding design considerations. The second section covers
performance parameters which focused on findings of effectiveness and efficiency for
different data transfer methods. The third section compiles a list of UAV characteristics

and performance specifications

A. DESIGN CONSIDERATIONS

Creed and Glenn (2000) were able to transfer data in real-time using radio
frequency (RF) links. In order to establish ship-to-shore data communication, each vessel
had its own local area network (LAN) which communicated with the shore command
center via FreeWave Spread Spectrum Data Transceiver/Ethernet bridge. During their
effort, requirements were that it must have high speed data transfer, be able to transfer
data over a 20-mile distance and be low cost. Based on their requirements, FreeWave
Technologies Spectrum Wireless Data Transceivers provided capabilities required (Creed

and Glenn 2000).

Jawhar, Muhamed, Trabelsi and Al-Jaroodi (2016) explored the significance of
UAV’s in wireless signal networks (WSN) for data collection as a median between relay
nodes (RN) and distribution sinks/Network Collection Centers (NCC). Using a series of
UAV algorithms, they developed models that compared the data collection strategies
across multiple testing parameters, including UAV flight routes (constant speed, variable
speed, adaptable speed) and different data links (RN to UAV, UAV to sink). Such
parameters are important to consider for relaying data from an AEGIS platform ship via

UAV to a land-based site. With a Variable Speed UAV (VSU), the algorithms considered

both when the UAV was in communication with the RN, and when no communication
was taking place. Once the data connection was made between the RN nodes and the
UAV, Jawar explained that medium range protocols- such as IEEE.802.11- have a data
rate ranging from between | megabyte per second (Mbps) and 70 Mbps, depending on
the height of the UAV’s flight. Jawar concluded from the various models that the data
transfer rate was dependent on the buffer size of the RN - as the buffer size increased the
UAV could deliver more packets to sinks, but the average delay of receiving the data also

increased (Jawhar et al. 2016).

Frink (2005) introduced a patent for a data retrieval system which uses a UAV to
retrieve collected data from at least one surface data collection instrument. Frink’s
invention can be placed in a ship and other types of marine vehicles. He stated that
satellite data retrieval was limited by at least three constraints: uplink time allocations
must be monitored and adjusted frequently, limited time slots available, and required
significant amount of power from ground station to communicate effectively. One of the
features for this invention was eliminating the need for personnel to retrieve data on-site
by launching a UAV to the ground-based data collection instrument which had a

transceiver attached to it (Frink 2005).

Wells (2010) discusses the major components associated with a high data rate
architecture. These components include a power supply, data interface, modulator,
demodulator, transmitter, receiver, combiner, and an antenna. According to Wells, the
most important aspect of a power supply is that it has to have a high reliability as well as
avoid power loss. The power supply must also “be designed to tolerate poor quality input
power with high levels of noise and/or transient spikes and avoid feeding back noise or
interference.” Techniques to increase “robustness of the data stream” were listed and
include forward correction error (FCE), interleaving, and encryption. Four classes of
modulation are examined; amplitude shift keying (ASK), frequency shift keying (FSK),
phase shift keying (PSK), and quadrature amplitude modulation (QAM). An issue often
faced with demodulation is discussed, multipath fading, as well as a common solution,
adaptive equalization. The importance of a power detector is to control high power
amplifier (HPA) output and output power. A concern for unregulated power output is the

possibility of violating licensing rules and interfering with other nearby wireless services.
A critical aspect of a receiver is to control the gain of the amplifier, otherwise the signal
is at risk for being distorted or the demodulator could be overloaded. Wells introduced a
combiner as a method for efficient use of hardware, through utilization of one antenna to
perform the actions of a transmitter and receiver. Antenna types are compared for
different uses; including highly directional reflector and aperture for long-distance
communications, and parabolic and flat panel for high capacity systems. Wells also
discusses methods for achieving gigabit per second data rates. These methods include
single channel transmission, adjacent channel transmission, dual-polarization
transmission, dual channel dual polarization, data compression, and multiple-input

multiple-output (MIMO) transmission (Wells 2010).

B. PERFORMANCE PARAMETERS

Yang (2018) proposed more effective data transfer means from a ship to coastal
area by designing three different data structures. These data structures included one for
RF and long-term evolution (LTE) based networks, one for satellite-based networks
(conventional method), and the last for emergency alerts. In this study, Yang states that
“satellite-based networks cover the entire ocean, but the costs are very expensive” (Yang

2018).

Johansen et al. (2014), developed experiments testing a UAV as a wireless relay
between an autonomous underwater vehicle (AUV) and a local ground control station
(GCS). Using geometric calculations to determine optimal data upload based on antenna
location, along with constructing an IEE802.11 Wireless fidelity (Wi-Fi) modem link
provided five test setups with results in average data rate between 326 kilobits per second
(Kbps) and 790 Kbps. The conclusion showed the driver behind the reduction in data
rates was the proprietary wireless system on the AUV that provided “a relatively low
capacity wireless data link regardless of signal strength and quality,” from the 802.11
standards of 11 Mbps to 54 Mbps (Johansen et al. 2014).

Li et al. (2017), considered the potential of optical communications between a

ground transmitter and a ground receiver by using a UAV. By utilizing orbital-angular

momentum (OAM) multiplexing, there was significant increased capacity of free-space
data transmission to moving platforms. This free-space optical (FSO) communication
system included the ground station as well as the OAM transmitter and receiver while the
UAV hovered in the air. In the conducted experiments, the authors were able to measure
a data transfer rate of up to 80 Gigabits per second (Gbps) over a short roundtrip link
(100m) (Li et al. 2017).

Burdakov et al. (2009), presented two algorithms that were capable of generating
relays in order to transmit sensor information back to a ground station. For their thesis, all
UAVs had the same range for communication. They explained that in order to minimize
transmission degradation UAVs require line of sight communication, and, that even
though it can be amended by increasing altitude, that will mean greater ranges (Burdakov

et al. 2009).

Tierney et al. (2012), compared data transfer protocols over high latency network
paths in an effort to achieve efficient and high-performance data transfer. This study was
focused on meeting expanding scientific data transfer needs for distributed architectures.
Although Tierney, Kissel et al., found that typical data transfers had a 10 Gbps
connection or had data transferred in parallel to circumvent bandwidth limitations, their
evaluation showed the best per-stream performance was around 13 Gbps, including 40
Gbps hosts. They recommended improvements to data transfer methods including the use
of zero-copy systems over the typical send()/recv() and the use of remote memory direct

access (RMDA) over converged ethernet (RoCE) (Tierney et al. 2012).

In a UAV cellular communications study, Xiao, Xia, and Xia (2016) discussed the
potential issues associated with utilizing a moving communication node. Some of the
issues they identified included blockage, beamforming, and propagation loss. Significant
signal degradation can occur when line of sight (LOS) from the ground-based station to
the UAV is blocked by any structure, but the proposed solution to address this issue is to
incorporate adaptive cruising algorithms. Xiao, Xia, and Xia identified thorough
beamforming was found to be timely and costly due to a large number of directions for
the antenna to train. A hierarchical beamforming structure was investigated and they

recommended as a method to significantly reduce search time. Use of a directional
18

antenna was shown to contribute to higher powered received signals (Xiao, Xia, and Xia

2016).

C. UAV CHARACTERISTICS AND SPECIFICATIONS

Table 5 compiles a variety of UAV physical characteristics and performance

specifications.

Table 5. UAV Characteristics and Performance Specifications

Proteus! 12500 1150 61000 219 313 14 78 56
Altus 12 2130 460 65000 81 120 24 54 24
ue 10500 1150 50000 230 300 14 66 36
Reaper?

Pretararape | 2250 710 25000 Bd 135 24 55 27
hae 135 58 19500 63 100 16 16 8
Tigersharké 610 . 14000 63 92 10 22 14
Ricue 416 185 15100 - 126 - 17 14
rr 18000 86 150 9 16 10
pice 68 15000 81 130 9 14 1
Scan Eagle! 49 ; 19500 69 92 24 10 6

Vindicator 22/ 100
i : witnedagt | 2500 65 200 3 9 9

Jackson, Peacock, and Munson (2003)

“General Atomics ALTUS” (2019; Gibbs (2017)

“General Atomics MQ-9 Reaper” (2020); United States Air Force (2015b)
4“General Atomics MQ-1 Predator” (2020); United States Air Force (2015a)
“Boeing Insitu RQ-21 Blackjack” (2020); Insitu Inc. (2017)

®NASC (2020)

™AAI RQ-2 Pioneer” (2020); Military (2020)

“Griffon Aerospace” (2020)

“A AT RQ-7 Shadow” (2020)

10B oeing Insitu ScanEagle” (2020)

"QinetiQ (2017)

D. ALTERNATIVES

In order to effectively find potential solutions for increasing availability of data
through ship-to-shore data transfer, the capstone team adopted the AoA framework in
Figure 6 identified by The MITRE Corporation (2013b). The capstone team identified
objectives from the stakeholder vision statement and then defined analysis criteria. The
capstone team also utilized the knowledge gained from the literature review and SME
feedback to identify, assess, and compare alternatives. This section of the AoA identifies
and describes the alternatives that were analyzed using modeling and simulation.

Additional detailed analysis is provided in Chapter VI, Section B.

2.0 Establish analysis
foundation/framework

3.0 Identify and

1.0 Plan define alternatives

5.0 Compare 40 Assess

are eae alternatives alternatives

Figure 6. AoA Framework. Adapted from The MITRE Corporation (2013b)

The research of design constraints, performance parameters, and UAV
characteristics and performance aided the capstone team with identification of
alternatives and important design considerations. Information provided by Johansen et al.
(2014); Tierney et al. (2012); Jawhar, Muhamed, Trabelsi and Al-Jaroodi (2016); and Li
et al. (2017) was found to be outside of the scope of the capstone. Information provided
by Creed and Glenn (2000), Yang (2018), and Frink (2005) were important design and
performance considerations but technologies discussed did not fit the scenario in which
the DAD conceptual system was going to be utilized. Research by Xiao, Xia, and Xia
(2016) was helpful to understand design considerations if utilizing a LOS with a
directional antenna. Information provided by Wells (2010) was useful to understand
important transceiver design considerations and limitations with range and environment.

Data rates and data transfer technologies provided by wells in Figure 7 made a significant
20

contribution, as microwave technology provided the best potential for a data rates and
was used as input for modeling and simulation. The data listed in Table 5 provided
insight into bolt-on subsystem design constraints as well as flight time limitations for data
transfer. The ranges identified for each UAV platform also provided insight into potential
use beyond CSSQT scenarios, permitting a data transfer technology that can support

longer ranges.

Fixed Microwave (6 to 40 GHz)
and mm-wave (> 60 GHz)

802.11n WiFi (5.8 GHz)

802.11a/b/g WiFi (2.4/5.8 GHz)

Theoretical
802.162 WiMAX (to 3.5 GHz)
[] Practically realizable
LTE 4G (to 2.5 GHz)

0 100 200 300 400 500 600 700 800 900 =1,000
Data Rate (Mbps)

Figure 7. Theoretical and Practical Data Rates via Commercial Technology.
Source: Wells (2010)

Based on stakeholder feedback, DOD experience, CSSQT knowledge, and UAV
operating knowledge, the capstone team prioritized communication range and potential
data rate as focal aspects for alternative solution development. Alternative solutions
regarding UAV or ship system integration were not developed or analyzed as they were
considered high risk for schedule and cost. The alternatives analyzed were chosen based
off limited integration requirements and potential for rapid development and deployment.
As specified in the vision statement, the alternatives developed in addition to the baseline

data transfer method were centered around UAV utilization.

1. Alternative 1: Existing Satellite Technologies

This alternative will keep the conventional satellite connection as the only method
of ship-to-shore data transfer. This method is the control and the benchmark for

comparison. Stakeholders identified current data transfer rates range from 9 — 12 Mbps.

25 Alternative 2: UAV as a Relay

The second alternative identified is using a UAV-deployed DAD subsystem as a
relay. This method is constrained by technology capability because the range at which the
UAV is required to position is equidistant between ship-to-shore. The increase in distance
rules out many data transfer technologies due to reduced capability at further distances, as
well as some of the UAV platforms listed in Table 5 due to limited endurance and longer
data transfer times. Also, increased distance requires greater power for data transmission
over longer ranges, a design consideration that may impact UAV platform selection. This

alternative enables bidirectional ship-to-shore data transfer.

3. Alternative 3: UAV Wireless Receive and Transmit

The third alternative is using a UAV deployed DAD subsystem with wireless
technology for both receiving and transmitting functionality. This method is constrained
by UAV platform range capability, as a wireless receive and transmit subsystem would
enable the ship to be at a further distance from shore. This method is also constrained by
UAV platform endurance due to the increased flight time associated with uploading and
downloading data to/from the DAD system components. The ability to have the UAV in
closer proximity to the ship widens the data transfer technologies available for utilization.

This alternative enables bidirectional ship-to-shore data transfer.

4. Alternative 4: UAV Wireless Receive and Land

The fourth alternative is using a UAV-deployed DAD subsystem to wirelessly
receive and store data from the ship onto a removeable hard drive, then return to base
(RTB) for personnel to retrieve the hard drive. This method is constrained mainly by the
size of the UAV-deployed DAD subsystem, as it cannot exceed maximum UAV payload
capacity. The benefit to selecting this alternative is the potential avoidance of limiting
UAV platform selection to those with greater endurance, as the UAV would only be
required to transit to ship proximity for data upload and RTB for hard drive removal. A
second benefit to selecting this alternative is also the avoidance of a more complicated
UAV-deployed DAD subsystem design that accounts for data transmission. This

alternative restricts data transfer from ship-to-shore and is not bidirectional.
2

5. Alternative 5: UAV Wireless Receive and Transmit + Land

A fifth alternative identified is a combination of UAV wireless receive and
transmit technology with a removeable hard drive. This method has the same constraints
as Alternative 3 but has the benefit of hard drive retrieval in case of emergency. This
method allows for the time saving benefits of alternative 4 but also for the transmission
of data to the ship to support troubleshooting efforts, or as mission dictates. This

alternative will not be analyzed as it will be covered through alternatives 3 and 4.

E. SUMMARY

Through the literature review, the capstone team was able to identify different
data transfer methods, technologies, and alternatives to ultimately increase data transfer
capability. In addition to the current USN date transfer method, alternatives identified
were utilization of the UAV as a relay, for wireless receipt and transmission, and for
wireless receipt and RTB. The research conducted and alternatives identified showcased
important information about the design constraints associated with use of a UAV as a
platform for data transfer. This literature review provides multiple perspectives on how

the information found can be applied to the conceptualization of the DAD system.

THIS PAGE INTENTIONALLY LEFT BLANK

IV. SYSTEM CONCEPTUALIZATION

A. OPERATIONAL CONCEPT DEFINITION

The capstone team developed a system concept that addressed the data transfer
capability gap identified by the vision owners. In addition to increasing availability of
data, the system concept was centered around modularity to avoid the complexities of
integrating with at least two host platforms. As displayed in Figure 8, the DAD

conceptual system is composed of:

One ship-based modular, standalone computer system capable of having

no direct interface with the ship’s combat system.

One bolt on assembly unit external to the UAV, capable of having no
direct interaction with the UAV’s systems. This bolt on unit will provide
the capability of using the UAV as a communication node for data

transfer.

One ground-based modular, standalone computer system capable of using

power provided by the ground station.

Los Angeles” .

; A
i a z oon
~~

bem AA

11 US DAVY SHEP wth Mocaitiar Comparten Lath Systeme

Figure 8. _ DAD Operational View
20

1. Benefits

The operational concept of the DAD system was to transfer ship’s combat system
data through utilization of UAVs outfitted with a bolt on deployable data transfer system,
enable faster availability to data for SME analysis, and decrease elapsed time between
events and decision making. The DAD system will increase ship-to-shore data transfer

effectiveness through the following benefits:

providing an additional method of data transfer redundant to existing

methods

providing an increase to battlespace awareness and an improvement to

tactical decision making through faster availability of critical data

fulfilling a capability gap identified by USN leadership through an

increase in data transfer rate

providing a system with the ability to update software and hardware at a

faster rate and potentially lesser cost than existing shipboard systems

2 Operations and Support Descriptions

Operation and support of the DAD system involves participation from ship’s
force (SF), DAD operators, UAV pilots, UAV launch and recovery team, element SMEs,
and CSSQT team. SF will be responsible for maneuvering the ship to the best UAV link
location and downloading the combat system data onto removeable media. The DAD
operators will be responsible for uploading/downloading data and establishing
communications with the bolt-on subsystem. The UAV pilots will be responsible for
guiding the UAV to both ship-based and ground-based link locations and to the launch/
recovery site(s). The UAV launch and recovery team will be responsible for UAV
preparation, launch, recovery, and any associated post flight requirements. The UAV
launch and recovery team will also be responsible for mounting and unmounting the bolt-

on DAD subsystem. The element SMEs will be receiving the downloaded data and will

perform analysis as required. The CSSQT team will be responsible for coordinating and

executing the data transfer with all involved activities during at-sea events.

1 1.2 1.3 14 15

16
Data
e- Planning |) UAV Launch > Osta rerred to-—> gownoaa "UAV Recovery Data Analysis ie
Figure 9. DAD High Level Activity Diagram

Figure 9 shows the various phases associated with utilization of the DAD system.
To accomplish data transfer from ship-to-shore via the DAD system, the following

general actions have been identified:
1. The CSSQT team, DAD SMEs, UAV teams, and SF will coordinate the

planning and execution of using the DAD system for data transfer.

2 Launch team will prepare UAV with the DAD bolt-on subsystem and will
launch UAV.

a. Ship’s technician will pull data from the combat system and will store on

removeable media.

4, Ship’s technician will provide the removeable media to the ship-based
DAD operator.
on Ship-based DAD operator will load the combat system data onto the

modular computer subsystem.

6. UAV will arrive at designated location; ship-based DAD operator will
initialize communications with the DAD bolt-on subsystem and will begin

data transfer process.

10.

ine

UAV will travel to a designated location near the ground station, ground-
based DAD operator will initialize communications with the DAD bolt-on

system and will begin data transfer process.

Ground-based DAD operator will verify data transfer and download

completion with ship-based DAD operator and UAV operator.
UAV will continue mission or RTB for recovery.

Ground-based DAD operator will upload combat system data to a

designated server for combat system element SME access.

Combat system element SME will analyze data and provide solutions/

recommendations to decision makers.

Operational Assumptions

To keep in line with the scope of this capstone and to simplify the operational

process, the following assumptions were made with regards to transferring data via the

DAD system:

DAD system utilization will occur on a predetermined day during CSSQT
execution, after completion of specified event(s). This will include all

requirements relative to test range scheduling.

The UAV that will carry the bolt-on subsystem will be identified prior to

CSSQT execution during the course of planning phase.

Data transfer was limited to combat system data but can be expanded to

any data available for transfer via removeable media.

The modular computer subsystem will utilize available shipboard

removeable media to transfer and upload data.

The ship will be responsible for properly handling the removeable media

after the ship-based DAD operator has completed the data transfer.

No distinction was made between the transfer of classified and

unclassified data.

DAD system utilization was limited to use of one UAV, but multiple
UAVs with bolt-on subsystems can be used as communication nodes to

relay data from further distances.
Data transfer will not exceed UAV loiter time.

The ground-based DAD operator and applicable SMEs will have access to

the same server.

B. SYSTEM LIFE CYCLE

DOD acquisition models subdivide the system life cycle into a set of basic steps
that separate major decision milestones. The decisions of these milestones are based on
the result of completed system objectives in the preceding life cycle phase, as shown in

Figure 10.

Disposal

Sytems Aequistons
Legend © = Decision Point aX = Milestone Decision C) = Major Review

Figure 10. DOD Acquisition Management Model (DOD 5000.2). Source:
AcqNotes (2018c).

1. Materiel Solutions Analysis (MSA) Phase
As identified by AcqNotes (2018d):

The purpose of the MSA Phase is to analyze all potential material
solutions for an identified need. This phase consists of an AoA and
material solution activities to include measures of effectiveness, cost
estimates, schedule, CONOPS and risk assessment. The goal of this phase

is to recommend possible solutions for further exploration in the
Technology Maturation & Risk Reduction (TMRR) Phase.

The MSA Phase for this capstone is divided into three stages: needs analysis,
concept exploration, and concept definition. Given the scope of this capstone, project
deliverables and objectives are met through the MSA activities, highlighted in Chapter
IV, Section C through Chapter IV, Section E of this report, as well as the AoA in Chapter
VI, Section B.

During the MSA phase, cyber engineering (CyE) efforts focus on gaining an
understanding of the system mission, operational environment, and the program’s risk
management strategy. The CyE tasks for this phase include development of cyber
functional requirements driven by assurance of mission critical functions, system
categorization based on mission, and the initiation of security control selection. These
functional requirements can serve as the baseline for the Cybersecurity Battle Plan, which
includes a Cybersecurity Strategy, Program Protection Plan, Security Assessment Report

and Security Authorization Package (Department of Defense 2015).

a. Needs Analysis

The capstone team conducted an extensive literature review and used stakeholder
and SME feedback throughout the first phase of system conceptualization. As a result,
the capstone team was able to identify existing operational deficiencies and capability
gaps in current data transfer methods. “Without proper understanding of the user needs,
any system runs the risk of being built to solve the wrong problems” (Fairley, Forsberg,
and Madachy 2020). Section C, Needs Analysis, answered the questions “Is there a need
for a new system?” and “How will this need be satisfied?.” The purpose of the needs
analysis was to provide a description of capabilities needed in the system of interest

(Sol).

b. Concept Exploration

The concept exploration phase provides an initial set of system performance
requirements which will be measured later against a set of required capabilities and

performance. This set of requirements are described in Section D for the DAD system
30

concept. Evaluation parameters were identified and deemed critical in order to evaluate
system operational effectiveness. In order to proceed to the concept definition phase, the
following elements needed identification: the system boundary, system functions, system

elements, system sub-elements, and system element interactions.

é. Concept Definition

The goal of the concept definition phase is to identify a set of Sol functional
specifications. Section E describes in detail the Sol’s intended usage and its capabilities.
These sets of functional requirements described the DAD system operational intent and
the capability that will be provided to its stakeholders. This phase delivered a set of
architecture models created using Innoslate. For the AoA discussed in Chapter I,
verification matrices were created and supporting details are provided with supporting

details for each of the alternatives analyzed.

2. Technology Maturation and Risk Reduction (TMRR) Phase

As identified by AcqNotes (2018d), the purpose of the TMRR phase is to “reduce
technology risks and to determine the appropriate set of technologies to be integrated into
a future system that satisfies the needs. . . . This phase will consist of risk reduction, cost
estimations, and programmatic activities.” The major product of the TMRR phase is
competitive prototyping from which an applicable program office will determine at

Milestone B which prototype will proceed as a funded, program of record.

The continued development of the DAD system would allow government
contractors to compete with government off the shelf (GOTS), commercial-off-the-shelf
(COTS), or new development DAD system components. Based on the complexity and
design requirements for the modular computers, multiple vendors could bid on any or all

of the data transfer computer subsystems.

During this phase, it is important to design hardware and software concepts with
cyber capabilities in mind. In the case that the DAD system is fielded, stakeholders must
analyze the best method to address obsolescence while accounting for both cost and

schedule. With risk management, the system development team must consider the effects

of hardware and software obsolescence on the overarching acquisition process and cyber

capability issues.

= i Engineering and Manufacturing Development (EMD) Phase

The purpose of the EMD phase is the realization of the system design. “The goal
of the EMD phase is to complete the engineering development and proceed into
production and development’(AcqNotes 2018d). Major activities in this phase include
developmental testing (DT) and initial operational test and evaluation IOT&E)
(AcqNotes 2018a).

If the DAD system development continued to this phase, the selected prototype
vendor(s) would be funded to further design and test through laboratory and experimental
scenarios. DT and IOT&E at land-based test sites can showcase data transmission
capabilities and can progress to sea-based testing when the system is demonstrated as

mature.

Regarding CyE efforts during this phase, the security T&E engineer must have
security controls and requirements assessed, the cyber risk assessment updated, and the
risk management framework (RMF) package submitted. It is critical that cyber
capabilities maintenance procedures and manuals include system administration
requirements, procedures for patching, virus scanning, antivirus signature updates,

amongst others.

4. Production and Deployment (PD) Phase
Defined by AcqNotes (2018d), the objective of the PD phase is to:

Achieve an operational capability that satisfies the users and mission
needs. This phase consists of two efforts: low-rate initial production
(LRIP) and full-rate production decision review (FRPDR). The phase will
also include operational testing of the capability to determine its
effectiveness.

An operational DAD system finishes operational testing in a sea-based scenario
with a USN vessel with full system validation, and the applicable program office will

fully fund contractors to build and deploy DAD systems.
32

5. Operations and Support (O&S) Phase

“The purpose of the O&S phase is life-cycle sustainment and disposal. The life-
cycle sustainment activities overlap the FRPDR effort of the PD phase. The phase ends
with the final disposal of a system” (AcqNotes 2018d).

The sustainment efforts of the DAD system depend on a number of factors,
including ISEA support, DAD system inventory across the U.S. fleet (potentially
including Foreign Military Sales to allied nations), and adaptability of the system to
upgrade across newer UAV platforms, hardware/software upgrades, and hardware/

software obsolescence.

GA NEEDS ANALYSIS

The objective of conducting a needs analysis is to identify that a valid operational
need exists and that a new system will fulfill that need at an affordable cost with an
acceptable level of associated risk. The needs analysis is critical in revealing why a new
system is needed and allows for a conceptualization of a successful system to form in the
minds of stakeholders by producing arguments that support the stated needs. The needs
analysis should answer the following questions: (Blanchard and Fabrycky 2011)

(1) What is required of the system in “functional” terms?
(2) What functions must the system perform?
(3) What are the “primary” functions?

(4) What are the “secondary” functions? What must be accomplished to alleviate

the stated deficiency: when must this be accomplished?
(5) Where is it to be accomplished?
(6) How many times or at what frequency must this be accomplished?

As seen in Figure 11, the primary inputs of the needs analysis are operational
deficiencies and technological opportunities. The team first derived inputs for the needs
analysis from the provided vision statement, followed by a more in-depth exploration of

background information, stakeholder needs, and a technical review.

Operational System Operational
Deficiencies Effectiveness

Technological System Capabilities
Opportunities

Figure 11. Needs Analysis Phase in the System Life Cycle. Source:
Kossiakoff (2011).

Operational deficiencies were initially identified by the stakeholder vision
statement and were further refined by follow-on research in the background and technical
review. The primary operational deficiency identified was the demand for a faster data
transmission method to augment existing ship-to-shore communication networks to
support USN test events. Test event analysis and distance support efforts necessitate
tremendous amounts of data to be transferred to ground-based activities. Bandwidth
constraints imposed by existing communications systems can prohibit the possibility of

both timely test event data analysis and distance support efforts.

The capstone team identified a technological opportunity to fill this capability gap
by leveraging capabilities of existing UAV platforms to facilitate a new line of
communication capable of fulfilling stakeholder requirements. The capstone team set out
to develop a novel system to augment existing USN communication systems with one
that can handle the steep data transfer requirements associated with USN test events.
Additionally, this system would have to operate in environmental conditions associated
with these events, interface with operators at the ship and ground station, establish and
maintain a bidirectional data connection as required between the ship and ground station,
and have the capability to interface and write data to approved removable media. Test
events are typically conducted post ship delivery or after an availability period, where

major system upgrades were implemented. With the current goal of a 355-ship fleet
34

(O’ Rourke 2020) and increasing complexity of ship systems, there will be consistent and
immediate demand for an improved data transfer capability to support test events for the
foreseeable future. The majority of test events occur on ranges in U.S. territorial waters.
These ranges have an existing infrastructure and established distances between ship

operational areas and ground stations.

Partitioning criteria was applied to translate that information into functions and
further allocate those functions into subsections. System and subsystem functions were
then further decomposed, and feasibility criteria was applied to formulate the feasibility
of the DAD concept. The derived conceptual system was an aggregate of analysis of

predecessors and related systems and paired with operational objectives.

D. REQUIREMENTS ANALYSIS

Maintaining progression through the systems engineering process, the
requirements analysis phase examines the operational perspective of the DAD system and
states requirements in terms of project objectives. The intent of the requirements analysis
is to restate or amplify both the system capabilities and system operational effectiveness
associated with the overall operational objectives. The analysis performed in this section
is derived from the definition of stakeholder needs as well as background research

applicable to system designs regarding UAV data transfer.

The requirements analysis can be expanded into a process of tasks to transform
the system capability inputs into more specific functional system performance
requirements. By utilizing the Institute of Electrical and Electronics Engineers (IEEE)
P1220, the capstone team was able to follow the systems engineering standard for
performing a comprehensive process in completing the Requirements Analysis (Defense
Acquisition University 2001). The capstone team tailored the list to consider all

necessary DAD system requirements.

1. Customer Expectations

The vision owners for this project understood both the project objectives in their

entirety and the validation process for the DAD system. Throughout our collaborative

meetings they expected our evidence to achieve its intended use in the conceptual,

operational environment within the academic timeframe allowed.

22 External Constraints

The list of external constraints can be sub-categorized by Academic Compliance

constraints and System Capability constraints.

a. Academic Compliance

Given the educational aspect of this hypothetical data transfer system, the
information released for viewing and referencing purposes to the general public must
comply with DISTRIBUTION STATEMENT A: Available for Public Use (Defense
Technical Information Center 2012) .This restricts sharing any potential classified,

proprietary, operational or otherwise vulnerable data and information.

b. System Capability

The scenarios in which the DAD system operates involves the respective
subsystems and their components to interact with both existing ship and shore software
and hardware systems, which can limit the interface capabilities. There are additional
cybersecurity risks to be considered when transferring classified data between ship and

shore subsystems.

3. Operational Scenarios

In order to achieve the project objectives in the allotted academic timeframe, the
operational scope consists of a small scale, single UAV to transfer data as a
communication node from ship-to-shore, during a CSSQT or other test events. Chapter
VI explains a post feasibility study that allows for expansion of the operational scenario

capabilities.

4. Utilization Environments

The hypothetical operational scenarios include ideal maritime environmental

conditions to transfer data from ship-to-shore during CSSQT or other test events. These

ideal conditions include daytime, clear weather (no low-pressure systems present in the

operational area), with steady sea-state conditions.

op System Boundaries

There are multiple boundary considerations for this project- operational,
hardware, software- that define the full capabilities of the DAD system. We have greater
interest in the hardware and software boundaries of the system, as these are best
represented by the systems architecture framework. The framework can outline the UAV,
ship and shore subsystem locations and their physical components, including operators
and removable media, as well as the operating system functional data paths within the

communication relay of the system.

Given the conceptual design scope of this project, physical interfaces were
considered as a suggestion based on both ergonomic principles and existing shipboard
installation availability. The physical configuration spaces on both ship and shore may
allow a smaller subsystem that is deployable, with modularity and a quick setup.

6. System Requirements

System requirements were partitioned between functional and non-functional
requirements. The capstone team developed the following requirements for the DAD
system after multiple feedback discussions with subject matter experts on both UAV’s
and communication relays:

a. Functional Requirements

Functional requirements were further decomposed in Chapter IV, Section E.

System shall have a human interface for the ground-based and ship-based

subsystems.

System shall have a user-friendly graphical user interface (GUI) for the

ground-based and ship-based subsystems.
System shall operate in clear weather conditions.

System shall establish and maintain a bidirectional data connection.
System shall receive/write data via authorized removable media.

System shall have an operational availability of xx% (threshold) or xx%

(objective).

Bolt-on subsystem shall be able to withstand takeoff, landing, and in-flight

conditions
Bolt-on subsystem shall be deployable with xx minutes.
Bolt-on subsystem shall be uninstalled within xx minutes.

Non-functional Requirements

System shall transfer data at a minimum rate of xx Mbps (threshold) or xx

Mbps (objective)

Ship-based modular computer subsystem shall utilize 110v electrical

outlet.
Systems shall encrypt data at rest on portable and removeable media.

All DAD system sub-components shall have an encryption and decryption

capabilities.
System shall encrypt data in transit.

Bolt-on subsystem shall have a minimum battery life of xx hours

(threshold) or xx hours (objective).
Bolt-on subsystem shall be under xx pounds (Ibs) and xx cubic feet (ft).

Bolt-on subsystem shall be battery powered.

E. FUNCTIONAL ANALYSIS

There is an importance to analyze what the system must do before describing how
those system capabilities are to be completed. The Functional Analysis offers a
decomposition of the system functional requirements through several subsystems
arranged in a hierarchical structure (Whitcomb 2000). The DAD system can be
decomposed into its modular and bolt on subsystems’ functional flow with respect to the

functional requirements listed in Section D.

1. Functional Flow Block Diagram (FFBD)

Utilizing an FFBD relates the inputs and outputs of the DAD system while
providing insight into the flow between the different system functions (INCOSE and
Wiley 2015b). The conceptualized scenario involves data input from either a ship-based
or ground-based user on the respective modular computer subsystem. That data package
is sent from one modular subsystem through a UAV’s transmitter/receiver bolt-on
subsystem as a relay for data retrieval to the other modular subsystem. A system level

FFBD is illustrated in Figure 12.

Ones SSS =
Figure 12. DAD System Level FFBD (ship-to-shore data transfer)

Figure 12 defines the functional scope of the DAD system, showing both
communications between the ship and shore on UAV services, and the data transfer
interactions between the modular and bolt-on subsystems. Note that this functional
example did not implement bi-directional flow in the same diagram, but each of the
functional steps would proceed in the same order had the shore requested UAV services

to send data from the shore modular subsystem to the ship modular subsystem.

2s Functional Requirements Decomposition

a. System shall have a human machine interface for both ground-based
and ship-based subsystem

For any ship test event, the process of communicating data starts with SF (both
enlisted and officers) relaying data packages to be received and interpreted by
government ISEAs. In order for the data to be extracted, both SF and ISEA must have the
physical capability to access the means to insert/compress the data to be sent, as well as

extract/decompress the relayed data package.

b. System shall have a user-friendly GUI for the ground-based and ship-
based subsystems

To assist with efficient use of both computer subsystems, the GUI shall have an

application that is easy to navigate with clear and concise information.

c. System shall operate during clear weather conditions

This requirement is necessary for reliably conducting data transfer operations
using the DAD system. Inclement weather conditions provide increased risk for impaired

data transfer capability, or event cancellation altogether.

d. System shall establish and maintain a bidirectional data connection as
required to both ground-based and ship-based subsystems

The UAV will have a predetermined flight plan, based on the request from the
ship. The UAV will proceed on course until in range to establish a data connection; the
UAV would fly in a loitering pattern about the ship to ensure a stable connection to
upload the data package. The ship would minimize its own change of course to keep a
consistent loitering pattern. In the event of a loss of communications or loss of global
positioning system (GPS) signal between the UAV and the ground operators,
programmed protocols would guide the UAV back towards the ground station until

communication link could be reestablished.

e. System shall receive/write data via authorized removeable media

The DAD system is conceptualized around existing shipboard spaces and overall

physical attributes, as well as hardware/software suites within the applicable combat

system baseline.
f System shall have an operational availability of xx% (threshold) or xx%
(objective)

Operational availability is a function of reliability, maintainability, and
supportability. The better the operational availability, the greater the capability for the
USN. (Office of the Chief of Naval Operations 2003)

g. Bolt-on subsystem shall be able to withstand takeoff, landing, and in-
flight conditions

Exposure to extreme environmental conditions requires the bolt-on subsystem to
be tested for shock, vibration, thermal cycling, salt-water, fog, electromagnetic

interference (EMI), and others.

h. Bolt-on subsystem shall be deployable within xx minutes

UAV deployment is dependent on acceptable launch conditions, potentially
decreasing the amount of time available to install the bolt-on subsystem. In order to be
available for use during real time decision making, the bolt-on subsystem must be able to

be installed within a given timeframe to avoid further launch delays.

i. Bolt-on subsystem shall be uninstalled within xx minutes

To be able to effectively maintain data control, is it important for the system to be

easily uninstalled in order to perform any direct download or sanitization.

F. SUMMARY

The capstone team expanded the idea of a data transfer system into an operational
concept that addressed the data transfer capability cap identified by the vision owners.
Considering the program requirements of acquiring a future DAD system, a layout of the

system life cycle was addressed by subdividing system deliverable across the multiple
4]

phases of DOD Acquisition. Given the conceptual scope of this project, most of the
capstone deliverables were shown in the MSA phase. This included a needs analysis that
identified an existing operational need and a concept exploration that included a
requirements analysis restating both system capabilities and system operational
effectiveness. Finally, a concept definition showed a functional analysis that described

how the system capabilities were to be completed.

V. SYSTEM ARCHITECTURE

System architecture provides a foundation for design and development through
organization of system components, their relationships to each other and to their
environment (The MITRE Corporation 2013). System architecture communicates the
system’s design through visual representation of functionalities, interfaces, and
requirements to ensure desired stakeholder requirements will be met. The architecting

process also helps to define system constraints, boundaries, and additional requirements.

The architecture for the DAD system was developed in accordance with (IAW)
the DOD framework shown in Figure 5 (Office of the Deputy Chief Information Officer
2020) using the MBSE tool Innoslate. Different system diagrams were developed in order
to showcase the DAD system and its functionalities on a broader level. Systems modeling
language (SysML) was used to create the following diagrams: requirements diagram,
package diagram, block definition diagram, use case, activity diagram, and a sequence

diagram.

A. REQUIREMENTS DIAGRAM

Development of the DAD system architecture began with the identification of
system requirements. The purpose of requirements diagrams is to represent relationships
between requirements, as well as partition those requirements into functional and non-
functional groups (SysML.org 2020b). DAD system requirements were initially
conceptualized by stakeholder needs and were refined through research and technical
review. Figure 13 shows a high-level requirements diagram for the DAD system. System
functional requirements define basic system behavior and for the DAD system included
interface, operational environment, data transfer, UAV launch, and availability
requirements. Non-functional requirements define how the system will perform its
behavior and for the DAD system included performance, design, and software security
requirements (QRA Team 2019). The requirements identified in Figure 13 were

previously discussed in Chapter IV, Section D.

aureee =< Feawreredt >>
"Sees tee | Reems | Scene” Race tn
Requirements Security Requirements

bolt-on sub-system shail Shall transfer data sta | Bolt-on sub-system shall
be deployable within xx minimum rate of xx Mbps be under xx Ibs and xx
minutes (threshold) or xx Mbps cubic ft
Bolt-on sub-system shall <a Weaate > Ship-based modular
be uninstalled within xx
minutes electrical outiet

Figure 13. DAD System Requirements Diagram

B. HIERARCHY DIAGRAM

The purpose of a hierarchy diagram is to show the Sol with the physical context
of its intended environment and external systems. Through visualization of physical
relationships, a better understanding can be gained about the system interactions and
boundaries. Figure 14 shows the upper levels of the DAD system alongside the external
systems associated with utilization of the DAD system for data transfer. Fourth level
subsystems were shown on select third level subsystems to simplify the hierarchy

diagram.

Universe

Citi

Figure 14. DAD System Hierarchy Diagram

C. PACKAGE DIAGRAM

The purpose of a package diagram is to support the organization of complex
system architecture through ‘decomposed by’ (solid lines) or ‘ related to’ (dashed lines)
relationships between elements packaged with unique identifiers (SysML.org 2020a). For
this capstone, a mission planning package diagram was created to show the elements
associated with using the DAD system for data transfer during a CSSQT. Figure 15 also
shows how the DAD system fits into CSSQT execution. To keep in line with the scope of
this capstone, the DAD system is shown as an additional method of data transfer, next to

currently used methods of satellite and hand-carrying data transfer. Combined with the
high-level physical relationships identified in the hierarchy diagram, the non-physical
relationships identified in this package diagram helps to visually represent the activities

and entities involved with using the DAD system to transfer data during a CSSQT.

Plannrg
Mesion | CSsoT
OO GR)
| — 7
osseR Progam
<< ON > Funding Tracking Firing Everts
TSE ee ————— Events
Guidelines ews = cssor »
Test Team
Iderthcator Daa
{ Meragement
| : Data upload 1 Osta
W
Test Gojoctive js Milestones | Schedule have © uAY ree rom
L » |
Cenicaion | ner Satobo meet: > Elomert Cato * ia 7
ESS = | DataTranster =~ *~~~*~ Recording b- seman + < =xe8 »
+ ccireet oe
Nissior Scanano Msson | Hand Carry :
Conot Pane Data Transter '

Cortfication | Readiness

Figure 15. DAD System Mission Planning Package Diagram

D. BLOCK DEFINITION DIAGRAM (BDD)

The purpose of a BDD is to define the features of a block as properties,
operations, and relationships; and relationships between blocks as associations and
dependencies (No Magic, Inc. 2020). The BDDs shown in Figures 16 through 19 breaks
down the DAD system into its subsystems and subcomponents. Additionally, the external
actors are shown via aggregation. Figure 16 shows the DAD system decomposed into its
three major subcomponents: the bolt-on UAV unit, ground-based modular computer

subsystem, and ship-based modular computer subsystem.

[ l

a — = Cenk =
C.1.1 Bolt-On Sub System C.1.2 Grourd-Based Modular Computer Sub-Syster C.1.3 Stip-Based Moctar Computer Sub-System

Figure 16. High Level DAD System BDD
46

Figure 17 decomposes the bolt-on UAV unit into its respective subcomponents
including the transmitter receiver, power supply, power distribution module, network
switch, and central processing unit (CPU). An aggregation relationship between the UAV

and bolt-on UAV unit are shown.

| Cau 4 C.1.1 Bolt-On Sub-Gystem |» 6.115CPU |

r ROSES

Figure 17. DAD Bolt-On UAV Subsystem BDD

Figure 18 decomposes the ground-based modular computer subsystem into its
respective subcomponents, including the CPU, KVM (Keyboard, Video, Mouse), and
transmitter/receiver. Aggregation relationships with the ground-based operator and

ground station power supply are shown.

a= thick oe «wl. a= bach ne
C.1.2.5 Ground Shation Power Supply j—S) C12 Ground Based Modular Computer Sub Systers re | C.1.24 Geound Station Opeutor
| ‘ +
== == oo tae os

C121 CPU C122KvWM C.1.23 Tranerritier Revewer

Figure 18. DAD Ground-Based Subsystem BDD

Figure 19 decomposes the ship-based modular computer subsystem into its
respective subcomponents, including the CPU, KVM, and transmitter/receiver.

Aggregation relationships with the ship-based operator and shipboard power supply are

shown.
C.1.3.5 Shipboard Power Supply —e— C.1 3 Ship-Based Modular Computer Sub-System oo C.1.3.4 Shipboard Operater
= | =
ae aus =a
C.13.1 CPU C1iA32KvM C.13.3 Trarumiter Revove

Figure 19. DAD Ship-Based Subsystem BDD

E. USE CASE DIAGRAM

A use case diagram represents system transactions with external actors. System
transactions are represented by ovals with action-oriented verbs or phrases, system
boundaries are represented by rectangles and have unique identifiers, and actors are
represented by stick-figures. Use case diagrams can also be used to identify top level

requirements (SysML.org 2020d).

Figure 20 shows the actors and transactions associated with the UAV launch and
data upload to UAV boundaries. To simplify the diagram, top level actions were used
within the shown system boundaries. For the UAV launch portion of the operational
sequence, three main transactions were identified; equip UAV with bolt-on subsystem,
prep UAV to launch, and launch UAV. The actors associated with the UAV launch
transactions are the DAD team, launch team, and UAV pilot. For the data upload to UAV
portion of the operational sequence, five main transactions were identified; pilot UAV,
verify intercept location, upload data to the modular computer ship-based subsystem,
upload data to bolt-on subsystem, download combat system (CS) data, and maintain bare
steerage. The actors associated with this phase are the UAV pilot, DAD SME, bolt-on

subsystem, ship-based modular computer subsystem, and ship’s force.
48

UAV Launch

DAD Team

Bot-On Sub- System

Ship's Force

Figure 20. DAD System Use Case Diagram for Receive and Transmit
Alternative

F. ACTIVITY DIAGRAM

An activity diagram is used to describe the control flow and object flow among
actions. An action is defined as a primitive executable behavior, control flow is defined
as the flow of functional behaviors, and object flow is defined as data flow of object
inputs/outputs (SysML.org 2020e). In the activity diagram in Figure 21, actions are
represented as white boxes, input/output are represented by green rectangles, and

decision points are represented by white diamonds. The activity diagram flows from left

to right and different actors are shown by different ‘lanes. Actors include personnel as

well as equipment.

Figure 21 identifies the required actions for data upload and data transmission
from the DAD SME, ship-based modular computer subsystem, bolt-on subsystem, UAV,
UAV pilot, and SF. The data upload phase is initiated by verification of ‘intercept’
location by the DAD SME and the UAV pilot, or the location where the UAV is going to
be positioned and be in range to communicate with the DAD ship-based modular
computer subsystem. Once the location is determined/verified, the UAV pilot will
maneuver the UAV to that location. Independent of those actions, the DAD SME will
upload the CS data (removeable media previously obtained from SF) and verify if upload
was successful. If upload was not successful, the DAD SME will attempt again or request
another removeable media from SF. After CS data upload completion to the ship-based
modular computer subsystem and arrival of the UAV on location, the DAD SME will
establish a connection with the bolt-on subsystem and initiate data upload. The DAD
SME will monitor upload status and upon completion will terminate connection with the
bolt-on subsystem. Completion status will be relayed to the UAV pilot and the UAV pilot
can then maneuver the UAV for ground station download. Due to variability of flight

time without using a specific UAV, fuel consumption was not shown as a resource.

Data Upload to UAV (Receive and Transmit Alternative)

Figure 21.

G. SEQUENCE DIAGRAM

The purpose of a sequence diagram is to display sequential system interactions/
behaviors as messages between actors (SysML.org 2020c). A sequence diagram is similar
to an activity diagram in that both show interactions between entities, but a sequence
diagram does not show input or output. Figure 22 shows the required actions for data
download from the UAV to the ground station. Actors include the bolt-on subsystem,
DAD SME, ground-based modular computer subsystem, UAV, and UAV pilot. The data
download phase has similar actions to the data upload phase, with the exception of
communications between the bolt-on subsystem and the ground-based modular computer

subsystem. Upon completion, the UAV can RTB or continue mission.

Figure 22. DAD Sequence Diagram
a2

H. SUMMARY

System architecture serves as the organization of system elements with each
other, as well as the environment. The visual representation provided through each
diagram created in Innoslate assist in communication of system interfaces, relationships,
boundaries, and constraints. The capstone team referenced the DOD architecture
framework 2.0 multi-step process as a guide to develop DAD system architecture (2020),
based off the requirements identified in Chapter IV, Section D, Subsection 6. Combined,
all provided diagrams describe upper and lower level relationships between the DAD

system and external activities.

THIS PAGE INTENTIONALLY LEFT BLANK

VI. MODELING AND SIMULATION

A. MODELING METHODOLOGY

The model used for this capstone was created using the modeling and simulation
tool ExtendSim. The purpose of using ExtendSim for modeling and simulation was to (1)
produce a model that was a representation of the intended construction of the Sol, (2)
enable analyses to predict the effects of any changes made to the Sol, and (3) evaluate
Sol behaviors and performance under different existing and proposed configurations
(Maria 1997). The following steps to construct and execute the ExtendSim model was

adapted from the Introduction to Modeling and Simulation (1997).

1. Problem Identification

Problem identification is discussed in Chapter I, Section C.

2. Model Development

The baseline model was developed with regards to real CSSQT scenarios. During
a CSSQT on a controlled range, the ship is located within a specified number of miles
offshore to enable communications with range safety and the test conductor. Proximity to
shore allows for CS element data to be transferred and analyzed. The quantity of data that

is typically transferred during any given CSSQT event was also taken into consideration.

The baseline model represented ship’s current method for data transfer, satellite
using Kurtz-unter (KU) band. The satellite scenario was the comparative control for
amount of operational time required to transfer data from ship-to-shore. In the satellite
model shown in Figure 23, the first function in the simulation was to set the file size to be
transmitted. The second function was a human factor delay to account for establishing
satellite connection. The data relay function was then used for calculating how long the
data will take to transit based on data rates provided by Wells (2010) and file size for
element data. The final function of the simulation was to tabulate the operational time

and write it to a database for analysis, representing the data being received.

Set File Data
Received

Figure 23. Satellite Baseline Model

3. Model Validation

Model validation was provided through research of existing and validated
systems, SME and stakeholder feedback, as well as academic modeling and simulation
SME feedback. Another method of model validation was comparison of simulation
model outputs utilizing various input combinations, such as different data transfer
technologies coupled with the different event condition inputs, such as human factor

variations.

4. Experimental Design and Simulation Conditions

Three different data transfer scenarios utilizing UAVs were modeled. Simulation
conditions included variations in human factor delays, data transfer capabilities, and time
required for the UAV to maneuver from different locations. Simulation inputs also
included variations in file size, UAV specifications, and distances from shore. Expected
simulation outputs were data rates and operational times. Using these specific scenarios,
data transfer technologies can be compared to show more coverage of current COTS

capabilities. Statistical analysis of operational time and relation to specified variables

aided in understanding the benefits and risks associated with utilizing unmanned vehicles

to transmit data. Alternatives are compared in Section C.

a. UAV as a relay

For this scenario, the bolt-on subsystem was used as a communication node,
similar to the KU band method, where the data will be wirelessly transferred through the
subsystem to the ground station. The relay scenario represented a case where the ship is
in such a proximity that the ship-based subsystem can communicate with the ground-
based subsystem. As shown in Figure 24, the first function in this simulation was to set
the file size and the second function was to set the human factor delay. The next function
included in the simulation was the UAV transit function. This function was an added
delay that accounted for UAV operational time, including flight speed variation. The next
function was a data relay delay based on data rate and file size for transmission. The final
function of the simulation was the same as the satellite version where the data is written
to a data table and processed for analysis. This model incorporated complications for

UAV power transmission.

Data
Received

Figure 24. UAV Relay Model

b. UAV wireless receive and transmit

For this scenario, the data was wirelessly uploaded and stored on the bolt-on
subsystem, then wirelessly transferred to the ground station. This scenario represented a
case where the bolt-on subsystem had the required power transmission capacity for the
specified data sizes, as well as UAV fuel capacity that supported the required transits and
loiters. In Figure 25, the model incorporated functionality used in the UAV relay scenario
but also accounts for additional time required for the UAV to transit to ground station
proximity and transfer data. This scenario had a second human factor delay to account for
the ground station operator establishing a connection with the bolt-on subsystem when

the UAV is in proximity.

Deta
Download

Figure 25. UAV Wireless Receive and Transmit Model

c. UAV wireless receive and land

For the UAV wireless receive and land scenario, the data was wirelessly uploaded
and stored on a bolt-on subsystem hard drive, then recovered by ground station personnel
after UAV RTB. This scenario represented cases where the power required for data
transmission cannot be achieved due to system design constraints or where it is
unfeasible for the UAV to transit back to ground station proximity for wireless data

transfer. As shown in Figure 26, this scenario had model behavior similar to the UAV

wireless scenario, without the added time for data download and with the second human

factor delay accounting for hard drive retrieval.

Figure 26. UAV Wireless Receive and Land Model

B. ALTERNATIVES ASSESSMENT

This section continues the AoA that is described in the Chapter I. The capstone
team analyzed the related ExtendSim models’ output data to determine overall UAV
effectiveness as a replacement or as an augmentation to the existing methods of data
transfer. For that reason, the focus was on operational time required to send and receive a
file to compare the alternatives. The assessment consisted of an analysis of variance of
means between different sets of output runs to determine model repeatability, descriptive
statistics of the output relay times for the four models, and the regression analysis and

factorial design of input factors to determine influence on the relay times themselves.

1. Statistics

The breakdown of analysis began with testability of the models. Using the data
collection and analysis tool, Minitab, 2-sample t-tests were used to compare two separate
100 output runs for each model against each other, to determine if the null hypothesis
(sample mean | = sample mean 2) could or could not be rejected. Table 6 details the t-test
metrics, including the p-values for each model. With an alpha value of 0.05, the p-values

show to be substantially greater, and the null hypothesis of equal means for multiple 100
output runs of the same model cannot be rejected. While the modeling methodology
highlights relay scenarios for 15GB, 100GB and 1000GB file sizes, the respective
comparisons for 15GB file sizes is an appropriate analysis baseline to compare the UAV

effectiveness to the current Satellite data transfer capabilities.

Table 6. 2-Sample t-Test Results for Satellite and UAV Models’ Testability

Satellite (hrs) 0.47 180 0.64 No

UAV Relay (hrs) 0.21 197 0.84 No

UAV Receive and Land (hrs) 0.38 197 0.70 No
UAV Receive and Transmit (hrs) 0.38 197 0.70 No

The average time (in hours), along with the standard deviation and range of 100
run time outputs for each model are shown in Table 7. These outputs consider a normal
distribution of random inputs for each of the respective input factors. A clear observation
would show that the satellite model takes well over three hours to completely send a
package size of 1ISGB, while each of the UAV models show significant decreases in time
required for data transfer. The UAV wireless receive and land and the UAV wireless
receive and transmit models show similar outputs because the UAV loiter time provides

the main action difference in the two models, providing little difference in variation.

Table 7. Descriptive Statistics for Satellite and UAV Models’ Output Times

for 15GB
Satellite (hrs) 3.66 0.44 2.96 5.47
UAV Relay (hrs) 0.52 0.15 0.29 0.79
UAV Receive and Land (hrs) 1.28 0.30 0.80 1.88
UAV Receive and Transmit (hrs) 1.32 0.30 0.83 1.92

2. Multivariant Regression Modeling

In order to analysis the significance in outputs, it was important to examine the
decomposition of the models themselves. With the existing method simulated in the
satellite model. All input factors- the file size, human factor delay, and data transfer rate-
were compared against the output of satellite data relay time. For the UAV related
models, the inputs all remain the same- the fixed transit distance of the UAV between
ground station and ship, the human factor delay, the UAV flight speed, the file size and
the UAV data rate- which are compared to three different outputs for the three UAV
models- UAV relay, UAV grab and land, and UAV grab and beam.

Regression modeling determines the strength of relationship between the input
factors and the output they are compared to. This helps determine if there is a level of
predictability with all factors when the values are manipulated. Table 8 and Table 9 show
the multivariable linear regression statistics tables for the satellite and UAV models,
respectively, to highlight the regression values with the 100 model run observations. As
the randomized inputs have shown, there proves to be no relationship to the output times

themselves. Further analysis needed to be completed to examine the influence of each

input.
Table 8. Multivariable Linear Regression Statistics for Satellite Model
Multiple R 0.12
R Square 0.01
Standard Error 0.15
Observations 100
Table 9. Multivariable Linear Regression Statistics for UAV Models

Multiple R 0.0967 0.0978 0.0980

R Squared 0.0094 0.0096 0.0096
Standard Error | 0.1509 0.3086 0.3085
Observations 100 100 100

3. Factorial Design

The significance of input factors to a model can be dependent of the number of
inputs present for the model itself. The fewer factors that contribute to the model, the
more significance they hold in relation to the output’s value. Because the satellite model
has two controllable, non-fixed factors and the UAV models have three controllable, non-
fixed factors (file size is a fixed input), then a creation of factorial design of experiments
(DOE) without the requirement of a screening for influential factors is needed. The
Factorial DOE created looks at two factors at two levels for the satellite model, and three
levels at two levels for the UAV models. Based on previous data collected through

research and SME discussion, the two levels “High” and “Low” are shown in Table 10.

Table 10. Level Values for Input Factors

High 45 150 12 860
Low 15 80 6 800

The factorial design highlights the influence of each input with a high and low
value with the other respective inputs in a randomized pattern. These sequences of 100
run samples are compared against each model, and against the default randomization of

the four developed models.

Table 11. Factorial Design for Satellite and UAV Models’ Output

HF LOW, UAV Speed
RAN, UAV Data RAN
HF HIGH, UAV Speed
RAN, UAV Data RAN
HF RAN, UAV Speed
LOW, UAV Data RAN
HF RAN, UAV Speed
HIGH, UAV Data RAN
HF RAN, UAV Speed
RAN, UAV Data LOW
HF RAN, UAV Speed
RAN, UAV Data HIGH

ALL UAV RANDOM 5

(Normal)
HF LOW, SAT Data RAN x
HF HIGH, SAT Data x
RAN

HF RAN, SAT Data LOW xX

0.29 0.81 0.85

0.79 1.81 1.85

0.54 1.42 1.46

0.54 1,23 1.27

x |x| mK | x | OK

0.52 1.26 Lat

0.35 1.28 1.32 x

4.20
4.66
6.06
3.30

HF RAN, SAT Data
HIGH
ALL SAT RANDOM
(Normal)

~ | Kx TX] OM LR]
~ | Kx TX] OM [PR]

4.45

Across the satellite model sequences, the data rate levels show the largest
difference in output mean to the default mean- with a respective min and max of 3.29 and
6.06 hours against the default average of 4.45 hours. With the UAV model sequences, the
human factor levels show the largest difference in output means to the default mean.

Table 11 highlights the entirety of discussed values.

Because of the large difference in data transfer rate, it is clear that as the required
data transfer time decreases, the influence of the human factor delay increases. A 30-
minute human factor delay will provide a larger variance from the output relay time mean

on the quicker UAV model than the conventional, slower satellite model.

C. ALTERNATIVES COMPARISON

In addition to statistical analysis, a comparison was performed between
operational time and engineering complexity for each alternative solution at file sizes 15,
100, and 1000 Gigabytes (GB). The inputs listed in Table 12 resulted in the outputs found
in Table 13 by utilization of a function that included UAV transit time (UAV alternatives

only) and data transfer time.

Table 12. Comparison Inputs

Distance from Shore (mi) 30
UAV Speed (mph) 80-140
File Size (GB) 15, 100, 1000
Satellite Data Rate Variation (Mbps) 6-12
UAV Data Rate Variation (Mbps) 800-860
Human Factor Delay Variation (min) 5-15

Table 13 shows a weighted comparison of all the alternative scenarios that were
simulated. The operational time shows the averages of 100 runs in the simulations for
each category of file size. The fastest method correlates to the smallest number of hours.
Each scenario was also rated in terms of design complexity low, medium, or high. The
best combination of these two parameters describe the best way to apply the use of a

UAV for data transfer.

Satellite

UAV Relay

Table 13. Alternative Data Transfer Methods

Deployed on current USN

Power to transmit needs attention
as well as hardware increase for
dealing with longer distances to

track the UAV.

UAV Receive
and Land

Power to receive is a lot less than

to transmit and landing the UAV

saves time when getting the data
to be analyzed.

UAV Receive
and Transmit

Satellite

UAV Relay

Medium

Power to transmit needs attention
as well as requirements for the
UAV platform like loiter time and

Starts to put pressure on event
schedules and mission capability if
requirements have a time window.
Power to transmit needs attention

as well as hardware increase for
dealing with longer distances to
track the UAV.

UAV Receive
and Land

Power to receive is a lot less than

to transmit and landing the UAV

saves time when getting the data
to be analyzed.

UAV Receive
and Transmit

Satellite

Power to transmit needs attention
as well as requirements for the
UAV platform like loiter time and

Puts massive strain on scheduling
and takes too long for Navy
mission.

UAV Relay

Power to transmit needs attention
as well as hardware increase for
dealing with longer distances to

track the UAV and flight time
starts to become a factor.

UAV Receive
and Land

UAV Receive
and Transmit

Power to receive is a lot less than

to transmit and landing the UAV

saves time when getting the data
to be analyzed.

Power to transmit needs attention
as well as requirements for the
UAV platform like loiter time and
range.

‘0 - 2.0 hours is considered favorable for operational time and is highlighted as green. 2.0 - 5.0
hours is considered less favorable for operational time and is highlighted as yellow. 5.0+ hours
are considered least favorable for operational time and is highlighted as red.

Engineering complexity was categorized into three levels: low, medium, and high.

D. SUMMARY

This chapter detailed the approach taken to simulate alternative solutions in order
to calculate the time it takes to transfer data from ship-to-shore. The capstone team
developed four different models representing the alternatives discussed in Chapter HI.
From the operational simulations, the capstone team performed statistical analysis for
alternative comparison. The data presented variations of mean output time and concluded
that regardless of delay time, the UAV operational time outputs showed significant

improvements over the traditional satellite model.

Vil. CONCLUSION

A. SUMMARY

The primary objective of this project was to conduct a feasibility study to
understand if a UAV can be used to improve the data transfer capability for the USN.
From the literature review and knowledge gained from SMEs, the capstone team
determined use of a UAV in ship-to-shore data transfer could provide benefit to the USN.
The capstone team used defined initial system requirements, available research of
communications systems, and available UAV characteristics to develop system
architecture with the MBSE tool Innoslate. The utilization of MBSE tools supported the
understanding and the ability to communicate interactions and functions of the DAD

system within itself, external users, and the environment.

The team identified several alternatives in which a UAV platform could be used
as part of a system to supplement existing USN communication systems for data transfer.
One alternative considered was to use wireless communications to get the data from the
ship to a UAV bolt-on subsystem, then have the UAV transit to ground station proximity
for wireless transmission of the data to a ground-based subsystem. In order to do this, it is
required that the bolt-on subsystem have sufficient power to transmit the data the
required distance, as well as the UAV have an endurance that supports the entire mission.
The design constraint and platform constraint will have to be considered if the DAD
system progresses through the acquisition life cycle. A second alternative considered was
to utilize a UAV bolt-on subsystem to wirelessly receive data and store to an onboard
hard drive, then RTB for hard drive retrieval. This method would avoid the design
constraint for having sufficient power within the bolt-on subsystem for data transmission.
The third alternative considered was to utilize the UAV as a relay, such that the bolt-on
subsystem would be used as a node, similar to the current data transfer method of using a
satellite. This concept would include the design constraint for transmission power, as well
as limitations on data transfer technologies available to meet the required transmission

distance.

The capstone team used ExtendSim to incorporate aspects of CSSQT scenarios to
be able to analyze operational time outputs that represented variations in human and
system performance. This operational time measurement was compared for each of the
alternatives and showed the influence of the input factors to their respective model

operational time outputs.

B. FINDINGS

This influence, identified through a factorial DOEs, showed the variation of mean
output time by controlling different valued levels of their inputs, as well as identifying
different influential factors for the satellite model versus the three alternative UAV
models. As a final point of data analysis, in the factorial DOE the influence of the human
factor delay showed that, regardless of the delay time, the UAV operational time outputs
showed significant improvements over the satellite model. Table 14 through Table 16
illustrate the percentage improvement of hours for each UAV model against the satellite
model. All sequence columns relate to the factor level sequences in Value Modeling in

Table 13.

Table 14. Percentage Improvement (Time) UAV Relay vs. Satellite Relay

pe a 1446% | 531% 774% | 783% | 803% | 798%
sara a 1605% | 589% phere eee | 892% | 886%
ies 2089% | 767% ree e|ieeeee| 1161% | 1153%
pao cee 1137% | 418% | 608% | 616% | 632% | 628%

Table 15. Percentage Improvement (Time) UAV Receive and Land vs.
Satellite Relay

en a 517% | 232% | 296% | 341% | 332% | 328%
eee 574% | 257% | 328% | 378% | 368% | 364%
a 747% | 335% | 427% | 492% | 480% | 473%
eee 407% 182% | 232% | 268% | 261% | 258%

Table 16. Percentage Improvement (Time) UAV Receive and Transmit vs.
Satellite Relay

grey a 493% | 227% | 287% | 330% | 321% | 314%
ages cag 547% | 252% | 319% | 366% | 357% | 348%
poy a 712% | 328% | 415% | 477% | 464% | 453%
pee ae 387% 178% | 226% | 259% | 253% | 247%

While all UAV alternatives with different input conditions provide significant
improvements in data transfer capabilities by decreasing total operational time, there are
a number of considerations for which options are both feasible and effective for the USN
to consider implementing for future test events. These considerations include the
engineering complexities and justifications listed in Table 13. While the alternative of
using an UAV as a relay yields the shortest operational times, the engineering complexity
with respect to transmit power and UAV loiter time have potential issues that have not
been researched within the scope of this project. The alternative of using a UAV for
receiving and landing yields significant improvements in operational time while the
engineering complexity is low, as the transmit power issues do not exist. The receiving

and landing alternative can permit the use of existing UAV platforms without extensive

research and developmental testing on transmitting power requirements. Additionally, a
business case analysis can show the cost of suitable UAV platforms for this alternative-
which increase when additional power requirements are not considered- the labor costs
for UAV operational personnel and ship-based personnel, and any cybersecurity/
information assurance requirements for successfully conducted the data transfer

scenarios.

As shown in Tables 13 through 16, implementing any of the UAV alternatives
would provide additional benefit with regards to data availability in a CSSQT
application. The capability to provide larger amounts of data with reduced transfer times
is invaluable in an operational environment, as it enables the ISEA to provide a faster
turnaround for system analysis to support system reliability, maintainability, and

availability.

C. RECOMMENDATIONS

There are several opportunities to improve the DAD system concept to close the
data transfer gap and increase availability of data for the USN. For future effort, the
capstone team recommends selecting an alternative from the proposed solutions (relay,
receive and transmit, receive and land, or receive and transmit + land) for continued
development. Selection of an alternative will enable identification of subsystem

requirements, specific design constraints, and detailed design of the DAD system.

The following list provides areas associated with this capstone that require further
research and development, and potentially could serve as a topic for other capstones at

NPS or command Naval Innovate Science and Engineering (NISE) projects:

Application of the DAD system concept for other unmanned vehicle
platforms (unmanned surface vehicle (USV) and/or extra-large unmanned

underwater vehicle (XLUUV))

Application of microwave technology that can meet the range and future

data rate needs of the USN

Integration into ship and/or unmanned vehicle platforms, with special

regards to cybersecurity compliance

Bolt-on subsystem design that fits the design constraints of a majority of

UAV platforms

THIS PAGE INTENTIONALLY LEFT BLANK

APPENDIX: RESEARCH NOT INCLUDED
IN THE LITERATURE REVIEW

Wang proposed a patent to augment wireless communication and satellite
positioning for machines at a worksite including one or more unmanned aerial vehicles
(UAV) configured to be remotely operated above an area encompassing the worksite

(Wang and Rybski 2017).

Li, Zhou and Lamont introduce four communication architectures for networking
UAVs and review some military communication standards applicable to UAV

communications (Li, Lamont, and Zhou 2013).

Howard describes the development of a stand-alone unattended ground sensor
used to process signals or data. The data collected is provided to a digital signal
processing computer and then it’s sent to an UAV. He then states that UAVs make

significant contributions to warfighting capability of operational forces and how they are

The naval studies board conducted a high-level assessment with the goal of
advising the Department of Navy on how to achieve Naval Command and Information
Infrastructure (NCII) functional capabilities. This study defines multiple technical needs
to transition to be a network centric force. The naval studies board explains that being

network centric is a key element in the Navy’s transformation effort (Council 2000).

In the Design for Maintaining Maritime Superiority, Admiral Gilday, defines key
actions on how the United States Navy is going to be trying to grow. He states that the
Navy will be tremendously challenged to match the changing threat landscape in this

period of great power rivalry and rapid technical transition (CNO 2018).

Kuleshov, Zaytseva, and Aksenov also considered using UAV routing algorithms
as an implementation method for autonomous UAV interaction to search for best node
positioning for uninterruptable transmission. The method, which involved an autonomous
network of multiple UAVs, included using Active Data (AD) structure which could alter
the data transmission process by controlling the network node’s hardware. An AD

structure on a repeater UAV network allowed for an extensive transmission distance for

oF)

data transfer between RN nodes and applicable sinks (Kuleshov, A. Zaytseva, and

Aksenov 2018).

Zwerger, Pirker et al., introduced an alternative of quantum repeater for long-
range quantum communication with improved scaling with the distance. The quantum
repeater improved long scale quantum communication that handles channel errors and

losses, as well as operational and memory errors (Zwerger et al. 2018).

In Kam’s thesis, an autopilot guidance and control algorithm were developed
which allowed relay vehicles to reposition themselves autonomously in order to maintain
an optimal loitering flight path. This maximized the quality of the communication link

between the command station and survey vehicle (Kam 2008).

LIST OF REFERENCES

“AAI RQ-2 Pioneer.” 2020. In Wikipedia. https://en.wikipedia.org/w/
index.php?title=AAI_RQ-2_Pioneer&oldid=973496196.

“AAI RQ-7 Shadow.” 2020. In Wikipedia. https://en.wikipedia.org/w/
index.php?title=AAI_RQ-7_Shadow&oldid=985532920.

AcqNotes. 2018a. “Acquisition Process - Engineering & Manufacturing Development
(EMD) Phase.” AcqNotes. May 22, 2018. http://acqnotes.com/acqnote/
acquisitions/emd-phase.

. 2018b. “Analysis of Alternatives (AoA).” AcqNotes. May 22, 2018.
http://acqnotes.com/acqnote/acquisitions/analysis-of-alternatives.

. 2018c. “Acquisition Process Overview.” AcqNotes. May 30, 2018.
http://acqnotes.com/acqnote/acquisitions/acquisition-process-overview.

. 2018d. “Acquisition Phases.” AcqNotes. June 7, 2018. http://acqnotes.com/
acqnote/acquisitions/acquisition-phases.

Blanchard, Benjamin S., and W. J. Fabrycky. 2011. Systems Engineering and Analysis.
5th ed. Prentice Hall International Series in Industrial and Systems Engineering.
Boston: Prentice Hall.

“Boeing Insitu RQ-21 Blackjack.” 2020. In Wikipedia. https://en.wikipedia.org/w/
index.php?title=Boeing_Insitu_RQ-21_Blackjack&oldid=976436485.

“Boeing Insitu ScanEagle.” 2020. In Wikipedia. https://en.wikipedia.org/w/
index.php?title=Boeing_Insitu_ScanEagle&oldid=985322475.

Burdakov, Oleg, Patrick Doherty, Kaj Holmberg, Jonas Kvarnstrom, and Per-Magnus
Olsson. 2009. “Positioning Unmanned Aerial Vehicles as Communication Relays
for Surveillance Tasks.” London, England: SAGE Publications 29 (8): 1069-87.
https://doi.org/10.1177/02783649 10369463.

Commander Naval Sea Systems Command. 2020a. “NSWC Port Hueneme Division.”
Naval Sea Systems Command. May 22, 2020. https://www.navsea.navy.mil/
Home/Warfare-Centers/NSWC-Port-Hueneme/What-We-Do/.

. 2020b. “PEO Ships.” Naval Sea Systems Command. May 22, 2020.
https://www.navsea.navy.mil/Home/Team-Ships/PEO-Ships/.

Defense Acquisition University. 2001. System Engineering Fundamentals. Defense
Acquisition University Press. https://ocw.mit.edu/courses/aeronautics-and-
astronautics/16-885j-aircraft-systems-engineering-fall-2005/readings/
sefguide_0O1_01.pdf.

Defense Technical Information Center. 2012. “Distribution Statements and Their
Corresponding Reasons for Use.” August 23, 2012. https://discover.dtic.mil/wp-
content/uploads/2018/09/distribution_statements_and_reasonsSept2018.pdf.

Department of Defense. 2015. DOD Program Manager’s Guidebook for Integrating the
Cybersecurity Risk Management Framework (RMF) into the System Acquisition
Life cycle Version 1.0. Government Guidebook. Washington, D.C., 20301-3140.
https://www.dau.edu/cop/test/DAU%20S ponsored%20Documents/
PM%20Cybersecurity %20Guidebook%20v 1 %200%20with%20publication%20n
otice.pdf.

. 2019. DOD Digital Modernization Strategy. June 5, 2019.
https://media.defense.gov/2019/Jul/12/2002 156622/-1/-1/1/DOD-DIGITAL-
MODERNIZATION-STRATEGY-2019.PDF.

Duren, Bernard G., and James R. Pollard. 1991. Combat Systems Vision 2030 Combat
System Architecture: Design Principles and Methodology. Fort Belvoir, VA:
Defense Technical Information Center. https://doi.org/10.21236/ADA252668.

Fairley, Dick, Kevin Forsberg, and Ray Madachy. 2020. “System Life Cycle Process
Models: Vee — SEBoK.” SEBoK Guide to the Systems Engineering Body of
Knowledge. May 15, 2020. https://www.sebokwiki.org/wiki/
System_Life_Cycle_Process_Models:_Vee.

Frink, Bentley D. 2005. Unmanned aerial vehicle apparatus, system and method for
retrieving data. United States US6868314B1, filed June 27, 2002, and issued
March 15, 2005. https://patents.google.com/patent/US6868314B I/en.

“General Atomics ALTUS.” 2019. In Wikipedia. https://en.wikipedia.org/w/
index.php ?title=General_Atomics_ALTUS &oldid=932379819.

“General Atomics MQ-1! Predator.” 2020. In Wikipedia. https://en.wikipedia.org/w/
index.php ?title=General_Atomics_MQ-1_Predator&oldid=984 168394.

“General Atomics MQ-9 Reaper.” 2020. In Wikipedia. https://en.wikipedia.org/w/
index.php ?title=General_Atomics_MQ-9_Reaper&oldid=985312163.

Gibbs, Yvonne. 2017. “NASA Dryden Fact Sheet - ALTUS IL” NASA. Brian Dunbar.

August 7, 2017. http://www.nasa.gov/centers/armstrong/news/FactSheets/FS-058-
DFRC.html.

“Griffon Aerospace.” 2020. In Wikipedia. https://en.wikipedia.org/w/
index.php ?title=Griffon_Aerospace&oldid=97769 1076.

Howard, Donald Benton. 1994. Remote sensing, processing and transmission of data for
an unmanned aerial vehicle. Calhoun: The NPS Institutional Archive. June.
Accessed April 2020. https://calhoun.nps.edu/bitstream/handle/10945/28501/
remotesensingproOOhowa.pdf?sequence=1 &isAllowed=y.

INCOSE, and Wiley. 2015a. INCOSE Systems Engineering Handbook: A Guide for
System Life Cycle Processes and Activities. New York, UNITED STATES: John
Wiley & Sons, Incorporated. http://ebookcentral.proquest.com/lib/ebook-nps/
detail.action?docID=4040424.

. 2015b. INCOSE Systems Engineering Handbook: A Guide for System Life Cycle
Processes and Activities. New York, UNITED STATES: John Wiley & Sons,
Incorporated. http://ebookcentral.proquest.com/lib/ebook-nps/
detail.action?docID=4040424.

Insitu Inc. 2017. “RQ-21A Blackjack.” Bingen, WA. https://www.insitu.com/images/
uploads/pdfs/RQ-21 ABlackjack_SubFolder_Digital_DU051217.pdf.

Jackson, Paul, Lindsay T Peacock, and Kenneth Munson. 2003. Jane’s All the World’s
Aircraft, 2003-2004. Coulsdon, Surrey, UK; Alexandria, VA: Jane’s Information
Group.

Jawhar, Imad Hussein, Nader Mohamed, Zouheir Trabelsi, and Jameela Al-Jaroodi. 2016.
Architectures and Strategies for Efficient Communication in Wireless Sensor
Networks Using Unmanned Aerial Vehicles. Unmanned Systems 04 (04): 289—
305. https://doi.org/10.1142/S2301385016500126.

Johansen, Tor A., Artur Zolich, Torkel Hansen, and Asgeir J. Sorensen. 2014.
“Unmanned Aerial Vehicle as Communication Relay for Autonomous
Underwater Vehicle — Field Tests.” In 20/4 IEEE Globecom Workshops (GC
Wkshps), 1469-74. Austin, TX: IEEE. https://doi.org/10.1109/
GLOCOMW.2014.7063641.

Kam, Khim Yee. 2008. “High Bandwidth Communications Links between
Heterogeneous Autonomous Vehicles Using Sensor Network Modeling and
Extremum Control Approaches.” Monterey, California: Naval Postgraduate
School. http://hdl.handle.net/10945/3833.

Kossiakoff, Alexander, ed. 2011. Systems Engineering: Principles and Practice. 2. ed.
Wiley Series in Systems Engineering and Management 67. Hoboken, NJ: Wiley.

Kuleshov, Sergey V., Alexandra A. Zaytseva, and Alexey Y. Aksenov. 2018. “The
Conceptual View of Unmanned Aerial Vehicle Implementation as a Mobile
Communication Node of Active Data Transmission Network.” International
Journal of Intelligent Unmanned Systems 6 (4): 174-83. https://doi.org/10.1108/
IJIUS-04-2018-0010.

Li, Jun, L. Lamont, and Yifang Zhou. 2013. “Communication architectures and protocols
for networking unmanned aerial vehicles.” 20/3 IEEE Globecom Workshops. 7.

Li, Long, Runzhou Zhang, Zhe Zhao, Guodong Xie, Peicheng Liao, Kai Pang, Haoqian
Song et al. 2017. High-Capacity Free-Space Optical Communications Between a
Ground Transmitter and a Ground Receiver via a UAV Using Multiplexing of
Multiple Orbital-Angular-Momentum Beams. Scientific Reports 7 (1): 17427.
https://doi.org/10.1038/s41598-017-17580-y.

Maria, Anu. 1997. Introduction to Modeling and Simulation. Atlanta, Georgia: Winter
Simulation Conference. http://acqnotes.com/Attachments/
White%20Paper% 20Introduction%20to%20Modeling %20and%20Simulation%20
by%20Anu%20Maria.pdf.

Military. 2020. “RQ-2A Pioneer | Military.Com.” Military. 2020.
https://www.military.com/equipment/rq-2a-pioneer.

NASC. 2020. “The NASC TigerShark XP.” Navmar Applied Sciences Corporation.
2020. https://www.nasc.com/nasc-tigershark-xp/.

National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy
for Enhancing Operational Capabilites, Chapter 6: Realizing Naval Command
and Information Infrastructure Capabilities. Washington, D.C.: The National
Academy Press. https://doi.org/10.17226/9864.

Naval Sea Systems Command. 2019. “NAVSEA Campaign Plan to Expand the
Advantage 2.0.” January 2019. https://www.navy.mil/navydata/people/cno/
Richardson/Resource/Design_2.0.pdf.

No Magic, Inc. 2020. “SysML Block Definition Diagram.” 2020.
https://docs.nomagic.com/display/S YSMLP190/
SysML+Block+Definition+Diagram.

Office of the Chief Information Officer. 2000. Department of the Navy (DON) Data
Management and Interoperability (DMI) Strategic Plan. Homeland Security
Digital Library. United States. Department of the Navy. November 1, 2000.
https://www.hsdl.org/?abstract&did=.

. 2020. “Department of the Navy Information Superiority Vision.” February 2020.
https://www.documentcloud.org/documents/678 195 1-DON-Information-
Superiority-2020.html.

Office of the Chief of Naval Operations. 2003. Operational Availbility Handbook.
Department of the Navy. https://www.secnav.navy.mil/doni/Directives/
03000%20Naval%20Operations%20and%20Readiness/03-
00%20General%20Operations %20and %20Readiness %20S upport/3000.12A.pdf.

. 2018. “A design for maintaining maritime superiority.” Department of Navy.
December. Accessed March 2020. https://www.navy.mil/navydata/people/cno/
Richardson/Resource/Design_2.0.pdf.

Office of the Deputy Chief Information Officer. 2020. Architecture Development -
DODAF - DOD Architecture Framework Version 2.02 - DOD Deputy Chief
Information Officer. Chief Information Officer U.S. Department of Defense.
2020. https://dodcio.defense.gov/Library/DOD-Architecture-Framework/
dodaf20_arch_development/.

QinetiQ. 2017. “Vindicator.” https://www.qinetiq.com/en/what-we-do/services-and-
products/vindicator.

QRA Team. 2019. “Functional vs Non-Functional Requirements: The Definitive Guide.”
QRA Corp. September 30, 2019. https://qracorp.com/functional-vs-non-
functional-requirements/.

SysML.org. 2020a. “SysML FAQ: What Is a Package Diagram (PKG)?” SysML.Org.
2020. https://sysml.org/sysml-faq//sysml-faq//sysml-faq/what-is-package-
diagram.html.

. 2020b. “SysML FAQ: What Is a Requirement Diagram (REQ)?” SysML.Org.
2020. https://sysml.org/sysml-faq//sysml-faq//sysml-faq/what-is-requirement-
diagram.html.

. 2020c. “SysML FAQ: What Is a Sequence Diagram (SD)?” SysML.Org. 2020.
https://sysml.org/sysml-faq//sysml-faq//sysml-faq/what-is-sequence-
diagram.html.

. 2020d. “SysML FAQ: What Is a Use Case Diagram (UC)?” SysML.Org. 2020.
https://sysml.org/sysml-faq//sysml-faq//sysml-faq/what-is-use-case-diagram. html.

. 2020e. “SysML FAQ: What Is an Activity Diagram (ACT)?” SysML.Org. 2020.
https://sysml.org/sysml-faq//sysml-faq//sysml-faq/what-is-activity-diagram.html.

The MITRE Corporation. 2013a. “System Architecture.” MITRE. July 18, 2013.
https://www.mitre.org/publications/systems-engineering-guide/se-life cycle-
building-blocks/system-architecture.

. 2013b. “Analyses of Alternatives.” Systems Engineering Guide. August 28,
2013. https://www.mitre.org/publications/systems-engineering-guide/acquisition-
systems-engineering/acquisition-program-planning/performing-analyses-of-
alternatives.

Tierney, Brian, Ezra Kissel, Martin Swany, and Eric Pouyoul. 2012. “Efficient Data
Transfer Protocols for Big Data.” In 20/2 IEEE Sth International Conference on
E-Science, 1-9. Chicago, IL, USA: IEEE. https://doi.org/10.1109/
eScience.2012.6404462.

United States Air Force. 2015a. “MQ-1B Predator.” U.S. Air Force. September 2015.
https://www.af.mil/About-Us/Fact-Sheets/Display/Article/104469/mq-1b-
predator/.

. 2015b. “MQ-9 Reaper.” U.S. Air Force. September 2015. https://www.af.mil/
About-Us/Fact-Sheets/Display/Article/104470/mq-9-reaper/.

United States Chief of Naval Operations. 2018. “A Design for Maintaining Maritime
Superiority, Version 2.0.” December 2018. https://www.navy.mil/navydata/
people/cno/Richardson/Resource/Design_2.0.pdf.

Wang, Qi, and Edmund Rybski. 2017. Augmented Communication and positioning using
unmanned aerial vehicle. United States of America Patent 20170146990A1. May
25.

Wells, Jonathan. 2010. Multi-Gigabit Microwave and Millimeter-Wave Wireless
Communications. Mobile Communication Series. Boston: Artech House.

Whitcomb, Clifford. 2000. “Functional and Physical Decomposition for Ship Design,”
March, 15.

Xiao, Zhenyu, Pengfei Xia, and Xiang-gen Xia. 2016. “Enabling UAV Cellular with
Millimeter-Wave Communication: Potentials and Approaches.” JEEE
Communications Magazine 54 (5): 66-73. https://doi.org/10.1109/
MCOM.2016.7470937.

Yang, Hyun. 2018. “A Cost-Effective Ship Safety Data Transfer in Coastal Areas.”
Journal of Coastal Research 85 (May): 1206—10. https://doi.org/10.2112/SI85-
242.1.

Zwerger, M., A. Pirker, V. Dunjko, H. J. Briegel, and W. Diir. 2018. “Long-Range Big
Quantum-Data Transmission.” Physical Review Letters 120 (3): 030503.
https://doi.org/10.1103/PhysRevLett. 120.030503.

INITIAL DISTRIBUTION LIST

Defense Technical Information Center
Ft. Belvoir, Virginia

Dudley Knox Library

Naval Postgraduate School
Monterey, California

Internet Archive Audio

Featured

Top

Images

Featured

Top

Software

Featured

Top

Books

Featured

Top

Video

Featured

Top

Mobile Apps

Browser Extensions

Archive-It Subscription

Save Page Now

Full text of "INCREASING FLEET DATA TRANSFER CAPABILITIES USING AN UNMANNED AERIAL VEHICLE (UAV)"

See other formats