Current Practice in Mission Planning in the Canadian Navy ... · planning process is broken into distinct portions, as in this paper, numerous tasks suitable for automation by the

Current Practice in Mission Planning in the Canadian Navy and Opportunities for Automation

T.R. Hammond DRDC – Atlantic Research Centre

Defence Research and Development Canada

Scientific Report

DRDC-RDDC-2017-R022

May 2017

Template in use: (2010) SR Advanced Template_EN (051115).dotm

© Her Majesty the Queen in Right of Canada, as represented by the Minister of National Defence, 2017

© Sa Majesté la Reine (en droit du Canada), telle que représentée par le ministre de la Défense nationale,

2017

DRDC-RDDC-2017-R022 i

Abstract

This paper reviews current practice in mission planning within the RCN, and identifies

opportunities for automation and decision support software. Tasks best suited to automation

follow established procedure and have a repetitive character, especially one that could induce

lapses in human attention. Tasks best left to humans are unique or require consideration of core

values or priorities. Every naval mission is unique, when considered as a whole, but when the

planning process is broken into distinct portions, as in this paper, numerous tasks suitable for

automation by the above criteria emerge. Many of these tasks could leverage tools created in the

project planning community. Many could leverage geographical information system tools and

navigation software. Many could incorporate models of sensor and communications performance,

and many could leverage tools for modelling vehicle movement. Statistical techniques for

representing uncertainty, both in measurements but also in intended movements, are highly

relevant. It has also been suggested that there could be an appropriate role for Track Suggestion in

mission planning. Commercial shipping companies are already using Track Suggestion

algorithms to route their ships around inclement weather and so save on fuel. Track Suggestion

will not find quite as significant a role in naval mission planning, largely because naval missions

have more complex goals, but it is not without niche applications. Overall, mission planning

should remain primarily a manual process, so the components of mission planning that aid the

decision maker in visualizing and evaluating issues are the most important. The paper offers a

few guidelines that should inform the assembly of the diverse tools above into a coherent

application environment that could effectively support mission planning.

Significance to Defence and Security

This paper considers how navies should go about planning missions and how software should

support them in the process. It lays out a vision for the appropriate role of technology in it. How

navies plan their missions can be expected to have a considerable impact on how successfully

mission goals are met. Thus, the considerations made here have considerable practical

significance for the Canadian Navy.

ii DRDC-RDDC-2017-R022

Résumé

Le présent document passe en revue les pratiques actuelles de planification des missions au sein

de la MRC et l’utilisation possible de logiciels d’automatisation et d’aide à la décision. Les tâches

se prêtant le mieux à l’automatisation suivent des procédures établies et ont un caractère répétitif,

ce qui pose un risque particulier de relâchement de l’attention. À l’opposé, les tâches qu’il vaut

mieux confier à des humains sont uniques ou bien nécessitent que l’on tienne compte de valeurs

fondamentales ou de priorités. Toutes les missions navales sont uniques si on les considère dans

leur ensemble, mais les scinder en tâches distinctes comme on le fait dans ce document permet

d’en dégager de nombreuses se prêtant bien à l’automatisation. Nombre de ces tâches peuvent

tirer parti d’outils créés au sein de la communauté de planification de projet, d’outils de systèmes

d’information géographique et de logiciels de navigation. D’autres pourraient intégrer des

modèles de performance des capteurs et des communications, et d’autres encore pourraient tirer

parti d’outils de modélisation des mouvements de véhicules. Les techniques statistiques de

représentation de l’incertitude, tant en mesures qu’en mouvements prévus, sont aussi très

pertinentes. On a également proposé que la suggestion de parcours joue un rôle approprié dans la

planification des missions. Les entreprises de transport maritime utilisent déjà des algorithmes

pour suggérer un itinéraire à leurs navires afin d’éviter les conditions météorologiques

défavorables et ainsi économiser le carburant. La suggestion de parcours ne joue certes pas un

rôle aussi important dans la planification des missions navales, surtout parce que les objectifs de

ces missions sont bien plus complexes, mais les créneaux d’application n’en sont pas moins

nombreux. En règle générale, la planification de mission doit demeurer un processus

essentiellement manuel. Par conséquent, les éléments qui aident les décideurs à visualiser et

évaluer les problèmes sont les plus importants. Le document propose quelques lignes directrices

qui devraient orienter la combinaison des divers outils mentionnés ci-dessus en un environnement

d’application cohérent qui pourrait appuyer efficacement la planification de mission.

Importance pour la défense et la sécurité

Le présent document porte sur la façon dont la marine devrait planifier ses missions et sur le

soutien que devraient lui apporter les logiciels. Il décrit une vision du rôle approprié que la

technologie pourrait jouer. On peut s’attendre à ce que la façon dont la marine planifie ses

missions ait une incidence considérable sur leur réussite. Les questions abordées ici sont donc

d’une grande importance pratique pour la Marine canadienne.

DRDC-RDDC-2017-R022 iii

Table of Contents

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i

Significance to Defence and Security . . . . . . . . . . . . . . . . . . . . . . i

Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii

Importance pour la défense et la sécurité . . . . . . . . . . . . . . . . . . . . ii

Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii

List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 Defining the Jargon . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Components of Mission Planning . . . . . . . . . . . . . . . . . . . 2

1.2.1 Task Planning and Management . . . . . . . . . . . . . . . . 2

1.2.2 Environmental Condition Forecasting . . . . . . . . . . . . . . 3

1.2.3 Projecting Vehicle Movement . . . . . . . . . . . . . . . . . 3

1.2.4 Environmental Response Modelling . . . . . . . . . . . . . . . 3

1.2.5 Sensor Modelling . . . . . . . . . . . . . . . . . . . . . . 4

1.2.6 Communications Modelling . . . . . . . . . . . . . . . . . . 4

1.2.7 Track Evaluation . . . . . . . . . . . . . . . . . . . . . . 5

1.2.8 Track Suggestion . . . . . . . . . . . . . . . . . . . . . . 5

1.3 Voyage Plan Vision . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4 Structure and Aims of the Paper . . . . . . . . . . . . . . . . . . . 6

2 Task Planning and Management . . . . . . . . . . . . . . . . . . . . . 7

2.1 Current Practice . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Leveraging Project Planning Tools . . . . . . . . . . . . . . . . . . 9

2.2.1 How Mission Planning is Like Typical Project Planning . . . . . . . 10

2.2.2 Concerns Particular to Planning a Voyage . . . . . . . . . . . . . 11

2.2.2.1 Generalized Task Dependencies . . . . . . . . . . . . . 11

2.2.2.2 Event Reports . . . . . . . . . . . . . . . . . . . . 12

2.3 Route and Track Construction and Editing . . . . . . . . . . . . . . . 14

2.3.1 Defining Routes with Waypoints . . . . . . . . . . . . . . . . 14

2.3.2 Route Editing . . . . . . . . . . . . . . . . . . . . . . . 14

2.3.3 Converting Routes to Tracks . . . . . . . . . . . . . . . . . . 14

3 Environmental Condition Forecasting . . . . . . . . . . . . . . . . . . . 17


3.1.1 Significant Weather Prognosis and Surface Analysis . . . . . . . . . 17

3.1.2 Wind . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.3 Waves . . . . . . . . . . . . . . . . . . . . . . . . . . 19

iv DRDC-RDDC-2017-R022

3.1.4 Currents . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.5 Satellite Photos. . . . . . . . . . . . . . . . . . . . . . . 21

3.1.6 Fog . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1.7 Ice . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2 Alignment with Track Suggestion Requirements . . . . . . . . . . . . . 25

3.3 Baseline Conditions . . . . . . . . . . . . . . . . . . . . . . . . 26

3.4 Visualization . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.5 The Consequences of Shore-Based NWP Models . . . . . . . . . . . . . 28

4 Projecting Vehicle Movement . . . . . . . . . . . . . . . . . . . . . . 29


4.1.1 Own Ship Understandings . . . . . . . . . . . . . . . . . . 29

4.1.2 Friendly Forces . . . . . . . . . . . . . . . . . . . . . . 29

4.1.3 Neutral Shipping . . . . . . . . . . . . . . . . . . . . . . 30

4.1.4 Hostile Forces . . . . . . . . . . . . . . . . . . . . . . . 30

4.2 New Perspectives . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2.1 Own Ship . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2.2 Friendly Forces . . . . . . . . . . . . . . . . . . . . . . 33

4.2.3 Neutral Shipping . . . . . . . . . . . . . . . . . . . . . . 34

4.2.4 Hostile Vehicles . . . . . . . . . . . . . . . . . . . . . . 34

5 Environmental Response Modelling . . . . . . . . . . . . . . . . . . . . 37


5.2 Converting Routes to Tracks Automatically . . . . . . . . . . . . . . . 38

5.2.1 Route to Track Conversion Under Fixed Conditions . . . . . . . . . 39

5.3 Predicting Indices of Environmental Risk . . . . . . . . . . . . . . . . 43

5.4 Dealing with Uncertainty . . . . . . . . . . . . . . . . . . . . . . 44

6 Sensor and Communications Modelling . . . . . . . . . . . . . . . . . . 45


6.2 Modelling Approaches . . . . . . . . . . . . . . . . . . . . . . . 45

6.2.1 The Simple Disc or Cookie Cutter Model . . . . . . . . . . . . . 45

6.2.2 The Double Disc Model . . . . . . . . . . . . . . . . . . . 46

6.2.3 Handling Altitude . . . . . . . . . . . . . . . . . . . . . . 46

6.3 Visualizing Model Predictions on a Chart . . . . . . . . . . . . . . . . 47

7 Track Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

8 Track Suggestion . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

8.1 Application to the Navy Context . . . . . . . . . . . . . . . . . . . 49

8.1.1 AWT’s (Storm Geo) Bon Voyage System and EnRoute . . . . . . . . 49

8.1.2 FORCE Technology’s Sea Planner . . . . . . . . . . . . . . . 50

8.1.3 Jeppesen’s Vessel and Voyage Optimization Solution (VVOS) . . . . . 51

8.1.4 MeteoGroup’s Ship Performance Optimization System (SPOS) . . . . . 51

8.1.5 Suitability for Naval Mission Planning . . . . . . . . . . . . . . 52

8.2 Responsible Track Suggestion . . . . . . . . . . . . . . . . . . . . 52

DRDC-RDDC-2017-R022 v

9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

List of Symbols/Abbreviations/Acronyms/Initialisms . . . . . . . . . . . . . . . 61

vi DRDC-RDDC-2017-R022

List of Figures

Figure 1: This figure provides an example of the sort of analysis of fronts, clouds and

weather systems that the CF Weather Office provides. . . . . . . . . . . 18

Figure 2: An illustration of the sort of predictions of wind speed available from the CF

Weather Office website. . . . . . . . . . . . . . . . . . . . . . . 19

Figure 3: An illustration of the sort of predictions of wind and wave speeds, heights and

directions that are available from the CF Weather Office website.. . . . . . 20

Figure 4: A prediction of wave conditions that includes information on the wave period

as well as the wave height and direction. . . . . . . . . . . . . . . . . 20

Figure 5: An illustration of the sort of predictions of current speeds that are available

from the CF Weather Office website. . . . . . . . . . . . . . . . . . 21

Figure 6: This is a typical satellite image of weather systems, which is available at

regular intervals on both coasts through the CF Weather Office website. . . . 22

Figure 7: An illustration of the sort of predictions of sea surface temperature available

from the CF Weather Office website. . . . . . . . . . . . . . . . . . 23

Figure 8: An illustration of the sort of predictions of ice cover that are available from the

CF Weather Office website. . . . . . . . . . . . . . . . . . . . . . 24

Figure 9: This figure gives an overview of the information provided in by the ‘ice egg’

used by Environment Canada. . . . . . . . . . . . . . . . . . . . . 25

Figure 10: A screenshot from the Oceanweather Display System (ODS), showcasing its

ability to display global wind speed and wave height forecasts. . . . . . . . 27

Figure 11: The COA matrix in which opposing force COAs, depicted in columns, are

evaluated against friendly force COAs, shown in the rows. . . . . . . . . 31

Figure 12: A rough indication of the movement of a ship could be captured by adding

circles to its various turn waypoints. . . . . . . . . . . . . . . . . . 33

Figure 13: This figure shows coloured contour lines of the density for the location of a

particular ship (referred to as “ship 2”) at a particular instant in time (12 hours

after the ship was first seen). . . . . . . . . . . . . . . . . . . . . 35

Figure 14: This figure shows the areas where a particular allocation of search effort (a

week’s worth of patrol flights, indicated by dashed lines) was most effective. . 36

Figure 15: An illustration of the route of a ship (shown in orange) through a region on the

ocean, over which wind speed and direction data are available over a coarse

grid. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Figure 16: This figure illustrated the problem of identifying which rectangles in a regular

grid are intersected by a given line segment. . . . . . . . . . . . . . . 40

Figure 17: An illustration of determining which intervals along a regular one-dimensional

grid (resembling a black ruler) are intersected by a given line segment (shown

in orange). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

DRDC-RDDC-2017-R022 vii

Figure 18: It can be effective to consider the problem row by row. . . . . . . . . . . 41

Figure 19: Considering just the portion of the segment in row 4, this is quickly seen by

projection to intersect on cells in columns 3 and 4. . . . . . . . . . . . . 42

Figure 20: Considering just the portion of the segment in row 5, this is quickly seen by

projection to intersect on cells in columns 4 and 5. . . . . . . . . . . . . 43

Figure 21: This sequence of images describes the dangerous phenomenon of broaching. . 44

Figure 22: The three portions of this figure each suggest a different

detection/identification model. . . . . . . . . . . . . . . . . . . . . 46

viii DRDC-RDDC-2017-R022

List of Tables

Table 1: Mission planning tasks that could be effectively supported by automation. . . 54

DRDC-RDDC-2017-R022 ix

Acknowledgements

I gratefully acknowledge the assistance of Lt(N) Scott Colbourne, Fleet Navigation Instructor at

the Canadian Forces Naval Operations School, who provided advice on existing practices in

navigation planning. I also acknowledge the advice of Lt(N) Cam Prescott, NavO on HMCS

Montreal, for his views on the current state of mission planning and how to improve it. This work

was funded by the Predictive Situational Awareness (PSA) task of DRDC – Atlantic Research

Centre’s Integration of Command Decision Support project (01db).

x DRDC-RDDC-2017-R022

This page intentionally left blank.

DRDC-RDDC-2017-R022 1

1 Introduction

This Scientific Report reviews current mission planning practice within the Royal Canadian Navy

(RCN) and identifies opportunities for automated decision aids to play a role in it. A key premise

of this document is that mission planning should leverage the experience of the broader project

planning body of knowledge [1]. This premise is justified because project planning practice has

been honed and refined by considerably more practical experience. Indeed, project planning

practice has guided the approach taken here: just as a large project is planned by breaking it into

smaller tasks, this document divides the mission planning process into eight separate components.

The results of such division naturally yield parts simpler than the whole. If such division is

carried out to sufficient extent, eventually subtasks will be found that are sufficiently simple and

straightforward that they could safely be entrusted to a computer. Automating such tasks can

yield benefits, when the automation would perform them faster or more accurately than a human.

It may even yield benefits when the computer is not clearly doing the task better, provided that

the humans normally doing it are freed up to engage in more important pursuits. Thus, this paper

is about identifying these potential benefits.

In considering the potential for automation, it is important to consider previous experience, as

tasks have been automated unsuccessfully [2]. Tasks suitable for automation have particular

characteristics [3]: they follow a recognizable, repeated pattern that allows algorithms to be

brought to bear. They may involve maintaining focus for extended periods, a task that most

humans find particularly difficult. They may involve tedious computations in which humans will

be prone to error. This paper identifies opportunities for automation by finding tasks with these

characteristics, but it also considers existing products and solutions. One such solution is Weather

Routing [4], which is here discussed under the name of Track Suggestion. The paper suggests

tools based on ideas from general project planning, charting software and Geographical

Information Systems (GIS).

Thus, this document offers a perspective on how best to support mission planning for ships of the

Canadian navy in future. Such support would involve the use of software to help the navy plan a

ship track for a given mission and then evaluate the track, visualize it or modify it. For example, a

proposed ship track might be evaluated by its expected total fuel consumption, or even by a

custom measure of how effectively it would contribute to the completion of mission goals.

Modifications to a proposed track might be made manually, using various user interface tools, but

