Findings of Canadian e-Navigation User Needs Survey

A comprehensive Canadian e-Navigation User Needs Survey was conducted during May - October 2009. The survey included both web-based surveys and personal interviews conducted in the four main maritime regions of Canada.

The survey questionnaire used was similar to the one that was jointly-developed by Germany and Canada for the worldwide, international survey conducted in early 2009 and reported at IMO NAV55 (NAV 55/11/3 and NAV55/INF.9). This included three main categories:

• Maritime Communications
• Human Machine Interface
• Technical/Operational Enhancements

A total of 177 persons participated, including 113 persons who completed the web-based survey form, and 64 persons who participated in the regional interview sessions. Participants ranged in age from less than 26 years to over 65. Those who were 46-55 years comprised the largest age group. Overall, 89% were males. Proportionally, more females participated in the survey interviews than the web-based survey. Over 65% of the participants worked onboard vessels, while 35% held shore-based positions. Of those who worked onboard vessels, most had first served as a mate/officer and then later as a master or pilot. Average onboard experience was over 10 years, and included sailing on a wide range of vessels. For those who worked ashore, the average work experience was over five years, and included positions at vessel traffic centers, port authorities, and shipping companies.

The results of the comprehensive Canadian e-Navigation User Needs Survey were compiled into three main groups:

1. Opinion ratings (e.g., agree - Neutral -- Disagree)
2. Ranking/priority (e.g., 1st, 2nd, 3rd, etc.)
3. Comments provided by participants. As appropriate, this included statements for and against (i.e., "Pros" and "Cons") the various topics that were surveyed.

The following sections correspond to the numbering scheme used for the survey questionnaire.

1.1 Problems Experienced

Most participants had not experienced major problems in maritime communications. Of the five potential problem areas listed on the survey form, poor English language skills was considered to be the most important problem for both ship-shore/shore-ship and ship-to-ship communications. Other types of Ship-shore/Shore-ship communications problems that were mentioned included "dead zones" where there was a lack of maritime communications coverage, availability, or reliability in some coastal areas.

Ranked in order of importance, concerns about the ship-shore/shore ship communications that were rated at high or moderate levels included:

The most important ship to shore and shore to ship communications in order of importance

Priority	Description	High	Moderate	Total Percentage
1st	language skills	7%	28%	35%
2nd	high volume of traffic	6	29	35
3rd	reporting requirements	6	22	28
4th	unreliable comms equipment	5	20	25
5th	non-standard phases	3	18	21

Similarly, there were some concerns about communications between ships:

Top five concerns pertaining to communications between ships

Priority	Description	High	Moderate	Total Percentage
1st	language skills	14%	31%	45%
2nd	high volume of traffic	6	24	30
3rd	reporting requirements	5	24	29
4th	unreliable comms equipment	2	15	17
5th	non-standard phases	2	13	15

Comments provided:

• High-volume of traffic communication is a problem in certain areas (e.g., Great Lakes).
• VHF Channel 16 is often used for routine, non-urgent/non-distress communications. This is more prevalent with fishing and recreational vessels.
• False alarms from the communication systems (e.g., GMDSS alerts) are distracting from navigational tasks, especially when they occur during critical situations.
• Key communications issues include increasing traffic (i.e., high volume of radio comms) reliability, security, and practicality.
• Authorities want more and more information (USA and Canada). Increased reporting requirements are becoming burdensome.

1.2 Use of Broadband for Maritime Communications

79% of the participants are in favour of using broadband for the provision and exchange of maritime communications. Of the three types listed in the survey, the greatest interest was in the use of satellite broadband for both ship-shore/shore-ship and between ship communications. A majority of participants were also in favour of using mobile phone and Wi-Fi.

Comments provided:

• Key issues of broadband communications include reliability, coverage, costs and safety.
• Satellite broadband will eventually have wide coverage and good reliability. But, it should primarily be used for non-navigational or non-urgent communication (e.g., routine
  reporting). It should not be used for "surfing the net!"
• Mobile phones can be used effectively for making arrangements with pilots.
• Communication between vessels and VTS should continue to be conducted via VHF voice communications. In this manner, relevant navigation-related information is
  available to all vessels within the designated VTS area.
• Satellite phones are expensive and not always reliable.
• Greater use of broadband could result in "quite-er" VTS.

1.3 Communication between Shore Authorities

Few participants see major problems in communications between shore authorities.



