Analysis of methods for communication the navigational

Zeszyty Naukowe 20(92) 25

Scientific Journals Zeszyty Naukowe Maritime University of Szczecin Akademia Morska w Szczecinie

2010, 20(92) pp. 25–32 2010, 20(92) s. 25–32

Analysis of methods for communication the navigational informations in the Remote Pilotage System

Analiza metod przekazu informacji nawigacyjnych w Systemie Zdalnego Pilotażu

Rafał Gralak

Maritime University of Szczecin, Faculty of Navigation, Institute of Marine Traffic Engineering Akademia Morska w Szczecinie, Wydział Nawigacyjny, Zakład Inżynierii Ruchu Morskiego 70-500 Szczecin, ul. Wały Chrobrego 1–2, e-mail: [email protected]

Key words: Remote Pilotage, e-navigation, methods of communication

Abstract The brand new technologies more frequently revolutionize the conservative fields of the navigation, such as

ECDIS for instance. The term of “E-Navigation” in the different forms is omnipresent in the major parts of

navigation, tried to substitute old-fashion technologies. The pilotage service is one of them, remains

immutable in its novelty and stays conservative from many years. The author focused on the technical aspects

of the system named Remote Pilotage System, as an aid to the in-shore and sea piloting methods. The content

of this article is focused on the analysis of methods for the voice-way information communication to the

navigator and the different interface figuration for the pilot. The described researches are the part of holistic

method of navigational information communication analysis for the Remote Pilotage System Interface.

Słowa kluczowe: Zdalny Pilotaż, e-nawiagcja, metody komunikowania

Abstrakt Konserwatywne sposoby prowadzenia nawigacji są coraz częściej rewolucjonizowane przez nowe technolo-

gie, na przykład elektroniczne mapy nawigacyjne ECDIS. Termin „E-nawigacja” pod różną postacią jest

obecny w głównych dziedzinach nawigacji, sukcesywnie zastępując przestarzałe metody jej prowadzenia.

Usługa zdalnego pilotażu jest jedną z nich, pozostaje niezmienna w swojej innowacyjności i trwa w konser-

watyzmie od wielu już lat. Autor skoncentrował się na technicznych aspektach systemu nazwanego Syste-

mem Zdalnego Pilotażu, przeznaczonego do wspomagania pilotażu na akwenach ograniczonych oraz

w żegludze pełnomorskiej. Treść artykułu poświęcona jest analizie metod komunikowania głosowego infor-

macji nawigacyjnych do nawigatora oraz różnym konfiguracjom interfejsu dla pilota. Opisane badania są czę-

ścią całościowej analizy metod komunikowania informacji nawigacyjnych w Interfejsie Systemu Zdalnego

Pilotażu.

Introduction

The E-Navigation Committee of IALA’s pro-

poses following working definition of E-Navigation

as a starting point: “E-Navigation is the collection,

integration and display of maritime information

onboard and ashore by electronic means to enhance

berth-to-berth navigation and related services,

safety and security at sea and protection of the ma-

rine environment” (Fig. 1).

E-Navigation is intended to make safe naviga-

tion easier and cheaper:

E-Navigation is the transmission, manipulation

and display of navigational information in elec-

tronic formats to support port-to-port operations;

it is needed:

• to minimise navigational errors, incidents

and accidents;

• to protect people, the marine environment

and resources;

• to improve security;

• to reduce costs for shipping and coastal

states;

Rafał Gralak

26 Scientific Journals 20(92)

Fig. 1. Safety of ship transportation event tree

Rys. 1. Bezpieczeństwo transportu statkiem – schemat blo-

kowy

• to deliver benefits for the commercial ship-

ping industry;

it can be delivered:

• using satellite positioning and radio commu-

nication systems;

• by introducing IBS and computer technology

on ships.

The aim is to develop a strategic vision for

E-navigation, to integrate existing and new naviga-

tional tools, in particular electronic tools, in an all-

embracing system that will contribute to enhanced

