Lifting the Veil on eNavigation – Obstacles that are slowing its implementation reveal what eNav will do

By Fred Pot
fred.pot@enavigation.org

October 2011

The International Maritime Organization (IMO), defining the goals of eNavigation in rather lofty and general terms, determined that eNavigation should:
• Facilitate communications including data exchange among ships and shore-based entities
• Integrate and present information on board and ashore to manage the workload of the users while also motivating and engaging the user and supporting decision making

A multinational group of experts (“the Correspondence Group” or CG) was formed under the auspices of the IMO’s Maritime Safety Committee (MSC) and Safety of Navigation Subcommittee (NAV). The CG was tasked to assess what obstacles stand in the way of achieving the eNavigation goals. You can’t really identify such obstacles unless you have a fairly good idea of the information exchanges that eNavigation will encompass. So the CG first identified these information exchanges and then looked for ways to streamline their processes and procedures.

Business process streamlining has been practiced by just about every company and government agency because it typically pays huge dividends. In many cases companies had to change the way they do things just to survive. Dreaming up a better way to do things is easy. Turning these “ideal world” dreams into tools that work reliably in the messy real world, and getting people to use the new tools the way they were intended to be used, is not.

In the CG’s report to the NAV committee it presented a 47 page spreadsheet of the obstacles it identified that prevent streamlining of processes and procedures along with suggestions on how to bridge these “gaps” as they call them.

The detailed description of these gaps reveal a great deal about the specific processes and procedures the CG wants to streamline.

eNavigation Information Services Menu
Fundamental to identifying the Gaps was identifying the information requirements of both mariners and shore-side users. The CG categorized information needs by the geographic areas of ship operations and the environment that existed within those areas. Five “Service Areas” were identified and the extensive menu of information needed within each termed a “Maritime Service Portfolio” (MPS):
• Harbor operations
• Operations in coastal and confined or restricted waters
• Trans ocean voyages
• Offshore operations
• Operations in Arctic, Antarctic and remote areas

How Will eNavigation Change ECDIS?
As e-navigation is implemented, ECDIS is expected to evolve in many ways, with its final shape still a matter for supposition and conjecture. Many of the new eNavigation information services for mariners will be made available through new features, intended to present the information in a meaningful, task-oriented way designed to assist the mariner in making operational decisions. Some examples of the proposed new features are:

Automatic Chart Updates – To use the voyage plan to automatically update the relevant ENC’s and electronic versions of publications (pilots, pilotage charts, tide tables, light list, etc.) in real-time. The gaps that the CG identified include the lack of timely delivery of ENCs and updates via the internet, the unnecessary complexity introduced by encryption of electronic charts and the lack of standards for transmission and display of non-ENC publications. While commercial solutions to overcome the ENC update problems are available, they are not available to all mariners. Also, electronic versions of publications are scarce.

Maneuvering Support – To support the mariner in making maneuvering (and mooring) decisions by presenting real-time own-ship status information, environmental information (winds, currents) and a highly accurate own ship position and heading relative to the dock. This might even include a prediction of what the ship’s position and heading will be in a couple of minutes. To receive this information it may well be necessary for the ship to exchange information with dock-side equipment, however, and this is another gap: standards for such information exchange are lacking.

PPU Information Exchange – The CG identified as a gap that digital communication with the pilot could be improved. The AIS “Pilot Plug” was the first attempt to exchange digital information with pilots. It allowed a pilot to receive and display AIS information and own-ship information on the carry-aboard laptop (PPU) but not all ships provided pilot plugs and those that did often positioned the plug in the wrong place on the bridge or had a plug that didn’t work at all. It appears that the CG proposes to fix these problems and to broaden the information exchange to more tightly couple the ship’s navigation system and the PPU. That could, for instance, include sharing VTS instructions, real-time environmental observations, waypoints, routes and maneuvering information.


Automatic Safety Information – The CG identified a gap that relates to Maritime Safety Information (MSI). Actually, it is more of a gaping hole than just a gap. Upon receiving real-time MSIs and other navigational warnings or broadcasts that are relevant for the vessel’s navigation, there is no interfacing technique that allows this information to be visible in real-time to the mariner. To fix this, the CG proposes:
• That shore authorities transmit critical safety information almost in real time and implement appropriate systems to enable them do so
• To present appropriate MSIs on a navigational display using standard symbols and text
• To automatically identify relevant MSIs during route planning and voyage planning
• That MSI’s have a parameter for urgency and that the ECDIS system provides the alarms


Real-Time Observations – The CG identified as a gap that currents, water levels and weather information are not automatically received. The CG appears to feel that, if such real-time observations were automatically received and presented (on-demand), the mariner could and would use them to make operational decisions. For example, transmission of real-time, tide-corrected bathymetry would allow the mariner to use ECDIS to automatically draw safety contours on the screen by taking into account the ship’s draft and the minimum under keel clearance.


Weather Routing – The CG focused on gaps in delivery and presentation of real-time observations but, surprisingly, did not focus on weather routing. Many ECDIS systems are not able to simulate alternative trans-ocean voyage tracks to estimate their time of arrival and fuel consumption while taking into account own-ship loading characteristics, short-term gridded binary (GRIB) weather forecasts, seasonally adjusted climatological information and pilotage charts. If it were made available, weather routing would assist the mariner with selecting a safe track while minimizing fuel consumption.