mission planning software could also suggest optimal tracks, by various criteria. When the

process is automated, it is referred to here as Track Suggestion. A typical use of this suggestion

feature would be to compute a track from start point (A) to destination (B) that would optimize

fuel consumption, while also avoiding land obstacles. Such optimization could take expected

weather and other environmental conditions, like currents, into account. Commercial shipping

companies are already using Track Suggestion software to help route their ships in such a way as

to minimize the impact of storms, especially on fuel consumption. Given this precedent, the

question naturally arises as to whether Track Suggestion could make an equally effective

contribution to naval mission planning.

In short, this paper suggests a vision for what support to Naval Mission Planning should be like in

the longer term. In pursuing this goal, the paper focuses on those parts of mission planning that

support the creation and evaluation of possible Courses of Action (COAs) for a given mission,

2 DRDC-RDDC-2017-R022

especially insofar as these COAs involve different routes. The paper gives due consideration to

the ways that planning a naval mission differs from planning a typical large project.

1.1 Defining the Jargon

This section defines three key terms, to avoid confusion in subsequent discussion:

Waypoint: A point defined by an ordered triple, composed of latitude, longitude and depth.

In this representation, the latitude and longitude identify where a vector from the centre of

the earth through the waypoint would intersect the surface of the ocean (at low tide), and the

depth identifies the distance from the waypoint to the surface, along this same vector, which

runs opposite to the pull of gravity. When speaking of waypoints for surface-bound ships,

the depth can be dropped on the understanding that it is zero, so that the waypoint simplifies

to an ordered pair.

Route: A representation of the path that a ship might follow between a given departure

waypoint A and destination waypoint B. A route can be represented as an ordered list of

waypoints, starting with A and ending with B. Implicit in this representation is a rule for

how the ship will sail between each pair of consecutive waypoints. There are a number of

options: the ship might sail along the line of constant bearing (the rhumb line), along the

great circle route (which approximates the earth as a sphere), or along the geodesic arc

(which acknowledges that the earth is really an oblate spheroid). Where there are changes in

depth between two successive waypoints, the vessel would most naturally be taken to

change depth linearly between them.

Track: A representation of the trajectory of a ship through space and time. It defines both

the route taken and the time at which each waypoint was reached, or will be. When the track

extends into the future, it gives the Estimated Time of Arrival (ETA) at each waypoint along

the route. It must be understood from the context whether a given track represents an actual

voyage or a plan for one.

1.2 Components of Mission Planning

Mission planning has eight components that will each be described briefly in this section. A

strategy for supporting mission planning for the RCN could be characterized by its allocation of

effort and resources to these components. A good strategy is one that will achieve component

quality in proportion to importance. Thus, it makes sense to rank the components by their

importance to the planning process. This section presents these components in decreasing order of

importance, along with remarks justifying this ranking. The first three components, and a small

component of the fourth, are the most crucial, while the latter ones involve additional

considerations that will become increasingly relevant as automation takes on a greater role in the

planning process. This paper will express reservations about the current readiness of automation

to play this more trusted role.

1.2.1 Task Planning and Management

There are already a number of widely-used project planning tools, Microsoft Project being but

one example. These assist the humans planning a project in breaking it down into smaller tasks,


typically called Work Breakdown Elements (WBEs). The tools also help set milestones, assign

people and equipment to tasks, identify slack time and identify the critical path [1]. Tasks on the

critical path have the property that any delays to their completions will delay the completion of

the whole project. In most respects, planning a naval mission is like planning any other project,

but there are a few concerns that are particular to the maritime context (as illustrated in

subsequent components). As a result of this resemblance, leveraging prior art in project planning

has the highest priority among the eight components of mission planning.

1.2.2 Environmental Condition Forecasting

The weather at sea, the state of the waves, as well as the tides and currents can all have an impact

on the success of a naval mission. Thus, it is important to forecast these conditions over the

mission area. Many of these predictions are derived from Numerical Weather Prediction (NWP)

models. The importance of these forecasts raises natural questions about what resolution and

spatial extent are required, about how often forecasts should be updated, and about how to deal

with the uncertainty inherent in all predictions of the future. The vital importance of weather to all

sea travel makes this component crucial for any tool hoping to support mission planning.

1.2.3 Projecting Vehicle Movement

Naval missions are not only affected by the movement of the decision maker’s own ship, but

often also by the movement of other vehicles, typically ships or aircraft. These other vehicles can

be friendly, neutral or hostile. Friendly vessels will often be part of a naval coalition, the overall

course of which is determined by the flag ship, with other vessels holding formation about her.

Thus, anticipating the implications of holding formation relative to other ships could be useful.

Neutral vessels can also affect the course of certain missions: fish patrols come to mind as an

obvious example. In these missions, the route of the naval ship is determined only roughly at the

initial planning stage, with the actual track taken dictated on the fly, in response to the shipping

traffic encountered. Last but not least, the classic naval mission calls on the ship to locate and

engage (or avoid) hostile forces. The success of particular missions may turn on the RCN’s ability

to anticipate the motion of adversaries, with due consideration of uncertainty. The fact that

movement modelling and projection could assist in planning the classic naval engagement argues

for its central role in mission planning. In short, decision makers would benefit from support to

their considerations of what tracks other ships might take.

1.2.4 Environmental Response Modelling

Just as environmental conditions can be important to the success of a naval mission, it is equally

important to be able to evaluate their implications. For example, if 50 knot headwinds and

7 metre swells are anticipated, the role of Environmental Response Modelling would be to help

the decision makers anticipate the implications for the ship, her engines, her crew, as well as for

key equipment on board, like cranes, helicopters, or Unmanned Vehicles. Thus, the role of

Environment Response Modelling is to anticipate risks to the mission that are due to the

prevailing environmental conditions. Typical questions for such modelling address whether or not

the ship will be able to launch and recover her helicopter, fire her gun, launch her missiles, deploy

small boats, and so on. It could help anticipate degradation in crew performance from


seasickness. It could help anticipate weather-related dangers to the ship, like ‘broaching to’ or

‘hull slamming’. It should definitely help estimate how much fuel the ship can be expected to

consume over the course of the mission, as this estimate is always required in planning. An

experienced commander can be expected to be very effective at evaluating environmental

implications, so it will prove challenging to find an appropriate role for automation [2], a role that

the humans can come to trust. In tasks that humans do well, such trust is particularly hard-earned

[3]. Environmental Response Modelling should give careful consideration to which tasks are most

amenable to automation and which should be left to the humans.

1.2.5 Sensor Modelling

Sensor modelling determines whether the various vehicles involved in a mission scenario will be

able to detect or identify one another. As a general rule, identification is considerably more

demanding of sensors than mere target detection, but self-reporting systems, like the Automatic

Identification System (AIS), now identify the majority of commercial shipping, simplifying the

task in peaceful times. It should be noted that this topic raises an interesting dimension to mission

planning: it could be important to consider not only what a naval ship would know of its enemies,

but also what these enemies would know of it. In other words, it involves a degree of speculation

about what is going on in the heads of adversaries. Supporting such considerations effectively

with software tools would have to be characterized as very challenging. If these complications are

not enough, sensor performance can be expected to be influenced by environmental conditions,

like fog or sea state. This component should leverage existing models for the various domains

(acoustic, Electro-magnetic (EM), visual, infrared (IR)). In general, it is much easier to apply

these models to Canada’s own naval sensors, whose properties are known, than it is to apply them

to other ships, especially those of enemies. The latter involves speculation as to what kind of

sensors these platforms might have been equipped with, unless relevant intelligence reports are

both available and thorough. Dealing with this added layer of uncertainty favours the use of very

simple models. The considerable difficulties involved have led this paper to assign relatively low

priority to sensor modelling in mission planning support. Moreover, it would be advisable to

focus on modelling Canada’s own naval sensors, leaving worries about opponent capabilities to

the human decision maker.

1.2.6 Communications Modelling

Like Sensor Modelling, this component has a role that pertains to the platforms participating in a

naval mission, whether these be ships, aircraft, shore stations, vehicles, army units or whatever

else may be relevant. It asks whether these platforms can communicate with each other, as they

move relative to one another over the course of the mission, using their available communications

technology. Typically, this can be expected to involve anticipating VHF radio coverage, but there

is certainly more to this component than just that. It is often enough, for the purpose of mission

planning, to approximate VHF radio coverage by the line of sight, so this component is assigned a

low priority. More complex and realistic models are certainly available (e.g., [5]), and they could

be important to the success of particular missions.


1.2.7 Track Evaluation

There are many ways in which one could measure the performance of a proposed track for a naval

ship on a particular mission. Indeed, naval missions could often be described as having multiple,

sometimes conflicting goals. For instance, a fish patrol might seek to identify as many fishing

vessels as possible, while also conserving fuel, avoiding bad weather and arriving on time for a

refueling rendezvous with a tanker. Some of these measures might involve risks to the ship, such

as the probability of a hull slamming event that could damage hull integrity. As varied as these

Measures of Performance (MOPs) might be, there are a few among them that have recurring

value, as they are worthy of consideration regardless of the specific mission. These fundamental

measures could well include some that pertain to the safety of the ship or its crew, but they

definitely include estimates of fuel consumption and time spent at sea. Estimating arrival time and

fuel consumption is so fundamental to ship travel that mission planning can be improved simply

by improving or facilitating it. Track evaluation in general has relatively low priority because it

would rely on all the other components of mission planning to compute particular MOPs, but

supporting the fundamental measures like fuel consumption has a priority far above the general

case. In this paper, estimating fuel consumption is considered part of Environmental Response

Modelling.

1.2.8 Track Suggestion

In theory, the MOPs that pertain to a track for a given naval mission could be combined into an

overall Measure of Effectiveness (MOE) for the track. This MOE could be regarded as a kind of

objective function that mission planning should try to optimize. Indeed, Track Suggestion could

be regarded as a problem in optimizing the MOE by modifying the mission track. This view has

the advantage of letting mission planning leverage general optimization techniques. Despite this

advantage, this approach is not advocated here because having the decision maker specify a

custom numeric objective function for a mission is very challenging, both for the software but

also for the decision maker. Instead, proposed tracks for a mission could be produced in a

semi-supervised manner. In this approach, the decision maker would manually construct portions

of the track to address the more complex mission goals, leaving the software to fill in portions

during which the ship could be said to follow simple, predefined objectives, like minimizing fuel

consumption or transit time. Such a limited role for Track Suggestion is not without promise.

1.3 Voyage Plan Vision

The overall vision of mission planning support that emerges from the ranking above is that it

should be like typical project planning support, but with a few added components that address the

particular characteristics of planning a sea voyage. Most of these particular characteristics would

predict environmental conditions, but some should also try to anticipate the movements of other

vehicles. Mission planning should facilitate the estimation of fuel consumption, under the

anticipated weather conditions. There may be a role for Track Suggestion, in situations where the

ship has simple objectives like conserving fuel, but good support for mission planning can be

achieved without it.


The design of support to mission planning should be guided by three fundamental principles:

1. Interactive Drill-Down: The detailed components of a plan should be hidden, especially in

overview presentations, and only presented selectively, on demand. This is so as not to

overwhelm the human users with details they do not need. Plans get complicated fast.

2. A Plan Answers Who, What, When, Where and How: These fundamental questions each

suggest a different perspective on, or way of looking at, a mission plan. Each question thus

should form the basis of a visualization component in the mission planning support software.

For example, a Gantt chart [1] provides a “When” visualization of a plan, while showing the

planned route for the ship on a chart (with tasks depicted as symbols along the route),

provides a “Where” visualization of it. A “Who” visualization would list participating

individuals and show which activities they were involved in. A “How” visualization would

reveal what methodologies, techniques or tools will be employed in the completions of tasks.

A “What” visualization would reveal the objectives, deliverables and risks associated with the

various WBEs.

3. Linked Components: The Who, What, When, Where and How components should be

linked to one another by the interactive drill-down principle. Thus, when looking at the

When visualization, the user could drill down into Who, to see who was involved at particular

times. Or they might come at things the other way, drilling into When from the Who

visualization, to see the times when a particular individual was involved in the mission.

Looking at Where visualization, they could drill into the What, to see objectives in play at

particular locations. Looking at How they could drill into When, to see when particular

techniques were being employed. The user could keep drilling down in similar fashion until

all five questions were answered, or they could leave some components unopened to provide

a higher level summary.

These three principles, taken together, provide the vision for how planning should be done and

what a plan might be. The challenge is in the details. Above all, a plan should be interactive.

1.4 Structure and Aims of the Paper

This paper is structured around the components of mission planning, as described briefly above.

Each will be revisited in greater detail below, in the same order of perceived importance, with the

aim of clarifying and elaborating on the component’s role, how this role is currently captured in

the existing mission planning process, and suggesting improvements. Each section will identify

some of the challenges involved in making these upgrades, suggesting approaches to them and, in

some cases, weighing these approaches against alternatives. The paper will try to identify the

scientific challenges posed by each component, suggesting where further research should play a

role. The conclusion will summarize recommendations for how automation could play a role in

mission planning, making the process not only be faster and easier, but also offering new

capabilities to those responsible for shepherding the mission to its successful conclusion.


2 Task Planning and Management

2.1 Current Practice

Currently, mission plans are developed and presented in Microsoft PowerPoint. Various other

software sources, like the Electronic Chart Display System (ECDIS) used to navigate the ship and

Google Earth, contribute imagery for use in these plans, and Microsoft Excel figures in the

construction of the colour coded tables in which proposed COAs are depicted, but beyond these

tools, mission planning is not supported by dedicated software. Tasks to be accomplished during

the mission are represented in a detailed schedule called the FLEX, which is typically either a MS

Word® document or an EXCEL spreadsheet, generally maintained by one of the Operations

Room Officers (OROs). This means that the planned mission track and the FLEX are maintained

in different applications, so they must be kept consistent through crew diligence. Determining just

where the ship will be during a given FLEX task requires the crew to consult the ECDIS

application. Project planning tools, like Microsoft Project, have not found a role in mission

planning. Thus, a new tool that is customized to the Naval mission planning context would fill a

gap in capability.

This paper will suggest that there is a distinction to be made between mission planning and more

specialized navigation planning, even though there is clearly some overlap between the two

processes. The former is the subject of this paper while the latter deals with safely navigating the

ship in pursuit of the agreed higher level mission strategy.

At present, navigation planning is conducted largely in the ship’s ECDIS, which is called

ECPINS. ECPINS is a computerized, shipboard navigational aid that displays electronic charts,

the ship’s position in real time, and sensor data. ECPINS, also called SHip’s INtegrated

Navigation And Display System (SHINNADS) for the customized RCN version, is developed

and maintained by OSI Maritime Systems. Installation across the RCN surface and subsurface

fleet started in 1989. The system will continue to be maintained and upgraded until 2020, with

options to extend for up to an additional 20 years. SHINNADS has one module for planning a

ship track (RTPLAN) and another for monitoring the ship’s progress (RTMON). RTPLAN also

serves as a backup to RTMON, having the same capabilities, though it is not typically connected

to the sensor feeds.

Within the RCN, CFCD130 – Canadian Navigation Manual [6] provides the authoritative text on

navigation policy. CFCD130 outlines the requirement for navigation planning. It indicates that,

while the Commanding Officer (CO) bears ultimate responsibility for the safe navigation of the

ship, it is normal practice to delegate navigation and pilotage to the Navigating Officer (NavO).

This manual indicates that each navigation passage, regardless of complexity, shall be planned for

visual and reduced visibility execution. All passage plans shall be approved by the CO and the

planned route will be saved and locked in SHINNADS for passage execution. In coastal waters

and in the open ocean, the Officer of the Watch (OOW) normally executes the NavO’s plan. In

pilotage waters, the NavO will normally execute the navigation passage, though the CO may

delegate these tasks to others for training purposes.


A Navigation Plan is not just composed of a planned route for the ship, drawn up in the RTPLAN

module of ECPINS. It is also comprised of annotations that are typically drawn on the charts, but

which may also be added to the OOW notebook. These provide supplementary information, such

as the positions and times at which lights will be sighted. Any dangers, hazards, action points, or

areas of concern must be highlighted for the OOW’s attention. All information that will affect the

ship’s movement through a particular passage must be clearly displayed. The symbols and

elements that may be added to the chart include the following:

1. Limiting Danger Lines (LDL): these mark the extent of safe water and serve as the

foundation for all navigation plans. LDLs are calculated in the following manner:

LDL = Draught + Safety + Squat – Height of Tide (HOT). An additional consideration for

swell should be calculated when it will be encountered. The standard for the safety

calculation is 2 meters, but this may be reduced with the CO’s concurrence.

2. Clearing Bearings: these visual bearings (relative to prominent terrestrial objects, like

lighthouses) delimit the area of water in which it is safe to navigate.

3. Clearing Depths: these depths (which will be compared to measurements from the ship’s

echo sounder) are used when visibility is so degraded that the Clearing Bearings become

impractical.

4. Labels: these three digit numbers, which are used to distinguish between various routes and

tracks, are placed on the north side of them. An open arrowhead indicates the direction of

travel. The course to steer, to compensate for currents or wind, may also be indicated in

brackets.

5. Wheel-Over Lines: these markers (which use an open arrowhead symbology) are helpful in

the execution of course alterations.

6. Distances to Go: these distances to the destination are indicated with circular symbols (with

a ‘leader’). They are helpful in making revised predictions of arrival time, and may thus

suggest the need to accelerate, to make up for lost time.

7. Chart Changes: the need to switch to another chart is indicated with parallel lines that will

be accompanied by the new chart number.

8. Ship Handling and Manoeuvering Evolutions: these are indicated on the chart with scale

drawings of the ship accompanied by arrows indicating the desired motion of the bow.

9. Command Decision Points: these ‘thought bubble’ symbols indicate positions at which a

decision between two or more predetermined COAs must be taken.

10. Point of No Return (PNR): A PNR indicates the point at which the ship can no longer break

off from the plan or take alternative action (such as anchoring until there is better weather).

All PNRs are required to have an associated Command Decision Point, but no reverse

requirement exists.


11. Check Bearings: these are used to assist the ship in making turns greater than 60°, especially

in the presence of hazards. A number of different procedures for making course changes are

available.

The list above is intended to suggest that the procedures and practices surrounding navigation

planning are rooted in longstanding naval practice, practice that has become tightly integrated

with the SHINNADS software in which it is largely conducted. Planning software should not

attempt to supplant the established role currently played by SHINNADS; instead, it should have

the ability to export any initial route or track suggestions produced to SHINNADS. Moreover, it

would need the ability to import routes and tracks back in from SHINNADS, once these have

been refined by the navigation plan. Such import should include some of the associated

annotations and symbols that are introduced by navigation planning.

2.2 Leveraging Project Planning Tools

It is important to consider how mission planning can leverage tools that have already been

developed in the project planning community because these tools have given a great deal of

thought to the planning process. A naval mission can be viewed as a project because it is also

composed of many tasks that each require people, time and equipment to complete.

The project planning community teaches that a good plan should include cost estimation, as well

as management of quality, human resources, communications, procurement, and stakeholders [1].

All of these considerations remain valid in planning a naval mission. As in project management, a

key use of the plan will be to monitor progress towards mission completion.

Another key lesson from project planning concerns risk. It will come as no surprise that a naval

mission may be subject to risks that might compromise individual tasks, and even the entire

mission. The most significant of these should be given due consideration in project planning.

Thus, a plan should identify risks and incorporate some degree of risk analysis. While no one can

be expected to anticipate every eventuality, it pays to consider what might go wrong and what the

impact would be. This is especially true when measures could be taken to mitigate these risks.

Mission planning should leverage project planning tools for this, to the extent possible.

Prussian General Helmuth von Moltke, the elder, said that no plan survives first contact with the

enemy. To the extent that this is true of naval operations, mission planning should facilitate

modifications to the initial plan. This consideration reveals the value of representing a plan in

software, as an interactive document, as opposed to in a static PowerPoint file. Such

representation helps identify which tasks would be impacted by a proposed change. In other

words, it helps the plan be more agile.

Though general experience in project planning should be helpful, it is worth remembering,

however, that naval operations sometimes involve enemies. The potential presence of these

opponents, who will surely try to prevent mission success, suggests an added component of risk

that goes well beyond that which is present in typical project planning. Few construction projects,

for example, need consider the possibility that workers might come under hostile fire. This

suggests that risk assessment and mitigation will have a more prominent role in naval mission

planning than they do in more general project plans. If so, that role is prominent indeed.


2.2.1 How Mission Planning is Like Typical Project Planning

Viewing a naval mission as a kind of project allows mission planning to take advantage of all the

insights and lessons that the considerably broader project planning body of knowledge [1]

provides. For example, project planning experience suggests that the planning process involves

breaking down larger goals into smaller, more manageable components. Moreover, this

breakdown process should continue until the component tasks produced have a straightforward

implementation, following established procedure. These straightforward tasks will here be called

WBEs, in deference to project planning convention. The fact that these WBEs follow known

procedure helps the planners to estimate the resources required by them, as the planners can bring

their experience to bear on the matter.

A naval mission will necessarily require its developers to define WBEs, sequence these, estimate

the required resources, estimate task durations, and put this all together into a schedule. The Gantt

Chart representation of this schedule, which shows the start and end times of the WBEs on the

overall project timeline, has proven to be an effective tool in depicting a project plan, as well as in

tracking progress towards completion. A Gantt chart is a bar chart of schedule information where

activities are listed on the vertical axis, dates are shown on the horizontal axis and activity

durations are shown as horizontal bars paced according to start and finish dates (or times) [1].

Mission planning should facilitate the construction of Gantt charts. Indeed, Gantt charts should

provide the basis for the “When” visualization of the mission plan suggested above.

Like a project, a naval mission always has a set of WBEs that are critical to mission success, any

delays to which will push back completion (these are said to lie on the critical path). The critical

path is defined by the sequence of activities that represent the longest path through a project. The

critical path determines the shortest possible duration for the project as a whole. Like a project, a

mission may also have other WBEs that can safely be moved or delayed without compromising

other tasks. It may have tasks with slack time. And like a project, a mission will have

relationships between some of its WBEs: some must be finished for others to start (the most

common case), but less common dependencies between tasks are also possible.

These WBE dependencies are defined as follows:

1. Finish-to-Start: A logical relationship in which a successor activity cannot start until a

predecessor activity has finished.

2. Finish-to-Finish: A logical relationship in which a successor activity cannot finish until a

predecessor activity has finished.

3. Start-to-Start: A logical relationship in which a successor activity cannot start until a

predecessor activity has started.

4. Start-to-Finish: A logical relationship in which a successor activity cannot finish until a

predecessor activity has started.

These dependencies have a temporal character, so they will here be called “When” dependencies.

Other kinds of task dependencies, produced by generalizing these concepts, as suggested by the

plan visualization components outlined above, should prove helpful in mission planning. In other


words, in addition to the “When” ones above, there could also be “Where”, “What”, “How” and

“Who” task dependencies. Examples of these are suggested below.

2.2.2 Concerns Particular to Planning a Voyage

Naturally, planning a voyage will involve some element of vessel movement over water (or

through it, in the case of submarines), so concerns pertaining to such motion are more pertinent

than they would be in typical project planning. These concerns clearly include the risks of sea

travel, such as storms. In other words, there is a spatial dimension to the planning process that is

not always present in general. The implications of this added dimension must be given due

consideration.

2.2.2.1 Generalized Task Dependencies

One of the implications of that spatial dimension is that WBEs could have “Where”

dependencies. These capture the idea that, in a naval mission, certain tasks might require the ship

to be in a certain location. For example, a ship might have to be at an ammunition depot in order

to take on munitions.

In practice, these “Where” relationships would be defined with reference either to a particular

area on the surface of the globe, either a circular one centred at a particular waypoint or a

polygonal one. Let this area be denoted by R. The two possible “Where” task dependencies are as

follows:

1. Area-to-Start: A logical relationship between a WBE and an area (R) in which the WBE

cannot start until the ship is in R. For example, the ship must be within artillery range of a

land target to begin firing at it with its guns.

2. Area-to-Finish: A logical relationship between a WBE and an area (R) in which the WBE

cannot finish until the ship is in R. For example, the ship might have to be within VHF radio

range of a shore facility in order to transmit a progress report to that facility.

It is possible to generalize the two relationships further by allowing not just a single area, but

collections of areas. For example, a certain activity might require the ship to be in port, but any

one of a collection of ports might serve equally well. Generalizing the two “Where” task

dependencies to collections of areas is straightforward.

Similarly, there could also be “Who” dependencies. These capture the idea that sometimes certain

individuals are crucial to accomplishing tasks. For example, launching a helicopter requires a

qualified pilot. This idea naturally suggests the following new task dependencies:

1. Person-to-Start: A logical relationship between a WBE and a specific person in which the

WBE cannot start until the person is on hard.

2. Person-to-Finish: A logical relationship between a WBE and a specific person in which the

WBE cannot finish until the person is on hard. For example, a supervisor might have to attest

that a task has been accomplished to an acceptable standard.


As with “Where” dependencies, these “Who” ones can also be generalized to collections of

people (the ship may have a number of qualified helicopter pilots, any one of whom might serve).

Just as some tasks need certain people, others might need certain tools, software or know-how.

This can be important, if the mission must rely on others to provide these things, or when things

break. Remember that a ship will have limited ability to resupply itself over the course of the

mission; certainly this ability is more restricted than in a typical construction project, for example.

Such dependencies are here called “How” dependencies. They are entirely analogous to the

“Who” ones just defined (they are called Tool-to-Start and Tool-to-Finish), except that they refer

to items from the “How” visualization component instead of to people.

“What” dependencies are more significant, because the “What” visualization is tasked with

dealing with deliverables and risks. Given the importance of weather to sea travel, many “What”

dependencies would be weather related. These particular dependencies have a particularly

important role in mission planning. They should be used to make contingency plans, in a process

closely analogous to the command decision points used in navigation planning. For example, if a

given mission will conduct reconnaissance to ascertain whether or not there are enemy forces

present in an area, a good plan would contain options for what to do in either eventuality. “What”

dependencies could specify that a given task depends on an “all clear” deliverable from the

reconnaissance, while other tasks might depend on the very opposite outcome. This suggests that

the “What” visualization component should present or hide tasks, according to what contingency

the user wishes to see presented.

Note that, it is likely that multiple types of dependencies could be associated with some tasks. For

example, a task would have both a “Who” and a “How” dependency at once, if it requires both a

specialist and a specific tool to complete.

A Mission Planning system will need these generalized task dependencies primarily to enable

agility: the ability of the plan to recover from an unforeseen event or setback. Mission plans will

have to be revised frequently in order to remain relevant. Thus, mission planning support should

include provisions for monitoring the plan’s execution. Remember that key people might be

injured or incapacitated, impairing the ship’s ability to complete tasks with “Who” dependencies.

Key equipment or tools might break, impeding tasks with “How” dependencies. The other types

of task dependency could likewise be broken. Thus, mission planning requires a means to report

the impact of unforeseen events. Event Reports provide just such a means.

2.2.2.2 Event Reports

An Event Report would allow the user to report the consequences of an unforeseen turn of events.

As envisaged here, Event Reports would have a type that matches with the plan visualization

components. In other words, there should be “Who”, “What”, “Where”, “When” and “How” events.

For example, a “Who” event would allow for the reporting of casualties, indicating that certain

people are killed or otherwise incapacitated. This should trigger an automated verification of all

“Who” dependencies, so that any tasks with affected dependencies would be flagged for

reconsideration and possible replanning or abandonment. Alternatively, this automated task review

could quickly reassure the commander that the casualties suffered will not impede the mission.

Similarly, a “How” event would allow users to report damage to equipment (or software),

automatically triggering a review of all “How” dependencies. A “When” event would be used to


signal an unforeseen delay, automatically triggering a rescheduling of the entire plan. Notice that

the pattern is similar for the aforementioned event types, but “Where” and “What” events would be

a little bit different. These will be considered below. It should already be apparent that a key benefit

of this concept is that the commanders would not have to remember all the detailed WBE

dependencies in a stressful crisis (human performance is not optimal under such conditions).

A “What” event would signal that a decision point (as identified in a “What” dependency) has

been reached and that the corresponding contingency plan has been activated. For instance, in the

reconnaissance example presented above, suppose that reconnaissance identifies that enemies are

present in the area in question. The event would automatically activate the contingency plan

associated with this outcome, making it the mission plan version that is presented in all plan

visualizations. Alternatively, if planners have not chosen to specify what they would do in that

event, then the software should automatically identify for them any WBEs that are affected by the

enemy presence. These “What” dependencies would allow the software to do so.

Like a “Where” dependency, a “Where” event would be defined with respect to an area (R) on the

surface of the globe. Such an event would signal that the ability to enter R is impeded somehow,

possibly by enemy activity, but it could be by some natural barrier or hazard (ice provides a good

example). This event would naturally trigger an examination of all the “Where” dependencies and

their associated areas. If any of these associated areas intersected with R, then the affected areas

would be flagged for reconsideration. The planned route of the ship would also be checked

automatically for intersection with R, and any intersection would trigger rerouting. There should be

a limited role for Track Suggestion in this context. In response to a “Where” event that impedes

motion on the planned route, Track Suggestion might automatically compute a new route for the

ship from its current position to the final destination that avoids area R. It would suggest this new

route to the NavO, cueing its verification for safety. Once the NavO cleared the route, possibly after

significant modification in SHINNADS, mission planning software would expect to import the

approved new route back into the mission plan. Then this new route would be converted to a track.

The consideration of “Where” dependencies above suggests the value of a key capability:

automated WBE rescheduling. When given a new track for the mission, this process would

automatically reschedule all remaining mission WBEs in a manner consistent with their

dependencies. In particular, a change in mission track must trigger a consideration of all “Where”

dependencies, as the new track might not meet their requirements. For example, if one of these

task dependencies requires the ship to be in area C in order for the associated task (W) to start,

then W can automatically be rescheduled to the new arrival time in C and, if C is never reached,

then the task must be revisited (either by changing the route further or by cancelling or otherwise

replanning the task). Note that the rescheduling of W would also trigger rescheduling of any tasks

that depended on it. These in turn might affect the timing of other tasks. Thus, there could well be

a cascading impact on the mission schedule.

An automated scheduling algorithm should be developed that would take the following inputs:

1. The tasks (WBEs)

2. The mission track (T)

3. The task dependencies


Using these inputs, the algorithm would automatically schedule the tasks in a manner consistent

with their dependencies, or indicate any inconsistencies that make such scheduling impossible.

Naturally, this scheduling process would also determine the spatial location of all the tasks

because of the relationship between space and time provided by T. Such automated scheduling

can be expected to speed up any revisions to the mission plan that may be required as a result of

changes to the mission track. The time required to produce a new plan should be shortened

considerably and thus the ship would be more agile.

2.3 Route and Track Construction and Editing

Any software produced to support mission planning will require some ability to produce routes

and tracks for the ship. The route construction process is considered fairly straightforward, as the

production of routes in SHINNADS is well refined. Mission planning software would have to

duplicate some of these capabilities. Still, there are a few issues to consider in the conversion of

routes to tracks that deserve some consideration.

2.3.1 Defining Routes with Waypoints

The simplest way to define waypoints is by clicking on the chart. In the right context, successive

clicks could define a route for the ship. The only issue is how to connect these waypoints. As

mentioned previously, possible connections include rhumb lines (which follow a constant

bearing), great circle routes (which are the shortest routes on a sphere) and geodesic arcs. Only

the first two links are here considered necessary for mission planning. It should be understood

that the type of connection between the waypoints of a route may change from one leg to the next.

2.3.2 Route Editing

Mission planning software must allow the route to be edited manually, either by moving

individual waypoints or by shifting the whole route at once. This implies also that routes can be

saved to files and read in from then. It is necessary to be able to export routes to a format that is

readable in SHINNADS. It is also necessary to be able to import routes produced in SHINNADS.

2.3.3 Converting Routes to Tracks

In mission planning, routes also need to be converted into tracks. In general, there are an infinite

number of different ways to convert a given route into a track. Such ways are here called driving

approaches and define how ships will be driven over different segments of the route. Fortunately,

a few driving approaches suggest themselves as being natural choices from the standpoint of

keeping things simple. For instance, the conversion from route to track is most straightforward, if

the route is traversed at constant Speed Over Ground (SOG) starting at a given time; however, in

order to maintain the same SOG, despite changes in the wind, waves and currents encountered, a

ship would be constantly modifying its engine configuration. Conversely, a ship that maintains a

constant engine configuration (perhaps as measured in engine Rotations per Minute (RPM)), must

accept fluctuations in its SOG to the extent that it encounters changing conditions. The