navigational safety (with all the positive repercus-

sions this will have on maritime safety overall and

environmental protection) while simultaneously

reducing the burden on the navigator. As the basic

technology for such an innovative step is already

available, the challenge lies in ensuring the availa-

bility of all the other components of the system,

including electronic navigational charts, and in

using it effectively in order to simplify, to the bene-

fit of the mariner, the display of the occasional lo-

cal navigational environment. E-navigation would

thus incorporate new technologies in a structured

way and ensure that their use is compliant with the

various navigational communication technologies

and services that are already available, providing an

overarching, accurate, secure and cost-effective

system with the potential to provide global cover-

age for ships of all sizes.

Considering the wide range of options and bene-

fits that could become part of E-Navigation, the

primary value of E-Navigation is to join the ship’s

bridge team and sea traffic monitoring teams to

create a unified navigation team that would achieve

safer navigation through shared information. For

full implementation of such a system it would need

to be mandatory for SOLAS vessels and scalable to

all users. E-Navigation would help reduce naviga-

tional accidents, errors and failures by developing

standards for an accurate and cost effective system

that would make a major contribution to the IMO’s

agenda of safe, secure and efficient shipping on

clean oceans [1].

General assumptions to Remote Pilotage System

Definition of Remote Pilotage System

Remote Pilotage System will be enclosed in the

E-Navigation notion. RPS assumes to be “an aid to

navigation intended for the conventional pilotage

service” in the first stage of its development

process. The prediction of possible development of

RPS is very difficult but it could be anticipated that

the system will be developing in two main direc-

tions:

• integrated system – where information from

ships will be send to shore data processing cen-

tres and the main decisions about the ship navi-

gation assist will be made onshore;

• distributed system – based on development of

ship intelligent self-organising systems which

will be able to exchange the information be-

tween the other ships and will be able to process

the information and to support the decision of

navigators.

Remote Pilotage System Conception

There are several problems that should be solved

before implementation of such system:

legal aspects;

mental aspect of stakeholders, navigators and

pilots;

technical aspect of ship an shore systems;

communication aspects (shore to ship and ship

to ship).

Most likely the final versions of the e-navigation

system will be the combination or above solutions.

In more near future the system will be most likely

developed in two stages:

first stage which will be totally based on exist-

ing bridge and communication systems (AIS,

ECDIS and voice VHF) only development of

shore piloting centres will be necessary;

final stage with dedicated system based on created

ship e-navigation support platform where satellite

communication will be applied (Fig. 2).

Safety of ship

transportation

Accident

prevention

Consequences

mitigation

Training

Policy and

management

Security

Safety

culture

Technical

systems

Preparadness

and Response

Short term

prevention

Search and

Rescue

Long term

protection

Analysis of methods for communication the navigational information in the Remote Pilotage System


Fig. 2. Possible final development of Remote Pilotage System

Rys. 2. Możliwa finalna wersja Systemu Zdalnego Pilotażu

The most important problem during creation of

Remote Pilotage System concept is concerned with

answer to following important questions:

the communication platform and technical

means used for communication, transmission

protocols and data encryption;

structure and basic equipment of shore data

navigation support and data processing centre;

equipment should be designed to engage both

the bridge team and VTS operator, maintaining

high levels of attention and motivation without

causing distraction;

man / machine interface (i.e., balance between

standardisation and allowing for innovation and

development);

technical structure of ships data exchange sys-

tem and the presentation format of data within

the integrated bridge system and pilot’s inter-

face.

The further part of the article will be devoted to

above mentioned two last subsections [2].

Communication aspects required for Remote Pilotage System

The following is a list of key communication

aspects required for Remote Pilotage System,

relating to both technical and content:

autonomous acquisition and mode switching

(i.e., minimal mariner involvement needed);

common messaging formats;

sufficiently robust (e.g., signal strength, resis-

tance to interference);

adequate security (e.g., encryption);

sufficient bandwidth (data capacity);

growth potential;

automated report generation;

global coverage (could be achieved with more

than one technology);

