`
`VOYAGE PLANNING IN ECDIS
`
`by Hein SABELIS 1
`
`This paper ivas first presented at the SASMEX Conference, 12-14 April
`1999, Rotterdam, The Netherlands.
`
`1. INTRODUCTION
`
`The aim of this paper is to emphasize the need for a structured approach
`to the development of tools for navigation support in ECDIS. To this purpose this
`paper focuses on voyage planning in ECDIS, outlining a more formal approach, to
`provide a basis for the development of tools for automated navigation support.
`
`The outline of this paper is as follows:
`
`First it will present some considerations regarding the development of
`ECDIS functionality,
`
`•
`•
`
`•
`•
`
`•
`
`then it will get into a definition of voyage p la n n in g ,
`followed by a conceptual framework of integrated navigation, which is
`then used as
`the basis for a more detailed look into the voyage-planning process.
`This is followed by an impression of what could be envisaged as automated
`support tools for voyage planning.
`Some concluding remarks are made in the final paragraph.
`
`2. ECDIS AND NAVIGATION SUPPORT
`
`the sole purpose of
`The electronic chart development started with
`replacing the paper chart. Soon it was realised that the electronic chart functionality
`
`1 Royal Netherlands Naval College, Department o f Nautical Sciences, Den Helder, The
`Netherlands. E-mail: H.Sabelis@ kim .nl.
`
`FLIR-1017.001
`
`
`
`could be expanded to a navigation information system; the name changed from
`electronic chart into electronic chart display and
`information system, ECDIS.
`However, the term 'information system’ can still be interpreted as a system which is
`simply able to display the stored data. In that case the discussion is reduced to the
`selection of data to be stored, the data structure and the symbology or display
`format. This basic interpretation does not lead to much added value. The added
`value improves significantly when the system integrates the available data into
`improved information products. This synergistic approach usually requires the data
`to be structured into objects and attributes which can be used in processing
`algorithms. The real value of ECDIS is determined by its synergism.
`
`When designing support tools we tend to ask the practitioner what he
`requires. Often however the practitioner is focused on the current procedures and
`the workload involved. The result may easily be the development of a support tool
`which in essence is an automated replica of the manual procedure, thus failing to
`improve the solution because the underlying issue was not identified. Development
`of support tools should therefore be based on a thorough analysis of the problem to
`be solved.
`It should also be borne in mind that the tool should fit into the logical
`process
`it
`is supposed to support,
`i.e.
`the tool should provide the required
`information with the information available in that phase of the process.
`
`The latest report of the workshop on development of Marine Information
`Objects (MIO) for ECDIS [ECDIS/MIO] showed some of the aforementioned in the
`resulting recommendations.
`
`is that the development of
`The point that is made here, however,
`navigation support tools for ECDIS is rather a result of individual ideas than the
`results of a structured analysis of the navigation process
`It is the author’s view that
`the development of new ECDIS functionality should be founded on some reference-
`model of the navigation process, identifying logical structure and processes eligible
`for automated support, possibly including agreed priorities. Manufacturers could
`then focus their efforts to substantiate the identified functionality, standardisation
`forums could concentrate on the required data structures, and data suppliers could
`focus on providing the required data in the required structure in order of the agreed
`priorities.
`
`The next paragraphs will focus on voyage planning as an area eligible for
`automated support by ECDIS.
`
`3. VOYAGE PLANNING
`
`3.1
`
`Voyage Planning defined
`
`Voyage planning can be defined as:
`
`the systematic process in which a sailing order is translated into an
`optimal navigation plan and detailed navigation scenario to fulfil the
`mission, having considered all relevant information.
`
`FLIR-1017.002
`
`
`
`The sailing order may differ for the different user groups: transport,
`fishery, offshore, navy, coastguard et cetera, but there will generally be a mission
`element and a constraints element that are to be satisfied by the voyage plan. Often
`the constraints are defined in terms of time, or economy, but they may also include
`criteria such as ship’s motion or temperature constraints.
`
`Voyage Planning is meant to provide:
`
`Prevention of potential conflicts or dangerous situations;
`•
`• Optimisation of planning for specific planning factors;
`•
`A detailed scenario for the execution;
`•
`A reference to compare the actual voyage progression with the planned
`progression.
`
`Typical of voyage planning is the great diversity of data to be collected,
`consulted and integrated into both the overall voyage plan, and the detailed
`navigation scenario for every watch.
`
`3.2
`
`Voyage Plan and Integrated Navigation
`
`This paragraph aims to identify voyage planning in the context of an
`integrated navigation system. Navigation can be defined as
`the process of
`controlling the movement of a craft from one state (position, course, speed, etc.) to
`another state, under predefined conditions.
`
`Fig. - 1 : The Navigation Domain
`
`From the perspective of elementary navigation disciplines (Fig. 1), this
`definition encompasses a broad variety of subjects, ranging from positioning,
`meteorology, tides, tidal stream, ocean current, hydrography and topography to anti
`collision regulations, communication and ship manoeuvring .
`
`FLIR-1017.003
`
`
`
`the
`is comprised of
`the process perspective navigation
`From
`consecutive phases of
`planning, watch preparation, watch execution, and
`evaluation.
`
`is also the system perspective where we can discern the
`There
`elements of data, algorithms, user-interface, procedures and the navigator.
`
`With this cube-like model (Fig.1) of the navigation domain in mind we can
`discern various sorts of system integration. First there is integration of different
`navigation disciplines, which we could refer to as synergistic integration. Then there
`is the integration across the various phases of the navigation process, where the
`products of each navigation phase could be transferred to the next phases. In the
`system dimension integration is concerned with the allocation of tasks to either the
`system or the user, based on human factors methodology. In the data segment
`integration is concerned with data models, data standards and data quality.
`
`In view of the focus of this presentation I will not go into a detailed
`discussion of integrated navigation. The remainder of this presentation will focus on
`voyage planning, being the first two phases of the navigation process, across all the
`disciplines and all segments of the system perspective.
`
`3.3
`
`Voyage Planning Process
`
`The present standard for voyage planning is laid down in the IMO Guide
`to the Planning and Conduct of passages. This standard discerns the phases of
`Appraisal, Planning, Execution and Monitoring. Reading this document provides a
`good impression of the factors to take into consideration. However, the document
`does not provide' a clear picture of the logical structure of the process, the
`interrelationships of the various aspects to consider, the questions to be answered,
`and the products resulting from each phase. It is a listing of reminders and things-to-
`do without logical structure or sequence. Therefore the document does not provide
`a basis which is sufficient for the development of coherent automated support tools
`for voyage planning.
`
`Voyage planning is not a straightforward process which leads to the
`correct answer. It is much more a search through a wide variety of, often time-
`variant, information in many different publications. The navigator’s task is to identify
`and comprehend the most important aspects to develop his voyage plan. In doing
`so he is repeatedly revisiting these aspects at an increasing level of detail while at
`the same time the voyage plan develops.
`
`FLIR-1017.004
`
`
`
`Fig. - 2: Voyage Planning Process
`
`Voyage planning can be seen as an iterative cyclical process, (Fig.-2) as
`represented by a spiral model, with a standard logical structure and a clearly defined
`product for every cycle. Each product serves as a directive for the next cycle. The
`first cycle, route planning, is concerned with selecting the best route; the product is
`the route plan, an outline description of the route which is feasible within the
`constraints provided in the sailing order.
`
`The second cycle, navigation planning, is concerned with the question
`how to navigate the selected route: the precise track to follow, the associated safety
`margins, track deviation tolerances, the overall time schedule and the navigation
`procedures for the different phases of the voyage (Fig.2).
`
`The resulting navigation plan should provide guidance for every officer of
`the watch to independently carry out his watch preparation resulting in a fully
`detailed navigation scenario for his watch.
`
`Theoretically speaking each cycle as aforementioned consists of the
`consecutive phases of analysis, synthesis, decision, and direction for the next cycle.
`The analysis-phase starts with the basic issues such as: what is required, within
`which constraints, which information is required, what does that information indicate.
`In the synthesis-phase options are generated and considered. Next the plan is
`finalised in the decision-phase and worked out to the required detail in the direction
`phase in order to serve as a reference directive for the next phase.
`
`This formal description of the voyage planning process may seem very
`theoretical to the navigation practitioner. However, the experienced navigator may
`well recognise the ’essential ingredients in the procedure he personally developed
`over the years. This theoretical procedure is not meant to be formally implemented
`in full detail in the daily navigation practice. It is meant to provide the basis for
`development of automated tools to support the voyage planning process.
`
`FLIR-1017.005
`
`
`
`4. VOYAGE PLANNING SUPPORT OUTLINE
`
`following paragraphs provide an outline description of voyage
`The
`planning support as envisaged for ECDIS.
`It is based on the aforementioned
`analysis. It is not meant to provide a complete picture. It is an extract, just to provide
`an impression of the required functionality that would result from a proper analysis.
`
`4.1
`
`Cycle-1: Route planning
`
`The aim here is to select the best route fulfilling the mission within the
`constraints as prescribed. The system requests the ports of departure and arrival to
`be identified on an overview map, including the basic planning constraints in terms
`of ETD and ETA, speed characteristics and maximum draught, cargo class. The
`system searches a predefined route network, to come up with an outline of
`feasible route options. ‘Feasible’ in this stage indicates that the basic ship’s
`constraints have been verified against the route constraints. Therefore the attributes
`of each leg of the route network include the basic parameters of that leg, such as
`distance, maximum allowable draught, speed
`limitations and prohibited cargo
`classes. Attributes may also provide references to other limitations that should be
`brought to the attention of the mariner on presenting the route as a feasible option.
`Next
`the presented
`route options are verified against a climatologicl and
`oceanographic database for critical and significant environmental factors as defined
`by the operator in terms of wind-speed and -direction, seastate,
`ice, ocean
`currents. Unfeasible route options (e.g. through ice) are then deleted and significant
`environmental characteristics are assigned to the remaining route options. The
`result is an overview of feasible route options with their specific characteristics in
`terms of distance,
`time, economy, and environmental
`factors, providing
`the
`necessary information to make an initial route selection. The result is a route
`defined by Route points and connecting legs, with an associated bandwidth for
`detailed track planning, together with an initial time-schedule and possibly some
`pointers urging for more detailed planning, such as tidal time-slots.
`
`4.2
`
`Cycle 2: Navigation planning
`
`The main questions to be answered in this cycle are concerning the
`definition of navigation track, its subdivision into phases of navigation (e.g. ocean,
`coastal, confined waters, inshore conditions), the associated safety margins and
`cross-track tolerances, the associated navigation procedures, and the detailed
`planning of critical elements of the voyage (e.g. tidal time-slots, critical passages,
`etc.). Before the course lines are drawn the system should mark areas of unsafe
`waterspace (within the defined route bandwidth). Then it highlights the vessel traffic
`data along the route such as TSSs and recommended tracks and routes. With this
`information the navigator can draw the initial course lines. Next, the system provides
`an initial subdivision of the track into the standardised phases of navigation.
`Assigning these phases of navigation automatically assigns specific (standardised)
`navigation procedures (positioning procedures, manoeuvrability, bridge manning,
`
`FLIR-1017.006
`
`
`
`etc.) to each phase of the route. Then the track is tested for critical points, as
`defined by the user, based on a combination of criteria such as safe water margin,
`positioning accuracy,
`tidal stream and water depth, prompting the navigator to
`adjust the track or to define additional measures and criteria in a decision point.
`
`traffic
`regarding
`information
`the system generates associated
`Then
`management (reporting point, procedures etc.), pilotage (procedures, positions etc.)
`and communication, based on the fairways and traffic management regions that are
`passed. The resulting Navigation plan provides all information for every officer of the
`watch (OOW) to do the planning of his next watch in full detail.
`
`4.3
`
`Cycle-3: Watch preparation
`
`The aim of this cycle is to produce a fuily detailed navigation scenario for
`the next four to six hours
`
`Upon starting his preparations the OOW will require a geographical
`overview of the voyage with a small window indicating the area of interest for the
`hours of his watch. From here the OOW will focus on the area within this window to
`familiarise with details of the navigation plan for his watch. The system recalculates
`the planned time schedule in case of any significant deviation from the route or time
`schedule. This may also involve recalculation of tidal streams UKCs etc.. Now the
`OOW will need to review the weather situation for his watch. To this purpose the
`system provides a comprehensive graphical presentation of the weather situation,
`based on actual data (own sensors), nowcast- and forecast-data, focused on: wind,
`seastate, visibility and precipitation. The OOW draws conclusion on impact on
`speed limitations, positioning options and collision avoidance. The next step is for
`the OOW to plan every course alteration
`in full detail under the anticipated
`circumstances of tidal stream, visibility and traffic.
`
`Then the OOW attempts to picture the visual environment in terms of both
`general and navigation specific characteristics. The system may provide support by
`detailed pictures, annotated aerial overviews and possibly a video impression. This
`information may be augmented by a textual description, which is kept to a minimum.
`
`The navigation pian, together with the detailed complementary information
`can be seen as the detailed navigation scenario in which the track and the
`associated
`time schedule are
`leading
`for
`the actions
`to
`take,
`in
`terms of
`manoeuvres, radio communication, ship’s procedures, navigation procedures and
`decisions on feasibility.
`
`Once again this description is far from complete, it is just an extract,
`meant to provide a picture of logical structure derived
`from analysis of the
`underlying process, resulting in options and requirements for automated support.
`
`FLIR-1017.007
`
`
`
`5. CONCLUDING REMARKS
`
`Modelling the process to be supported provides a clear insight into the
`logical sequence of questions to be answered, with the data available in the specific
`phase of the process.
`
`This can provide logic and structure into the supporting system, thus
`inviting the user to follow a structured process, at the same time ensuring that all
`relevant information is considered. A formal analysis of marine navigation and the
`processes involved could serve as a reference for manufacturers, data managers,
`researchers and regulators to provide coherence and purpose into the development
`of ECDIS as an information system. It could also serve as a reference for the
`customer to compare and contrast different systems.
`
`Bibliography
`
`IMO, International Maritime Organization; Guide to the Planning and Conduct of
`Passages: IMO Circular SN/CIRC. 92; London, 23 October 1978.
`
`International Maritime Organization; Performance Standards for Electronic
`IMO,
`Chart Display and Information Systems (ECDIS); Resolution A 817(19) adopted
`at the 19th session of the IMO general Assembly, London, 23 November 1995
`
`STCW-95, Standards for Training Certification and Watchkeeping 1995; Voyage
`Planning; STCW Convention of 1995, Section A - VIII/2; London 1995.
`
`FLIR-1017.008
`
`