conversion of a route to a track under a constant engine configuration requires the ability to

anticipate these speed fluctuations. A ship that maintains either a constant speed or a constant


RPM will naturally induce a specific arrival time at its destination. Indeed, in these approaches,

the arrival time at a given destination is a consequence of the average speed of the ship, so any

obstacle that forces the ship to lengthen her planned route will naturally push back arrival.

Most ships have a particular engine configuration that is known to be optimal from the standpoint

of conserving fuel. Ships can be expected to cruise in this optimal configuration for extended

periods. For instance, the Pielstick Propulsion Diesel Engine (PDE) on Canadian Patrol Frigates

is capable of up to 17 knots ahead, but its most fuel efficient speed is 10 knots [6]. Most of the

time, the HALIFAX Class is driven with the PDE driving both propeller shafts via the X-Conn

gear box. A cruising speed of 15 knots is a typical compromise between haste and thrift [7].

Generally, one of the two General Electric LM-2500 Gas Turbine (GT) engines is engaged only if

the ship needs to exceed 17 knots, and engaging both GTs at once allows the ship to reach speeds

approaching 30 knots (at the cost of increased fuel usage).

Ships often sail in such a way as to arrive at their destination on time, adjusting their average

speed in order to do so. Interestingly, according to the CFCD 130 [6], when an average speed in

excess of 17 knots is needed to arrive at the destination on time, the HALIFAX class can be often

be most fuel efficient by sprinting (at speeds in the 25 knot vicinity) on one of its GT engines for

just long enough that the rest of the trip can be completed on the more efficient PDE engine at

17 knots (as opposed to going the whole way on the GT). Such sprinting is a common way of

driving the ship, even though it takes a few minutes to make the switch from one driving mode to

the other [7]. Naturally, there would be considerable choice about when to do such a sprint. The

more normal situation is for ships to be driven for long stretches under fixed engine

configurations.

Thus, crews are used to having considerable flexibility in driving approaches. This suggests that

software might best approach the conversion from route to track by supporting a manual

assignment of speeds to legs of the route. Rather than having the crew specify these speeds

directly, however, have them attach particular engine configuration to each leg of the journey

instead. The software would then convert the engine configuration used to an effective SOG,

using both the known properties of the engine and the expected environmental conditions. Thus,

the conversion would be semi-automated.

There is an agility benefit to be had from completely automating the conversion, but facilitating it

will be demanding of the mission planners, requiring different ways of thinking. It would require

them to specify the legs of the mission journey in a way that does not depend on the route itself. It

would be possible to do this, if the legs of the journey were defined by a particular time, or upon

completion of a particular task (note, these are “When” dependencies). Alternatively, it would be

possible to do it, if the planners were prepared to define the legs of the journey in relation to

specific outcomes from the WBEs. For example, if upon successful completion of a particular

task (a “What” dependency in the sense suggested above), the mission goals were met, then the

ship might well accept that the voyage home should follow a particular driving algorithm, one

that is independent of where that last task may have taken them. In general, there is value in

defining the legs of a mission journey in response to “What”, “Where” and “When” dependencies

and in associating particular driving algorithms with the legs of the journey. The increased plan

agility is expected to come from eliminating the need for manual conversion from route to track.

This should increase the speed of revising a plan in response to an unforeseen event.


A driving algorithm specifies a way of driving the ship (a driving approach) that is independent of

the route chosen (it will work for any route). A heuristic that calls on the ship to “Drive on the

PDE at 15 knots” provides a simple example. Note, in a driving algorithm, there might be value

in specifying an approach to any turns required. An example driving algorithm for the voyage

home in a HALIFAX Class might take as argument the planned mission end date and time (e) and

a safe route home (r), as verified by the NavO, for instance:

1. Compute the distance home along r.

2. Compute the Speed of Advance (SOA) required to get home by e along r.

3. If SOA is less than 17 knots, sail home on r on the PDE at 17 knots.

4. If SOA is more than 17 knots, sprint along r on one GT at 25 knots, until the journey may be

completed at 17 knots, or sprint the whole way home, if the ship is running so late relative to

e that no steaming on the PDE will be possible.

The driving algorithm above would allow for an automated conversion of route r to a track, with

due accounting for engine performance and predicted environmental conditions.

The use of legs defined by “When”, “Where” and “What” dependencies and driving algorithms

like this opens the door not only to fully automated route to track conversion, but to more

automated mission replanning (down the road) in response to Events that force detours. In other

words, there could be a considerable benefit to plan agility, both immediately and possibly in

future.


3 Environmental Condition Forecasting


Currently, ships of the RCN have access to forecasts of environmental conditions from a variety

of sources. Though some of these sources have several available formats in which they might

provide these predictions, the ships are choosing to obtain them in image form. The reason is

clear: this format is most useful for inclusion into plans formulated in Microsoft PowerPoint®. If

the Meteorology Technicians (Met Techs) on the frigates have any software that could take

predictions in other formats, they are bringing this on their own initiative.

According to CFCD 130 [6], there are many methods by which the ship might receive weather

products at sea, but the primary method is via the internet. The main website for weather support

to CF operations is provided by the CF Weather Office. This site provides a number of

weather-related imagery products that are relevant to missions. Another useful site is provided by

Environment Canada [8]. Ships also use yachting websites [9] or US government sites [10]. If the

internet is unavailable, MARPACHQ or MetOc will still be able to assist in a variety of ways. For

instance, weather products can be faxed, emailed, or sent to a handheld device. Same Time Chat

is also available via MCOIN and the MetOc duty briefer can even be phoned. In addition, twice

daily weather messages (called WEAX messages) may be requested of CFB Comox Met on the

west coast or of from MetOc on the east coast.

The remainder of this section will outline some of the products available from the CF Weather

Office. Be it understood, however, that, with the exception of the satellite imagery, these products

depict estimates from computer weather models, as opposed to measurements.

3.1.1 Significant Weather Prognosis and Surface Analysis

The imagery available from the CF Weather Office website originates from various divisions of

Environment Canada including Nav Canada and the Canadian Meteorological Centre (CMC).

Two types of images are available: surface analysis and significant weather prognosis. A surface

analysis chart shows the forecast mean sea level pressure field at a given time, along with the

position of high and low pressure centres and fronts. These analyses are produced 4 times a day,

at 0000, 0600, 1200 and 1800 UTC by the CMC of Environment Canada. A significant weather

prognosis chart contains forecast positions of surface pressure centres, surface fronts and clouds

with icing expected; positions of tropical storms and hurricanes are indicated when applicable.

Significant icing and turbulence areas are included as well as freezing levels. These charts are

prepared twice a day, and are valid approximately 11 hours after issue times (valid times are

either 0000 UTC or 1200 UTC). These charts typically form the basis of MetTech weather

briefings to the crew of a navy ship at sea. Figure 1 provides an example of a significant weather

surface prognosis for the Atlantic Region.


Figure 1: This figure provides an example of the sort of analysis of fronts, clouds and weather

systems that the CF Weather Office provides. Note the contour lines of air pressure, in

millibars. It employs symbols and acronyms that require specialized knowledge

to interpret. It is considered helpful in planning air operations. Red

symbols also indicate areas with freezing rain and drizzle.

3.1.2 Wind

Estimates of the wind speed and direction are also available from the CF Weather Office site.

These are updated every 6 hours in Canadian waters and every 12 hours globally. Predictions of

future wind states are available, at approximately 12 hour periods over the next five days, though

the particular time span of these predictions, as well as the appearance of the charts, varies by

coast. An example of how these estimates of the wind vector field look is provided in Figure 2,

which offers an explanation of the flag symbology employed in them.


Figure 2: An illustration of the sort of predictions of wind speed available from the CF Weather

Office website. These predictions employ a symbology in which the local wind speed is

determined by adding up the speeds indicated by all the special accents

(triangular flags, lines, and half-lines) on a given symbol. These

accents indicate the wind speeds as follows: each flag indicates

50 kts; each line, 10 kts; and each half-line, 5 kts. The symbol

end with the accents indicates the direction from which

the wind is coming, so the strongest winds in the

figure are from south by southwest.

3.1.3 Waves

Measurements of wave height are notoriously difficult to make visually, in part because of the

complexity of the wave field. For this reason, sea waves are often reported in terms of the

significant wave height, which is defined as the average height of the highest one third of all

waves present. Predictions of wind speed and wave height are normally included in Canadian

weather forecasts and meteorological products.

The wave predictions available from the CF Weather Office website offer combined wind and

wave estimates. These estimates include current conditions as well as 12 hour, 24 hour, and

36 hour prognoses. An example of these is provided in Figure 3. These estimates do not offer

much insight into the wave spectrum, providing no indication of period or wavelength.


Figure 3: An illustration of the sort of predictions of wind and wave speeds, heights

and directions that are available from the CF Weather Office website.

Other charts produced for mariners do provide insight into the wave period, as shown in Figure 4

[11].

Figure 4: A prediction of wave conditions that includes information on

the wave period as well as the wave height and direction.


3.1.4 Currents

Predictions of the speed of sea surface currents are also available. An example showing the

current speed off Labrador is shown in Figure 5. There is a general lack of flexibility in the

process of obtaining current predictions at the CF Weather Office site, in terms of the areas

covered as well as the times at which the predictions were available. There was also a lack of

consistency between the coasts. On the positive side, however, charts like Figure 5, lacking any

indication of current direction though they may be, indicate that the capability to predict currents

is available from existing models to which the CF Weather Office has access.

Figure 5: An illustration of the sort of predictions of current speeds

that are available from the CF Weather Office website.

3.1.5 Satellite Photos

Satellite photos, like the one shown in Figure 6, provide a picture of cloud conditions. These

images are used extensively in locating fronts and lows, especially over large bodies of water.

They are considered invaluable for the early detection of tropical storms [6], but satellite analysis

training is required in order to interpret them fully.


Figure 6: This is a typical satellite image of weather systems, which is available at

regular intervals on both coasts through the CF Weather Office website.

3.1.6 Fog

By noting dew point and temperature of the air and then comparing them with sea surface

temperature, fairly accurate predictions of fog can be made. Thus, charts of sea surface

temperature, like the one shown in Figure 7, can be useful, especially when ships are operating in

the vicinity of cold waters. The CF Weather Office website did not offer such estimates with

consistency across the coasts. When and where they were available, they were updated about

once a day.


Figure 7: An illustration of the sort of predictions of sea surface

temperature available from the CF Weather Office website.

3.1.7 Ice

The Canadian Ice Service [12], a division of the Meteorological Service of Canada, is the leading

authority for information about ice in Canada’s navigable waters. Their products, also available

through the CF Weather Office site, offer a remarkably detailed insight into not only the extent of

ice coverage but also its thickness, age and form. This insight is provided with their “ice egg”

symbology, as illustrated in Figure 8. Interpreting these ice eggs requires training, as well as

access to ice state and ice form code tables (not reproduced here in the interest of brevity). The

main ideas conveyed are suggested in Figure 9, which shows that the top two rows of an ice egg

convey ice concentrations, while the bottom two rows convey stage of development and form.


Figure 8: An illustration of the sort of predictions of ice cover that are available from the CF

Weather Office website. These predictions use a special coding called the ‘ice egg’,

shown in ovals at bottom left. Each ice egg corresponds to the

coloured regions that share the same letter code.


Figure 9: This figure gives an overview of the information provided in by the ‘ice egg’ used by

Environment Canada. The first row of the egg indicates (with a number less than 10) the

total concentration of ice in the area, in tenths. Thus, 7 would mean 70% of that area

has some form of ice covering it. The second row will divide that total concentration

into partials according to thickness, also in tenths (thickest ice on left, thinnest

on right). These partials must sum to the total given in row 1. The

remaining rows use codes to classify the stage of development

and form of the ice for each of regions indicated in row 2, so

columns of the egg refer to the same region.

3.2 Alignment with Track Suggestion Requirements

In a recent master’s thesis dealing with Track Suggestion [4] (which calls it Weather Routing),

the authors offer a convenient list of the environmental predictions that typically feed into the

underlying algorithms. These typical inputs provide a shopping list of desired environmental

predictions that ships should want to consider in mission planning, even if they do not actually

employ Track Suggestion.

Their list includes the following items:

1. Wind speed and direction

2. Wave direction, height and period

3. Current speed and direction

4. Ice conditions: Thicknesses, presence of icebergs and drift ice

It is interesting to compare the available environmental predictions, as identified in the preceding

section, with these requirements. This comparison suggests that all these desired predictions are


available to ships of the Canadian Navy through the CF Weather Office website. The ice

predictions available are particularly good. On the negative side, however, predictions of wave

period and current direction were not displayed in the image products currently showcased on that

website. That existing models can predict the wave period is supported by Figure 4. That the

estimates of current speed in Figure 5 could also have been supplemented with corresponding

estimates of the current direction is a reasonable assumption to make. In short, the alignment is

encouraging. What is more worrisome is that neither the desired inputs nor the available

environmental imagery make any mention of uncertainty, despite the fact that they are both

concerned with weather forecasts that may extend quite a few days into the future. When it comes

to predictions of the future, ignoring uncertainty is misleading at best. One site where predictions

are made with due consideration of uncertainty is provided by the US centre for environmental

prediction [13].

Another interesting observation is that the input requirements of Track Suggestion do not reveal

how far into the future the predictions need to extend. Clearly, this question is related to the

length of the voyage being undertaken. A voyage that lasts but one or two days need have little

concern that predictions of environmental conditions will not be available, but a naval mission

could extend for weeks, and few weather services extend their predictions that far into the future.

Indeed, it is widely believed that the accuracy of weather forecasts degrades markedly after the

first few days, so the demand for longer term predictions is weak. This observation raises an

important question: if the length of the voyage extends for longer than the furthest environmental

predictions, what should mission planning (or Track Suggestion for that matter) do for the

remainder? The answer to this question is not without significance to mission planning.

Mission planning had best not depend on having access to all the environmental predictions it

might desire as inputs. Not only are long term predictions subject to significant error, but the

communications systems that bring these predictions to ships at sea might fail. Indeed, mission

planning had best be able to proceed, even if it has none of the forecasts it might desire available.

To make do without the desired inputs, it would be helpful to know something of the distribution

of historical conditions in the area. These historical precedents are here called the baseline

conditions, though they are more widely referred to under the heading of climatology.

3.3 Baseline Conditions

Ships have been reporting weather conditions at sea for decades thanks to the efforts of the World

Meteorological Organization (WMO). The WMO collects weather reports, four times daily, from

about 4000 Voluntary Observing Ships (VOS), when these vessels are at sea. These ships send

their weather reports to one of forty-nine National Meteorological Services (NMSs), and then the

NMS forwards them to the WMO for compilation. Such reports make an important contribution

to marine meteorological services of the sort provided by the CF Weather Office, since they are

used as input data in NWP models. One of the major continuing problems facing meteorology is

the scarcity of data from vast areas of the world’s oceans, largely in the southern hemisphere, in

support of basic weather forecasting. This scarcity affects the quality of NWP outputs in these areas.

While imagery from meteorological satellites, as in Figure 6, can reduce these problems, ship

weather reports remain essential, as they provide ground truth for the satellite observations, and

measure things that the satellites cannot see.


Historical observations should form the basis of expectations for environmental conditions when

no explicit predictions are available. In other words, experience should guide expectations of

what conditions will be encountered in future missions. One way to accomplish this is by

representing the baseline conditions with Bayesian prior distributions. This representation has the

advantage of providing a probabilistic framework for updating these priors in the light of specific

predictions. Non Bayesian approaches are certainly possible too. However the baseline might be

represented, the variability in environmental conditions is just as important for planning purposes

as the average ones because that variability helps quantify mission risks.

3.4 Visualization

It is essential that those engaged in mission planning be able to visualize predicted environmental

conditions, as well as baseline conditions, over a user-defined region in an interactive software

environment that lets them show the predictions most relevant to their current thinking and hide

distracting ones. One way to achieve this is by representing predictions as layers in a GIS, such as

the Oceanweather Display System [14], available as a Commercial-off-the-Shelf (COTS)

produce. Regardless of the source of weather forecasts, the user-interface these systems provide

(see Figure 10) should help guide the design of mission planning support systems.

Figure 10: A screenshot from the Oceanweather Display System (ODS), showcasing

its ability to display global wind speed and wave height forecasts.


The visualization capabilities of the software should not just be limited to spatial representations