the use of a single language, perhaps with other

languages permitted as options.

The following communications issues are

among those that will require resolution to achieve

the above:

it seems likely that a satellite broadband link

will be required to achieve the above require-

ments, and consideration must be given to how

this will be achieved;

the question of cost and who pays for the

provision of a satellite broadband link must be

resolved early in development of E-Navigation /

RPS [3].

The first stage of RPS development will be

totally based on existing bridge and communication

systems. Most of new developed hardware and

software will operate with standard NMEA

protocol and Serial / LAN communication for

testing on possessed test bed. Real time tests may

be carry out with existing standard bridge and

communication system [4].

Method of navigational information communication analysis

Due to problems of IBS definition an effort

should be made to standardise and define minimal

subsystems and modules of Integrated Bridge Sys-

tems and such definition will be base for further

Remote Pilotage System definition and creation.

The IBS system is nowadays the integration of fol-

lowing subsystems: Radar / ARPA, ECDIS / ENC,

VDR / S-VDR, Systems of control HAP / CSAAP,

Gyrocompass, Autopilot / Trackpilot, Logs, Echo-

sounder, GMDSS, SSAS Ship Security Alert Sys-

tem, External communication, AIS, DGNSS and

Inertial and mooring support systems. So many

integrated electronic systems and devices under one

system will lead to several problems [5].

Series of researches and tests launched in the

Marine Academy in Szczecin are planned to elabo-

rate the most effective standard for conveying the

information between the pilot and the navigator of

the ship, in order to guide the unit safely both on

the inshore waterways and the open sea. The range

includes the following areas:

working out the most effective method for

gathering and exchange of navigation informa-

tion, using the following as the medium:

• sound (VHF, VoIP, etc.);

Internethigh speed

connection

Heavy trafic area transmittion unit

Central backup dbase server

User 1 (within range

of VHF)

User 2 (ourside

range of VHF)

User 3 (within range

of VHF)

Pilot

Mainframe

Remote piloting center

CONNECTIVITY IN REMOTE PILOTING

SYSTEM COORDINATION

Remote piloting center

Pilot coordinator

for whole area

Rafał Gralak


• graphics (ECDIS plug-ins, separate visuali-

zation system, etc.);

• two, above mentioned methods combined;

working out the most effective standard for

content and the form of navigational information

exchanged between the pilot and the navigator.

Test-bed specification

All researches had been carried out in Marine

Traffic Engineering Centre located at the Maritime

University of Szczecin which offers a full range of

scientific-research works in marine traffic engineer-

ing in open and restricted water areas (Fig. 3).

Fig. 3. Test-bed. Full Mission Ship’s Bridge Simulator

Rys. 3. Poligon badawczy. Wielozadaniowy symulator manew-

rowy

The MTEC comprises:

one full mission shiphandling simulator with

270° visualisation and live marine ship equip-

ment;

two multi task shiphandling simulators with

120° visualisation and mix of real and screen-

-simulated ship-like equipment including;

two desktop PC simulators with one monitor

visualisation and one monitor screen-simulated

ship-like equipment;

a dedicated staff and possibility to test new

developed hardware.

All hardware and software are forming the

Polaris System from Kongsberg Maritime AS

which was granted DNV certificate for compliance

or exceeding the regulations set forward in

STCW’95 (section A-I/12, section B-I/12, table

A-II/1, table A-II/2 and table A-II/3).

In order to create own ship models a hydro-

dynamic ship-modelling tool is available. This tool

enables creating almost any ship type (controls for

at least two engines with propellers’ controls for

fixed propeller, adjustable pitch propeller CPP and

azimuth; rudder controls adequate for various types

of conventional rudders and Z-drive / azimuth – DP

ready) with very high fidelity hydrodynamics in 6

DOF (surge, sway, yaw, roll, pitch & heave). All of

Integrated Bridge Systems defined appliances are

also included with possibility of logging systems’

signals, messages and data, also in service mode.

Windows OS allows to easy installing new deve-

loped software.