Ranked in order of importance, concerns about some communication issues that were rated at high or moderate degree levels included:

Top five concerns pertaining to communications between shore authorities

Priority	Description	High	Moderate	Total Percentage
1st	unwillingness to share information	10%	34%	44%
2nd	coordination between shore authorities	9	31	40
3rd	different data formats	10	24	34
4th	VTS send faulty AIS data sets	5	10	15
5th	exchange between VTS and pilots	4	10	14

Comments provided:

• Too often, there is a need to send the same information several times to different shore authorities, and in different required reporting formats. Standardized reporting forms
  agreed to by all responsible agencies would significantly reduce workload.
• Improved sharing of information could reduce duplication of communication work. For instance, there are too many separate pre-arrival notices because government agencies do
  not share information with one another. Need to streamline.
• There are differences between those who are responsible for providing necessary information, and those responsible for transmitting to users.

1.4 Reporting Requirements

A large majority (72%) of participants are in favour of vessels having to send required reporting information only once.

Comments provided:

• Ideally, a ship would file a single report to one portal, and then it would be distributed to all relevant agencies. This would reduce operator workload (shipborne and ashore), save
  time, reduce costs, prevent errors and keep VHF channels free for other communications.
• All responsible shore-based authorities (e.g., VTS, port authority, etc.) should have access to this information so that only important changes need to be communicated via
  voice when the situation demands.
• Current reporting requirements are burdensome, and can be a distraction from performing navigational duties. Multiple reporting in different required formats causes increased
  workload, especially in confined waters where there is heavy traffic.
• It is a constant challenge to satisfy both Canadian and USA requirements.

AIS Binary (Application-specific) Messages

1.5 Knowledge or Experience (of AIS binary messages)

• Less than one-half (47%) indicated they had a high/moderate degree of knowledge about (or experience with) AIS binary messages. However, based on their responses to further questions and additional comments that were provided, many participants were not aware that there is a difference between AIS targets and AIS binary messages. Quite likely, the overall percentage of persons having actual experience in using AIS binary messages is low.

Comments provided:

• Good experience on AIS binary messages (e.g., water levels) has been gained in St.
  Lawrence Seaway, and portions of the St. Lawrence River (Quebec City).
• Maritime pilots using Portable Piloting Units (PPUs) are already using of this type of
  information for air draft (e.g., Halifax pilots).
• For certain types of information (e.g., met/hydro), this is the best means to provide.
• AIS binary messages can and should be displayed on PPUs, ECS, or ECDIS.
• There should be a "guarantee" that any AIS information is also available via backup AIS or internet.

1.6 Effectiveness of AIS binary messages

Of those that indicated high/moderate levels of experience, there were varied opinions on whether AIS binary messages can be an effective means to transmit navigation-related information. While 51% of those experienced with AIS binary messages felt it was an effective means to transmit navigation-related information, 28% expressed a neutral opinion or disagreed, and 10% had no option (Figure 1.6).

Comments provided:

• AIS and ATONIS represent an excellent means of information exchange.
• AIS binary messages should complement voice VHF.
• Not currently effective due to display constraints (e.g., ECDIS) and accuracy issues.
• Must identify what is important information to transmit (no spam!)
• AIS should primarily be used for vessel ID and tracking.
• This type if information can effectively be displayed in real-time on ECDIS.
• Too few sensors (e.g., for water levels) can lead to problems.

1.7 Concerns (about the use of AIS binary messages)

Both experienced and inexperienced participants raised concerns regarding the use of AIS binary messages for the transmission of navigation-related information (Figure 1.7).

Listed in order of importance, concerns that were rated at high or moderate degree included:

Top seven concerns pertaining to concerns about the use of AIS binary messages

Priority	Description	High	Moderate	Total Percentage
1st	vessels without AIS	41%	28%	69%
2nd	no feedback, if msg received	33	29	62
3rd	no feedback, if msg understood	32	29	61
4th	too slow for time-critical information	28	28	56
5th	slow transfer of informaiton	20	32	52
6th	geography masking transmission	19	29	48
7th	AIS broadcasts unreliable	14	19	33

Comments provided:

• The alarm indicating that an AIS message is received (if it exists) is often switched off and officers may be too occupied with other duties to recognize if/when this occurs.
• There is no confirmation that a message was received unless a reply is sent.
• Concerned about some vessels not receiving crucial broadcast messages (e.g., only have AIS Class B receivers). Unless regulatory requirements mandate AIS for fishing fleets
  and recreational boaters, AIS remains a commercial fleet issue.