of the conditions prevalent in the mission area at a particular time, as depicted in Figure 10. The

software should also be able to project these conditions onto the planned track of the vessel. In

other words, the software should be able to anticipate the conditions that will be encountered by

the ship. This projection is important in the conversion of routes to tracks. Thus, in the “When”

visualization of the mission plan, the user should be able to bring up a prediction of any desired

environmental variable, as it is projected to be for the ship at the time selected. By the same

token, in the “Where” visualization of the mission route, the user should be able to click on any

portion of that route and bring up a projection of any environmental variable, as it is expected to

be when the ship gets to the position clicked on.

3.5 The Consequences of Shore-Based NWP Models

The current framework for obtaining environmental predictions at sea in the RCN has these

predictions made ashore and then pushed out to the ships via satellite communications. It should

be borne in mind that this is not the only way things could be done: in theory, NWP models could

be run on the navy ships themselves. In practice, however, the latter approach has not been

followed for a number of reasons. First, leading models are extremely complex (e.g., [15]),

second, they require high bandwidth access to input data, and third, they benefit from being

located near centres of excellence in meteorological research, where many experts are available to

interpret data sources that require specialized training. The Met Techs on a navy ship cannot

reasonably be expected to have comparable experience.

One of the major consequences of the shore-based architecture that has emerged is that it

becomes necessary to manage the communication of weather predictions to the ship, preferably in

manner that does not unduly consume limited communications bandwidth or interfere with the

ship’s mission (by making it less covert). To the extent that ships are free to control this transfer,

planning for when and how often they will download predictions and where predictions are

required necessarily becomes part of mission planning. Two rates are relevant to such planning:

the first is the rate at which new model predictions are produced by the NWP models themselves

(which varies by model and by variable predicted) and the second is how often mission plans are

revised. It should also be borne in mind that, as a well-established rule of thumb, longer term

weather predictions are less reliable than shorter term ones (all else being equal). Thus, decision

makers should consider how long ago any predictions they look at were actually made. Keeping

track of the various sources of uncertainty inherent in predictions of the future is no trivial

challenge, but one that cannot safely be avoided.

The complexity of the considerations in the previous paragraph suggests the need for a tool to

help the crew manage the communication of weather predictions. Such a tool might be called

Bandwidth Management for Predictions. An architecture that facilitates a publisher-subscriber

relationship between NWP models and navy ships should prove helpful in designing such a tool.


4 Projecting Vehicle Movement

It is typical for a naval mission to involve vehicles other than the planners’ own ship. These other

vehicles can be classified into three broad types: friendly, neutral and hostile. Of these types, the

neutral vessels can be expected to have the least impact on plan development, as navies stand a

better chance of obtaining reliable cooperation from friendly vessels and are more concerned with

the actions of hostile ones. Indeed, the actions of any hostile ships present can be expected to be

of greatest consequence to mission planning. That having been said, even anticipating the

movements of neutral vessels could be relevant to specific missions. It can also be said with some

confidence that friendly vessel movement is the easiest to handle, as navies can expect these

vessels to share their intentions, at least roughly but often even in track form. Plans should trust

the promises of those considered ‘friendly’. As has been suggested repeatedly in this paper,

military plans need to be agile, more so than most. Thus, mission planning should be prepared to

consider the movements of all three types of ships and to account reasonably for uncertainty. This

section is about how these considerations affect and should affect mission planning.


The impression of current naval mission planning practice given here, as it pertains to vehicle

movements, relies on an examination of a few mission plans, discussions with planners [7, 16] as

well as on the template that is given to mission planners to help guide them through the process.

Naturally, it also draws on the author’s experience of naval operations.

4.1.1 Own Ship Understandings

It is common practice to plan many naval missions with a rough track for the own ship [16]. Such

a mission track is understood, by those involved, to serve more as a guideline than as a script to

be stuck to with precision. For example, this sort of rough planning is done for fish patrol

missions, where the intent is to go out into certain general areas, see which ships are encountered

out there, hail and approach some of them and respond to any suspicious activities that might be

observed in so doing. The mission is highly adaptive, with a sense of improvisation. On the other

hand, there could be naval missions in which people realize the ship actually intends to stick to

the planned track, perhaps because she has made key appointments (maybe with a refuelling

tanker) along the route that must be kept for the mission to succeed. Mission planning should

indicate these cultural understandings more explicitly, in order to avoid potential

misunderstanding.

4.1.2 Friendly Forces

The mission planning process can reasonably hope to influence, if not control, the movement of

friendly forces. Yet, it was not entirely apparent how planning would be affected when friendly

relationships fell closer to the influence end of the spectrum than to the hierarchical

commander-subordinate end. It is fair to say that the projected movements of friendly forces in

mission plans are characterized by the same kind of rough track understanding discussed in the

previous section. As in that section, this understanding is maintained in people’s heads. It is


important to describe this understanding more explicitly, so as to differentiate between the

following two friendly vehicle promises:

1. We will probably move, more or less, along the track indicated, within a half a day of the

time suggested, unless something interesting comes up.

2. We will definitely follow the indicated track to within GPS accuracy, and be on time, to the

minute. You can depend on it.

It should come as no surprise that two people could hear the exact same words and come to

different conclusions as to which of the options above was being promised, especially if they

came from different cultures. It should also be apparent that there is a world of difference

between the two promises from the mission planning standpoint. That difference should be

accounted for.

4.1.3 Neutral Shipping

Currently, it cannot quite be said that little thought is given to anticipating the movements of

neutral shipping in naval mission planning, but the planning process employed (as exemplified in

its templates) does not encourage such thoughts. Instead, it steers them primarily towards

consideration of the potential movements of hostile forces and towards RCN actions in response.

A convenient shortcut though this simplification provides in many scenarios, anticipating the

movements of neutral shipping could be important, if these got in the way of operations or

suffered collateral damage. Note that it would be a mistake to conclude that the RCN is not

concerned about neutral shipping: it is just that it relies largely on mechanisms outside of the

mission planning template to capture these concerns.

4.1.4 Hostile Forces

The COAs of Hostile forces are the focus of the current mission planning template. Indeed, the

planning template suggests that “Enemy courses should be developed first, regardless of which

side has the initiative.” Anticipating these opposing force COAs and developing effective

responses to them, which are called friendly force COAs, is at the very core of the mission plan.

These courses of action are displayed in a table, as depicted in Figure 11. The process would

guide planners towards filling in the table with appropriate labels for the various COAs.

Moreover, it suggests rating table entries using stoplight colours: “You can take a plus/minus

approach in order to determine whether the comparison is green—good to go—a high chance of

success, yellow—some issues which can mitigate success and red—a mission failure will result if

pursued.” This stoplight methodology is being followed in real plans, and adding text to the table

cells justifying the stoplight rating has emerged as a creditable standard practice. This approach is

not without merit, especially considering its benefits in simplifying communication.


OPPOSING

FORCE COA 1

OPPOSING

FORCE COA 2

OPPOSING

FORCE COA 3

FRIENDLY

FORCE COA 1

FRIENDLY

FORCE COA 2

FRIENDLY

FORCE COA 3

Figure 11: The COA matrix in which opposing force COAs, depicted in columns, are evaluated

against friendly force COAs, shown in the rows. Coloured table entries are often

supplemented with text justifying the rating.

The stoplight methodology is at its most effective in supporting decision making when one

particular Friendly Force COA dominates the others. This is because a decision can then be made

without needing to speculate about which Opposing Force COA is most likely. A Friendly Force

COA is dominant, if its performance is rated at least as highly as that of the top contender,

regardless of what COA the opposing force may take. Such a dominant strategy should clearly be

followed. While such a dominant COA has emerged in at least one real mission plan, this very

dominance raises concerns that the other COAs were but “straw men”, considered merely to make

a preferred course look good by comparison. In other words, it may seem as if planners knew

what they intended from the start and only went through the motions of the process, raising

doubts about the value added by it. It is unfortunate that such doubts are raised precisely when the

methodology is most effective. In the example of Figure 11, no single strategy is dominant.

If no dominant strategy emerges, the stoplight approach can be expected to draw the eyes of

decision makers towards strategies with more green cells or less red ones. One way to capture this

idea is through a kind of cancellation tally. For instance, in Figure 11, Friendly Force COA 1 and

Friendly Force COA 2, both have one column in which they are rated yellow while the other is

rated red, outcomes that could be taken to cancel one another. Following this cancellation, the

remaining column (Opposing Force COA2) is green for Friendly Force COA 1 but only yellow

for Friendly Force COA 2, suggesting the former is superior. Similarly, Friendly Force COA 1

and Friendly Force COA 3, both have one column in which they are rated green while the other is

rated red, which would again cancel. Following this, the remaining column (Opposing Force

COA1) is yellow for Friendly Force COA 1 but red for Friendly Force COA 3, suggesting the

former is again superior. Thus, under this cancellation tally evaluation method, something close


to which is implicitly favoured by the overall methodology, Friendly Force COA 1 would be

chosen.

The implicit assumption of the cancellation tally (and of score-based approaches by which it is

typically implemented) is that the opposing force COAs are equally likely. Of course, this

assumption might not hold true. Indeed the template encourages planners to think about which

opposing force COA is most likely, as well as which is most dangerous. In suggesting evaluation

that implicitly treats opposing force COAs as equally likely, while encouraging thoughts that

contradict this, the current methodology creates a certain cognitive dissonance. In the example of

Figure 11, could opposing force COA 3 not be so much more likely than the others that Friendly

Force COA 3 (which is considered to do best in that scenario) becomes attractive, even though

the cancellation tally would have decision makers eliminate that option?

Another concern with the current approach arises from the complexity of calculations that planners

are asked to perform in their heads. In particular, they are effectively asked to integrate out various

sources of uncertainty. To see this, consider their evaluation of a particular combination of friendly

and opposing COAs (one of the table cells of Figure 11) in a traditional naval engagement. Surely,

in evaluating the outcome of the battle envisaged, it would be helpful to know which force has the

other outgunned. Indeed, one would expect this factor to be all but decisive. Yet mission planners

could be asked to rate the cell without knowledge of the strength of the opposing force, effectively

requiring them to integrate over the distribution of possible strengths for it. Not only is this

challenging, it also discourages consideration of strategies that allow for an early determination of

relative strength, the better to guide a fight-or-flight decision later on.

In short, the current approach is simple, but this normally commendable virtue has been pushed to

near its boundary with the simplistic, in view of the complex considerations that could impact

naval missions. The planning process discourages due consideration of some COAs, via artifacts

of the methodology employed.

4.2 New Perspectives

This section presents recommendations for how to improve the existing planning process, insofar

as it deals with vehicle movement. The best of these recommendations would facilitate tasks that

planners are already doing. Admittedly, however, some advocate doing new things in the

planning process. In considering these, it should always be borne in mind that planners have only

so much time to devote to the process, so, if they take on new planning tasks without increasing

their overall effort, some of the things they are already doing can be expected to suffer.

4.2.1 Own Ship

It was indicated above that some mission plans indicate their own ship’s movements with but a

rough suggestion of the general vicinity in which they plan to go. In these missions, awareness

that the planned track is just a rough guideline is maintained in people’s heads. It should prove

useful to indicate more explicitly how far from that rough track the mission is prepared to wander.

Such an indication can readily be provided by supplementing the mission track with range circles

placed at its turning points, as shown in Figure 12. These would delimit the extent of permitted

meanderings throughout the mission, via simple interpolation.


Figure 12: A rough indication of the movement of a ship could be captured by

adding circles to its various turn waypoints. These circles would indicate

the extent of potential wandering from the planned route.

To be sure, adding range circles (or other shapes) increases the planning workload slightly, but

the benefits provided are twofold. First, it avoids the misunderstandings that will surely result

from assuming that all participants have the same understanding in their heads. Second, it

differentiates a rough track from one that the ship intends to follow precisely. In short, it

improves communication, a major objective of any plan.

4.2.2 Friendly Forces

The idea of setting limits to wandering is also expected to be of benefit in understanding other

ship tracks. In Section 4.1.2, there was a brief discussion of promises and how these can mean

very different things to different people. Most people have personal experience confirming this

fact of life, as well as of the conflict that often results. It was suggested in that section that,

insofar as promises pertain to the intended movements of friendly vehicles, these understandings

are currently being maintained in people’s heads. As argued in the previous section, there is a

great benefit to documenting what promised movement is actually being taken to mean, and range

circles, like those shown in Figure 12, can be used to do so. When considering the movement of

aircraft or submarines, analogous approaches based on spheres or cylinders instead of circles

readily suggest themselves. Note that polygonal sectors are already being used in waterspace

management to control convoy movement in formation. The general principle underlying this is a

simple one, well rooted in experience: do not assume, document. The time required will more

than pay off in misunderstandings avoided.


It should not escape the reader’s notice that the range circles (or spheres/cylinders) suggested

above lend themselves naturally to the simulation of samples of movement tracks for the friendly

forces. These in turn could naturally feed into simulations that would prove helpful in evaluating

the outcome of the various scenarios.

4.2.3 Neutral Shipping

A lot of neutral shipping is conveniently announcing its intended movement through 96 hour

reports, through Long Range Identification and Tracking (LRIT), as well as through the

Automatic Identification System (AIS). Various websites also indicate schedules, especially

arrival and departure times in port, for a small selection of ships. The data from these systems is

available to the CF and should be used to project neutral ship motion, perhaps even as a matter of

routine in planning. The key is to make this projected motion easy enough to accomplish and the

results simple to visualize. This projection should naturally consider land obstacles and perhaps

even ice, in addition to the reported destination. Such projection could be accomplished by

finding the shortest route from the last known position of each ship to its destination. This route

can then be used to project neutral ship motion through time, provided the start and arrival times

are known. Admittedly, only a small portion of ships would meet all these data requirements

(known position, destination, arrival time, and departure time—all of which must be consistent

with reasonable ship cruising speeds), but it should still be valuable to forecast their movements,

when these intersect with the mission area. In the longer term, a tool that could display the

predicted location of all these ships at any given time during the mission should be particularly

helpful. The TREAD tool, developed at the Centre for Marine Research and Experimentation,

which extracts shipping routes from AIS data [17], should form an effective basis for projecting

ship motion. In the nearer term, access to data from the Recognized Maritime Picture (RMP) will

have to serve as rough general indication of neutral ship activity.

4.2.4 Hostile Vehicles

The movements of hostile vehicles are already central to mission planning, yet considerations of

their motion are currently compressed into but a handful of supposedly representative COAs. This

paper suggests a different perspective. In particular, the tracks of hostile vehicles should be

regarded as samples from a probability distribution over a space of possible tracks. In other

words, instead of having but a handful of opposing force COAs, there would be hundreds, even

thousands, all simulated by computer. This sort of probabilistic modelling over track space was

first advocated in theoretical papers [18, 19], but its potential use in modelling hostile ship

movement has been demonstrated in a realistic application [20]. The benefits of this approach are

perhaps best expressed by illustrating that the uncertainty about the position of a hostile vehicle at

a given time can be represented with a heat-map, like the one illustrated in Figure 13 [18]. Such

heat-maps are readily adapted to consider areas searched without finding the target [19]. In future

naval conflicts, the victor will be determined in part by which side searches for the other most

shrewdly. Heat-map-guided searches for the enemy, updated in real time, represent the state of

the art, the way things should be done. The first steps in this direction are now appearing and

serve as a useful vision of the way ahead.


Ship 2 Location After 12 Hours

Figure 13: This figure shows coloured contour lines of the density for the location of a particular

ship (referred to as “ship 2”) at a particular instant in time (12 hours after the ship was first

seen). The redder colours indicate higher density values, so they can be viewed as a

kind of heat-map for the location of ship 2. The land is shown in grey.

There are other ways of looking at a particular search besides the heat-map. In particular, one might

ask where a particular search has been most effective and where it has left gaps. This perspective is

also facilitated by the track space viewpoint advocated above, as shown in Figure 14. This figure,

taken from [20], illustrates where a week of patrol aircraft effort was most effective and where it

left gaps (white areas).


Figure 14: This figure shows the areas where a particular allocation of search effort (a week’s worth of patrol flights, indicated by dashed lines) was most effective. The darker the shade

of blue, the higher the detection probability, as shown on the legend at right.

Exciting as future capabilities look, especially in comparison to the current techniques, those cited above are still too slow to support mission planning effectively. Fortunately, there are more mature products available that also embrace the same heat-map-guided search vision advocated above. Among these, the VOIR tool [21], can certainly be recommended as having the requisite technological readiness. This tool could well be adapted to various search scenarios and should be integrated into mission planning software, to help anticipate the movements of hostile targets.