Assumptions to method analysis

The first phase of the researches using the Full

Mission Ship’s Bridge Simulator concerns the

analysis of methods for communication the

navigational information. The research (partially

executed) consists in conducting the unit through

the specific sections of the area, in this case

entrance to the port of Świnoujście, in the different

variants of communication and gathering and

passing the navigational information.

In the tests described, the most common method

in the marine communication was used as a first

one, this is the voice transmission using the VHF

panel. This type of communication is a base for the

remote pilotage, known for years, which is using

the form of navigational instructions from the VTS

side in case the ship is lead by the captain.

The voyage of the vessel was divided in three

sections of waterway:

straight,

bend,

mooring operations.

As a default the navigator had no ability to steer

the unit at his own discretion. All the commands on

the ship’s devices, executed by him on the bridge

were remotely generated in the pilot center (in

MTEC it was the Instructor Station). Tests were

limited to the commands on three ship’s devices,

that is:

• power order – commands ahead and astern,

• rudder order – commands port and starboard,

• thruster order – commands port and starboard.

Statistical analysis of the passages was based on

the following data logged from the ship’s devices

during the passage:

number of commands given by pilot;

average time to execute one command from the

moment is the pilot started to give it to the

moment of order realization by the navigator;

obtaining the percentage amount of faulty

realizations of commands given in the direction

pilot-ship;

obtaining the fairway safety limits for the

different variants of the unit passages.



During the research the pilot center was the

instructor’s station, where the voice commands

were given for the officer. To test different variants

of gathering the information by the pilot, aimed on

the interpretation of the current navigational

situation, three variants of pilot interface were

applied:

1. 2D motion (Fig. 4), standard ECDIS, North-Up

display, in the true motion complemented with

the speed vector and the data from the ship’s

navigational devices as: Log, Windmeter, Tele-

graph, Rudder and Thruster Order Repetitors.

Fig. 4. 2D pilot’s interface

Rys. 4. Dwuwymiarowy interfejs pilota

2. 3D motion (Fig. 5), system, which by its display

assures the eyeshot similar to the one, observed

by the navigator. The condition to obtain such

a eyeshot is creating a 3D reservoir map, with-

out the necessity to create the solid model of the

unit.

Fig. 5. 3D pilot’s interface

Rys. 5. Trójwymiarowy interfejs pilota

3. 3D motion with offset (Fig. 6), 3D panel

description extended with the possibility to

decentralize, move and rotate the point of view.

There is also a possibility to set the point of

view beside the contour of the ship’s hull, e.g. in

the front of bow during the mooring, what is

impossible in the reality. To obtain such a inter-

face configuration, it is necessary to construct

the solid model of the given unit and placing it

in the display coordinates. It increases the cost

of the system significantly, because it is

necessary to equip the unit with a number of

devices picturing the hull movements of the

wave and converting it to the pilot’s interface.

Fig. 6. 3D pilot’s interface with decentered point of view

Rys. 6. Trójwymiarowy interfejs pilota z możliwością decen-

trowania

The passages were executed in the following

configuration:

• sound communication – 2D pilot’s interface;

• sound communications – 3D pilot’s interface;

• sound communication – 3D with offset pilot’s

interface.

Results

The results have been obtained by carrying out

the passages of the vessel in the Port of Świnoujście

fairway, based on the commands given by the pilot

with using VHF station and different screen inter-

faces, to the navigator on the bridge. All the naviga-

tional information were logged with its’ parameters

such as time of execution and number of faults. The

statistical data processing was done for collected

samples, as fallows.

Time of execution the pilots’ orders

By “the average time of execution the pilots’

orders” we understand the time counted from the

moment the pilot starts to give the command to the

moment the given order is set by the officer. The

time to re-steer the ship’s devices is not included to

the results, as it has a different characteristics for

the different units.

The average time for orders’ execution is the

following:

• sound communication – 2D pilot’s interface:

Rafał Gralak


• sound communications – 3D (no offset) pilot’s

interface:

• sound communication – 3D with offset of point

of view on pilot’s interface.

Fig. 7. Average time of execution the pilots’ orders for 2D

pilot’s interface

Rys. 7. Średni czas realizacji komendy pilota przy zastosowa-

niu interfejsu 2D


(no offset) pilot’s interface


niu interfejsu 3D


(with offset) pilot’s interface


niu interfejsu 3D z możliwością decentrowania

Performing the results analysis for the passages

conducted for three types of path sections in the

configuration with three types of pilot interface

display, we can point out a number of dependences:

1. The time of change for the value given for

rudder order is the longest when compared to

other actions;

2. The time to realize the commands increases with

the intensification of frequency in the time unit;

3. Most of the times needed for a given value

change is oscillating in the range of 4–6 sec;

4. Commands on the helm in the mooring phase

takes c.a. 7–8 seconds due to operating with the

more significant deflection angles;

5. The average time of executing one command for

sound communication is 5,24 sec.

Faults in the orders communication

By the mistake we understand inconsistency

between the command given by the pilot and the

order realized by the navigator on the ship’s

devices. As a mistake we treat also incorrect pilot’s

command, which occurred as a result of wrong

interpretation of the navigational situation. Such

a mistake can be generated due to two reasons:

pilot’s mistake resulting from the lack of expe-

rience;

pilot’s mistake resulting from the inaccuracy

of the picturing the real navigational situation

on the panel.

The analysis of the results for the passages in the

assumed configurations, we can conclude that the

biggest number of navigational mistakes comes

from the passages while using the 2-dimension

pilot’s panel (Fig.10).

Fig. 10. Average percentage of faults in pilots’ orders execution

for all sections

Rys. 10. Średni procent błędów w komendach pilota dla

wszystkich sekcji toru wodnego

This may be caused by the following factors:

significant time interval when refreshing the

speed vector;

inaccuracy in picturing the turn rate of ship’s

envelope;

Straight

Bend

Mooring

0,00

1,00

2,00

3,00

4,00

5,00

6,00

7,00

8,00

Proppeler Rudder Thruster

4,50 4,63

no thruster

6,175,69

no thruster

4,90

7,13

3,10

Tim

e [s

]

Straight

Bend

Mooring

0,00

1,00

2,00

3,00

4,00

5,00

6,00

7,00

8,00

9,00


5,506,17

no thruster

6,335,12

4,00

4,54

8,67

3,50

Tim

e [s

]

Straight

Bend

Mooring

0,00

1,00

2,00

3,00

4,00

5,00

6,00

7,00

8,00


4,50

6,75

no thruster

5,78 4,88

no thruster

5,09

7,25

3,50

Tim

e [s

]

Straight

Bend

Mooring

0,00

1,00

2,00

3,00

4,00

5,00

6,00

7,00

8,00

9,00

3D+sound (with_offset)

3D+sound (no_offset)

2D+sound

0,00 0,00

5,26

0,00

6,98

9,09

5,666,38

7,04

Per

cen

t [%

]



significant delay in refreshing the envelope on

the screen;

necessity to work in the big close-up no refe-

rence to the further space, the shoreline.

Passages while using 3D pilot panel with offset

of view point turned out to be the safest. Such

a picturing has a number of advantages:

it reminds the reality more;

allows for changing the point of view;

possibility to refer the movement of the hull to

the static onshore objects;

during the manoeuvre of mooring there is

a possibility to move the point of view to any

place (including out of ship’s contour).

Average percentage of faults in correctness of

pilots’ orders realization for each variant of pilot’s

interface display is presented in figure 11.

Fig. 11. Average percentage of faults in the pilots’ orders

execution for all methods

Rys. 11. Średni procent błędów w komendach pilota dla

wszystkich metod

Average percentage of faults in correctness

of pilots’ orders realization for sound communica-

tions between pilot and navigator is 6.49%.

Manoeuvring safety limits

The statistical data also contains the position of

the vessel during its passages. It allows to deter-

