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: r.gralak@am.szczecin.pl
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;
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
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
• 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 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
Fig. 8. Average time of execution the pilots’ orders for 3D (no offset) pilot’s interface
Rys. 8. Średni czas realizacji komendy pilota przy zastosowa-niu interfejsu 3D
Fig. 9. Average time of execution the pilots’ orders for 3D (with offset) pilot’s interface
Rys. 9. Średni czas realizacji komendy pilota przy zastosowa-niu interfejsu 3D z możliwością decentrowania
Performing the results analysis for the passages
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
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,17 5,69 no thruster 4,90 7,13 3,10 T im 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
Proppeler Rudder Thruster 5,50 6,17 no thruster 6,33 5,12 4,00 4,54 8,67 3,50 T im e [s ] 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 6,75 no thruster 5,78 4,88 no thruster 5,09 7,25 3,50 T im 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)(no_offset)3D+sound 2D+sound 0,00 0,00 5,26 0,00 6,98 9,09 5,66 6,38 7,04 Pe rce n 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
Fig. 13. Manoeuvring safety limits with faults marked for 3D no offset pilot’s interface
Rys. 13. Bezpieczne granice manewrowe statku z ewidencją 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) (with_offset)3D+sound percentage Average of faults for sound communication Pe rc en t [% ]
Fig. 14. Manoeuvring safety limits with faults marked for 3D with offset pilot’s interface
Rys. 14. Bezpieczne granice manewrowe statku z ewidencją 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.