0.00

0.05

0.10

0.15

0.20

0.01

0.0

1

0.01

0.0

1

0.01

0.0

1

0.0

1

0.03 0.03

0.03

0.0

3

0.03 0.03

0.0

5

0.0

7

Proposed Dark Target Metric


5 Environmental Response Modelling

Environmental response modelling is concerned with anticipating the implications of the

predicted environmental conditions for key components of the mission effort. These components

include not just the ship itself, but critical equipment on board, as well as the crew. This paper

distinguishes three different general approaches to environmental response modelling: leave it to

the humans to sort out, use an empirical approach, which would use lots of measurements of the

relevant variables to fit statistical regression models, or model the mechanisms by which effects

are produced (for example, model the effects of the waves on ship pitch and roll). Using expert

systems could be said to introduce a new class that draws on all three of the other approaches.

Whichever approach is chosen, it should take proper account of uncertainty, as it will often be

important to speak of degraded performance rather than absolute incapacity (consider

seasickness). Whichever approach is used, predictions should be compared to actual observations,

to allow for improvement over time. Clearly, the more ambitious Environmental Response

Modelling becomes, the greater its challenge in communicating results effectively to the decision

maker will get. Automated computations would have to be presented selectively, in response the

decision maker’s interest, in order to avoid overwhelming planners with too much information.


Currently, the effects of environmental conditions on the ship, her equipment and her crew, as

well as the implications on mission planning, are left entirely to the planners to sort out. This is

not necessarily a bad thing, as human experience can be an effective guide on such matters. The

primary risk is that the people become so overwhelmed by the potential complexity that they

either forget important aspects or give them short shrift.

The mission planning template encourages planners to consider several factors affecting the

achievement of the mission. One of these factors is associated with the Area of Operations

(AOO). Planners are urged to consider a broad view of “not only such physical elements as the

topography, oceanography and meteorology, but issues related to the political, diplomatic,

alliance/coalition, economic, cultural, religious and host nation(s) situation in the region.” Such

guidance can be expected to lead planners to examine the broad implications of anticipated

environmental conditions for the higher level mission objectives, as opposed to on specific

components. It would be helpful if planners were guided towards considering some of these more

specific implications, especially when these might have higher level impacts. Sometimes it is the

small things, the ones easily forgotten, that wind up having big impacts on a mission.

There is at least one specific environmental response that this paper contends properly belongs in

mission planning, as opposed to in its current home in the navigation plan: the estimation of fuel

consumption. Currently, this task is undertaken by the NavO, who considers the Distance to Go

(DTG) for a particular transit and the engine configuration in which the various legs of the

journey will be done. Each particular ship has a spreadsheet that relates the various engine

configurations that can be employed to the fuel consumed per hour in calm seas. Thus, once the

total Time of the Transit (TT) for each leg is known, fuel consumption on a leg can be computed

by simple multiplication. The fuel consumption for the entire journey would then be found by

summing over the legs.


Adjustments for environmental effects are made by adjusting the effective SOG that the engine

configuration is expected to produce, thereby affecting the TT and hence the estimated fuel

consumption [7]. These SOG adjustments are made using various heuristics, some of which are

suggested by the CFCD 130, but which ultimately rely on the experience of the NavO. For the

HALIFAX class, for instance, the CFCD 130 suggests that “One can expect sets of about l/30th

wind speed when winds are from dead ahead, 1/15th wind speed when on the beam, and 1/20th

wind speed when dead astern (l/10th wind speed when the hangar door is open).” These sets

indicate the speed at which the ship will drift downwind, so they could increase the SOG as well

as decrease it. It is not unusual for the NavO to treat the effect of environmental conditions that

fall short of hurricane strength as being negligible or “in the noise”, as the NavO’s priority is on

accounting for the constraints posed by mission activities and FLEX tasks [16].

Mission planning could make a contribution here simply by documenting such adjustments

explicitly and standardizing them, to remove the individual NavO effect. Such standardization is

most helpful when it is based on best practices across the fleet. These best practices should be

continually refined and updated by comparing predicted fuel consumptions to actual

consumption. Mission planning should support such iterative refinement, at least by allowing for

replacement algorithms to be slotted in as these are developed.

5.2 Converting Routes to Tracks Automatically

The estimation of environmental effects on fuel consumption should be part of mission planning

because, as suggested in Section 2.3.3, it is very useful to automate the conversion of routes to

tracks, mainly because it makes the plan more agile. It would also be helpful to know how much

fuel will be required relatively early in the planning process. This section suggests an approach to

this conversion that takes environmental predictions into account. It assumes that the heuristics

required to adjust the effective SOG for the predicted direction and speed of the wind, current,

and waves, as well as for the wave amplitude are available. These adjustments will here all be

lumped into one and referred to as environmental adjustments to SOG.

The algorithm suggested here for converting a route through a field of environmental predictions

to a track works as follows:

1. Convert the route to a track (t) by assuming that the environmental predictions for the start

time of the voyage will remain in effect throughout the voyage. Use these to make

adjustments to SOG (as suggested in the previous section). This initial track does not account

for predicted changes in the environment over the course of the voyage.

2. Using t, determine what future environmental predictions (for periods after the start of the

voyage) will be encountered over t and use these predictions to obtain a new track t'.

3. Replace t by t' and repeat Step 2, until the difference between t and t' is acceptably small, as

measured by the difference in arrival times at waypoints of the route.

This section will now suggest how the first step can be accomplished in more detail. The second

step can then be done in analogous fashion.


5.2.1 Route to Track Conversion Under Fixed Conditions

This section describes an approach to converting a route to a track under the assumption that the

environmental conditions predicted for the start of the journey will remain in effect throughout. In

other words, it assumes that the environmental conditions are fixed. This suggests these

conditions can be represented as a field, as suggested by the wind flags shown in Figure 15. The

idea of the algorithm is to break down the route into small portions, along which the ship may be

taken to sail with a fixed heading through conditions that remain constant. Note that knowing the

heading of the ship relative to that of the wind is what is needed to make the SOG adjustments for

wind set recommended in Section 5.1. Thus, any legs of the route along which the ship plans to

sail along great circle routes will have to be broken into appropriate rhumb line portions.

Figure 15: An illustration of the route of a ship (shown in orange) through a region on the ocean,

over which wind speed and direction data are available over a coarse grid. The wind

speed data are depicted in the flag symbology used by the RCN, in which

each long flag indicates 10 knots and each short flag indicates 5.

The main challenge faced by the software is identifying which rectangles in the field of

predictions (see Figure 15) will be intersected by each rhumb line segment. Clearly, an exhaustive

search over all the rectangles, examining each for intersection with the current line segment,

should be avoided, as it will be too slow. This section suggests a faster approach.


The problem is best characterized visually by examining an example straight line route segment,

as shown in Figure 16. The task is to compute a list of grid cells, identified by their row and

column numbers, that intersect the segment and to do it as fast as possible.

Figure 16: This figure illustrated the problem of identifying which rectangles

in a regular grid are intersected by a given line segment.

An approach to this problem is suggested by considering an analogous problem in one dimension.

Suppose that you have a long line segment that is divided into regular intervals, that you are given

a shorter line segment, and the you wish to determine which of the intervals on the long segment

are intersected by the short one. There is no need to check all of them. You can determine exactly

which intervals are intersected using the endpoints of the short segment. Take the example

illustrated in Figure 17:

Figure 17: An illustration of determining which intervals along a regular one-dimensional grid

(resembling a black ruler) are intersected by a given line segment (shown in orange).

In Figure 17, the length of the long segment is 100, the interval width is 10 and the short segment

goes from 22 to 74. Taking the left endpoint of the short segment (22) and the segment width, the

index of the leftmost segment may be found by ((22-0) div 10) +1 (where div is integer division)

1 2 3 4 5 6 7 8 9 10

1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 9 0

2 2 7 4


giving 3. Similarly, the index of the rightmost segment may be found by ((74-0) div 10) +1,

giving 8. Thus the segment intersects intervals 3 through 8. In two dimensions, the problem is

similar because the line segment can be projected onto the horizontal and vertical axes.

These projections are illustrated in Figure 16. They partly reduce the problem to the simpler one

dimensional case, eliminating the need to check all the grid cells. Instead, the line segment is

projected onto the horizontal axis to find which columns are intersected and projected onto the

vertical axis to find the rows. Evaluating each of these projections reduces to the interval problem

solved above. By these previous results, only columns 3 through 8 need to be considered further.

Similar computations show that only rows 4 through 8 need to be considered further (note that

rows are numbered from the bottom up). Time has already been saved time by eliminating grid

cells. This is a good start, but the search can be simplified still further. Consider just the portion

of the original segment that lies in row 4. This row is shown in the blue rectangle of Figure 18.

Figure 18: It can be effective to consider the problem row by row. In this case

the portion of the original segment that lies in row 4 is highlighted.

Projecting just the portion of the original segment that also lies in this blue rectangle upwards

onto the horizontal intervals immediately shows that within row 4, the line segment only

intersects the cells in columns 3 and 4, as shown in Figure 19.


Figure 19: Considering just the portion of the segment in row 4, this is quickly

seen by projection to intersect on cells in columns 3 and 4.

Similarly, within row 5, only the cells in columns 4 and 5 will intersect the segment, as illustrated

in Figure 20. Within row 6, the segment only intersects the cells in columns 5 and 6, and so on.

Thus, the ability to clip a line segment down to just the portion within a rectangle, an algorithm

provided by topology libraries, provides the means to quickly compile a list of which grid cells

are intersected by the segment.

Note that, in the approach above, there is a choice as to whether to clip the segment by row, as

illustrated above, or by column (which works in much the same way). Clearly, when the segment

intersects more rows than columns (as determined by the original bounding box), it should be

clipped by columns, and conversely when it intersects more columns than rows, it should be

clipped by row. Of course, when the segment intersects an equal number of rows and columns,

both approaches will be equally fast.


Figure 20: Considering just the portion of the segment in row 5, this is quickly

seen by projection to intersect on cells in columns 4 and 5.

Naturally, the set of grid cells intersected by the entire route is just the union of all the cells

intersected by its straight segments. Once this set has been found, its grid cell elements can then

be used, one by one, to clip the original route into little intervals in which there is both constant

heading for the ship and constant conditions. Thus, in each of these intervals, one could compute

the wind direction relative to the bow of the ship. The same process would be done for the waves.

In so doing these environmental conditions can be evaluated and so the route portion can be

converted to a track. To finish up, the final track is assembled by stitching together all these little

portions of it.

5.3 Predicting Indices of Environmental Risk

Currently, responsibility for keeping the ship safe, along with its equipment and crew rests with

the commander. That will certainly remain the case. Nonetheless, mission planning software

should warn planners, if the COAs they were considering would incur unnecessary environmental

risk. Some of the environmental risks that ships could incur involve squatting (sinking deeper in

shallow water, particularly at higher speeds) [6], dangerous pitch and roll (including hull

slamming, parametric or synchronous roll [4]), as well as being pooped or broaching [6].


Broaching is a particularly dangerous situation that develops when waves are coming from astern

at close to the speed of the ship, especially with wavelengths close to the length of the vessel. It is

depicted in Figure 21, which is taken from [6]. It is best not to place ships in dangerous situations

in the first place, rather than relying on the crew to deal with them once they develop. Defence

Research and Development Canada (DRDC) has done work in predicting hull slamming [22], as

well as on anticipating sea sickness effects.

Figure 21: This sequence of images describes the dangerous phenomenon of broaching.

5.4 Dealing with Uncertainty

While little use is being made currently of indications of uncertainty in environmental

predictions, these indications should be both obtained and used. Yet, it is not immediately

apparent how this might be accomplished. One effective means of integrating uncertainty into

deliberations is to design expert systems to evaluate environmental responses. If these expert

systems were based on Bayesian Networks [23], then effective consideration of uncertainty would

be built-in. In the longer term, such systems should be investigated in this role. In the near term,

however, this goal is too ambitious. On the other hand, if mission planning software were to

provide placeholders for response models, to be developed later, then it could readily incorporate

ongoing research.


6 Sensor and Communications Modelling

This section considers the question of whether mission planners need any support to help them

decide whether and when the various vehicles involved in the mission scenario would be able to

either talk to each other (as they move about), or detect each other with their sensors. It is not

hard to imagine situations where these considerations become central to the evaluation of the

proposed COAs. Moreover, if planning moves towards the simulation based methodology

advocated in Section 4.2.4, then this capability will become increasingly important.


Current practice in this regard is to leave all considerations of sensor capability to the humans to

sort out.

6.2 Modelling Approaches

A few simple models might be helpful in addressing questions of who can hear whom, and who

can detect or identify whom in a more automated fashion. Three such models are depicted in

Figure 22. The top left of the figure shows the single disc model, the top right shows the double

disc and the bottom portion shows the conical beam. Each model could be used to support

questions of detection, identification or communication. These models treat the problem from the

perspective of a particular vehicle or sensor, at position x. They simplify the problem by

considering just the position of the target relative to x, as opposed to the target’s location on the

map. This means that they cannot consider the effects of terrain. Despite this limitation, they may

be useful in modelling naval mission scenarios, especially those involving hostile vehicles for

which information on exact sensor capabilities is lacking.

The models depicted in Figure 22 could be classified as empirical, parametric models because

they have parameters (typically ranges and probabilities) that would have to be estimated from

sensor (or communications) performance data. Another class of models could be derived from

modelling the physical processes involved. For example, when dealing with a radar system, one

can use physical models of radar signal propagation, along with characteristics of the target (like

its radar cross section), to compute detection probability. A review of physics-based approaches

to modelling radio communications (as well as AIS signal detection) is provided in a DRDC

Contract Report [5]. This approach has advantages when almost all the parameters are known

(often from manufacturer specifications), but can be expected to suffer (in comparison to simpler

models) when these parameters are subject to significant uncertainty.

6.2.1 The Simple Disc or Cookie Cutter Model

This model (shown in the top left quadrant of Figure 22) is compellingly simple. It involves but a

single range circle. Within the circle, detection, identification or communication, as the case may

be, are taken to be possible—with a particular probability (typically either 100% or 50%), while

outside it they are not.


Figure 22: The three portions of this figure each suggest a different detection/identification

model. All these models rely on the relative position of the target with respect

to the patrol asset. The top left shows the single disc, the top right

the double disc and the bottom shows the conical beam.

6.2.2 The Double Disc Model

A slightly more complicated model employs two concentric discs with radius r1 and r2

respectively (see the top-right panel of Figure 22). Whether the model considers detection,

identification or communication, success is taken to be certain inside the inner disc and

impossible outside the outer one. In the ring in between, the probability of success is p. The

special case where the inner ring has radius 0 is also worth considering.

6.2.3 Handling Altitude

A simple extension of the disc model, here called the flashlight (or conical) beam (see the bottom

panel of Figure 22), can be used to model detection, identification or communication from

airborne surveillance assets. This extension treats the effective region as a conical beam. Just as a

flashlight illuminates a larger area at greater range, the effective region would grow as the aircraft

climbed to higher altitude or shrink as the plane descended. Note that the double disc model also

has a natural conical extension, in which the two radii are replaced by off-axis angles. This

extension naturally permits the model to handle changes in aircraft altitude, just as with the

simple disc model.


6.3 Visualizing Model Predictions on a Chart

The capability to overlay some of the models considered in the previous section on a chart should

be helpful in mission planning because it could help planners visualize how to stay out of range of

hostile sensors. At the same time, they can try to ensure that their own sensors will have coverage

of strategic locations and choke points, at key times. The temporal components of these

considerations can be significant. In other words, it can be helpful to attach models to moving

vehicles, in order to model how sensor coverage moves over the course of a mission, as the

various vehicles traverse the mission space. An example of such attachment is provided in a

DRDC Scientific Report [20]. Moreover, DRDC has been developing experience with the

Satellite Tool Kit (STK) [24], which provides a powerful development environment, well suited

to the models presented above (as well as more complex ones). The STK environment has already

been used to develop a mission planning tool [25], albeit for a rather particular mission type. This

tool effectively incorporated environmental predictions from NWP models, among them the

Global Ice-Ocean Prediction System [15].


7 Track Evaluation

This section is concerned with automatic evaluation of proposed tracks for the mission. As such,