mine the manoeuvring safety limits (maneuvering

area) with using the special software to indicate the

most dangerous moments of the manoeuvring

process consequent from faults in orders communi-

cation. The presentation of manoeuvre area is

a perfect image of results obtained from the tests

for average time of execution and average percen-

tage of faults in pilots’ orders.

The voyages with 2D pilot’s panel show us (Fig.

12) direct transmission of previous results on both

safety limits’ shape. Carried out analysis pointed

that the manoeuvre area is the widest and most

dangerous exactly for 2D pilot’s panel display.

Fig. 12. Manoeuvring safety limits with faults marked for 2D

pilot’s interface

Rys. 12. Bezpieczne granice manewrowe statku z ewidencją

błędów w realizacji komend dla interfejsu 2D pilota


no offset pilot’s interface


błędów w realizacji komend dla interfejsu 3D pilota

The passages with 3D (Fig. 13) and 3D with

offset (Fig. 14) pilot’s panel both have less faults

number in the pilot’s orders than the passages with

using 2D interface. In consequence it had an effect

with the narrower manoeuvring area, especially

during mooring operations. The comparison of

manoeuvring areas for all passages configurations

presents figure 15.

7,13 6,68

5,66

6,49

0

1

2

3

4

5

6

7

8

2D+sound 3D+sound (no_offset)

3D+sound (with_offset)

Average percentage

of faults

for sound

communication

Per

cen

t [%

]

Rafał Gralak



with offset pilot’s interface


błędów w realizacji komend dla interfejsu 3D pilota z możli-

wością decentrowania

Fig. 15. Manoeuvring safety limits comparison for all pilot’s

interfaces configuration

Rys. 15. Bezpieczne granice manewrowe statku – prezentacja

dla wszystkich interfejsów pilota

The results show directly dependence between

the number of given orders (most of all for 2D

interface) and number of faults done by the

navigator in consequence the widest and most

dangerous maneuvering area.

Conclusions

The results obtained from the first stage of

analysis of methods for communication the

navigational information in the Remote Pilotage

will be the point of reference for further tests and

researches.

Such database will be the basis to create the

most effective, the safest and user-friendly systems

included in Remote Pilotage.

According to the results shown dependence

between the number of given orders to the number

of faults done during vessel’s passages the safety

criterion can be defined. It was stated that the 2D

pilot’s interface, as the most non transparent source

of the manoeuvring situation for the pilot, generate

lots of useless orders thereby increase the

probability of making errors and misunderstanding

on the way pilot-navigator. Such a criterion can be

the determinant to assign the most effective

configuration of the pilots interface in Remote

Pilotage System.

Further researches will be focused on the

analysis of graphics methods for communication

the navigational information.

It should be mentioned, that the simulation

methods, except its’ numerous advantages e.g. cost

effective, possibility of research environment free

creation, have also disadvantages. For instance:

faulty projection of distance in 3D visualization and

psychological effect with feeling of safety in virtual

reality. Above mentioned problems will be also the

subject of further researches on the test-bed within

RPS development process.

References

1. WEINTRIT A., WAWRUCH R., SPECHT C., GUCMA L., PIE-

TRZYKOWSKI Z.: Polish Approach to E-Navigation Con-

cept. Trans-Nav’2007, Gdynia 2009.

2. BASKER S.: E-Navigation: The way ahead for the maritime

sector. Trinity House, September, London 2005.

3. MITROPOULOS E.: E-navigation: a global resource. Sea-

ways, The International Journal of the Nautical Institute,

March 2007.

4. PATRAIKO D.: Introducing the e-navigation revolution.

Seaways, The International Journal of the Nautical Insti-

tute, March 2007.

5. WEINTRIT A. WAWRUCH R.: Future of Maritime Naviga-

tion, E-Navigation Concept. Proceedings of 10th Interna-

tional Conference “Computer Systems Aided Science,

Industry and Transport” TRANSCOMP’2006, Zakopane,

Poland, 4–7 December 2006.

Documents

Analysis of methods for communication the navigational