Traffic Organization Service – The CG identified as a gap that there are no standard data formats for on board capture and presentation that covers the entire scope of information provided by a VTS. The latter includes things like the VTS traffic flow plan and the time slot allocations to individual ships.

VTS authorities in some cases may not only prescribe traffic separation schemes and arrival and departure sequences, but actually prescribe the track to be followed, the time to start on the track and the arrival time at waypoints (“Gates”) along the prescribed track. This is likely the case not only for busy harbor approaches but also in waterways such as the Bosporus, the Malacca Straits, the English Channel and Gibraltar. ECDIS could be set up to automatically receive and display the prescribed track along with the speed to maintain to arrive at the check-in gates at the prescribed time. Doing so will greatly reduce voice VHF transmissions and thereby ambiguity caused by language comprehension obstacles.

The CG identified as a gap that current VTS hardware and software may not have the capacity for real time display of vessels’ track to provide a (NAS or) TOS service. eNavigation will change not only ECDIS but also shore-based VTS Systems. It will require, for instance, upgrades to enable these systems to automatically receive and accept Automatic Identification System (AIS) transmissions. Upgrades will also be required to allow transmission of traffic flow plans, their associated tracks and time slot allocations to individual ships.


Navigation Assistance Service – This service is normally rendered at the request of a vessel or by the VTS when deemed necessary. NAS is especially important in difficult navigational or meteorological circumstances or in case of defects or deficiencies such as lack of ENC coverage. When requested, the VTS operator assists the bridge team with determining the vessel’s position and provides advice to support on board navigational decision-making.

The CG notes that the VTS operator should have confidence that the information is correctly exchanged with the ship and that the system enables the operator to effectively communicate with the bridge team. To be effective, NAS requires close coupling of the on board navigation system with the VTS system. AIS provides some of the required telemetry, but standards are lacking for the exchange of other information, such as digital transmission and acknowledgement of information, warnings, advice and instructions that the VTS Operator provides.


Remote Inspection – Several of the gaps the CG identified refer to remote monitoring of the quality of on-board navigation systems by shore-based authorities. The CG seems to propose to enable shore-based authorities to remotely determine things like:
• The make and model of the ECDIS and radar systems that are being used, and whether they are running the latest version of the system software. This tells them, for instance, whether the on board ECDIS can automatically receive and display MSIs.
• The make and model of the GPS and eLoran receivers that are being used and whether they are running the latest version of their system software along with their position accuracy.
• The version of the ENC being used for the coastal area and for the harbor approach and whether the on-board ECDIS system can automatically receive and install a new version.

This type of fully automated remote inspection is likely to be more effective than the current practice of only relying on one-time type certification of navigation equipment that freezes its further development.

Remote Update of AIS Voyage Details – The CG identified as a gap the “lack of a single-window and/or automated and single entry for any required reporting information into the system for it to be shared by authorized authorities without further intervention by the ship during navigation”. From the proposed solution it becomes clear that the CG is referring primarily to AIS voyage details. The CG appears to favor enabling shore-based authorities to remotely update a ship’s AIS voyage details if they are out of date, which still occurs quite frequently. The CG also proposes that ship operators use satellite-based systems to monitor its ships’ AIS transmissions (AIS-S) and alert the bridge team if the voyage details are out of date.


Standardized and Automated Reporting
How will eNavigation change the mariner’s administrative processes and procedures?

The CG identified a host of gaps that involve processes and procedures that are not associated with the safe navigation of the ship, but take up a lot of the mariner’s time. For example, the CG identified insufficient means for ship reporting, and proposes to “remove the need for human interface and communication of manually operated systems by replacing them with automated systems (based on shipboard AIS) that will seamlessly populate VTS and Marine Domain Awareness (MDA) systems, anywhere in the world”. An ambitious goal, this requires for instance that the European SafeSeaNet, the Baltic nations’ HELCOM, the US Electronic Notice Of Arrival/Departure (eNOA/D) and all similar national and port systems in the world will automatically receive and accept a single set of electronic reports about the vessel, the voyage, the cargo, the crew and the passengers.

The above list of proposed services was not provided by the CG. The author merely inferred them from the CG’s gap analysis. The list of proposed services is, also, not intended to be comprehensive. The CG identified many more gaps that are associated with Search And Rescue (SAR) and with Ice Navigation along with a host of others but the services described above represent the major ones that mariners would be able to use in the normal course of operations. Everyone that will be affected by eNavigation should read the report of the CG to the NAV committee. It may be found at http://e-nav.no/media.php?file=96

It is not too late to influence the design of eNavigation services that will be offered. The eNavigation Conference in Seattle (November 29-30, 2011) provides an excellent opportunity to provide feedback to not only the Chairman of the CG (Mr. John Erik Hagen, Norwegian Coastal Administration) but also to the USCG and US Federal Department of Transportation officials that in turn are in a position to influence implementation of the CG proposals at the IMO, IALA and ITU level.

Fred W. Pot is Principal of Marine Management Consulting and can be reached at fred.pot@enavigation.org. He acts as Co-Chair for the 2011 eNavigation Conference along with Capt. Robert G. Moore, who contributed to this article.