Current Practice In Mission Planning In The Canadian Navy And

Transcript

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 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. DRDC-RDDC-2017-R022 i 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. ii DRDC-RDDC-2017-R022 Table of Contents Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i Significance to Defence and Security . . . . . . . . . . . . . . . . . . . . . . i Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii Importance pour la défense et la sécurité . . . . . . . . . . . . . . . . . . . . Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii iii List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . ix 1 Introduction . . . . . . . . . . . . . . . 1.1 Defining the Jargon . . . . . . . . . . 1.2 Components of Mission Planning . . . . . 1.2.1 Task Planning and Management . . 1.2.2 Environmental Condition Forecasting 1.2.3 Projecting Vehicle Movement . . . 1.2.4 Environmental Response Modelling . 1.2.5 Sensor Modelling . . . . . . . . 1.2.6 Communications Modelling . . . . 1.2.7 Track Evaluation . . . . . . . . 1.2.8 Track Suggestion . . . . . . . . 1.3 Voyage Plan Vision . . . . . . . . . . 1.4 Structure and Aims of the Paper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 2 2 3 3 3 4 4 5 5 5 6 2 Task Planning and Management . . . . . . . . . . . . . . 2.1 Current Practice . . . . . . . . . . . . . . . . . . 2.2 Leveraging Project Planning Tools . . . . . . . . . . . 2.2.1 How Mission Planning is Like Typical Project Planning 2.2.2 Concerns Particular to Planning a Voyage . . . . . . 2.2.2.1 Generalized Task Dependencies . . . . . . 2.2.2.2 Event Reports. . . . . . . . . . . . . 2.3 Route and Track Construction and Editing . . . . . . . . 2.3.1 Defining Routes with Waypoints . . . . . . . . . 2.3.2 Route Editing . . . . . . . . . . . . . . . . 2.3.3 Converting Routes to Tracks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7 9 10 11 11 12 14 14 14 14 3 Environmental Condition Forecasting . . . . . . . . . . . 3.1 Current Practice . . . . . . . . . . . . . . . . . 3.1.1 Significant Weather Prognosis and Surface Analysis . 3.1.2 Wind . . . . . . . . . . . . . . . . . . 3.1.3 Waves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 17 17 18 19 DRDC-RDDC-2017-R022 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 21 22 23 25 26 27 28 Projecting Vehicle Movement . . . . . . . . . . . . . 4.1 Current Practice . . . . . . . . . . . . . . . . 4.1.1 Own Ship Understandings . . . . . . . . . 4.1.2 Friendly Forces . . . . . . . . . . . . . 4.1.3 Neutral Shipping . . . . . . . . . . . . . 4.1.4 Hostile Forces . . . . . . . . . . . . . . 4.2 New Perspectives . . . . . . . . . . . . . . . 4.2.1 Own Ship . . . . . . . . . . . . . . . . 4.2.2 Friendly Forces . . . . . . . . . . . . . 4.2.3 Neutral Shipping . . . . . . . . . . . . . 4.2.4 Hostile Vehicles . . . . . . . . . . . . . Environmental Response Modelling . . . . . . . . . . . 5.1 Current Practice . . . . . . . . . . . . . . . . 5.2 Converting Routes to Tracks Automatically . . . . . . 5.2.1 Route to Track Conversion Under Fixed Conditions 5.3 Predicting Indices of Environmental Risk . . . . . . . 5.4 Dealing with Uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 29 29 29 30 30 32 32 33 34 34 37 37 38 39 43 44 6 Sensor and Communications Modelling . . . . . 6.1 Current Practice . . . . . . . . . . . . 6.2 Modelling Approaches. . . . . . . . . . 6.2.1 The Simple Disc or Cookie Cutter Model 6.2.2 The Double Disc Model . . . . . . 6.2.3 Handling Altitude . . . . . . . . . 6.3 Visualizing Model Predictions on a Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 45 45 45 46 46 47 7 8 Track Evaluation . . . . . . . . . . . . . . . . . . . . . . . Track Suggestion . . . . . . . . . . . . . . . . . . . . . . . 8.1 Application to the Navy Context . . . . . . . . . . . . . . . 8.1.1 AWT’s (Storm Geo) Bon Voyage System and EnRoute . . . . 8.1.2 FORCE Technology’s Sea Planner . . . . . . . . . . . 8.1.3 Jeppesen’s Vessel and Voyage Optimization Solution (VVOS) . 8.1.4 MeteoGroup’s Ship Performance Optimization System (SPOS) . 8.1.5 Suitability for Naval Mission Planning . . . . . . . . . . 8.2 Responsible Track Suggestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 49 49 49 50 51 51 52 52 3.2 3.3 3.4 3.5 4 5 iv 3.1.4 Currents . . . . . . . . . . . . . 3.1.5 Satellite Photos. . . . . . . . . . . 3.1.6 Fog . . . . . . . . . . . . . . . 3.1.7 Ice . . . . . . . . . . . . . . . Alignment with Track Suggestion Requirements . Baseline Conditions . . . . . . . . . . . . Visualization . . . . . . . . . . . . . . The Consequences of Shore-Based NWP Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DRDC-RDDC-2017-R022 9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 57 List of Symbols/Abbreviations/Acronyms/Initialisms . . . . . . . . . . . . . . . 61 DRDC-RDDC-2017-R022 v 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 vi DRDC-RDDC-2017-R022 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 DRDC-RDDC-2017-R022 vii List of Tables Table 1: viii Mission planning tasks that could be effectively supported by automation. . . 54 DRDC-RDDC-2017-R022 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). DRDC-RDDC-2017-R022 ix This page intentionally left blank. x DRDC-RDDC-2017-R022 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, DRDC-RDDC-2017-R022 1 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, 2 DRDC-RDDC-2017-R022 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 DRDC-RDDC-2017-R022 3 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. 4 DRDC-RDDC-2017-R022 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. DRDC-RDDC-2017-R022 5 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. 6 DRDC-RDDC-2017-R022 2 2.1 Task Planning and Management 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. DRDC-RDDC-2017-R022 7 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. 8 DRDC-RDDC-2017-R022 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. DRDC-RDDC-2017-R022 9 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 10 DRDC-RDDC-2017-R022 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. DRDC-RDDC-2017-R022 11 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 12 DRDC-RDDC-2017-R022 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 DRDC-RDDC-2017-R022 13 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 14 DRDC-RDDC-2017-R022 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. DRDC-RDDC-2017-R022 15 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. 16 DRDC-RDDC-2017-R022 3 3.1 Environmental Condition Forecasting Current Practice 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. DRDC-RDDC-2017-R022 17 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. 18 DRDC-RDDC-2017-R022 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. DRDC-RDDC-2017-R022 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. 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. 20 DRDC-RDDC-2017-R022 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. DRDC-RDDC-2017-R022 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. 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. 22 DRDC-RDDC-2017-R022 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. DRDC-RDDC-2017-R022 23 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. 24 DRDC-RDDC-2017-R022 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 DRDC-RDDC-2017-R022 25 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. 26 DRDC-RDDC-2017-R022 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. DRDC-RDDC-2017-R022 27 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. 28 DRDC-RDDC-2017-R022 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. 4.1 Current Practice 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 DRDC-RDDC-2017-R022 29 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. 30 DRDC-RDDC-2017-R022 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 DRDC-RDDC-2017-R022 31 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. 32 DRDC-RDDC-2017-R022 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. DRDC-RDDC-2017-R022 33 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. 34 DRDC-RDDC-2017-R022 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). DRDC-RDDC-2017-R022 35 Proposed Dark Target Metric 0.20 0.15 0.01 1 0.0 0.0 3 0.07 3 0.0 0.01 0.05 0.10 0.03 0.0 1 0.01 0.01 0.0 1 0.0 3 3 0.0 3 0.0 0.05 0.00 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. 36 DRDC-RDDC-2017-R022 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. 5.1 Current Practice 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. DRDC-RDDC-2017-R022 37 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. 38 DRDC-RDDC-2017-R022 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. DRDC-RDDC-2017-R022 39 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: 22 1 2 10 74 3 20 4 30 5 40 6 50 7 60 8 70 9 80 10 90 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) 40 DRDC-RDDC-2017-R022 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. DRDC-RDDC-2017-R022 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. 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. 42 DRDC-RDDC-2017-R022 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]. DRDC-RDDC-2017-R022 43 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. 44 DRDC-RDDC-2017-R022 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. 6.1 Current Practice 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. DRDC-RDDC-2017-R022 45 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. 46 DRDC-RDDC-2017-R022 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]. DRDC-RDDC-2017-R022 47 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. 48 DRDC-RDDC-2017-R022 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 DRDC-RDDC-2017-R022 49 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, 50 DRDC-RDDC-2017-R022 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. DRDC-RDDC-2017-R022 51 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 52 DRDC-RDDC-2017-R022 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. DRDC-RDDC-2017-R022 53 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 Planning and Management Task Suitable for Automation Technology Readiness Level 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). Environmental Condition Forecasting 54 1 Semi-automated route-to-track conversion using driving algorithms (see Section 2.3.3 and 5.2). 2–4 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 DRDC-RDDC-2017-R022 Mission Planning Component Projecting Vehicle Movement Environmental Response Modelling Task Suitable for Automation Support to COA matrix evaluation (see Section 4.1.4). Technology Readiness Level 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 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 DRDC-RDDC-2017-R022 55 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. 56 DRDC-RDDC-2017-R022 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). DRDC-RDDC-2017-R022 57 [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). 58 DRDC-RDDC-2017-R022 [30] FORCE Technology, “Sea Planner,” http://forcetechnology.com/en/maritimeindustry/passenger-ships/onboard-decision-support-systems, (Access date: 13 August 2016). [31] Jeppesen, “Vessel and Voyage Optimization Solution,” http://commercialmarine.cmap.com/en/c-map-integrated-maritime-suite/c-map-vessel-and-voyage-optimizationsolution-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). DRDC-RDDC-2017-R022 59 This page intentionally left blank. 60 DRDC-RDDC-2017-R022 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 DRDC-RDDC-2017-R022 61 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 62 DRDC-RDDC-2017-R022 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 Centre Defence Research and Development Canada 9 Grove Street P.O. Box 1012 Dartmouth, Nova Scotia B2Y 3Z7 Canada 3. 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 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 7. 6a. NO. OF PAGES (Total containing information, including Annexes, Appendices, etc.) 72 6b. NO. OF REFS (Total cited in document.) 32 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 Centre Defence Research and Development Canada 9 Grove Street P.O. Box 1012 Dartmouth, Nova Scotia B2Y 3Z7 Canada 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.) 9b. CONTRACT NO. (If appropriate, the applicable number under which the document was written.) 01db 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.) 10b. OTHER DOCUMENT NO(s). (Any other numbers which may be assigned this document either by the originator or by the sponsor.) DRDC-RDDC-2017-R022 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