it incorporates the implications of some of the preceding sections. Thus, evaluations of the

mission track could include not just the implications of environment conditions, but also the

implications of the other vehicles involved, as well as their weapons, sensors, and

communications systems. The various measures of performance (MOPs) that might be relevant to

a mission could well be combined into a measure of overall effectiveness (MOE) for the track.

This capability would become increasingly important, as automation comes to play a greater role

in mission planning. If many of these issues are left to the humans, then (aside from fuel

predictions) automated track evaluation has but a minor role.


8 Track Suggestion

The purpose of this section is to consider the extent to which Track Suggestion can and should

play a role in naval mission planning. Before doing so, the paper will try to clarify the

terminology and resolve some of the ambiguities. In this paper, the role of Track Suggestion is

always to connect start waypoint A to destination waypoint B. What can vary, in various

implementations, is the extent to which the optimization algorithm is free to modify the departure

time from A, namely tA and the arrival time at B, namely tB. Given that the temporal extent of

military missions is usually fixed in advance, the capability to explore automated modifications to

tA and tB can be considered a lower priority. The user can always investigate the impact of these

times manually. What really matters in Track Suggestion is the ability to optimize the route.

Usually, this optimization process seeks to minimize either the fuel consumption or the travel

time. Some tools also provide the capability to warn the crew about potentially dangerous

conditions, like parametric rolling. It should be noted that, in commercial products, Track

Suggestion is more commonly referred to by the name Weather Routing. This terminology is

resisted here because both the route and the speed at which it is traversed are being optimized, so

the more common term is slightly misleading.

8.1 Application to the Navy Context

The paper considers a number of commercial products to see if they suit the requirements of

naval planning. These products are considered market forerunners, but they are by no means the

only ones available.

8.1.1 AWT’s (Storm Geo) Bon Voyage System and EnRoute

StormGeo, which started in 1997, calls itself an advanced weather forecast company, offering

decision support for weather sensitive operations. They claim to be one of the largest providers of

professional weather services, with eight forecast centres worldwide. They are now an

international company, employing nearly 400 people in 25 offices in 15 countries, with

headquarters in Bergen, Norway. One of their branches, called Applied Weather Technology

(AWT), is located in Silicon Valley, California. AWT was acquired in 2014. AWT’s on board

weather routing product is called the Bon Voyage System or BVS for short [26]. BVS puts

mission planning in the hands of the captain on board, but AWT also offers shore based routing

services. AWT claims to help plan the safest, most fuel-efficient route. BVS can pass routes to

most ECDIS systems, to confirm navigational safety. It incorporates an hourly forecast of

precipitation, temperature, humidity, visibility, winds and wave conditions, which can be

delivered by email, internet, or KVH IP-MobileCast. It now takes into account traffic separation

schemes fuel costs and Emission Control Areas (ECAs). Its 72 hour forecasts indicate areas of

increased risk of rogue waves.

The weather forecasts used by the BonVoyage System come from the Global Forecast System

(GFS). GFS is a global NWP system containing a computer model run by the United States’

National Weather Service (NWS). This model is run four times a day, and produces forecasts for


up to 16 days in advance, but with decreased spatial resolution after 10 days. It is one of the

predominant synoptic scale medium-range models in general use.

The GFS model is a spectral model with an approximate horizontal resolution of 0.125° for the

first 10 days and 0.25° from 240 to 384 hours (16 days). In the vertical, the model is divided into

64 layers and temporally, it produces forecast output every hour for the first 120 hours, three

hourly through day 10 and 12 hourly through day 16. GFS data are not copyrighted and are

available for free in the public domain.

Interestingly, AWT offer a second Weather Routing System, acquired from a Swedish company

called SeaWare, when the latter merged with Storm Geo. The second system is called EnRoute [27].

It performs voyage optimization, for time, safety or cost, using a physics-based ship propulsion

model. It finds optimal speeds and other route properties for each leg of the suggested route.

EnRoute obtains its condition forecasts, which extend up to 15 days ahead, in areas that can be

defined by the user, and which can be obtained at spatial resolutions down to 0.125°. These

forecasts are sent by email. EnRoute provides for graphical presentation of these weather

predictions. Weather predictions are obtained from the European Centre for Medium Range

Weather (ECMRW) [28] as well as from the Real-Time Ocean Forecast System (RTOFS) [29].

EnRoute can identify conditions that may lead to parametric rolling, using an enhanced dynamic

stability module. This module was developed in co-operation with Wallenius Marine and the

Royal Institute of Technology in Stockholm. The brochure claims this module represents a major

step forward in operational decision support for vessels that are sensitive to parametric rolling and

pure loss of stability.

8.1.2 FORCE Technology’s Sea Planner

FORCE Technology calls itself a technological consultancy company. They offer their consulting

services in several sectors, including the maritime one. They are an international company with

subsidiaries in Sweden, Norway, China, Singapore and the United Arab Emirates, lead from their

headquarters in Denmark. SeaPlanner is their on board system [30], developed in partnership with

the Danish Meteorological Institute (DMI). SeaPlanner can optimize the route, the speed sailed

along it, as well as the engine configuration. This optimization accounts for the wind, waves and

currents. It can be configured to minimize the voyage time, or it can maintain a fixed arrival time.

The algorithm may also be constrained to maintain constant power, constant RPM or constant

speed.

The weather data used by SeaPlanner are provided by DMI, who update their forecasts twice

daily, so new ones are provided every twelve hours. Forecasts extend out to 10 days ahead, in

steps of either 12 or 24 hours. Predicted conditions can be provided at a resolution down to 0.5°.

The predicted conditions include the mean sea level pressure, the wind speed and direction, the

significant wave height, period and direction, the swell height period and direction, the sea height,

period and direction, the surface current speed and direction, as well as a freak wave index. All

this can be delivered automatically by subscription or via email. Note that ice is not mentioned.

SeaPlanner’s propulsion model claims to include considerations of water temperature and density,

draft and trim, efficiency of the engine, propellers and hull, resistance from still water, waves,


wind, shallow water, and hull fouling, as well as considering engine maintenance and propeller

fouling. Their still water resistance model incorporates ship speed and draft, and can be based on

a semi-empirical model, on model tests or on sea trial data.

SeaPlanner is part of the SeaSuite family of onboard systems, which also offer engine

performance monitoring, optimum trim guidance and other services. SeaPlanner can use data

gathered by these other modules.

8.1.3 Jeppesen’s Vessel and Voyage Optimization Solution (VVOS)

Jeppesen is part of Boeing and based in the United States. Their route optimization software is

called the Vessel and Voyage Optimization Solution (VVOS) [31] and forms an integral part of

the C-MAP Integrated Maritime Suite. VVOS generates a range of optimized routes that claim to

balance trade-offs between ETA and fuel consumption. Thus, it can optimize the track to

minimize fuel consumption, either with fixed arrival time or without it. It compares its optimal

tracks to traditional strategies, such as constant speed or “sprint and loiter”. Integrated

environmental response models facilitate analysis of any route, using high-resolution weather

forecasts to weigh trade-offs among ETA, fuel consumption, ship motions, hull stresses, and

weather and sea conditions. The optimization algorithms are said to keep the tracks suggested to

within the seakeeping limits specified by the user, avoiding heavy weather.

The product brochures claims that, unlike traditional weather routing services, VVOS includes a

detailed model of the ship’s specific motion, engine and propeller characteristics or limitations.

This ship-specific model computes the speed made good under the forecast wind, wave and ocean

current conditions, at a given engine power and propeller RPM. VVOS can import and export

routes in 20 different ECDIS formats.

The brochure claims that VVOS incorporates industry-best metocean forecasts from several

sources, which they do not identify. These forecasts extend out for 15 days into the future, and are

delivered at a resolution of 1° via email. It is not clear how often these forecasts are updated. The

brochure does not mention whether VVOS can incorporate predictions of ice cover.

8.1.4 MeteoGroup’s Ship Performance Optimization System (SPOS)

MeteoGroup, claims to be one of the world’s leading private providers of weather solutions,

operating wherever they think weather impacts business decision making. Their research and

forecasts are said to help customers make more effective critical decisions, increasing revenues,

saving costs, improving sustainability and reducing risk. MeteoGroup calls itself the UK’s largest

private sector weather business and the European market leader. They have their headquarters in

London (UK), but have offices in 17 countries around the world.

MeteoGroup’s onboard weather routing software is called the Ship Performance Optimization

System (SPOS Onboard) [32]. It integrates seamlessly with their SPOS Fleet Management

System. SPOS Onboard is designed to take ship-specific characteristics into account. Their

routing algorithm is said to take into account sea conditions, such as waves, current and swell, as

well as wind and other weather elements.


The product website [32] claims SPOS has been designed to improve vessel performance and

increase safety for crew, vessel and cargo. SPOS provides detailed weather information onboard,

as well as advice and support during the planning and execution of ocean voyages. Weather

forecasts, which are generated by MeteoGroup themselves, are received daily on the ship via

e-mail, from which the software can produce weather maps.

8.1.5 Suitability for Naval Mission Planning

The products listed above are by no means the only ones available. Generally, their inner

workings are proprietary. As typically sold, these products are not suitable for general military

mission planning for two reasons. First, military missions are characterized by incorporating

many tasks (WBEs) that affect the track of the ship. Examples of such tasks include launching a

helicopter (which may require the ship to be pointed into the wind) or conducting a

man-overboard drill. Such tasks would clearly prevent the ship from following a suggested track

that did not allow for them. Commercial vessels, on the other hand, are primarily concerned only

with steaming from place to place and so accept fewer deviations from planned routes. Thus,

military missions have complexities these products do not capture. Second, Track Suggestion

routines are not sold separately from software components that receive and display the

environmental predictions. Even if the vendors were prepared to sell just the Track Suggestion

components of their software, integration of these into software environments for which they

were not designed could be risky. It goes without saying that the RCN should not tie itself to

specific commercial weather services, when government weather services are available at no

additional cost.

While this paper is skeptical about the suitability of Track Suggestion to support general mission

planning, it could certainly find a role in specific situations. For example, if a portion of a

particular mission could be singled out in which the only objective is to get from A to B as

economically as possible (a situation similar to the one experienced by commercial vessels), then

Track Suggestion could help plan just that portion. Track Suggestion is attractive to mission

planning only to the extent such specific situations arise in practice. As suggested tracks would

still require extensive manual verification and tinkering, mission planning is better served by

devoting effort to support these processes instead.

8.2 Responsible Track Suggestion

Whenever automation is used to suggest a COA to a human decision maker, it raises the question

of who is responsible if the suggested COA is taken but things go wrong. Usually, the makers of

COTS tools will limit their liability. Thus, the tool’s suggestions must be evaluated by the human

decision maker, despite any implied suitability for purpose that being given the tool might

engender. In the current context, if a naval ship were to strike a rock when following a route

suggested by software, the CO should expect to be held responsible. In theory, one might think

that verifying whether a proposed route will lead a ship to run aground is the kind of repetitive,

routine task that lends itself well to automation. In practice, there are a number of reasons why

verifying whether a given route will lead a ship to run aground is no simple task:

1. The depth at a given location is estimated with uncertainty of various forms, but indices of

this uncertainty are not generally available. First, the depth is generally interpolated from


measurements made nearby. Second, it is subject to change over time. In the short term, tides

can change the local depths, in extreme cases by over ten meters. Over longer time intervals,

wind, waves, currents and ice can move the sediments around and erode coastlines. Thus, the

uncertainty in depth is a function of how close the nearest soundings were, and how long ago

these were made, neither of which stays constant over the globe. In general, depths are known

with greater precision and accuracy in well-travelled areas. The most dangerous areas, of

course, are not well-travelled. As a result, the bathymetry of polar waters is not nearly as

well-known as that near major shipping lanes. Depth contour lines are not nearly as well

delineated as the coastline itself, as the latter can be extracted directly from photographs,

while the former cannot be.

2. In shallow waters, the local variability in depth matters. Areas where the depth changes but

gradually are clearly safer than those with sheer cliffs beneath the waves.

3. Weather and currents can make it challenging to keep a ship on a planned route. Greater

deviations from the planned route can be expected in areas with turbulent water flow or

vortices, as well as in areas unprotected from the full brunt of ocean storms. The direction of

prevailing winds and currents can matter: for example, currents that pull ships towards rocks

can be expected to be more dangerous than those that push them away. In other words, how

close one may safely approach a hazard is dependent on the prevailing conditions.

4. Dangerous areas, like the waters off Sable Island, tend to reveal themselves over time by

producing a lot of wrecks, at least where there has been historical ship traffic. Ship captains

know about this history and so take extra precautions in these areas; track suggestion

currently does not.

Thus, track suggestion will have to be supervised for the foreseeable future. This is important in

view of a key premise about decision support: prioritize support effort to those who retain the

responsibility. Mission planning should facilitate track visualization, evaluation and modification,

all of which have higher priority than Track Suggestion itself. In particular, tools that support

manual evaluation of whether a given track is safe, perhaps by helping to visualize its proximity

to known hazards along with the expected conditions, will have ongoing value.


9 Conclusion

This paper suggested a vision of how mission planning should be supported by software in the

long run. The overall vision presented was guided by just three principles: interactive drill-down;

answering who, what, when, where and how; and interlinked components. Mission planning was

broken into eight portions, each described in some detail in the sections of this paper. These

portions were named as follows: Task Planning and Management, Environmental Condition

Forecasting, Projecting Vehicle Movement, Environmental Response Modelling, Sensor

Modelling, Communications Modelling, Track Evaluation and Track Suggestion. Each section

examined current practice in the RCN, and identified tasks suitable for automation. The tasks

considered suitable are summarized in Table 1, with an evaluation of the Technology Readiness

Level (TRL) of the underlying algorithms.

Table 1: Mission planning tasks that could be effectively supported by automation.

Mission

Planning

Component

Task Suitable for Automation Technology

Readiness

Level

Task Planning

and Management

Linking FLEX tasks (WBEs) to where they would be

accomplished on the mission track (see Section 2.1).

9

Defining WBEs, scheduling them, assigning people and resources

to them and other core project management tasks (see

Section 2.2.1).

9

Chart management, with route and track editing (see Section 2.3). 9

Generalized task dependencies (see Section 2.2.2.1). 1

Event reports (see Section 2.2.2.2). 1–4

Automated task rescheduling considering generalized task

dependencies (see Section 2.2.2.2).

1

Semi-automated route-to-track conversion using driving

algorithms (see Section 2.3.3 and 5.2).

2–4

Environmental

Condition

Forecasting

Interactive visualization of environmental predictions and

associated uncertainties in GIS layers (see Section 3.4).

6–9

Subscription-based satellite bandwidth management for

Environmental Predictions (see Section 3.5).

4–6


Mission

Planning

Component

Task Suitable for Automation Technology

Readiness

Level

Projecting

Vehicle

Movement

Support to COA matrix evaluation (see Section 4.1.4). 1

Modelling friendly ship intended movement, including holding

formation and rough track planning (see Section 4.2.2).

3–6

Tools that help anticipate the movement of neutral shipping (see

Section 4.2.3).

3–4

Tools that help anticipate the movement of hostile shipping (see

Section 4.2.4), e.g., using heatmaps to guide searches for the

enemy.

1–4

Environmental

Response

Modelling

Estimating fuel consumption considering predicted environmental

conditions (see Section 5.1 and 5.2).

6–9

Fully automated route-to-track conversion (see Section 5.2) using

driving algorithms.

1–2

Computing and displaying indices of environmental risk (see

Section 5.3).

6–9

Sensor and

Communications

Modelling

Visualizing model predictions on a chart (see Section 6.2). 9

Attaching models to tracks, to present a time-varying model of

detection (see Section 6.3).

9

Track Evaluation Computing and displaying generic, pre-specified mission MOPs

(see Section 5.3) like total fuel consumption.

6–9

Computing and displaying custom, mission-specific MOPs or

MOEs (see Section 7).

4–6

Track Suggestion Track Suggestion with pre-specified objective (save fuel) and no

concern for WBE dependencies.

9

Track Suggestion with a mission-specific objective (or constraint)

but no concern for WBE dependencies.

1–4

Track Suggestion accounting for generalized WBE dependencies. 1


Mission planning should remain primarily a manual process for the foreseeable future, as opposed

to one in which automation suggests COAs to the human decision makers. As such, the

components of mission planning that aid the people in visualizing and evaluating issues are by far

the most important, while those that compute implications automatically have a lesser role to

