Embed Size (px)
Citation preview
0MB No. 0704-0188I REPORT DOCUMENTATION PAGE Form Approved
Standard Form 298 (Rev. 8-98)Prescribed by ANSI-Std Z39-18
Public reporting burden for this collection of information is estimated to average 1 hour per response , including the time for reviewing instructions, searching 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 Service, Directorate for Information Operations and Reports,1215 Jefferson Davis Highway, Suite 1204, Arlin gton, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188) Washington, DC 20503.PLEASE DO NOT RETURN YOUR FORM TO THE ABOVE ADDRESS.1. REPORT DATE (DD-MM- YYYY) 12. REPORT TYPE
29-05-2020 Master's Thesis13. DATES COVERED (From - To)
4. TITLE AND SUBTITLE
Automated Decision Making for Operations within a Traffic Separation Scheme Using MOOS-lvP
Sa. CONTRACT NUMBER
Sb. GRANT NUMBER
Sc. PROGRAM ELEMENT NUMBER
6. AUTHOR(S)
Barker, Jason, B, LT5d. PROJECT NUMBER
Se. TASK NUMBER
Sf. WORK UNIT NUMBER
7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATIONREPORT NUMBER
9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES)Civilian Institutions Office (Code 522) Nava l Postgraduate School 1
1 0. SPONSOR/MONITOR'S ACRONYM(S)
NPS CIVINS
1 University Circle, Herrmann Hall Rm HE046Monterey, CA 93943-5033
11. SPONSORING/MONITORINGAGENCY REPORT NUMBER
12. DISTRIBUTION AVAILABILITY STATEMENT
Approved for public release; distribution is unli mited
13. SUPPLEMENTARY NOTES
14. ABSTRACTThis thes is proposes a set of practical applications that utili zes the sharing of in tent information a nd intende d courses between marin e vehicles operating in the vicinity of a Traffic Separation Scheme in order to reduce risk of collision for vehicle s with intentions to join in accordance with Rule 10 of the COLREGs. The proposed set of applications also creates a method to digitally represent a Traffic Separation Scheme in MOOS-IvP simulation software usin g a structure modeled after Title 33 of the Code of Federal Regulations. Two types of Traffic Separation Scheme intents are communicated: traffic lane compliance , in which the vessel in the traffic lane is withi n the lane and on a compliant vesse l heading in accordance with Rule 10.b, and comp li ant lane approach/traffic crossing, in whi ch vehicle s wit h lane crossin g intent or intent to enter are on a compliant heading in accordance with Rule I 0. c. Incorporating in ter-vehi cle commu nicatio ns to share intended co urses allows for discre te extrapolation of future positions, determination of risk conditions, and ultimately arecomme ndation for an early speed maneuver to reduce risk conditions. Comm un icatio ns between shore and vehicle are also used to allow the veh ic le to populate a Traffic Separatio n Scheme instance onboard whic h will enable future flexibility and minimize pre-loading of data for harbor operations. Si mu lation expe riments demonstrate the feasibility of the proposed Rule 10 method in terms of both vehicle safety and proper traffic lane operation.
15. SUBJECT TERMS
unmanned marine vehicles, traffic separation scheme, marine autonomy
16. SECURIT
IY CLASSIFICAT
I ION OF:
17. LIMITATION OFABSTRACT
uu
18. NUMBEROF PAGES
99
19a. NAME OF RESPONSIBLE PERSON
a. REPORT b. ABS ACT c. THIS AGE
u19b. TELEPONE NUMBER (Include area code)
INSTRUCTIONS FOR COMPLETING SF 298NPS CIVINS PROGRAM STUDENTS
1. REPORT DATE. Enter your graduation date in format DD-MM-YYYY. Include at least year and month and use xx if there is no day of the month, e.g. xx-06-2019 or 15- 12-2020
2. REPORT TYPE. Enter the type of document you are submitting, e.g. Master's Thesis or Capstone Project
3. DATES COVERED. Leave blank
4. TITLE. Enter the title and subtitle (if appropriate) of your thesis
5. CONTRACT NUMBER. Leave blank
Sb. GRANT NUMBER. Leave blank
Sc. PROGRAM ELEMENT NUMBER.Leave blank
5d. PROJECT NUMBER. Leave blank
Se. TASK NUMBER. Leave blank
Sf. WORK UNIT NUMBER. Leave blank
6. AUTHOR(S). Enter your name and rank as: last name, first name, middle initial, and additional qualifiers separated by commas, e.g. Smith, Richard, J, Jr., LT or Smith, Robert, ENS
7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES). Leave blank
8. PERFORMING ORGANIZATION REPORT NUMBER. Leave blank
9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES). Pre-filled
10. SPONSOR/MONITOR'S ACRONYM(S). Pre-filled
11. SPONSOR/MONITOR'S REPORT NUMBER(S). Leave blank
12. DISTRIBUTION/AVAILABILITY STATEMENT. Pre-filled
13. SUPPLEMENTARY NOTES.Leave blank
14. ABSTRACT. Enter a brief (approximately 200 words) factual summary of the most significant information.
15. SUBJECT TERMS. Enter key words or phrases identifying major concepts in the report, e.g. management, personnel management, Africa, conflict
16a.SECURITY CLASSIFICATION OF:REPORT. Pre-Filled
16b.SECURITY CLASSIFICATION OF:ABSTRACT. Pre-Filled
16c.SECURITY CLASSIFICATION OF:THIS PAGE. Pre-Filled
17. LIMITATION OF ABSTRACT.Pre filled
18. NUMBER OF PAGES. Enter the number of pages in the PDF file you are submitting
19. NAME OF RESPONSIBLE PERSON.Leave blank
20. TELEPHONE NUMBER. Leave blank
STANDARD FORM 298 Back (Rev. 8/98)
Automated Decision Making for Operations within a Traffic Separation Scheme Using MOOS-IvP
by
Jason Barker
B.S., The Citadel (2012)
Submitted to the Depa rt ment of Mechanical Engineering in partial fulfillment of the requirements for the degrees of
Naval Engineer
and
Master of Science in Mechanical Engin eerin g
at the
MASSACHUSETTS INSTITUTE OF TECHNOLOGY
May 2020
@Massachusetts Inst it ute of Technology 2020. All rights reserved.DISTRIBUTION A. Approved for public release; distribution unlimited.
Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Depart ment of Mechanical EngineeringMay 14, 2020
Certified by . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Michael R. Benjamin Principal Research Scientist
Depart ment of :tvfe cha nical EngineeringThesis Supervisor
Accepted by . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Nicolas Hadjiconstantinou
Chairman, Depart ment Committee on Graduate Theses
Automated Decision Making for Operations within a Traffic
Separation Scheme Using MOOS-IvP
by
Jason Barker
Submitted to the Department of Mechanical Engineering on May 14, 2020, in part ial fulfillment of the
requirements for the degrees ofNaval Engineer
andMaster of Science in Mechanical Engineering
AbstractThis thesis proposes a set of practical applications that ut ilizes the sharing of
intent information and int ended courses between marine vehicles operating in the vicinity of a Traffic Separation Scheme in order to reduce risk of collision for vehicles with intentions to join in accordance with Rule 10 of the COLREGs. The proposed set of applications also creates a met hod to digitally represent a Traffic Separa t ion Scheme in MOOS-IvP simulation software using a structure modeled after Title 33 of the Code of Federal Regulations. Two types of Traffic Separation Scheme intents are communicated: traffic lane compliance, in which the vessel in the traffic lane is within the lane and on a compliant vessel heading in accordance with Rule 10.b, and compliant lane approach / t raffic crossing, in which vehicles with lane crossing intent or intent to enter are on a compliant heading in accordance with Rule 10.c. Incor porating int er-vehicle communicat ions to share int ended courses allows for discrete ext rapolation of fut ure positions, determinat ion of risk conditions, and ultimat ely a recommendation for an early speed maneuver to reduce risk conditions. Communica tions between shore and vehicle are also used to allow the vehicle to populate a Traffic Separation Scheme insta nce onboard which will enable fut ure flexibilit y and minimize pre-loading of data for harbor operations. Simulation experiments demonstrate the feasibility of the proposed Rule 10 method in terms of both vehicle safety and proper traffic lan e operation.
Thesis Supervisor: Michael R. Benjamin Title: Principal Research Scientist Depart ment of Mechanical Engineering
3
5
Acknowledgments
I am forever grateful to all of the people in my life, my friends, my family, my
peers, and my mentors, who have supported me, guided me, inspired me, and joined
me in this long roller coaster journey. Words cannot fully express how much each of
you played a part. No great thing is done alone, and this document could not have
been written without the help I received from all of you.
To Mike Benjamin, thank you for all of your help and constant encouragement to
do things that seemed impossible for me. I came to MIT with very limited coding
experience and my journey culminated in one of the most exciting classes that I could
have ever imagined possible. I have enjoyed many experiences on campus but your
class will always stand out.
To my fellow 2N students that I had to privilege to share time with, what a bond
we have. Through all the study sessions, trivia nights, and social events, this was by
far some of the best officers I could hope to meet . I wish you all good fortunes in the
future and appreciate that I had the help of such wonderful people.
To my parents Eucharist and Charles, I want you to know that this work is a
product of the hard work and perseverance you instilled in me. I will never stop
pushing the boundaries of my understanding, increasing my level of knowledge, or
questioning the assumptions - just like you taught me to.
To my children Winter, Tela Jordan, Celeste, and Jason II, know that even when
I am away on deployment or pre-occupied with work, that I always think of you.
All of you are my only inspirations and motivations to succeed. I do not know what
occupation destiny had for my life, but I know that being your father has been the
only calling I ever wanted to be good at. I hope that I can motivate and inspire you
the same way that each of you do for me. I am so proud of all you.
To my lovely wife Brynn, thank you. Every husband and every wife could de
scribe how they have the most "pick your favorite adjective" spouse. I could do the
same but I choose to celebrate how lucky and fortunate I was to find such a partner
and side-kick. I could not have done so many things without your support, your en-
6
couragement, and your love. All the good times we have shared are so important to
me; equally important to me are the hard times, frustrations, and failures we shared
together that have forged our strong relationship. Even though you may never read
this document or understand the contents within, I want you to know that your input
was all over this. I know the completion of this work can not make up for all that
you have sacrificed for me, but I can think of no other person that I want to share
this victory with than you. Thank you so very much and I Love You.
7
For Brynn,
Winter, Tela Jordan,
Celeste, and Jason II
9
Contents
1 Introduction 21
1.1 Motivation for Study of Traffic Separation Schemes 22
1.2 Problem Statement ..... 23
1. Nautical Rules of the Road . 25
1.4 Literature Review . . . . . . 27
1.4.1 Fuzzy Logic Usage for Collision Avoidance in Vessel Traffic Service 29
1.4.2 Evolutionary Sets of Safe Ship Trajectories within Traffic Sep-
aration Schemes . . . 30
1.5 Contributions of this Work . 33
1.6 Scope and Assumptions 33
1.7 Objectives and Approach . 34
2 Vessel Traffic Services and Traffic Separation Schemes 35
2.1 Code of Federal Regulations 35
2.2 Vessel Traffic Services ... 36
2.3 Traffic Separation Schemes 36
3 Implementing the Traffic Separation Scheme Scenario in MOOS-IvP 43
3.1 Launching the Baseline TSS Scenario . . . . . 43
3.2 Traffic Separation Schemes in C+ + Language 47
3.3 Creating Traffic Lanes inside the TSS Scenario . 49
3.4 Sharing Destination Information . . . . . . . . . 50
3.5 Sharing Traffic Separation Scheme Compliance . 52
1
3.6 Speed Recommendation for the Joining Vehicle 53
3.6.1 Determination of Intersections ..... . 53
3.6.2 Extrapolation of Discrete Points for Contacts 55
3.6.3 Final Speed Recommendation ........ . 59
4Analysis of the Traffic Separation Scheme Scenario 65
4.1 Grading Criteria ..... 66
4.2 Evaluation of the Scenario 67
4.2.1 Definition of the Null Hypothesis and Critical Values 67
4.2.2 Scoring the Scenario ...... . 68
4.2.3 Statistical Analysis of the Results 70
5 Conclusions 75
5.1 Limitations of Study . . . . . . . . . . 75
5.2 Recommended Areas for Further Study 76
5.2.1 Digital Representation of Traffic Lanes 76
5.2.2 Injection of Historical AIS Data . . . 77
5.2.3 Behaviors for Traffic Lane Operation 77
5.3 Final Conclusions . . . . . . . 78
A Marine Autonomy Landscape 79
A.1 Commercial Landscape 81
A.2 Military Landscape 82
A.3 Technology . . . . 82
A.4 Current As-Is Architecture - U.S. Navy 84
A.4.1 Ecosystem and Stakeholders 84
A.4.2 Strategy . . 85
A.4.3 Information 86
A.4.4 Infrastructure 87
A.4.5 Products and Services 87
1
A.4.6 Process, Organization, Knowledge . 88
1
B Results of TSS Scenario Experiments 89
Bibliography 97
1
List of Figures
1-1 A TSS scenario between Charlie and Dana in which Dana int ends to
join the TSS........................................................................................................24
1-2 Illustration of t he current st at e of risk collision analysis tools for t he
problem st at ement scenario..............................................................................25
1-3 A TSS scenario between Charli e, Dan a, and Echo, in which Dana
intends to join the TSS . . . . . . . . . . 26
1-4 Traffic Separation Scheme - General Idea 27
1-5 Nav igat ional Area of t he Single Bend Divid ed into Sections to deter-
mine fuzzy events [8 ] . . . . . . . . . . . . 29
1-6 Mod elling of t he Fuzzy Guarding Rings [9] 30
1-7 Mod elling of Evolut ionary Algorit hms . . . 31
1-8 ESoSST Method with Speed Reduction Flowchart [28] 32
2-1 NOAA Chart 18440 . . . . . . . . . . . . . . . . . . 38
2-2 NOAA Chart 18440 highlight ing a Separation Zone 40
2-3 NOAA Chart 18440 highlighting Precaut ionary Area "SC" 40
2-4 NOAA Chart 18440 highlight ing the Nor thbound Transit Lane Bound-
ary Line . . . . . . . . . . . . . . 41
3-1 TSS Scenario - Baseline Scenario 45
3-2 TSS Scenario - Overa rchin g Archit ect ure 45
3-3 TSS Scenario Appli cat ion Interaction Map for Tra ffic Separation Scheme
Generat ion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3-4 TSS Scenario App licat ion Interaction Map for Speed Reduction 48
1
3-5 pTrafficPopulate AppCasting [13] Screenshot 51
3-6 Intersecting Lin es - Generic Case . . . . . . 55
3-7 Intersecting Lines - Case with a Terminal Endpoint on the Other Line 56
3-8 Intersecting Lines - Case with Similar Terminal Endpoints by Both Lines 57 3-
9 pSegListintercept AppCasting [1 3 ] Screenshot Verifying Calculations 57
3-10 pSegListi ntercept AppCasting [13] Screenshot Showing Speed Recom-
mendat ion ....................... . 63
4-1 TSS Scenario Average Scores versus Contact Density 70
A-1 IDEF Mod e O Model of Marine Autonomy . . . . . . . . . . . . 81
A-2 Global Output of Autonomous Maritime Pat ents, 1970-2016 [12] 83
A-3 Output of Autonomous Maritime Pat ents for China, the United Stat es,
and the Rest of the World, 2000-2016 [12] 83
A-4 ARIES Element Mode l [1 8 ] . . . . . . . . . 84
1
List of Tables
3.1 Initial Conditions for MOOS-IvP TSS Scenario 46
3.2 Resultant Intersection Points of the TSS Scenario 55
4.1 Critical Values for Hypothesis Testing ............ . 684.2 TSS Scenario Baseline Results for One Vehicle Permutations 724.3 TSS Scenario Results for One Vehicle Permutations with Speed Ad-
justment Recommendations . . . . . . . . . . . 734.4 Test Statistic Calculations for the TSS Scenario 74
B.1 Two Vehicle (min) Permutations without Speed Recommendation 90
B.2 Three Vehicle (min) Permutations without Speed Recommendation 91
B.3 Four/ Five Vehicle (min) Permutations without Speed Recommendation 92
B.4 Two Vehicle (min) Permutations with Speed Recommendation . 93
B.5 Three Vehicle (min) Permutations with Speed Recommendation 94
B.6 Four/ Five Vehicle (min) Permutations with Speed Recommendation 95
1
Listings
3.1 Example Separation Zone (*.tss file) in C+ + language for the TSS
Scenario ............... . 47
3.2 Example Precautionary Area (*.tss file) in C+ + language for the TSS
Scenario............................................................................................................... 48
3.3 Example Traffic Lane Boundary Line (*.tss file) in C+ + language for
the TSS Scenario................................................................................................49
3.4 Function predict_point() and pointCalculate() from the SegListCon-
tact class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.5 Function predictSpeed() inside the pSegListintercept application 59
1
Commonly Used Abbreviations
AI Artificial Intelligence
AIS Automatic Identification System
ARIES Architecting Innovative Enterprise Strategy
ARPA Automatic Radar Plotting Aid
CFR Code of Federal Regulations
COLREGs Regulations for Collisions at Sea 1972 (International and Inland)
CONOPs Concept of Operations
COTS Commercial-Off-The-Shelf
DoD Department of Defense
ESoSST Evolutionary Sets of Safe Ship Trajectories
ITZ Inshore Traffic Zone
Iv P Interval Programming
MOOS Mission Oriented Operating Suite
MOOSDB Mission Oriented Operating Suite - Database
NOAA Nat iona l Oceanic and Atmospheric Administration
ROE Rules of Engagement
ROV Remotely Operated Vehicle
TSS Traffic Separation Scheme
UAV Unmanned Aeria l Vehicle
USCG Un it ed States Coast Guard
1
USV Unmanned Surface Vehicle
UUV Unmanned Underwater Vehicle
VTS Vessel Traffic Service
2
Chapter 1
Introduction
"The mark of a great ship handler
is never getting into a sit uat ion
requiring great ship handling"
Admiral Ernest King
COMINCH and CNO
dnring World War II
Admiral King's quote provides great insight into the motivation behind this study.
The US Navy possesses highly trained personnel operating on extremely modern
and technically advanced vessels around the world. T he navy also pairs modern
navigational tools and training techniques to improve the skill and decision making
of ship officers. Also operating in the marin e domain, the marine autonomy industry
continues to grow in both military and non-military applications. Advances in marine
autonomy controls, decision making , and algorithms continue to produce increasingly
reliable autonomous vehicles that are compliant with the Internat ional Regulat ions
for Preventing Collisions at Sea (COLREGs) [12, 2, 10]. Acknowledging that there
are competent officers and top level autonomous systems, Admiral King suggests a
simple but probing question: How do we avoid driving into poor situations?
Route pre-planning is not a new concept and is used in multiple domains all t he
time. Prior to a road trip, your typical driver will analyze the entire route and make
2
assumptions about destination arrivals. Using that int uition, a driver may leave early
or leave late to minimize poor traffic conditions in a congested city. P ilots operating
in conjunction with Air Traffic Control, control arrival and depart ure of flights along
predeter mined routes to minimize contact density of airplanes and congestion on the
tarmac at airports. In the marine domain, vessels will plan underway and return times
to coincide with favorable tide conditions. Both manned and unma nned systems find
value in looking over the horizon or into the fut ure for predict ive means. This thesis is
motivated to build in predictive powers that reduce contact density and reduce poor
situations before they occur in the approach to Traffic Separa tion Schemes (TSS) -
access routes into and out of US port s. If these poor situations occur, we must rely
on experienced supervisors or complex autonomy to resolve challenging situations. In
the marine domain, this is not a new problem but it is growing in complexity with the
integration of unmanned vehicles. Integration and cooperation between unmanned
and human-operated vehicles requires communicat ion and validat ion of intent ions
between both vessels that ensure both vehicles adhere to the rules of the nautical road,
resolve risk of collision situations in a predictable mann er, and approach increasingly
complicated situations in a prudent and cautious manner - which promotes the safety
of all vehicles [7].
1.1 Motivation for Study of Traffic Separation Schemes
To any mariner, the COLREGs are the foundational document for safe naut ical
operations. It has many rules, guidelines, examples, and exempt ions that guide the
ship officer in making nautical decisions that are in keeping with the expectat ions
of other marin ers. As technology advances and more tools become available, the de
cision space around the ship and crew change. Advances in radar technology and
automat ic radar plotting aid (ARPA) tools have increased the tactical awareness of
the crew. As a ship officer makes varied decisions about the maneuvering of a vessel
into a traffic sepa ration scheme, it is prudent to try to und erstand the constraints,
destinat ions, and operability of the other vessels that are around. In the human-
2
only domain, such intentions are communicated in a multitude of ways and, in most
cases, a combination of methods. Such methods include deliberate ship maneuvers,
voice-to-voice communications, using the ship's whistle, communications to and
from a vessel traffic service (VTS), and proper usage of automatic identification
system (AIS). Vessels within a TSS have well regulated transit lanes which can
create more predictable travel patterns. Acceptable maneuvers and patterns are
regulated under Rule 10 of the COLREGs and create additional layers of constraints
that can be used to further refine ship officer decisions. This is of particular interest
when the traffic lanes have well-defined turns and waypoints. In most situations, it is
prudent to never assume that another vessel will behave in a certain manner.
Therefore, in a TSS, ship officers will monitor a situation with expectations of other
mariners but not assumptions. This study conducts an exploration to unlock
capabilities that occur when future maneuvers are communicated and utilized for
contact avoidance.
1.2 Problem Statement
Consider the scenario in Figure 1-1. In this scenario, vehicle Charlie is a vessel
adhering to a TSS and will continue to do so in accordance with Rule 10 and the
regulations of the TSS until it exits. The expected actions for Charlie are to maintain
compliant courses in the traffic sepa ration lane unless an extremis sit uat ion requires
evasive maneuvers for collision avoidance. Vehicle Dana is a vessel not currently
in a TSS but has a planned track to join. Dana has specific Rule 10 requirements
for entry into a TSS and should seek to minimize interactions and avoid projecting
confusing intentions with Charlie. Using current algorithms, Dana and Charlie would
not consider either a risk of collision until both vessels were on a single leg crossing
situation (Figure 1-2). Dana would not proceed to process a collision avoidance or
speed maneuver until Charlie conducted its waypoint turn and was on the crossing
leg. This is because current algorithms do not assume contact maneuvers. In this
situation, the maneuver decisions by Dana would be to (a) continue as the stand-on
2
Figure 1-1: A TSS scenario between Charlie and Dana in which Dana intends to join the TSS. In this scenario, both Dana and Charlie have a multi-leg approach to a potential crossing situation. Current algorit hms and assumptions prevent Dana from determining risk of collision with Charlie while Dana is on its current leg. Currently, this situation requires a Dana ship officer to conduct a dead reckoning ana lysis of Charlie and apply intuition to determine where both vessels will be in the future. Often this is on the intercept leg or on the leg prior to intercept. Additionally, COLREGs-compliant collision avoidance algorithms would incorrectly determine that Dana was the st and -on vessel and would incorrectly advise Charlie to maneuver to starboard and potentially exit the TSS.
vessel or (b) maneuver in extremis if Charlie fails to maneuver. Both decisions by
Dana communicate confusing intent to vehicle Charlie while Charlie is in operating
in a traffic separa t ion scheme.
Consider the same scenario but with an additional vehicle in the other lane. In
this new scenario, the potential interaction (Figure 1-3) occurs in which Dana crosses
both Charlie and Echo. Depending on the time of intercept, this maneuver might be
ahead of both Charlie and Echo. Current COLREGs-compliant collision avoidance
algorithms would tell Dana to maintain course and speed due to its position on the
starboard side of Charlie and expect Charlie to conduct a compliant maneuver to
avoid collision. Additionally, Dana would be expected to maneuver to starboard for
Echo. Both assumptions would be incorrect for Dana with an intended track that
joins the TSS. In this scenario, a speed maneuver determined by Dana at an earlier
decision point improves the outcome of the scenario and minimizes contact density
2
Figure 1-2: Illustration of the current state of risk collision analysis tools provided onboard marine vessels for the problem statement scenario. Ownship vessels assume contacts maintain current course and speed until an observed change. Advances in voyage management systems provide extrapolation with ownship (Dana) multi-leg maneuvers but will maintain the contact (Charlie) course and speed. Analysis tools will not account for the existence of traffic lanes or land and will predict risk of collision and danger rings on land.
at the point of intersection.
When this same scenario occurs on manned vessels, current ARPA tools and other
navigational aids do not account for target vessel maneuvers and use the assumption
that targets maintain current course and speed. These scenarios require ship officer
experience and intuition to evaluate expectations of target vessels and render all the
onboard electronic aids less than ideal during the interaction time. This problem is
further complicated by the proximity to the traffic lanes at the time of critical decision
making when such speed - and potentially course - maneuvers would be required.
1.3 Nautical Rules of the Road
The following COLREGs rules are for all vessels in sight of one another and apply
during open ocean operations [7, 27]:
• Rule 13 - Overtaking: 'any vessel overtaking any other shall keep out of the
way of the vessel being overtaken'
2
Figure 1-3: Problem statement scenario with Dana seeking to join the TSS and negotiating entrance with Charlie and Echo contacts in opposite directions. In this scenario, Dana should determine a requisite speed to create a safe distance from both vehicles while crossing the path of Charlie and potentially crossing in front (or behind) of Echo. As traffic density in both lanes increase, it becomes more challenging to determine a speed that minimizes contact density at the point of intersection.
• Rule 14 - Head-On Situation: 'when two power-driven vessels are meeting on
reciprocal or nearly reciprocal courses so as to involve risk of collision each shall
alter her course to starboard so that each shall pass on the port side of the
other'
• Rule 15 - Crossing Situation: 'when two power-driven vessels are crossing so as
to involve risk of collision, the vessel which has the other on her own starboard
side shall keep out of the way ("give way") and shall, if the circumstances of
the case admit, avoid crossing ahead of the other vessel'
• Rule 16 - Actions for a Give Way Vessel: 'take early and substantial action to
keep well clear'
• Rule 17 - Actions for the Stand-On Vessel: 'may take action to avoid collision
if it becomes clear that the give-way vessel is not taking appropriate action'
Ships operating within a traffic separation scheme are in accordance with COL REGs
Rule 10. A typical TSS is illust ra ted below in Figure 1-4. Behaviors of partic ular
interest to autonomous vehicles are cited in the following [7]:
• Rule 10.a - 'this rule applies to traffic separation schemes and does not relieve
2
any vessel of her obligation under any other rule'
• Rule 10.b - 'a vessel using a traffic separation scheme shall:
- proceed in the appropriate t raffic lane in the general direction of traffic
flow for that lane
- so far as pract icable keep clear of a traffic separation line or separation
zone
- normally join or leave a traffic lane at the termination of the lane, but
when joining or leaving from either side shall do so at as small an angle to
the general direction of traffic flow as practicable'
• Rule 10.c - 'a vessel shall, so far as practicable, avoid crossing traffic lanes but if
obliged to do so shall cross on a heading as nearly as practicable at right angles
to the general direction of traffic flow'
Figure 1-4: Traffic Separation Scheme - General Idea
1.4 Literature Review
In previous works [10, 2], mult i-ob jective optimization was used to demonstrate
safe COLREGs-compliant collision avoidance in open ocean scenarios in which
inten tions of the autonomous vessel are relayed by delibera te ship maneuvers that
2
serve
2
to communicate understanding of the relevant COLREGs Rules 13-17 and compli
ance with required actions. This study looks at Rule 10 of the COLREGs that has
not been previously examined for autonomous vehicles. In the marine domain, Rule
10 discusses the changes in operations that occur within traffic separation schemes
(TSS). Vessels within a TSS have well-regulated transit lanes which can create more
predictable travel patterns. Additionally, there are hazards to navigation such as prox
imity to land, required waypoint turns, requirements on entry and exit, and proximity
to vessels such as ferries that cross traffic schemes that require different maneuvers
than those observed in open ocean. As stated before, autonomous vehicles would ex
ecute open ocean collision avoidance maneuvers with both course and speed maneu
vers to prevent risk of collision using current COLREGs-compliant collision avoidance
algorithms. Such maneuvers in a TSS or in the inshore traffic zone (ITZ) would com
municate improper intentions to human-operated vessels where speed maneuvers are
more prevalent and different course decisions would be expected. Conversely, vehicles
operating in the TSS under similar algorithms might execute maneuvers that would
exit the TSS due to stand-on and give-way assumptions. In specific scenarios, such
as ferry crossings, the COLREGs would require the ship give way for other ships on
their starboard side. Typically, ferries normally give way for all traffic or delay their
departure to create an opening to transit across traffic flow. In other scenarios, ship
officers of through traffic conduct speed maneuvers to facilitate creating the opening
for ferries. These behaviors have no documented support in COLREGs and may
cause misunderstanding between human operators and autonomous vehicles without
addressing the change in environment [23]. AIS was implemented to prevent this mis
understanding by transmitting destinations between manned vessels. The usage of
inter-vehicle communication in this study proposes that transmitting intended routes
between vehicles allows for calculation of vehicle trajectories and collision avoidance
maneuvers in place of assumptions of st an d-on/ give-way vessel maneuvers.
3
1.4.1 Fuzzy Logic Usage for Collision Avoidance in Vessel
Traf fic Service
Fuzzy logic mathematics is way to represent vague, sparse, and imprecise infor
mation in mathematical models. Fuzzy logic has been used to quantify dangerous
situations by coupling collision probabilities derived from simulated data and field
studies of navigational collisions, groundings, and accidents with fuzzy logic prob
ability sets. Fuzzy probability sets were used to capture unfavorable navigational
situations and distances in which accidents had a probability of occurring but may
not have and the incident went unregistered. Studies utilized the fuzzy logic method
to quantify ships maneuvering around bends in waterways such as in Figure 1-5. In
the scenario, grounding probabilities and distances to the extremes of t he waterways
were analyzed to determine fuzzy events. Fuzzy logic method was later applied to
Figure 1-5: Navigational Area of the Single Bend Divided into Sections to determine fuzzy events [8]
vessels operating in a vessel traffic service that has navigational constraints and, in
some cases, traffic separation schemes. Fuzzy logic coupled probabilistic collision risk
with the generation of guarding rings around vessels. The contribution of this ap
plication was used to provide an alert monitoring system for VTS monitoring and
decision making to predict potential collisions. In this method, a fuzzy system used
AIS dynamic data (such as ship size and speed) along with static information like sea
state to calculate the range of the guarding ring and the value of the clanger index
[0,1]. Additionally, fuzzy logic was applied to critical collision scenarios covered by
3
Rule 17.a.ii of the COLREGS in which the give way vessel fails to take appropriate
actions and the stand on vessel is required to make ext remis maneuvers to avoid col
lision. The method then calculated collision encounters using vessel velocit y, turning
rate, turning direction, and a desired passing distance as variables [[8 ], [9], [22]] .
(a) The radial axis of two guarding rings (b) Typical architecture of a fuzzy system
Figure 1-6: Modelling of the Fuzzy Guarding Rings [9]
In this thesis, the process of determining probabilistic collision risk is replaced with
the generation of sets of extrapolation points and coupling that to guarding rings.
This study determines collision risk using contact waypoints, contact speed, ownship
waypoints, and stand-off distance as variables to determine a safe ownship speed to
reduce collision risk using the applicat ion pSegListlntercept in Chapter 3.
1.4.2 Evolutionary Sets of Safe Ship Trajectories within Traf fic
Separation Schemes
While fuzzy logic was used to quantify potential collisions, other studies focused on
determining safe trajectories to avoid collision. An early approach was to use evolu
tionary algorit hms and fuzzy logic probability to determine ownship t ra ject ories [24].
Lat er approaches by Szlapczynski focused on combining portions of game theory with
evolutionary algorithms called evolutionary sets of safe ship tra jector ies (ESoSST).
The multi-ship scenario treated each ship as a differential game in which each par ticipant
possessed their own strategy for success. Early evolutionary algorithms then searched
through permutations of possible solutions to obtain global optim izat ions against a
fitness function. Gam e theory scenarios would predict target maneuvers and
3
calculate own ship trajectory as the input solution . Evolutionary algorithms would
generate a coupled set of optimized trajectories that worked all ships involved in an
encounter while avoiding collisions. The application of this method was for VTS mon
itoring and on-board collision avoidance systems . This was computationally powerful
but required targets to maintain course and speed or new ownship trajectories would
need to be recalculated. Later the author utilized advances in evolutionary algorithms
by use of evolutionary operators that enhanced results and allowed removal of target
maneuver constraints [25, 26]. Similar to genetic algorithms, the inclusion of special
ized operators sped up the evolutionary process while generating a diverse
population and a vast space of solutions to search. This could now account for
vessels maneu vering in restricted waters in which maintaining course and speed was
impractical or resulted in grounding or navigationally unsafe conditions.
(a) Evolutionary Algorithm - General [26] (b) Evolut ionary Algorithm - ESoSST [27]
Figure 1-7: Modelling of Evolutionary Algorithms
In 2013, Szlapczyriski noted that the TSS problem had not been investigated
thoroughly and added additional Rule 10 operators [27]. These operators were used
to detect TSS violations and penalize the fitness function accordingly. Violations
were categorized into three groups:
• Inshore Traffic Zone Violations (region between nearby coastal shore and traffic
lane)
• Violations of the Separation Zone (regulated space between traffic lanes)
• Violations of the Traffic Lan e
3
Assumed to be a 10° difference between the ship's heading and the lane's
direction for transiting through
Assumed to be a 10° difference from the lane perpendicular for vessels
crossing the lane
- Assumed to be a 20° difference at the lane ent ra nce/ exit and ship's heading
More recently, Szlapczy riski added a new decision element for operating within a traf fic
separation scheme which optimized against speed reduction maneuvers illust ra ted in
the flowchart in Figure 1-8 [28]. He noted that within a TSS, there are shorter distances
between vessels in which course alterations may be insufficient alone, large man euvers
may be the imp roper signal to other ship operators, and there is a re duction in the
detection time for ship maneuvers. This result ed in a new set of ship trajectories that
also accounted for a speed reduction to avoid collision.
This thesis int ends to ut ilize the operators of TSS violations - specifically the vehicle
Figure 1-8: ESoSST Method with Speed Reduction Flowchart [28]
course while t ransiting through and crossing traffic la nes - to allow vehicles iden tify
their stat us and compliance wit h Rule 10. This defin ition is then turned into a message
passed by int er-vehicle communications for classifying TSS conta cts by the
3
application pTSSCompliance.
1.5 Contributions of this Work
Applications of the algorithms presented could also be applied to current human
navigation voyage management aids and ARPA tools or for use in a stand alone
decision aid to better inform ship officers during traffic separation operations. This
work presents new algorit hms and applications to the COLREGSs-compliant library
that can further enable autonomous vessels to operate in closer inland waters where
the current state of practice is to have manual or remote operations in waters close
to the pier and then transition to full autonomy in open ocean. This thesis seeks
to understand the complexity in generating and communicating traffic separation
schemes to vehicles and creating an instance on board using using Mission Oriented
Operating Suite - Interval Programming (MOOS-IvP) software. Applications and
behaviors are presented for modeling the Traffic Separation Scenario in the MOOS
IvP autonomy software in order to demonstrate predictive solutions and generate
experiment al results.
1.6 Scope and Assumptions
The scope of this thesis focuses on the collision avoidanc e speed maneuver from
a vehicle seeking to join a TSS and assumes that vessels operating in the traffic lane
will execute motions in accordance with waypoints and speeds passed during vehicle
communications. Because waypoints are shared, a maneuver intent ion trajectory es
timation is used with discrete trajectories [11] to determine discrete intercept points
and determine time horizon of interc ept ion. Additionally, intent can be derived from
adherence to traffic lanes and communication of destination. The proposed algo
rithms assume intent inform at ion is obtained through inter-vehicle communications
with unlimited range and without faulty communications.
3
1. 7 Objectives and Approach
The objective of this thesis is to build a multi-leg predictive analysis tool that
recommends safe speed to minimize contact density for vehicles joining a traffic sep
aration scheme. Additionally, this thesis intends to create a method to generate a
traffic separation scheme onboard a vessel via message passing vice pre-loading har
bor coord inates. There is no known work to elate on unmanned systems to generate
COLREGs-compliant collision avoidance specifica lly for Rule 10. This thesis proposes
algorithms for over-the-horizon speed prediction that minimizes collision risk based
on the intent and adherence to traffic separation schemes by nearby contacts coupled
with COLREGs Rule 10 constraints . The thesis has the following approach:
• Provide background information about vessel traffic services and traffic sepa ra
tion schemes
• Development of structures and algorithms to digitally recreate a traffic sepa ra
tion scheme on a shoresicle application based on Title 33 CFR
• Development of a method to pass traffic separation scheme messages to vehicles
and generate scheme onboard for close inland water usage
• Development of a Traffic Separation Scheme scenario and identification of method
to pass compliance intent between vessels
• Develop a baseline non-compliant scenario as a basis for comparison
• Develop an algorithm to predict traffic density, points of interest, and safe speed
for a vessel enter ing/ exiting the traffic scheme
• Evaluation of the proposed collision avoidance applicat ions through simulat ions
using sepa ration distance between vehicles as a metric for success
3
Chapter 2
Vessel Traffic Services and Traffic
Separation Schemes
2.1 Code of Federal Regulations
The rules, regulat ions, definitions, and governing authorities for vessel traffic ser
vices and traffic separation schemes are outlined in the Code of Federal Regulations,
Title 33 - Navigat ion and Nav igable Waters (33 CFR) [4] [5]. T he CFR is a collection
of governing laws, divided into 50 broad sub ject titles, upd at ed annually, and pub
lished in the Federal Register by various agencies of the federal government. Federal
depart ment s responsible for Title 33 includ e:
• Chapter l: United Stat es Coast Guard (USCG) / Depart ment of Homeland
Security
• Chapter 2: Army Corps of E ngineers / Depart ment of the Army, DoD
• Chapter 4: St. Lawrence Seaway Development Corporation / Depart ment of
Tra nsport at ion
33 CFR Chapter 1, Subchapter P - Ports and Waterways Safety - cont ains the im
plementation of the regulat ions identified in the Ports and Waterways Safety Act
of 1972. This act authorizes the USCG to create vessel traffic services and traffic
separation schemes for ports, harbo rs, and other wat ers under the jurisdiction of the
United Stat es that are sub jected to congested vessel traffic [29].
3
2.2 Vessel Traffic Services
Vessel Traffic Services and Vessel Movement Reporting Systems (VMRS) are de
fined in Subcha pter P: Part 161 of T it le 33. Per 161.l(a), this service is provided
to "enhance navigation, vessel safety, marine environmental protection, and promote
safe vessel movements 11 [5]. A VTS provides safe, efficient marin e vessel traffic and
collision prevention by collecting, coordinating, and disseminating traffic information
and continuous monitoring and management of vessel traffic. There are 12 service
centers designat ed in the United St at es as defined in Part 161.12 and regulat ed by the
USCG, but the operations of each center are not standard. Geographical constraints,
geographical location, traffic density conditions, and regional legislation means that
each VTS provides a similar service but potentially accomplished in a different way.
According to the Puget Sound VTC User's Manual (2019) [33], management consists
of monitoring, informing, recommending, and directing (on rare occasions and height
ened security). In contrast, the New York VTS User's Manual (2019) [32] a lso states
that it manag es traffic by informing, monitoring, and recommending, but explicit ly
states that it II does not direct the maneuvering of a vessel11 •
T itle 33 still maintains that the overall responsibility for ship safety remains with
the ship's officer but VTS may inform and issue directions to vessels to minimize
risk of collision and supervise movements within a VTS area. Mu ch of the research
discussed in Section 1.4 into VTS and TSS creates a solution or tool for use by a
VTS center to create a global set of solutions for traffic insid e a TSS and coordinate
traffic patterns to minimize risk.
2.3 Traffic Separation Schemes
Traffic Separation Schemes, defined in 33 CFR Part 167 Subpart A are established
to provide access routes into and out of US ports by the means of separating opposing
streams of traffic [5]. Vessels operating insid e of a TSS operate in accordance with
Rule 10 of the COLREGs. There are specific inst ances of two-way traffic but a typical
3
TSS is primarily composed of separated one way schemes with the following objects:
• One way traffic lanes - typically defined by a set of coordinates that establishes
the boundary between the traffic lane and the inshore traffic zones
• Separation zones or lines - a set of coordinates which are used to provide sepa
ration and distinction between the opposing traffic lanes
• Precautionary Areas - a set of coordinates or a provided coordinate and associ
at ed radius used as a routing tool that identifies areas in which ship officers must
navigate with precaution usually due to branching, joining , or exiting traffic or
exp ect ed course maneuvers
33 CFR Part 167 Subpart B contains the geographical coordinate descript ion of all
the traffic separation schemes in the US as referenced using the North American 1927
Datum (unless specifically stated otherwise). An example TSS (Figure 2-1) , such as
Puget Sound and its approaches: Puget Sound (33 CFR 167.1323) is provided as a
collection of six separation zones and two traffic lanes connected by six precautionary
areas. An excerpt from the Puget Sound TSS list of the items is are provided below [5]:
(a) A separation zone bounded by a line connecting the following geographical po
sitions (lett ers provided for reference in Figure 2-2):
(A)
(B)
(C)
(D)
(E)
(F)
(b) Precautionary area IISC" which is contained within a circle of radius 0.62 miles,
centered at 48°01.85' N, 122°38.15'W (see Figure 2-3).
(m) A traffic lane for northbound traffic that connects with precaut ionary areas
Lat it ude Longit ude
48°11.0S'N 122 °46.88'W
48°06.85' N 122 °39.52'W
48°02.48'N 122 °38.1TW
48°02.43'N 122 °38.52'W
48°06.72' N 122 °39.83'W
48°10.82' N 122 °46.98'W
3
Figure 2-1: NOAA Chart 18440 displaying the Traffic Separation Schemes for the Puget Sound Region. This type of chart is a freely-available chart expected to be carried by ship navigators onboard.
4
"SC", "SE", "SF", "SG", "T", and "TC" as described in paragraphs (b), (d),
(f), (h), (j), and (k) of this section, respectively, and is located between the
separation zones described in paragraphs (a), (c), (e), (g), (i), and (k) of this
section, respectively, and a line connecting the following geographical positions
(see Figure 2-4):
Latitude Longitude
48°11.72'N 122 °46.83'W
48°07.13' N 122 °38.83'W
48°02.lO' N 122 °37.32'W
47°58.23'N 122 °34.07'W
47°55.83'N 122 °28.S0'W
47°45.92'N 122 °25.33'W
47°39.68' N 122 °26.95'W
47°34.65' N 122 °26.l S'W
47°27.13 ' N 122 °23.40'W
47°23.33' N 122 °20.37'W
47°22.67' N 122 °20.53'W
47°19.07' N 122 °26.75'W
4
Figure 2-2: NOAA Chart 18440 Separation Zone. Letters on the chart correspond to the coordinates in 33 CFR 167.1323.a for a separation zone in the Puget Sound TSS. The separation zone is highlighted in red.
Figure 2-3: NOAA Chart 18440 Precautionary Area. The highlighted region corre sponds with details specified in 33 CFR 167.1323.b for a precautionary area in the Puget Sound TSS identified as II SC 11
•
4
Figure 2-4: NOAA Chart 18440 illustrating the line that connects the coordinates in 33 CFR 167.1323.m. and bounding the northbound transit lane.
4
Chapter 3
Implementing the Traffic Separation
Scheme Scenario in MOOS-IvP
In order to evaluate the response of vehicles operating in a TSS, a baseline
scenario was established in MOOS-IvP. MOOS-IvP utilizes message passing between
processes and applications within a publish-subscribe architecture similar to Robot
Operating System (ROS) or Micro Air Vehicle Link (MAVLink). This architecture
has a star like topology (Figure 3-2) in which each participant in the scenario runs a
stand-alone collection of of MOOS applicat ions called a community. Applications and
processes within a MOOS community publish and subscribe to variable-value pairs
stored within the community Mission Oriented Operating Suite - Database (MOOSDB)
[16, 15, 17]. MOOS -IvP applications have been used primarily- but not exclusively - in
the marine domain. The TSS scenario begins with a vehicle operating outside the
traffic lane in the ITZ with a planned track to cross the inbound lane and use the
outbound lane for transit.
3.1 Launching the Baseline TSS Scenario
The baseline scenario is the simulation scenario without additional applications
and behaviors to alter simple waypoint following behaviors. It can be viewed by the
user via a GUI application called pMarineViewer and is launched from the command
$ ./launch.sh --in=2 --out=3 5
4
line. It has TSS traffic lane vehicles st art ing in the inbound (red) and outbound
(green) lanes that operate in accordance with Rule 10 and transit accordingly. There
are two separate command line arguments in the launch script that allow the user to
increase the number of simulated traffic vessels in the inbound and outbound lanes
individually. Additionally there is a time warp argument at the end that allows a
mission to be sped up. Starting positions within the lane polygons and vessel speeds
are picked at ra ndom.
The sc enario has a joining vehicle begin in a st art area outs ide of t he lanes with
intentions to cross the inbound lane and join t he outbound lane t raffic. The baseline
scenario without arguments is a three vehicle int eract ion between a joining vehicle
and two transiting vessels (one in each lane), similar to the geometry seen in Figure 3-
1.
T he TSS Scenario creates a MOOS-IvP community called shoresid e t hat serves
as the simul ate d harbor traffic or VTS system in place to monitor marine traffic. A
second community called 11,sv is created for the joining vehicle with subsequent
com munit ies generated for the t raffic lane vessels. Each community runs a MOOSDB
applicat ion that allows dist inct applications in that community to communicate by
mapping variable names to values for use wit hin that community. T he architecture of
the MOOS-IvP scenario is illust ra ted in Figure 3-2 which shows t he distribution of a p
plicat ions between the various communities. Figure 3-3 shows a high level interaction
of the a pplicat ions within the scenario specifically around the digital representation
of the traffic sepa ration scheme. Figure 3-4 shows a high level int era ction of the a p
plicat ions used for speed recommendations.
4
Figure 3-1: TSS Scenario - Baseline Scenario. This scenario is similar to the problem statement scenario in Chapter 1. In the TSS scenario, USV is joining the TSS by crossing the pat hs of Abe (in the inbound lane) and Fin (in the outbound lane) and transiting in the outbound lane.
Figure 3-2: TSS Scenario - Overarching Archit ecture
4
The TSS Scenario utilizes the following applications generated by the author with
init ial conditions summarized in Table 3.1:
1. Shoreside applications
• pTrafficPopulate - application for defining and generating a traffic sep
aration scheme and generating messages for vehicle use to create traffic
separation schemes locally
• pTrafficGrade - application for producing an overall grade for the sce
nario based solely on the number of encounters for usv with other vehicles
within user defined ranges
2. Vehicle applications
• pSegPassing - application for sharing intended waypoints to other vehi
cles
• pTSSCompliance - application for sharing compliance with Rule 10.b
and 10.c of the COLREGs to other vehicles
• pSegListlntercept (joining vehicle only) - applicat ion for determining
contact intersections, calculating interaction times of interest, and ulti
mately recommending a speed maneuver for the joining vessel that mini
mizes contact density at intersection points
TSS Scenario Initial ConditionsVehicle Type Vehicle Name Vehicle Waypoints
(x,y coords)Vehicle Speed
(m / s)Joining usv 10,-180: 110,-100: 70,-60 2.5
Inbound (up to a max of 5)
abe, ben, cal, deb, and / or eve
random starting position for eachvehicle inside upper polygon:
(150,60: 30,-60: 50,-60: 170,60)followed by waypoints :
40,-60: 160,-180: 160,-300
random speedfor each vehicle
in therange 1:4
Outbound (up to a max of 5)
fin, gil, hal, ike, and / or jim
random starting position for eachvehicle inside lower polygon:
(180,-180: 180,-320: 200,-320: 200,-180)followed by waypoints:190,-180: 70,-60: 190,60
random speedfor each vehicle
in therange 1:4
Table 3.1: Initial Conditions for MOOS -IvP TSS Scenario
4
Figure 3-3: TSS Scenario Application Interaction Map for Traffic Separation Scheme Generation. This expansion of Figure 3-2 shows which variables each application publishes (blue) and subscribes to (green) within the TSS Scenario with regards to the digital representation of the traffic separation scheme created in this study.
3.2 Traffic Separation Schemes in c++ Language
In the scenario, a series of user generated *.tss files are called. In order to repli
cate the structure in 33 CF R, each .t ss file corresponds to a specific object inside a
traffic separation scheme. As the scenario reads each file, it creates an object called a
Traffi.cObject and adds each to a vector of objects that populate a Traffi.cScheme
object. Similar to the example TSS in Section 2.3, each object is described in C+ +
Language for introduction into shapes recognizeable to MOOS-IvP simulation soft
ware. For simplicity in programming, the TSS Scenario uses local coordinates in the
X,Y plane vice lat it ude and longitudinal coordinates; however, lat it ude and longitu
dinal reference is possible. Separation Zones (Listing 3.1) and Precautionary Areas
(Listing 3.2) are described with a constraint that the provided polygon must be given
as a convex input:
4
Figure 3-4: TSS Scenario Application Interaction Map for Speed Reduction. This expansion of Figure 3-2 shows which variables each application publishes (blue) and subscribes to (green) within the TSS Scenario with regards to the speed recommenda tion that is generated within this study. This picture specifically shows the interaction between usv and abe. In the TSS Scenario, only the joining vehicle (u,sv ) uses the pSegListintercept applicat ion.
1
2
3
4
Listing 3.1: Example Separation Zone (*.tss file) in C+ + language for the TSS
Scenario
1 //==============================================
2 type precaution area
3 poly polygon
4 points x=55, y=-60, radius=25
,, label SC
Listing 3.2: Example Precautionary Area (*,tss file) in C+ + language for the TSS
Scenario
A traffic lane (Listing 3.3) is described with the classifier "seglist" and requires ori
entation as identified by starting X,Y coordinates that are explicit in the provided
//==============================================
type separation zone
poly polygon
points 170,60: 50,-60: 60, -60: 180,60
//==============================================
type poly pointsstart
inbound laneseglist
150,60 30, -60 150, -180: 150, -350
x=150, y=-350
4
seglist:
1
2
3
4
5
Listing 3.3: Example Traffic Lane Boundary Line (*.tss file) in C+ + language for the
TSS Scenario
Once traffic sepa ration scheme information is transferred to digital form, there are
several things that can be done with it such as generating visual aids for end user
GUI app lications and status determination by vehicles. A subsequent function was
written in the TrafficScheme class to combine traffic lane boundary lines with pro
vided separation zone polygons to produce multiple convex polygons that
collectively represent the various one way traffic lanes. Based on the number of
coordinates pro vided in the seglist boundary line, a requisit e number of quadrilaterals
is determined and formed by combining sequent ial seglist coordinate pairs with the
closest adjacent separation zone polygon points for each. Visual classification and
representation as inbound (red) and outbound (green) is given by the .tss "type" and
follows the USCG "Red, Right, Returning" convention in the U.S Aids to Navigation
System. This con vention describes how returning vessels maintain reel markers on
the starboard side of the vessel [31].
3.3 Creating Traffic Lanes inside the TSS Scenario
In the scenario, shoreside uses an app lication called pTrafficPopulate to generate
and publish the multiple convex polygons that comprise the inbound and outbound
lanes. This application publishes two variables: TSS_LANES and TSS_SEP _ ZO NES .
T SS_ SEP _ ZO NES is a sem i-colon separated string of colon separated points and
TSS _ LANES is a semi-colon separated string of seglist specifications. The concate-
5
nation of separation zone polygons and boundary seglists onboard the vehicle creates
a local traffic separation scheme instance (Fig ure 3-5). Future versions of pTraf
ficPopulate would also pass precautionary areas and navigational hazards as other
variables that could be published for vehicle use.
TSS _SEP_ ZONES = pts={ l 70,-180:170,350:18,0-180};pts ={50, -60:170,-180:180,-180:60,-60}...
TSS_ LANE = pts={ 200,-350;200,-180:80,-60:200,60}, label = out bound;pts= ....
The practice of transmitting TSS data to vessels is currently atypical in the ma
rine domain. TSS lanes are well-defined on freely-available National Oceanic and
Atmospheric Administration (NOAA) charts, described in 33 CFR, or already est ab
lished on an approved Navigator's chart pack. In the autonomous marine domain,
it would be impractical to pre-load all possible polygons for all possible ports and
harbors prior to launch. The process of publishing transit lanes, in general, allows
vessels to dynamically register to any traffic system for the most up-to-dat e traffic
lanes and, for autonomous vehicles, this would allow for emerge ncy port calls. As
more vessels transition away from paper charts to electronic charts, a case could be
made for a similar process in the manned marine domain to ensure electronic voyage
management systems and navigational aids are always operating on the most current
information. Additionally, the transmission of polygons in this manner could also be
used to broadcast navigational hazards, anchorage zones, and other areas of caution
that could be used to dynamically change pre-plann ed routes for unmann ed vehicles
the same way that a Notice to Mariners is used by ship officers [34].
3.4 Sharing Destination Information
In the marine domain, vessels use AIS messages to pass voyage information be
tween vessels and for collision avoidance onboard. AIS transmits dynamic information
(such as lat it ude, longit ude, course, and speed) every two seconds and static infor
mation (such as ship's name, destination, length, beam, and draught) every six min-
5
Figure 3-5: pTrafficPopulate AppCasting [13] Screenshot. This screenshot shows sta tus information for the pTrafficPopulate applicat ion. In this screenshot, five polygons (two precautionary area circles and three separa tion zones) and two seglists are passed into the traffic scheme object as *.tss files. Given the length of the boundary line seglists (four points each), this application creates an additional six (6) traffic lane polygons (three for each seglist). Total class size for this traffic separation scheme object is eleven (11) objects. This class also assigns polygon visual properties like fill colors and edge sizes.
utes [19]. In MOOS-IvP, this information is simu lat ed with the inter-vehicle message
NODE_REPORT but lacks the destination information. In the TSS scenario, a vehi cle
to vehicle message is generated by the pSegPassing application called SEGLIST that
passes the intended waypoints to augment the node report and fully simulate the
passing of AIS destination information.
SEGLIST = vname=dana;pts ={70,-30:40,-60:160,-180:160,-300}
The joining vehicle in the TSS scenario subcribes to SEGLIST and NODE _ REP ORT,
parses both messages, and creates a vector of contacts for future calculat ions in the
pSegListlntercept applicat ion. To enable the pSegPassing application, adjust-
5
ments of the existing MOOS-IvP library waypoint behavior BHV _ WAYPOINT were
requir ed to have vehicles publish their individual waypoint seglist.
3.5 Sharing Traffic Separation Scheme Compliance
The application pTSSCompliance produces a string message that constantly
updates the status of the vehicle compliance - or lack thereof - with COLREGs Rule
10.b and 10.c. This thesis uses two traffic separation scheme violation criteria from
the ESoSSTs study [27] in Section 1.4 to determine compliance. This study evaluates
ent ra nce of the vehicle to the traffic separation scheme at locations other than the
terminal ends and does not evaluate the compliance at the terminal ends. The two
criteria modelled in this application:
1. A 10° difference between the ship's heading and the lane's direction for transit
ing through
2. A 10° difference from the lan e perpendicular for vessels crossing the lane
This application publishes a variable called TSS _STATUS that outputs a message
describing the status of observing proper TSS headings and the current action of the
vehicle within the TSS Scenario. One of the first checks is the initial determinat ion of
whether the current position of the vessel is located within the published traffic lanes
and if the vehicle heading corresponds with the first criteria. A subsequent check
determines if the current location of the vehicle is within the published separation
zones. A final check looks for vehicles that are currently outside of the traffic lane
and searches through the intended path to determine if the vehicle intends to cross a
lane. This check determines if the approaching vessel heading is near perpendicular
to the lane in accordance with the second criteria. All other vehicles are classified as
"Non-Compliant / Non-Part icipant ". Examples of the st ring message:
TSS_STATUS = vname= u:-w, :,tat u:,= compliant , act ion = tra n:,it ing properly
TSS_ STATUS - vname- abe, stat us- compliant , a ction- approaching the lane properly
TSS _ STATUS = vname= fin , stat us= non-compliant/ non-participant
5
3.6 Speed Recommendation for the Joining Vehicle
The application pSegListlntercept determines contact intersections, calculates
intera ction t imes of interest , and recommends a speed maneuver for the joining vessel
that minimizes contact density at points of intersect. Using the seglist inform at ion
provided from each vehicle from pSe gPassing , the joining vehicle, 11,sv, is able to
compare incoming seglist with the ownship seglist to determine if there are any in
tersection points. Additionally, node reports posted from each vehicle are read for
assoc iat ed speed information. This application then populates a Cont act SegList
object wit h contact name, speed, and seglist for each contact. A vector of these
objects populate a ContactSegListSet object.
3.6.1 Determination of Intersections
This thesis uses the Faster Line Segment Calculation method described by Franklin
Antonio [1] to determine if seglists intersect. This method evaluates two variables a
and fJ using the x,y coordinates from the endpoints of two potential inte rsecting lines
(Figure 3-6) against three test criteria . This application searches through ownship
seglist and a contact seglist to conduct the following calculat ions for each leg of both:
(3.1)
where:
Ax,y = (x, y)2 - (x, y)i
Bx,y = (x, y)3 - (x, y)4
Cx,y = (x,Y)1 - ( x ,Yh
f=J (Ax* Cy) - (Ay * Cx) (Ay * Bx) - (Ax* By)
(3.2)
5
This method has the following three checks:
1. Ensure the denominator (Ay * Bx ) - (Ax* By) is not zero. If the denominat or
is zero, the two segments are colinear.
2. Both a and (3 must have the same sign
3. Both a and (3 must be on the interval [0,1]
If all three are satisfied, then the line segments intersect. If it is determ ined that an
intersect ion occurred, the equation to determine the actual intersection point P(x,y)
is given by t he following:
Px,y = ( x , y)i +a* (( x , y)2 - ( x , y)i) (3.3)
The Faster Lin e Segm ent Inters ectio n met hod is effective for determining when
line segments int ersect but is not effective in scenarios in which one line segment
terminates on the other such as in Figure 3-7. This geometry situation is equally
import ant in the vehicle domain. This part icular geometry is present in the TSS
Scenario where usv has a line segment that terminates on any outbound vehicle
line segment before joining t he outbound lane. Franklin 's calculation misses this
import ant intersection point. An ad ditional check was added to determine instances
in which a line segment terminat es on the other and adds the result ant coordinates
to the vector of calculated intersection points. One of the limitations of this study
is that the inclusion of this second check results in a duplication of answers when
the intersection point is the terminal end for both line segments (Figure 3-8). Future
versions implementing this process would look to eliminate duplicate answers.
In the TSS Scenario, starting position and starting speed are randomized to the
vehicles in the traffic lane but they share the same waypoints. Each vessel is ide al
ized with a heading down the center of each lane polygon. This provides the added
ability of being able to verify proper calculation of int ersection points shown in the
pSegListlntercept application in Figure 3-9 with Table 3.2.
5
Figure 3-6: Intersecting Lines - Generic Case. The Faster Line Segment Intersection calculation by Franklin [1] is robust to this case. In this case, the two line segments intersect completely.
Ownship Seglist Contact Seglist Resultant
Intersection Points
10,-180: 110,-100: 70,-60 rand start, 40,-60: 160,-180: 160,-300 93.33, -113.333
10,-180: 110,-100: 70,-60 rand start ,190,-18 0: 70,-60: 190,60 110.00,-100.00
70, -60
Table 3.2: Resultant Intersection Points of the TSS Scenario. As discussed earlier, the resultant answer is the intersection point with the inbound vehicle, the outbound vehicle, and the shared waypoint (70, -60) of usv and the outbound vehicle.
3.6.2 Extrapolation of Discrete Points for Contacts
Now that intersection points are generated for the joining vessel, usv, a quick
algorit hm calculates the length of usv 's seglist to each of the int ersection points along
the seglist. Combined with usv's speed, a time until intersection is determined. Once
armed with time, an extrapolation of scenario contacts can be calculated. Since each
object in the ContactSegList class has a contact speed and a vector of seglists, a
time on each seglist by the contact can be determined. An algorit hm was generated
which takes an input variable of time (from usv ) , determines the appropriate seglist
in the Contact SegList , and calculates an associated point along the contact seglist
5
Figure 3-7: Intersecting Lines - Case with a Terminal Endpoint on the Other Line. This is the geometry in which the Faster Line Segment Intersection calculation fails to generate an intersection point. This study added a subsequent check for these points because they are points of interest to this study.
that corresponds to that time at the contact speed (Listing 3.4). This function is a
simple displacement calculation given by the following:
x1 = x0 + (cos(heading)* velocity* time)
Y1 = Yo + (sin(heading) *velocity* time)
(3.4)
(3.5)
where:
x0 , y0 = The beginning x,y coordinate for the relevant contact leg
x1 , y1 = The final x,y contact coordinate based on the amount of time on the leg
velocity = Contact velocity
time = Time of interest. This is the time that u,sv reaches the intersection point
This application assumes that contacts are travelling on the associated heading for
future legs and assumes that speed remains constant. Additionally, no adjustments
are made for turning radius or turning speeds in the calculation of time or associated
extrapolation points in the future.
5
Figure 3-8: Intersecting Lines - Case with Similar Terminal Endpoints by Both Lines. This geometry produces duplicate answers in this study because both checks find this answer. In the TSS Scenario, this means that usv and all the outbound vehicles should show duplicate answers at their shared waypoints throughout.
Figure 3-9: pSegListintercept AppCasting [13] Screenshot Verifying Calculations. This TSS Scenario run contains usv as the joining vehicle. Inbound contacts are abe and ben. Outbound contacts are fin and gil. This screenshot captures a verification of the calculations of intersection points from Table 3.2. In this scenario, shared way points with usu are captured by both met hods of calculat ion and produces duplicate answers (70,-60) as discussed in Figure 3-8.
5
1 XYPoint m_locate;
2 //-----------------------------------------------------------------
3 //Procedure: predict_point
4 void SegListContact:: predict _ point( double time)
5 {
6 if( m _ got _ spd){
1 for ( int i=O; i<m_leg_seglist.size(); i++){
8 double time_remain = O;
o double heading= O;
10 if(time <= m_time_leg [OJ){
11 time_remain = time;
12 m_locate. set_label ( 11 vname = 11 +m vname + 11 ;
heading doubleToString(m_leg_heading[OJ));
13 heading= m_leg_heading[OJ;
II +
14 pointCalculate(m_leg_seglist [OJ , heading, time_remain);
15 m_got_predict = true ;
16 return ;
17 }
1s else if ((time <= m_time_leg [i]) && (time > m_time_leg [i-1])){
rn time_remain = time - m_time_leg[i-1J;
2()
21
m_locate. set_label( 11 vn ame = 11 +m_vname + 11 ;
heading
doubleToString(m_leg_heading[iJ));
heading= m_leg_heading[iJ;
II +
22 pointCalculate(m_leg_seglist[iJ, heading, time_remain);
23 m_got_predict = true ;
24 ret urn;
25 }
26 }
27 }
28 }
w 1/-----------------------------------------------------------------
w //Procedure: pointCalculate
31 void SegListContact::pointCalculate(XYSegList seglist, double
heading, double time_remaining)
32 {
33 double xi seglist .get _ vx( O) ;
double double double doubledouble
y1 = seglist.get_vy(O);hdgconvert = angle180(90 - heading);
radhdg
xy
xi+
degToRadians(hdgconvert);((cos(radhdg))* m_nav_spd * time_remaining);
y1 + ((sin(radhdg))* m_nav_spd * time_remaining);
m_locate.set_vertex(x,y);
}
void SegListlntercept::predictSpeed(){
double speed_guessif( m _ extra _ready){
m_input_speed;
for ( double s=m_min_speed; s<=m_max_speed; s=s+m_rate_of_change){
5
M
35
36
37
38
Tu
40
Listing 3.4: Function predict_point() and pointCalculate() from the SegList Cont act
class
3.6.3 Final Speed Recommendation
Given the discussed init ial conditions, a speed recommen dat ion is given to the
joining vehicle inside the pSegListlntercept applicat ion. At this point, the process
has produced two key pieces of information: the int ersection point and the associ ated
contact points for that int ersection. This application allows the user to define a
guarding ring range to maintain contacts outside of. The goal is to determine the
number of extrapolated contact points that occur inside of this guarding ring at each
of the intersection points. A final algorithm was written to search through a range
of speeds and return a speed that coincides with the least amount of limiting con t
act s (contacts within the guarding ring range). The following function predictSpeed()
(Listing 3.5) occurs insid e the pSegListlntercept application. This function gen
erates a WPT _ UPDATE message to the existing waypoint following behavior that
adjusts the speed of the joinin g vehicle. The speed recommendation is based on find ing
the speed associated with the global minimum number of limiting contacts inside the
user-defined guarding ring at all of the calculated int ersection points. An example status
of this application is shown below in Figure 3-10.
1
2
3
4
5
6
6 //This for loop sets the speed guess between a min and max range.
7 // A range [1, 3.5] was chosen to prevent a high speed or slow speed
8 //solution that creates a trivial scenario
g //NOTE: Recommended to NOT have a min_speed of zero
10
11 speed_guess = s;
12 vector <double >
m_length; vector <double >
m_time;
14
15 //Step 1: For each of the contact seglists, determine all the
16II intercept points (get_px and get _ py) .
Once you have
17 II18IIl[l II20II
the intercept points, determine the time of interest
for the joining vehicle until the intercept point.
The function biteSegList returns the remaining seglist
from the beginning until the intercept point for the
21 II22 II
first argument seglist .
joining vehicle (ownship)
In this case, the
23
for ( int l=O; l<m_os_intercept.size(); l++){
25 XYSegList remaining= biteSegList(m_os_seglist, m_os_intercept
.get_px(l), m_os_intercept.get_py(l));
26 double length= remaining.length();
21 m _ length . push _ back( length) ;
28 double time = length/speed_guess;
29 m_time.push_back(time);
30 }
31
32 //Step 2:
33 II34 II35II36II37II38II39II
40II
6
For
each of
the
interes
t times
(vector
<double
>m_time
),
extrapo
late
points
for all
the
contact
s
populat
ed
in ContactSeglistSet (m_tss_contacts).
For each contact, the SegListContact function
.extrapolate_point(time) searches through
each
leg
(contact
legs
each
have a
max time
on leg
based
on
contact
speed as part of the ContactSegList object), finds the
leg of interest, calculates a remaining time on leg,
and then calculates a x,y
6
41II42II43II44II
position.
Additionally, this loop calculates the distance
from the extrapolated point to the associated
intercept point.
45
vector<string> m_extrapo_contacts;
47 vector <double > m_extrapo_dists;
48
40 for ( int i=O; i<m_time.size() i++){
w XYPoint ownship;
51 ownship . set _ vertex( m _ os _ intercept .get _ px( i) ,
m_os_intercept. get_py(i));
52 for( int j=O; j<m_tss_contacts.size(); j++){
53 SegListContact curr_contact = m_tss_contacts.get_contact(j);
54 XYPoint guess_point = curr_contact.extrapolate_point(m_time[
i]);
55 string guess_info = guess_point.get_spec();
5G m_extrapo_contacts.push_back(guess_info);
57 double guess_dist = distPointToPoint(ownship, guess_point);
58 m_extrapo_dists.push_back(guess_dist);
59 }
60 }
61
62 //Step 3:
63 II64 II
Based on the near miss range (nm_range),
a guard ring is calculated (m_range_concern)
and all contact distances inside this guard
65 II66 II
ring are
contacts
collected as a vector of
(vector<string>m_limit_contacts)
67
M vector<string> m_limit_contacts;
® vector <double > m_limit_dist;
70
11 for ( int i=O; i<m_extrapo_dists.size(); i++){
12 if(m_extrapo_dists[i] <= m_range_concern){
73 m_limit_dist.push_back(m_extrapo_dists[i]);
74 m _ limit _ cont acts . push _ back( m _ extr apo _ contacts[ i]) ;
6
n, }
76 }
77
78 //Step 4a: Two cases remain.
79 II If there are no limiting contacts,
80 II the recommended speed is the initial speed
81 II set by (m_input_speed).
82 if( m _ 1 imit _ c on tacts .size() = = 0)
83 m_current_spd_recommend = speed_guess;
84
85 //Step4b: The other case.
86 II If there are limiting contacts at this
87 II speed, set the resolved limiting contacts count to
88 II the current vector size. This has the effect
89 II of returning the speed that results in the
90 // case with the least amount of limiting contacts
91 // for the speed range in the for loop.
92 else if( m _l imit _ contacts .siz e() != O){
93 if( m _l imit _ contacts .siz e() <= m_spd_rec_resolved_count){
94 m_current_spd_recommend = speed_guess
9fi m_spd_rec_resolved_count = m_limit_contacts.size();
96 }
97 }
98 II This final part looks at both cases and gives a
99 II recommended speed update as either the input speed
100 II or the new calculated speed (speed_guess)
101 }
102
103
104
105
106
107
108
m_final_speed = doubleToString(m_current_spd_recommend);
string speed_recommendation = 11 speed = 11 + doubleToString(
m_current_spd_recommend);
Not ify( 11 WPT _UPD ATE 11 , speed_recommendation);
}
}
Listing 3.5: Function predictSpeed() inside the pSegListintercept application
6
Figure 3-10: pSegList intercept AppC ast ing [13] Screenshot Showing Speed Recom mendation. This screenshot capt ures the total number of intercept points, the number of ext rapolat ed points (which should be the number of intercept points times the num ber of contacts), the initial and final number of limiting contacts, the initial speed of the scenario, and the final recommended speed. In this scenario, it was determined that speeding up to 3.5 m/ s resulted in the least amount of limiting contacts.
6
Chapter 4
Analysis of the Traffic Separation
Scheme Scenario
The primary ob ject ive in the TSS Scenario is to minimize contact density for
the joining vehicle at the points in which it crosses or enters the traffic separation
scheme with a speed recommendation. The algorit hm for speed recommendation is
constrained on the low end such that the speed recommendation is not so slow that
all the contacts pass without meaningful int eract ion. This recommendation is also
constrained on the high end to prevent the joining vessel from shooting t hrough the
scenario. These constraints were set to avoid a solution consisting of a speed recom
mendat ion that is t rivial or unrealist ic. As such, the speed recommended represents
the selection of a speed that minimizes the number of limit ing contacts and does
not eliminate them completely (i.e. coming to a stop until all vehicles pass would
eliminate limiting cont acts) . Minimiz ing contact density should also minimize vehicle
encount ers and collisions. The shores ide community uses the application pTraffic
Grade and the exist ing applicat ion uFldCollisionDetect [14] to grade the TSS
Scenario. The uFldCollisionDetect application uses the NODE _ REP ORT from
each vehicle to locate them and analyze encounte rs between them. The user sets
some specific parameters:
• near miss range - encounters within this range are considered near misses
• collision range - encounters within this range are considered collisions
6
The only constraint to the application is that near miss range is larger than collision
range. The uFldCollisionDetect app publishes the variable
COLLISION_DETECT_PARAMS which transmits the user settings to the MOOSDB
and the variable UCD _ REPORT which is a generated report that occurs for each
encounter. The pSegListlntercept app uses the near miss range for setting the
guarding ring range to determine limiting contacts (see Listing 3.5) and recommend
a vehicle speed for usv. Finally, the pTrafficGrade app uses the encount er report
to find the encounters associated specifically for the joining vehicle usv to generate a
scenano score.
4.1 Grading Criteria
The application pTrafficGrade uses the encounter reports, encounter report
ranges, and the parameter ranges associated with near miss and collision to gen erate
a scenario score for usv. The maximum score grade of 1.0 corresponds to a scenario in
which 11,sv has no close encounters inside the near miss range - which also includes
having no close encounters inside the collision range. The minimum score grade of 0.0
occurs whenever usv has a close encounter inside of the collision range. It was
determined that any collision event should be represented with a failing grade of zero
because the goal of any mariner is collision avoidance. All scores are on the range [0,1]
with a linear slope grade generated for the number of close encount ers between the
near miss range and the collision range and the range of those close encounters. The
closer the close encount er was to collision range, the higher the penalt y and the lower
the scenario score. The TSS Scenario had the following settings:
• near miss range - 6 meters
• collision range - 3 meters
Rnm8 -clos e encounter rangeiRnms-Rcrs
#close en co'unt er s
6
The TSS Scenario grade then results in three possible outcomes:
1.00 collisions and close encounters = 0
1.00- co, ll i sion s = 0 but close encounters -/=- 0
0 collisions -/=- 0
where:
Rnms = Near Miss Range Setting (6m)
Rcrs = Collision Range Setting (3m)
4.2 Evaluation of the Scenario
4.2.1 Definition of the Null Hypothesis and Critical Values
The null hypothesis for this study was twofold:
• The Nu ll Hypothesis H0
1. The baseline scenar io average score for each permutation will be the same
with and without speed recommendation adjustment
2. The population average score for the baseline scenario will be the same
with and without speed recommendation
• The Alternate Hypothesis H1
1. The speed recommendation scenario average score for each permutation
will be higher than the scenario without speed recommendation adjust ment
2. The population average score for the speed recommendation scenario will
be higher than the scenario without speed recommendation
Critical Values for a sample hypothesis help determine if the sample results are
a product of a noticeable change agent introduced to the sample population or due
to random chance based on the standard deviation of the population. The critical
6
values for 0.1, 0.05, and 0.01, are summarized below in Table 4.1. This thesis uses
the critical value of 1.28 that corresponds to a = 0.1. In this study, a statistical t-
test is conducted on the before and after population to evaluat e the effects on the TSS
Scenario. If the calculated test statistic is greater than the critical value, we reject
the null hypothesis that scores would remain unchanged. By rejecting the null
hypothesis, we accept the alternative hypothesis that there is strong evidence to
suggest speed recommendations produce an increase in test results. Accepting the
alt ernat ive hypothesis also means that improved scores are not clue to random chance.
Critical Value1.281.642.33
Table 4.1: Critical Values for Hypothesis Testing. Calculations of the sam ple pop ulation (after speed recommendations) determine a test statist ic. Because this is a right-tailed test, values are positive and imply an increase in results over the null hypothesis.
4.2.2 Scoring the Scenario
In the evaluation of the TSS Scenario, the baseline (original scenario without
speed recommendation) and the final (scenario with speed recommendation) was run
fifty (50) times each and scored. This score [0,1] was based solely on the geometry
of the starting positions and speeds of the contact vessels and the starting position
and speed of the joining vessel usv. The scores of the random scenario without
speed recommendations for the one vehicle permutations are captured in Table 4.2.
Scores for the one vehicle permutation experiments with speed recommendations are
captured in Table 4.3. Evaluating the TSS Scenario required evaluated runs with
each of the possible permutation of contact vehicles. Because there are a maximum
of five (5) vehicles in both the inbound and outbound lanes, there are twenty-five
(25) permutations of experimentation. Data results for the TSS Scenario are
continued in Appendix B.
6
For a majority of the baseline scenario runs, the geometry of the scenario result ed
in two highly recurring cases:
• The geometry of the scenario result ed in no usv close encounters within the
near miss range (a ll contacts maintained outside 6 meters - 1.0 score)
• T he geometry of t he scenario resulted in 1 or more usv close encounters within
the collision range (at least one contact within collision range - 0.0 score)
T hese cases were the most recurring due to the small distanc e (3 meters) between
the collision range and the near miss range. This produced a smaller probabilit y of
having an init ial geometry that result ed in close encounters exact ly between 3 meters
and 6 mete rs without having any vehicle with a final range inside the collision range.
Higher contact density can result in an increase in the number of close encounters
which can lower t he score (based on close encounter range). This condition is observed
in Figure 4-1. It is notewort hy that the scores for the baseline scenarios without speed
recommend ations for permut at ions with more outbound vehicles typically scored less
than the recip rocal event with increased inbound vehicles. This is probably due to
the fact that outbound vehicles have more intersection points with usv than inbound
vehicles.
Comparison of the raw data between the two types of ru ns showed an increase in
the average scores for each permutation with the inclusion of speed recommendat ion .
This is best represented with an increase in the number of perfect scores (1.0) and a
reduct ion of collision scores (0.0) between Ta bles 4.2 and 4.3. Anot her way to display
the results is a comparison of the average score versus the contact density of the
scenario (F igure 4-1). In this figure, the bottom axis represents an incr ease in overall
contact density from 2 to 10. This result s in the combinin g of averages over different
permutat ion experiments and eliminat ing the influ ence of which lan es the contacts
were in since all possible permutations are included for each contact density set. As
expected, as the contact density increases, the overall score decreases . Of int eresting
note, contact densities of 2 and 10 only have a single permut at ion (1 inbound with 1
outbound and 5 inbound with 5 out bound) making these two test densit ies suscept ible
to potent ial outlier result s.
7
Figure 4-1: TSS Scenario Average Scores versus Contact Density. The above shows the before and after average scores for the TSS Scenario as a product of contact density.For example, where contact density says 4, the corresponding average score is theresultant average from three different experiment runs (1 inbound with 3 outbound, 3 inbound with 1 outbound, and 2 inbound with 2 outbound).
The overall average score for the population without speed recommendation is
0.561 with a standard deviation of 0.4862. The overall average score for the popu
lat ion with speed recommendation is 0. 731 with a standard deviation of .4406.
4.2.3 Statistical Analysis of the Results
Although the raw data showed improvement in the population average test scores
and increases across each permutation, the possibility exists that resultant data was
due to chance and still within the standard deviation of the population. Statistical t-
testing of the two populations permutations was conducted along with an overall
population comparison and shown in Table 4.4. Results show strong evidence that
speed recommendations increase overall scenario performance. At the individual level,
19 of the 25 trial runs produced critical values above the .1 crit ical value (1.28)
threshold. These individual runs would reject the null hypothesis and accept the
alt ernat ive hypothesis. There were 6 out of 25 trial runs that would fail to reject the
7
null hypothesis. The overall population (1250 cases) was overwhelmingly above the
.01 crit ical value with calculated a test statistic of 9.378. Based on these result s,
this study rejects the null hypothesis that average scores would remain the same and
accepts the alternative that speed recommendat ion improved the average test scores.
7
RUN lin / lout lin / 2out 2in / lout lin / 3out 3in / lout lin / 4out 4in / lout lin / 5out 5in / lout1 1.00 1.00 0.00 1.00 1.00 1.00 1.00 0.00 0.002 1.00 0.00 0.00 0.00 1.00 0.00 1.00 1.00 1.003 1.00 1.00 1.00 1.00 0.00 1.00 0.00 0.00 0.004 0.00 1.00 0.00 1.00 1.00 1.00 1.00 1.00 1.00fj 0.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 0.006 0.37 0.00 1.00 1.00 1.00 1.00 1.00 1.00 1.007 0.00 1.00 1.00 1.00 1.00 1.00 1.00 0.00 0.008 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.009 1.00 1.00 1.00 1.00 1.00 1.00 l.00 LOO 1.0010 1.00 0.00 1.00 0.00 1.00 0.00 0.98 0.13 0.0011 1.00 1.00 1.00 1.00 1.00 1.00 0.00 1.00 1.0012 0.57 0.13 1.00 0.00 0.00 0.00 0.30 0.00 1.0013 1.00 0.00 1.00 1.00 1.00 1.00 0.00 0.28 0.0014 0.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.0015 1.00 0.00 0.00 1.00 0 39 1.00 1.00 0.00 0.0016 0.77 0.00 1.00 1.00 1.00 1.00 0.00 0.96 1.0017 1.00 1.00 1.00 1.00 1.00 1.00 1.00 0.00 1.0018 1.00 1.00 0.00 1.00 0.00 1.00 0.00 1.00 1.0019 0.48 0.30 0.00 1.00 1.00 1.00 0.00 1.00 1.0020 1.00 1.00 0.00 0.00 1.00 0.00 0.00 1.00 1.0021 1.00 1.00 1.00 1.00 0.00 1.00 0.00 1.00 1.0022 0.00 0.94 1.00 0.00 1.00 0.00 0.00 0.00 0.0023 1.00 1.00 1.00 1.00 0.00 1.00 0.00 1.00 1.0024 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.0025 1.00 1.00 1.00 0.00 1.00 0.00 1.00 0.00 1.0026 1.00 0.82 0.92 1.00 0.00 1.00 0.00 0.00 0.0027 1.00 1.00 1.00 0.00 0.00 0.00 0.00 1.00 0.0028 1.00 1.00 1.00 1.00 1.00 1.00 0.00 0.08 1.0029 1.00 0.00 1.00 1.00 1.00 1.00 0.00 1.00 1.0030 1.00 1.00 1.00 0.00 1.00 0.00 0.00 0.00 1.0031 1.00 1.00 0.00 1.00 1.00 1.00 0.00 1.00 1.0032 1.00 1.00 1.00 0.00 1.00 0.00 0.00 0.85 1.0033 1.00 0.10 1.00 0.00 1.00 0.00 1.00 0.00 0.9934 1.00 1.00 1.00 0.02 1.00 0.02 0.42 0.00 1.0035 0.00 0.00 1.00 0.00 0.00 0.00 1.00 0.00 1.0036 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 0.0037 0.00 0.00 1.00 1.00 0.00 1.00 1.00 1.00 0.0038 1.00 1.00 0.00 1.00 0.00 1.00 0.00 1.00 0.9939 1.00 1.00 1.00 1.00 0.00 1.00 0.00 1.00 1.0040 0.00 0.00 1.00 0.00 1.00 0.00 1.00 1.00 1.0041 1.00 1.00 1.00 1.00 0.27 1.00 0.00 0.00 0.0042 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.0043 0.29 1.00 1.00 1.00 1.00 1.00 0.00 1.00 1.0044 0.00 1.00 1.00 1.00 0.00 1.00 1.00 1.00 1.0045 1.00 0.00 0.00 0.00 0.00 0.00 1.00 0.00 0.0046 0.50 0.13 1.00 1.00 1.00 1.00 1.00 0.00 1.0047 0.00 1.00 0.33 0.00 1.00 0.00 0.00 1.00 0.0048 1.00 1.00 1.00 1.00 0.75 1.00 0.00 0.00 1.0049 0.00 0.00 0.00 1.00 1.00 1.00 0.00 0.00 1.0050 0.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 0.00MEAN 0.70 0.67 0.74 0.68 0.71 0.68 0.47 0.57 0.68STD DEV 0.43 0.45 0.43 0.47 0.44 0.47 0.49 0.48 0.47VAR 0.18 0.21 0.18 0.22 0.19 0.22 0.24 0.23 0.22
Table 4.2: TSS Scenario Baseline Results for One Vehicle Permutations. The following table shows the graded results from the TSS Scenario for all permut at ions that have a single vehicle in eit her the inbound and / or outbound lane. It is notewort hy that the scenarios with more outbound vehicles typically score less than the reciprocal event with increased inbound vehicles. This is probably due to the fact that outbound vehicles have more int ersection points than inbound vehicles.
7
RUN lin / lout lin / 2out 2in / lout lin / 3out 3in / l out lin / 4out 4in / l out lin / 5out 5in / lout1 1.00 0.00 1.00 0.00 0.00 0.00 1.00 0.00 0.002 1.00 1.00 1.00 0.00 1.00 1.00 1.00 1.00 1.003 1.00 1.00 1.00 1.00 0.00 1.00 1.00 1.00 1.004 1.00 1.00 1.00 0.00 1.00 0.00 0.00 1.00 1.005 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 0.006 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.007 1.00 1.00 1.00 1.00 1.00 1.00 1.00 LOO LOO8 1.00 1.00 0.00 1.00 1.00 1.00 0.00 1.00 1.009 1.00 1.00 1.00 1.00 1.00 1.00 0.00 1.00 1.0010 1.00 1.00 0.00 1.00 1.00 1.00 1.00 1.00 1.0011 1.00 1.00 1.00 1.00 0.00 1.00 1.00 1.00 1.0012 0.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.0013 1.00 1.00 1.00 1.00 1.00 1.00 0.00 1.00 1.0014 1.00 1.00 1.00 1.00 1.00 1.00 0.00 1.00 0.0015 1.00 1.00 1.00 1.00 1.00 0.00 0.00 1.00 1.0016 1.00 1.00 1.00 1.00 0.00 0.00 1.00 1.00 0.0017 1.00 1.00 1.00 1.00 1.00 1.00 0.00 0.00 0.0018 1.00 1.00 1.00 0.00 1.00 1.00 0.00 1.00 1.0019 1.00 1.00 1.00 1.00 0.00 1.00 1.00 1.00 0.0020 1.00 1.00 1.00 1.00 0.00 1.00 1.00 0.00 1.0021 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.0022 1.00 1.00 1.00 1.00 0.00 1.00 1.00 0.54 1.0023 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 0.0024 1.00 1.00 1.00 1.00 1.00 1.00 1.00 0.00 1.0025 1.00 1.00 1.00 1.00 1.00 1.00 0.00 1.00 1.0026 0.00 1.00 1.00 1.00 1.00 0.00 0.00 1.00 0.0027 0.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 0.0028 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.0029 1.00 1.00 1.00 1.00 0.00 1.00 1.00 1.00 1.0030 1.00 1.00 1.00 1.00 LOO 0.00 LOO LOO 0.0031 1.00 1.00 1.00 1.00 1.00 1.00 1.00 0.00 1.0032 1.00 1.00 1.00 1.00 1.00 1.00 0.00 0.00 0.0033 1.00 1.00 0.00 1.00 1.00 1.00 1.00 1.00 0.0034 0.00 1.00 1.00 0.00 0.00 0.00 0.00 1.00 1.0035 1.00 1.00 1.00 1.00 1.00 1.00 0.00 1.00 1.0036 1.00 1.00 1.00 0.00 1.00 1.00 1.00 1.00 0.0037 1.00 1.00 1.00 1.00 1.00 1.00 0.00 0.00 1.0038 1.00 1.00 1.00 1.00 0.00 1.00 1.00 1.00 1.0039 1.00 0.00 1.00 0.00 1.00 1.00 0.00 1.00 1.0040 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 0.0041 1.00 1.00 1.00 1.00 1.00 1.00 1.00 0.00 1.0042 1.00 0.00 1.00 0.00 1.00 1.00 1.00 1.00 1.0043 1.00 1.00 1.00 0.00 1.00 1.00 0.00 1.00 1.0044 1.00 1.00 0.00 1.00 1.00 0.00 1.00 1.00 1.0045 1.00 1.00 1.00 1.00 1.00 1.00 0.00 0.00 1.0046 1.00 1.00 1.00 1.00 1.00 0.00 0.00 1.00 1.0047 0.00 1.00 0.00 1.00 1.00 1.00 0.00 1.00 1.0048 0.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.0049 1.00 1.00 0.00 1.00 1.00 0.00 1.00 1.00 1.0050 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 0.00ME AN 0.88 0.94 0.88 0.82 0.80 0.80 0.62 0.81 0.70ST D DE V 0.32 0.24 0.32 0.38 0.40 0.40 0.49 0.39 0.46VAR 0.11 0.06 0.11 0.15 0.16 0.16 0.24. 0.15 0.21
Table 4.3: TSS Scenario Results for One Vehicle Permutations with Speed Adjust- ment Recommendations. The following table shows the graded results from the TSS Scenario for all permut at ions that have a single vehicle in eit her the inbound and / or outbound lane after algorithms access the contact density and generate a speed ad- justment recommendation.
7
RUN TEST STATISTIClin / lout 2.292lin / 2out 3.7062in / lout 1.773lin / 3out 1.6283in / lout 1.028lin / 4out 1.2834in / lout 1.349lin / 5out 2.8455in / lout 0.2312in / 2out 3.5282in / 3out 1.2933in / 2out 2.6882in / 4out 4.8504in / 2out 1.9692in / 5out 2.5595in / 2out 0.7923in / 3out 1.8733in / 4out 1.9484in / 3out 0.1823in / 5out 2.2515in / 3out 1.0984in / 4out 0.7384in / 5out 1.6585in / 4out 2.2805in / 5out 2.446POPULATION 9.378
Ta ble 4.4: Test Statistic Calculations for the TSS Scenario. The calculated values in this table are compared to critical values in Table 4.1. This uses the critical value of1.28 for comparison.
7
Chapter 5
Conclusions
This study examined the effect of early speed recommendation on a vehicle joining
a traffic separation scheme. This study produced a set of practical applicat ions to
digitally represent a traffic separation scheme, to determine compliance with traffic
separation scheme headings, and to recommend a speed for entering the scheme
while minimizing contact density. Applications of this study could be included in
current navigational aids and voyage management systems or as another decision aid
oper ating on a st and-alone unit for ship officers. Comparative and stat ist ical analysis
of the results showed an improvement in contact management and collision
avoidance for the joining vehicle.
5.1 Limitations of Study
This research was based on the sharing of vehicle information and destination
intent which is simil ar to the usage of AIS. Previous work [19] has shown that AIS
information can be unreliable and early work in this study found that AIS informa tion
is sparse ly filled out. In the military domain, it may be imp ract ical to broadcast
destination information or vehicles may be operating in a GPS denied environment.
Such constraints would make it difficult to use the assumptions and algorithms of
t his study. Additionally, their are no known rules for autonomous vehicles in the
COLREGs and this study treats them the same as power-driven vessels (all vehicles
7
treated equally). It is possible that future changes to the COLREGs that include
unmann ed vehicles may address their hierarchy with respect to other vehicles and
change the assumptions of this study.
This research graded the scenario based on final contact vehicle location in three
distinct regions: outside of near miss range, insid e of collision range, and between
near miss range and collision range. This study did not conduct multiple variations
in the thresholds for near miss range or collision range which would change the overall
grading score of the scenario. Future work could be conducted to determine the effects
of changing these ranges on the overall score. This study also constrained the speed
recommendat ion and allowed the algorithm to pick the best speed in that range.
This may not always be allowed in real world scenarios in which slowing down by a
ship officer is the more prudent and safer choice. Future expansion of t his work may
include the ability to toggle between a slow speed and high speed solut ion.
5.2 Recommended Areas for Further Study
During the course of this research study a number of subjects and branching ideas
were identified which could represent useful expansions of this work. Such ideas and
subjects are presented here as identifiable next steps for follow-on research.
5.2.1 Digital Representation of Traffic Lanes
The function that creates traffic lan es only joins seglist boundary lines with sepa
ration zon es at this time. Further research is needed to properly join boundary lines
with separation zones and precaut ionary areas to create traffic lanes that are more
representative of 33 CFR. Additionally, the ability to clear a TrafficScheme object
with a message and dynamically populate a new traffic separation scheme inst ance or
transition between mult iple inst ances based on xy locat ion would be a necessary next
step. This would allow a vehicle to complete a full inbound/ outbound transit that
uses mult iple traffic separation schemes while minimizing the message size passed to
7
the vehicle.
5.2.2 Injection of Historical AIS Data
Based on the author's experience, mariners transiting in the traffic lane at speeds
slower than the observed average traffic speed tend to bias ship location to the outside
of the lane and allow faster vehicles to bias to the inside. This study maintained all
vehicles operating in the center of lane. Such biasing could affect the distance between
vehicles, change the number of limiting contacts, and change overall scenario score.
An injection of historical AIS data for specific traffic lanes would be the next step
in creating a more realistic scenario that approximates vehicle location within the
lane, probabilistic turns (and turn radius), and probabilistic entra nce/ exit points at
locat ions other than the terminal ends of the traffic separation scheme. There is
considerable room to imp rove t he kinematics used to ext ra polate future positions
using turning radius and acceleration/ deceleration of vehicles. Further work with
historical AIS data could be done to take a geogra phic location or point destination
and convert it into a set of waypoints and seglist that conform to the generated traffic
separation scheme and combine it with a probabilistic enter / exit points to the scheme.
This could be done in lieu of passing waypoints and seglists and would represent the
next step in converting AIS destination data to useful information that the algorithms
of this thesis could ingest and convert into a speed recommendation.
5.2.3 Behaviors for Traffic Lane Operation
This study looked only at speed recommendat ions for the u,sv vehicle. Future
expansion of this work would be to couple the speed recommendation with a possible
course recommendation using the ± 10° criter ia used in this study as approved head
ings for approaching the traffic lane. In this scenario, the vehicle joining the lane has
all collision avoidance behaviors turned off. In future iterations of this work, these
behaviors should be turned on to measure response and minimize the number of close
encounters that occur. A separate behavior could be created for use while operat-
7
ing in the transit lane to identify vehicles in front and behind vehicles transiting in
the lane. This new behavior could seek a location and speed within the lane that
minimizes getting "run over" by the other transiting vehicles and should be used by
all vehicles to better represent reality. A different type of collision avoidance could
be generated for transiting vehicles that seeks to maintain operations inside the lane
as a high priority using speed recommendation, vehicle placement, and overtaking
methods. Future work to switch between different collision avoidance behaviors for
vehicles operating in the lane and not operating in the lane could be explored. The
use of pTSSCompliance application to toggle between different collision avoidance
behaviors is the logical next step. It is the author's belief that this combination would
turn some of the collisions in this study to near misses and near misses to non-
events.
5.3 Final Conclusions
This study successfully created a method to digitally represent and publish a
traffic separation scheme for use in multiple applications within a simulation envi
ronment. The ability to dynamically generate a traffic separation scheme is a key
enabler to incr eased operations for unmanned vehicles in the harbors and close-in
waters. This study also successfully implemented a met hod of determining contact
density at key int ersection points and converting that into a speed recommendat ion.
This research demonstrates that collision avoidance can be improved with early
speed recommendat ions, but this is only one part that is needed in effective ship
handling by good mariners or good autonomous systems. The next step of research in
this study would be to demonstrate that the inclusion of over-the-horizon speed
recom mendat ions would enhance collision avoidance and minimize contact density
when coupled with a ship officer or as part of a suite of autonomous collision
avoidance software than scenarios wit hout .
7
Appendix A
Marine Autonomy Landscape
This section uses the Architecting Innovative Enterprise Strategy (ARIES) method
ology, developed by Dr. Deborah Nightinga le and Dr. Donna Rhodes[18], to examine
the Marine Autonomy enterprise for the US Navy by the author. The ARIES ap
proach examines the enterprise in a holistic way to understand the external and
internal factors that contribute to and bring about change in an enterprise and ex
amines an enterprise from several different points of view - or lenses - to explain the
inner workings, communications, structure, and exchange of information that deliv
ers value to the stakeholder. Marine Autonomy for the USN is a large multi-domain
topic area with many overlapping factors. Despite the similarit ies with unmanned
aerial vehicles (UAVs) and unmanned underwater vehicles (UUVs), the scope of this
study will focus on marine autonomy on unmanned surface vehicles (USVs) since the
COLREGs are for surface vessels and most applicab le to vessels within sight of one
another. While commercial indust ry, academ ia, and foreign agents are mentioned at
a high level to define the ecosystem, it is beyond the scope to discuss hostile actors
from a military standpoint or to dive deep into proprietary technologies. Such unique
studies are either classified or require extensive analysis as a separate study of their
own.
In order to better visualize the long list of factors that influence USN marine au
tonomy, an IDEF0[21] model like Figure A-1 shows the different inputs and outputs
of the enterprise as well as controls and mechanisms to this system of systems. The
8
IDEF0 model is a representation of the overall function of a sys t em and the requir e
ments needed to provide that function. At the center is the system or activity itself
repr esented in a "noun-v erb" description. In the case of marin e autonomy, this is best
presented in two cases. The first case, "providing degrees of aut onomy" , represents
a range of CONOPs for autonomous vehicles and the levels of human in the loop
intera ctions. In some CONOPs, such as open ocean travel and waypoint following,
this model represents a completely autonomous system. In other instances, such as
combat or inst ances with rules of engagement (ROE) , a utonomy contains humans
in the loop for decidin g behaviors and selecting missions. In these circumst ances,
human ju dgement and intuition of varying circumstances and variables are required.
The other case of marine autonomy, is when autonomy is used to II augment human
decision making". Autonomy of this type is used to remove easily programmable and
highly repetitive tasking which enables ship officers to focus on more det ailed and
complicat ed situations. In this sit uat ion, autonomy reasons about the environment
or system it operates in and produces an output that compresses the amount of input
information to decision makers. The growing range and scope of marin e autonomy
CONOPs prevents a single phrase to describe the overall function.
At a high level, these functions are perform ed by the objects around the IDEF0
model. On the left are the Jnp'IJ,ts, or materials that are used/ consumed by the
syste m or act ivit y. For marine autonomy, this is generally represented by the input s,
sensors, and algorit hms. T he ability to detect other vessels is essent ial in collision
avoidan ce. Additionally, the ability to take in input s from the environment - such as
acoustics, sonar scans, and ima ges - form the foundation of autonomous CONOPs.
At the top, the Controls bound the act ivit y by outlining the condit ions needed to
perform the overall function or the guidelines needed to perform the function. At a
military level, this is captured in varying levels of regulations, guidelines, commande rs'
intent, and explicitly with defensive readiness conditions (DEF CON) and ROE. At
the bot to m, t he Mechanisms are the physical or organizational aspects that enable its
operation. For most marine applicat ions of autonomy, these mechanisms are rudders
and propulsors to transit the ocean. Hardwar e and soft ware it ems such as power
8
sources and computational power are here. Finally, to the right are the Outputs - or
the results - from the system that are provided to the user or stakeholder.
Figure A-1: IDEF Mode O Model of Marine Autonomy
A.1 Commercial Landscape
Non-military applications for marine autonomy are mainly driven by the shipping
indust ry, offshore oil and drilling, and academia. The shipping industry influences
autonomy advances in collision avoidance, navigation, and complete platform au
tomation as it seeks to shift to unmann ed vessels. This shift towards unmanned
platforms with high degrees of autonomy is believed to decrease overall operating
costs while maintaining reliable delivery of shipped goods. Offshore oil and drilling
uses remotely operated vehicles (ROYs) to assist in functions such as underwater con st
ru ction and operation, environment al monitoring, and inspections. These platforms
benefit from increases in marine autonomy to alleviate low-level decision making from
8
operators, allocate these to the vehicle, and allow the operator to concentrate on more
complicated tasks. Academic inst it ut es continue to explore advances in navigation,
sensor and platform algorithms that support autonomous operations. Additionally,
academia and support ind ust ries advance the state of technologies such as machine
learning, artificial intelligence, control theories, and continue to evolve the decision
making algorithms, computational processing, power generation, and power allocation
of marine platforms[35].
A.2 Military Landscape
The US Navy is the largest stakeholder in the US marine autonomy market and
maintains a continual effort to understand the current and future state of its marine
autonomy enterprise. As the state of technology changes, the Navy continually ac
cesses the potential benefits and capabilities that marine autonomy provides warfight ers.
As industry, academia, and foreign agents continue to make advances in marine
autonomy capabilities, the US Navy evaluat es incorporation of commercial solutions,
determination of foreign and domestic vulnerabilities, generation of solutions and
variations in CONOPs. At a high level, the Navy currently uses marine autonomy
for information gathering, seabed exploration / manipulat ion, decision making aug
mentation, battlespace awareness and management. Currently, the Navy CONOPs
maintain humans in the loop for ROE, complex decision making, and cyber-security
concerns [12].
A.3 Technology
A RAND Corporation study produced in 2019 found that the first patent in marine
autonomy was in 1970. Since 2000, this industry has seen an exponential growth in
the number of global patents[12]. Much of this growth can be attributed to advances
in comput ing processing power, machine learning, art ificial intelligence (AI), and
renewed interest in maritime autonomous systems. Additionally, advancements in
8
other unmanned systems - such as self-driving cars and UAVs - have created avenues
for cross domain applicat ions . Another explanat ion for the growth of global patents in
marine autonomy illustrated in Figure A-2 is the increase in Chinese marine autonomy
patents. In Figure A-3, the United States - individually - used to produce the same
number of patents as the rest of the world (excluding China) combined. At the time
of the RAND report, the US patent was still tracking with the rest of the world
but Chinese patents have been increasing exponentially. The main drivers of marine
autonomy patents in the US are the US Navy and technology firms while in China
the large contributors are universities.
Figure A-2: Global Output of Autonomous Maritime Patents, 1970-2016 [12]
Figure A-3: Output of Autonomous Maritime Patents for China, the United States, and the Rest of the World, 2000-2016 [12]
8
A.4 Current As-Is Architecture - U.S. Navy
As discussed before, the ARIES approach exam ines the enterprise at multiple lev els.
This section captures the current state of t he enterprise (i.e the As-Is condit ion) with an
ARIES element model as defined by the aut hor. This model is a thorough, but not
exclusive, list of lenses that are identified in Figure A-4.
Figure A-4: ARIES Element Mod el [18 ]
A.4.1 Ecosystem and Stakeholders
The Navy's marine autonomy ecosystem includ es foreign adversar ies and congres
sional oversight and budget ing in a geo-political lens [20]. The marine autonomy
mar ket contains a combination of Commercial-Off-The-Shelf (COTS), government
vendor, and government furnished platforms, sensors, and algorit hms. Unmanned
maritime systems do not currently have a lot of regulations. The COLREGs cur
rently do not cont ain references or sit uat ions involving USVs. Additionally, high
traffic dense areas such as ports and harbors do not have specific unmanned opera tional
doctrine [6]. This is particularly interesting when you start to consider where fault lies
in the event of a collision with an autonomo us vehicle making decisions about
dynamically changing contact condit ions . As previously identified, the Joint Chiefs of
Staff does not allow for unmanned systems to make decisions with regards
8
to ROE [12].
Other stakeholders in the marine autonomy enterpr ise include:
• US Naval Fleet and Force Commanders (battlespace awareness/ manipulat ion)
• US Sailors (end users)
• Government Vendors (algorithm and platform producers)
• Technology Vendors (machine learning, AI, control systems)
• Academia (and other open sources for algorithms)
• Other non-military applicat ions (i.e. commercial and hobbyist)
• Regulatory entit ies (i.e. US Government, US Coast Guard - COLREGs)
• Other marine vessels (commercial, personal, other military platforms, other
unmanned marine systems)
A.4.2 Strategy
The Department of Defense (DoD) produces a 25 year plan that outlines the
vision and direction for unmanned systems. In the most recent Unmanned Systems
Integration Roadmap 2017-2042 [30] written in 2018, the DoD vision for unmanned
systems is that they will operate "seamlessly with mann ed systems to compress the
warfighters' decision-making process, while reducing the risk to human life" and each
organization within the DoD has utilized autonomy according to organizational need.
A separate study cond uct ed by the RAND Corporation [12], identified key strategic
goals for Navy Unmanned Systems that included:
• Operations and communications in limit ed-connectivity and over-the-horizon
condit ions
• CONOPs that utilize combinations of and collaboration between smaller plat
forms ("distributed let hality" or SWARMs) vice concentration on larger "do-all"
platforms
• Operations and intelligence gathering in areas where communications and relay
nodes are denied
• Prevention of foreign agents to target and/ or sabotage unmanned assets with
relat ive ease
8
• Continued sub-surface battlespace management and control
A.4.3 Information
The information needed to operate unmanned systems is driven mainly from sen
sory inputs, making decisions about the environment, and potentially communicating
outputs. In the marine autonomy enterprise, information can be idealized into three
separate categories: navigation, communication, and primary mission payload. Nav
igationally, marine autonomy is similar to manned vessels in that safe operation is
driven by the ability to identify other vessels, navigational hazards, and continually
identify vehicle location. As such, it may also be the most limiting of the three. When
sensors and other navigational tools fail, the COLREGs still identify the ship offi
cer as responsible for safe ship operations and collision avoidance. In the unmanned
realm, some limitations to navigational information can be summarized [12, 19]:
• GPS - not covert, access to satellites may be denied, and is not available for sub-
surface use
• RADAR - requires environments with distinguishable features, minimal envi
ronmental factors, but is highly reliable
• AIS - access to satellites may be denied, lots of sparse (fields not required to
be filled) and incorrect data (headings), not always required or transmitted by
vessels
• LIDAR - limited range, susceptible to errors from basic environmental effects
• SONAR - extremely versatile for collision avoidance, requires a lot of known
features to utilize as a primary source of navigation
Mission payload information has some overlap with navigation. In this lens, the
information that is needed is specific to the mission performed by the platform. While
navigation can be a specific mission (such as following waypoints), it is an essential
activity performed by all Navy unmanned maritime systems. Identifying that there is
some overlap means that over time, fusion of sensory information will be required to
optimize platform design. Mission specific information may include sonar information,
picture images, weather conditions, wave currents, and ocean environment condit ions .
8
Mission information is generally agnost ic to the platform with algorit hms, sensors,
a nd feat ures typically packaged together to perform the mission. This is furt her
discussed in Section A.4.4.
Communication information is the ability to send and receive mission planning
and collaborate between multiple vehicles. This information may also include confir
mation or sta tus feedback to mission planners or other actors. Similar to navigational
inform at ion , this inform at ion has limitat ions. Sat ellit e communicat ions can be less
secure, require large suites, and may be denied. Radio and light communications have
limitat ions in dat a rate. Additionally, the ability to receive, categorize, classify, and
report inform at ion remains an area within the Navy unmann ed systems enterprise
with less progress. Sabot age and inform at ion security remain concerns for the US
Navy [30].
A.4.4 Infrastructure
The US Navy utilizes key at t ribut es in its infrastructural architecture to maintain
a sust aina ble enterprise. The most import ant of these attributes is a common, open
archit ecture in which the payload and mission portion of marine autonomy is platform
agnostic. The commona lity in this architecture is a key driver towards avoiding vendor
specific and singular, proprietary driven platforms. One of the ongoing efforts of the
US Navy and a key enabler to this architecture is to achieve a common language
architecture across its current vendor landscape to enable a robust and modular
enterprise. This common language includes a st andard for command, cont rol, a nd
communi cat ion between systems [30, 3].
A.4.5 Products and Services
The Navy marine autonomy enterprise provides increasingly capable mar it ime do
main capabilities to combat ant comm anders on both UUV and USV systems. Current
and fut ure services includ e [3]:
• Future "dist ribut ed let halilty" to includ e unmann ed and mann ed system coop-
8
eration
• Distributed sensing and communication relay nodes for over-the-horizon oper
ations
• Mine Countermeasure operations to include sweep, hunt, and neutralize
Addit iona lly, the Navy has the ability to test, evaluate, verify, and validate a wide
range of autonomous factors to determine suitability and compliance with military
marine conditions. Testing tools are an essential part of the process to bring new,
emerging autonomous technologies to the encl user that are reliable and have expected
functional outcomes [30]. Because algorithms, platforms, and sensors may come
from COTS or non-military applications, this step also includes the process of ensuring
and transforming non-military autonomous concepts into products that occupy
military, marine environments.
A.4.6 Process, Organization, Knowledge
The organizational and social network of the US Navy marine autonomy enter
prise currently centers around a Program Office - PMS 406. This office is overall
responsible for acquisition and development of unmanned marine systems and the
delivery of those systems to the US Navy. This office is in charge of overall procure ment
of technologies and intellectual properties but the Navy has other organizations (i.e.
NUWC Newport, DARPA, ONR) within the marine autonomy enterprise that generate
competencies, expertise, and other intellectual properties [20]. The US Navy also hosts
test demonstrations (i.e. ANTX) that allow vendors to feature emerging capabilities.
Because the US Navy is the largest occupant in the marine autonomy market, these
activities allow vendors to showcase to the US Navy emerging trends in technology
and new concepts in application, operation and capability. As a large stakeholder, the
Navy maintains a strong ability to drive this market to acquire plat forms, algorithms,
and other technologies it deems essential to continued operation or enablers for
future growth.
8
Appendix B
Results of TSS Scenario Experiments
9
Ta ble B.l: Two Vehicle (m in) Permut at ions without Speed Recommendation
RUN 2in / 2out 2in / 3out 3in / 2out 2in / 4out 4in / 2out 2in / 5out 5in / 2 out1 0.00 1.00 0.00 0.17 0.00 1.00 0.382 0.00 1.00 0.00 0.14 1.00 1.00 1.003 1.00 1.00 1.00 1.00 1.00 1.00 0.004 1.00 1.00 0.00 0.00 0.00 1.00 0.005 1.00 1.00 1.00 1.00 1.00 1.00 0.006 1.00 0.00 0.00 1.00 1.00 0.00 0.007 1.00 1.00 1.00 0.35 0.00 0.1.5 0.008 1.00 0.00 0.00 0.00 0.00 1.00 1.009 0.00 0.69 1.00 0.00 0.00 1.00 0.0010 0.00 0.00 1.00 1.00 0.00 0.00 1.0011 1.00 1.00 1.00 1.00 0.00 0.00 0.0012 0.00 1.00 1.00 0.00 0.00 0.00 1.0013 1.00 0.00 1.00 0.00 0.58 1.00 0.0014 0.00 1.00 1.00 1.00 1.00 1.00 0.0015 1.00 0.00 0.00 1.00 0.00 1.00 0.0016 1.00 1.00 1.00 1.00 0.00 1.00 1.0017 1.00 1.00 0.98 1.00 1.00 1.00 1.0018 0.00 1.00 0.00 0.00 0.00 1.00 1.0019 1.00 1.00 0.00 0.00 0.00 1.00 0.0020 0.00 1.00 1.00 0.00 1.00 0.02 1.0021 0.00 1.00 1.00 1.00 1.00 1.00 1.0022 1.00 1.00 0.00 0.00 0.00 0.00 0.0023 1.00 1.00 1.00 1.00 1.00 1.00 1.0024 0.00 1.00 1.00 0.27 1.00 1.00 1.0025 0.87 1.00 0.41 0.00 0.61 0.00 0.6726 1.00 1.00 1.00 0.00 1.00 0.00 0.0027 1.00 1.00 1.00 0.00 0.00 0.00 0.0028 0.00 1.00 1.00 1.00 0.00 0.00 1.0029 1.00 1.00 1.00 0.32 0.00 0.46 1.0030 1.00 0.00 0.00 0.00 0.00 0.00 0.0031 0.00 1.00 1.00 1.00 1.00 0.52 1.0032 1.00 0.00 0.00 0.00 0.23 1.00 0.0033 1.00 1.00 0.00 0.00 1.00 0.00 1.0034 0.00 0.00 1.00 1.00 1.00 0.00 1.0035 1.00 0.00 1.00 1.00 1.00 0.00 0.0036 1.00 1.00 1.00 1.00 1.00 0.00 1.0037 0.00 0.00 1.00 1.00 1.00 1.00 0.6338 1.00 1.00 1.00 1.00 1.00 0.00 1.0039 1.00 0.00 0.00 0.00 1.00 1.00 1.0040 0.00 0.00 1.00 0.00 0.00 0.00 0.0041 1.00 1.00 1.00 0.00 0.00 1.00 0.0042 1.00 0.00 0.00 0.00 0.00 1.00 1.0043 0.00 1.00 1.00 0.03 0.05 1.00 1.0044 0.00 1.00 0.19 1.00 1.00 0.00 0.0045 0.00 1.00 1.00 1.00 0.00 1.00 1.0046 0.00 1.00 1.00 1.00 1.00 1.00 0.0047 1.00 1.00 0.00 1.00 1.00 0.00 1.0048 1.00 0.00 0.00 0.00 0.00 1.00 0.0049 1.00 1.00 1.00 0.00 1.00 0.00 1.0050 1.00 1.00 0.00 0.00 1.00 1.00 1.00MEAN 0.62 0.71 0.63 0.47 0.51 0.56 0.53STD DEV 0.48 0.45 0.47 0.48 0.49 0.48 0.48VAR 0.23 0.20 0.22 0.23 0.24 0.23 0.24
RUN 3in / 3out 3in / 4out 4in / 3out 3in / 5out 5in / 3out
9
Table B.2: Three Vehicle (min) Permutations without Speed Recommendation
1 0.00 0.00 1.00 1.00 0.002 1.00 0.00 1.00 0.00 0.003 0.00 0.00 1.00 1.00 0.004 1.00 0.00 1.00 0.00 0.005 0.00 0.00 0.00 0.86 0.476 1.00 0.00 0.71 0.47 1.007 0.00 1.00 1.00 0.00 0.808 1.00 1.00 1.00 0.00 1.009 1.00 1.00 0.00 0.00 0.0010 1.00 0.00 1.00 0.00 0.0011 1.00 0.00 1.00 0.00 0.0012 0.00 1.00 0.00 0.00 0.0013 1.00 0.00 1.00 0.00 1.0014 1.00 0.00 0.00 0.00 1.0015 1.00 1.00 0.00 0.00 1.0016 1.00 0..53 1.00 0.00 0.0017 0.00 1.00 1.00 0.00 1.0018 0.00 0.00 1.00 1.00 0.0019 1.00 1.00 0.00 0.00 1.0020 1.00 1.00 1.00 0.00 1.0021 1.00 0.00 0.00 0.00 1.0022 1.00 0.00 1.00 0.00 0.0023 1.00 1.00 1.00 1.00 0.0024 o.o.s 0.00 1.00 0.00 1.0025 0.00 0.00 0.38 0.00 0.0026 1.00 1.00 0.00 0.00 1.0027 0.00 1.00 1.00 0.97 1.0028 0.00 0.00 1.00 1.00 1.0029 1.00 1.00 1.00 0.73 0.0030 1.00 1.00 1.00 1.00 1.0031 0.00 0.00 0.00 0.00 1.0032 0.00 1.00 0.00 0.00 1.0033 1.00 0.00 0.00 0.00 0.0034 1.00 0.00 1.00 1.00 0.0035 0.00 1.00 1.00 1.00 1.0036 0.00 0.00 0.00 0.00 1.0037 1.00 0.30 1.00 1.00 1.0038 0.00 0.00 0.00 0.00 1.0039 1.00 1.00 1.00 0.00 0.0040 1.00 1.00 0.00 1.00 0.0041 0.00 1.00 1.00 1.00 1.0042 0.24 1.00 1.00 1.00 0.0043 0.00 1.00 1.00 0.00 0.0044 0.00 0.00 0.00 1.00 0.0045 1.00 1.00 1.00 0.00 0.0046 0.00 1.00 1.00 1.00 1.0047 1.00 0.00 1.00 1.00 0.0048 1.00 1.00 0.00 0.00 0.0049 1.00 0.00 0.00 0.00 1.0050 1.00 1.00 1.00 1.00 0.00MEA N 0.59 o..so 0.64 0.38 0.49STD DEV 0.49 0.49 0.47 0.47 0.49VAR 0.24 0.24 0.22 0.22 0.24
9
Table B.3: Four/ Five Vehicle (m in) Permutations without Speed Recommendation
RUN 4in / 4out 4in / 5out 5in / 4out 5in / 5out1 1.00 0.11 0.00 0.002 1.00 0.00 0.00 0.00.•), 0.00 0.00 0.00 0.004 0.00 1.00 0.00 1.005 1.00 1.00 0.00 1.006 1.00 0.00 1.00 0.007 1.00 0.00 1.00 1.008 0.00 0.00 1.00 1.009 1.00 0.00 0.00 0.0010 0.07 1.00 0.00 1.0011 1.00 0.00 0.00 0.0012 0.00 0.00 0.00 0.0013 0.00 1.00 0.00 0.0014 1.00 0.00 0.00 0.001-5 0.00 0.00 1.00 1.0016 0.00 1.00 0.00 0.0017 1.00 0.00 0.00 1.0018 0.00 0.00 0.00 0.0019 0.00 0.00 1.00 1.0020 0.00 1.00 0.00 0.0021 1.00 0.04 0.00 0.0022 0.00 0.00 0.00 1.0023 0.00 0.00 1.00 0.0024 0.87 1.00 1.00 1.0025 0.00 0.38 0.00 0.1126 0.00 1.00 0.45 0.8627 0.00 0.00 0.00 1.0028 1.00 0.00 0.00 1.0029 1.00 0.00 1.00 0.0030 1.00 0.21 0.00 0.0031 0.00 0.00 1.00 0.0032 0.00 0.00 0.00 0.0033 0.00 1.00 0.00 0.0034 0.00 lL59 1.00 o..5735 1.00 0.09 0.00 0.0036 1.00 0.00 0.00 0.0037 0.00 1.00 0.00 0.0038 0.00 0.00 0.00 0.0039 1.00 0.44 1.00 1.0040 1.00 0.81 1.00 0.0041 0.16 0.00 0.00 1.0042 1.00 0.00 0.00 1.0043 0.00 1.00 1.00 1.0044 0.00 1.00 0.00 1.004-5 1.00 1.00 0.00 1.0046 1.00 0.00 0.00 0.0047 1.00 1.00 1.00 0.0048 0.00 1.00 0.00 0.0049 0.09 0.00 0.00 0.0050 0.00 1.00 0.00 0.00MEAN 0.44 0.37 0.29 0.39STD DEV 0.49 0.46 0.45 0.48VAR 0.24 0.21 0.20 0.23
9
Table B.4: Two Vehicle (min) Permutations with Speed Recommendation
RUN 2in / 2out 2in / 3out 3in / 2out 2in / 4out 4in / 2out 2in / 5out 5in / 2 out1 1.00 1.00 1.00 1.00 1.00 1.00 1.002 0.00 1.00 1.00 1.00 1.00 1.00 1.003 1.00 1.00 1.00 1.00 1.00 1.00 1.004 1.00 1.00 1.00 1.00 1.00 0.00 0.005 1.00 1.00 0.00 1.00 1.00 1.00 0.006 1.00 0.00 1.00 1.00 0.00 1.00 0.007 1.00 1.00 1.00 1.00 1.00 1.00 0.008 1.00 1.00 1.00 1.00 1.00 1.00 1.009 0.00 1.00 1.00 1.00 0.00 0.00 0.0010 1.00 0.00 1.00 1.00 1.00 1.00 1.0011 1.00 1.00 1.00 1.00 1.00 1.00 1.0012 0.00 1.00 1.00 1.00 1.00 0.00 1.0013 1.00 1.00 1.00 1.00 1.00 0.00 1.0014 0.00 0.00 1.00 1.00 1.00 1.00 0.0015 1.00 1.00 1.00 1.00 0.00 0.00 1.0016 1.00 1.00 1.00 1.00 1.00 0.00 1.0017 1.00 1.00 1.00 0.00 0.00 1.00 0.0018 1.00 0.00 1.00 1.00 1.00 1.00 1.0019 1.00 1.00 1.00 1.00 0.00 1.00 1.0020 1.00 1.00 0.00 1.00 1.00 1.00 1.0021 1.00 1.00 1.00 1.00 0.00 1.00 0.0022 1.00 0.00 1.00 1.00 0.00 1.00 1.0023 1.00 1.00 1.00 0.00 1.00 1.00 1.0024 1.00 0.00 1.00 1.00 1.00 1.00 0.0025 1.00 1.00 1.00 0.00 1.00 0.00 1.0026 1.00 1.00 0.00 1.00 1.00 1.00 0.0027 1.00 1.00 1.00 1.00 1.00 1.00 0.0028 1.00 1.00 1.00 1.00 0.00 1.00 1.0029 1.00 1.00 1.00 0.00 1.00 0.00 0.0030 1.00 1.00 1.00 1.00 1.00 0.00 0.0031 1.00 1.00 1.00 1.00 1.00 1.00 1.0032 1.00 1.00 1.00 1.00 1.00 1.00 1.0033 0.00 1.00 1.00 1.00 0.00 1.00 1.0034 1.00 1.00 0.00 1.00 1.00 0.34 0.0035 1.00 0.00 0.00 1.00 0.00 1.00 1.0036 1.00 1.00 1.00 1.00 1.00 1.00 1.0037 1.00 1.00 1.00 1.00 1.00 1.00 0.0038 1.00 0.00 1.00 1.00 1.00 0.00 1.0039 1.00 1.00 1.00 0.00 1.00 1.00 0.0040 1.00 1.00 0.00 1.00 0.00 1.00 0.2341 1.00 0.00 1.00 1.00 1.00 1.00 1.0042 1.00 1.00 1.00 1.00 1.00 1.00 1.0043 1.00 1.00 1.00 1.00 1.00 1.00 0.0044 1.00 1.00 1.00 1.00 0.00 1.00 1.0045 1.00 1.00 1.00 0.79 0.00 1.00 1.0046 1.00 1.00 1.00 1.00 1.00 1.00 0.0047 0.00 1.00 1.00 1.00 0.00 1.00 0.0048 1.00 1.00 1.00 0.00 1.00 1.00 1.0049 1.00 1.00 1.00 1.00 1.00 1.00 1.0050 1.00 1.00 1.00 0.00 0.00 1.00 1.00MEAN 0.88 0.82 0.88 0.86 0.70 0.79 0.60STD DEV 0.32 0.38 0.32 0.35 0.46 0.40 0.49VAR 0.11 0.15 0.11 0.12 0.21 0.16 0.24
9
Ta ble B.5: Three Vehicle (min) Perm utations with Speed Recommend ation
RUN 3in / 3out 3in / 4out 4in / 3out 3in / 5out 5in / 3out1 1.00 0.00 0.00 0.00 0.002 1.00 1.00 1.00 0.74 0.003 1.00 0.00 1.00 0.00 1.004 1.00 1.00 1.00 1.00 0.005 1.00 1.00 1.00 1.00 1.006 1.00 1.00 1.00 0.00 1.007 0.00 1.00 0.00 0.00 1.008 1.00 0.00 1.00 1.00 0.009 1.00 1.00 1.00 0.00 0.0010 0.00 0.00 1.00 0.00 0.0011 1.00 0.00 1.00 1.00 1.0012 1.00 1.00 0.00 0.00 1.0013 1.00 1.00 0.00 1.00 0.0014 1.00 1.00 0.00 1.00 0.0015 1.00 1.00 0.00 1.00 1.0016 0.00 0.00 1.00 1.00 0.0017 1.00 0.00 1.00 0.00 1.0018 1.00 1.00 0.00 0.00 0.0019 0.00 0.00 0.00 1.00 1.0020 0.00 1.00 1.00 1.00 0.0021 1.00 1.00 1.00 1.00 1.0022 0.00 1.00 1.00 1.00 1.0023 0.00 0.00 0.00 0.00 1.0024 0.00 1.00 0.00 1.00 0.0025 1.00 0.00 1.00 0.00 1.0026 1.00 1.00 1.00 0.00 1.0027 1.00 1.00 0.00 1.00 1.0028 1. 00 1.00 1.00 0.00 1.0029 1.00 0.00 0.00 0.00 1.0030 0.00 0.00 1.00 1.00 0.0031 1.00 1.00 1.00 1.00 0.0032 1.00 1.00 1.00 1.00 1.0033 1.00 1.00 1.00 1.00 1.0034 1.00 1.00 0.00 1.00 1.0035 1.00 1.00 1.00 0.00 0.0036 0.00 1.00 0.00 1.00 0.0037 1.00 1.00 0.00 1.00 0.0038 1.00 1.00 1.00 1.00 1.0039 1.00 1.00 1.00 0.00 1.0040 1.00 0.00 1.00 0.00 0.0041 1.00 1.00 1.00 1.00 1.0042 1.00 1.00 1.00 1.00 1.0043 1.00 1.00 0.00 1.00 1.0044 1.00 1.00 1.00 1.00 0.0045 1.00 0.00 1.00 0.00 1.0046 1.00 1.00 1.00 0.00 1.0047 1.00 1.00 0.00 1.00 1.0048 1.00 0.00 1.00 1.00 1.0049 0.00 1.00 1.00 1.00 0.0050 0.57 1.00 1.00 1.00 1.00ME AN 0.77 0.70 0.66 0.61 0.60ST D D E V 0.41 0.46 0.47 0.48 0.49VAR 0.17 0.21 0.22 0.23 0.24
9
Tab le B.6: Four/ Five Vehicle (min) P ermutat ions with Speed Recommendation
RUN 4in / 4out 4in / 5out 5in / 4out 5in / 5out1 1.00 1.00 0.00 0.002 1.00 0.00 0.00 1.00•).J 1.00 1.00 1.00 1.004 0.00 0.00 0.00 1.005 1.00 1.00 1.00 1.006 1.00 1.00 1.00 1.007 1.00 1.00 0.00 1.008 0.42 1.00 1.00 1.009 1.00 1.00 0.00 1.0010 1.00 1.00 1.00 1.0011 0.00 1.00 0.00 1.0012 0.00 0.00 1.00 0.0013 1.00 0.00 1.00 1.0014 0.00 1.00 0.00 0.001-5 1.00 0.07 0.00 1.0016 0.00 0.00 1.00 0.0017 0.00 0.00 1.00 0.0018 1.00 1.00 1.00 0.,5119 1.00 0.00 0.00 0.0020 1.00 0.00 0.00 1.0021 1.00 1.00 1.00 1.0022 0.00 0.00 0.00 0.0023 0.00 0.00 1.00 1.0024 0.00 1.00 1.00 1.0025 0.00 0.00 1.00 1.0026 0.00 0.00 0.00 1.0027 0.00 0.00 0.00 1.0028 0.00 0.00 0.00 0.0029 1.00 0.00 1.00 1.0030 0.00 1.00 0.00 1.0031 0.00 0.00 1.00 0.9232 0.00 0.00 0.86 0.0033 0.00 0.00 1.00 1.0034 0.00 0.00 0.00 0.0035 1.00 1.00 0.00 1.0036 1.00 0.26 1.00 0.8737 1.00 0.00 0.00 0.1338 1.00 1.00 1.00 1.0039 1.00 1.00 0.77 1.0040 0.00 1.00 0.00 0.0041 0.00 0.00 1.00 1.0042 0.00 1.00 0.00 0.0043 0.00 1.00 0.00 0.0044 1.00 1.00 1.00 1.004-5 1.00 1.00 1.00 0.0046 1.00 1.00 0.00 0.0047 1.00 1.00 1.00 1.0048 0.00 1.00 0.00 0.0049 0.00 0.00 0.36 1.0050 1.00 1.00 0.00 0.00MEANSTD DEV
o..s1o..so
0.530.49
0.500.49
0.630.47
VAR 0.2.5 0.24 0.24 0.22
9
Bibliography
[1] Franklin Antonio . Fast line segment int ersection. In Graphic Gems III, pages 199- 202, 500- 501. Boston: Harcourt Brace Jovanovich, 1992. David Kirk (edi tor).
[2] Michae l R. Benjamin. Fast-Cpa: A Layered Caching Algorit hm for Rapid Clos est Point of Approach Calculations in Marin e Collision Avoidance . In Marine Technology Society - Anchorage OCEANS, 2017.
[3] Captain Pete Small. Unmanned Mar it ime Systems Updat e, January 2019. url = htt ps:/ / www.navsea .navy.mil/ Port a1s / 103/ Documents / Exhibits/ SNA2019/ Un manned Marit imeSys -Small.pdf?ver = 2019-01-15-165105-297.
[4] Federal Register. Code of Fede ral Reg 11,lati ons - Ann11,al Edition. url htt ps:/ / www.govinfo.gov/ app/ collection / cfr.
[5] F ederal Regist er. Electronic Code of Fede ral R egulati ons. Legal Information Inst it ute: Cornell Law School. url = https:/ / www.law.cornell.edu / cfr / text .
[6] Dani el Gonza les and Sarah Harting. Designing Unmanned Syst ems with Great er Autonomy: Using a Federated , Partially Open Systems Architecture Approach. Technical report, RAND Corporation, 2014.
[7] Commandant United Stat es Coast Guard. Navigation rules, international inlan d/ U.S. Department of Transportation, United States Coast Guard. [Wash ington, DC] : T he Guard: [F or sale by the Supt. of Docs., U.S . G.P.O.], 1977-19, CG, 1999.
[8] Lucjan Gucma and Zbigniew Pietrzykowski. Ship Manoeuvring in Restricted Areas: An Attempt to Quantify Dangerous Situations Using a Probabilistic Fuzzy Met hod. The Journal of Navigation, 59(2):251- 262, May 2006. T he Royal Inst it ute of Nav igation.
[9] Sheng-Long Kao , Kuo-Tien Lee, Ki-Yin Chang, and Min-Der Ko. A Fuzzy Logic Method for Collision Avoidance in Vessel Traffic Service. The Journal of Navigation, 60(1):17- 31, January 2007. The Royal Inst it ute of Nav igat ion.
[10] Joseph William Leavitt. Intent-Aware Collision Avoidance for Autonomous Ma rine Vehicles. Master's thesis, Massachusetts Inst it ute of Technology, 2017.
9
[11] Stephanie Lefevre, Dizan Vasquez, and Christian Laugier. A survey on montion prediction and risk assessment for intelligent vehicles. ROBOMech Journal, l, January 2014. url = https:/ / doi.org/ 10.1186/ s40648-014-00 01-z.
[12] Bradley Martin, Danielle C. Tarraf, Thomas C. Whitmore, Jacob DeWeese, Cedric Kenney, Jon Schmid, and Paul DeLuca. Advancing Autonomous Sys tems: An Analysis of Current and Future Technology for Unmanned Maritime Vehicles. Technical report, RAND Corporation, 2019.
[13] Mike Benjamin. Introduction to AppCasting, June 2018. url https:/ / oceanai.mit .edu/ ivpman / pdfs/ app _ casting_ intro.pdf.
[14] Mike Benjamin. uFldCollisionDetect: Detecting Collisions, June 2018. url = htt ps:/ / oceanai.mit .edu / ivpman/ pdfs/ app _ ufld_ collision _ detect.pdf.
[15] MIT MOOS-IvP Project. A Very Brief Overview of MOOS. url = https:/ / oceanai.mit .edu/ ivpman/ pmwiki/ pmwiki.php?n = Helm.M OOSOverview.
[16] MIT MOOS -IvP Project. Design Considerations of MOOS-IvP. url = htt ps:/ / oceanai.mit .edu / ivpman/ pmwiki/ pmwiki.php?n= Helm.HelmDesign lnt ro.
[17] MIT MOOS-IvP Project. References in the Recent Literature Using MOOS-IvP (May 2019). url = http:/ / oceanai.mit .edu/ moos-ivp / users.
[18] Deborah J. Nightinga le and Donna H. Rhodes. Architecting the Future Enter prise. Cambridge, Massachusetts: The MIT Press, 2015.
[19] Andy Norris . AIS Implementat ion - Success or Failure? Journal of Navigation,60(1):1-10, January 2007.
[20] Ronald O'Rourke. Navy Large Unmanned Surface and Undersea Vehicles: Back ground Issues for Congress. Congressional Research Service, March 30, 2020. url= https:/ / fas.org/ sgp/ crs/ weapons / R45757.pdf.
[21] G.S Parnell, Driscoll P.J, and D.L Henderson. Decision Making in Systems Engineering and Management. John Wiley & Sons INC., 2011.
[22] L.P Perera, J.P. Carvalho, and C. Guedes Soares. Fuzzy logic based decision making system for collision avoidance of ocean navigation under critical colli sion conditions . Journal of Marine Science and Technology, 16(1):84 - 99, 2011. Published online 07 October 2010.
[23] Thomas Porathe. Transmitting intended and suggested routes in ship operations: cognitive off-loading by placing knowledge in the world. Work, (Volume 41) 2012.
[24] Roman Smierzchalski, editor. Evofotionary-Fuzzy System of Safe Ship Steering in a Collision Situation at Sea, International Conference on Computational Intelligence for Modelling, Control and Automation and International Confer ence on Intelligent Agents, Web Technologies and Internet Commerce, Vienna, November 2005. IEEE. Date Added to IEEE Xplore: 22 May 2006.
9
[25] Rafal Szlapczynski. Evolutionary sets of cooperating ship trajectories in multi ship. In Adam Weintrit, editor, Marine Navigation and Safety of Sea Trans portation, chapter 10.6, pages 443- 448. Taylor & Francis Group, London , June 2009.
[26] Rafal Szlapczynski. Evolutionary Sets of Safe Ship Trajectories: A New Ap proach to Collision Avoidance. The Royal Instit11,te of Navigation, 64(1):169-181, January 2011.
[27] Rafal Szlapczynski. Evolutionary Sets of Safe Ship Trajectories Within Traffic Separation Schemes. The Royal Instit11,te of Navigation, 66(1):65-81, January 2013.
[28] Rafal Szlapczynski. Evolutionary sets of safe ship trajectories with speed reduc tion manoeuvres within traffic separation schemes. Polish Maritime Research, 1:20-27, 2014.
[29] United States Coast Guard. Ports and Waterways Safety Act - NOAA Summary. url = htt ps:/ / coast.noaa.gov/ dat a/ Documents / OceanLawSearch / PortsandWaterwaysSafety Act.pdf.
[30] United States, Department of Defense. Unmanned Systems Integration Roadmap 2017-2042, August 2018. url = htt ps:/ / www.defensedaily.com / wp content / uploads/ post_ attachment / 206477.pdf.
[31 ] US Coast Guard. U.S Aids to Navigation System. url htt ps:/ / www.uscgboat ing.org/ images/ 486.P DF .
[32 ] US Coast Guard, Vessel Traffic Service New York. 2019 User's Man11,al. url = https:/ / homeport .uscg.mil/ Lists / Content / At t achments / 864/ VT S%20User's%20 Manual%20Revision %20November%202019.pdf.
[33] US Coast Guard, Vessel Traffic Service Puget Sound. 2019 User ' s Man11,al. url = https:/ / www.paci ficarea.uscg.mil / Port als/ 8/ Dist rict _ 13/ sect pugetsound / VTSpugetsound / 2019_ VTSPS _ UserManua l.pdf.
[34] ] US Nat ional Geospatial-Intelligence Agency. Maritime Saftey Information - No tice to Mariners. url = htt ps:/ / msi.nga.mil / NT M.
[35] F. Zhang, RN Marani, G. Smith, and H.T. Choi. Future Trends in Marine Robotics. IEEE Robotics 8 A11,tomation Magazine, 22(1):14 - 21, and 122, March 2015.