• In concept, AIS binary messages are a good idea. But, have concerns about:
  • How would a voyage plan sent to a ship be acknowledged? What if changes are needed? Who decides? When would this occur? How often?
  • Have concerns about the ability to display additional navigation critical info on existing shipborne displays.
  • Ability to understand received information. What if incorrect or confusing?
  • No feedback is a limitation.
  • Currently, need to use Pilot Plug in order to access and display this type of information.

2.1 Presentation of Additional Information on Navigational Displays

In general, there is broad support for the presentation of additional information on the navigational displays on the ship's bridge.

Comments provided:

• The availability to display real-time information on the navigational displays would be an advantage for mariners in terms of informed decision-making and safety-of-navigation.
• Information overload is an increasing concern, and needs to be prevented.
• The presentation of information should be user-selectable. Information should always be available. But, it is the mariner who must decide what information is important and when
  it should be displayed (e.g., on ECDIS as a supplemental layer).
• A suggestion: This type of information should be provided on an additional dedicated screen (e.g., Pilots Portable Unit or notebook computer interfaced to the Pilot's plug).

2.2 Filtering of Information for Presentation

Participants felt that that during certain circumstances, there should be means whereby some broadcast data could be filtered based on user-set parameters.

Ranked in order of importance, those parameters that participants are strongly in favour or agree included:

Top four parameters pertaining to filtering of information that participants are in favour of

Priority	Description	High	Moderate	Total Percentage
st	info only from user-selected harbour	47%	31%	78%
2nd	info only from user-selected sea area	48	28	76
3rd	position of own ship	47	18	65
4th	entered route plan	41	22	63

Comments provided:

• The system should be designed to be able to over-ride (or cancel) filters in certain circumstances (e.g., severe weather warnings, divers in water, vessel on fire, etc.)
• No need to deal with telecomm traffic that is irrelevant to the vessel's safe navigation.
• Too much information can be dangerous. Not all information is useful.
• Instead of filter, different displays should be available, but only displayed when needed.
• Would help to focus critical info, but current situation influences what is needed.
• Large area information should always be available, but smaller area could be displayed
  based on user-defined parameters.
• Security considerations must be considered, and are dependent upon vessel type, cargo,
  location, etc.
• Potentially, this could cause a problem if the route plan established by the navigation
  officer differs from the pilot's plan. It could lead to misinterpretation (e.g., X track).

2.3 S-Mode Concept

72% of the participants were in favour of the S-Mode concept for shipborne navigation displays.

Comments provided: [Note: More comments were provided on S-Mode than any other topic]

• Pros

  Some form of standardization (e.g., default menu, interface, presentation, etc.) would be very helpful for navigation control and monitoring.

  • S-Mode would be a significant benefit to pilots and mariners changing ship or company.
  • Would be a major improvement for pilots boarding different vessels every day; standard controls more important than standard display.
  • Users should have the final say in terms of what is needed at a certain time. But, this would be very helpful in having a common starting point.
  • There are limits on what can (or should be) standardized. Having a default mode of operation is different than a standard display.
  • Absolute necessity; but should be called a "default" mode. All systems should have a default (or reference) mode.
  • S-Mode should concentrate innovations on the needs and capabilities of the users, and make new technology solutions more user-friendly.
  • S-Mode needs to be "user set" with minimum guidelines/standards.
  • Regular reviews of S-Mode standards should ensure that latest innovations are considered.
  • Collaborative R&D programs by groups of several companies should be established in order to achieve consensus on what and how.
• Cons
  • Only partially in favour; want to see more specifics as to what it would be. Depends on what is considered a suitable "standard mode." Also, different people prefer different levels of display (minimum vs. maximum content).
  • Too much of an excuse for lack of proper training.
  • Establishing an S-Mode may limit further innovative development or use of improved technologies. Need to use optimum capability, not S-Mode.
  • Information that is important during certain navigational situations might be filtered out.
  • Manufacturer specific training and proper handover would be better than introducing SMode.
  • Pilots are already bringing their own computers (i.e., PPUs) aboard the vessels. If the information is already displayed in a familiar way on their PPUs, then displaying thissame information on other shipborne equipment/systems is less important.

3.1 Redundancy for a GNSS

79% preferred another form of Global Navigation Satellite System (GNSS) as redundancy for the current Global Positioning System (GPS). While 61% were in favour of radar positioning;
only 24% were in favour of using Loran-C. While 51% indicated they disagreed or were opposed to using Loran-C be continued, many of the comments provided were in support of Loran-C being continued.

Comments provided:

• Other GNSS
  • If any satellite-based navigation system completely fails, it would take years to replace. An earth-based nav backup system makes sense vs. another satellite system that would be subject to the same failure.
  • Backup has to be precise (e.g., same as satellite-based positioning)
• Loran-C
  • Enhanced Loran-C provides an independent navigation system which is not dependent on common failure situation (i.e., solar activity could cause all satellite positioning systems to become inoperative).
  • If any alternative is required, an e-Loran-C system would be preferred.
  • By keeping old systems, it will slow down improvements (e.g., Loran-C, and too many floating aids to navigation).
  • Loran-C because our fishing data is logged using it.
  • Loran-C is important to fisherman with experience prior to GPS.
  • Fishermen were trained with Loran-C, and still use it. But, increasingly use GPS.
• Radar
  • Radar positioning is currently the main navigation system used in the St. Lawrence River.
  • Redundant system should be relatively simple and cheap to install & maintain.
  • Prefer to use radar as primary system when in coastal waters. Cross-check/confirm with GPS.

3.2 Strategic Coordination of Vessel Traffic Flow

Most participants are highly in favour of having a more shore-based strategic coordination of
vessel traffic flow.

Ranked in order of importance, the situations that participants were strongly in favour or agreed with included:

Top five shore-based strategic coordination of vessel traffic flow

Priority	Description	High	Moderate	Total Percentage
1st	very large vessel movements	44%	38%	82%
2nd	traffic density	43	35	78
3rd	current environmental conditions	42	35	77
4th	transit/procession order	39	35	74
5th	berth/lock assignment	35	38	73
6th	vessel meeting/passing	37	30	67

Comments provided:

• There is a need for better coordination on what is actually important (i.e., priority) information. More is not always better.
• This is currently in use on the St. Lawrence River. Anything that makes traffic more efficient should be encouraged.
• This should also pertain to pleasure craft, fishing vessels, tour operators, ferries, commercial vessels, and military vessels.
• Having exact information provided without delay would be useful. But, this may demand more attention by the watchkeeper (shore-based and ship borne).
• This would require that shore-based personnel (i.e., VTS operator) have knowledge and experience with shipborne navigation. Need to be in the mariner's shoes.
• Ship management is good, but not for direct vessel control. It should always be up to ships master to decide (can be other contributing factors that the VTS operator is not
  aware of).
• Do not agree with vessel control from ashore. In particular, crossing/passing decisions should be left to those on board the vessels, who have a full understanding of the
  situation, not to some management system on shore.

3.3 Automatic Checks for Required Shipboard Routines

While a majority (55%) of participants were in favour of having automatic checks for certain shipboard routines, 17% had a neutral opinion and 23% were not in favour or opposed.

Comments provided:

• Pros
  • Automatic checks would reduce the risk of human error and omission, save time, reduce paperwork, and ensure compliance with the checklists. They could also mitigate liability.
  • Automatic checks should only be used as a useful reminder for regular manual checks.
  • Great for safety orientation and checklists.
• Cons
  • May be a good idea, but not practical from a regulatory point of view. Compliance with International Safety Management (ISM) Code and "Best Practices" already provide for
    this.
  • Not really a necessary part of navigation; more part of management; could be a distraction.
  • Automatic checklists are not reliable and therefore cause additional workload.
  • Information duplication could create errors that are hard to detect. Also, it would be hard to determine what is correct?
  • It may be difficult to find one standard for the various types of vessels.
  • There is no need to duplicate paper checklists. Also, mechanically performing a task with no thought can lead to problems.
  • Checklists can give a false sense accomplishment. On several occasions they have proven to me that they do not work.

3.4 Paper Information in Electronic Form

72% of participants were in favour of having paper information and documentation provided in electronic form.

Comments provided:

• Pros
  • Having electronic versions could save time due in locating and accessing information
    (e.g., with the help of a search function).
  • This may be useful in tracking automatic updates (e.g., of Notices to Mariners), and
    possible integration of information on other systems on the bridge (e.g., ECDIS).
  • Electronic documents should have a user-friendly design, be printable, or be additionally
    provided as paper version.
  • Could accomplish more efficient and effective filing and monitoring.
  • Should not be necessary to have paper - at all!
• Cons
  • When reading documentation, it is often easier to work with printed versions.
  • This is really not necessary, nor within the scope of e-Navigation.
  • This could lead to unnecessary duplication and uncertainty as to what is current.
  • Still need to have paper documentation (signed forms, logs, etc.)

Over 50% of the survey participants provided additional comments or expressed concerns about e-Navigation. This portion was even greater (70%) for those who participated in survey
interviews. Listed in descending order based on how often mentioned, these comments/concerns can be grouped into six broad categories:

• Implementation process
• Information overload
• Cost, reliability, and complexity of systems
• International standards and regulations
• Further study
• Training/certification

• 1. Implementation Process
  • What is the time-line for implementation of e-Nav? Will there be phased-in approach?
  • There should be a mechanism whereby people can propose changes as e-Nav becomes operational.
  • Need to be careful that in 'implementing' e-Nav, we do not slow down progress or innovation.
  • We need to define what is e-Nav should look like. Then, let current technology that is already being used help define where e-Nav should go.
  • Need to manage user expectations re: how and when e-Nav will be implemented.
  • On an ongoing basis, there is a need to ask about mariner views as to the window for implementation.
  • Need to have close collaboration with users before e-Nav is implemented.
• 2. Information Overload
  • Information is important, but workload control is as well. Information overload is dangerous.
  • The aim should be simplification and standardization with the goal of reducing workload and confusion.
  • Enhanced information with simplicity will be a key element.
  • Have concerns about overloading the mariner with too much information.
  • Need mariner input and consensus on what should be displayed, and how.
  • Easy access to decision-making information is important. There is need to ease the additional administrative burden of modern navigators.
  • More information -- if it is not specific to your current operation -- is just going to be annoying.
  • It is hard to imagine how to organize all this information, and how it should be used.
  • The type of information that should be displayed depends on the end user. Just because something is available, does not mean that it is necessary.
  • Mariners are not going to be looking at the windows anymore. This is going to be a problem.
  • Supplemental information (e.g., MIOs) should be "selectable. But, there should be some indication provided to alert the navigator that new info is available.
  • There needs to be a way to reduce or hide unnecessary information, so as to avoid cluttering the display.
• 3. Cost, reliability, and complexity of systems
  • What happens when various e-Nav systems begin to fail or become unreliable?
  • What will be the government responsibility to insure full availability (e.g., like for GPS).
  • What will the backup to e-Navigation systems/services?
  • Reliability of communication equipment (e.g., coverage and signal strength) may be a problem.
  • What are the costs associated with updating systems to conform to e-nav requirements; timeline?
  • What will be the cost of implementation? (e.g., who pays, how much?)
• 4. International standards and Regulations
  • e-Navigation equipment needs to meet international performance standards, and be certified compliant. Good example of that which already occurs for GPS equipment.
  • As technology changes, tendency will be to "improve e-Nav by adding additional components. Phasing in new carriage requirements must be considered (e.g., should only
    be done every 5-10 years).
  • Have concerns whether all government regulators can agree what e-Nav systems are really necessary (not just nice to have), and what equipment will be required (mandatory).
  • Need to have both regional and international harmonization.
  • It will be important to share findings with other countries (e.g., USA) to see if their plans for e-Navigation will be similar - or different.
  • Carriage requirements for domestic users, especially smaller vessels, must be discussed.
• 5. Further Study
  • There is a need to:
    • Conduct an audit of what e-Nav capabilities are currently used in the area/region?
    • Determine what organization(s) has leadership and who else should be involved.
  • There is a need for a study on effect of situational awareness when using e-Navigation and INS.
  • How should e-Nav systems be evaluated?
  • Need to look into the possibility using e-Navigation to replace current VTS systems with either an automatic system or a silent one.
• 6. Training/certification
  • It will be important to know what type of information the e-Navigation will provide - and how it should be properly used. For instance, with the advent of GPS, there are lots of
    sailors now who don't know the difference between Speed-Through-the Water (STW) and Speed-Over the-Ground (SOG).
  • What should be the training/certification requirements?
  • Who and/or how will this be decided?
  • Will e-Navigation training become mandatory? If so, when?