play. Estimating fuel consumption was something that should be taken on as a responsibility of

mission planning support software, and many suggestions were made pertaining to this. Track

Suggestion software, as used by commercial shipping, should not play much of a role in naval

mission planning, largely because naval mission planning involves many more activities

undertaken while at sea. Track Suggestion could play a minor role in mission planning, however,

if portions of the overall mission can be identified in which the ship is steaming between points

like a cargo ship, solely with the goal of saving fuel and arriving on time.


References

[1] “A Guide to the Project Management Body of Knowledge,” Pennsylvania: Project

Management Institute, Inc., 2013.

[2] R. Kessel, “The burden of computer advice: Using expert systems as decision aids,”

DRDC Atlantic TR 2003-241, Defence Research & Development Canada – Atlantic, 2003.

[3] R. Kessel, Apparent reliability: “Conditions for reliance on supervised automation,”

DRDC Atlantic TM 2005-155, Defence Research & Development Canada – Atlantic, 2005.

[4] E. Larsson, and M. Simonsen, “DIRECT Weather Routing,” M.Sc., Shipping and Marine

Technology, Chalmers University of Technology, Gothenburg, 2014.

[5] D. Green, J. K. E. Tunaley, C. Fowler, and D. Power, “VHF propagation study,”

DRDC Atlantic CR 2011-152, Defence Research & Development Canada – Atlantic, 2011.

[6] Department of National Defence, “Canadian Navigation Manual,” CFCD130, 2014.

[7] S. Colbourne, “Personal communication,” Fleet Navigation Instructor at Canadian Forces

Naval Operations School, 2016.

[8] Environment Canada, “Weather Information,” https://weather.gc.ca/, (Access date:

13 August 2016).

[9] PassageWeather.com, “Sailing Weather Forecasts,” http://passageweather.com/, (Access date:

13 August 2016).

[10] National Oceanic and Atmospheric Administration, “Marine Weather,”

http://www.opc.ncep.noaa.gov, (Access date: 13 August 2016).

[11] National Oceanic and Atmospheric Administration, “Atlantic Graphical Forecasts,”

http://www.opc.ncep.noaa.gov/Atl_tab.shtml, (Access date: 17 July 2016).

[12] Environment Canada, “Canadian Ice Service,” http://iceweb1.cis.ec.gc.ca/CISWebApps/,

(Access date: 13 August 2016).

[13] National Oceanic and Atmospheric Administration, “Probabilistic Guidance,”

http://www.opc.ncep.noaa.gov/probabilistic_guidance.shtml, (Access date:

13 August 2016).

[14] OceanWeather, Inc., “OceanWeather Display System (ODS),”

http://www.oceanweather.com/forecast/ODS/index.html, (Access date: 17 July 2016).

https://weather.gc.ca/

http://passageweather.com/

http://www.opc.ncep.noaa.gov/

http://www.opc.ncep.noaa.gov/Atl_tab.shtml

http://iceweb1.cis.ec.gc.ca/CISWebApps/

http://www.opc.ncep.noaa.gov/probabilistic_guidance.shtml

http://www.oceanweather.com/forecast/ODS/index.html


[15] G. C. Smith, F. Roy, M. Reszka, D. Surcel Colan, Z. He, D. Deacu, J.-M. Belanger,

S. Skachko, Y. Liu, F. Dupont, J.-F. Lemieux, C. Beaudoin, B. Tranchant, M. Drévillon,

G. Garric, C.-E. Testut, J.-M. Lellouche, P. Pellerin, H. Ritchie, Y. Lu, F. Davidson,

M. Buehner, A. Caya, and M. Lajoie, “Sea ice forecast verification in the Canadian Global

Ice Ocean Prediction System,” Quarterly Journal of the Royal Meteorological Society,

vol. 142, no. 695, pp. 659–671, 2015.

[16] C. Prescott, “Personal communication,” NavO on HMCS Montreal, 2016.

[17] G. Pallotta, M. Vespe, and K. Briyan, “Vessel pattern knowledge discovery from AIS data: a

framework for anomaly detection and route prediction,” Entropy, vol. 15, pp. 2218–2245, 2013.

[18] T. Hammond, “Applications of probabilistic interpolation to ship tracking,”

DRDC-RDDC-2014-N7, Defence Research and Development Canada, 2014.

[19] D. J. Peters, and T. R. Hammond, “Interpolation between AIS reports: Probabilistic

inferences over vessel path space,” Journal of Navigation, vol. 64, pp. 595–607, 2011.

[20] T. Hammond, “The probability of intercepting dark targets,” DRDC-RDDC-2015-R135,

Defence Research and Development Canada, 2015.

[21] Y. Allard, M. Mayrand, M. Lavallée, and D. Radulescu, “Command and control application

development: VOIR server design details and installation guide,” DRDC-RDDC-2016-C183,

Defence Research and Development Canada, 2016.

[22] K. McTaggart, “Operator guidance for avoiding slamming of the KINGSTON class based

on measured vertical accelerations,” DRDC Atlantic TM 2007-022, Defence Research &

Development Canada – Atlantic, 2007.

[23] F. V. Jensen, “An Introduction to Bayesian Networks,” Springer, 1996.

[24] R. Blanchette, and C. Hébert, “MISR Visualization Experimental Environment:

MISR STK Study,” DRDC Valcartier CR 2008-128, Defence Research & Development

Canada – Valcartier, 2008.

[25] J. C. Innes, “AMEC project summary: GIS enabled METOC products,”

DRDC-RDDC-2015-C029, Defence Research and Development Canada, 2015.

[26] StormGeo, “Bon Voyage System,” http://www.awtworldwide.com/products/bvs-routing/,

(Access date: 13 August 2016).

[27] StormGeo, “EnRoute,” http://www.awtworldwide.net/products/seaware-enroute.asp, (Access

date: 13 August 2016).

[28] European Centre for Medium Range Weather, “European Centre for Medium Range

Weather,” http://www.ecmwf.int/en/about/who-we-are, (Access date: 13 August 2016).

[29] National Oceanic and Atmospheric Administration, “Real-Time Ocean Forecast System

(RTOFS),” http://polar.ncep.noaa.gov/ofs/, (Access date: 13 August 2016).

http://www.awtworldwide.com/products/bvs-routing/

http://www.awtworldwide.net/products/seaware-enroute.asp

http://www.ecmwf.int/en/about/who-we-are

http://polar.ncep.noaa.gov/ofs/


[30] FORCE Technology, “Sea Planner,” http://forcetechnology.com/en/maritime-

industry/passenger-ships/onboard-decision-support-systems, (Access date:

13 August 2016).

[31] Jeppesen, “Vessel and Voyage Optimization Solution,” http://commercialmarine.c-

map.com/en/c-map-integrated-maritime-suite/c-map-vessel-and-voyage-optimization-

solution-vvos, (Access date: 13 August 2016).

[32] MeteoGroup, “Ship Performance Optimization System (SPOS),”

http://www.meteogroup.com/en/gb/sectors/marine/shipping/spos.html, (Access date:

13 August 2016).

http://forcetechnology.com/en/maritime-industry/passenger-ships/onboard-decision-support-systems

http://forcetechnology.com/en/maritime-industry/passenger-ships/onboard-decision-support-systems

http://commercialmarine.c-map.com/en/c-map-integrated-maritime-suite/c-map-vessel-and-voyage-optimization-solution-vvos



http://www.meteogroup.com/en/gb/sectors/marine/shipping/spos.html


This page intentionally left blank.


List of Symbols/Abbreviations/Acronyms/Initialisms

AIS Automatic Identification System

AOO Area of Operations

AWT Applied Weather Technology

BVS Bon Voyage System

CF Canadian Forces

CMC Canadian Meteorological Centre

CO Commanding Officer

COA Course of Action

COTS Commercial off-the-Shelf

DMI Danish Meteorological Institute

DND Department of National Defence

DRDC Defence Research and Development Canada

DTG Distance to Go

ECDIS Electronic Chart Display System

ECMRW European Centre for Medium Range Weather

ECPINS A computerized, shipboard navigational aid that displays electronic charts,

own ship’s position in real time, and sensor data.

ETA Estimated Time of Arrival

GFS Global Forecast System

GIS Geographical Information System

GPS Global Positioning System

GT Gas Turbine

HOT Height of Tide

LDL Limiting Danger Lines

LRIT Long Range Identification and Tracking

MetTech Meteorological Technician

MOE Measure of Effectiveness

MOP Measure of Performance

NavO Navigating Officer

NMS National Meteorological Service


NWP Numerical Weather Prediction

NWS US National Weather Service

OOW Officer of the Watch

PDE Pielstick Propulsion Diesel Engine

PNR Point of No Return

PSA Predictive Situational Awareness, a task within the Integration of Command

Decision Support project (01db).

RCN Royal Canadian Navy

RPM Rotations Per Minute

RTOFS Real-Time Ocean Forecast System

SHINNADS SHip’s INtegrated Navigation And Display System

SOG Speed Over Ground

SPOS Ship Performance Optimization System

TT Time of the Transit

UTC Coordinated Universal Time

VHF Very High Frequency

VOS Voluntary Observing Ships

VVOS Vessel and Voyage Optimization Solution

WBE Work Breakdown Element

WMO World Meteorological Organization

DOCUMENT CONTROL DATA (Security markings for the title, abstract and indexing annotation must be entered when the document is Classified or Designated)

1. ORIGINATOR (The name and address of the organization preparing the document.

Organizations for whom the document was prepared, e.g., Centre sponsoring a

contractor's report, or tasking agency, are entered in Section 8.)

DRDC – Atlantic Research CentreDefence Research and Development Canada9 Grove StreetP.O. Box 1012Dartmouth, Nova Scotia B2Y 3Z7Canada

2a. SECURITY MARKING (Overall security marking of the document including

special supplemental markings if applicable.)

UNCLASSIFIED

2b. CONTROLLED GOODS

(NON-CONTROLLED GOODS) DMC A REVIEW: GCEC DECEMBER 2013

3. TITLE (The complete document title as indicated on the title page. Its classification should be indicated by the appropriate abbreviation (S, C or U) in

parentheses after the title.)

Current Practice in Mission Planning in the Canadian Navy and Opportunities for Automation

4. AUTHORS (last name, followed by initials – ranks, titles, etc., not to be used)

Hammond, T.R.

5. DATE OF PUBLICATION (Month and year of publication of document.)

May 2017

6a. NO. OF PAGES (Total containing information,

including Annexes, Appendices,

etc.)

72

6b. NO. OF REFS

(Total cited in document.)

32

7. DESCRIPTIVE NOTES (The category of the document, e.g., technical report, technical note or memorandum. If appropriate, enter the type of report,

e.g., interim, progress, summary, annual or final. Give the inclusive dates when a specific reporting period is covered.)

Scientific Report

8. SPONSORING ACTIVITY (The name of the department project office or laboratory sponsoring the research and development – include address.)

DRDC – Atlantic Research CentreDefence Research and Development Canada9 Grove StreetP.O. Box 1012Dartmouth, Nova Scotia B2Y 3Z7Canada

9a. PROJECT OR GRANT NO. (If appropriate, the applicable research

and development project or grant number under which the document

was written. Please specify whether project or grant.)

01db

9b. CONTRACT NO. (If appropriate, the applicable number under

which the document was written.)

10a. ORIGINATOR’S DOCUMENT NUMBER (The official document

number by which the document is identified by the originating

activity. This number must be unique to this document.)

DRDC-RDDC-2017-R022

10b. OTHER DOCUMENT NO(s). (Any other numbers which may be

assigned this document either by the originator or by the sponsor.)

11. DOCUMENT AVAILABILITY (Any limitations on further dissemination of the document, other than those imposed by security classification.)

Unlimited

12. DOCUMENT ANNOUNCEMENT (Any limitation to the bibliographic announcement of this document. This will normally correspond to the

Document Availability (11). However, where further distribution (beyond the audience specified in (11) is possible, a wider announcement

audience may be selected.))

Unlimited

13. ABSTRACT (A brief and factual summary of the document. It may also appear elsewhere in the body of the document itself. It is highly desirable that

the abstract of classified documents be unclassified. Each paragraph of the abstract shall begin with an indication of the security classification of the

information in the paragraph (unless the document itself is unclassified) represented as (S), (C), (R), or (U). It is not necessary to include here abstracts in

both official languages unless the text is bilingual.)

This paper reviews current practice in mission planning within the RCN, and identifies

opportunities for automation and decision support software. Tasks best suited to automation

follow established procedure and have a repetitive character, especially one that could induce

lapses in human attention. Tasks best left to humans are unique or require consideration of core

values or priorities. Every naval mission is unique, when considered as a whole, but when the

planning process is broken into distinct portions, as in this paper, numerous tasks suitable for

automation by the above criteria emerge. Many of these tasks could leverage tools created in the

project planning community. Many could leverage geographical information system tools and

navigation software. Many could incorporate models of sensor and communications

performance, and many could leverage tools for modelling vehicle movement. Statistical

techniques for representing uncertainty, both in measurements but also in intended movements,

are highly relevant. It has also been suggested that there could be an appropriate role for Track

Suggestion in mission planning. Commercial shipping companies are already using Track

Suggestion algorithms to route their ships around inclement weather and so save on fuel. Track

Suggestion will not find quite as significant a role in naval mission planning, largely because

naval missions have more complex goals, but it is not without niche applications. Overall,

mission planning should remain primarily a manual process, so the components of mission

planning that aid the decision maker in visualizing and evaluating issues are the most important.

The paper offers a few guidelines that should inform the assembly of the diverse tools above

into a coherent application environment that could effectively support mission planning.

---------------------------------------------------------------------------------------------------------------

Le présent document passe en revue les pratiques actuelles de planification des missions au sein

de la MRC et l’utilisation possible de logiciels d’automatisation et d’aide à la décision. Les tâches

se prêtant le mieux à l’automatisation suivent des procédures établies et ont un caractère répétitif,

ce qui pose un risque particulier de relâchement de l’attention. À l’opposé, les tâches qu’il vaut

mieux confier à des humains sont uniques ou bien nécessitent que l’on tienne compte de valeurs

fondamentales ou de priorités. Toutes les missions navales sont uniques si on les considère dans

leur ensemble, mais les scinder en tâches distinctes comme on le fait dans ce document permet

d’en dégager de nombreuses se prêtant bien à l’automatisation. Nombre de ces tâches peuvent tirer

parti d’outils créés au sein de la communauté de planification de projet, d’outils de systèmes

d’information géographique et de logiciels de navigation. D’autres pourraient intégrer des modèles

de performance des capteurs et des communications, et d’autres encore pourraient tirer parti

d’outils de modélisation des mouvements de véhicules. Les techniques statistiques de

représentation de l’incertitude, tant en mesures qu’en mouvements prévus, sont aussi très

pertinentes. On a également proposé que la suggestion de parcours joue un rôle approprié dans la

planification des missions. Les entreprises de transport maritime utilisent déjà des algorithmes

pour suggérer un itinéraire à leurs navires afin d’éviter les conditions météorologiques

défavorables et ainsi économiser le carburant. La suggestion de parcours ne joue certes pas un rôle

aussi important dans la planification des missions navales, surtout parce que les objectifs de ces

missions sont bien plus complexes, mais les créneaux d’application n’en sont pas moins

nombreux. En règle générale, la planification de mission doit demeurer un processus

essentiellement manuel. Par conséquent, les éléments qui aident les décideurs à visualiser et

évaluer les problèmes sont les plus importants. Le document propose quelques lignes directrices

qui devraient orienter la combinaison des divers outils mentionnés ci-dessus en un environnement

d’application cohérent qui pourrait appuyer efficacement la planification de mission.

14. KEYWORDS, DESCRIPTORS or IDENTIFIERS (Technically meaningful terms or short phrases that characterize a document and could be helpful

in cataloguing the document. They should be selected so that no security classification is required. Identifiers, such as equipment model designation,

trade name, military project code name, geographic location may also be included. If possible keywords should be selected from a published thesaurus,

e.g., Thesaurus of Engineering and Scientific Terms (TEST) and that thesaurus identified. If it is not possible to select indexing terms which are

Unclassified, the classification of each should be indicated as with the title.)

Mission Planning; Track Suggestion; Weather Routing; Environmental Prediction; Decision Support

Documents

Current Practice in Mission Planning in the Canadian Navy ... · planning process is broken into distinct portions, as in this paper, numerous tasks suitable for automation by the